Mobile Application Security - Main Issues & Vulnerabilities

Infrastructure Vulnerabilities in Mobile Applications

The market for mobile applications is growing and more and more transactions are made on mobile devices. A variety from mobile payment systems is trying to attract the users and this creates a growing field for attackers to get into this systems and manipulate them.

Now, the shop webpages also have to work on various platforms and devices and special versions for each device are often created. This again gives attackers a big range of attack vectors.

There are mainly significant problems in the mobile application sector that is occuring mainly all time. The developers of the most mobile apps do not have the technical skills and experience to secure their applications. But this unsecure applications are provided for download at the big app stores. Thus affects finally the secure infrastructure of the mobile devices connected to shops like apple itunes, apple appstore, google app-store, open-market and windows market-place.

The publication control systems of these app-stores and market-places are proportinal low to the available safety risk that the manufacturer and vendor takes for the customer. As far as an attacker is able to compromise only one app, he can get control of the affected device. We saw that in the last 2 years by criminals and government acting agencies that try to evade the security concepts of the iOS product series at all instances. By watching the public sector you can see that there is a big need for criminals and government agencies to take control of mobile devices.

The main problem with application bugs is that they are produced by a third party to the manufacturer without correct responsibility. In case of a critical vulnerability the manufacturer (apple) does not care about the disclosure or risk. A researcher or coordinator has to get in contact with the developer (3rd party).

Normally the manufacturer of the product should take control about the notification and disclosure process because the products are running on there device finally. In such a case the apple product security team would like to say nothing and let the researcher interact with the developer. In 80% of the disclosed vulnerabilities in our mobile feed we got no reply by the developer which results in a full disclosure. Even after the release the manufacturer mostly would like to not become responsible for such bugs even if the customers are finally affected.

Facebook portal for example rushs to inform all application vedors about discovered bugs, even if they are created by a third party. Same should be done by manufacturer to secure the product line and grant that no backdoors or permanent exploitable security bugs are available over years. An adopting problem occurs very often when the same issues are as well adopted to several other mobile applications. Lets say there is a manufacturer programming a web interface for wifi. Now he used the webkit and java coding language with the available programming engines. In case of that there are often old packages to generate simply functions for iOS or there are wrong tutorials publicly available that teaches the young developer the wrong way of implementation. In a lot of test cases we found a UI that was programmed by one developer and shared to different parties for adopting the modules.

The vulnerabilities we mention are actual treads to the mobile app and shop security. There is a lot of work for security researcher to make this systems more secure, the vendors are in charge to build internal security teams or let external researchers test the systems. Because of the actual laws against hacking the independent research is very limited in looking for vulnerabilities on their own. Without the acceptance of the vendor its against the law to test a computer system for common bugs and vulnerabilities. But sadly many vendors do not have internal security teams or book external experts to secure their systems.

The image above shows an application-side input validation vulnerability and filter bypass issue in a bluetooth chat software of the apple mobile iOS. The attacker can send malicious messages to the victim via bluetooth protocol of the iOS device.

The picture above shows the same issue within another mobile application. The issue occurs in the same location of the application because of significant failure in validation procedure. The same module has been adopted to another software which results in a general security issue. In the next picture we can see a vulnerability that occurs because of the wrong encoding of the device name (c:id) value. The bug allows to use the name value of a stored code to trigger a persistent script code execution.

The same issue occurs also in the following code line of multiple other mobile apps with wifi interface. Reason is that apple does not prevent the device name because of allowing any char to rename it. Thus results in a permanent failure of validation in hundrets of application without knowledge of the third party developers.

Beginning of the year 2015 the core researchers of the vulnerability laboratory revealed a backdoor in the invoices of apple itunes & appstore when processing to buy a mobile web-application. The vulnerability was connected to the shop infrastructure, hardware settings and email configuration. The bug had an impact to compromise another users device or mobile applications. The last picture demonstrates how the code of the hardware has been used to the buy an app for final exploitation of the apple invoice.

The experience report shows the public researchers, agencies, whitehats and blackhats that there is no cooperation between the developers of a source, that runs on a specific embed device operating system and the manufacturer. This situation should change by time because the manufacturer of a product needs to be responsible also to third party products that are installed by the core services or stores. Finally the integrity and security protection of a product can only exist if the manufacturer covering all points of communcation.

Download: http://www.vulnerability-lab.com/get_content.php?id=1647

Reference(s):
http://www.vulnerability-lab.com/show.php?cat=mobile