[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.
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:
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:
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/hacked
And sure enough, when checking on that file /tmp/hacked
you can see that the command injection worked just fine.
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:
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