countering malware quality assurance

just a quick post to point out something i just realized - maybe it's obvious to others, maybe not...

i was reading dancho danchev's umpteenth post on malware q/a when it struck me that the recent trend by vendors to put the scanning engine in the cloud effectively kills malware q/a... i suggested before that randomizing heuristic parameters might combat it, but that's probabilistic and comes at the cost of false positives... cloud-based scanning on the other hand ensures that the scanner implementing this new architecture cannot be used effectively (if at all) in traditional malware q/a because the samples will either be given to a server that the av vendor controls (thus destroying the samples' value to an attacker), or if the malware tester manages to sever the ties with the av server then the testing will give an incomplete and misleading result regarding the detectability of the malware in question...

each new scanner that goes this route is another scanner removed from the pool of scanners that malware q/a testers can use and with symantec, mcafee, trend, and panda (and perhaps more that i can't think of at the moment) having already gone this route that's a significant portion of the av user-base which will soon no longer be at the mercy of malware q/a...

i have no idea if this was intended or serendipitous, but either way it's still a good thing - and once again it proves the point that for every measure there exists a countermeasure...

harnessing the power of spam

one of the things i really like is the concept of using the bad guy's tactics against them... i enjoy the subtle irony, so when dmitry chan mentioned the possibility of harnessing the power of spam over on the securiteam blog my creative juices started to flow... i thought i'd share the idea i came up with if for no other reason than because i think it's kind of funny...

the idea is that you use spam emails in CAPTCHAs... if you can pick the ham out of the spam then you pass the test... as the bad guys make advances to beat such spam-based CAPTCHA systems, we use their advances in our spam filters and remove the now detectable spams from the spam-based CAPTCHA so that the bad guys have to keep advancing the art of spam detection in order to bust the CAPTCHAs that stand between them and the ability to produce more spam...

this may well not be workable in practice (i imagine it may simply get too hard for real people to identify the ham) but it's still fun to imagine spammers working against themselves (or more likely against each other since it offers them a new way to compete against each other)...

adapting to malware quality assurance

as previously mentioned, malware quality assurance is an attack against heurstics... the idea is to make the malware sufficiently dissimilar to other malware that most heuristic engines find little of anything to be suspicious about...

and unfortunately, it works... at the time of writing, av-comparatives.org's latest retrospective test show that most of the results are grouped around a 40% detection rate... there are some outliers (in both directions) but 40% seems to be the general ballpark for most products when it comes to detecting new/unknown malware...

that's not really a score to be proud of... maybe once upon a time when new malware was comparatively rare, the remaining 60% of those few new pieces of malware for the small window of opportunity during which they remained new/unknown weren't really a big deal... at the current rate of new malware creation 60% miss rate is a big deal... users need to adapt and vendors need to adapt too...

users can adapt by taking any number of steps to prevent new/unknown programs (malware or otherwise) from executing or getting significant system privileges... this includes things like running as a limited user rather than an administrator, using behaviour blocking/HIPS software, using application whitelisting, using sandboxing, etc...

vendors can adapt by making those techniques/technologies easier to find, easier to understand, and easier to use... but there's one more thing... at one point i thought malware qa was pretty much the last nail in the coffin of heuristics but it's occurred to me that there's one thing vendors might be able to try to breathe some life back into heuristics...

polymorphism (sort of)... by which i mean changing/tweaking the heuristic algorithm frequently enough so as to make the results of malware qa less useful... the premise of malware qa is that if the malware is undetected right now it will stay undetected until the malware gets found by someone-somewhere, then gets sent to an anti-malware vendor for analysis, gets analyzed, gets added to the signature database, and that signature database update gets distributed to the potential victim population... create new malware fast enough and that window of opportunity, small though it may be in the ideal defender case, is still big enough... if instead that window of opportunity was significantly less predictable, malware quality assurance wouldn't offer the same kind of assurance it does now...

that's a high-level thought, though... i don't pretend to know how feasible it is to implement (i'm hoping that some engines have parameters originally intended to adjust it's sensitivity to various conditions and that could be randomized)... i do know that this would likely increase the number of false alarms, and probably worse still make those false alarms equally unpredictable, so maybe it's a bad idea but it's an idea none-the-less and i offer it for free to anyone who wants to try it...

cold boot attack good for more than just full disk encryption

while walking to the bus stop on my way to work one day last week i was thinking about the idea of measure vs. countermeasure (as i sometimes do) and an interesting juxtaposition of concepts popped into my head: non-persistence in malware and the so-called cold boot attack... bonus points if you already know where this is going...

you may recall that i ate some crow way back when i was describing how active stealth could be countered by outside-the-box analysis and then a certain stealthkit that shall not be named came along that used non-persistence to get around that problem... thanks to the work of ed felten and co. it appears i ate the crow a little too soon... non-persistence as a countermeasure depends on the very same assumptions about the volatility of RAM that many encryption implementations depend on - that RAM is volatile enough that it's contents are as good as gone once the system loses power... we now know not only that this assumption is false (there are those who will point out that that much was actually known for quite some time) but also that it's relatively straightforward to exploit...

that means it's technically possible to boot to a dedicated OS on a known-clean medium, dump the contents of memory and detect so-called non-persistent stealth malware using known-malware scanning (for known malware, obviously) or using cross-view diff with a second memory dump taken while the compromised system was still active (for unknown malware)...

this isn't the only countermeasure for non-persistent virtualized stealthkits, but it's a neat one none the less and it shows once again that for every measure there is a countermeasure...