Slashdot Mirror

From the report, I gather they want to define security and then they can make sure they meet that definition. Make the rules and play by them, at least in legal terms.

With Retina at $995 for 16 IP's, this additional gunpower for OSS will really keep the commercial vendors on their toes.

Maybe this will create a better turn-around time for M$'s "Security Initiative" too... Oh, wait, it's 4/2!

The Spread of the Witty Worm

March 19, 2004

An analysis by Colleen Shannon (cshannon@caida.org) and David Moore (dmoore@caida.org) of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis.

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

• Witty was the first widely propagated Internet worm to carry a destructive payload.
• Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
• Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
• Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
• Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

• In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both

The Spread of the Witty Worm

March 19, 2004

An analysis by Colleen Shannon (cshannon@caida.org) and David Moore (dmoore@caida.org) of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis.

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

• Witty was the first widely propagated Internet worm to carry a destructive payload.
• Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
• Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
• Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
• Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

• In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both

The Spread of the Witty Worm

March 19, 2004

An analysis by Colleen Shannon (cshannon@caida.org) and David Moore (dmoore@caida.org) of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis.

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

• Witty was the first widely propagated Internet worm to carry a destructive payload.
• Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
• Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
• Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
• Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

• In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both

Eh. The one I found appeared to be a valid bug that's been about half-fixed; some sort of mailing list search feature that doesn't work consistently. It's been followed up to several times, but the commit that seemed to fix most of it seems to be late 2003 vintage for a bug that was submitted in late 2001.

Granted, it's not a malicious-code-exploit bug, and it's not all that serious ... but like I said, I spent two minutes looking ^^; (Not that I'd expect to find tons of stuff on the order of the reports linked to in my parent, but I think debunking something like this is best achieved by focusing on other bits of the report first.)

On the other hand, if parent had said something like "sitting on bugs for months without saying anything", I'd have probably agreed fully.

OpenOffice does not have a dedicated development or support rteam.Consequently,if bugs go unresolved,users have the option to resolve problems by scouring through numerous community sites and chat rooms.

Here's a kicker: when a security audit was planned for one of the machines, DOI pulled the plug when they knew it would be getting scanned!

Without knowing the rules of engagement, I'd say this sounds totally justified, based on the apparent equation of "security audit" with "scan". A lot of the bozo "security auditors" who rely on scanning (because it's cheap) instead of actual auditing don't bother to secure the traffic between their company's network and the target of the scan. Meanwhile, they may require you to poke a big hole in your perimeter just to let their scan in. Consequently, any vulnerabilities in the target system get exposed to any observer on the network path. In these cases, it's better to pull while the idiots scan, report the idiot to your local inspector general, and then do the audit yourself with the scant funds left over after the idiots (still) get paid.

Furthermore, pulling the system in advance of the scan may have been the prescribed response to detecting the scan's imminence based on IDS logs or other activity. Again, we need to know the actual rules of engagement to know whether the admins were avoiding their duties or fulfilling them.

Auditing security is a lot more complex than running nmap or Retina. Doing it properly is expensive and time-consuming, and involves understanding the system and network architecture, mapping out trust relationships, logging into systems and auditing their patch levels and network and process profiles, groveling through code, possibly lots of it, possibly incoherent and uncommented, etc. Too many vendors want to come in with scanners and charge a queen's ransom for a couple of hours of real work, without providing any real security.

Umm... I'd like to know how Microsoft explains these.

As for real security experts, they routinely find vulnerabilities in Windows beforesending a description to MS which would then, a few months later, issue a patch. Maybe.

There is a fine line between marketing and outrageous lying. I'm glad to see that MS gleefully steps over it every single time. Any other conduct would actually be unsettling. You see, we geeks revel in a binary vision of the world, and we cannot thank MS enough for consistently being a caricature of evil villain. It makes working against them so much more rewarding.

Perhaps David Aucsmith would care to explain this then? Though eEye (purposely) doesn't describe the vulnerabilities that they list there, it's been indicated (on mailing lists like Full-Disclosure) that several of them are being actively exploited.

I think nows a good place to post a link to eeye's upcoming advisories page

I wonder if any of the leaked source code includes the MS crypto system. If so, this could be very bad news for Microsoft seeing how people have already discovered a slew of critical vulnerabilities but are biting their tongues to wait for MS to fix the flaws. Now you have a bunch of crackers running their debuggers on actual source code... they are going to craft and use exploits before they're public knowledge or officially fixed.

