Ladybug in action. How to find vulnerabilities in Android and get into the top white hackers of Google

In 2010, when the bug bounty direction was not yet widely known, Google launched its vulnerability reward program. Since then, more than 3,000 security researchers have participated in the Google Vulnerability Reward Program. Every year, Google updates the lists of its top bug hunters who have found the most vulnerabilities in their products. And we managed to talk to one of them.

Alena Sklyarova is a security researcher, ranked 13th in the top Google bug hunters for the last year, and also 13th in the ranking of Android researchers of all time. Alena has found several dozen vulnerabilities in the Android operating system, for which she has repeatedly received thanks from Google. Most of the vulnerabilities found are of high severity, all of them are noted in the Android security bulletins.

In this article, she will share her hacking experience, talk about the difficulties at the beginning of the journey and successes, and also give valuable advice to novice bug hunters.

How did it all start?

Once upon a time, at the start of my career, I was fortunate enough to get a job at the research center of a well-known Russian IT company. Despite the work projects, each employee of the center had their own research that they did in their spare time. Many colleagues had been working in this field for quite a long time and were already recognized gurus of reverse engineering and binary exploitation. They participated in bug bounty programs of Apple, Samsung, Mozilla, NVIDIA and actively shared their experiences, talked about their research. My colleagues inspired me a lot, and I decided to try to do my own research as well.

I needed to decide on the area of research where I would look for vulnerabilities. In the end, I chose the Android operating system, as it dominates the mobile OS market, and its vulnerabilities could put hundreds of millions of users around the world at risk. So I immersed myself in the research of the Android Open Source Project (AOSP) and learned about the existence of the Android Security Reward Program.

Have you tried looking for bugs in Android apps? Google has a separate reward program for them.

Yes, there was such a program — the Google Play Security Reward Program, under which you could receive a reward for vulnerabilities in mobile applications with more than 100 million installations on Google Play. However, as of August 31, 2024, the program was announced closed due to a decrease in the number of discovered vulnerabilities.

It's funny, but once upon a time, finding and exploiting vulnerabilities in mobile applications was my main job. But once I tried to delve into the OS, applications took a back seat and were no longer as engaging.

Why did you choose to research the OS?

The operating system is significantly more multifaceted than even the most feature-rich application. I am very interested in studying how the various components of the OS interact and function with each other — from the high-level Java world to the native system modules and the kernel.

For me, finding vulnerabilities coincides with studying the structure of the operating system — it immerses me better in the context and makes the process more exciting. As a result, after submitting several reports, I often realized that I had a good understanding of how a particular system service works. After all, how else can you find and exploit a vulnerability without understanding the details of the component's operation?

Tell me about your first bug.

I started participating in the Google Bug Bounty in the summer of 2022. But it didn't work out right away.

For the first two months after registering on the platform, all my attempts to submit a vulnerability report failed. Either Google considered the report a duplicate of some issue, or the engineers couldn't reproduce the bug, or they thought everything was working as intended and it wasn't a bug but a feature. Of course, I didn't want to give up. This stage was quite exhausting, though in some ways the most important. I gained very valuable experience: I learned how system services work, how OS components "communicate" with each other. The operating system code told me a lot and taught me a lot. At the same time, I learned how the Google Bug Bounty program works, how to write a competent report, what mistakes not to make, how to prepare a PoC, how to interact with the Android Security Team, and so on.

In the end, at the beginning of autumn of the same year, I received my first successful vulnerability credit. It consisted of bypassing the Android permission QUERY_ALL_PACKAGES, which applications can obtain only after passing Google's moderation, and leaking information about the packages installed on the device. The bug is quite simple, but it broke the streak of failures, and there was no limit to the joy.

If I found a bug, how do I report it?

If you found a vulnerability, do not delay writing and sending a report to the engineering team. In this matter, the first one wins, and receiving duplicates is always unpleasant.

