New Worm targets BlackICE vulnerability

[Gabriele Neukam]

On that special day, Zvxr Bkovt, ([email protected]) said...

http://www.eeye.com/html/Research/Upcoming/index.html
on or about April 8, IIRC.

APRIL? You must be traveling in a time machine.


Gabriele Neukam

(e-mail address removed)

 

[Gabriele Neukam]

On that special day, Robert Green, ([email protected]) said...

Well, we have gone from an inaccessible partition to
probably just a corrupt file or two. So we are making
progress ;-).

How fast can 20,000 different IP addresses be scanned and infected? It
won't take long, I am afraid. which means, the worm will overwrite hard
disk sections every other minute or so. An unwary user might think it is
the Office Indexer running, while ihis data is slowly but terminally
trashed...

This one is only slightly better than Opasoft.K, but definitely worse
than Klez.H


Gabriele Neukam

(e-mail address removed)

 

[Robert Green]

On that special day, Robert Green, ([email protected]) said...

How fast can 20,000 different IP addresses be scanned and infected? It
won't take long, I am afraid. which means, the worm will overwrite hard
disk sections every other minute or so. An unwary user might think it is
the Office Indexer running, while ihis data is slowly but terminally
trashed...

Yep, I didn't catch the loop. Maybe I should just shut up
.

Bob

 

[Axel Pettinger]

On that special day, Robert Green, ([email protected]) said...


How fast can 20,000 different IP addresses be scanned and infected?

I don't know how many IP addresses "Witty" is able to scan per second,
but as some av vendors compare the worm with "Slammer" ...:

"In practice, due to bandwidth limitations and the per-packet overhead,
the largest probe rate we directly observed was 26,000 scans/second,
with an Internet-wide average of approximately 4,000 scans/second per
worm during the early phase of growth."
[From "The Spread of the Sapphire/Slammer Worm"

It won't take long, I am afraid. which means, the worm will overwrite
hard disk sections every other minute or so. An unwary user might
think it is the Office Indexer running, while ihis data is slowly but
terminally trashed...

This one is only slightly better than Opasoft.K,

Hmm, "Opasoft.K" ..., you mean the one which can "which can overwrite
the boot sector, delete the CMOS, and delete the contents of the hard
disk" [1] ? Not really very nice either ...

but definitely worse than Klez.H

Certainly, as Klez.h isn't destructive at all.

Regards,
Axel Pettinger

[1] http://vil.nai.com/vil/content/v_99930.htm

 

[Gabriele Neukam]

On that special day, Axel Pettinger, ([email protected]) said...

Certainly, as Klez.h isn't destructive at all.

So, which version was it that perforated Office documents (beyond
repair, as it wrote to disk right into the files, instead of saving them
anew), and wiped the C:\$system$ directory on the 6th of January or
June? One did that.


Gabriele Neukam

(e-mail address removed)

 

[Axel Pettinger]

On that special day, Axel Pettinger, ([email protected]) said...


So, which version was it that perforated Office documents (beyond
repair, as it wrote to disk right into the files, instead of saving
them anew), and wiped the C:\$system$ directory on the 6th of January
or June? One did that.

I'm not so sure whether this kind of damage isn't as effective as the
one of the "Witty" worm. Depends probably on the point of view of its
victim ...

Anyway, you probably mean the "E" variant of Klez although I don't
remember exactly the details of its payload routine. Both, the "E" and
the "H" variant, are still quite wide spread I'd say.

Regards,
Axel Pettinger

 

[Snowsquall]

I'm not so sure whether this kind of damage isn't as effective as the
one of the "Witty" worm. Depends probably on the point of view of its
victim ...

Anyway, you probably mean the "E" variant of Klez although I don't
remember exactly the details of its payload routine. Both, the "E" and
the "H" variant, are still quite wide spread I'd say.

The E version destroys *all* the files on Jan 6 and June 6 and when viewed
in dos with the "type" command they all start with "run in DOS mode but they
all have gooblely doo.
Klez H does not have that payload.

 

[Gabriele Neukam]

On that special day, Snowsquall, ([email protected]) said...

The E version destroys *all* the files on Jan 6 and June 6 and when viewed
in dos with the "type" command they all start with "run in DOS mode but they
all have gooblely doo.
Klez H does not have that payload.

Ok. I had thought it was the other way round re versions and payload,
but I guess you're right. I can only tell that several of them came into
my mailbox, but of course none of them was applied; I didn't want to try
it out :-/


Gabriele Neukam

(e-mail address removed)

 

[cquirke (MVP Win9x)]

But the MBR & PBR are lost (overwritten) in this scenario,

Hence the "or..."

so it can only be done in the way I have indicated.

If using the BIOS equipment list, you still have to "guess the weight
of this cake", i.e. figure ir it's one full-size partition, one
slightly-under-full-size partition (geometry issues, partition
reserved for Compaq or suspecnd-to-disk etc. - tho those could be at
the front of the disk). Or an arbitrary-sized partition on a hard
disk that has multiple volumes on it.

I'd see the equipment list as the starting point. To figure the
volumes that were on this now-physically-limited hard disk, I'd search
for subdiirs and test potential volume geometries to fulfil the
prophecy of the . pointer. This is covered in some detail in my
pages, but generally, expect to see these sort of patterns:

1) One sequence of clusters with constant offset
- get your pre-cluster structures sized right, then OK

