Mailing List Archive

> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 12:52 PM

<...>

> Meng was thinking about SES/CBV during his shower this morning and
> wondered if we'd addresses the problem of replay attacks yet. If a
> spammer gets his hands on a good SES return-path, can't he send out a
> spam with return-path? CBV would pass.

We probably have not fully addressed that, so let's try. Yes, a replay
attack would definitely work. SRS rewritten addresses are similarly
vulnerable to replay attacks, as far as I can tell. Both SES and SRS
addresses are protected by the same timestamp field, so the usefulness of a
harvested address would be time limited in both cases.

The real question here is how easy is it to harvest a signed envelope
address, regardless of the signing protocol? When I originally brought this
up as a possible exploit against SRS to Shevek, his answer was to not send
email to spammers and then they wouldn't have your signed return-path.
Though I groused about it at the time, that really was a pretty good answer.
If you don't send email to spammers, how _would_ someone go about harvesting
signed envelope addresses?

Thinking about this further, a full signed return-path address should never
appear in an MUA anyway. I say this since the Return-Path: header in a
successfully delivered message cannot, by definition, be used to send a
legitimate DSN. Therefore, the signed address has no legitimate use at this
point since it will not accept normal (non-DSN) mail. I think you will have
to address this same issue as you integrate SRS functionality into the MX
modules you are developing. My guess is that you will end up unwrapping the
SRS-rewritten address down to the unsigned source address buried inside it
and putting that address in the Return-Path: header.

If you make this implementation choice, what methods are left to harvest
signed return-paths? A malicious party could hack the mailer to get it to
divulge the full signed return-path, but then harvesting signed
return-path's is the least of your concerns. I can imagine eavesdropping on
the network connecting the MSA's to the MTA's, but if the signing takes
place in the MTA, this wouldn't get you anywhere. Eavesdropping on the link
between an MTA and the border router is perhaps the best place to do
mischief, but that would be a dedicated link in any sane implementation and
someone on the inside would have to cut cables and install hardware without
detection. Sounds like a job for 007, though M would have to agree.
Eavesdropping on the lines exiting the provider's border routers is
imaginable, but that's not trivial even on the T1's or DS-3's that small
providers use and pretty much impossible (without detection) on the fiber
links used by most other providers.

Perhaps I'm missing something basic, and if so, I'd appreciate you clueing
me in, as usual.

--

Seth Goodman

On Thu, Apr 29, 2004 at 02:57:14PM -0500, Seth Goodman wrote:
|
| Thinking about this further, a full signed return-path address should never
| appear in an MUA anyway. I say this since the Return-Path: header in a
| successfully delivered message cannot, by definition, be used to send a
| legitimate DSN. Therefore, the signed address has no legitimate use at this
| point since it will not accept normal (non-DSN) mail.

If an SES message has a dozen addresses on a CC line, and one of those
addresses is a web archiver, another is a regular user, and a third
address bounces, the same message with a single SES

- has been successfully delivered,
- is the cause of a DSN,
- is exposed to the web.

On Thu, Apr 29, 2004 at 02:57:14PM -0500, Seth Goodman wrote:
| > Meng was thinking about SES/CBV during his shower this morning and
| > wondered if we'd addresses the problem of replay attacks yet. If a
| > spammer gets his hands on a good SES return-path, can't he send out a
| > spam with return-path? CBV would pass.
|
| We probably have not fully addressed that, so let's try. Yes, a replay
| attack would definitely work. SRS rewritten addresses are similarly
| vulnerable to replay attacks, as far as I can tell. Both SES and SRS
| addresses are protected by the same timestamp field, so the usefulness of a
| harvested address would be time limited in both cases.

I should be clear --- when I say "replay attack" I mean a spammer gets
his hands on an SRS/SES address and sends mail *using it* as the return
path. That attack works for SES, doesn't work so well for SRS/SPF.

An SRS address would (presumably) have SPF protection so a replay attack
wouldn't work. If SES addresses refuse SPF protection (and if they
decline SRS, they refuse SPF protection) then replay attacks do work.

