XS-Searching takes advantage of timing-based attack

A security researcher has refined a known but slightly obscure hacking technique and applied it to trawl Google’s bug tracker and extract examples of juicy zero-days.

The cross-site search attack (XS-Searching) was harnessed by security researcher Luan Herrera to unearth details of vulnerabilities from a Google’s bug-tracking database.

Herrera exploited several low-grade vulnerabilities in Google’s Monorail issue tracker system to obtain sensitive data (vulnerable source code files and line numbers) from private bug reports held on the system.

Monorail is an open source issue tracker used by several Chromium-related projects as well as by Project Zero, Google’s zero-day bug-hunting crew.

The system omitted protection against cross-site request forgery (CSRF) attacks - a shortcoming that gave Herrera a starting point in developing an attack.

The CSRF flaw meant it was possible to make authorized users interrogate the database for entries marked with sensitive tags (specifically, Restrict-View-SecurityTeam).

A second issue meant it was possible to increase the number of results obtained from the same query.

The first flaw created a means to run complex search queries, while the second allowed a way to harvest multiple results from these searches.

Combining these two vulnerabilities facilitated an XS-Search attack.

Perfect timing

The two flaws create a means to run searches through the proxy of an authorized user’s session – something that wouldn’t be possible if the underlying app was secure.

This isn’t much use in itself, but Herrera realized that if the response for a search query matched a bug, it returned a longer result that if nothing useful was found.

There’s a sizeable difference in the length of responses, and this is associated in a marked increase in the time it takes the system to return results for valid queries.

This, Herrera realized, created a means to run a side-channel attack based on looking for results with delayed responses, and by taking advantage of the Cache API.

Herrera explained in a blog post: “The Cache API comes in handy, by only making one request and repeatedly calculating the duration that the response takes to be cached it’s possible to infer with certainty if the result of the search query returned bugs or not.”

But what to search for in putting together a proof of concept exploit?

Chromium bug reports indicate the file path and line number where the vulnerability can be found. This allowed Herrera to craft search terms that exploited the subtle cross-site search vulnerability present in the system.

The issue is far from confined to Google’s bug tracker system alone. The same techniques might usefully be applied against other sites that harbor similar flaws.

The underlying technique (pdf) of cross-site search attacks date back to 2015, but it remains poorly understood.