Tag Archives: Mobile

Mobile-Security-Attacks

Mobile Security Attacks – A Glimpse from the Trenches (OWASP AppSec USA 2014 Preo Review)

AppSecUSA.2014At the recent OWASP AppSecUSA in Denver, Yair Amit and Adi Sharabani of Skycure presented a very informative overview of mobile security issues. There was a great deal of good material in this presentation, packed into a short period of time.

The presenters divided the attacks into four overlapping areas:

  • Physical Security
  • Network
  • Application Security & Privacy
  • Malware

Physical Layer

The problem here is obvious: the device is lost or stolen, or temporarily accessed by a non-authorized user. In these cases, the responsibility has fallen on the OS for protection. With stolen devices in particular, the opportunities for controlling loss are greatly reduced, as the thief will intentionally disable internet access, which is required for many of those protective mechanisms to work.

Network Attacks

The presenters estimate that 10% of “scanned networks” (presumably wifi) pose some sort of threat, and that the likelihood of encountering such a network is 40% over a period of four months, with that number increasing with time. They have even put together a real-time mapping of network threats: https://maps.skycure.com/ (Just for fun, I recently entered Los Angeles into the app, and it identified a half dozen clustered in east LA, and one in South Central. Central LA seemed clear, but there were some other threats in Beverly Hills and Westwood. Your mileage may vary.) For more information: https://www.skycure.com/blog/mapping-global-security-threat-landscape/

Network Security Implementation Issues

Two network layer implementation issues affecting mobile devices were reviewed: the gotofail bug in iOS, and Heartbleed in Android. The presenters briefly contrasted the updating mechanisms for the two platforms. The good news for iOS is that gotofail could be easily fixed and updated on affected devices, as iOS is a single platform that is updated by the vast majority of users in short order. The less good news for Android is that updating is more difficult due to platform fragmentation. Since Heartbleed is really more of a server concern and is hard to exploit on a device, the lack of updatability was not too troubling in this case.

Network Security General Design Issues

This portion of the presentation focused on design issues of the more general “protocol” varieties (i.e. not mobile device specific).

sslstrip

The first design flaw examined was the five year old sslstrip vulnerability. The solution, HSTS, is only present on newer browsers. Older devices have older browsers (presumably especially on harder-to-update Android) that do not support HSTS. In terms of how to address the problem, the difference between this design issue and the implementation bugs above is (presumably) that a server modification is necessary in addition to the device update.

“SSL Decryption”

“SSL decryption” was the second general design issue discussed. By this, the presenters are referring to a man-in-the-middle SSL certificate attack. While this is a general issue and not mobile-specific, the presenters nevertheless focused on the dialog that pops up on iOS devices when there are SSL certificate problems. This dialog allows the user to either cancel or continue with the connection. Of course, “continue” is the wrong choice as it may indicate a man-in-the-middle attack, but they have found that 92% of users choose to continue.

They also suspect that the percentage rises with repetition of the dialog, due to the annoyance (if “cancel” means I keep getting the dialog, then…). If a user clicks “continue” not when loading a web page, but due to a problem communicating with an Exchange server, then credentials are compromised. This can lead to even further compromise, e.g. other accounts by resetting passwords, changing contacts with new phone numbers, etc.

My Ten Agorot (or two cents, hey, the presenters are Israeli…)

The presenters did not describe how this SSL certificate problem is handled on Android, which would have been interesting to hear. Neither did the presenters explore possible solutions to this problem, such as future versions of mobile OS that might have a setting to automatically always disallow certificate mismatches.

Karma

The third general design vulnerability is the Karma wifi auto-connect attack.

My Two Cents