The vulnerability Shevek responded to was where the spammer uses an SRS
address as the *recipient address* to send spam to the original sender.
In this situation, under both SES and SRS the original sender gets the
spam, but this case is of limited interest outside the 5-player SRS1
game which Shevek has already solved by adding the "never shortcut"
subclass.

> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 3:07 PM
>
>

<...>

> I should be clear --- when I say "replay attack" I mean a spammer gets
> his hands on an SRS/SES address and sends mail *using it* as the return
> path. That attack works for SES, doesn't work so well for SRS/SPF.
>
> An SRS address would (presumably) have SPF protection so a replay attack
> wouldn't work. If SES addresses refuse SPF protection (and if they
> decline SRS, they refuse SPF protection) then replay attacks do work.
>
> The vulnerability Shevek responded to was where the spammer uses an SRS
> address as the *recipient address* to send spam to the original sender.
> In this situation, under both SES and SRS the original sender gets the
> spam, but this case is of limited interest outside the 5-player SRS1
> game which Shevek has already solved by adding the "never shortcut"
> subclass.

This would be true for normal (non-DSN) spam, but for SRS, a spammer would
abuse a harvested address is by sending the spam as a DSN. Since a DSN has
a null-sender, SPF checks based on the HELO name. If I understand SRS
correctly (and perhaps I don't), if you can obtain a valid SRS-rewritten
address, you can send a DSN to that address from any machine whose HELO name
and SPF record will allow it to pass an SPF check. That's not much of a
hurdle. If what I've said is true, harvesting an SRS or an SES address
makes you equally vulnerable to spam, though through different mechanism.

--

Seth Goodman

In <20040429175132.GU5369@dumbo.pobox.com> Meng Weng Wong <mengwong@dumbo.pobox.com> writes:

> On Thu, Apr 29, 2004 at 12:42:04PM -0500, Seth Goodman wrote:
> |
> | Meng has produced and published slides which correctly, IMHO, argue that the
> | some of the cost burden of email needs to be shifted from the recipients to
> | the senders. At the same time, he has argued that CBV's are too costly and
> | that major providers would likely not buy into any scheme that relies on
> | CBV's.
>
> Meng is probably wrong about that --- major providers *are* doing CBV
> today, eg. Verizon.

Does Verizon really do CBV on each and every email? I thought they
would just do probes to make sure that you aren't an open relay and
such.

I went through my email logs and couldn't find a single case of
sending or receiving a non-spam email from verizon, so I can't tell.
Lots of spam though.



> today, eg. Verizon. So CBVs are obviously not too expensive for major
> providers to do, especially if their mail servers are centralized enough
> to take advantage of clever things like memcached.

Well, I have used CBV off and on for the last year or two. Right now
it is off because of problems with Yahoo Groups failing and it was
easier to turn CBV off than excempt Yahoo.

So, I'm not anti-CBV, I just know that I've run into quite a few
email-clueful people who are.



-wayne

On Thu, Apr 29, 2004 at 05:15:07PM -0500, Seth Goodman wrote:
| This would be true for normal (non-DSN) spam, but for SRS, a spammer would
| abuse a harvested address is by sending the spam as a DSN. Since a DSN has
| a null-sender, SPF checks based on the HELO name. If I understand SRS
| correctly (and perhaps I don't), if you can obtain a valid SRS-rewritten
| address, you can send a DSN to that address from any machine whose HELO name
| and SPF record will allow it to pass an SPF check. That's not much of a
| hurdle. If what I've said is true, harvesting an SRS or an SES address
| makes you equally vulnerable to spam, though through different mechanism.
|

If a spammer can get his hands on the return-path, SRS makes the sender
vulnerable to spam directed to that return-path, yes.

But SES makes the sender vulnerable to spoofing --- a spammer could send
mail *as* that SES address to a bazillion recipients. You'd have to
dynamically invalidate the SES address and hope enough people do CBV.

> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 3:03 PM

<...>

> If an SES message has a dozen addresses on a CC line, and one of those
> addresses is a web archiver, another is a regular user, and a third
> address bounces, the same message with a single SES
>
> - has been successfully delivered,
> - is the cause of a DSN,
> - is exposed to the web.

Just like any other MTA, we would expect the web archiver to use an
SPF/SRS/SES compliant front end which would unwrap the signed return path
into an unsigned Return-Path: header. If the web archiver is broken enough
that it saves raw signed addresses and exposes them to the web, customers
that use either SRS or SES would not use their service and they would either
change their configuration or suffer a significant loss of business. I
suggest this problem would rapidly self-correct, just like broken mailing
lists that use MAIL FROM: rather than the From: header for user
confirmation. Losing customers is a terrific motivator for change.

--

Seth Goodman

In <MHEGIFHMACFNNIMMBACAIEPDHMAA.sethg@GoodmanAssociates.com> "Seth Goodman" <sethg@GoodmanAssociates.com> writes:

>
> The real question here is how easy is it to harvest a signed envelope
> address, regardless of the signing protocol? When I originally brought this
> up as a possible exploit against SRS to Shevek, his answer was to not send
> email to spammers and then they wouldn't have your signed return-path.
> Though I groused about it at the time, that really was a pretty good answer.
> If you don't send email to spammers, how _would_ someone go about harvesting
> signed envelope addresses?


When SRS is used by forwarders, they have quite a bit of control over
who they send email to. If you uses SES and send email to anyone who
requests sales info, or whatever, signed envelope address harvesting
is much more of a serious concern.


-wayne

On Thu, 2004-04-29 at 18:22, Meng Weng Wong wrote:
> On Thu, Apr 29, 2004 at 05:15:07PM -0500, Seth Goodman wrote:
> | If what I've said is true, harvesting an SRS or an SES address
> | makes you equally vulnerable to spam, though through different mechanism.
> |
>
> If a spammer can get his hands on the return-path, SRS makes the sender
> vulnerable to spam directed to that return-path, yes.
>
> But SES makes the sender vulnerable to spoofing --- a spammer could send
> mail *as* that SES address to a bazillion recipients. You'd have to
> dynamically invalidate the SES address and hope enough people do CBV.

Could the SES address contain a truncated body checksum? If so, and a
modifier as discussed earlier today were able to be used by the sender
to specify what sort of checksum is included, the actual SES format
used, what body headers are included, and so forth, the recipients
*could* do body checks.

Even a truncated body checksum could help against that sort of replay
attack.

(Of course, most people here don't like body checks. Having only small
domains, I wouldn't mind doing checksum verifications on every incoming
email at MTA time, rejecting all mails for which the checksums fail,
which I imagine is not the case for many people here. However, I wonder
if the dislike of doing body checksum verifications on receipt
translates into a dislike of writing checksums on transmission, since
most domains will of course send much less mail than they receive.)

--
Mark Shewmaker
mark@primefactor.com

On Thu, 2004-04-29 at 18:22 -0400, Meng Weng Wong wrote:
> But SES makes the sender vulnerable to spoofing --- a spammer could send
> mail *as* that SES address to a bazillion recipients. You'd have to
> dynamically invalidate the SES address and hope enough people do CBV.

You do that anyway; they're timestamped. And web archivers tend not to
include the Return-Path in my experience. Hell, most don't even bother
to include the Message-Id (let alone include '&references=' in the
mailto: link if they have a reply link).

Yes, there's a replay window. It's short.

--
dwmw2

On Thu, 29 Apr 2004, Mark Shewmaker wrote:
>
> Could the SES address contain a truncated body checksum?

No, that makes it impossible for CBV to work.

--
Tony Finch <dot@dotat.at> http://dotat.at/

On Fri, 30 Apr 2004, David Woodhouse wrote:
>
> Yes, there's a replay window. It's short.

It has to be about a week, which is plenty long enough for viruses.
Although MDAs that know about SSAs will unsign the address before creating
the return-path header, there will for a long time be many MDAs out there
that don't know about SSAs and therefore leak addresses in a way that
allows them to be found by viruses.

Thus MXs should have a mechanism for automatically revoking SSAs that get
used too much. "Too much" is hard to define: it depends on the number of
recipients of the original message (perhaps this should also be encoded
in the SSA), the maximum Received: path (there may be a CBV for each hop),
and the number of possible DSNs (more than one for each recipient in the
case of quota delays, vacation messages, etc.).

Unfortunately this requires per-SSA state to be maintained on the MX,
which we have been trying to avoid through use of crypto. It's
particularly unpleasant for clustered MXs.

--
Tony Finch <dot@dotat.at> http://dotat.at/

On Fri, 2004-04-30 at 05:26, Tony Finch wrote:
> On Thu, 29 Apr 2004, Mark Shewmaker wrote:
> >
> > Could the SES address contain a truncated body checksum?
>
> No, that makes it impossible for CBV to work.

Why?

--
Mark Shewmaker
mark@primefactor.com

On Fri, 30 Apr 2004, Mark Shewmaker wrote:

> On Fri, 2004-04-30 at 05:26, Tony Finch wrote:
> > On Thu, 29 Apr 2004, Mark Shewmaker wrote:
> > >
> > > Could the SES address contain a truncated body checksum?
> >
> > No, that makes it impossible for CBV to work.
>
> Why?

How can the SMTP server validate the address if it doesn't have all the
information it needs? If the address includes a body checksum it can't be
validated until after the message body is seen, and the body is never
transmitted during CBV.

Note also that bounces often omit the body, so this kind of address can't
protect against collateral spam.

--
Tony Finch <dot@dotat.at> http://dotat.at/

On Fri, 2004-04-30 at 06:59, Tony Finch wrote:
> On Fri, 30 Apr 2004, Mark Shewmaker wrote:
> > On Fri, 2004-04-30 at 05:26, Tony Finch wrote:
> > > On Thu, 29 Apr 2004, Mark Shewmaker wrote:
> > > >
> > > > Could the SES address contain a truncated body checksum?
> > >
> > > No, that makes it impossible for CBV to work.
> >
> > Why?
>
> How can the SMTP server validate the address if it doesn't have all the
> information it needs? If the address includes a body checksum it can't be
> validated until after the message body is seen, and the body is never
> transmitted during CBV.

Ahh.

I was suggesting that the receiving MTA validate the checksum, not the
sending machine--the sending machine would just validate that the MAIL
FROM string as a whole checks out, (ie, that it's self-consistent and
hasn't yet expired), just as is done with SES today.

--
Mark Shewmaker
mark@primefactor.com

Mark Shewmaker wrote:

>>>>> Could the SES address contain a truncated body checksum?
>>>>
>>>> No, that makes it impossible for CBV to work.
>>>
>>> Why?
>>
>> How can the SMTP server validate the address if it doesn't have all
>> the information it needs? If the address includes a body checksum it
>> can't be validated until after the message body is seen, and the
>> body is never transmitted during CBV.
>
> Ahh.
>
> I was suggesting that the receiving MTA validate the checksum, not the
> sending machine

In that case, such a checksum could simply be added to the headers (like any
other signing scheme); no need to cramp it into an envelope_from address.
Anything you stick in an envelope_from, like used for SES, is only to
"validate" the recipient in the SMTP dialogue. If you suck in an entire
message, to calculate a checksum over it, then this checksum should really
just be part of that same DATA (in the headers).

No?

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

> From: Mark
> Sent: Friday, April 30, 2004 7:22 AM
>
>
> Mark Shewmaker wrote:

<...>

> In that case, such a checksum could simply be added to the
> headers (like any
> other signing scheme); no need to cramp it into an envelope_from address.
> Anything you stick in an envelope_from, like used for SES, is only to
> "validate" the recipient in the SMTP dialogue. If you suck in an entire
> message, to calculate a checksum over it, then this checksum should really
> just be part of that same DATA (in the headers).
>
> No?

Yes, it certainly could be included in the headers and others have proposed
this, as well. There is one advantage of including it in the MAIL FROM:,
however, and that is to foil spoofing based on the type of replay attacks
that Meng proposed. Harvesting an SES address does you little good if it
contains a hash of the message body and some headers, which your spam won't
match. It's not ideal, in that the MAIL FROM: would be accepted, but the
body check based on the hash embedded in MAIL FROM: would fail and you would
wind up rejecting the message at the end of DATA (ugh). Spammers could
certainly send this stuff out, but since they know in advance that it will
fail any checks, they have little incentive to go that route. It's very
similar to sending spoofed mail pretending to be from a domain that
publishes an SPF record. There's nothing stopping you from doing it, but
the likelihood of successful delivery is low. I think spam takes the path
of least resistance, kind of like a familiar substance that flows downhill,
and this does not sound like not that path.

--

Seth Goodman

> From: wayne
> Sent: Thursday, April 29, 2004 5:22 PM

<...>

> So, I'm not anti-CBV, I just know that I've run into quite a few
> email-clueful people who are.

Ditto here. There are definitely some people who really dislike CBV's.
When I've pressed for their reasons for objecting to it, I more often than
not get an emotional response rather than substance. I hate religious
arguments, as there can be no resolution. Still, these are folks who really
know their stuff, so their dislike of it has to be taken seriously.

--

Seth Goodman

In <1083279718.10805.108.camel@localhost.localdomain> Mark Shewmaker <mark@primefactor.com> writes:

>
> Could the SES address contain a truncated body checksum? [...]
>
> Even a truncated body checksum could help against that sort of replay
> attack.

You would have to make sure that you didn't truncate the checksum too
short. If a spam has 20 lines in it and you have a 20bit checksum, you
can create 2^20 variations of the spam by simply adding or deleting a
space at the end. Spammers can use to hundreds of thousands of
trojaned PCs to do this kind of calculation.

Then you also have the problem of things like mailing lists or MS
Exchange munging the email, thus causing the checksum to fail.


-wayne

On Fri, 30 Apr 2004, Seth Goodman wrote:
>
> Harvesting an SES address does you little good if it contains a hash of
> the message body and some headers, which your spam won't match. It's
> not ideal, in that the MAIL FROM: would be accepted, but the body check
> based on the hash embedded in MAIL FROM: would fail and you would wind
> up rejecting the message at the end of DATA (ugh).

In what way is this operationally different from putting the hash in the
header?

There isn't enough space for an address signature and a message contents
hash in the reverse path address. Since it must be possible to validate
the address reasonably securely in the absence of any other information,
the message content hash does not help. The message content hash is only
useful when you have the message content to check it against, so the right
place to put it is with the message content.

--
Tony Finch <dot@dotat.at> http://dotat.at/

> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 5:22 PM

<...>

> If a spammer can get his hands on the return-path, SRS makes the sender
> vulnerable to spam directed to that return-path, yes.
>
> But SES makes the sender vulnerable to spoofing --- a spammer could send
> mail *as* that SES address to a bazillion recipients. You'd have to
> dynamically invalidate the SES address and hope enough people do CBV.

That is true. It is equally true, however, for unsigned mail coming from
any host, and you don't even need to harvest a signed address to perpetrate
the spoof. Even if a domain publishes an SPF record, the only thing that
stops joe-jobs is if enough other people do SPF checks. Both SPF and SES
depend on the recipient to do the appropriate check. If they don't, neither
method will prevent forgeries.

In terms of dynamically invalidating an SES address that has been harvested,
one way to mitigate the damage that would normally do is to include a hash
of the body (and a few headers) in the SES address. If the hash had enough
bits (considering the birthday bound, you would roughly double the number of
bits needed to represent the daily outgoing traffic of the MTA), this would
effectively act as a message ID and the signed return path is now message
specific. Any SES host would reject such messages after DATA since the body
hash would not pass. This would be a big disincentive to even try this
spoof. Similarly, in an SPF world, people can still spoof domains that
publish SPF records, but it is largely a waste of time.

If you did have to invalidate a single message return-path, you would only
be giving up the possibility of receiving a valid DSN for that one message.
In fact, this causes no harm whatsoever. As Wayne pointed out, the likely
method of harvest would be from a general sales account for a large company.
If someone at a particular address harvests your signed return path, the
message was delivered and there will be no DSN, so you give up nothing by
disabling that return path signature.

Since the spammer must use that harvested SES address in a joe-job, the full
signed return path would be in the MTA log files of the spam targets. That
return path identifies the outgoing message and tells you exactly what
address harvested your return path, even if they used a compromised
broadband box (that doesn't have log files) to deliver the spam while hiding
their identity. That is something we cannot trace today: the remote
control source behind the broadband box spewage. You could then get the
spammers domain on RHSBL's, get all of their MTA's listed on IP DNSBL's and
get them listed in SpamHaus. Now we're getting somewhere in fighting these
dirtballs. If you then used the blacklists to check the destinations of
outgoing mail as well as incoming, you should be able to greatly reduce your
chance of having your address harvested.

Summarizing, if we put a body hash which also doubles as a message ID into
the MAIL FROM:, recipients have a method, albeit at the end of DATA, to
detect spoofs due to harvested SES addresses. Furthermore, as domain owners
and abuse desk personnel, now gain the ability to find out who harvested the
address, which identifies the actual spammer, who currently hides behind a
farm of zombie mailers that anonymize him.

--

Seth Goodman

> From: wayne
> Sent: Thursday, April 29, 2004 5:26 PM
>
>
> In <MHEGIFHMACFNNIMMBACAIEPDHMAA.sethg@GoodmanAssociates.com>
> "Seth Goodman" <sethg@GoodmanAssociates.com> writes:
>
> >
> > The real question here is how easy is it to harvest a signed envelope
> > address, regardless of the signing protocol?

<...>

>
>
> When SRS is used by forwarders, they have quite a bit of control over
> who they send email to. If you uses SES and send email to anyone who
> requests sales info, or whatever, signed envelope address harvesting
> is much more of a serious concern.

OK, that is reasonable. Let's agree that loosely managed accounts, such as
general sales accounts, are a not-too-difficult way to get a signed return
path sent to you, and you then just need access to the mailer logs to
harvest the full signed return path.

I think I've addressed this exploit in my post

MHEGIFHMACFNNIMMBACAGEPPHMAA.sethg@GoodmanAssociates.com

sent at 08:42:27 -500 April 30, 2004.

I would be interested in your critique to see if I've plugged the hole.

--

Seth Goodman

Not to belabor the point, and since I am in this thread a little late,
could someone please provide me a link to the CBV stuff so that I might
review the protocol?

Thanks in advance
Michael Weiner

In <4FD2C985D5E2A642AE25823DFD61C2B0C0E0D1@orca.agcom.amgreetings.com> "MW Mike Weiner (5028)" <MWeiner@ag.com> writes:

> Not to belabor the point, and since I am in this thread a little late,
> could someone please provide me a link to the CBV stuff so that I might
> review the protocol?

CBV == "Call-back Verification"

The idea is that when you get mail claiming to be from
"foo@example.com", you try to send a bounce back to that address. You
stop before you actually send the real message, so legitimate email
accounts won't get these test messages, but if example.com rejects the
email, you can be pretty safe in rejecting the email claiming to be
from them.

So, the sequence of events looks like this:

hacked-dsl.com connects to my-mta.com
hacked-dsl.com ->: HELO junk
my-mta.com <-: 250 Ok
hacked-dsl.com ->: MAIL FROM:<foo@example.com>

my-mta.com connects to example.com
my-mta.com ->: HELO my-mta.com
example.com <-: 250 Ok
my-mta.com ->: MAIL FROM:<>
example.com <-: 250 Ok
my-mta.com ->: RCPT TO:<foo@example.com>
example.com <-: 500 invalid user "foo"
my-mta.com <-: QUIT

my-mta.com <-: 500 call-back verification failed for <foo@example.com>

hacked-dsl.com ->: AUIT

It is important to always use a null envelope from (the "<>") when
doing a CBV to prevent loops where each domain keeps making additional
CBVs to eachother. For some reason, postfix uses the email address of
postmaster@my-mta.com (or whatever the domain) anyway.


Due to the overhead of TCP connection setup and teardown and the
slow-start TCP window size, a CBV is almost as expensive as actually
delivering email. All this has to be done *while* the original SMTP
session is taking place. Many people consider this "too expensive"
and claim that it "doesn't scale". I agree that it is kind of
expensive, but it will never go beyond a factor of 2. With email
volumes double every year or so, this just means that the resources
needed to do CBV in 2004 is what you would need in 2005 anyway.
Still, people complain about it.

A more valid complaint is that since spammers often forge email
addresses on large spam runs, if everyone did CBV, an small company
that has the unfortunate luck of being used by a large spammer can
have their MTA tied up for hours or days.



-wayne