Farseeing: a look at BeyondCorp

In our BlackHat talk, “Fighting the Previous War“, we showed how attacks against cloud services and cloud-native companies are still in their nascent stages of evolution. The number of known attacks against AWS is small, which is at odds with the huge number (and complexity) of services available. It’s not a deep insight to argue that the number of classes of cloud specific attacks will rise.

However, the “previous war” doesn’t just refer to cloud stuff. While our talk primarily dealt with cloud services, we also spent some time on another recent development, Google’s BeyondCorp. In the end, the results weren’t exciting enough to include fully in the talk and so we cut slides from the presentation, but the original slides are in the PDF linked above.

In this post we’ll provide our view on what BeyondCorp-like infrastructure means for attackers, and how it’ll affect their approaches.

We start with a quick overview of BeyondCorp that strips out less important details (Google has a bunch of excellent BeyondCorp resources if you’ve never encountered it before.)

In an ossified corporate network, devices inside the perimeter are more trusted than devices outside the perimeter (e.g. they can access internal services which are not available to the public Internet). In addition, devices trying to access those service aren’t subject to checks on the device (such as whether the device is known, or is fully patched).

In the aftermath of the 2009 Aurora attacks on Google, where attackers had access to internal systems once the boundary perimeter was breached, Google decided to implement a type of Zero Trust network architecture. The essence of the new architecture was that no trust was placed in the location of a client regardless of whether the client was located inside a Google campus or sitting at a Starbucks wifi. They called it BeyondCorp.

Under BeyondCorp, all devices are registered with Google beforehand and all access to services is brokered through a single Access Proxy called ÜberProxy.

This means that all Google’s corporate applications can be accessed from any Internet-connected network, provided the device is known to Google and the user has the correct credentials (including MFA, if enabled.)

Let’s walk through a quick example. Juliette is a Google engineer sitting in a StarBucks leaching their Wifi, and wants to review a bug report on her laptop. From their documentation, it works something like this (we’re glossing over a bunch of details):

1. Juliette’s laptop has a client certificate previously issued to her machine.
2. She opens https://tickets.corp.google.com in her browser.
3. The DNS response is a CNAME pointing to uberproxy.l.google.com (this is the Access Proxy). The hostname identifies the application.
4. Her browser connects using HTTPS to uberproxy.l.google.com, and provides its client certificate. This identifies her device.
5. She’s prompted for credentials if needed (there’s an SSO subsystem to handle this). This identifies her user.
6. The proxy passes the application name, device identifier (taken from the client certificate), and credentials to the Access Control Engine (ACE).
7. The ACE performs an authorization check to see whether the user is allowed to access the requested application from that device.
8. The ACE has access to device inventory systems, and so can reason about device trust indicators such as:
   1. a device’s patch level
   2. its trusted boot status
   3. when it was last scanned for security issues
   4. whether the user has logged in from this device previously
9. If the ACE passes all checks, the access proxy allows the request to pass to the corporate application, otherwise the request fails.

One particularly interesting aspect of BeyondCorp is how Google supports a bunch of protocols (including RDP and SSH) through the same proxy, but we won’t look at that today. (Another interesting aspect is that Google managed to migrate their network architecture without interruption and is, perhaps, the biggest takeaway from their series of papers. It’s an amazingly well planned migration.)

This sucks! (For attackers)

For ne’er-do-wells, this model changes how they go about their business.

Firstly, tying authorisation decisions to devices has a big limiting effect on credential phishing. A set of credentials is useless to an external attacker if the authorisation decision includes an assertion that the device has previously been used by this user. Impersonation attacks like this become much more personal, as they require device access in addition to credentials.

Secondly, even if a beachhead is established on an employee’s machine, there’s no flat network to laterally move across. All the attacker can see are the applications for which the victim account had been granted access. So application-level attacks become paramount in order to laterally move across accounts (and then services).

Thirdly, access is fleeting. The BeyondCorp model actively incorporates updated threat information, so that (for example), particular browser versions can be banned en masse if 0days are known to be floating around.

Fourthly, persistence on end user devices is much harder. Google use verified boot on some of their devices, and BeyondCorp can take this into account. On verified boot devices, persistence is unlikely to take the form of BIOS or OS-level functionality (these are costly attacks with step changes across the fleet after discovery, making them poor candidates). Instead, higher level client-side attacks seem more likely.

Fifthly, in addition to application attacks, bugs in the Access Control Engine or mistakes in the policies come into play, but these must be attacked blind as there is no local version to deploy or examine.

Lastly, targeting becomes really important. It’s not enough to spam random @target.com addresses with dancingpigs.exe, and focus once inside the network. There is no “inside the network”, at best you access someone’s laptop, and can hit the same BeyondCorp apps as your victim.

The lack of a perimeter is the defining characteristic of BeyondCorp, but that means anyone outside Google has a similar view to anyone inside Google, at least for the initial bits needed to bootstrap a connection.

We know all services are accessed through the ÜberProxy. In addition, every application gets a unique CNAME (in a few domains we’ve seen, like corp.google.com, and googleplex.com).

DNS enumeration is a well-mapped and frequently-trod path, and effective at discovering corporate BeyondCorp applications. Pick a DNS enumeration tool (like subrute), run it across the corp.google.com subdomain, and get 765 hostnames. Each maps to a Google Corporate application. Here’s a snippet from the output:

• […]
• pitch.corp.google.com
• pivot.corp.google.com
• placer.corp.google.com
• plan.corp.google.com
• platform.corp.google.com
• platinum.corp.google.com
• plato.corp.google.com
• pleiades.corp.google.com
• plumeria.corp.google.com
• […]

But DNS isn’t the only place to identify BeyondCorp sites. As is the fashion these days, Google is quite particular about publishing new TLS certificates in the Certificate Transparency logs. These include a bunch of hostnames in  corp.google.com and googleplex.com. From these more BeyondCorp applications were discovered.

Lastly, we scraped the websites of all the hostnames found to that point and found additional hostnames referenced in some of the pages and redirects. For fun, we piped into PhantomJS and screencapped all the sites for quick review.

Results? We don’t need no stinking results!

The end result of this little project was a few thousand screencaps of login screens:

However, a few weeks ago a high school student posted the story of his bug bounty which appeared to involve an ÜberProxy misconfiguration. The BeyondCorp model explicitly centralises security and funnels traffic through proxy chokepoints to ease authN and authZ decisions. Like any centralisation, it brings savings but there is also the risk of a single issue affecting all applications behind the proxy. The takeaway is that mistakes can (and will) happen.

By no means is this the death of remote attacks, but it shifts focus from basic phishing attacks and will force attackers into more sophisticated plays. These will include more narrow targeting (of the BeyondCorp infrastructure in particular, or of specific endusers with the required application access), and change how persistence on endpoints is achieved. Application persistence increases in importance, as endpoint access becomes more fleeting.

With all this said, it’s unlikely an attacker will encounter a BeyondCorp environment in the near future, unless they’re targeting Google. There are a handful of commercial solutions which claim BeyondCorp-like functionality, but none rise to the same thoroughness of Google’s approach. For now, these BeyondCorp attack patterns remain untested.