Zenn
🐥

ハッキング学習〜様々な攻撃〜

2023/07/14に公開
Security
ホワイトハッカー
idea

様々な攻撃

Dos攻撃

Denial of service攻撃の略で、サービス不能攻撃やサービス拒否攻撃とも呼ばれます。
サーバー、またはネットワークに過剰なストレスを与え、ユーザーによるシステムリソースへのアクセスを低下、制限、阻害することにより、ターゲットに経済的損失や信用失墜を与えることを目的としています。

Dos攻撃の種類

Dos攻撃には帯域幅を消費させるものとシステムリソースを消費させるものの2種類があります。
基本的に工夫などはなく、通常のリクエストパケットを送ります。しかし、一般的にはエンタープライズ仕様のサーバーやネットワークに対してパフォーマンスに影響が出るほどのパケットを個人のPCから送りつけるのは難しいです。

「俺のPCひとつであの憎きサービスを停止に追い込みたい。。」

そんな哀しい願いを叶えるために先人兄貴たちは送信するパケットや送信する方法を工夫する手法を考えました。

帯域幅消費系

SYN-flood攻撃
TCPの3wayHandShakeを悪用した手法。
接続先ホストはSYNフラグを受け取ると、SYN/ACKフラグを返し、接続テーブルを用意します。
この接続テーブルは接続元からACKフラグが返ってくるまで一定時間保持されます。これを利用します。
ここでACKフラグを返さず、テーブルが消去される前に異なるIPアドレスから新しい接続要求（SYNフラグ）を出し、新たに接続テーブルを作成させます。
これをすばやく何回も繰り返すことにより、やがて新しい接続テーブルが作成できなくなり、一般ユーザーのサービス利用を阻害することができるというわけです。

増幅系攻撃
偽装したIPアドレスにより、特定のネットワーク内での応答を増幅させる手法。
外部ネットワークから、ターゲットのネットワーク内部の全てのマシンにpingを打ちます。この時、送信元を境界ルーターの内部向けのIPアドレスに偽装しておきます。
するとpingの返答の全てが境界ルーターに送られることになるため、ハッカーは1つのパケット通信を行うだけで、ネットワーク内部に500くらいのパケットの応答を起こすことが可能となります。

システムリソース消費系

Ping of Death
65,535byteを超えるサイズのpingを送りつけます。以前は65,535byteを超えるサイズのpingを受け取るとサーバーがHungUpする設定があったようです。

E-mail bombing
サイズが大きなメール（添付含む）でメールサーバーのリソースを消費させます。
メールサーバーをダウンさせることができる場合があります。

WinNuke
139/tcpにOOB(Out Of Bounds)を送ります。古いWindowsの場合はHungUpする場合があるようです。

ただ、これらの手法は現在は対策されており、また、工夫したが故に特徴があり、侵入検知に簡単に引っかかってしまいます。

DDos攻撃

Distributed Denial Of Service Attack攻撃の略で、分散型サービス攻撃とも呼ばれます。
送るパケットは工夫せずに、複数のマシンから同じターゲットにタイミングを合わせて送りつけることで大量の帯域消費を狙います。
パケットの中身自体に攻撃性が無いのがこの攻撃の厄介なところで、検知されない他、止めることもできません。

「戦いは数だよ兄貴。。」

流れは次の通り。

  1. 攻撃しやすいマシンにアクセスして、ボット[1]をしこむ
  2. それをいくつものマシンに行う
  3. ハンドラ[2]と呼ばれるツールを使い、ボットに一斉に指示をおくり、ターゲットを攻撃させる

攻撃者は直接ターゲットと通信しないため、追跡されにくいという特徴があります。隠れている獣の巨人のようなものです。

また、DDos攻撃の派生としてDRDos攻撃という手法があります。

DRDos攻撃

Distributed Reflection Denial of Service攻撃の略で、分散型反射サービス拒否攻撃とも呼ばれます。
DDosの手法とIPスプーフィングの複合技で、中間標的にターゲットのIPでリクエストを行い、そのレスポンスをターゲットに集中させることで攻撃します。この時、ターゲットからは中間標的が攻撃元に見えます。

流れは次の通り。

  1. 攻撃しやすいマシンにアクセスして、ボットをしこむ
  2. それをいくつものマシンに行う
  3. ハンドラと呼ばれるツールを使い、ボットに一斉に指示をおくり、中間標的を攻撃させる
  4. この時、ボットの送信元IPアドレスをターゲットのものとする
  5. 大量のレスポンスがターゲットに向かう

ターゲットに向けて攻撃を中間標的に反射させるというわけです。（サテライトキャノンかな）

昨今のDDos系攻撃の特徴として、組織化による大規模化が挙げられます。
犯罪組織、テログループ、特定国家などがDDos攻撃を行うグループを支援するわけです。

Dos攻撃の活用

Dos攻撃にはパケットを工夫したが故に特徴があり、侵入検知に簡単に引っかかってしまうという特徴がありました。このことを逆手に取り、サービス不能にする以外の用途にも利用できます。

