3 ms·

SMTP Injection via recipient email addresses [pdf]

20 points by ogig 11y ago

aidos 11y ago
I actually saw this attack used in the wild just over 10 years ago – so I guess it's one that spammers have long since been aware of. In my case we had a server that was running Adobe Coldfusion suddenly start misbehaving itself. After digging around a little we discovered all the outgoing email. I can't remember the exact form but it was something like a forgot password mechanism. As described in the article the attackers were just exploiting the non-validation of the recipient so they could inject an smtp payload. I remember at the time thinking that it was a) clever of the hackers and b) sloppy of the entire pipeline to not be doing some sense checking.
lightlyused 11y ago
I'm guessing that they didn't test this on qmail because it is not vulnerable.
- amluto 11y ago
  Did you actually read the article, or are you just randomly claiming that qmail is superior? This is an attack against the SMTP protocol that is run through an SMTP client library. There is very little that an MTA could do to mitigate the attack. AFAIK qmail doesn't have an API that accepts untrusted input like this. It could be interesting to see whether there are similar attacks against local MTAs in which a malformed email ends up sending unexpected requests to the remote server when the local server tries to deliver it, but that's not what the article is about.
feld 11y ago
I found this paper a bit difficult to grasp due to the terminology being used. I kept thinking of completely different attack scenarios (communicating with port 25 directly, somehow MITM an SMTP session) and had to re-read it several times. It seems all we're doing here is just bypassing validation used by common libraries behind email forms on websites. You attack by using malicious input (full spam email message) in the "email address" section of the sign-up form and it successfully lands in the MTA's queue and sends out. It wasn't clear if this can be defeated simply by disabling pipelining? If so, that seems like a sane fix if you don't feel you can trust your application.

20 points by ogig 11y ago

aidos 11y ago

I actually saw this attack used in the wild just over 10 years ago – so I guess it's one that spammers have long since been aware of. In my case we had a server that was running Adobe Coldfusion suddenly start misbehaving itself. After digging around a little we discovered all the outgoing email. I can't remember the exact form but it was something like a forgot password mechanism. As described in the article the attackers were just exploiting the non-validation of the recipient so they could inject an smtp payload. I remember at the time thinking that it was a) clever of the hackers and b) sloppy of the entire pipeline to not be doing some sense checking.

lightlyused 11y ago

I'm guessing that they didn't test this on qmail because it is not vulnerable.

amluto 11y ago
Did you actually read the article, or are you just randomly claiming that qmail is superior? This is an attack against the SMTP protocol that is run through an SMTP client library. There is very little that an MTA could do to mitigate the attack. AFAIK qmail doesn't have an API that accepts untrusted input like this. It could be interesting to see whether there are similar attacks against local MTAs in which a malformed email ends up sending unexpected requests to the remote server when the local server tries to deliver it, but that's not what the article is about.

feld 11y ago

I found this paper a bit difficult to grasp due to the terminology being used. I kept thinking of completely different attack scenarios (communicating with port 25 directly, somehow MITM an SMTP session) and had to re-read it several times. It seems all we're doing here is just bypassing validation used by common libraries behind email forms on websites. You attack by using malicious input (full spam email message) in the "email address" section of the sign-up form and it successfully lands in the MTA's queue and sends out. It wasn't clear if this can be defeated simply by disabling pipelining? If so, that seems like a sane fix if you don't feel you can trust your application.