日本を含む東アジアの企業を狙ったAPTグループBlacktech(Palmerworm)の新たな攻撃
米国のセキュリティベンダーSymantecにより、APTグループPalmerworm(別名BlackTech)の新たな攻撃キャンペーンが観測されました。
symantec-enterprise-blogs.security.com
BlackTechによる攻撃については、以前にも当ブログで紹介しました。
BlackTechの説明なども書いているので、併せてご確認ください。
今回の観測では、以前に紹介したPLEADではなく、新たなマルウェアファミリーの利用が確認されたとのことです。
今回は、この辺りの情報について簡単にまとめます。
目次
標的の組織と観測時期
今回の攻撃キャンペーンは、2019年8月から観測され、直近では2020年の8月に確認されているとのことです。
Symantecの観測結果を簡単にまとめた表が以下です。
| 国 | 業種 | 潜入期間 |
|---|---|---|
| 日本 | メーカー | 数日 |
| 台湾 | 金融機関 | 数か月 |
| 台湾 | メディア | 1年以上 |
| 台湾 | 電子機器メーカー | 数週間 |
| 中国 | 建設会社 | 数か月 |
| 米国 | 不明 | 約半年 |
また、Symantecも図にしてまとめてくれています。
攻撃キャンペーンで用いられた戦術
今回の香華キャンペーンで用いられた戦術を簡単にまとめてみます。
カスタムマルウェアの利用
新しく開発されたのか、既存のマルウェアの進化系なのかは定かではありませんが、4種類の検体が確認されています。
- 初めて観測された検体(Symantecの検知名)
- Backdoor.Consock
- Backdoor.Waship
- Backdoor.Dalwit
- Backdoor.Nomri
また、これらの検体の他に、以前の攻撃キャンペーンで観測された検体も確認されているとのことです。
- 以前にも確認されたマルウェア(Symantecの検知名)
Symantecは、これらの検体の観測されたことから、BlackTechの活動だと推測しているようです。
また、これらとは別にカスタムローダーとネットワーク偵察ツールの利用も確認しているとのことです。
Living Off the land攻撃
Living Off the land攻撃とは、「企業や組織で普段使いされることもある正規ツールを使った攻撃」を指し、記事中ではデュアルユースツールの利用も、この戦術の一部だとしています。
以下、今回の攻撃キャンペーンで確認されたツールです。
- Putty
- リモートアクセスに利用し、データの窃取などを行う
- PSExec
- Microsoftの正規ツール、被害者のネットワークにおける横展開に使う
- SNScan
- ネットワーク探索に利用する
- WinRAR
- ファイルの圧縮に利用するアーカイブツール
窃取などにより不正に取得したデジタル証明書を利用
以前、セキュリティベンダーのESETがブログで紹介していた攻撃キャンペーン同様、窃取などにより不正に取得したとみられるデジタル証明書の利用が今回も確認されていたようです。
参考として、ESETの記事も掲載します。
侵入経路は不明
ただし、過去のBlackTechの傾向から、スピアフィッシングメール経由だと推測されています。
まとめ
今回も、速報ベースで簡単にまとめてみました。
標的型攻撃は、被害に遭った組織でもない限りなかなか、その全容を把握できないので、セキュリティベンダーがこういった形で情報を展開してくれるのはありがたいですね。
9月も今日で最終日。
緊急事態宣言以降、筆者も在宅で仕事をしていますが、気づいたら半年経ってしまいました。
これを機にリモートでもできることをいろいろ始めてはいるものの、やっぱり人と会ってお話ししたいな～なんて思っています。
普段、ブログやTwitterを見ていただいている方々にオフ会とかでお会いできると楽しいんだろうなと思いつつ、それはまだ先のことになりそうです。
AndroidおよびiOSのInstagramアプリに存在するMozjpeg実装に係る脆弱性について
CheckPointより、 AndroidおよびiOSのInstagramアプリに存在するRCE脆弱性の内容が公開されました。
当該脆弱性については、2020年2月10日にFacebookよりリリースされたパッチにて修正済みです。
以前にも、Instagramの脆弱性はご紹介しましたが、この時はパスワードリセットの仕組みに問題があり、アカウント乗っ取りができてしまうというものでした。
今回公開されたRCE脆弱性は半年前に修正済みでもありますし、悪用の事実も確認されていないとのことなので、緊急度は高くないですが、法人も含め多くの人が使うアプリなので簡単にまとめてみます。
目次
脆弱性の概要
- Instagramが使用するサードパーティのライブラリMozjpegの実装方法に脆弱性
- 画像のサイズが約4.3GB(232)以上の場合に整数オーバーフローが発生する
- 画像サイズ = width(横) × height(縦) × output_components(主にRGBの要素)
- 整数オーバーフローを起因として、ヒープバッファオーバーフローが引き起こされる
- 結果、攻撃者はInstagram上で任意のコード実行が可能になる
- 2020年2月10日にFacebookよりリリースされたパッチにて修正済み
Mozjpegとは
- 2014年3月5日に、「mozjpeg」プロジェクトとして、Mozillaが発表
- JPEGファイルの圧縮に定評のある、画像エンコーダー
- 画像を圧縮しファイルサイズ減らすことで帯域への負荷を減らす
- クライアント側でWeb画像をより速く読み込むことができる
攻撃シナリオ
- 攻撃者は電子メールやWhatsAppなどのSNS、その他のオンラインストレージを介して画像を被害者に送信するだけ
- 被害者が画像を選択し、Instagramアプリを開くと成功
- 攻撃者は端末へのアクセスが可能になる
- Instagramのアプリに対して許可している操作
- 連絡先
- 端末のストレージ
- 画像や動画ファイルをはじめとしたさまざまなファイル
- 位置情報
- 端末のカメラ
- Instagramのアプリに対して許可している操作
- もちろんInstagramの操作も可能
- ダイレクトメッセージの閲覧
- 画像や動画の投稿や削除
- 一度、攻撃が成功すると、アプリを削除して再インストールしない限り、被害者の端末上でクラッシュを続ける
まとめ
内容自体の重要度も考慮しつつですが、今回は、端的にまとめてみました。
CheckPointのブログ記事にも記載がありますが、今やどのアプリケーションにおいても、サードパーティ製のツールを組み込んでいるといっても過言ではありません。
今回は、Instagram側での実装方法に問題があったため、脆弱性を生み出してしまっていましたが、ツール自体に脆弱性が含まれている可能性も大いにあります。
まずは、日々の情報収集や脆弱性の種類を把握しつつ、ひょっとしたら。。というくらいの感覚で、他のアプリケーションにも類似の脆弱性があるのではないかと疑ってみるのが大事なのかなと思います。
つい先日のドコモ口座不正送金の件も、そうですよね。
単一の物事に対し、良い、悪い。と決めるのではなく、もう一歩踏み込んで考えて、同じ失敗を繰り返さないようにすること。
少し話は逸れますが、コロナ禍における諸々の対策についても、こういった心構えで向き合えるといいのかなと思ってます。
Magentoで構築されたECサイトを狙った過去最大規模の攻撃について
ECサイトのセキュリティ対策などに強みを持つオランダのセキュリティベンダSansecの発表により、今週末(2020年9月11日~14日)にかけて、Magentoで構築されたECサイトに対する過去最大規模の攻撃が観測されたことが明らかになりました。
本攻撃は、特にMagentoで構築されたECサイトを狙う攻撃グループとして知られるMagecartによる攻撃だとされています。
Magecartについては、過去の記事でも紹介しているので、ご参考にしてください。
目次
攻撃の被害規模
今回攻撃の被害に遭ったサイトのほとんどは、2019年の6月にサポートが終了したMagento 1で構築されており、Magento 2で構築されたECサイトはわずかだったとのことです。
Sansecの観測では、現在も約95,000件のMagento 1プラットフォームが稼働しています。
Sansecの検知システムにて、Magentoのチェックアウトページへキーロガーの埋め込みが確認されたサイト数は1,904件で、日ごとの内訳としては、以下のようでした。
- 金曜日(2020/09/11)
- 10件
- 土曜日(2020/09/12)
- 1,058件
- 日曜日(2020/09/13)
- 603件
- 月曜日(2020/09/14)
- 223件
この情報が公開された当日が月曜日だったことから、本攻撃が今もなお継続している可能性があります。
また、Sansecの見解として、これら侵害されたサイトのうちひとつからは、数万件単位で顧客情報が漏洩していることが推定されています。
Sansecは2015年以降継続して、類似の攻撃を観測しているとのことですが、これまでの最大値は2019年7月に確認された962件であり、今回の攻撃が最大規模であることがわかります。
Our crawlers detected 962 breached stores last night. It is the largest automated campaign to date (previously: MGCore with 700 stores). Decoded skimmer: https://t.co/CCVakmMrR5 pic.twitter.com/nIHQFwtRXN
— Sansec (@sansecio) 2019年7月5日
ハッキングフォーラムで売買されるMagentoのゼロディ悪用方法
今回被害に遭ったECサイトでは、過去のセキュリティインシデントの被害にはあっていないとのことでした。そのことから、今回の攻撃において、新たな攻撃手法が用いられていると推測されます。
可能性として、8月の中旬にハッキングフォーラムにて売り出されたMagento 1のゼロディが利用されているのではないかと、Sansecは推測します。
以下の画像の通り、z3r0dayによって、$5,000でリモートコード実行の悪用方法を紹介したビデオを含むセットを販売している様子です。
販売数は10点なようですが、Magecartにまんま利用されている可能性は大いにありそうです。
攻撃の痕跡
Magecartの攻撃は、効果的に実行することを心掛けているからか、自動化した運用を行っていることが攻撃の痕跡からもわかります。
攻撃者は米国のサーバとフランスのサーバ(OVH)経由でMagentoの管理画面を操作し、Magento Connectという機能経由で、mysql.phpという名のマルウェアを含む様々なファイルを取得しています。
以下は、確認されたWebサーバへのアクセスログの一部です。
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含め他のプラットフォームにも広く存在します。
自身も、サイト運営などを試みていますが、脆弱性対応含め、運用って大変だな～と思う次第です。
もちろん、目的次第ではありますが、ブログにしてもアプリにしても、SaaSを利用した利便性に甘んじたくなってしまいますよね。
まずは、実際にトライしてみて、それぞれの方法における利点欠点が確認できると一番いいのかなと思っています。
PayPayやメルペイは関係ないでいいんだっけ？ドコモ口座の不正送金問題を踏まえた考察
9月8日ごろから話題になっている、「ドコモ口座を悪用した不正送金問題」について、当ブログでも深堀りをしようと思い、まとめることにしました。
以前、7pay事件の際にも、記事を書きましたが、ちょっと似たような空気を感じています。
理由については、記事の最後で書きますが、まずは本題から行きましょう。
目次
まずは不正送金の流れを確認
まず、今回の不正送金の流れを図でご説明します。
攻撃者はどうやって暗証番号を入手するのか
攻撃者ははじめに、何らかの方法で口座番号、名義、暗証番号などを入手します。
暗証番号の入手に関しては、別のサービス経由で漏洩している場合もありますが、今回の攻撃では、リバースブルートフォースという手法で取得された可能性が指摘されています。
リバースブルートフォースは、ブルートフォースの逆で、パスワードを固定し、口座番号を総当たりで特定する手法です。
暗証番号は連続で失敗すると、アカウントロックがかかりますが、その逆はロック対象のアカウントがそれぞれ異なるので、アカウント単位でのロックができません。
リバースブルートフォースの対策としては、単にID・パスワードの認証だけではなく、後述するSMS認証を挟むことや、秘密の質問やCAPTCHAなど別の認証を挟むことが挙げられます。
あとは、一定時間のログイン拒否や同一パスワードを使うユーザの強制ロックなどがありますが、ユーザの利便性を大きく損なうのであまり対策としてはお勧めできません。
では、本来リバースブルートフォース対策となりうる、SMS認証について掘り下げます。
なぜ自身の銀行口座が他人のアカウントに紐づくのか
ドコモ口座を例に挙げると、銀行口座の連携には、dアカウントを作成した後、ドコモ口座を作成し、銀行口座と結びつけることで口座利用が可能になります。
これ自体の仕組みは、ドコモ口座ないしdアカウントに限らず、PayPayやメルペイなどの決算手段においても、あまり変わりはなさそうです。
では、ドコモ口座の何がまずかったのかというと、dアカウントの作成ハードルが非常に低く、攻撃者が悪用後すぐに破棄することで足がつきにくいという点です。
dアカウントは、他の電子決済サービスに使われるアカウントとは異なり、Eメールアドレスのみで作成可能で、作成が非常に容易です。
この点に関しては、NTTドコモが対策に踏み切っており、現在dアカウント作成時には、SMSを利用した2段階認証が必須です。
すでに、公式ページでのアカウント作成手順も変更されていて、これまでがどうだったかを示す素材がなかったのですが、以下のブログに手順が残っていたので、気になる方はご確認ください。
攻撃者目線で考えるSMS認証の重要性
文章だと分かりづらいと思い、こちらも筆者が想定する攻撃シナリオとして図を作成したので、ご参考にしてください。
もし、SMS認証があれば、dアカウント作成の段階で、電話番号を所持している個人に目星が付くので、少なくともEメールアドレスよりも攻撃者にとってはリスクが上がります。
さて、ここで気になってくるのが、他の決済サービスではアカウント作成時に2段階認証を導入しているのかという点です。
2段階認証の有無で、先述の通り、攻撃者の利用ハードルが下がります。
SMS認証に対応している決済サービス
以下の、マイナポイント人気決済サービスを参考に、決済手段に対し、銀行口座からのチャージをおこなう前に、2段階認証が導入されているかどうか、状況を確認してみましたので、ご活用ください。
| 決済サービス | 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カード決済の煩わしさは、セキュリティとのトレードオフだったんだなと、しみじみ感じます。
銀行口座登録が本人確認という不思議
さて、このように基本的には各サービスにSMS認証が採用されていることが確認できました。
ただ、もうひとつ気になる点があります。
銀行口座の情報を知っている人=利用者本人
というロジックが通っていいのかという点です。
どういうことかというと、今回のドコモ口座では、「銀行口座は銀行側で本人確認しているため、本人確認材料になりうる」という前提のもと、銀行口座の登録による本人確認を認めているということです。
こうなってしまうと、たとえ、他人の口座番号や暗証番号であっても、本人確認の手段になってしまいます。
金融機関によっては、口座番号と暗証番号以外に二段階認証などを含めることで、銀行口座登録時に本人確認を行うのですが、地方銀行などを含め、ほとんどが、行われていないという実態なようでした。
詳しくは以下に掲載のリストが参考になりそうです。
筆者自身も決済手段のうち、いくつのサービスが、銀行口座登録による本人確認を認めているか、調べてみました。
紛らわしくて恐縮ですが、「可」としているサービスが銀行口座登録による本人確認を認めているので、ご注意ください。
なお、各社の情報に基づいて、筆者が解釈した情報なので、実際に利用されている方で、事実と異なる事象を確認された場合、ご連絡いただければと思います。
| 決済サービス | 銀行口座登録による本人確認 | 備考 |
|---|---|---|
| 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
WordPressのプラグインFile Managerの脆弱性を悪用した攻撃が確認。70万以上のサイトに影響か。
Wordfenceのブログにて、WordPressのプラグインFile Managerに存在していたゼロディ脆弱性と攻撃の悪用情報が明らかになりました。
当該脆弱性のパッチは、昨日、2020年9月1日(現地時間)に公開されたとのことですが、アクティブインストールの数も700,000件を超えており、早急なバージョンアップが推奨されています。
当記事では、脆弱性に関する情報と周辺情報をまとめ、公開します。
目次
脆弱性の概要と影響範囲
Wordfenceの脅威インテリジェンスチームの発表によると、WordPressのプラグインFile Managerにゼロディ脆弱性が存在し、すでに攻撃への悪用を確認しているとのことです。
脆弱性の影響は以下です。
- 認証されていないユーザがコマンド実行可能
- 悪意のあるファイルをサイトにアップロードすることが可能
- 結果、遠隔から任意のコードを実行することが可能になる
パッチはすでに公開されており、最新バージョン6.9へのバージョンアップで対応可能です。
以下、File Managerの公式ページ
- 脆弱性の概要
- プラグインに含まれるライブラリelFinderが脆弱性の起点として使われていた
- elFinderはオープンソースのファイルマネジャーで、ファイル管理のためのインターフェース作成およびコア機能を提供している
- elFinderに含まれる
connector.minimal.php.distファイルの拡張子を.phpに直接変更することができる - 本来であれば、アクセス制御なしに利用されることが想定されていない当該ファイルに、アクセス制御がかかっていないことが問題
- つまり、誰にでもアクセスできてしまう
- このファイルにより、elFinderのコマンドを開始できてしまう
- 以下に、実行可能なコマンドリストを転記します(割といろいろなことができます)
- プラグインに含まれるライブラリ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/ を超えた範囲でのコマンド実行はできないとのことです。`
- 確認された手法
利用状況と日本ユーザへの影響予測
公式サイトからも確認できる通り、File Managerは70万件以上のアクティブインストールが確認されています。
そして、2020年9月3日現在、パッチ適用後のバージョン6.9へアップデートしているのは全体の6.8%とのことなので、まだ、6万5,000件以上のサイトが脆弱な状況であると分かります。
公式サイトからは、日本のユーザがどの程度存在するかはわかりません。
ただ、Googleで「wordpress file manager 日本語」と検索しても、50万件以上ヒットすること。
また、サポートサイトを見る限り、日本語化対応もされていることから、おそらく影響範囲も広いと考えられます。
WordPress運用者へのススメ
以前にも当ブログでは、WordPressプラグインの脆弱性について取り上げました。
WordPressプラグインの脆弱性といっても、年間で相当な数の情報が上がってくるため、すべてをウォッチし対処するのは現実的に難しいと考えています。
明確に基準を設けているわけではないですが、おおよそ以下のような判断基準で記事にまとめています。
また、WordPressに関する脆弱性情報の収集源としては、以下の2つのサイトを活用しています。
- Wordfenceブログ
- SUCURIブログ
もちろん、これらのサイトを見ていれば、網羅できるというわけではありませんが、特にこの2社はWordPressを専門とするセキュリティベンダなだけあって、情報のキャッチアップには優れています。
WordPressのホスティングソリューションを提供するKinstaというベンダもこの2社の比較記事をリリースしているくらいですからね。
まとめ
今回は、脆弱性情報とともに、WordPress関連の脆弱性情報収集についても少し触れました。
私自身、ブログをWordPressに切り替える検討を、随時行っていて、セキュリティ情報をウォッチしていることもあり、WordPress関連の脆弱性は運用負荷に大きく影響を与えるものだと思っています。
そのため、こういった情報が運用者の皆様に役立てばと思い、記載させていただきました。
そういった情報はさておき、兎にも角にも、今回の記事の本質は、File Managerの早期アップデートです。
File Managerの利用が思い当たる方は、記事を確認次第、お早めのアップデートをご検討ください。
WindowsにVisual Studio CodeをインストールしてDjangoの開発環境を快適にしてみた
先日、やってみた系の記事として、Djangoで作ったアプリケーションをAWS Elastic Beanstalkへデプロイする方法をご紹介しました。
今回は、デプロイする前の開発段階で、ローカルのコーディングをより効率化する開発環境のご紹介です。
タイトルですでにお察しかとは思いますがVisual Studio Code、通称VSCodeです！
今回は、VSCodeの簡単なご紹介とDjangoの開発環境構築チュートリアルをご紹介します。
アプリケーション開発に限らず、HTMLやCSS、Markdownの編集やPythonやRuby、JavaScriptのコーディングにも使えてとても便利なので、ぜひ試してほしいという思いを込めて！
目次
Visual Studio Codeとは
まず、Visual Studio Codeとは何ぞや。という方のために、簡単な説明を。
- VSCodeとは
VSCodeの強み
- 開発者向けの機能
- オープンソース
- めちゃくちゃ高機能にもかかわらず無料です。ありがたい。
- 複数OSに対応
プログラミング技術に関するナレッジコミュニティStack Overflowの2019年の調査では、Visual Studio Codeが最も人気のある開発者環境ツールとして評価されており、回答者の過半数である50.7%(87,317人中)が使用していると回答しました。
本調査の2020年版では、開発環境のランキングはありませんでしたが、その他の調査内容も非常に興味深いものばかりだったので、併せてご確認いただければと思います。
開発者の経歴や志向、給料など幅広く調査されているので、眺めているだけでも、自身がどういう位置づけなのかを知る参考になるかなと。
Django開発環境のセットアップ
それでは、簡単にDjango開発環境をセットアップするまでの流れをご紹介します。
Djangoアプリケーションは、以前紹介した以下の記事をもとに作成していただくと、そのままお使いいただけるかなと思います。
AWS Elastic Beanstalkを使ってDjangoアプリをデプロイしてみた(後編) - みっきー申す
ちなみに、筆者はWindows10で実行しています。
VSCodeのインストール
以下のサイトからDownload for Windowsをクリックして、インストーラVSCodeUserSetup-x64-x.xx.x.exeをダウンロードします。
先ほどの、インストーラを実行して、案内通りに進めていけば、躓くことなくインストールができるかと思います。
まず、使用許諾書への同意です。 問題なければ、「同意する」を押して、「次へ」をクリックしてください。
続いて、インストール先の指定です。
こちらもこだわりがなければ、デフォルトの設定のまま、「次へ」をクリックしてください。
確認のポップアップが出ますが、こちらも「はい」をクリックしてください。
続いてスタートメニューフォルダの指定ですが、こちらもこだわりがなければ、デフォルトのまま「次へ」をクリックしてください。
追加タスクの選択では、デフォルトのままでもいいのですが、標準のエディタとしたい場合は、「エクスプローラーのファイルコンテキストメニューに[Codeで開く]アクションを追加する」にチェックを入れて、インストールするのもよいかもしれません。
確認次第、「次へ」をクリックしてください。
最後に確認画面が出るので、「インストール」をクリックしてください。
1分もたたないうちに完了すると思います。
開発環境の整備
それでは、VSCodeを使って、ローカル環境にセットアップしたDjangoを実行するまでをご説明します。
VSCode を起動し File から Open Folder... をクリック、プロジェクトのディレクトリ(前回のAWS EBで作成された環境をお使いの方ならばtrial_django）を開きます。
次に、Python の Extension を install します。
下図の通り、左タブの上から5番目、「Extensions」をクリックし、検索タブでpythonと入力。
PythonのExtensionをクリックして、インストールしてください。
次に、View の Command Palette... を選択。
Python : select interpreter をクリック
仮想環境(前回のAWS EBで作成された環境をお使いの方ならばeb-virt）のinterpreterを指定してください。
もし、仮想環境の選択肢に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 へ飛ぶといつものロケット発射が確認できるかと思います。
以下、トラブルシュートの例として、2点ご紹介しておきます。
実行時にエラーメッセージが出てしまった場合
- PowerShellでの実行制限がかかっている可能性があります。
- デフォルトではPowerShellの実行が制限されています。
以下を実行してみてください。
PowerShell Set-ExecutionPolicy RemoteSigned
RemoteSignedというのは、ローカル上のスクリプトと非ローカル上の署名のあるスクリプトのみ実行可能な権限のことです。
詳しくは、以下の記事などが参考になります。
DisallowedHost at /~ と表示された場合
- EBのハンズオンを実行していた人は、AllowedHostの設定があるかと思いますので、削除をお願いします。
まとめ
今回は、エディタの紹介という、ちょっと違った視点でのご紹介でした。
VSCode自体、2015年の11月にリリースされたもので、比較的新しいソフトウェアですが、使い勝手はとても良いように感じています。
無料でこの機能は文句なしですし、基本これひとつで、大抵のPC作業は済んでいます。
情報感度の高い方は、もうすでにお使いかとは思いますが、開発者の方に限らず、Webデザイナーやブロガーの方にも是非この便利さを味わってもらいたいなと思いました。
日本も標的！北朝鮮の攻撃グループ(LazarusおよびBeagleBoyz)による最近の活動
フィンランドに本社を構えるセキュリティベンダーF-Secureの調査レポート、および米国のCISAとFBIと財務省が出した共同注意喚起にて、北朝鮮のサイバー犯罪グループLazarusおよびBeagleBoyzによる攻撃活動が立て続けに明らかになりました。
https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf
後述しますが、このBeagleBoyzというハッキンググループも、活動の共通点などからLazarusの派生組織だと考えられています。
Lazarusの記事は、先月もKasperskyの情報をもとにリリースしていますので、併せてご確認いただけると幸いです。
目次
暗号資産交換業者を狙った攻撃
F-secureの調査によると、攻撃の起点は、LinkedInの個人アカウント経由で送られるフィッシングドキュメントだとのことです。
当該ドキュメントは、「受信者のスキルに合った、暗号資産交換事業者への求人」を装って送られており、少なくとも以下の国々が被害にあったとみられています。
米国、中国、英国、カナダ、ドイツ、ロシア、韓国、アルゼンチン、シンガポール、日本など
引用元：https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf
今回の攻撃に用いられた手法は、昨年7月に、JPCERT/CCが公開した分析記事でも紹介されており、分析した検体の類似検体の多くのデコイ文書に、仮想通貨に関する内容が記載されており、「仮想通貨に関連する組織へ送信された」と言及していました。
F-Secureは、GDPRで保護されたと称する文書ファイルを確認しており、保護を解くためにマクロを有効にするよう促し、不正なリンクへとつながる短縮リンクへの接続、そして、C2サーバへのリダイレクトを試みていると述べています。
当該文書ファイルのサンプルは以下です。
引用元：https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report.pdf
また、攻撃の流れについて、以下の図にて示しています。
引用元：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
- VIVACIOUSGIFT
- FASTCASH for Windows
今回の活動は、RATを介して、銀行を強盗することに特化したハッキングチームによって行われており、米国政府はこのチームをBeagleBoyzと呼んでいます。
なお、BeagleBoyzは攻撃の手法や他の北朝鮮系ハッキンググループとの関連から、Lazarusの派生組織だと考えられています。
米国政府がFASTCash 2.0と名付けるこの活動については、2018年にアフリカやチリに対して行われたFASTCash事件の再来だと考えられます。
そのため、以前のFASTCashと合わせて、これまでに標的となった国々として以下の図の通り示しています。
図からもわかる通り、日本もその一部に含まれています。
また、攻撃の流れとして、以下のような図を公開しています。
まず、スピアフィッシングなどを起点に標的の金融機関への侵入を試み、金融機関の企業ネットワークに侵入。
その後、様々な手法を悪用し、組織内への横展開や権限奪取、永続的な潜入や検知回避を行います。
そして、注目すべきなのが、CISAの注意喚起中に、「従来の金融機関への強盗に加え、暗号通貨取引所を標的とした攻撃」と述べている点です。
おそらくですが、先述のF-Secureの記事とも関連があるのではないかと推測できます。
まとめ
今回は、LazarusおよびBeagleBoyzによる攻撃活動について、まとめてみました。
北朝鮮のサイバー攻撃に関して、最近、気になるトピックが多いですね。
朝鮮系ということで、北朝鮮だと断言はできないものの、DarkHotelに関しても気になる動きがみられますし。
サイバー攻撃については、よく攻撃者優位なんてことが言われますが、まさにそのあたりを表しているような活動な気がしますね。
特に地理的に近い国なわけですし、引き続き、目が離せないなーというのが個人の感想です。