2) Two+ sequences of clusters, intertwined
- historical and present partitionings, overlaid

3) The sequence diverges in offset
- wrong cluster size; fix that, then as per (1)

4) The sequence starts again from low values
- you have crossed a boundry between volumes

End of volume, or physical HD?

I always have a tuff time building boot sectors - I suspect there are
relevant data fields that DiskEdit doesn't show, or something. Or
it's just the difficulties I have with basic arithmetic :-(

"RECYCLED" is probably the best search term (what if it is a
non-system partition?), but you should use the others as well.

Yes; "RECYCLED " is a particularly good one
Also "_RESTORE " on a known-to-be-WinME.

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

I would *not* trust Scandisk with this, except maybe for laffs (having
first backed-up the FATs, or perhaps imaged the whole raw disk).

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 dipped, but not enough to know how a BMD report is derived or how
well it assures write-sanity. The golden rule with data recovery is
"don't write through the file system until you know it's sane", and
knowing the file system is sane (or safe) for writes isn't easy.

It's sometimes possible to make a file system safe for writes, even if
it's not sane yet. When I first learned data recovery (on a
proprietary diskette file system for a ZX Spectrum interface), the
file system treated the free space as just another cluster (or in this
case, 1024-byte sector) chain.

Step one in protecting an at-risk diskette was to set the free space
to zero and point the start of the free space chain off the end of the
disk. Safe for writes, in that you can't write to it

Would be glad to. I enjoy our infrequrnt converstaions .

I'll email you RSN (in "software time", i.e. when time permits!)

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

Error Messages Are Your Friends

 

[Axel Pettinger]

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.

It seems Symantec's first description wasn't that wrong and under
certain circumstances the worm writes the DLL indeed to the first 128
sectors of a hard disk. From F-Secure's description:

"Witty sends the UDP packets to 20000 random IP addresses. After
completing the loop it opens one of the eight first physical drives and
writes 64KiB of the vulnerable DLL to the disk. The intention of the
author seems to be to write the data to a random place on the disk. Due
to the DLL version dependency in some cases one of the API calls goes to
an incorrect address and the worm overwrites the first 64KiB instead."

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.

Regards,
Axel Pettinger

 

[cquirke (MVP Win9x)]

Who said that? Did I say that? I guess it's true, I'm just surprised
if I would have said it tho.

I used to, but as I don't anymore

I still do, but only on FATxx. I don't have tools for NTFS and
tackling that via DiskEdit's raw hex view... eh, I'll pass!

Oh, *that* guy said etc. OK...

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.

The worm's functionality is as follows:

4) Opens a random PHYSICALDRIVE from 0-7, which
allows raw hard disk access

Is it just me, or does (4) look like something that even Win95 is
supposed to render impossible, i.e. direct disk access? So where's NT
and NTFS's much vaunted "more secure" protection here?

