Subject: Re: [Asrg] 1. inventory of problems draft 2

From: Brad Spencer <[email-masked]>
Date: Fri, 11 Apr 2003 08:39:13 -0500

If I may I'd like to add a few comments:

At 07:30 AM 4/11/2003 -0400, Paul Judge wrote:
>This is the Inventory of Problems document that was originally started by
>Liudvikas Bukys. I've made some changes based on feedback from others and
>myself. I thought that I sent this to the list after I sent the list of work
>items, but I could not find it to refer to it. Liudvikas will resume
>ownership of this document.
>
>Evading accountability
>         - forging envelope sender
>         - forging From header

Very typically they HELO with a false identity.

There's asymmetric IP spam sending - Ralsky used that in Dallas, don't know 
if he (or anyone) does now.  He had a link between a system with a fast 
internet connection and a system with a dialup line (could easily all be on 
the same system).  He spoofed the dialup IP in the packets sent out on the 
fast connection.  The reply packets came back through the dialup 
system.  The dialup lines were protected against outgoing port 25 traffic 
(so if a complaint was made the abuse desk "knew" the complaint was an 
error - it wasn't possible.)  If the complaint was accepted the account 
used for the dialup line was a throwaway - another was waiting to take its 
place.  (If ISPs simply watched for outgoing packets that claimed to come 
from a different space they could kill this technique.)

Using open proxies also helps evade accountability.

They also add false lines to the header.

>Exploitation of weak systems
>         - exploit open smtp relay
>         - exploit insecure web services (cgi formmail)
>         - exploit open proxies (HTTP CONNECT, HTTP)

If you subdivided there's an abuse wherein an open proxy in the same space 
as an MTA is used to submit relay email to the MTA.  As the proxy is in the 
same space the relay email source appears legitimate, if the MTA just 
checks on that basis.

And there's Jeem.

>Aggressive database generation
>         - directory harvesting (web, LDAP)
>         - name guessing & probing
>         - name guessing without probing [selling bogus data to others]
>         - inappropriate database sharing/selling

I've seen it reported that some organizations sell their mail logs.  I 
theorize that a rogue employee could steal addresses from email logs.  The 
logs have the email addresses of everyone who sends email through a 
particular MTA - easy to grep off, should be saleable. (P.S.  the ideal job 
for a spammer, if he also works, might be as an abuse desk person or as a 
system operator.)

>Inadequate opt-in
>         - no actual opt-in
>         - deceptive opt-in
>         - simple opt-in without confirmation

(I changed it to "simple" - "double opt-in" sets some people's teeth on edge.)

Simple opt-in isn't the problem.  It's fake opt-in that's the problem, and 
simple opt-in can be easily faked.  If the operator of the list is honest 
then that operator doesn't want to send to unwilling recipients and will 
use confirmed opt-in (so he can't be fooled by a fake.)  Confirmed opt-in 
works for the list operator, not the victim.  A spammer could have my 
confirmation and affidavits from someone saying I opted in.  All forged, of 
course.  What's the significance of opt-in - that the ISP requires it of 
it's bulk-email-sending customers?  Confirmed opt-in can be forged just as 
easily as single opt-in, if the ISP is willing to be gulled.  "Yep, I see 
the Pope's signature on that affidavit.  He opted in and forgot, that's 
all.  Carry on - sorry to bother you."

>Inadequate opt-out
>         - opt-out not implemented
>         - opt-out ineffective (pro forma removal from one list not all)
>         - opt-out untimely
>         - opt-out difficult to execute
>         - opt-out hostile (used only for address verification & enrollment
>in even more databases)
>
>Evasion of automated filters
>         - content randomization
>         - eyespace transformation
>                 - misspelling
>                 - punctuation and spacing
>                 - substitution of visually similar characters
>                 - html coding tricks
>                         - slice&dice tables
>                         - javascript-generated content
>                         - font size/color/background
>         - mime multipart encoding
>         - inclusion of non-spam chaff (visible or invisible)
>         - content in images, not text
>         - content in other external links
>
>Evasion of human caution
>         - fake DSN

DNS?

>         - fake content resembling common cgi-to-mail
>         - "returned your call", "your account has a credit", etc
>
>Not a real business
>         - spam as chain letter/pyramid, selling software and bogus data to
>the naive
>         - spam as DoS attack, no real solicitation in content
>
>False claims
>         - false claims regarding opt-in
>
>Fraud & Crime
>         - Nigerian 419
>         - eBay password/credit card theft
>         - payPal password/credit card theft

The recent post about what remains constant has some bearing here.  There 
may be a difficult trail to follow but the spammer has to give some 
information that somehow leads back to the spammer (at least for most 
spam.)  I recall my frustration in trying to get the telephone company to 
tell me how to find out who had rights to a particular 800 number, the 
number being the way to contact the relay spammer who had flooded me.  The 
FCC was also no help.

In other words, pay some attention to what is not obscured.  In the relay 
spam I've trapped with variable HTML comments sprinkled through it the 
comments aren't put within any URLs (as you know.)  One guy for a while at 
least had success from filtering out email that had the same comment 
repeated 3 or more times in one line - the evasion technique flagged 
spam.  The spammer I was trapping right about the time I heard that started 
varying the comment in every position in the spam to which he was adding 
HTML comments.  (Other of his spam wasn't obscured in the text at all and 
was invariant message to message.  He even forgot to vary the fake sender 
name through his list of fake sender names.)

Is there reason/need to add to the list the things done to obscure the 
source beyond the content of the spam itself?  Fake registration names, 
addresses, telephone numbers?  If whois queries reported the old 
information (after an information change) for a month would that hamper the 
spammers enough to matter?

What about this kind of deception:  for www.gabesgab.org there's no DNS for 
gabesgab.org but there is (or was yesterday) an entry for www.gabesgab.org?

Fake traceroutes?  

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 11 Apr 2003 10:19:26 -0500

> Very typically they HELO with a false identity.

Unless I'm missing something, aren't HELO commands optional and just
add, effectively, a comment from the sender MTA to the receiver MTA?
EHLO does provide information about the SMTP extentions that the
receiver MTA suppors, but it is still optional.

> There's asymmetric IP spam sending - Ralsky used that in Dallas, don't
> know if he (or anyone) does now.  He had a link between a system with
> a fast internet connection and a system with a dialup line (could
> easily all be on the same system).  He spoofed the dialup IP in the
> packets sent out on the fast connection.  The reply packets came back
> through the dialup system.

How did he get around the three way handshake of a TCP connection and
the random sequence numbers?  Did he have a back channel from the slow
system to the fast system?

> DNS?

Maybe, or maybe "Delivery Status Notification".  That is, the expaned
SMTP error codes.

-wayne

---

From: Brad Spencer <[email-masked]>
Date: Fri, 11 Apr 2003 10:50:49 -0500

>receiver MTA suppors, but it is still optional.

Duh.  I should have said HELO or EHLO.  They call themselves other than who 
they are when they connect; they even do that when they connect via an open 
proxy.

>system to the fast system?

Exactly.  The dialup IPs had the TCP/IP characteristics of a Cisco switch, 
so a switch may have been part of the scheme.

I think you could do this on a single system with both a high-speed and a 
modem link (spammers: cover your eyes, stop reading.)   Send (as far as the 
spamware is concerned) through the dialup but patch the code in the dialup 
routines after the packet is created to use the high-speed link driver 
rather than the serial line driver to send.  As you need a number of serial 
lines to handle the return packets you might need several systems sending 
on the serial line, if a single system can't support that number.  Bare 
lowest-end systems should suffice as a serial-line controller.  Alternately 
they could use a terminal server, if they could find one (aren't made any 
more, are they?  In truth I don't know but it would seem the main market 
for those is gone forever.)

I assume the main consideration is keeping the high-speed link running at 
near-saturation.  I can conceive of a scheme whereby the spoofed IPs are in 
another part of the country, with the return packets encapsulated in some 
packet and tunneled back to the origin, where they're made to look normal 
again and go back in to the appropriate driver.  That's slower: the 
solution is more dialups, so you can keep the high-speed link 
saturated.  Keeping it saturated means you're sending the maximal amount of 
spam.  I think you'd want an excess of dialups so that there's always a 
slight backlog of responses.

>Maybe, or maybe "Delivery Status Notification".  That is, the expaned

Oh.

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 11 Apr 2003 12:18:33 -0400

At 8:39 AM -0500 4/11/03, Brad Spencer wrote:
>Simple opt-in isn't the problem.  It's fake opt-in that's the 
>problem, and simple opt-in can be easily faked.  If the operator of 
>the list is honest then that operator doesn't want to send to 
>unwilling recipients and will use

Not 100% the case.  There is a significant problem from people 
entering false email addresses to avoid spam.  I think this is why so 
many web sites are "syntax checking" (incorrectly of course) email 
addresses, and requiring people to type them twice.  They seem to 
think these bouncing (or misdirected) email addresses are accidents. 
They aren't.  They are deliberate.

Admittedly I see this problem more than most because of my domain 
name, but I know that people are using "fake" addresses regularly.

>What about this kind of deception:  for www.gabesgab.org there's no 
>DNS for gabesgab.org but there is (or was yesterday) an entry for 
>www.gabesgab.org?
What's wrong with that?  (Or do you mean something other than, "there 
was no A record")?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg