Securing the EV Charging Ecosystem

Ready? Whatever. I gota wait for this person to first. Gotcha. Gotcha. If I can do the introduction, I'm gonna need your mic. Go for it. Sorry. I know you're much taller here. Just that. So, we're going to have to change it. Hello again. For people who have heard me speak many times, uh, our next speaker, I am going to read the bio again. So, I gave Hacker Tracker a second to pull up because Hacker Tracker decided to crap out immediately on me. Cool. All right. So, our next speaker is Danielle Maguire. They have eight years of experience in electric power cyber security and the security of industrial control systems more generally. When she's not doing that, she enjoys

reading, cooking, and tinkering with electronics. Her main technical toolkit includes Python, Bash, C, microcontrollers, SBC, and SBC's. She is currently learning Rust, containerization, RICV and radio. She would love to meet people in chat. Good icebreers include how can I get started with hacking EV chargers and what is the relationship between cybernetic and surveillance capitalism? And the time is yours now. Thank you. Uh hello. Thank you everyone. I am really excited to be here. Uh thank you for that introduction. My name is Danielle Maguire. I have been working in uh ICS uh cyber security for almost a decade now. Um I am currently looking for work if anyone is knows anyone or is looking for an OT professional

themselves. Um and we will not be talking about uh cybernetic capitalism or surveillance capitalism today, but hacking EV chargers. And we're going to look at doing this in a couple of different ways because these are vulnerable in a lot of different ways. Um but primarily we're going to look at uh hacking individual models and then hacking the uh communication protocols themselves. So this is a very simplified uh diagram showing the EVSSC ecosystem the EVS ecosystem because there is a complex interplay of actors assets and technologies here. Um we will look at a more detailed uh depiction of this later on. But what we have at this point is we have the car, the charger, the cloud

management, and the utility. The charger we call EVSSE, electric vehicle supply equipment. The charger or the cloud server we'll call the CSMS, the charge station management system. And then the utility, it's like your electric company who you pay your uh electricity bill to. And critically, that's one of the things that I want to point out on this diagram right here. You can see that they are showing AC power flows, DC power flows, and communications flows. Uh when we look later, we will see the communication flows in more detail. But at this point, I just want to note that no communication occurs between the utility and the ch car itself. And although it does have some uh communication shown

between the utility and the EVSSE, um this is not the control traffic for the EVSSE. This is the utility talking to the building management system if there is one. The utility has no ability to monitor or control this EVSSC. in a typical deployment. Every uh utility in North America is different. Um mine owns no generation assets and also no EVSSE for like customers like the general public. We have a couple on our corporate campuses. Um but the utility is not the person that is responsible for securing this equipment. That is the responsibility of the individual owner operator. in Pittsburgh. Our t our top three customers who have EV chargers are EV dealerships, um bougie apartment

buildings, you know, that one apartment style that goes up in every city made of corrugated steel and um the parking garage by Google Pittsburgh. So, it's not something that the utility can do. It's not something that to my knowledge any centralized organization is able to do, but it's going to be a decentralized and cooperative effort. Um, and this is really important because EVSSC is a growth industry. Um, some of you might know that we are in the midst of a climate crisis that might kill us all. Um, and a lot of smart people are working on this problem. And one of the major challenges that they are running into, I want to show you this is

that EVSSE significantly um is increasing the load on the grid as it exists today. If we put every single EV charger in a botnet and then turned them all on at once or turned them all off at once because either is sufficient to uh destabilize the very precise balance between uh generation and consumption of electricity that is necessary to keep the electric grid stable. If we were to turn all of our chargers on or off as they exist on the grid today, there is not enough load to significantly destabilize the grid. that is not a um threat vector or a threat scenario that we are too concerned about right now. But this might change because pretty much everything that you

