The hackers infiltrated Tesla’s Kubernetes console, which was not password protected
Tesla has fallen victim to crypto-jacking, per a report by RedLock CSI. Hackers found a way in via a Kubernetes console that was not password protected. From there they were able to find a Kubernetes pod with exposed credentials. Those credentials got them into Tesla’s AWS environment, which, in turn, contained an Amazon Simple Storage Service (S3) bucket that was full of sensitive data.
Oh, and the hackers were also using one of the Kubernetes pods to mine cryptocurrency. As you do.
There’s a lot to unpack here, so let’s start from the beginning.
How did this happen?
Well, let’s start by pointing out that RedLock informed Tesla of this, and Tesla immediately patched it. But there are some additional steps that Tesla could have taken. For one, it could have done a better job of monitoring its configurations. A company like Tesla should have the resources and tools to monitor for risky configurations. That would have likely caught this unsecured Kubernetes console.
For the record, a Kubernetes is an open-source system for the automated deployment and management of containerized applications.
Back to Tesla though, it probably could have prevented this by monitoring network traffic better, too. As in, had Tesla correlated network traffic with its configurations it would have seen the suspicious traffic coming from the vulnerable Kubernetes pod.
This could also underscore the need to incorporate Artificial Intelligence (AI) and machine learning into a defense strategy as well. Had Tesla been able to baseline regular user activity – when the account is active, what part of the network it interacts with – it would have seen anomalous activity coming from the credentials in use. Then it could have mitigated the entire situation. Unfortunately humans aren’t well-suited to this kind of task, whereas an AI could handle it quickly.
What is Crypto-jacking?
Crypto-jacking occurs when an attacker infiltrates a network and begins using its computing power to mine cryptocurrency. And actually, per RedLock, this isn’t even the first time attacker have used unsecured Kubernetes consoles as an attack vector. Aviva and Gemalto have also been crypto-jacked.
But the Tesla attack had some marked differences from its predecessors. Per RedLock:
Unlike other crypto mining incidents, the hackers did not use a well known public “mining pool” in this attack. Instead, they installed mining pool software and configured the malicious script to connect to an “unlisted” or semi-public endpoint. This makes it difficult for standard IP/domain based threat intelligence feeds to detect the malicious activity.
The hackers also hid the true IP address of the mining pool server behind CloudFlare, a free content delivery network (CDN) service. The hackers can use a new IP address on-demand by registering for free CDN services. This makes IP address based detection of crypto mining activity even more challenging.
Moreover, the mining software was configured to listen on a non-standard port which makes it hard to detect the malicious activity based on port traffic.
Lastly, the team also observed on Tesla’s Kubernetes dashboard that CPU usage was not very high. The hackers had most likely configured the mining software to keep the usage low to evade detection.