Chris-Linfoot.net

• Although this configuration has been running for some considerable time without incident, recently Johnny Spammer did a port scan against the Domino server and found SMTP answering on an unexpected port. After this an exploit was inevitable - it was only a matter of time.
  
  
• Next, JS attempts to exploit his new relay directly and meets with failure. However there can be few reasons to have SMTP listening on a non-standard port and it doesn't take a genius to work out that if SMTP is also listening on port 25 then a spam proxy is in use and the SMTP on the non-standard port is only expecting to hear from that proxy. Now, what might its address be? 127.0.0.1 seems a likely bet.
  
  
• SMTP uses TCP. TCP packets can be large (large enough for an entire spam to be contained in one packet). TCP source addresses may also easily be spoofed. Of course, if you do spoof the source address then your SMTP client spamware will never see any responses back from the server (like 220, 250, 354, 221 and so on) but if your aim is just to get an unwanted message onto someone else's delivery queue, you don't want to be troubled by minor details like that.
  
  
• So, JS crafts a single TCP packet bearing a spoofed source address (127.0.0.1) and containing the entire SMTP transaction from HELO to . complete with <CR><LF> where needed, then fires it at the non-standard SMTP port of the target system. He repeats this a large number of times.
  
  
• Result: A large number of messages on Domino's delivery queue and a large number of open connections from 127.0.0.1 (they never get closed properly in this scenario).

So. Why weren't these messages, being entirely from non-local senders and mainly to non-local recipients, rejected as relays by Domino? If they had been, there'd be no dead messages in mail.box, not 19,000 as we see here (the open SMTP sessions from 127.0.0.1 would still be evident). And Domino has been configured to reject not just relays, but all email coming from non-local hosts.

Well, yes. But 127.0.0.1 has been exempted from relay checking, hasn't it? So any message from that IP address will be accepted regardless of the sender's or recipient's email addresses.

Why were 19,000 emails dead in mail.box? Because they were addressed to non-existent recipients and Domino failed to deliver them. It then failed to bounce them because the spoofed sender addresses also did not exist. It seems possible, though, if not actually probable that some spam and some backscatter did get through.

So, what did we learn?

1. Your firewall is your best friend.
   
   Use it to lock down every port not specifically needed to be open from the outside. On an SMTP server, you need only DNS (TCP/53 and UDP/53 outbound), SMTP (TCP/25) and optionally SMTP TLS (TCP/465).
   
   If the non-standard SMTP port had been locked down at the firewall then a) the port scan would not have revealed it and b) it would not have been possible to connect to it from the outside anyway, even using a spoofed TCP source address (the best the hacker could manage would be a LAND attack and any well maintained firewall should be immune to that).
   
   
2. Be careful who you permit to relay even if you think you trust them.
   
   Other forms of attack are possible using localhost, particularly on a Microsoft server platform. Hint: think malware.
   
   In this scenario, it isn't necessary to give unrestricted relay access to localhost anyway. Once the firewall restriction is in place then you can relax the Domino block on external addresses and enforce relay restrictions normally for all IPs including loopback.
   
   
3. This may be another reason to consider reducing MTU size in the server OS.
   
   A single spam in a large TCP packet is only possible where permitted by a large MTU size. I doubt this exploit would work if the spammer's spoofed TCP packet were fragmented in transit.

Category: Domino: Administration
Technorati: Domino SMTP

1. Richard Schwartz12/04/2006 05:19:05
Homepage: http://www.rhs.com/poweroftheschwartz

Nice analysis. I'm not so sure that reduced MTU size would have any impact. The sending side uses its own MTU and lets routers along the way deal with fragmentation if needed. On the receiving side, packet reassembly happens down in the depths of the TCP/IP stack. The SMTP server should not even be aware that it happened.

What I don't know is how the attacker got past the TCP SYN handshake, which should have involved several packets. But I imagine that this is probably child's play for experienced crackers.

2. Alan Bell20/04/2006 10:46:43
Homepage: http://www.astoryforbedtime.com

wow, that is very clever. At least the spammer wasted a lot of their bandwidth doing this.

3. Chris Linfoot21/04/2006 09:36:33

Possibly not if he used a botnet to execute the attack. And this sort of attack is actually very widespread as people do not seem to realise that this type of vulnerability is actively exploited or even exists...

4. person19/05/2006 21:26:48

Yea, I was wondering about the tcp handshake too; maybe predictable sequence numbers?

Unable to post a comment? Please read this for a possible explanation...