have probably seen in the wild is a level two DC charger. There is um DC fast charging that is available for consumers now. I have spoken with folks who own it. But uh the kind of things that we are going to be looking at today and specifically when we look at what has already been done the research at pone to own it is uh level two chargers but the Tesla supercharger and extreme fast chargers are both orders of magnitude uh they consume orders of magnitude more energy. Uh real fast for folks that uh maybe don't think about electricity all day. Um electricity is the flow of electrons. Um the push that those electrons receiving is the

voltage. Um the rate at which those electrons is are flowing is the current and when you multiply the voltage by the current you get electric power in watts or kilowatts or whatever. And then when you multiply the power by the time you get the energy. So kilowatt hour is a measure of how much energy uh something is going to use and its wattage is uh how much energy it uses over time. It's jewels per second. So what we are seeing here is that these extreme fast chargers are consuming 50 times as much or they're consuming energy at a rate that is 50 times greater than these level two chargers. And then when we compare these

with other household appliances, and I'm sorry, I know this is really hard to see, but uh the level two here, if you can see, is 7.2 kow. And um yeah, the uh air conditioning, sorry, air conditioning for a room is, I think, 1 kilowatt typically. And we have the central air here is 2 to 5 kilowatts. We have the um well pump 1/3 to 1 horsepower well pump gets up to 1.2 kilowatt. So when we're talking about uh level two chargers, those are still on the same order of magnitude as the traditional household appliances, but the extreme fast chargers are going to be orders of magnitude more powerful, literally. Um and this is an example

level two charger that we're going to look at today. And I will make these slides available afterwards. also feel free to take pictures of them. But the um I'm going to Oh, I would like that. Thank you. Um

Thank you. Yes. All right. This is a level two charger with max uh 12 kW typically uh 7.2. As of last fall, you could have it for 500 and $550. And the things that I want to point out on here, it has Wi-Fi, it has Bluetooth, although I don't think I put that there. It has 90 days of charge data locally. It uh does its firmware updates just right over Wi-Fi or on some models over Bluetooth even. Um, and we will uh look some more at these internals, but specifically it's using an ARM9 processor on its main control board. It's using uh some RAM and some flash. And it's also got a secondary um well,

it's got a Bluetooth model and it's got a secondary MSP 430 chip on its metrology board. And this will be important in a second. So, uh who here has ever done any hardware hacking before? Two people, two and a half. All right. Two and a halfish. Um well, that's okay. Uh so, the deal with hardware hacking is pretty much try to get the firmware. Um, if you can get the firmware and analyze the image, then typically, uh, a lot of the skills you're going to use are your traditional, uh, memory corruption, uh, vulnerability research or just privilege escalation on a Linux box because these things are almost always Linux boxes. So much worse when they're Windows boxes.

Um, but on this board here, you can actually tell a lot about it just by looking at it. And by the way, all of these uh internals that we're getting are from ZDI from the Pone to Own Automotive Competition in Tokyo. We will be discussing that more in a bit, but they were good enough to put uh pictures of all of the things online. Um so it's not just this uh Charge Point charger. Um don't mention this outside this room. Well, the reason that we're talking about Chargepoint is that I happen to know that Charge Point is what is deployed all over the city of Pittsburgh right now. Um there are different models. Um, and this was the charge

point model that was in the pone to own competition. Great. Thank you. Um, so but when we're looking at this, you see that there are a few chips on the front of this control board. Um, you see that there are do I have a not a cursor, I guess. Um, generally the bigger the chip, the more complex it is. You got to shove more transistors into there. Um, you also know notice the pins that are coming out of these. Um, those two right there, you can see the pins. They're visible. This one right here, it's got its pins underneath. Um, guaranteed. Um, it's probably got about 64 of them. I could have looked that up, but I chose not to.

Um, but yeah, uh, there are a couple things there. And then everything else on there is a passive component. Um, resistors or capacitors or in some cases inductors, also diodes and transistors. And the important things about these is that these just respond to the electricity signals that they receive. There is no intelligence in them. They're dumb devices basically. So there's not really anything for you to hack unless you're going to try and hack by giving it too much voltage. Um but let's look at the metrology board because that one a second ago was the control board. It has very small components because it is handling a 3.3 volt or 5V circuits. um this has much larger components because

