ハッカーが SQL インジェクションと DDoS で Web サイトを乗っ取る仕組み

ハッカーグループ Anonymous や LulzSec の出来事を大まかにフォローしたことがあるとしても、悪名高い Sony ハッキングのように、Web サイトやサービスがハッキングされたという話は聞いたことがあるでしょう。彼らがどのようにしてそれを行うのか疑問に思ったことはありますか?

これらのグループが使用するツールやテクニックは多数あり、これを自分で行うためのマニュアルを提供するつもりはありませんが、何が起こっているのかを理解するのには役立ちます。彼らが使用しているとよく聞く 2 つの攻撃は、「(分散) サービス拒否」(DDoS) と「SQL インジェクション」(SQLI) です。仕組みは次のとおりです。

画像提供者: xkcd

サービス拒否攻撃

それは何ですか？

「サービス拒否」 (「分散型サービス拒否」または DDoS と呼ばれることもあります) 攻撃は、システム (この場合は Web サーバー) が一度に大量のリクエストを受信し、サーバーリソースが過負荷になり、システムが単にロックされたときに発生します。そしてシャットダウンします。 DDoS 攻撃の目標と成功の結果は、ターゲットサーバー上の Web サイトが正当なトラフィックリクエストに利用できなくなることです。

どのように機能するのでしょうか?

DDoS 攻撃のロジスティクスは、例によって最もよく説明されるかもしれません。

コールセンターをダウンさせて X 社のビジネスを妨害するという目標を持って 100 万人 (攻撃者) が集まっていると想像してください。攻撃者らは、火曜日の午前 9 時に全員が X 社の電話番号に電話するように調整します。おそらく、X 社の電話システムは一度に 100 万件の通話を処理できないため、すべての着信回線が攻撃者によって遮断されることになります。その結果、電話システムが攻撃者からの通話の処理に追われるため、正規の顧客からの通話 (つまり、攻撃者ではない通話) が通じなくなります。したがって、本質的に、X 社は、正当なリクエストが通過できないためにビジネスを失う可能性があります。

Web サーバーに対する DDoS 攻撃もまったく同じように機能します。 Web サーバーがリクエストを処理するまで、どのトラフィックが正規のリクエストからのものなのか、攻撃者からのものなのかを知る方法は事実上ないため、このタイプの攻撃は一般に非常に効果的です。

攻撃の実行

DDoS 攻撃の「ブルートフォース」の性質により、同時に攻撃できるように多数のコンピューターを調整する必要があります。コールセンターの例をもう一度見てみると、すべての攻撃者が午前 9 時に電話をかけることを知っていて、実際にその時間に電話をかける必要があります。この原則は Web サーバーを攻撃する場合には確かに機能しますが、実際の有人コンピューターの代わりにゾンビコンピューターを利用すると、攻撃が大幅に容易になります。

ご存知かと思いますが、マルウェアやトロイの木馬には多くの亜種が存在し、システム上に一旦侵入すると休止状態になり、場合によっては指示を求めて「電話」をかけてきます。これらの指示の 1 つは、たとえば、午前 9 時に X 社の Web サーバーに繰り返しリクエストを送信することです。したがって、それぞれのマルウェアのホームロケーションを 1 回更新するだけで、1 人の攻撃者が侵害された数十万台のコンピュータを即座に連携させて大規模な DDoS 攻撃を実行できます。

ゾンビコンピューターを利用する利点は、その有効性だけでなく、攻撃者が実際に攻撃を実行するためにコンピューターをまったく使用する必要がないため、その匿名性にもあります。

SQLインジェクション攻撃

それは何ですか？

「SQL インジェクション」(SQLI) 攻撃は、貧弱な Web 開発技術を利用したエクスプロイトであり、通常は欠陥のあるデータベースセキュリティと組み合わされます。攻撃が成功すると、ユーザーアカウントになりすますことから、それぞれのデータベースやサーバーが完全に侵害されるまで、さまざまな結果が生じる可能性があります。 DDoS 攻撃とは異なり、Web アプリケーションが適切にプログラムされていれば、SQLI 攻撃は完全かつ簡単に防ぐことができます。

