The Workspaces component of Biscom Secure File Transfer (SFT) version 5.1.1015 is vulnerable to stored cross-site scripting in two fields. An attacker would need to have the ability to create a Workspace and entice a victim to visit the malicious page in order to run malicious Javascript in the context of the victim’s browser. Since the victim is necessarily authenticated, this can allow the attacker to perform actions on the Biscom Secure File Transfer instance on the victim’s behalf.
Biscom Secure File Transfer (SFT) is a web-based solution that replaces insecure FTP and email, allowing end users to easily send and share files without IT involvement. More about the product is available on the vendor’s web site.
These issues were discovered by Orlando Barrera II of Rapid7, Inc, and disclosed in accordance with Rapid7’s vulnerability disclosure policy.
After authenticating to the Biscom Secure File Transfer web application, an attacker can alter the “Name” and “Description” fields of a Workspace, as shown in Figures 1, 2, and 3.
Figure 1: Adding XSS to Name and Description
Figure 2: Navigating to the Workspace fires the Name field XSS
Figure 3: Navigation to the Workspace fires the Description field XSS
In addition, the File Details component within a Workspace is also vulnerable to stored XSS injection. An attacker can save arbitrary Javascript in the “Description” field of the File Details pane of a file stored in a Workspace.
Figure 4: Editing file details
Figure 5: Navigating to the Workspace fires the File Details Description XSS
As of version 5.1.1025, the issue has been resolved. Absent an update, a web application firewall (WAF) may prevent attackers from entering the malicious XSS, and/or protect users by stripping offending XSS.
Security is the top priority for Biscom and we appreciate Rapid7 identifying this issue and bringing it to our attention. Once we were informed, our team moved quickly to release a patch within a week to address the issue. Biscom is not aware of any customers being impacted by this issue and Biscom sees the likelihood as low since an authenticated user is required. Biscom values the sharing of security information and we thank Rapid7 in evaluating our application’s security.
Biscom’s response to this issue was exemplary, taking less than 30 days from private notification to a public fix, as seen in the timeline below.