Distant Code Execution Vulnerability in Google They Are Not Keen To Repair

Distant Code Execution Vulnerability in Google They Are Not Keen To Repair

April 14, 2023

It is a story a couple of safety vulnerability in Google that allowed me to run
arbitrary code on the computer systems of fifty+ Google workers. Though Google
initially thought of my discovering a severe safety incident, afterward, it
modified its thoughts and acknowledged that my discovering will not be, in actual fact, a vulnerability,
however the supposed habits of their software program.

Earlier this yr, I used to be doing safety analysis into dependency confusion.
Dependency confusion is a software program misconfiguration attributable to which a bundle that
is meant to be pulled from a non-public bundle repository is as an alternative downloaded
from a public repository, for instance, from npmjs.org within the case of NPM. In
most eventualities, an attacker finds a reputation of a non-public bundle and uploads a
bundle with the identical identify to the general public repository. The attacker can embrace
any code within the bundle and in most languages is ready to run arbitrary code
already at set up time, making dependency confusion vulnerabilities
notably harmful.

From the exploit complexity perspective, dependency confusion points are simple to
exploit. All it’s important to do is add a bundle to the general public bundle repository
and anticipate the bundle to be downloaded. That is one thing anybody can do and
doesn’t require any particular abilities. The onerous half is figuring out the non-public
packages which might be vulnerable to dependency confusion. Often, corporations preserve
their non-public packages and the tasks that make the most of these packages non-public, so
you simply can’t have a look at an organization’s GitHub and anticipate finding all of the tasks
weak to dependency confusion along with the names of personal
dependencies.

Fortunately, the names of inside packages are often not guarded with top-level
safety measures. For instance, for code that’s deployed to the front-end, the
bundle names could also be included within the code bundle. And whereas it isn’t attainable
to find out which packages can be downloaded attributable to dependency confusion
points, safety researchers (and malicious actors) can add all potential
packages they discover – the worst that may occur is that the uploaded bundle will
not be downloaded.

Early this yr, I began tinkering with the thought of mechanically discovering
non-public bundle names from publicly obtainable supply code, hosted on websites like
GitHub. This led me to search out a big set of personal bundle names which I used to
uncover a string of dependency confusion points at varied massive tech
corporations.

My methodology for mechanically discovering these bundle names was easy. I
scanned GitHub repositories for lists of dependencies in widespread codecs and
regarded for dependencies that have been a part of a dependency listing, however there was no
matching bundle within the public bundle repository. For instance, for Python, I
checked out lists matching the output of pip freeze command and for packages
that weren’t current in PyPi. The search house was constrained to repositories
that have been owned by a company associated to main expertise corporations, such
as Google or Microsoft, and to repositories that have been owned by workers of
these corporations. I thought of a GitHub person an worker if that they had set their
firm in GitHub to a big tech firm, e.g., that they had the @google tag on
their profile.

One of many matches of my scanner got here from a public repository belonging to a
Google worker. My scanner discovered a reference to a non-existent bundle (referred to as
bundle X onwards^{) in one of many recordsdata within the repository. A GitHub search
for the bundle identify revealed three extra references to the identical bundle in
GitHub. All of the matches got here from workers and ex-employees of Google, so this
gave me early confidence that the bundle was owned by Google.}

The reference to bundle X was in a necessities.txt file, which means it was a
Python bundle. This was excellent news since Python is a language with unarguably
the worst dependency administration system. With Python, this can be very simple to
misconfigure your set up scripts to be liable to dependency confusion. Simply
to point out how simple it’s to shoot your self within the foot, right here is an instance shell
command that installs non-public bundle kaboom from non-public registry
https://example.com and is weak to dependency confusion:

pip set up kaboom –extra-index-url https://instance.com

A reader that works with Python every day and is up-to-date on safety
is aware of that extra-index-url is a no-go for putting in non-public packages. Regardless of
having been identified for years now, extra-index-url remains to be used broadly as a result of
bizarre customers don’t think about the safety implications when utilizing the
parameter. I cannot flip this publish right into a rant about Python and pip, but when
you have an interest on this subject, there’s a dialogue with 100+ feedback on
GitHub relating to extra-index-url: https://github.com/pypa/pip/issues/8606.

After discovering bundle X from the GitHub repository, the subsequent step was to add
a public bundle with that identify to PyPi, the default Python bundle repository.
Within the set up script of the general public bundle, I included code that might
ship an HTTP request with the present hostname and username to an online server I
hosted. That allowed me to detect when the bundle was put in at Google and
is the go-to methodology for confirming dependency confusion vulnerabilities.