it is actually measuring the electricity that is charging the car. Now we're talking tens of volts, even hundreds of volts. Um there's components in there to uh rectify the power and smooth the power and make sure that the power doesn't exceed any um points that could uh damage the equipment. And you notice that all of this equipment is much bigger because it has to be it has to be physically larger in order to handle the uh more powerful electricity that's going through it. So um just quick show of hands. Who thinks that we are more likely to find a vulnerability here in this control board with its uh four uh integrated circuits? All right, one person. Thank

you. Who thinks we're more likely to find it on this metrology board that has one IC and a bunch of inductors and stuff? Couple more people. Um, you are correct. Uh if anyone here has ever watched a series of uh YouTube videos called I think make me hack um but Valerio Detro who wants to be your uh friendly Italian hacker neighbor um has put out an excellent series of videos on hardware hacking for absolute beginners. um he will take you through the entire process of not even having a device but doing open source intel on like the FCC database or there are wikis of people that have already um done a lot of work on a lot of devices and have shared

their information. Um but one thing that he always always stresses is take the easiest path first because there are a lot of ways for things to go wrong. If you are hitting roadblocks on a particular vector, it is possible and likely that there are other vectors available that don't have those roadblocks because the creators of the device simply did not put them there. So he always says if you hit a roadblock, try something else. And so that's what I'm here to say. There is a lot more on a lot more protection on the control board because obviously it's a control board. No one bothered to do anything with the uh MSP 430 on the um on the

metrology board. And before we start to um dig into the uh CPH50 consumer charge point a little bit more, um I just want to say that this is not just this vendor. Um I'm picking on this vendor because I see them a lot, but um all EVSC is vulnerable. I said that there were um pone to own competitions in Tokyo. Uh pone to own automotive that in 2024 and 2025 offered uh EV chargers as a target EVSSE. And what they found is I believe last year in 2024 every single device was ultimately um owned RCED I believe. Um and this year we don't have all of the results yet. Um we are going to get

those results almost certainly uh during hacker summer camp when people released their findings during uh Defcon and Black Hat. Uh but this year what we do know is that there were 39 uh zero days that were discovered uh hundreds of thousands of dollars and prizes given out. Um there were two specifically in the um Tesla wall charger. I believe four teams uh hacked Tesla with two unique ODS. And we'll talk about Tesla in the next slide. But one thing that I also want to stress is that as it exists today, there is not enough of this on the grid to destabilize the grid if they are all turned on or off at once. But this may

well change over the next 10, 20 years. Um especially with a lot of the other changes that are necessary for the electric grid to uh get through the climate crisis. And I'm just going to get this out of the way now. Um, oh, well, we'll talk about that in a second because I already built you up for this. We needed to talk about Elon. Um, I mean, yeah, he is a laughable man. He is a sad, pathetic little man. Um, but he's also a Nazi and he has a lot of power right now and he is a major uh EVSSE manufacturer. So I showed you um one thing I didn't show you I guess um

but at Pone to Own they have maybe seven or eight different vendors of EVSSE and part of this is because the Biden administration as part of its uh infrastructure recovery act um put billions of dollars into trying to build an alternate um EV charging infrastructure in the United States to Teslas. Uh Tesla uses a proprietary uh charging point that they license out to uh the auto manufacturers. Um it's the exact same strategy that Apple uses to get you to buy proprietary Apple products. Um well, I cannot predict the future. Um but as long as Elon Musk has the power that he has in the federal government, I think it's fairly safe to say that we are not going to have an

