[Fwd: Complete Analysis of CodeRedII] (General Discussion)

Thread

Board Archives

	Bots
	Community
	General Discussion
	Sdk
	Wishlist
	Author Search

Site Features

	Citizens List
	Badges & Achievements
	Events Directory
	News and Articles
	Worlds List
	About Alphaworld
	Search Object Paths

Activeworlds Support

	Download Activeworlds
	Quickstart Tutorial

Historic Archives

	Truespace Archives
	Newsgroup Archives

[Fwd: Complete Analysis of CodeRedII] (General Discussion)

[Fwd: Complete Analysis of CodeRedII] // General Discussion

andras

Aug 7, 2001, 3:33pm

Everyone who is running IIS4 or higher on W2K or NT4 probably interested to read this article.
600,000 server infected so far :(
Andras

-------- Original Message --------
Subject: Complete Analysis of CodeRedII
Date: Mon, 6 Aug 2001 00:39:07 -0700
From: Steve Gibson <support at grc.com>
Newsgroups: grc.news,grc.news.feedback
Followup-To: grc.news.feedback

Folks,

Here's the clearest and most complete analysis I've seen so far.

-------------------------------------------------------------------

Code Red II Worm Analysis Update
=================================
The new worm that was first noticed yesterday has been
analyzed. Here is a summary of the facts based on the
excellent analyses referenced at the bottom of this page.

EXPLOITED VULNERABILITY
------------------------
This worm uses the same mechanism as the original Code
Red worm to infect vulnerable servers. That is, the
worm looks for IIS servers that have not patched the
unchecked buffer vulnerability in idq.dll or removed
the ISAPI script mappings. See the Code Red Patch FAQ
at http://www.incidents.org/react/code_red.php for
information on patching systems to remove the vulnerability.

Except for using the buffer overflow mechanism in order
to get the worm code executed on a vulnerable IIS server,
this new worm is entirely different from the original Code
Red CRv1 and CRv2 variants.

Note: According to eEye, the worm code will be successfully
executed only on a Win2000 system running a vulnerable IIS
server, WinNT-based IIS servers will simply crash when
attempting to execute the worm code. Our experiments and
reports received from users confirm this finding.

BACKDOOR
--------
The most damaging property of this new worm is that the worm
creates a back door on an infected server, leaving the system
wide open to any attacker.

The worm copies %windir%\CMD.EXE to the following locations:
c:\inetpub\scripts\root.exe
c:\progra~1\common~1\system\MSADC\root.exe
d:\inetpub\scripts\root.exe
d:\progra~1\common~1\system\MSADC\root.exe

This provides a means for a remote attacker to execute
arbitrary commands on the compromised server.

In addition, the worm creates a trojan copy of explorer.exe
as described below. Due to the actions of the trojan
explorer.exe, IIS will make the C: and D: root directories
accessible to a remote attacker even if the root.exe
command shell program is removed from the scripts and
msadc directories.

TROJAN EXPLORER.EXE
--------------------
The worm carries its own copy of explorer.exe. The worm
places its own copy of explorer.exe at c:\explorer.exe
and d:\explorer.exe. By placing the trojan file in these
locations, Windows will find and run the trojan rather
than the real explorer.exe because of the way Windows
seaches for executables by default. Specifically, unless
the system has been patched against the "Relative Shell
Path" vulnerability, the trojan explorer.exe will be
executed when the next user logs into the system. (See
http://www.microsoft.com/technet/security/bulletin/MS00-052.asp)

Upon execution, the trojan first runs the real explorer.exe
(thus the user will not notice any problems) and then goes
on to modify the system registry as outlined below.

First, the trojan program adds the value SFCDisable=0xFFFFFF9D
to HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogin.
This registry setting completely disables the Windows File
Protection (WFP) mechanism. WFP prevents the replacement of
certain monitored system files. See the following for more info:
http://support.microsoft.com/support/kb/articles/Q222/1/93.ASP

Next, the trojan sets the following "Virtual Roots" in the registry:
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
\scripts to
,,217
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
\msadc to
,,217
These "217" settings ensure that the scripts and msadc directories
(which contain the root.exe copy of cmd.exe) have read/write/execute
permission.

Finally the trojan sets these two "Virtual Root" values as well:
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c to
c:\,,217
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d to
d:\,,217
These mappings, which do not normally exist, map the root C: and D:
drives to a place where IIS can find them, namely /c and /d. The
permissions here are also set to read/write/execute.

Quoting eEye's analysis, the purpose of these mappings are described:
--------
Basically the above code creates a virtual web path (/c and /d) which
maps
/c to c:\ and /d to d:\. The writer of this worm has put in this
functionality to allow for a backdoor to be placed on the system so
even if
you remove the root.exe (cmd.exe prompt) from your /scripts folder an
attacker can still use the /c and /d virtual roots to compromise your
system. The attacks would basically look like:

http://IpAddress/c/inetpub/scripts/root.exe?/c+dir (if root.exe was
still
there) or:
http://IpAddress/c/winnt/system32/cmd.exe?/c+dir (Where dir could be
any
command an attacker would want to execute).
----------

