2020-09-25

AndroidおよびiOSのInstagramアプリに存在するMozjpeg実装に係る脆弱性について

脆弱性情報サイバーセキュリティベンダーレポート

f:id:micro_keyword:20200925201829j:plain:w400

CheckPointより、 AndroidおよびiOSのInstagramアプリに存在するRCE脆弱性の内容が公開されました。

research.checkpoint.com

当該脆弱性については、2020年2月10日にFacebookよりリリースされたパッチにて修正済みです。

以前にも、Instagramの脆弱性はご紹介しましたが、この時はパスワードリセットの仕組みに問題があり、アカウント乗っ取りができてしまうというものでした。

micro-keyword.hatenablog.com

今回公開されたRCE脆弱性は半年前に修正済みでもありますし、悪用の事実も確認されていないとのことなので、緊急度は高くないですが、法人も含め多くの人が使うアプリなので簡単にまとめてみます。

Instagramが使用するサードパーティのライブラリMozjpegの実装方法に脆弱性
- Mozjpegは、JPEG形式のデコーダーとして使用するオープンソースツール
画像のサイズが約4.3GB(2³²)以上の場合に整数オーバーフローが発生する
- 画像サイズ = width(横) × height(縦) × output_components(主にRGBの要素)
整数オーバーフローを起因として、ヒープバッファオーバーフローが引き起こされる
結果、攻撃者はInstagram上で任意のコード実行が可能になる
2020年2月10日にFacebookよりリリースされたパッチにて修正済み

Mozjpegとは

2014年3月5日に、「mozjpeg」プロジェクトとして、Mozillaが発表
JPEGファイルの圧縮に定評のある、画像エンコーダー
画像を圧縮しファイルサイズ減らすことで帯域への負荷を減らす
クライアント側でWeb画像をより速く読み込むことができる

攻撃シナリオ

攻撃者は電子メールやWhatsAppなどのSNS、その他のオンラインストレージを介して画像を被害者に送信するだけ
被害者が画像を選択し、Instagramアプリを開くと成功
攻撃者は端末へのアクセスが可能になる
- Instagramのアプリに対して許可している操作
  - 連絡先
  - 端末のストレージ
    - 画像や動画ファイルをはじめとしたさまざまなファイル
  - 位置情報
  - 端末のカメラ
もちろんInstagramの操作も可能
- ダイレクトメッセージの閲覧
- 画像や動画の投稿や削除
一度、攻撃が成功すると、アプリを削除して再インストールしない限り、被害者の端末上でクラッシュを続ける

まとめ

内容自体の重要度も考慮しつつですが、今回は、端的にまとめてみました。

CheckPointのブログ記事にも記載がありますが、今やどのアプリケーションにおいても、サードパーティ製のツールを組み込んでいるといっても過言ではありません。

今回は、Instagram側での実装方法に問題があったため、脆弱性を生み出してしまっていましたが、ツール自体に脆弱性が含まれている可能性も大いにあります。

まずは、日々の情報収集や脆弱性の種類を把握しつつ、ひょっとしたら。。というくらいの感覚で、他のアプリケーションにも類似の脆弱性があるのではないかと疑ってみるのが大事なのかなと思います。

つい先日のドコモ口座不正送金の件も、そうですよね。

micro-keyword.hatenablog.com

単一の物事に対し、良い、悪い。と決めるのではなく、もう一歩踏み込んで考えて、同じ失敗を繰り返さないようにすること。

少し話は逸れますが、コロナ禍における諸々の対策についても、こういった心構えで向き合えるといいのかなと思ってます。

2020-09-15

Magentoで構築されたECサイトを狙った過去最大規模の攻撃について

サイバーセキュリティインシデントベンダーレポートマルウェア脆弱性情報

f:id:micro_keyword:20200915025228j:plain:w400

ECサイトのセキュリティ対策などに強みを持つオランダのセキュリティベンダSansecの発表により、今週末(2020年9月11日~14日)にかけて、Magentoで構築されたECサイトに対する過去最大規模の攻撃が観測されたことが明らかになりました。

sansec.io

本攻撃は、特にMagentoで構築されたECサイトを狙う攻撃グループとして知られるMagecartによる攻撃だとされています。

Magecartについては、過去の記事でも紹介しているので、ご参考にしてください。

micro-keyword.hatenablog.com

2020-09-14T09:57:06  92.242.62.210  GET /downloader/ HTTP/1.1
2020-09-14T09:57:09  92.242.62.210  POST /downloader/ HTTP/1.1
2020-09-14T09:57:09  92.242.62.210  GET /index.php/admin/?SID=XXXX HTTP/1.1
2020-09-14T09:57:10  92.242.62.210  GET /index.php/admin/dashboard/index/key/<hash>/ HTTP/1.1
2020-09-14T09:57:13  92.242.62.210  GET /index.php/admin/system_config/index/key/<hash>/ HTTP/1.1
2020-09-14T09:57:15  92.242.62.210  GET /index.php/admin/system_config/edit/section/dev/key/<hash>/ HTTP/1.1
2020-09-14T09:57:19  92.242.62.210  POST /index.php/admin/system_config/save/section/dev/key/<hash>/ HTTP/1.1
2020-09-14T09:57:20  92.242.62.210  GET /index.php/admin/system_config/edit/section/dev/key/<hash>/ HTTP/1.1
2020-09-14T09:57:22  92.242.62.210  GET /index.php/admin/import/index/key/<hash>/ HTTP/1.1
2020-09-14T09:57:25  92.242.62.210  POST /index.php/admin/import/validate/key/<hash>/ HTTP/1.1
2020-09-14T09:57:25  92.242.62.210  GET /downloader/ HTTP/1.1
2020-09-14T09:57:28  92.242.62.210  POST /downloader/index.php?A=connectInstallPackageUpload&maintenance=1&archive_type=0&backup_name= HTTP/1.1
2020-09-14T09:57:29  92.242.62.210  GET /downloader/index.php?A=cleanCache HTTP/1.1
2020-09-14T09:57:31  92.242.62.210  GET /mysql.php HTTP/1.1