alternative uh EVSSE infrastructure. Um, I think that uh there is still going to be a focus on modernizing and expanding grid capabilities. Um, because I think that no matter what political party you're on, uh, people recognize that the things we want to do with the electric grid in the 21st century, the grid is not handled is not ready for. Uh, it's pretty much the same design that we've had for over a hundred years. It's people sitting in a control center somewhere sending power from generation sources down to customers following very um deterministic schedules. But the grid of the future is going to have people sending power back up to the grid from uh solar or wind. It is uh

non-deterministic because solar and wind um are variable generation as opposed to the kind of known generation that you would get from burning coal or natural gas. but also um nuclear. Uh and there's a lot, but I think that it's safe to say that at this point um the American auto industry is expecting to um just license the proprietary Tesla charger. Uh so we will see where everything goes. I think that it is safe to say that probably um there the importance of pentesting individual EVSSE hardware models may not be as important but um the broader thing of we are putting a lot more assets onto the grid is not going to go away. Um and

also this is why I pointed out that Tesla had two zero days discovered at Pone to Own Automotive in January. Uh just to show that like I said there is not one vendor that does EVSSE charger security better than the others at this point that I have seen. Um Tesla is just as vulnerable as your charge points or your juice boxes or your hotels or what you what have you. But back to the CPH50. Um they got root on this thing in 30 minutes. They talked about it. I said that it took uh actually way longer for them to get the charger than to get root. And not only did they get root in uh 30 minutes, it was

a remote code execution. No authentication over Bluetooth. It was password inject no command injection in the password field. Command injection in the password field. I was reading the write up beforehand to make sure I was remembering that right. And yeah, um they don't want to store plain text passwords, so they pass your password to a Linux command that's supposed to encrypt it. Um something in the OpenSSL suite, I think, but they just it's just a like percent s inside something that they pass to system. It's bad. Um, but we also can use this to understand a little bit about how hardware hacking works because once you get to the actual uh digital communications, it's pretty

much the same as um any other memory corruption vulnerability research. But how do we get to that point? and Computest Sector 7 uh credited some Kasperski research here that showed that this um CPH50 like pretty much all embedded devices uh it is a Linux device and it runs Uboot and it has a JTAG interface and this is also something that Valario uh DGMO has gone into a lot of information on um finding your hardware debug interfaces. There are a couple of them. There's um I should not have said that when I don't have any others off the top of my head and none on the board, but there's JTAG and there's other ones, but most people use

JTAG and it's just a few pins. There's like a UART. Thank you. Thank you. Um it has pins. It has a receive pin and a transmit pin and a voltage set pin and a ground pin. And it's really just a serial communication. You can use a standard USB to serial converter. In fact, I think that is what you use unless you have a JTAGulator, which is a dedicated hardware device for automatically determining the details of your port. Um, you find these hardware debug ports by looking for sets of exposed pins on the circuit board. Once you find them, you can use a multimeter to determine which uh pins are static high voltage, um, static ground voltage, and

fluctuating voltage. and then try a few different pin connections until you find one that gets you the information that you need. Um, so that's how you talk to these things over the J-TAG interface, which almost all devices are going to have at least one. Although one thing that a manufacturer might do is they will have the J-TAG interface somehow disabled on their production devices. So you might have to find a way and sending it and enable is almost always like sending an electric signal to the right place. Uh but once you have the J tag um this thing was set to uh use auto boot to just uh boot up into the binary that they wanted. They didn't want to do

that. They wanted to explore the uh Linux file system and operating system. Uh so they described how Kasperski I think downloaded the binary image and then patched the image patched the password validation functionality so that it would uh allow Kasperski to use their password. But um the Comput test sector 7 guys said that sounds way too hard. We want to do the easiest path first. So they just booted into single user mode. Um and then they added their own user and then they started poking around and they found out that yeah, Telnet is just listening on the local network and it's got a set UID shell. Um so sorry this is different than the um

