https://n0psn0ps.github.io/

This is another series on android reverse engineering. In this series I will be going through num1r0’s crackme’s and give detailed steps on how I solved these challenges. The first crack me is crackme_0x01. Though these crackmes are a bit older, they offer useful guidance on how to look at an android apk and begin doing some basic reverse engineering on an application. 

The apk can be pulled down from github and examined using any apk decompiling tool. I prefer to use jadx-gui. Opening the apk I first examine the AndroidManifest.xml file for any useful hints as to what I might be looking for. 

Defined in the code above I can see that the application has a single activity. Called MainActivity with an intent that supplies an action MAIN and category LAUNCHER. Opening the MainActivity class we can see the main onCreate and onClick methods. 

The onCreate method from lines 20 – 29 is what builds our main activity to submit the user defined password. This allows the user to submit any string for the password only once the Button tied to the onClickListener is clicked on line 29. Once clicked this will evaluate the editTest string on line 27 submitted by the user to the value of the getFlag method in the FlagGuard class. 

Once the correct password is submitted the if statement will execute the FlagGuard class and decodes the hard coded flag. Sending a message dialogue to the user with the flag.

The FlagGuard class runs a series of if else statements to evaluate the scrambled string using an index from a-z to evaluate the array charArray. What is particularly interesting is that the private String unscramble uses the log.e method. Logging the letter and FLAG of the application which can be obtained via adb’s logcat functionality. 

Furthermore we can see that the public string getFlag evaluates the str string from the application MainActivity class with the private string getData Data class on lines 10 – 13. If the password is correct the application will jump to the private String unscramble and begin executing the code. 

If we inspect the Data class we can see an interesting plaintext string stored in the application. 

This appears to be the application’s password to obtain the flag. Lets type the password in the prompt and see if it gives us the flag.

Alright this looks like the solution. I hope you enjoyed the first crackme from num1r0. Look out for my anothr blog post in the series on cracking the second one.

One major flaw in mobile testing is the use of insecure logging. Often developers will use log methods to trace code for debugging purposes. Sometimes this can include sensitive data like usernames and passwords, and as applications go from the development phase into production the code can make its way into production mobile applications. 

In this example we can see that Insecure Shop makes use of the log.d method or the Log Debug Android API. Do take some time to overview the common use of the logging methods. It can help with understanding each of their intended uses.

In the last part of the blog series we took some time to examine the LoginActivity class. We observed that the class took in the username and password of the application user. This specific class also has a log method flaw built into the code. As we can see in the example code below. The highlight red text identifies the user of log.d or the debugging log Android API call. 

We can see that the username and password are logged into the application logs and can be retrieved in real time. This can be a major risk for any user who may be using an application and if their phone is stolen. Sensitive data can be pulled from the log files on the phone and used to further an attack against the user’s device. 

Logcat is a useful tool built into adb. It allows for monitoring and even storing logs of an application on an Android device. Often used in mobile penetration tests as part of the dynamic analysis part of the application test. The tester can observe all the actions happening on the device that may be logged. 

Using the command below let’s start adb and log into the Insecure Shop application the device:

adb logcat > log.txt

I like to make use of the standard redirect command to create a log.txt file. This helps me parse the logs to locate any sensitive user data. 

Below we can see the sensitive data stored in the logs of the android application that we submitted in the prior blog post. This includes the fake credentials used in the boolean bypass and the default username and password. 

Remediation

It is advised to remove code that could log sensitive information in a mobile application. Especially if that application is in production. As we saw in this post, user credentials are stored directly into the log file.

One common mobile application vulnerability is the use of hardcoded credentials, API keys, or application functions such as backdoors or undocumented API requests. In my own vulnerability testing I have found various API keys coded into applications that allow for use of APIs outside the scope of their intended purpose. In this blog post I would like to go over some methods used to locate such issues using InsecureShop. I will not be detailing how to jailbreak, root, or bypass ssl pinning for applications please see Google for such resources. 

First you will need to pull the application from the android device using adb. Once pulled from the device use the following apktool command below to decompile the apk and begin the reverse engineering process.

apktool d base.apk -o dis-insecureshop

Nuclei

Nuclei has a great set of template developed for the purpose of scanning decompile apks for keys, databases, and various activity related vulnerabilities. 

Once you have decompiled the apk you can then run nuclei against the directory created via the -o flag. 

Often developers will leave API keys or any other hardcoded secrets in the /res/values/strings.xml file. So it is a common location to check for various hardcoded values. 

Jadx-gui 

