We have developed a system that discovers 0day vulnerabilities automatically.

The preparation for the upcoming Hactivity conference [25-26 October 2019] goes really well. This week we also launched the mass production of our new electronic hardware-hacking badge that is going to be handed over to our ticket buyers. These are the things you might already know, but here’s a new announcement which is for sure new and exciting for you.

In the background, The Hacktivity Team have created a new department called Hacktivity Labs. \o/
What is this about? In general, Hacktivity Labs will focus on reverse engineering all kinds of techniques to discover software & hardware vulnerabilities. [This department is responsible for the production and development of the hardware-hacking badge as well.]

Finding bugs automatically

If you have ever searched for software or any kind of bugs you may know that after being happy about it, the next thought is that: OK, how can I find a lot more of this? So the first project of Hacktivity Labs was to develop a tool that can automatically find software vulnerabilities efficiently on Windows operating system. 

The leader of this project is Attila Marosi-Bauer. In his free time, he likes to dive deep in the process of reverse engineering to get a better understanding of how these products are operating, and more importantly to find the vulnerabilities and weaknesses of these kinds of software.

Ok, we recognized that we have the obsession to find software bugs on Windows systems. One of the easiest test cases is to run the tested application while Sysinternals ProcMon or any kind of system monitoring service running to collect information about the discussion of the application and the Operation System. After harvesting enough behavior information, the one that can query well may find software vulnerabilities.
For example:
  • DLL search order hijacking
    • DLL injection
    • DLL hijack
  • loading DLL by COM objects (com object hijacking)
    • here we have the same ability: hijack and/or add dll to the application (depends on the application)
If an application has one of this type of vulnerabilities and its running in highest integrity level, then a folder (or registry hive) can be written, that leads to privilege escalation.
However this approach seems quite “noob” and these bugs can be detected quite quickly, most of you may think that “big” names have already tested their applications in this way to stay away from these stupid bugs. But the reality shows something else.
We did it many times and found many vulnerabilities but after a time we get bored with it. The path was clear: we need automation. 
Automation of the process:
  • start a VM
  • start monitoring tools
  • harvest collected data
and then, here we had the real challenge. Turn into a code what was in our mind. We had many best practices to find vulnerabilities. So we had to clean them to be able to write a code that can replace us. 🙂 Now we’re done with it.

It was pretty clear at the beginning of this process that simply grepping the logs to find “NOT FOUND” and such will result in more false-positive records then valuable hints.

So we decided to create a system that can “rebuild” processes by the logs and can understand the events by the time they occur. By this approach, the system can easily make differences between events that are good for nothing, and taking care of them is just a waste of time or events that may highlight vulnerabilities that can be exploited for sure. 

This system now can recognize:
  • dll hijack
  • com object hijack
Also, it understands process integrity levels, thus it can also highlight the vulnerabilities that may be used for privilege escalation.
Our automated system has been designed to have the ability to be extended. Currently, the above-mentioned vulnerabilities can be detected by it, but in the future, some more will come. What makes this special is that it is able to audit Windows applications within minutes as well.

How deep is the rabbit hole?

In this section, we would like to provide some proof of our service. After working out the beta system, we tested it with many application of different vendors. The best target of this tool is the desktop agent applications, especially if they have/need admin rights. Maybe because we are working in this industry for a long time, maybe not, but our first candidates were AntiVirus agents. As you can see, with this tool vulnerabilities can be found in other types of applications as well

VMware Workstation 14.1.5 / VMware Player 15 – Host VMX Process COM Class Hijack Privilege Escalation