5) Seeks to a random point on the disk
6) Writes 65K of data from the beginning of the vulnerable
DLL to the disk

Some clarity on (6) would be good. From what I've read, is it:
- 65k (128 sectors) of arbitrary memory contents
- as above, but specifically from the malware's .DLL
- as above may suggest, over a .DLL it looked up in the file system
?

AFAIK, the malware exists as an in-memory image, or possibly within
the memory image of a .DLL that's part of Black Ice Offender. If it
throws random memory content to random disk, chances are the memory
content it will throw will be itself (the easiest memory to get).

7) Closes the disk
8) Starts the process over from step 1

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

More like rainfall, or what I refer to as "freckles"-pattern
corruption. Pretty big freckles, if it's 128 sectors per throw.

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

1) Heads-up the client to expect < 1.0 confidence of recovered
material - you can spot damaged file systrem structure and
rebuild from redundent, deduced or guessed info, but you
cannot be sure that what's inside the data clusters is not junk.

2) Check MBR; if insane, look for backup copy, else deduce a new one

3) Check PBR; if insane, look for backup copy, else deduce a new one

4) Compare FATs; if insane, cross-paste from other FAT's same-offset
- if both insane, guess flat-FAT, consider HD insane for writes

5) Check root; if insane, harvest subdirs, make a new root; see (7)

6) Check subdirs, DO NOT LET SCANDISK FIX, slide up good
subdir sectors back over garbage (Scandisk will truncate)

7) For a freckled subdir (or root), search for other subdirs that
have .. pointing to the afflicted (sub)dir. If no entries in
the afflicted dir point to these subdirs, craft a new entry.

8) Copy off what you now have access to

Unless, I completely misunderstood something here?
Gadi Evron.


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

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[cquirke (MVP Win9x)]

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.

No, I think you're missing my point there. I expect Fix-CIH will look
at the HD, say "this is NOT an unfettered CIH payload case" and leave.
IOW, Fix-CIH is very specifically written to undo a specific known
pattern of damage; it's not a general "recover from splatted front of
physical disk" utility. I remember when I first got it and tried it
on CIH strikes where I'd started manual recover (e.g. got as far as
MBR, or MBR + PBR) and it backed out without writing a byte.

I admired that, from the "first, do no harm" perspective.

Well it *is* More Secure ;-).

I read about a dog trainer who supplied explosive-sniffing dogs to US
airports etc. who was busted when it was discovered that his dogs
wouldn't point to test samples at all. They were just dogs, that's
all; they hadn't been trained squat.

The fact that Witty can write to raw disk, from the midst of NT
running on NTFS, indicates that whatever NT on NTFS is supposed to do
has FAILED. That makes it overtly relevant to ask; what's the
fallback plan, given this is clear evidence that s:-(t DOES happen?

But unlike FAT not very amenable to being recovered in place.

In other words, less survivable. So where Witty is concerned, you
have a file system that is exactly as vulnerable, but is less
survivable. That's negative value, by my reckoning.

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

If you're happy and you know it, clunk your chains.

 

[Robert Green]

"cquirke (MVP Win9x)" <[email protected]> wrote

in

[snip]

Would be glad to. I enjoy our infrequrnt converstaions

.

I'll email you RSN (in "software time", i.e. when time

permits!)

OK. I'll wait for that instead of replying here, as we are
getting a bit off topic.

Bob

 

[Duane Arnold]

