Subject: [Asrg] Software bashing

From: Gordon Peterson <[email-masked]>
Date: Mon, 19 Jan 2009 14:47:09 -0600

> I see no reason why we should change (...snip...) in order to 
accomodate the thriving malware ecosystem made possible in large measure 
by the abysmally low quality of Microsoft products.

It doesn't advance the discussion in any useful direction to condemn any 
given software vendor.

The DOD/NSA for years has had bids out for totally "secure" operating 
systems and everything produced has either not been particularly secure, 
or hasn't been usable.

If 90% of all the computer workstations were running Linux, then the 
virus/malware authors would be writing viruses for THAT platform.  Same 
is true for Macs.

The problems in software engineering that result in holes and 
exploitable bugs are NOT limited to any specific platform or hardware 
architecture.

Besides, the problems of malware are not all due to unreliable software 
anyhow... phishing exploits are a good counter-example.

For all their many sins (including of omission), Microsoft has probably 
done more than ANY other vendor to automate and accelerate the 
distribution of patches to correct security problems.

-- 

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 22 Jan 2009 23:54:07 -0500

> virus/malware authors would be writing viruses for THAT platform.  Same  

This is nonsense: there *was* a time when most of the computer workstations
on this network were running Unix, yet we did not see massive malware
infections with network-wide negative impact on a recurring and persistent
basis.

We saw one.  Over twenty years ago.  And it was eradicated in 48 hours.

That's roughly 10000 times lower than the malware incidence rate for Windows.

And if this claim were true today, then we would expect to see
infected systems roughly in proportion to their deployment: if OS type
A was 6% of the population, then we would expect to see systems of OS
type A accounting for 6% of infections.

But we don't.  We don't see anything even remotely close to that.

( Actually, since Unix/Linux systems are vastly preferable targets --
thanks to their markedly superior capabilities and their frequent use
in security-critical applications, we should expect to see infection
rates somewhat *higher* than their population percentage.  We see
precisely the opposite. )

What we do see is a minimum of at least a hundred million compromised
Windows systems.  Credible and experienced observers have postulated
that the real number may now be two to three times that, and I've found
no contradicting evidence.

	( Of course, that speculation can't be directly proven or
	disproven, since any system which doesn't provide evidence to an
	external detector won't be observed.  Every those with very large
	numbers of detectors, e.g., the CBL, are no doubt missing large
	numbers of these.  Moreover, any system which has been zombied
	but which emits no traffic signalling that state will remain
	undetected indefinitely no matter how many detectors there are
	and how adept they are at noticing the signs.  Given what we
	know of abuser strategy and tactics, it seems very likely that large
	numbers of such systems are held in reserve. )

Whatever the "real" number is: it's very big, and getting bigger.
And there's no reason to anticipate that the trend will reverse, and
a number of reasons to believe it will get worse. [2]

But don't take my word for it: run the experiment yourself.  Turn on
passive OS fingerprinting in your perimeter devices (or on your servers)
and correlate that data with:

	- spam attempts
	- ssh attempts
	- ftp attempts
	- pop/imap attempts
	- port scans
	- crafted packet attacks
	- http-based exploit attempts
	- DoS attacks
	- etc.

After a year or two, I think you'll find is what I've found after running
this experiment in multiple environments of different sizes, characteristics,
purposes, etc.: the abuse problem is largely (in some cases, almost
exclusively) a Microsoft Windows problem. [1]  And it's clear that
the correlation far exceeds the population percentage, either as-observed
or as-guesstimated.  (Some of my sensors have gone for months without
detecting a non-Windows-originated ssh attempt, for instance.)

Incoming spam, for example, differentiates into three categories:
(a) zombies, and the number of non-Windows zombies is negligible;
(b) incompetently-run mail servers, e.g., Yahoo, Hotmail, of varying OS
composition; and (c) spammer-owned/leased mail servers, also of varying
OS composition.

