最近、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

準備が9割

gamzatti
Vote 0 Votes

先日主催した日米協働のサイバー演習が非常に好評だったとのこと。

https://www.meti.go.jp/press/2019/09/20190912009/20190912009.html

私達は特に、特出したな能力を持っている訳ではないけれど、それなりに実績を挙げて来られているのは、入念な準備だと思う。

既にノウハウを持っていたり、何回か繰り返したものであっても、準備は気を抜かずに入念に行うようにしている。

"準備が9割"は、真実。

準備が完璧なら、本番にどんな予測不可能な事態が起きても、頭が真っ白になっても、何とかなる。

執筆記事その2

gamzatti
Vote 0 Votes
レコメンドとはどんな意味?会話での使い方や英語の例文もまとめて紹介!

https://kuraneo.jp/posts/1215

来週はBlack hat USA

gamzatti
Vote 0 Votes

来週はいよいよBlack hat USA。

昨年Europeで発表した時も感動したけれど、やはりUSAでの発表は特別感がある。

今回発表するネタは、Europeが終わってすぐ、私たちの公演を聞いてくれた人からのコメントを

参考に、検証を開始した。

最初は色々苦戦し、冬休みの半分くらいをそれに費やしたりもしたけれど、

その成果があったなと改めて感じる。

よく、"忙しくて時間がない"という言葉を聞くけれど、私はこの言葉を口にしてしまったら

負けだと思っている。

これは単なる言い訳で、時間なんて、忙しくても作ろうと思ったらいくらでも作れる。

1日30分でも、コツコツやれば必ず成果は出る。

来年は社会人ドクターになる予定。

高い壁は見えているけれど、頑張りたいと思う。

そして、プレゼンターとして参加するラスベガスが今からとても楽しみ。

執筆記事その1

gamzatti
Vote 0 Votes

一区切り

gamzatti
Vote 0 Votes
出向して2年目の仕事が無事ひと段落。
安堵と寂しさと充実感が混ざった様な、不思議な気分です。
人の繋がりの大切さを改めて実感した2年間でした。
7月には次の仕事がまた始まるけれど、この1週間は束の間の研究に没頭できる時期。
明日から1週間、名古屋へ行ってどっぷり検証してきます
プライベートで最近勉強しているのが量子コンピュータ。
すぐに実用できるものではないけれど、知っていて損はしないはず。
後、斬新な発想だし、将来があっていいなと。
とは言いつつ、いきなりAPIの使い方に苦戦していて、まだまだ道は遠そう(笑)

目標叶ったり

gamzatti
Vote 0 Votes
ずっと目標としていたBlack hat USAのarsenal(デモ展示)に採択されました。
昨年度、Europeで発表した検知ツールの改良版になります。
Real-Time Detection Tool of High-Risk Attacks Leveraging Kerberos and SMB
Black hat USAは最先端のテクニカルなセキュリティカンファレンスなこともあり、 最新の技術を使った内容が発表されることが多い印象ですが、この内容は、 最新の技術を使っていたり、手法自体が目新しい訳ではありません ただし、内容はとても実用的で良い研究だと思っているので、採択されたことを感謝し、 実りのある発表にしたいです。 研究歴は浅いなりに、この2年間研究を続けてきて思うのは、手法自体が全く新しいものでなくとも、以下のような条件をクリアしていれば、学会やカンファレンスに注目される可能性があるということ。
  • 概念的な手法自体は既知だが、具体的な実装方法が公開されていない
  • 既存の技術やソフトウエアなどを組み合わせて、改良した手法(システム実装に近いかもしれません)
  • 実用的であるもの
後、私たちの基本コンセプトとして、先ず検証ありきの研究をしています。 実際、手を動かして見えてくるものもたくさんありました。改めて手を動かすことの重要性を実感する毎日です。