Memcachedサーバーの脆弱性を突いたリフレクション攻撃が急増。JPCERTも注意喚起を実施。

f:id:nanashi0x:20180301142658j:plain

https://www.jpcert.or.jp/at/2018/at180009.html

ここ数日間でMemcachedを悪用したDDoS攻撃が急増している。

個人的にMemcachedについては存在すら知らなかったので、ゼロから調べた際にメモを作成し、ニュースに絡めて紹介する事にした。

その為、この記事はMemcaechedを悪用したDDoS攻撃を理解する為の前提知識から説明していく形になっている。

この記事では以下のように大きく3つのポイントに分けて説明する。

Memcachedについての説明
リフレクション攻撃についての説明
Memcachedを悪用したDDoS攻撃の被害状況

前半部分は基本的知識の説明に終止する為、既に理解している読者は後半部分まで飛ばし読みして構わない。

Memcachedとは

Memcachedとは、Webアプリケーションの高速化・スケーラビリティを配慮して作成されたソフトウェアである。

Danga Interactive社のBrad Fitzpatrick氏が中心になって開発された。

一般的にWebアプリケーションは、RDBMS(リレーショナル・データベース管理システム)にデータを格納し、アプリケーション・サーバーがデータを引き出してブラウザに表示する。

この時、RDBから取り出すデータが大量になったり、RDBへのアクセスが集中すると、RDBMSの負荷が上がってしまう。

その結果、RDBからのレスポンススピードが下がり、Webサイトの表示が遅延する自体に陥る。

Memcachedは、WebアプリケーションのからRDBへ行われる問い合わせ結果を一時的にキャッシュする。

そうすることで、Webアプリケーションからデータベースへのアクセス回数を減らし、Webアプリケーションの高速化、スケーラビリティ向上を図れる。

参考URL（外部リンク）

memcachedを知り尽くす

リフレクション攻撃について

このセクションでは、以下のポイントに分けてリフレクション攻撃について説明していく。

リフレクション攻撃とは
リフレクション攻撃の手順（簡略版）
リフレクション攻撃が発生する条件

リフレクション攻撃とは

（追記: リフレクション攻撃に関する記述に誤った表現があり、修正致しました。

_hiro(@papa_anniekey)さん、ご指摘＆改善案のご提示ありがとうございます。edited by Ichi at 2018/03/02)

送信元から送られたリクエストに対して、反射的に応答をするものをリフレクターと呼ぶ。

リフレクターを利用して行われるリフレクション攻撃は、コネクションレス型プロトコルであるUDPの特性を悪用して行われる。

UDPを用いるプロトコルとしては、DNSをはじめ、Syslog、SNMP、NTP、そして今回話題となっているmemcachedが挙げられる。

UDPがリフレクタ攻撃の要となっている理由は『攻撃元の隠ぺいが容易』である事だ。

攻撃元の隠ぺい技術は、IP Spoofingと呼ばれる。

HTTPで用いられるTCPのようなコネクション型プロトコルは、3Way-Handshakeで知られるように、実際のデータ・ペイロードのやり取りを行う前に、必ず通信を行う為の〝前準備＝3回の通信”が必要となる。

しかし、UDPの場合のようなコネクションレス型プロトコルの場合、この"前準備"は必要ではない。

一方的に通信を送り付けると受信した側はIPヘッダに書かれている送信元IPアドレスを送信元と判断してそこに対してリクエストの内容に応じたResponseを一方的に返す。

これを悪用すると、IPヘッダを偽装（IPヘッダにターゲットを記載）することで任意のターゲットに対し、応答パケットを「送り付ける」事が可能となるのである。

リフレクション攻撃の手順

リフレクション攻撃を行う為の、簡単な手順は以下のようになる。

攻撃者は、送信元IPアドレスを、DDoS攻撃の対象となるIPアドレスにSpoofしたリクエストパケットを作成する。
そのリクエストをMemcachedサーバーの11211番ポートに向けて送信する。
Memcachedサーバーは、攻撃者から送信されてきたリクエストに応じて応答を返す。応答は、攻撃者により設定された任意の送信元IPアドレス（＝攻撃のターゲット）に”返送”される。
このリクエストを送信する際、攻撃者はリフレクターから返送される応答の結果が、できるだけ大きくなるようなリクエスト（コマンド）も含めて送信する。
その結果、応答のサイズが攻撃者のリクエストと比較して大きくなり（＝増幅され）、攻撃としてインパクトが生まれる。

リフレクション攻撃の参考例

以下のshodanから取得した画像は、リフレクターにパケットを送信した後に、増幅されて返送されてきた応答の例である。

画像内の一行目の”stats”が、リフレクターに対して送信したリクエストで、二行目以降がリフレクターから返送されてきた応答である。

TCPを使用しているので今回の攻撃で使われている手法とは異なるが、リフレクターがこのような返答をするというイメージを掴むには良いだろう。

f:id:nanashi0x:20180302165746j:plain

(画像は任意のIPアドレスを入力して出力した結果)　

参考URL（外部リンク）

リフレクション攻撃が成立する条件とは

リフレクション攻撃が成立するための条件は、主に3つある。

