Credits

John
Github: https://github.com/johnjhacking
Molly White
Twitter: https://twitter.com/molly0xFFF
Zultan
Twitter: https://twitter.com/orpheus9001

Summary

First and foremost, we may have taken the phrase “Hack the Planet” a little too serious.

Google Earth Enterprise is an application that is utilized by Scientific, Government, Military and Educational organizations. We discovered that GEE deploys with default credentials that hundreds if not thousands of organizations fail to change. The nature of GEE is to map or chart various Google Earth entities. The problematic aspect of government and military organizations utilizing default credentials is that in many cases, they are likely deploying instances of GEE and mapping logistical supply routes, field operation positions, transportation routes, etc. In addition, the GEE instances have the ability to access apache logs, including error logs, which in many cases, can reveal the private IP subnet of the affected parties - and by default, allows a threat actor to view all of the public IP addresses accessing the apache server on the clientside (as well as displaying the paths) - very similar to a server status page.

A bad actor could unpublish or publish databases, as well as potentially modify various search functionality and even add/delete google earth layers within the application. The databases had file paths that in some cases, revealed internal host systems not seen on the client side.

While we wanted to avoid speculation, GEE proved to be fairly rich with data, with the ability to create custom layers and view heaps of logistical. It was of no doubt in our minds that Nation State threat actors may already have access to US Government/Military GEE instances. We immediately informed CERT/CISA to advise affected organizations.

The United States wasn’t the only impacted country. It appears that Taiwan also deploys GEE instances, therefore we did our due diligence and informed CERT of this as well.

Take a look at GEE’s promotional video:
https://www.youtube.com/watch?v=UHL9sDbBGnk

Military organization utilization:

Identification

While utilizing various Github Dorks, I realized that most of the current scripts were limited to searching for single organizations or usernames, with no ability to pass in uname/org lists. While useful to search an organization against a list of dorks, sometimes there’s a need to look at multiple organizations. In addition, most of the current scripts do not work with the GitHub credentials or tokens correctly, severely limiting the amount of searches that could be performed.

Thus, Molly White’s brainchild was born:
https://github.com/molly/gh-dork

After utilizing the script and searching various organizations, Molly had identified the following snippet of code in the .htaccess file of Google Earth Enterprise’s open source project:

\#
\# Copyright 2017 Google Inc.
\#
\# Licensed under the Apache License, Version 2.0 (the "License");
\# you may not use this file except in compliance with the License.
\# You may obtain a copy of the License at
\#
\#      http://www.apache.org/licenses/LICENSE-2.0
\#
\# Unless required by applicable law or agreed to in writing, software
\# distributed under the License is distributed on an "AS IS" BASIS,
\# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
\# See the License for the specific language governing permissions and
\# limitations under the License.
\#

geapacheuser:$apr1$eDCITJPv$wWVyjf6F.ETfwKbd1dAkq/

We thought about cracking the hash, but after some digging, we came across a GEE document covering the deployment configuration and setup for the Admin Console:

Essentially, the document stated that upon deployment of the application, it would be setup with default credentials geapacheuser:geeadmin

At first, we had thought that they were hardcoding the credentials and not allowing the client to change them, fortunately - that wasn’t the case. Google advises that the client utilizing the GEE application changes the credentials - negating the possibility of this being a CVE.

Exploitation

Obviously I wouldn’t be doing this writeup if the story ended at “Google recommends clients to change the password, end of story”.

We have reason to believe that many of the organizations utilize default credentials, problematic given the type of organizations that benefit from GEE. We exploited one of the the GEE instances within legal-bounds and tested the various application functionality.

Logging into the application was trivial, as we stated earlier, the credentials geapacheuser:geeadmin were used:

Upon login, we could see a dashboard highlighting application statistics:

Apache logs gave us access to view Public IP addresses of clients connecting to the application:

Internal IP address exposure on the application, via Apache Error logs:

By clicking on the database tab, a threat actor can remove databases completely or publish/unpublish existing databases:

In addition, on the more mild end of the scale, a threat actor could delete search filters or create their own:

Now the good part. Here is an example of various points of interest for a specific organization:

Out of context, this screenshot wouldn’t make much sense at all. However, there are thousands of different ways to map objects in GEE and being that the government/military is utilizing it, this is of a serious concern. The above rending is 2D, but there’s also 3D options - which are limited based on depreciated plugins.

Automation

What fun would any of this be without a little automation for hackers and organizations trying to identify attack surface?

I came up with the idea of making a Nuclei template to check for panel exposures. Originally, I created a template to identify the front page of GEE - which was a solid first step. However, Zultan had the idea to turn the template into a default login template instead, and together we identified a flow that would work based on all of the various instances:

id: google-earth-dlogin

info:

  name: Google Earth Enterprise Default Login

  author: orpheus,johnjhacking

  severity: high

  tags: default-login,google

requests:

  - raw:

      - |

        GET /admin/ HTTP/1.1

        Host: {{Hostname}}

        Authorization: Basic {{base64(username + ':' + password)}}

    attack: pitchfork

    payloads:

      username:

        - geapacheuser

      password:

        - geeadmin

    matchers-condition: and

    matchers:

      - type: status

        status:

          - 200

      - type: word

        words:

          - 'DashboardPanel'  

Simple enough. If a GEE instance is identified, nuclei will attempt a login with the default credentials and return a result if the body of the request contains “DashboardPanel” which is the indicator that the login was successful.

Remediation

Fixing the vulnerability is simple:
sudo /opt/google/gehttpd/bin/htpasswd -c /opt/google/gehttpd/conf.d/.htpasswd geapacheuser