先日 Akamai SIRT からも報告のあった¹²³複数のゼロデイ脆弱性を悪用して感染を行う Mirai 亜種 InfectedSlurs の活動状況について、IIJ の観測結果を共有します。

アクターについて

今回のアクターによる攻撃活動を IIJ では昨年から継続して観測しています。今年 1月に発生した国内の河川監視カメラへの不正アクセス⁴も、同アクターによるボットの感染活動と見られます。10月末に悪用が確認されたゼロデイ脆弱性⁵もそうですが、主に日本国内でのみ利用されている機器も感染対象としているのが、このアクターの特徴の一つと言えます。

感染状況

11月から活動している検体は、感染時に機器のホスト名を “TBOT” または “PBOC” に変更するという挙動を行います。そのため比較的感染が見つけやすく、Shodan や Censys 等でこれらのホスト名を検索すると、少なくとも数千台が感染しているようです。

一方、IIJ のハニーポットでも、このような挙動を示すスキャン活動⁶を観測していますが、ユニークな送信元アドレスはもっと数が多く、少なくとも 1万台を越える感染規模と推定されます⁷。12月に観測したユニークなスキャン送信元アドレスの国別分布を図 1 に示します。中国、インドが大半を占めていますが、日本も国別で 5番目に多く観測されています。

図1 ユニークなスキャン送信元アドレスの国別分布 (2023年12月)

DDoS 攻撃状況

このボットネットは DDoS 攻撃活動も非常に活発に行っています。C2 観測データに基づく直近 3ヶ月の DDoS 攻撃回数を図 2 に示します⁸。また攻撃対象となった IP アドレスの国別分布を図 3 に示します。

図2 InfectedSlurs による DDoS 攻撃回数の日別推移

図3 DDoS 攻撃対象アドレスの国別分布

平均して 1日約 240回の DDoS 攻撃が毎日継続して多数の国のアドレスに行われています。このような状況から、このボットネットが何らかの DDoS 攻撃代行サービスのインフラとして利用されている可能性も考えられます。

まとめ

本アクターの攻撃活動は期間が非常に長く、国内で主に利用されている機器も感染対象としている点や、複数のゼロデイ脆弱性を悪用して感染を行うなどの特徴があります。また InfectedSlurs のボットネットは感染規模も比較的大きいうえに、DDoS 攻撃の活動も非常に活発です。DDoS 攻撃への対処だけでなく、感染対象機器の特定や脆弱性対応なども含めて、今後も継続して対処が必要と言えるでしょう。IIJ では引き続き国内の関連する事業者等と観測情報を共有し、対処にあたっていきます。

脚注

1. InfectedSlurs Botnet Spreads Mirai via Zero-Days | Akamai ︎
2. Actively Exploited Vulnerability in FXC Routers: Fixed, Patches Available | Akamai ︎
3. Actively Exploited Vulnerability in QNAP VioStor NVR: Fixed, Patches Available | Akamai ︎
4. 国土交通省が管理する簡易型河川監視カメラへの不正アクセスについてまとめてみた – piyolog ︎
5. JVNVU#92152057: FXC製無線LANルータ「AE1021PE」および「AE1021」におけるOSコマンドインジェクションの脆弱性 ︎
6. これらの検体のスキャンモジュールは Mirai 由来のものではないため、オリジナル Mirai のスキャンの特徴 (TCP のシーケンス番号が宛先 IP アドレスと一致する) を有していません。 ︎
7. 同一機器による IP アドレスの変更を考慮していないため、スキャンの送信元アドレス数は実際の感染規模よりも多くなる可能性があります。 ︎
8. 1回の攻撃指令において複数の IP アドレスを指定することがあるため、IP アドレス数は攻撃回数よりも多くなります。 ︎

約2年半ぶりの出張でアイルランドのダブリンにきています。今回、34th Annual FIRST Conference に現地参加することができました。

この記事ではカンファレンスの様子と、前半の日程で気になったセッションを簡単に紹介します。

Annual FIRST Conference について

FIRST は1990年に設立された国際的な CSIRT の団体で、CSIRT 組織、国の情報セキュリティ関係組織、大学や研究機関、企業の情報システム部門など、さまざまな分野に渡る700以上の組織が加盟しています。

FIRST は年間複数回の会合を実施していますが、そのうち最も大規模なものが年次会合、Annual FIRST Conference です。FIRST の主催する会合は加盟組織を対象にしたものが多いのですが、Annual FIRST Conference は FIRST に加盟していない人も参加可能で、コロナ禍前は1,000人以上が参加する大規模な会合でした。

コロナ禍により2020年および2021年の年次会合はオンライン開催に変更されましたが、今年はアイルランドのダブリンで、3年ぶりに対面での会合を中心とした開催になりました。

現地のコロナ対応

現地の様子ですが、会場の the Convention Centre Dublin ではアイルランド政府の勧告に基づいた感染対策が実施されています。開催者である FIRST からも、状況の変化に合わせて情報発信や対応が行われていました。

• COVID Safety Updates | FIRST.Org, Inc.

カンファレンス会場では、参加者はマスクをつけることが推奨されていて、会場スタッフはマスクをしています。

また、カンファレンス中にある参加者どうしの交流について、リストバンドを配って接触の許容度を明示するルール(オプション)が用意されていて、多くの人が自身の事情に合った色のリストバンドをつけていました。

現地に来てみて、実際のところはどうだったかというと、参加者のマスク着用率は1,2割ぐらいかな、という印象です。夕食などで街に出るとマスクを付けている人は稀で、だいたいコロナ禍前の風景に戻っているのではないかなと思いました。ニュース映像などで見てはいましたが、日本と比べるとかなりの差を感じます。

ただ、お店の入り口などには消毒液が置かれているところが多く、席があくと店員さんが消毒液を使って念入りに消毒をしていました。政府の勧告に従って、マスクよりもそちらを重視した対策がとられているようですね。

参加状況

今回の Annual FIRST Conference ですが、最終的な現地参加登録数は88ヶ国から900人ほどになったそうです。コロナ禍前の2/3ぐらいの人数まで回復しているということで、主催者も予想以上の数に喜んでいると話していました。

Lookyloo と Cerebrate

カンファレンス前半で、私が気になったセッションを紹介します。

MISP などのツールで有名な CIRCL から、新しい2つのツール、Lookyloo と Cerebrate の紹介がありました。

さっそく手元で試してみようと思ったツールが Lookyloo です。Web forensics tool と書かれていますが、Web ページ内にあるコンテンツがどこにあるかを、見やすくグラフ表示してくれるものです。表示されたページをパッと見ただけではわからないものが可視化されて、いい感じですね。

MISP もそうですが、他にもいろいろと面白そうなツールを OSS としてリリースしてくれているので、そういうものはちゃんと使ってフィードバックしていかなければいけませんね。

ワークショップを提供

2019年の Annual FIRST Conference に引き続き、今回のカンファレンスでも IIJ からワークショップを提供しました。今回はメモリフォレンジックに関する内容です。

• Super Easy Memory Forensics – You Can “Mount” Memory Images and Analyze them with Explorer and Notepad

講師を努めた鈴木と梨和は、Black Hat USA でもインシデントレスポンスのためのフォレンジックおよびマルウェア解析のトレーニングを継続して提供しています。その、Black Hat USA で提供しているトレーニングの一部を、今回の Annual FIRST Conference でワークショップとして実施しました。

Annual FIRST Conference は当日まで参加者が確定しないのですが、30人ほどの受講者に座学と CTF 形式の実践を含めたワークショップを提供することができました。

今回のワークショップ資料は Slideshare に公開していますので、興味のある方は下記のリンクからご覧ください。

• Super Easy Memory Forensics

また、今年の Black Hat USA 2022 でも4日間のトレーニングを提供します。

Black Hat USA 2018 で提供を始めたときの内容は以前の blog に書きました。その後毎年ブラッシュアップを重ねて、実践的で盛りだくさんな内容になっています。興味を惹かれた方はチェックしてみてください！

• A Comprehensive Guide to Digital Forensics & Malware Analysis for Practical Incident Response – Black Hat USA 2022 | Trainings Schedule

家に帰るまでが出張です

今朝(この記事を書いたのは現地の6/30(木)です)、日本入国のために必要な PCR 検査を受けてきました。ただいま、検査結果を待ちながらカンファレンスに参加しています。