password injection one. They have so many vulnerabilities and they write them up. But what I'm trying to say here is that the vulnerabilities themselves are straightforward. Um the hardware hacking process is also straightforward. Um and if this if folks are looking for CVES, these are still very juicy targets. Um they may not be as critical uh because EVSC is in flux right now. But there is a lot of other critical grid technology that this same uh principles apply to. be it uh deers, smart inverters, battery energy storage systems, uh vehicle to grid. Um I don't know if I said AMI, advanced metering infrastructure or smart meters, but there's a lot of tech to research and uh a lot of

vulnerabilities to find. Um and here are some further links. Again, I will share these slides afterwards. Okay. So, yeah, looks like we're about halfway through and that's good because now let's go back and let's talk about the EVSSE ecosystem in greater detail. Uh, I showed you earlier that we have the CSMS in the cloud, your charge station management system. You have your EVSC, uh, your electric vehicle supply equipment. You have your car and you have your utility. So in this model right here, um this and this the um EVSC network operator and the grid services aggregator up there um are both uh major components of what might be considered a CSMS on the other diagram. Uh right here

we see the EVSC. We don't actually see the uh car itself on the diagram. We also have the building management system right down there which I mentioned. This is what handles like the lights and the air conditioning for this hotel. It's a very very uh under inspected attack surface. Um has anyone here ever pentested a building management system? Wow. Okay. That's why your keynote. Uh that too. Uh but yeah, very underexposed. Um, and then you've got the utility over there on the far right. And it's a little hard to see. I apologize, but all of these uh red connections here um are ILE E 2030.5 or open ADR 2.0 and these are automated demand response protocols. Um,

one of the ways that we are handling the fact that um, wind and solar are non-deterministic and variable is having a protocol that can turn on demand assets on and off dynamically um, for the exact balancing of the generation of power versus the consumption of power. Um, so that is how automated demand response is meant to work. It is still very much in progress. Uh but that's what these communication between the utility and the building management system are. It is not the utility sending um OCPP the open charge point protocol which we will discuss more in just a second but it is sending these open ADR signals that are designed to build a interdependent decentralized

um geographically and organizationally disper dispersed network that is capable of dynamically um retaining stability by um sending communication back and forth about what is needed and who is doing what. It's really fascinating stuff. Come find me if you want to talk about it. Um, but it's not the open charge point protocol. The open charge point protocol is what is used by the CSMS in the cloud to manage the EVSSE. Um, it is pretty much everything I've seen in the wild uses OCP 1.6 6 without the security extensions. There is an OCPP 2.0 and an OCP 1.6J that bring the security extensions from OCPP 2.0 back down to OCP 1.6. And the major one here is that none of this

traffic is encrypted by default. Um, this is all plain text. This is all right over the wire. If anyone here has ever maninthemled something, um, the attack that I'm about to show you is not going to be very novel at all. Um, but the critical thing here is OCP 1.6 has some commands to start and stop transactions, to ask the cloud whether or not somebody is authorized to use the server or to use the charger. Um, and also to update firmware. um whe both do I need a firmware update and give me the firmware update. So someone that is listening on the local network and has the ability to respond to things faster than the

legitimate um charge management server can can basically do whatever they want. Um let's look at that. So, we're going to walk through this man-in-the-middle attack. And um for those of you who have done a lot of man-in-the-middle, I apologize. Um it's not going to be very interesting. I'm also almost certainly going to make some technical mistake. Please be nice to me. Um but what happens is that when the management software tells the OCP client inside your um charger that it is time to do a uh firmware update, then that client goes ahead and sends the request for firmware over to your legitimate um charging service in the uh far right. But if you are sitting on the same

network then and in this situation they just use the tools etercap and uh man in the middle proxy. We'll talk about some other tools in a minute but then just you know intercept the uh firmware update. Tell the uh EVSC yeah uh I've got firmware for you. It's at this IP and it's named this. So in case you can't see, I don't think anyone can see the red IP is different than that IP. The um firmware name is different than that firmware name. But then when it goes to download it again from the same adversary, uh in this case the adversary is passing back a um a Java binary that has the log for shell uh vulnerability inside it. Um