M$.com

^is and was fixed prior to the release of the bug...I think?

More info from the people that found the specifics

\/
eeye.com

Correct me if I am wrong...isn't that the same bug that is being exploited?

Does A. Russell Jones know anything about security??? It doesn't appear so from this article. This reads like something written by some un-informed CNN reporter from 1989. Did this guy do any investigation before spewing forth such ignorant dribble???

Governments "get what they pay for"? Are you kidding me? Governments typically pay FAR MORE for FAR LESS than any other organizations on the planet! Mainly due to incompetent employees paid on time of service rather than actual performance.

"sooner or later, governments that rely on free open source software will put their country's and their citizens' data in harm's way." Yea, so let's stick with the far more secure options of MS-Windows, etc...

"Instead, the security breach will be placed into the open source software from inside, by someone working on the project." Yea, cause there has never been an instance of a paid employee/developer inserting an Easter egg, back door, or other malicious code.

"As anyone can create and market a distribution, it's not far-fetched to imagine a version subsidized and supported by organizations that may not have U.S. or other government interests at heart." I know my government is mostly stupid and ignorant, but I doubt "Joe's garageware jonix distribution" would make it through the laborious bidding process.

"the widespread perception that Linux is more secure than Windows, despite the fact that both products are riddled with software security holes." Agreed. The difference is, we can actually learn about the presence of open-source holes MUCH faster than closed source. (See recent /.ed article!)

"Can Self-Policing Work?" Of course not! And that's exactly what closed-source is: self-policing! Open-source is open policing and scrutinizing by virtually anyone and everyone. Hmmmm... Should I rely on the QA/security efforts of a 10-20 person team who better play good politics to keep their jobs and/or get raises? OR, Should I consider the QA/security efforts of 100's of thousands of unapologetic experts?

eeye.com

Dear parent, I know it's very hard to use the a-tag, but please, can you at least give it a try in your future posts? Please?

More stuff from eeye

Didn't openssl have ASN.1 issues recently? Did MSFT copy some of the code ;-) ?

BTW: Interesting timeline of more to come

Better keep checking for updates.

Lets see some of the images in "various competitors" and what do we get?

THIS crap:

---
Security AlertSecureIIS Application Firewall Security Alert

If you feel that you have received this page in error, please contact the administrator of this web site, reporting the following reference ID:

20031201946923

SecureIIS Evaluation Version
SecureIIS offers websites running Microsoft Internet Information Server a broad range of protection from common vulnerabilities, both known and unknown. Because SecureIIS does not protect against specific vulnerabilities, but classes of vulnerabilities, it allows for a much more far reaching layer of security.

For more information on SecureIIS, please visit http://www.eeye.com/SecureIIS/

eEye(TM) Digital Security - Vulnerability Is Over...

---

"Secure IIS" is an oxymoron and not letting casual visitors view your images is ridiculous. "Protecting agains unknown threats. I'm the surfer. I threat your webserver!"

@stake, eeye, and iss have all agreed w/ microsoft not to release details of even potential exploits until the microsoft has had 30 days to "evaluate" them, leaving admins and the public unnecessarily exposed to vulnerabilities. This is completely unacceptable, and contrary to the scientific peer-review process of real science. If you know there's a problem, you speak out, suggest a fix, and hopefully the appropriate parties will be responsible enough to take action. Additionally, others have to be able to VERIFY and REPRODUCE findings, a critical part of *real* research. But microsoft's tactic is to force so-called security "research" companies (who are in it for money, not necessarily for altruistic research or making things more secure) into a lop-sided, biases "standards" NGO, the "Organization for Internet Safety" (OIS), which Microsoft is a member. (read this). What they are proposing is censorship, hiding information until they can find a fix, so that only the hackers will know what's broken. Talk about the fox guarding the hen-house!!!

Additionally, the director of research for @stake, Chris Wysopal, is effectively lobbying congress to give teeth to the OIS, and more power to microsoft and their buddies.

OIS = @stake, BindView, SCO, Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, Symantec. sounds like the stone cutter's guild to me.

Eeye seems to be left out for obvious reasons, they oppose this secretive "research." Read eeye's Marc Maiffret's (chief hacking officer) thoughts on things to a congressional subcommittee here.

"windows corrupts, microsoft corrupts absolutely."

