Advisory: Accellion File Transfer Appliance Vulnerability
By Orange Tsai
About Accellion FTA
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.
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).
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.
Vulnerability Analysis and Exploitation
Multiple Cross-Site Scripting (CVE-2016-2350)
1. XSS in move_partition_frame.html
2. XSS in getimageajax.php
3. XSS in wmInfo.html
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,
$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:
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 ).
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!
The created PHP file will be located at
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 (`)
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
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.
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 is the command for proceeding updates. Part of the codes are as follows:
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
will grant execution freely as root!
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
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.
- 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