Daily Archives: July 11, 2018

Breaking ground: Understanding and identifying hidden tunnels

It’s me again – Cognito. As always, I’ve been hard at work with Vectra to automate cyberattack detection and threat hunting. Recently, we made an alarming discovery: hackers are using hidden tunnels to break into and steal from financial services firms!

Clearly, this is serious business if it involves bad guys targeting massive amounts of money and private information. But what exactly are we dealing with? Let’s dig into what hidden tunnels are and how I find them to uncover the answer.

Mitigating Spectre with Site Isolation in Chrome



Speculative execution side-channel attacks like Spectre are a newly discovered security risk for web browsers. A website could use such attacks to steal data or login information from other websites that are open in the browser. To better mitigate these attacks, we're excited to announce that Chrome 67 has enabled a security feature called Site Isolation on Windows, Mac, Linux, and Chrome OS. Site Isolation has been optionally available as an experimental enterprise policy since Chrome 63, but many known issues have been resolved since then, making it practical to enable by default for all desktop Chrome users.

This launch is one phase of our overall Site Isolation project. Stay tuned for additional security updates that will mitigate attacks beyond Spectre (e.g., attacks from fully compromised renderer processes).

What is Spectre?

In January, Google Project Zero disclosed a set of speculative execution side-channel attacks that became publicly known as Spectre and Meltdown. An additional variant of Spectre was disclosed in May. These attacks use the speculative execution features of most CPUs to access parts of memory that should be off-limits to a piece of code, and then use timing attacks to discover the values stored in that memory. Effectively, this means that untrustworthy code may be able to read any memory in its process's address space.

This is particularly relevant for web browsers, since browsers run potentially malicious JavaScript code from multiple websites, often in the same process. In theory, a website could use such an attack to steal information from other websites, violating the Same Origin Policy. All major browsers have already deployed some mitigations for Spectre, including reducing timer granularity and changing their JavaScript compilers to make the attacks less likely to succeed. However, we believe the most effective mitigation is offered by approaches like Site Isolation, which try to avoid having data worth stealing in the same process, even if a Spectre attack occurs.

What is Site Isolation?

Site Isolation is a large change to Chrome's architecture that limits each renderer process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes, and thus, between sites. Note that Chrome uses a specific definition of "site" that includes just the scheme and registered domain. Thus, https://google.co.uk would be a site, and subdomains like https://maps.google.co.uk would stay in the same process.

Chrome has always had a multi-process architecture where different tabs could use different renderer processes. A given tab could even switch processes when navigating to a new site in some cases. However, it was still possible for an attacker's page to share a process with a victim's page. For example, cross-site iframes and cross-site pop-ups typically stayed in the same process as the page that created them. This would allow a successful Spectre attack to read data (e.g., cookies, passwords, etc.) belonging to other frames or pop-ups in its process.

When Site Isolation is enabled, each renderer process contains documents from at most one site. This means all navigations to cross-site documents cause a tab to switch processes. It also means all cross-site iframes are put into a different process than their parent frame, using "out-of-process iframes." Splitting a single page across multiple processes is a major change to how Chrome works, and the Chrome Security team has been pursuing this for several years, independently of Spectre. The first uses of out-of-process iframes shipped last year to improve the Chrome extension security model.
A single page may now be split across multiple renderer processes using out-of-process iframes.

Even when each renderer process is limited to documents from a single site, there is still a risk that an attacker's page could access and leak information from cross-site URLs by requesting them as subresources, such as images or scripts. Web browsers generally allow pages to embed images and scripts from any site. However, a page could try to request an HTML or JSON URL with sensitive data as if it were an image or script. This would normally fail to render and not expose the data to the page, but that data would still end up inside the renderer process where a Spectre attack might access it. To mitigate this, Site Isolation includes a feature called Cross-Origin Read Blocking (CORB), which is now part of the Fetch spec. CORB tries to transparently block cross-site HTML, XML, and JSON responses from the renderer process, with almost no impact to compatibility. To get the most protection from Site Isolation and CORB, web developers should check that their resources are served with the right MIME type and with the nosniff response header.

Site Isolation is a significant change to Chrome's behavior under the hood, but it generally shouldn't cause visible changes for most users or web developers (beyond a few known issues). It simply offers more protection between websites behind the scenes. Site Isolation does cause Chrome to create more renderer processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes. Our team continues to work hard to optimize this behavior to keep Chrome both fast and secure.

How does Site Isolation help?

In Chrome 67, Site Isolation has been enabled for 99% of users on Windows, Mac, Linux, and Chrome OS. (Given the large scope of this change, we are keeping a 1% holdback for now to monitor and improve performance.) This means that even if a Spectre attack were to occur in a malicious web page, data from other websites would generally not be loaded into the same process, and so there would be much less data available to the attacker. This significantly reduces the threat posed by Spectre.

