New Worm targets BlackICE vulnerability

  • Thread starter Thread starter Axel Pettinger
  • Start date Start date
On that special day, Axel Pettinger, ([email protected]) said...
There seems to be a new worm which tries to exploit a vulnerability in
ICQ parsing in ISS products like BlackICE.
Click to expand...

That was *fast* (tm). The advisory about this specific ISS products flaw
came out only yesterday or the day before.

http://www.eeye.com/html/Research/Advisories/AD20040318.html
http://xforce.iss.net/xforce/alerts/id/166 (as mentioned by Axel)

Don't forget, there is an older vulnerability, too in

http://www.eeye.com/html/Research/Advisories/AD20040226.html
A patch for that
vulnerability is available ...

More info:
http://isc.sans.org/diary.html

That worm knocked on the door of my computer several times now ...
Click to expand...

Neat. Somehow I have a feeling, that someone knew about that
vulnerability even before the advisory came out; or how did the malware
come into existence that early? Was it made with a trojan construction
kit?


Gabriele Neukam

(e-mail address removed)
 
Axel said:
There seems to be a new worm which tries to exploit a vulnerability in
ICQ parsing in ISS products like BlackICE. A patch for that
vulnerability is available ...

More info:
http://isc.sans.org/diary.html
Click to expand...

The ISC page was updated ..., re-read ...
http://xforce.iss.net/xforce/alerts/id/166

That worm knocked on the door of my computer several times now ...
Click to expand...

According to Symantec "Witty" has a destructive payload:

"Attempts to overwrite the first 128 sectors of one random physical hard
drive with data from memory."

http://www.sarc.com/avcenter/venc/data/w32.witty.worm.html

Other descriptions of the Witty worm:
http://www.Europe.F-Secure.com/v-descs/witty.shtml
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_WITTY.A

One could get the impression that most anti virus companies are sleeping
- just because Witty is worm which can only be found in memory ... :/

This worm exists probably since almost 14 hours and its still hard to
find a good description about it on their sites ...

Regards,
Axel Pettinger
 
David H. Lipman said:
| There seems to be a new worm which tries to exploit a vulnerability
| in ICQ parsing in ISS products like BlackICE. A patch for that
| vulnerability is available ...
|
| More info:
| http://isc.sans.org/diary.html
| http://xforce.iss.net/xforce/alerts/id/166
|
| That worm knocked on the door of my computer several times now ...

I guess Real Secure -- is NOT real secure !

Dave :-)
Click to expand...

Maybe that should be the message of that worm - who knows? After all it
is obviously a destructive one. Without that payload I'd have said that
is a (more or less) harmless warning for users to patch their systems
before trojans (or hackers) compromise them using that vulnerability.
But now ... :/

ISS's own page about the Witty worm and the vulnerable product versions
(the site is different from the one mentioned above):

http://xforce.iss.net/xforce/alerts/id/167

McAfee just started their analysis of the worm:
http://vil.nai.com/vil/content/v_101118.htm

Regards,
Axel Pettinger
 
Axel Pettinger said:
The ISC page was updated ..., re-read ...
times now ...

According to Symantec "Witty" has a destructive payload:
"Attempts to overwrite the first 128 sectors of one random
Click to expand...
physical >drive with data from memory."

Note: if the target is a hard drive and the intital
partition is FAT32, then it will be 100% recoverable.
Gibson's FIXCIH ought to be enough.
If NTFS the damage will be worse. It will need restoring the
MBR and the partition boot sector, then a repair re-install.
Some NT4 and W2000 systems may need a fresh install and data
restored from backup. If no backup exists, then a file
recovery tool should be able to recover very nearly the
entire file system.
http://www.sarc.com/avcenter/venc/data/w32.witty.worm.html

Other descriptions of the Witty worm:
http://www.Europe.F-Secure.com/v-descs/witty.shtml
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_WITTY.A

One could get the impression that most anti virus companies are sleeping
- just because Witty is worm which can only be found in memory ... :/

This worm exists probably since almost 14 hours and its still hard to
find a good description about it on their sites ...

Regards,
Axel Pettinger
Click to expand...

Bob
 
Note: if the target is a hard drive and the intital
partition is FAT32, then it will be 100% recoverable.
Gibson's FIXCIH ought to be enough.
If NTFS the damage will be worse. It will need restoring the
MBR and the partition boot sector, then a repair re-install.
Some NT4 and W2000 systems may need a fresh install and data
restored from backup. If no backup exists, then a file
recovery tool should be able to recover very nearly the
entire file system.
Click to expand...

