Skip navigation.
Home

blogs

Logical bug in <= gmer.sys [1, 0, 15, 4809 built by: WinDDK]

Messing a little bit recently with a gmer’s code I discovered logical bug which can cause abnormal behavior of an random applications.

[+]Localization of a problem
If some file can’t be deleted in the usual way, gmer will try to close all opened handlers related with this file and after it delete file.
In my opinion implementation of this procedure has not been thought out correctly.

More info here
http://www.icewall.pl/2010/07/22/blad-logiczny-w/?lang=en

<= GMER 1.0.15.15281 Buffer overflow 0day

During some research which results I’m going to publish in near future, I discovered a bug in a gmer win32 application causes a buffer overflow.
(un)Fortunatelly because of existing security cookies in code and it’s character near function where BO appears, it’s not possible to
achieve code exec.
Although couples of my tries to contact with gmer’s author I didn’t get any response for this day and unfortunatelly bug has not been fixed yet also. So , only thing I can do now is to share with you an advisories, which you can download from here:

Vera 0.20 - Now Available

After a lot of work, I'm happy to announce that Vera 0.20 is available for download. This release is a rewrite of the entire code base into wxWidgets. Based on some excellent feedback from my talk at REcon (an excellent con by the way) I've made some substantial changes to the backend code.

If you're not familiar with VERA, it's a visualization tool to help understand the dynamic execution of a program. It's made to take the instruction traces from Ether and generate directed graphs showing the overall flow and composition of a program. Identifying the OEP is easy, as well as looking for main loops and initialization sections of the program. You can read about VERA in my Vizsec 2009 paper for more information.

Here's the complete changelog:

Rewrite of entire codebase to wxWidgets (should allow for future ports to other platforms)
Added configuration file (~/.wxVera/wxvera.ini)
Read/save previous window position and size from/to config file
Fixed a graph centering problem
Added update checking code
Reloading of graphs more efficient
Added welcome message
Introduced notebook style for GUI

Please feel free to contact me (dquist at this domain) if you have any problems or suggestions for VERA. Thanks!

AV Testing Standards: Don't Like the Results of the Tests? Change the Rules

There were good responses, mostly from people in the AV industry, to my blog post about the malware testing standards. Overlooking my error linking to their original paper (sorry) there were some points I would like to address.

At the heart of this whole process, is exactly how dangerous a collection of malware is. For the consumers, I would argue, it's not dangerous at all. The malware industry is the only one who has to fear from it. Notice I didn't say just the AV vendors, but also the producers of the malicious software. In large part the authors depend on a closed, inside group of people unwilling to collaborate openly on the problem. If you look at the major sources of malware in academic research prior to the creation of large open collections, you'll see that there were some big problems. First, the samples were old and not representative of current threats. Second, those samples either did not work or were not malicious in nature. Finally, the samples are traded as something of value.

I'm no different, of course. I derive value both from the collection and from consulting. I do, however, go out of my way to support those doing open research as much as I can. If someone in academia needs access to samples, just contact me and I'll work something out. Likewise we have helped innumerable small businesses get their start in the malware world before they could enter the "circle of trust" mentioned by David Harley.

The "circle of trust" is often cited when discussing who can and cannot gain access to these samples. Over the course of the years I've joined four of these groups. While the vetting is done as best as possible, there's very little outside of an email address, and a recommendation keeping someone from joining. Antivirus vendors exchange malware with themselves at a much higher volume, but there is still a perceived difficulty of entering this area. Malware exists on the Internet in a freely available manner as a function of its being. Limiting sample access to a certain set of privileged people fundamentally hurts innovation and response by everyone.

There was also some allusion that I did not support malware testing at all. That is not the case. Malware defense systems should be heavily tested against a range of threats. The basis for my problems with the AMTSO is that it should *not* be composed of anyone in the AV industry. Consumer Reports did an excellent job exposing the ineffectiveness of AV vendors by producing new samples. Due to the very nature of the threat, there are going to be new samples that are discovered for the first time. If an AV software can't respond to this threat, it should not be given a favorable review.