残り2日になった今回のカンファレンス。この調子で以前のような状況に戻っていくことを祈りつつ、残りのセッションを楽しんで帰ろうと思います。

先日から2回にわたり NDSS Symposium 2021 のセッション紹介をしています(1本目, 2本目)。続けて今回も興味深いセッションを1つ紹介します。

Does Every Second Count? Time-based Evolution of Malware Behavior in Sandboxes^[1]Alexander Küchler (Fraunhofer AISEC), Alessandro Mantovani (EURECOM), Yufei Han (NortonLifeLock Research Group), Leyla Bilge (NortonLifeLock Research Group), Davide Balzarotti (EURECOM), “Does … Continue reading

マルウェア検体を動的解析にかけるとき、実行時間をどのくらいで打ち切るかは、いつの時代でも悩ましい問題です。長時間実行すればそれだけ挙動に関する情報を多く取れるであろうことを期待できますが、一定時間内で処理できる検体数は実行時間に応じて少なくなっていきます。かといって、多数の検体をさばくために解析を短時間で打ち切れば、本来見つけたかった挙動が始まる前に観測を止めていることになるかもしれません。このように、解析にかけられる時間あたりの検体数と観測できる挙動のデータ量はトレードオフの関係にあるといえます。

これを踏まえたうえで、それでは実行時間をどのくらいにするのが良いでしょう?

この問いへの答えを求めて、たくさんの検体を集めて検証したのがこの研究報告です。

Küchler 氏らの研究グループは半年間に渡って計10万件の検体(マルウェア検体 8.6万件、良性検体 1.4万件)を集め、その動的解析データを収集、分析しました。大量の検体に対して重たい分析処理を実施するため、実行データを記録してリプレイできる動的解析環境 PANDA を使用しています。さらに、PANDA 環境でのオーバーヘッドによって生じる時刻の遅れを評価するために、有名な動的解析環境である Cuckoo サンドボックスでの実行データと比較もしています。（図1）

詳細は論文を参照いただくとして、ここでは、彼らの報告の中から興味深い知見を3つ紹介します。

• ほとんどの検体は「最初の2分以内に終了する」「15分以上動き続ける」のどちらか（図２）
• 最初の2分間で実行されるコードのカバー率は、15分後のカバー率とほとんど変わらない。つまり2分を過ぎてからは、検体の新たな振る舞いはほとんど観測されない^[2]例えばストレージへのアクセスを続けていても、その振る舞い自体に目新しいものはない。
• 機械学習によるマルウェア判定器を作ると、最初の2分間の挙動を教師データとした場合に最も正解率(accuracy)が高くなった。2分より短くしても、長くしても正解率が下がる

以上のように、複数の観点から「最初の2分間」というのが現時点での最適な答えだろうと結論づけています。

ところで、特徴的な挙動を一切見せずに長時間潜伏するようなマルウェアは多いのか、少ないのか？ これは動的解析だけでなく、例えばインシデントレスポンスの立場からも気になることです。また、マルウェア作者の意図次第で潜伏時間は変えられます。このような知見が将来のある時点でも有効なままなのかを確かめるためにも、今後も定期的に調査が行われることを期待します。

先日の記事に引き続き、NDSS Symposium 2021 で面白かったセッションを紹介します。

Zoom on the Keystrokes: Exploiting Video Calls for Keystroke Inference Attacks ^[1]Mohd Sabra (University of Texas at San Antonio), Anindya Maiti (University of Oklahoma), Murtuza Jadliwala (University of Texas at San Antonio), “Zoom on the Keystrokes: Exploiting Video Calls … Continue reading

この論文では、Zoom などのビデオ会議システムに映った映像を解析することで、画面に映っているユーザのキー入力を推測しようと試みています。「ん？ そうは言っても、ビデオ会議の画面ってあまり手元の方は映ってないよね？」…と思ってしまうわけですが、著者たちはビデオ会議で映っている上半身の映像からタイピング内容を推測する手法を考案、検証しました。

彼らの手法ではビデオ会議の画像のみを使用します。ビデオ会議に映っていることが多い上半身の映像を画像処理して肩と腕の線を抽出。その動きを解析して、キーをいつ押したのかおよび手先がどの方向に動いたかを、ちょっとした動きからもある程度の精度で検出することができたと報告しています。彼らはさらに、これらの情報から入力を推測するために、指の動きに関する情報を付加した専用の辞書を作成して実際のキー入力をどのくらい当てることができるか実験を実施しました。

こうして辞書中からタイプされたと思われる文字列を推測して、実際にタイプされた文字列と比較します。その結果、Webcam の画質やライティング、キーボード操作方法^[2]例えば、手があまり動かないタッチタイプよりも、両手が大きめに動く1本指タイプの方が動作の検知率は上がるようですなどでいい条件が揃った場合、辞書中から200件ほどに絞り込んだ候補内に正解が含まれている確率を80%ほどまで上げることができたそうです。ただし、辞書に含まれていない単語やパスワードなども対象にした、より実環境に近い使用条件では正解率がとても下がることもあわせて報告しています。実際の様々な条件比較に関しては、発表動画や論文を参照してください。

この論文では、撮影状態が手の動きが判別できる程度に良好な動画であれば、辞書などにより必要な情報を補強することである程度の推測が可能なことを示しました。先行研究として挙げられていた「音声チャットでのキータイプ音から内容を推測する」手法と比べて推測精度を上げることができたため、ビデオ会議ではタイピング内容を盗まれる可能性があることに気をつけるべきである、しかし辞書に載っていない文章を推測するのは難しいと彼らは結論づけています。

カメラに映った上半身のみのごく僅かな動きからキータイプを推測しようというアイディアと、そこから実際にキーボード上での手の動きを抽出できたという手法がすごくて、とても面白い発表でした。実環境ではまだまだ難しいことが多いという結論にはなっていましたが、単語の列から文脈の情報を推測に付加したり、今回は使っていない音や入力のタイミングなど、別の外部情報をあわせることで精度をあげられる可能性もありそうです。一方で、実環境で多く使われるようになっている予測変換や、日本語では必須になる漢字変換のような、キー入力にワンクッション入るような入力メソッドを使っている場合にはさらに難しくなりそうだなどと想像しました。将来このような手法が進展して現実的な脅威となったら、ビデオ会議には VTuber のようにアバターを使って参加するのが常識だという時代がくるかもしれません。

意図せず出て/漏れている情報から何かを得ようという研究は、考え方や視点、使われる技術のどれをとっても面白いですね。

デジタルアイデンティティ難しいです。勉強のため、アイデンティティに関する世界最大規模のワークショップ IIW (Internet Identity Workshop) に参加してみることにしました。年に2回の会合で、第32回となる今回は2021年4月20日から3日間のオンライン開催です。アンカンファレンスと呼ばれるスタイルが採用されています。あらかじめプログラムが決められる通常のカンファレンスとは異なり、毎朝 Opening Circle という場でその日のプログラムを参加者たちが話し合いながら決めていくようです。

開催まで一週間を切った4月16日、IIW の事務局から開催案内メールが届きました。ワークショップでは QiqoChat という交流システムを使うようで、開催前に参加登録と動作確認をしておくようにとの指示でした。

QiqoChat への参加登録には2通りのやり方があるようです。1つ目は “Personalized Link” で、メールに含まれる URL (受信者を特定する識別子付き)をクリックして登録する、よくあるやり方です。

2つ目の方法が本記事の本命で、その名も “Verified Credential Ticket” です。”Verified” とありますが、これはきっと今はやりの Verifiable Credential (VC) でしょう。日本でも昨年11月の #idcon vol.28 で実験的にチケットとして利用されていました。今回も勉強のために VC のチケットを取ってみましたので、参考までにその過程を共有します。

Verifiable Credential とは

本題に入る前に Verifiable Credential (検証可能なクレデンシャル) について簡単に紹介します。

「クレデンシャル」は多様な使われ方をする言葉ですが、ここでは運転免許証、社員証、卒業証明書のような、その持ち主が何らかの資格や属性をもつことを第三者が保証する文書をクレデンシャルと呼びます。例えば運転免許証は、持ち主が自動車を運転する資格をもつことを都道府県公安委員会が保証する文書です。