Okay, we can continue this on usenet like you said.. :o)

So, don't you think you are a tad optimistic?

Gadi Evron.
 
Gadi Evron said:
Okay, we can continue this on usenet like you said.. :o)
Click to expand...

Okay :-).
So, don't you think you are a tad optimistic?
Click to expand...

Not really. It is optimism based in experience. I do this
suff for a living these days ;-).

For FAT there are 5 steps to recover this kind of thing,
whether you use a tool like Gibson's or do it some other
way. (The CIH recovery tools, AFAIK, only work for FAT32,
but FAT16 can also be recovered in this case, though not in
the CIH case.)

1. Analyze the surviving part of the FAT to determine the
sectors per FAT and for FAT32 the start sector of the FAT.

2. Determine the size of the partition, ie, just locate the
end of it.

3. From the sectors per FAT and total sectors in partition
you can calculate the other BPB parameters and rebuild the
boot sector. You might also have to locate a FAT32 root
directory if it is not at cluster 2.

4. Rebuild the partition table

5. Repair the FAT

For NTFS

1. Locate the backup boot sector (in last sector of the
partition) and use it to restore the primary boot sector.

2. Rebuild the partition table.

3. Do a repair reinstall

Naturally the above is a very general outline, and there are
a number of possible complications, but they are all capable
of solution.

So, I think I have justified my optimism :-).

BTW, for people interested in this kind of stuff I have a
few case studies posted here:
http://bootmaster.filerecovery.biz/appnotes.html. Case Study
5, a case involving CIH, is derived from an a.c.v. thread
of a few years ago.
Gadi Evron.
Click to expand...

Bob
 
On Sat, 20 Mar 2004 17:02:38 +0100, Gabriele Neukam wrote
Neat. Somehow I have a feeling, that someone knew about that
vulnerability even before the advisory came out; or how did the malware
come into existence that early?
Click to expand...

Information on the vulnerability exploited by Witty Worm was posted here as an
"Upcoming Advisory"
http://www.eeye.com/html/Research/Upcoming/index.html
on or about April 8, IIRC.

So AFAIK, since the SMB parsing vulnerability was similarly easily exploited,
a VXer may have been eagerly waiting for eEye's typical prolific details.
Was it made with a trojan construction
kit?
Click to expand...

A kit, perhaps not. Safe to say "some assembly required" though.
 
They've changed that sentence. Like Lurhq and McAfee before, Symantec
says now:

"Attempts to overwrite 128 sectors in a random location of one of the
first eight physical hard drives with data from memory."
Note: if the target is a hard drive and the intital
partition is FAT32, then it will be 100% recoverable.
Gibson's FIXCIH ought to be enough.
If NTFS the damage will be worse. It will need restoring the
MBR and the partition boot sector, then a repair re-install.
Some NT4 and W2000 systems may need a fresh install and data
restored from backup. If no backup exists, then a file
recovery tool should be able to recover very nearly the
entire file system.
Click to expand...

Now it's probably more difficult to restore damaged/deleted files ...

Regards,
Axel Pettinger
 
You may find that Gibson's Fix-CIH is admirably strict about
identifying a pure CIH payload attack, and thus won't touch anything
else. I'd just compare and repair the two FAT copies in the usual way

Yep. But hey, that's OK because NTFS is More Secure. After all, NT
with NTFS is so secure that it's impossible for malware to gain access
and write garbage to arbitrary file system structures... right?


--------------- ----- ---- --- -- - - -
Click to expand...
Who is General Failure and
why is he reading my disk?
 
"Gadi Evron" <[email protected]> wrote in message
Click to expand...
For FAT there are 5 steps to recover this kind of thing,
Click to expand...
1. Analyze the surviving part of the FAT to determine the
sectors per FAT and for FAT32 the start sector of the FAT.
Click to expand...

You'd either find that in PBR (which you find via MBR) or you can
search for those structures.
2. Determine the size of the partition, ie, just locate the
end of it.
Click to expand...
3. From the sectors per FAT and total sectors in partition
you can calculate the other BPB parameters and rebuild the
boot sector. You might also have to locate a FAT32 root
directory if it is not at cluster 2.
Click to expand...

Note that the usual "find subdirectory" approach won't work because
root doesn't start with . and .. entries. I search for space-padded
"8 3" format names such as "NTLDR ", "IO SYS" etc.
4. Rebuild the partition table
Click to expand...
5. Repair the FAT
Click to expand...

Get a split view going with a copy of each FAT in each window, and
compare windows from the start. The one full of non-unique
non-special values with insane high-order bytes is the garbage.
Cross-paste accordingly - and if both nuked, use "flat-FAT" logic

