Feedback
Did this article resolve your question/issue?

   

Article

MOVEit Transfer - Vulnerability Scanner, Penetration Testing, and Hardening FAQ's

« Go Back

Information

 
TitleMOVEit Transfer - Vulnerability Scanner, Penetration Testing, and Hardening FAQ's
URL NameVulnerability-Scanner-Pentest-FAQ-s
Article Number000190266
EnvironmentProduct: MOVEit Transfer
Version: All Supported Versions
OS: All Supported Platforms
Question/Problem Description

I ran a security vulnerability scan on my MOVEit Transfer server and found some vulnerabilities. How do I report these to the Progress MOVEit Team?

If a vulnerability exists, when will the Progress MOVEit Team implement a fix?
Steps to Reproduce
Clarifying Information
Please review this article for commonly reported vulnerabilities, CVE's, and hardening techniques for MOVEit Transfer. Also included is a list of known issues, non-applicable issues, false-positives, and Microsoft-layer issues that may show up in a security scan.

To receive email notifications for Security Hotfixes, please log into the Progress Community Portal and sign up for our Progress Alert and Notification Service (PANS). Please see our FAQ page regarding PANS alerts.

For a similar article that covers the MOVEit Automation product, please see MOVEit Automation - Vulnerability Scanner, Penetration Testing, and Hardening FAQ's

For a similar article that covers the MOVEit Gateway product, please see MOVEit Gateway - Vulnerability Scanner, Penetration Testing, and Hardening FAQ's

For a similar article that covers the MOVEit Analytics product, please see MOVEit Analytics - Vulnerability Scanner, Penetration Testing, and Hardening FAQ's
Error Message
Defect/Enhancement Number
Cause
Resolution

MOVEit Transfer CVE's

__________________________________________________________________________________________