just because I mean anyone here remember log for shell? Anyone get enough sleep? Two weeks of no sleep. That's right. Um and as we showed on the um previous slide with the pone to own vulnerabilities, there are ample vulnerabilities in all of these. So it is not at all um it raises the bar to demand that the uh attacker bring a zero day or an end day in um their in whatever charger they're attacking, but it is not a particularly high bar. And then at that point, it's just pretty much game over. and it was game over ever since the um ever since the attacker was able to tell the EVSC where to get its firmware

update from. And yeah, that's pretty much all it takes. So simple that a muppet can do it. So then let's talk about um the tool that I made and then I see that we are going a little bit uh faster than I had anticipated. We can either do more questions or I can go into greater detail on um anything that we talked about, but I think we probably got about maybe 10 minutes of content left and then we'll figure out what we want to do. Um but yeah, uh EVSSE tool. Um I would like it to be the Swiss Army knife for uh EVSSE pen testing. I am very busy and very tired. Um, but I am doing the

best that I can. And what the tool is capable of doing today is on a local area network. So we're talking if you are wired or if you're running a container simulation, it will just uh read your plain text uh OCP 1.6 traffic in real time. Um, and then on the Wi-Fi LAN, I am currently capturing the initialization vectors to decrypt that, but I haven't figured out how to get my Python script to decrypt uh, Wi-Fi in real time once I have the initialization vectors. So, that is what I am working on. But the goal here is that this will be a very straightforward turnkey pen testing solution where someone rolls up on a network where they find that EVSSE

is deployed. They get onto a Wi-Fi network by whatever means are appropriate and then from there they start a sniffer at the command line um that will then show them in real time OCP traffic as it goes across the wire. And so the major things that you're then looking for here are the start and stop transaction pair um authorization requests and the um update firmware stuff. Although that is probably not going to be a common traffic um because once you have those just simply by virtue of sending start transactions or stop transactions you are able to uh in some cases start and stop transactions. In other cases, it will be set up so that the person who

wants to use the EVSSE has to get approval from the cloud. In that case, it really is as straightforward as make sure that you have your response to the charger before the legitimate service can get it to them because it is there's no other validation in this protocol outside a simple um yeah, you might need to capture a particular uh identification token so that you can say that you are who you say that you are, but that's the sort of thing that you get just by sniffing it for a little bit. Um, so what I would like to ask is that if anyone does use this tool to um try and hack some EVSSE um or if you

break my tool for in any case, please uh let me know uh and share the data, share the use case. Uh let me know where I have done poorly so that I can do better and we can make this together the um best utility for this case that we can because yes, I want this to be something that a script kitty can use. So that then all of us can go to the owner operator of the EVSC and say yes um this is a tool that a script kitty can use. You should upgrade to OCP 2.0 or OCP 1.6J which includes uh encrypted communications which just breaks this tool. Simple as that. Um I think that

OCP 1.6 six should be considered as secure as uh electronic code book ECB for encryption or um web for uh Wi-Fi, which is just to say it's not. Um and so I have a screenshot of the tool here. Um let me see if I can zoom in on this at all. No maybe think one moment

please. You know what? Um, sorry. One moment. I know where to get us a better picture of this.

[Music]

Um so

Yes. All right. Can folks see that? Okay. Great. Great. Thank you. Um, so let's scroll all the way up to the top. So what I have here is we are using Docker containers to run this tool in two modes. Um, this mode right here is just uh it is acting in uh sniff mode. So it is listening as a sniffer. And over here this is uh emulating the CSMS and I don't have or no I'm sorry this is not emulating the CSMS this is emulating the act of querying the CS SMS. So over here we're going to see the uh traffic that the uh CS SMS sees and you see that first it's just going to

