As a result of some research into various trojans it was identified that majority of them rely on packers, crypters, and anti debugging tricks. Nothing new here. However, what was interesting is that some of them were completely missed by Snort. Rulebase included default signatures that come with base installation, community rules, and Emerging Threats (ET).
It turns out that analyzed trojans modified the executable's header which did not fall within signature's patterns. This can be partly fixed by creating a signature to detect the PE header's magic value within a certain distance from the start of the DOS header. However, the trick here is to pick a distance which will not produce false negatives. If it's too short then it's doomed to miss lots of stuff. Higher values may produce false positives, more research into this is needed.
It's best to detect executables by reading their structure. PE/COFF format states that the offset to start of PE header is found 0x3C bytes from start of DOS header. I was not able to achieve desired results using the regular Snort rule syntax but using the dynamic rules feature worked perfectly. It's written C and must be compiled. Download it here.
2008-10-26
Importance of verifying vendor's protection claims
One of my favorite fundamental security principles is perfectly summarized by this blog post: "Are you Secure? Prove it.
This is true for any situation more so for high severity issues like the MS08-067 vulnerability. So, one of the big names in enterprise security products came out with couple of signatures in their end user protection product. I won't name which one since it doesn't really matter in this context.
Taking into account that not all organizations can patch immediately, in large enterprises there are many factors which can contribute to the delay, the last resort to protect users is to rely on security software on their workstations. Antivirus can only go so far and it's largely useless these days. However, some HIPS signatures can limit the exposure.
So, this HIPS product rolled out signatures to supposedly detect and prevent the attack. After testing their claims it turned out that it only blocks exploit attempts from the workstation which has this HIPS installed. Any attacks against this workstation will be successful. It is beyond me why this decision was made. It'll stop the worm from spreding but it won't protect the client from being infected by the trojan which can easily be downloaded by the shellcode.
Interestingly, the response from the vendor was that they created detection for the most common exploit vector. I understand that it's not always possible to create signatures for the vulnerability, product has its limitations, thus only specific exploit vectors are detected.
But in this case it wasn't event the most common vector. My tests used the code which was published on milw0rm by stephenl and at that time had just over 10,000 views, currently at over 16,000. I would think that the vector used in that PoC would be the most common since it's quickly copied by many other hacking sites.
Thus, if organizations rely on their security vendor's claims and don't have in-house expertise to verify those claims then they're at a high risk of having a false sense of security. Considering that this product is from a rather large security vendor then the list of those organizations is rather large.
On the upside, vendor was notified and is currently working on updating their detection.
This is true for any situation more so for high severity issues like the MS08-067 vulnerability. So, one of the big names in enterprise security products came out with couple of signatures in their end user protection product. I won't name which one since it doesn't really matter in this context.
Taking into account that not all organizations can patch immediately, in large enterprises there are many factors which can contribute to the delay, the last resort to protect users is to rely on security software on their workstations. Antivirus can only go so far and it's largely useless these days. However, some HIPS signatures can limit the exposure.
So, this HIPS product rolled out signatures to supposedly detect and prevent the attack. After testing their claims it turned out that it only blocks exploit attempts from the workstation which has this HIPS installed. Any attacks against this workstation will be successful. It is beyond me why this decision was made. It'll stop the worm from spreding but it won't protect the client from being infected by the trojan which can easily be downloaded by the shellcode.
Interestingly, the response from the vendor was that they created detection for the most common exploit vector. I understand that it's not always possible to create signatures for the vulnerability, product has its limitations, thus only specific exploit vectors are detected.
But in this case it wasn't event the most common vector. My tests used the code which was published on milw0rm by stephenl and at that time had just over 10,000 views, currently at over 16,000. I would think that the vector used in that PoC would be the most common since it's quickly copied by many other hacking sites.
Thus, if organizations rely on their security vendor's claims and don't have in-house expertise to verify those claims then they're at a high risk of having a false sense of security. Considering that this product is from a rather large security vendor then the list of those organizations is rather large.
On the upside, vendor was notified and is currently working on updating their detection.
2008-08-27
Neosploit devel/updates retired! However...
It seems that development of this exploit pack has ended. The message basically states that efforts which are put into development are not returning enough income and supported is ending.
However, this does not mean that you will no longer see exploits delivered via this framework. There are many installations of it out there and it's still one of the best exploit packs, although it was expensive. Also, the Neo folks have released instructions/script on how to move the CGI program from one server to another. Previously, this had to be done with the help of Neosploit Support, as the binary was compiled for specific server. If source code is leaked out or released then it's highly likely that more malware will be delivered through it.
Now, that background info behind us, we have seen something interesting which leaves more questions then answers. We have identified a site which utilizes this pack to drop a binary which seems to be associated with the recent fake Antivirus malware.
What is of most interest is the fact that the obfuscated script, mainly the deobfuscation function has some modifications to its code. Several key statements were rearranged in such a way that logic isn't changed.
Why make such a change? Is it a change or some older build which had a short life span and wasn't updated since? We've been keeping an eye on Neosploit's progress for many months now and have never seen this code sequence. We have observed similar minor changes before, during active development, but now since it's supposedly retired the update does stand out. Is it possible that source code was leaked? or did someone just modify the binary in place, and for what purpose, evade detection?
More research is needed to confirm if this change occurs elsewhere, on other domains hosting Neosploit.
2008-08-23
le fiesta - another exploit pack
This is yet another web based exploit pack which utilizes PHP and SQL. Overall, it's similar to the other PHP based packs except here the file structure is much more compact, not that it really matters, and it's less smart about serving out exploits (not loaders) to already visited victims.
Uses two layers of encryption/obfuscation via Javascript with random function and variable names upon each visit. Here's a rough list of included exploits:
COM objects(see metasploit)
"?spl=com"EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F CreateControlRange
"?spl=vml2"DirectAnimation.PathControl
"?spl=wfi"WebViewFolderIcon.WebViewFolderIcon.1 setSlice()
"?spl=zango1"8C875948-9C60-4381-9248-0DF180542D53 DownloadAndExec()
"?spl=zango2"BFC08CFF-C737-4433-BD5A-0EE7EFCFEE54 DownloadAndExec()
"?spl=myspace"48DD0448-9209-4F81-9F6D-D83562940134
"?spl=ymj"5F810AFC-BB5F-4416-BE63-E01DD117BD6C AddImage()
"?spl=buddy"Sb.SuperBuddy.1 LinkSBIcons()
The ?spl= parameter will be passed to "load.php" which will update statistics of each exploit.
2008-08-22
"Army cyber ops"...
In a Government Computer News article there was an interesting fact mentioned which hints at Army's cyber command centers ability to handle contigency issues.
It was stated that many of their links utilize undersea cables but some also use land based fiber. One of such land links was severed by a garbage truck, disabling service to their northern and southern continental CC for several hours.
Now, I know how difficult it can be to design and run a full contigency operation but one would think that with the budget and resources of a government such a goal should not pose too much of a problem. Apparently, this is not so for Army's cyber ops.
To be honest, it's a big surprise to me. I've seen companies not lose a single tcp connection upon core router/switch failures, cable cuts in server racks, and power outages in data centers and they don't have the same resources as the government can afford.
This isn't a good sign especially in light of more and more talk regarding large scale cyber warefare. Hopefuly, that garbage truck incident served as a lesson. On a bright side, at least the guys at the monitoring consoles got a decent break :)
It was stated that many of their links utilize undersea cables but some also use land based fiber. One of such land links was severed by a garbage truck, disabling service to their northern and southern continental CC for several hours.
Now, I know how difficult it can be to design and run a full contigency operation but one would think that with the budget and resources of a government such a goal should not pose too much of a problem. Apparently, this is not so for Army's cyber ops.
To be honest, it's a big surprise to me. I've seen companies not lose a single tcp connection upon core router/switch failures, cable cuts in server racks, and power outages in data centers and they don't have the same resources as the government can afford.
This isn't a good sign especially in light of more and more talk regarding large scale cyber warefare. Hopefuly, that garbage truck incident served as a lesson. On a bright side, at least the guys at the monitoring consoles got a decent break :)
2008-08-16
Why I love cons...
Some great talks, interesting presentations and new ideas. Also, you get to meet very interesting people and get to pick their brains or just hang out and enjoy their strange and wonderful personalities.
However, the best is when you discover people who are true hackers. By that I mean people with a certain state of mind who take a creative approach to solve problems.
Here's an example which proves that a real hacker does not need a computer but only his brain:
And yes, this guy was hacking away at deciphering some message.
However, the best is when you discover people who are true hackers. By that I mean people with a certain state of mind who take a creative approach to solve problems.
Here's an example which proves that a real hacker does not need a computer but only his brain:
And yes, this guy was hacking away at deciphering some message.
2008-05-24
Analysis of the Adobe exploit within Neosploit
It appears that currently the toolkit is under active development. Adobe vulnerability which is exploited is one from CVE-2007-5659 disclosure.
We have seen some old exploit being added, removed, then added again. This was the MS06-067 DirectAnimation.PathControl.KeyFrame() vulnerability. More on this one later.
The function which exploits Adobe vulnerability (CVE-2007-5659) will try to load ActiveX controls in the following order:
If successful then it'll identify the version in use and will continue only if it's below 8.1.2, which makes sense since Adobe realeased an unpdate with this version that fixed the issue. Then, the version is inserted into an already embedded URL string to download the actual PDF file.
Returned PDF file is around 10K in size and contains Zlib compressed obfuscated Javascript. Thus, any IDS detection which looks for the vulnerable code will not pick this one up. Obfuscation method is the same as for all other pages. After peeling this layer off one finds the familiar heap spray function to populate memory with the shellcode. Then, once again a version check is performed. Finally, a long string is created (~ 44K) and used as an argument to Collab.collectEmailInfo() method.
If the overflow works, then the shellcode will GET a URL which is the same as the one before except for one changed byte (from 01 -> 02), perhaps to track which stage is requested. That file is an Executable which will be saved in the user's Temp directory as "sxoC.exe".
For those who rely on HIDS/HIPS, AV, nIDS/nIPS chances are nothing will be seen, unless the dropped binary gets picked up by AV (right!).
We have seen some old exploit being added, removed, then added again. This was the MS06-067 DirectAnimation.PathControl.KeyFrame() vulnerability. More on this one later.
The function which exploits Adobe vulnerability (CVE-2007-5659) will try to load ActiveX controls in the following order:
1. AcroPDF.PDF
2. PDF.PdfCtrl
If successful then it'll identify the version in use and will continue only if it's below 8.1.2, which makes sense since Adobe realeased an unpdate with this version that fixed the issue. Then, the version is inserted into an already embedded URL string to download the actual PDF file.
Returned PDF file is around 10K in size and contains Zlib compressed obfuscated Javascript. Thus, any IDS detection which looks for the vulnerable code will not pick this one up. Obfuscation method is the same as for all other pages. After peeling this layer off one finds the familiar heap spray function to populate memory with the shellcode. Then, once again a version check is performed. Finally, a long string is created (~ 44K) and used as an argument to Collab.collectEmailInfo() method.
If the overflow works, then the shellcode will GET a URL which is the same as the one before except for one changed byte (from 01 -> 02), perhaps to track which stage is requested. That file is an Executable which will be saved in the user's Temp directory as "sxoC.exe".
For those who rely on HIDS/HIPS, AV, nIDS/nIPS chances are nothing will be seen, unless the dropped binary gets picked up by AV (right!).
Subscribe to:
Posts (Atom)