Known Issues
Most of the issues which may be detected on your server are already mitigated in some way with built-in MOVEit Transfer functionality. However, the best resolutions for these issues will always be on the Microsoft layer, whether that be within the OS itself or within IIS. The Progress MOVEit Team is always working to make the hardening of these Microsoft components easier for you in future releases.
  • Weak SSL/TLS Protocol and/or Ciphers Enabled
    • PCI-DSS v3.1 has called out not just old SSLv2 & SSLv3 but also TLSv1 and TLSv1.1 as not strong cryptography. Anything less than TLSv1.2 should not be introduced into new cardholder environments after 30 June 2015 and there is a deadline to be fully compliant by 30 June 2016.
    • NIST Special Publication 800-52 Revision 1 no longer considers TLS 1.0 as strong cryptography. TLS 1.0 is also no longer in compliance with PCI DSS v3.1 requirements. PCI does not consider TLS 1.0 to be adequate to protect cardholder data and has deprecated its use starting June 2016
    • TLS 1.0 is considered insecure as it lacks support for strong cipher suites and is known to be plagued by several known vulnerabilities. It either uses RC4 cipher, which is prone to bias attacks or uses Cipher Block Chaining (CBC) mode cipher, which enables condition for POODLE (Padding Oracle On Downgraded Legacy Encryption) attacks.
    • Use of insecure protocol versions will weaken the strength of the transport protection and could allow an attacker to compromise, steal or modify sensitive information. Configuring the web server to use the most secure protocol, TLS 1.1 or TLS 1.2 is highly recommended.
    • MOVEit DMZ's SSL/TLS capabilities rely on Microsoft Windows' SSAPI known as Schannel. Although Windows can, by default, potentially negotiate protocols and ciphers that are deemed to be weak, those weaker protocols and ciphers will never be preferred by modern clients. However, currently the MOVEit DMZ application layer  requires a connection secured with at least 128-bit encryption, by default. Any further hardening will have to be implemented according to Microsoft's articles, linked below.  In version 8.0 and above, the DMZ Config tool will interface with the registry keys indicated within the following Microsoft KB articles, making this easier to configure. In all older versions, you can resolve this issue by editing the registry per these articles:
  • POODLE Vulnerability
  • WinShock Vulnerability
  • Sweet 32
    • To mitigate against this Web browsers should offer 3DES as a fallback-only cipher, to avoid using it with servers that support AES but prefer 3DES. You can disable 3DES ciphers in MOVEit Transfer Config on the SSL tab and then uncheck ciphers using 3DES: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  • Clickjacking/Cross-Frame Scripting
    • MOVEit DMZ employs built-in backend clickjacking/cross-frame scripting protection, to help prevent attackers from loading the DMZ site within an iframe on a malicious site. To implement this manually please review the following Microsoft article, Mitigating framesniffing with the X-Frame-Options header.
  • Application Exception, Custom Error Pages
    • By default, MOVEit Transfer indeed displays application exceptions, including stack traces. You can turn these off in the application by signing on as sysadmin, then going to the Settings page and clicking the Error Display link towards the bottom. Set it to No.
    • Other kinds of error pages may still appear and this is because IIS and ASP.NET themselves also show their own specific error pages. Detailed exception information will not appear for remote connections for these error pages.
    • Please review this Microsoft article for more information on how to implement both IIS and ASP.NET custom error pages manually, Displaying a Custom Error Page (C#).
  • Internal IP Address/Network Name Disclosure
    • If your MOVEit Transfer server is behind a NAT or load balancer, IIS can leak the internal/private/non-Internet-routable IP address in the Location HTTP header of a "302 Found"/redirect response. MOVEit Transfer generates redirects upon sign on, and if you attempt to access the site without SSL/TLS. Please see this Microsoft post for comprehensive details.
    • To manually remediate this issue, run the following command on the server, where my.dmzhostname.com is the appropriate hostname for your MOVEit Transfer server:
      • appcmd.exe set config -section:system.webServer/serverRuntime /alternateHostName:"my.dmzhostname.com" /commit:apphost
  • Server Information Disclosure in HTTP Headers
    • IIS has built-in functionality to transmit version information to HTTP/S clients in the following HTTP headers:
      • Server
      • X-Powered-By
      • X-AspNet-Version
    • Please consult Microsoft's recommendations if you must mitigate this. Please see this link for options on how to remove unwanted http response headers.
  • BREACH Attacks
    • An attacker with the ability to inject HTTPS requests from a victim's browser to your MOVEit DMZ server, as well as monitor the encrypted responses to those requests, can leverage the known properties of compression and cryptography to decrypt small pieces of traffic, which can result in a session hijack and/or information disclosure. Please see this CERT database entry for more details:
    • There is currently no known mitigation for these attacks, other than to disable HTTP layer compression. Please note that disabling HTTP compression will increase your overall bandwidth usage. There are two encryption methods that should be disabled: static and dynamic compression.
    • To disable static compression, in Internet Information Services (IIS) Manager:
      • 1. Select the appropriate site under your server, Sites folder on the left. Normally, the site is named moveitdmz.
      • 2. In the middle pane, double-click the Compression feature in the IIS section.
      • 3. Un-check Enable static content compression.
    • Alternatively, you can add the following line to the MOVEitDMZ\wwwroot\web.config file, in the system.webServer section:
      • <urlCompression doStaticCompression="false" />
      • It is safest to put this in its own line immediately after <system.webServer> or immediately before </system.webServer>. This can be done at the same time you're editing the config to disable dynamic compression, below.
    • To disable dynamic compression, you must edit the MOVEitDMZ\wwwroot\web.config file. Please be careful--back-up your web.config file (copy it to another location) before editing it.
    • Remove this section near the top of the web.config file:
      • image.png
    • Then further down in the file, delete this section:
      • image.png
    • Then further down in the file, delete this section:
      • image.png
    • When you save the file, the changes will take effect immediately. Check to make sure you can still successfully access the site. If not, you should restore your web.config backup as there was likely an error during the change.
  • Short Files/Folder Name Disclosure
    • Version of ASP.NET prior to 4.0 allowed a user to brute-force the short names of files or directories using the 8.3 short name scheme. This is mitigated in DMZ 8.1 and above through use of ASP.NET version 4.0. On older versions you can disable the 8.3 naming convention as DMZ does not use it except during installation. This can also be mitigated using URLScan, by adding ~ to [DenyURLSequences].
  • Autocomplete enabled for password field
    • Versions of DMZ prior to 8.0 had this feature enabled. This concern was addressed in version 8.0 and later and autocomplete is no longer enabled for the password field 
  • Custom HTTP Headers
    • The following headers have been reported in a number of scans lately, and appear to have no negative impact if implemented: 
      • X-XSS-Protection
      • X-Content-Type-Options
      • Strict-Transport-Security
    • These headers, however, are not supported. CSP (Content-Security-Policy) will cause MOVEit Transfer to become nonfunctional, while PKP (Public-Key-Pins) is simply being deprecated and as such is not recommended to be used.
    • As of 2018 SP1, HTTP security response headers are provided with hardened options (SETTINGS > System - HTTP Headers: Security Headers). Please see our official documentation for more on HTTP Security Headers.
    • These settings are set by default for new installations and include hardened/OWASP suggested settings for:
      • Content-Security-Policy.
      • HTTP-Strict-Transport-Security.
      • X-XSS-Protection (cross-site scripting).
  • 7-zip Arbitrary Code Execution
    • An issue has been found in older versions of 7-zip, which comes bundled with MOVEit Transfer and can be optionally integrated into MOVEit Automation.  As of Transfer 2018 SP1, we have updated 7-zip to 64-bit and version 18.05, which is patched for this vulnerability.  For more information, please see https://www.7-zip.org/history.txt
  • Cross-Origin Resource Sharing
  • Use of JavaScript Library with Known Vulnerability
    • Versions prior to 2018 SP2 are using AngularJS 1.5.8 which is considered vulnerable. In 2018 SP2 we updated this version to 1.6.10
  • Bar Mitzvah Vulnerability
    • The Bar Mitzvah Vulnerability is related to a weakness in the RC4 algorithm. The remediation for this CVE (CVE-2013-2566, CVE-2015-2808) is to avoid the use of RC4 ciphers. To remediate, create a backup of your MOVEit Transfer system and in the MOVEit Transfer Config Utility on the SSL tab you can uncheck the following ciphers that use RC4:
      • TLS_RSA_WITH_RC4_128_SHA
      • TLS_RSA_WITH_RC4_128_MD5
      • SSL_CK_RC4_128_WITH_MD5
  • AngularJS version less than 1.7.9
    • Your MOVEit Transfer server may be flagged for utilizing a vulnerable AngularJS library. As of version 12.1, AngularJS code is no longer executed by MOVEit Transfer unless you have manually enabled the older JavaScript Wizard.
      • Affected Versions: 10.2 through 12.0
      • Fixed in Version: 12.1
    • Your server may still be flagged for this item even after upgrading to 12.1, because the AngularJS files still exist on the system. If you must resolve this item, please follow these steps:
      • 1. Take a full back of the MOVEit Transfer system.
      • 2. Save a copy of the entire jswiz folder from the (C:\MOVEitTransfer\wwwroot) folder,
      • 3. Delete the jswiz folder from wwwroot,
      • 4. Restart IIS
      • 5. Test that you can still upload and download.
      • 6. Scan your system again and ensure the item has been resolved.
  • lodash version less than 4.17.12
    • Your MOVEit Transfer server may be flagged for utilizing a vulnerable lodash library (CVE-2019-10744, CVE-2019-1010266). MOVEit Transfer 12.0 and above defaults to leveraging a REACT based upload/download mechanism. The aforementioned CVE's are only applicable if the default setting is overridden to utilize the legacy JavaScript Wizard.
      • Affected Versions: 10.2 through 12.1 (Note: See above comment for Transfer instances 12.0 and greater which still leverage the legacy Javascript Wizard)
      • Fixed in Version: TBD
__________________________________________________________________________________________

Non-Applicable Issues

Here are some known issues that are commonly detected on servers running MOVEit Transfer. The following issues have no security impact and are therefore not applicable. In some sense, they can be called false-positives, which is often used interchangeably with non-applicable. However, false-positive implies that the scanner shouldn't have detected the issue in the first place, but the Progress MOVEit Team does not dispute that these issues should be detected by scanners.
  • Microsoft ASP.NET 2.0 Request Filtering Bypass Cross-Site Scripting Vulnerability
    • While MOVEit Transfer(DMZ) versions up to and including 8.0 do use ASP.NET 2.0 (which is how the scanner detects this issue), the software does not rely on ASP.NET request filtering to protect itself from malicious inputs, including cross-site scripting attacks. In fact, the most commonly used ASP.NET-driven web pages in MOVEit Transfer(DMZ) are actually configured to disable ASP.NET request filtering. You can check this for yourself by opening MOVEitDMZ\wwwroot\human.aspx in Notepad; you should see the following string:
      • ValidateRequest="false"
    • Even for obscure pages where this feature is enabled, the MOVEit Transfer(DMZ) software always uses its own code to filter-out dangerous input. Any potentially malicious string which bypasses the ASP.NET 2.0 Request Filtering will still be caught by MOVEit DMZ code.
    • Since MOVEit DMZ does not rely on the ASP.NET 2.0 Request Filtering feature for protection in any supported versions, this issue does not apply.
  • Windows file path disclosures, Hosting product documentation on the MOVEit Transfer server
    • These issues are always detected in various pages of the MOVEitDMZ documentation located under the wwwroot\doc folder. The Windows paths referenced in the pages within that folder are static and based on installation defaults--they may or may not correspond to actual paths on your server--hence there's no real disclosure of information about your server in particular.
    • Ipswitch nevertheless understands that customers might not be comfortable with hosting product documentation on their servers. If you wish, you can delete the wwwroot\doc directory or move it somewhere else on the system. To remove links to the manual involves going into the DMZ web interface, then navigating to Settings | Display Profiles (under the Appearance header). For each display profile selected in the drop-downs at the top, click Edit on the corresponding display profile below, and un-check the Display "Online Manual" link box.
    • However, when considering whether to remove the manual from your server, bear in mind that this manual is already publicly available. In fact, in future MOVEit DMZ version 8.0 and later, links to the online manual will direct users to documentation hosted on an Ipswitch server, where the product documentation will remain publicly available.
    • Because the product documentation is (and will remain) public, there is no security impact for hosting it on your MOVEit Transfer(DMZ) server. Furthermore, the Windows paths contained within these pages do not necessarily correspond to real paths on your particular server, so this issue is not applicable.
  • Cookies not Flagged as Secure, HttpOnly
    • MOVEit Transfer(DMZ) uses many cookies, the vast majority of which correspond to harmless information that in some cases must be accessed by Javascript. With only one exception, MOVEit Transfer(DMZ) cookies are used for Upload/Download Wizard functionality and other preferences (such as the selected language and organization ID). An attacker would not be able to leverage the values of these cookies for any gain.
    • The one cookie that does require protection is the ASP.NET_SessionId cookie. When your MOVEit Transfer(DMZ) organizations are configured to require secure connections (as they are by default--this option is very rarely disabled), this cookie will have the Secure flag enabled. It should always have the HttpOnly flag enabled. You can verify this in Chrome's Developer Console by hitting F12 on your keyboard. Check it under Resources | Cookies | [your DMZ hostname]. You will see the cookies on the right, and the ASP.NET_SessionId will have HTTP and Secure checked.
    • Since the only cookie that requires this level of protection has these flags enabled, this issue is not applicable.
  • Microsoft Windows Unquoted Service Path Enumeration
    • If your scan is flagging this against your MySQL registry entry, this is a false positive. Given an example path of C:\MySQL\Bin\MySQLd-NT.exe MySQL, the actual path to the executable is C:\MySQL\Bin\MySQLd-NT.exe, which does not require quotation as it has no spaces.The MySQL at the end of the entry is a variable passed to the executable, not part of the path, and MySQL will not start if you put quotes around the entire entry.
  • jQuery Version greater than 1.0.3 and less than 3.5.0
    • This vulnerability will appear on security scans if the jQuery version being used is less than 3.5.0 but greater than 1.0.3. However, this is non-applicable as the MOVEit Transfer application does not directly utilize the function (jQuery.htmlPrefilter) determined to be vulnerable within the jQeury library per the published Common Vulnerability Exposures: (CVE-2020-11022, CVE-2020-11023).
      • Affected Versions: 10.2 through 12.0
      • Fixed in Version: 12.1
__________________________________________________________________________________________

False-Positives
The following issues are known to be false-positives; MOVEit Transfer's behavior in response to the scanner's test attack coincidentally aligns with the vulnerability signature, but in reality, the test attack was unsuccessful. This is often due to a broadly-written signature on the scanner's part.
  • Apache Struts2 Multiple Vulnerabilities (S2-008) QID 12542
    • MOVEit products do not use the Apache Struts2 framework in any way. The scanner is testing this vulnerability by sending a GET request to MOVEit DMZ containing Struts2-specific configuration options and an executable command in the URL string parameters. None of these parameters are recognized nor accepted by MOVEit DMZ--they are simply ignored--so the server simply returns the content of the default Sign On page, the same as if you tried to access the server with no added parameters. The scanner sees something in this response--which is simply the default, human.aspx Sign On page--that causes it to believe the server is vulnerable. Potentially, the fact that DMZ returned a non-error response to the attack is at issue.
    • While it remains unclear at this time as to why the scanner believes the server is susceptible to this vulnerability, it is simply not. Please disregard this false-positive finding.
  • XSS Vulnerability
    • Any XSS vulnerability that references the username value, or r or p value, is a false positive. The username value is reflected into the username field on the signon screen, and this is what flags the vulnerability scanner - anything inserted into this value is santized and is never executed by the application. The 'r' and 'p' values are not used by DMZ in any way, and as such are completely ignored. Likewise, anything inserted into these values is ignored and is never executed.
__________________________________________________________________________________________
 
Miscellaneous
Please review this section for issues that may be detected on servers running MOVEit Transfer. The following issues have little to no security impact, however they might show up on security scans. Also contained are general configuration options that promote security.
  • MySQL General Logging Disabled
    • Your MOVEit Transfer server may be flagged for MySQL general logging being disabled (This only applies to systems using MySQL as the database engine). In an effort to promote security, MySQL general logging is intentionally disabled as it may reveal customer input that would otherwise not appear within the MOVEit Transfer logs. If you would like to enable this option, see instructions at this link.
  • MySQL Remote Connections
    • The built-in MOVEit MySQL engine has remote connections disabled by default. Vulnerability scanners may see that the MOVEit Transfer server is listening on port 3306 and that is why it is getting flagged. If you attempt to connect to MySQL you should get access denied and/or not allowed by default. You can try connecting to your MySQL instance remotely using MySQL Admin tools, telnet, or command line to verify.
  • Setting X-Content-Type-Option nosniff
    • You may want to enable X-Content-Type-Option 'nosniff' within IIS to prevent browsers from performing MIME-type sniffing. Follow the below steps to enable via IIS.
      • 1. Open IIS Manager and on the left hand tree, left click the site you would like to manage.
      • 2. Double click the “HTTP Response Headers” icon.
      • 3. Right click the header list and select “Add”
      • 4. For the “name” write “X-Content-Type-Options” and for the value “nosniff”
  • Potentially Insecure Content Security Policy
    • MOVEit Transfer utilizes the following Content-Security-Policy (CSP): (default-src 'self' ; script-src 'self' 'unsafe-inline' 'unsafe-eval' ; style-src 'self' 'unsafe-inline' ; img-src 'self' data: ; media-src 'none'). Unsafe-eval and Unsafe-inline may be reported as vulnerable to cross-site scripting (XSS) attacks. After review, it was determined that this is a low to medium severity and we are considering removing the unsafe directives from the CSP in a future release. Please see our official documentation for more on our built-in HTTP Security Headers.
Workaround
Notes
Last Modified Date4/8/2021 9:26 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.