滲透 Facebook 的思路与发现
写在故事之前
身为一位渗透测试人员，比起 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 来说应该是相对重要的网段，之后一切的故事就从这裡开始。
弱点发现
在同网段中，发现一台特别的伺服器
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 操作即可。
似乎有点奇怪?
正当收集证据準备回报 Facebook 安全团队时，从网页日誌中似乎看到一些奇怪的痕迹。
首先是在 “/var/opt/apache/php_error_log” 中看到一些奇怪的 PHP 错误讯息，从错误讯息来看似乎像是边改 Code 边执行所产生的错误?
↑ PHP error log
跟随错误讯息的路径去看发现疑似前人留下的 Webshell 后门
↑ Webshell on facebook server
其中几个档案的内容如下
sshpass
没错，就是那个 sshpass
bN3d10Aw.php
前几个就是很标準的 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 可以观察到的每隔数日骇客会将记录到的帐号密码清空
使用 Shell Script 进行内网扫描但忘记把 STDERR 导掉XD
尝试对内部 LDAP 进行连接
尝试访问内部网路资源
( 看起来 Mail OWA 可以直接访问 …)
尝试对 SSL Private Key 下手
从浏览器观察 files.fb.com 的凭证还是 Wildcard 的 *.fb.com …
后记
在收集完足够证据后便立即回报给 Facebook 安全团队，回报内容除了漏洞细节外，还附上相对应的 Log 、截图以及时间纪录xD
从伺服器中的日誌可以发现有两个时间点是明显骇客在操作系统的时间，一个是七月初、另个是九月中旬
七月初的动作从纪录中来看起来比较偏向 “逛” 伺服器，但九月中旬的操作就比较恶意了，除了逛街外，还放置了密码 Logger 等，至于两个时间点的 “骇客” 是不是同一个人就不得而知了 😛
而七月发生的时机点正好接近 CVE-2015-2857 Exploit 公佈前，究竟是透过 1-Day 还是无 0-Day 入侵系统也无从得知了。
这件事情就记录到这裡，总体来说这是一个非常有趣的经歷xD
也让我有这个机会可以来写写关于渗透的一些文章 😛
最后也感谢 Bug Bounty 及胸襟宽阔的 Facebook 安全团队 让我可以完整记录这起事件 : )
官方 