The current set of players in the malware testing arena are profit driven. In and of itself that's ok, I'm all for capitalism, but in fairness there needs to be an independent authority. AV testing companies that publish open information on the effectiveness of scanning results are not independent. Without naming names, there is a prominent one claiming to provide results for the public, but instead is backed by every AV vendor in the industry. This testing company takes in new samples, scans them with all the products, then tells the vendors how their performance rates. What is not acceptable, in my view, are the shoddily written reports intended for consumers that report unethically high detection rates.

Finally I would like to address the ethics of the malware tester. One thing I agree with David Harley on is the need to represent the full scope of the testing process to the consumer. One of the things that the academic world does well is to produce research which can be recreated by other researchers. That's the intent, at least. AV testing standards advocated by the vendors cannot and will not provide the latest samples to malware authors. What this ends up doing is providing all the methods of testing, but not the actual data to test on. For those of us able to use new samples, it's not a problem. Others who have older data and are unable to acquire new malware (due to cost, time involved, etc.) are left with only one viable option: Synthesize new samples using the exact same methods available to the authors.

Does anyone have a sample of rootkit.tmphider / drop.stuxnet.a.5

|

i'm looking for a sample which apparently has the md5 of 016169ebebf1cec2aad6c7f0d0ee9026, and has been known to propagate over USB by exploiting an lnk file based exploit.. any pointers would be appreciated

Using RDMA during malware research

During my malware research i have encountered thousands of samples.
most research labs uses same methods during their sample analysis, they all uses emulators or any other kind of virtualization implementation.
the problem start when trying to analyze well defended malwares, i.e. malwares which uses good packers, antivm and anti debugging technique (and no im not talking about IsDebuggerPresent).

Vera 0.11 - Bug Fix Release

First of all, thanks for all the great feedback from everyone about Vera. Keep the feedback coming!

Vera 0.11 is out on the main Vera page. This release fixes a major memory leak for those of you who aren't running video cards with a gig of ram. This should also alleviate problems that were related to running under Windows XP. A future port to a wxWidgets version is underway. This will eventually allow for cross-platform versions, hopefully timed with the IDA QT release.

As always, please report bugs to dquist at this domain.

Gunpack - A Generic Unpacking tool

God's Unpacking tool for automated unpacking.
A generic unpacking tool works well against almost all the packers, except few.

http://code.google.com/p/gunpack/

URLVOID: Suspicious url scanner

Urlvoid (beta version at the moment) is a free service that scan suspicious websites with multi engines to check if the site is safe to browse.

Its a virustotal like but for websites ;)

http://www.urlvoid.com/

Scanner list used by urlvoid:

McAfee SiteAdvisor, McAfee Trusted Source, PcTools Browser Defender, Norton SafeWeb, MyWOT, Threat Log, MalwareDomainList, hpHosts, ZeuS Tracker, Google Diagnostic, PhishTank, Project Honey Pot, ParetoLogic, Spamhaus, URIBL, Malware Patrol, SURBL, SpamCop, TrendMicro Web Reputation, Web Security Guard.

Finding the TDSS authors and affiliates ---- An Analysis

Although it is a mystery who created TDSS, there are some interesting strings in some of TDSS'es files.

Lets start with this one.

If we open the file in notepad, we see this somewhere:

Comments Thanks to Edin Kadribasic, Marcus Boerger, Johannes Schlueter

FileVersion 5.2.11.11 0
InternalName php.exe |$ LegalCopyright Copyright 1997 - 2007 The PHP Group 0 LegalTrademarks PHP 8 OriginalFilename php.exe PrivateBuild 8 ProductName PHP php.exe 2 ProductVersion 5.2.11 SpecialBuild URL http://www.php.net D VarFileInfo $ Translation Z y D @ M u . ? / $ !

Syndicate content