«Breaking Antivirus Software Joxean Koret, COSEINC 44CON, 2014 Breaking antivirus software Introduction Attacking antivirus engines Finding ...»
Breaking Antivirus Software
Joxean Koret, COSEINC
Breaking antivirus software
Attacking antivirus engines
Exploiting antivirus engines
Common features of AV engines:
Written in C/C++.
Signatures based engine + heuristics.
Command line/GUI on-demand scanners.
Support for compressed file archives.
Support for packers.
Support for miscellaneous file formats.
Advanced common features:
Packet filters and firewalls.
Drivers to protect the product, anti-rootkits, etc...
Antivirus products or engines An antivirus engine is just the core, the kernel, of an antivirus product.
Some antivirus engines are used by multiple products.
For example, BitDefender is the most widely used antivirus kernel.
It's used by so many products like QiHoo360, G-Data, eScan, F-Secure, etc...
Most “big” antivirus companies have their own engine but not all. And some companies, like F-Secure, integrate 3rd party engines in their products.
In general, during this talk I will refer to AV engines, to the kernels, except when specified the word “product”.
Attack surface Fact: installing an application in your computer makes you a bit more vulnerable.
You just increased your attack surface.
If the application is local: your local attack surface increased.
If the application is remote: your remote attack surface increased.
If your application runs with the highest privileges, installs kernel drivers, a packet filter and tries to handle anything your computer may do...
Your attack surface dramatically increased.
Myths and reality
“We make your computer safer with no performance penalty!” “We protect against unknown zero day attacks!”.
AV engines makes your computer more vulnerable with a varying degree of performance penalty.
The AV engine is as vulnerable to zero day attacks as the applications it tries to protect from.
And can even lower the operating system exploiting mitigations, by the way...
Breaking antivirus software Introduction Attacking antivirus engines Finding vulnerabilities Exploiting antivirus engines Antivirus vulnerabilities Conclusions Recommendations Attacking antivirus engines AV engines, commonly, are written in non managed languages due to performance reasons.
Almost all engines written in C and/or C++ with only a few exceptions, like the old MalwareBytes, written in VB6 (!?).
It translates into buffer overflows, integer overflows, format strings, etc...
Most AV engines installs operating system drivers.
It translates into possible local escalation of privileges.
AV engines must support a long list of file formats:
AV engines not only need to support such large list of file formats but they also need to do this quickly and better than the vendor.
If an exploit for a new file format appears, customer will ask for support for such files as soon as possible. The longer it takes, the higher the odds of losing a customer moving on to another vendor.
The producer doesn't need to “support” malformed files.
The AV engine actually needs to do so.
The vendor needs to handle malformed files but only to refuse
can install new files and/or replace existing installation files.
It often translates in completely owning the machine with the AV engine installed as updates are not commonly signed.
Yes. They aren't.
I will show later one of the many vulnerable products...
Breaking antivirus software Introduction Attacking antivirus engines Finding vulnerabilities Exploiting antivirus engines Antivirus vulnerabilities Conclusions Recommendations Vulnerabilities in AV engines Started around end of July/beginning of August 2013 to find vulnerabilities, for fun, in some AV engines.
At first, during my spare time, some hours from time to time.
Found remote and local vulnerabilities in 16 AV engines or
I'll talk about some of the vulnerabilities I discovered.
The following are just a few of them...
Some old AV engines vulnerabilities Avast: Heap overflow in RPM (reported, fixed and paid Bug Bounty) Avg: Heap overflow with Cpio (fixed...)/Multiple vulnerabilities with packers Avira: Multiple remote vulnerabilities BitDefender: Multiple remote vulnerabilities ClamAV:Infinite loop with a malformed PE (reported & fixed) Comodo: Heap overflow with Chm DrWeb: Multiple remote vulnerabilities (vulnerability with updating engine fixed) ESET: Integer overflow with PDF (fixed)/Multiple vulnerabilities with packers F-Prot: Heap overflows with multiple packers F-Secure: Multiple vulnerabilities in Aqua engine (all the F-Secure own bugs fixed) Panda: Multiple local privilege escalations (reported and partially fixed) eScan: Multiple remote command injection (all fixed? LOL, I doubt...)
In my case I used, initially, Nightmare, a fuzzing testing suite of my own.
Will be officially presented at T2 conference (Finland) in October.
Downloaded all the AV engines with a Linux version I was able to
Fuzzed the command line tool of each AV engine by simply using radamsa + the testing suite of ClamAV, many different EXE packers and some random file formats.
Results: Dozens of remotely exploitable vulnerabilities.
Also, I performed basic local and remote checks:
A friend of mine convinced me to write a fuzzer and do a “Fuzzing explained” like talk for a private conference.
Really simple fuzzing engine with a max. of 10 nodes.
engines, those I was able to run and debug.
For that specific talk I did fuzz/test the following ones:
BitDefender, Comodo, F-Prot, F-Secure, Avast,
ClamAV: 1 Remote DOS with a malformed icon resource directory in a PE.
Avast: One possible RCE due to an uninitialized variable in code handling RPM archives.
F-Secure: One memory exhaustion bug with CPIO.
Comodo: 2 heap overflows, one handling CHM files.
F-Prot: Armadillo, PECompact, ASPack and Yoda's Protector unpackers heap overflows.
AVG: CPIO and XAR heap overflows.
BitDefender: Amazing number of bugs. Many likely exploitables.
Breaking antivirus software Introduction Attacking antivirus engines Finding vulnerabilities Exploiting antivirus engines Antivirus vulnerabilities Conclusions
Exploiting an AV engine is like exploiting any other client-side application.
Is not like exploiting a browser or a PDF reader.
Exploiting memory corruptions in client-side applications remotely can be quite hard nowadays due to ASLR.
However, AV engines makes too many mistakes
But it's common that only the core modules are compiled with ASLR.
Not the GUI related programs and libraries, for example.
Some libraries of the core of some AV engines are not ASLR enabled.
Check your target/own product, there isn't only
The x86 emulator is a key part of an AV engine.
It's used to unpack samples in memory, to determine the behaviour of an executable program, etc...
Various AV engines create RWX pages at fixed
By default, an AV engine will try to unpack compressed files and scan the files inside.
A compressed archive file (zip, tgz, rar, ace, etc...) can be created with several files inside.
The following is a common AV engines
AV engines implement multiple emulators.
The emulators, as far as I can tell, cannot be used to perform heap spraying, for example. But they expose a considerable attack surface.
It's common to find memory leaks inside the emulators,
a programming interface to craft inputs to the AV engine.
Exploiting AV engines: Summary Exploiting AV engines is not different to exploiting other client-side applications.
They don't have/offer any special self-protection. They rely on the operating system features (ASLR/DEP) and nothing else.
And sometimes they even disable such features.
There are programming interfaces for exploit writers:
Multiple files doing different actions each can be send in one compressed file as long as the order inside it is kept.
Owning the AV engine means getting root or system in all AV engines I tested. There is no need for a sandbox escape, in general.
Breaking antivirus software Introduction Attacking antivirus engines Finding vulnerabilities Exploiting antivirus engines Antivirus vulnerabilities Conclusions Recommendations Details about some vulnerabilities in AV engines and products...
Also, if you uses my research for promoting your products and they suck, you deserve public shame.
Affected AV engines or products The bugs I will show affect the following AV
engines or products:
AVG, BitDefender, BKAV, ClamAV, Comodo, DrWeb, eScan, ESET, FortiClient, Ikarus, Kaspersky, Kingsoft, Panda, Rising and Sophos.
Products using engines from the previous list are, naturally, also affected.
Some bugs are vulnerabilities by itself and others are not.
Some are 0days and other are recently fixed.
Local Escalation of Privileges Example: Panda Multiple local EoPs In the product Global Protection 2013 there were various processes running as SYSTEM.
Two of those processes had a NULL process
We can use CreateRemoteThread to inject a DLL, for example.
Two very easy local escalation of privileges.
But the processes were “protected” by the shield.
Example: Panda Multiple local EoPs Another terrible bug: The Panda's installation directory had write privileges for all users.
However, again, the directory was “protected” by the shield...
What was the fucking shield?
The Panda shield was a driver that protects some Panda owned processes, the program files directory, etc...
It reads some registry keys to determine if the shield is enabled or disabled.
But... the registry key was world writeable.
Also, it's funny, but there was a library (pavshld.dll) with various exported functions...
Example: Panda Multiple local EoPs All exported functions contains human readable names.
All but the 2 first functions. They are called PAVSHLD_001 and 002.
Decided to reverse engineer them for obvious reasons...
The 1st function is a backdoor to disable the shield.
It receives only 1 argument, a “secret key” (GUID):
ae217538-194a-4178-9a8f-2606b94d9f13 If the key is correct, then the corresponding registry keys
There were many more stupid bugs in this AV product...
For example, no library was compiled with ASLR enabled.
One could write a reliable exploit for Panda without any real big effort.
And, also, one could write an exploit targeting Panda Global Protection users for any program.
Why? Because it used to inject 3 libraries
We already discussed that Panda Global Protection didn't enable ASLR for all modules.
Do you believe this is an isolated problem of just one antivirus product?
As it is common with antivirus
avzkrnl.dll and module vlns.kdl, a vulnerability scanner (LOL), were not ASLR enabled.
One could write a reliable exploit for Kaspersky
BKAV is a Vietnamese antivirus product.
Gartner recognizes it as a “Cool vendor in Emerging Markets”.
I recognize it as a “Cool antivirus for writing
And, like Panda, they inject a non ASLR enabled library system wide, the Bkav “firewall” engine...
...miserably failing at securing your computer.
BTW, this vulnerability was made PUBLIC
So, apparently, they did not fix that vulnerability. However, I cannot probe it.
I'm not going to buy one more f**cking AV product.
Anyway... do you think Panda and BKAV are
Kingsoft is a Chinese software company.
This company offers one AV suite: Kingsoft Internet Security or Kingsoft AV.
Kingsoft uses BitDefender so all BitDefender's own bugs are also present on it's AV product.
However, they have many bugs to worry about, not
It took me a while to discover the true latest version as the versions in English are not the latest one.
Only the Japanese and Chinese versions are the true latest ones. So this time I had the option to choose which language I do not understand at all I want to install this AV product on.
Indeed, I don’t know if I installed it, finally, in either Japanese or Chinese. Anyway.
The hardest part of finding bugs on it was actually
And they install 1 to 4 non ASLR enabled
libraries system wide:
Miserably failing at securing your computer like Panda or BKAV.
Writing exploits targeting Kingsoft AV's users is
Comodo Antivirus is a product from Comodo Group, a company from USA.
This antivirus, no matter what they say, is as crappy as most of the other AV products I analysed and in some senses it's even worst than most others.
They decided to use my prior research to
The product Comodo Internet Security is the one they mentioned in a
desafortunate blog post:
in the ass.
More than anything, because most IDA modules (tested 6.4 to 6.6) are flagged as malware, so you can't run properly IDA in the analysis machine...
False positives, yeah.
Nobody uses IDA at
So, I spent in total 2 days, considering the time required to revise the crashes I get from my fuzzing system.
Let's see my results only regarding ASLR...
Comodo Internet Security Another cool antivirus for writing targeted exploits: the library guard(32|64).dll without ASLR is injected system wide.