Facebook Bounty Hunter Wins $10,000 By Finding Backdoor
Facebook bounty hunter Orange Tsai received $10,000 after finding someone installed a backdoor, according to betanews. Tsai was able to penetrate a Linux-based staff server to discover a piece of malware was stealing passwords and usernames.
Facebook noted that the backdoor did not compromise any user information.
Tsai, who works for Devcore in Thailand, used a reverse lookup to find files.fb.com running the Accellion Secure File Transfer service that is prone to some vulnerabilities.
Bounty Hunter Installed Malware
Facebook claims a security researcher installed the malware who was trying to gain the bounty.
Tsai executed remote code on the server to gain control of it using an SQL injection vulnerability. This was the point where Tsai found the password-stealing PHP scripts.
Reginaldo Silva, a Facebook security engineer, said the company appreciates Tsai’s work. The company used a third party software they do not fully control. Facebook ran the software isolated from systems hosting the data that people share with Facebook as a way to have better security, Silva said.
Facebook determined the activity came from another researcher who participates in the company’s bounty program. Neither bounty hunter was able to undermine other parts of the company’s infrastructure, Silva said. He called it a “double win” when two researchers assess the system, and one reports what they found and receives a bounty, but neither researcher was able to expand the access.
Tsai Orange Relates Exploit
Facebook began the “Bug Bounty Program” in 2012, Tsai noted in a Devcore blog.
Tsai noted that server side vulnerabilities are “cooler to take over” than client-side vulnerabilities. Both vulnerability types are critical in a penetration test, Tsai noted.
In searching for vulnerabilities, Tsai first determines how big the company’s “territory” is on the Internet, then attempts to find an entrance. Initial steps are:
• What can be found by Google Hacking?
• How many B Class and C Class IP addresses are being used?
• Whois And Reverse Whois?
• What domain names are used and what are their internal domain names?
• What are equipment vendors preferred techniques?
• Are there Github or Pastebin data breaches?
Tsai noted there are common security issues in large corporations.
1. “Network Boundary” is hard to take care of. When a company’s scale has expanded, tens of thousands of computers, servers and routers make it impossible for the MIS to have a perfect protection mechanism. Luck is often on the attacker’s side since an attacker only has to find a small weak spot. A susceptible server on the “border” will grant access to the internal network.
2. Lack of knowledge of “Networking Equipment” protection. The majority of this equipment does not provide delicate SHELL controls, and only the user interface can configure them. The protection oftentimes is built on the Network Layer, but users might not notice if 0-Day or 1-Day attacks compromise these devices.
3. “Breached Database,” known as “Social Engineering Database” has emerged in China. The leaked data sometimes lowers the difficulty of penetration. The attacker only has to connect to the breached database, find a user credential with VPN access, and they can penetrate the internal network.
When the scope of the breach can be large enough that the Key Man’s password can be discovered in the breached data, the victim company’s security diminishes.
The Search Begins
Tsai found domain names of Facebook and also tried Reverse Whois which yielded an interesting domain name: tfbnw.net. This apparently stood for “The Facebook Network.”
Tsai then found the following server through public data; vpn.tfbnw.net.
In accessing vpn.tfbnw.net, the Juniper SSL VPN login interface offered no vulnerability to be directly exploited.
Tsai enumerated vpn.tfbnw.net’s C Class IPs to find some interesting servers such as:
• Mail Server Outlook Web App
• F5 BIGIP SSL VPN
• CISCO ASA SSL VPN
• Oracle E-Business
• MobileIron MDM
The information on those servers led Tsai to believe the C Class IPs were important.
A special server among the C Class IPs was:
Based on the Footer and logo, the login interface was Accellion’s Secure File Transfer (FTA). FTA allows secure file transfer, syncing and online file sharing, in addition to integration with Single Sign-on mechanisms that include Kerberos, LDAP and AD. The Enterprise version supports SSL VPN service.
The next thing Tsai did was to search the Internet for public exploits. HD Moore made the latest one public on Rapid7 Advisory: Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE – 2015-2857).
The version leaked from “/tws/getStatus” can determine whether this vulnerability is exploitable. When Tsai discovered files.fb.com, the defective v0.18 already had updated to v0.20. Tsai believed there should still be security issues in FTA and began to seek 0-Day on FTA products.
Black-box testing did not yield vulnerabilities, so Tsai tried white-box testing. After gathering source codes from prior FTA versions, research proceeded.
Also read: The Facebook Hacker 2016 Cup is underway
Tsai noted the following about FTA product:
1. Web-based user interfaces mainly were composed of Perl & PHP.
2. IonCube encrypted the PHP source codes.
3. There were lots of Perl Daemons in the background.
Tsai first attempted to decrypt IonCube encryption. The IonCube version that FTA used was not up to date, and ready-made tools could not decrypt it.
Tsai thought Rapid7 should have gotten the easier vulnerabilities following a simple review. Finding the vulnerabilities easy to exploit required further investigation.
Tsai discovered seven vulnerabilities that included the following:
• 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
Tsai reported vulnerabilities to the Accellion Support Team. Once the vendor was patched, Tsai sent these to CERT/CC which assigned four CVEs for the vulnerabilities.
Tsai noted there will be additional details published after full disclosure policy.
After assuming control of the server, Tsai checked whether the server environment was friendly. To remain on the server, it was necessary to be aware of the restrictions, logs, environments, etc. and not be detected.
Tsai found restrictions on the server.
1. Firewall outbound connection unavailable, including TCP, UDP, port 53, 80 and 443
2. Remote Syslog server
3. Audit logs enabled
While the outbound connection was not available, the ICMP Tunnel was working. Tsai could control the server with a webshell as this was merely a Bug Bounty Program.
In gathering vulnerability details to report to Facebook, Tsai found some strange things on the web log. These included strange PHP error messages that appeared to be caused by modifying codes online.
Tsai followed the PHP paths in error messages and discovered suspicious WEBSHELL files form prior “visitors:
The hacker created a proxy on the credential page to log Facebook employee credentials. The passwords were stored under the web directory to allow the hacker to use WGET occasionally.
Apart from the logged credentials, there were contents of letters seeking files from FTA. The logged credentials rotated regularly.
There were about 300 logged credentials from Feb. 1 to 7. There were primarily two modes in FTA for user login.
Tsai reported proofs to the Facebook Security Team.
Screenshots, timelines and logs were provided in addition to vulnerability details.
There were two periods the hacker operated the system based on the server logs, one in early July and the other in mid-September. The first one was a server “dorking” while the second was more severe. Keyloggers were also deployed.
The July incident occurred just before the CVE-2015-2857 exploit. Whether or not it was an invasion of 1-day exploitation or unknown-0 ones is not known.
Featured image from Shutterstock.