不正なコードを一通りprototype.jsに追加したのち、取得されたファイルは自動的に削除されます。

この、prototype.jsは、被害を受けたMagento 2のサイトではjquery.jsという名で見つかっているようです。

いずれのjsファイルにおいても、以下のソースコードからわかるようにmcdnn[.]netドメインから、同じマルウェアwidget.jsの取得を試みるようです。

//mcdnn[.]net/122002/assets/js/widget.js はインストールされたパスのページに応じた動的コンテンツを提供します。

そして、チェックアウトページから参照されたときのみ、悪意のあるキーロガーが取得されるとのことです。

実際の支払いは、モスクワにホストされているhttps://imags[.]pw/502.jspに漏洩するとのことで、当該ドメインはmcdnn.netと同じネットワークに所属するとのことです。

まとめ

先日、WordPressのプラグインにて確認された脆弱性の記事を公開しましたが、CMSへの脅威としては、Magento含め他のプラットフォームにも広く存在します。

micro-keyword.hatenablog.com

自身も、サイト運営などを試みていますが、脆弱性対応含め、運用って大変だな～と思う次第です。

もちろん、目的次第ではありますが、ブログにしてもアプリにしても、SaaSを利用した利便性に甘んじたくなってしまいますよね。

まずは、実際にトライしてみて、それぞれの方法における利点欠点が確認できると一番いいのかなと思っています。

2020-09-10

PayPayやメルペイは関係ないでいいんだっけ？ドコモ口座の不正送金問題を踏まえた考察

インシデントサイバーセキュリティ

9月8日ごろから話題になっている、「ドコモ口座を悪用した不正送金問題」について、当ブログでも深堀りをしようと思い、まとめることにしました。

www.nikkei.com

以前、7pay事件の際にも、記事を書きましたが、ちょっと似たような空気を感じています。

micro-keyword.hatenablog.com

理由については、記事の最後で書きますが、まずは本題から行きましょう。

まずは不正送金の流れを確認
- 攻撃者はどうやって暗証番号を入手するのか
なぜ自身の銀行口座が他人のアカウントに紐づくのか
- 攻撃者目線で考えるSMS認証の重要性
- SMS認証に対応している決済サービス
銀行口座登録が本人確認という不思議
被害リスクを低減するために
まとめ

まずは不正送金の流れを確認

まず、今回の不正送金の流れを図でご説明します。

f:id:micro_keyword:20200911145004j:plain

攻撃者はどうやって暗証番号を入手するのか

攻撃者ははじめに、何らかの方法で口座番号、名義、暗証番号などを入手します。

暗証番号の入手に関しては、別のサービス経由で漏洩している場合もありますが、今回の攻撃では、リバースブルートフォースという手法で取得された可能性が指摘されています。

リバースブルートフォースは、ブルートフォースの逆で、パスワードを固定し、口座番号を総当たりで特定する手法です。

f:id:micro_keyword:20200910234619j:plain

暗証番号は連続で失敗すると、アカウントロックがかかりますが、その逆はロック対象のアカウントがそれぞれ異なるので、アカウント単位でのロックができません。

リバースブルートフォースの対策としては、単にID・パスワードの認証だけではなく、後述するSMS認証を挟むことや、秘密の質問やCAPTCHAなど別の認証を挟むことが挙げられます。

あとは、一定時間のログイン拒否や同一パスワードを使うユーザの強制ロックなどがありますが、ユーザの利便性を大きく損なうのであまり対策としてはお勧めできません。

では、本来リバースブルートフォース対策となりうる、SMS認証について掘り下げます。

なぜ自身の銀行口座が他人のアカウントに紐づくのか

ドコモ口座を例に挙げると、銀行口座の連携には、dアカウントを作成した後、ドコモ口座を作成し、銀行口座と結びつけることで口座利用が可能になります。

f:id:micro_keyword:20200910234633j:plain

これ自体の仕組みは、ドコモ口座ないしdアカウントに限らず、PayPayやメルペイなどの決算手段においても、あまり変わりはなさそうです。

では、ドコモ口座の何がまずかったのかというと、dアカウントの作成ハードルが非常に低く、攻撃者が悪用後すぐに破棄することで足がつきにくいという点です。

dアカウントは、他の電子決済サービスに使われるアカウントとは異なり、Eメールアドレスのみで作成可能で、作成が非常に容易です。

この点に関しては、NTTドコモが対策に踏み切っており、現在dアカウント作成時には、SMSを利用した2段階認証が必須です。

