Slashdot Mirror

Eeye's advisory is here.

SecureIIS application firewall security alert
HTTP Request caused a security alert, please contact our web master if you are getting this alert in error.
What is SecureIIS
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 Digital Security - Vulnerability Is Over...

Wow... good to know that eEye is protecting innocent IIS users from the horrors of the Slashdot Effect!! ;-)

SecureIIS application firewall security alert


HTTP Request caused a security alert, please contact our web master if you are getting this alert in error.


What is SecureIIS
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? Digital Security - Vulnerability Is Over...

Since you have gone to the trouble of saying this several times in this article, even going so far as to mock people, I feel it is worth a moment to point out why you are (effectively) wrong.

Your definition of a firewall is very simplistic. Perhaps it is one of a beginning Computer Science student or a mid level manager / sales team member of a firewall product company. I encourage you to take a moment to revise it to more accurately reflect what firewalls do, and to open your mind somewhat to understand perspectives that are not yours. A better definition of a firewall may perhaps be "a piece of hardware or software designed to restrict communication between points as permitted by site policy and as configured by a site administrator".

A firewall can do several things that really do not fit into your more narrow definition of a firewall. Some of these things might be gateways/proxies (SecureIIS is a proxy of sorts that does exactly this), reactive ACLs (a'la Cisco), stateful packet analysis (chained to the appropriate logging or filtering facilities), yes, even completely rewriting the packet with different source or destination addresses (NAT) and or ports (sometimes abbreviated PAT) based on certain rules.

Your arrogance and/or ignorance is blinding you to the fact that NAT is two sided, and that the relevant portion to "firewalling" is the portion you aren't considering. That is, the NAT device can not guess, based on a random incoming packet, where it should send that packet inside the "protected" area, therefore it is forced to discard it.

A fair example of this, I believe, is my own home system, where I have exactly one machine for web browsing, and it is a laptop under the control of my employer - a fine bunch of people but not always on top of the patches for my machine. I have a basic OpenBSD system at home that serves no relevant purpose other than to simply provide me DHCP and ipf/ipnat services. By merely putting this NAT in line with my daily machine, I have been protected from the wave of Code Red and Nimda variants that pounded my cable modem a few months ago. In fact, thinking this through, its easy to come to the (perhaps incomplete) conclusion that all broadband users should be forced to be behind NAT for their own good. While that may be a bit extreme, I can say that NAT was the simplest way for me to provide effective firewalling for 100% of the problems that my machine has been at risk of. (excusing of course the onslaught of E-Mail worms which would have necessitated other forms of filtering had I been running Outlook and friends.)

In conclusion, there is more to firewalling than simple packet filtering (or whatever "make communication impossible" is meant to imply).

Enjoy your new clue.

-Dan

P.S. If your teriyaki glaze really looks like WD-40 please reply to this and I'll e-mail my mom and get her recipe from her and pass it along.

It is quite sad to see that the former l0pht (hopefully you remember them), who went corporate and melted into @stake, have joined the "coalition against full disclosure of computer vulnerability information". I'm amazed that Mudge and Weld Pond would turn full circle and endorse this sort of thing. The l0pht were the sort of people who stood for full disclosure. Too bad they have made this decision. I have lost my respect for them.

At least eEye are keeping their heads about them.

Agreed, HFNetchk essentially looks for Registry keys that state which patches are installed. If you use it, always use the '-z' switch, which tells it to not look for the registry entries. This makes it take a little longer, because it searches for actual files, but it's ALOT more accurate.
Also, eEye has a neat little NIMDA Scanner which will do up to a Class B net looking for exploitable machines. Sometimes finding a machine that COULD be infected is harder then finding the actual infected ones.
URLScan is nice, but you really need to know what your doing to run it, as it's easy to mess up a webserver thats running fine.
But the most important thing to do is to get on those security lists, NTBugtraq, MS security lists, etc. As well as hitting the big security related sites out there before your morning cup of coffee to make sure nothing new has come up.

It's all basically common sense, but every now and then you need a nice reminder.

From: "Marc Maiffret" <marc@eeye.com>
To: "Richard M. Smith" <rms@privacyfoundation.org>,
"BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date: Fri, 10 Aug 2001 13:10:51 -0700

After about 3 weeks of little to no sleep and spending lots of my (and Ryan
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.

|Hello,
|
<snip>
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.

Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."

|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.

Lets get the facts straight. CodeRed is based off of another worm that was
written for a .htr ISAPI buffer overflow. CodeRed is an almost identical
copy of the .htr worm. A worm which was released back in April. A worm which
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the .htr worm went unnoticed. To bad a security company had
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.

So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS .htr
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.

Now a few months later someone took that .htr worm and modified it to attack
the .ida vulnerability. They already had ALL of the knowledge they needed in
order to modify the .htr worm to be the .ida worm. There was nothing that
eEye gave them that made it any easier.

In fact when it comes down to it technically... eEye's technical exploit
information within the .ida ISAPI overflow advisory was actually put to
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj .ida exploit were
technically superior to anything that we (eEye) discussed in our .ida
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.

|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.

This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.

|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org

There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities

From: "Marc Maiffret" <marc@eeye.com>
To: "Richard M. Smith" <rms@privacyfoundation.org>,
"BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date: Fri, 10 Aug 2001 13:10:51 -0700

After about 3 weeks of little to no sleep and spending lots of my (and Ryan
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.

|Hello,
|
<snip>
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.

Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."

|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.

Lets get the facts straight. CodeRed is based off of another worm that was
written for a .htr ISAPI buffer overflow. CodeRed is an almost identical
copy of the .htr worm. A worm which was released back in April. A worm which
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the .htr worm went unnoticed. To bad a security company had
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.

So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS .htr
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.

Now a few months later someone took that .htr worm and modified it to attack
the .ida vulnerability. They already had ALL of the knowledge they needed in
order to modify the .htr worm to be the .ida worm. There was nothing that
eEye gave them that made it any easier.

In fact when it comes down to it technically... eEye's technical exploit
information within the .ida ISAPI overflow advisory was actually put to
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj .ida exploit were
technically superior to anything that we (eEye) discussed in our .ida
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.

|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.

This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.

|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org

There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities

From: "Marc Maiffret" <marc@eeye.com>
To: "Richard M. Smith" <rms@privacyfoundation.org>,
"BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date: Fri, 10 Aug 2001 13:10:51 -0700

After about 3 weeks of little to no sleep and spending lots of my (and Ryan
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.

|Hello,
|
<snip>
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.

Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."

|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.

Lets get the facts straight. CodeRed is based off of another worm that was
written for a .htr ISAPI buffer overflow. CodeRed is an almost identical
copy of the .htr worm. A worm which was released back in April. A worm which
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the .htr worm went unnoticed. To bad a security company had
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.

So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS .htr
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.

Now a few months later someone took that .htr worm and modified it to attack
the .ida vulnerability. They already had ALL of the knowledge they needed in
order to modify the .htr worm to be the .ida worm. There was nothing that
eEye gave them that made it any easier.

In fact when it comes down to it technically... eEye's technical exploit
information within the .ida ISAPI overflow advisory was actually put to
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj .ida exploit were
technically superior to anything that we (eEye) discussed in our .ida
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.

|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.

This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.

|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org

There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities

Remember that eEye is a business too. What if eEye releases information hoping to encourage development of new exploits? It certainly would get their name in the news and generate FUD to drive more people to buy their products.</conspiracytheory>

Here you go

Then there is a nice little Vulnerable Server Scanner Provided by the people at www.eeye.com.

It basicly looks for Vulnerable servers so that network admins can track them down and get the web admins to patch the machines before they get infected.

Nice to see someone has come up with a clean, pro-active method to kill this little menace off.

I'd be interested in seeing how the sales of Code Red have correlated with the public's awareness of Code Red.

http://www.eEye.com/Retina

CodeRed - There were two versions of the original CodeRed worm, both of which were strictly memory resident and fairly tame, all things considered. Both of these will show NNNN's in your log files. You can find more information here.

CodeRed 2 - This is the worm we're seeing now, the one with the XXXX's in your logs. This worm seems to most frequently scan in it's own IP range (Class A I think?) So, if you're in the 24/8 range, you'll probably see a lot of scans from people using various cable providers. You can find more information about CodeRed 2 here.

So far, I haven't seen anything on the security sites confirming a 3rd version of this worm. The media has often used the term CodeRed3 to describe what is actually CodeRed2, the one giving us grief right now.

If a new variant of this worm does make it into the wild, it'll be interesting to see how quickly it can spread. It seems that a lot of hosts infected with CR2 give the error (403.9 Too many users connected) when you try to access port 80, which causes the eeye scanner to miss them, and apparently keeps them from being exploited by a new worm. It also keeps people from getting to the /scripts/root.exe that CR2 leaves behind as a backdoor. I'm not sure why IIS would give an error about too many users being connected when in reality, the number of CR hits are around 1-2 a minute. It's likely that the IIS process looks for the number of open sockets and then gives that message if there are too many sockets open. This would make sense since CR2 will open up ~300 connections in its attempt to spread.

It was also mentioned yesterday that NT4 servers that have been patched are still vulnerable to CR2 if they're using redirection. This seems odd to me, since the patch should have fixed a buffer overflow in idq.dll. If that overflow was fixed and IIS is still crashing, perhaps there is another buffer overflow that's showing up when it gets the long string from CR2 as part of the redirection. Just a guess on my part though.

CodeRed - There were two versions of the original CodeRed worm, both of which were strictly memory resident and fairly tame, all things considered. Both of these will show NNNN's in your log files. You can find more information here.

CodeRed 2 - This is the worm we're seeing now, the one with the XXXX's in your logs. This worm seems to most frequently scan in it's own IP range (Class A I think?) So, if you're in the 24/8 range, you'll probably see a lot of scans from people using various cable providers. You can find more information about CodeRed 2 here.

So far, I haven't seen anything on the security sites confirming a 3rd version of this worm. The media has often used the term CodeRed3 to describe what is actually CodeRed2, the one giving us grief right now.

If a new variant of this worm does make it into the wild, it'll be interesting to see how quickly it can spread. It seems that a lot of hosts infected with CR2 give the error (403.9 Too many users connected) when you try to access port 80, which causes the eeye scanner to miss them, and apparently keeps them from being exploited by a new worm. It also keeps people from getting to the /scripts/root.exe that CR2 leaves behind as a backdoor. I'm not sure why IIS would give an error about too many users being connected when in reality, the number of CR hits are around 1-2 a minute. It's likely that the IIS process looks for the number of open sockets and then gives that message if there are too many sockets open. This would make sense since CR2 will open up ~300 connections in its attempt to spread.

It was also mentioned yesterday that NT4 servers that have been patched are still vulnerable to CR2 if they're using redirection. This seems odd to me, since the patch should have fixed a buffer overflow in idq.dll. If that overflow was fixed and IIS is still crashing, perhaps there is another buffer overflow that's showing up when it gets the long string from CR2 as part of the redirection. Just a guess on my part though.

I wonder if the symptoms of Code Red 3 is just similar as the one as the second version here or here? Or probably the first version?

This is almost the same thing I said in my post. You wouldn't want it to propagate via the worm technique though... it must remain strictly confined to the intended network (otherwise you might fix potential clients.) On a side note, I wouldn't be surprised if the virus writer(s?) worked for a company that offers this type of service. Look at eEye: they found the vulnerability, got credit from Microsoft, and make money with vulnerability assessment services. Corporate ethics: Make it hard to tell the good guys from the bad.

None of the above.

I vote for

Crucify the next virus writer (or other random, innocent hacker) they manage to catch and pass more inane laws that have no other effect but to make your life as a programmer even more difficult. Microsoft will hailed as the "hero" in the case, them being the underdogs against a sea of malicious open source hackers, when they release a patch that closes the script kiddie hole of the week, but not much else. 3rd party vendors will scramble to create more useless server side "personal firewall" applications that filter ONLY traffic based on *OLD* infection methods. No attempt will be made to make IIS itself less of a security risk. No reporting of IIS cgi-child processes running with admin level permissions will be made. Releasing the results of virus related research will become illegal. Discussing possible future vulerabilties will become illegal. Using any "hacker" operating system (e.g. not made by Microsoft) will become illegal. Using the word "virus" or "worm" anywhere on the Internet will earn you a visit from the FBI (after all, if you are innocent, you have nothing to hide). That small inconvenience of having all of your "computer related" possessions confiscated (including your home and car) and yourself thrown in jail w/o bail is insigificant when compared to the amount of viruses prevented from spreading.

The Code Red worm, named for the new flavor of Mountain Dew soda preferred by the eEye Digital Security team, sends probes across the Internet, looking for computers to break into.

• The first version of the worm appeared on July 13 or so.
  • It had an unseeded random number generator, so the IP's it scanned were a fixed sequence -- BUT it contained the code to seed the random number generator; this code was disabled.(*)
  • Its DoS attack was set to bomb a particular fixed IP address, AND not even send the bomb packets if that IP could not be reached
  • It contained code to deface web pages served making its presence very visable well before the bombing attack was scheduled to take place
  • It contained code to deactivate its spread if a particular file (c:\notworm) was present.
  • It contained code to deactivate its spread after the "attack phase" began
• On July 19, a second version was introduced.
  • The second version re-enabled the random number generating seed but was otherwise no less shackled than the first version.
  • This version spread exponentially, with growth finally being limited by the number of susceptible servers connected to the internet and the fact that it reached the time of the "attack phase"
  • This version infected over 359,000 hosts in under 14 hours.

The point? The worm author has carefully controlled the attack to cause alarm but not do real damage. When the initial version failed to cause serious alarm, it was loosened slightly from its shackles but still extremely restrained. More to the point? If the worm author -- or anyone else among the thousands with the technical skills to do so -- chose to, they could DoS basically the whole internet. According to netsizer.com, there are about 121 million internet hosts right now, so that gives a ratio of 1 infected computer to 300 hosts. That sounds like too small of a ratio to DoS all of them, but remember to shut things down all that has to happen is to saturate bandwidth, not overload servers. The only reason we're using the net happily today is that the worm author and others with those skills choose to restrain themselves.

It seems that if you neglected to cleanup your IIS machine after being infected during the first round of CodeRed, you won't get it a second time because of its "lysine deficiency".

After spawning 100 threads, after rewriting your pages, but before entering spread-mode, it checks for the existence of c:\notworm . If this file exists, it goes dormant.

So, how many systems out there cleaned up that file but didn't apply the patch? How many vulnerable(unpatched) systems are there? How many new infections are possible?

Too bad incidents.org is slashdotted

The other interesting thing is the # of probes I got from the Eeye Scanner starting yesterday afternoon a few hours before 8PM EDT - From IPs on totally different nets (ie it wasn't a local ISP admin doing it) Looks to me like some folks were looking for seed hosts to get things rolling again. Even more interesting is the probes wern't being done sequentially since I didn't see scans across my web server IPs, they were more random.

Turns out that this signature is probably from the eEye CodeRed scanner to identify vulnerable hosts. Interesting that they seemed to show up after 5PM from various places.

To quote Marc Maiffret, "We've designated this the .ida "Code Red" worm, because part of the worm is
designed to deface web pages with the text "Hacked by Chinese" and also
because code red mountain dew was the only thing that kept us awake all last
night to be able to disassemble this exploit even further."
If you want to blame someone, blame eEye; for once, a journalist isn't to blame. I'll content myself with wagging an accusatory finger at the braindead moderators who dumped points in your lap.
Easy does it!

Or maybe they read the part in the original advisory where the eeye folks mention that they took the name from the bottle o' Dew in the room:

Greetings:
The guy at Del Taco that sold us food at 3am to allow us to perform this research. The guy who left the warm "Code Red" Mountain Dew in the eEye lab.

Nonsense, it just takes one step out of the process. Have you read eEye's Analysis of Code Red? He didn't have the source, but he accurately predicted what it did and what would happen.

And look, IIS is closed sores, and they still managed to get into a bundle of crap.

Linus said: Given enough eyeballs, any bug is shallow.

Hiding the source just cuts down the number of eyeballs.

The guys at Eeye have a good overview here.

This is basically just the usual buffer overflow attack that's had a patch available for a month, and by following best practices shouldn't be an issue at all. The really interesting thing is where the guns being gathered are pointed: at whitehouse.gov. Should be an interesting night!

Jason

The guys at Eeye have a good overview here.

This is basically just the usual buffer overflow attack that's had a patch available for a month, and by following best practices shouldn't be an issue at all. The really interesting thing is where the guns being gathered are pointed: at whitehouse.gov. Should be an interesting night!

Jason

Ummm, until your favorite packet sniffer starts decoding stuff like this on the fly. After all, if your email reader can decode it, what's to stop anyone else from decoding it? This is about as useful as Microsoft's Obscurity server.

You can find the C program that writes to C:\ HERE

Wroot

Eeye even has a CHO, "Chief Hacking Officer"! Now, what's that?

Retina and iris scans, voice print identification, DNA patterns, credit card numbers, social security numbers.. It can't get much worse than it already is. Just sit back and enjoy the ride, or do your duty as a responsible citizen.
--

Apache running mod_perl is much more stable I assure you. And much more secure than IIS. See this advisory. In all honesty, have you ever used apache? Its time tested and runs the majority of internet servers. Install apache (even in NT) and see how much better it is. I promise you will never go back.

There is still the eeye hard info. IIS would not be able to grant a "system" command prompt to a script kiddie without itself running as a "system" level service, or am I wrong? Either way, IIS has the ability to overflow into memory areas that have system level access on a machine, therefore granting a script kiddie a "system" shell on an NT box. You forgot to give me an explanation as to how this is possible.... I would sure love to know. Educate me.

And for your info, I can lock down any box and build firewalls with the best of them.

In many respects, NT's security architecture (ACLs on everything, non-root daemons, no setUID, etc.) is STRONGER than Linux.
If you are truly correct about the "non-root daemons" then the >3000 character IIS buffer overflow that eeye found would not be possible. IIS runs with system level access, which is "root" on an NT box. That is how someone can obtain a "system level" command shell by using this expliot. I think someone else needs to "get an education about NT before talking..."
But what would I know anyway, I'm just a stupid 20 year old college kid with a linux box and an internship at a huge corporation doing sysadmin work.

(I'm not a cDc member, but I find the above post to be the best introduction to what I have to say.)

Somebody should break into the CDC's computers and screw with their files so they can see how 'beneficial' it is.

Go for it! I'm sure you wouldn't be the first to try, and if you succeeded, you would have demonstrated that they should use better software.

2: It's MS' fault for having the security holes in the first place. Response: Bull. Microsoft's engineers have attempted to create a product that will be useful to people. There may be defects in the product, but that gives you no right to write a program whose primary purpose is to punish those who use it. If I leave my door unlocked that doesn't make it my fault when you steal my things. You're still the criminal.

Microsoft's engineers have most likely attempted to create a product that is as profitable as possible; that's how publically traded companies work. Unfortunately, the software market has demonstrated that what is most profitable is not what is most secure, stable, flexible, etc.

Also, I think that analogies to physical things like windows, cars, guns, and cows, are inaccurate. High physical security isn't feasible in our day to day lives; e.g. Kevlar vests are expensive and currently unfashionable. However, decent computer security is both feasible and sexy, so it is acceptable--and I believe beneficial--to create an environment in which it is necessary.

3: MS wouldn't fix the holes if we didn't exploit them. Response: If you're so concerned about MS fixing their security holes, why not give them an advance copy of the software so they can attempt to fix them _before_ all the jackass kids exploit them?

History has shown that MS drags their feet on fixing security holes that are given to them privately, in advance. Remember the IIS hole that eEye found? (See www.eeye.com for specifics.) To summarize, Microsoft was given a week of advance notice, but apparently did nothing until exploits were already available. Even then, they called eEye irresponsible for releasing an exploit after others already existed!

However, I don't feel that eEye had any ethical obligation to give Microsoft the advance notice that they did. If everyone always gives Microsoft (or any other company) advance notice about security holes, then Microsoft has little financial incentive to put more effort into releasing a product that is secure to begin with. I think it's shortsighted to look at the actions of a group like cDc in the context of a single exploit; you need to look at the long term effect they have on the market. If Microsoft has to pay dearly for each security hole in their products (in this case, paying in terms of lost revenue from people who decide to use more secure products), they will be more concerned about the security of their products, because it will increase their profitability.

The only way that users win when it comes to security holes is simply to have secure software. If vendors are treated with too much leniency, this will never be achieved.

All the high profile sites have to run UNIX because IIS can't keep up. Add the fact that high profile means lots of people working there means lots of opportunity for human involvement to create security leaks. Like others have said here, there is no completely secure box. Especially if you run remote admin stuff and set up simple trust relationships. I don't see those practices as being beneficial enough to outweigh turning the services off.

Also, an NT box can be made to be very secure. Of course, then you have to turn off functionality there as well. However, holes in NT like you'll find here can't help but make it easier than UNIX to crack.

I find these studies inadequate as data to inform a purchasing decision. While MS will claim that they have proven NT to be better than Linux for Web and file serving in the general case, I disagree. Here's why:

These studies do not address price/performance. P/P is one of the most important metrics in making a purchase decision; these studies measured only peak performance. That the prices of the Linux-based and NT configurations tested are not given indicates to me that Microsoft wishes price to be disregarded as a factor in purchasing decisions. To do so would be an irresponsible act for any purchaser. Consider that NT license fees increase dramatically with number of clients, while Linux's price is constant and lower than any NT option.

These studies do not address options such as clustering. Clustering is a common solution to the problem of constant high client load. It may well be a better solution (in P/P and in peak performance terms) than simply boosting processing power with multiple processors. It also has reliability advantages.

These studies are not generalizable to other hardware configurations. While MS will claim that they prove that "NT is faster than Linux" inherently, they do not. The HW configuration was selected for the first Mindcraft study, which has been proven to have been engineered to favor Microsoft. Hence the hardware configuration itself is suspect. An across-the-board comparison on various configurations, with P/P as well as peak performance measured, would be a more reasonable comparison of the virtues of the OSes themselves, and would also highlight particular combinations of HW and SW that are worthy of consideration for purchase.

These studies do not address security. The release version of MS IIS has outstanding security holes, including the recent one disclosed by eEye. This was a root compromise which took eight days for Microsoft to admit, and two more to fix. Microsoft classically avoids the subject of real-world security, preferring the proven-worthless tactic of security by obscurity. Security, of course, is a major consideration to be made in purchasing.

These studies do not address stability. Stability, like P/P, is an important metric for purchase decisions. It helps one determine how expensive a system will be to maintain -- one that requires regular resetting or reconfiguration in order to keep operating will cost in manpower; one which crashes a lot will cost in downtime. Downtime costs money in an enterprise situation, and hence should inform purchase decisions strongly.

These studies do not address changing real-world needs. A real server system is rarely left serving static Web pages forever. When needs change, performance will likely change as well. Building a system to meet a single, narrow-minded need is likely to lead to a dead end in terms of scalability.

These studies demonstrate nothing about the future. Based on past trends, one can expect the situation for Linux-based OSes to get better and better. The next version of Windows NT will likely offer decreased performance on the same hardware (due to increased resource consumption by the OS itself) whereas future versions of Linux will likely improve performance. Buying heavily into Windows NT leads one to platform lock-in which may damage one's ability to escape the expensive effects of bloat.


In short, I do not believe that MS has demonstrated that there are advantages to purchasing an NT system over a Linux-based system for real-world file and Web service. Wise system administrators, IS/IT managers, and CIOs should stick with the proven security responsiveness, stability, price/performance, and scalability of Unix-based systems, possibly including Linux-based systems, rather than betting the farm on the Johnny-come-lately Windows NT.

The NT system in question is a vanilla install of NT4 SP3 with IIS. Hmm. Maybe I'll upgrade to SP4 and see if it works...

I haven't tried it however so can't vouch for whether it works or not but I have no reason to think it wouldn't.
--
"I am not a nut-bag." -- Millroy the Magician

I haven't tried it however so can't vouch for whether it works or not but I have no reason to think it wouldn't.
--
"I am not a nut-bag." -- Millroy the Magician

Stupid proprietary software...

Jeff