Because of this, we are planning to re-enable precise timers and features like SharedArrayBuffer (which can be used as a precise timer) for desktop.

What additional work is in progress?

We're now investigating how to extend Site Isolation coverage to Chrome for Android, where there are additional known issues. Experimental enterprise policies for enabling Site Isolation will be available in Chrome 68 for Android, and it can be enabled manually on Android using chrome://flags/#enable-site-per-process.

We're also working on additional security checks in the browser process, which will let Site Isolation mitigate not just Spectre attacks but also attacks from fully compromised renderer processes. These additional enforcements will let us reach the original motivating goals for Site Isolation, where Chrome can effectively treat the entire renderer process as untrusted. Stay tuned for an update about these enforcements! Finally, other major browser vendors are finding related ways to defend against Spectre by better isolating sites. We are collaborating with them and are happy to see the progress across the web ecosystem.

Help improve Site Isolation!

We offer cash rewards to researchers who submit security bugs through the Chrome Vulnerability Reward Program. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards levels, up to twice the usual amount for information disclosure bugs. Find out more about Chrome New Feature Special Rewards.

Is the California Consumer Privacy Act the “American GDPR”?

The new California Consumer Privacy Act is the strictest data privacy law in the U.S., but it falls fall short of the GDPR. The recent Exactis data leak, which could surpass Equifax in the sheer number and scope of records exposed, has data privacy advocates calling for an “American GDPR.” While it is unlikely that… Read More

The post Is the California Consumer Privacy Act the “American GDPR”? appeared first on .

IoT And Your Digital Supply Chain

“Money, it’s a gas. Grab that cash with both hands and make a stash”, Pink Floyd is always near and dear to my heart. No doubt the theme song to a lot of producers of devices that fall into the category of Internet of Things or IoT.

I can’t help but to giggle at the image that comes to mind when I think about IoT manufacturers. I have this vision in my head of a wild-eyed prospector jumping around after finding a nugget of gold the size of a child’s tooth. While this imagery may cause some giggles it also gives me pause when I worry about what these gold miners are forgetting. Security comes to mind.

I know, I was shocked myself. Who saw that coming?

While there is a mad rush to stake claims across the Internet for things like connected toasters, coffee makers and adult toys it seems security falls by the way side. A lot of mistakes that were made a corrected along the way as the Internet evolved into the monster that it is today are returning. IoT appears to be following a similar trajectory but, at a far faster pace.

With this pace we see mistakes like IoT devices being rolled out with deprecated libraries and zero ability to upgraded their firmware or core software. But, no one really seems to care as they count their money while they’re still sitting at the table. The problem really comes into focus when we realize that it is the rest of us that will be left holding the bag after these manufacturers have made their money and run.

Of further concern is the fractured digital supply chains that they are relying on. I’m worried that with this dizzying pace of manufacture that miscreants and negative actors are inserting themselves into the supply chain. We have seen issues like this come to the forefront time and again. Why is it that we seem hell bent on reliving the same mistakes all over again?

One of my favorite drums to pound on is the use of deprecated, known vulnerable, libraries in their code. I’ve watched talks from numerous presenters who unearthed this sort of behavior at a fairly consistent pace. What possible rationale could there be for deploying an IoT device in 2016 with an SSL library that is vulnerable to Heartbleed?

I’ll let that sink in for a moment.

And this is by no means the worst of the lot. These products are being shipped to market with preloaded security vulnerabilities that can lead to all manner of issues. Data theft is the one that people like to carry on about a fair bit but, it would be a fairly trivial exercise to compromise some of these devices and have them added to a DDoS botnet.

What type of code review is being done a lot the way by code written by outsourced third parties? This happens a lot and really does open a company up to a risk of malicious, or poor, code being introduced.

The IoT gold rush is a concern for me from a security perspective. Various analyst firms gush about the prospect of having 800 gajillion Internet enabled devices online by next Tuesday but, they never talk about how we are going to clean up the mess later on. Someone always has to put the chairs up after the party is over.

Originally posted on CSO Online by me.

The post IoT And Your Digital Supply Chain appeared first on Liquidmatrix Security Digest.

Uncle Teeth – Application Security Weekly #23

This week, Keith and Paul talk The Hardest Problem in Application Security: Visibility. In the news, Google patches critical remote code execution bugs in Android OS, JavaScript API for face recognition in the browser with tensorflow.js, Social media apps are 'deliberately' addictive to users, and more on this episode of Application Security Weekly!

 

Full Show Notes: https://wiki.securityweekly.com/ASW_Episode23

 

Visit https://www.securityweekly.com/asw for all the latest episodes!

 

Visit https://www.activecountermeasures/asw to sign up for a demo or buy our AI Hunter!!

 

→Visit our website: https://www.securityweekly.com

→Follow us on Twitter: https://www.twitter.com/securityweekly

→Like us on Facebook: https://www.facebook.com/secweekly