October 2019 Archives

最近、Webアプリケーションに対する攻撃として、SSRFが話題になっており、

Black hatなどのカンファレンスネタになっていることも多いです。
CSRFはご存知の方も多いと思いますが、SSRFは話題になっている割に、分かりやすく解説しているサイトが少ないので、取り上げてみます。

SSRFは端的には、ユーザの入力を元に、サーバサイドプログラムから別のサーバへリクエストを送信しているプログラムを踏み台として悪用し、
ユーザから本来アクセスできないサーバに対してアクセスを試みる攻撃です。

なお、"Forgery"とは"偽装する"という意味で、
・CSRFでは、正規のユーザのセッションを悪用して、リクエストを偽装する
・SSRFでは、正規のサーバサイドプログラムを悪用して、別サーバへのリクエストを偽造する
という意味になります。

"サーバサイドプログラムから別のサーバへリクエストを送信しているプログラム"とは、
サーバサイドプログラムが自身がクライアントとなってリクエストを送信しているプログラムを指します。

これは、HTTPリダイレクトやwebフォームのサブミットによるリクエストとは全く別の仕組みであることに注意が必要です。
HTTPリダイレクトやwebフォームは、あくまで送信元はWebクライアント(ブラウザ)なのに対し、SSRFの対象となるのは
Webサーバ自身が送信元(クライアント)となっている点が異なります。

通常のアプリケーションではあまり実装しないかもしれないですが、
ポータルサイトやブログを作成する様なソフトウエアであれば、プレビュー機能や、ポートレットへ別コンテンツを表示する機能などを実装するために
使われることがあります。
(私自身もポータルサイトの基盤ソフトを開発している際に、Webページ内に別のWebページを表示する機能を開発した時に使いました)

具体的な攻撃の仕組みです。

通常時:
・ユーザ(クライアント):インターネット
・フロントのWebサーバ:DMZに存在
・バックエンドのWebサーバ:内部ネットワーク上に存在
・その他、内部向けのサーバ:内部ネットワーク上に存在

アクセスコントロール:
インターネット --deny--> 内部ネットワーク
DMZ --allow --> 内部ネットワーク

1)ユーザがプレビュー機能で、プレビューしたいコンテンツを指定すると、プレビュー用のURLが生成され、URLがフロントのWebサーバにリクエストパラメータとして送信される
2)フロントのWebサーバは、リクエストパラメータで指定されたURL(バックエンドのWebサーバ)に送信される
3)バックエンドのWebサーバでコンテンツを生成してフロントのWebサーバに返却
4)フロントのWebサーバはプレビュー結果を表示

攻撃:
攻撃者がフロントのWebサーバに対し、バックエンドのWebサーバの管理画面や、その他、内部向けのサーバのコンテンツのURIをリクエストパラメータとして送信した場合、
3)で意図したURLであるかのチェックを行っていない場合は、DMZから内部ネットワークへの通信が許可されているため、
本来インターネットからアクセスできないコンテンツが閲覧できてしまいます。

以下は、SSRFの対策として有効と考えるものです。
・サーバサイドプログラムで受け取ったURL(プロトコル、ホスト部など)が意図したものであるか、チェックを行う
・プロトコル、IPアドレス単位でアクセスコントロールを適用する
・更に、Webサーバのアクセス制御機能などを利用して、管理画面などにコンテンツ単位でアクセス制御を行う

今まで、HTTP/HTTPSを利用するデータの持ち出しに主に着目し、紹介してきましたが、DNSクエリを悪用するデータの持ち出しを行うマルウエアもそれなりに観測されているそうです。

https://gblogs.cisco.com/jp/2016/07/detecting-dns-data-exfiltration-html/

https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html

DNSクエリの悪用を検知する観点では、DNSのクエリログを残しておくことも有効と言えそうです。

DNSクエリの悪用例をとてもシンプルに説明すると、以下の様になります。

・被害端末:攻撃者が既に侵害し、リモートコントロールしている端末

・組織のキャッシュ DNSサーバ:被害端末が参照している自組織のDNSサーバ

・攻撃者のDNSサーバ:example.comのドメインを管理しているとします

1)持ち出したいデータ(file1)を分割し、base64などでエンコードする(このデータをdata1-Nとする)

2)攻撃者は、被害端末上で、組織のキャッシュ DNSサーバに対して、以下の様な名前解決要求を送信する

{data1}.file1.example.com

{data2}.file1.example.com

...

