Damn Vulnerable iOS Application - Mobile Security Research Labs | Mobile Security Research Labs

Damn Vulnerable iOS App (DVIA)
is an iOS application that is damn vulnerable. Its main goal is to
provide a platform to mobile security enthusiasts/professionals or
students to test their iOS penetration testing skills in a legal
environment. This application covers all the common vulnerabilities
found in iOS applications (following OWASP top 10 mobile risks) and
contains several challenges that the user can try. This application also
contains a section where a user can read various articles on iOS
application security. This project is developed and maintained by @prateekg147. The vulnerabilities and solutions covered in this app are tested upto iOS 7.0.4 .





Vulnerabilities and Challenges Include …

• Insecure Data Storage
• Jailbreak Detection
• Runtime Manipulation
• Transport Layer Security
• Client Side Injection
• Information Disclosure
• Broken Cryptography
• Security Decisions via Untrusted input
• Side channel data leakage
• Application Patching

All these vulnerabilities and their solutions have been tested up to iOS 7.0.4


The app also contains a section on iOS Application Security Tutorials
for those who want to learn iOS Application Pentesting. Every
challenge/vulnerability has a link for a tutorial that users can read to
learn more on that topic.


This app will only run on devices running iOS 7 or later. Users can
download the source code and run the application on previous versions of
iOS as well.


The app itself is free and can be downloaded from here but the solutions can be purchased for a cost of $19.



Damn Vulnerable iOS Application - Mobile Security Research Labs | Mobile Security Research Labs

Read More

Vulnerabilities in Android Update Make All Android Devices Vulnerable | Mobile Security Research Labs

Android upgrade mechanism brings to light a whole new set of
vulnerabilities pervasively existing in almost all Android versions,
which allow a seemingly harmless malicious app (“unprivileged app” in
the security term) running on a version of Android to automatically
acquire significant capabilities without users’ consent once they upgrade to newer versions!
Such capabilities include automatically obtaining all new permissions
added by the newer version OS, replacing system-level apps with
malicious ones, injecting malicious scripts into arbitrary webpages,
etc.

We call these vulnerabilities Pileup flaws (privilege escalation
through updating). In total, we discovered six Pileup flaws in the code
of Android OS. We further confirmed the
presence of the issues in all AOSP (Android Open Source Project)
versions and 3,522 source code versions customized by Samsung, LG and
HTC across the world. Those flaws affect all the Android devices
worldwide, posing serious threats to billions of Android users who are
actually encouraged to update their systems.


A distinctive feature of the threat is that the attack is not aimed at a vulnerability in the current system. Instead, it exploits the flaws in the updating mechanism of the “future” OS, which the current system will be upgraded to.
More specifically, through the app running on a lower version Android,
the adversary can strategically claim a set of carefully selected
privileges or attributes only available on the higher OS version. For
example, the app can define a new system permission such as
android.permission.READ_PROFILE (read the user’s personal profile data)
on Android 2.3.6, which is to be added on 4.0.x. It can also use the
shared user ID (UID) (a string specified within an app’s manifest file)
of a new system app on 4.0.x, its package name and other attributes.
Since these privileges and attributes do not exist in the old system
(2.3.6 in the example), the malicious app can silently acquire them
(self-defined permission, shared UID and package name, etc.). When the
system is being updated to the new one, the Pileup flaws within the new
Package Manager will be automatically exploited. Consequently, such an
app can stealthily obtain related system privileges, resources or
capabilities. In the above example, once the phone is upgraded to 4.0.x,
the app immediately gets android.permission.READ_PROFILE without the
user’s consent and even becomes its owner, capable of setting its
protection level and description. Also, the preempted shared UID enables
the malicious app to substitute for system apps such as Google
Calendar, and the package name trick was found to work on the Android
browser, allowing the malicious app to contaminate its cookies, cache,
security configurations and bookmarks, etc.