And category (a) dominates - by attempts, by volume, by extent, by everything.
(Hardly surprising: it's the most cost-effective and anti-spam-resistant
method for abusers.  They'd be silly not to exploit it.)

This isn't a new observation nor is it original with me: note this
wonderfully clever hack, from almost exactly 5 years ago:

	openbsd's fingerprinting and shaping used for evil^Wgood
	http://use.perl.org/~merlyn/journal/17094

As a result, it's long since become part of my anti-spam and overall
security strategy to consider anything originating on a Windows system
as "suspect", at best, and to subject such traffic to (a) rate-limiting
(b) refusal (c) higher scrutiny and/or (d) modified services.  I highly
recommend this approach for anybody with the facilities to use it:
the results are striking.

---Rsk

[1] You'll also find that zombies are obviously acting in concert.  We've
known for years that a variety of techniques are used to coordinate their
activities: top-down control, P2P methods, etc.  It seems more than likely
that following incidents like the McColo shutdown that abusers will
reconsider and develop more resilient methods that are more resistant
to the loss of any control point.

[2] Among those reasons: I'm waiting for the use of virtualization by
malware, so that (a) the putative owner of the system can be sandboxed
into a VM which checks out as "clean" when scanned by anti-malware
products and (b) VM instances can be separately created and leased in
bulk, thus permitting multiple abusers to utilize a system's hardware
resources simultaneously.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Fri, 23 Jan 2009 00:10:19 -0500 (EST)

>> virus/malware authors would be writing viruses for THAT platform.
>> Same is true for Macs.
> This is nonsense: there *was* a time when most of the computer
> workstations on this network were running Unix, yet we did not see
> massive malware infections with network-wide negative impact on a
> recurring and persistent basis.

Yes, but there were some other important differences.  To name just the
first two that comes to mind, there was basically no money to be had
writing malware, and the network was substantially more heterogenous
than today's is.  ("Windows" now is not homogenous, no, but I believe
it's closer than "Unix" then was.)

Furthermore, the claim you're replying to is about what would be
written.  What sort of infection rates the resulting malware would
achieve are a separate question.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Fri, 23 Jan 2009 00:00:24 -0800

>detecting a non-Windows-originated ssh attempt, for instance.)

I'm commenting on the spam attempts only as I've been running an 
experiment on that since several years.  In general, most of the SMTP 
sessions from Windows hosts are spam attempts.  Passive OS 
Fingerprinting in combination with other heuristics can be quite 
effective in detecting spam attempts.

>the results are striking.

Such a strategy doesn't work well in some environments where there is 
a higher proportion of valid messages from Windows-based mail 
servers.  Some people might need an exception list if they implement 
the above methods.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Sat, 24 Jan 2009 07:31:20 +1200 (FJT)

Can we get more info and stats on the correlation of spam and fingerprinting of the OS?

We are a research group after all.

Now what happens to all the small businesses that use MS-Exchange to send email?

---

From: der Mouse <[email-masked]>
Date: Fri, 23 Jan 2009 14:49:12 -0500 (EST)

> send email?

The same thing that happens if they unwittingly pick someone on ROSKO
for a mailout house: they get a sharp lesson in why due diligence is
not only good but damn near essential, and how a non-spammer looking
enough like a spammer will get treated like a spammer.

I see no more need to support direct-to-MX-from-Exchange (or any other
package that evidences Exchange's level of imperviousness to
mail-handling clue) than to support an
unwitting-and-otherwise-legitimate client of a spam-for-hire house.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "John Johnson" <[email-masked]>
Date: Fri, 23 Jan 2009 14:19:34 -0600

> This seems an interesting thread and an interesting way of fighting spam.
>

Please take a look at the following paper - it appears it would impact
MS-Exchange less than you would imagine.

http://www.sans.org/reading_room/whitepapers/email/zombie_profiling_with_smtp_greylisting_33008

for a working sendmail specific milter example, I found this interesting:

http://www.elandsys.com/scam/

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 23 Jan 2009 15:22:10 -0500

> unwitting-and-otherwise-legitimate client of a spam-for-hire house.

Direct-to-MX-from-Exchange?  That's what it's _supposed_ to do.  It's
the MTA.  There are some annoyances in Exchange, but true infections on
Exchange servers are extremely rare.

ITYM: direct-to-MX-from-Outlook.  AFAIK Outlook _can't_ do direct-to-MX,
because it doesn't have the MX lookup code for it.  In fact, if you know
how to detect what _would_ be direct-to-MX from Outlook, it's a good
filtering rule.

