I am currently in a 30day evaluation of CSA.
I have the POC code for ms04-007 (from k-otik and elsewhere), 2 variations in fact, and they both reboot my target box.
In both cases, with CSA in IDS-Test mode and Normal mode, nothing is registered in csalog.txt, nor does anything get reported back to the CSA central server.
I imagine that if/when this code is wrapped by some worm propagation mechanism, CSA may detect that, but until then, the raw exploit code does not get prevented by CSA in any way.
Has anyone else dont any testing?
No testing here and I must admit that I am just getting my hands around CSA myself but a question I have is how are you injecting the code onto the box? Do you have it locally and launch it or do you inject it over the network? If you are doing it locally I would imagine that CSA considers this a script and since it is doing nothing more than rebooting the server it is allowed just as a script might be. Can you let the experts here (not me!) know what the results are if you try to do this over the network? If you are indeed injecting this over the network and getting these results then the experts here will be chiming in soon I am sure.
Yes I'm sending the exploit over the network.
ASN affects many aspects of windows, but this exploit at http://www.k-otik.com/exploits/02.14.MS04-007-dos.c.php takes advantage of file/print sharing being enabled on the target.
The two variations I have work on ports 139 and 445
I tried to attack our evaluation VMS-Server itself (Win2000SP4) with the exploit from 'k-otik'. The VMS-server is protected by a CSA-Agent with default settings.
When I start the exploit locally and attack 127.0.0.1 then the maschine hangs or sometimes reboots.
This works even when I start the exploit from a guest account with no administrative rights.
From the network the attack is blocked by the CSA with rule 20:
"The process 'System' (as user NT AUTHORITY\SYSTEM) tried to accept a TCP connection from 184.108.40.206 on port 445 and this was prevented."
This is a general network-rule which denies connections to server-processes at the machine like a personal firewall does it.
When I disable this rule I can crash the server also from the network.
CSA seems not to protect the process lsass.exe which is attacked by the exploit. In this case CSA acts only like a personal firewall which protects against network connections from outside.
There is some tweaking that needs to de done but I am sure that CSA can protect lsass.exe. Maybe not out of the box with default settings but I am sure it can. I am researching this issue and will report back if I find anything.
I would not be that worried about the exploit since CSA catches it if it comes in over the network which is exactly where it would be coming from. If you have someone that can physically run this logged onto the console then you gots bigger problems than this exploit.
Any CSA experts out there want to chime in? I am in no way claining to be anywhere near an expert on it. Just trying to share my 2 cents.
I tested this against the 'out of the box' Desktop policy.
I'm sure the VMS specific policy is locked down tighter since it is configured specifically for VMS installations.
The desktop policy however does not block on connections to 445.
In order for this exploit to work you must turn on file/print sharing on the target box. The two variations of the exploit target ports 139 and 445. Both of which are allowed by the Desktop policy.
Thank you for posting your message. It is true that the proof of concept code that you are referring to does crash the lsass.exe process. At this time, however, we have not seen this vulnerability used to take over a system by someone with malicious intent. We have been consistent in the message of how we stop attacks - "Defense in Depth." An attack that might utilize the ASN.1 vulnerability would have to get past our layered protections in order to take over systems protected by the Cisco Security Agent.
An attack utilizing this vulnerability to take over a system would have to do most of the following:
- Buffer overflow (penetrate stage)
- Downloaded content starting to execute (penetrate stage)
- System bootup configuration changed (persist)
- Modify OS/install new binaries (persist)
- Connect out to find/infect new systems (propagate)
- Wipe the disk, etc (paralyze)
We feel confident our defense in layer approach would give you the protection from this kind of attack.
>Buffer overflow (penetrate stage)
It appears though that the exploit does that?
From what I saw, it affects the HEAP and the exploit finished by doing a DESTROY rather than an EXIT (out of my league here).
If it isn't doing a stack/heap overflow, how does this POC code remotely crash the box?