 First of all, I want to start off by inviting Spencer McIntyre up here. Can you come up real quick, stand in front of the stage, sir? Here he is right here. Spencer works for secure sake, right? Okay. And he's been doing meter research for them. He's also doing AMI assessments as well. And what they've done is they've released an optical tool, at least a framework that you can start with. We're actually going to be talking about how I did that in just a second. But we're not releasing our tool publicly. We're releasing it to vendors. We're releasing it to utilities and to security researchers that we can confirm are working in this industry. And the reason for that is ours has a little bit more stuff. No, no, sit down. Get back up here so people can see your face. And, hang on just a second. Because we have a little bit more functionality in our tool, just built in. Spencer's broken it out a little bit. So it's his tool, Terminator, is on Google code. If you go and look it up, you can download it. You can have his code. It'll be the initial framework that you need to communicate with the meters. I'm sure he has modules that he has that are proprietary. But you can write your own. So also, with that being said, if you're a security researcher in the utility field, please contact me. Come to the Q&A afterwards. I'll get your card. We'll research it and we'll get to our code as well. So Spencer McIntyre, everybody, he's done a great job. If you haven't seen EatPeak, you should check that out as well. I use it in all of my wireless assessments. Thank you. Okay. Looking into the eye of the meter. When I first started working on meters, I went over to the carpenter ranch, Met Carpenter. He couldn't make it here today. But I really appreciate all his help because he really got me into the security field as far as AMI goes. And I had never done hardware before. So when I came over to the carpenter ranch, he said, pick up that smart meter and take it apart. But as soon as I picked it up, the first thing I noticed were two IR LEDs on the front of it, on the face of it. I'm like, what are these? And he said, well, when the field technicians have to make a modification to the meter, what they do is they first they try to contact it with the radio because they all have radios in them. But if they can't contact it, and it's some type of condition that they don't want to pull the meter off, lots of rain, really hot and they're really sweaty, lizard conditions, what they'll do is they'll use the optical port to either pull data off or reconfigure it. I was like, oh, that's cool. Can we talk to it? And he said, well, you can get the vendor software to speak with it. But all that lets you do is to program it and to read the configuration of it. Each meter that you have has specific software that you have to register with the manufacturer to get. I was like, well, that sucks. I just want to run stuff on it. It's like, yes, that's what we want to do. I was like, okay, who's done this before? Nobody's done this before. So ever since I started working on the meters, that's been winking at me. That's why I called it looking into the eye of the meter. Now, I'm cut away. Some of you know me as Don Weber, but I'm cut away. I came on with inguardians because I learned things very fast. And we needed somebody to spin up on hardware so that the utility industries knew what they're publicly facing devices, what kind of threat they pose to their whole infrastructure. So that's what we decided to help them with. And we've been really successful. This is the talk that I was going to give at Shmucon. Okay? I was going to give it probably to about 100 people at Shmucon. Looking around here and counting the people we were at Blackcat, I've now reached out to probably over 1,000 people. So thank you very much for coming. It's awesome. It's way better than that. I would have loved to give it. But somebody contacted us. I gave this out. I gave the presentation out two weeks before I did the presentation. I gave the code out about a month before. I actually got vendors responding with code updates and with requests for modifications to the slide deck so that I was more accurate. But one company didn't feel comfortable with moving forward. Wanted to speak with us more. So that's what we did. We pulled the talk so we can talk with them. And then obviously we've made them feel better because here we are today. Now, this slide was in the first one. I've updated one bullet in this because of something that somebody asked me. And it was actually something that needed to be in there. But I'm not going to talk about specific meters. Or specific vulnerabilities in specific meters. We're not going to mention vendors because we don't really need to. Smart meters are smart meters. There's about six or seven different types out there if you just count the main ones. And you're going to find stuff. We're going to talk about stuff that is a concern with all of them. But they don't apply to each one. And therefore you have to look at each one slightly differently. It's just like any other embedded device. So we're not going to talk about those vendors. We're not going to talk about anything specific. But we're still going to get some good education. Am I? Excuse me. Advanced metering infrastructure. It's the whole solution. We'll talk about it in just a second from smart meters to the back end servers. Now, meters are designed to be on the side of your house. They're high voltage electricity devices. If you take one off and you get an adapter you'll see in a second and plug it into your wall and touch something wrong, you will fucking die. All right. Who knows Travis Goodspeed here? Who's ever heard Travis Goodspeed yell? Travis has yelled at me. I started reaching for a meter. Actually that was taken out. And as I was reaching for the meter he said, what the fuck are you doing? I'm a marine. Okay. I jumped. Travis just yelled at me. Okay. But it made a point. If you don't treat it with respect you're going to kill yourself. I've seen Atlas get shocked. I've seen Q get shocked. I've seen Matt Carpenter get shocked. Q's arm was numb for about three hours. Okay. And it wasn't even plugged in. That was just the energy coming off the cap that you'll see in just a second. Okay. Don't do research on your own. Get permission. Yeah. All right. What we're going to talk about. We're going to talk about what the smart meters are so that people who don't understand it will understand it. Okay. Then we're going to talk about what security researchers are looking for. But I say criminals because that's exactly what we're looking for. We want to figure out what the criminals are doing. Okay. And they're going to look at it just the same way we're doing. So we're going to outline those steps and we'll be able to understand the risks associated with that. Then we're going to look at how that information can lead us, gather us information so that we can start building tools. We're going to build assessment tools. Some people are going to build attack tools. And then we're going to talk about the optical tool and if we get to it some of the mitigations. And if I don't get to it, let me say it now. The mitigations that I have in these slides are already implemented out there. That's why I feel comfortable talking about this. They're not all implemented by every solution, but just like everything else, you know, people are trying to build a good solution. They're doing their best. And it's stuff like this that's helping them understand it and get other mitigations built in. Now the purpose for this presentation is to get the word out. I want to educate people. I wanted to educate a hundred people at Schmucon, but now I've got to educate a thousand. So I'm happy. But I've also educated the vendors. You know, they've started making talking completely differently about their solutions now just from that one talk getting canceled. I wasn't scared about talking about this because we had released the AMI attack methodology back in 2009. Okay? Everything we're going to talk about here is what basically I use this as a guide to help teach me hardware, teach me meter assessments, teach me embedded device assessments. Okay? And we're going to walk through that. And we're doing it to do things like generate anomalous data so that they understand what it looks like on the back end, on those servers. So this is the basic breakdown of an AMI methodology. The stuff that's outlined in red, those are the publicly facing devices. The one on the far right is a smart meter. Now smart meters can be meshed together. They either communicate over 900 mega or, yes, 900 megahertz, communicating with other meters and with the aggregators that are, excuse me, that are on the pole top. Or they've got network interface cards that have, they have network interface cards that have cellular modems in there. So 2.4 gigahertz. And those won't need an aggregator except for in remote locations. And those will just talk back directly to the cell tower. But we're concerned with all of those things in the red. The rest of this stuff, the cellular network, the edge resources like the routers and the firewalls back into the internal, that's just like a network. Okay? That's just a business network. We do the same types of assessment, helping them do web assessments, database assessment, looking at configurations of the different stuff on the internal side. But we're talking about the external, publicly facing devices. So what are the criminals going to want to do? Well, let me tell you this. We've got five bullet points up here. Utility industry has been doing this for 100 years. They've got a list that's about four times this long of the things that they're concerned with. Okay? All right. So free energy. Every time I talk to somebody, I'm like, yeah, man, I do research on smart meters. And they're like, oh, man, can you get me free energy, dude? What's up? And I tell them, no, I don't do that type of research. I mean, I know a lot about a smart meter, but because each meter is different, doing this is different for every meter. But it has been done. Criminals are doing this. Back in, I believe it was February. It might have been a little later. You can check Brian Krebs's blog. And you'll see that he talked about this happening in Puerto Rico. What happened is, is that there was an FBI report, investigation into utility, stealing energy down in Puerto Rico. And they estimated that if it continued, it had been about $400 million worth of theft of energy. They actually got 10% penetration. What I mean is, they had an insider steal the software that was supposed to be programming the meters. They knew the password, because it never got changed. And they were able to modify 10% of the meters in Puerto Rico so that businesses and residents got cheaper electricity. So it has occurred. This is a problem, but it was completely ignored because it was suppressed by the FBI. Okay? So that's why we're trying to, that's one of the things we're trying to help people understand. Corporate espionage, it is a concern. If you can understand the consumption of a business at a certain point, a critical point, you know, are they going to make their deadlines? If you need to understand that? Are they working on something new and something good? Okay? They probably don't want you to be able to read that data off of there. But if you can't tell from the tools that are provided to you by the manufacturer, whether or not that information is accessible without a password, you need something to help you understand that. There for another reason for our tools. Access to the back end resources. That's a given. Okay? Can somebody take a meter, take an aggravation point, and can they get to the servers on the back end and insert shell code? Okay? But also, you know, they're just like any other business. They try to consolidate resources. So they're skated devices, the stuff in their substations, those potentially could be communicating through the aggregators. Alright? So can I hop from a meter? Can I do something to meter and hop over to their skater network? So they're concerned about that. A kinetic attack. I have to explain this one a lot. And they, a lot of people don't have their heads wrapped around this very well. I say, yes, I can disconnect your meter. And the first thing they say is like, well, I can hit it with a baseball bat. They actually call it the baseball bat attack. Or they say, well, I can drive a truck into it. The truck into the substation. Okay. Yeah, you can do that. But when you walk up to the meter, if I change it via the optical port, the configuration, if I turn it off via the optical port, which one can you tell happened? The one that has been beaten up with a baseball bat? Or the one that has been changed via the optical port? You're going to know instantly. And here's why it's a big deal. They hate these pictures. These two pictures up right up here? They hate them. Because I'm pointing out that there's a residential meter. Commercial meters don't have a disconnect. But residential meters do. So I can disconnect, and that means you turn off the power. Now, if I am able to do this, I have the security code and you do need that. And I know which function to run. I can turn Sprint off on this cell phone tower. I can't turn the other two off because they're on commercial meters. So they need to understand where they're deploying these types of devices. And then they turn to me and they say, oh, well, we just turn off that functionality. Well, you just use a function to turn that functionality off. So I turn the functionality on, and then I turn the meter off. Thank you. Okay. And then obviously we all know, we know about hacktivism. We talk to people a little bit. People are getting more educated about that. But at the same time, they're going to use any resource they have to meet their agenda. Okay. We are talking about smart meters, but this is what kind of a good example of an aggregator on a pole top. The concern about these things is that, you know, they're high up on the pole. They're connected to the power lines usually. Okay. And is anybody here want to steal a transformer? Because you'll probably fucking die. I saw the hand go up. I saw you. So, you know, I mean, what do you need? You might be able to pull copper out of there or something like that. So somebody may be able to do that. But when they figure out that there's network capabilities on the pole top, you don't think they're not going to go for it. I can sweep those lines really easy. Actually, the neighborhood that this is in, it's on a side street. No houses face it. And there's a ditch on the other side of it. It's not too hard to steal these things. And if I can figure out a way to modify these things and put some type of device in there, the next one I'm not going to steal. I'm just going to hop up on it, they have no tamper detection and alerting that I'm going to put my device in there. And I'm connected until they finally figure out that I'm in there. And I'm using this as my entry point. I put the OMG on there because at first I was like my fucking god. You know, because it's a network port. You can just tap, you know, throw my laptop right on there. I did talk to somebody who did an assessment on this one. He said they have actually have that locked down really well. Bigger concerns, bigger priorities that they needed to address on that and they did work on it. But only one of them winks at you. At least one winks at me. Every time I pick it up it's still hey, I need you to talk to me. So how am I going to get a meter? Well, I just, I call the meter vendors and ask them to give me one. That's how I do my research. Sometimes they're nice, sometimes they're not. But how are criminals going to get out of their cars to go out there and pull this meter off and toss it in the back of the truck and they're going to drive off. But they can do it themselves if they want to, if they don't, then they have somebody else do it. You know, I mean, this is freaking dangerous right here, but it's just, I mean, even if it's locked, if they don't have a tamper alarm, or who cares if they have a tamper alarm because they're not going to do it, you know, you don't have to plug them into your house to work on them. That's the actual example of an adapter that I was talking about. You don't want to take a smart meter and just plug it into this because it's still, it's still not protecting you, so please still be careful. And these pads right here with the danger on them, those are the ones I was reaching for that Travis yelled at me about. I'm going to figure out what other people are going to do. I break it down. Data at rest and data in motion. You have your microcontrollers, memory devices, radios, and that's data at rest. If they haven't protected those components, then I can just pull that stuff down. I can grab the firmware from the microcontrollers, obviously data and potentially firmware from the memory components. The radios might have firmware in them, but in motion, they have to communicate between the two. If I can tap that, and I'll explain that in a second, if I can tap that, then I can see the information that they're passing, which is actually more important because it's necessary. So data at rest, we just need to figure out what components are on there. It just takes a little bit of research. I mean the data sheets are all published exposed or partially exposed. We can, there are devices out there that you'll see in a second that can actually communicate with those. You don't need to even power the full meter to pull the memory off there. The ones on the images on the right are ball grid array components. They're a little bit more complex. It makes it harder to potentially tap these because these are really nicely designed embedded devices. They're very complex. But we can still pull those off. We can still heat up those boards and pull those memory components off. I did that for, actually Q did it. We did it for a client. We were talking to the client and we said, yeah, when we pulled the memory off, we got this other information, we didn't get very far. They're like, what do you mean you got information? The vendor told them it's all there. They showed them that and they can start asking more questions. Once you have those devices, I'm sorry. Yes, sir. Depending on the, the question was, do they have JTAG interfaces? Depending on the microcontroller, they'll have those. Radios will have different data debugs depending what they're using. Does that answer your question? The question was, are they subject to differential power analysis or vulnerability? You know, generally you're going to test for it. Usually what I do is I prioritize. I might have a particular thing that I'm going after. For this, I'm specifically concerned with the optical port. So I was going off that. I wasn't doing firmware analysis at this portion of, or it depends on what type of assessment we're doing. So we prioritize. Does that answer your question? Okay. All right. Back to memory components. So we just get devices that communicate with them. The aardvark device communicates with some very easily. You know, it's very simple. It'll power the memory component and pull the data off and then you have a data file. For the ball grid array components, it's a little more complicated. It's actually, you know, more expensive. And that's the ZELTECH on the right-hand image. But I, you know, and one of the things I want to tell you about is that the component is expensive, but if they haven't made an adapter for it, they're about $500 a piece. But the fact that I can actually call them and say, you don't have this. Can you make it and they send it to me within two weeks? That means it's not that hard. And I can pull, you know, it just makes it really easy to pull stuff off of those components that are ball grid array. And then of course there's a good fed out there that everybody can get. If you find him, I was actually hoping that I could find him and get some boards up here to pass out or at the Q&A. So if he shows up, we might have some there. But all you have to do is contact him. Look up the good fed and you can write your own custom extractors and get memory off of things that are strange and don't have a commercial tool for them. But once we do that, it's just like any other file system. But there's no pointer saying that this is the actual file or the data that you're interested in. You can run strings on it. You're going to get some interesting information out of there. You might even locate something just by perusing it. So what I turn to is I turn to the communication standards, the ANSI C12 stuff that we'll be talking about in just a second. But the reason why I do that is because things are going off of radio, so they've got timing issues. They don't have a lot of CPU power. So sometimes they just write straight to memory. So you can use these to help you understand how they are and maybe try to locate certain things within that file that you pulled out. So if we can't find anything, nothing pops out at us from our memory. And the reason why I do that first, even though it's hard, I might not do it, it's the easiest thing to do. So I grab that data, something might pop out. But then now I can start turning to data in motion. Because as I mentioned, they're only going to pass the most important data generally. So you can focus in on that data very quickly by monitoring data in motion. But you don't have just component to component communication. Meters are made up of metrology boards which count. And those have to communicate. And what's great about it, what we figured out, is that the Nick generally has to authenticate to the metrology board in order to get that information. So now it has to pass the security codes across those lines. And that's what we're going to focus on. This is an example of tapping the pins on memory components. Hopefully you guys have seen this before, but if you haven't, I'll describe it. Basically in the video, that's a logical analyzer. I prefer this Laological Analyzer. It's small, it's easy to carry, and it works really well. It's got some really good analyzers you'll see in a second. But basically it's just a, you know, we tap into the pins, we use the micro grippers to monitor each one of the pins so that we know what's going across those pins at any one point in time. And actually what the image that you see right here is the microcontroller driving the pin. And you can't have enough memory to keep that. So the microcontroller has to manage it. It has to send it the next hop, the next hop. Who understands frequency hopping? Okay, if you monitor these lines, and you save them off to a file, now you have the hopping pattern for that particular radio. Now you can start using that for your analysis into other things like finding patents, generating that hopping pattern. And if you can do that, now you're getting into the next phase that I really want to get into, and we're already working on that. The right hand side, if I can't get the micro grippers on there, if it's just line, like the Bob Gritt array components, or they're really small, I can't get the grippers to grip onto there, then I'll tap with the hypodermic needles. It's really good because it's got that point in a grip on there. But the problem with both of these things is that if I tap this with my elbow or my knee when I'm standing up to go do something, all of that stuff pops off. And you don't know how aggravating it is doing this for trying to get those hypodermic needles on there for 30 minutes just to look up, bump it, and have to do it all again. So it's really tough. So what we do is we look for debugging pads. Most of the debugging pads are for reprogram microcontrollers so that the developers have an easy way to push firmware up into the memory components. But when we go on board to board, sometime we have those as well. And the board to board is going to show the communications that's passing between the nick and the metrology board. And so we solder on that. And we pull those lines out onto our breadboard. And now we've got a more persistent connection. And we can put our logical analyzer on there. And if we understand how it's communicating, we can get devices and connect to those lines as well. So in the right-hand image you see my logical analyzer. So I'm still analyzing the lines. But I'm also putting an FTDI chip in there because I know it does serial communications. And now I can use this. It's important that's why I'm bringing it up. I can use this for serial communications. Because once I get to this point, now I can do man in the middle. I've got the lines that are coming out. I have to reconnect those lines. I can put those, make those lines go anywhere. So I can pass either those companion opponents any data that I want. I can let them communicate to each other if I want. But in order to do that, I need to understand the communication standards. And I did have to buy these. I don't think a vendor ever gave me one. So I did have to buy them. But they're only $200 a piece. So it's really not that big deal. I tried to search for them for this talk online. I couldn't locate them specifically. So C1218. That was their first stab at it. And this is so that they develop this so that they can have interoperability. So they have multiple manufacturers developing things and they all communicate the same way. Even though we all know how that works, they do it slightly differently at every organization. So C1218, it's not secure. The security code, the password, in the clear, all the other communications is in the clear. But it was their first start. It's actually a really good protocol. C1221 was their attempt at securing it. More securely. And what they did is they used DES encryption to pass a token between each other so that they had mutual authentication. But they had two problems with this standard besides the DES part. Is that everything passed after that mutual authentication is in the clear. So I still see the security code. But as a part of the standard the mutual authentication is optional. So to say that you're doing C1221, all you have to do is say that you're doing it. You don't have to do anything else. It's a fucking lie. So their answer to that was C1222. It was really hard at creating a standard so that supported networking, TCPIP you can do C1222. The problem is that they selected an encryption protocol that had not been approved by NIST. NIST didn't approve it because it's vulnerable to attacks of if you send a back... I might have this wrong but I'm going to try to do the best I can. If you send small packets, one, two bytes, it's to brute forcing the key. In this protocol you're never going to send anything I think less than 8 bytes. So it's not vulnerable to this attack. But because it's vulnerable and NIST won't approve it therefore none of the vendors will implement this until NIST says they okay because they're working on interoperability standards. So now ANSI has to go back fix this it'll probably be about 2015. Then the vendors can start doing the development so those meters will get C1222 in about 20 years. I'm just kidding. I'm sure somebody's working on it. Did that wake you up? I didn't plan that. Are you volunteering? I'll give you $10. Okay, so looking back to our logical analyzer, talking about the communications this is actually the output from a Soleilogical Analyzer and you're seeing actually the information service response packet here. And this is where they say they're going to do C1221 they just change that one byte. But what's important here is that the logical analyzer tells me what's going across these lines. As long as I configure it correctly then it's smart. For this right here it's just acing serial. The nick and the metrology board are just communicating via acing serial. And what I can do is I can not only use the analyzers to get the data it's parsing but I can export it to a CSV file. And then you know where I'm going there. How does it look? Because I've got low res. Okay, good. It came out good. So now I can start labeling the packets. When I first got those standards that I was talking about I read this for about two weeks because I'm really good at analyzing documentation and writing protocols and communications and stuff like that and it completely baffled me. I got this output and as soon as I can start labeling these bytes I'm like, oh man, now it makes sense. This is frickin' awesome. I know exactly what they're doing. I know every part of that packet. What's great is then I merge the files because you export the receive pin and then you export the transmit pin and you can merge these files. Now you can see the full conversation. The request and response. The nick card logging in. The metrology board saying okay. Identification, negotiation, logon, security. That's a security quote. Now I know how to log in. If they're using that code for the optical port that's what I'm hoping. Probably the next most important thing is the actions. The read, write, run procedures because those are still kind of hard to understand but also every manufacturer does it differently. If I can see them how they're acting, now I can start programming that myself. As I'm sitting there looking at these things, the first tool in my toolkit is a basic parser that will take both of those files, merge them together, mark all that stuff because it takes a long time to do all of that by hand. That was the first part of my toolkit to speed things up. As I'm writing that, I'm looking at it and I'm like, wait a minute. When I was working with Atlas working on the MSP430 disassembler and emulator, he told me when you're working with Python tables are the best way. Tables are the fastest things to reference. I'm like, holy shit, I've got tables because every response and request is exactly the same. There's a slight difference, there's a control byte, but I can account for that. It's exactly the same. I can just write tables to tables and if I can write the tables and I know what's coming back, now I can start generating my tools. Now that I have a persistent connection now that I can start writing tools for that, I have an advanced persistent tether. I can communicate with a device, I can send things to it and see what kind of response it gives. If I do this correctly, if I just think about what normal replay attacks do, you just send a packet. In this case, I didn't care about what it returned. Well, I cared about what it returned but I monitored to see what that response was. I didn't modify my behavior according to that response and so I would send a packet, I would send that logon packet, the negotiate packet. All the way up to the security packet, if it came back and when I analyzed what it was sending in return, I logged in correctly. So now I've got a man in the hand. So now I can receive responses via the logical analyzer, understand what's going on, know that I'm doing it right. And now I've got a hardware, this was the second one in my toolkit. A hardware client to communicate with the meter, log in, see what those configurations are and do it over and over again in a repeatable process. But I still have wires coming out of it. This is just on my laptop. On my desktop. I'm still not getting that full communication. What's great is that those meters, once they're powered, they will connect back to the radar tower. So potentially they're still communicating with that meter if they haven't turned it off. So things could be still passed on there. But it's not the side of my house. I walk outside, I walk by my smart meter and it's weakening at me madly because I want to talk about the optical port. For just 30 seconds. How many of you are in here going to stay for the next talk in this track? Raise your hand if you're staying for that talk. How many of you are planning to go to FX's talk? Shit, would you help me count? All right. Thank you. Everybody give him a big hand. Everybody lied, right? But in order to communicate with it, basically it's just developed according to a standard. They all have to do it the same way maybe. But it's just IR. IR LEDs. So what's the first thing I do? I'm like IR LEDs. There's plenty of projects out there that do that. Plenty of projects online. They don't do it the same way. And they don't do it that's easy to do for async serial. I was in a time crunch so I bit the bullet and spent $350 on the optical probe because you can buy them online. It's expensive but no big deal. And I get it. And I plug it in and I look and I've got TTY USB 0. USB to serial. Because my FTDI chip, the one that I've been sending for my hardware client was the same thing. So I'm halfway. I'm even closer. I'm one step closer because I don't really have to modify that much more. $350 is kind of expensive. I did try. There's a project out there that somebody set up. They didn't outline the pins to a normal serial that I'm used to. I'm not really good at modifying boards just yet. So I contacted the people that make one of the IR dongles, Gwana Works. We helped fund some of this research and they were able to get an initial production. It doesn't quite work just yet. But what's great is not only do they have a serial, a module that has a serial out. So now I can plug in things like an XB module that you see right here. Cellulum modum. Now I can start making wireless optical probes. People are already doing this. $350 expensive. This will probably run between $50 and $75 if they told me correctly. If you're interested in this project, please contact at Gwana Works so that they know there's interest in the new development of it. But what do I need to do? I've got a client that will send data. But I need to respond in order to speak with optical port, I need to respond intelligently. So really I've done pretty much all of those things except for the response part. And so that's what I did. I wrote a client which was the primary tool within our toolkit that we're calling OptiGuard. It's next to it for smart meter optical communications kick. I thought it was okay but we decided to change the name to OptiGuard so that the utilities would not think it's mean. We were actually going to name it the smart meter optical assessment toolkit, SMOTE. They didn't like that either. So we went with OptiGuard. Thank you, John Soria. If you weren't in here before, let me know. Okay, so the optical client. Basically it's just a whole bunch of functions that will do what the manufacturer's tools do. But actually this first bullet point I need to point this out because I was asked to do it. This is the bullet point I was asked to add. In order to walk up to a meter at the side of your house and use our tool, you have to have the security code. It doesn't mean that you can't do things without it. It's basically what our tool is designed to do. We don't need a security code to run it, but if you want to make modifications to it, you have to do stuff like the research that I just talked about in order to get it. Or you need to pay somebody to give it to you. So if you don't have it, but you have the tool, you just can't run around rampantly changing and make them modifying things. But what this allows you to do is it allows you to test functionality that the meter manufacturer software don't give you. One stuff without a password. To see if are there any tables which is where the stuff that contains the data, configuration data, the settings and so forth, they call them tables. So you can pull that table information out. Now you can attempt to pull it out without a password. Some manufacturers protect everything. Some manufacturers only can protect the ones that they think are important for security. But they've made that decision instead of the utilities. Now we have something that the utilities can use to test. Pull that information out and say, you know what, we don't mind about tables one, two and three, but you really need to table number 15. I can read that without a password and you need to protect that. Same with procedures. Did somebody mess up in development and leave a procedure in there that allows you to do something such as disconnect the meter without a password? With the regular manufacturer tools, you can't test for that. But now we can test for it as well. Actually, what we were able to do once we had the security code, now I was able to run every procedure at the same time. So I ran every procedure and then with, okay, first I just sent no data and didn't get any data, no joy. But then I sent a zero. I'm sitting there and I'm waiting and then all of a sudden the meter turned off. And that's the sound of the meter turning off. I'm like, oh, what? So I quickly look because I have some good logging in there. I'm like, okay, this number right there. And so then I just ran that one procedure with a zero and nothing happens. Crap. Now I send a one. The meter turns back on. Now I can turn this meter on and off. It's awesome. And then of course, you know, I called everybody in InGuardians and made them listen to Klunk. They called my friends. I'm like, what is that? I'm like, Klunk? Some knew, some didn't. Okay. But now we're showing that we can do this. I don't need a manufacturer to software to run this. So I can development. Criminals can develop it as well. But what's great is now we have an assessment tool to generate that data, to do those types of things so that they can start looking for it. Okay, we're running kind of short. Unfortunately, one meter manufacturer found out that if I ran all the procedures at the same time, so I did it. And then it started acting a little funny, but not too funny. So I'm trying to figure out how to reconfigure it. And then I look over at the screen and it says uncalibrated on it. Uncalibrated. I don't know what that is. I don't see it. Oh, yeah. Yeah, utilities can't fix that. You have to send it back to the vendor. I was like, oh, so if I have the security code and I can run every procedure, I just brick your meter. It's like, yeah. It's like, woo-hoo! But I didn't say that on the phone. But now we can tell the utilities that and we can pass this information back to the vendors and they can start looking into it because we're generating anomalous activity that they weren't expecting. I'm kind of moving on because we're getting short, so I want to make sure I get to some of the mitigations. iChart is basically just brute-forth method. I don't need the password to log in, attempt to log in. I can brute-force it just like any other service. But what's great is I have a tool now. I just go through all that memory that I dumped before and I generate every single password that's in there and you need it. I do the login. So even though I unique it and got 12,277 passwords, it's still going to take me seven hours to run it. And I've never actually gotten my tool to run for more than about 20 minutes consistently. I can build some smartness into it and just restart it. But that's kind of important for utilities to know. Can they detect those brute-force logins? I can generate my own dictionaries. I don't have to get one out of memory. So are they using stuff like the utility name as the password? The vendor name at the password. So you can develop your own dictionary files and generate that kind of data. I was going to give a demo when we thought about it. But then something kind of dawned on me when I was thinking about my demo for Smookon and Black Hat. I realized that even if I show you the demo, if I have a meter up here and I click on the clock because it's cool, it doesn't mean that I'm really showing you anything. I'm showing you something that I can do with the security code on one meter. Okay? And there's at least seven different types of manufacturers out there and they all develop multiple types of meters. So I'm not really showing you anything. What I would really like to show you is that I can make the meter click on clock and then I can point over to the detector to detect it. Because that's what I did. I got on the phone with one of my clients. I turned the meter off and he's looking at his logs and he goes, I can see it. I'm going to screenshot that. I'm like, woo-hoo! That was my biggest woo-hoo because now I've actually shown that they can make those once I make a configuration change out in the field. Something that's unauthorized. Now the operators can identify it on the back end. Now they can create a large suit and form my security research. Mitigations, as I mentioned, most people do a lot of the mitigations that are going to be outlined right here. We talked about the residential meters, making sure you put those in the proper area. Actually, deploying a million meters and having a million different passwords is probably another security vulnerability. But you can still do it intelligently. So we talked to them about that. Obviously, we just talked about incident response plans, tamper alerts. On the smart meters, maybe not so much because there's so many out there, but definitely on the aggregation points for the pull tops, you'll want to do that. Encryption has to be done properly. We all understand that. The configuration integrity checks, we just talked about that. Some people break the standard a little bit just on their meters. They send an authentication code, but what's great about that is I can still build into my tool kit, you know, the method to pass the token. But what they do is if you pass the wrong token, they immediately shut off the optical port for a period of 20 minutes. So it makes it really difficult to work on those. So, you know, start thinking about different things if you're going to be researching this. I already thought about, you know, the wireless optical port readers. You know, we talked about that with the ZigBee optical spraying. If I'm standing 10 feet away from a meter and shooting IR at it, because I know the timing now, if I do that and I never touch the meter, did I do anything to the meter? So, you know, thinking about that, making people understand that. The wireless sniffers that we talked about putting in the aggregation points and putting... They could probably detect the ones that are in the meters, but the aggregation points are my concern for the sniffers that you just put in and leave them in place to send data back to you. And then obviously the frequency hopping. You know, that's probably the next big concern. Being able to do this type of stuff and get that radio information to understand so that you can do all of this stuff wirelessly via the radio. That's something that I'm really interested in and we're working towards. I mentioned that the vendors helped us. Ed Barrisette from Elster, you know, he actually contributed to the code to make sure that, you know, I'm working with more meters than I had actually worked with. Robert Former from Itron is a constant, constantly encouraging me, and he actually worked very hard to make sure that our toolkit is being used by their research team, that their developers understand it and they know to talk about this stuff as well. And then we're getting great positive feedback from a lot of the vendors except for one or two. I couldn't have done this without support from a lot of people. I listed some people on here. I obviously miss people. Once again, my name's Cutaway. Thank you everybody for coming. There is going to be a Q&A afterwards. I really appreciate it. Thank you very much.