Browser Exploitation とか MITB とかに関しての雑な記事
目次
前書き
実は最近ブラウザハックという書籍を読み進めています。
なので、今回はそれに関連して Browser Exploitation や MITB 攻撃などに関して少し書いてみようかと思います。
しかし、まだ学習中の身なのでこの記事の内容のすべてが正しいとは限りません。
そのため記事の内容は鵜呑みにせず、信頼できる他のソースも探して参照していただけると幸いです。
※注意
許可の無い環境に対する攻撃は犯罪です。絶対に許可の無い環境に対して攻撃を行わないでください。
今回行った攻撃の流れや環境
今回は Web サーバ、被害者のマシン、そして攻撃者のマシンである3つの仮想マシンを作成して色々と試してみました。
それぞれ以下のようなものになっています。
またWeb サーバには以下の2つのサイトを用意しました。
今回行った攻撃の流れとしては以下のようになります。
- 攻撃者が Stored-XSS のある Web サーバに被害者のブラウザを hook （被害者のブラウザを制御下に置くといった意味？）するためのコードを挿入する。
- 被害者が脆弱なサイトにアクセすることで被害者のブラウザが hook される（攻撃者の制御下に置かれるといった意味？）。
- 攻撃者が被害者のブラウザに対して攻撃コードを送信。
- 被害者のブラウザで攻撃コードが実行される。
図で表すと図1のようになります。
実際に行った攻撃
それでは実際に攻撃を行ってみます。
悪意あるコードの挿入
まず初めに被害者のブラウザを hook するための悪意のあるコードを show.php に挿入しましょう。
図1 だと 2 列目に悪意のあるコードが挿入されています。
BeEF というツールを使用すると攻撃者のマシンの 3000 番ポートに BeEF のサーバが立ちます。
そのため、被害者のブラウザをhook する際は BeEF のサーバにある hook.js にアクセスさせればよいです。
被害者のブラウザを hook する
次に被害者のブラウザにに先ほど挿入したコードを実行させましょう。
そのために被害者に shop.php に訪れてもらいました。
すると攻撃者のマシンで BeEF を用いて被害者のブラウザが hook されたことが確認できます。
悪意あるコードの送信と実行
それでは悪意のある攻撃コードを被害者のブラウザで実行させましょう。
今回はBeEFというツールを使用して Petty Theft という攻撃を行いました。
今回は facebook のログイン画面を表示し、ユーザ名とパスワードを被害者に入力させます。
BeEF の Pretty Theft モジュールを実行すると被害者にユーザ名とパスワードの入力を促す画面が表示されます。
今回はユーザ名とパスワードの両方に test という値を入力して Log In をクリックしました。
すると攻撃者の BeEF 上で入力された値を確認することが出来ました。
結局 Browser Exploitation とかって何？
今回行った Pretty Theft 攻撃を見ても一体 Browser Exploitation の何が危険なのかわかりにくいですよね。
XSS と何が違うのかといった疑問をもった方もいるのではないでしょうか？
私もそこが気になったため色々と調べてみました。
そもそも Browser Exploitation や MITB はアプリケーション層において不正なマルウェアや拡張機能などによって引き起こされます。
つまり、これらの攻撃は XSS などの脆弱性がなくとも悪意のある拡張機能やマルウェアを用いることで攻撃が可能となってしまうと考えられます。
また、今回はログイン画面を表示すると言ったような JavaScript を実行させる攻撃でしたが MITB 攻撃ではユーザが POST したデータの内容を改ざんするといったような攻撃も存在します。
雰囲気としては Burp Suite や OWASP ZAP を用いて通信をインターセプトし内容を改ざんするといった処理に近いのではないかと感じました。
対策は？
先ほどあげたようにマルウェアや悪意のある拡張機能をダウンロードしないようにするのが有効な対策なのではないかと思います。
また、最新のセキュリティソフトを用いることで BeEF による攻撃を防ぐことが出来るようです。
参考:Harshil Sawant, Samuel Agaga."Web Browser Attack Using BeEF Framework". (researchgate.net)
感想
JavaScript って思ったよりも多くのことが出来るのですね。
MITM の攻撃で有名なマルウェアは JavaScript ではありませんでしたが、拡張機能を用いた攻撃などは JavaScript で書かれているはずなので中々恐ろしいと感じました。
時間が出来たらもう少ししっかりと調べて補足したいと思います。
それでは、今回は少し短めですがこのあたりで記事を終了としたいと思います。
最後まで読んでくださりありがとうございました。
Bulldog を攻略した記事（writeupを含みます）
どうも皆さんこんにちは。
今回は Bulldog という脆弱な仮想マシンを攻略したのでその手順を書いていこうかと思います。
まだ攻略していない方は下記リンクからダウンロード出来るので興味があればぜひ挑戦してみてください。
bulldog：
※注意
この記事は攻撃を推奨するものではありません。また、許可を得ていない機器に対する攻撃は犯罪となるため絶対に行わないでください。
目次
シェルを取る編
いつも通りポートスキャンを行います。
80番と8080番のポートで http のサービスが動いているみたいですね。
そこで、なにか面白いファイルやディレクトリがないかをツールを使って探しました。
admin と dev というディレクトリがありました。それぞれにアクセスしてみましょう。
admin にアクセスするとログインページにリダイレクトされるみたいですね。
また、dev にアクセスすると社内向けの文章が書かれたページが表示されました。
さらに、dev にアクセスした際のページ下部には以下のような面白そうな情報がありました。
これは何かに使えそうなのでメモしておきましょう。
また、dev のページに /dev/shell へと飛ぶことの出来るリンクがあったのでそれも確認してみました。
権限がなさそうです。
先ほど見つけたログイン画面でログインすることに成功したら何かが変わりそうですね。
また、robots.txtもあるみたいなのでアクセスしてみたのですが、面白い情報は何一つとしてありませんでした。
dev のページに一度ハッキングされていると書いてあったので、その雰囲気作りといったところでしょうか？
とりあえず確認できる部分をすべて確認してみましたが、これ以上の情報は得られませんでした。
ログイン画面で使用できるパスワードでも見つかれば良いと思っていたのですが、ユーザ名に使えそうな情報しかなかったためこれでブルートフォース攻撃を行うのではないかと思いました。
しかし、ツールを使うのが下手な為ツールが上手く動きませんでした......
おそらくヘッダやクッキーの値の設定で詰まっていたのではないかと思います。
そこで、解答をチラ見してユーザ名とパスワードを確認した上でブルートフォース攻撃を行いました。（ズルですね......）
画像をみると bulldog の部分だけ他のレスポンスと違う事が分かりますね。
これはユーザ名を nick と仮定してパスワードが何かをブルートフォース攻撃を用いて調べています。（ズルでユーザ名とパスワードが分かっているのでこれを行う必要は無いのですが、悔しいので......）
また、辞書に用いたファイルに bulldog が入っていることも事前に確認したうえで行っています。（凄いズルい......）
ちなみに、今回使用したツールは burp suite というツールです。（これはセキュリティツールなので紹介します。）
通信を確認したり再送したり脆弱性を自動で調べたりと色々できる便利なツールです。
初めに注意の部分でも触れているように悪用は絶対に駄目ですが、脆弱性や通信の内容を確認するのにとても便利なのでおすすめです。
閑話休題、もとの話に戻ります。
ユーザ名とパスワードが分かったのでログインしてみましょう。
このページでは特に面白い情報は見つかりませんでした。
では、先ほど目をつけていた /dev/shell のページにアクセスしてみましょう。
どうやら限られたいくつかの OS コマンドなら実行出来るみたいです。
指定されていないコマンドも実行出来たら出来ることの幅が広がりますね。
とりあえず使用できるコマンドで色々調べていたところ、面白い情報を見つけました。
後ほど使うかも知れないのでメモしておきます。
さらに色々試していたところ、制限をバイパスする方法を見つけました。
どうやら、パイプでコマンドを連結することで任意のコマンドを実行出来るみたいです。
（ls|python manage.py というコマンドで manage.py が実行されている。）
せっかくなので .ssh ディレクトリを作成し、公開鍵をその中において ssh で接続できるようにしてみました。
ちなみにauthrized_keys は wget で公開鍵を自分のパソコンから送る際に名前を間違えてしまったもので、面倒くさくてそのまま消さずに残してしまいました......
このアカウントの名前が django であること（スクショしてませんが whoami コマンドで確認しました）を用いて ssh コマンドで接続すると......
シェルの取得に成功しました。
次は権限昇格編ですね。
権限昇格編
色々調べるツールを使用したところ、面白いファイルを見つけました。
この中の /.hiddenAVDirectory/AVApplication.py というファイルなのですが、書き込みが可能なようです。
さらにこのファイルは所有者が root であるというかなり興味深いファイルでした。
このファイルにコマンドを実行するようなコードを書いた後に管理者権限でコマンドを実行出来たら権限昇格出来そうですね......
さらに色々調べていると、不思議な実行ファイルを発見しました。
実行は出来ないのですが、strings コマンドで調べてみると何やら怪しい文字列がありました。
そこで、末尾についている H を除いて文字列を繋げてみると「SUPERultimatePASSWORDyouCANTget」という文字列になりました。
さらに、webshell で情報を探している段階において発見した note というファイルからこの文字列は現在操作している django というアカウントのパスワードであることが推測されます。
このパスワードを試してみると、確かに django のパスワードであることが確かめられました。
これによって sudo コマンドの実行が可能となります。
せっかくなので先ほど見つけた AVApplication.py にコマンドを実行するような Python のコードを書き加えて管理者権限で実行してみました。
コードを書き換えて恒常的な管理者権限を取得できるようにします。
これで管理者権限の取得が完了しました。
最後にフラグを取得して終了です。
対策編
どのような対策をすれば防げるのかを考える章を書いてみようかなと思ったので今回の記事から対策編という章を追加しました。
まず今回の攻撃の流れを軽くおさらいします。
- シェルを取る編
- django のログイン画面においてブルートフォース攻撃による認証の突破
- Webshell における OS コマンドインジェクション？
- 権限昇格編
- パスワードの漏洩
シェルを取る編において、パスワードが突破されてしまう問題については強固なパスワードを使用するか、ブルートフォース攻撃を検知する仕組みを構築して不審な IP からのログインの試行を拒否するといった対策が有効なのではないかと思いました。
OS コマンドインジェクションの対策に関しては、きちんとメタ文字をエスケープすることで回避できるのではないかと思いました。
権限昇格編におけるパスワードの漏洩に関しては、実行ファイル内に機密情報を入れなければ良いのではないかと思いました。
今回の場合は、おそらく与えられたユーザ名と実行ファイル内にあるパスワードの文字列を用いて sudo コマンドを実行しているといった実行ファイルであると推測されます。
そのため、strings コマンドでパスワードが漏洩してしまったのではないでしょうか。
仮に平文ではなく、sha256 などのハッシュ関数でハッシュ化した値を格納したら安全になるのか気になりましたが、余り詳しくないのでそのような実装が安全かは分からないですね......
振り返りと感想
ブルートフォース攻撃が凄く苦手です......
上手く使えるようになりたいですね。
今回はそこまで複雑な内容ではなかったのでこれくらいで終わりにしようかと思います。
最後まで読んでいただきありがとうございました。
Tre を攻略しようとした記事（writeup を含みます）
どうも皆さんこんにちは。
今回は Tre という脆弱な仮想イメージの攻略に挑戦しました。
以下のサイトから仮想イメージをダウンロード出来るので興味があれば挑戦してみてください。
Tre : Tre: 1 ~ VulnHub
※注意
実際の攻撃手法が含まれますが、許可されていない機器に対してそれらの攻撃を仕掛けることは犯罪となるので絶対にやらないでください。
目次
シェルを取る
まずはポートスキャンを行って動いているサービスの確認を行います。
その結果、ssh と Webサーバソフトが二つ動いていることが分かりました。
まず初めに、80 番ポートで動いているサイトにアクセスしてみました。
しかし、竹の画像が表示されているだけで得られる情報は何もありませんでした。
そこで、ツールを使って何か有用な情報や脆弱性がないかを調べてみました。
すると、info.php を見ることが出来る事と /system/ にアクセスする際の ID とパスワードが admin,adimn であること等が分かりました。
そこで /system/ のベーシック認証を先ほど判明した ID とパスワードで突破すると以下のようなサイトが表示されました。
どうやらこの Web サーバでは mantis Bug Tracker というソフトが動いていることが推測されます。
現時点ではユーザ名やパスワードに関する情報は何一つないため、他に何か情報が無いかを探します。
しかし、何も見つかりませんでした。
そこで、もう一つの 8082 ポートで動いているサイトに関しても色々調べましたがこちらには有用な情報がほとんどありませんでした。
そこで色々と調べていると、Webコンテンツスキャナを使用する際に単語とファイル名（index.phpなど）がごちゃ混ぜに入っているデフォルトの辞書ではなく、単語のみ（adiminなど）が入っている辞書の末尾に拡張子をつけてスキャンを行うことで違う結果が現れるという情報を見つけました。
それを試してみると、adminer.php というページと mantisbt というディレクトリを見つけることが出来ました。
adminer.phpにアクセスすると以下のように表示されました。
ログインするために必要な情報が集まっていないためとりあえず後回しにします。
さらに、mantisbt の中に config というディレクトリを見つけました。（前の攻略の際に面白い情報が入っていた記憶があるので重要度が高いです）
すると、a.txt といういかにも怪しげなファイルが中に入っていました。
さらに、a.txt の中にはとても面白い情報が入っていました。
adminer.php のログインに使用できそうな情報ですね。
これを用いて adminer.php にログインしてみると次のように表示されました。（パスワードを変更した後にスクショしてしまったため tre と administrator のパスワードが元の値と違います。すみません......）
どうやらパスワードが変更できるようなので administrator と tre のパスワードを変更しました。
次に mantis Bug Tracker に administrator でログインしてみました。
すると mantis Bug Tracker のバージョンが 2.3.0 であることが判明しました。
そこで mantis Bug Tracker の バージョン 2.3.0 に何か脆弱性がないかを探してみると、 RCE の脆弱性があることが分かりました。
参考サイト
この脆弱性に対する exploit を実行することでシェルの取得に成功しました。
権限昇格（失敗）
いつも通り色々調べるためのツールを動かして探しましたが、よい情報を見つけることが出来ませんでした。
そこでふと、apache のバージョンで脆弱性を探したときにローカルでの権限昇格の脆弱性があったような気がしたのを思い出しました。
バージョンも合致していたのでこの脆弱性ではないかと思いこれを試してみたのですが、発火の条件がよく分からず権限昇格もうまく出来なかったため失敗してしまいました。
他になにかあるはずですが皆目見当がつかず今回のマシンはここで諦めてしまいました......（もっと Try Harder してください！！！！）
答え合わせ
今回はこちらの writeup を参考にしました。
まず、シェルを取る手法が違いましたね。
adminer.php において tre の本名が Tr3@123456@A! となっていることから、これが ssh のパスワードであると推測しているみたいです。
確かにこんなにも数字と記号にまみれた文字列が名前であるはずないですね。
そして ssh で tre のアカウントにアクセスした後に色々調べるツールで /usr/bin/check-system というファイルに注目しています。
ちなみに、このファイルは私が使用したツールでも書き込み可能な怪しいファイルとして出力されていました......
さらに、プロセスの履歴ではこのプログラムが root によって走らされていることが分かります。
これも私が使用したツールで出力されていました......
このことから、/usr/bin/check-system を書き換えることによって再起動した際に管理者権限でコマンドが実行することが出来ると言えます。
もう何でも出来ますね。
こんな感じで答え合わせは終了とします。
振り返りと感想
結果的に権限昇格に失敗しているのでよくないのですが、シェルを取るまでは凄くよかったですね。
たぶん mantis Bug Tracker のバージョンからしてこの手法も想定解の一つだったのではないかと思っています。
そこまでをなんとか自力でクリアできたのはよかったですね。
また、 config ファイルが怪しい事に気がつけたのは今までのマシン攻略の経験を生かせている証なのでそれもよかったです。
権限昇格に関してはいつも通りですね。
でもさすがに今回は気がつくべきでしたね。
/usr/bin みたいなディレクトリに入っているならコマンドでしょうし、それが書き込み可能であるならばかなり怪しいと考えるべきでした。
プロセスに関しては仕方が無いですが、次回からきちんと確認したいですね。管理者がコマンドを実行しているならば、そのコマンドを書き換えて権限昇格に繋げるのはよく聞く手法なので。
管理者によって実行されるプログラムは proc 関係の方が印象深いのですが、こういう場合もあるというのはよい勉強になりました。
まぁ、今回はこんな感じで記事を終わりにしようかと思います。
最後まで読んでくださりありがとうございました。
My Web Server を解いたので振り返りとか（writeup を含む）
どうも皆さんこんにちは。
すこし前にも似た様な記事をあげたと思いますが、今回も脆弱なマシンを攻略したのでその振り返りを行います。
今回は My Web Server というマシンを解きました。
まだ解いていないという方は以下の URL からダウンロードできるので興味があれば是非解いてみてください。
※注意
前回も書きましたが、この記事には実際の攻撃手法などが含まれています。これらのツールや攻撃を許可の無い機器に対して行うことは違法となるので決して行わないでください。
目次
シェルを取るぞ編
とりあえず対象のマシンの IP アドレスを確認します。
どうやら 10.0.2.19 のようです。（10.0.2.18 は自分のマシンのアドレスです）
次はポートスキャンを行ってどのようなサービスが動いているのかを調べます。
今回のマシンは結構色々なものが動いていますね。
しかも ウェブサーバが多めですね。まさしく My Web Server。
とりあえずそれぞれのウェブサーバにアクセスしてみました。
色々なサイトがありますね。
とりあえず各サーバに関してディレクトリを列挙して面白い情報が無いかを調べました。
すると 2222 番ポートのサイトに面白そうなページを見つけました。
面白そうですね。でもこれはシェルを取ることには役立ちませんでした。
もしかしたら別の方法では使うのかも知れませんが、今回は使用しませんでしたね......
他にも色々と探してみましたが、面白そうな情報は特に見つかりませんでした。
そこで、ポートスキャンの際に見つけたサービスに関して何か脆弱性が無いかを調べました。
するととても興味深い脆弱性を見つけました。
nostromo に任意コード実行の脆弱性があったのです！！（バージョンも 1.9.6 で合致しています）
これはとても有用ですね。
ちなみにこの脆弱性は CVE-2019-16278 というものです。
では早速リバースシェルを使ってシェルを取得しましょう！！
exploit が落ちていたので今回はこれを使いました。
適当なポートを Listen の状態にした後にリバースシェルを実行するコマンドを実行すると......
シェルの取得に成功しました！！！
嬉しいですね。次は権限昇格のパートです。
権限昇格するぞ編
来ましたね。権限昇格パート。
とりあえず色々調べるツールを wget を用いて対象のマシンに渡し、実行しました。
するとかなり面白いファイルを見つけました。
/etc/sudoers.d 内のファイルです。
/etc/sudoers.d 以下のファイルに sudo を許可する設定を書くことが出来ます。
今回はその中に tomcat が java コマンドをパスワード無しに管理者権限で実行出来るという内容の設定を見つけました。
つまり！！ tomcat でアクセスし、 java コマンドを使うことで管理者権限で色々出来るようになると言うことです。
現在は daemon というアカウントなので直近の目標は tomcat というユーザになる事を目標とします。
ここで考えたのは、どうにかしてログインし任意のコマンドを実行出来るようなファイル（リバースシェルなど）を送り込んで tomcat のアカウントでコマンドを実行出来るようにするといった手法です。
そこで、どうにかして tomcat の管理画面にアクセス出来ないかと考えながら色々と調べていると、面白いファイルを見つけました。
ユーザ名とパスワードが載っていますね。
これを使えば tomcat の Web アプリケーションマネージャにログインすることが出来ます。
さらにネット上で tomcat を用いたリバースシェルに関して調べていたところ、面白いサイトを見つけました。
このサイトでは msfconsole（metasploit でいいのかな？）を用いてリバースシェルを実行する手順が紹介されていました。
普段は msfconsole を使わないのですが、せっかくなので今回はこちらのサイトを参考にしてリバースシェルを実行しました。
結構楽ですね。
これで tomcat のアカウントでコマンドを実行出来るようになりました。
次は以下のサイトを参考にして msfvenom を用いて java のリバースシェルのファイルを作成しました。
control – Java -jar payload
そして作成したファイルを攻撃対象のマシンに送り込み、 tomcat のユーザで実行すると......
権限昇格が完了しました！！！
これにて今回のマシンの攻略は完了ですね。
振り返り
今回は結構いい感じに攻略できましたね。
しかも学びが多かったです。
/etc/sudoers.d 以下のファイルから重要な情報を手に入れるのはかなり探すのに時間がかかりました。
でも、よく考えたら管理者権限に関するファイルなので確認して然るべきですよね。
あと、 tomcat の設定ファイルも探すのに手こずりましたね。
そもそもウェブサーバの運用をしたことがないのでどこに設定ファイルがあるのかとか知らないのですよね......
そのためそれらを調べるという手間が発生してしまいます。
まぁ、すべてのサービスに関して精通することなんて不可能なのできちんと Google とかネットで調べる能力が必要ですね。
さらに、今回は msfvenom とか msfconsole を使ってみましたね。
正直いまいち使い方を把握できていないです......
誰かよい資料とか知らないでしょうか？
使いこなせたらきっと便利です。
まぁ、msfconsole は OSCP において使用回数に制限がかかっていた気はしますが、だからといって使えなくてよい訳でもないと思うのです。
とりあえずこんな感じでしょうか？
では、今回の記事はこれくらいで終わりにしたいと思います。
最後までお付き合いいただきありがとうございました。
最近 API のセキュリティに関して勉強したのでちょっとメモみたいなやつ
皆さんこんにちは。
最近 "ハッキングAPI" という本を読んだのですよ。
API のセキュリティってあまり CTF でも見かけない（あまり参加できていないから目にしないだけかもしれないけれど......）から凄く新鮮で面白かったです。
そこで今回は OWASP API Security Top 10 に関してだらだらと書いていこうかと思います。
しかし、まだまだ勉強を始めたての身なので内容はかなり浅く、不正確な情報も多分に含まれると思います。
もし OWASP API Security Top 10 が気になったという方はぜひ本家のサイトに訪れていただけたらと思います。
サイトのリンクは下に貼っておきます。
OWASP API Security Top 10:OWASP API Security Top 10
2023年度の OWASP API Security Top 10 は以下の10個のようです。
- Broken Object Level Authorization (BOLA)
- Broken Authentication
- Broken Object Property Level Authorization
- Unrestricted Resource Consumption
- Broken Function Level Authorization
- Unrestricted Access to Sensitive Business Flows
- Server Side Request Forgery（SSRF）
- Security Misconfiguration
- Improper Inventory Management
- Unsafe Consumption of APIs
Broken Object Level Authorization (BOLA)
アクセス可能なユーザかどうかの検証がされること無く誰でもオブジェクトにアクセス出来る脆弱性みたいです。
AさんのデータにはAさん以外の人がアクセス出来てはいけないはずなのに、他の人がAさんのデータにアクセス出来てしまうような脆弱性みたいです。
この脆弱性の面白い部分なのですが、基本的にその API にアクセス出来るのは仕様という点ですね。
対策としてはレコードの ID に予測不可能な値を設定することや、認可の仕組みを実装することなどがあげられています。
Broken Authentication
認証の不備に関する脆弱性です。
API を使用できるユーザであるかを確認する機能が脆弱であった場合に、他人のアカウントを乗っ取ったりできてしまうかもしれないみたいです。
この脆弱性は API 仕様ではなく、API 側が提供している認証処理に脆弱性があるといったものみたいですね。
対策は認証処理に不備がないようにすれば良いのですが、言うは易く行うは難しです。
そもそも API はステートフルであることが前提であるため（REST API の6つの制約）、認証処理を実装するのはとても難しいと考えられます。（もしかしたら良い方法があるのかも知れないですが、あいにく分かりません......）
もっと冴えた素晴らしい技術が出てきたらそちらに変わったりするのかなぁ......とか考えたりします。
まぁ、技術がどのように進化していくかは予想できないですね。
Broken Object Property Level Authorization
ユーザが読み取るべきでないプロパティを公開していたり、ユーザがアクセス出来ないはずのプロパティの値を操作できてしまったりするような脆弱性みたいです。
CTF とかで出題しやすそうな脆弱性ですね。
対策としてはクライアントからの入力をそのまま入力値として適用しないようにすること（マスアサインメント脆弱性？）や、変更できるプロパティを制限すること、ユーザに返すプロパティを厳選することなどが挙げられています。
変なリクエストが来たときに余計な情報を渡してしまったり、値の変更がされないようにしましょう！という印象を受けました。
実際どうなんでしょうね？
Unrestricted Resource Consumption
リソースの使用量などに制限がかかっていないという脆弱性みたいです。
これに関しては API に限った話ではない気がしますね。
DoS 攻撃になったり、何かしら有料のシステムをしようしているのなら莫大な請求が引き起こされたりするのかも知れません。
対策としては制限を行えば良いのですが、多種多様な DoS 攻撃の手法を見た感じ一筋縄ではいかなそうですよね......
でも、制限を行えばいくつかの攻撃は防げるので対策は大事ですね。
Broken Function Level Authorization
異なるロールの API の機能を使用できてしまう様な脆弱性みたいです。
具体的には非特権ユーザが特権ユーザしか使うことが出来ない機能を使用できてしまったりするような脆弱性です。
ロールごとに API エンドポイントが分かれている場合以外にも、ロールごとに異なるHTTP リクエストメソッドを用いている場合もあります。（管理者は POST メソッドでユーザアカウントの作成が行える。一般ユーザは GET メソッドでユーザ自身の情報を取得できるといったようなもの？）
対策方法は、関数レベルでの認可をしっかりやることなどがあげられてますね。
他の対策はちょっと知識不足で理解ができてないですね......（コントローラがなんたらかんたらとか？）
Unrestricted Access to Sensitive Business Flows
商品の買い占めや予約の枠をすべて潰してしまうといったような脆弱性？みたいです。
こういうものも技術的な対策の範囲内なんですね。
てっきりそれらの企画の段階で不正が出来ないようにするものだと思っていました。（それらをしたうえでさらに技術的な対策が必要なのかも知れないですが）
Server Side Request Forgery（SSRF）
正直よく分かりません。
サーバの機能が実行できてしまうといった脆弱性なのでしょうか？
雰囲気的には与えられた URL にアクセスしてリクエストを取ってくるような機能のあるサーバに対し、本来アクセス出来無いような URL を与えると十分に検証されないことによってアクセス出来てしまったりするという感じなのかもしれません。（合っているかは分からないですね）
サーバの機能を悪用してるから SSRF なのでしょうか？
Security Misconfiguration
セキュリティの設定ミスに関する脆弱性みたいです。
凄く多岐にわたりますよね。
これに関しても API に限った話では無いと感じます。
Improper Inventory Management
古いバージョンが残っていたりするような脆弱性なのでしょうか？（いまいち全貌を把握できていない）
これも API に限った話ではないですね。
資産管理は重要です。
Unsafe Consumption of APIs
API からの入力を無条件に信頼してしまうことによる脆弱性みたいです。
どんな入力でもきちんと検証したほうがよいということなのでしょうか？
まとめ
だらだらと書きましたが、理解できてない点が多いですね。
もっと勉強しなければならないと思いました。
sundownを解いたので攻略の振り返りと反省を行う記事（writeupを含みます）
どうもみなさんこんにちは。（もしくはこんばんわ、そしておはようございます）
記事のタイトルにもある通り今回は vulnhub というサイトからダウンロードした sundown という脆弱な仮想イメージを使って権限昇格までを行ったのでその振り返りを行います。
まだ解いてない！という方がいたらぜひ解いてみてください。リンクは下においておきます。
※注意
この記事には脆弱性を用いた攻撃手法などが含まれますが、攻撃を推奨するものではありません。また、許可を得ていないマシンに対してそのような攻撃を行うことは違法行為となりますので絶対に行わないでください。
目次
シェルを取る編
まずはポートスキャンを行ってどのサービスが動いているのかを確認します。
すると ssh と http が動いていることがわかります。
しかし、現時点ではユーザ名やパスワードなどの情報は持っていないため ssh でアクセスすることはできません。
そこで、http にアクセスして何かできないかを探します。
雰囲気的には WordPress っぽい感じがしますね。
とりあえず robots.txt にアクセスできるか確認します。
どうやら WordPress で間違いないみたいです。
とりあえず、/wp-admin と /wp-admin/admin-ajax.php にアクセスしてみました。（wp-adminにアクセスしたらwp-loginに自動的に遷移しました）
得られるものはあまりなさそうですね。
次は WordPress の情報を集めてくれるツールを使って情報を集めました。（ツールの名前を出してよいのか不安なのでぼかします。）
すると面白いものが見つかりました。（するっと書いていますが、この面白い情報を見逃したため1回詰まりました......ちゃんと出力に目を通さないとだめですね）
こちらのプラグインですが、Remote File Inclusion（RFI） の脆弱性がありました。
WordPress Plugin WP with Spritz 1.0 - Remote File Inclusion - PHP webapps Exploit (exploit-db.com)
これでいろいろな情報を集めることができるようになりました。
とりあえず、/etc/passwd ファイルを確認してみましょう。
確認しずらいと思いますが、末尾のほうに carlos というアカウントがあることが確認できます。
これで carlos というユーザが存在するという情報を得ることができました。
次は、このユーザ名を使って ssh に対して辞書攻撃を行います。
その結果、 carlos のパスワードは carlos であることが判明しました！！（通称 Joeアカウントというやつですね。ちなみに今回使用した辞書は rockyou.txt というものです。）
では早速 carlos さんのアカウントに ssh でログインしてみましょう。
すると1つ目の Flag を手に入れることができました！！！
次は権限昇格編です！！
権限昇格編
とりあえずいろいろな情報を調べてくれるグリーンピースみたいな名前のツールを使って情報を集めます。（ツールの名前はぼかしました）
しかし、何も見つけることができずに数時間が経過......いろいろ試したのですがうまくいかず、ほかの人の回答をチラ見することにしました。
すると、wp-config.phpを先ほど使用した RFI の脆弱性を使って確認していたため、僕もそれに倣って確認をしてみました。
するととても面白い情報を見つけることができました！！
なんと MySQL のユーザ名とパスワードを見つけることができたのです！！！
しかし、そこから WordPress の管理者アカウントのパスワードを書き換えてログインしたりもしましたがそれらが権限昇格につながるわけでもなく、またしても詰まってしまいました......
そこでさらにほかの人の回答をチラ見すると、どうやら管理者権限のアカウントが root 以外にもあるとのことでした。
そこで先ほど使用したグリーンピースみたいな名前のツールの結果を確認すると、mysql が管理者権限を持っていました......（これは見逃したくなかったですね......まぁ、確かに普段はしっかりと確認しない部分ではありましたが、悔しいですね）
そこで、MySQLを用いてできることをいろいろと試してみました。
初めに思いついたのは MySQL を用いてファイルを作成することです。
以下のサイトが参考になりました。
例えば"into OUTFILE"で実行結果をファイルに書き込めるなら、SQLの実行結果に任意のスクリプト(<?php echo shell_exec("ipconfig")?>)を含ませ、その結果を任意のファイル(test.php)に出力しよう。
以下のようなSQL文が考えられる。
SELECT * FROM Data; all SELECT <?php echo shell_exec("ipconfig")?> into OUTFILE 'c:/xampp/htdocs/test.php'
実行の結果、Webサーバのルートにtest.phpが出力されるはずだ。
しかし、それらのファイルは所有者が root だったのですが実行権限が付与されていなかったため権限昇格はうまくいきませんでした......
次に考えたのは MySQL を用いてファイルを読み出すということです。
どうやら LOAD_FILE 関数というものを用いればファイルを読み出せるということがわかりました。
参考サイト:How the LOAD_FILE() Function Works in MySQL (database.guide)
しかし、ファイルの読み出しはできても root ディレクトリに入っている Flag のファイル名がわからないためこの方法もうまくいきませんでした。
色々と試してみましたがうまくいかずに数時間が経過し、泣く泣くほかの人の回答をチラ見しました。
すると MySQL の User Defined Function(UDF) Dynamic Library に関する脆弱性を用いてることがわかりました。（日本語にするとユーザ定義関数の動的ライブラリといったところでしょうか？）
脆弱性の詳細:MySQL 4.x/5.0 (Linux) - User-Defined Function (UDF) Dynamic Library (2) - Linux local Exploit (exploit-db.com)
上記のサイトの手順に則って関数を作成することで任意のコマンドを使用することが出来るようになります！！
これで何でも出来るようになりました。
最後に /etc/passwd ファイルを書き換えて carlos さんを管理者権限にして Flag を取得したいと思います。
まず new_passwd というファイルを作成します。
そしてこれを /etc/passwd ファイルに書き込んだら管理者権限を手に入れることが出来ます。
そして carlos のアカウントに改めて ssh で接続すると......
無事 Flag を取得することが出来ました！！
振り返りと感想とか
こうやって記事にしてみて気がついたのですが、チラ見しすぎですね。
Try Harder の精神はどこに行ってしまったのでしょうか......
それはさておき、今回のマシンはとても面白かったですね。
SQL の脆弱性なんて SQL インジェクションくらいしか知らなかったし、 Web アプリケーション上で探しておしまい、みたいなイメージを持っていたので新鮮でした。権限昇格にも使えるんですね。
また、 WordPress のwp-config.php の中に SQL のパスワードが記述されていたのも凄かったですね。
あそこらへんのファイル群は数が多いのでどれを見れば良いのかいつも悩みます。
あと、WordPress をスキャンしてくれるツールが使いこなせてなかったですね。
この記事では結果の一部しか載せていませんが、実際は他にも色々な情報が出力されます。その中から有用な情報を探す、という事がまだまだ苦手なんですよね......
そしていつも思っていますが、グリーンピースみたいな名前のツールが全く使いこなせてないですね。
新しいマシンを解くたびに、今回はこの情報だったか......となることが多いです。
まぁ、そのたびに注意すべき点を増やしてはいるのですが......まだまだ勉強不足ですね。
まとめ
ここまで読んでくださってありがとうございました。
今回攻略した sundown というマシンなんですが、実は sunset というシリーズのマシンの1つなんです。
このシリーズのマシンは面白いものが多いのでおすすめします。
セキュリティ・ミニキャンプに参加したので布教する記事
どうもみなさんこんにちは。
この間「セキュリティ・ミニキャンプ in 東京 2023」に参加してきたのでその感想を書いていこうと思います。
目次
自己紹介
まず初めに、そもそもこの記事を書いている人は誰なのかを軽く書こうと思います。
僕は情報系の大学に通っている大学生です。
webセキュリティが好きなため、普段はwebセキュリティに関する勉強を好んでやっています。（他の分野もやるべきとは思っているのですが......）
セキュリティの勉強を始めたのが大学に入学した頃なので、この時は勉強を始めてから2年と少しが経過した頃ということになります。
セキュリティ・ミニキャンプとは？
公式ホームページでは次のように説明されています。
「全国大会により多くの学生にチャレンジいただくため
若年層を対象とし情報セキュリティ人材育成に関心の高い地域で地方大会を開催しています。」
全国大会に参加出来る様な人材の育成が目的のようです。
期間は二日間で定期的に各地で開催されています。
講義の内容はそのときによって違いますが、どれも面白く、為になる内容ばかりだと思います。
しかも、参加費は無料（僕が参加した時点において）です！！
応募するためには応募課題を解く必要がありますが、きちんと調べれば解くことが出来るのでは無いかと思います。（課題があるから......で諦めるのはとてももったいないです！！！）
少なくとも今回参加したのはとても為になりました！！
ぜひ、少しでも興味があれば応募をしてみてください。
感想
本当であれ各講義の内容に触れつつ感想を書きたいのですが、いかんせん僕の理解が追いついていない部分が多いため講義の内容に関しては割愛させてください。（すみません......）
そのため、ここではセキュリティ・ミニキャンプに参加して良かったことを書いていこうと思います。
普段は大学内の人としか交流を持たないため、高専の方や実際に社会で働かれている方々、大学院の方と言った様な様々な人と交流を持てたのはとても良い刺激になりました。
セキュリティ・ミニキャンプ終了後も交流を持てている方が何人かいるため人脈が広がると言った意味でもとても良かったです。
もし、仮に周りでセキュリティに関心を持っている人がいないといった状況であればこのイベントに参加することで同じ興味を持つ方と知り合いになることが出来ます！！
また、専門的な内容を聞いてその分野に対する興味を持つことが出来たのもとても良かったです。
おかげで新しい分野の勉強もしてみようという気持ちになることが出来ました！！
まとめ
今回の記事では精一杯セキュリティ・ミニキャンプの楽しさを書いてみました。
この記事では十分に楽しさを伝え切れていないと思いますが、少しでも参加してみたいと思っていただいたら幸いです。
