VulnHubのIMF: 1をやってみたよ～！
VulnHubのIMF: 1をやってみたよ～！ということでやっていく。
まずはnetdiscoverでIMF VMのアドレスを取得。
アドレスが分かったら次はNmapでポートスキャン。
80番ポートでApacheが動いていることがわかる。
アクセスしてみた結果が次の画像。
かっこいいページだがここにはヒントはなさそう。
違うページをあさっているとcontactページのソースにフラッグを発見した。
ざっとみてスルーしてしまいそうだったが、なんとなくブラウザのページ内検索を試したら見つかった。あぶないあぶない。
さて、他に隠されたページはないかdirbを使って辞書ベースのページ探索をしてみる。
特になさそうだ。
niktoでサイトに脆弱性がないか試してみる。
うむ…とくになさそう。
早くもどうしようかとウロウロしていると先程見つけたフラッグの中身がBase64でエンコードされた文字列であることに気づいた。
さっそくデコードしてみる。
ふむふむ？
ファイルが関係する…のか？
これまでのところファイルが見えるのはページのソースだけなので再度チェックしてみる。
サイトのソースをくまなく見ていくと次の画像の部分でそれをみつけた。
3つの文字列をつなげてからデコードしてみる。
フラッグゲット！
が、またしてもエンコードされているのでデコードする。
どういうことだろう・・・？
ページ名か…？
おお、合ってた。
ログインページさんこんにちは。
適当に試してももちろんログインできないのでソースを見てみる。
ソースにRogerというユーザー名が見つかった。
これをつかって何度かログインを試してみたうまく行かず。
contactページでいくつかメールアドレスやユーザー名が見つかっていたので、それらをもとにcewlを使って簡単なワードリストを作る。
ワードリストにRogerも追加して…
Burpsuiteでユーザー名とパスワードを格納するパラメータも入手し、準備は万端。
hydraでブルートフォースアタック！
が…うまくいかない…
ログイン可能な組み合わせは見つからなかった。
脆弱性を使うのかと、Apache2.4.18の脆弱性について調べて回ったが利用できそうなものは見あたらない。
裏でphpが動いていることはわかっているのでphpのlogin処理をbypassする方向で調べを進めたがこれもうまくいかない。
sqlインジェクションの脆弱性があるのかとあれこれ試してみたがこれもだめ。
ただユーザー名がrmichaelsであることはレスポンスから判別することができた。
結局writeupを見た。
burpsuiteを使ってパスワードを受け取る変数をpass=をpass[]=にしてやるとうまくいくということだ。
そのレスポンスとして次のページが帰ってきた。
フラッグの文字列をデコードしたのが次の画像。
またリンクをクリックすると次のページに飛んだ。
URLをよく見ると引数を受け取っていることがわかる。
これは脆弱性がありそうだ。
試しにクォーテーションだけを与えてやるとさっそくエラーが出た。
sqlmapでmysqlを攻撃可能か調べる。
脆弱性があるといろいろ表示されるので試しに次の画像のコマンドでテーブルを表示する。
得られたテーブルで特に気になったのが次の画像だ。
ページ名とおぼしき文字列が得られている。
アクセスしてみる。
ふーむ、画像にQRコードが含まれていることがわかる。
https://zxing.org/w/decode.jspx
このサイトでQRコードを読み取るとフラグが得られた。
デコードしてみる。
まーたページ名かな？
アクセスしてみる。
アップロードフォームだ。
リモートシェルを返すスクリプトをphpで書いてアップロードしてみる。
が、phpファイルはアップロードを許可されていなかった。
拡張子だけをみて判定していると考え、先程のファイルの拡張子をjpgに変えて再度アップロードする。
すると今度はeval関数が含まれているため許可されないとレスポンスが帰ってきた。
結局私はGIFファイルシグネチャーをヘッダーに付与した非常に簡素なWebシェルをアップロードすることでこのWAFを回避した。
次の画像が実際にアップロードに使用したgifファイルだ。
このファイルを呼び出すことができれば引数に与えたコマンドを実行できる。
uploadディレクトリ配下に格納されると考えいくつか適当なURLにアクセスしたがページが見つからないとレスポンスが帰ってくる。
ディレクト構造に調べたりと散々苦労したあと、アップロードフォームのソースに次の文字列を発見した。
緑色にコメントアウトされているのがその文字列である。
私は最初、この文字列が何を意味するのかわからなかった。
何度かファイルをアップロードし直したりする中で、この文字列が変化していることに気づいた。
おそらくこれがアップロード後のファイル名なのではないか？
ファイル名がハッシュ値のような形に変換されているのではないかと考えた。
実際にURLのファイル名を、この16進数表記された文字列に変えてアクセスして見るとコマンドの結果が表示された。
lsコマンドを渡すと、フラッグが同ディレクトリ内にあることがわかったのでcatで表示させたのが次の画像。
デコードすると次のような文字列を得られた。
ここまでたどり着くのにかなりの時間を要した。
無事フラグも回収できたので、気を取り直して次のステップに進もう。
Webシェルの引数にwgetコマンドを与え、Kaliに置いてあるリバースシェルを張るスクリプトをダウンロードさせる。
次に、URL上でスクリプトを指定して実行させると、無事シェルが得られた。
シェルが得られたら次にすべきことは権限昇格だ。
PoCを使ってカーネルエクスプロイトを狙いたいがおそらくこれまでの流れから察するにうまくいかない。
先のフラッグで得られたagentservicesというヒントを使っていきたい。
netstatで裏でどんなサーバーサービスが待ち受けているのかを表示したのが次の画像。
7788番ポートでLISTENがある。
Agetn IDを求めるプログラムが動いていた。
明らかにこのプログラムが次の攻略対象だと思われる。
また/usr/local/binにこのagentプログラムとaccess_codesというファイルを見つけた。
access_codesは何に使うんだろうか…？
とりあえずagentを解析するためにcatで出力し、Base64で表示可能な範囲に変換。
この文字列をKaliにコピペし、デコードすればファイルを実質ダウンロードしたことになる。
またIMF VMの方でpsコマンドを実行したところknockdを発見した。
これは予め決めておいた順にポートアクセスされたときに特定ポートを開放するというものだ。
さきほどのaccess_codeはおそらくknockするためのものだろう。
ためしにやってみる。
冒頭のNmapを使ったスキャンでは開いていたなかった7788番ポートにアクセスできるようになっている。
やはりこのagentプログラムを利用して権限昇格を狙うので間違いないだろう。
まずはstringsコマンドで簡単にプログラムに含まれる文字列をチェックする。
agentプログラムは最初にagent IDを求めてくる。
おそらくその部分の処理はstringsで表示された、strncmpで行われていると予想される。
ltraceでライブラリの呼び出しをチェックしてみる。
やはりそうだった。
agent IDは48093572だ。
次の入力で大量の文字列をインプットするとSegmentation faultを起こす。
このことからバッファオーバーフローを利用した攻撃が可能だと考えられる。
まずはバッファからeipを上書きできる場所までのオフセットを求める。
最初に一意な文字列を生成し、
edbをagentにアタッチさせた状態で、先程の文字列をagentにインプットする。
するとedbの方で次のような出力を得る。
eipが上書きされ、不法なアドレスにアクセスしようとした結果エラーが出たわけだ。
この文字列までのオフセットを次のコマンドで求める。
なるほど、バッファからeipを上書きできる部分までのオフセットは168だということだ。
したがってmsfcenomでリバースシェルを張るシェルコードを生成し、
見つけておいたcall eax（番地0x08048563）へと、eipが上書きされるように次のようにすれば権限昇格が狙える。
Netcatで待ち受けて…
よおし！！
ここまで長かった…