Jadx-gui is the swiss army knife of any android mobile penetration tester. In a nutshell this tool will convert the Davlik code to Java which allows for easier source code review. In this section of the post I would like to go over how to locate the hardcoded credentials. 

Under the AndroidManifest.xml file we can see an activity with a class named LoginActivity which is highlighted in red.

Navigating to the LoginActivity class we can see that a few conditions are met against the username and password variables submitted by the user. As we can see in the screenshot below on line 43.

An if statement compares the Util class verifyUserNamePassword method as seen in the Util class on lines 12 and 18. 

But the hardcoded credentials are stored in clear text on line 14. Using this username and password combination we can login into the InsecureShop application.

Objection

Objection is another powerful tool that I use as part of my methodology for mobile pentesting. This tool is powered by frida for real time hooking of an android or iOS application. 

In this exercise we are going to bypass a boolean class built into the verifyUserNamePassword method called by the Util class. We can use this to bypass the login authorization and load directly into the InsecureShop app. Refer to line 18 of the prior screenshot which sets a boolean operation. 

First off we will load the gadget into objection and begin exploring the underlying classes and methods for our attack path.

Once we have objection hooked onto the InsecureShop app we will want to dump all the classes of the application and begin exploring the methods.

Now that we have identified all 39 classes we can see we have a class titled Util at the very bottom. Now let’s list all the class methods using objection. 

As we can see there is a method that takes a boolean value to compare the LoginActivity values username and password. This method is called verifyUserNamePassword. Let now set the value to true and attempt to login to the application. 

Now we can login to the application with any username or password combination.

Remediation 

Do not set hardcoded credentials or sensitive data in source code. It is very easy for attackers to gain access to the base apk of your application and reverse engineer the code. 

https://cwe.mitre.org/data/definitions/798.html

Below are public reports disclosed via HackerOne related to this issue.

https://hackerone.com/reports/412772

https://hackerone.com/reports/753868

https://hackerone.com/reports/792850

First off I would like to go over what is slowly becoming one of my new favorite attack vectors on a web application. James Kettle, a researcher with BurpSuite, found an amazing webapp vulnerability called Server Side Template Injection or SSTI for short. His definition is brief but concise in the nature of how Template Injection arises:

“This vulnerability typically arises through developers intentionally letting users submit or edit templates – some template engines offer a secure mode for this express purpose. It is far from specific to marketing applications – any features that support advanced user-supplied markup may be vulnerable, including wiki-pages, reviews, and even comments. Template injection can also arise by accident, when user input is simply concatenated directly into a template.”

https://portswigger.net/research/server-side-template-injection

He also did an amazing talk at Black Hat detailing this vulnerability in depth with proof of concept demos. Plus a detailed white paper going into the findings of this vulnerability. 

In short there are many template engine frameworks that are vulnerable to this attack. FreeMarker, Twig, Velocity, Thymelead, Smarty, Spring View, ERB, Jade, Tornado, and Handlebars. There is rich documentation on how to exploit all the frameworks on the internet. I will offer some resources at the end. 

Firstly, we need to find an application with a vulnerable template engine. I will be using the PortSwigger example page with the vulnerable engine. We need to identify the location of this engine and then identify the correct version based on this flow chart.

Using the curly brackets and a numeral mathematical operation we can begin to iterate through the series of possible IDs for our vulnerable app. I will start with the operation below:

{{7*7}}

Then hit the preview button we see that our numeral operation did not succeed. 

Based on this we will make the necessary changes and proceed. We will then try to use this operation:

{7*7}

And again we see it is still a failure. So we have currently enumerated that it is neither a Twig or Jinja2 framework. So let’s add a dollar sign to our code injection and see if we can ID the framework further.

We get a solution to our operation. 

Let’s dig a bit further and see if this success can give us a possible framework ID. Adding single quotes to the second 7 gives us an error or blank screen.

Which in this case based off our enumeration is a FreeMarker engine template. So let’s dig around and see if we can use a known RCE to explore the server a big further. We will use the code below to run commands on the system and see if we can find anything interesting.

<#assign ex=”freemarker.template.utility.Execute”?new()> ${ ex(“command_here “) }

I would like to understand who the running user is, what os is running on the machine, locate the passwd file, and then finish our objective on the target server.

<#assign ex=”freemarker.template.utility.Execute”?new()> ${ ex(“whoami”) }

The underlying user is Carlos

<#assign ex=”freemarker.template.utility.Execute”?new()> ${ ex(“uname -a”) }

The OS is Linux running on Amazon Cloud.

<#assign ex=”freemarker.template.utility.Execute”?new()> ${ ex(“cat /etc/passwd”) }

