Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: Hardening Postfix Against FTP Relay Attacks - Internet Security | DShield SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
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:

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 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
221 2.7.0 Error: I can break rules, too. Goodbye.


Johannes B. Ullrich, Ph.D.


2901 Posts
ISC Handler
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" ( ).
(source: )

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

119 Posts 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!


Sign Up for Free or Log In to start participating in the conversation!