lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 04 May 2004 22:09:41 +0200
From: Gadi Evron <ge@...uxbox.org>
To: Marc Maiffret <mmaiffret@...e.com>
Cc: NTBUGTRAQ@...TSERV.NTBUGTRAQ.COM, bugtraq@...urityfocus.com,
   full-disclosure@...ts.netsys.com
Subject: Re: New LSASS-based worm finally here (Sasser)


Marc Maiffret wrote:

> One thing most people fail to note when speaking of
> vulnerability-to-worm timelines shrinking is that your basing your
> timeline off of when a vulnerability is disclosed, to when a worm is
> discovered, NOT when a worm is released. The importance of this is that
> your timeline is not specifically based off of when the "bad guy"
> decides to do a bad thing and more so when the "good guys" discover a
> "bad guy" has done something bad.

Usually I would agree, but as you mention below in your post security 
and AV companies have come a long way in detecting worms faster since 
the days of code red. The time between when a worm is released and when 
it goes "in the wild" is called seeding time. In many occasions a worm's 
success is pre-determined by how well (or not so well) the VX-er seeded 
the worm in the first few hours to days.

> With all of these security companies scrambling to be first (even if
> they have nothing intelligent to say, other than some nifty name for the
> worm) it means they are investing a lot of resources into being the
> first to detect these worms. Which means that as their detection
> capabilities grow, the timeline of how quickly they are able to detect a
> worm is going to shrink. Which therefore can help lead to the appearance
> (right or wrong) that worms are being released faster, when in reality
> it is that they are now being detected faster.

I agree, we do not have enough data to determine if worms are being 
released faster as a trend, but it sure appears that they do. We do get 
a lot more worms nowadays though, so things even out. I think things are 
going faster now but I don't believe a full research was done on this 
particular issue before (I am probably wrong).

> Take CodeRed for example... There was about a weeks time where many
> Microsoft IIS web servers were being crashed and "no one" understood
> what was happening. There is much evidence of this if you look at any
> Microsoft newsgroups around the time of CodeRed. So there is a week, or
> maybe even more, that the worm had been released (which changes the
> timeline) but no one knew about it. Now today, in some ways due to the
> fame of CodeRed, worms are sexy and appealing to companies and media
> alike... And therefore they get a lot more attention. We would never
> have the case today where there would be public discussion of web
> servers randomly crashing for a week without people figuring out there
> was a worm on the loose (Well I shouldn't bet on other peoples
> intelligence, but... ;-). 

I agree 100%, but that is not a good enough reason to reply, so -
This started from the issue of the usefulness of an historical 
perspective.. so.. let us get factual.

Network worms are nothing new and in fact "original-named" worms were 
network worms (rather than email). However, although honey pots and 
honey nets were always in use, until around the time of code red they 
weren't the main tool the AV industry used for finding new threats. The 
threats invented the means, and in this case it was just re-enforcing 
the use of honey pots.

I believe there are a couple of articles about this by Costin Raiu on 
the web which may be interesting to demonstrate AV-used honey pots.

> In the real world most of these discussions about timelines of
> vulnerability-to-worm do not matter, depending on your goal. For me
> personally I think the goal is trying to create as much accurate threat
> awareness as possible. We do not need to get down to the number of
> specific days of this worm vs that worm to know that for a fact there
> have been a few worms lately that have been released/discovered within a
> timeline that is shorter than a month or two. For any company that is a
> data point to think hard about, and how your company handles security.
> Are you running around putting out fires every time some kid has a bad
> day and writes a worm, or are you being proactive and pitying your
> peers?

Well, I agree that in the end it doesn't matter much exactly how long it 
takes for the worm to show up. But let us get back to the fact that a 
worm nearly always does - knowing that and being prepared is what 
matters and I do believe that is the point you were trying to make, so 
although I agree exact timing is not that important, I don't really see 
why the timelines do not matter?

	Gadi Evron.

-- 
Email: ge@...uxbox.org. Backup: ge@...p.mx.dk.
Phone: +972-50-428610 (Cell).

PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104  C0D0 A7B3 1CF7 D921 6A06
GPG key for encrypted email: 
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA  569A A87E 8DB7 06C7 D450

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists