An analysis of 10,000 mobile apps has found that a significant portion of them are open to web API hijacking – something that potentially affects the privacy and security of tens of millions of business users and consumers globally.
The root of the threat lies in the inconsistencies that are often found between app and server logic in web API implementations for mobile apps. Researchers at Texas A&M University created the WARDroid framework to crawl applications, automatically carrying out reconnaissance and uncovering these kinds of inconsistencies, using static analysis, along with what kinds of HTTP requests are accepted by the server. Once an attacker has the information on what these requests look like, he or she can carry out their own actions by tweaking a few parameters.
For instance, the researchers discovered a problem with a popular e-commerce SDK utilized by thousands of apps and online stores across the world, with millions of users, that would allow free shopping. That’s thanks to WARDroid finding that the app has a constraint on the quantity field for shopping cart items that disallows numbers less than one.
“Naturally, a quantity zero would have no effect, but WARDroid also suggested a violating input as a negative quantity,” the researchers said. “This is disallowed by the SDK’s constraints in the app, but we discovered that it was allowed by the server because the same functionality is used to process returns and refunds, where a negative quantity is indeed valid. However, since this inconsistency exists, we can bypass the app and replay a checkout action using a negative quantity on a line item that can be manipulated to cause the checkout total to be zero dollars.”
Using a set of 10,000 popular free apps from the Google Play Store, the researchers uncovered these types of inconsistencies – what they call “problematic logic” — in APIs used in over 4,000 apps. They then tested 1,000 of those apps with logic inconsistencies to successfully validate the capability for web API hijacking, a.k.a. HTTP request parameter injection attacks.
Development Mismatches
At the heart of the problem is the fact that the controls built into the mobile app and the controls actually enforced at the server side are rarely in sync. While mobile apps might do a great job of enforcing business logic on the handset, like user authentication, this may be neglected or not as strict on the server side.
“Mobile apps are often built as front-ends to services hosted in the cloud infrastructure and accessible through web API services,” explained A&M researchers Abner Mendoza and Guofei Gu, in a research paper on WARDroid [PDF]. In other words, mobile applications are merely interfaces on the client/app side that live on our phones, but then integrate with new or existing cloud services on the back-end server side. The apps reach out via the web to pull down information from the server as needed.
To make this work securely, the mobile web service API architecture mandates that input validation logic – controls for things like making sure all user names are unique, for instance – is done with the same strength on both the client and server side.
However, if the cloud service is an existing one that a developer is now building a mobile app for, or if he or she lacks experience, or if there’s a scale-and-speed premium on the work, odds are there will be a lack of consistency between two.
“We observe that it is non-trivial to ensure full and robust consistency between app-based and server-based validation routines, resulting in inevitable mismatches between client and server implementations of input validation logic,” the researchers wrote. They added, “While mobile apps may have robust input validation and access control logic implemented in their native code, those are often not equally replicated on the server side for data sent to a web API.”
As a result, an attacker can bypass client-side controls and exploit the web API services to extricate data or inject malicious data without proper authorization.
“If the web API service does not properly validate request data, and instead defers the responsibility to the mobile app, an attacker can hijack the API functionality meant exclusively for the mobile app,” said Mendoza and Gu. “The inconsistency lies in how the web API server replicates that validation. Attackers in our threat model do not attack the apps themselves but can use the app to understand the web API communication profile and leverage that knowledge to coerce the server to conduct malicious activities, expose sensitive user data, or gain unauthorized access to privileged functionality.”
Deploying WARDroid
WARDroid analyzes, en masse, Android applications’ APK packages to uncover possible web API hijacking opportunities. It determines what kinds of HTTP server requests the server accepts; and once they know that, bad actors could simply craft requests that mimic legitimate requests, to carry out their own actions.
“First, we model the mobile app’s web API communication into HTTP message templates,” the researchers explained. “To accomplish this, we utilize program analysis techniques that analyze the app to extract the program slices that generate HTTP requests from each point of interest. The main task is to track all dependencies that eventually flow to network buffers through particular Android framework APIs. This allows us to extract the relevant path constraints and reason about the web API requests generated by the app.”
Armed with this information, WARDroid can determine what request messages that would violate the extracted constraints and test if they’re accepted by the server, thus uncovering potential attack vectors – i.e., what the malicious requests should look like in order to be successful.
“Web API hijacking opportunities for specific API endpoints are uncovered through evaluation of inconsistencies by generating requests from the request templates that violate one or more constraints expressed in the template,” the researchers explained. “To evaluate the inconsistencies, we employ a string matching approach to automatically test sample requests to determine inputs that could be successful.”
They also built heuristics into the test module to identify the server technology from the response headers. For example, some servers will disclose the runtime framework, database, and other details that can be used to fingerprint the server.
“In our prototype, we use simple heuristics to identify the web server runtime (PHP, asp.net, etc) and the backend server (MySQL, mssql),” Mendoza and Gu said. “These are used to suggest further inputs that utilize domain knowledge, such as generating a simple SQL injection type input value.”
It should be said that an attack isn’t easy to carry out; the threat model assumes a network attacker has access to the mobile application and can reverse engineer the source code; and that he or she can observe and manipulate their own network traffic if necessary.
Also, “we assume the attacker has a means of sniffing data from legitimate mobile user devices, but he also operates his own mobile device and can observe, modify and decrypt his own HTTPS traffic,” the researchers noted. “Our attacker is also a legitimate mobile application user. This attacker has full access to the Android client layer through which he can interact with the remote web API server as a legitimate user would.”
Impact
A dizzying range of apps were found by WARDroid to be vulnerable, opening the door to an array of attack types. Most of the afflicted were less popular apps, with user populations between 100 to 1,000, although popular apps, as seen in the e-commerce example, are not excluded from the problem.
Overall, WARDroid found a total estimated victim population of over 6.47 million users from only 926 apps that displayed web API hijacking opportunities.
“If we consider this to be a representative sample of the total number of apps, we can assert that the potential impact is widespread, reaching many millions of users throughout the world,” the researchers said.
Also, although they tested Android apps for the purposes of the research, this is not a Google-specific issue; it’s a developer best-practice issue. Thus, Mendoza and Gu added that iOS apps also are at risk, along with any other client that uses the vulnerable web APIs, including Windows apps and software-as-a-service (SaaS) applications.
The bottom line is that this is a coding problem that causes big security issues. The researchers pointed the finger squarely at the ease of development these days, which allows even inexperienced developers to get into the mobile app game. This is helped along with modern tools like pre-packaged mobile cloud solutions from infrastructure players like Amazon AWS and Microsoft Azure, which developers can integrate into their apps with just a few lines of code. There are also ready-made solutions for common tasks such as data storage, user authentication, e-commerce, social-media integration and push notifications.
“This fast-paced development is often done without full consideration of security implications. Often, there is no robust security design or guidance of the application integration with the pre-packaged components, exposing many mobile applications to exploitation,” Mendoza and Gu said. They added, “This work sheds light on the existence and pervasiveness of this important ongoing research problem, and our hope is that it will motivate further research in this area.”