Note that the trojan explorer.exe need only be executed once for
these registry changes to be made. Thus, all the backdoors are
enabled, and continue to be enabled, forever after, regardless
of whether or not explorer.exe is running.

To emphasize, note that even killing the trojan explorer.exe process
will not remove the back doors. Further, even killing the
explorer.exe
process and removing the copies of root.exe and deleting the registry
settings will not eliminate the backdoors. If the trojan explorer.exe
is executed again (e.g. when the next person logs in), the registry
settings will be reinstated, making the C: and D: drives again
externally accessible. Finally, note that even deleting the registry
settings, removing the copies of root.exe, and removing the trojan
explorer.exe is not sufficient to clean the system. During the
time the system was backdoored any other attacker could have
installed new backdoors that are not associated with this worm.

The trojan process sleeps most of the time, but wakes
to loop through these registry key modification steps every
10 minutes. This way, even if an administrator notices the
registry settings and deletes them, the trojan will reinstate
the settings a few minutes later.

PROPAGATION
-----------
How aggressively the worm attempts to propagate itself
depends on whether or not Chinese is the language installed on
the system. If Chinese, the worm creates 600 threads and
attempts to spread for 48 hours. If non-Chinese, the worm
creates 300 threads and attempts to spread for 24 hours.
After the infection-spreading interval, the system is
forcibly rebooted. The reboot flushes the memory resident worm,
and leaves the backdoors and the explorer.exe trojan in
place.

TARGET SELECTION
-----------------
The 300 or 600 worm threads all work simultaneously to
propagate the infection. Each chooses a random target IP
and then uses one of the following masks with the given
probabilities.The masked parts of the IP are replaced
with the host computer's own IP information. Thus, the
worm mostly confines its targeting to IP addresses close
to the host computer's own.

0.0.0.0 (probability 12.5%) => random
255.0.0.0 (probability 50.0%) => same class A
255.255.0.0 (probability 37.5%) => same class B

Target IPs which are excluded are 127.x.x.x and 224.x.x.x,
and no octet is allowed to be 0 or 255. In addition, the
host will not attempt to re-infect itself.

INFECTION PROCESS
-----------------
Before each attempt to connect to a new target, the worm
checks the local time to see if the year is less than 2002
and if the month is less than 10. If either of these checks
return false, then the worm ceases the propagation cycle
and reboots the server. Note that this implies that all worms
will cease propagating by Oct. 1, 2001.

To aid performance, the worm uses a nonblocking socket to connect
to each target. Specifically this means that if one thread is
stuck waiting for a slow connection to a particular target,
the wait will not slow down the rest of the threads from continuing
their scanning function.

After making a successful connection with a target (the three way
handshake has completed), the worm thread uploads all of the
worm code at once, looks for an acknowledgement, and then moves on
to attempting to infect other hosts.

When a worm first arrives on a target and begins execution, the
worm checks to see if the host has already been infected, and if
so, disables itself. Specifically, the worm checks to see a CodeRedII
atom has been placed using "GlobalFindAtomA". If the worm finds that
the atom exists then it goes to sleep forever. If the CodeRedII atom
does not exist, the worm creates the atom and continues execution.

DOWNLOADS
---------
Corecode provides a .zip file containing a IDA Pro project file
and a plaintext disassembly for both the worm and the trojan
explorer.exe at:
http://www.eikon.tum.de/~simons/ida_root/

To download the eEye analysis and their disassembly files:
http://www.eeye.com/html/advisories/coderedII.zip

The worm binary can be found at the Unixwiz site:
http://www.unixwiz.net/techtips/CodeRedII.html

REFERENCES
-----------
Corecode's Analysis:
http://archives.neohapsis.com/archives/incidents/2001-08/0092.html