See http://users.iafrica.com/c/cq/cquirke, data recovery section.
For NTFS
Click to expand...
1. Locate the backup boot sector (in last sector of the
partition) and use it to restore the primary boot sector.
Click to expand...
2. Rebuild the partition table.
Click to expand...
3. Do a repair reinstall
Click to expand...

Hm - dump several megs of code onto an insane and at-risk file system
to fix it. Am I missing something here?
BTW, for people interested in this kind of stuff I have a
few case studies posted here:
http://bootmaster.filerecovery.biz/appnotes.html. Case Study
5, a case involving CIH, is derived from an a.c.v. thread
of a few years ago.
Click to expand...

I am, so I'm OMW... hmm, looks like good stuff! We should talk, FWIW
I'm a non-coder (well, ex-coder) with ideas for recover app design.


-------------------- ----- ---- --- -- - - - -
Click to expand...
Trsut me, I won't make a mistake!
 
Comments below...
Okay :-).

:)



Not really. It is optimism based in experience. I do this
suff for a living these days ;-).
Click to expand...

I used to, but as I don't anymore, I'll bow before your experience
before we start.
:o)
For FAT there are 5 steps to recover this kind of thing,
whether you use a tool like Gibson's or do it some other
way. (The CIH recovery tools, AFAIK, only work for FAT32,
but FAT16 can also be recovered in this case, though not in
the CIH case.)

1. Analyze the surviving part of the FAT to determine the
sectors per FAT and for FAT32 the start sector of the FAT.

2. Determine the size of the partition, ie, just locate the
end of it.

3. From the sectors per FAT and total sectors in partition
you can calculate the other BPB parameters and rebuild the
boot sector. You might also have to locate a FAT32 root
directory if it is not at cluster 2.

4. Rebuild the partition table

5. Repair the FAT

For NTFS

1. Locate the backup boot sector (in last sector of the
partition) and use it to restore the primary boot sector.

2. Rebuild the partition table.

3. Do a repair reinstall

Naturally the above is a very general outline, and there are
a number of possible complications, but they are all capable
of solution.

So, I think I have justified my optimism :-)
Click to expand...

Okay, sorry for not replying inline, but as much as your steps make
sense.. they personally don't sound like they'd work with this worm.

According to our friend Joe, at http://www.lurhq.com/witty.html -

The worm's functionality is as follows:

1) Generates a random IP address
2) Sends the worm payload
3) Repeats steps 1-2 20,000 times
4) Opens a random PHYSICALDRIVE from 0-7, which allows raw hard
disk access
5) Seeks to a random point on the disk
6) Writes 65K of data from the beginning of the vulnerable DLL to
the disk
7) Closes the disk
8) Starts the process over from step 1
It writes 0x10K bytes from the offset of the vulnerable DLL to

So, watch steps 3 to 6...
It writes 0x10K bytes from the offset of the vulnerable DLL to the HDD,
over-writing rather than anything else, much like in wipe.

It is a scortched earth strategy..

How can you (without onvesting way too much) deal with that?

Unless, I completely misunderstood something here?

Gadi Evron.
 
cquirke (MVP Win9x) said:
FAT.

You'd either find that in PBR (which you find via MBR) or you can
search for those structures.
Click to expand...

But the MBR & PBR are lost (overwritten) in this scenario,
so it can only be done in the way I have indicated.
Note that the usual "find subdirectory" approach won't work because
root doesn't start with . and .. entries. I search for space-padded
"8 3" format names such as "NTLDR ", "IO SYS"
Click to expand...
etc.

"RECYCLED" is probably the best search term (what if it is a
non-system partition?), but you should use the others as
well.
Get a split view going with a copy of each FAT in each window, and
compare windows from the start. The one full of non-unique
non-special values with insane high-order bytes is the garbage.
Cross-paste accordingly - and if both nuked, use
Click to expand...
"flat-FAT" logic

Well, in this case you don't need to do it manually.
SCANDISK is fine. Caveat: there are possible cases of FAT
damage where SCANDISK is definitely *not* fine. F6 damage by
FDISK, for example.
See http://users.iafrica.com/c/cq/cquirke, data recovery section.




Hm - dump several megs of code onto an insane and at-risk file system
to fix it. Am I missing something here?
Click to expand...

Well, you look at details of specific cases. In my case I
can normally judge from the BMD reports (you've been to my
site, so maybe you know those are ;-) what is safe to do and
what needs more evaluation.
I am, so I'm OMW... hmm, looks like good stuff! We should talk, FWIW
I'm a non-coder (well, ex-coder) with ideas for recover
Click to expand...
app design.