Be sure to read the program rules on the Google Bug Hunters portal. Here you will find answers to the most popular questions, best practices, as well as approximate payout amounts for various categories of vulnerabilities. Interestingly, according to Google statistics, more than 90% of submitted reports do not contain information about vulnerabilities.

The report needs to be formulated correctly and made as complete as possible. Remember that your report will also be evaluated on a quality scale. The lower the report quality, the lower the payment will be. This is how Google motivates researchers to prepare high-quality and detailed reports. Write the report in English. Come up with a title that reflects the essence of the problem and its impact on security, while remaining brief and informative, for example: "Heap overflow in ClassName#MethodName allows return pointer overwriting that leads to remote code execution". Provide technical details of the vulnerability, description of the attacker's model, reproduction instructions. You also need to attach PoC, stack traces, device fingerprint.

What to include in technical details?

The technical details section of the vulnerability is one of the most important. Here is what should be included:

1. A brief description of the vulnerability and its impact on security.

2. Describe how you discovered the vulnerability in the code, your thought process is very important. Feel free to quote AOSP code, add screenshots of the disassembler or debugger if you reversed and do not have access to the source code.

3. Attach stack traces, crash cases if you fuzzed.

4. Be sure to analyze the malicious impact. Demonstrate what an attacker can gain as a result of exploiting the vulnerability.

5. Note the likelihood of successful exploitation and the resources required for this. Be sure to describe the characteristics of the devices or emulators on which you tested the PoC. Attach configs, describe the environment that needs to be prepared in advance so that the bug manifests itself successfully.

6. Describe the principle of PoC operation.

What should PoC look like?

PoC always depends heavily on the type of vulnerability and exploitation. PoC can be anything — a mobile application, an executable file, a script, a set of bytes. In the case of remote exploitation, an additional device may be required. But there is one rule — PoC must be reproducible on the latest AOSP build. If you attach an Android application as a PoC, remember that pre-built APK files are not suitable as evidence. Instead, provide an Android Studio project, and the engineers will build everything themselves.

Another important point. When creating a PoC, try not to use external dependencies. For example, it is highly discouraged to include third-party libraries in an Android Studio project. I have had cases where such evidence was not accepted.

In addition, it is worth attaching additional materials that contribute to the quick and unhindered reproduction of the vulnerability. For example, I very often attach screenshots and small video files where I demonstrate the PoC in action. That is, in essence, I create a visualization of the reproduction instructions.

It is very convenient to record the screen both from the device itself and from the emulator. However, this function may not always help, for example, if the physical device needs to reboot during the PoC. In this case, I have a separate camera and tripod — I record with their help.

Is it necessary to offer vulnerability fixes?

This is not mandatory, but if you can — then yes!

If you find a bug and know how to fix it, don't hesitate to attach a patch to the report in the additional materials. You can send the patch later, but do it as soon as possible. If your patch is accepted by the engineering team, you can expect additional rewards.

You can read the Patch Rewards Program Rules on the website.

Essentially, the patch must be applied to the master branch of AOSP, fix the vulnerability, and not create new problems.

Can I tell someone about my finding?

You definitely shouldn't do this until the vulnerability is fixed and published by the vendor. Until then, maintain confidentiality and do not share technical details with anyone. This rule applies to all bug bounty programs and is an important part of ethical hacking.

How long to wait for the final decision?

On average, the vulnerability is assessed in about two weeks. I have records in both directions, when the report was reviewed super quickly - in two days, and when it was studied for a very long time - almost six weeks.

Vulnerabilities are assessed by Google engineers according to the Severity Assessment Matrix. Pay attention to the table with ratings, which range from low to critical, as well as rating modifiers. These are cases where your vulnerability may have its danger level reduced. This is a very unpleasant case, and I even managed to encounter it once: a vulnerability that was initially rated as high was downgraded to medium.

What kind of response can I get?

There are only two options:

1. The vulnerability was confirmed and rated from low to critical.

After some time, the bug will be fixed, and you will be notified. For high-rated bugs, this time can take from a month to three, for medium ones you can wait six months or more. Within 90 days, a reward is assigned. Sometimes this happens before the vulnerability is fixed.