送信元IPアドレスの詐称(IP Spoofing)によって攻撃可能なこと
- 攻撃者がIPアドレスを詐称した問い合わせがリフレクターに到達可能でなければいけない。送信元IPアドレスは自己申告制である。つまり”なりすまし”が可能なのだ。攻撃者はこれを利用して、ターゲットとなるノードのIPアドレスを送信元として指定したパケットを、リフレクターに送信する。そうすることでリフレクターからの増幅された応答を届けられる。
リフレクターが数多く存在する
- Webサーバーがリフレクターとなり得る。すなわち、攻撃対象となるリフレクターの数が多ければ多いほど、リフレクターを用いた攻撃がしやすくなる。
リフレクターの増幅率が高い事
- 攻撃者が第一弾としてリフレクターに対して送信するパケットのサイズを、リフレクターがサイズを増幅してパケットを返す事になる。この時、”問い合わせ”に対する”応答”のサイズ比が大きければ大きいほど、リフレクター攻撃の効率が上がる。

参考URL（外部リンク）

技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について

Memcachedを悪用したDDoS攻撃の概要

さて、本題であるMemcachedを悪用したDDoS攻撃の概要と被害状況に関して説明していく。

DDoS攻撃について

DDoS攻撃は、MemcachedサーバーでデフォルトでONになっているUDPポート11211番を送信元として世界各地に存在するサーバーに対して行われている。

つまりMemcachedのリフレクター機能を踏み台としてDDoS攻撃を行っている状況である。

ArborNetworksの調査では、今回のMemcachedを踏み台として行われているDDoS攻撃は、最初にスキルの高い攻撃者によって手動で行われ、徐々にメソッドがDDoS-for-hireボットネットを通して非常に短期間で拡散していったと見られている。

Memcachedを起因とするDDoS攻撃の規模

Qihoo 360が公開しているDDoS Monのデータを以下に示す。

2月下旬までは比較的フラットな推移をしていたのだが、ここ数日間でMemcachedを悪用したリフレクション攻撃が急増。

f:id:nanashi0x:20180301142847p:plain

(Memcachedが悪用されて発生しているリフレクション攻撃の日別推移。DDoSMonより引用。)

Memcachedから送信されてくるパケット毎秒数(pps)は、最高値でおよそ23Mppsである。1秒毎のパケットサイズで言えば、そこまで大した大きさではないよう見える。

f:id:nanashi0x:20180301143053p:plain

(パケットサイズ毎秒の日別推移。Cloudflareより引用。)

しかしmemcachedから送信されてくるインバウンド・トラフィックの帯域幅は、260gbpsに到達している。

f:id:nanashi0x:20180301143104p:plain

(帯域幅の日別推移。Cloudflareより引用。)

なお、Cloudflareが公開しているtcpdumpの結果は以下。検知されているパケットが使用する帯域幅は、およそ1400となっている。

単純計算で、23(Mpps)　× 1400(bytes) ≒ 257（Gbps）となる。

f:id:nanashi0x:20180301143138p:plain

(Cloudflareが行なった調査過程で実行されたtcpdump結果。Cloudflareより引用。)

ソースIP

脆弱なMemecachedサーバーは世界各国に点在している。

f:id:nanashi0x:20180301142931p:plain

(ソースIPはアメリカ、ヨーロッパ、アジアと広範囲に渡る。Cloudflareより引用。)

また、Cloudflareの公開しているAS(Autonomous System)別に分けられたIPアドレスでは、フランスのクラウドサービスであるOVH、アメリカのDigitalOceanに次いで、日本のさくらインターネットが上位に入っている。

f:id:nanashi0x:20180301143013p:plain

(殆どのクラウドサーバーがリストに入っている。Cloudflareより引用。)

踏み台にされない為の対策

Memcachedを利用しているかに関わらず、サーバーを管理している人は、自身のサーバーがDDoS攻撃の踏み台にされない為にアクセス制御を行う必要がある。

さくらインターネットがMemcachedのアクセス制御を行うよう注意喚起を行ない、その中に3つの方法が示されていたので紹介する。

Memcachedにアクセス可能なIPアドレスをlocalhostに限定する。UDPを無効にする。

Memcachedを使用していない場合はサービス停止、自動起動を無効化。不要の場合は削除。

ファイアウォールを設定し、Memcachedが使用するポートへのアクセス制限。

上記した方法①に関しては、さくらインターネットの注意喚起ではCentOS７における手順が公開されているので参照してもらいたい。

参考URL（外部リンク）

【重要】memcachedのアクセス制御に関する注意喚起

追記：DDoS攻撃の史上最大規模を記録。リクエストが5万倍に増幅

2018年2月28日の17時21分〜17時26分の間、GitHub.comがダウンした。

Githubは自社のブログにてダウンした原因がMemcachedからのDDoS攻撃である事を公表した。

同社のブログによると、毎秒1億2690万パケット送信され、帯域幅は1.35Tbpsにも達したという。

同日の17時半ごろに1.35Tbpsに達する攻撃が発生し、18時過ぎに400Gbps程度の攻撃が再度発生している。

f:id:nanashi0x:20180302151210p:plain

(DDoS攻撃の規模を示す画像。GitHubから引用。)

参考リンク(外部URL)

追記：Memcachedに対して打つコマンド

Memcachedに対してリクエストを投げる際は、以下のようなコマンドを実行する。

Test for the Memcached amplification vulnerability on your servers:
$ echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u <target> 11211
— x0rz (@x0rz) March 2, 2018