攻撃の実行

Web サイトにログインしてユーザー名とパスワードを入力するたびに、資格情報をテストするために、Web アプリケーションは次のようなクエリを実行することがあります。

SELECT UserID FROM Users WHERE UserName= 'myuser' AND Password = 'mypass' ;
 SELECT UserID FROM Users WHERE UserName= 'myuser' AND Password = 'mypass' ;

注: SQL クエリ内の文字列値は一重引用符で囲む必要があるため、ユーザーが入力した値の前後に文字列が表示されます。

したがって、UserID を返すには、入力したユーザー名 (myuser) とパスワード (mypass) の組み合わせが Users テーブルのエントリと一致する必要があります。一致しない場合、UserID は返されないため、ログイン資格情報は無効になります。特定の実装は異なる場合がありますが、仕組みは非常に標準的です。

それでは、ユーザーが Web フォームに入力した値を置き換えることができるテンプレート認証クエリを見てみましょう。

SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’

一見すると、これはユーザーを簡単に検証するための簡単で論理的な手順のように思えるかもしれませんが、ユーザーが入力した値の単純な置換がこのテンプレートで実行されると、SQLI 攻撃の影響を受けやすくなります。

たとえば、ユーザー名フィールドに「myuser’–」が入力され、パスワードに「wrongpass」が入力されたとします。テンプレートクエリで単純な置換を使用すると、次のようになります。

SELECT UserID FROM Users WHERE UserName= 'myuser' --' AND Password='wrongpass'
 SELECT UserID FROM Users WHERE UserName= 'myuser' --' AND Password='wrongpass'

このステートメントの鍵となるのは、2 つのダッシュを含めることです。

 ( --)

。これは SQL ステートメントのコメント開始トークンであるため、2 つのダッシュ (両端を含む) の後にあるものはすべて無視されます。基本的に、上記のクエリはデータベースによって次のように実行されます。

SELECT UserID FROM Users WHERE UserName= 'myuser'
 SELECT UserID FROM Users WHERE UserName= 'myuser'

ここでの明らかな省略は、パスワードチェックが欠如していることです。ユーザーフィールドの一部として 2 つのダッシュを含めることで、パスワードチェック条件を完全に回避し、それぞれのパスワードを知らなくても「myuser」としてログインできました。クエリを操作して意図しない結果を生成するこの行為は、SQL インジェクション攻撃です。

どのような損害が発生する可能性がありますか?

SQL インジェクション攻撃は、不注意で無責任なアプリケーションコーディングによって引き起こされ、完全に防ぐことができます (これについてはすぐに説明します)。ただし、与えられる損害の範囲はデータベースの設定によって異なります。 Web アプリケーションがバックエンドデータベースと通信するには、アプリケーションはデータベースへのログインを提供する必要があります (これは、Web サイト自体へのユーザーログインとは異なることに注意してください)。 Web アプリケーションが必要とするアクセス許可に応じて、このそれぞれのデータベースアカウントには、既存のテーブルのみの読み取り/書き込みアクセス許可から完全なデータベースアクセスまで、あらゆるアクセス許可が必要になる場合があります。これがまだ明確でない場合は、いくつかの例を見て明確にする必要があります。

上記の例に基づいて、たとえば次のように入力すると、それがわかります。

 "youruser'--" , "admin'--"

または他のユーザー名を使用すると、パスワードを知らなくてもそのユーザーとしてサイトに即座にログインできます。システムに入ると、自分が実際にそのユーザーではないことがわからないため、それぞれのアカウントに完全にアクセスできます。通常、Web サイトにはそれぞれのデータベースへの少なくとも読み取り/書き込みアクセス権が必要であるため、データベースのアクセス許可はこれに対するセーフティネットを提供しません。