mainichi.jp

すでに、公式ページでのアカウント作成手順も変更されていて、これまでがどうだったかを示す素材がなかったのですが、以下のブログに手順が残っていたので、気になる方はご確認ください。

estpolis.com

攻撃者目線で考えるSMS認証の重要性

文章だと分かりづらいと思い、こちらも筆者が想定する攻撃シナリオとして図を作成したので、ご参考にしてください。

f:id:micro_keyword:20200911145534j:plain

もし、SMS認証があれば、dアカウント作成の段階で、電話番号を所持している個人に目星が付くので、少なくともEメールアドレスよりも攻撃者にとってはリスクが上がります。

さて、ここで気になってくるのが、他の決済サービスではアカウント作成時に2段階認証を導入しているのかという点です。

2段階認証の有無で、先述の通り、攻撃者の利用ハードルが下がります。

SMS認証に対応している決済サービス

以下の、マイナポイント人気決済サービスを参考に、決済手段に対し、銀行口座からのチャージをおこなう前に、2段階認証が導入されているかどうか、状況を確認してみましたので、ご活用ください。

news.mynavi.jp

決済サービス	2要素認証の導入	備考
d払い(dアカウント)	×→○	今回の件を機に導入 https://mainichi.jp/articles/20200909/k00/00m/040/282000c
PayPay	○	登録時にSMS認証必須 https://paypay.ne.jp/guide/start/
メルペイ(メルカリアカウント)	○	メルカリ登録時にSMS認証が必要 https://jp-news.mercari.com/2018/11/26/signup/
auPAY(auID)	○	auPAY利用開始時にSMS認証が必要。auIDはSMS認証なし https://wallet.auone.jp/contents/sp/guide/other.html https://id.auone.jp/id/sp/guide/regist/another/index.html
楽天ペイ	○	楽天ペイ利用開始時にSMS認証が必要。楽天会員登録にはSMS認証なし https://pay.rakuten.co.jp/
LINE Pay(LINEアカウント)	○	LINEアカウント作成時にSMS認証必須。Facebook認証は2020年3月に撤廃 https://guide.line.me/ja/signup-and-migration/line-signup.html https://pay.line.me/portal/jp/about/sign-up https://guide.line.me/ja/update/0002.html
ファミペイ	○	登録時にSMS認証必須 https://www.family.co.jp/famipay/app.html
J-Coin Pay	○	登録時にSMS認証必須 https://j-coin.jp/user/guide/
ゆうちょpay	○	登録時に電話番号認証必須 https://www.jp-bank.japanpost.jp/kojin/sokin/yuchopay/kj_sk_yp_goriyo.html

一覧で見ていただくと分かるように、確かにdアカウントは特別抜け穴になってしまっていたようでした。

なお、コード決済ではなくICカード決済の場合は以下の通り、そもそも銀行口座チャージは提供していないものがほとんどで、唯一提供しているWAONも相当ハードルが高かったです。

WAON
- 銀行口座チャージはイオン銀行限定かつ、イオンのATMもしくはICカードリーダライタで手元のイオンカードを読み取る必要がある
- https://www.waon.net/charge/aeon_bank_account/
Suica
- 2019年9月に銀行口座からの入金サービスは終了
- https://www.jreast.co.jp/mobilesuica/new_s/bankchargestop20190408.html
nanaco
- 銀行口座からのチャージ機能はなし
- https://www.nanaco-net.jp/how-to/charge/
PASMO
- 銀行口座からのチャージ機能はなし
- https://www.pasmo.co.jp/charge/

先日スマートフォンのレビュー記事でご紹介した、ICカード決済の煩わしさは、セキュリティとのトレードオフだったんだなと、しみじみ感じます。

micro-keyword.hatenablog.com

銀行口座登録が本人確認という不思議

さて、このように基本的には各サービスにSMS認証が採用されていることが確認できました。

ただ、もうひとつ気になる点があります。

銀行口座の情報を知っている人=利用者本人

というロジックが通っていいのかという点です。

どういうことかというと、今回のドコモ口座では、「銀行口座は銀行側で本人確認しているため、本人確認材料になりうる」という前提のもと、銀行口座の登録による本人確認を認めているということです。

こうなってしまうと、たとえ、他人の口座番号や暗証番号であっても、本人確認の手段になってしまいます。

金融機関によっては、口座番号と暗証番号以外に二段階認証などを含めることで、銀行口座登録時に本人確認を行うのですが、地方銀行などを含め、ほとんどが、行われていないという実態なようでした。

詳しくは以下に掲載のリストが参考になりそうです。

piyolog.hatenadiary.jp

筆者自身も決済手段のうち、いくつのサービスが、銀行口座登録による本人確認を認めているか、調べてみました。

紛らわしくて恐縮ですが、「可」としているサービスが銀行口座登録による本人確認を認めているので、ご注意ください。

なお、各社の情報に基づいて、筆者が解釈した情報なので、実際に利用されている方で、事実と異なる事象を確認された場合、ご連絡いただければと思います。