[High volume/long term experience:  Moderate to high return at times,
zero FPs.  Tho, obviously, you shouldn't apply this on your outbound
submission servers!!!!!]

This probably applies to most other MUAs - they can't MX no matter what.

Our experience indicates that MTA servers, of _any_ flavour or O/S, are
seldom infected with anything viral or wormlike.  This is largely due to
the fact that "ordinary users" are virtually never reading or browsing
on the server, and the vast majority of current worm/viral compromises
require one or the other.

[Tho, in the face of a network spreader like SQLSlammer, all bets are off.]

Exchange may be worse than some other O/S/MTA combinations, but not by a
lot.  It's subject to sloppy admin/config, but so is everything else.

The real issue with "compromised" Exchange (or any other MTA) is more
things like poorly chosen passwords, not worm/viral.  Not exclusive to
windows by any stretch.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Fri, 23 Jan 2009 15:46:11 -0500 (EST)

>> [T]hey get a sharp lesson in [...] how a non-spammer looking enough
>> like a spammer will get treated like a spammer.

>> I see no more need to support direct-to-MX-from-Exchange [...]

> the MTA.

Right.  But it's an unusually badly behaved one.  Exchange is good
groupware with a bad MTA duct-taped onto the side.

> ITYM: direct-to-MX-from-Outlook.

You think wrong.  Look enough like a spammer and you can expect to be
treated like a spammer, even if you're not.  Someone using Exchange as
a world-facing outgoing MTA may not be a spammer, but will be running
Windows on what to the rest of the world is an SMTP client.  This looks
like a spammer from the perspective of this thread (which was about OS
fingerprinting of SMTP client hosts).  You wrote

> There are some annoyances in Exchange, but true infections on

which, even if true, is pretty much irrelevant without some way to tell
whether that Windows machine connecting to you is an Exchange outgoing
MTA or a direct-to-MX zombie.

Some would say that this makes it "impossible" to use this technique.
The stance behind my note is that Exchange is a bad enough MTA that the
pressure this technique would exert against it would be of net positive
value.

And if there were some way to identify Exchange, all its getting a free
pass would mean would be that bitnet herders would mass-install
Exchange on their zombies and send through it - or, perhaps even more
likely, just forge whatever Exchange indicator(s) get(s) widely used.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Steve Atkins <[email-masked]>
Date: Fri, 23 Jan 2009 13:07:54 -0800

> MTA or a direct-to-MX zombie.

Which is usually easy enough to tell by other approaches.

I see some legitimate email from Windows systems (Exchange, primarily,
but also a few others).

The majority of the spam I see in my inbox (which is filtered, but not
by anything that takes source address into account) comes, AFAICT,
from Linux boxes or email appliances (primarily linux based).

Compromised PHP boxes and spam coming from sources that emit
a mixture of spam and legitimate email dominate the traffic that
makes it to my inbox, AFAICT from a quick look.

Which doesn't tell me much, but does suggest that A) people blaming
Windows for all the net's ills may not be basing it on representative
traffic and B) research is likely useful, speculation probably isn't.

Cheers,
   Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 23 Jan 2009 16:41:29 -0500

> groupware with a bad MTA duct-taped onto the side.

That was true of archaic Exchange implementations.  Eg: the infamous
"Exchange 5" (aka IIS 5).  As was Sun Sendmail SMI 4.1.

But, reasonably recent Exchange is just fine in SMTP.

A consumer level site may see a different mix of MTAs than we do, but
it's been our experience that Exchange as an outbound is generally not a
problem, and we see lots of perfectly legit email from Exchange servers.

Many small-to-medium businesses lack the expertise to run something else.

I wouldn't dream of blocking an email based on a p0f signature of
"Windows" (tho, maybe Win95, 98 ;-) I'd score it.

> likely, just forge whatever Exchange indicator(s) get(s) widely used.

If there was some way to identify windows via passive O/S
fingerprinting, all that giving anything else a free[r] pass would mean
that the botnet herders would get something to fake that something else.

Hint: it's already in BOTs.  And that's _all_ I'm going to say about that.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Fri, 23 Jan 2009 16:01:39 -0800

