Winntiグループによる香港の大学を狙った標的型攻撃について
2020年1月31日、セキュリティベンダのESET社のブログにて、Winntiグループによる香港の大学を狙った標的型攻撃に関するブログ記事が公開されました。
今回の攻撃キャンペーンにおける標的は香港の大学でしたが、当該グループは過去に日本の組織を狙った攻撃も行っています。
そのため、過去分も掘り下げつつ、Winntiグループについて、まとめていきます。
目次
香港の大学を対象にした攻撃
2019年の11月、ESETのリサーチャーにより、Winntiグループの活動が観測されました。
今回対象となったのは、香港の2つの大学です。
今回の攻撃では、以前よりWinntiグループが使用している、ShadowPadというバックドアが用いられましたが、いくつか改変が加えられていました。
そして、攻撃グループの名前にもなっているWinntiという名のマルウェアも、10月の末に同大学への感染が確認されたとのことでした。
Winntiグループの過去の攻撃
Winntiグループの活動は2009年ごろから行われているとされております。
ここでは、いくつかの過去の攻撃をご紹介します。
日本を含むゲーム業界への攻撃
2013年にKasperskyが出したレポートによると、2011年の秋ごろから、オンラインゲームの公式サーバからマルウェアが配布されていることを確認しました。
その後、オンラインゲームの開発企業が標的となっ他攻撃が行われていること、そして、その背後にはWinntiグループの存在があったことに気づきました。
この時に使われたマルウェアはWinntiであり、名付け親はSymantecだとのことです。
そして、当該マルウェアに署名された証明書には、実在するゲーム開発企業の名前が含まれていました。
以下の図は、当時、攻撃の被害にあったゲーム会社の所属する国をマッピングしたものです。
CCleanerにバックドアを埋め込んで悪用した攻撃
2017年9月、世界中で広く使われているクリーナーソフトCCleanerにバックドアが組み込まれた状態で配布する攻撃も過去には観測されました。
バックドアの通信先であるC2サーバから送られてきた、組織のリストには、SONYやEPSONなどの日本企業や、IntelやCiscoなどのグローバル企業が含まれており、これらの組織を狙ったものだと推測されました。
そして、この記事の執筆元であるCisco Talosによると、Group72が使用するマルウェアサンプルと非常に似ており、その関連が疑われると、言及していました。
そのGroup72は、Winntiグループの別名なわけです。
MITREのグルーピングでは、Winntiグループは、Winntiを使うという点からも、Group72と非常に関連が深く、関連組織だと推測されています。
Axiom, Group 72, Group G0001 | MITRE ATT&CK®
ASUS Live Updateを利用した攻撃
2019年の3月には、ASUSのアップデートサーバを侵害した攻撃も確認されました。
本攻撃はOperation ShadowHammerと名付けられ、Kasperskyよりその調査結果が公表されました。
この攻撃では、ASUS社のサーバが改ざんされたことで、ASUS製品がアップデートをする際に、悪意のあるバージョンへとアップロードをかけてしまうというものです。
結果的に、バックドア化したASUSにアップデートされ、攻撃者の要したC2サーバと通信を始めるというものでした。
アップデートされた端末はそのMACアドレスにより、標的となるかどうかが判断されるよう、作成されていました。
被害端末には日本も含まれていました。
Our blogpost on Operation #ShadowHammer, with information about targets, geography of victims and IOCs: https://t.co/cOlT4Uiuvt pic.twitter.com/8oNt7BQh8x
— Costin Raiu (@craiu) 2019年3月25日
本件については、piyologにてまとまっていますので、ご参考まで。
今回の攻撃におけるマルウェアの通信
今回の攻撃では、マルウェアの通信先のC2サーバのURLから対象とする組織が推測できました。
b[org_name].dnslookup[.]services:443 w[org_name].livehost[.]live:443 w[org_name].dnslookup[.]services:443
私自身、公開情報から確認しましたが、少なくとも4つの大学名がサブドメインから確認できています。
ESETの調査では、ドメインから推測する限りさらに3つの大学、つまり5つの大学が対象になっていたと推測されています。
この先頭の“w”という文字はマルウェアWinntiを、“b”という文字はShadowPadを指すそうです。
そして、この攻撃の背景として、先日起きた香港の大学におけるデモとの関連も疑われると、ESETのリサーチャーは述べています。
マルウェアShadowPadの特徴
今回用いられた、ShadowPadの機能は、2019年の10月に観測された検体に比べて、シンプルになっているとのことでした。
直近で確認された、VMProtectを使わなくなっていたり、ペイロードの暗号化が行われていなかったり、暗号化の面を中心に機能をそいでいるように見えるとのことです。
記事の中では図を交えて、感染の流れが記載されているのですが、大まかにまとめるとこんな感じです。
- ShadowPadはhpqhvsei.dllという名のDLLであり、hpqhvind.exeによって読み込まれる。hpqhvind.exeは本来HP Digital Imagingにとともにインストールされる実行ファイル。
- hpqhvsei.dllによって、親プロセス(hpqhvind.exe)のコードの一部を書き換える。
- 別のプロセスよりhpqhvsei.dllを改めて読み込む
- ペイロードの復号および実行
- 書き換えられたhpqhvind.exeをCLR.exeとしてディスクに書き込み、永続化を試みる
- wmplayer.exeプロセス(Microsoft Windows Media Player)の実行ファイルにShadowPad自身を組み込み、ポート番号13567を用いてC2サーバと通信を行う
まとめ
Winntiの感染活動はすでに10年続いています。(2009年からだったはず)
日本国内でも相次いで、大手企業が標的型攻撃の被害に遭っていることを公表し始めましたが、やられていることを前提として、立ち返ることが重要なのかもしれません。
専門家による侵害診断サービスなどを受けて、自身の組織も侵害されていないか、確認してみるのも有効かもしれません。
新型コロナウィルスに関する内容を装ったEmotetの感染活動
新型コロナウィルスに関連した肺炎患者について、増加の一途をたどっています。
1月29日時点で、中国の保健当局の発表によると、患者数は7711人、死者は170人だとのことです。
https://www3.nhk.or.jp/news/html/20200130/k10012264951000.htmlwww3.nhk.or.jp
日本にチャーター機で帰国した日本人のうち3名が、新たに新型コロナウィルスへの感染を確認されているとのことです。
https://www3.nhk.or.jp/news/html/20200130/k10012264981000.htmlwww3.nhk.or.jp
そんな中、きわめて不謹慎なスパムメールが観測されています。
スパムメールはマルウェアEmotetを配布するもので、昨年の秋ごろから活動が再開されています。
Emotetに関しては、以前に記事をまとめているので、ご確認ください。
過去の配布手法
Emotetの配布には、時事ネタを含めて、感染を誘発する手法がたびたび用いられています。
ある時はハロウィンパーティーを装い
ある時はクリスマスパーティを装い
ある時は賞与支払いを装い
またある時は、スウェーデンの環境活動家グレタ・トゥーンベリさんへの寄付を呼びかけ
手を変え、品を変え、感染を試みています。
今回確認されたメール文面
Emotetの調査を行っている国内のリサーチャーのTwitterでは以下のようにメールの本文が紹介されています。
新型コロナウイルス関連をテーマにした #emotet のばらまきメール。
— bom (@bomccss) 2020年1月29日
昨日と本日で確認どちらも日本語に違和感はありません。
■件名
添
■添付ファイル
別添.doc
■件名
別添 01.29
■添付ファイル
取扱説明書.doc pic.twitter.com/r6Ra3eZf2l
文章自体、日本人が見ても違和感がないですし、しかるべき人が受信した場合、開いてしまってもおかしくなさそうです。
ただ、リサーチャーの方がおっしゃる通り、タイトルと添付ファイル名は、違和感がありますね。
I think the text was stolen. However, Japanese in the subject and file names is strange. Also, it has been received by multiple organizations and is considered to be used as a theme. Email of the same type is on the rise.
— bom (@bomccss) 2020年1月29日
添付された文書ファイルのマクロを有効にすることで、PowerShellが実行され、バックグラウンドでEmotetがダウンロードされます。
一連の挙動については、マルウェアサンドボックスVMrayなどにも記載があるので、ご確認ください。
4c9e35f3...cccb | VMRay Analyzer Report
まとめ
今回は、速報ベースで、Emotetの新たな活動について、記載しました。
その手法も、より高度になってきているため、より一層の注意が必要になってきますね。
そもそも、メールという手段に限界がある気もしますが。。。
東京オリンピックの転売サイトを使ったサイバー犯罪集団MageCartの情報窃取活動
ついに東京五輪の開幕まで、ちょうどあと半年になりましたね。
巷では、サイバー攻撃が話題になっていますが、標的型攻撃となってくるとなかなか防ぐのは難しいもので。。。
個人的には、むしろ起こってしまった後の避難訓練のようなものが重要になってくると、思っています。
2人のセキュリティリサーチャーによる調査結果
さて、そんな東京五輪に関する話題ですが、サイバー犯罪集団MageCartが五輪チケットの転売サイトを通じて情報窃取活動を行っているとの調査ブログが公開されました。
ところでこの記事は2020年1月25日付ですが。。。 未来。。。
少し信ぴょう性に不安がありましたが、 記事中に記載のURLを、URL確認サイトurlscanで確認しても、 その存在が確認できました。
そのため、転売サイトの存在と不正なスクリプトが埋め込まれていることは間違いなく活動自体も間違いなさそうです。
olympictickets2020.com - urlscan.io
また、ちょうど数日前に、別の個人ブログでも、東京五輪の転売サイトにて情報窃取のためのスクリプトが埋め込まれていることが確認されたとの記載があります。
これらの二人のブログ執筆者は共同で分析したと記事では述べられています。
ちなみに、MageCartについては。以前から本ブログでもちょこちょこ取り上げているのでそちらでもご確認ください。
諜報活動の概要
MageCartは転売サイトに不正なJavaScriptを埋め込むことで、アクセスしたユーザのクレジットカード情報を盗みます。
あるサイトでは少なくとも50日間、またあるサイトでは2週間、先ほど紹介したブログの執筆者が見つけるまで不正なスクリプトが埋め込まれたままになっていたとのことです。
本活動に関して、カード情報を摂取するコードの特徴およびMagentoで作られたECサイトを対象としている点から、MageCartの介入が推測されています。
JavaScriptの動作について
MageCartが配置したとされるJavaScriptは感染したサイトのすべてのページで読み込まれます。
そのため、ユーザはアクセスの度にこのスクリプトを実行することになります。
このスクリプトが実行されると以下のキーワードの検索が行われ、該当すると、クレジットカード情報を攻撃者のC2サイトに送信します。
- onepage
- checkout
- store
- cart
- pay
- panier
- kasse
- order
- billing
- purchase
- basket
以下はJavaScriptの記載内容の一部になります。
まとめ
当たり前ですが、そもそも得体のしれない転売サイトからチケットを購入すること自体がリスクです。
まあ、私自身、好きなアーティストのライブのチケットがどうしても欲しくて探し続けたみたいな経験もあり、気持ちがわからなくもないですが。。
一生に一度あるかないかの機会だ!と思う気持ちもわかりますが、抽選に外れてしまったのならこの際あきらめて、家で仲間たちとゆったり観戦するのもありではないでしょうか。
ランサムウェアFTCODEについて~ChromeやFirefoxに保存された認証情報の取得を試みる~
米国のセキュリティベンダZscalerより、ランサムウェアFTCODEに関する観測記事が公開されました。
本ランサムウェアはイタリア語圏のユーザを対象としているものの、その機能が、情報を暗号化するだけでなく、情報窃取も行うものであり、興味深かったので、読み解いてみました。
FTCODEについて
- 作成言語
- 攻撃の対象だと考えられるユーザ層
- イタリア語圏
これまで、FTCODEは文書ファイルに含まれるマクロを実行することで、ダウンロードされていました。 そして、今回の、最近の活動では、VBScriptsを利用し、Webサイト経由でダウンロードされる様子も確認されているとのことです。
下の図は、Zscalerクラウドにて観測されたFTCODEのダウンローダについて、 文書ファイル経由でFTCODEをダウンロードするパターンを"赤"、 VBScripts経由でFTCODEをダウンロードするパターンを"黄"で示したものです。
ダウンロードから暗号化までの流れ
ユーザが攻撃者の用意したWebサイトにアクセスし、VBScriptsを実行すると、以下のような画像ファイルが、デコイ(おとり)ファイルとしてダウンロードおよび展開されます。
ただ、その裏では、FTCODEがダウンロードされ、実行されるといった流れになります。
以下は、FTCODEの実行後のC2サーバへのリクエストです。
なお、FTCODEは永続化を行うための手法も用いており、スタートアップフォルダ(Windowsの起動時に実行されるプログラムを配置するフォルダ)にwindowsIndexingService.lnkとして、ショートカットファイルを配置します。
そのため、端末が起動するたびにVBScriptsが実行されます。
また、タスクスケジューラにもWindowsApplicationServiceとして、VBScriptsの実行が登録されることが確認されています。
このあたりの流れについては、マルウェア解析サービスのAnyRunに登録された情報なども参考にしてみてください。
https://app.any.run/tasks/77ac62ba-0d03-40eb-8a51-64bb66ee4472/app.any.run
そして、FTCODEは、C2サーバへの通信を通して、以下のような情報を送信しています。
- ver = マルウェアのバージョン(1117.1 version)
- vid = 攻撃の識別番号(vb5)
- guid = データの識別番号
- ext = 新規に作成されたGUIDの先頭6文字
- r1 = BESA64でエンコードされた文字列
また、マルウェアが暗号化プロセスを開始する直前には、以下のような通信が発生することも確認されています。
最後に、暗号化されたのち、以下のようなランサムノートが生成されます。
ブラウザやメールクライアントからの認証情報窃取機能
本機能は、今回注目したポイントです。
近頃、被害端末のファイルを暗号化する前に取得し、身代金を払わないと、情報を公開するようなランサムウェアMazeのようなものも流行っていますが、FTCODEは少し違うようです。
ちなみに、Mazeランサムウェアに関する記事が意図的に消え始めているんですが。。。
本題に戻すと、FTCODEでは、以下のソフトウエアに保存された認証情報を盗み出す機能を持ちます。
どれも主要どころですね。
基本的には、端末の感染後に、上記のアプリにおいて認証情報が保存される端末内のフォルダにアクセスし、認証情報の取得を試みます。
たとえばこちらは、Chromeの例ですが、
\%UserProfile%\AppData\Local\Google\Chrome\User Data*\Login Data
で示されるパスの探索を行っているのがわかりますね。
まとめ
Zscalerの調査では、FTCODEの対象はイタリア語圏とされていますが、本ランサムウェアのような機能を備えた検体は今後も増えてくるかもしれません。
感染を予防する取り組みも重要ですが、ブラウザに不必要に認証情報を保存しないことや、会社の端末で、個人の認証情報を入れたり、その逆を行わせないような、セキュリティ教育も重要になってくると思います。
社会人5年目の20代が大手SIerからWeb系企業へ転職を決めたときの話
大手電機メーカーのSIerに入社して、4年9か月。
現在の企業を退職し、新しく別の会社に入社することを決意しました。
転職先はWeb系の企業。
システムを作って納める立場から、システムを運用する立場への変化です。
転職を決断した理由と、今後どんな人生を歩んでいきたいか。
約半年間、考えた内容は、他の誰かにも役に立つものと思い、今回文章に起こすことにしました。
目次
これまでの経歴
私が入社した大手電機メーカーのSIerにおけるざっくりとした経歴は以下です。
年次 | やったこと |
---|---|
1年目4月~6月 | 社会人基礎やIT基礎の研修 |
1年目7月~9月 | 製品理解のための研修受講など |
1年目10月~3月 | パブリッククラウドを使ったサービス開発のための検証 |
2年目4月~3月 | システム構築のプロジェクト管理 |
3年目4月~4年目3月 | 出向先のセキュリティ専門機関にてCSIRT業務 |
5年目4月~5年目12月 | システム構築の提案及び設計 制御セキュリティ分野における製品検証およびソリューション検討 |
個人的に転機となったのは、2年間の出向から帰任した、5年目の春でした。
転職を考えたきっかけ
社会人4年目が終わり、出向から戻る直前になって 自分は今後何をしたいのか。どうなっていきたいかを深く考えるようになりました。
社会人になってからの4年間で、
- 組織の看板を背負って社外の人と接する仕事ができるやりがい
- 自身がこれまでに経験したことのない分野に挑戦し、成長を実感できる楽しさ
- 社外の同世代と出会うことで得られる競争意識と成長意欲
を感じたことや
- 20代から活躍する経営者が世の中にはたくさんいること
- ITを働く人間としてGAFAやBATHを意識した時の自身の市場価値に疑問を感じ始めたこと
- 次々と新しい技術が誕生し、市場が目まぐるしく変化していること
を日々のニュースなどを通して意識するようになったことが、私自身がキャリアを改めて考え直す契機になりました。
今の企業でのキャリアを模索
私自身、転職経験がなかった上、職場の人間関係に大きな不満があったわけではなかったため、社内での異動を含めた方向性でまずはキャリアを考えてみました。
所属している企業は事業領域の広い大企業だったし、何かしらの道があれば、それを利用しない手はないと、感じたからです。
そして、自身の立ち位置を見直す意味でも、まずは所属部署におけるミッションを見返してみました。
コストセンターとプロフィットセンター
企業において、社内の役割を大別する言葉として、プロフィットセンターとコストセンターというものが存在します。
- プロフィットセンター
- 利益を生む部門
- コストセンター
- バックオフィスや研究開発を行うコスト部門
私が所属していたのはプロフィット部門。
プロフィット部門では、利益を出すことが最優先となるため、アサインされたプロジェクトに期間中は従事します。
ただ、私自身プロフィット部門に所属しながら、 - 社外と情報交換をすること - 新しい技術やビジネスモデルを学ぶこと
などが好きで、与えられた仕事以外にもやりたいことはたくさんあったため、不完全燃焼感を抱えていました。
基本的に、どの会社でも、「やることやっていれば、他のことをやってもいいよ」と言ってはくれますが、マネジメント側からすると、与えた仕事以外をされるのはあまり気持ちの良いものではないようで。。。
その理由を、私なりに考えてみたところ、SI業界特有の人月という考え方が邪魔してるようだ。
という仮説にたどり着きました。
人月という考え方
SIerのプロフィット部門において、個人の仕事は人月という単位で与えられます。
人月とは、「1人が1か月で行うことのできる作業量(工数)を表す単位」です。
つまり、定時時間内は、人月として与えられた仕事以外は、行わない前提です。
研修や間接業務は、それ用の人月として与えられるため、
- 「○○さんを1人月で△△プロジェクトにアサインする!」
となった場合、それ以外の仕事をすることはない、というものです。
これが成果物ベースの仕事の場合、「3か月で○○を完成させる」となれば、
- 「1か月で仕事を終え、余った時間を他に使う」
ということもでき、自由が利きます。
私は、夏休みの宿題を「はじめの一週間で終えてあとは遊びまくる」タイプだったので、今となっては「夏休み中宿題に従事し続ける」ような人月の働き方は少し合っていなかったようにも感じています。
(人月も本来、一月で終えられる仕事量として受けるため空いた時間を使うことは理論上可能ですが。。。)
私が感じたコストセンター
では、コストセンターに異動すれば私のやりたい仕事はできるのではないか。
私自身もそう考えました。
ただ、組織において、「コストセンターはプロフィットセンターが稼いだお金で"働かせてもらっている"」というような、上下関係を持ったような雰囲気もあり、直接お金を稼ぐ部署ではないコストセンターへの異動には前向きになれませんでした。
各々が自身の仕事に向き合えていればそれでいいと思いますが。。。
そもそも部署異動をすることについて
日本の昔ながらの企業ではよくあることかもしれませんが、「部署異動は後ろ向きな理由で行われるもの」という前提はどうも存在するように感じます。
実際、私自身が体験した部署異動の障壁として、
- 社内公募・FAのチャンスは年1回の限られた機会
- 出向者および出向から帰任後1年以内の者は社内公募やFA権は使えない
こういったものが存在しました。
私としては、公募ではなく、会社の下命での出向に対し、1年も拘束する制度に少なからず違和感を覚えていました。
結果として、出向の経験は大きな財産になりましたが、そうでないケースがあることを想像すると。。。
そんな背景もあり、1年間「ただただ待つ」ということはせず、転職という道をしっかり考えることにしました。
自分は今後何になりたいか
転職とひとえに言っても、選択肢はとても広いです。
そのため、「なりたい自分像」を中心に要素を洗い出し、その要素にマッチングするような環境を考えてみました。
なりたい人物像と必要な要素
急に子供みたいなイメージの伝え方をしますが、私は、
マンガに出てくる彼らのような、「多くの人との絆をもとにリーダーシップを発揮するような人物像」に憧れます(笑)
たかがマンガ、されどマンガ。
この人物像をもとに必要だと考える要素は、
- 明確な夢を持ち突き進めること
- 関わる多くの人間をひきつけ仲間になること
- 仲間に信頼されうる能力を持つこと
- 常に成長し続けること
このあたりだと思っています。
この要素を身に着けるチャンスがありそうな環境を求め、職場を探すわけですが、もう少し具体になるよう、人生計画に落とし込んでみることにしました。
私の人生計画
ここで参考にしたのが、 ソフトバンクの孫さんが19歳のときに立てたといわれている「人生50カ年計画」です。
- 孫さんの「人生50カ年計画」
- 20代で名乗りを上げ
- 30代で軍資金を1000億円貯め
- 40代でひと勝負し
- 50代で事業を完成させ
- 60代で事業を後継者に引き継ぐ
僕自身、孫さんと同じ人生設計をするイメージはないですが、 40代以降の計画は、非常に共感できました。
なので、私自身は、
- 20代で技術スキルを向上し社外に名前を売り
- 30代でビジネスで信頼できる仲間を集め
- 40代でひと勝負し
- 50代で事業を完成させ
- 60代で事業を後継者に引き継ぐ
このような形で人生を考えてみました。
私が求める環境
上記の人生設計をもとに、自身が求める環境を探してみました。
条件は、
- 技術スキルの向上および社外へのアピールができそうな環境
- 同世代の仲間との出会いがありそうな環境
- 起業文化がある環境
これらを軸として、さらに、「自身がこれまでに培ってきたITの知識が活かせる」という基準で企業選びをした結果、Web系企業への就職が一番イメージに近いと思い、 選考を受け、転職を決定しました。
Web系企業ってなんだろう
って人も多いと思うので、転職口コミサイトVorkersからリストを載せておきますね。
https://www.vorkers.com/company_list?field=0025&pref=&src_str=&sort=2
ここでいうインターネット業界が、それにあたるかと思います。
転職活動を終えて
この記事を見て、「割とスムーズに転職の軸決めから内定まですすんだのかな~」と思う方も多いと思います。
ただ、実際かかった時間を考えると。
- 社内での異動を考えたのが3か月(4月~6月)
- 転職の軸決めで2か月(7月~8月)
- 選考期間(9月~10月)
と半年以上かけての活動でした。
今回の記事で書いた考え方はほんの一部で、他にも、 - ビジネス雑誌や書籍、ネットの記事を読む - 信頼できる社会人の先輩や家族の話を聞く - 自分の考えをいろいろな人に発信する
この中でやっと、前に進めたような気がしています。
迷ったときの道しるべ
つらつらと書きましたが、一番伝えたいことをここに書きます。
迷ったときは、自分の中に答えを求めること!
人に相談すればするほど、だんだん頭が混乱してきます。
少々ドライですが、人のアドバイスは、 その人の価値観の下、受け手が最も都合よく動いてくれるようなアドバイスをします。
これはおそらく無意識なもので、自分の人生を否定するような発言は誰もしないので、結果としてそうなっていることが多い、という意味です。
僕自身もすごく悩みましたが、
マンガを通して、自分が何に心打たれるのかを再認識したり、
就活の時に「芸能事務所の総合職」や「テーマパークの総合職」を受けたことを思い出し、サービスを受ける立場の人の心を充実させる喜びを求めていたことを思い出したりする中で、
自身の中から答えにつなげられたと思っています。
最後に
結果として、自身は転職をすることになりましたが、これが正解かどうかはまだわかりません。
今後、人生の目標に向かって突き進む課程の中で、今この瞬間が意味のあるものになっていることが大切だと思っています。
今の職場でさらに成長し、夢に向かってこれからも進めること、
そして、夢をかなえた先に、また夢を描けること。
それが続いていくことができて、はじめて、この人生の選択が正しいと思えるのかなと思っています。
"Connecting The Dots"
スティーブ・ジョブズ氏がスタンフォード大学の卒業式で述べたこの言葉の意味は、その瞬間瞬間を真剣に生きた者のみ知ることができるものだと思っています。
この記事が、人生の先輩方や今を生きる同世代、そして、未来を担う後輩たちにとって実りのある内容になっていると幸いです。
ご拝読ありがとうございました。
Tiktokが抱える色々な問題について(XSS,CSRF脆弱性など)
みなさん一度は耳にしたことがあると思います。 若者に大流行! と言われているくらいなので、使っていない私はもう若者ではないのかも。。。
と今更ながら思っている悲しみ。。。
少し調べてみると、こんな記事が
記事によると、TiktokはFacebook、Twitter、Instagramに並ぶ世界的SNSになろうとしているようです。
確かに、MMD研究所が示す資料を見てもTiktokも徐々に利用率を伸ばし始めていることが示されていますね。
先ほどの、ダイアモンドの記事では、Facebook、Twitter、Instagramに追随しうる理由として、以下を挙げています。
- 「テキスト・画像から動画へ」という長期トレンドに沿っている。
- 「検索からレコメンドへ」という長期トレンドに沿っている。
- プラットフォームとして確固とした強みがある。
- 母体となる運営会社の実力が図抜けている。
- SNSとしての設計、運営戦略が優れている。
詳しくは、記事の参照を見ていただきたいとことですが、果たして、これがどこまで行くか、注目ですね。
という記事にしたいのではなく、本題はこちら。
CheckPoint社の調査によりTiktokに容易に悪用可能な脆弱性が複数含まれることが明らかになりました。
端的に言うと、脆弱性の悪用により様々な攻撃が可能になります。
- Tiktokのアカウントを乗っ取り、アカウントのコンテンツを操作できる
- 動画の削除ができる
- 第三者により動画がアップロードできる
- 非公開動画を公開状態に変更できる
- 攻撃者がアカウントに紐づく個人情報を取得できる
これらについて、簡単なでも動画があるのでご紹介します。
https://research.checkpoint.com/wp-content/uploads/2020/01/tiktok_video.mp4?_=1
以降にて、CheckPoint社の調査内容について、詳しく紐解いていきます。
目次
- Tiktokに対する規制の動き
- 具体的な攻撃手法
- パート1 SMS Link Spoofing
- パート2 クロスサイトスクリプティング
- パート3 クロスサイトリクエストフォージェリ
- 動画の削除
- 動画の作成
- フォロワーへの追加
- 非公開動画の公開
- ユーザ情報の公開
- まとめ
Tiktokに対する規制の動き
年末ごろから、Tiktok利用に関する米国の規制が話題になっています。
発端は、カリフォルニア州の大学生が起こした集団訴訟にあると考えられます。
訴状によると、2019年4月にTiktokがユーザー情報を中国が管理する2つのサーバー(bugly.qq[.]com と umeng[.]com)に転送しており、転送された情報には、ユーザーが利用している端末や閲覧したウェブサイトの情報が含まれていたとのことです。
Tiktok側の主張として、米国のユーザー情報はすべて米国内に保存しており、データのバックアップはシンガポールにあるとのことですが、中国のサーバへの転送問題には言及していないとのことでした。
論点のすり替え感が否めない。。。笑
12月21日にロイターが公開した記事によると、米海軍が17日の軍関係者向けFacebookページにて、 「TikTokを削除しないデバイス利用者は、海軍および海兵隊のイントラネット(NMCI)」と伝えたとのことでした。
つまり、「政府から支給されたiPhoneやiPadなどにTiktok入れちゃだめだよ」みたいな話ではあるんですが、 個人的には「そりゃそうだろ!」なんて思うところです。
日本企業だとSNS自体社用スマホに入れるのNGな気がしますが、 米海軍では、一般的なSNSを含む一般的な商用アプリの使用は可能だとされているようですね。
また、NewYorkTimesによると、すでに2019年10月には、フロリダの上院議員が対米外国投資委員会に対し書簡を送り、TikTokが国家安全保障レビューにかけていることを報道しています。
そして、後日、米国陸軍においても、Tiktokが使用禁止になったことをMilitary.comが認知したとのことでした。
HUAWEIの時もそうでしたが、この手の問題は引き続きいろいろな形で噴出しそうですね。
特に、中華系アプリが、アメリカに進出すればするほど。
長くなりましたが、以降でTiktokを使った攻撃手法について、ご紹介します。
具体的な攻撃手法
パート1 SMS Link Spoofing
まずは、Tiktokが招待用に送るSMSに関する脆弱性です。
Tiktokが新しいユーザを招待するときに、SMSを使って、招待リンクを送ることができます。
ただ、この招待メッセージを生成する過程で、Webページに入力した電話番号に送る前のリクエストをBurpSuiteなどのプロキシツールで書き換えることができてしまうのです。
本来のリクエストに含まれる、download_urlの部分を
任意の値 https[:]//attacker[.]comに変えることで、
生成されるはずだったリンクが
こうなってしまうわけです。
まあ簡単(笑)
これに対して、他にも工夫ができてしまうので、いくつかご紹介です。
カスタムリンクの悪用
Tiktokのアプリケーションでは、https[:]//m.tiktok[.]comスキーマと「musically[:]//」カスタムスキーマをリッスンしており、これらのカスタムリンクではurlパラメータを含みます。
簡単に言うと、このurlパラメータを任意の宛先(ここでは、http[:]//10.10.10[.]113[:]8000)を指定することで、攻撃者の管理するサーバへ通信させます。
ドメイン正規表現を利用したオープンリダイレクト
Tiktokの正式ドメインから派生したリンク https[:]//login.tiktok[.]comに通信するときに、リダイレクトが行われます。
ただ、このリダイレクト時もredirect_urlというパラメータを含めることができます。
https[:]//login.tiktok[.]com/?redirect_url=https[:]//www.maricious-tiktok[.]com
例えばこんな感じにすると、攻撃者が用意した宛先にリダイレクトされてしまいます。
ここで問題なのが、redirect_urlは正規表現で判定しているのですが、
こんな感じで、攻撃者がこの正規表現に合致するドメインさえ持っていれば、簡単にアクセスできてしまうわけですね。
ちなみにお名前ドットコムだと初年度760円から利用できるので、おこずかい感覚で買えてしまいますね。
https://www.onamae.com/service/domain/com/
パート2 クロスサイトスクリプティング
パート2は、tiktokサイトの作りこみの甘さを指摘する形になってしまいますが、
https[:]//ads.tiktok[.]comがXSSの脆弱性を含むことが分かっています。
具体的には、https[:]//ads.tiktok[.]com/help/で利用可能なヘルプセンターに、検索の脆弱性があるとのことです。
例えばこんな感じで、入力すると https[:]//ads.tiktok[.]com/help/search?q=pwned
つまりここでいう、q=pwnedの部分をJavaScriptコードに書き換えると、
攻撃者が意図した動作、つまり、警告ウィンドウのポップに成功しています。
これを悪用することで、https[:]//ads.tiktok[.]comのサーバに可能な権限の範囲でいろいろなことができてしまいます。
パート3 クロスサイトリクエストフォージェリ
今回の脆弱性のうち、最もわかりやすい被害が出るのがこのパートです。
HTTPリクエストの加工のみで簡単に実行可能になります。
一つ一つ追ってご紹介します。
動画の削除
https[:]//api-t.tiktok[.]com/aweme/v1/aweme/delete/?aweme_id = video_id
と、GETリクエストを送るだけで実行可能です。
tiktokに投稿される動画には識別子として動画IDが付与されるため、この動画IDをパラメータとして含め、リクエストを送ります。
レスポンスコード200
うまくいったようです。
動画の作成
ここでは、攻撃者がまず、自身で動画を作成するリクエストを生成し、そのリクエストを一度プロキシで止めたのち、新たな動画IDを利用することで、任意の動画を別のユーザに対しPOSTで送りつけることができるとのことです。
フォロワーへの追加
基本的には、これまでと同じような流れですが、フォロワーの承認も簡単にできます。
https[:]//api-m.tiktok[.]com/aweme/v1/commit/follow/request/approve
上記のパスに対し、POSTリクエストを送るわけですが、from_user_idの値を変更することで、攻撃者の任意のアカウントが、対象となるアカウントのフォロワーになることができます。
非公開動画の公開
続いて、非公開動画の公開設定です。
こちらは以下のパスに対してリクエストを送ります。
https[:]//api-m.tiktok[.]com/aweme/v1/aweme/modify/visibility/?aweme_id=video_id&type=1&aid=1233&mcc_mnc=42503
ここでいうところの、typeパラメータが 1 だと公開、2 だと非公開になるようです。
つまりここの設定を変えるだけでした。
ユーザ情報の公開
最後は、若干毛色が違うのですが、APIを悪用したものです。
TiktokのAPI用サブドメインは、https[:]//api-t.tiktok[.]comもしくはhttps[:]//api-m.tiktok[.]comで指定され、Cross Origin Resource Sharing (CORS)やSame Origin Policy (SOP) の制限がかかっているため、特定の送信元以外からのリクエストには応答しないようになっています。
こんな感じで、失敗してしまいます。
ただし、TiktokにはCORSやSOPの制限を受けずAPIサーバからのリクエストを受けるJSONPコールバックのカスタム実装がなされていることがCheckPointの調査によって発見されました。
JSONPインジェクションについては、以下のブログで簡単に解説されていました。
これにより、APIリクエストの応答に含まれる機微な情報が取得できてしまいます。
まとめ
なんだか、これだけで、Web通信にかかるありがちな攻撃のチュートリアルみたいになってしまいましたね。
もちろん悪用は厳禁ですし、モラルを守るようにしましょう。
こういった記事を書くときに難しいのは実際にやってみないとわからないけど、一歩間違えると犯罪になってしまうリスクがある点ですよね。
どうしても試してみたい人は、アプリケーションの開発ベンダに入社するか、自分で作るか。
Firefoxの脆弱性(CVE-2019-17026)について
現地時間の1月8日、Firefoxの脆弱性に関する修正バージョンFirefox 72.0.1 and Firefox ESR 68.4.1が公開されました。
本バージョンの公開は、前日の1月7日に、Firefox72およびFirefox68.4が出た直後の出来事であり、 背景として、今回の修正された脆弱性を悪用した攻撃がすでに観測されていることが関係あると考えられます。
Security Vulnerabilities fixed in Firefox 72 — Mozilla
Security Vulnerabilities fixed in Firefox ESR 68.4 — Mozilla
脆弱性情報
- CVE-2019-17026
- IonMonkey type confusion with StoreElementHole and FallibleStoreElement
- 概要
- 報告者
- Qihoo 360 ATA
JITコンパイラとは
- ソフトウェアの実行時にコードのコンパイルを行い実行速度の向上を図るコンパイラ
- あらかじめ用意された実行環境に依存しない汎用的な中間コードを、プログラムの実行時点でプロセッサが実行可能な機械語にコンパイルする
- JavaやMicrosoft . NETなどで採用されている技術
- これにより、Webアプリケーションやゲームの実行速度が高速化される
- JavaScript から機械語への直接変換ではなく、中間表現を行う仕組みを用いるため、保守性の向上も見込まれる
古い記事にはなりますが、IonMonkeyに関する説明は、Mozillaのブログに書いてありますので、ご参考まで。
グラフを見る通り、ベンチマークの結果からも、JavaScriptの処理速度向上が示されていますね。
なお、本脆弱性については、米国のCISAからもアラートが出ており、 攻撃者が脆弱性を悪用することで、システムを乗っ取ることも可能だと言及されています。
今回簡単ではありますが、以前Coinbaseなどの組織への攻撃にFirefoxの脆弱性(CVE-2019-11707およびCVE-2019-11708)が悪用されたことを踏まえ、記事を書いてみました。
何かの参考になるとありがたいです。
おまけ
2020年が始まりましたね。 先週末、IT神社としても有名な神田明神にてお参りに行ってきて、おみくじも引いてきましたが、小吉でした。 何とも言えない感じですが、まだまだ伸びしろがあるということで、やる気出ますね。
今年はオリンピックイヤーということで、なかなか騒がしい年になると思いますが、引き続き頑張っていこうかと思います。