A malicious application with the INTERNET permission granted could retrieve all entries from the Download Provider internal database, bypassing all currently implemented access control mechanisms, by exploiting an SQL injection in the sort parameter (ORDER BY clause) and appending a LIMIT clause, which allows expressions, including subqueries.
The information retrieved from this provider may include
potentially sensitive information such as file names, descriptions, titles,
paths, URLs (which may contain sensitive parameters in the query strings),
cookies, custom HTTP headers, etc., for applications such as Gmail, Google
Chrome, the Google Play Store, etc.
A malicious application with the INTERNET permission granted could retrieve all entries from the Download Provider internal database, bypassing all currently implemented access control mechanisms by exploiting an SQL injection in the selection clause.
The information retrieved from this provider may include potentially sensitive information such as file names, descriptions, titles, paths, URLs (that may contain sensitive parameters in the query strings), cookies, custom HTTP headers, etc., for applications such as Gmail, Google Chrome, the Google Play Store, etc.
A malicious application without any granted permission could retrieve all entries from the TV Provider internal database, bypassing all currently implemented access control mechanisms by exploiting an SQL injection in the projection parameter.
The information retrieved from this provider may include personal and potentially sensitive information about other installed applications and user preferences, habits, and activity, such as available channels and programs, watched programs, recorded programs, and titles in the “watch next” list.
By exploiting an SQL injection vulnerability, a malicious application without any permission granted could retrieve all entries from the Download Provider, bypassing all currently implemented access control mechanisms. Also, applications that were granted limited permissions, such as INTERNET, can also access all database contents from a different URI.
The information retrieved from this provider may include potentially sensitive information such as file names, descriptions, titles, paths, URLs (that may contain sensitive parameters in the query strings), etc., for applications such as Gmail, Chrome, or the Google Play Store.
Further access to the downloaded contents may be possible as well, depending on the permissions granted to the app and files.
As attack vectors go, very few are as significant as obtaining the ability to insert bespoke code in to an application and have it automatically execute upon “inaccessible” backend systems. In the Web application arena, SQL Injection vulnerabilities are often the scariest threat that developers and system administrators come face to face with (albeit way too regularly). In fact the
OWASP Top-10 list of Web threats lists SQL Injection in first place.
More often than not, when security professionals discuss SQL Injection threats and attack vectors, they focus upon the Web application context. So it was with a bit of fun last week when I came across a photo of a slightly unorthodox SQL Injection attempt – that of someone attempting to subvert a traffic monitoring system by crafting a rather novel vehicle license plate.
My original tweet got retweeted a couple of thousand of times – which just goes to show how many security nerds there are out there in the twitterverse.
“in the wild” SQL Injection attempt was based upon the premise that video cameras are actively monitoring traffic on a road, reading license plates, and issuing driver warnings, tickets or fines as deemed appropriate by local law enforcement.
At some point the video captures of the passing vehicle’s license plate must be converted to text and stored – almost certainly in some kind of backend database. The hope of the hacker that devised this attack was that the process would be vulnerable to SQL Injection – and crafted a simple SQL statement that could potentially cause the backend database to drop (i.e. “delete”) the table containing all of the license plate information.
Whether or not this particular attempt worked, I have no idea (probably not if I have to guess an outcome); but it does help nicely to raise attention to this category of vulnerability.
As surveillance systems become more capable – digitally storing information, distilling meta-data from image captures, and sharing observation data between systems – it opens many new doors for mischievous and malicious attack.
The physical nature of these systems, coupled with the complexities of integration with legacy monitoring and reporting systems, often makes them open to attacks that would be classed as fairly simple in the world of Web application security.
A common failure of system developers is to assume that the physical constraints of the data acquisition process are less flexible than they are. For example, if you’re developing a traffic monitoring system it’s easy to assume that license plates are a fixed size and shape, and can only contain 10 alphanumeric characters. Meanwhile, the developers of the third-party image processing code had no such assumptions and will digitize any image. It reminds me a little of the story in which reuse of some object-oriented code a decade ago resulted in
Kangaroos firing Stinger missiles during a military training simulation.
While the image above is amusing, I’ve encountered similar problems before when physical tracking systems integrate with digital backend processes – opening the door to embarrassing and fraudulent events. For example, in the past I’ve encountered similar SQL Injection vulnerabilities within systems such as:
- Toll booths reading RFID tags mounted on vehicle windshields – where the tag readers would accept up to 2k of data from each tag (even though the system was only expecting a 16 digit number).
- Credit card readers that would accept pre-paid cards with negative balances – which resulted in the backend database crediting the wrong accounts.
- RFID inventory tracking systems – where a specially crafted RFID token could automatically remove all record of the previous hours’ worth of inventory logging information from the database allowing criminals to “disappear” with entire truckloads of goods.
- Luggage barcode scanners within an airport – where specially crafted barcodes placed upon the baggage would be automatically conferred the status of “manually checked by security personnel” within the backend tracking database.
- Shipping container RFID inventory trackers – where SQL statements could be embedded to adjust fields within the backend database to alter Custom and Excise tracking information.
Unlike the process of hunting for SQL Injection vulnerabilities within Internet accessible Web applications, you can’t just point an automated vulnerability scanner at the application and have at it. Assessing the security of complex physical monitoring systems is generally not a trivial task and requires some innovative approaches. Experience goes a long way.
— Gunter Ollmann, CTO IOActive Inc.
