Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

8/6/2020
08:33 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Getting to the Root: How Researchers Identify Zero-Days in the Wild

Google Project Zero researcher Maddie Stone explains the importance of identifying flaws exploited in the wild and techniques used to do it.

When a zero-day vulnerability is exploited in the wild, it's essential to identify the bug at the root of the attack. This "root cause analysis" informs researchers how an attack unfolded.

"We care a lot about making it harder for people to exploit users using zero-days," said Google Project Zero researcher Maddie Stone in a Black Hat presentation on the topic. "When zero-day exploits are detected in the wild, that's the failure case for these attackers. And so we need to learn as much as possible each time that happens."

Much of the time, when the security industry learns of a zero-day exploit in a blog post or advisory, there is often information about the malware payload or attack group behind it, but little about the "nitty gritty" of how intruders got the initial access to launch their attack. 

The goal of a root cause analysis comes down to figuring out what that vulnerability is, in such depth that researchers can trigger it, Stone explained. This shows they understand all the details – not just the overarching summary – as well as the attackers' exploit methodology. This information can help determine which actions should be taken next to prevent it from being exploited again, such as structural improvements, variant analysis, and new detection methods. 

Over the past 12 months, Project Zero has analyzed 11 zero-day vulnerabilities exploited in the wild. Researchers used five different techniques to identify their root cause, underscoring a point Stone emphasized in her talk: the process for analyzing a vulnerability can vary each time.

"There's a lot of different ways to reverse engineer a vulnerability," she explained, and these can vary depending on the information available and the target being exploited. Security researchers often talk about processes as a monolith; in reality, there's a lot of creativity involved and paths they can take to raise the likelihood for success while using fewer resources. 

She broke the techniques down into four categories. Reversing the exploit code can be done if a researcher has the exploit sample. Source code patch diffing can be used if they have access to a target's source code; for example, if someone is researching on Android, Chrome, or Firefox, or if they have privileged access as a vendor or partner. Binary patch diffing involves comparing two binary builds of the same code; one known to be vulnerable and one containing a patch. "Bug hunting based on exploit details" is possible with tips on an unpatched vulnerability.

The technique a researcher uses largely depends on their role. Understanding not just what the technique is, but how it's done, can vary from one zero-day to the next. 

"Your role influences what data you have access to, and how much you're willing to invest in getting to the root cause vulnerability," Stone explained.

A person who discovered the exploit, for example, may not decide to do a root cause analysis because their primary goal is to get it fixed. If they wait on reporting until they achieve root cause analysis, they prolong the amount of time a vulnerability goes unpatched. In these cases, they often have access to an exploit but not necessarily the source code or vendor expertise.

Vendors are another story. If a researcher works for a vendor, they likely have access to more details, whether that's the experts who wrote the code being exploited, or the source code itself, and/or the exploit. In these cases, Stone said, they should complete root cause analysis.

Then there are the third-party users and researchers, who see something was exploited in the wild through a blog post or advisory and likely have the least amount of information. They'll need to decide how much time and energy they want to invest in the project.

Project Zero has been in each of these positions, she noted. "Sometimes we discover [the vulnerability], sometimes vendors ask to partner with us for expertise [and] help figure out the root cause; and most often we're the third party researchers who are trying to dig in and learn as much as we can."

Stone's presentation (slides available) detailed seven case studies across a variety of platforms including Windows, iOS, WhatsApp, Firefox, and Android. These cases revealed similarities and differences in reverse engineering techniques across targets. Some were successful, others were not – a takeaway she emphasized to her audience of security pros.

"Not every endeavor is successful," she said, but "each time we don't get to the end goal, or have a success of identifying the root cause, we have a lot to learn from that we can then apply, if we're deliberate, to the next set to raise the probability of success."

Related Content:

 

 

Register now for this year's fully virtual Black Hat USA, taking place now, and get more information about the event on the Black Hat website. Click for details on conference information and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...