Look. MS Win\2003 and future versions contain public-keys for encryption, for which the licensed user (not owner) holds no corresponding private-key. Who holds the private keys? Microsoft, for sure - and whoever they escrow to at Three Letter Agency.

Sony Pictures may well hold private-keys, distributing the pub-key to you by use of MS's APIs in a software installer. The implications of this is that your computer cannot be trusted by its user.

Oh, and the worm comments seem like flamebait? The DCom-RPC vulnerability is YEARS old in the code - 1997. Never caught by the people who had access and ownership of the source. Not after bringing in special tools for reviewing code last year, not after a 5-month security related delay for review of 2003 Server. This is an OBVIOUS place to look for flaws, being RPC, and automated tools for checking buffer code is not rocket science.

The newest (of many) problems in the IE use of the OBJECT tag was so downplayed in the MS announcement yesterday, that I have hardly heard a mention. This is not a joke to leave unpatched, and it is related to IE ignoring RFC compliance on 7-bit MIME-type headers, and weakness in the mechanism for defining "zones".
See if you can tell that this announcement:
http://www.microsoft.com/technet/security/bulletin /MS03-032.asp
relates to this disclosure by eEye:
http://www.eeye.com/html/Research/Advisories/AD200 30820.html
You think that Linux or Solaris or whatnot suffers equally? A regular user of an account on the box cannot establish the trust policy for code executed outside of his own shell.

We can go on for pages and pages in this vein - instead just manage to look through the relevant list-archives for Full-Disclosure and Incidents, etc...

Windows is a little, dirty-toilet OS.

Actually, you'd want to go to eEye's Security advisory for that.

It's because the bug isn't in DirectX, but in the windows MIDI decoder, according to eEye
Read the Advisory

It would have been nice if the poster posted a link to the actual microsoft security bulletin, which also links to the patch for your particular DirectX. Also nice would have been a link to this article at eEye security, which goes into much more technical information. What also would have been nice is if the poster specified that the attack only affected MIDI files, instead of implying that all downloads of online music were at risk. The link to the random and not-really-related article about Microsoft protecting its users from legal hassles could probably have been left out, as it just confused the issue.