This warranted only a brief mention with practically no discussion at all. Probably the omission was due to time, as there has been a lot of content disseminated on this already, and more recent mobile OS versions have been updated to prevent the attack from working. For more information, see it in action using our favorite hacking device, the WiFi Pinapple (https://scotthelme.co.uk/wifi-pineapple-karma-sslstrip/)

Network Security Mobile Design Issues

iOS Configuration Profiles

The combination of having one app store with a lot of screening and the sandbox model do make iOS a relatively secure platform. However, there is a rather significant attack vector available for iOS: “configuration profiles.” These are XML files that allow IT departments to configure iOS devices for specific network purposes. They are very powerful, affecting the entire device, and they bypass all of the aforementioned security mechanisms, making them attractive not only for legitimate use, but also for attackers. They can do some potentially very nasty things, such as redirect traffic and install root certificates! And all it takes is a tap by the user. A web site can be crafted to make such an attack look entirely legitimate, when in fact a Trojan is what is being offered. The presenters put together an example configuration profile attack that worked as a key logger as well as a device keyboard controller. It looks like complete control of the device may be possible including launching and controlling apps!

These attacks do exist in the wild, and they are aware of cases where even legitimate configuration profiles were somehow hijacked by malicious actors. Further, some of the attacks are then spread virally, by sending messages through email and social networking to the victim’s contacts to entice them to also install the malicious configuration profile. For more information: https://www.skycure.com/blog/malicious-profiles-from-theory-into-reality/

My Two Cents

This part of the presentation held particular interest for me. When I was at DEFCON earlier this year, I noticed that the conference wifi was provided for iOS devices by means of a configuration profile. Even though I knew nothing about them at the time, it struck me as a risky proposition to install something like this. I demurred, and while I’m sure it was safe enough, I ultimately decided to stick to the cellular network as a (probably) safer option. It was gratifying to see my concerns about configuration profiles validated.

WiFiGate

Going back to the Karma attack, mobile device carriers may install pre-defined wifi settings that will result in a device automatically connecting to certain wifi networks, right out of the box. These settings are not user-modifiable, and the devices are vulnerable to a Karma-like attack without the user having to take affirmative steps to connect to anything at all. For more information: https://www.skycure.com/blog/wifigate-how-mobile-carriers-expose-us-to-wi-fi-attacks/

Application Security

As a software engineer in the field of web application scanning, my greatest interest is most clearly in this category, which they characterize as an “emerging threat.”

My Two Cents

Whether they mean mobile web applications or installed mobile applications, this threat has clearly already emerged. Web applications generally have been a primary point of attack since the early 2000’s. Now, installable mobile applications are rapidly being released. What’s worse about these new applications is that they utilize newer technologies, and neither the developer nor security teams have the same experience testing them, nor the tools to do so. So, the risk associated with mobile applications is of great concern. Gartner predicts that through 2015, more than 75% of mobile applications will fail basic security tests. (Gartner Application Security Magic Quadrant, 2014)

Most global enterprises and large organizations have well-established application security programs to detect and resolve application security issues. While we are used to thinking of this as primarily a browser presentation issue, the mobile dimension will increase over time. Some of the “old” vulnerabilities (such as SQL injection) can show up in the web service back-ends for mobile applications. For more on current application security threats and trends, visit www.ntobjectives.com.

Plain HTTP

Non-encrypted traffic is still a used by some mobile applications (amazingly). No further elaboration is necessary.

Certificate Pinning

Mobile applications can and should be pinned to a specific certificate to work, but according to the presenters, few apps do this, even major ones. This is an astounding security hole, but the poor rate of use is due to pinning being difficult to implement correctly. Specifically, if a certificate must change, due to expiration or compromise, some mechanism must be provided to update the client app.

HTTP Request Hijacking

In an untrusted environment, a man-in-the-middle issues a persistent redirect (301) to a malicious server. This has a permanent effect even when back on a safe network, with the app still contacting the malicious server pointed to by the redirect. This is a cleverly sneaky attack that I will enjoy testing on several apps.

Malware

Malicious apps have been more of a problem with Android than with iOS. The “year of Android malware” was 2011, countered by “Bouncer” a year later. Then malware went to other external stores, followed by a focus on “verified apps,” moving Android closer to the iOS security model. Thus malicious applications now are becoming sneakier. The best example given was asking for all keystrokes in exchange for better services! This is possible on Android and iOS 8 with installable keyboards.

NTOBJECTives Relevance

Almost everything in this presentation focused on the client side of the mobile security equation. This is a natural and typical focus for mobile security. But the traffic between a mobile application and a server can be just as vulnerable, and more damaging if breached, to the server side of the equation than to the device side. NTOSpider can be used to scan such sites and web services for vulnerabilities. For example, one of the issues in this presentation touches on server side behavior beyond simply the general use of SSL/TLS: the use of HSTS for preventing the sslstrip attack. NTOSpider detects this header and reports on the lack of its use in conjunction with HTTPS.

For more information on mobile applications and web application scanning see the following content at www.ntobjectives.com:

Mobile Apps

How to Overcome the Shortfalls of Web Application Security Scanners when Testing Mobile & Rich Internet Applications

Mobile AppsYou’ve built a custom rich internet application that is sure to become your business’ next major revenue stream. Conscious of security, you’ve ensured that the native application authenticates to the server, and you’ve run the app through a web application security scanner to identify weaknesses in the code. Those vulnerabilities have been remediated, and now you’re ready to go live.

Not so fast.

Despite your best intentions, chances are good your rich internet application is going live with dangerous security flaws. Most traditional web application security scanners and authentication methods do not provide the necessary protection when you’re dealing with modern application architectures, data formats and other underlying technologies. However, you can still build state-of-the-art rich internet applications with reliable and safe web application security by following these simple steps.

Step 1: Understand your chosen technology and its security requirements.

Classic HTML applications are no challenge for web application security scanners because that’s what they were originally built to do. However, rich internet applications based on newer technologies like AJAX, JSON and REST are a different story –,most security scanners do not support these new formats unless they’ve been re-architected. Due to the heavy use of JavaScript or complete lack of HTML, these new application formats and technologies make it nearly impossible for scanners to crawl an app. Plus, mobile applications further complicate matters because they often use web services which cannot be crawled at all.

To make matters worse, attackers are finding new ways to exploit application programming interfaces (APIs) associated with mobile applications. Web application session management techniques fail to deliver the protection developers expect, and these old and insecure techniques do not stop attackers from tampering with the application, committing fraud or performing man-in-the-middle attacks.

Therefore, it is important to understand the technologies used in your rich internet applications so you can find an appropriate web application security scanner and/or supplement your scanning efforts accordingly. Below is a list of the technologies that may require a more in-depth security solution:

  • AJAX applications: JSON (JQuery), REST, GWT (Google WebToolkit)
  • Flash remoting: Action Message Format (AMF)
  • HTML5
  • Back end of mobile apps powered by JSON, REST and other custom formats
  • Web services: JSON, REST, XML-RPC, SOAP
  • Complex application workflows: Sequences (shopping cart and other strict processes) and XSRF/CSRF tokens

Step 2: Understand the vulnerabilities of rich internet applications.

There are two key qualities you should require of a web application security scanner that you plan to use for modern rich internet applications. The first is the ability to import proxy logs. The second is an understanding of mobile application traffic, which enables the scanner to create attacks to test for security flaws. Vendors are often quick to advertise their scanners’ ability to be fed data from a proxy, but if the scanner is not familiar with JSON and REST, it will not be able to create attack variations – even when fed recorded traffic.

Like web application security scanners, traditional authentication methods fail to deliver the protection they once promised. While historically used to protect server-side mobile applications from SQL injection and cross-site scripting attacks, today’s authentication methods simply aren’t sophisticated enough to provide adequate web application security to new rich internet applications and mobile apps. For example, attackers can exploit weak passwords when a scheme only authenticates the user and not the application. This can be avoided by using a client-side certificate to identify the application, but this isn’t feasible for all apps – especially customer-facing mobile apps.

Step 3: Determine whether your web application security scanner is capable.

You can – and should – ask your web application security scanner provider what technologies the tool is able to scan. But don’t leave it at that – verify what they say is true. For instance, you can test for the security scanning coverage of an AJAX application by analyzing the request/response traffic. To do so, simply enable the scanner’s detailed logging feature, run the scanner through a proxy like Paros, Burp or WebScarab, and save the logs for manual review.

JSON also poses a unique challenge to web application security scanners. They must be able to decipher the new format and insert attacks to test the security of web application interfaces. A review of detailed logs of request/response traffic will indicate whether the web application security scanner is fully capable of protecting rich internet applications like yours. However, not all web application security scanners provide detailed logging. If this is the case, you will need to set up a proxy to capture traffic during the scan. Begin by scanning only a page that uses JSON, then check to see if the scanner requests include the JSON traffic and requests.

Step 4: Bolster manual testing efforts and custom web application security models.

Attackers are increasingly targeting back-end servers. And while new mobile APIs like JSON create new ways to engage customers in rich internet applications, they also create new ways for attackers to reach back-end servers. The only way to discover and remediate API security flaws, authentication weaknesses, protocol-level bugs and load-processing bugs is with several rounds of testing. Also, understand that you cannot rely on SQL or basic authentication to protect the back end. Develop server-based applications to anticipate attacks by continually verifying the integrity of the application and uptime environment.

Finally, when developing rich mobile applications, keep the following tips in mind:

  • Data provided by the client should never be trusted.
  • A device’s mobile equipment identifier should never be used to authenticate a mobile application, but do use multiple techniques to verify that requests are from the intended user.
  • Because session tokens for mobile apps rarely expire, attackers can use them for a very long time.
  • Credentials should not be stored in the application’s data store, local to the device.
  • When requiring SSL, a valid certificate should be necessary.

Guaranteeing reliable web application security for rich internet applications and mobile apps can be tricky business. However, completing the proper research, choosing the right security scanner, and performing an ample amount of testing will help detect vulnerabilities and ward off new attacks, allowing your application to be successful in the marketplace.

Vegas 2011 Review: Transparent Botnet Command and Control for Smartphones over SMS

Conference: B-Sides
Title: Transparent Botnet Command and Control for Smartphones over SMS
Speaker: Georgia Weidman

The title actually says most of it.  SMS is used because it is easy to conceal the botnet.  Malware on phones often announces its presence by draining the battery and piggybacking into SMS packets solves that.  And SMS is fault tolerant.  It is within the protocol itself to resend the message if there is no acknowledgement.  The protocol extends to the hacker the courtesy of persistently communicating the attack to its destination.  The balance of the talk encompassed the technical details of what an SMS packet looks like and how you craft the attack.

Summary:  this talk provided good general security knowledge.  I’m not sure if we (NTO) will ever scan smartphones.  That is an interesting business prospect though… I have never heard of a smartphone app scanner… one targeted specifically to phone apps.