ここで、Web サイトがそれぞれのデータベースを完全に制御し、レコードの削除、テーブルの追加/削除、新しいセキュリティアカウントの追加などを行うことができると仮定します。一部の Web アプリケーションではこの種の権限が必要になる可能性があることに注意することが重要です。フルコントロールが許可されることは自動的に悪いことではありません。

したがって、この状況で発生する可能性のある損害を説明するために、上の漫画で提供されている例を使用して、ユーザー名フィールドに次のように入力します。

 "Robert'; DROP TABLE Users ; --".

単純な置換の後、認証クエリは次のようになります。

SELECT UserID FROM Users WHERE UserName= 'Robert' ; DROP TABLE Users ; --' AND Password='wrongpass'
 SELECT UserID FROM Users WHERE UserName= 'Robert' ; DROP TABLE Users ; --' AND Password='wrongpass'

注: SQL クエリ内のセミコロンは、特定のステートメントの終わりと新しいステートメントの始まりを示すために使用されます。

これはデータベースによって次のように実行されます。

SELECT UserID FROM Users WHERE UserName= 'Robert'
 SELECT UserID FROM Users WHERE UserName= 'Robert'

DROP TABLE ユーザー

そのため、SQLI 攻撃を使用して Users テーブル全体を削除しました。

もちろん、許可されている SQL 権限に応じて、攻撃者が値を変更したり、テーブル (またはデータベース自体) をテキストファイルにダンプしたり、新しいログインアカウントを作成したり、データベースインストール全体をハイジャックしたりする可能性があるため、さらに悪いことが行われる可能性があります。

SQL インジェクション攻撃の防止

以前に何度か述べたように、SQL インジェクション攻撃は簡単に防ぐことができます。 Web 開発の鉄則の 1 つは、上記のテンプレートクエリで単純な置換を実行したときのように、ユーザー入力を盲目的に信頼しないことです。

SQLI 攻撃は、いわゆる入力のサニタイズ (またはエスケープ) によって簡単に阻止されます。サニタイズプロセスは、本質的に行うことは、SQL ステートメント内の文字列を途中で終了するために使用できないように、インラインの一重引用符 (‘) 文字を適切に処理することだけであるため、実際には非常に簡単です。

たとえば、データベースで「O’neil」を検索する場合、O の後の一重引用符によって文字列が途中で終了してしまうため、単純な置換は使用できませんでした。代わりに、それぞれのデータベースのエスケープ文字を使用してサニタイズします。インラインの一重引用符のエスケープ文字が各引用符の前に \ 記号を付けていると仮定します。したがって、「O’neal」は「O\’neil」としてサニタイズされます。

この単純な衛生化行為により、SQLI 攻撃はほぼ防止されます。これを説明するために、前の例に戻って、ユーザー入力がサニタイズされたときに結果として生じるクエリを見てみましょう。

 myuser' --

/ 間違ったパス:

SELECT UserID FROM Users WHERE UserName= 'myuser\' --' AND Password='wrongpass'
 SELECT UserID FROM Users WHERE UserName= 'myuser\' --' AND Password='wrongpass'

myuser の後の一重引用符がエスケープされている (つまり、ターゲット値の一部とみなされている) ため、データベースは文字通り次の UserName を検索します。

 "myuser'--" .

さらに、ダッシュは SQL ステートメント自体ではなく文字列値に含まれるため、SQL コメントとして解釈されるのではなく、ターゲット値の一部とみなされます。

 Robert'; DROP TABLE Users ; --

/ 間違ったパス:

SELECT UserID FROM Users WHERE UserName= 'Robert\' ; DROP TABLE Users ; --' AND Password='wrongpass'
 SELECT UserID FROM Users WHERE UserName= 'Robert\' ; DROP TABLE Users ; --' AND Password='wrongpass'