Re: worldwide DDOS (sql server fun)
In message <005701c2c4b1$165b1a80$0c01a8c0(a)saarinen.org>, "Juha Saarinen" writes:
Joe Abley
wrote: http://news.bbc.co.uk/1/hi/technology/2693925.stm Although I remain dubious about this claim: "Unlike viruses, the worm exists only in memory, so it cannot be detected by traditional anti-virus scanners."
I'm not sure which bit you're dubious about: the "only in memory" or the "cannot be detected by traditional anti-virus scanners". The only in memory has been identified by various people starting to disassemble it. Various useful links (that have come through Bugtraq):
From "Jay D. Dyson"
:
http://www.kb.cert.org/vuls/id/370308 http://www.kb.cert.org/vuls/id/399260 http://www.kb.cert.org/vuls/id/484891
From H D Moore
:
http://www.digitaloffense.net/worms/mssql_udp_worm/ (which contains some disassembly screen shots, and a unannotated disassembly)
From cstone
http://www.boredom.org/~cstone/worm-annotated.txt (which contains an annotated disassembly)
From what I can tell it's just a worm, spreading itself as fast as it can. Presumably the vulnerable hosts thus identified are then prime targets for something else to come in as a second wave.
There's nothing in the annotated disassembly that indicates writing/sending data anywhere other than the Internet, hence "only in memory". Various people report that the infection can be cleared by stopping SQL server and/or rebooting -- with the obvious caveat that if it's not disconnected/firewalled from possible sources, it'll be reinfected quickly. As for "cannot be detected by traditional anti-virus scanners", that's probably a fall out of not writing anything to disk (which could be scanned), and memory protection in modern OS (which means the "memory scan" phase of DOS-based virus scanners is limited to the memory space the anti virus scanner is running in, without kernel support). Presumably a debug API or similar could be used to scan all memory, but I don't recall seeing that type of technique in (m)any anti-virus programs. Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Ewen McNeill
There's nothing in the annotated disassembly that indicates writing/sending data anywhere other than the Internet, hence "only in memory".
Yes, the worm is sending data to randomly selected hosts over the Internet, but not writing anything to disk (or doing the usual virus writer self-aggrandization stuff like popping up dialogs on the screen, etc). Interesting -- the worm process only exists as long as there are unpatched SQL Server installations connected to the Internet. Time to have a "Reboot Your SQL Server" day...
As for "cannot be detected by traditional anti-virus scanners", that's probably a fall out of not writing anything to disk (which could be scanned), and memory protection in modern OS (which means the "memory scan" phase of DOS-based virus scanners is limited to the memory space the anti virus scanner is running in, without kernel support). Presumably a debug API or similar could be used to scan all memory, but I don't recall seeing that type of technique in (m)any anti-virus programs.
It could be as you say a "drawback" of the memory protection in Windows 2000. If the AV can't access memory used by SQL Server and/or associated processes which are being compromised by the worm, then presumably it won't be able to see identifying traits like the worm generating a long Registry key name (which is never saved) and loading system DLLs (which, as they're not infected, won't raise alerts even if the AV scans them on loading). Seeing that the worm sends out large amounts of data indiscriminately, should a Red Alert go out to those unfortunate ISP customers that are paying 20c/MB yet cannot filter out traffic aimed at TCP/UDP 1434? -- Juha - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (2)
-
Ewen McNeill
-
Juha Saarinen