Sig 3338 for LSASS not detecting SASSER

[admin_2]

I am wondering if sig 3338 is completely useless for the SASSER virus and if anyone has come up with a good Cisco custom signature for detection of the buffer overflow after the Syn-Ack.

TIA, Peter

[yusuff]

IDS should trigger on:

3338.0 Windows LSASS RPC Overflow

3002.0 TCP SYN Port Sweep

There are two tcp ports used for this worm's propagation AFTER the two signatures above have fired. Neither of these exploits a vulnerability in

and of itself. These are ports set up for distribution of the worm after the Windows LSASS RPC Overflow is successful.

5554 FTP server for code download residing on the infecting (attacker) host.

9996 shell used (on the victim) to connect back to the FTP service just mentioned.

The worm is non-destructive, spawns 128 threads to scan, and 50% of the time it will attempt to exploit a completely random IP address 25% of the time it will attempt to exploit a random address within the same first octet of the local subnet 25% of the time it will attempt to exploit a random address within the same first and second octets of the local subnet

IDS dev team at Cisco will be addressing the back door ports in release S91 sig-update. Any sig release of S85 or greater should be able to track the transmission of this worm in the wild with signatures 3338 and 3002.

[derwalke]

There was a false negative situation, based upon our previous information about the LSASS overflow. Sasser did in fact have a false negative condition with the pre-S91 version of signature 3338. As of S91 this has been fixed and tested specifically against Sasser and works definitively.

Also included in S91 are signatures 3142.0 and 3142.1 which detect Sasser activity *specifically* as opposed to the more generic buffer overflow in 3338.

[mjuckett]

Do we have an ETA on when the S91 update will be available? I am not seeing it yet on the downloads page.

Thanks so much.

[derwalke]

It is to be posted today by 2pm CST.

[mjuckett]

Thanks very much for the update. I can see the files out there now for download and will download them as soon as synching allows.

[#7]

Hello,

What exactly is LSASS Overflow triggering on. Also are there any possible benign triggers for the Sasser actvity signature?

[pbobby]

If you look at the signature details, 3142 subsig 0 is

\x63\x6d\x64\x2e\x66\x74\x70\x26\x65\x63\x68\x6f\x20\x61\x6e\x6f\x6e\x79\x6d\x6f\x75\x73 on destination port 9996

and subsig 1 is

\x32\x32\x30\x20\x4f\x4b\x0a on port 5554

This signature only triggers after a machine has been compromised, and is now making the connection to the infecting hosts' ftp server so it can download the sasser worm.

This signature does not trigger during the scanning portion, nor the actual LSASS infection vector, only when a machine has been compromised.

In other words, you may have a handful of machines infected, but you wont know they are until they successfully infect another machine _and_ propagate the worm to that new machine.

I'm hoping the original signature, 3338 Windows LSASS Overflow, will catch the infection vector. But as the poster above already stated, it doesn't.

[derwalke]

The signature 3338 will catch the LSASS propogation as of version S91, which was available yesterday (Monday).

[darin.marais]

In some organisations, NIDS designers place a sensor on the internal LAN just in front of the Internet Firewall. This sensor will watch lost traffic that tries to egresses the network towards the Internet.

Internal network-----FW-----Internet

|

Sensor(S91)

In this type of design, I personally have seen that the only way to detect internally infected Sasser machines is to watch the event TCP-SYN host scan. Internal devices that scan the port TCP_445 could be infected by Sasser. There is no way to definitely tell at this point if the machine that is scanning port 445 is in fact infected.

In this design I have enabled all of the Sasser signatures including the backdoor signature at the sensor and still have not been able to detect infected machines using these specific signatures.

Is this normal?

Besides the tcp_syn host scan events, what other events in the above design should be trigger when the internally infected Sasser hosts starts scanning for new hosts to infect?

[p.hachmeister]

How do you find these details? I don't see them via Cisco. Are you looking at snort.org?

Thanks,

Peter

[fields.james]

You can see the specific strings if you edit the signature directly on the sensor; if you're looking at it with VMS you can't access the actual string being matched.