This vulnerability was not found by our system but it could have been.
The description which can be found on the exploit-db.com is very clean. (https://www.exploit-db.com/exploits/46601)
“The VMX process (vmware-vmx.exe) process configures and hosts an instance of VM. As is common with desktop virtualization platforms the VM host usually has privileged access into the OS such as mapping physical memory which represents a security risk. To mitigate this the VMX process is created with an elevated integrity level by the authentication daemon (vmware-authd.exe) which runs at SYSTEM. This prevents a non-administrator user opening the process and abusing its elevated access.
Unfortunately the process is created as the desktop user which results in the elevated process sharing resources such as COM registrations with the normal user who can modify the registry to force an arbitrary DLL to be loaded into the VMX process.“
If we check this application in our system we get this result:
So, we have an alert! Check out the details of it!
The owner of the process is DESKTOP-HVNOCSA\dev This user has admin rights but we did not grant added rights for it (by UAC). 
The integrity level of the process is System
The system also flags the process as:
    • can be hijacked by CLSID
    • can be hijacked by dll injection
    • or any of the vulnerabilities can be turned into a privilege escalation
If we scroll down in the log we get the most interesting part of it.
By this summary we immediately know that:
  • 5 COM object has to be used by the process
  • DLLLoaded: True = From the 5, only 3 loaded during the analysis. This is one of the best features of the tool. According to the logs, these were many many COM actions but only these can give you a chance to exploit them.
    • {CB8555CC-9128-11D1-AD9B-00C04FD8FDFF}
    • {7C857801-7381-11CF-884D-00AA004B2E24}
    • {D68AF00A-29CB-43FA-8504-CE99A996D9EA}
  • DLLLoaded: False = These are the COM objects that are queried by the process but during the analysis () they not loaded. Maybe later, in other circumstances, there will be an event that leads to DLL load, but in our analysis, they did not load.
    • {E7D35CFA-348B-485E-B524-252725D697CA}
    • {1B1CAD8C-2DAB-11D2-B604-00104B703EFD}
However, this bug was not found by our system, finding it would require some more minutes.
Since we don’t want this post to become too much technical, we won’t share any further details, only some statistics. If you are interested in the bugs we found in a deeper way, please contact us! At the end of this article, you can find some more information on getting a live demo about our project.

AntiVirus systems

We had a quick test about 7 different AV vendors’ products and we immediately found vulnerabilities in 5 of them.
However a few of the bugs we found have already been patched and released, here we won’t share details about them. Also, we won’t share the name of the vendors right now. (this is not the right time for it)

Vulnerabilities overall

According to our tests, 70% of the applications have some kind of vulnerability, meaning that we have much more bugs (0day) in the drawer then we can handle.

S(H)ELOB – Streams Endlessly Logic Bugs

Ok, so we have the project, now we have to find a name for it. 
The name of the tool is very close to S(h)elob, that is a fictional demon in the form of a giant spider from J. R. R. Tolkien’s Middle-earth legendarium. However s(h)elob is not a positive character in the story, our tool definitely is. We would think about this tool and the service as something that can provide a safety net for products that may fall without it.

Pros – Cons 

As usual in the project life, we have to summarize the positive and negative results, to find out where to go. In this current state, all the processed data are generated from running applications that have some pros and cons.

Pros:

  • No need to understand the code
    • no source code needed
    • no need to decompile
  • Finds logical software bugs quickly and efficiently
  • Generate vulnerability report in Markdown format (each type of vulnerability has its own template). Contains all information which needs to reproduce the bug
  • Capable of generating Proof of Concept (PoC) codes automatically
  • This framework has a good base to extend to find more type of bugs

Cons:

  • We have to be able to run the application. Sometimes it not so trivial:
    • system compatibility issues
    • licensing… etc.
  • We can only test the code path that we can run
    • if there is a code path we did not reach (or cannot reach) we won’t find any vulnerabilities

Way to go

Our main goal with this project is to use these techniques in an ethical way in order to help vendors discovering and fixing software vulnerabilities. We have hundreds of 0days in the drawer and we are looking for partners who would use these vulnerabilities ONLY for respectable & ethical purposes!
If you would like to get more information about this tool and the service, do not hesitate to contact us via [email protected]!  At #Hacktivity2019, we would like to provide some live demos for those who are interested in this project and for wannabe partners as well. Please note, that pre-arranged appointment is needed for these live demo sessions.