Chris Linfoot | A Domino open relay?

Wednesday, 2. June 2004

A Domino open relay?

OK. This one's got me really puzzled.

We have two of these from the same Domino host over night. The source is different in each case but both are probably trojaned proxies (this sample is from 24.184.138.147). The first received header in both cases is a forgery.

The timing of the real received headers is consistent and shows that the relay happened almost immediately.

We received this one at Tue, 1 Jun 2004 16:37:29 +0100 which is Tue, 1 Jun 2004 15:37:29 UTC
The abused Domino host received it at Tue, 1 Jun 2004 21:07:33 +0530 which is Tue, 1 Jun 2004 15:37:33 UTC (so their clock is slightly fast)

The thing is, ORDB says this Domino host doesn't relay though it very clearly has - and this sample was relayed after ORDB had tested it!

I have even tested it myself the old fashioned way and met with "554 Relay rejected for policy reasons."

The message is not a bounce and has not been relayed using SMTP AUTH - Domino records "with ESMTP" in its received header when ESMTP is used and the abused host has only recorded "with SMTP" (though it did subsequently relay the message to us with ESMTP). So it must be a simple relay.

Is there some vulnerability or regression in Domino 6.0.1 that permits relaying, perhaps with some archaic but RFC correct RCPT TO envelope? Anyone out there care to hazard a guess as to what may be going on here?

From: "Jolene Toney" <probably_spoofed>
Message-ID: <forgery>
To: blanchard[at]tacogroup.com
Subject: Corel Photo rqwy Painter 8 
Date: Tue, 01 Jun 2004 10:37:39 -0600
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
          charset="windows-1251"

Category: Domino: Administration
Technorati: Domino: Administration

Comments :

1. Chris Linfoot03/06/2004 12:25:01

I know - responding to my own post

Just wanted to mention that the total count of messages received here from this compromised Domino 6.0.1 server now stands at seven!

We have not blocked the IP address but have created a mail rule to move messages from this host to a spamtrap so that users will not see them - I want more samples to I can try to figure out what is happening.

2. Nathan T. Freeman03/06/2004 16:50:06

How about, the IP address that hit the Tacogroup Domino server is permitted to relay by explicit IP permission for [24.184.138.147]? It would make sense, since if it's a worm-based message, it may have searched a user's local Outlook address book and hit on a colleague from the office (blanchard@tacogroup.com).

I've been trying to find information on Tacogroup. They're identifiable on Google, but their web server is given as simply "tacogroup.com" and it's not reachable right now (207.106.22.15.) The cached stuff on Google, frankly, looks like demostration data. It's just a bunch of weird bios for Asian CEOs.

3. Nathan T. Freeman03/06/2004 16:52:07

Here we go...

http://www.tata.com/tata_autocomp/

4. Chris Linfoot03/06/2004 17:19:23

If IP [24.184.138.147] has permission to relay, then so do:

[68.57.154.193] Comcast, USA
[207.134.178.153] Telus, Canada
[66.222.141.113] Telus, Canada
[68.80.8.42] Comcast, USA
[67.173.41.40] Comcast, USA
[81.130.120.225] BT, UK
[81.98.105.98] NTL, UK

[24.184.138.147] is Optimum On-Line, USA

The one thing they all have in common is that they are all proxy servers (and their users are presumably unaware of this).

I rather doubt that the administrator of this Domino server (in India) has configured it to accept relays from known dynamic pools in the USA, the UK and Canada and seeming chosen at random...

5. Nathan T. Freeman03/06/2004 21:31:12

True enough. Did you check the release notes at LDD for 6.0.2 updates that might have dealt with a relay issue? I have a hard time believing there's some old bug there, though it's certainly possible.

6. Chris Linfoot04/06/2004 12:50:08

The worry is that it might be a bug that has not yet been reported, still less fixed

7. Chris Linfoot07/06/2004 08:39:43

Update: as of 03:07 UTC+0100 Monday, 7th June, 2004, the count of messages from this host trapped here stands at 45.

All are spam. All are from different relay IPs. All of these relay IPs are dial-up/dynamically assigned (DSL/Cable) being used as proxies, probably due to trojan/worm infections.

The USA is the winner with 18 of these 45 proxies/relays. Korea and Canada tie for 2nd place with 5 each. The UK and Japan have 3 each. The remaining proxies/relays (1 or 2 per country) are in Belgium, Bulgaria, China (a huge surprise, scoring only one), Germany, Spain, Israel, Mexico, the Netherlands and Norway.

8. Christian Brandlehner08/06/2004 22:00:45
Homepage: http://chris.brandlehner.at

I am dealing with a similar problem with Domino accepting blank from headers with incoming SMTP emails. Try the following example with your server:

telnet mail.yourdomain.net 25
helo relay-test
mail from: <>
rcpt to: <doe_not_exist_here@yourdomain.net>
data
subject: This will be delivered as a NDR to somebody else
from: <poor_victim@iris.com>
This is some text in the message body.
.

At the moment I don't have an easy solution for that, only thing that might work here is a mail rule.

Christian

9. Chris Linfoot09/06/2004 08:26:40

Two things.

1. These spams are not "bounce" spams.

2. It is possible to defeat this kind of abuse using "Verify that local domain recipients exist in the Domino Directory:" - you don't need mail rules.

10. Christian Brandlehner14/06/2004 07:32:00
Homepage: http://chris.brandlehner.at

ad 2) Unfortunately "verify that local domain recipient exists in the Domino directory" does not work in Domino xSP configuration with hosted organisations in Domino 6.5.1. I am currently in contact with IBM Lotus Support to get this fixed.

11. Chris Linfoot21/07/2004 09:45:54

Solved:

http://chris-linfoot.net/plinks/CWLT-5ZSBL3

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