Hardening Postfix Against FTP Relay Attacks

Hardening Postfix Against FTP Relay Attacks
Yesterday, I read an interesting blog post about exploiting XXE (XML eXternal Entity) flaws to send e-mails [1]. In short: It is possible to trick the application to connect to an FTP server, but since mail servers tend to be forgiving enough, they will just accept e-mail if you use the FTP client to connect to port 25 on a mail server. The mail server will of course initially see the "USER" and "PASS" commands, but it will ignore them. Initially, I considered this a lesser issue. A similar attack has been used in the past via HTTP proxies. HTTP proxies can also connect to port 25, and relay mail connections that way. But from my experience, mail servers tend to ignore them. For example: 220 mail.dshield.org ESMTP GET 221 2.7.0 Error: I can break rules, too. Goodbye. Connection closed by foreign host. However, (and thanks to Alexander, the author of the blog for pointing this out), it looks like the list of blocked command is limited to HTTP verbs: smtpd_forbidden_commands (default: CONNECT, GET, POST) List of commands that cause the Postfix SMTP server to immediately terminate the session with a 221 code. This can be used to disconnect clients that obviously attempt to abuse the system. In addition to the commands listed in this parameter, commands that follow the "Label:" format of message headers will also cause a disconnect. This feature is available in Postfix 2.2 and later. Only CONNECT, GET, and POST will be blocked by default. To extend the list, use the following line in your main.cf file for postfix: `smtpd_forbidden_commands = CONNECT,GET,POST,USER,PASS` I don't think either USER or PASS is ever used legitimately in SMTP. Instead, SMTP uses "AUTH" to log in a user. To test, just connect to the mail server via telnet or netcat: `$ nc localhost 25 220 mail.dshield.org ESMTP USER 221 2.7.0 Error: I can break rules, too. Goodbye.` [1] https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/ --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn	Johannes 3915 Posts ISC Handler Feb 20th 2017
Subscribe	Feb 20th 2017 3 years ago
Initially I thought that somehow /Postfix/ was vulnerable, but that is not the case. I would probably have understood the issue at hand if the text above: "It is possible to trick the application to connect to an FTP server" would have read "It is possible to trick a vulnerable XML-processing Java application to connect to an FTP server". One of the risks at hand is, if you have an internal mail server, the vulnerable Java application may cause your mail server to send an email while that vulnerable Java application /itself/ thinks that it is connecting to an FTP server (and executing an FTP command). A recipient of such an email may believe that the email actually originated from a /person/ within your organization, in particular if (outgoing) emails are provisioned with anti-spoofing measures such as SPF, DKIM and/or DMARC. What Johannes describes above, may help block such specific attacks. However, more risks exist as Timothy Morgan writes in "Java/Python FTP Injections Allow for Firewall Bypass" ( http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html ). (source: http://www.theregister.co.uk/2017/02/21/java_python_ftp_code_vulnerable/ ) Erik van Straten (somehow my name is not displayed anymore when I post when logged in)	Erik van Straten 126 Posts
Quote	Feb 21st 2017 3 years ago
Does postfix normally have this option in their config file? I couldn't seem to find it in mine. I've since added it though, thanks for the tip!	Anonymous
Quote	Feb 21st 2017 3 years ago

Yesterday, I read an interesting blog post about exploiting XXE (XML eXternal Entity) flaws to send e-mails [1]. In short: It is possible to trick the application to connect to an FTP server, but since mail servers tend to be forgiving enough, they will just accept e-mail if you use the FTP client to connect to port 25 on a mail server. The mail server will of course initially see the "USER" and "PASS" commands, but it will ignore them.

Initially, I considered this a lesser issue. A similar attack has been used in the past via HTTP proxies. HTTP proxies can also connect to port 25, and relay mail connections that way. But from my experience, mail servers tend to ignore them. For example:

220 mail.dshield.org ESMTP
GET
221 2.7.0 Error: I can break rules, too. Goodbye.
Connection closed by foreign host.

However, (and thanks to Alexander, the author of the blog for pointing this out), it looks like the list of blocked command is limited to HTTP verbs:

smtpd_forbidden_commands (default: CONNECT, GET, POST)

List of commands that cause the Postfix SMTP server to immediately terminate the session with a 221 code. This can be used to disconnect clients that obviously attempt to abuse the system. In addition to the commands listed in this parameter, commands that follow the "Label:" format of message headers will also cause a disconnect.

This feature is available in Postfix 2.2 and later.

Only CONNECT, GET, and POST will be blocked by default. To extend the list, use the following line in your main.cf file for postfix:

smtpd_forbidden_commands = CONNECT,GET,POST,USER,PASS

I don't think either USER or PASS is ever used legitimately in SMTP. Instead, SMTP uses "AUTH" to log in a user. To test, just connect to the mail server via telnet or netcat:

$ nc localhost 25 220 mail.dshield.org ESMTP USER 221 2.7.0 Error: I can break rules, too. Goodbye.

[1] https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Johannes

3915 Posts
ISC Handler

Feb 20th 2017

Initially I thought that somehow /Postfix/ was vulnerable, but that is not the case.

I would probably have understood the issue at hand if the text above:
"It is possible to trick the application to connect to an FTP server"
would have read
"It is possible to trick a vulnerable XML-processing Java application to connect to an FTP server".

One of the risks at hand is, if you have an internal mail server, the vulnerable Java application may cause your mail server to send an email while that vulnerable Java application /itself/ thinks that it is connecting to an FTP server (and executing an FTP command).

A recipient of such an email may believe that the email actually originated from a /person/ within your organization, in particular if (outgoing) emails are provisioned with anti-spoofing measures such as SPF, DKIM and/or DMARC.

What Johannes describes above, may help block such specific attacks.

However, more risks exist as Timothy Morgan writes in "Java/Python FTP Injections Allow for Firewall Bypass" ( http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html ).
(source: http://www.theregister.co.uk/2017/02/21/java_python_ftp_code_vulnerable/ )

Erik van Straten (somehow my name is not displayed anymore when I post when logged in)

Erik van Straten

126 Posts

Does postfix normally have this option in their config file? I couldn't seem to find it in mine. I've since added it though, thanks for the tip!

Anonymous