Verifiable Credential はデジタル化されたクレデンシャルです。データモデルは W3C 勧告になっています。デジタル署名やゼロ知識証明といった暗号技術を活用することで、紙でできた従来のクレデンシャルよりも高いセキュリティやプライバシ保護を実現するという嬉しい特徴があります。例えば氏名や生年月日を隠したまま運転資格をもつことだけを証明したり、生年月日を隠したままで年齢が20歳以上であることを証明したりできます。前者は Selective Disclosure (選択的開示) と呼ばれます。最近はワクチン接種証明書 (ワクチンパスポート) への応用が期待され、国際的な注目を集めています^[1]参考: CCI (COVID-19 Credentials Initiative), VCI (Vaccination Credential Initiative)。

今回は QiqoChat の中の IIW 専用スペースに入るためのチケットが、この Verifiable Credential (VC) を使って実装されたようです。私 (チケットの持ち主) が、IIW の参加者であることを、IIW 事務局が保証するためのクレデンシャルです。そこまでプライバシ保護が要求される状況ではないかもしれませんが、実験として面白いと思います。

登場人物とチケットの流れを簡単に図示します。

メインの登場人物は、VC チケットを発行する IIW 事務局、発行された VC チケットを保持する私、私が提示したチケットを検証する QiqoChat の3者です。ブロックチェーン (Verifiable Data Registry) は発行者 (今回は IIW 事務局) の識別子や公開鍵を格納する場所で、具体的には Decentralized Identifier (DID) のためのものですが、本記事では説明を割愛します。

チケットの発行と受取

まずは IIW 事務局から VC チケットを受け取ります。IIW 事務局から受け取ったメールをモバイルデバイスで読んでいるか、それとも PC で読んでいるかでやり方が変わります。モバイルデバイスの場合は、メール内のリンクをクリックするとデバイス上で「ウォレット」と呼ばれるアプリケーションが起動し、登録処理が始まります。一方、PCでメールを読んでいる場合は、メールに埋め込まれた QR コードを「ウォレット」でスキャンすると処理が始まるようです。どちらもあらかじめ「ウォレット」のインストールが必要です。候補として Esatus, IdRamp Passport, Lissi, Trinsic の4 つが挙げられていました。いずれも Android と iOS の両方に対応しています。

私は実験用に入れていた Trinsic Wallet を使いました。メールは PC で受け取っていたので、PC 上に表示した QR コードを Trinsic Wallet でスキャンしました。

ちなみに Trinsic Wallet は Verifiable Data Registry として利用するブロックチェーン(台帳)を選択可能になっていました。今回は Sovrin Network のメインネットに設定したところ、問題なく動きました。

ここから VC チケットが私のウォレットに入るまで、私とウォレットと IIW 事務局 (が使っている idRamp のサーバ) の間で、以下のようなやり取りが行われます。ウォレットと idRamp 間の通信は直接見えなかったため、想像して書いています。Trinsic ウォレットで動くことが確認できたので、ここには Hyperledger Aries の Issue Credential Protocol が使われていると仮定しています^[2]参考: Trinsic のドキュメント。

メール内の QR コードには https://oob.idramp.com/(32桁の16進数) のようなリンクが含まれています。

ウォレットを使って QR コードをスキャンすると(1)、ウォレットがこのリンクにアクセスし(2)、Issuer である idRamp のサーバから Credential Offer を受け取ります(3)。Credential Offer は「こういったクレデンシャルをあなたに発行しようと思うけど、良いですか？」という意味合いのメッセージです。これを受けたウォレットの画面上には、クレデンシャルの内容と受入可否を尋ねるボタンが表示されます(4)。(ここ、スクリーンショットを撮り忘れました)

クレデンシャルは Event Attendee という名前で、以下の9属性を含んでいます。

• Email: 事前に登録したメールアドレス
• First Name: 事前に登録した名
• Last Name: 事前に登録した姓
• Company: 事前登録時に社名を記載したつもりでしたが . (ドット) になっていました
• Event Name: IIW 32
• Event Identifier: iiw32
• Issue Date: 04/20/2021
• Event Date: 04/20/2021
• Attendee Type: Participant

内容に問題ないことを確認したので(5)、ウォレット上で ACCEPT ボタンを押します(6)。するとクレデンシャルがウォレットに格納され、Issued 2021/04/16 と印字されます。

この裏ではウォレットと Issuer の間で、プロトコルに従った Credential Request(7) と Credential 発行(8) が行われたものと想定しています。おそらくCamenisch-Lysyanskaya (CL) 署名方式を使って、コミット (秘匿化) された link secret と上の9属性に対する署名が生成されたものと思います。

これで、IIW 事務局の発行してくれた VC チケットが、めでたく私のウォレットに格納されました。

チケットの利用

無事に VC チケットが手に入ったので、これを持って QiqoChat に向かいます。この後の一連の流れをシーケンス図にしておきます。

