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

Foreword

As a pentester, I love server-side vulnerabilities more than client-side ones. Why? Because it’s way much cooler khổng lồ take over the VPS directly and gain system SHELL privileges.

Of course, both vulnerabilities from the server-side & the client-side are indispensable in a perfect penetration thử nghiệm. Sometimes, in order lớn take over the VPS more elegantly, it also need some client-side vulnerabilities to lớn bởi the triông chồng. But speaking of finding vulnerabilities, I prefer to lớn find server-side vulnerabilities first.

Bạn đang xem: One weird trick to get more facebook likes for free

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 to lớn give it a shot.

From a pentester’s view, I tend lớn start from renhỏ & vì some retìm kiếm. First, I’ll determine how large is the “territory” of the company on the internet, then…try lớn find a nice entrance 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 names are used? What are their internal tên miền names? Then proceed with enumerating sub-domains What are their preferred techniques and 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 set forth by Bug Bounty, the overlapping part will be the part worth trying.

Here I’d lượt thích to lớn 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 to 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 lớn handle, it’s impossible lớn build up a perfect mechanism of protection. Security attacks can only be defended with general rules, but a successful attaông chồng only needs a tiny weak spot. That’s why luchồng is often on the attacker’s side: a vulnerable server on the “border” is enough lớn grant a ticket lớn the internal network! Lack of awareness in “Networking Equipment” protection. Most networking equipment doesn’t offer delicate SHELL controls và 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 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 victlặng 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 khổng lồ. When I was doing some renhỏ and research, not only did I look up the domain name 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 khổng lồ be quite new và 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 khổng lồ enumerate the C Class IPs of vpn.tfbnw.net and found some interesting servers, for example:

Mail Server Outlook Web App F5 BIGIPhường. 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 aý muốn these C Class IPs.


*
↑ Login Interface of files.fb.com

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

FTA is a hàng hóa which enables secure file 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.

Xem thêm: Đây Là Cách Tạo Nhanh Hòm Thư Trong 10 Phút Mail, Tạo Email 10 Phút Miễn Phí

Upon seeing this, the first thing I did was searching for publicized exploits on the internet. The lachạy thử 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 lớn v0.trăng tròn. 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 lớn look for 0-Day vulnerabilities on FTA products!

Actually, from black-box testing, I didn’t find any possible vulnerabilities, and 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 và PHP. The PHP.. source codes were encrypted by IonCube Lots of Perl Daemons in the background

First I tried to lớn decrypt IonCube encryption. In order khổng lồ 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 lớn date và could be decrypted with ready-made tools. But I still had to fix some details, or it’s gonna be messy…

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

Finally, I found 7 vulnerabilities, including

Cross-Site Scripting x 3 Pre-Auth SQL Injection leads lớn Remote Code Execution Known-Secret-Key leads lớn Remote Code Execution Local Privilege Escalation x 2

Apart from reporting khổng lồ Facebook Security Team, other vulnerabilities were submitted lớn Accellion Support Team in Advisory for their reference. After vendor patched, I also sent these lớn CERT/CC & 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 Squốc lộ 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 hệ thống environment is friendly lớn you. To stay on the VPS longer, you have khổng lồ be familiar with the environments, restrictions, logs, etc và try hard not lớn be detected. :P

There are some restrictions on the server:

Firewall outbound connection unavailable, including TCP, UDP, port 53, 80 & 443 Remote Syslog hệ thống Auditd logs enabled

Although the outbound connection was not available, but it looked lượt thích ICMPhường. Tunnel was working. Nevertheless, this was only a Bug Bounty Program, we could simply control the hệ thống with a webshell.

Was There Something Strange?

While collecting vulnerability details and evidences for reporting lớn 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 to lớn 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 & there’s one exception: “sclient_user_class_standard.inc

In include_once “sclient_user_class_standard.inch.orig” was the original PHPhường phầm mềm for password verification, and 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 log the credentials of Facebook employees. These logged passwords were stored under website directory for the hacker lớn 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, and these logged credentials were rotated regularly (this will be mentioned later, that’s kindomain authority cheap…XD)

And at the time I discovered these, there were around 300 logged credentials dated between February 1st to lớn 7th, from February 1st, mostly “
fb.com) used LDAPhường. và authenticated by AD Server

I believe these logged credentials were real passwords & I GUESS they can access khổng lồ 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 website log When the hacker was sending out commands, he didn’t take care of STDERR, và left a lot of comm& error messages in web 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; emang đến > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1" 200 2559 ...

cát tmp_list3_2 | while read line; vày 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); bởi emang đến "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout...

Xem thêm: Điện Thoại Samsung Galaxy S4 Giá Tốt, Phân Phối Chính Hãng Tại Nguyenkim


Use ShellScript lớn scan internal network but forgot khổng lồ 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/VPS.key: No such file or directorymv: cannot stat `x': No such file or directorysh: /etc/opt/apache/ssl.crt/VPS.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 file or directorysh: /etc/opt/apache/ssl.crt/server.crt: Permission deniedmv: cannot stat `x': No such tệp tin or directorysh: /etc/opt/apache/ssl.crt/server.crt: Permission deniedmv: cannot stat `x': No such tệp tin or directorysh: /etc/opt/apache/ssl.crt/server.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 Facebook Security Team. Other than vulnerability details accompanying logs, screenshots & 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 & one in mid-September

the July one seemed khổng lồ be a hệ thống “dorking” and the September one seemed more vicious. Other than VPS “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 khổng lồ 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, &, generally speaking, it was a rather interesting experience xD Thanks lớn this sự kiện, it inspired me to write some articles about penetration :P

Last but not least, I would lượt thích to 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: Tại sao cần làm digital marketing