[Dshield] cracking SoBig/SINIT/MyDoom, et alius

Erik van Straten emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl
Fri Feb 13 12:01:40 GMT 2004


John, Jayjwa,

On Thu, 12 Feb 2004 15:16:25 -0800 John Draper wrote:
>
> On Feb 11, 2004, at 3:36 PM, jayjwa wrote:
>
> > Let's place the blame where it belongs- not at some tele-virus
> > trans-continental spam-gang spreading viruses, but at home with
> > Mr. Joe Avg. User. Why? Because Mr. User opens mystery zip-files,
> > then proceeds to click on the attachment, that is clearly
> > labeled as an .exe. He runs notoriously vulnerable software from
> > a company with an awful track record for security.
>
> I agree,  this is the main cause.
>
> JD

This is nonsense. Much in our lives depends on trust. Life will be
unbearable for most if us without it. If you buy vegetables, you
trust the shop and the farmer that they have not poisoned it. We
cannot and will not all start running our personal chemical and
biological labs checking food we buy.

If someone rings my doorbell, says his car broke down and asks for
a phonebook, I'll get it. My wife had her leather coat stolen like
this. It does not mean we will distrust anyone (we'll be a bit more
careful though).

The MyDoom virus could have happened to any operating system user.
It is not based on bugs in an OS, perhaps just on bugs between the
ears of the user, but there are a LOT of people with these bugs
(please define "normal" and "common sense"). In contrary to what
Jayjwa states, most of them were not clearly labeled as an exe.
For example, MyDoom.A (this one obviously was not sent by Cisco
but other samples looked more convincing) - body.zip at bottom of
the following page:

http://seclists.org/lists/fulldisclosure/2004/Feb/0408.html
Contains MyDoom.A/NoVarg.A virus as an attachment body.zip.
Note, the filename is:
SFN: BODYTX~1 SCR        22,528  02-09-04  1:25p 
LFN: body.txt______________________________________________________________________.scr
(note: I have replaced 70 spaces by 70 underscores).

I expect to see a lot more of these social engineering tricks, and
they will get "smarter". It is a waste of time and resources
educating users on this, and they will also distrust other mail and
communications (generating increasing numbers of "false positives").
These social engineering tricks WILL happen to a Linux or MacOS user
near you. The morons who are spreading this shit are to blame and
should be prosecuted. This is not PoC, this is harassment.
Who's gonna pay the bill?

Some of us have become so "secured" that they start exhibiting very
strange behavior. For example, Jayjwa (who apparently fears telling
us his real name) has a fixation on source ports. After a strange
post from him in January I tried to explain to him, OFF-LIST, how
this IP stuff works. Here it is (I gave up after this 3d attempt):

