How to do Security Research with ZeroPath

Introduction

It's trivial, but security researchers, even bug bounty hunters, often begin their research by running SAST tools, just to check for low hanging fruit. If the target you're looking at isn't well tested, running CodeQL or some other static analysis tool just to get started can be a productive use of time.

The new breed of AI SAST tools are pretty definitively more powerful than their basic static-analysis driven predecessors, and expand the scope of bugs you can quickly grep for. If you weren't using them befeore, it makes sense to reevaluate. Unfortunately however, a lot of security researchers are unaware of what these tools can do by default, or don't understand how to configure them for the code they're looking at. Here's how the ZeroPath team uses ZeroPath to find bugs in open source repositories.

Select Your Targets

First, target selection: ZeroPath isn't going to find you any WordPress 0days (yet). It helps to pick a popular but new repository on the github trending list. When the team is spelunking we usually look for web applications between 500 and 10000 github stars that have been updated in the last few months.

For this example we will use SuperAGI, an “Open-source framework to build, manage and run useful Autonomous AI Agents”

SuperAGI

Running Your First Scan

Before configuring any custom settings, it usually makes sense to run a basic scan so that you can see what kind of results ZeroPath will return for the repository by default. Among other import methods, ZeroPath lets you scan code at any live github URL, or upload a zip archive of the source manually. After the scan is complete, you can view the number of results and navigate to the issues page by clicking on our scan. Here were the results when we tried:

Many_Issues

Clearly, our tool did not report 65 independently high value exploitable bugs for the SuperAGI repo; most of these are going to be false positives. To help with triage, for each potential finding, ZeroPath will give you a natural language description, an explanation of what associated request handler, a description of the application the bug was found on, and a CVSS ranking with subscores determined by the AI.

superagi_partial

Additionally, you go to the explorer tab, you can also get a list of all code points in the application that receive external traffic. Even if you're not using the findings this can help with recon and giving you a sense of the app's surface area. In SuperAGI's case, this will show us all extant HTTP endpoints.

superagi_explorer

In our experience, looking at the first ten or so issues is sufficient to see if ZeroPath did well the first try.

Customizing ZeroPath's SAST

Sometimes ZeroPath will need some configuration; like if there are important details about the app that aren't available in the source. For example, let's say that for this application, I know that all the /intrnl/**/* endpoints are only exposed internally, and not to the wider internet.

With AI SAST tools, I can just explain this to the AI in my own words, by adding repo context. Then when I rescan, the AI will take into account that information when reporting security bugs.

repo_context

By phrasing instructions as contextual information, you can progressively narrow the scan results until the findings are excluded to the kinds of issues you want. For example, you can:

Tell the AI that certain inputs are sanitized by an external router.
Tell the AI that broken auth issues are out of scope for its assessment.
Tell the AI that a @foo decorator applies some filtering or authentication checks.

Additionally, you can also give the AI extra details to alert on. These are called "natural language rules" and when you specify them the AI will scan the code for the violations that you specify. For instance, you can ask it to look for any endpoint that's declared without a specific decorator attached:

custom_rule

Finding Real-World Security Vulnerabilities

During our review of the SuperAGI project, we found a legitimate Insecure Direct Object Reference (IDOR) vulnerability in the /get/{resource_id} route very quickly. The download_file_by_id function which this route serves would respond with files based on a user supplied resource_id, without performing any authorization checks on that resource_id for the user.

super_agi_idor

The actual finding from the scan is shown above, and you may notice the status is "patched". This is because we generated a security fix and submitted the PR to the SuperAGI maintainers, which got merged.

Detecting Business Logic Vulnerabilities

Particularly because up until now there has been no easy way to scan for these types of vulnerabilities, we've had a high success rate in finding business logic vulnerabilities across many apps. These issues traditionally require lots of manual labor to find, because there's no simple way to grep for them. In applications where there are hundreds or thousands of endpoints, having a human review each one for authorization and similar flaws is time consuming. Hopefully as AI SAST gets better this will be less and less the case.

Conclusion

Overall, AI SAST is not perfect, but we think it's currently a force multiplier for security research and will only keep improving overtime. It's helped us in both pentests and in security research to find issues that might have been overlooked or required a lot of manual effort to find. If you're a security researcher who utilizes SAST tools, we'd be happy if you gave ours a try and let us know how it does, especially repos it currently struggles on.

Happy hunting!