connect to a websocket with a particular uh URL. This CP1 is a unique identifier for the particular charger and it sends back an HTTP 1.101 which I'm pretty sure is just saying we need to change to the websocket uh thing particularly um is there? No. Yeah. Okay. So then over here we can see the particular um messages that the simulated EVSSC the simulated charger is using. And so the first thing that it's going to do is it's just going to send a boot notification to the uh server in the cloud. It says here that it's model is changed me and its vendor is Tudu. Um and we receive that over here. Um so I think then next it asks to

[Music] authorize. Yes, it sends the uh boot me boot notification. And then here it goes ahead and says I would like to author or I would like to ask if so and so is authorized to use this. So the ID that I sent it was just 0 1 2 3 4 5 6 7 backup because it's a 20 character thing. And over here um you can choose to have your tool uh respond to any authorized messages, any start or stop transactions with whatever you want. Uh in this case I just chose to um have it reject any particular authorized stuff. uh but then just show you how the uh start and stop work as though they were authorized. So

we have the uh authorized message come in right here. I think that these are duplicated. I forget why we are having all of these duplicated and I apologize for that. But um you see here that it sends back an immediate uh status equal blocked response which is then received over here by the um by the simulated EVSSE. And just by the way um if you go into Wireshark today, Wireshark is capable of decoding the underlying uh websockets uh connection. It is not then capable of decoding the OCP layer on top of that. Uh meanwhile, Scappy uh SCAPY, the main uh Python protocol dissector, it does not have stuff for either um OCP or uh or websockets or OCP. Um I

implemented both of those layers and it also does not have the um decode Wi-Fi in real time layer. So I'm working on that. Uh but that is the status. If you were to go and try and look for other tools, um, you can read this OCP traffic in Wireshark. As you can see, it's fairly human readable. It's just JSON structures being passed back and forth over websockets. Um but to the best of my know and that is also one of the projects that I am attempting to get done here is get the rest of the standard uh blue se blue team red team forensic suite updated with these and the other key protocols. But then um you notice here we're going

to try and do three things. We have a start transaction which gets denied, a status notification that um is sent back and then a stop transaction that gets denied and then when it receives the um start and stop transaction over here, it is pretty much up to the charge system management system to decide what it wants to do with it. there is no further the only um information that is passed back and forth is that on the authorize we send an ID tag that is meant to identify like when you're out driving and if you have an account with um charge point or any of these people with Tesla you get a little uh 20 number uh numeric ID that

identifies you uniquely and this is every time you want to um charge your car you're going to send that or you're going to tap something on the charger and it's going to read your ID and it's going to send it up to the cloud and the cloud decides whether or not that is authorized. Um the people that the Computest Sector 7 people that wrote up that um CPH50 breakdown earlier also describe how they uh went poking around the um charge point uh cloud servers for CSMS and they found a lot of other stuff there. Um I do not have any authorization nor particular expertise in pentesting um web applications. Uh but really great stuff. Definitely recommend checking it

out. But then further down when we tried to do our um start transaction. Oh, I just made that small again. when we try to do our start transaction, the only thing that we're going to send on over is uh yeah, start transaction and I made it small. Where is

the There we go. Start transaction connector ID. You see the zero up to nine up to nine. that is the same ID that we previously failed to authorize in the authorize step. So that's why the tool then does not um allow the start transaction or any of the subsequent things. But that's all it is. It's an ID tag and all of the validation is done in the cloud. So if you as the malicious actor want to send a message saying, "Oh yeah, that ID tag is fine with me." There is nothing else that the um system will check. So thank you for bearing with me there. Um, I think the last thing that I wanted

to make sure to hit on right

here. Um, what can you do if you own EVSC? Well, the good news is security hygiene goes a long way. um just making an inventory that has all of the EVSC um model number and firmware version, all of the network gear that it uses, um all of the uh network diagrams that are relevant, all authorized users and all, uh all user accounts that may be using it in general, uh authorized and unauthorized. Um for all accounts, put them in a some kind of credential management solution. Enforce a decent password policy. Um, make sure people don't reuse passwords, change it if there are breaches. Um, yeah, make sure that procedures to update the password are in