<#assign ex=”freemarker.template.utility.Execute”?new()> ${ ex(“rm /home/carlos/morale.txt”) }

SSTI Mitigations

Again I would like to quote James Kettle here due to the thorough understanding on how to safely protect against these attacks:

“If user-supplied templates are a business requirement, how should they be implemented? We have already seen that regexes are not an effective defense, and parser-level sandboxes are error prone. The lowest risk approach is to simply use a trivial template engine such as Mustache, or Python’s Template. MediaWiki has taken the approach of executing users’ code using a sandboxed Lua environment where potentially dangerous modules and functions have been outright removed. This strategy appears to have held up well, given the lack of people compromising Wikipedia. In languages such as Ruby it may be possible to emulate this approach using monkey-patching.

Another, complementary approach is to concede that arbitrary code execution is inevitable and sandbox it inside a locked-down Docker container. Through the use of capability-dropping, read-only filesystems, and kernel hardening it is possible to craft a ‘safe’ environment that is difficult to escape from.”

Additional Resources

https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection
https://github.com/DiogoMRSilva/websitesVulnerableToSSTI

Broken Access Control is one the OWASP top 10. Access control can be defined as an application’s ability to give or take away access to certain types of credentials or data based on the authorization of users. Say for example we have a banking application that allows access to alice’s personal banking information and her account is declared with the id=321. And bob has the id=322 and alice can manipulate the id such that is the numeral 1 is replace with 2 and the application improperly applies the necessary controls then alice could view bobs account information. This is a simple use case with wider implications. 

The impacts can vary from leaked user data like account info above, horizontal or vertical privilege escalation from a low privilege user to admin, logic flaws to manipulate cart transactions, path traversal and RFI.

IDOR

I would like to go over 3 quick examples. The first being IDOR or Insecure Direct Object Reference. Which I have briefly touched on before on my blog. But in short IDOR is a vulnerability in which a user manipulates code and in return is supplied data from an application directly. In this example we will be using DVWS Node. This application has a note taking functionality that can be manipulated to access notes via the GET request that is called to the API. 

We have generated a few notes for our testing purpose. After generating the note and firing up our proxy BurpSuite we captured the requests and started playing around with the application. Notice the Update button, after clicking the button we get an interesting request we can use to manipulate the web application.

We can then manipulate this portion of the get request:

/api/v2/notes/

By adding a 0, 1 or 2 to the end. Which will dump the contents of the notes endpoint of the API. 

/api/v2/notes/0 or /api/v2/notes/1

What is super important in this attack is that we are manipulating the id parameter. To glean useful or relevant information about the contents of the notes. 

Obviously this is a simple attack, but depending on the context it can be incredibly devastating. Maybe the information accessed is actually critical to the upkeep and maintenance of the company or server.

Vertical Privilege Escalation

In the context of access control vulnerabilities vertical privilege escalation is when a user is allowed some functionality that is not otherwise granted to them. So for example say Alice is a normal everyday user but is able to manipulate a portion of the application request to elevated her privilege to delete or modify another user. This is probably one of the more severe attacks due to the ability to fully compromise an application and wreak havoc. 

The PortSwigger website has an amazing series of web application based testing exercises. All focused on the OWASP top 10 and very great for beginners. I will quickly just touch on a small but easy exercise demonstrating the concept of vertical privilege escalation.

In one of the exercises there is a web store with different users and functionalities for each user. The objective is to find the admin panel, browse to the admin panel and then delete the user carlos. So first we need to locate the main page and view the source code. Scrolling through the code we locate a JS script. With our admin panel directory:

/admin-f8pyuv

Taking this and adding to the end of our url we are able to access the admin panel below.

Once in we now have full control of the admin panel and can manipulate aspects of the web application. 

Path Traversal

Is a vulnerability in which information or data on an underlying servers directory structure is accessed due to misconfigured permissions. So for example a .php file is called directly from the URL of a server and displayed by the user if permissions are incorrectly set a user can browse the /etc/passwd file.

For this example I am going to use DVWA to show how this vulnerability can occur. Setting the security level to low and browsing to the file inclusion section.

We will manipulate the application in our proxy. By changing the URL path to our .php file from include.php to /etc/passwd

Whatever way you desire to do this you can do it inline in the URL or via a web proxy. I prefer the web proxy since I can use the Repeater tab to change and configure data on the fly. 

Digging into the code we can see the code is calling directly to the page and not filtering out user supplied input to the applications underlying server via the PHP get method. 

Now that we have broken down some examples of broken access control let’s dive into some steps for remediation. 

Mitigations

