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]
Message-ID: <3F39A012.15373.4DA12425@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Windows Dcom Worm planned DDoS

"Andrew Thomas" <andrew@...erator.co.za> to me to him:

> > > The examinations of the code so far indicate that the worm is
> > > coded to DoS the windowsupdate site from the 15th of August 
> > > onwards through the end of the year.
> > 
> > I'll ignore the sloppiness in that description, as several of the 
> > published descriptions have (or at least initially got) it confused 
> > through slightly wrong too...
> 
> The examinations of the code *that I have read so far* indicate 
> that...?

I've seen "15 August", "from 15 August" and "after 15 August" use dto 
describe the trigger for windowsupdate.com DoS payload.  All are 
incorrect.  The briefest of examinations of the trigger condition 
checks in the code show that first the date is checked for the current 
day of the month and if it is after the 15th, the DoS payload is run.  
If it is not after the 15th a second test condition is checked and if 
it is the eighth month or earlier the DoS payload is skipped.  Thus, 
assuming all inected machines' clocks are accurate, the DoS payload 
will start come 16 August and continue till the end of 31 December, 
then stop for fifteen days then run from 16 January till the end of the 
monthm stop for fifteen days, run from 16 February till the end of the 
month, et seq. until 16 August is hit again then run till end of year, 
et seq (there are no year tests, so the sequence runs ad infinitum).

> >And, of course, if MS started messing with the DNS entries for 
> >windowsupdate.com, it would be cutting an awful lot of users off from
> >much needed updates. which could be as disturbing as the rest of the 
> >worm's effects...
> 
> Still leaving large organisations and smaller ISP's free to make
> the decision themselves on whether the loss of Windows update
> is more or less important than the prevention of the additional
> spurious traffic.

I think cutting folk off from WindowsUpdate for about two-thirds of the 
year is quite unreasonable for any ISP.

> In countries/situations where bandwidth is paid for by traffic 
> transferred, and is often quite expensive, I suspect that more 
> decisions will be made to eliminate access to WindowsUpdate, 
> at least for a period of time, rather than paying for excess
> traffic generated. 

I understand your situation (my current deal doesn't involve a traffic 
charge component, but DSL connections here do and where I used to work 
we charged for Internet service by bandwidth used) but still feel that 
cutting off WindowsUpdate for two-thirds of the year is unreasonable.

And perhaps you are looking at it the wrong way?  Perhaps getting a 
hefty traffic bill due to unwittingly taking part in such a DoS might 
make some folk sit up and start to take the security of their machines 
seriously (all too often the "there's nothing of value on my machine, 
so why secure it" attitude can only be countered by a rude shock such 
as a hefty network traffic bill.

> It's more than a matter of degraded service.

True, but the degraded intellects that run such easy target machines as 
end up taking part in things such as this worm's DoS network are often 
only fixed through a swift kick in the gonads...


Regards,

Nick FitzGerald


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