意識すること
- 列挙は、私たちが持っている、またはすでに発見したデータに基づいて、繰り返し情報を収集するループ
- インフラがどのように設定されているか、そして特定のサービスを提供するためにどのような技術的側面とサービスが必要かを理解する⭕️
- 見つかった認証サービスなどの明白なことに焦点を当て、会社のシステムに無理やり侵入しようとする❌
Our goal is not to get at the systems but to find all the ways to get there.
- (私たちの目標は、システムにたどり着くことではなく、そこにたどり着くためのあらゆる方法を見つけることである。
- 列挙には2つ以上のツールを使用する必要がある
- ツールのプログラミングにより、手動で確認しなければならないさまざまな情報を取得する可能性があるため
- したがって、どのように書かれたかを正確に知らない自動化されたツールだけに頼るべきではありません。
- 重要なのは、「段階的な列挙」「ターゲットの深い理解」「状況に応じた柔軟な思考と工夫」
自問自答すべきこと
- 何が見えるか?
- それを見る理由は何で?
- 私たちが見るものは、私たちにどのようなイメージが見える?
- 私たちはそれから何を得る?
- どうやって使える?
- 何が見えない?
- 私たちが見えない理由は何で?
- 私たちが見ていないものからどのようなイメージが見える?
Principle
- 目に見えるものだけがすべてではない。 あらゆる視点を考慮しろ
- 見えていることと、見えていないことを区別しろ
- 常に情報を得る手段は存在する。 対象をしっかり理解しろ
方法論
列挙は主に3つに分けられる
- インフラベースの列挙
- ホストベースの列挙
- OSベースの列挙
図にするとこんな感じ(Active Directoryインフラストラクチャなどのイントラネットとかは含んでない)
レイヤー | 説明 | 注目すべき部分 |
---|---|---|
1. インターネットプレゼンス | インターネット上の存在感および外部からアクセス可能なインフラの特定 契約の範囲で追加のホストを探すことができる場合、このレイヤーは固定ターゲットのみよりもさらに重要 |
ドメイン、サブドメイン、vHosts、ASN、ネットブロック、IPアドレス、クラウドインスタンス、セキュリティ対策 |
2. ゲートウェイ | 企業の外部・内部インフラを保護するためのセキュリティ対策の特定 到達可能なターゲットのインターフェース、それがどのように保護されているか、およびネットワーク内のどこにあるかを理解する |
ファイアウォール、DMZ、IPS/IDS、EDR、プロキシ、NAC、ネットワークセグメンテーション、VPN、Cloudflare |
3. アクセス可能なサービス | 外部または内部でホストされているアクセス可能なインターフェイスやサービスの特定 特定の理由でインストールされた特定の目的がある |
サービス種類、機能、構成、ポート、バージョン、インターフェイス |
4. プロセス | サービスに関連する内部プロセス、送信元、送信先の特定 | PID、処理データ、タスク、送信元、送信先 |
5. 権限 | アクセス可能なサービスに対する内部の権限および特権の特定 | グループ、ユーザー、権限、制限、環境 |
6. OSセットアップ | 内部コンポーネントおよびシステム設定の特定 | OSの種類、パッチレベル、ネットワーク構成、OS環境、設定ファイル、機密性の高いプライベートファイル |
インフラベースの列挙
対象
- ドメイン、サブドメイン、vHosts、ASN、ネットブロック、IPアドレス、クラウドインスタンス、セキュリティ対策
ドメイン情報
- ドメイン情報は、あらゆる侵入テストの中核要素であり、サブドメインだけでなく、インターネット上での存在全体に関する
- 直接的なスキャンやアクティブスキャンなしで、隠れたまま情報を集めることができる
- 積極的に情報を集めるときは、サードパーティーサービスを使うことでより集められる
- するべきこと
- 最初に会社のメインのウェブサイトを精査すること
- そして、わかったことを念頭に続けていく
オンラインプレゼンス
- 証明書が複数のドメインに使用され、これらがまだアクティブである可能性が高いことを示す
- より多くのサブドメインを見つけるための別のソースはcrt.shを使える
- 証明書の透明性のログ
- 暗号化されたインターネット接続の発行されたデジタル証明書の検証をできるようにする
- Let's Encrypt などの SSL 証明書プロバイダーは、これを Web インターフェイス crt.sh と共有するので、crt.sh に保存されてる。
証明書
- インターネット上での最初のプレゼンスポイントは、私たちが調べることができる会社のメインWebサイトからの
SSL certificate
である可能性がある - 多くの場合、そのような証明書には単なるサブドメイン以上のものが含まれていることがある
curl -s https://crt.sh/\?q\=<DOMAIN>\&output\=json | jq .
正規表現でサブドメインだけも集められる
curl -s https://crt.sh/\?q\=<DOMAIN>\&output\=json | jq . | grep name | cut -d":" -f2 | grep -v "CN=" | cut -d'"' -f2 | awk '{gsub(/\\n/,"\n");}1;' | sort -u > subdomainlist
account.ttn.inlanefreight.com
blog.inlanefreight.com
bots.inlanefreight.com
console.ttn.inlanefreight.com
ct.inlanefreight.com
data.ttn.inlanefreight.com
*.inlanefreight.com
inlanefreight.com
integrations.ttn.inlanefreight.com
iot.inlanefreight.com
サブドメインのリストから、インターネットから直接アクセスできて、会社がホストしているホストを特定できる
for i in $(cat subdomainlist);do host $i | grep "has address" | grep <DOMAIN> | cut -d" " -f1,4;done
blog.inlanefreight.com 10.129.24.93
inlanefreight.com 10.129.27.33
- どのホストをさらに調査できるかを確認したら、
cut
コマンドを少し調整してIPアドレスのリストを生成し、Shodan
やFoFa
で検索実行 - 検索した中で一番空いてるポートが多いものについて考える
DNSレコード
-
DNSからもサブドメインだったりIPを見つけることができる
-
A
レコード:Aレコードを通じて、特定の(サブ)ドメインを指すIPアドレスを認識します。ここでは、すでに知っているものだけを見ることができます。 -
MX
レコード:メールサーバーのレコードは、どのメールサーバーが会社のメールを管理する責任があるかを示します。私たちの場合、これはGoogleによって処理されるので、これをメモして、今のところスキップする必要があります。 -
NS
レコード:これらの種類のレコードは、FQDNをIPアドレスに解決するためにどのネームサーバーが使用されているかを示します。ほとんどのホスティング プロバイダーは独自のネーム サーバーを使用しているため、ホスティング プロバイダーの識別が容易になります。 -
TXT
レコード:このタイプのレコードには、さまざまなサードパーティプロバイダーの検証キーや、SPF、DMARC、DKIMなどのDNSのその他のセキュリティ側面が含まれていることがよくあります。これらの側面は、送信された電子メールの送信元を検証および確認する責任があります。結果を詳しく見ると、ここですでにいくつかの貴重な情報を見ることができます。
snowyowl644@htb[/htb]$ dig any inlanefreight.com
; <<>> DiG 9.16.1-Ubuntu <<>> any inlanefreight.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52058
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;inlanefreight.com. IN ANY
;; ANSWER SECTION:
inlanefreight.com. 300 IN A 10.129.27.33
inlanefreight.com. 300 IN A 10.129.95.250
inlanefreight.com. 3600 IN MX 1 aspmx.l.google.com.
inlanefreight.com. 3600 IN MX 10 aspmx2.googlemail.com.
inlanefreight.com. 3600 IN MX 10 aspmx3.googlemail.com.
inlanefreight.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
inlanefreight.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
inlanefreight.com. 21600 IN NS ns.inwx.net.
inlanefreight.com. 21600 IN NS ns2.inwx.net.
inlanefreight.com. 21600 IN NS ns3.inwx.eu.
inlanefreight.com. 3600 IN TXT "MS=ms92346782372"
inlanefreight.com. 21600 IN TXT "atlassian-domain-verification=IJdXMt1rKCy68JFszSdCKVpwPN"
inlanefreight.com. 3600 IN TXT "google-site-verification=O7zV5-xFh_jn7JQ31"
inlanefreight.com. 300 IN TXT "google-site-verification=bow47-er9LdgoUeah"
inlanefreight.com. 3600 IN TXT "google-site-verification=gZsCG-BINLopf4hr2"
inlanefreight.com. 3600 IN TXT "logmein-verification-code=87123gff5a479e-61d4325gddkbvc1-b2bnfghfsed1-3c789427sdjirew63fc"
inlanefreight.com. 300 IN TXT "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.24.8 ip4:10.129.27.2 ip4:10.72.82.106 ~all"
inlanefreight.com. 21600 IN SOA ns.inwx.net. hostmaster.inwx.net. 2021072600 10800 3600 604800 3600
;; Query time: 332 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mi Sep 01 18:27:22 CEST 2021
;; MSG SIZE rcvd: 940
- DNSサーバーのエントリでしたが、一見するとあまり面白く見えない
- 私たちが今見ることができる核心情報は次のとおり
- Atlassian
- ソフトウェア開発やコラボレーションに利用されるプラットフォーム
- 未経験の場合、無料トライアルで試してみることができる
- Google Gmail
- メール管理で Google が使われていることを示唆
- GDrive 上のフォルダやファイルが共有リンクでアクセス可能になっている可能性もある
- LogMeIn
- リモートアクセスを多角的に管理・制御するための中央ハブ
- 中央集約にはリスクもあり、管理者権限を取得されると全システムや情報へのフルアクセスを許してしまう恐れがある(例: パスワード使い回しによる侵害)
- Mailgun
- メールに関する複数のAPIやSMTPリレー、Webhookなどを提供
- IDORやSSRF、POST/PUTリクエストを悪用した攻撃など、APIインターフェイスの脆弱性に注意が必要
- Outlook
- ドキュメント管理の指標になり得る
- 多くの企業はOffice 365やOneDriveなどを利用し、Azure BlobやFile Storageといったクラウドリソースも活用
- AzureのファイルストレージはSMBプロトコルで動作し、興味深い攻撃対象になる場合がある
- INWX
- ドメインの購入や登録ができるホスティングプロバイダー
- TXTレコードの「MS」値はドメイン所有確認などでよく使用される
- 多くの場合、管理プラットフォームへのログインに使うユーザ名やIDと類似しているケースがある
クラウドにおけるセキュリティ
- クラウドプロバイダーはインフラストラクチャを一元的に保護するが、管理者によって作成された構成は、会社のクラウドリソースを脆弱にすることも多い
- 誤って設定されている場合、認証なしでアクセスできることが多いサービス
S3 buckets
(AWS)blobs
(Azurecloud storage
(GCP)
1. 会社が使用しているクラウドを見つけ出す
- FoFa,Shodanで会社のドメインで検索する
- Google Dorks
intext:<会社名・会社ドメイン> inurl:amazonaws.com
intext:<会社名・会社ドメイン> inurl:blob.core.windows.net
intext:<会社名・会社ドメイン> inurl:storage.googleapis.com
- PDFとか画像とかJSのソースコードも見つかるかもね
- ターゲットウェブサイトのソースコードとかね
2. クラウドだったりドメインの情報を引き出す
- domain.glass
- ドメインやcloudのurlで検索する
- Cloudflareのセキュリティ評価ステータスが「安全」に分類されている
- 以下のなんらかの対策が行われていることがわかる。
- WAF(Web Application Firewall)
不正アクセスや攻撃をフィルタリングし、アプリケーションサーバーを守る - DDoS対策
大量のアクセスによるサーバー障害を防ぐ - CDN(Content Delivery Network)
コンテンツを世界各地にキャッシュし、アクセス速度を改善すると同時に負荷分散を実現する
- WAF(Web Application Firewall)
- 以下のなんらかの対策が行われていることがわかる。
- GrayHatWarfare.
- さまざまな検索によってAWS、Azure、GCPのクラウドストレージを発見し、さらにファイル形式ごとにソートやフィルタリングできる
- そのため、Googleで見つけたストレージをGrayHatWarefareでも検索し、該当のクラウドストレージに保存されているファイルを受動的に把握することが可能
- sshが見つかることもある
- あとは、会社が略語でシステムを構築してることもあるから、それに目を光らせる
- https://leakix.net/
- ここで検索してもある程度わかる
求人や従業員からの漏洩
- SNSや求人からの情報取得
- GitHub
- ファイルの 1 つで、従業員の個人的な電子メール アドレスを検出でき、さらに調査すると、Web アプリケーションにはハード コードされた JWT トークンがあります。
- 従業員
- LinkedInは、コネクション、場所、会社、学校、業界、プロフィール言語、サービス、名前、役職などで分類された、雇用者の包括的な検索を提供する
Metasploit Framework
素晴らしい一枚絵
- エクスプロイトの失敗は、疑われる脆弱性の存在を否定するものではなく、単にMetasploitエクスプロイトが機能しなかったことを示すに過ぎない。
- 多くのエクスプロイトは、対象ホストに合わせたカスタマイズが必要であるため、自動化ツール(Metasploitフレームワークなど)はあくまでサポートツールであり、手動の技術を置き換えるものではない。
Moduleのタイプ
タイプとその説明
- Auxiliary
スキャン、ファズ、スニッフィング、管理などの補助的な機能を提供し、追加サポートを行います。 - Encoders
ペイロードがターゲットに正しく届くように変換処理を行います。 - Exploits
ペイロードの配信を可能にする脆弱性を突くモジュールです。 - NOPs
(No-Operationの略)エクスプロイト実行時にペイロードのサイズを一定に保つ役割を果たします。 - Payloads
リモートでコードを実行し、攻撃者のマシンにコールバックして接続(またはシェル)を確立します。 - Plugins
追加スクリプトがmsfconsoleに統合され、評価作業をサポートします。 - Post
情報収集やさらなるネットワーク内移動(ピボット)のための各種モジュールです。