place and executed regularly. I mean, patch your stuff. Uh, you can do n minus2 versioning uh or like a delay of a couple weeks on versioning, but don't let critical security updates sit out there for months and years. And I think the biggest one, don't put don't put this on guest Wi-Fi. Uh I hope that I have shown that this thing on a local network doesn't have any suspicion. It doesn't have any fear. It assumes that if you can talk to it, you are a friend, which is part for the course for a lot of these things. But uh just putting it on a dedicated subnet with a like WPA3 and a strong password, even a pre-shared

key, um having strong user accounts, changing the default credentials. Um, I forgot to mention, but in 2024, one of the vulnerabilities that um, ChargePoint removed the day before the competition was a vendor back door in uh, every single Charge Point product. Uh, yeah, change your passwords. Um, change your encryption data. Uh, that's also not handled well. But I also have like some stuff for the seuite. A NIST 8 NIST 8473 um has or is that yeah NIST 8473 is a NIST document on creating an EVSC security program. They map to the NIST cyber security framework. It's very boring and probably pretty effective. Um we don't have to talk about that but we can if anyone wants to. Um thank you so

much. Uh any questions? Yes.

What are some of your favorite people? Uh yes, thank you. That's great. Um first up, multimeter. Um if you've ever used these in a high school physics class, a good one is like 20 bucks. Uh you need one that can do DC and AC voltage. like pretty much not a toy. Um it'll be able to do that. Um if you can get an oscilloscope or a logic analyzer, um that is great. But I would think that the single two biggest things are a bus pirate that is capable of handling a lot of different um serial USB interfaces. Um and then I'm sorry, I'm completely blanking. There was a bus pirate and then there was a different one.

Oh yeah, just a USB to um serial converter. And I mean, if you'll all indulge me for a second, um I can pull up something from my blog that might have a bit more information. Uh does anyone else have any other questions?

Yes, it's cybernetic philosophy and computers. Oh, yeah. Yes. Well, thank you. Um, so let's look at this. Um, because in this case, what I was trying to do is, uh, I wrote a custom Rust kernel using a wonderful tutorial on GitHub and then we had to flash it in this case just to the Raspberry Pi. Um, so you see over here, my friend loaned me this uh FT232, which I think is a yes, it's a USB uh TTL um transistor something logic, but just um it sends USB into 3.3 to uh 5V signals. And this thing was just like 10 bucks. So that was ultimately I think we did UART. Um yes, it was a UART. And then here I

can even just show you what it looks like. [Music] Um where is

cursor? So here we're just resetting it and plugging it back in and then you get the data. So, you see that what we've got down here. As I play this again, we have a um regular cable going to the and by regular I mean a uh micro USB going to the Raspberry Pi which then has some uh wires connected to the uh serial converter which then um send the or sorry that's a power cable. Uh there's no data being sent over that. That's just it that micro USB is just for power. the computer is plugged into one end of the uh 232 USB to serial converter and then those wires go directly to the um board. So that is

actually how we flashed the firmware on there over UART. So when we looked at J-TAG earlier, if you wanted to directly flash uh firmware onto a device, often it's possible to do that through JTAG um but it might be locked down and also it's just not the easiest path. Take the easiest path first. Uh yeah, thanks. Great question. Yes.

Yes. Yes. Thank you. Uh that's a great question. Um so what I have found is that there are computers inside your converter that are or computers inside modern cars that are capable of making web requests. So what I have found is that it is possible to have your EV charger tell the car charger to reach out to a particular um domain somewhere and do something. I have not pinpointed this exact mechanism and I have not found anybody then who has taken the next step of using this to actually through the EV hack the car directly. Um I'm asking everyone about it so thank you for bringing that up. But to the best of my knowledge, the car charger

can tell the car to reach out to somewhere. But I haven't found the exact mechanism. Thank you. Anyone else?

All right. Well, thank you so much, Rochester. Uh, this was wonderful. Yeah. Thank you.