Mailing List Archive

| guess. I am using hashlength=8, so I don't think this will be very successful
| other than annoying my milter. The attempts are from AOL and YAHOO.
| The hash values seem to be random, rather than sequential. I am getting
| them on all of the mail servers and domains I manage.

Could you please post details of an attack transaction? I would be
interested in seeing HELO and MAIL FROM data, etc.

begin Saturday 20 March 2004 01:35, Meng Weng Wong quote:
> We should maybe move this thread to srs-discuss.
>
> On Fri, Mar 19, 2004 at 07:30:55PM -0500, Stuart D. Gathman wrote:
> | More interesting, I am getting a pile of attempted bounces to lowercase
> | SRS signed users - each with a different combination in the hash.
> | Someone is repeating a timestamp, and trying lots of combinations of
> | hashes to try and find a good one - and counting on the case folding to
> | reduce combinations I guess. I am using hashlength=8, so I don't think
> | this will be very successful other than annoying my milter. The attempts
> | are from AOL and YAHOO. The hash values seem to be random, rather than
> | sequential. I am getting them on all of the mail servers and domains I
> | manage.
> |
> | I guess this means spammers are taking notice of SRS, and seem to be
> | planning on a brute force attack.
>
> But even if they manage to brute one particular combination, that still
> doesn't let them guess the key ...

But, depending on how the SRS is set up (i.e. integrated into the
MTA), "one particular combination" may unfortunately be just as good
as a key. Indeed, if the spammer has obtained one valid encoding of an
e-mail address that he controls, he may use this to trick the server
into revealing the encoding of whatever other address he wants: just
send a forged mail "from" the address that he wants to encode "to" the
encoded address that he already has.

Just lemme explain by example:

1st step:
Spammer tries to find out (through brute force, or through bugs)
what is the SRS encoding of one address that he controls:

From: dummy@nowhere.com
To: SRS0=fdgWtWqA=GR=spammer.cx=evil@victim.com

===> If the spammer succeeds, he has now a valid encoding for an
address he control (can read)


2nd step:
Use this Address to translate addresses of his recipients:

From: spamrecipient@yahoo.com
To: SRS0=fdgWtWqA=GR=spammer.cx=evil@victim.com

||
||
\/

From: SRS0=aWDFEQzx=GR=yahoo.com=spamrecipient@victim.com
To: evil@spammer.cx

===> evil@spammer.cx now knows encoding of spamrecipient@yahoo.com!

What has happened:
(1) Victim.com has _decoded_ the SRS "To"
(2) At the same time, it has _encoded_ the spam recipients' "From"


===> with a single SRS cookie, the spammer can generate as many others
as he feels like
===> if his cookie nears expiry, he just needs to inject another
address that he controls (maybe hidden as a spamrecipient...), and he
has a new "fresh" cookie!


Limitations of this algorithm
-----------------------------
1. Lots of effort needed to find initial cookies
2. The spammer is forced to reveal one of his own addresses to make
the scheme workable.
3. It obviously wouldn't work if the recipient has SPF (because in
that case, victim.com would not accept the forged probe.

Why a spammer might do this anyways
-----------------------------------
1. Effort only needs to be spent once.
2. Revelation of his own address is not tragic to the spammer: just use a
throwaway hotmail.com or a .cn address
3. SPF is still not widespread enough to significantly cut into the
number of potential recipients. So, this is obviously an attack that
works "best" now that SPF has not a wide penetration. Its main goal
would not be to spread spam, but to discredit SRS by converting SRS
hosts into unwitting open relays.

What we can do about it:
------------------------
1. Do not apply SRS encoding for mails where we already do SRS
decoding.
2. Or, only apply encoding for From eaddresses whose domain publishes SPF
3. (or maybe easyer to implement): only apply SRS decoding if From is
<> or <postmaster@ ... >
4. Some throttling mechanism (limit number of SRS encoding /decoding
operations per minute that come from a same IP or IP range)

Regards,

Alain

On Sat, 2004-03-20 at 15:03 +0100, Alain Knaff wrote:
> What we can do about it:
> ------------------------
> 1. Do not apply SRS encoding for mails where we already do SRS
> decoding.
> 2. Or, only apply encoding for From eaddresses whose domain publishes SPF
> 3. (or maybe easyer to implement): only apply SRS decoding if From is
> <> or <postmaster@ ... >
> 4. Some throttling mechanism (limit number of SRS encoding /decoding
> operations per minute that come from a same IP or IP range)

I do #2 -- in fact I only apply encoding when the reverse-path has an
SPF record _and_ I know the recipient domain is checking it.

I also do #3. Nothing but bounces should _ever_ go to SRS addresses;
there's no excuse for accepting mail with non-empty reverse-path to
them, except perhaps for the special case of postmaster@ to work around
pobox.com's broken CBV.

--
dwmw2