On Mon, 26 Jan 2004 02:20:00 +0100 Erik van Straten wrote:
> To: "jayjwa" <jayjwa at atr2.ath.cx>
> Subject: Re: [Dshield] ISP's not blocking egress 25/tcp (was: spoofed address)
>
> NOTE: OFF-LIST RESPONSE
>
> ----------------------------------------------------------------------
> NOTE: this is my THIRD attempt to send you this mail. If I send from
> my MTA, cpo.tn.tudelft.nl, your MTA denies the connection. Thank you:
>
>   <jayjwa at atr2.ath.cx>: host atr2.ath.cx[64.179.12.45] said: 550 5.0.0
>     DENIED!THIS MTA EATS SPAMMERS FOR LUNCH (in reply to MAIL FROM command)
>
> I am now relaying via another MTA. If you reply, I will send any reply
> on your mail via my own MTA. If that fails, I'm sorry. I will not retry
> any other route. You are not being very kind...
> ----------------------------------------------------------------------
>
> Hi Jayjwa,
>
> Sorry for the late response, I was quite busy (discussing with Wietse
> Venema among others :)
>
> You're mixing up some things. Firstly, blocking egress (outbound) SMTP
> traffic does NOT imply blocking ingress (inbound) traffic. They are 2
> different things.
>
> Like good old snail mail (the letters with postmarks on them), email
> usualy takes different routes. If the mailman brings your letters, he
> puts them in your mailbox. However, to send mail, you cannot put
> letters you write in that same mailbox and expect the mailman to take
> these with him (this process may be still be in use in some countries).
>
> Without an ingress 25/tcp block, ANYONE can put mail in your mailbox,
> and you can do your own filtering, blacklisting etc. This is entirely
> unrelated to an egress 25/tcp block.
>
> With an egress 25/tcp block, your PC (mailserver) can ONLY hand over
> email to your ISP's mailserver, this is called a smartrelay. They will
> take care of the delivery. It is comparable to putting your paper mail
> in the mailbox at the street corner, to have the postal service take
> care of delivering it. Blocking egress 25/tcp prevents YOU from going
> to another town and posting a letter there. You are forced to use the
> mailbox (colored red in most countries) on the streetcorner. This has
> advantages and some disadvantages, which are discussed on the DShield
> list.
>
> However, ingress 25/tcp filtering (which I was NOT discussing on
> DShield) does not only have disadvantages. For example, we have it
> enforced on our university network. It is bad because I cannot simply
> use the blacklists I'd like to use. It is good because the MTA's on the
> campus perimeter (border) that do accept mail, are BIG boxes and have a
> good virusscanner. This prevents a lot of problems on campus (hardly
> any viruses, and no performance problems with on-campus mailservers
> during external virus outbreaks).
>
> Regarding your IP port remarks. IP communicates through sockets. A
> socket is a combination of an IP-address and a port number. An
> IP-address is (currently) 4 bytes, a port number is 2 bytes. The
> numbers are really irrelevant. To communicate you need 2 sockets:
>
> a.b.c.d:p <-> w.x.y.z:q  (p and q are ports, a.b.c.d is your IP).
>
> To start a communication with a remote PC you need to know 2 things:
> the IP-address and the protocol you want to talk. The portnumber is
> irrelevant. However, it would be a waste if everytime you want to start
> an SMTP connection, you'd have to try all ports on the remote PC to see
> which one talks the SMTP protocol. Therefore, a long time ago, people
> agreed that if you have an SMTP server, it should listen on port 25 for
> incoming connections (but you can have an SMTP server listen on any
> port you like).
>
> When you send mail, your PC starts an SMTP connection with the SMTP
> server you specify. Before sending anything, your PC allocates an
> unused LOCAL port number > 1024 and uses that as a source port (allocate
> means find the first unused number > 1024, then mark it as "in use").
> The number is irrelevant. Let's asume it's 1031. What happens:
>
> a.b.c.d:1031 -> w.x.y.z:25
>
> If the server w.x.y.z listens on port 25, and accepts connections from
> you, it will reply to a.b.c.d:1031 that you may talk (it knows that
> your PC expects answers to port 1031, because your PC sends that
> info to the server in every IP packet, including the first one).
>
> As you probably see, contrary to the destination port 25, the source
> port is absolutely irrelevant. It usually is a number between 1025
> and 65535 (both inclusive). These are so called unprivileged ports,
> because long time ago people figured that 1024 reserved ports would
> suffice for every imaginable service.
>
> Therefore, if YOU run your own server that accepts incoming mail
> (which, as you should understand by now, is a process totally unrelated
> to sending mail), you will see remote clients using such high port
> numbers. This is expected behavior.
>
> NOTE: some admins may run an SMTP server that listens on an unpriv.
> port. There are various reasons to do that. But this does not imply
> that the same port is used when the server acts as a client; on the
> contrary, definitely another port will be used.
>
> HTH,
> Erik
>
> On Fri, 23 Jan 2004 14:10:51 -0500 jayjwa wrote:
> >
> > On Thu, 22 Jan 2004, Erik van Straten wrote:
> >
> > > I have been advocating blocking egress 25/tcp traffic on our campus,
> > > with the exception of some legitimate mailservers (like mine :).
> > > However, because of some issues (that can probably be fixed), and
> > > perhaps because our main MTA is blacklisted, this measure is not yet
> > > effective (it certainly does not help). Thank you SORBS.
> > >
> > > Is anyone aware of advantages or complications of blocking outbound
> > > SMTP that I missed?
> >
> > The trouble is, everyone wants _their_ server clear, but everyone else's
> > blocked (on ISP's networks, your example above). I don't use my ISP's MTA,
> > but my own. I'd hate to think what my inbox would look like, had I opted
> > to use theirs. To be sure, they will let in far more than I ever would.
> > They kind of have to; because of their size and number of clients, they
> > can't do the broad, blanket blacklisting that I do. SomeNetwork just
> > mailed SPAM to me for the 10th time this week? Banned. That works here,
> > because no one knows anyone on that network anyway. If configured
> > properly, I think that users running their own mailservers instead of
> > using their ISP's can be even more resistant to SPAM. If an admin notices
> > a large amount of outbound traffic coming from a client's mailer, then he
> > can take action, but those of us that don't SPAM and use our servers
> > correctly shouldn't be punished. Plus, I've seen many cases where a server
> > will sit  around, up on a higher port, say 5550, and send from there. If
> > you can confirm the source of a SPAM, take a look at the computer that
> > sent it out. Many times it's a Windows-WinNT machine running a mailserver
> > on a high port. I doubt a legit company is mass-sending email from a
> > Windows 98 machine from port 5685 =)
> >
> >
> > [jayjwa]RLF#37

P.S. if my basic explanation of IP is wrong, please correct me!

Jayjwa: it's not my intention to make a fool of you. I know that having
your email address published on mailinglists causes one to be spammed
(which is one reason I'm not using my regular address but a discardable
one instead). However I'd appreciate if security specialists stop
stating that ordinary people -who try to live normal lives- are stupid
for being tricked into something definitely not obvious. Instead, I
suggest we start thinking (and discussing) technical solutions to
prevent these attacks from happening, preferrably anticipating on
future "developments" in social engineering tricks.

Regards,

Erik van Straten
- still believing that most people deserve to be trusted -




More information about the list mailing list