3)上記のFQDNは実際には存在しないが、example.comは攻撃者が管理するドメインなので、名前解決要求は組織のDNSを経由して、攻撃者のDNSサーバに転送される。結果、情報が流出するという仕組み。

上記の手口だと、攻撃のDNSクエリは組織のキャッシュ DNSサーバを経由して転送することが可能なため、

ファイアウォールなどで、攻撃者のDNSサーバからのみ、DNSリクエストを許可していたとしても、迂回されてしまう可能性があります。

組織のキャッシュ DNSサーバのクエリログを取得していると、エンコードされたデータを含む異様に長い名前解決要求が残るため、

攻撃を検知できる可能性があります。

これらの攻撃をAIで検知する研究もある様です。

http://www2.ee.unsw.edu.au/~hhabibi/pubs/conf/19im.pdf

Silver Ticketについて

gamzatti
Vote 0 Votes

この連休は台風で身動き取れなかったこともあり、PCの前にいる時間が長い気が(笑)

Silver Ticketについての追加情報です。

Silver Ticketは特定のサービスに対する不正なService Ticketですが、これを無効にするには、

Service Ticketが作られた対象のサービスを起動させているアカウントのパスワードを二回変更する必要があります。
厳密には、ここでいうサービスとは、Service Principal Name(SPN)のことです。
SPNは、クライアントがサービスのインスタンスを一意に識別するための名前のことで、各サーバで利用できるSPNの一覧は以下のコマンドで確認できます。
setspn {アカウント名}
例:コンピュータアカウントDC$が動かしているSPN一覧を表示する
setspn DC$

サービスを動かしている代表的なアカウントとして、コンピュータアカウントを紹介していましたが、
以下によると、コンピュータアカウントが実質ほぼ全てのサービスを動かしているそうです。
https://blog.stealthbits.com/impersonating-service-accounts-with-silver-tickets

ですので、管理者が手動でSPNの登録を行なっていない場合は、Silver Ticket対策としてはコンピュータアカウントのパスワード変更で
大部分はカバーできるのではと考えます。

新しいバージョンのwindows(10や2016)に対する攻撃手法についてまとめてみます。

新しいバージョンでは、セキュリティ機能が強化されていることで、以下のような点で攻撃しづらくなっています。

・10/2016ではメモリに認証情報が残らなくなっているので、メモリから認証情報を窃取する攻撃は受けづらい

・MS14-068の攻撃コードは、10/2016で動作するものは、現時点では確認していない

しかし、一旦ドメイン管理者権限を取られてしまうと、Golden Ticketなどのバックドアを作られる可能性があり、

基本的には古いバージョンと同じ方法で攻撃することができます。

・Golden/Silver Ticketは、古いバージョンのwindowsと同じ方法で作ることができる

・ 端末の管理者権限を取られて、ウィルス対策ソフトやdefenderを無効化されてしまうと、mimikatzを使ってGolden/Silver Ticketをメモリに展開し、使用することが可能

したがって、新しいバージョンのwindowsを使っていたとしても、以下の様な状況の場合は、攻撃を受ける可能性が高いと言えます。

・パッチを適用していない

・ビルドが古いバージョンを使っている

検知手法や対処は古いバージョンと同じです。

・イベントIDの体系は、大きく変わっていない

・Golden/Silver Ticketを無効化するための対策も、同じ

ただし、Golden Ticketを作られてしまうと、単一のイベントでは検知が難しいので、複数のイベントを俯瞰的に見る必要があります。

参考:

https://www.blackhat.com/eu-18/briefings/schedule/index.html#real-time-detection-of-attacks-leveraging-domain-administrator-privilege-13100

https://github.com/sisoc-tokyo/Real-timeDetectionAD

なお、Golden/Silver Ticketを確実に見つけるためには、イベントログだけでは難しく、kerberosのパケットを見る必要があります。

https://www.blackhat.com/us-19/arsenal/schedule/index.html#real-time-detection-tool-of-high-risk-attacks-leveraging-kerberos-and-smb-16707

https://github.com/sisoc-tokyo/Real-timeDetectionAD_ver2

端的には、ドメインコントローラから発行されていないTGTやSTを見つけることです。

Golden/Silver Ticketを見つけられるセキュリティ製品(ATAなど)も、おそらく似た様なロジックを使っていると思われます、

https://docs.microsoft.com/ja-jp/advanced-threat-analytics/what-is-ata

About this Archive

This page is an archive of entries from October 2019 listed from newest to oldest.

September 2019 is the previous archive.

November 2019 is the next archive.

Find recent content on the main index or look in the archives to find all content.