For remediation of access control issues there are quite a few things you can implement into the architecture of your web application. I will go over a few that are detailed in the OWASP cheat sheet linked below. If you want a full description of how to do check out the links below.

• Role Based Access Control: access decisions in which the roles and responsibilities are defined by the users function.
•  Discretionary Access Control: restrictions based on the id of a user or membership within a group/s. So this can be credential separation like a low privilege user and admin need to perform different actions.
•  Mandatory Access Control: information is accessed based on the sensitivity, so a need to know basis, admin only has grants access.
• Permission Based Access Control: decision is based on whether or not that user has permission associated with that information or content.

https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls

https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html

My second Vulnerable VM nameSpaceS0S is live on VulnHub.
https://www.vulnhub.com/entry/namespaces0s-1,584/

Today’s post will be focusing on different attacks on the XXELab. First, let’s define XXE, what it is, and how it presents itself on a web application. XXE stands for XML External Entity attack and any application that parses XML input may be vulnerable to this type of attack, especially if it parses data without filtering input from the user. This attack can lead to sensitive server side information being disclosed like user password files, logs, software versions, and remote code execution allowing a full compromise of the machine. XXE takes advantage of an entity, an entity is a storage unit of some type. The entity is declared as a system identifier which can then be called within an XML document. Now let’s move onto the XXELabs exercises. 

The Lab

If you have not heard of XXELabs it is an amazing project it is a simple webapp with an XXE vulnerability. You will need a proxy to play with this setup project like BurpSuite or ZAP. I will not go over the installation setup for the proxy or the lab since there are many other websites that detail this. Plus the XXELabs has an amazing setup guide on their GitHub. 

This is the user interface for our vulnerable XML web application. Now let’s fill in the form, capture the request, and attack. 

The Methods

Let’s talk about different XXE methods first. There are a few and I won’t detail the DOS attacks since I am mostly interested in exploiting and exfiltrating data to be used in testing applications in the wild. Since this is where the biggest risk lies for any company. DOS can be a nuisance but it does have its uses for leveraging into a system further and compromising other aspects of the network. 

The 3 types of attacks we will cover in this 2 part series are accessing a local resource, remote code execution, and then in part two we will go over external URL commands using the HTTP module. 

Module Types

When exploiting XML we have a few commonly used modules types we will be using to exploit our victim machines. Most often we will use file: http/s: expect: all will retrieve useful data from the server to the attacking machine. 

The Basics: A string to /etc/passwd

A basic XML response will look something like this the XML parser is executing code onto the remote server. Inside of the POST response we can see we get a call for XML version 1.0. 

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

The XML form below gives us different parameters to inject our code into using the registration form. With fields such as name, telephone number, email address, and password. 

Now lets begin to craft a bit of malicious XML code into our registration form. We will begin by calling a Document Type Definition which defines the document with a list of valid elements and attributes. This is where we will be leveraging our attack.

In this example we will start with a basic “Hello world” attack. By placing the world into an attribute called bar. Calling is in our XML code below with &bar; in the email parameter.

Once we have verified this attack we will move onto placing and expect://id module into the XML code. So moving from a string to an exfiltration attack to gain knowledge about the underlying system. 

Our new code should look something like this:

<!DOCTYPE foo

  [<!ELEMENT foo ANY >

   <!ENTITY xxe SYSTEM “expect://id” >]>

We will be calling the SYSTEM and the expect id of the user who has control over the application. After modifying out code we get the output of the user www-data. 

And then changing the n0ps@email.com with our new attribute. 

Now that we have gone from a simple string replacement to identifying the id of the web application user we will modify our exploit to gain some interesting output about the underlying system. Taking the same code we had from before we will modify it slightly to look like this:

<!DOCTYPE foo [

  <!ELEMENT foo ANY >

  <!ENTITY xxe SYSTEM “file:///etc/passwd” >]>

Run our code in the BurpSuite repeater tab and we should see the output of /etc/passwd file.

In the next article I will show you how to go from XXE to RCE and other fun little tricks in the XXELab. Plus some mitigation techniques!

I have been spending the last few weeks building and deploying vulnerable VMs locally on my machine. Today I happened upon a new CVE Privilege Escalation developed by Arnauec. This takes advantage of “A flaw… found in the Linux kernel before 5.9-rc4. Memory corruption can be exploited to gain root privileges from unprivileged processes. The highest threat from this vulnerability is to data confidentiality and integrity.”
POC code by Arnauec

This is my first vulnerable virtual machine called fishymail. You can download it here load the .vdi up on VirtualBox and give it a try. Feel free to contact me or leave a comment if you have any questions or need some help troubleshooting.