New Worm targets BlackICE vulnerability

[Axel Pettinger]

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 ...

Regards,
Axel Pettinger

 

[Gabriele Neukam]

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.

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 ...

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)

 

[Clay]

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 ...

It's been kissing my router here too.

 

[David H. Lipman]

I guess Real Secure -- is NOT real secure !

Dave



| 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 ...
|
| Regards,
| Axel Pettinger

 

[Jari Lehtonen]

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 ...

Regards,
Axel Pettinger

Yes, they seems to call it "Witty"

http://www.f-secure.com/v-descs/witty.shtml

Jari

 

[Axel Pettinger]

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

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 ...

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

 

[Axel Pettinger]

| 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

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

 

[Robert Green]

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

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

Bob

 

[Gadi Evron]

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.

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

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

Gadi Evron.

 

[Robert Green]

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

Okay .

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

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.

Bob

 

[Zvxr Bkovt]

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?

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?

A kit, perhaps not. Safe to say "some assembly required" though.

 

[Axel Pettinger]

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.

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

Regards,
Axel Pettinger

 

[cquirke (MVP Win9x)]

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?

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

Who is General Failure and
why is he reading my disk?

 

[cquirke (MVP Win9x)]

"Gadi Evron" <[email protected]> wrote in message

For FAT there are 5 steps to recover this kind of thing,

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

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.

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.

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

5. Repair the FAT

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

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

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.

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.

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

Trsut me, I won't make a mistake!

 

[Gadi Evron]

Comments below...

Okay .





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

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

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

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.

 

[Robert Green]

FAT.

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

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"

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

"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?

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

app design.

Would be glad to. I enjoy our infrequrnt converstaions .

Bob

 

[Nick FitzGerald]

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

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?

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.

 

[Robert Green]

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

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...

right?

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

Bob

 

[Robert Green]

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."

Very different story then.

Now it's probably more difficult to restore

damaged/deleted files ...

Yep. You'd have just a mess.

Bob

 

[Robert Green]

Comments below...


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

[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

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

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

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?

At this point I think we are all on the same page.

Gadi Evron.

Bob