The consequences of the attacks are dire, depending on the exploit opportunities on different Android devices,
that is, the natures of the new resources on the target version of an
update. As examples, on various versions of Android, an upgrade allows
the unprivileged malware to get the permissions for accessing
voicemails, user credentials, call logs, notifications of other apps,
sending SMS, starting any activity regardless of permission protection
or export state, etc.; the malware can also gain complete control of new
signature and system permissions, lowering their protection levels to
“normal” and arbitrarily changing their descriptions that the user needs
to read when deciding on whether to grant them to an app; it can even
replace the official Google Calendar app with a malicious one to get the
phone user’s events, drop Javascript code in the data directory to be
used by the new Android browser so as to steal the user’s sensitive
data, or prevent her from installing critical system apps such as Google
Play Services. We performed a measurement on those exploit
opportunities, which shows how they are distributed across Android
versions and vendors. Figure 1 compares the average numbers of the
exploit opportunities provided by AOSP, Google and Samsung, when the
system is upgraded from 2.3.X to 4.0.X, then to 4.1.X, 4.2.X, 4.3.X and
4.4.X consecutively. As we can see from the figure, not only do the
manufacturers introduce more opportunities than AOSP, but Samsung adds
more than Google. Also interestingly, though Google and AOSP apparently
make the biggest system overhaul from 2.3.X to 4.0.X and show a trend of
less aggressive updating afterwards, Samsung continues to bring in more
new stuffs from 4.1.X to 4.2.X and to 4.3.X, at the cost of increased
security risks.

Go to top

Vulnerabilities in Android Update Make All Android Devices Vulnerable | Mobile Security Research Labs

Read More

mSeclabs - Smartphones at risk of malicious code injection through HTML5-based apps | Mobile Security Research Labs

Only a fraction of mobile apps are currently written in HTML5 – but
if 50 percent of applications are written in the markup language by
2016, as experts predict, then a whole lot of smartphones could soon be
at risk of a new Cross-Device Scripting (XDS) attack that researchers
have been investigating.

In the paper, “XDS: Cross-Device Scripting Attacks on Smartphones through HTML5-based Apps,”
Xing Jin, Tongbo Luo, Derek G. Tsui, and Wenliang Du, researchers with
Syracuse University, explore how anyone running vulnerable HTML5-based
apps on their smartphones – including iPhones, Blackberry’s and
Android-based devices – is at risk of malicious code injection.


Attackers can inject the malicious code through a number of different
commonly used channels, including Wi-Fi scanning, SMS messaging,
scanning of 2D barcodes, Bluetooth pairing, and even through the playing
of MP3 audio or MP4 videos, Du told SCMagazine.com on Monday.


So, if a compromised 2D barcode was scanned using an HTML5-based app,
then that app would be compromised. However, playing a compromised MP3
file in an app running in the device’s native programming language –
Android-based devices use JavaScript and iOS devices use Objective-C –
would result in no compromise.


The injection via Wi-Fi scanning is particularly interesting because
it does not require a user to connect to the attacker’s network, just to
locate it using a vulnerable HTML5-based app, Du said, explaining an
attacker can circumvent the 32 byte length limitation and inject more
effective malicious code by using multiple Wi-Fi access points.


Another particularly nasty element to the attack is that it will send
malicious code to contacts via SMS if granted access to a user’s
address book, Du said, explaining that any of those contacts running an
HTML5-based SMS app will become at risk of being compromised.


After injecting the malicious code, an attacker has access to just
about anything the compromised mobile application has access to, Du
said. Right now that may really only include access to SMS messages,
location data and address books, given the HTML5-based apps currently in
use, but that is bound to change as the programming language is more
widely adopted.


“HTML5 allows [developers] to write one version of code that can be
used across platforms,” Du said, explaining that the time-saving
technology has already proven attractive to developers and is being
taught in schools. “Today [it may not be as] relevant, but two years
from now, if many people have these kinds of [HTML5-based] apps, it’s
likely that this will spread, and that’s where the problems will come.”


Du could not reveal the name of one vulnerable app that he said has
been downloaded by more than a million users, but he explained that his
team has alerted the app developer of the HTML5 issues and that the
company is exploring a fix.


Meanwhile, the Syracuse University researchers are also still
exploring ways to mitigate this threat, Du said, but as of now, he
suggested using one of the safer application programming interfaces
(API) listed in the research as a good start.


Download the advisory : XDS attacks  Advisory by Syracuse University  Research Team





mSeclabs - Smartphones at risk of malicious code injection through HTML5-based apps | Mobile Security Research Labs

Read More