The fact that Witty can write to raw disk, from the midst of NT
running on NTFS, indicates that whatever NT on NTFS is supposed to do
has FAILED. That makes it overtly relevant to ask; what's the
fallback plan, given this is clear evidence that s:-(t DOES happen?

What are you talking about here? Sure, any program can write to an NTFS
protected system based on the security context of the account being used at
the time of the compromise. If the security context of the account being
used at the time by the compromising program has write permissions why
should it not be able to write?

For all anyone knows, the SYSTEM, SERVICE or a User Account with Admin
privileges could have been in play at the time and they usually have full
privileges. You're going to need to come-up with some proof here with some
*hard* evidence showing that something can be written to a NTFS protected
system if the account being used at the time doesn't have write permission
to back up your statements.

Duane

 

[FromTheRafters]

Is it just me, or does (4) look like something that even Win95 is
supposed to render impossible, i.e. direct disk access? So where's NT
and NTFS's much vaunted "more secure" protection here?

Perhaps the software flaw is in a real mode granted process? It's
a bad place to have a flaw, but then an ICE program is a bad place
to have a flaw anyway.

Some clarity on (6) would be good. From what I've read, is it:
- 65k (128 sectors) of arbitrary memory contents
- as above, but specifically from the malware's .DLL
- as above may suggest, over a .DLL it looked up in the file system
?

AFAIK, the malware exists as an in-memory image, or possibly within
the memory image of a .DLL that's part of Black Ice Offender. If it
throws random memory content to random disk, chances are the memory
content it will throw will be itself (the easiest memory to get).

That is what I assumed, and from RAM not from any "virtual memory"
image that may require any additional paging or swapping. It probably
just grabs what's closest and easiest. I haven't seen any really technical
write-ups yet.

 

[cquirke (MVP Win9x)]

On that special day, Axel Pettinger, ([email protected]) said...

So, which version was it that perforated Office documents (beyond
repair, as it wrote to disk right into the files, instead of saving them
anew), and wiped the C:\$system$ directory on the 6th of January or
June? One did that.

Klez.E, if memory serves. Klez.H posed as a cure for it.

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

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[FromTheRafters]

What are you talking about here? Sure, any program can write to an NTFS
protected system based on the security context of the account being used at
the time of the compromise.

Most "security contexts" will write (if allowed) by using the filesystem. The
thing here is that it apparently circumvents the filesystem and writes directly
to disk without using the protection afforded by the OS. It is analogous to
a protected memory scheme failing due to real mode manipulations of real
memory.

If the security context of the account being
used at the time by the compromising program has write permissions why
should it not be able to write?

It should, but only with the assistance of the filesystem, I think.

For all anyone knows, the SYSTEM, SERVICE or a User Account with Admin
privileges could have been in play at the time and they usually have full
privileges.

I was thinking that it might have been beneath the whole "protected"
memory and filesystem scheme.

You're going to need to come-up with some proof here with some
*hard* evidence showing that something can be written to a NTFS protected
system if the account being used at the time doesn't have write permission
to back up your statements.

Irrespective of account permissions, code running at ring 0 has the
whole ball of wax. If the faulty DLL has this, then there isn't much
the malware can't do is there?

 

[Duane Arnold]

Most "security contexts" will write (if allowed) by using the
filesystem. The thing here is that it apparently circumvents the
filesystem and writes directly to disk without using the protection
afforded by the OS. It is analogous to a protected memory scheme
failing due to real mode manipulations of real memory.


It should, but only with the assistance of the filesystem, I think.


I was thinking that it might have been beneath the whole "protected"
memory and filesystem scheme.


Irrespective of account permissions, code running at ring 0 has the
whole ball of wax. If the faulty DLL has this, then there isn't much
the malware can't do is there?

As we discussed before, on a Win 9'x or ME O/S it is certainly possible
to do anything one wants ring 0 or no ring 0. They are not protected O/S
(s) in any way.

Someone is going to have to show some documentation some hard *proof*
that this can happen on a NT based O/S. Otherwise, as far as I am
concerned, it's a moot point. If this was an issue on the NT based O/S, I
think this would have been exposed a long long time ago.

http://www.comptechdoc.org/os/windows/ntwsguide/ntwsstructure.html

Duane

 

[Gabriele Neukam]

On that special day, Axel Pettinger, ([email protected]) said...

Due
to the DLL version dependency in some cases one of the API calls goes to
an incorrect address and the worm overwrites the first 64KiB instead."

Overwrites the first 64k of the defective dll, or of the hard disk?


Gabriele Neukam

(e-mail address removed)

 

[Frank Reid]

Overwrites the first 64k of the defective dll, or of the hard disk?

The hard disk. Got mine. I figured it was running for about 10 minutes
on mine. You know its gonna be a long day when you boot from a floppy
and try to switch to the c: drive and it tells you it doesn't exist.