決済サービス	銀行口座登録による本人確認	備考
d払い(ドコモ口座)	可	2020/9/10 現在新規紐づけ停止中 https://docomokouza.jp/detail/about.html?dcmancr=b1c41d0acc052e62.1599706803461.8325.1599706812932_68897292.1598457716_39
PayPay	可	https://paypay.ne.jp/guide/auth/
メルペイ	可	https://www.mercari.com/jp/help_center/article/918/
auPAY(auID)	不可	じぶん銀行は本人確認書類必須その他の銀行はローソンのATMで本人確認 https://www.jibunbank.co.jp/account/?code=KD6CMC140506 https://wallet.auone.jp/contents/pc/guide/lawsonbank_charge.html
楽天ペイ	不可	本人認証サービス（3Dセキュア）が必要。そもそも、楽天カード、楽天銀行、ラクマ経由のチャージのみ可能 https://pay.rakuten.co.jp/
LINE Pay(LINEアカウント)	可	http://pay-blog.line.me/archives/75806865.html
ファミペイ	可	チャージはレジorクレジットカードor銀行口座銀行口座は各金融機関の本人確認に依存しているので実質本人確認可能 https://famidigi.jp/famipay/about-registration/index.html#credit
J-Coin Pay	不可	本人確認書類が必須 https://j-coin.jp/user/identification/
ゆうちょpay	可	ただしゆうちょ銀行に限る https://www.jp-bank.japanpost.jp/kojin/sokin/yuchopay/kj_sk_yp_goriyo.html

この表を見る限り、どのサービスにおいても本人確認を金融機関に依存してしまっているように見えます。

こうなった場合、連携する金融機関次第では、決済サービスも脆弱なサービスとなってしまうわけです。

もちろん、金融機関ごとのセキュリティ向上も必要ですが、サービス事業者も利便性向上ばかりではなく、金融機関を正しく評価した上で連携を実装することも重要になってきますね。

そして、利用者自身も、利便性だけでなく、セキュリティ面を考慮したうえでのサービス利用することが、結果、自分を守ることになるのかなと思います。

被害リスクを低減するために

今回の件に関しては、冒頭から申し上げている通り、ドコモ口座を責めるというのは少し筋が違うと思っています。

その点に関しては、サービス事業者、金融機関、ユーザのリテラシー向上や相互理解が大切かなと思っています。

私自身、ユーザとしての立場で気を付ける点を書いてみたので、参考にしていただければ幸いです。

被害リスクを低減するために
- 口座連携のハードルが高い銀行を利用するよう心掛ける
  - zaimやマネーフォワードを使っている人ならそのあたりの勘所がわかるかも。
  - 連携がめんどくさいほど、セキュリティが強固だという思考に変える。
  - ワンタイムパスワードや乱数表の併用が必要な銀行はセキュリティが高いと考えられる。
- 決済サービスを使うこと自体のリスクとは切り離して考えるべき
  - 今回もドコモ口座やdアカウントが悪用されたものであり、自身の利用する決済サービスが被害に遭ったわけではない。
  - 時代に合わせて、サービスを利用することが、ユーザリテラシーの向上にもつながると思う。

まとめ

冒頭で述べた通り、個人的にはこういった問題が起きたとき「7Payやばい、2要素認証なしとか草生えるww」とか「ドコモ口座ザルすぎ、わろたww」みたいな事業者を叩く、謎な流れになるのがいやです。

「サービス提供者=悪」で片づけるのではなく、今回顕在化したリスクが、本当に被害に遭ったサービスだけの問題なのか、というところまで考えることが、大人の対応なのかなと思います。

個人の話ですが、小学校の時に、いじめが問題になって、その時の先生の対応を思い出します。

「いじめっ子のA君の何が悪かったかみんなで紙に書いて提出しましょう」

これがその時の先生の対応です。

結果として、いじめっ子をさらにいじめることになっている子の対応に、子どもながらに「やばいな、このおばはん」と思いましたw

もちろん、当人にも非はありますが、そこを叩くことは解決策でも何でもない。

言いたいのはそういうことなんです。

今回の件を通して、少しでもサービス提供者の気持ちになって考えてあげられると、いいのかな、なんて思います。

改訂履歴

2020/09/11
- ドコモ口座からの出金について、「セブン銀行ATMからの出金はドコモキャリア回線契約者のみが可能」とのご指摘をいただき、その旨、公式サイトより事実確認ができたため、修正しました。
- 参考URL https://docomokouza.jp/detail/transfer.html

2020-09-03

WordPressのプラグインFile Managerの脆弱性を悪用した攻撃が確認。70万以上のサイトに影響か。

インシデントサイバーセキュリティベンダーレポート脆弱性情報

f:id:micro_keyword:20200903024854j:plain:w400

Wordfenceのブログにて、WordPressのプラグインFile Managerに存在していたゼロディ脆弱性と攻撃の悪用情報が明らかになりました。

wordfence.com

当該脆弱性のパッチは、昨日、2020年9月1日(現地時間)に公開されたとのことですが、アクティブインストールの数も700,000件を超えており、早急なバージョンアップが推奨されています。

当記事では、脆弱性に関する情報と周辺情報をまとめ、公開します。

脆弱性の概要
- プラグインに含まれるライブラリelFinderが脆弱性の起点として使われていた
  - elFinderはオープンソースのファイルマネジャーで、ファイル管理のためのインターフェース作成およびコア機能を提供している
