HULKって何？ - HTTP Unbearable Load King?

HULKって何？ 

HULKは、HTTP Unbearable Load Kingの略で、Webサーバに対する分散型DDoS攻撃ツールです。主に研究目的で設計され、ペンテスターがサーバの耐性を確認するための助けとなります。これにより、セキュリティ専門家はDDoS対策の弱点を見つけ、実際の攻撃者がそれを悪用する前に改善することが可能となります。

‍

歴史

サイバーセキュリティ専門家のBarry Shteiman（現BlastRadiusのCTO）は、2012年5月にHULKを作成しました。多くのペンテストツールが予測しやすい負荷パケットやHTTP SYNリクエストを生成するため、セキュリティ専門家が組織の本当の防御能力を評価できないことに不満を抱いたBarryは、DDoS攻撃のテスト用にこのPythonスクリプトを書きました。その目的は、より実際に近い攻撃を仕掛け、サーバの実際の耐性を試すことにあります。

‍

HULKの動作原理

HULKは一般的なペンテストツールや攻撃スクリプト、脆弱性悪用手法とは大きく異なります。HULKは1つのホストから不規則な間隔で多数のユニークなリクエストを発信します。そのため、単にDDoS攻撃を実行するのみならず、ネットワークの防御機構が攻撃パターンを推測しにくいよう仕向けています。このため、トラフィックやパケットのフィルタリングが非常に困難となります。

さらに、このツールにはリファラの難読化や実際のエージェントの隠蔽など、複数の機能が搭載されています。

次に、HULKウェブサーバツールの動作をまとめます:

• HULKはターゲットサーバに対して連続してユニークなリクエストを送信します。これにより、サーバのリソースを使い果たし、ダウンさせようと試みます。こうしたリクエストがサーバの同時接続上限に達すると、正当なユーザのリクエストが処理されなくなります。
• 各リクエストは多様な性質を有しており、キャッシュ機構、侵入検知システム、その他のフィルタリング機構を回避することが可能です。
• Shteimanは、4GB RAM搭載のMS IIS7サーバでテストを行い、スクリプトにより被攻撃サーバが1分以内にダウンすることを確認しました。このテストでは、すべてのリクエストが同一ホストから送信されました。
• 攻撃速度を向上させるには、複数のノードを使用し、クライアント側のリソースを大幅に投入する必要があります。

HULKで使われる技法

1. 難読化（クライアント情報）

HULKは、既知のUser Agentリスト（次のセクションを参照）を活用してリクエストを難読化します。生成される各リクエストごとにランダムなUser Agentが選ばれるため、侵入防止システムが異常を検知しにくくなっています。

2. 持続接続

HULKは、複数のキープアライブ接続を試みます。これらの接続継続時間はそれぞれ異なり、結果として多数のHTTPリクエストを開き、利用可能なリソースを占有し続けることに成功します。

3. リファラ偽造 

HULKは、リファラ情報を難読化して偽造します。あらかじめ指定された主要なウェブサイト、またはホスト自身を示す場合があります。

4. キャッシュ無効

HULKはユニークなリクエストを生成するのみならず、ターゲットHTTPサーバに対してキャッシュ無効を適用します。これにより、専用のキャッシュソリューションの背後にあるサーバでも、より迅速にダウンさせることが可能です。

5. ユニークなURL変換

各リクエストごとにユニークなURLを生成することで、キャッシュツールやその他のフィルタリング・最適化機構を回避できます。この機能により、ほとんどの場合、サーバは200（OK）の応答を返します。

‍

HULKの技術的詳細 - 簡単に解説

観察ポイント1

もしHulk.pyスクリプトを確認すると、random.randint関数が何度も使用されていることが分かるでしょう。例えば、以下のリクエスト生成部分をご覧ください:

request = urllib2.Request(url + param_joiner + buildblock(random.randint(3,10)) + '=' + buildblock(random.randint(3,10)))
        request.add_header('User-Agent', random.choice(headers_useragents))
        request.add_header('Cache-Control', 'no-cache')
        request.add_header('Accept-Charset', 'ISO-8859-1,utf-8;q=0.7,*;q=0.7')
        request.add_header('Referer', random.choice(headers_referers) + buildblock(random.randint(5,10)))
        request.add_header('Keep-Alive', random.randint(110,120))
        request.add_header('Connection', 'keep-alive')
        request.add_header('Host',host)

観察ポイント2

以下のスクリプト部分を確認すると、HULKがどのUser Agentを利用しているかがわかります.

'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090913 Firefox/3.5.3'
'Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)'
'Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)'
'Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.1) Gecko/20090718 Firefox/3.5.1'
'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.1 (KHTML, like Gecko) Chrome/4.0.219.6 Safari/532.1'
'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; InfoPath.2)'
'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729)'
'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Win64; x64; Trident/4.0)'
'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; .NET CLR 2.0.50727; InfoPath.2)'
'Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)')
'Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)'
'Opera/9.80 (Windows NT 5.2; U; ru) Presto/2.5.22 Version/10.51'

観察ポイント3

HULKは通常のTCPハンドシェイクからHTTPフラッディング攻撃を開始します。まずSYNリクエストが送信され、次にSYN ACK、そしてACKが続きます。

最初のリクエストが障害を突破すると、User Agentは対象URLへ多様なHTTP GETリクエストを送信し始め、ランダムな接尾辞を利用します.

観察ポイント4

ホストは、異なる／ランダムな接尾辞を付与した複数のHTTP GETリクエストを送信し、200（OK）の応答を受け取ります.

観察ポイント5

以下のHULK統計を確認すると、このツールが非常に効率的であることが理解できます。その効率は、クライアント側のリソースや使用するノード数に比例し、攻撃は実際に8.818秒以内で終了（成功）することもあります.

‍

結論

セキュリティ専門家、ペンテスター、または組織のサイバーネットワーク管理を担う方にとって、HULKはテストに欠かせないツールです。確実に難しい状況を引き起こし、ネットワークのセキュリティ強化に寄与するでしょう。しかし、好奇心からHULKをサイバー犯罪や実際の攻撃目的で利用しようと考える場合は、ツール作成者がその悪用を禁じている点に十分留意してください。結果や問題については、使用者自身の責任となります。