05 Aug Honda Leaks Database With 134 Million Rows Of Employee Computer Data
Security team at motor company reacts quickly after notification
– Sausalito, Calif. – Aug. 3, 2019
I was searching Shodan yet again when I discovered an ElasticSearch database without any authentication.
The data contained within this database was related to the internal network and computers of Honda Motor Company, the eighth largest automobile manufacturer in the world (as of 2015). They have an approximate market cap of $46.8 billion, with offices spread across the world, including Japan, United States, Great Britain, Mexico, and other locations.
The information available in the database appeared to be something like an inventory of all Honda internal machines. This included information such as machine hostname, MAC address, internal IP, operating system version, which patches had been applied, and the status of Honda’s endpoint security software.
I would like to thank the security team at Honda Motor Company for their very prompt action to secure the database shortly after being notified.
Incident Timeline
Honda Statement
“Thank you very much for pointing out the vulnerability. The security issue you identified could have potentially allowed outside parties to access some of Honda’s cloud-based data that consisted of information related to our employees and their computers. We investigated the system’s access logs and found no signs of data download by any third parties. At this moment, there is no evidence that data was leaked, excluding the screenshots taken by you. We will take appropriate actions in accordance with relevant laws and regulations, and will continue to work on proactive security measures to prevent similar incidents in the future.”
Background:
Based on the Shodan scan of the IP in question (which I am intentionally not linking to), it appears that the database was likely publically accessible as of July 1, 2019.
Initially it was challenging to locate a human at Honda Motor Company. I requested assistance on Twitter, and several very helpful folks reached out with offers of assistance. Through one of these contacts I was able to reach Honda’s security team on July 6th, and they promptly took action to secure the database.
How much data?
The exposed ElasticSearch database contained approximately 134M documents which translated to roughly 40GB of data.
Data in the database appeared to go as far back as March 13, 2019 or roughly 3.5 months of data.
To get an estimate of data volume I looked back at the previous 30 days of time, and observed that roughly 40,000 data points were being added to the database nearly every day. There is an anomalous spike in data volume around mid-March 2019 that I did not investigate. It seems likely that this could have been something like an initial load of data into the database given that the database seems to have only come online on March 13th.
What was exposed?
Initially I assumed this data was a likely to be from a single Honda dealership. This seemed like a far more likely scenario. With additional digging it quickly became clear that this was a much broader data set that contained data related to all of Honda’s global network of employee machines.
It seems the “empty string” value for the “company” field corresponded with Honda’s offices in Japan. The bulk of the data was related to those employees, but as you can see several other offices were also included in the data. The screenshot only shows the top 5 values, not all possible values.
A few quick notes:
Before I get into the specifics of what information was contained within the leak I wanted to touch on why this data is sensitive.
What makes this data particularly dangerous in the hands of an attacker is that it shows you exactly where the soft spots are. I am specifically not going to name the major endpoint security vendor that protects Honda’s machines, but the data makes it clear which vendor they use and which machines have the endpoint security software enabled and up to date. The data seems to show you which machines do not have endpoint security enabled, which machines are running older operating systems, and if you have a particular vulnerability you could quickly search for machines that have not been patched yet using this data. As I’ll show in later screenshots this data contained enough identifiable information to make it extremely simple to locate specific high value employees (such as the CEO, CFO, CSO, etc). In the hands of an attacker this leaked data could be used to silently monitor those executives to identify ways to launch very targeted attacks. One of the tables of data seems to provide a list of machines that do not have endpoint security software in place. This is my guess based on the naming scheme and the data in the table. If an attacker is looking for a way into Honda’s network knowing which machines are far less likely to identify/block their attacks would be critical information. These “uncontrolled machines” could very easily be the open door into the entire network.
During the course of this disclosure process Honda requested a number of redactions be made to the following screenshots. I agreed to make a number of these redactions for obviously sensitive content. I have no intention of oversharing. That being said, I did not make all the requested redactions where I felt they were over inclusive and not referring to sensitive data.
The “ad_com_all” table
This table included the employee name, host name, operating system(OS) type, and the OS version. Roughly 300,000 data points per cycle of data being updated.
The “ad_user_all” table
This table included the employee email address, employee name, department, last login, employee number, account name, and a mobile field (I didn’t see values populated though). Slightly less than 300,000 data points per update.
The “comterminal” table
This table included the employee email, department, machine IP address, MAC address, host name, operating system, machine type, endpoint security state, and which Windows KB/patches had been applied. Roughly 40,000 data points per update.
The “nwcomteminal_data” table
This table included the also included the machine IP address, MAC address, host name, and which Windows KB/patches had been applied.
The “dhcp_data” table
This table included the asset tag for a device and the MAC address. The “EA-LastModifiedBy” field included usernames of what I can presume to be administrative staff who made changes.
The “printer_data” table
This table included the printer name and internal IP. Roughly 2,500 rows of data per update.
The endpoint security table
I am specifically not sharing the real name of this table as it makes it clear who the endpoint security vendor is. This table included the username of the employee and the endpoint security status for their machine. Roughly 90,000 rows of data per update.
The “uncontrolledmachine” table
This table included what I can reasonably guess (I cannot 100% confirm) to be the hostname and operating system for machines that are not monitored by the endpoint security software. Some usernames were also present. Roughly 3,000 rows of data per update.
This isn’t a separate table in the database, but this is a selection of columns from the “ad_com_all” table showing the wealth of useful data for an attacker. This view shows the hostname, username, last login date, when created, last changed date, OS, OS version.
The CEO’s laptop
This view shows the CEO’s full email, full name, department, MAC address, which Windows KB/patches had been applied, OS, OS version, endpoint security status, IP, and device type.
This view shows the CEO’s full name, last login date, employee ID, email, department, email nickname, and account name.
Summary
Thank you to Honda for quickly acting on my report and securing this data.
Please secure your data.
Originally posted at Rainbowtabl.es
– Justin Paine is an experienced security researcher and Cybercrime Magazine contributor