- elFinderに含まれるconnector.minimal.php.distファイルの拡張子を.phpに直接変更することができる
- 本来であれば、アクセス制御なしに利用されることが想定されていない当該ファイルに、アクセス制御がかかっていないことが問題
  - つまり、誰にでもアクセスできてしまう
- このファイルにより、elFinderのコマンドを開始できてしまう
  - 以下に、実行可能なコマンドリストを転記します(割といろいろなことができます)

/**
  * Commands and required arguments list
  *
  * @var array
  **/
 protected $commands = array(
     'abort' => array('id' => true),
     'archive' => array('targets' => true, 'type' => true, 'mimes' => false, 'name' => false),
     'callback' => array('node' => true, 'json' => false, 'bind' => false, 'done' => false),
     'chmod' => array('targets' => true, 'mode' => true),
     'dim' => array('target' => true, 'substitute' => false),
     'duplicate' => array('targets' => true, 'suffix' => false),
     'editor' => array('name' => true, 'method' => true, 'args' => false),
     'extract' => array('target' => true, 'mimes' => false, 'makedir' => false),
     'file' => array('target' => true, 'download' => false, 'cpath' => false, 'onetime' => false),
     'get' => array('target' => true, 'conv' => false),
     'info' => array('targets' => true, 'compare' => false),
     'ls' => array('target' => true, 'mimes' => false, 'intersect' => false),
     'mkdir' => array('target' => true, 'name' => false, 'dirs' => false),
     'mkfile' => array('target' => true, 'name' => true, 'mimes' => false),
     'netmount' => array('protocol' => true, 'host' => true, 'path' => false, 'port' => false, 'user' => false, 'pass' => false, 'alias' => false, 'options' => false),
     'open' => array('target' => false, 'tree' => false, 'init' => false, 'mimes' => false, 'compare' => false),
     'parents' => array('target' => true, 'until' => false),
     'paste' => array('dst' => true, 'targets' => true, 'cut' => false, 'mimes' => false, 'renames' => false, 'hashes' => false, 'suffix' => false),
     'put' => array('target' => true, 'content' => '', 'mimes' => false, 'encoding' => false),
     'rename' => array('target' => true, 'name' => true, 'mimes' => false, 'targets' => false, 'q' => false),
     'resize' => array('target' => true, 'width' => false, 'height' => false, 'mode' => false, 'x' => false, 'y' => false, 'degree' => false, 'quality' => false, 'bg' => false),
     'rm' => array('targets' => true),
     'search' => array('q' => true, 'mimes' => false, 'target' => false, 'type' => false),
     'size' => array('targets' => true),
     'subdirs' => array('targets' => true),
     'tmb' => array('targets' => true),
     'tree' => array('target' => true),
     'upload' => array('target' => true, 'FILES' => true, 'mimes' => false, 'html' => false, 'upload' => false, 'name' => false, 'upload_path' => false, 'chunk' => false, 'cid' => false, 'node' => false, 'renames' => false, 'hashes' => false, 'suffix' => false, 'mtime' => false, 'overwrite' => false, 'contentSaveId' => false),
     'url' => array('target' => true, 'options' => false),
     'zipdl' => array('targets' => true, 'download' => false)
 );

