 Today, I will talk about the EV charging points. Basically, I will just explain a specific one that I find it in Europe. And basically, you can use it everywhere in Europe. I will also show the map, then you can imagine. I'm John Kurnas from KPMG Netherlands. I'm working as a senior consultant and mostly doing penetration tests on web applications, infrastructure, and sometimes also IoT and ICS. Sorry? Okay. All right. Great, great. Okay, this is my contact info. If you want to ask something or discuss about something on IoT or ICS, please don't hesitate. For a disclaimer, basically I did this research by myself and my company doesn't involve on that. So if someone wants to sue me, just sue me, not my company. And I'm a little bit nervous because this is the first presentation, recorded presentation for mine. So that's why I feel a little bit nervous. Please help me. So on agenda, we will talk about the introduction of the EV charging points. Then I will try to explain the threat that I find. Then the consequences we will discuss. Then we will go into the details and I will explain more details. Then I will show you just a small metasploit module that you can make a denial of service of this EV charging point. This is a basic small module, but you can use it. So let's start. So this is 100% SunSu Free InfoSecTol because probably you have a lot of quotes from SunSu on these presentations on these days. So I will just skip that for the introduction. So it's a little bit confusing because EV charging points, electric vehicle charging points are in somewhere between IoT and ICS-KDA. So basically, electric vehicle charging point is a device that you can supply electric energy to recharge your electric vehicle. And nowadays, manufacturers are trying to connect these devices to the internet and that makes a little bit trouble for them and also for the clients. And previous research done by, for charge point, it's another, let's say, manufacturer. This research done by Casper Skill Lab and for the Schneider EV Link positive technologies done a couple of research on that. So basically, the idea, they are relatively new on the field and they are just building to work. So security is not a concern in the beginning, but since they are connecting to the internet, now it's a problem. So based on these previous researches and also mine, we are considering the security maturity is quite immature on these devices. So basically, I completed an engagement for these devices, a couple of, last year, actually. And then when I was writing the report, I just wanted to check if I write the name correctly. I just googled the name of the device, as you can see over there, and it showed up on the first page. Then I said, what? Yeah, basically, I mean, you are not expecting these kind of devices are connected directly to the internet and indexed by the Google, right? So let's discuss about the threats. So after that, I checked Shodan and I realized with this map, so basically, on the beginning of 2018, there were 200 devices connected directly to the internet and indexed by Shodan. After, in the middle of 2018, it come up 300. And as you can see on the map, it's all around the Europe. So basically, if you create a smart map, you can travel around by using these charging points, you can travel around freely because basically, you can compromise the device on the internet and you can charge your car. And I will also show that later. So now, this is a new one. They are appearing on the US also now. Maybe, I don't know, at the end of this year or next year, you can also do it in here. So the consequences, so what? Basically, you can compromise the device and you can get root. So if you want to create your next mirai by using these devices, you can. And the details. So the first vulnerability that I find on these devices, authentication bypass with direct request, so the web applications of these devices mostly are not secure enough, so it's a quite straightforward vulnerability, as you can imagine. So application was not that good, it's basically broken. So the access control was only on the login page and the rest is not that secure. It wasn't covering by the authentication scheme, so it can be easily bypassed. So as you can see in here, there's a login screen over there for the setup.html page. It's the, let's say the first page that you, when you try to connect to the device after you find the IP, you'll see this. So I mean, you can also guess the password, of course, but I decided to take a look to the source code of the web application. And yeah, basically by first browsing, you can go to the other pages of the web application. I will show you later. Then you can have access on the other pages. Basically, it will also affect the management interface of that device. So when we check the source code, we are realizing there are a couple of pages except setup.html, like index.html, and also there's a Java file, upload.scaled.jar, and also a couple of, let's say, informational subpages like repository, device ID, and logs. You can also check the logs, but I'm not considering to check that because it's just an information disclosure. So I try to connect to the management interface by using, as you can see in here, upload.scaled.client, it's in index.html. So yeah, it was successful. So there were no authentication for this page specifically. So even if the device has some password for the setup.html page, you can just browse the other page, like index.html, then you can connect to the device and you can control the device. So basically, if you can see on the screens, there are two plugs, A and B, and you have to full control of these two plugs. So what can be done with this? And I don't know, you can put it to the remote start, click to the remote start, then you can charge your car freely. Then attacker may abuse this to get someone, let's say, power from that, and also charge the car. And what if they click to remote stop? Let's think about it, someone is connected to the EV charging point and charging their car and you are just clicking remote stop, and after he come from his work, his office, he's realizing the car has not been charged. And also, you have an option that you can disable the plug. So basically, if you click to disable, then the charging point will be turned off, so it will be disabled, it's sort of a denial of service. And sometimes, it's also another possibility that you can lock the connector, so when you lock the connector, it will just stop connecting to the device. So basically, it has some sort of a, I don't know how you call it, hook for the connector that because someone, we don't want someone steal the cable when we are charging. So if you lock that connector, someone else also would not plug in. So as you can see in here, these boats are now open, quite ready for charging, but if I click to the remote start, as you can see, it's starting to charging and also locking the device. And at the same time, you can also stop it. So let's come back to the source code, web application. Then you're realizing we have a Java code over there, right? So for downloading this Java application, also there is no authentication, so if there is authentication on the web application, you can freely download this application and then you have control for all these charging stations. You only need to supply, you only need to provide the IP address of the other charging points because Java application doesn't have any authentication, it just gets the IP, then you can control the other devices. So you can hack all these devices by using this Java application. So yeah, there I am downloading the Java application and I'm just running it, then it asks me IP address of the device, then you are connecting any device and you can freely control it. So the other vulnerability that I find on these devices is also quite straightforward, or as command injection on the web application and the thing is you need to provide the password for connecting the setup HTML. I mean, if there is a password and you couldn't guess it or you couldn't find it, it doesn't work, of course, but mostly these devices doesn't have any password, they are not setting this up. So the pink feature, of course, as you can imagine, is vulnerability OS command injection attacks and the attack surface, as you can see before, connected ones are already indexed by showdown, by Google. I know, yeah, it's really easy to find these devices, basically. So let's increase the attack surface. Most of the EV charging stations doesn't have any authentication on the setup page, so they are not, as I mentioned before, they are not setting up the passwords, mostly. And after accessing this setup HTML page, somehow, if you provide the password or if you find it without the password, it's really quite straightforward to exploit it by using the pink IP feature. So I am just using the back ticks to run my command. I just tried to create another page for the web application to see if my command works, then it works. And I realized I can run commands on these devices, basically. I just use the back ticks. As you know, everything you type between the back ticks are executed by the shell just before the main command. So main command was the pink, but when you are writing the back ticks, it was running the command that you write over there. So let's double the attack surface, increase attack surface. So using a default password is encouraged by the vendors, because it's written on the vendor's manual that I will show you later now. Let's check this. It's recommended leaving the default settings according to the table below. Default password is admin and password is one, two, three, four. It was in the owner's manual. And then I see it. It's also possible to find it online. And when I see it, it's it. So let's give some more details. So I tried to run some commands and I succeed. Then I created my reverse shell by using MSF Venom. The device was using the ARM processor, so I created for the ARM. And created the executable Linux file, because it was quite easy to run it. Then I tried a couple of times. Of course, I failed a couple of times before, then somehow it worked at some point. And I just also created a Python simple HTTP server to download my payload to the device. And also created a listener to get a connection back to me. And I used curl to download my payload to the device. And after a couple of trials, I succeeded. Then I run the executable Linux file, then I got the shell, like that. Quite smooth. And then I realized it's instantly a root shell. So yeah, the rest you can imagine. You can create your own boats by using these devices, or I don't know, you can use for something else. Then I reported that to ICS-Chert. In the middle of 2018, I reported, it took almost five months to get the response. After this discussion, ICS-Chert acknowledged and also discussed with the vendor. They fixed it somehow. They fixed it for not all the vulnerabilities, not for the remote code execution, because I think they couldn't do it. They told me they fixed it. I also tried again with an e-firmware. I did it again, at least I break the device again, so I couldn't get the shell back, but I just break the device. But they told me they fixed it. I already warned them. Yeah. So the bonus, as a bonus, I created a Metasploit module for denial of service because denial of service is quite easy. You just write a reboot by using it with Bactics, and that's all. So yeah, because I'm quite lazy, I didn't want to create a whole remote code execution module for that. So I just saved my POST request, and I created this module by using the POST request, and that's all. I'm planning to share the POC module end of DefCon. And this is all what I have. Thank you very much for joining me. And if you have any questions, or if you want to contact me, please don't hesitate. Thank you very much.