Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> Some stock machines which have default locked accounts > running SSH Secure Shell 3.0 are vulnerable to > arbitrary logins. This is a serious problem with > Solaris, for example, which uses the sequence "NP" to > indicate locked administrative accounts such as "lp", > "adm", "bin" etc. Some Linux machines which have > accounts with !! in the etc/passwd or /etc/shadow such > as xfs or gdm are also vulnerable. Since it is relatively > easy to become root after gaining access to certain > accounts, we consider this a potential root exploit. Since on Solaris all the standard binaries(sh, ls, rm, etc.) are bin owned, all systems with SSH-3.0 should be considered to be completely rootable by even basic unix-aware attackers. Worse, the nature of the SSH protocols is that the exact version of the SSH server shows up upon initial connection to the SSHD port. This means a mass scan, combined perhaps with minor TCP property analysis, will reveal both the vulnerable SSHD and the specific OS whose accounts are to be attacked. Mass SSH scanners are available; it may be worthwhile as an administrator to search and cleanse your network before someone else does. While you're at it, watch for OpenSSH 2.2.0p2 in particular, as there apparently exist Linux root exploits for that obscure deattack.c bug found several months ago. The big issue here, of course, is not that sshd incorrectly checks the cryptographic hash of an inadequately sized password but that it checks it at all. NP, as far as I know, specifically stands for No Password (acceptable, *not* needed), and !! I believe has the same meaning for Linux(! for "no"). SSHD has traditionally when possible directly tested its passwords straight through most available interfaces, be them a raw password file or a PAM call. But when the SSHD checked the cryptography of NP or !!, it failed to successfully parse the critical message in the password database: Let Nothing At All, No Matter What, In. When such a message exists, it deserves immediate servicing. They expected the cryptography to fail; it was an implicit assumption that an explicit security-critical demand would be serviced automatically. The assumption was incorrect, and now a reasonably major hole exists. Yours Truly, Dan Kaminsky, CISSP http://www.doxpara.com
URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Secure Shell Community, A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password fields consisting of two or fewer characters. Unauthorized users could potentially log in to these accounts using any password, including an empty password. This affects SSH Secure Shell 3.0.0 for Unix only. This is a problem with password authentication to the sshd2 daemon. The SSH Secure Shell client binaries (located by default in /usr/local/bin) are not affected. SSH Secure Shell 3.0.1 fixes this problem. Please note that if using a form of authentication other than password, AND password authentication is disabled, you are NOT VULNERABLE to this issue. PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1 Solaris 2.6 thru 2.8 HP-UX 10.20 HP-UX 11.00 Caldera Linux 2.4 Suse Linux 6.4 thru 7.0 Please note that other platforms not listed here may also be vulnerable. PLATFORMS NOT IMPACTED: Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable. Please note that other platforms not listed here may also be immune. SCOPE Some stock machines which have default locked accounts running SSH Secure Shell 3.0 are vulnerable to arbitrary logins. This is a serious problem with Solaris, for example, which uses the sequence "NP" to indicate locked administrative accounts such as "lp", "adm", "bin" etc. Some Linux machines which have accounts with !! in the etc/passwd or /etc/shadow such as xfs or gdm are also vulnerable. Since it is relatively easy to become root after gaining access to certain accounts, we consider this a potential root exploit. DETAILED DESCRIPTION During password authentication, if the field containing the encrypted password in /etc/shadow, /etc/password, etc. is two or less characters long, SSH 3.0.0 will allow anyone to access that account with ANY password. The bug is in the code that compares the result of calling crypt(pw, salt) with the value of the encrypted password in the /etc/shadow (or /etc/password) file. SSH Secure Shell Server 3.0.0 does a bounded string compare bounded to the length of the value stored in aforementioned file (2 characters in this case) against the return value of crypt(). The return value of crypt() is 13 characters, with the first two characters being the salt value itself. The salt value used is the first two characters of the encrypted password in /etc/shadow (or /etc/password). A 2 character string comparison between the 2 character encrypted password in /etc/shadow, and the 13 character crypt() return value, whose first two characters ARE the 2 characters from the password in /etc/shadow. The strings match, and the 3.0.0 daemon then accepts the password, no matter what is input. SOLUTIONS Preferred Immediately upgrade to SSH Secure Shell 3.0.1 which will be available on our e-commerce site http://commerce.ssh.com shortly, and is available on the ftp site now - ftp://ftp.ssh.com/pub/ssh A patch for 3.0.0 source code is also available there. Alternative work-arounds Disable password authentication to the SSH Secure Shell daemon (sshd2) in the /etc/ssh2/sshd2_config and use another form of authentication such as public key, SecurID, Kerberos, certificates, Smart Cards, or hostbased to authenticate your users. These alternative authentication methods are NOT VULNERABLE. Please see our SSH Secure Shell support web pages for more information on how to enable these authentication methods. OR If you cannot disable password authentication fully, limit access to the sshd2 daemon to allow only users with entries in the /etc/passwd and /etc/shadow which exceed two characters. This can be done using the AllowUsers, AllowGroups, DenyUsers, and DenyGroups keywords in the /etc/ssh2/sshd2_config file. See our SSH Secure Shell support web pages http://www.ssh.com/support/ssh and man sshd2_config for more information. OR Assign a valid password for each account. Because it is possible that assigning a password to some system accounts could cause problems on some operating systems, this work-around is limited and is provided only as a last-resort alternative. OR Use the following patch in the source code: """ File /lib/sshsession/sshunixuser.c Function ssh_user_validate_local_password Location near line 953, before /*Authentication is accepted if the encrypted passwords are identical. */ Add lines if (strlen(correct_passwd) < 13) return FALSE; "" We apologize for any inconvenience this may cause. SSH Communications Security takes security issues very seriously, and a CERT advisory and submission to Bugtraq regarding this issue have been submitted. Please make every effort to ensure that your systems are protected using one of the above methods as quickly as possible. As this information becomes widely known, your systems could be at even greater risk
Tool released to scan for possible CodeRed infected servers
In an effort to help administrators find all systems within their network that are vulnerable to the .ida buffer overflow attack, which the "Code Red" worm is using to spread itself, we have decided to release a free tool named CodeRed Scanner. It can scan a range of IP addresses and report back any IP addresses which are vulnerable to the .ida attack, and susceptible to the "Code Red" worm. The program will allow you to either scan a single IP address or a Class C (254) set of IP addresses. It will output a list of IP addresses which can be double clicked on to get information on how to patch your system from the .ida vulnerability and to eradicate the "Code Red" worm from your system. Also this is a program you get to install on your own computer so you do not have to go to a website and register to scan 1 IP address at a time etc... like some of the other scanners we have seen that scan for the CodeRed Worm. We are able to remotely scan IP addresses (web servers) for the .ida vulnerability (CodeRed Worm) without having to test your system via a buffer overflow, which can bring your web server down. Instead we use a technique which we have taken from Retina that allows CodeRed Scanner the ability to test a web server remotely, without causing any harm to it. This allows us to see if the .ida patch is installed or not (if the server is infected or susceptible to infection). To download CodeRed Scanner go to: http://www.eeye.com/html/Research/Tools/codered.html 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
RE: RED-CODE WORM PATCH possibly not working ????
On Friday, July 20, 2001 5:36 tigerblue wrote > > > i have got some IIS4-and some IIS5-servers. I was checking the logfiles = > to get a short info about the red-code worm. The IIS4-servers were = > respondig to the get default.ida with a http 40x code, but the IIS5 on = > w2k machines were all responding with an http 200 code. Hmmm strange = > =B4cause all the servers have been patched in the last month against = > this idq-vulnerability (MS01-033). > > I=B4m really a wondering, is it normal, that the w2k servers reponding = > with an 200-Code or is mabe the patch not working at all... does anybody = > had this effect The 404 code will return only when you have ida mapping disabled. The patch fixes the buffer overrun problem; it does not disable the mapping. To test for whether the patch is applied, you should look at the file date of the idq.dll; if it is 5/24/2001, the patch has been applied. Steve Halford [EMAIL PROTECTED]
Re: [BUGTRAQ] Full analysis of the .ida "Code Red" worm.
On Fri, 20 Jul 2001, Nick FitzGerald wrote: > No -- it is "constrained" because it has reached the *UTC date* (not > time as initially reported) when it is programmed to switch from > "spread like crazy" mode to "DoS one of the IPs that was part of > www.whitehouse.gov" mode. In about ten days it will flick back to > the "spread like crazy" mode. I've just done a quick check of my Apache logs, we have something like 20 virtual hosts each with a different IP address but in the same block, and while all the others have only received something like 20 attacks, one of them has received more than 3500, coming from 2150 different hosts. FYI I've split attacks by top level domains, when the IP was resolvable, and it gives: net : 447 com : 377 edu : 70 jp : 65 tw : 39 de : 27 fr : 25 ca : 25 nl : 22 es : 18 uk : 17 se : 17 it : 15 dk : 15 at : 12 gr : 10 cn : 10 ch : 10 be : 10 ru :9 us :8 no :8 fi :8 cz :8 au :8 pl :7 org :7 br :5 za :3 si :3 is :3 hu :3 hr :3 cl :3 cc :3 arp :3 ua :2 pt :2 nz :2 nu :2 mx :2 kr :2 ie :2 hk :2 tr :1 th :1 sg :1 mil :1 int :1 il :1 bn :1 bg :1 ar :1 the remaining is unresolvable, this was the majority. Jerome Alet - [EMAIL PROTECTED] - http://cortex.unice.fr/~jerome Fac de Medecine de Nicehttp://wwwmed.unice.fr Tel: (+33) 4 93 37 76 30 Fax: (+33) 4 93 53 15 15 28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE
Re: "Code Red" worm - there MUST be at least two versions.
On Fri, 20 Jul 2001, Don Papp wrote: > I wonder if I have seen this variant - a person I emailed has a > server whose web pages served looks a lot like the Code Red worm's output > (1 line of simple html) displaying > > FUCK CHINA GOVERNENT > and p0isonb0x (or something like that) > > On a black background. The web files themselves are untouched. > > Actually I have the source of what it spits out: > > align="center">fuck CHINA > Governmentfuck > PoizonBOx color=red>contact:[EMAIL PROTECTED] > I would tend to assume that isn't a variant of the worm. It's certainly not CRv1 or CRv2. The HTML is about 40 bytes longer than that in Code Red, so it would be a bit more than simply changing the HTML code in the worm and relaunching; you'd have to adjust the content length reference, and a number of other items. I would think it's non-trivial. I would think this was a hand-done response to Code Red. Ryan
RE: "Code Red" worm - there MUST be at least two versions.
> I wonder if I have seen this variant - a person I emailed has a >server whose web pages served looks a lot like the Code Red worm's output >(1 line of simple html) displaying > FUCK CHINA GOVERNENT More likely, USA Government. > and p0isonb0x (or something like that) and PoizonBOx >From Sadmind worm. http://vil.nai.com/vil/virusSummary.asp?virus_k=99085 (named BoxPoison) Jimmy [EMAIL PROTECTED]
Re: "Code Red" worm - there MUST be at least two versions.
On Fri, Jul 20, 2001 at 12:15:46PM -0600, Don Papp spake thusly: > I wonder if I have seen this variant - a person I emailed has a > server whose web pages served looks a lot like the Code Red worm's output > (1 line of simple html) displaying > > FUCK CHINA GOVERNENT > and p0isonb0x (or something like that) > > On a black background. The web files themselves are untouched. I think this was something else - maybe a similar worm, but it used a different attack: "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts\ shell.exe" 404 - The machine that sent that to me had that same web page up, and I also got one from a different IP (on the same subnet) a few hours before that. That was a week ago though - July 13... -- Jon-o Addleman
Full analysis of the .ida "Code Red" worm - solve the problem
To protect your IIS against it you can do this: Remove the ".ida" entries in ISAPI-assignments of each site. There for you can use the management console -> basic directory -> (application settings) -> configuration. A simple other way is to remove idq.dll from your system32 directory, if you don't use the index server. Since we've done this, our servers are immune. * * Frank Steinert * mailto:[EMAIL PROTECTED] * http://www.protime.de * * proTime GmbH * Josef-von-Fraunhofer-Str. 9 * D-83209 Prien * Tel: 08051-6916-25 * Fax: 08051-6916-11 *
Re: "Code Red" worm - there MUST be at least two versions.
Nope. Different worm altogether. > I wonder if I have seen this variant - a person I emailed has a >server whose web pages served looks a lot like the Code Red worm's output >(1 line of simple html) displaying > > FUCK CHINA GOVERNENT > and p0isonb0x (or something like that) "fuck USA Government" "fuck PoizonBOx "> Sadmind worm a few months ago...but they all look the same. http://www.cert.org/advisories/CA-2001-11.html
RED-CODE WORM PATCH possibly not working ????
Hi, i have got some IIS4-and some IIS5-servers. I was checking the logfiles = to get a short info about the red-code worm. The IIS4-servers were = respondig to the get default.ida with a http 40x code, but the IIS5 on = w2k machines were all responding with an http 200 code. Hmmm strange = =B4cause all the servers have been patched in the last month against = this idq-vulnerability (MS01-033). I=B4m really a wondering, is it normal, that the w2k servers reponding = with an 200-Code or is mabe the patch not working at all... does anybody = had this effect best regards tigerblue MCSE systemadministration
Re: Two birds with one worm
We seem to be seeing similar printer problems with Xerox Docuprint N32 printers. It appears to be yet another example of a badly-written embedded web server. --tep -- Tom E. Perrine ([EMAIL PROTECTED]) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.858.534.5000 "Libertarianism is what your mom taught you: 'Behave yourself and don't hit your sister."' - Kenneth Bisson of Angola, Ind.
Origin of Code Red worm?
Hi all. Now that the infectiong from code red seems to have slowed down, has anybody had a chance to look at where it originated? It would certainly seem to be Chinese in origin, but has anybody claimed responsibility? Do any of the early victims want to contribute web server log entries that point to a source? Regards, Dave Taylor
Coverage on Code Red worm
As the Code Red worm is one of the security issues BugTraqers and media is talking about a lot these days, we did a detailed coverage with Code Red alerts, news clips, AV vendor comments and solutions. It is available on the following URL in few formats (html, txt, pdf): http://www.net-security.org/text/articles/coverage/code-red/ Sincerely, Berislav Kucan Help Net Security - http://www.net-security.org IP-Solutions - http://www.ip-solutions.dk E-mail: [EMAIL PROTECTED] Phone: +385 91 513 9159
Re: "Code Red" worm - there MUST be at least two versions.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Jul 2001, Chris Paget wrote: > Secondly, can someone capture a copy of this second variant and > dis-assemble it? > > I intend to add egress filters to one of my servers and allow it to > become infected; if anyone wants to volunteer to help me pick it apart > afterwards it would be appreciated. I wonder if I have seen this variant - a person I emailed has a server whose web pages served looks a lot like the Code Red worm's output (1 line of simple html) displaying FUCK CHINA GOVERNENT and p0isonb0x (or something like that) On a black background. The web files themselves are untouched. Actually I have the source of what it spits out: fuck CHINA Governmentfuck PoizonBOxcontact:[EMAIL PROTECTED] I've asked that he do a few things (including check for outbound connections to port 80s of random IPs, patch, reboot, etc) but haven't heard from him yet - his site is no longer up either. Don P http://aeinnovations.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7WHVT2KCg0hzfOnQRAkX9AKCatgkSAUQEugcNbpcw2UHaWNgMLgCfaC2R Id2u7spws0eFvrx6Qmn23rg= =ufnI -END PGP SIGNATURE-
RE: Two birds with one worm
I can verify an issue with HP JetDirect as well. We have two HP LaserJet 4000N printers that started doing the exact same thing yesterday, the printer itself crashes, dumping a page of exception data from the card and freezing with an "EIO 2 ERROR" message. I see no information (yet) on the HP web site regarding any connection to the Code Red Worm. Anybody heard anything different? Randall Berger '91 Systems Analyst Department of Student Financial Aid Texas A&M University (979) 862-1539 FAX (979) 847-9061 http://faid.tamu.edu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 2:26 AM To: [EMAIL PROTECTED] Subject:Re: Two birds with one worm I can confirm that this worm is killing JetDirect cards. The HP JetDirect Card in our HP LaserJet 4000N has been steadily crashing as infection attempts hit it; the result is that, every ten to thirty minutes or so, the printer itself crashes, dumping a page of exception data from the card and freezing with an "EIO 2 ERROR" message. A hard reset of the printer is required to make it operational again. -- Patrick Chipman System Administrator University of Memphis Cognitive Science Lab - Original Message - From: "Brian.J.Mauter" <[EMAIL PROTECTED]> Date: Thursday, July 19, 2001 11:10 pm Subject: Re: Two birds with one worm. > Hi, > > Testing various other devices on my subnet, I found that my 3Com > WirelessLAN Access Point was not affected, but my HP 4500 was > because it has an HP > Jet Direct Card in it. I do not have conclusive evidence that it > was Code > Red, but the printer has never acted strangely before. When I > call the > printer's webserver, I get a "Device is not attached" error along > with "HP > JetDirect [Not available:SNMPException: no response]" at the top > of the > page. All of the admin functions fail and I cannot determine if the > printer is even functioning. (It's remote, or else I'd walk over > to it > and look.) > > I don't know, but this may get any HP device with JetDirect. Can > anyonequalify that?
Re: Full analysis of the .ida
This is hogwash. When Microsoft issued the bulletin, it was quite clear that it was to fix an Index Server problem. Since we, among others, had not been running the Index Server because of its historical security flaws, the patch did not appear to be required. You don't blindly apply patches that have no apparent bearing on your system -- it may break other things. Surprise! It was. This was truly a misleading security release. In effect, there was no notification. You can't expect harried sysadmins to read between the lines. Even Microsoft themselves did not feel the need to apply the patch to some servers, probably for much the same reasons. -- Mardy > > This DOES raise some pretty fundamental questions about the security of > > all the infrastructure, because, in theory the compromised servers > > _could_ have been exploited more extensively and _could_ be delivering > > nastily compromised stuff around. I have no reason to believe it has > > happened, but still... > > > I have to disagree. Microsoft released a patch for this issue on 6/18/2001. > Here we are, a tad over a month later, and the issue is being exploited en > masse. This calls to question the attention of systems administrators to > their networks. The days of selective application of security patches are > long since over. IMHO, systems affected by this recent outbreak are being > administered by techs that need to pay closer attention to their > installations and keeping them up to date. > > As the world reliance on computer systems continues to increase, it become > more and more imperative that people learn these are not simply toasters > that sit on the kitchen counter. Regular maintenance and attention is > required and an irresponsible or ignorant attitude towards these things is > the true threat to the infrastructure. The only security issue here is the > human element as always. Microsoft has already come up with a tool that > automagically notifies users/admins of the need to update their system > within moments of a patch being released. What should they do next -- > auto-patch the systems for the user/admin to ensure the security of the > infrastructure? Maybe the user/admin needs to learn about that toaster on > the countertop. > > > James >
RE: Mitigating some of the effects of the Code Red worm
Microsoft has been so good about locking people out of using Windows XP and Office XP if they don't activate their product. How about locking people out of using IIS if they don't keep their patches up to date. Microsoft has the technology to expire unpatched versions, say, every 30-to-60 days. These computers would then revert to "reduced functionality" mode where they couldn't connect to the Internet. -Original Message- From: Ryan Russell [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 02:45 To: LARD BENJAMIN LEE Cc: BUGTRAQ Subject: Re: Mitigating some of the effects of the Code Red worm ... Having done my usual lecturing, I will say that this is the first time I've even been willing to entertain the idea of a good worm... I just don't know what else can fix a problem of this scale. You will never, ever come to agreement on how it should be done. Either some government will decide for you, or some hacker who is willing to take one for the team. I'm not real comfortable with either of those two setting policy for the Internet. Ryan
RE: Safe(?) testing for idq.dll vulnerability
While the hfcheck utility is a great thing to have you must have netbios access to the system as well as an account. It will not help when trying to assess the risk posture of a system remotely over HTTP and HTTPS alone. -chris _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: Safe(?) testing for idq.dll vulnerability
On Fri, 20 Jul 2001 01:59:28 +, Chris St. Clair wrote:
>I had to come up with a way to test a server remotely for this
>vulnerability without actually killing it and running the plerthora
>of exploit code that is out. This is what I have, hopefully someone
>can use it.
Good ideas.
Marc Maiffret discusses just such a test at
http://www.8wire.com/article_render/?aid=2094
(may reqire registration)
McAfee is offering "CyberCop WormScan" free
http://www.mcafeeasap.com/asp_subscribe/trial_cc_wormscan.asp
Matt Scarborough 2001-07-20
>Known Vulnerable Testing Platform
>The first round of tests was run on a Windows 2000 Server running
>IIS 5.0 (if anyone has similar analysis for IIS 4.0 I'd love to
>see it) with AND without SP1 (no difference) not patched for MS01-033.
>
>Results
>Sending 1-219 bytes yields the error:
>The IDQ file NULL.ida could not be found.
>Nothing written to the event log.
>
>Sending 220-231 bytes we get:
>File .
>Error 0xc005 caught while processing query
>Nothing written to the event log.
>
>Sending 232-??? bytes we get:
>No response from web server.
>System event log event ID 7031 from Service Control Manager.
>IIS services are then stopped and restarted.
>
>
>Known Invulnerable Testing Platform
>Another system running Windows 2000 Server, IIS 5.0 with SP1 and
>the patch for MS01-033.
>
>Results
>Sending 1-199 bytes yields the error:
>The IDQ file NULL.ida could not be found.
>Nothing written to the event log.
>
>Sending 200-??? bytes we get:
>File .
>Error 0x80040e14 caught while processing query
>Nothing written to the event log.
>
>So, in summary, to test do the following:
>send 200 bytes
>if response = "Error 0x80040e14 caught while processing query" the
>sytem is patched.
>if response = "The IDQ file NULL.ida could not be found." the system
>is not patched.
>
>I can't take all the credit for figuring this out. Like most people,
>I owe it all to the following bit of code:
>#!/bin/sh
>SIZE=1
>export SIZE
>
>while [ $SIZE -lt 201 ]; do
> BUFF="`perl -e 'print \"x\" x $ENV{SIZE}'`"
> echo -e "GET /NULL.ida?$BUFF=X HTTP/1.1\nHost: iluvpaul\n\n" | \
> nc host port
> SIZE=`expr $SIZE + 1`
>done
Get free email and a permanent address at http://www.amexmail.com/?A=1
Code Red / Microsoft Patch Q300972i / NT Service Packs
Microsoft's Security Bulletin MS01-033 (the one announcing the vulnerability
being used by Code Red, and the patch availability) states :
"The Windows NT 4.0 patch can be installed on systems
Windows NT 4.0 Service Pack 6a."
(See
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/security/
bulletin/ms01-033.asp, and click "Additional information about this patch".)
And the relevant KB article
http://support.microsoft.com/support/kb/articles/Q300/9/72.ASP says
"NOTE: Due to file dependencies, this hotfix requires
Microsoft Windows NT 4.0 Service Pack 6a."
Can anyone provide any experience of successfully using the patch
("Q300972i.exe") on an NT4 Server running *earlier* service packs ? A
statement from Microsoft would be nice (like: What is the impact of applying
the patch to a server running an earlier SP ? What would be broken ?)
[ We have a couple of NT4 servers stuck with earlier SPs (one with SP4, and
one with SP5) due to alleged non-certification of their major application
with any later service pack. I've set up a test NT4/SP5/IIS4 server, and
installed Q300972i, and IIS is back up & running without apparent sickness
...]
Thanks for any light anyone can shed.
Nick Boyce
EDS, Bristol, UK
Program and Source for Removal of IDA/IDQ Script Mappings (in response to Red Code Worm)
Hello everyone This is in response to the sheer numbers of web server that got pummeled by this new worm. While many people and firms created exploit/checks/Advisories for this Dangerous exploit, we have yet to see a "helping hand" program...until now! Having previously worked at a site with a huge server farm I experienced how painful it can be to go to 175 machines to install a single hot fix. This program will allow you to sit at your desk and simply yank the script mappings from the web server altogether and eliminate some 6 or so vulnerabilities that are associated with Index Services. This is a very simple program that you can use to remove the .IDA and .IDQ script mappings from the root of a web server and from all its sub-web sites. We have included the source code as well as the setup packages. (the metautil.dll has to get installed) for your perusal. You may retrieve the 1.43 meg download from our web site at http://www.criticalwatch.com/downloads/IDA_ScriptRemoval_Util.zip Nelson Bunker, CISSP V.P. of Security Critical Watch
Code Red worm address generator pattern
I posted this chart before showing non-legitimate http syn scans targeting my class-b address space on 07/19 broken down by hour (EDT, GMT-4); probable code red probes. However I did some further crunching and added an additional column showing the number of destination addresses within my class-b address space being targeted by non-legitimate http syn scans during that 60 minute timeframe. Note that the number of addresses being targeted held steady and then suddenly jumped until it covered nearly the entire class-b range. This jump coincides with the increase in source addresses scanning. Worm variant? Or sudden increase in efficiency? # Unique Source# Unique Dest Hour # Code Red Worm ScansAddresses Scanning Addresses being EDT Scanned - - --- 00 126992450562 01 130592577562 02 132722590541 03 130562564525 04 132832632507 05 132292612502 06 135542601468 07 135172608506 08 137462685612 09 168193325 1724 10 365897838 8338 11 116083 26823 28462 12 295348 68085 51459 13 466542 103522 59699 14 520973 113451 60881 15 513513 115124 60814 16 513894 90931 60900 17 499642 75 60469 18 480850 106215 59987 19 449712 97699 58908 20 266877319 8507 21 91972181 3046 22 77821814 2570 23 70561648 2343 Ken Eichman Senior Security Engineer Chemical Abstracts Service Tel: (614) 447-3838 ext 3230 2540 Olentangy River RoadFax: (614) 447-3855 Columbus, OH 43210 Email: [EMAIL PROTECTED]
Re: CodeRed: the next generation
I've now analyzed data from three different sites, using the simple random spread model I outlined in my post to Incidents very early this morning. All three sets of data are very consistent with each other, and all are well explained by the hypothesis that the CRv2 worm was released in the early hours of yesterday morning, that it had a reasonably good random spread algorithm (unlike CRv1) and that it was capable of a spread of approximately 1.8 compromises/hour. (That is, a compromised host in the early stages of the infection could find and compromise about 1.8 other hosts in an hour - in the later stages it drops off because most hosts are already compromised. It probably compromised almost all the .ida vulnerable hosts on the Internet over the course of about twelve hours before being cleaned up and/or turning itself dormant. There's no doubt a great deal of it still lieing dormant. This was definitely a big bad worm. I imagine the worm writers can improve significantly on 1.8 compromises/hour though, so it's only going to get worse. I'm sure we can expect to see smarter targeting too. The analysis from early this morning is at http://www.silicondefense.com/cr/ I'll hopefully get a fuller analysis out some time soon. Stuart. -- Stuart Staniford --- President --- Silicon Defense ** Silicon Defense: Technical Support for Snort ** mailto:[EMAIL PROTECTED] http://www.silicondefense.com/ (707) 445-4355 x 16 (707) 445-4222 (FAX)
Code Red Worm, New information
Heya all, By now we are all aware of the serious nature of the Core Red Worm. One of the most powerfull lessons we can all take away from this is how this community is capable of mustering in times of crisis like in order to face and analyze threats. The traffic accross the Incidents, Bugtraq lists among other sources has been outstanding in terms of rallying against this. A number of efforts are underway to address this situation outside of list discussion, I am going to outline what we are doing here at SecurityFocus. This is not intended to detract from anyone elses work, it's all great, we are just bringing you into our contribution. Notification First, we are in the process of notifying all of the infected IP owners that we know of. This data has been taken from the ARIS Analyzer user base as well contributions from individuals in the community (I will post a public thanks to them just as soon as they give me permission to do so). The list of infected hosts that we are now in the process of notifying against is a little over 40,000 hosts. Each host owner that we can indentify will be recieving a mail outlining the fact that they are infected, which IP's are infected and how to address the situation. New Data Reports Second we are posting a series of reports derived from ARIS Predictor, a SecurityFocus system designed to track events such as these. The data is coming from a system wich is pre-production so it will contain some minor inconsistencies, please take this into account. The data we are posting here is derived from 100 IDS sensors accross 6 continents with statistics derived from a 10 day period, the 10th until today. The information available herein is quite interesting and worth a read. We will make a point of making this type of information available whenever we face a problem like this in the community. Now, onto the reports: 1. New Attacks Trend Report This report displays the frequency of attacks which attacks have been viewed (in terms of abnormal compared against a baseline) over the last 10 days. It clearly shows our first contact with the worm on the 11th (earlier than previously thought). Other reports (not listed here) show the first contact happening at 17:00 GMT in the USA on the 11th. http://www.securityfocus.com/data/staff/Trends.pdf 2. Top 10 Destination (Attacked Countries) for the Core Red Worm This report displays the top ten victim countries for which the greatest number of attacks is destined. This pie graph and all of the others only tabulate data from the IDS's which saw the attack, therefore the numbers will not add up to 100%. http://www.securityfocus.com/data/staff/destination.pdf 3. Average Attacks Based On Averaged Time Of Day (10 days) This graph shows the frequency of attacks accross time of day as seen by each continent. Very interesting. http://www.securityfocus.com/data/staff/timeofday.pdf 4. Average Attacks Based On Averaged Time Of Day (1 day) This graph shows the frequency of attacks accross time of day as seen by each continent for the 19th. http://www.securityfocus.com/data/staff/timeofday-1.pdf 5. Attacked Industries Report This report displays the frequency of attacks targeted against specific industry types over our 10 day period. http://www.securityfocus.com/data/staff/industry.pdf 6. Targets As Determined By Revenue This report displays the frequency of attacks targeted against companies of a particular annual revenue range. http://www.securityfocus.com/data/staff/revenue.pdf We could post a large number of other reports with more granular data or against other data points, but this should be sufficient for the time being to help augment the current data available. We will quite possibly post other information in the near future. Cheers, Alfred Huger VP Engineering SecurityFocus "Vae Victis"
CodeRed: the next generation
The following is a description of a "variant" "Code Red" worm that we have found to be in the wild. Sorry for the rough content but we thought it would be best to get this information out sooner and worry about pretty text formating later ;-] -- In this text, we will be refering to the original "Code Red" worm as CRv1 and the second generation "Code Red" worm as CRv2. This does not preclude further generations/varioations still in the wild, it is just an analysis of the worms we have access to. This information is not currently public. Well, sort of is (we published the disassembly of CRv1, so CRv1 targeting info may be known), but the existance of CRv2 with different targeting has not been verified until now as far as we know. For the evidence surrounding the impetus for this second worm search, please examine Stuart Staniford's ([EMAIL PROTECTED]) excellent statistical analysis of worm hit data. The CRv2 worm has the following charecteristics: second:milisecond randomness added to ip selection process removal of web page hack display (no notice to the end users via a defaced page) All other parts of the worm are the same. (still attacks whitehouse.gov (but the IP address has been blackholed), has time limits/definitions of attack, notworm lysine) The worst part about this means that our original tracking methodology (sensors early in the sequence) is no longer accurate, since CRv2 infected hosts do not contact early hosts, nor reliably contact any point (other than the blackholed IP address that use to point to whitehouse.gov). This means that potentially ALL(ie: global, coprehensive) ids/logs data must be organized and sorted to find infected hosts. The Differences: It has 13 or so pertient bytes changed, adding a time based randomness factor and disabling page defacement. The code had been there all along. It had intentially (we must assume) been disabled in CRv1 , then reenabled near the end of the cycle. There has been discussion that this was a natural progression of the worm code, however, we do not beleive this is the case. From analsysis of CRv1, there seems to be no distinct way to shift the nessecary bytes to generate CRv2. Hence, it is my belief that this is a modified worm, rereleased. It has been posited that the CRv1 was a target aqusition mechanism, gathering data on infectable hosts to gain a high initital base for the following CRv2 infection. The Ip Selection Process: We will display the effecive CRv1(sequence), and the effective CRv2(timebased) ip selection processes. This is a one byte change, at offset 9C2. it changes the storage of some time based computations that were performed in CRv1 but discarded. The new byte changes the storage location from EBP-1B0( a general purpose holder stack var) to EBP - 18C(the location of the ip). This means that the timevars are actively used in CRv2, while being discarded in CRv1. These are the targeting algorithms(complete, as far as we can discern) that are the asm in the CRv1 worm and also in the CRv2 worm. Seeding the "PRNG" for these examples seed is used for ip through the first iteration of the connect loop. the seed does not change between CRv1 and CRv2, but each thread in the worm has a mildly different seed. seed = threadcount(based on 1) * 50F0668D; CRv1: The ipselection process in CRv1 is a simple sequence generator. This caused the early sequences that we noticed and refered to in our (eEye's) initital warning advisory: ip = (ip * 0x0CF3383) + 0x76BFE53; CRv2: The ipselection process in CRs2 is signifigantly more complex. It takes use of time and a whole lot more input operations. In the following secmsec is the DWORD pair of seconds and mseconds returned from GetSystemTime ip = (ip + secmsec*secmsec*0x0CD59E3 + secmsec*0x1E1B9) * 0x0CF3383 + 0x76BFE53 Other Details: Coincidentally, if this isn't general public knowledge, the worm is smart enough to avoid attacking the 127.x.x.x and 224.x.x.x subnets using the following logic after setting the ip. if( (ip & 0xFF == 0x7f) || (ip & 0xFF == 0xE0) )ip +=0x20DA9; the Hacked Page: The second difference between CRv1 and CRv2 is that CRv2 does not deface the webpage of an infected system. It does this by having 12 bytes different from CRv1. When TcpSockSend is hooked(this still happens), CRv2 points this to a basic redirect that performs harmless actions and returns without actually changing any content. Crv1 pointed to a replacement, CRv2 points to basically a donothing function. what is happeinging is that the label "PADDING_BYTES" actually is padding bytes in CRv1(the code does not disassemble to any sane code). CRv1: We've used ida's data feature to show the "padding data" as dwords(instead of a bunch of bytes) CD4 - EB F8jmp short near ptr HOOK_FAKE_TCPSOCKSEND+4 ; Jump CD6 - 22 6E 84 32 PADDING_BYTES dd 32846E22h CDA - 03 75 B3 CAdd 0CAB37503h CDE - 5A 04 56 34
Re: "Code Red" worm - there MUST be at least two versions.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 20, 2001 at 05:30:16PM +0100, Chris Paget wrote: > The only conclusion is that there is another version of the "Code Red" > worm in the wild, which has a correct randomisation routine (and > possibly other differences). > As I posted yesterday, and followed-up by more log parsing done this morning, all the evidence I have points to this conclusion as well. Logs at three sites show two different types of attacks: 1) A large netblock port scan, followed up by a targetted attack to open HTTP ports along the scan. 2) Random attacks, by a single host against a single host, with no follow-up or hint of an impending attack. The attacks on my home netblock (a /28 on a DSL connection) were skewed about 60/40 in favor of the scanning variant, and there were 65 total attacks through the six-hour period between 1000 PDT and 1600 PDT (1800 - GMT). Attacks on my corporate and production networks (discontiguous netblocks through a colo) were not only stacked about 90/10 in favor of the random directed variant, but were also over 100x greater in frequency during the same time period. Also, the frequency of the scanning variant attacks dropped off during the time period, while the frequency of the random directed version increased. I saw no scanning attacks after about 1445 PDT. This suggests that the random directed variant is more virulent, and also (unless I'm just lucky) has some sort of logic which puts a lesser weight on known cable/DSL/dial-up netblocks, and a higher one on netblocks with more legitimate targets. > The GET request logged by the second worm variant is as follows: > > GET /default.ida > >%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a > > Firstly, can someone confirm whether this is the same as the GET > request logged by the hard-coded worm? > The first request was from a scanning attack: 12.39.137.80 - - [19/Jul/2001:10:32:27 -0700] "GET /default.ida? %u9090%u6858%ucbd3%u7801%u9090%u 6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53 1b%u53ff%u0078%u%u00=a HTTP/1.0" 400 322 The second request is from a random directed attack: 203.127.71.178 - - [19/Jul/2001:16:31:47 -0700] "GET /default.ida?NN NN%u9090%u6858%ucbd3%u7801%u9090 %u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u 531b%u53ff%u0078%u%u00=a HTTP/1.0" 400 322 Both were taken from my home Apache 1.3.19 webserver. They are identical. > I intend to add egress filters to one of my servers and allow it to > become infected; if anyone wants to volunteer to help me pick it apart > afterwards it would be appreciated. My disassembly skills are non-existent, but I and I'm sure the community would love to hear the results. - -- "A true friend stabs you in the front." - Oscar Wilde -BEGIN PGP SIGNATURE- Comment: For info see http://www.gnupg.org iD8DBQE7WHdV36NTGsm+2Z4RAthEAKCAxikWj/r+dfdPDgmq+34+SYimOgCfdA1Y 31GnTACEgLrtcaXFgRaMVQw= =yrl1 -END PGP SIGNATURE-
Re(2): Re(2): 'Code Red' does not seem to be scanning for IIS
I can't argue with your statistical analysis but since CNet used my stats for that chart I have to disagree here. If you look at the bigger picture, the rate of growth since this worm was apparently released on 7/13 (chart below), it was more or less a linear growth pattern until approximately the 1400 GMT timeframe on the 19th, and in fact up until then the growth rate appeared to have leveled off. Daily stats from my IDS of apparent 'code red' scans: Date # Worm Probes# Unique Source Addr's # Unique Source Addr's Probing (For the Day) Probing (Cumulative) ---- -- 07/13 611 27 27 07/1436273 10761079 07/15 215020 34983641 07/16 316828 61377146 07/17 316359 7189 10212 07/18 294345 8247 13866 07/19 4080321 272052 279911 By the way for today as reported by others, my numbers have dropped off dramatically. > From: "Phillip Reed" <[EMAIL PROTECTED]> > Looking at the infected population chart as published on C|Net, I have to > say that the dramatic increase looks exactly like the classical "knee" in a > exponential growth curve. In fact, the entire curve looks like a standard > infection "population vs. time" graph, with the upper end fall-off due to > the saturation of the available uninfected population. No nefarious > modifications are needed here to explain the sudden surge. > > For entertainment value, try creating a chart (I used Excel), plotting > y=x^9. Then look at the curve. The knee starts around x=20 or 21, and the > value takes off from there. No modifications needed. > >>I can correlate what Kelly reports -- *something* happened between 14-1500 GMT >>today to drastically increase the number of 'code red' scans/infections. I'VE >>been tracking them since Saturday on my IDS. Our class-b address space appears >>to be high up on the worms scanning pattern. For all of 7/18 I recorded probes >>from 8247 unique host IP addresses, presumably compromised with 'code red' >>Just during the 1900GMT hour today - one hour of logs - I recorded 'code red' >>hits from 115124 different IP addresses. All of these probes are bouncing off >>our firewall. The drastic increase in infections/probes began between 1300- >>1400 GMT today and *seemed* to start leveling off around 1600-1700 GMT. > > Phillip C. Reed > Network Administration - Cincinnati > > Eviciti > 1148 Main St., 4th floor > Cincinnati, OH 45210 > (513) 929-0785 x218 > http://www.eviciti.com > mailto:[EMAIL PROTECTED] Ken Eichman Senior Security Engineer Chemical Abstracts Service Tel: (614) 447-3838 ext 3230 2540 Olentangy River RoadFax: (614) 447-3855 Columbus, OH 43210 Email: [EMAIL PROTECTED]
Re: 'Code Red' does not seem to be scanning for IIS
Ryan wrote: >Mike Brockman wrote: >> >From what i read about the 'Code Red'-worm, it was supposed to be scanning >> for IIS-servers. It obviously is'nt, i believe it tries to infect >> everything they find on port 80, or something as simple as that. > >Run nc -l -p 80 > worm, and you'll get a copy. It's not scanning >in any sense, it just tries a connect, and sends the string. An anonymous chat room contact yesterday told me they'd had success linking default.ida to their kernel; the worm always seemed to abort its attack after something like 32k of stuff was shoved down the pipe from thier Linux/Apache server. They hypothesized it was causing a buffer overrun in the worm code. After hearing that, I dropped a copy of Shakespeare's "Much Ado About Nothing" into htdocs/default.ida on my system and snooped the net a while. I got one more connect attempt from the worm and it seemed to have dropped its connection after something like 30k of data flowed back, but I was unable to tell what happened at the far end. I only was able to watch one event happen. I've reviewed the eEye analysis and concluded I don't know enough assembly to tell whether it appears to work that way, and I don't have an IIS system to use as a testbed. Can someone who's got a better handle on how the virus' internals are behaving take a look and confirm or deny that this is an effective prophylactic measure? -george william herbert [EMAIL PROTECTED]
"Code Red" worm - there MUST be at least two versions.
I have two different webservers, each of which has been logging infrequent attempts from the Code Red worm to attack it (each box has so far received around 20 such attacks since 18/07/01). Both are immune to it (one has been patched, and the other has the .ida mapping removed). The two servers are using completely different addresses on completely different subnets. Comparing the logfiles for each server, it is clear that no single IP address has attacked both servers. If the only "wild" version of Code Red effectively has a hard-coded sequence of addresses to attack (due to the fixed randomisation seed), one server must necessarily be attacked before the other. Therefore, it would follow that both logs should contain the same IP Addresses, with some time difference between them (unless one or other server has had downtime, which they have not). This is not the case. The only conclusion is that there is another version of the "Code Red" worm in the wild, which has a correct randomisation routine (and possibly other differences). The GET request logged by the second worm variant is as follows: GET /default.ida %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a Firstly, can someone confirm whether this is the same as the GET request logged by the hard-coded worm? Secondly, can someone capture a copy of this second variant and dis-assemble it? I intend to add egress filters to one of my servers and allow it to become infected; if anyone wants to volunteer to help me pick it apart afterwards it would be appreciated. Chris -- Chris Paget [EMAIL PROTECTED] In the battle of Linux Vs Microsoft, remember this: It's hard to not engage in holy wars when everybody knows everything.
Oracle Vulnerability Discovered in OID
There's a new vulnerability discovered in the Oracle Internet Directory (Oracle's LDAP server). It has been in the database since 7/16, but I haven't seen it mentioned here yet. Here are links to the details of the advisory: "Oracle Internet Directory contains multiple vulnerabilities in LDAP handling code" http://www.kb.cert.org/vuls/id/869184 http://www.securityfocus.com/bid/3047 http://otn.oracle.com/deploy/security/pdf/oid_cert_bof.pdf Regards, Aaron C. Newman CTO/Founder Application Security, Inc. 212-490-6022 [EMAIL PROTECTED] www.appsecinc.com -Protection Where It Counts-
Re: Possible CodeRed Connection Attempts
> From: [EMAIL PROTECTED] > We have a sniffer located on the network segment behind our Internet router > and in front of the firewall. The stats below show attempts from Internet > hosts to connect to port 80 on random IP addresses on our class B network. > I have not included any connections to the machines that are running web > servers that are reachable from the Internet. Dave, Wow! I've got a similar setup and have been tracking these probes since 7/13. I'm lining our stats up side-by-side for comparison purposes. Man they're similar! I have no idea why my class-b was getting hit more frequently to start with. I'm speculating that my address space just happened to get hit more by the worm's 'random' address generator. Day HourTotal UniqueTotal Unique Connections Sources Connections Sources === 07/19 00 120 17 12699 2450 07/19 01 81 12 13059 2577 07/19 02 62 11 13272 2590 07/19 03 97 20 13056 2564 07/19 04 85 18 13283 2632 07/19 05 128 20 13229 2612 07/19 06 140 20 13554 2601 07/19 07 212 34 13517 2608 07/19 08 645 137 13746 2685 07/19 09 5717128116819 3325 07/19 10 36879 818636589 7838 07/19 11 150913 34361 116083 26823 07/19 12 362011 79789 295348 68085 07/19 13 519846 48 466542103522 07/19 14 556220 117946 520973113451 07/19 15 547087 115193 513513115124 07/19 16 540009 115983 513894 90931 07/19 17 519810 111290 49964275 07/19 18 499565 107106 480850106215 07/19 19 390019 89331 449712 97699 07/19 20 14541 349326687 7319 07/19 21 97332233 9197 2181 07/19 22 90931882 7782 1814 07/19 23 85391672 7056 1648 =========== Day Total 4171552274041 4080321279911 Ken Eichman Senior Security Engineer Chemical Abstracts Service Tel: (614) 447-3838 ext 3230 2540 Olentangy River RoadFax: (614) 447-3855 Columbus, OH 43210 Email: [EMAIL PROTECTED]
IBM TFTP Server for Java vulnerability
Vulnerability: The IBM alphaWorks TFTP Server for Java available at http://alphaworks.ibm.com/tech/TFTP is vulnerable to a standard directory traversal attack (i.e. ../../). Vendor Response: The vendor was contacted on 19 June 2001 and responded on 20 June 2001 as follows: "We will take a look at the issue and fix it as soon as possible". Further correspondence requesting when a fix will be released has been ignored. Solution: None.
RE: Mitigating some of the effects of the Code Red worm
Also, let's not forget that Max Vision got sent up the river for something similar. Plain and simple, there's no such thing as a "beneficial" worm -- besides, how would *you* like it if you received a message saying, "Hi. You don't know me from Adam, but I just patched your webserver against the latest vulnerability. I didn't throw in any trapdoors or any other bad stuff. Scout's honor." Besides, even the best of intentions sometimes goes straight to crap. Sure, the code you wrote may have tested just fine on your box, but Alice's webserver crashes instantly upon exposure, and Bob's starts to BSoD at random times afterwards. Legally it's a violation of (I think -- please correct me if I'm wrong) 18 USC 1030, the Computer Fraud and Abuse Act 1986. That's assuming it works as planned. If it starts to DoS webservers, you could be held civilly liable for the business impact. Ethically, it's pretty much unconscionable. Just because we *can* take advantage of vulnerabilities, it doesn't necessarily follow that we *should*. The possible for damage or misuse far outweighs any potential benefits. Just my $0.02, as always, I welcome any comments/flames/voodoo curses... Mike -Original Message- From: LARD BENJAMIN LEE [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 7:11 PM To: BUGTRAQ Subject: Mitigating some of the effects of the Code Red worm I'm not sure of the ethical or legal aspects of this, but I don't see why we can't take advantage of three facts: 1) There is something of an ongoing log of affected machines that can be obtained from boxes earlier in the IP list. 2) Machines which have been compromised can STILL be compromised. 3) The worm has a "lysine deficiency" which can be remotely introduced. What I'm getting at, is for someone to create another exploit that creates the C:\notworm file in infected machines and does something to notify whoever is in charge of a particular box (even something as simple as placing you_are_hacked.txt and a link to the patch on the desktop could be beneficial). Even better, an exploit to patch a machine (through removing the .ida and .idq extensions) would prevent the inevitable wave of post-attacks (both from this worm and future attacks). Of course, I'm guessing this is illegal, although I highly doubt you'd be prosecuted. If someone has the expertise to create a "white hack" such as this, I'm sure there are daring admins out there who would happily attempt to stem the flow. If we don't do something, you know it's just a (very short) matter of time before script kiddies, armed with a modified worm and a log of infected machines, do something more sinister. Ben Lard University of Colorado, Boulder
Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities)
On Wednesday 18 July 2001 15:30, Richard Kettlewell wrote: > A better answer might be to stat the file, and reject it if it not a > regular file. Another approach would be to forbid inlining "file:" > URLs from external pages, as described at > http://bugzilla.mozilla.org/show_bug.cgi?id=91316 Exactly this has been done in Konqueror CVS and will be in the upcoming 2.2 release. It wouldn't allow opening of these in the URL bar but it would open them as . -- George Staikos
CodeRed worm honeypot & reverse-tester (in Java)
For shits and giggles, I whipped up a little Java program that serves two functions: - when invoked with a single argument, it connects to that host on port 80, issues an IDQ-style request according to Chris St. Clair's recently posted testing methodology (only tested on IIS/5.0), and tells you if the server appears to be vulnerable or not for example: $ javac CodeRedLogger.java $ java CodeRedLogger infected.system.com - when invoked with no arguments, it turns into a little multithreaded web server on port 80, which for each client connect, sees if the client sends the attack signature, and if so, connects back to the client on port 80 and performs the test mentioned above for example: $ javac CodeRedLogger.java $ java CodeRedLogger (sit back and wait) I just wrote this off the top of my head and tested it on a few servers. Maybe someone wants to modify the tests to handle IIS 4.0 servers. :) The typical disclaimer for exploit code applies: don't use it unless you're allowed to. I wouldn't run this on a public server, and I certainly wouldn't try to reverse-connect and inject the lyseine deficiency via shellcode (although I bet it would be easy). :) I also would not recommend trying to do a WHOIS or trying to send email to the server's sysadmin, because that could just burden the infected systems even more. Again, I just wrote it for shits and giggles. I redirected port 80 on my firewall at home to go to my home PC, and then have been running it on my home PC, so I can watch worm requests come in through my cable modem. :) I've compiled and tested this under Sun JDK 1.2, it should work on any 1.2 and later JDK. Chad Loder Principal Engineer Rapid 7, Inc. http://www.rapid7.com CodeRedLogger.java
RE: Full analysis of the .ida "Code Red" worm.
At 06:55 PM 7/19/2001 -0700, you wrote: >This whole worm process that we have been going through will basically start >from scratch and run its course again when the 1st of next month comes >around. That is sort of true. What happens is on the 20th, the threads that were trying to attack new hosts move to performing the DoS. All of those threads on the 28th move into an infinite sleep. Thus, if you are infected your infection goes dormant. So, in the 'ideal' world, the worm goes dormant on the 1st. But if a single new infection anywhere in the world happens again on the 1st, then everyone (unpatched) is up for infection again. And of course that can happen if anyone has their date set wrong. ...Eric
NetWin Authentication Module 3.0b password storage vulnerabilities / buffer overflows
NetWin Authentication Module 3.0b password storage vulnerabilities / buffer overflows AFFECTED SYSTEMS NWAuth module as used by DMail, SurgeFTP, others... (cfr www.netwinsite.com) I've tested SurgeFTP in particular The source code for NWAuth 2.0 can be found at http://www.netwinsite.com/dmail/nwauth.htm The source is provided on all platforms and for Windows and most Unix based platforms it is pre-compiled, as nwauth.exe or nwauth. DESCRIPTION The 'NetWin Authentication module' which is used by SurgeFTP, DMail and other programs uses a quite 'unusual' hashing algorithm to store the password hashes. Because of the complexity of the hashing algorithm, the users of NWAuth may not be aware of it, but the algorithm is flawed in (at least) two ways : 1) the password hashes can be decrypted 2) one hash can match more than one password So basically I'm saying that one user doesn't have one password, but he can have a few million besides the one that he was actually assigned. (no comment...) Fortunately, SurgeFTP has some anti-hammering techniques implemented to prevent bruteforcing. As for the decryption, I've attached source code (nwauthcrack.c) that will generate all possible passwords for a given hash. The password hashes used by fe SurgeFTP can be found within the files \surgeftp\admin.dat (sysadmin password) & \surgeftp\nwauth.clg (user passwords) Storing the passwords using MD5 hashes would probably be a better idea, maybe added up with a simple cipher to prevent the average script kiddie from attacking the passwordfile with canned tools. (this type of hashing is done by Serv-U FTP) And if one really wants to implement salting, then append the username to the password and feed it into the MD5 hashing algorithm, it has the same effect, it's easier and much more secure. =-=- NWAuth also has alot of buffer overflows riddled throughout the source code (especially older versions, like 2.0), which might lead to serious flaws in programs that use this module. Although version 2.0 probably contained much more of them, here are some examples of buffer overflows which are still not fixed in version 3.0b : -> the nwauth -del command causes an access violation when supplied with a very long username, this might not be a big deal since only administrators are supposed to delete users -> the nwauth -lookup command causes an access violation when supplied a username of about 1000 characters, this might be triggered by an attacker if the program would pass this username from a "USER" command greetz, [ByteRage] [EMAIL PROTECTED] [http://byterage.cjb.net] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ nwauthcrack.c
Possible CodeRed Connection Attempts
We have a sniffer located on the network segment behind our Internet router and in front of the firewall. The stats below show attempts from Internet hosts to connect to port 80 on random IP addresses on our class B network. I have not included any connections to the machines that are running web servers that are reachable from the Internet. Because the firewall blocks port 80 connections, except for the deisgnated web servers, all I have are the initial SYN packets so I don't know for sure that all of these packets are being generated by the CodeRed worm. However, I believe that the vast majority of them are. The stats are broken down by hour and then included a summary for the day. I have included all of July 18th as a baseline for what appears to be "normal" hacking/probing activity. Starting around 9am on July 19, the numbers start to skyrocket. The times are EST. Dave Goldsmith Day HourTotal Unique Connections Sources == 07/18 00 143 20 07/18 01 148 15 07/18 02 89 15 07/18 03 96 18 07/18 04 144 22 07/18 05 127 16 07/18 06 98 15 07/18 07 111 16 07/18 08 116 15 07/18 09 149 22 07/18 10 143 18 07/18 11 175 24 07/18 12 134 22 07/18 13 146 20 07/18 14 118 21 07/18 15 95 17 07/18 16 133 22 07/18 17 104 17 07/18 18 78 17 07/18 19 76 15 07/18 20 67 15 07/18 21 85 15 07/18 22 62 12 07/18 23 105 14 Day Total 2742194 07/19 00 120 17 07/19 01 81 12 07/19 02 62 11 07/19 03 97 20 07/19 04 85 18 07/19 05 128 20 07/19 06 140 20 07/19 07 212 34 07/19 08 645 137 07/19 09 57171281 07/19 10 36879 8186 07/19 11 150913 34361 07/19 12 362011 79789 07/19 13 519846 48 07/19 14 556220 117946 07/19 15 547087 115193 07/19 16 540009 115983 07/19 17 519810 111290 07/19 18 499565 107106 07/19 19 390019 89331 07/19 20 14541 3493 07/19 21 97332233 07/19 22 90931882 07/19 23 85391672 Day Total 4171552 274041
RE: Firewall-1 Information leak
That's not the only way to do it. An 'authenticated' connection can download the topology data. However, the authentication needed for this to work is a shared secret or certificate as defined in the 'IKE' properties for the user (i.e. you can't use things like SecurID for this bit) Once you've got the topology, there's nothing stopping you re-authenticating with a normal authentication method. We do this with a seperate account set up purely for topology downloads. This account does not have any access to the network via the rulebase. Checkpoint have a couple of documents available on how to set this up, they are not that hard to find, searching for 'unauthenticated topology downlads' in the Checkpoint knowledge base should do the trick. Regards, Dave > -Original Message- > From: Bugtraq Account [SMTP:[EMAIL PROTECTED]] > Sent: 19 July 2001 23:02 > To: Haroon Meer > Cc: [EMAIL PROTECTED] > Subject: Re: Firewall-1 Information leak > > On Wed, 18 Jul 2001, Haroon Meer wrote: [David Sexton] > This is a well-known, and generally accepted, risk associated with running > FWZ SecuRemote VPN's to FireWall-1. As others have already commented, it > is possible to turn off unauthenticated topology downloads through the > policy properties. If you do this, you will need to manually distribute a > userc.C file (containing the topology information) to all of your > secuRemote users. This file should be loaded into the > c:\winnt\fw\database directory on the client. [David Sexton] --- Any opinions expressed in this message are those of the individual and not necessarily the company. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Sapphire Technologies Ltd http://www.sapphire.net
Re: Full analysis of the .ida "Code Red" worm.
> This DOES raise some pretty fundamental questions about the security of > all the infrastructure, because, in theory the compromised servers > _could_ have been exploited more extensively and _could_ be delivering > nastily compromised stuff around. I have no reason to believe it has > happened, but still... I have to disagree. Microsoft released a patch for this issue on 6/18/2001. Here we are, a tad over a month later, and the issue is being exploited en masse. This calls to question the attention of systems administrators to their networks. The days of selective application of security patches are long since over. IMHO, systems affected by this recent outbreak are being administered by techs that need to pay closer attention to their installations and keeping them up to date. As the world reliance on computer systems continues to increase, it become more and more imperative that people learn these are not simply toasters that sit on the kitchen counter. Regular maintenance and attention is required and an irresponsible or ignorant attitude towards these things is the true threat to the infrastructure. The only security issue here is the human element as always. Microsoft has already come up with a tool that automagically notifies users/admins of the need to update their system within moments of a patch being released. What should they do next -- auto-patch the systems for the user/admin to ensure the security of the infrastructure? Maybe the user/admin needs to learn about that toaster on the countertop. James
Re: Re(2): 'Code Red' does not seem to be scanning for IIS
Looking at the infected population chart as published on C|Net, I have to say that the dramatic increase looks exactly like the classical "knee" in a exponential growth curve. In fact, the entire curve looks like a standard infection "population vs. time" graph, with the upper end fall-off due to the saturation of the available uninfected population. No nefarious modifications are needed here to explain the sudden surge. For entertainment value, try creating a chart (I used Excel), plotting y=x^9. Then look at the curve. The knee starts around x=20 or 21, and the value takes off from there. No modifications needed. >I can correlate what Kelly reports -- *something* happened between 14-1500 GMT >today to drastically increase the number of 'code red' scans/infections. I've >been tracking them since Saturday on my IDS. Our class-b address space appears >to be high up on the worms scanning pattern. For all of 7/18 I recorded probes >from 8247 unique host IP addresses, presumably compromised with 'code red'. >Just during the 1900GMT hour today - one hour of logs - I recorded 'code red' >hits from 115124 different IP addresses. All of these probes are bouncing off >our firewall. The drastic increase in infections/probes began between 1300- >1400 GMT today and *seemed* to start leveling off around 1600-1700 GMT. -- Phillip C. Reed Network Administration - Cincinnati Eviciti 1148 Main St., 4th floor Cincinnati, OH 45210 (513) 929-0785 x218 http://www.eviciti.com mailto:[EMAIL PROTECTED]
Cisco Security Advisory: "Code Red" Worm Customer Impact
-BEGIN PGP SIGNED MESSAGE- Cisco Security Advisory: "Code Red" Worm Customer Impact Revision 1.0 For public release 2001 July 20 12:00 UTC _ Summary A malicious self replicating program known as the "Code Red" worm is targeted at systems running the Microsoft Internet Information Server (IIS). Several Cisco products are installed or provided on targeted systems. Additionally, the behavior of the worm can cause problems for other network devices. The following Cisco products are vulnerable because they run affected versions of Microsoft IIS: * Cisco CallManager * Cisco Unity Server * Cisco uOne * Cisco ICS7750 Other Cisco products may also be adversely affected by the "Code Red" worm. Please see the Affected Products section for further details. The worm and its effects may be remedied by applying the Microsoft patch to affected servers, http://www.microsoft.com/technet/treeview/default.asp?url=/technet/ security/bulletin/MS01-033.asp. This advisory is available at http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml . Affected Products The following Cisco products are directly vulnerable because they run affected versions of Microsoft IIS: * Cisco CallManager * Cisco Unity Server * Cisco uOne * Cisco ICS7750 * Cisco Building Broadband Service Manager Other Cisco products may be indirectly affected by the IIS vulnerability (this is not an exhaustive list): * Cisco 600 series of DSL routers that have not been patched per the Cisco Security Advisory, http://www.cisco.com/warp/public/707/CBOS-multiple.shtml , will stop forwarding traffic when scanned by a system infected by the "Code Red" worm. The power must be cycled to restore normal service. * Cisco Network Management products are not directly affected but might be installed on a Microsoft platform running a vulnerable version of IIS. Details The "Code Red" worm exploits a known vulnerability in Microsoft IIS by passing a specially crafted URI to the default HTTP service, port 80, on a susceptible system. The URI consists of binary instructions which cause the infected host to either begin scanning other random IP addresses and pass the infection on to any other vulnerable systems it finds, or launch a denial of service attack targeted at the IP address 198.137.240.91 which until very recently was assigned to www.whitehouse.gov. In both cases the worm replaces the web server's default web page with a defaced page at the time of initial infection. The worm does not check for pre-existing infection, so that any given system may be executing as many copies of the worm as have scanned it, with a compounding effect on system and network demand. As a side-effect, the URI used by the worm to infect other hosts causes Cisco 600 series DSL routers to stop forwarding traffic by triggering a previously-published vulnerability. Any 600 series routers scanned by the "Code Red" worm will not resume normal service until the power to the router has been cycled. The nature of the "Code Red" worm's scan of random IP addresses and the resulting sharp increase in network traffic can noticeably affect Cisco Content Service Switches and Cisco routers running IOS, depending on the device and its configuration. Unusually high CPU utilization and memory starvation may occur. Impact The "Code Red" worm is causing widespread denial of service on the Internet and is compromising large numbers of vulnerable systems. Once infected, the management of a Cisco CallManager product is disabled or severely limited until the defaced web page is removed and the original management web page is restored. Software Versions and Fixes Microsoft has made a patch available for affected systems at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/ security/bulletin/MS01-033.asp . Cisco is providing the same patch at http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=c isco/voice/callmgr/win-IIS-SecurityUpdate-2.exe&swtype=FCS&code=&size= 246296 with documentation at http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=c isco/voice/callmgr/win-IIS-SecurityUpdate-Readme-2.htm&swtype=FCS&code =&size=4541 Cisco Building Broadband Service Manager is documented separately at http://www.cisco.com/univercd/cc/td/doc/product/aggr/bbsm/bbsm50/ur gent.htm . Obtaining Fixed Software Cisco is making available software patches and upgrades to remedy this vulnerability for all affected Cisco customers. For most Cisco customers, upgrades are available through the Software Cen
Errata for CodeRedLogger.java
See what happens when I'm in a hurry. :( line 135, should have a line == null test. $ diff CodeRedLogger.java CodeRedLoggerOld.java 135,136d134 < if (line == null)
Re: Two birds with one worm
I can confirm that this worm is killing JetDirect cards. The HP JetDirect Card in our HP LaserJet 4000N has been steadily crashing as infection attempts hit it; the result is that, every ten to thirty minutes or so, the printer itself crashes, dumping a page of exception data from the card and freezing with an "EIO 2 ERROR" message. A hard reset of the printer is required to make it operational again. -- Patrick Chipman System Administrator University of Memphis Cognitive Science Lab - Original Message - From: "Brian.J.Mauter" <[EMAIL PROTECTED]> Date: Thursday, July 19, 2001 11:10 pm Subject: Re: Two birds with one worm. > Hi, > > Testing various other devices on my subnet, I found that my 3Com > WirelessLAN Access Point was not affected, but my HP 4500 was > because it has an HP > Jet Direct Card in it. I do not have conclusive evidence that it > was Code > Red, but the printer has never acted strangely before. When I > call the > printer's webserver, I get a "Device is not attached" error along > with "HP > JetDirect [Not available:SNMPException: no response]" at the top > of the > page. All of the admin functions fail and I cannot determine if the > printer is even functioning. (It's remote, or else I'd walk over > to it > and look.) > > I don't know, but this may get any HP device with JetDirect. Can > anyonequalify that?
Re: Mitigating some of the effects of the Code Red worm
On Thu, 19 Jul 2001, LARD BENJAMIN LEE wrote: > I'm not sure of the ethical or legal aspects of this, but I don't see why > we can't take advantage of three facts: > > 1) There is something of an ongoing log of affected machines that can be > obtained from boxes earlier in the IP list. The victim boxes won't tend to have a lot of logs lying around, but there are such lists. > 2) Machines which have been compromised can STILL be compromised. Yes. > 3) The worm has a "lysine deficiency" which can be remotely introduced. Yes... I can also change what it is with a hex editor in about 20 seconds... > > What I'm getting at, is for someone to create another exploit that creates > the C:\notworm file in infected machines Uh oh. > and does something to > notify whoever is in charge of a particular box (even something as simple > as placing you_are_hacked.txt and a link to the patch on the desktop could > be beneficial). If a "you've been hacked by the Chinese" page doesn't do it, why should a file on the desktop? > Even better, an exploit to patch a machine (through > removing the .ida and .idq extensions) would prevent the inevitable wave > of post-attacks (both from this worm and future attacks). You'd never get 100% success rate. > > Of course, I'm guessing this is illegal, although I highly doubt you'd be > prosecuted. You're kidding, right? We just threw a Russian citizen in jail for cracking ROT13. Anyone who tries such a stunt had better make sure they launch it anonymously. > If someone has the expertise to create a "white hack" such as > this, I'm sure there are daring admins out there who would happily attempt > to stem the flow. If we don't do something, you know it's just a (very > short) matter of time before script kiddies, armed with a modified worm > and a log of infected machines, do something more sinister. Let's be very specific: They only people who would thank anyone for such a stunt would be the clueless admin who can't install the patch on their own. Now, obviously, there are lots of those. OK, cut to the chase, here's my list of reasons hy this is bad, to be trotted out whenever someone suggests a "nice" worm: -What about the traffic it takes up? -What about the boxes that don't patch properly, don't make it back after reboot, or took down etrade in the middle of a trading day? -How does your worm know when it's done? -Maybe I don't want my box patched, the patch broke my app -How do I tell your good worm apart from the original bad worm, or the other worm which looks like the good worm, but is really a bad worm? -How about people like us who track attack data, and you just skewed the heck out of it? When does www1.whitehouse.gov get to come back? If there's still *A* worm around on the 1st, which one is it? -Do we really want an Internet-sized game of corewars? -Why stop at patching? Don't clueless NT admins deserve to have the hard drives reformatted until they learn how to apply patches? (and if you're no good at spotting sarcasm, please be sure to send me flames.) Having done my usual lecturing, I will say that this is the first time I've even been willing to entertain the idea of a good worm... I just don't know what else can fix a problem of this scale. You will never, ever come to agreement on how it should be done. Either some government will decide for you, or some hacker who is willing to take one for the team. I'm not real comfortable with either of those two setting policy for the Internet. Ryan
RE: Safe(?) testing for idq.dll vulnerability
You can get the IIS5 Hotfix Checking Tool from Microsoft Technet at http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24168 >From above listed source page: The HFCheck tool allows IIS5.0 administrators to ensure that their servers are up to date on all security patches. The tool can be run continuously or periodically, against the local machine or a remote one, using either a database on the Microsoft web site or a locally-hosted copy. When the tool finds a patch that hasn't been installed, it can display or dialogue or write a warning to the event log. -- Andrew Hatfield Head of Inter-Network Security Division RedHat Certified Engineer Hatfield & Associates Pty. Ltd. Phone : +61 7 3849 7155 Fax : +61 7 3849 6277 WWW : http://www.hatfields.com.au/ Email : [EMAIL PROTECTED]
Safe(?) testing for idq.dll vulnerability
I had to come up with a way to test a server remotely for this
vulnerability without actually killing it and running the plerthora
of exploit code that is out. This is what I have, hopefully someone
can use it.
Known Vulnerable Testing Platform
The first round of tests was run on a Windows 2000 Server running
IIS 5.0 (if anyone has similar analysis for IIS 4.0 I'd love to
see it) with AND without SP1 (no difference) not patched for MS01-033.
Results
Sending 1-219 bytes yields the error:
The IDQ file NULL.ida could not be found.
Nothing written to the event log.
Sending 220-231 bytes we get:
File .
Error 0xc005 caught while processing query
Nothing written to the event log.
Sending 232-??? bytes we get:
No response from web server.
System event log event ID 7031 from Service Control Manager.
IIS services are then stopped and restarted.
Known Invulnerable Testing Platform
Another system running Windows 2000 Server, IIS 5.0 with SP1 and
the patch for MS01-033.
Results
Sending 1-199 bytes yields the error:
The IDQ file NULL.ida could not be found.
Nothing written to the event log.
Sending 200-??? bytes we get:
File .
Error 0x80040e14 caught while processing query
Nothing written to the event log.
So, in summary, to test do the following:
send 200 bytes
if response = "Error 0x80040e14 caught while processing query" the
sytem is patched.
if response = "The IDQ file NULL.ida could not be found." the system
is not patched.
I can't take all the credit for figuring this out. Like most people,
I owe it all to the following bit of code:
#!/bin/sh
SIZE=1
export SIZE
while [ $SIZE -lt 201 ]; do
BUFF="`perl -e 'print \"x\" x $ENV{SIZE}'`"
echo -e "GET /NULL.ida?$BUFF=X HTTP/1.1\nHost: iluvpaul\n\n" | \
nc host port
SIZE=`expr $SIZE + 1`
done
-chris
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