ただし、脆弱性の悪用時も1点制限があり、elFinderが備えるディレクトリトラバーサル機能により、 plugins/wp-file-manager/lib/files/ を超えた範囲でのコマンド実行はできないとのことです。`

確認された手法
- 実際の攻撃では、先ほど紹介したコマンドのうち upload が利用されていた
- upload　コマンドで、webshellを埋め込んだ画像を含むPHPファイルをアップロードしていた
- 配置先は plugins/wp-file-manager/lib/files/
- これまでに攻撃でアップロードが確認されたファイル名
  - hardfork.php
  - hardfind.php
  - x.php

利用状況と日本ユーザへの影響予測

公式サイトからも確認できる通り、File Managerは70万件以上のアクティブインストールが確認されています。

f:id:micro_keyword:20200903025009p:plain

そして、2020年9月3日現在、パッチ適用後のバージョン6.9へアップデートしているのは全体の6.8%とのことなので、まだ、6万5,000件以上のサイトが脆弱な状況であると分かります。

公式サイトからは、日本のユーザがどの程度存在するかはわかりません。

ただ、Googleで「wordpress file manager 日本語」と検索しても、50万件以上ヒットすること。

また、サポートサイトを見る限り、日本語化対応もされていることから、おそらく影響範囲も広いと考えられます。

ja.wordpress.org

WordPress運用者へのススメ

以前にも当ブログでは、WordPress プラグインの脆弱性について取り上げました。

micro-keyword.hatenablog.com

WordPress プラグインの脆弱性といっても、年間で相当な数の情報が上がってくるため、すべてをウォッチし対処するのは現実的に難しいと考えています。

明確に基準を設けているわけではないですが、おおよそ以下のような判断基準で記事にまとめています。

脆弱性が確認されたプラグインが100万件近くインストールされていること
- 50万件以上であっても日本への影響次第では発信することもある
脆弱性の悪用がすでに確認されていること

また、WordPressに関する脆弱性情報の収集源としては、以下の2つのサイトを活用しています。

Wordfenceブログ
- https://www.wordfence.com/blog/
SUCURIブログ
- https://blog.sucuri.net/

もちろん、これらのサイトを見ていれば、網羅できるというわけではありませんが、特にこの2社はWordPressを専門とするセキュリティベンダなだけあって、情報のキャッチアップには優れています。

WordPressのホスティングソリューションを提供するKinstaというベンダもこの2社の比較記事をリリースしているくらいですからね。

kinsta.com

まとめ

今回は、脆弱性情報とともに、WordPress関連の脆弱性情報収集についても少し触れました。

私自身、ブログをWordPressに切り替える検討を、随時行っていて、セキュリティ情報をウォッチしていることもあり、WordPress関連の脆弱性は運用負荷に大きく影響を与えるものだと思っています。

そのため、こういった情報が運用者の皆様に役立てばと思い、記載させていただきました。

そういった情報はさておき、兎にも角にも、今回の記事の本質は、File Managerの早期アップデートです。

File Managerの利用が思い当たる方は、記事を確認次第、お早めのアップデートをご検討ください。

2020-09-02

WindowsにVisual Studio CodeをインストールしてDjangoの開発環境を快適にしてみた

IT活用

f:id:micro_keyword:20200902175302j:plain:w400

先日、やってみた系の記事として、Djangoで作ったアプリケーションをAWS Elastic Beanstalkへデプロイする方法をご紹介しました。

今回は、デプロイする前の開発段階で、ローカルのコーディングをより効率化する開発環境のご紹介です。

タイトルですでにお察しかとは思いますがVisual Studio Code、通称VSCodeです！

今回は、VSCodeの簡単なご紹介とDjangoの開発環境構築チュートリアルをご紹介します。

アプリケーション開発に限らず、HTMLやCSS、Markdownの編集やPythonやRuby、JavaScriptのコーディングにも使えてとても便利なので、ぜひ試してほしいという思いを込めて！

VSCodeとは
- エディタの一種
  - Windows、Macともにメモ帳が用意されていますが、それもエディタですね。
  - 学生や社会人なりたての頃は、サクラエディタを使っていました。
  - ちなみに、ブログの執筆は、HackMDを使っています。

VSCodeの強み

開発者向けの機能
- テキストのエディット機能だけでなく、プログラミングやシステム開発に関する機能が用意されています。
- コードに色づけしてくれたり、コードの補完をしてくれたりします。
- ターミナル機能も付いているので、コマンドプロンプトをわざわざ開く必要もありません。
オープンソース
- めちゃくちゃ高機能にもかかわらず無料です。ありがたい。
複数OSに対応
- Windows、Mac、Linuxに対応しています。

プログラミング技術に関するナレッジコミュニティStack Overflowの2019年の調査では、Visual Studio Codeが最も人気のある開発者環境ツールとして評価されており、回答者の過半数である50.7%(87,317人中)が使用していると回答しました。

f:id:micro_keyword:20200902173427p:plain

insights.stackoverflow.com

本調査の2020年版では、開発環境のランキングはありませんでしたが、その他の調査内容も非常に興味深いものばかりだったので、併せてご確認いただければと思います。

開発者の経歴や志向、給料など幅広く調査されているので、眺めているだけでも、自身がどういう位置づけなのかを知る参考になるかなと。

insights.stackoverflow.com

Django開発環境のセットアップ

それでは、簡単にDjango開発環境をセットアップするまでの流れをご紹介します。

Djangoアプリケーションは、以前紹介した以下の記事をもとに作成していただくと、そのままお使いいただけるかなと思います。

AWS Elastic Beanstalkを使ってDjangoアプリをデプロイしてみた(後編) - みっきー申す

ちなみに、筆者はWindows10で実行しています。

VSCodeのインストール

以下のサイトからDownload for Windowsをクリックして、インストーラVSCodeUserSetup-x64-x.xx.x.exeをダウンロードします。

code.visualstudio.com

f:id:micro_keyword:20200902173139p:plain

先ほどの、インストーラを実行して、案内通りに進めていけば、躓くことなくインストールができるかと思います。

まず、使用許諾書への同意です。問題なければ、「同意する」を押して、「次へ」をクリックしてください。

f:id:micro_keyword:20200902173145p:plain:w400

続いて、インストール先の指定です。

こちらもこだわりがなければ、デフォルトの設定のまま、「次へ」をクリックしてください。

f:id:micro_keyword:20200902173149p:plain:w400

確認のポップアップが出ますが、こちらも「はい」をクリックしてください。

f:id:micro_keyword:20200902173154p:plain:w400

続いてスタートメニューフォルダの指定ですが、こちらもこだわりがなければ、デフォルトのまま「次へ」をクリックしてください。

f:id:micro_keyword:20200902173200p:plain:w400

追加タスクの選択では、デフォルトのままでもいいのですが、標準のエディタとしたい場合は、「エクスプローラーのファイルコンテキストメニューに[Codeで開く]アクションを追加する」にチェックを入れて、インストールするのもよいかもしれません。

確認次第、「次へ」をクリックしてください。

f:id:micro_keyword:20200902173204p:plain:w400

最後に確認画面が出るので、「インストール」をクリックしてください。

f:id:micro_keyword:20200902173209p:plain:w400

1分もたたないうちに完了すると思います。

f:id:micro_keyword:20200902173214p:plain:w400

開発環境の整備

それでは、VSCodeを使って、ローカル環境にセットアップしたDjangoを実行するまでをご説明します。

VSCode を起動し File から Open Folder... をクリック、プロジェクトのディレクトリ(前回のAWS EBで作成された環境をお使いの方ならばtrial_django）を開きます。

f:id:micro_keyword:20200902173108p:plain

次に、Python の Extension を install します。

下図の通り、左タブの上から5番目、「Extensions」をクリックし、検索タブでpythonと入力。

PythonのExtensionをクリックして、インストールしてください。

f:id:micro_keyword:20200902173114p:plain

次に、View の Command Palette... を選択。

f:id:micro_keyword:20200902173120p:plain

Python : select interpreter をクリック

f:id:micro_keyword:20200902173127p:plain

仮想環境(前回のAWS EBで作成された環境をお使いの方ならばeb-virt）のinterpreterを指定してください。

f:id:micro_keyword:20200902173133p:plain

もし、仮想環境の選択肢にeb-virtが出てこない場合は、仮想環境は上の階層にあるので、「Enter interpreter path」でDjango_workspace\eb-virt\Scripts\python.exeを選択してください。

もちろん、Djangoプロジェクトのフォルダ(前回の記事でいうところのtrial_django)に仮想環境を作るのもありです。

そうした場合、プロジェクトごとに仮想環境が用意できますね。

そして最後に、左タブの上から5番目、虫のアイコンをクリック後、歯車アイコンをクリックします。

この時自動的に、Python:Djangoの環境が選択されるはずなのですが、うまくいかない場合は、手動でPythonおよびDjangoを選択してください。

そして、緑の▶(再生ボタン)を押すと、Debug Console上でアプリケーションが起動します。

webブラウザで 127.0.0.1:8000 へ飛ぶといつものロケット発射が確認できるかと思います。

f:id:micro_keyword:20200902174242p:plain:w400

以下、トラブルシュートの例として、2点ご紹介しておきます。

実行時にエラーメッセージが出てしまった場合

PowerShellでの実行制限がかかっている可能性があります。
デフォルトではPowerShellの実行が制限されています。

以下を実行してみてください。

PowerShell Set-ExecutionPolicy RemoteSigned

RemoteSignedというのは、ローカル上のスクリプトと非ローカル上の署名のあるスクリプトのみ実行可能な権限のことです。

詳しくは、以下の記事などが参考になります。

qiita.com

DisallowedHost at /~ と表示された場合

EBのハンズオンを実行していた人は、AllowedHostの設定があるかと思いますので、削除をお願いします。

まとめ

今回は、エディタの紹介という、ちょっと違った視点でのご紹介でした。

VSCode自体、2015年の11月にリリースされたもので、比較的新しいソフトウェアですが、使い勝手はとても良いように感じています。

無料でこの機能は文句なしですし、基本これひとつで、大抵のPC作業は済んでいます。

情報感度の高い方は、もうすでにお使いかとは思いますが、開発者の方に限らず、Webデザイナーやブロガーの方にも是非この便利さを味わってもらいたいなと思いました。

2020-08-27

日本も標的！北朝鮮の攻撃グループ(LazarusおよびBeagleBoyz)による最近の活動

標的型攻撃マルウェアベンダーレポートサイバーセキュリティインシデント

f:id:micro_keyword:20200827193743p:plain:w400

フィンランドに本社を構えるセキュリティベンダーF-Secureの調査レポート、および米国のCISAとFBIと財務省が出した共同注意喚起にて、北朝鮮のサイバー犯罪グループLazarusおよびBeagleBoyzによる攻撃活動が立て続けに明らかになりました。

https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf

us-cert.cisa.gov

後述しますが、このBeagleBoyzというハッキンググループも、活動の共通点などからLazarusの派生組織だと考えられています。

Lazarusの記事は、先月もKasperskyの情報をもとにリリースしていますので、併せてご確認いただけると幸いです。

micro-keyword.hatenablog.com

今回の攻撃に用いられた手法は、昨年7月に、JPCERT/CCが公開した分析記事でも紹介されており、分析した検体の類似検体の多くのデコイ文書に、仮想通貨に関する内容が記載されており、「仮想通貨に関連する組織へ送信された」と言及していました。

blogs.jpcert.or.jp

F-Secureは、GDPRで保護されたと称する文書ファイルを確認しており、保護を解くためにマクロを有効にするよう促し、不正なリンクへとつながる短縮リンクへの接続、そして、C2サーバへのリダイレクトを試みていると述べています。

当該文書ファイルのサンプルは以下です。

f:id:micro_keyword:20200827192622p:plain

引用元：https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf

また、攻撃の流れについて、以下の図にて示しています。

f:id:micro_keyword:20200827193006p:plain

引用元：https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf

F-Secureの分析結果によると、最終的に取得される検体(資料ではMAIN IMPLANTSで紹介されている検体)を被害端末に感染させることで、攻撃者は被害端末から情報を盗み出していると考えられます。

世界中の銀行を標的にした攻撃

先述の通り、米国のCISA、財務省、FBIにより、注意喚起が発行された、世界中の銀行への標的型攻撃ですが、FASTCash 2.0と名付けられています。

関連するマルウェアの分析レポートも別途公開されているので、検体の挙動等は以下をご参照ください。

ECCENTRICBANDWAGON
- https://us-cert.cisa.gov/ncas/analysis-reports/ar20-239a
VIVACIOUSGIFT
- https://us-cert.cisa.gov/ncas/analysis-reports/ar20-239b
FASTCASH for Windows
- https://us-cert.cisa.gov/ncas/analysis-reports/ar20-239c

今回の活動は、RATを介して、銀行を強盗することに特化したハッキングチームによって行われており、米国政府はこのチームをBeagleBoyzと呼んでいます。

なお、BeagleBoyzは攻撃の手法や他の北朝鮮系ハッキンググループとの関連から、Lazarusの派生組織だと考えられています。

米国政府がFASTCash 2.0と名付けるこの活動については、2018年にアフリカやチリに対して行われたFASTCash事件の再来だと考えられます。

そのため、以前のFASTCashと合わせて、これまでに標的となった国々として以下の図の通り示しています。

図からもわかる通り、日本もその一部に含まれています。

また、攻撃の流れとして、以下のような図を公開しています。

まず、スピアフィッシングなどを起点に標的の金融機関への侵入を試み、金融機関の企業ネットワークに侵入。

その後、様々な手法を悪用し、組織内への横展開や権限奪取、永続的な潜入や検知回避を行います。

そして、注目すべきなのが、CISAの注意喚起中に、「従来の金融機関への強盗に加え、暗号通貨取引所を標的とした攻撃」と述べている点です。

おそらくですが、先述のF-Secureの記事とも関連があるのではないかと推測できます。

まとめ

今回は、LazarusおよびBeagleBoyzによる攻撃活動について、まとめてみました。

北朝鮮のサイバー攻撃に関して、最近、気になるトピックが多いですね。

朝鮮系ということで、北朝鮮だと断言はできないものの、DarkHotelに関しても気になる動きがみられますし。

micro-keyword.hatenablog.com

サイバー攻撃については、よく攻撃者優位なんてことが言われますが、まさにそのあたりを表しているような活動な気がしますね。

特に地理的に近い国なわけですし、引き続き、目が離せないなーというのが個人の感想です。

2020-08-27

コスパ最強！Google Pixel 4aを最速で購入して使ってみた

IT活用

f:id:micro_keyword:20200826234856j:plain:w400

2020年8月20日、Google Pixelシリーズの最新作Google Pixel 4aを購入しました！

Google Pixel 4aは昨年発売されたGoogle Pixel 4の廉価版モデルなのですが、前作のGoogle Pixel 3aも十分スペックが高く、発表前から高コスパスマホとして注目されていました。

私自身、4年ほど前SIMフリーに移行してからは、中古の端末(Xperia XZ、Xperia XZ1)を使っていたのですが、やはり型落ちした製品だということもあり、あまり満足はしていませんでした。

ただ、今回、発売されたGoogle Pixel 4aが税込み42,900円であることに驚き、それまで狙っていた、美品中古で42,800円のXperia 1(2019年6月販売)はあきらめ、購入を決断しました。

Xperia 1の参考情報は以下です。

akiba-pc.watch.impress.co.jp

今回は購入を決断した理由と、買ってみた感想をご紹介します。

ちなみに、私はGoogleの回し者ではなく、むしろSonyファンなので、その辺は安心して読んでいただければと思います(笑)

機種	値段
iPhone11(128GB)	87,780円(税込) 79,800円(税抜)
iPhoneSE(128GB)	54,780円(税込) 49,800円(税抜)
Google Pixel 4(128GB)	10万3,950円(税込)
Google Pixel 4a(128GB)	42,900円(税込)
XPERIA 5(128GB)	75,900円(税込)
Xperia 8(64GB)	33,310円(税込)

画面が大きくてキレイ
- 先ほどご紹介したレビュー記事にもありましたが、画面が大きいです
- そして有機ELディスプレイのキレイさに改めて感動します
動きがサクサク
- ゲームフリーズすることがなくなり、ストレスを感じなくなりました！
- ポケモンGOのPvPでフリーズして負けることがなくなりました(笑)
余計なアプリが入っていない
- これが意外と大きい！
- auやドコモ、ソフトバンクのスマホにプレインストールされているアプリ、煩わしいですよね。
- そして、これらが消せないというのが最悪。。。
- Googleのスマホなので、基本的にGoogleのアプリしか入っておらず、むしろ、これらは必須アプリなのでありがたい。
セキュリティアップデートの早期適用
- Androidの開発元であるGoogleの恩恵です
- どのAndroid スマホよりも早くアップデートが適用されるのは納得ですよね
- おそらく動作の面でも、Androidとの親和性が高いのだと思います
データ移行が簡単
- 写真でもご紹介した通り、初心者にも親切な初期設定ガイドが入っています
- データ移行も乗換元のスマホとコードでつなぐだけ
- これなら、機械弱い人も余裕ですね
- 相当iPhoneを意識しているのだと感じました
SIMカードの取り出しに驚き
- iPhoneユーザでないので、細い針を押し込んでSIMカードを取り出すスマートさに感動しました
- 海外行くときは細い針忘れられないなって思いました
- ちなみに筆者は、海外のSIM体験に苦い思い出が。。。
- 詳しくは以下の記事にて