In the end, the vulnerability is assigned a CVE ID, published in the Android Security Bulletin, and acknowledged by the Android Security Team.

Note that in the bulletins for the past year, you will not find vulnerabilities rated below high, that is, only critical and high. The point is that in May 2023, the Android VRP rules were changed, according to which CVEs will no longer be assigned for medium bugs. Plus, the matrix itself is sometimes updated, and some types of impact may be re-evaluated.

2. The vulnerability was not confirmed.

There are several verdicts here. I have encountered the following: NSBC (Not Security Bulletin Class) and Duplicate. Everything is clear with duplicates — another researcher submitted a report on this vulnerability before you. NSBC denotes vulnerabilities that do not meet the matrix criteria and most often correspond to minor security issues. NSBC is always supplemented with a status:

• Won’t fix (Not reproducible)

Engineers could not reproduce the bug. This may be due to poorly written instructions or an incorrectly working PoC, but most often it happens because the bug has already been fixed. For example, in an internal engineering build of Android.

• Won’t fix (Intended behavior)

Everything works as expected, there is no bug here.

• Won’t fix (Infeasible)

These are usually vulnerabilities with a low impact on security. Google considers this risk acceptable and leaves everything as it is.

• Won’t fix (Obsolete)

A rather rare type, it means that the bug is outdated. I have seen this only in the public bug tracker (Issue Tracker).

Did your reports often fail?

Quite often, especially at the beginning, when you are just learning and making mistakes. Now the number of failures still outweighs the number of successes. I have a 55% failure rate, meaning more than half of the reports I submitted were not accepted. I had a lot of them at the very beginning. Mostly due to duplicates and low-impact security bugs.

Then I worked on my mistakes. If in the first year successful reports were only 13%, then in the last year it was 85%.

How long does it take to find one bug?

It always varies. Sometimes you get lucky and find something interesting in a couple of days, and sometimes you can struggle for several weeks and find nothing. If you have a main job and bug hunting is a hobby (as in my case), then your time resources will be limited, and the search may take longer.

Tell me about your bugs.

I have successfully reported 30 vulnerabilities in Android so far. Of these, 10 already have their CVE IDs, the rest are awaiting assignment.

At the beginning, I focused more on finding leaks through permission bypasses, as I mentioned earlier. Previously, such bugs were rated as medium, but they were downgraded to low, and you can no longer get a CVE for such a leak. Example — CVE-2023-21348.

Currently, I mainly find bugs like EoP and permanent DoS. All of them have a high level of danger.

For example, the vulnerability CVE-2024-23713 allowed a malicious application to gain the right to listen to notifications, even if the user did not grant such permissions. And the result of exploiting the vulnerability CVE-2023-21240 was a permanent denial of service of the device, in which the smartphone entered a state of infinite boot loop and became unusable. This happened due to heap overflow and resource exhaustion of the system during its boot stage when processing the device's Wi-Fi configuration.

How to get to the top of the ranking?

It's quite difficult, but possible. You need to successfully submit as many cool bugs as possible that will push you forward. Remember — the competition is high! A lot of cool guys are bug hunting, many for several years. And it's always hard at the start.

The ranking is generally a very dynamic thing — it always changes. Found new vulnerabilities? Then you will move up. And if you didn't search, were busy with something else, then you start to slowly slide down, someone moves ahead. This is normal.

It seems to me that without a developed strategy it is impossible to stay at the top all the time. You must have your own approach to finding vulnerabilities, and it should work like clockwork. This is already such a level when bug hunting becomes a daily job. Otherwise, the position in the ranking will be unstable.

What is important for successful vulnerability search?

I think the key point is the ability to adapt quickly and not be afraid to discover new things. Get inspired by other researchers, analyze and read their work, develop your own ideas. Take notes as you go along — you can always come back to them and see with fresh eyes what was previously unnoticed. The ability to learn new things, improve your skills, and keep moving forward despite setbacks is the key to success in bug hunting.