Biscom Secure File Transfer is an application that gives the ability for companies to share files among users and focuses on being easy to use for the everyday user. It allows for users to send files without having to use FTP, email, or any possibly insecure method and has been certified as FIPS-140. By going to Biscom's Secure File Transfer site (http://www.biscomsft.com/) you can see many large industry names that have picked Biscom to meet their secure file transfer needs. However, during a penetration test we discovered a vulnerability in the application that allows for access to all sent files and the ability to overwrite any existing file.
This blog post will provide a high level overview of the vulnerability.
Disclaimer: This content is for personal or educational use only. Do not use the exploit code and/or techniques in this blog against systems you do not own or do not have permission to test
Background
The Tevora threat team was on a penetration test with minimal services and applications exposed. We saw the client was using Biscom secure file transfer that allowed for anyone to make a user account that did not need to be authorized by an administrator. New accounts are given little access initially, although they can be granted more by an administrator. During the penetration test we were operating with the lowest privileges.
With the lowest level privileges the application has the following functionality:
- viewing received messages
- the ability to send messages
- management of account settings
When operating with this level of privileges, messages can only be sent to a specific set of users (a specific domain). Regardless, sending a message to any user (real or fake) will show in the sent items directory and it will contain the contents of that message.
File Upload
When creating a message and attaching a file the application goes through a multi-step process with multiple HTTP POSTS:
- The application sends a request to initialize the file upload. This step is not important for the exploit.
- Once the file is uploaded to the server, the server response contains the generated attachment ID.
- The final post sends information about the file and the ID is sent (upload finish) as the 'dataFileId' seen below.
This ID is created in a sequential order, giving insight to the number of files in the system and allowing all previously created file IDs to be guessed.
The 'dataFieldId' suffers from a logic error that does not validate the ID is the same ID returned by the server in Step 2. If an existing ID is set in Step 3, the uploaded file will overwrite the file at the existing ID. This could allow an attacker to replace existing files with malicious payloads, or corrupt data.
Sending a Message with Any File Attached
After the file is uploaded, the next POST request is to send a message with a file, or files, attached. In the message send request, the dataFileId field is used to define which files are attached to the message. Like the previous file upload steps this field has no server side validation, allowing any file to be attached to the message. Seeing as all file IDs are sequentially created, we know what every file ID is, and can add any file in the system as an attachment to our message.
When the user sends a message there are two pieces of information necessary to make the exploit successful. First, when initially visiting the send message page an Apache Struts token is created to prevent CSRF attacks. Since we are sending messages in this attack we will need to grab the Struts token with every message or else it will fail. Secondly, the 'dataFieldId' will be used so the application knows which attachments needs be sent with the message.
Once the message has been sent we can go to the sent message page of the application and view our file. In the proof of concept, we see that our 24-byte test file that was initially uploaded is now 104.1 KB meaning we were able to access the file of the ID we gave it. By attaching every file in the system, we are able to download thousands of files containing intellectual property and sensitive information.
The Exploit
Now with this information we created an exploit to send file ID 1 all the way to the most current file ID to ourselves so we could access everything on the server.
If you would like the PoC for this vulnerability contact us (threat@tevora.com) for more information
Conclusion
During the penetration test Biscom was alerted about this vulnerability and issued a patch to fix it. If you're running Biscom be sure to make sure you have applied the patch for this. According to Biscom affected versions of SFT are 5.0.1000 through 5.0.1048 and version 5.0.1050 contains the fix. Stay tuned for more information in the coming months with research Tevora is performing on various applications.
This was assigned CVE-2016-10710.
Timeline
- February 2016 - Vulnerability found, Biscom notified
- February 2016 - Biscom releases patch
- June 2016 - Vulnerability details and exploit released