Would be glad to. I enjoy our infrequrnt converstaions :-).

Bob
 
Gadi Evron said:
I used to, but as I don't anymore, I'll bow before your experience
before we start.
:o)

Okay, sorry for not replying inline, but as much as your steps make
sense.. they personally don't sound like they'd work with this worm.

According to our friend Joe, at http://www.lurhq.com/witty.html -

The worm's functionality is as follows:

1) Generates a random IP address
2) Sends the worm payload
3) Repeats steps 1-2 20,000 times
4) Opens a random PHYSICALDRIVE from 0-7, which allows raw hard
disk access
5) Seeks to a random point on the disk
6) Writes 65K of data from the beginning of the vulnerable DLL to
the disk
7) Closes the disk
8) Starts the process over from step 1
It writes 0x10K bytes from the offset of the vulnerable DLL to

So, watch steps 3 to 6...
It writes 0x10K bytes from the offset of the vulnerable DLL to the HDD,
over-writing rather than anything else, much like in wipe.

It is a scortched earth strategy..

How can you (without onvesting way too much) deal with that?

Unless, I completely misunderstood something here?
Click to expand...

What you "completely missed" is that Bob's initial assessment was correct
_given the information it was based on_:

According to Symantec "Witty" has a destructive payload:
"Attempts to overwrite the first 128 sectors of one random
physical >drive with data from memory."

Of course, we know that information is incorrect and Symantec altered the
page ages ago, but Bob's assessment was, as far as we can tell, based
solely on the (secondhand) report he had (from Axel) that the overwriting
was always _from_ the first sector of the drive.
 
cquirke (MVP Win9x) said:
You may find that Gibson's Fix-CIH is admirably strict about
identifying a pure CIH payload attack, and thus won't touch anything
else. I'd just compare and repair the two FAT copies in
Click to expand...
the usual way

I'm pretty sure Fix-CIH will work for this case, but of
course you can approach it another way. I just mentioned
Fix-CIH 'cause its free and easy.
Yep. But hey, that's OK because NTFS is More Secure. After all, NT
with NTFS is so secure that it's impossible for malware to gain access
and write garbage to arbitrary file system structures...
Click to expand...
right?

Well it *is* More Secure ;-). But unlike FAT not very
amenable to being recovered in place.

Bob
 
Axel Pettinger said:
They've changed that sentence. Like Lurhq and McAfee before, Symantec
says now:

"Attempts to overwrite 128 sectors in a random location of one of the
first eight physical hard drives with data from memory."
Click to expand...

Very different story then.
Now it's probably more difficult to restore
Click to expand...
damaged/deleted files ...

Yep. You'd have just a mess.

Bob
 
Gadi Evron said:
Comments below...


I used to, but as I don't anymore, I'll bow before your experience
before we start.
:o)
Click to expand...

[snip quote from my post]
Okay, sorry for not replying inline, but as much as your steps make
sense.. they personally don't sound like they'd work with this worm.

According to our friend Joe, at
Click to expand...
http://www.lurhq.com/witty.html -
The worm's functionality is as follows:

1) Generates a random IP address
2) Sends the worm payload
3) Repeats steps 1-2 20,000 times
4) Opens a random PHYSICALDRIVE from 0-7, which allows raw hard
disk access
5) Seeks to a random point on the disk
Click to expand...

Oh, OK. That's the detail I didn't know. I guess you didn't
know it either, since you didn't point out that the Symantec
desrption Axel quoted was wrong ;-). I have been going on
the assumption that the overwriting was from LBA 0 to 127.

The reason I reply on something like that is that many users
may see this knid of damage as intractable and give up on
it, when it is actually quite repairable. But that turns out
not to be the case...
6) Writes 65K of data from the beginning of the vulnerable DLL to
the disk
7) Closes the disk
8) Starts the process over from step 1
It writes 0x10K bytes from the offset of the vulnerable DLL to

So, watch steps 3 to 6...
It writes 0x10K bytes from the offset of the vulnerable DLL to the HDD,
over-writing rather than anything else, much like in wipe.

It is a scortched earth strategy..

How can you (without onvesting way too much) deal with
Click to expand...
that?

Well, we have gone from an inaccessible partition to
probably just a corrupt file or two. So we are making
progress ;-).
Unless, I completely misunderstood something here?
Click to expand...

At this point I think we are all on the same page.
Gadi Evron.
Click to expand...

Bob
 
Back
Top