・　敢えて発見させることでアラートを出しまくり、愚かな監視者が監視レベルを下げることをワンチャン狙う
・　アラートを出しまくらせ、本命の威力のある攻撃を裏で通すためのカモフラージュに使用する
・　攻撃の跡を残すことにより、調査の手間を増やす嫌がらせをする
・　ログに残ることを逆手に取り、外部からログを塗りつぶす手段として使用する

このように色々と悪用できる手法なのです。

Dos系攻撃は発見されてしまうことが前提なので、行う際はIPスプーフィングが重要となります。
また、追跡の手間を増やし、混乱させるために内部IPを利用するのかそれともグローバルIPを利用するのかその時々によって使い分けましょう。（やってはいけません）

Webアプリケーション攻撃

Webアプリケーションとは

WebサービスにおけるWebサーバーとユーザーのインターフェースのこと。ユーザーはWebアプリケーションを介してWebサーバーと通信しています。
便利で誰にでも使いやすい形で提供されますが、その分セキュリティの面では色々大変なのです。

Webアプリケーションのセキュリティ

Webアプリケーションのセキュリティを取り巻く環境には以下のような特徴があります。

  1. 一般への公開が目的のため、アクセス制限やポートの制御などのアクセス制御が難しい。
  2. HTTP自体が古い技術のため、セッションや暗号化は開発者が実装する必要がある。
  3. ユーザーからの入力をパラメータとして使用するため、信頼性のないデータを入力するリスクがある。また、ブラウザやJavaScriptの脆弱性も考慮する必要がある。
  4. 個人情報や金融取引情報など、損害や信用失墜につながる重要な情報を扱うことが増えている。
  5. 攻撃者のリターンが大きくなっているため、攻撃方法が進化している。
  6. 脆弱性のほとんどは開発者の実装ミスによるものである。

元々はサーバーにあるファイルを閲覧する用途の技術を使っているわけですから、まぁ色々とあるわけです。

Webアプリケーションの脆弱性

よくある代表的な脆弱性には以下のようなものがあります。

入力時やプログラム内での使用時の検証、サニタイズミス
ユーザーからの入力値や環境変数、データベースやファイルから再利用する値をプログラムで利用する際の検証を行わない、もしくは不適切であるという脆弱性。入力値をSQLに含める時のミスもこれに当たります。
ほぼ全ての攻撃がこの脆弱性に起因すると言われています。
-> ヘッダインジェクション[3]、OSコマンドインジェクション[4]、SQLインジェクション、ディレクトリトラバーサル[5]、オープンリダイレクト[6]、クロスサイトスクリプト

表示時の値のサニタイズミス
ユーザーからの入力値をHTMLに含める際に適切なサニタイズを施さない脆弱性。
-> クロスサイトスクリプト

エラー情報の表示設定ミス
エラー表示設定のミスにより攻撃に有効な情報が露出してしまったり、不適切なエラーメッセージにより列挙が可能になってしまうことがあります。脆弱性とは少し違いますが、これもよくある実装のミスです。
-> サーバーのフットプリンティング、SQLインジェクション、有効なログインアカウントの列挙

サニタイズ処理は現代はフレームワークがやってくれることも多いですが、常に意識は必要です。

Webアプリケーションへの攻撃準備

基本的な偵察やスキャニングは終えている前提で、改めてWebアプリケーションからわかる情報を集めてみましょう。

URLを見てみる

https://www.abcde.jp/topic.aspx?date=20191213&sort=desc
これだけでも以下のような情報が収集できます。
https: SSLの使用
aspx: Aspxで開発。WebサーバーはIIS
sort=desc: 並べ替えの語句がDBに直接使用されている可能性

404エラーページやその他エラーページにアクセスしてみる

初期状態だとWebサーバーがデフォルトで用意している404画面に遷移しますが、その際バナー情報が表示されます。これも貴重な情報源です。

SSL証明書を見てみる

SSL証明書の中には、企業情報などが入っている場合があります。

隠されたコンテンツを見てみる

例えばクローラー向けのrobots.txtの中にディレクトリ構成が書いてあったりします。

エントリーポイントを触ってみる

APIのエントリーポイントはJSから簡単に確認することができます。また、リクエスト時のパラメータやパラメータがアプリケーションに与える影響、レスポンスのエンコード状況の確認（<が&lt;にエンコードされてるなぁなど）を行うことで攻撃に繋がりやすい情報を得ることが可能です。

この際に役にたつのがBurpSuite Proxyというツールです。
BurpSuite Proxyは
・ブラウザからのリクエストを送信前にインターセプトし、表示する。また、パラメータの変更もできる
・サーバーからのレスポンスをブラウザに表示する前にインターセプトし、表示する
などの機能をもったリバースプロキシ[7]で、これを利用すると、httpリクエストのパラメータの内容を確認、変更することができます。（ググると使い方を説明したページがたくさん出てきます）

このようにして収集した情報から、攻撃方法の選択、攻撃文字列の考察、実証方法の検討などを行い、実行に移します。