>fingerprinting of the OS?

The following figures are not representative as the mail traffic is 
biased because of the user-base.  About 60% of identified SMTP 
sessions are from Windows hosts and 99% of the messages they sent 
were identified as spam.

>Now what happens to all the small businesses that use MS-Exchange to 

Either you discriminate against them and lose business or else you 
combine your fingerprinting with other heuristics to reduce its 
effect.  Some MS-Exchange hosts are behind non-Windows devices and 
the OS won't be detected as Windows.

Regards,
-sm

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 24 Jan 2009 07:08:40 -0500

> from Linux boxes or email appliances (primarily linux based).

You know what?  I see pretty much the same thing in my mailbox.

But that's after:

	- network perimeter filtering
	- system firewall filtering
	- numerous DNS existence and consistency checks
	- numerous SMTP protocol checks
	- numerous network allocation blocks
	- numerous (okay, huge) domain blocks
	- numerous subdomain blocks
	- numerous other blocks
	- DNSBls
	- RHSBLs
	- etc.

What finally makes it through doesn't look anything like what's trying
to make it through.  It's a fraction (roughly 1-2%) of the presented
SMTP traffic and very much unrepresentative.

I can say much the same thing about HTTP exploit attempts and SSH
brute-force attempts and all the other kinds of real/attempted abuse:
what's observed at the server level doesn't look much like what's
really incoming.

So the best place to measure this isn't your mailbox; it's on the
outer perimeter of your network -- at the packet level.

Or, to refine that slightly, on the outer perimeter of a network that
nobody knows you're associated with, since at least some abusers do seem
to make a point of at least trying to enumerate the ones where their
adversaries are watching.

> traffic and B) research is likely useful, speculation probably isn't.

I didn't blame Windows for "all the net's ills".

I said that the abuse problem is mostly a Microsoft Windows problem.
And, clearly, "abuse" is only one of the many things wrong with
the Internet.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 24 Jan 2009 07:33:59 -0500

On Fri, Jan 23, 2009 at 04:01:39PM -0800, SM wrote:
> combine your fingerprinting with other heuristics to reduce its effect.  

Exactly what I've done in some cases -- after observing something about
patterns of inbound mail on many different mail servers: in almost all
cases, the number of sources for mail (excluded spam-only sources)
is surprisingly small.  (Spare me the counterexamples, I already know
about them.)  If that number is weighted by message count, then the
resulting graph is pretty lopsided.

This means that it's actually reasonable to consider enumerating the
primary sources of mail and treating them differently.  In one setup
that I built, logs were analyzed to determine the top senders, who,
combined, accounted for 92% of all mail the site received.  Those top
sending networks were then presented with a DNS view that specified
a different MX order from the rest of the world, with the top MX's
configured with a firewall that only permits connections from those
senders.  They've also got greylisting turned off, and they don't impose
OS-specific rate limiting.

What happens if someone else grabs this DNS view and tries to hit
the "private" MX's?  They can't: firewall.  What happens if one of
those known sending sites starts using a different network allocation?
Then they get the same DNS view as the rest of the world, which specifies
the "public" MXs, for lack of a better term, and their mail still gets
through: just not as quickly and with more scrutiny.  But: since all
the logs are post-processed every day, and part of that post-processing
includes looking for exactly this situation, when it happens the DNS
view and firewall config will be updated to track the change, and soon
thereafter they'll be back to delivering to the "private" MX's.  (What
happens if they have their old DNS view but are sending from a new network?
They step through the MX list until they find the "public" ones.)

This kind of split-view essentially provides two tiers of mail service:
the "we know who you are" tier, and the "you look like a stranger" tier.
It requires detailed knowledge of mail traffic patterns, but IMHO anyone
running a mail server should already have that.  One of the nice things
about it is that it allows resources to be allocated where they're most
needed -- on the servers that will handle most of the real mail traffic,
as opposed to fending off abuse.

This isn't a new idea; I think possibly the only thing I added to it
was the use of passive OS fingerprinting on the "public" MX's, and in
practice, that's turned out not to be particularly needed because of
all the other blocking enabled on those.

---Rsk