NAI's Analysis:
http://vil.nai.com/vil/virusChar.asp?virus_k=99177

eEye's Analysis:
http://www.eeye.com/html/advisories/coderedII.zip

SecurityFocus Analysis:
http://archives.neohapsis.com/archives/bugtraq/2001-08/0066.html

ACKNOWLEDGEMENTS
-----------------
We are very grateful to Jesper Johansson for reviewing this
report and providing many helpful suggestions and technical details.

Many thanks are due to corecode, who stayed up all night and provided
the very first analysis of the worm binary to the public.

We'd also like to recognize Stephen Friedl of Unixwiz for performing
a higher level analysis last night and posting his findings to the
web
before any other concrete information was available.

Also, we thank Matt Scarborough for testing the worm on WinNT
to confirm that these systems crash rather than running worm
code successfully.

--
_________________________________________________________________
Steve Gibson, at work on: < a million loose ends >

wing

Aug 7, 2001, 5:28pm

*grin* Typical. Ingenius though, one of the more creative worms that I've seen in awhile. Not malicious in itself, except for the
rebooting. However, 600k servers in one day, that means that mathematically, by the time the worm stops propagating in October, ALL
W2k and NT4 systems that havn't been patched are infected. *thwacks M$ in the head*

[View Quote]

"andras" <andras at andras.net> wrote in message news:3B702530.6606912B at andras.net...
>
>
> Everyone who is running IIS4 or higher on W2K or NT4 probably interested to read this article.
> 600,000 server infected so far :(
> Andras
>
>
> -------- Original Message --------
> Subject: Complete Analysis of CodeRedII
> Date: Mon, 6 Aug 2001 00:39:07 -0700
> From: Steve Gibson <support at grc.com>
> Newsgroups: grc.news,grc.news.feedback
> Followup-To: grc.news.feedback
>
> Folks,
>
> Here's the clearest and most complete analysis I've seen so far.
>
> -------------------------------------------------------------------
>
> Code Red II Worm Analysis Update
> =================================
> The new worm that was first noticed yesterday has been
> analyzed. Here is a summary of the facts based on the
> excellent analyses referenced at the bottom of this page.
>
>
> EXPLOITED VULNERABILITY
> ------------------------
> This worm uses the same mechanism as the original Code
> Red worm to infect vulnerable servers. That is, the
> worm looks for IIS servers that have not patched the
> unchecked buffer vulnerability in idq.dll or removed
> the ISAPI script mappings. See the Code Red Patch FAQ
> at http://www.incidents.org/react/code_red.php for
> information on patching systems to remove the vulnerability.
>
> Except for using the buffer overflow mechanism in order
> to get the worm code executed on a vulnerable IIS server,
> this new worm is entirely different from the original Code
> Red CRv1 and CRv2 variants.
>
> Note: According to eEye, the worm code will be successfully
> executed only on a Win2000 system running a vulnerable IIS
> server, WinNT-based IIS servers will simply crash when
> attempting to execute the worm code. Our experiments and
> reports received from users confirm this finding.
>
>
> BACKDOOR
> --------
> The most damaging property of this new worm is that the worm
> creates a back door on an infected server, leaving the system
> wide open to any attacker.
>
> The worm copies %windir%\CMD.EXE to the following locations:
> c:\inetpub\scripts\root.exe
> c:\progra~1\common~1\system\MSADC\root.exe
> d:\inetpub\scripts\root.exe
> d:\progra~1\common~1\system\MSADC\root.exe
>
> This provides a means for a remote attacker to execute
> arbitrary commands on the compromised server.
>
> In addition, the worm creates a trojan copy of explorer.exe
> as described below. Due to the actions of the trojan
> explorer.exe, IIS will make the C: and D: root directories
> accessible to a remote attacker even if the root.exe
> command shell program is removed from the scripts and
> msadc directories.
>
>
> TROJAN EXPLORER.EXE
> --------------------
> The worm carries its own copy of explorer.exe. The worm
> places its own copy of explorer.exe at c:\explorer.exe
> and d:\explorer.exe. By placing the trojan file in these
> locations, Windows will find and run the trojan rather
> than the real explorer.exe because of the way Windows
> seaches for executables by default. Specifically, unless
> the system has been patched against the "Relative Shell
> Path" vulnerability, the trojan explorer.exe will be
> executed when the next user logs into the system. (See
> http://www.microsoft.com/technet/security/bulletin/MS00-052.asp)
>
> Upon execution, the trojan first runs the real explorer.exe
> (thus the user will not notice any problems) and then goes
> on to modify the system registry as outlined below.
>
> First, the trojan program adds the value SFCDisable=0xFFFFFF9D
> to HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogin.
> This registry setting completely disables the Windows File
> Protection (WFP) mechanism. WFP prevents the replacement of
> certain monitored system files. See the following for more info:
> http://support.microsoft.com/support/kb/articles/Q222/1/93.ASP
>
> Next, the trojan sets the following "Virtual Roots" in the registry:
> SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
> \scripts to
> ,,217
> SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
> \msadc to
> ,,217
> These "217" settings ensure that the scripts and msadc directories
> (which contain the root.exe copy of cmd.exe) have read/write/execute
> permission.
>
> Finally the trojan sets these two "Virtual Root" values as well:
> SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c to
> c:\,,217
> SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d to
> d:\,,217
> These mappings, which do not normally exist, map the root C: and D:
> drives to a place where IIS can find them, namely /c and /d. The
> permissions here are also set to read/write/execute.
>
> Quoting eEye's analysis, the purpose of these mappings are described:
> --------
> Basically the above code creates a virtual web path (/c and /d) which
> maps
> /c to c:\ and /d to d:\. The writer of this worm has put in this
> functionality to allow for a backdoor to be placed on the system so
> even if
> you remove the root.exe (cmd.exe prompt) from your /scripts folder an
> attacker can still use the /c and /d virtual roots to compromise your
> system. The attacks would basically look like:
>
> http://IpAddress/c/inetpub/scripts/root.exe?/c+dir (if root.exe was
> still
> there) or:
> http://IpAddress/c/winnt/system32/cmd.exe?/c+dir (Where dir could be
> any
> command an attacker would want to execute).
> ----------
>
> Note that the trojan explorer.exe need only be executed once for
> these registry changes to be made. Thus, all the backdoors are
> enabled, and continue to be enabled, forever after, regardless
> of whether or not explorer.exe is running.
>
> To emphasize, note that even killing the trojan explorer.exe process
> will not remove the back doors. Further, even killing the
> explorer.exe
> process and removing the copies of root.exe and deleting the registry
> settings will not eliminate the backdoors. If the trojan explorer.exe
> is executed again (e.g. when the next person logs in), the registry
> settings will be reinstated, making the C: and D: drives again
> externally accessible. Finally, note that even deleting the registry
> settings, removing the copies of root.exe, and removing the trojan
> explorer.exe is not sufficient to clean the system. During the
> time the system was backdoored any other attacker could have
> installed new backdoors that are not associated with this worm.
>
> The trojan process sleeps most of the time, but wakes
> to loop through these registry key modification steps every
> 10 minutes. This way, even if an administrator notices the
> registry settings and deletes them, the trojan will reinstate
> the settings a few minutes later.
>
>
> PROPAGATION
> -----------
> How aggressively the worm attempts to propagate itself
> depends on whether or not Chinese is the language installed on
> the system. If Chinese, the worm creates 600 threads and
> attempts to spread for 48 hours. If non-Chinese, the worm
> creates 300 threads and attempts to spread for 24 hours.
> After the infection-spreading interval, the system is
> forcibly rebooted. The reboot flushes the memory resident worm,
> and leaves the backdoors and the explorer.exe trojan in
> place.
>
>
> TARGET SELECTION
> -----------------
> The 300 or 600 worm threads all work simultaneously to
> propagate the infection. Each chooses a random target IP
> and then uses one of the following masks with the given
> probabilities.The masked parts of the IP are replaced
> with the host computer's own IP information. Thus, the
> worm mostly confines its targeting to IP addresses close
> to the host computer's own.
>
> 0.0.0.0 (probability 12.5%) => random
> 255.0.0.0 (probability 50.0%) => same class A
> 255.255.0.0 (probability 37.5%) => same class B
>
> Target IPs which are excluded are 127.x.x.x and 224.x.x.x,
> and no octet is allowed to be 0 or 255. In addition, the
> host will not attempt to re-infect itself.
>
>
> INFECTION PROCESS
> -----------------
> Before each attempt to connect to a new target, the worm
> checks the local time to see if the year is less than 2002
> and if the month is less than 10. If either of these checks
> return false, then the worm ceases the propagation cycle
> and reboots the server. Note that this implies that all worms
> will cease propagating by Oct. 1, 2001.
>
> To aid performance, the worm uses a nonblocking socket to connect
> to each target. Specifically this means that if one thread is
> stuck waiting for a slow connection to a particular target,
> the wait will not slow down the rest of the threads from continuing
> their scanning function.
>
> After making a successful connection with a target (the three way
> handshake has completed), the worm thread uploads all of the
> worm code at once, looks for an acknowledgement, and then moves on
> to attempting to infect other hosts.
>
> When a worm first arrives on a target and begins execution, the
> worm checks to see if the host has already been infected, and if
> so, disables itself. Specifically, the worm checks to see a CodeRedII
> atom has been placed using "GlobalFindAtomA". If the worm finds that
> the atom exists then it goes to sleep forever. If the CodeRedII atom
> does not exist, the worm creates the atom and continues execution.
>
>
> DOWNLOADS
> ---------
> Corecode provides a .zip file containing a IDA Pro project file
> and a plaintext disassembly for both the worm and the trojan
> explorer.exe at:
> http://www.eikon.tum.de/~simons/ida_root/
>
> To download the eEye analysis and their disassembly files:
> http://www.eeye.com/html/advisories/coderedII.zip
>
> The worm binary can be found at the Unixwiz site:
> http://www.unixwiz.net/techtips/CodeRedII.html
>
>
> REFERENCES
> -----------
> Corecode's Analysis:
> http://archives.neohapsis.com/archives/incidents/2001-08/0092.html
>
> NAI's Analysis:
> http://vil.nai.com/vil/virusChar.asp?virus_k=99177
>
> eEye's Analysis:
> http://www.eeye.com/html/advisories/coderedII.zip
>
> SecurityFocus Analysis:
> http://archives.neohapsis.com/archives/bugtraq/2001-08/0066.html
>
>
> ACKNOWLEDGEMENTS
> -----------------
> We are very grateful to Jesper Johansson for reviewing this
> report and providing many helpful suggestions and technical details.
>
> Many thanks are due to corecode, who stayed up all night and provided
> the very first analysis of the worm binary to the public.
>
> We'd also like to recognize Stephen Friedl of Unixwiz for performing
> a higher level analysis last night and posting his findings to the
> web
> before any other concrete information was available.
>
> Also, we thank Matt Scarborough for testing the worm on WinNT
> to confirm that these systems crash rather than running worm
> code successfully.
>
> --
> _________________________________________________________________
> Steve Gibson, at work on: < a million loose ends >

