ietf-asrg
[Top] [All Lists]

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

2003-04-11 06:40:42
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg