はじめに

Hack The Boxでようやく重い腰を上げ、Winodws問を始めようとしたのですが、Windowsの権限昇格って何というボヤッとした疑問が出てきました。なので最初に読んだWriteupに出てくるRotten Potatoというツール？手法？をとりあえず掘り下げて見ることにしました。

Rotten Potatoとは

Rotten Potatoはサービスアカウント（ユーザアカウントではない）をNT AUTHORITY\SYSTEMアカウントの権限まで昇格させることができるそうです。

サービスアカウントとは恐らくwordpressを走らせていたりとかそういうアカウントの類でしょうか？（間違っていたらツッコミお願いします。）NT AUTHORITY\SYSTEMはAdministratorsグループと同じ権限を持っているので、何でもできそうです。

この手法はHot Potatoをベースにしているようなので、まずそちらから見てみます。

foxglovesecurity.com

Hot Potato

foxglovesecurity.com

参考記事は2016/1/16に書かれてますのでそのつもりで読む。こちらでもNT AUTHORITY\SYSTEMへの昇格をするようです。

Privilege Escalation on Windows 7,8,10, Server 2008, Server 2012 … and a new network attack

1. Local NBNS Spoofer

NBNS(NetBIOS Name Service)は名前解決のためのUDP プロトコル。（DNSで名前解決できなかった際にネットワーク内にブロードキャストされる）
このリクエストに含まれる対象のホスト名を事前に分かっていれば、NBNSスプーフィングでホストを偽れる。(Hot Potatoの指定したサーバをホストとして偽れる)
DNSへの問い合わせ発生の際に、他UDPポートをバインドしておくことでDNS問い合わせが失敗し、NBNSリクエストを出させることが可能。
- (NBNSパケット内のTXID(2byte)はリクエストとレスポンス間で一致する必要があるが、パケットの中身は見ないので、65536パターンを全て流して対応)

2.Fake WPAD Proxy Server

IEはデフォルトでhttp://wpad/wpad.dat”へアクセスしてネットワークプロキシ設定を取得しようとする。
上の1. Local NBNS Spooferを使用して、WPADはループバックの127.0.0.1と嘘の名前解決を行わせる。
WPADのリクエストが無事127.0.0.1に飛んできたら、プロキシはlocalhost:80ですと偽る。（この80番のサーバはHot Potatoが自分で建てる）
以降IEのリクエストが全てlocalhost:80を経由して飛ぶようになる。（しかもこのwindowsマシン全てにこの設定が反映されるため、Administratorの通信も飛んでくるようになる）

3. HTTP -> SMB NTLM Relay

NTLMリレーは、チャレンジ&レスポンスで認証する方式。(詳しくは調べて)
localhost:80へ飛んでくるHTTPリクエストを、どこかNTLM認証の発生するところへ飛ばす。
発生したNTLM認証要求に対して、別途SMBのリスナーで発生させたNTLMのチャレンジを返すことで、正規パスワードを使用したレスポンスを生成させる。
レスポンスは再びlocalhost:80を通るので、それを拾いSMBへ返すことでNTLMリレーが成功する。
例えばWindows Update Serviceなどのリクエストを拾うことで、NT AUTHORITY\SYSTEMでの認証が成功する。

補足

WPADに関しての情報がキャッシュされているとそもそも名前解決が行われないので、少し待つ必要がある。
ここのSMBリレーのリバースログオンの解説をしている図は、若干違いますがやろうとしていることは理解しやすいかも。

Rotten Potato

foxglovesecurity.com

こちらは、Privilege Escalation from Service Accounts to SYSTEMと書かれています。James ForshawのBlack Hatのトークと、Google Project Zero researchが元になっているそうです。前述した通り、Hot Potatoでも使用されているローカルネゴシエーションでのNTLMリレーを一部使っているようですが、今回の最終的な目的はAPIをコールしなりすましのトークンを取得することです。

足掛かり

System権限で走っているCOMへのAPIコールを利用する。
例えとして、Systemで走っているCOMに対して127.0.0.1:6666からBITSオブジェクトをロードしたいという命令を出す。
- COM(Component Object Model )は.NET Framework以前のソフトウェアの機能を部品化して外部から呼び出して利用できるようにする技術仕様で、古いものですが今でも使用可能な技術とのこと。
- BITS(Background Intelligent Transfer Service)は使用していないネットワークの帯域を利用して非同期にファイル転送を行う常駐サービス。(?)

Man-In-The-Middle

上記の命令によりCOMはRPCプロトコルで127.0.0.1:6666と対話しようとする。(BITSはRPCを使うらしい)
127.0.0.1:6666は届いたリクエストを利用してRPC:135ポートへリクエストを送る。->レスポンスをCOMに返す。
上の流れをNTLM認証が発生するまで繰り返す。

NTLM Relay and Local Token Negotiation

NTLM認証が発生したらこの節の作業が始まります。

画像は参考サイトより。青字がCOMの処理、赤字が127.0.0.1:6666の裏での処理になります。この節ではNTLMリレーの裏で、別のプロセスも行われており、APIを呼んでます。

TYPE 1 (NEGOTIATE) PACKET

COM→127.0.0.1:6666のNTLMネゴシエーションパケット内のNTLMセクションを取り出し、それを利用してローカルでネゴシエートするプロセスを開始する(AcquireCredentialsHandleとAcceptSecurityContextを呼ぶ)。(上図の赤字の流れ)
- Hot Potatoでは、送信先(SMB。今回ではRPC)に対して認証を通すような動きであったが、今回は送信元(COM)が対象なのでアプローチが違う。(そもそも今回やりたいことはローカルでのプロセスでImpersonationTokenを発行すること)
127.0.0.1:6666はパケットをそのままRPC:135にも送る。

NTLM TYPE 2 (CHALLENGE) PACKET

RPC:135からNTLM認証のチャレンジレスポンスが127.0.0.1:6666へ返ってくる。
127.0.0.1:6666はレスポンス内のNTLM Server ChallengeとReservedの値を先程呼んだAcceptSecurityContextの返り値で置き換え、COMに返す。

NTLM TYPE 3 (AUTHENTICATE) PACKET

偽装されたチャレンジを受け取ったCOMはいい感じに認証を進める。
- ReservedフィールドはSecHandleを参照していて、COMがメモリ上で認証してくれる。
認証作業が終わったら、COMはからのレスポンスを返す（認証は全てメモリ上で行われている）。
127.0.0.1:6666はレスポンスをローカルプロセスでのAcceptSecurityContextコールに使用し、ローカルプロセスでの作業が完了する。(空なのにどこを使うのかはわかりませんでした,,)
これにより、ImpersonateSecurityContextが呼べるようになり、impersonation tokenを取得可能になる。(このトークンでCOMが走っていた権限(今回はSystem)でコードが実行可能になるはず？)

その他

NTLMは本来はDEC/RPCの認証とネゴシエーションのためのものだった？ので、RPC呼べばとりあえずNTLM認証を発生させられるはず。(他でも発生するなら良い？)
BITSはRPCを使うようなので、RPCを使わせるためにBITSを使っているような気がする。(ここのDependecesにRPCが指定されているし)
このimpersonation tokenを入手するまでの好条件が揃っているのが、最初に書いたサービスアカウント系とのこと。例えば、IISやSQL serverを走らせている系。

終わりに

正確な情報かは微妙ですが、やろうとしていることは何となくあっていると思いますが、できれば各節の参考リンク先を見てください。windowsがどう動いているのか知るのは面白いですね。