After importing the bundle, it took about two weeks till I began receiving
downloads at a price of roughly one obtain per day. The downloads got here from
computer systems or digital desktops of Google workers around the globe. They spanned
totally different roles like software program engineers and firmware engineers (in line with
LinkedIn) and totally different nations, together with the US, Belgium, and
China. Curiously, the downloads got here solely from hosts that have been related
with particular individuals and never from automated builds or from Google providers. My
speculation is that bundle X is an inside instrument that’s solely used regionally and
not a part of any Google product deployments.

Upon receiving the primary actual obtain inside Google, I reported the
vulnerability to Google’s vulnerability reward program. At first, Google took
motion rapidly and categorised the bug as S0, which is the very best severity in
their vulnerability reward program. They mounted the problem in about two weeks and
awarded a bounty of $500^{. Throughout these two weeks, the bundle was put in
to roughly 15 distinctive hosts.}

For the aim of including extra credibility to the story, listed below are the main points of
a couple of hosts to the place my model of bundle X was put in:

A couple of weeks after the patch, I began as soon as once more receiving downloads from
worker gadgets. I made a brand new report back to Google, saying that the problem has
resurfaced. Surprisingly, this time Google closed my report, stating that it’s
not in actual fact a safety vulnerability and that the software program is working as
supposed. In addition they mentioned that the vulnerability included social engineering
which is out of scope of the vulnerability reward program. This was complicated
for me for the reason that bug includes zero social engineering. I made a number of makes an attempt
to focus on the influence of this bug and the way it doesn’t contain social
engineering. Ultimately, their determination was the identical — every little thing is
working as supposed.

See Also

OpenIPC · GitHub

Now, there are a number of choices why Google didn’t assume it is a drawback and
determined to not pursue fixing it:

• They didn’t perceive the issue. I believe this feature is the more than likely
  one as a result of after I submitted the primary report, it was assigned the very best
  severity attainable and promptly mounted. That occurred as a result of the case supervisor
  understood the issue and its influence. It’s attainable that the case supervisor
  that dealt with my new report didn’t merely perceive the vulnerability and
  dangers related.
• There is no such thing as a precise threat related to downloading these packages. Since I
  haven’t labored at Google, I have no idea what are their safety practices. It
  is feasible that they run every little thing in remoted environments the place the chance
  related is extraordinarily low. However, the affected environments ought to
  nonetheless comprise some info as a result of they don’t seem to be simply plain OS
  installations with no information. There should be one thing there, like proprietary
  supply code or proprietary inverted binary timber.
• There really is “social engineering” concerned. It’s attainable that by social
  engineering they meant that customers set up the bundle by themselves from PyPi
  and by some means mistake it for the inner bundle. I discover that situation unlikely
  as a result of it doesn’t clarify the few weeks throughout which the problem was mounted.
• The bug can’t be exploited by malicious person since I claimed the bundle.
  That is true since just one particular person can declare a bundle on PyPi, however it will
  undoubtedly be a really odd safety follow.
• They merely don’t care.

On the time of writing, it has been per week since our final communication and the
Python bundle remains to be being downloaded by Googlers every single day. If I wished to,
I may exchange the present model of the bundle with one thing malicious, and
it will begin working on Google’s workers’ computer systems/digital desktops.

So far as fixing the issue goes, Google has had an easy option to repair the
particular situation from the beginning – they might merely have bundle X faraway from
PyPi by employees and have the identify blacklisted to forestall the identical bundle from
being claimed once more sooner or later. That is one thing different corporations to whom I
have reported dependency confusion points have accomplished and ensures that the identical
bundle can’t be used for dependency confusion sooner or later. Now, that is
definitely not a strong repair since there could also be different non-public packages that would
be used rather than bundle X.

The truth is, there have been 5 extra references to non-existent non-public packages within the
similar GitHub repository the place I discovered bundle X. I cannot disclose the names of
these packages, however judging by their names, they’re seemingly inside instruments and
most likely put in in the identical manner as bundle X. If anybody is inquisitive about
penetrating Google (be your intent claiming bug bounties or one thing else), you
can simply discover these packages by doing an analogous scan as I did. And there are
seemingly much more packages I didn’t discover since I solely scanned a small fraction
of the info.

Anyway, this was the story of how I hacked into Google. Let’s see if Google
takes one other have a look at my report after I publish this publish.

By the way in which, I plan to jot down one other piece that dissects in additional element the
strategies I used to search out these bundle names from open-source information. In case you
have an interest, keep tuned.

If in case you have any feedback relating to this text, be at liberty to succeed in out to us at
[email protected].