# Vulnerability: Puffin Browser Server Side File Read Access for iOS
# Date: 30.04.2014
# Tested on: iOS 7.0.1
# CVE: No assigned yet
# Author: Marek Zmysłowski
# http://browser-shredders.blogspot.com
1. The Puffin Browser (paid version) processing some of the web content on the server side. The vulnerability exist when the "file:///" URL is processed incorrectly, revealing the content of the server side.
2. Proof of Concept
4. Fix
The issue has been fixed on the server side.
5. Timeline
30.04.2014 - vulnerability reported
01.05.2014 - fix
30.05.2014 - public disclosure
Monday, June 16, 2014
Thursday, June 12, 2014
Exploring and Exploiting iOS Web Browsers - part 1
After our Hack In The Box talk, I thought it would be a good idea to explain some of the slides in more detail. I am currently playing with iOS8 and WKWebViews, which solve a lot of issues, but not all of them. More on this soon - for now, let's stay on with UIWebViews.
UIWebView is the component used to load web content into iOS applications - basically it's Mobile Safari with the UI stripped off, leaving just the viewport part. Some of the differences:
1. UIWebView can only view a single document at a time (+ frames)
For example, links with target="_blank" will work as target="_top", and window.open() will work more or less the same as location.assign().
2. There is also no UI for error events
The user will not be asked for accepting invalid SSL certificate, will not be informed the connection to the given host failed, etc. However, JavaScript-initiated alerts and prompts are shown (and are not controllable through available API).
3. There is an API to control UIWebView content and behaviour
(By the way, you may want to take a look at this presentation from OWASP Poland meeting.)
Browsers using UIWebViews have to add the user interface - this means at least address bar and error handling. Usually to do this programmers implement UIWebViewDelegate methods:
webViewDidStartLoad:
webViewDidFinishLoad:
webView:didFailLoadWithError:
The last one causes problems usually. The most common issue is lack of address bar update within this method. This may allow an attacker to spoof the address bar by forcing some kind of an error. Apart from events like invalid SSL certificate, NXDOMAIN DNS response or simply response timeout, this method is also called when document.write() function interrupts page load or replaces loaded page.
Lack of address bar update on webView:didFailLoadWithError: was the reason for about a half of the address bar spoofing vulnerabilities we reported to browser authors. Most of the second half was due to updating address bar too early - as soon as the navigation was initiated, before the document actually started loading into UIWebView ("loading loop" from the HITB presentation is an example). By combining both techniques, an attacker can be almost sure the address bar will point to whatever she/he wishes.
See you in the next part soon.
UIWebView is the component used to load web content into iOS applications - basically it's Mobile Safari with the UI stripped off, leaving just the viewport part. Some of the differences:
1. UIWebView can only view a single document at a time (+ frames)
For example, links with target="_blank" will work as target="_top", and window.open() will work more or less the same as location.assign().
2. There is also no UI for error events
The user will not be asked for accepting invalid SSL certificate, will not be informed the connection to the given host failed, etc. However, JavaScript-initiated alerts and prompts are shown (and are not controllable through available API).
3. There is an API to control UIWebView content and behaviour
(By the way, you may want to take a look at this presentation from OWASP Poland meeting.)
Browsers using UIWebViews have to add the user interface - this means at least address bar and error handling. Usually to do this programmers implement UIWebViewDelegate methods:
webViewDidStartLoad:
webViewDidFinishLoad:
webView:didFailLoadWithError:
The last one causes problems usually. The most common issue is lack of address bar update within this method. This may allow an attacker to spoof the address bar by forcing some kind of an error. Apart from events like invalid SSL certificate, NXDOMAIN DNS response or simply response timeout, this method is also called when document.write() function interrupts page load or replaces loaded page.
Lack of address bar update on webView:didFailLoadWithError: was the reason for about a half of the address bar spoofing vulnerabilities we reported to browser authors. Most of the second half was due to updating address bar too early - as soon as the navigation was initiated, before the document actually started loading into UIWebView ("loading loop" from the HITB presentation is an example). By combining both techniques, an attacker can be almost sure the address bar will point to whatever she/he wishes.
See you in the next part soon.
Tuesday, June 10, 2014
Opera Coast SSL Man-in-the-Middle Vulnerability
# Vulnerability: Opera Coast SSL Man-in-the-Middle Vulenerability
# Software Link: https://itunes.apple.com/pl/app/opera-coast-web-browser/id674024845
# Vulnerable versions: 3.01 and earlier
# CVE: not yet assigned
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Opera Coast browser for iOS was vulnerable to man-in-the-middle attacks against SSL-protected web pages. The validation of the webpage certificate was performed for the domain of the main document only, skipping resources embedded from other domains.
2. Proof of Concept
https://ios.browsr-tests.com/alt/ssl.php
3. Fix
This specific issue was fixed in version 3.02.
Other potentially unfixed vectors may be related to the fact that for some cases of invalid SSL certificates for the main domain the user is alerted of an error, but the page content is still loaded in background (potentially accessing cookies or performing cache poisoning attacks). These vectors were not retested in detail.
4. Timeline
22.01.2014 - initial contact regarding SSL MITM in Coast (not this specific issue), received detailed response explaining why Opera does not consider it to be a bug
29.01.2014 - public disclosure on OWASP Poland meeting
11.03.2014 - second report with this specific issue presented (with paypal.com proof-of-concept), received immediate response confirming the bug
24.04.2014 - partially fixed version released
26.05.2014 - version 3.02 with final fix released
# Software Link: https://itunes.apple.com/pl/app/opera-coast-web-browser/id674024845
# Vulnerable versions: 3.01 and earlier
# CVE: not yet assigned
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Opera Coast browser for iOS was vulnerable to man-in-the-middle attacks against SSL-protected web pages. The validation of the webpage certificate was performed for the domain of the main document only, skipping resources embedded from other domains.
2. Proof of Concept
https://ios.browsr-tests.com/alt/ssl.php
3. Fix
This specific issue was fixed in version 3.02.
Other potentially unfixed vectors may be related to the fact that for some cases of invalid SSL certificates for the main domain the user is alerted of an error, but the page content is still loaded in background (potentially accessing cookies or performing cache poisoning attacks). These vectors were not retested in detail.
4. Timeline
22.01.2014 - initial contact regarding SSL MITM in Coast (not this specific issue), received detailed response explaining why Opera does not consider it to be a bug
29.01.2014 - public disclosure on OWASP Poland meeting
11.03.2014 - second report with this specific issue presented (with paypal.com proof-of-concept), received immediate response confirming the bug
24.04.2014 - partially fixed version released
26.05.2014 - version 3.02 with final fix released
[CVE-2014-1315] OSX Safari uncontrolled format string
This one is for OS X Safari, so not exactly in our main field of interest, but it's really funny:
<iframe src="lets-try-format-string:%p%p%p%p%p%p..."></iframe>
CoreServicesUIAgent responsible for the format string vulnerability was fixed in OS X Mavericks 10.9.2 (Mountain Lion and previous were not affected). Exploitability was not confirmed on our side, however Apple states that it could result in arbitrary code execution. Hats off to Erik Kooistra, who reported this vulnerability independently (before I did).
[CVE-2013-7197] Yandex.Browser for iOS - Universal Cross-Site Scripting
# Vulnerability: Yandex.Browser for iOS - Universal Cross-Site Scripting
# Software Link: https://itunes.apple.com/us/app/yandex.browser/id574939428
# Vulnerable versions: 13.11-13.12
# CVE: CVE-2013-7197
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Yandex.Browser for iOS was vulnerable to Universal Cross-Site Scripting attacks, allowing a webpage to execute JavaScript on any other webpage, requiring minimal user interaction.
2. Proof of Concept
<button onclick="w=window.open('redirect.php?http://example.com');setTimeout(function(){w.document.write('<script>alert(location)</script>')},5000);">Click</button>
3. Fix
This issue was fixed in version 14.02.
4. Timeline
14.12.2013 - initial contact, multiple issues reported
27.12.2013 - Yandex response, additional data provided proving the issue is in Yandex code and not in Apple's API
10.01.2014 - Yandex confirmation and bug bounty award
24.02.2014 - version 14.02 released
30.05.2014 - public disclosure
# Software Link: https://itunes.apple.com/us/app/yandex.browser/id574939428
# Vulnerable versions: 13.11-13.12
# CVE: CVE-2013-7197
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Yandex.Browser for iOS was vulnerable to Universal Cross-Site Scripting attacks, allowing a webpage to execute JavaScript on any other webpage, requiring minimal user interaction.
2. Proof of Concept
<button onclick="w=window.open('redirect.php?http://example.com');setTimeout(function(){w.document.write('<script>alert(location)</script>')},5000);">Click</button>
3. Fix
This issue was fixed in version 14.02.
4. Timeline
14.12.2013 - initial contact, multiple issues reported
27.12.2013 - Yandex response, additional data provided proving the issue is in Yandex code and not in Apple's API
10.01.2014 - Yandex confirmation and bug bounty award
24.02.2014 - version 14.02 released
30.05.2014 - public disclosure
[CVE-2013-6893] Mercury Browser for iOS - Universal Cross-Site Scripting
# Vulnerability: Mercury Browser for iOS - Universal Cross-Site Scripting
# Software Link: https://itunes.apple.com/pl/app/mercury-web-browser/id331012646
# Vulnerable versions: at least 8.1 and newer (not tested on previous versions)
# CVE: CVE-2013-6893
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Mercury Browser for iOS is vulnerable to Universal Cross-Site Scripting attacks, including the possibility to hijack passwords saved by the browser.
2. Proof of Concept
<button onclick="w=window.open('http://example.com');w.document.write('<script>alert(location)</script>');">Click</button>
3. Fix
No response from the vendor, no fix issued. The vulnerability is partially mitigated by popup blocker not allowing to open new tabs if the user does not whitelist target domain (bypassable with redirects).
4. Timeline
02.12.2013 - initial contact, no response
18.12.2013 - proof-of-concept for UXSS and password hijacking sent, no response
30.05.2014 - public disclosure
# Software Link: https://itunes.apple.com/pl/app/mercury-web-browser/id331012646
# Vulnerable versions: at least 8.1 and newer (not tested on previous versions)
# CVE: CVE-2013-6893
# Author: Lukasz Pilorz
# http://browser-shredders.blogspot.com
1. Vulnerability
Mercury Browser for iOS is vulnerable to Universal Cross-Site Scripting attacks, including the possibility to hijack passwords saved by the browser.
2. Proof of Concept
<button onclick="w=window.open('http://example.com');w.document.write('<script>alert(location)</script>');">Click</button>
3. Fix
No response from the vendor, no fix issued. The vulnerability is partially mitigated by popup blocker not allowing to open new tabs if the user does not whitelist target domain (bypassable with redirects).
4. Timeline
02.12.2013 - initial contact, no response
18.12.2013 - proof-of-concept for UXSS and password hijacking sent, no response
30.05.2014 - public disclosure
Thursday, May 15, 2014
Jailbreak Detection Methods
The purpose of this post is to summary methods used for iOS jailbreak detection.
All methods presented in this point can be easily detected (it is very easy to find appropriate string in the application) and can be very easily bypassed (simple file name change can bypass this detection).
/private/var/stash
/private/var/lib/apt
/private/var/tmp/cydia.log
/private/var/lib/cydia
/private/var/mobile/Library/SBSettings/Themes
/Library/MobileSubstrate/MobileSubstrate.dylib
/Library/MobileSubstrate/DynamicLibraries/Veency.plist
/Library/MobileSubstrate/DynamicLibraries/LiveClock.plist
/System/Library/LaunchDaemons/com.ikey.bbot.plist
/System/Library/LaunchDaemons/com.saurik.Cydia.Startup.plist
/var/cache/apt
/var/lib/apt
/var/lib/cydia
/var/log/syslog
/var/tmp/cydia.log
/bin/bash
/bin/sh
/usr/sbin/sshd
/usr/libexec/ssh-keysign
/usr/sbin/sshd
/usr/bin/sshd
/usr/libexec/sftp-server
/etc/ssh/sshd_config
/etc/apt
/Applications/Cydia.app
/Applications/RockApp.app
/Applications/Icy.app
/Applications/WinterBoard.app
/Applications/SBSettings.app
/Applications/MxTube.app
/Applications/IntelliScreen.app
/Applications/FakeCarrier.app
/Applications/blackra1n.app
The size of the file can be changed when new updates are installed.
/Library/Ringtones
/Library/Wallpaper
/usr/arm-apple-darwin9
/usr/include
/usr/libexec
/usr/share
/Applications
Appropriate implementation can be very difficult to detect and bypassed.
This method can be very time consuming (if ssh is not installed, the connection must be timeout). It is also very easy to bypass by changing the port for the OpenSSH service.
If calling the Cydia’s URL scheme (cydia://) from your application gives a success, you can be sure that the device is jailbroken.
1. Using the Filesystem
All methods presented in this point can be easily detected (it is very easy to find appropriate string in the application) and can be very easily bypassed (simple file name change can bypass this detection).
Existence of file
/private/var/stash
/private/var/lib/apt
/private/var/tmp/cydia.log
/private/var/lib/cydia
/private/var/mobile/Library/SBSettings/Themes
/Library/MobileSubstrate/MobileSubstrate.dylib
/Library/MobileSubstrate/DynamicLibraries/Veency.plist
/Library/MobileSubstrate/DynamicLibraries/LiveClock.plist
/System/Library/LaunchDaemons/com.ikey.bbot.plist
/System/Library/LaunchDaemons/com.saurik.Cydia.Startup.plist
/var/cache/apt
/var/lib/apt
/var/lib/cydia
/var/log/syslog
/var/tmp/cydia.log
/bin/bash
/bin/sh
/usr/sbin/sshd
/usr/libexec/ssh-keysign
/usr/sbin/sshd
/usr/bin/sshd
/usr/libexec/sftp-server
/etc/ssh/sshd_config
/etc/apt
/Applications/Cydia.app
/Applications/RockApp.app
/Applications/Icy.app
/Applications/WinterBoard.app
/Applications/SBSettings.app
/Applications/MxTube.app
/Applications/IntelliScreen.app
/Applications/FakeCarrier.app
/Applications/blackra1n.app
Size of /etc/fstab file
The size of the file can be changed when new updates are installed.
Read/Write permission to the root partition
Existence of symbolic links
/Library/Ringtones
/Library/Wallpaper
/usr/arm-apple-darwin9
/usr/include
/usr/libexec
/usr/share
/Applications
Directory permissions
Writing file
2. API Calls detection
Appropriate implementation can be very difficult to detect and bypassed.
fork()
system()
vm_protect() - obsolete
dyld functions
3. Services detection
The jailbroken device mainly runs some services. The can be check in order to detect if device is jailbroken.This method can be very time consuming (if ssh is not installed, the connection must be timeout). It is also very easy to bypass by changing the port for the OpenSSH service.
OpenSSH
4. Scheme detection
It is difficult to change scheme for the iOS however the Cydia can be removed during the testing process.Cydia
If calling the Cydia’s URL scheme (cydia://) from your application gives a success, you can be sure that the device is jailbroken.
5. Summary
The more complicated jailbreak detection is, the more difficult is to detect and bypass it. It is important not to create the detection runtime which returns true or false. It is very easy to locate this runtime and modify it.
Subscribe to:
Posts (Atom)