VC チケットで入場するには、QiqoChat に用意された専用ページ(https://qiqochat.com/authorize_personal_identity_solutions_event?event=iiw32) を使うようです。PC でこちらにアクセスすると(1,2)、QiqoChat から idramp.com にリダイレクトされました(3,4)。先程チケットを発行してくれた idramp が、ここでは ID プロバイダ (IdP) を兼ねるようです。具体的には以下のような URL にリダイレクトされます。

https://prod.idramp.com/indy/idp/(乱数っぽい文字列)/(乱数っぽい文字列)?returnUrl=%2Foauth20%2Fendpoint%2Finit%2F(乱数っぽい文字列)

OpenID Connect かと思いきや、そうではないようです。

IdP からは、以下のような QR コード付きの画面が返されました(5)。QR コードの中身はクレデンシャル発行のときと同じような https://oob.idramp.com/(32桁の16進数) という URL でした。

ここから PC は IdP の https://prod.idramp.com/api/v1/indy/status/(乱数っぽい文字列)/(乱数っぽい文字列) に毎秒アクセスし、サーバ側の状態が変わるのを待ち続けます(6,7)。

表示された QR コードを手元のモバイルウォレットでスキャンすると(8)、ウォレット上に Presentation の同意確認が表示されます(11)。

この裏ではウォレットと IdP の間で Hyperledger Aries の Present Proof Protocol が動いているものと思います(9,10)。ここも見えないので想像ですが。

ウォレット上では各属性について提示するか否かを選択できます。これが噂の Selective Disclosure (選択的開示) ですね。デフォルトではすべて開示になっていますが、例えば Attendee Type のところを押すと、開示と非開示を切り替えられます。

折角なのでいくつか隠してみても良かったのですが、今回は真面目に全部開示しました(12,13)。するとすぐに proof 成功の表示が出ます。思ったより早いです。(画面に表示されている Masterid や Prooforcreditcard は今回とは無関係です)

裏ではウォレットと IdP の間で Hyperledger Aries の Present Proof Protocol に則った Presentation と検証が行われたと想定します(14-16)。おそらく CL 署名に付随するゼロ知識証明が使われ、署名値や一部の属性を隠しつつ署名の有効性を証明して検証されたものと思います。

すると、毎秒ポーリングしていたブラウザに IdP からリダイレクトが返り(17)、ブラウザ、QiqoChat、IdP の間であれこれ走った後(18-23)、めでたく PC 側に QiqoChat の初期画面が表示されます。

説明を飛ばしてしまった18から23の処理を振り返ってみます。ブラウザは IdP へのポーリングを終えると(17)、IdP の別ページにリダイレクトされます(18)。IdP 訪問時に returnUrl として与えていた場所です。具体的には /oauth20/endpoint/init/(32桁の16進数) でした。

ここから今度は QiqoChat にリダイレクトされます(19,20)。具体的には https://qiqochat.com/idramp_authorization_events/callback?code=(文字列) です。(Authorization Code Flow 的な動きに見えますが state 等がないですね。そもそもどうやってこの callback 先を知ったのだろう)

この後、裏では QiqoChat が IdP にアクセスし(21)、IdP が私の Presentation から抽出した属性を ID Token 等の形に変えて渡してあげて(22)、QiqoChat が私の属性を把握(23)、という動きが走っているものと思います。ここも私の想像です。

まとめ

個人的には VC を使っただけで満足してしまいましたが、少し冷静になって何が嬉しかったのかを考えてみます。

Verifiable Credential の利点の1つは、Issuer と Verifier の間に必ず利用者 (Holder) 本人が介在し、利用者に関する情報の流れを利用者自身が制御できるようにすることで、Issuer や Verifier による利用者の行動追跡を難しくする点にあると思っています。今回は Issuer も Verifier も同じ IIW 事務局 (実際には idRamp) なので利点が分かりにくいです。本当は QiqoChat 側で Verifier の機能を備えて、Presentation の検証を idRamp に任せないのが VC の想定しているモデルに沿うように思いますが、すべてのサイトが Verifier 機能を実装するのも大変ですね。

ただ、後になって思ったことですが、今回のケースでも Selective Disclosure を使ってメールアドレスと氏名を隠せば、presentation の際に idRamp (Verifier) に私の素性を特定させず、ただ IIW32 の参加者であることだけを示すことができますね。その状態で QiqoChat に連携してくれるようなら、QiqoChat にメールアドレスも氏名も明かすことなく、匿名の IIW32 参加者として振る舞えたのかもしれません。今回は既に全属性を開示してしまったため確認できませんが。

現在 OpenID Foundation で改訂が進められている Self-Issued OpenID Provider (SIOP) や、その改訂を待って本格的に議論が再開されるという DID-SIOP も、今回のようなユースケースには深く関わってくるのではと思います。引き続き勉強します。

本日、Security Diary サイトをリニューアルしました。

運営方針や内容は今までと変わりありませんが、スマートフォンなどからでも見やすくなったと思います。これからもどうぞよろしくお願いいたします。

さて、今日から何回かに分けて、2月下旬に開催されていた NDSS Symposium 2021 から興味を惹かれたセッションをいくつか紹介します。このシンポジウムは Internet Society が主催するネットワークと分散システムのセキュリティに関する話題を幅広く扱ったもので、1995年から毎年開催されています。

このシンポジウムではほとんどの論文と講演動画が公開されますので、私は開催後にプログラムを眺めながら興味のあるセッションをチェックしました。コロナの影響で他のカンファレンスなどでもオンライン開催が続いていて、現地に行って直接話したり飲み食いしたりする機会がめっきりなくなったのは寂しいんですが、後から映像で見れるものがとても増えたことは嬉しい変化ですね。

Hey Alexa, is this Skill Safe?: Taking a Closer Look at the Alexa Skill Ecosystem ^[1]Christopher Lentzsch, Sheel Jayesh Shah, Benjamin Andow, Martin Degeling, Anupam Das, and William Enck., “Hey Alexa, is this Skill Safe?: Taking a Closer Look at the Alexa Skill … Continue reading

この論文は Amazon が販売している音声アシスタント、Alexa で使用できる「スキル」について、大規模で包括的な調査を実施したものです。

スキルは、Alexa の音声入出力インターフェースを使ってユーザに機能を提供するための仕組みで、開発してスキルストアに登録することでユーザにサービスを提供することができます。スキルストアは現在82ヶ国、8言語^[2]英語、ドイツ語、イタリア語、フランス語、スペイン語、日本語、ヒンディ語、ポルトガル語。Amazon Alexa誕生から6年、数字でわかるAlexaの成長で展開されているそうです。

研究課題として挙げられているのは、「スキル審査プロセスの精査」「スキルスクワッティング攻撃(スキル名を占拠する攻撃)はどの程度有効か」「プライバシーポリシーリンクを提供するという要件には効果があるか」の3点です。著者たちはそのうちの7ヶ国(アメリカ、イギリス、カナダ、オーストラリア、ドイツ、フランス、日本)でスキルストアの情報をクローリングして、公開されていた全スキル15万件以上のスキルのメタデータとも言うべき情報を収集しました。また、この実験のために彼ら自身がスキルを作成。これらから得られた知見を元に分析を実施しています。

彼らは上記の研究課題について、たとえばスキル審査後のバックエンド変更によって審査中のチェックをすり抜けることができるなど、スキル審査プロセスの過程に攻撃者が悪用できる可能性があるいくつかの問題を発見しました。スキルのプライバシーポリシーについてはツールを作成して分析、不十分な内容のものが多いことを報告しています。また、これら発見した問題の報告と改善方法の提案を Amazon に対して行い、話し合っているそうです。

音声アシスタントに対しての命令は、(当たり前ですが)音声で与える必要があります。彼らはこの作業を丹念に繰り返すために、ログの監視と制御を実施する Raspberry Pi とスピーカー、そして Amazon Polly というテキストの読み上げサービスを使って実験環境を作りました。

この環境を使って、例えば、ユーザが有効化しようとしたスキルに複数同名のものがある場合どちらのスキルが選択されるか実験して、その判断結果と前述したスキルのメタデータが持つパラメータを突き合わせ、Amazon の選択基準がどうなっているかを推測しています。また、同名のスキルを登録することでスキルへのアクセスを奪うスキルスクワッティング的な攻撃が可能であるか、スキルによってユーザのプライバシー情報を盗み出せないかなどを事細かに検証しています。

著者たちの調査と分析結果、およびクローリングにより収集したスキルのメタデータなどが下記のサイトで公開されていますので、興味を持った方はぜひチェックしてみてはいかがでしょうか。

• A Privacy & Security Analysis of the Alexa Skill Ecosystem

(2021-03-24 追記): 講演動画の出典元サイトを明記しました。さらに、音声アシスタントについて思い出したことがあるので追記しておきます。

昨年、遅ればせながら複数メーカーの音声アシスタントを自宅で買って使ってみたんですが、音声を使ったインターフェースで機械とやり取りするのは、Web やコマンドラインとはまったく違う難しさがあるなと実感しました。

音楽が好きなのでいろいろ試してみたんですが… 海外のマイナーなヘヴィメタルを聴きたいことが多い私の場合、ちゃんと聞き取ってもらう難易度がとても高くて、なかなか目的の曲を再生してもらえません。自分の発音が悪いせいかとも思いましたが、そもそも単語の言語が混ざることが難しいというのが本質なのでしょう。

人間同士でも聞き違いによる問題はたびたび起こるので、音声アシスタントの普及度が上がれば上がるほど、サービス提供側が安全性に気を遣わなければならない場面は増えていきそうです。

かつて、技術レポート Internet Infrastructure Review (以下 IIR) で DDoS backscatter 観測状況を継続的に報告していました。最後の報告記事は2017年3月までを扱った IIR Vol.35 でしたから、それから3年近くになります。本記事では、この間の長期的な傾向の変化を紹介しようと思います。

DDoS backscatter とは

DDoS における backscatter とは、送信元を偽ったパケットを受け取ったホストが、その偽装された送信元に対して返答するパケットのことです。DDoS 攻撃では送信元を偽った大量のパケットを送りつける攻撃手法があり、偽装された送信元がたまたま自分で使用している IP アドレスだった場合、その backscatter パケットを受け取ることになります。IIJ では MITF (Malware Investigation Task Force) というマルウェア対策のための観測を行っていて、その設備で backscatter も観測しています。

backscatter については IIR Vol.8^[1]Internet Infrastructure Review（IIR）Vol.8 https://www.iij.ad.jp/dev/report/iir/008.html 2010年8月27日発行: 1.4.2 DDoS攻撃によるbackscatterの観測 で詳しく解説していますので、ご参照ください。

観測パケット数は増加傾向

2015年1月から2020年1月までの全体的な観測状況の推移を見てみましょう。次のグラフは月毎に集計したポート別^[2]観測した DDoS backscatter パケットに含まれる送信元ポート。つまり、攻撃対象の受信ポート。パケット数の推移を示したものです(図1)。

まず気がつくのは全体的な増加傾向です。実際に1日平均の観測パケット数を計算すると、2016年には1万(パケット/日)程度でしたが、2017年には2万、2018年には9万、2019年には16万となり、大幅に増加していることがわかります。

では DDoS 攻撃事案の件数も同じように増えたのか、という疑問が浮かびます。

DDoS backscatter 観測データから直接に事案の件数を示すことは非常に困難なので、代用として、観測データのユニーク IP アドレスを数えることで攻撃対象となったホストの数を見ることにしましょう。次のグラフは月毎のユニーク IP アドレス数の推移を示したものです(図2)。

これによればユニーク IP アドレス数は、減少傾向か横ばいか議論の余地がありますが、少なくとも増加傾向はないと判断できます。

攻撃対象となったホストの数に増加傾向はないということは、ホストあたりの観測パケット数が大幅に増加しているということですから、DDoS 攻撃事案一件あたりのトラフィック規模が大きくなっている様子が伺えます。

高いポート番号への攻撃

最初のグラフ(図1)から、観測の全体像としてパケット数が大幅に増加していることはわかりました。では、その内訳はどうなっているでしょうか。

Web (80/TCP, 443/TCP, 8080/TCP) や SSH (22/TCP), FTP (21/TCP) といった広く使われているサービスのポートが目立つ月もたびたび見られますが、実は、通常のサービスでは利用されない高いポート番号宛の backscatter が観測件数の大半を占めるように変化してきています。実際のデータで見てみましょう。

後述する「DNS 水責め攻撃」の影響を受けないように結果を読み取りたいため、まずは 53/UDP 宛の backscatter を除外します。その上で、大まかな様子を見るために、ここでは0〜65535のポート番号範囲を32768以上と32768未満の半分ずつに分割して集計、月別のグラフにしました(図3)。32768未満のポート番号には、公開サービス用のいわゆる well-known ポート(0-1023)や、それ以外でも公開サービスに使われている 8080/TCP などのポート、また、ゲームのサーバが使うポートなども含まれています。32768以上の「高いポート番号」は特定の用途やプロトコルのために予約されてはおらず、主に TCP/IP スタックが送信元として自動で割り当てる範囲として使われているものです。

2019年8月に32768未満のグラフに大きな山がありますが、これはこの月に2つの IP アドレスに対する SSH(22/TCP) への攻撃件数が突出していたためです。全体を俯瞰すれば、かつては低いポート番号(32768未満)へのパケット数の方が多かったのに、現在では高いポート番号(32768以上)へのパケット数がずっと大きくなっています。

同じデータを割合グラフで見れば、全体に占める高いポート番号(32768以上)の割合が大きくなっていっていることがよくわかります(図4)。

このように、特定のサービスへの攻撃ではなく単純に回線を埋めることだけを狙ったと思われるパケットが多くを占めるようになりました。

DNS 水責め攻撃のその後

DNS で使われるポート 53/UDP への攻撃を示す backscatter が2014年2月から多く観測されるようになり、そのことを IIR Vol.23 で報告しました。のちに IIR Vol.25 で、これらが「DNS 水責め攻撃^[3]JPRS用語辞典｜ランダムサブドメイン攻撃（DNS水責め攻撃） https://jprs.jp/glossary/index.php?ID=0137」と呼ばれる手法の backscatter であると考えられる旨を報告しました。この攻撃は継続的に、長期間観測されていました。過去に紹介したのは、2016年5月25日から一時的に収まっていたものの同年9月20日頃から再び観測されはじめ、1日あたりの観測件数はもとの水準にまで戻っていた、ということでした。

その後、この DNS 水責め攻撃の backscatter がどうなったか、推移を見てみましょう。図5は、DNS 水責め攻撃が始まる前の2014年1月から今年2020年1月までの、ポート 53/UDP を対象にした backscatter 観測件数のグラフです。

グラフを一見してわかるように、53/UDP の backscatter は2017年5月中旬を境にほとんど観測されなくなりました。それ以降現在に至るまで、1日数件程度に収まっています。これは DNS 水責め攻撃が観測されるようになる2014年2月より前と同じ水準です。DNS 水責め攻撃は2017年5月に収束したと表現して良いでしょう。

なぜこの時期に収束したのか、社会情勢の変化(攻撃側の方針転換)やインターネット上の全体的な DNS インフラ構造の変化(防御側の変化)などで思い当たるものもなく、理由はわかっていません。

終わりに

長らく DDoS backscatter 観測データを分析してきたのですが、最近は報道で取り上げられるような大規模な DDoS 事件の backscatter パケットを観測することが少なくなったように感じています。攻撃者側の観点を想像してみると、彼らは「使い捨ての botnet で攻撃するならば送信元アドレスをランダムに詐称する必要はない」と考えるかもしれません。また、昨今事例が増えている TCP SYN/ACK リフレクション攻撃^[4]IIJ Security Diary: IoT 機器を踏み台として利用する SYN/ACK リフレクション攻撃 https://sect.iij.ad.jp/d/2019/02/128021.html^[5]wizSafe Security Signal: Servers.comを狙ったDDoS攻撃の観測 https://wizsafe.iij.ad.jp/2019/10/764/は、攻撃対象のアドレスを送信元として詐称することでインターネット上にある多数の踏み台機器から大量の応答パケット(backscatter)を攻撃対象に集中させる手法ですから、観測用センサーにパケットが届くことはありません。私たちのチームでは、このような攻撃手法の変化が前述したような印象をもたらす大きな要因になっているのではないかと推測しています。

しかしながら、backscatter 観測件数そのものは大きく増加し続けています。攻撃件数の多いものをピックアップして調べると、個人向け PC ゲームの通信用ポートやゲームサーバのサービスポート、ゲーム関連のユーザ・フォーラムのサイトが多く見られます。単純すぎる推測ではありますが、リアルタイムに通信を行うゲームが普通になった時代を反映して、ユーザのトラブルなどを端緒とした DDoS 攻撃がカジュアルに、より多く行われるようになってきているのかもしれません。

防御する側としては、ホストあたりの観測件数が大きく増加した事実を無視するわけにはいきません。守るべきサーバやサービスの規模にかかわらず、DDoS 対策の検討や攻撃に対する対応の用意、定期的な確認など、普段から備える必要性が増してきていると考えるべきでしょう。

本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおいて、2019年に観測した IoT ボットの状況についてご紹介します。

主要なボットの活動状況

IIJ のハニーポットで観測される IoT ボットの活動として、Mirai, Hajime, qBot の 3種類が支配的である状況は昨年から変わっていません。Mirai と qBot はそれぞれ2016年と2015年にソースコードが公開されており、それ以降は元のコードを改変した多様な亜種が次々と出現する状況が継続しています。これらのボットの種類別に2019年の活動状況を以下に示します。なお2018年の観測状況についてはこちらの記事を参照してください。

(1) Mirai

上のグラフは IIJ のハニーポットに到着したパケットのうち、Mirai の特徴に合致するものを示しています^[1]Mirai および Mirai のコードを流用した亜種の場合、スキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP … Continue reading。期間は2019年1月から12月までの観測データを集計したものです。Mirai の通信の特徴に合致するすべてのボットが含まれていることに注意してください。

グラフからわかるように、7月以降の宛先ポートに変化が見られ、またスキャン通信も増加しています。このうち、37215/tcp, 60001/tcp, 34567/tcp, 9000/tcp はいずれも2018年には宛先ポートのトップ10に入っていなかったポートです。

37215/tcp は Huawei HG532 の脆弱性 (CVE-2017-17215) を悪用するもので、7月後半から9月にかけて複数の Mirai 亜種の活動が活発になった影響によるものです。37215/tcp に対するスキャンの送信元アドレスは中国に大きく偏っていました。

宛先ポート 60001/tcp, 34567/tcp, 9000/tcp の増加は fbot / estella / moobot ファミリーの大規模感染によるものです。60001/tcp ポートは Jaws Web Server の脆弱性 (EDB-ID: 41471^[2]EDB-ID は Exploit Database で利用されている識別番号。CVE 番号の採番されていない脆弱性のため、ここでは EDB-ID で示す。)、34567/tcp ポートは dvrip の脆弱性^[3]34567/tcp に対する dvrip の脆弱性を悪用する攻撃は 2019年 2月に fbot の感染活動で最初に確認された。詳細は以下のブログ記事を参照。The new developments … Continue readingを悪用するものであり、9000/tcp は telnet によるバックドアを探索する通信と考えられます。これらのボットは2019年2月以降断続的に活発な活動が観測されています。fbot は2018年9月に 360Netlab によって最初に報告されたボットで、Satori との関連性が指摘されています^[4]詳細は 360Netlab のブログ記事を参照。なお IIJ のハニーポットでは初期の fbot の活動を 2018年 5月から観測しており、Satori … Continue reading。Satori は2017年11月に国内で Mirai 亜種感染急増の原因となったボットのひとつです^[5]国内における Mirai 亜種の感染急増 (2017年11月の観測状況) https://sect.iij.ad.jp/d/2017/12/074702.html。

fbot / estella / moobot ファミリーに共通する特徴を以下に示します^[6]このボットファミリーには Mirai 亜種だけでなく、qBot 亜種も多数存在しており、同時期に複数のタイプを使い分けていると考えられる。。

• オリジナル Mirai とは異なる独自の暗号化手法
• オリジナル Mirai とは異なる独自の C2 通信プロトコル (バージョンによって異なる)
• 9527/tcp (telnet), 34567/tcp (dvrip) など、他の Mirai 亜種が利用しない独自の感染経路
• C2 サーバ、ダウンロードサイトなど共通のインフラを利用

他の Mirai 亜種とは異なる感染経路を利用するため、競合があまりないことから、感染規模が数万台を超える場合があります。そのため DDoS 攻撃に利用されると高い攻撃力を持つと考えられます。2019年9月には moobot を利用した DDoS 攻撃により、Wikipedia, Twitch, Blizzard のサービスで被害が発生しました。この攻撃活動の詳細についてはこちらの記事をご参照ください。

上のグラフは Mirai 亜種によるスキャン通信の、ユニークな送信元アドレス数の全体の推移および国別トップ10の推移を示したものです。ハニーポットによってスキャン通信が観測されるものは全体の一部ではありますが、感染規模を推定する指標にはなります。

全体としては2019年前半までは減少を続けていたのが7月以降増加に転じ、11月頃にピークを迎えて再び減少傾向となっています。国別では年間を通じて中国が感染数の最も多い国となっています。また、台湾、ブラジル、エジプトなど、特定の亜種の活動が活発になると一時的に感染数が増加している国が見られます。これは2018年から継続して見られる特徴です。

(2) Hajime

上のグラフは IIJ のハニーポットに到着したパケットのうち、Hajime の特徴に合致するものを示しています。期間は2019年1月から12月までの観測データを集計したものです。Hajime はコードのリークや公開は確認されていないため、亜種というものは存在しません。年間を通じて安定した活動状況が観測されていますが、緩やかな減少傾向にあることがわかります。

下のグラフは Hajime によるスキャン通信のユニークな送信元アドレス数の全体の推移および国別トップ10の推移を示したものです。国別でみると Hajime はブラジル1国に集中して感染している状況が続いており、2019年12月時点の IIJ の観測では Hajime の感染数の約4分の1はブラジルです。ただしブラジルの感染数はこの1年間で半数以下に減少しており、全体の感染数減少の主な要因となっています。

なお2019年12月時点において Hajime が主に攻撃対象としているポートと脆弱性、および活動している検体は2018年5月以降変わっていません。これらの詳細については2018年の記事を参照してください。

(3) qBot

qBot には Bashlite / Gafgyt / Lizkebab / LizardStresser / Torlus など様々な別名があり、2015年にソースコードがリークされて以来、多数の亜種が存在します。Mirai や Hajime などと異なり、qBot はその通信の特徴だけでは判別できず、またスキャン機能をもたない検体も多いことから、全体の感染規模ははっきりしません。ですが IIJ のハニーポットで捕捉している IoT ボットの中では Mirai, Hajime と並んで最も多いボットのひとつです。Corona, Cayosin, Demon, Love などの qBot の亜種が年間を通じて活発に活動しています。

国内の動向

国内では2017年末に大規模な Mirai 亜種の感染事案が発生したものの、2018年以降は減少を続け、2019年は年間を通じて Mirai 亜種の国内感染数は非常に低い水準で推移しました。2017年末の大規模感染では、52869/tcp ポートに対して Realtek SDK の脆弱性 (CVE-2014-8361) が悪用されたことがわかっています。販売元のベンダー^[7]ロジテック製300Mbps無線LANブロードバンドルータおよびセットモデル（全11モデル）に関する重要なお知らせとお願い … Continue readingや JPCERT/CC^[8]Mirai 亜種の感染活動に関する注意喚起 https://www.jpcert.or.jp/at/2017/at170049.html からの注意喚起などもあり、当該脆弱性を持つ機器数は減少していると考えられますが、それでもまだ相当数が国内に存在していると推定されます。そのため、この脆弱性を悪用する感染活動には注意が必要です。

下のグラフは 52869/tcp へのスキャン送信元アドレス数の推移をマルウェアの種類別に示したものです。つまり、この脆弱性を悪用して、どの種類のマルウェア感染が試みられたかを表しています。1月など一部で Mirai 亜種の感染試行が多く見られますが、全体的には qBot 亜種の感染試行が大半を占めていることがわかります。これらの qBot 亜種はスキャン機能をもたないものがほとんどで、ハニーポットによる観測では感染規模の推定が困難です。国内では Mirai 亜種の感染数は減少したものの、かわって qBot 亜種の感染が拡大している可能性もあり、引き続き警戒が必要と考えます。

国内における脆弱な IoT 機器を調査する活動

2019年には、総務省および国立研究開発法人情報通信研究機構 (NICT) が国内 ISP と連携して、IoT 機器の調査と注意喚起を行う取り組み「NOTICE」が話題となりました^[9]IoT機器調査及び利用者への注意喚起の取組「NOTICE」の実施 https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00011.html。この他にも同様に脆弱性のある IoT 機器を調査する目的で複数の広域スキャン活動が国内において実施されています。IIJ のハニーポットでは以下の3つのスキャン活動について観測しています。

(1) 総務省および国立研究開発法人情報通信研究機構 (NICT) による取り組み 「NOTICE」

2018年11月より予備的な事前調査を開始、2019年2月より本調査を開始しており、実施状況は四半期毎に公開されています^[10]脆弱なIoT機器及びマルウェアに感染しているIoT機器の利用者への注意喚起の実施状況（2019年度第3四半期） … Continue reading。観測された通信を見ると、ポートスキャンには Masscan、バナー取得には ZGrab をそれぞれ利用しているようです。

(2) 一般社団法人 ICT-ISAC による取り組み^[11]脆弱なIoT機器の調査について https://www.ict-isac.jp/news/news20181022.html

ICT-ISAC が総務省と連携して2018年9月より実施しているもので、1週間に1回程度のペースで約250のポートを継続してスキャンしています。ポートスキャンには Nmap を利用しているようです。

(3) NTTアドバンステクノロジによる取り組み^[12]広域ネットワークスキャンによる調査について https://www.ntt-at.co.jp/news/2018/detail/info181107.html

平成30年度における総務省の研究開発の提案公募に採択されたもので、2019年7月までスキャン活動が観測されていました。対象ポートはかなり広範囲で1万以上のポートに対してスキャンしていました。ポートスキャンには Masscan を利用していたようです。

最近の話題から

最後に IoT 機器に関する最近の話題をひとつご紹介します。2020年1月19日に「50万 IP 以上の機器における Telnet のユーザ名とパスワードのリストがハッカーによって公開された」という内容の記事が ZDNet から公開されました^[13]Hacker leaks passwords for more than 500,000 servers, routers, and IoT devices | ZDNet https://www.zdnet.com/article/hacker-leaks-passwords-for-more-than-500000-servers-routers-and-iot-devices/。国内ではあまり報道されていませんが、海外ではセキュリティ系のメディアを中心にこの記事が広く参照されています。

IIJ でもこのリストを入手し独自に調査しました。リストは16個のテキストファイルから構成されており、51万件余りの IP アドレスと ID/PW のリストが含まれています。しかしデータを精査してみるとかなり重複があり、ユニークな IP アドレスは10万件弱でした。このリストには Mirai リストと名前がつけられていましたが、この10万件の IP アドレスを2019年に IIJ のハニーポットで観測した100万件以上の Mirai 亜種の送信元アドレスと比較したところ、一致したのは約2千件(2%)でした。また ID/PW については admin:admin や root:root など、よく知られたデフォルトのものが多数を占めており、上位10個の組み合わせが全体の半数を占めていました。これらの結果に加えて、IP アドレスが動的アドレスですでに変更されていたり、Telnet のポートが閉じていたりする可能性も考えられます。したがって、IoT ボットの感染活動にこのリストをそのまま利用することを想定した場合、その有用性は著しく低いと考えられます。Mirai のコードを流用したほうがおそらくもっと効率的でしょう。こういった記事の内容から影響を評価することは難しいため、不必要に踊らされることなく、脆弱性のある機器を減らすための取り組みを粛々と続けていくことが大事です。

2019年10月下旬に大規模な TCP SYN/ACK リフレクション攻撃を複数観測しました。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットの観測結果から、今回の DDoS 攻撃の発生状況について紹介します。

TCP SYN/ACK リフレクション攻撃

リフレクション攻撃 (リフレクター攻撃、アンプ攻撃とも呼ぶ) は、送信元アドレスを偽装した IP パケットを踏み台となる多数の機器 (リフレクター) に大量に送信することにより、その応答パケットを利用して攻撃する DDoS 攻撃手法の一つです。この場合、偽装された送信元アドレスがターゲットとなる被害者ということになります。真の発信元である攻撃者のアドレスを隠蔽するとともに、リフレクターからの応答パケットのサイズが大きくなる増幅効果を狙う攻撃です。UDP と比較すると増幅効果のあまり大きくない TCP によるリフレクション攻撃はこれまであまり使われてきませんでしたが、2018年から攻撃の観測数が増加しています^[1]TCP の場合はペイロードを含まないためパケット単体としての増幅効果はないが、SYN/ACK パケットの再送によるパケット数の増幅が見込める。UDP … Continue reading。これまでの観測事例については以下の記事も参照ください。

wizSafe Security Signal

• wizSafe Security Signal 2018年9月 観測レポート
• wizSafe Security Signal 2019年7月 観測レポート
• Servers.comを狙ったDDoS攻撃の観測

IIJ Security Diary

• IoT 機器を踏み台として利用する SYN/ACK リフレクション攻撃

これまでに IIJ で観測している TCP SYN/ACK リフレクション攻撃には以下のような特徴があります。

• 宛先ポートは 80/tcp, 443/tcp が大半を占め、主に Web サーバを踏み台として利用している
• オープンポート以外には SYN パケットが到達しない。そのため攻撃者は事前にポートスキャンをするなどして、踏み台として利用するアドレスとポートのリストを保持していると考えられる
• ターゲットとなる送信元アドレスの偽装において、Carpet Bombing (絨毯爆撃) と呼ばれる攻撃手法が多く用いられる (後述)

2019年10月における攻撃の観測状況

TCP SYN/ACK リフレクション攻撃の起点となる SYN パケットには複数のパターンがあることが IIJ の分析によりわかっており、IIJ のハニーポットでは2018年8月から継続してこれらのパターンに該当するパケットを観測しています。下のグラフは、攻撃パターンに該当する SYN パケット数の2019年4月から10月までの日別推移をあらわしています。過去半年と比較すると特に大規模な攻撃が10月下旬に集中していることがわかります。

10月22日から10月31日の期間について、さらに送信元アドレスの AS 別に SYN パケット数の内訳を示したのが上のグラフです。攻撃日時とアドレスから、複数の攻撃活動を特定できます。

(1) 韓国への攻撃

10/23から10/27にかけて Korea Telecom (AS4766) に対して、10/25から10/31にかけて AWS (AS16509) のアジアパシフィックの複数のリージョンに対して (10/26は日本、10/29,30は韓国)、それぞれ攻撃を観測しています。具体的な攻撃のターゲットや両者の攻撃の関連性は不明ですが、いずれも攻撃のピークは10/26で、攻撃の時間帯が同じです。

(2) トルコへの攻撃

10/27から10/28にかけて、トルコの AS12903 (Garanti Bilisim Teknolojisi ve Ticaret T.A.S.) に対して、この期間における最大規模の攻撃を観測しました。トルコの大手金融機関 Garanti BBVA は DDoS 攻撃を受けたことを明らかにしています。また現地報道によると上流の大手通信事業者 Türk Telekom も攻撃の影響を受けたようです。

• https://twitter.com/GarantiBBVA/status/1188469498275336192
• https://twitter.com/GarantiBBVA/status/1188745097338335233
• http://www.hurriyetdailynews.com/cyberattack-targets-turk-telekom-garanti-bank-148034
• https://www.dailysabah.com/turkey/2019/10/28/cyberattacks-blamed-for-sundays-internet-disruption-across-turkey
• https://www.cnnturk.com/video/ekonomi/garanti-internet-sube-coktu-mu-garanti-bankasindan-ddos-aciklamasi

(3) イタリア、フランスへの攻撃

10/31にイタリアの Lottomatica と Eurobet、フランスの Unibet と Winamax に対する攻撃を観測しました。これらはいずれもオンラインギャンブルサイトです。このうちイタリアの Eurobet に対しては小規模ながら10/14,15にも攻撃を観測しており、この時には攻撃者と思しき人物から Twitter 上で金銭を要求する脅迫メッセージが送られていることを確認しています。また Lottomatica に対しても、10/19から10/23にかけて小規模な攻撃を観測しています。

(4) Tor network への攻撃

上記 (1) から (3) までと比較すると観測した TCP SYN/ACK リフレクション攻撃の規模は小さいですが、10/31に Tor network に関連すると思われる複数のアドレスへの攻撃を観測しています。このうち Tor Exit Node を多数運用している Emerald Onion (AS396507) では^[2]Tor Metrics のデータから、AS396507 において運用されている Tor relay を確認することができる。https://metrics.torproject.org/rs.html#search/as:396507、/24 のアドレスすべてに対して合わせて 200Gbps の攻撃を受けたため、上流プロバイダから経路の伝達を一時的に拒否されたことを明らかにしています^[3]AS396507 の上流は AS6939 で、RIPEstat の Upstream Visibility のデータによると、10/30 20:30 (UTC) 頃から 10/31 06:20 (UTC) 頃まで約 … Continue reading。IIJ のハニーポットで観測した送信元アドレスは /24 のレンジのうち一部に限定されており、また攻撃トラフィックの規模が 200Gbps と非常に大きいことから、TCP のほかに UDP アンプ攻撃など複数の攻撃手法が併用された可能性が高いと考えられます。

• https://twitter.com/EmeraldOnion/status/1189668679752900608
• https://twitter.com/EmeraldOnion/status/1189797459771310080

なお、(1) から (3) までの攻撃と (4) の攻撃とでは、送信される SYN パケットのパターンが異なっており、これらは別の攻撃インフラを利用した活動と考えられます。ただし (1) から (3) までの攻撃に関してもパケットのパターンは同じですが、これらが同じ攻撃者による活動なのか、同じ攻撃インフラを用いた別の攻撃者による活動なのか、そのいずれでもないのか、現段階ではわかっていません。

Carpet Bombing

ターゲットとなる送信元アドレスの偽装においては、Carpet Bombing と呼ばれる攻撃手法が多く用いられています。IIJ では2018年頃からリフレクション攻撃と組み合せて使われていることを確認しています。NETSCOUT 社の2018年下半期のレポートによると、2017年11月からこのタイプの攻撃を観測しており、2018年に急増したと報告しています^[4]NETSCOUT Threat Intelligence Report 2H 2018 https://www.netscout.com/sites/default/files/2019-02/SECR_001_EN-1901%20-%20NETSCOUT%20Threat%20Intelligence%20Report%202H%202018.pdf。

Carpet Bombing では、送信元アドレスの偽装において単一の IP アドレスを指定するのではなく、/20 や /21 など広いレンジのサブネット全体に対して万遍なく攻撃を行います。そのため IP アドレス単位での攻撃の検知やブロックはうまく機能しない可能性があります。こうした検知や防御を回避するのが攻撃者の狙いと考えられます。ただし攻撃対象となるアドレスが分散している点を除けば他に特異な点はなく、これまでと同様の防御手法が有効と言えます。

TCP SYN/ACK リフレクション攻撃への対応

現在 IIJ で観測されている TCP SYN/ACK リフレクション攻撃では宛先ポートとして 80/tcp と 443/tcp が多くを占めており、世界中の Web サーバが踏み台として利用される可能性があります。攻撃規模がある程度大きくなると、このような踏み台となるサーバ側でも、自身のサイトに対する SYN Flood 攻撃が行われていると誤認して攻撃を検知することが予想されます。実際に狙われているのは偽装された送信元アドレスの方ですが、踏み台となる機器において積極的に攻撃を検知、防御することによって、最終的なターゲットに対する攻撃を緩和することにつながります。一方、こうした対応をすることによって二次的な被害が発生する危険性もあります。たとえば、実際には攻撃の被害者である偽装された送信元アドレスをブラックリストに入れるような対応をした場合、本来は許可されるべき通信まで阻害される恐れがあります。こうした点に注意は必要ですが、攻撃発生の抑止が難しい現状では、踏み台となるリフクレターでの対応も求められます。IIJ ではこのような DDoS 攻撃に対処すべく、今後も攻撃の観測、分析を続けていきます。

今月9/7から9/9にかけて、Wikipedia, Twitch, Blizzard の各サーバに対して連続して DDoS 攻撃が発生しました。この一連の攻撃は Mirai 亜種によるボットネットによって引き起こされたことが IIJ の調査によりわかりました。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットの観測結果から、この攻撃で利用されたボットネットの特徴と DDoS 攻撃の発生状況について紹介します。

DDoS 攻撃の概要

一連の攻撃は日本時間の 9/7 2:40 頃から始まり、最初に被害を受けたのは Wikipedia でした^[1]Wikipedia への攻撃の状況については、ThousandEyes 社の解説記事が詳しい。Analyzing the Wikipedia DDoS Attack https://blog.thousandeyes.com/analyzing-the-wikipedia-ddos-attack/。その後、攻撃対象は Twitch から Blizzard へと変わりました。

• Malicious attack on Wikipedia—What we know, and what we’re doing – Wikimedia Foundation
• Recent DDoS Attacks Impacting Game Service – Community / General Discussion – World of Warcraft Forums

各サイトへの攻撃発生時刻はおよそ以下のとおりです。Twitch と Blizzard に対しては2日間にわたり断続的に攻撃が発生しています。IIJ では該当時間帯のボットネットの活動を監視しており、時刻とアドレスのデータは C2 サーバからの攻撃指令の内容に基づいています。

攻撃者は攻撃実行の様子を Twitter アカウントからリアルタイムに中継していましたが、その内容は外部における攻撃観測の状況や IIJ での観測結果とも整合しており、実際の攻撃者自身によるものとみて間違いありません^[2]該当アカウントはサスペンドされているが、一部のツイートはアーカイブサイトから確認することができる。 https://archive.is/http://twitter.com/UKDrillas。攻撃者は Twitch への攻撃の際にはいくつか個別のチャンネルに言及しています。また Blizzard への攻撃では World of Warcraft Classic のサーバのアドレスを攻撃対象として選定しています。攻撃の動機ははっきりしませんが、オンラインゲームに関連するサービスを狙う明確な意図があったと考えられます。一方、Wikipedia を狙った理由はよくわかりませんが、一連の攻撃のテスト、デモンストレーションとして選定された可能性が考えられます。

Mirai 亜種 moobot

攻撃に利用されたボットネットは Mirai 亜種 moobot で、複数の DVR 機器を狙って8月末から感染を拡大していました。このボットにはスキャンする対象ポートと攻撃に利用する脆弱性の違いから3つのタイプがあります。それぞれの特徴を以下に示します。

• タイプ1
  • スキャン対象ポート TCP: 34567
  • dvrip プロトコルを利用し、デフォルトの ID/PW の組み合わせでログインを試行して、コマンドを実行する^[3]2019年2月に fbot という Mirai 亜種が用いたのと類似の攻撃手法を利用している。The new developments Of the FBot … Continue reading。コマンド実行によって特定のポートにバックドアをあけ、そのポートにサーバから接続して、ボットのダウンロード、感染を行う。
• タイプ2
  • スキャン対象ポート TCP: 80, 81, 82, 83, 85, 88, 8000, 8080, 8081, 9090
  • Hisilicon 製 DVR 機器の脆弱性を利用して、機器のモデル番号を取得する^[4]HiSilicon DVR Devices – Remote Code Execution – Hardware remote Exploit https://www.exploit-db.com/exploits/44004。サーバにレポートされたモデル番号をもとにエクスプロイトを実行すると推定されるが、IIJ では確認できていない。
• タイプ3
  • スキャン対象ポート TCP: 60001
  • JAWS Web Server の脆弱性を利用してコマンドを実行する^[5]MVPower DVR TV-7104HE 1.8.4 115215B9 – Shell Command Execution (Metasploit) – ARM remote Exploit https://www.exploit-db.com/exploits/41471。コマンド実行によってシェルスクリプトをダウンロードして実行し、このスクリプトがボットのダウンロード、感染を行う。

このほか、ボットの感染拡大にあたっては ADB (Android Debug Bridge, 5555/tcp) や Telnet (9527/tcp) なども利用されており、これらのポートへはボットからではなく複数のサーバからの攻撃を IIJ のハニーポットでは観測しています。

いずれのタイプも共通する C2 サーバによって支配され、同じ5種類の DoS 攻撃手法を備えていますが、今回の DDoS 攻撃では主に “tcp syn” と “tcp ack” の2種類の攻撃が行われました。これらはオリジナルの Mirai も備えている攻撃手法で、それぞれ TCP の SYN パケットおよび ACK パケットを攻撃対象のアドレスに対して大量に送信するものです^[6]オリジナルの Mirai については、IIR Vol.33 のフォーカスリサーチ「1.4.1 Mirai Botnet の検知と対策」を参照 https://www.iij.ad.jp/dev/report/iir/033/01_04.html。

上のグラフは IIJ のハニーポットで観測した各タイプ別ユニーク送信元アドレス数の日ごと推移を示しています。これらのスキャン送信元はボットに感染していると考えられます。8月末から急激に感染数が拡大し、9/4頃をピークとして徐々に減少している様子がわかります。外部の観測結果などもあわせて推定すると、ピーク時点で約4〜5万台程度の規模と考えられます。

また下のグラフは9/1から9/14までの2週間に IIJ が観測した送信元アドレスの国別分布を示しています。特定の国に分布が大きく偏っており、上位5ヶ国 (VN, BR, MX, TW, TR) で約半数を占めています。これはボット感染に利用された脆弱性をもつ機器の分布の偏りを示していると考えられますが、攻撃者が特定の国を狙って感染を拡大させた可能性もあります。

攻撃に利用されたボットネットは、ある Stresser/Booter サービスの攻撃インフラとなっていたことが IIJ の調査でわかっています。Stresser/Booter は安価に DDoS 攻撃のインフラを利用できる DDoS 攻撃代行サービスです。DDoS-as-a-Service や DDoS-for-Hire Service などとも呼ばれ、近年 DDoS 攻撃が発生しやすくなっている要因の1つと考えられています。Stresser/Booter にはボットネットを利用するもの、DNS や NTP など UDP アンプ攻撃を実行するもの、あるいはこれら複数の攻撃インフラを組み合わせたものなど、様々な種類のサービスが存在します。今回の攻撃者もおそらくこの Stresser サービスを契約して、DDoS 攻撃を行ったのではないかと考えられます。

世界中に脆弱性のある IoT 機器が大量に存在する現状では、今回のように比較的短期間で大規模なボットネットが構築され、そのボットネットを利用した DDoS 攻撃が行われるという事例が繰り返し発生する可能性があります。IIJ では IoT ボットの感染および攻撃活動を今後も継続して観測するとともに、脆弱性のある機器を減らすための取り組みを続けていきます。

IoC (ボット検体の SHA256 ハッシュ、ファイル名はいずれも armv7l)

• タイプ1
  • 64dacda48e72df46a1bf8e952c0f3b3ad207166ff570242358b0ec7dfa2e75c9
  • 5be892b089400fd57b1a0e200ea4c2510dd35afa557a1bd2c392cf8f6aa2f289
  • d9c26aa6271c9922c06d1c88b8e2211dd25b0d398b92e899c312a0522bf44424
• タイプ2
  • 8634783741d1be922ccbcebf5ba241a669d727dae6963cfbbe5196f6af73e227
  • a1be9d53956734cba1e7752fef850e5a9265fa12167cc959df058e3515d779ef
  • 337b01ed4b591950dd7de4eb3ae25e72068e466fb763864283e687c487206c1a
• タイプ3
  • 1def13b9e3269694c1e76500391190696a86badc632b8b0bfb140840bc841116