Last year I decided to do some security research on an antivirus product. Avast seemed a good target since it is among most popular AV products used by home users and, as an added bonus, there is a bug bounty program ran by Avast.
I downloaded Windows version and decided to take a look at the inter-process communications done by various components and, believe me, there are a plenty of them in Avast. To be fair, many antivirus products these days incorporate a plethora of functionality which means a bunch of components and subsystems, e.g. browser protection, E-mail protection, VPN module and so on. As components emerge, there is a need to establish some communication protocol between them. So Avast on Windows heavily relies on Microsoft Remote Procedure Calls for that. Specifically, they use Local Procedure Calls (LPC).
The first vulnerability I stumbled upon was in a set of APIs designed to work with files: delete a file, move a file, and finally (juicy!) execute a file (well, almost – not just any file – read on). These APIs are available to any local user on the Avast box.
So what happens here is that any local client can use the LPC interface defined by Avast to invoke the aforementioned functions. This, in turn, will make an RPC call to a local server running as LocalSystem (specifically, this is the AvastSVC.exe Windows service). Guess what happens next? J
In order to pull off the file execution I had to perform a bit of a trick. The binary you can launch is hardcoded and predefined. However, as it happens sometimes, there is a binary from that predefined list which will happily load an evil library if we want it. So in the end we get arbitrary code execution as LocalSystem by any local user.
Unfortunately, in order to perform all of the above the Self-Defense feature needs to be turned "OFF". The reader may ask: is it on by default? Well, of course! Avast is smart enough to ship the product with Self-Defense ON. This essentially protects Avast from attacks coming from other code (non-trusted by Avast) even if the code executes at an elevated level. This meant I had to do one more obstacle to overcome: break the protection.
So the way Avast itself disables and enables Self-Defense is also via RPC. However they do check that the RPC comes from trusted code, e.g. code signed by Avast. So if my own application tries to invoke the RPC in question, it will fail. I then tried to start the avastui.exe (which is signed) from my own location and inject my code via a library replacement – specifically I replaced the ssleay32.dll with my own evil library. However Avast does a check there too – the call to RPC must come from a signed module, and the ssleay32.dll I built is obviously not signed by Avast. However, I kept the hope and continued the search for an escape.
After a few days of intermittent code examination I found an IOCTL that is used to mark a process as trusted. One of the parameters the IOCTL accepts besides the PID, is a location of a function that must return 1 as one of its outputs and must be within an Avast-signed module again. And as it happens, there are several such gadgets (i.e. locations with instructions that behave exactly as we need) in the binary shipped by Avast itself.
I will spare some space here and direct readers to the advisory we've published recently for both technical details and a fully working POC! Check it out here: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/multiple-vulnerabilities-in-avast-antivirus/?fid=9201
Avast has been cooperative and released a new version of the product in February which resolves all the issues mentioned. To remedy these vulnerabilities please upgrade to at least Avast v17.