代表的な攻撃手法
クロスサイトスクリプト

ユーザーが入力した値をレスポンスに含めるとき、「タグ」や「スクリプト」をそのまま表示する脆弱性を利用したクライアントサイド攻撃。

想定される被害
・HP改ざん
・フィッシングサイトへの誘導
・セッションIDの盗難

特徴
レスポンスの場所によって有効な攻撃文字が異なる。

攻撃方法
任意のスクリプトがアプリケーション内で実行されるように、inputなどに仕込む。

例
以下のように入力値{$str}がレスポンスされたとします。

入力値：{$str} ①
<input type=”text” value=”{$str}”> ②
<input type=”button” onclick=document.getElementById(“msg”).innerHTML=”{$str}”> ③
<input type=”button” onclick=checkStr2({$str})> ④
<script>
function checkStr(){
var str = ‘{$str}’; ⑤
document.getElementById(‘msg’).innerHTML=str;
}
</script>

それぞれに有効な文字列は以下のようになります。
① 本文
<script>alert(document.cookie)</script>
<img src=”x” onerror=alert(document.cookie)>
② タグ内の値
“><script>alert(document.cookie)</script>
“onclick=alert(document.cookie)+”
③ タグ内のイベントの値
“;alert(document.cookie)+”
④ タグ内のイベントの引数
);alert(document.cookie
⑤ JS内
‘;alert(document.cookie);//

scriptタグを使わなかったりと、様々な書き方がありますが、結局はレスポンスの場所でJSを動かす書き方を考えれば良いわけです。

対策
一般的な対応策はサニタイズ（無害化、出力文字のエンコード）です。一般的に<>'"&の5文字をサニタイズすればいいと言われています。しかし、④を防げないように、これだけでは不十分な場合もあります。
また、特定の言語のエンコード関数で、デフォルトだとシングルクォーテーションをサニタイズしてくれないことがある罠などもありますので、注意が必要です。

SQLインジェクション

ユーザーが入力した値を適切に検証せずに、プログラムが発行するSQL構文の中に含めてしまう脆弱性を利用したDBへの攻撃。

想定される被害
・認証突破
・機密情報の漏洩
・データの改ざん
・その他あらゆるセキュリティ要素の侵害

特徴
DBを操られてしまうので、被害が重大になりやすい。

攻撃方法
任意のSQLがサーバー内で実行されるように、inputなどに仕込む。

例
認証を突破してみましょう。次のようなSQL構文があるとします。
SELECT * FROM users WHERE user_id=’ユーザーID’ AND password=’パスワード’
これにID：‘ OR 1=1 –、パスワード：なしのように入力をすると、、、
SELECT * FROM users WHERE user_id=’‘ OR 1=1 –’ AND password=’’
↓
SELECT * FROM users WHERE user_id=’‘ OR 1=1（–以降はコメントなので）
これで認証を突破できてしまうのです。

認証突破以外だと
UPDATE users SET password=’パスワード’ WHERE user_id=’ユーザーID’
これにID：‘ OR 1=1 –、パスワード：なしのように入力をすると、全てのユーザーのパスワードがTESTになるというやばいことが起こります。

また、WAF[8]突破の方法としては、単純に「2=2」としてみたり、「=」を見ている場合は
「7 > 1」や「5 BETWEEN 1 AND 7」など、他の方法でいけたりします。

脚注

  1. Robotの略で、ここではDDos攻撃を行うように設定されたプログラムのことを指す。外部からの指令、もしくは定められたトリガで動作する。 ↩︎

  2. ここでは複数のボットをコントロールするプログラムのことを指す。攻撃者はハンドラを通してボットに指令を出す。 ↩︎

  3. https://www.ipa.go.jp/security/vuln/websecurity/http-header.html ↩︎

  4. https://www.ipa.go.jp/security/vuln/websecurity/os-command.html ↩︎

  5. https://www.ipa.go.jp/security/vuln/websecurity/parameter.html ↩︎

  6. https://www.mbsd.jp/research/20220526/open-redirect/ ↩︎

  7. インターネットとWebサーバーの間に置かれるプロキシサーバー（代理サーバー）のこと。クライアント（もしくは内部ネットワーク）とインターネットの間に置かれるフォワードプロキシとインターネットへ接続する方法が逆であるため、リバースプロキシと呼ばれる。フォワードプロキシが内部ネットワークを守るのに使われるのに対し、リバースプロキシはwebサーバーを守るのに使われる（主な用途はwebサーバーの負担軽減ではあるが）。 ↩︎

  8. Web Application Firewallの略。ファイアウォールはネットワークレベルでのアクセス制限に使われるが、外部に公開する必要のあるWebアプリケーションに用いるわけにはいかない。そこで使われるのがWAF。簡単に言えば、攻撃パターン（シグネチャと呼ばれる）を覚えさせて該当するアクセスを弾くというもの。（逆に安全なパターンを覚えさせてそれ以外を弾く方式もある）。 ↩︎

Discussion