(Maybe I'm just bitter that my submission of the same story got rejected)

It would have been nice if the poster posted a link to the actual microsoft security bulletin, which also links to the patch for your particular DirectX. Also nice would have been a link to this article at eEye security, which goes into much more technical information. What also would have been nice is if the poster specified that the attack only affected MIDI files, instead of implying that all downloads of online music were at risk. The link to the random and not-really-related article about Microsoft protecting its users from legal hassles could probably have been left out, as it just confused the issue.

(Maybe I'm just bitter that my submission of the same story got rejected)

Not to nitpick, but the SQL Slammer worm appeared to be written in assembly. It is quite interesting to read through the source. [alt] [alt]

While the PRNG isn't of the highest quality, its brevity is what allowed it to spread so quickly. An infected system was sending out packets as fast as the outbound pipe could handle it. A smaller virus, even by a few bytes, would mean that much faster of an infection rate.

By and large, you're right about VBScript making for simple virii, but this isn't the one to use as an example.

To write a virus from scratch takes a bit more effort, and you need to be adept at asm, which nowadays, very few young people bother learning. I dont think people reallize that virii are not written in C, its all asm.

If someone actually wants to take a look at what a real virus looks like, take a look at the following site. Im sure we all remember the SQLWorm Virus of late January. Well, here is a website that has the virus code posted:

http://www.eeye.com/html/Research/Flash/sapphire.t xt

Retina, by Eeye, is another excellent scanning school. IMHO, it's better than GFILanguard. I especially like the ability to fix registry problems from the scanning machine. It's interface is also very smooth. It's located here. They also have another product for scanning IIS, but I haven't used it yet.

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

Flash has been known for its security vulnerabilities, such as this one:

Security hole in Macromedia Flash allows attack through any browser.

By editing the Flash header (SWF), it is possible to run any code on the computer of a visitor to a web page, according to an eEye Digital Security Alert. The vulnerability exists in all versions of Flash and in all browsers that support Flash, making it "... trivial to bypass firewalls and attack the user at his desktop." eEye says they found 17 other vulnerabilities in Flash. eEye reported a previous vulnerability last May.

I've always disliked how Flash tends to be an advertisement for Flash. Visitors to a page with Flash often get upgrade notices.

When I read the above security risk announcement, I disabled Flash in Mozilla, and now I often get the Macromedia advertisement: "Click here to get the plugin." Did the owners of those web sites intend to force me to install unsafe software or go elsewhere? No, probably they just trusted a web site builder who knew that flashy graphics is cheaper than useful content.

Flash has been known for its security vulnerabilities, such as this one:

Security hole in Macromedia Flash allows attack through any browser.

By editing the Flash header (SWF), it is possible to run any code on the computer of a visitor to a web page, according to an eEye Digital Security Alert. The vulnerability exists in all versions of Flash and in all browsers that support Flash, making it "... trivial to bypass firewalls and attack the user at his desktop." eEye says they found 17 other vulnerabilities in Flash. eEye reported a previous vulnerability last May.

I've always disliked how Flash tends to be an advertisement for Flash. Visitors to a page with Flash often get upgrade notices.

When I read the above security risk announcement, I disabled Flash in Mozilla, and now I often get the Macromedia advertisement: "Click here to get the plugin." Did the owners of those web sites intend to force me to install unsafe software or go elsewhere? No, probably they just trusted a web site builder who knew that flashy graphics is cheaper than useful content.

Flash has been known for its security vulnerabilities, such as this one:

Security hole in Macromedia Flash allows attack through any browser.

By editing the Flash header (SWF), it is possible to run any code on the computer of a visitor to a web page, according to an eEye Digital Security Alert. The vulnerability exists in all versions of Flash and in all browsers that support Flash, making it "... trivial to bypass firewalls and attack the user at his desktop." eEye says they found 17 other vulnerabilities in Flash. eEye reported a previous vulnerability last May.

I've always disliked how Flash tends to be an advertisement for Flash. Visitors to a page with Flash often get upgrade notices.

When I read the above security risk announcement, I disabled Flash in Mozilla, and now I often get the Macromedia advertisement: "Click here to get the plugin." Did the owners of those web sites intend to force me to install unsafe software or go elsewhere? No, probably they just trusted a web site builder who knew that flashy graphics is cheaper than useful content.

Most discovery to patch timelines go like this:

[researcher finds vulnerability]->[notifys vendor]->[waits impatiently for a month or so]->[vendor releases patch in hotfix or service pack]

This case was completly different and demonstrates a disturbing trend in security research. NO ONE knew about this until it was discovered in the wild. Usually the script kiddies find out about the flaw the same day customers do and then it's an arms race to patch. This time the kids were armed with the exploit before even Microsoft knew about it. The trend of exploits staying secret has started to rear it's ugly head and this is the first major case where it's happened. Don't be suprised if this starts happening more and more. The good news is that MS was able to cough up a patch in a matter of days. The bad is that black hats are obviously keeping secrets about flaws they find.
Gone are the days where each vulnerability found was shouted from the rooftops till someone noticed the researcher. Now they just root servers with unfettered access until someone figures out that it's a new vulnerability. EG they bypass all IDS and in this case most firewalls.
For the record, it seems like this is a simple buffer overflow (when will they learn?) so tools like URLScan and SecureIIS stop these attacks. If your running an IIS server it would be a REALLY good idea to invest into either of these. Since they both stop all forms of buffer overflows (and various other types of attack) they don't require a patch to fend off these types of attacks.

There is a scanner available to find vulnerable systems. The free version can scan up to a class C address at once.

Get it here:

[SapphireSQL]

Also, Microsoft this morning released an updated patch kit for SQL Server 2000 and MSDE 2000, that allegedly eliminates needing to manually copy files and run manual commands. Supposedly, installing the patch only requires two clicks, so most Windows administrators should be able to handle it (ducking for cover....)

You can get the new patch kit here:

[slammer]

PSS Security Response Team Alert - New Worm: W32.Slammer
UPDATED: January 26, 2003
SEVERITY: CRITICAL
DATE: January 25, 2003
PRODUCTS AFFECTED: SQL Server 2000 RTM, SQL Server 2000 SP1, SQL Server 2000 SP2, and Microsoft SQL Desktop Engine Version (MSDE) 2000

And another: http://www.eeye.com/html/Research/Flash/AL20030125 .html (worm operation and links)

*ahem*

Internet Explorer's Recently Discovered PNG Deflate Heap Corruption Vulnerability

Twas the night before Christmas, and deep in IE
A creature was stirring, a vulnerability
MS02-066 was posted on the website with care
In hopes that Team eEye would not see it there

But the engineers weren't nestled all snug in their beds,
No, PNG images danced in their heads
And Riley at his computer, with Drew's and my backing
Had just settled down for a little PNG cracking

When rendering an image, we saw IE shatter
And with just a glance we knew what was the matter
Away into SoftICE we flew in a flash
Tore open the core dumps, and threw RFC 1951 in the trash

The bug in the thick of the poorly-written code
Caused an AV exception when the image tried to load
Then what in our wondering eyes should we see
But our data overwriting all of heap memory

With heap management structures all hijacked so quick
We knew in a moment we could exploit this $#!%
More rapid than eagles our malicious pic came --
The hardest part of this exploit was choosing its name

Derek Soeder
Software Engineer
eEye Digital Security

Link to source

*ahem*

Internet Explorer's Recently Discovered PNG Deflate Heap Corruption Vulnerability

Twas the night before Christmas, and deep in IE
A creature was stirring, a vulnerability
MS02-066 was posted on the website with care
In hopes that Team eEye would not see it there

But the engineers weren't nestled all snug in their beds,
No, PNG images danced in their heads
And Riley at his computer, with Drew's and my backing
Had just settled down for a little PNG cracking

When rendering an image, we saw IE shatter
And with just a glance we knew what was the matter
Away into SoftICE we flew in a flash
Tore open the core dumps, and threw RFC 1951 in the trash

The bug in the thick of the poorly-written code
Caused an AV exception when the image tried to load
Then what in our wondering eyes should we see
But our data overwriting all of heap memory

With heap management structures all hijacked so quick
We knew in a moment we could exploit this $#!%
More rapid than eagles our malicious pic came --
The hardest part of this exploit was choosing its name

Derek Soeder
Software Engineer
eEye Digital Security

Link to source

Did you ever notice that one company is taking over the Internet? The company is called "Click here to get the plugin."


Okay, okay, maybe it's because I don't like this:

By editing the Flash header (SWF), it is possible to run any code on the computer of a visitor to a web page, according to an eEye Digital Security Alert. The vulnerability exists in all versions of Flash and in all browsers that support Flash, making it "... trivial to bypass firewalls and attack the user at his desktop." eEye reported a previous vulnerability last May.

I've always disliked how Flash tends to be an advertisement for Flash. Visitors to a page with Flash often get upgrade notices.

TheBrainLess could realize that a lot of people deleted the Flash plugin during one of the previous security alerts.

Did you ever notice that one company is taking over the Internet? The company is called "Click here to get the plugin."


Okay, okay, maybe it's because I don't like this:

By editing the Flash header (SWF), it is possible to run any code on the computer of a visitor to a web page, according to an eEye Digital Security Alert. The vulnerability exists in all versions of Flash and in all browsers that support Flash, making it "... trivial to bypass firewalls and attack the user at his desktop." eEye reported a previous vulnerability last May.

I've always disliked how Flash tends to be an advertisement for Flash. Visitors to a page with Flash often get upgrade notices.

TheBrainLess could realize that a lot of people deleted the Flash plugin during one of the previous security alerts.

&nbsp&nbsp&nbsp&nbspIf you want to compare Linux to Windows, I'd be willing to bet my life that Windows has more security holes. There's only a limited number of people that review Windows' code. GNU/Linux, however is made up of many different smaller components that have the love and affection of their programmers. Linux is made from love. Windows is made from corporate greed. The programmers that make Windows have deadlines and upper management telling them to stop working on one project so they can put resources into creating new features. This is all my opinion, of course, but it's a very logical conclusion.

&nbsp&nbsp&nbsp&nbspThere will probably never be a truly secure operating system as long as humans are involved in making it. We make mistakes. It only takes one overlooked mistake in a protocol or the code for a system to be compromised. A good example is the recent SNMP exploit. The protocol itself was not created with security in mind, so many vendors were vulnerable. The best chance we have at a human created, secure OS is one that focuses on security, such as OpenBSD.

&nbsp&nbsp&nbspIf our government (I'm speaking of my country, the USA) adopted OpenBSD and threw enough resources behind it, other governments would have to throw a whole lot of money and effort into finding something our efforts failed to see. The way things stand though, it wouldn't be terribly difficult to bring our systems crawling to their knees.

&nbsp&nbsp&nbspFor instance, lets say one of the employees at eEye was hired by Cuba to find exploits in NT and remain silent to everyone else, it would cost them very little to hack into our systems. The guys at eEye and other security firms find exploits such as buffer overflows all the time, and I'm sure enough money could convince one employee to commit treason. Heck, they could just use the unpatched exploits already out there and do it for free!

&nbsp&nbsp&nbspThe point is that all we can do as system and network admins is to keep up to date on known exploits. We patch our systems and networks and make it so that only a true hacker could bypass our efforts. Script kiddies would be stopped dead in their tracks and 99.9% of the time, that's all the defense we require. In this respect, the amount of patched exploits should have very little effect on the decision making process. However, keep those unpatched exploits in mind.

&nbsp&nbsp&nbspWelcome to the real world!

How can Flash be removed from 1) Windows, and 2) Linux?

Reasons not to run Flash:

Flash presents unknown security risks. Sometimes Flash and other Macromedia products have been the point of entry of trojans and viruses, as mentioned in this documentation of a very serious bug, Macromedia Flash Activex Buffer overflow.

Flash on a website advertises Flash. There must always be some notice that says "Download Flash if you don't have it", and a link to Macromedia, so that web site viewers can get the latest version. This forced added content distracts from the intended content.

Flash is nearly always used to provide images that are irrelevant to the content. Except for those who care about bright, shiny things more than content, Flash gets in the way. Flash authors are seldom qualified to provide moving picture content, and, even if they were, Flash is a very limited cinematic tool.

Flash often causes long load times. Long load times communicate that the website viewer's time is less important than the website creator's love of movement. Flash often causes Website viewers to wait for "Loading..." messages.

For website viewers who do not want to run Flash and other Macromedia software, or cannot, web sites using it are broken.

By using Flash, authors of Flash content may cause the URL of their customers to be transmitted to Macromedia. If some disloyal Macromedia employee, or Macromedia itself, thought of some profitable reason to approach those customers directly, Flash content authors could lose business.

Flash content is proprietary content. It is the money-making scheme of one company. This tends to undermine web standards like HTML. The Internet is a public utility for all of us to use. Proprietary methods go against that spirit.

Taken directly from the Eeye vulnerability page:
Greetings:
Mom, Dad, and all of the little people that helped me and believed in me - oh - and a big YO HO to the homeboyz in the h00d.

Hrm....

Here are additional considerations concerning the use of Macromedia Flash:

Flash presents unknown security risks. Sometimes Flash and other Macromedia products have been the point of entry of trojans and viruses, as mentioned in this documentation of a very serious bug, Macromedia Flash Activex Buffer overflow.

Flash on a website advertises Flash. There must always be some notice that says "Download Flash if you don't have it", and a link to Macromedia, so that web site viewers can get the latest version. This forced added content distracts from the intended content.

Flash is nearly always used to provide images that are irrelevant to the content. Except for those who care about bright, shiny things more than content, Flash gets in the way. Flash authors are seldom qualified to provide moving picture content, and, even if they were, Flash is a very limited cinematic tool.

Flash often causes long load times. Long load times communicate that the website viewer's time is less important than the website creator's love of movement. Flash often causes Website viewers to look at "Loading..." messages.

For website viewers who do not want to run Flash and other Macromedia software, or cannot, web sites using it are broken.

By using Flash, authors of Flash content may cause the URL of their customers to be transmitted to Macromedia. If some disloyal Macromedia employee, or Macromedia itself, thought of some profitable reason to approach those customers directly, Flash content authors could lose customers.

Flash content is proprietary content. It is the money-making scheme of one company. This tends to undermine web standards like HTML. The Internet is a public utility for all of us to use. Proprietary methods go against that spirit.

Posting, distributing or making available source code to viruses should be illegal? You mean, like this?

CodeRed.zip at Eeye.com

and

CodeRedII.zip at Eeye.com

Eeye.com has often posted the proof-of-concept exploits as a part of their advisories... is the author of the guest editoral saying eeye.com is doing wrong?

Back when the original Code Red was stirring up a ruckus, I posted its disassembled code (from eeye) to alt.comp.virus.source, and an short discussion of several weird aspects (poor coding) of the code ensued. I don't think I did anything wrong by posting it. If some weasel used that post (or other such sources) to create CRII, so be it. IMO, by that time any servers that were still vulnerable to CR/CRII deserved to be hit and, better yet, TOS'd by there ISP.

I just don't subcribe to the idea that suppressing potentially dangerous source code will do good in the long run. Having the source available and widely distributed has several advantages:
- promotes understanding of exploit mechanisms in order avoid making the same mistakes in the futre
- promotes rapid deployment of fixes. There is no pressure greater than knowing every little script kiddy's got the code
- raises awareness of code weaknesses/failure modes/common pitfalls (maybe *someday* CS courses will teach future coders to prevent buffer overflows!)

I firmly believe that being open about software/network/OS weaknesses will gradually drive the state of the art in secure software to a much higher level. The "keep quiet", "head-in-the-sand" approach that M$ is promoting these days will only hinder such advances. I'll make a loose analogy to the old outlaws & guns argument: "If you outlaw virus source code, only outlaws will have virus source code."

In fact, I think it is *imperative* that malicious source code NOT be suppressed. How else can we arm the next generations of app and OS coders to develop resistance code?

Posting, distributing or making available source code to viruses should be illegal? You mean, like this?

CodeRed.zip at Eeye.com

and

CodeRedII.zip at Eeye.com

Eeye.com has often posted the proof-of-concept exploits as a part of their advisories... is the author of the guest editoral saying eeye.com is doing wrong?

Back when the original Code Red was stirring up a ruckus, I posted its disassembled code (from eeye) to alt.comp.virus.source, and an short discussion of several weird aspects (poor coding) of the code ensued. I don't think I did anything wrong by posting it. If some weasel used that post (or other such sources) to create CRII, so be it. IMO, by that time any servers that were still vulnerable to CR/CRII deserved to be hit and, better yet, TOS'd by there ISP.

I just don't subcribe to the idea that suppressing potentially dangerous source code will do good in the long run. Having the source available and widely distributed has several advantages:
- promotes understanding of exploit mechanisms in order avoid making the same mistakes in the futre
- promotes rapid deployment of fixes. There is no pressure greater than knowing every little script kiddy's got the code
- raises awareness of code weaknesses/failure modes/common pitfalls (maybe *someday* CS courses will teach future coders to prevent buffer overflows!)

I firmly believe that being open about software/network/OS weaknesses will gradually drive the state of the art in secure software to a much higher level. The "keep quiet", "head-in-the-sand" approach that M$ is promoting these days will only hinder such advances. I'll make a loose analogy to the old outlaws & guns argument: "If you outlaw virus source code, only outlaws will have virus source code."

In fact, I think it is *imperative* that malicious source code NOT be suppressed. How else can we arm the next generations of app and OS coders to develop resistance code?

• You have to turn on the auto update feature, its not on by default.
  
• The Universal Plug and Play (UPnP) subsystem vulnerabilities in XP

I know I do. "Hackers" can sieze control if people connect to the Net. MS makes a free fix[1] available on their Web site. Like, through the Net. So eXPendable users are basically forced to play Russian Roulette when they get on-line.

Oh the fun you could have with BackOrificeXP right now... User tries to get patch, Evil haX0r-d00d shoots out a pop-up and mp3: a little Strauss music and a MsgBox reading, "I don't think I can let you do that, Dave."

open-source programmers the world over laugh at how hard it is for closed-sourcer's to fix their code, because 3rd parties can't examine it for bugs. however, in an instance like this, even though it is HARDER to find the bug, especially without the source code, the bug is still found and fixed, and agreeably handled. and no doubt that eeye has made a nice profitable business out of their security testing.

in retrospect, it smacks of plain un-willingness & hatred against MS when someone claims that bugs are harder to find in closed-source. it's harder, but it's UNWILLINGNESS to help that makes it IMPOSSIBLE.

According to the eeye coverage:

The SSDP service also listens on Multicast and Broadcast addresses. Therefore gaining SYSTEM access to an entire network of XP machines is possible with only one anonymous UDP SSDP attack session.

Someone's gonna have a lot of fun with this one!

Since the article is virtually useless as far as explaining what the security problem really is, here is the complete explanation from eEye
http://www.eeye.com/html/Research/Advisories/AD200 11220.html

What the article doesn't mention is that Windows 98 with XP sharing is also affected, and that any version of Windows ME is affected as well.

If you are running Windows 98 or ME, you should immediately go to Microsoft's website and download the patch for your system.

A more technical description can be found here.

Windows 2000 is not affected.