john viper

Aug 7, 2001, 10:12pm

"andras" <andras at andras.net> wrote in news:3B702530.6606912B at andras.net:

> Everyone who is running IIS4 or higher on W2K or NT4 probably
> interested to read this article. 600,000 server infected so far :(
> Andras
><snippety snip snip>

:-) *pats Apache Jakarta Tomcat server* Who the hell would ever yse IIS
when they can hava Apache, which is better and, umm, freeer?!

Actually this is an interesting snippet from my server log. I dunno if
someone has been trying to attack me with CodeRed or what, but what I DO
know is that www.worm.com does NOT look very promising...

----- BEGIN SERVER SNIPPETT
2001-08-03 04:21:26 - Ctx( ): 404 R( + /default.ida + null) null
Parse error, missing : in ccept: */*
x
Full GET /default.ida?
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNN
NNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%
u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0
Content-type: text/xmlHOST:www.worm.com Accept: */*
xmlHOST:www.worm.com Accept: */*
*
Uß)????§½òß¦???? ò+²òæòò+jG?j-M?Uß+???? òjú+¦j-m?mjß+????~' ò²òæòò+¦j-i?
UT?????
ò+++jG?j-A ºj-I~?¦j-e òj-uªU9?Ual-¦+¦jG-¦>w{V-=ß+t·÷+±±t=µµò+
(±+n˜t(t8
+ò+t=(ß=+ns=ò-=ß¦ß(tßas_v=·+ò+t=(ß=+t·÷=µµ+ò+==¦¦(°=±+ns=ò-··˜(·+···÷ò-
tnß=+n·=
¦=(±+n·=ò¦·==sò-fnß+t·÷=µµò+··µ=¦(v±·=ò-¦++¦ªºò-¦+¦ß(tßasòµ·÷¦=ßò÷··µ=
÷¦=ßò÷·v
v=÷ßòµ=v±òt=÷pò÷°±+=f=òHost:
???????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????
????
????????????????????????????????????????????????????????????????????????????
????
????????????????????????????????????????????????????????????????????????????
????
??????????????????????????????????????3+¦??+ï?ï at `3¦¦$?+ ad¦???1îj

----- END SERVER SNIPPETT

_____________________________________________
Jeff Tickle (John Viper, #296714)
jviper at jtsoft.net
http://www.jtsoft.net

andras

Aug 8, 2001, 5:12am

[View Quote] You won't believe but %95 of those infected machines running IIS probably without the knowledge of the machine's owner! They have no webpages at all - just the standard "Under construction" default from MS.
Most likely those ppl installed W2K without disabling the IIS install (it is installed by default). Of course they don't care about any security advisory (MS patches, etc) so it is easy to infect them.
Thanks to M$ to make "secure" OSs :((

>
> Actually this is an interesting snippet from my server log. I dunno if
> someone has been trying to attack me with CodeRed or what, but what I DO
> know is that www.worm.com does NOT look very promising...
>
<snip CodeRed V1>

This was the CodeRed 1 trying to infect you. The IP you received this request is an already infected machine.

Andras

john viper

Aug 8, 2001, 8:13am

>
> You won't believe but %95 of those infected machines running IIS
> probably without the knowledge of the machine's owner! They have no
> webpages at all - just the standard "Under construction" default from
> MS. Most likely those ppl installed W2K without disabling the IIS
> install (it is installed by default). Of course they don't care about
> any security advisory (MS patches, etc) so it is easy to infect them.
> Thanks to M$ to make "secure" OSs :((

Now that you mention it, I got a call from a friend of mine a few months
back saying that he just discovered he was running IIS, so I did lots of
searching and could find it nowhere on this comp... looks like I finally
have the real test of things ;-)

> This was the CodeRed 1 trying to infect you. The IP you received this
> request is an already infected machine.

EEW! get it off!!!!!! ;-) I wonder who it was...

_____________________________________________
Jeff Tickle (John Viper, #296714)
jviper at jtsoft.net
http://www.jtsoft.net

andras

Aug 8, 2001, 9:26am

[View Quote] Try to open his IP in your web browser :)

>
> EEW! get it off!!!!!! ;-) I wonder who it was...

Your log should contain the requestor's IP. The fellow who wanted to infect you has no clue about it! This worm spread without human intervention.
Andras

agent1

Aug 8, 2001, 11:43am

Don't know if any of you read slashdot, but apparently you can run http://$IP$//scripts/root.exe?some-commandline-command ... apparently root.exe is just cmd.exe.

-Agent1

[View Quote]

wing

Aug 8, 2001, 12:39pm

[View Quote] Theres a rule that I always follow while installing M$ O$'s. NEVER do a typical install. It installs components you don't want and
not the ones that you DO want (Solitaire but no charmap, IIS but no Dialup networking, IPX/SPX protocols but no TCP/IP, demented
things like that)

john viper

Aug 8, 2001, 10:10pm

"andras" <andras at andras.net> wrote in news:3B7120AF.1456227B at andras.net:

> Your log should contain the requestor's IP. The fellow who wanted to
> infect you has no clue about it! This worm spread without human
> intervention. Andras

Ah well the sucky part is that Tomcat seems to overwrite the log files when
it is restarted. Damn. Oh well...

_____________________________________________
Jeff Tickle (John Viper, #296714)
jviper at jtsoft.net
http://www.jtsoft.net

john viper

Aug 8, 2001, 10:12pm

"agent1" <Agent1 at my.activeworlds.com> wrote in
news:3b714216$1 at server1.Activeworlds.com:

> Don't know if any of you read slashdot, but apparently you can run
> http://$IP$//scripts/root.exe?some-commandline-command ... apparently
> root.exe is just cmd.exe.
> <snippety snip snip>

Good ol' M$. You might think they actually encouraged crackers...

Ah wait, no. They DO encourage the crackers to do their cracking, but once
the cracking is done, they can sell the fix for a couple of kajillions of
bucks.

_____________________________________________
Jeff Tickle (John Viper, #296714)
jviper at jtsoft.net
http://www.jtsoft.net

ananas

Aug 10, 2001, 8:29pm

You can "win" an IIS by installing software like voice chat
or webcam stuff. Some require IIS and activate/start it
without asking.

[View Quote] --
"_
|
/\
\ /
__/ /_

Awportals.com · ProLibraries Live · Twitter · LinkedIn