NG9-1-1: The Next Gen of Emergency Ph0nage
Forgety, Trey (CINCVolFLT)
Kreilein, Alex (AK3R303)
For 48 years, 9-1-1 has been /the/ emergency telephone number in the United States. It’s also been mired in 48-year-old technology. So let’s just put that on the internet, right? What could possibly go wrong? Without the radical segmentation of the PSTN, the move to IP networks (even the private, managed kind) will bring new 9-1-1 capabilities AND new vulnerabilities. This talk builds on the work of quad, r3plicant, and Peter Hefley (see &lquo;Hacking 911: Adventures in Destruction, Disruption, and Death,&rquo; DEF CON 22,). It provides an overview of NG9-1-1 architecture and security concerns, and identifies critical attack surfaces that Public Safety Answering Points need to monitor and secure. Familiarity with NENA’si3 and NG-SEC standards may be helpful, but is not required. Bio: CINCVolFLT (Trey Forgety) is Director of Government Affairs for NENA: The 9-1-1 Association. He previously served as a Presidential Management Fellow in the U.S. Department of Homeland Security’s Office of Emergency Communications, with rotations in the Federal Communications Commission’s Public Safety and Homeland Security Bureau, and the U.S. Department of Commerce’s National Telecommunications and Information Administration. A sometimes-piratical sailor and inveterate tinkerer, CINCVolFLT’s recent activities have included work on establishing a backup timing source for telecom networks to ensure service during GPS outages or jamming, and serving as pro bono counsel to QueerCon.He holds a B.S. in Applied Physics and a J.D., both from the University of Tennessee (GO VOLS!). AK3R303 (Alex Kremlin) is Managing Partner and CTO of SecureSet, which is a cybersecurity services provider specializing in education and startup acceleration. Previously, AK3R303 was a Technology Strategist with the U.S. Department of Homeland Security and a Guest Researcher at the National Institute of Standards and Technology focusing on public safety and mobile communications network security. He holds a B.A. from Fordham University where he studied nuclear game theory through the political science department in Beijing, China. He holds an M.A. in National Security & Strategic Studies from the US Naval War College, and is an M.S. / Ph.D. candidate at the CU Boulder College of Engineering & Applied Sciences in Telecom Engineering.
 We've got a great presentation going for you on Next Generation 911 Security. We're calling it the Next Generation of Emergency Phonage. Myself, my name is Alex Kryline. I'm the CTO of SecureSet, a Cyber Security Academy in Denver. I used to be a strategist with the Department of Homeland Security and a researcher with NIST. I'm also a level 8 cyber wizard. That's me. This is my partner, Trey. I'm Trey Forgutty. I'm the director of government affairs and they call me the resident teenager at the NINA, the 911 Association. It's got a great face. We're the standards developer for everything related to 911. So when you get found, when you call from a cell phone, we're the reason that's actually possible. I'm also a former presidential management fellow. Alex and I did very similar tours. I was at DHS, FCC, and TIA, kind of all over the federal government. The reason that I'm still into like computers and security stuff in spite of being, and I'm going to use the official DEF CON term, a fucking lawyer. Fucking lawyer. In spite of that. The reason that I can still be into all this sort of stuff is because in addition to that, I'm a physicist and a navigator. So these are things that, technologies that are still very interesting and important to me and I kind of try to keep on top of stuff. Also a pirate, true story. So a couple of opening shots to set the stage a little bit. We're going to talk about some vulnerabilities in the way trust is implemented in next generation 911, which we're going to tell you all the sort of background about first. There's a really important reason that we're doing this in the public safety community. We're very comfortable with not telling people things. Like we, you know, everybody knows the police department, the fire department, they just love sharing information, right? Well, 911 is the same way. The problem is in today's information security environment, that doesn't work. The only way you get stuff fixed is by talking about it and bringing people like you together to say, oh, okay, how can we poke at this and figure out how it works and break it and make it better? So that's why we're doing this. And, you know, we believe very passionately our organization does that talking about vulnerabilities makes us stronger. And so we're going to be doing that. This October we're actually doing the first 911 cybersecurity conference. It'll be in Columbus, Ohio. It's going to be really cool. Same reason I tell my dates I cry in my sleep. So the, I'm going to talk a little bit in the first part of this, a little bit of history. And it's important to understand that today's 911, the 911 that you could use if you called right now, is it's called E911. That's a part of the telephone age. It's not a part of the computer age and it's certainly not a part of the internet age. It really is a part of the telephone age. There are things here like time division multiplexing and class 5 ESS switches that you just like, people like us don't ever want to see in our day jobs because that just means we're doing something wrong, right? But 911, that's all that it runs on. And that has some consequences. So historically trust in the public switch telephone network was this very sort of inherent thing. You had relatively high confidence usually that the person you were calling was the person that you got because there was physical security of the trunks running through conduits and overhead cable. The signaling was very obscure until folks like Cat and Crunch, Tea Profit and folks that the telephorics really got into poking around with the network. Things like medium frequency signaling and camo, which is centralized automated message accounting, which is no joke, a paper tape protocol invented in the 1950s, which is still used to connect 911 calls today. No joke, if you make a 911 call, it's probably being connected by a camera. And carrier pigeon. That too. You also had control plane segregation, legal protections, all these sorts of things. And that just meant that you didn't have to worry about things like certificates and authentication and cryptography and so forth. That just wasn't in the mindset. And it's still largely not in the mindset of public safety professionals. So back in the 1968, 1960s, the International Association of Fire Chiefs and ultimately a big thing called the President's Commission on Law Enforcement and the Administration of Justice got together and they really like imagined the public safety system of the future. This is a report that was issued in about 1967, I think. And in this report, they actually envisioned having 911, having computer aided dispatching, automatic vehicle location and radios on every copy. That's pretty amazing at a time when like a radio was something that you could just barely fit in the trunk of a car. So we've come a long way and this is kind of how we got there. So the fundamental problem that we're trying to solve with all of this stuff is who called us and where and with what. Those are important things. We need to know who needs help and how do we find them to get the help to them. And it's also important for reasons that we'll talk about in a second to understand what they were calling with because the 911 system was part of the wire line world, right? Telephones were these big heavy metal things that sat on tables that some nice man came and installed at your house. I've seen the videos. That changed though in the 1980s when all of a sudden a phone could be a three pound hunk of metal that you put in the floorboard of your car. And those no longer had convenient addresses. And then all of a sudden crazy people came along and started sending voice calls over this internet thing that nobody knew anything about. And we decided, okay, well, those should probably have access to 911 too because otherwise somebody's going to pick one up one day because it looks like a telephone and they're not going to get what they expect. So the world that all of this is designed for just to kind of set the stage in your mind, in 911, the way it really works, you've got when you when you establish telephone service with a wire line phone, the phone company takes your address from you on the service order and they validate it against this maroon box called the master street address guide. It's a list of all the street names in a jurisdiction and all the correct address ranges. They look it up in the fixed database, make sure that it's valid and then they record it in that purple box, the automatic location identification database. And then at call time when you when you call in the selective router, that's just a class five telephone switch. It uses your phone number to dereference your address and send that to the 911 center over typically a you know these days they might be up to like, you know, 14.4 kilobit modems. And I'm really not exaggerating that that's true. A lot of these are, you know, old very modern infrastructure. The 90s. The 92s still out there. And the great thing is because of that now, you know, in the early days of 911, all of the people in a town, regardless of which was like the right 911 center, the right police department in those days, all the calls went to one place, which was not great because you might be in the other part of the county that's actually served by the city. And so that's why this thing is called a selective router. It can also decide, hey, you're in Robertsville, not Alice Springs, send that to the other PCAP. PCAP is a public safety answering point. It's fancy time for 911 center. And this is important because what we're going to be talking about this same type of logical trust model is what's bolted on to IP networks, right? So understanding that the phone company trusts the phone company because it's all the phone company is really important because we didn't change that even though it's not the phone company anymore. That's where our exploitation is about to come in. The line we actually put on the conference CD is that in the beginning, the AT&T created the PSTN and the trust model was void and without form. Hallelujah. Because they were the phone company, damn it. Can I get an amen? So there are some problems with keeping this kind of stuff around because if you do this, and this has been talked about at DEF CON before, static databases become vulnerable to spoofing. If you can spoof the automatic number identification, then as provided you're sort of generally in the same jurisdiction as the 911 center you want to target, you can get a call to look like it's coming from someone else. And these sorts of things have been used in like swatting attacks to basically convince a 911 center that in fact this is Brian Krebs for example calling 911. Which happens. Which is probably not. Spoofing any automatically spoof sally, this is a terrible horrible miserably unethical thing to do and we strongly encourage you not to because it makes you a terrible human being. The thing is in the PSTN world there is no flag to say hey this looks kind of suspicious, maybe treat it differently. And all of this legacy equipment is getting really expensive, everything is going over the top, people want to communicate with RTT and videos and pictures and electronic medical records and all this stuff and you can't fit that over a voice channel. And so that's kind of the forcing function that is getting us to NG number one. So we have a better way. We'll just put that on the internet. Nope. Yeah. But seriously, a lot of people here next generation 911 they hear that it's IP based and they immediately say oh you're putting 911 on the internet, how could you be so stupid? Well first off no we're not. That's not the idea. Almost. We're not. Okay fine. Stop trying to make the internet happen. So it's going to be over private managed IP networks. It's all hopefully going to be very secure. But as we're going to talk about in a bit there are some reasons why things have to work differently for life safety systems. So other sort of externalities that matter for us. Carriers are walking away from their legacy TDM infrastructure. They don't want to be in this business anymore because it doesn't make money, it's expensive to maintain, it's highly regulated. So even in places where you know they are keeping up the copper network, they're no longer keeping up the copper network for the purpose of carrying analog voice. They're actually giving you like a DSL terminal adapter for your house and then spitting the telephone stuff out the back end of that. They're doing the conversion inside the home. And that has real consequences because now that changes the way that the voice call part of it is being carried even in the wireline world. And as I already said there are lots of different ways that people now want to communicate that from our perspective we want to accommodate because we want people to be able to get 911 natively the way they need it. There's even a proceeding right now at the FCC about PSTN sunset, right? So regardless of whether or not the carriers choose to do this, they're going to be required to do this in a very short term period of time. So that's why NG911 is very important is because it's the new standard that can sit on top of IP based networks which is what we're rolling to but we have to fix some things. Our organization and a few others got together and formed something called the NG911 Now Coalition. And basically our goal, you can find it's NG911Now.org. Our goal is to have NG911 rolled out nationwide by the end of the year 2020. That's really aggressive and it's going to be hard but we're pushing hard with Congress, the FCC, the carriers, everybody to try and get that done because we need it badly. So what's the purpose for wanting to do this, right? Because now we're starting to transition into a, okay, well we know we have to move to this new thing because the PSTN is going away. But there are lots of things that we could do to just preserve PSTN functionality on an IP network, right? But the thing that's also driving it is a desire for shiny new toys. We want things like dynamic location based routing, which we will very much talk about in just a moment. We want failover ease and the ability to transfer calls to the appropriate public safety answering point on a really dynamic basis because the telephone's hardwired. We want to be able to do mobile public safety answering points. We want virtualized public safety answering points. So imagine we have a hurricane and all the public safety answering points are blown away. Okay, cool. So understanding that that happens, then how do you respond? The way you respond is by spinning up a new public safety answering point. But remember that we have this problem with trust in the PSTN, right? Because we're not the phone company anymore. Now we're lots of different organizations who all want equal privileged access. That gets into some really interesting problems and NG911, while it is absolutely necessary, it is still totally the Jetsons on some level because we haven't quite figured out how to do the thing that we really want to accomplish. So I'm going to talk for just a moment about the i3 architecture. This is done by Nina, big shout out. i3 architecture has basically three different types of components. The first component is the carrier service environment, right? Or rather the originating service environment. These are the carriers like AT&T, Verizon, T-Mobile, Sprint, Comcast, everybody else who dials into the emergency services IP network or the EZNet. That's that central big blue cloud on the screen. Just to be clear, it is the carrier, she's absolutely right about that. The cool thing is with NG911, it's no longer just the carrier. That's right. So if Facebook and WhatsApp want to send emergency traffic to an NG911 system and they're using the ITF standards for how you do stuff like that, they can absolutely do it and it will work fine. Totally. But remember, now we have new service providers who are not traditional telcos who now are able to associate traffic with a 911 environment, right? Like, who's WhatsApp? Who knows who they are? Do we know? Well, you all have the app, but have you talked to the CEO of WhatsApp? No, you're not going to do that. So this gets to an interesting question of like, how do we validate trust end to end, right? Because this is what we're about to exploit. The third part of this architecture are these legacy and next generation public safety answering points, right? So ultimately, what the duration of this talk is going to focus on is the association between those public safety answering points and that EZNet, right? That emergency services IP network. So let's talk. Yeah, real quick. I want to give a shout out. The National Highway Traffic Safety Administration operates the National 911 office, which is really unfortunate within our government. There is like one person with a handful of contractors who's who's a boss. She's awesome, Laurie Flaherty. They actually put this diagram together. They're great for this stuff. So big shout out to NHTSA and the National 911 office. Thanks, Laurie. So let's talk protocols for a minute. So because this is really what we're going to be exploiting in the next couple of slides. We have this thing called the ESRP or the Emergency Services Routing Protocol. This is basically a SIP proxy, right? Handles all SIP traffic that's initiated with inside of the EZNet. The second piece that we have is this emergency call routing function or the ECRF. This determines the best or most appropriate PSAP. Not necessarily the closest, but the most appropriate, right? So like, if you're, can you give a use case about where one wouldn't be the closest but most appropriate? Perfect example of this. If you are standing right near the border between two counties, one county has its 911 system literally directly across the line within like feet of you, but you're here. The people that respond, the people that are supposed to answer that call are your counties 911 center. It may be farther away. Clear across the state. But it's still the right one because you're inside its service contour, which gets important in a minute. So then the last piece we have is the policy routing function, which really defines the non-geographic assets of routing, right? Like, you know, flag these calls, send all these calls to this one public safety answering point because they have like special analysts or, you know, telecommunicators who are there, who are the 911 call takers, right? Somebody who might be specially trained in some sort of methodology. And then the last one is ICAM, which we all know, identity credential access management. So these are really the four, the four different pieces of the network that we're going to interface with. So what's the trouble with trust? This is a really important piece because what we've done is we've talked about is we took this legacy methodology of trust from the PSTN. We laid it on the IP network. Remember that all calls under all circumstances must reach 911, even if the authentication fails. Everything has to go through. Why? Because if something happens, we want to make sure that somebody's taken care of. We've got a great quote on this in a second. It's just not acceptable to say, we're sorry your certificate is expired. Please hold and bleep to death. And we'll have someone with you in a wait time of five to ten minutes. But the interesting part here is what we've built underneath of this model of all calls must go through is a fail working model. And that fail working mode is really important and is what we're about to talk through the exploitation. So this is, I'm personally very proud of this. I this, I would love to say this was intentional and I hacked DEF CON knowing that someday I would give this talk, but that's total BS. But two years ago I asked Bruce Shiner a question about how do we get folks to, how do we drive adoption of secure communications technologies by making sure that access to emergency services, which for people experiencing some kinds of emergencies, it's really important. You know, if you're being abused, if you know how you have a medical condition, you don't want other people to know about that. We have to keep up trust. And Bruce thought about it for a second and he said, you know, if there's some reason the PKI doesn't work, if there's some reason the fucking PKI doesn't work, I want to fucking talk to 911. Amen. And I guarantee you everybody feels that way, right? I mean, you don't ever want to hear, we're sorry, the OCSP server is offline, you can't call 911 today. That's not, that's just not okay. So that has consequences though. You know, in military communications and financial communications and literally everything else we do, if the authentication fails or the encryption fails, we say don't handle that traffic because it's, you know, it's not good. We don't want it. It's potentially malicious. In 911, that's not an option for us. We don't get that privilege. So we have to work around it. And that has real consequences for vulnerabilities in deployed systems. So we're going to talk through what our methodology was for exploitation of the emergency services IP network and basically that's side of the architecture for NG911. So when we wanted to do our research here, we focused on not necessarily low hanging fruit, but the hard to solve problem. Because the hard to solve problem here is how do we make sure that all calls go through and could frankly, we haven't figured that piece out. And that's why we're here because we're going to talk about our exploitation. What we did figure out though is how to use the fail working model to our nefarious advantage. So I'm going to talk through the steps that we took. The first one was we exploited the underlying cryptographic vulnerability in the current implementation of the standard, not in the standard itself. We'll talk through that. Two, we got command and control inside of the Esynet. We were able to forge geolocation coordinates for both where our public safety answering point is supposed to be in the world. And thus it's also its inherent service contour. But also where all of your calls are supposed to come from is very different from where we tell the Esynet where they actually come from. We were able to set up a denial of service attack to DOS, the other public safety answering points, and capture all the failover traffic. So in three different ways we figured out how to subsume all of the possible traffic so we get all of the calls. So all calls flow to basically my laptop. Important caveat, very important caveat. We did not do this in the world. So I'm not going to jail for DEF CON. Sorry guys. Output was we did this at a research lab. We went to Texas A&M University to the Internet 2 lab. They were incredibly cool to have us. We're going to give a huge shout out at the end for them. But I want to note that there are some really important things here. This is a lab environment. It's not a production environment. So things are going to operate differently. They're both neater and cleaner in some areas. They're also way more fucked up in other areas, right? The other piece of this though is that some of this is just the way that the software is currently implemented. And because it's not running in a production environment, some things we were able to do, we don't know if they will fix in production. So we figured out what those really awful things were, like read write privileges and privilege escalation and figure out then how to take those and go back to the vendors to help them make a more secure solution. And I'll just point out there that a lot of this, so there are a lot of NG911 systems that are deployed today. They're sort of transitional. And so some of these things you probably could go and do if there was something attached to those other than like analog voice channels. But there isn't. So it's kind of hard to pop certificates over TDM voice. Yeah. So this is not an O-day talk. Sorry, guys. So let's start with our first step, exploitation of certificates. So NG911 uses certificates to assure trust. So they're not just letting people blank fire. There is in the standard a requirement for certificate authority, but it's called the PSAP credentialing authority and due to reasons mostly involving money, it doesn't exist yet. Womp, womp. So while it calls for that certificate authority, they're actually today just using self-signed certificates. Boom. So here's the problem with self-signed certificates. You can do easy certificate exploitation. So let's walk through the methodology. So we start by getting on the wire with SSL strip, sip vicious, wire shark, and a few other tools. We see the cert as it floats by on the wire. We pull it down. We now form it. And as you'll see in line six, the certificate says maximum ponage. That's really interesting. No way that's auto-generated. So we now supply our self-signed certificate to our own virtual public safety answering point, right? So we have access to a virtual one because Texas A&M was cool enough to give us one, but you can also go out and get them because they exist because we want emergency response to be dynamic. So we have this public safety answering point. We have our own certificate. We have all the drivers. We've got all the ports correctly configured. We associate it with a network. And what happens next? Boom goes the dynamite. We're now authenticated to the emergency services IP network or the EZNet in equal privilege to everybody else. It accepts our certificate and now we're on. And what happens? SIP sessions start moving because it has load balancers that are inherent in the network. We don't have to do anything but provide the network our base geolocation coordinates to start getting traffic. So we've invented a bullshit PSAP. We've supplied the EZNet with a bullshit certificate and we already start capturing 911 calls. But after we do this, because I'm a special brand of interesting person, I wanted to do two different types of geolocation attacks. The first one is I wanted to see if I could move my PSAP. So why would I want to do that? So I've got this rogue, you know, it's like a rogue base station attack basically. You want to put the victim in geolocation to your infrastructure. So I moved my infrastructure to be in geolocation of whatever I wanted. So in this circumstance, right, the ESRP uses this function called loss, the location and service translation and it requires the ECRF, sorry, to use the location data interface to figure out where I actually am. Do you want to? Yeah, and the cool thing about this is like it NG911 is designed using these like awesome IETF standards track things like lost and held and devices called forest guides that make it possible for your gadgetry to figure out where you are for the network to figure out where you are and then to communicate that information we hope securely to an NG911 system. They use for the part we're talking about here though, they also use something called GIS, geospatial information systems to define the service contours of 911 centers. That's right. This is all of the calls within this polygon go to this center and here's the IP address of its border controller. So we switched our service contour to move from Texas to Ballet's Paris hotel giving DEF CON its very first PSAP. So all calls in all calls in our part of Texas where we actually are are now received in DEF CON basically by my laptop. Not particularly cool. The other part though of this attack and this is the other interesting part is we were able to forge the geolocation of inbound calls. So it's one thing to change the geolocation of the public safety answering point. It's another thing to write a short script and run it on top of the Esynet that says put all inbound calls into a 10 meter radius of the middle of my service contour. So we grab, they have nowhere else to go. We grab all traffic even if we're not able to get to this level of exploitation. Even if for some reason there's something on the network that senses that's bullshit, that's not your geolocation, you're not supposed to be the correct PSAP. It doesn't matter because on the other side if we're able to attach at all we can direct all the calls to us anyway. In fact if we wanted to we could selectively, we could basically man in the middle your pitaflow, position information, data format, location object. That's the thing that the location information server sends into the 911 center to say here's where the caller is. We could actually man in the middle of that, alter it and then the forest guides will tell your carrier network to send the call somewhere else, basically somewhere of our choosing. And that's, we didn't, we didn't write that up here but that's certainly another way you could do this very simply because the pitaflows are not signed. The carrier doesn't have to sign that to say this person is actually where I assert that they are. Or you could look for a single phone number of an inbound caller, a single phone number of an inbound caller, you can track and identify an actual individual and you can make their call, not all calls, just that one call go to the public safety answering point you want. Anybody see Oceans 11? Because it was filmed here in Vegas. I mean that essentially happened. They had to like physically tap something to do that. Yep. Because of the nature of the 911 network but that wouldn't be required. Right. You could just say okay any 911 calls from within, I think it was the MGM grant in that case, please bring those to us. Totally. So not having Brad Pitt and George Clooney at hand, we also had to figure out a failover vulnerability. So when we talk about this fail working model that we discussed previously with all calls must go through, we're going to show two use cases. The way it's supposed to work and then the way we made it work. So when we did the failover vulnerability, we have this, you know, basically public safety answering point. So this is the NG911 function running on top of the Ezzie net. You have a good public safety answering point. This is like the legit good dues they're supposed to be there. They start connecting, right? They exchange their certificates, they're all copacetic, they start getting SIP traffic. We have another good public safety answering point, right? Because we have multiple public safety answering points in a state. Because these are the 911 call centers. So there's like 50 or whatever. You know, sorry for being a little flippant about the number, but you know, it depends on the state. And so, but what happens if we now sever this line of communication? Well, if they drop the session, the good PSAP goes away and it fails over to the other good PSAP, right? That's good. We want that to happen. In a hurricane, one public safety answering point gets knocked out, they lose power, something happens, it rolls over, calls get balanced, all calls still go through. What's the way that the other way that this could work? Well, we use this attack called VoIPer, straight got it off GitHub. I'm not going to invent like I wrote the code. But so we use VoIPer attack to go after the quality of service of the SIP connection between this bot, this cloud, ooh, the cloud, and the good PSAP, right? So we have the public safety answering point in our, just like we did in our last one. And it connects over here, but then we also have our evil PSAP, ooh. And so our evil PSAP initiates a SIP attack using VoIPer against the quality of service of that connectivity between the NG911 function on the EZNet and the good PSAP. And so when it starts doing that, what we're able to do is turn that good PSAP, because we're cutting off its line of communication, because we're fucking with QoS, right, into a sad PSAP. And now that we have our sad PSAP, we get all the traffic. All your 911 calls are belong to us. Boom. So why would we do this? Right? It's cool to be able to do this in a lab. But why is this actually important? Beyond the fact that we're looking to bring people into the security research field on this. Well, it's important to understand who the threat actors for these things would be. So I mean, it's one thing to be able to like, invent some cool vulnerability, but like, if no one's going to use it, then so what? Well, ultimate reality here is that this is the tomfoolery and trickery of the criminal element, right? You get them to look the other direction, then you punch them in the neck. And the way that we do that here is we think through a circumstance in which you would have someone or a group of people who would work, for example, in the criminal element, like organized crime or others who would want to be able to do things like rob a bank, capture all the 911 calls from people saying the bank's being robbed, and just basically move them to DevNol. And at the end of what we've done here basically is we figured out how people would choose to use 911 as a veneer, right? The comfort that people get when they call 911 and take that availability away from them. And you could easily imagine people wanting to do this in multiple fields. And because basically what we've done is we've used the system redundancy against the network itself, we have been able to express the same type of tactics, techniques and procedures that we would expect from criminal element. And I'll point out, let me give you kind of a hypothetical example of like where and why this could matter. So one of the big like sexy use cases for NG911, if you remember the Christmas Day bombing attack from New York City, that was stopped because someone called 911 and they said there's this creepy looking white van, here's the license plate, blah, blah, blah. That's great, that works. Creepy looking white van, it's a Ford license plate, etc. It would be much better for us in the public safety community if the person making that on one call could instead simply snap a picture of the creepy looking white van and send that to us so that we can then decide, okay, is this relevant? Yes, great, push it out to the cops on the street, go after this creepy looking white van. Because that stops, you know, I had a buddy that got, you know, yanked out of his truck and thrown to the ground with, you know, guns to his head, basically, because he was driving a truck that looked like one of an armed robber. You know, with photographs, it's harder for that to happen, hopefully. But somebody could easily, in a circumstance like that, alter that information. If they were lurking, the attacker could have said, okay, I see that photograph coming across the wire, let's make the white van red to her cell. Yeah, so I mean, you can fool the integrity and availability of these systems, but what's important to understand is it's not just the 911 network, it's a critical infrastructure network. Like, these are things that people use that we all pay money for that's supposed to work that we're supposed to be able to rely on, and that's why you have to do vulnerability research in these areas. But not all is lost, there are mitigations, Trey. Yes, so we talked earlier in my organization, we're the standards developers, and the great thing is we do actually have a small number of very dedicated, very knowledgeable people on IP networking and ITF standards and security to some extent, although that's probably our biggest limitation right now. They came up with two things, both the i3 standard, that's the standard for how you do ng911. It has tons of security related functional entities and protocols and so forth baked in. The border control functions do special things, the routing proxies do things, you know, we mark suspicious traffic, all that sort of stuff. But then on top of that, they actually published another standard called ngsec, that's the security standard for ng911. I will tell you, it is good, it's not great, it's not done. It is a wonderful document as it is, but there are tons of things that the public safety community has not yet thought about to put in there because we've never had intrusion detection before. What are you going to detect? The pizza guy called instead of, you know, a ng911 call, that doesn't help. We've never had a lot of these security related things that we're going to have to have now, and so just knowing about it enough to put it in a document is like step one for our community, it's very important. We have the ability, as I said, in the standard to mark unauthenticated traffic as suspicious, and now with some of the recent rule changes by the FCC, we should have much better capability to use reputation scoring for phone numbers and things like that to make decisions about, okay, do we think this is likely to be a nefarious call from the media standpoint. I have, we mentioned the PSAP credentialing authority, the special CA. That does not exist yet, but there is an RFP being put together for that, and I looked at what I hope and pray will be the final version that I have to edit last week, and so it'll be about another two months, I think, before an RFP goes out for the CA, which is a good thing, but we also still have to figure out how to pay for it because that, you know, in the public sector, everyone is so flush with cash that they just, you know, have tons of it lying around. Not really. Depends on which state, but not really. And for now, there's this sort of inherent mitigation, which is that even though most of the carrier networks are now natively IP, SIP, you know, VoIP basically, and even though there are NG911 systems out there that are natively IP and SIP, in the middle, everything is getting converted to TDM to go over like one set of trunks and use one particular switch so that it can still get to the place where it's just going to be turned right back into what it was to start with, which is not terribly efficient, but it is sort of a security protection because turning your traffic into TDM first like breaks a lot of the stuff that we talk about here because none of the IP stuff actually makes it out the other end. Plus, even if we wanted to get away from the technical side of things, right, like if you're a public safety answering point and you normally get like 80 calls in an hour and you get no calls for like three hours, you can probably start to imagine that there's something up, right? So there's like, if you're just a smart person, you'll figure out that you're under attack depending on what the nature of the attack is, and you can then contact your systems administrator on line seven, or you could contact any people who run the emergency services network and they can begin doing some sort of analysis or forensics to determine these things. So these are bad things that absolutely 100% can happen today, but we have a reasonable expectation that by getting people who are smart together in a room and working through it, that we'll get there. Also, and that the process you just talked about can be automated actually. There are people right now looking at it. So it turns out the 911 call is exceptionally regular. We see it beautifully in terms of like the flow by time of day, day of week, etc. And so you can start to automate things like around, okay, am I getting far more calls or far fewer calls than I should reasonably expect? Standard deviation. Yeah. So we'll leave. Oh, sorry. I got a couple, a couple more mitigations here. First off, we could start having, we talked earlier that the location objects are not signed. We should absolutely be signing those. And that's actually going to be part of a future revision to the standard, we think. Yep. Same thing with PSAP service contours. Those should be signed as well once the CA exists. We can start to do some things like low level sanity checking. We can say if the GPS chip in the cell phone says it's in Texas, and it's showing the call is being presented at a PSAP in Las Vegas, well, okay, there's a mismatch there and we should find out why that's happening unless we intended it to. And we can also do things like we can say if this is attached to a cable modem that's in Kansas, then the call should not be showing up at a PSAP that's in Florida. So we can start to do some of the database stuff that we do today to kind of sanity check some of this. Also implementing TLS for all the held lookups is really important. Go RC. That depends on the CA again. So we'll leave you guys with a couple of parting shots. As we said before, it's really vital that 911 always work for everyone because lives really are at stake. And there's a lot of work left to be done to make sure that all of these things are secure to start with and become even more secure down the line. So one of the big reasons that we put into present this year was to basically put out a call for help to say our community in public safety, we're not as unfriendly as we seem sometimes. We desperately need the folks in this room to be part of the community. And one of the ways you can do that is by joining us at dev.neena.org. That's our standards development portal for those of you who've used Covey before. It's a Covey site. And we would love to have you if you want to actively participate, that's where to sign up. It's a little scary given the pervasive nature of 911 that this is probably the largest group of security professionals that's ever been involved at all in this type of security research. That should scare people. It's not a good idea the two knuckleheads or the guys who are leading research on this. And so we'd ask you to do, if you're interested in this, if you have like a persistent interest in NGSec and 911 security, tonight at 4 p.m. at Burgers, we're going to be holding a meetup where I will personally pay for one round of drinks for half of you, depending on the number of people who show up. So come for the beer and the jokes and the conversation. But we want to start a community of people who actually get involved in research on this. You can make a legit difference and we're here to support for that. Also shameless self-promotion, we will have the first ever 911 security conference this October. It's going to be in Columbus, Ohio, that garden spot. And we'll have at least four or five hundred security pros or mainly public safety pros. We're going to be talking through some of these issues. So we'd love to have anybody there that can join us. So shout out to our team. We had a couple of people who helped us out. Tom Blackard with Team Secure Set, Jake Nelson with Team Secure Set, and with Team Texas and in University, Walt Magnussen and this really awesome little network nerd, Derek Ladd, who just made it hop. So cheers to them. So now I have one personal shout out. Yeah, please. So two years ago I came here as a total noob, as a fucking lawyer, as someone who had no business at all being at DEF CON. And the guy back here from queercon brought me in. They are my family now. They are wonderful. These badges are the coolest thing you will ever see at DEF CON. Right on. Big hands. So thank you to you guys for getting me up here. So now's the dangerous part of the talk. We open to comments, prayer requests, song dedications, but no smug assertions of infosex superiority. Amen. So there should be microphones I think some place. There's one down here. One over there some place. Hello. Since the HIPAA standard actually deals with 911 and emergency centers where a patient cannot die simply because your computers aren't up. I was wondering how much have you actually looked at and it's really scary if you actually consider emergency room security and improvement, but actually it might be. How much of that standard have you actually looked at versus trying to reinvent the wheel? So HIPAA applies in some very specific and relatively narrow circumstances. There are certain types of information in certain types of transit that have to be protected in certain ways. The objective of the I3 and NGSEXPEX was to make sure that that was at least a minimum so that we were not trying to reinvent the wheel. A lot of that should be baked in. Now personally, because our organization just this past year, we did the first ever NIST GAP assessment of a 911 center. And what we found was frankly somewhat terrifying because it looked like basically a house with no windows and no doors and maybe only part of a roof that was mostly on fire. And so we're a little bit scared about where that is. We have had just this year about six or eight hit with ransomware and thankfully those guys were just interested in getting paid, but they could have equally been interested in taking people's data. And so we're very conscious of the need to protect sensitive health information. Well, no, I was thinking at a more strategic level here for a second because I've been making the case like the risk management case with a doctor. I mean his risk management case is you're not going to die in 15 minutes. We're fine. What's the risk? Okay. And the information security case says, okay, they're not going to die in 15 minutes. Why would you spend $1,000 on security versus a heart monitor? Okay. And that's the risk management case really that you're facing, which is- So we should absolutely talk about that. But I want to get another- So catch up with us at four o'clock at Burgers and we will definitely talk about that. Who's next? This guy. I've got a question prefaced with an explanation for you. Go for it. My question is how robust is the load distribution and PSAP spin-up process? How what was it? How robust is it in NG911? And the reason that I'm asking that question is that there was a fantastic 101 on Thursday regarding virtual PBX switch, SIP access, and being able to spam a phone number with a shitload of phone calls. So if say a person who wants to cause chaos in a certain town could buy 500 SIP lines and then spam 10,000 calls an hour. So never mind NG911 at all. Forget that that exists for a second. We're just in today's NG911 world. The average 911 center has a grand total of five or six inbound trunks. You pop one enterprise call manager at a small business, not even a medium business. You can overload a region easily. And we don't have any way to defend against that. Like there's no, you know, it's difficult and terrifying and so we don't know what to do about that. I'd also say if you go, if you, yeah right. So and remember it's just a lab environment but computationally to spin up a virtual PSAP. So that took about an hour and a half to get that set. But like that thing eats like a hog, right? So if you throw enough traffic at it, not just from like a telecom denial service perspective, but if you make that thing eat enough, it's going to take itself down. So we have to be really careful about our implementation. I'll be honest, I dozed myself twice, right? Like it's going to happen. So yeah, it's not as robust as it needs to be. Is there a way to mitigate that on your guys' checklist? Not yet. Not yet. There are some, and there have been attacks by the way. People have DOS PSAPs over their admin lines. International SIP gateway exchanges have really messed up, messed with them. Go for it. Two questions. First of all, the database that you mentioned earlier that has all the addresses. Location information server. Yeah. Is it 1D or an E? Is it 1D database or does every telephone company have their own database? Is it proprietary? So it depends on which one you're talking about. If you're talking about in the E911 world, can you scroll back to that while I talk? In the E911 world, there's a Master Street address guide in each town, basically. There is a selective routing database and an alley automatic location identification database. In theory, for each carrier, but in practice, they're all outsourced to about three companies. Yeah. So the data is proprietary or? Yes. For now. My second question is regarding the NCS GETS system, are they having similar problems in transitioning? Do they use as a net? So funny story, actually, we used to work at DHS in the component that runs WPS and GETS. Thanks for knowing about it. You're the guy. Yeah. You're the one. They are actually working now on next generation GETS and WPS. I don't know where it is because I've been out of that now for six years, but yeah, that's definitely happening. Anybody consider pen testing that too? Yeah. I mean, it still uses underlying compromise, you know, like infrastructure, right? Like SS7 and a lot of other infrastructure. So NGN GETS is not as secure as you might believe it to be because it's not TDM based. So most of this is new to me. Is any of this 911 stuff crossover with the Amber Alert system? No. Okay. So we'll say excellent talk. You mentioned funds are a major issue in a severely aging infrastructure, especially in some of the more rural areas in Texas as well. That being said, I'm a firefighter and first responder, so I have a unique viewpoint rather dealing with city management for funds, not only for fire gear, but everything else. Yes, sir. You start talking about a lot of this stuff to city and police and everybody else. They're going to start looking like, you know, you're a heretic and want to burn you. So how do you, how are you going to approach that? Very carefully. But no, that is like, that's the biggest thing for our organization being the 911 association. We just decided, you know what, burn us at the stake if you want. We are going to talk about this until it's all fixed. Yeah. Like, dude, this has to happen for police, fire, EMS, civil servants, also just people, right? Just everybody else. Like, my nightmare scenario is somebody screws the geolocation coordinates up and they send your guys into a building and that's a chem fire instead of a regular fire, right? That's, that's a clusterfuck. So this has to get taken care of. Okay. Thank you guys. You've been wonderful. Thank you. Thank you.
 We've got a great presentation going for you on Next Generation 911 Security.  We're calling it the Next Generation of Emergency Phonage.  Myself, my name is Alex Kryline. I'm the CTO of SecureSet, a Cyber Security Academy in Denver.  I used to be a strategist with the Department of Homeland Security and a researcher with NIST.  I'm also a level 8 cyber wizard. That's me. This is my partner, Trey.  I'm Trey Forgutty. I'm the director of government affairs and they call me the resident teenager  at the NINA, the 911 Association. It's got a great face. We're the standards developer for  everything related to 911. So when you get found, when you call from a cell phone, we're the reason  that's actually possible. I'm also a former presidential management fellow. Alex and I did  very similar tours. I was at DHS, FCC, and TIA, kind of all over the federal government.  The reason that I'm still into like computers and security stuff in spite of being, and I'm going  to use the official DEF CON term, a fucking lawyer. Fucking lawyer. In spite of that. The reason that  I can still be into all this sort of stuff is because in addition to that, I'm a physicist  and a navigator. So these are things that, technologies that are still very interesting  and important to me and I kind of try to keep on top of stuff. Also a pirate, true story.  So a couple of opening shots to set the stage a little bit. We're going to talk about some  vulnerabilities in the way trust is implemented in next generation 911, which we're going to tell  you all the sort of background about first. There's a really important reason that we're doing  this in the public safety community. We're very comfortable with not telling people things. Like  we, you know, everybody knows the police department, the fire department, they just love sharing  information, right? Well, 911 is the same way. The problem is in today's information security  environment, that doesn't work. The only way you get stuff fixed is by talking about it and bringing  people like you together to say, oh, okay, how can we poke at this and figure out how it works and  break it and make it better? So that's why we're doing this. And, you know, we believe very passionately  our organization does that talking about vulnerabilities makes us stronger. And so we're  going to be doing that. This October we're actually doing the first 911 cybersecurity conference.  It'll be in Columbus, Ohio. It's going to be really cool. Same reason I tell my dates I cry in my  sleep. So the, I'm going to talk a little bit in the first part of this, a little bit of history.  And it's important to understand that today's 911, the 911 that you could use if you called  right now, is it's called E911. That's a part of the telephone age. It's not a part of the  computer age and it's certainly not a part of the internet age. It really is a part of the  telephone age. There are things here like time division multiplexing and class 5 ESS switches  that you just like, people like us don't ever want to see in our day jobs because that just means  we're doing something wrong, right? But 911, that's all that it runs on. And that has some  consequences. So historically trust in the public switch telephone network was this very sort of  inherent thing. You had relatively high confidence usually that the person you were calling was the  person that you got because there was physical security of the trunks running through conduits  and overhead cable. The signaling was very obscure until folks like Cat and Crunch, Tea  Profit and folks that the telephorics really got into poking around with the network. Things like  medium frequency signaling and camo, which is centralized automated message accounting, which  is no joke, a paper tape protocol invented in the 1950s, which is still used to connect 911  calls today. No joke, if you make a 911 call, it's probably being connected by a camera. And  carrier pigeon. That too. You also had control plane segregation, legal protections, all these  sorts of things. And that just meant that you didn't have to worry about things like certificates  and authentication and cryptography and so forth. That just wasn't in the mindset. And it's still  largely not in the mindset of public safety professionals. So back in the 1968, 1960s, the  International Association of Fire Chiefs and ultimately a big thing called the President's  Commission on Law Enforcement and the Administration of Justice got together and they really like  imagined the public safety system of the future. This is a report that was issued in about 1967,  I think. And in this report, they actually envisioned having 911, having computer aided  dispatching, automatic vehicle location and radios on every copy. That's pretty amazing at a time  when like a radio was something that you could just barely fit in the trunk of a car. So we've  come a long way and this is kind of how we got there. So the fundamental problem that we're  trying to solve with all of this stuff is who called us and where and with what. Those are  important things. We need to know who needs help and how do we find them to get the help to them.  And it's also important for reasons that we'll talk about in a second to understand what they were  calling with because the 911 system was part of the wire line world, right? Telephones were these  big heavy metal things that sat on tables that some nice man came and installed at your house.  I've seen the videos. That changed though in the 1980s when all of a sudden a phone could be a  three pound hunk of metal that you put in the floorboard of your car. And those no longer had  convenient addresses. And then all of a sudden crazy people came along and started sending  voice calls over this internet thing that nobody knew anything about. And we decided, okay, well,  those should probably have access to 911 too because otherwise somebody's going to pick one  up one day because it looks like a telephone and they're not going to get what they expect. So  the world that all of this is designed for just to kind of set the stage in your mind,  in 911, the way it really works, you've got when you when you establish telephone service with a  wire line phone, the phone company takes your address from you on the service order and they  validate it against this maroon box called the master street address guide. It's a list of all the  street names in a jurisdiction and all the correct address ranges. They look it up in the fixed  database, make sure that it's valid and then they record it in that purple box, the automatic  location identification database. And then at call time when you when you call in the selective  router, that's just a class five telephone switch. It uses your phone number to dereference your  address and send that to the 911 center over typically a you know these days they might be  up to like, you know, 14.4 kilobit modems. And I'm really not exaggerating that that's true. A lot  of these are, you know, old very modern infrastructure. The 90s. The 92s still out there. And the  great thing is because of that now, you know, in the early days of 911, all of the people in a  town, regardless of which was like the right 911 center, the right police department in those  days, all the calls went to one place, which was not great because you might be in the other part  of the county that's actually served by the city. And so that's why this thing is called a selective  router. It can also decide, hey, you're in Robertsville, not Alice Springs, send that to the other  PCAP. PCAP is a public safety answering point. It's fancy time for 911 center. And this is  important because what we're going to be talking about this same type of logical trust model  is what's bolted on to IP networks, right? So understanding that the phone company trusts  the phone company because it's all the phone company is really important because we didn't  change that even though it's not the phone company anymore. That's where our exploitation is  about to come in. The line we actually put on the conference CD is that in the beginning, the AT&T  created the PSTN and the trust model was void and without form. Hallelujah. Because they were the  phone company, damn it. Can I get an amen? So there are some problems with keeping this kind of  stuff around because if you do this, and this has been talked about at DEF CON before, static  databases become vulnerable to spoofing. If you can spoof the automatic number identification,  then as provided you're sort of generally in the same jurisdiction as the 911 center you want to  target, you can get a call to look like it's coming from someone else. And these sorts of things  have been used in like swatting attacks to basically convince a 911 center that in fact  this is Brian Krebs for example calling 911. Which happens. Which is probably not. Spoofing any  automatically spoof sally, this is a terrible horrible miserably unethical thing to do and we  strongly encourage you not to because it makes you a terrible human being. The thing is in the PSTN  world there is no flag to say hey this looks kind of suspicious, maybe treat it differently. And all  of this legacy equipment is getting really expensive, everything is going over the top, people want  to communicate with RTT and videos and pictures and electronic medical records and all this stuff  and you can't fit that over a voice channel. And so that's kind of the forcing function that is  getting us to NG number one. So we have a better way. We'll just put that on the internet. Nope.  Yeah. But seriously, a lot of people here next generation 911 they hear that it's IP based and  they immediately say oh you're putting 911 on the internet, how could you be so stupid? Well  first off no we're not. That's not the idea. Almost. We're not. Okay fine. Stop trying to make  the internet happen. So it's going to be over private managed IP networks. It's all hopefully  going to be very secure. But as we're going to talk about in a bit there are some reasons why  things have to work differently for life safety systems. So other sort of externalities that  matter for us. Carriers are walking away from their legacy TDM infrastructure. They don't want  to be in this business anymore because it doesn't make money, it's expensive to maintain, it's highly  regulated. So even in places where you know they are keeping up the copper network, they're no  longer keeping up the copper network for the purpose of carrying analog voice. They're actually  giving you like a DSL terminal adapter for your house and then spitting the telephone stuff out  the back end of that. They're doing the conversion inside the home. And that has real consequences  because now that changes the way that the voice call part of it is being carried even in the  wireline world. And as I already said there are lots of different ways that people now want to  communicate that from our perspective we want to accommodate because we want people to be able to  get 911 natively the way they need it. There's even a proceeding right now at the FCC about  PSTN sunset, right? So regardless of whether or not the carriers choose to do this, they're going  to be required to do this in a very short term period of time. So that's why NG911 is very  important is because it's the new standard that can sit on top of IP based networks which is what  we're rolling to but we have to fix some things. Our organization and a few others got together  and formed something called the NG911 Now Coalition. And basically our goal, you can find it's  NG911Now.org. Our goal is to have NG911 rolled out nationwide by the end of the year 2020.  That's really aggressive and it's going to be hard but we're pushing hard with Congress, the FCC,  the carriers, everybody to try and get that done because we need it badly. So what's the  purpose for wanting to do this, right? Because now we're starting to transition into a, okay, well  we know we have to move to this new thing because the PSTN is going away. But there are lots of  things that we could do to just preserve PSTN functionality on an IP network, right? But the  thing that's also driving it is a desire for shiny new toys. We want things like dynamic  location based routing, which we will very much talk about in just a moment. We want failover ease  and the ability to transfer calls to the appropriate public safety answering point on a really  dynamic basis because the telephone's hardwired. We want to be able to do mobile public safety  answering points. We want virtualized public safety answering points. So imagine we have a  hurricane and all the public safety answering points are blown away. Okay, cool. So understanding  that that happens, then how do you respond? The way you respond is by spinning up a new public  safety answering point. But remember that we have this problem with trust in the PSTN, right?  Because we're not the phone company anymore. Now we're lots of different organizations who all want  equal privileged access. That gets into some really interesting problems and NG911, while it is  absolutely necessary, it is still totally the Jetsons on some level because we haven't quite  figured out how to do the thing that we really want to accomplish. So I'm going to talk for just a  moment about the i3 architecture. This is done by Nina, big shout out. i3 architecture has  basically three different types of components. The first component is the carrier service  environment, right? Or rather the originating service environment. These are the carriers like  AT&T, Verizon, T-Mobile, Sprint, Comcast, everybody else who dials into the emergency services IP  network or the EZNet. That's that central big blue cloud on the screen. Just to be clear,  it is the carrier, she's absolutely right about that. The cool thing is with NG911, it's no longer  just the carrier. That's right. So if Facebook and WhatsApp want to send emergency traffic to an  NG911 system and they're using the ITF standards for how you do stuff like that, they can absolutely  do it and it will work fine. Totally. But remember, now we have new service providers who are not  traditional telcos who now are able to associate traffic with a 911 environment, right? Like,  who's WhatsApp? Who knows who they are? Do we know? Well, you all have the app, but have you  talked to the CEO of WhatsApp? No, you're not going to do that. So this gets to an interesting  question of like, how do we validate trust end to end, right? Because this is what we're about  to exploit. The third part of this architecture are these legacy and next generation public  safety answering points, right? So ultimately, what the duration of this talk is going to focus on  is the association between those public safety answering points and that EZNet, right? That  emergency services IP network. So let's talk. Yeah, real quick. I want to give a shout out. The  National Highway Traffic Safety Administration operates the National 911 office, which is really  unfortunate within our government. There is like one person with a handful of contractors who's  who's a boss. She's awesome, Laurie Flaherty. They actually put this diagram together. They're  great for this stuff. So big shout out to NHTSA and the National 911 office. Thanks, Laurie.  So let's talk protocols for a minute. So because this is really what we're going to be exploiting  in the next couple of slides. We have this thing called the ESRP or the Emergency Services Routing  Protocol. This is basically a SIP proxy, right? Handles all SIP traffic that's initiated with  inside of the EZNet. The second piece that we have is this emergency call routing function or  the ECRF. This determines the best or most appropriate PSAP. Not necessarily the closest,  but the most appropriate, right? So like, if you're, can you give a use case about where  one wouldn't be the closest but most appropriate? Perfect example of this. If you are standing right  near the border between two counties, one county has its 911 system literally directly across the  line within like feet of you, but you're here. The people that respond, the people that are supposed  to answer that call are your counties 911 center. It may be farther away. Clear across the state.  But it's still the right one because you're inside its service contour, which gets important in a  minute. So then the last piece we have is the policy routing function, which really defines the  non-geographic assets of routing, right? Like, you know, flag these calls, send all these calls to  this one public safety answering point because they have like special analysts or, you know,  telecommunicators who are there, who are the 911 call takers, right? Somebody who might be  specially trained in some sort of methodology. And then the last one is ICAM, which we all know,  identity credential access management. So these are really the four, the four different pieces of  the network that we're going to interface with. So what's the trouble with trust? This is a really  important piece because what we've done is we've talked about is we took this legacy methodology  of trust from the PSTN. We laid it on the IP network. Remember that all calls under all circumstances  must reach 911, even if the authentication fails. Everything has to go through. Why? Because  if something happens, we want to make sure that somebody's taken care of. We've got a great quote  on this in a second. It's just not acceptable to say, we're sorry your certificate is expired.  Please hold and bleep to death. And we'll have someone with you in a wait time of five to ten  minutes. But the interesting part here is what we've built underneath of this model of all calls  must go through is a fail working model. And that fail working mode is really important and is what  we're about to talk through the exploitation. So this is, I'm personally very proud of this. I  this, I would love to say this was intentional and I hacked DEF CON knowing that someday I would  give this talk, but that's total BS. But two years ago I asked Bruce Shiner a question about how do  we get folks to, how do we drive adoption of secure communications technologies by making sure  that access to emergency services, which for people experiencing some kinds of emergencies,  it's really important. You know, if you're being abused, if you know how you have a medical condition,  you don't want other people to know about that. We have to keep up trust. And Bruce thought about  it for a second and he said, you know, if there's some reason the PKI doesn't work, if there's  some reason the fucking PKI doesn't work, I want to fucking talk to 911. Amen. And I guarantee you  everybody feels that way, right? I mean, you don't ever want to hear, we're sorry, the OCSP server  is offline, you can't call 911 today. That's not, that's just not okay. So that has consequences  though. You know, in military communications and financial communications and literally everything  else we do, if the authentication fails or the encryption fails, we say don't handle that traffic  because it's, you know, it's not good. We don't want it. It's potentially malicious. In 911,  that's not an option for us. We don't get that privilege. So we have to work around it. And that  has real consequences for vulnerabilities in deployed systems. So we're going to talk through  what our methodology was for exploitation of the emergency services IP network and basically that's  side of the architecture for NG911. So when we wanted to do our research here, we focused on  not necessarily low hanging fruit, but the hard to solve problem. Because the hard to solve problem  here is how do we make sure that all calls go through and could frankly, we haven't figured  that piece out. And that's why we're here because we're going to talk about our exploitation. What  we did figure out though is how to use the fail working model to our nefarious advantage. So  I'm going to talk through the steps that we took. The first one was we exploited the underlying  cryptographic vulnerability in the current implementation of the standard, not in the  standard itself. We'll talk through that. Two, we got command and control inside of the Esynet.  We were able to forge geolocation coordinates for both where our public safety answering point is  supposed to be in the world. And thus it's also its inherent service contour. But also where all  of your calls are supposed to come from is very different from where we tell the Esynet where  they actually come from. We were able to set up a denial of service attack to DOS, the other public  safety answering points, and capture all the failover traffic. So in three different ways we  figured out how to subsume all of the possible traffic so we get all of the calls. So all calls  flow to basically my laptop. Important caveat, very important caveat. We did not do this in the  world. So I'm not going to jail for DEF CON. Sorry guys. Output was we did this at a research lab.  We went to Texas A&M University to the Internet 2 lab. They were incredibly cool to have us.  We're going to give a huge shout out at the end for them. But I want to note that there are some  really important things here. This is a lab environment. It's not a production environment.  So things are going to operate differently. They're both neater and cleaner in some areas.  They're also way more fucked up in other areas, right? The other piece of this though is that  some of this is just the way that the software is currently implemented. And because it's not  running in a production environment, some things we were able to do, we don't know if they will  fix in production. So we figured out what those really awful things were, like read write privileges  and privilege escalation and figure out then how to take those and go back to the vendors to help  them make a more secure solution. And I'll just point out there that a lot of this, so there are a  lot of NG911 systems that are deployed today. They're sort of transitional. And so some of these  things you probably could go and do if there was something attached to those other than like analog  voice channels. But there isn't. So it's kind of hard to pop certificates over TDM voice.  Yeah. So this is not an O-day talk. Sorry, guys. So let's start with our first step, exploitation  of certificates. So NG911 uses certificates to assure trust. So they're not just letting people  blank fire. There is in the standard a requirement for certificate authority, but it's called the  PSAP credentialing authority and due to reasons mostly involving money, it doesn't exist yet.  Womp, womp. So while it calls for that certificate authority, they're actually today just using  self-signed certificates. Boom. So here's the problem with self-signed certificates. You can do  easy certificate exploitation. So let's walk through the methodology. So we start by getting on the  wire with SSL strip, sip vicious, wire shark, and a few other tools. We see the cert as it floats  by on the wire. We pull it down. We now form it. And as you'll see in line six, the certificate says  maximum ponage. That's really interesting. No way that's auto-generated. So we now supply our  self-signed certificate to our own virtual public safety answering point, right? So we have access  to a virtual one because Texas A&M was cool enough to give us one, but you can also go out and get  them because they exist because we want emergency response to be dynamic. So we have this public  safety answering point. We have our own certificate. We have all the drivers. We've got all the ports  correctly configured. We associate it with a network. And what happens next? Boom goes the  dynamite. We're now authenticated to the emergency services IP network or the EZNet in equal  privilege to everybody else. It accepts our certificate and now we're on. And what happens?  SIP sessions start moving because it has load balancers that are inherent in the network.  We don't have to do anything but provide the network our base geolocation coordinates to start  getting traffic. So we've invented a bullshit PSAP. We've supplied the EZNet with a bullshit  certificate and we already start capturing 911 calls. But after we do this, because I'm a special  brand of interesting person, I wanted to do two different types of geolocation attacks. The first  one is I wanted to see if I could move my PSAP. So why would I want to do that? So I've got this  rogue, you know, it's like a rogue base station attack basically. You want to put the victim in  geolocation to your infrastructure. So I moved my infrastructure to be in geolocation of whatever  I wanted. So in this circumstance, right, the ESRP uses this function called loss, the location  and service translation and it requires the ECRF, sorry, to use the location data interface to  figure out where I actually am. Do you want to? Yeah, and the cool thing about this is like it  NG911 is designed using these like awesome IETF standards track things like lost and held  and devices called forest guides that make it possible for your gadgetry to figure out where  you are for the network to figure out where you are and then to communicate that information we  hope securely to an NG911 system. They use for the part we're talking about here though, they also  use something called GIS, geospatial information systems to define the service contours of  911 centers. That's right. This is all of the calls within this polygon go to this center and  here's the IP address of its border controller. So we switched our service contour to move from Texas  to Ballet's Paris hotel giving DEF CON its very first PSAP. So all calls in all calls in our part  of Texas where we actually are are now received in DEF CON basically by my laptop. Not particularly  cool. The other part though of this attack and this is the other interesting part is we were able  to forge the geolocation of inbound calls. So it's one thing to change the geolocation of the  public safety answering point. It's another thing to write a short script and run it on top of the  Esynet that says put all inbound calls into a 10 meter radius of the middle of my service  contour. So we grab, they have nowhere else to go. We grab all traffic even if we're not able to get  to this level of exploitation. Even if for some reason there's something on the network that  senses that's bullshit, that's not your geolocation, you're not supposed to be the correct PSAP.  It doesn't matter because on the other side if we're able to attach at all we can direct all the  calls to us anyway. In fact if we wanted to we could selectively, we could basically man in the  middle your pitaflow, position information, data format, location object. That's the thing that  the location information server sends into the 911 center to say here's where the caller is. We could  actually man in the middle of that, alter it and then the forest guides will tell your carrier network  to send the call somewhere else, basically somewhere of our choosing. And that's, we didn't,  we didn't write that up here but that's certainly another way you could do this very simply because  the pitaflows are not signed. The carrier doesn't have to sign that to say this person is actually  where I assert that they are. Or you could look for a single phone number of an inbound caller,  a single phone number of an inbound caller, you can track and identify an actual individual and  you can make their call, not all calls, just that one call go to the public safety answering point  you want. Anybody see Oceans 11? Because it was filmed here in Vegas. I mean that essentially  happened. They had to like physically tap something to do that. Yep. Because of the nature of the  911 network but that wouldn't be required. Right. You could just say okay any 911 calls from within,  I think it was the MGM grant in that case, please bring those to us. Totally. So not having Brad Pitt  and George Clooney at hand, we also had to figure out a failover vulnerability. So when we talk about  this fail working model that we discussed previously with all calls must go through, we're going to  show two use cases. The way it's supposed to work and then the way we made it work. So when we did  the failover vulnerability, we have this, you know, basically public safety answering point. So this  is the NG911 function running on top of the Ezzie net. You have a good public safety answering  point. This is like the legit good dues they're supposed to be there. They start connecting,  right? They exchange their certificates, they're all copacetic, they start getting SIP traffic.  We have another good public safety answering point, right? Because we have multiple public  safety answering points in a state. Because these are the 911 call centers. So there's like 50 or  whatever. You know, sorry for being a little flippant about the number, but you know, it depends  on the state. And so, but what happens if we now sever this line of communication? Well, if they  drop the session, the good PSAP goes away and it fails over to the other good PSAP, right? That's  good. We want that to happen. In a hurricane, one public safety answering point gets knocked out,  they lose power, something happens, it rolls over, calls get balanced, all calls still go through.  What's the way that the other way that this could work? Well, we use this attack called  VoIPer, straight got it off GitHub. I'm not going to invent like I wrote the code. But so we use  VoIPer attack to go after the quality of service of the SIP connection between this bot, this cloud,  ooh, the cloud, and the good PSAP, right? So we have the public safety answering point in  our, just like we did in our last one. And it connects over here, but then we also have our  evil PSAP, ooh. And so our evil PSAP initiates a SIP attack using VoIPer against the quality of  service of that connectivity between the NG911 function on the EZNet and the good PSAP. And so  when it starts doing that, what we're able to do is turn that good PSAP, because we're cutting off  its line of communication, because we're fucking with QoS, right, into a sad PSAP. And now that we  have our sad PSAP, we get all the traffic. All your 911 calls are belong to us. Boom. So why  would we do this? Right? It's cool to be able to do this in a lab. But why is this actually  important? Beyond the fact that we're looking to bring people into the security research field on  this. Well, it's important to understand who the threat actors for these things would be. So I  mean, it's one thing to be able to like, invent some cool vulnerability, but like, if no one's  going to use it, then so what? Well, ultimate reality here is that this is the tomfoolery and  trickery of the criminal element, right? You get them to look the other direction, then you punch  them in the neck. And the way that we do that here is we think through a circumstance in which you  would have someone or a group of people who would work, for example, in the criminal element, like  organized crime or others who would want to be able to do things like rob a bank, capture all the  911 calls from people saying the bank's being robbed, and just basically move them to DevNol.  And at the end of what we've done here basically is we figured out how people would choose to use  911 as a veneer, right? The comfort that people get when they call 911 and take that availability  away from them. And you could easily imagine people wanting to do this in multiple fields. And  because basically what we've done is we've used the system redundancy against the network itself,  we have been able to express the same type of tactics, techniques and procedures that we would  expect from criminal element. And I'll point out, let me give you kind of a hypothetical example of  like where and why this could matter. So one of the big like sexy use cases for NG911, if you  remember the Christmas Day bombing attack from New York City, that was stopped because someone  called 911 and they said there's this creepy looking white van, here's the license plate, blah,  blah, blah. That's great, that works. Creepy looking white van, it's a Ford license plate, etc.  It would be much better for us in the public safety community if the person making that on  one call could instead simply snap a picture of the creepy looking white van and send that to us  so that we can then decide, okay, is this relevant? Yes, great, push it out to the cops on the street,  go after this creepy looking white van. Because that stops, you know, I had a buddy that got,  you know, yanked out of his truck and thrown to the ground with, you know, guns to his head,  basically, because he was driving a truck that looked like one of an armed robber.  You know, with photographs, it's harder for that to happen, hopefully. But somebody could easily,  in a circumstance like that, alter that information. If they were lurking, the attacker could have  said, okay, I see that photograph coming across the wire, let's make the white van red to her cell.  Yeah, so I mean, you can fool the integrity and availability of these systems, but what's  important to understand is it's not just the 911 network, it's a critical infrastructure network.  Like, these are things that people use that we all pay money for that's supposed to work that  we're supposed to be able to rely on, and that's why you have to do vulnerability research in these  areas. But not all is lost, there are mitigations, Trey. Yes, so we talked earlier in my organization,  we're the standards developers, and the great thing is we do actually have a small number of  very dedicated, very knowledgeable people on IP networking and ITF standards and security to  some extent, although that's probably our biggest limitation right now. They came up with two things,  both the i3 standard, that's the standard for how you do ng911. It has tons of security related  functional entities and protocols and so forth baked in. The border control functions do special  things, the routing proxies do things, you know, we mark suspicious traffic, all that sort of stuff.  But then on top of that, they actually published another standard called ngsec, that's the security  standard for ng911. I will tell you, it is good, it's not great, it's not done. It is a wonderful  document as it is, but there are tons of things that the public safety community has not yet  thought about to put in there because we've never had intrusion detection before. What are you  going to detect? The pizza guy called instead of, you know, a ng911 call, that doesn't help.  We've never had a lot of these security related things that we're going to have to have now,  and so just knowing about it enough to put it in a document is like step one for our community,  it's very important. We have the ability, as I said, in the standard to mark unauthenticated  traffic as suspicious, and now with some of the recent rule changes by the FCC, we should have  much better capability to use reputation scoring for phone numbers and things like that to make  decisions about, okay, do we think this is likely to be a nefarious call from the media standpoint.  I have, we mentioned the PSAP credentialing authority, the special CA. That does not exist yet,  but there is an RFP being put together for that, and I looked at what I hope and pray will be the  final version that I have to edit last week, and so it'll be about another two months, I think,  before an RFP goes out for the CA, which is a good thing, but we also still have to figure out how  to pay for it because that, you know, in the public sector, everyone is so flush with cash that they  just, you know, have tons of it lying around. Not really. Depends on which state, but not really.  And for now, there's this sort of inherent mitigation, which is that even though most of the  carrier networks are now natively IP, SIP, you know, VoIP basically, and even though there are  NG911 systems out there that are natively IP and SIP, in the middle, everything is getting converted  to TDM to go over like one set of trunks and use one particular switch so that it can still get  to the place where it's just going to be turned right back into what it was to start with, which  is not terribly efficient, but it is sort of a security protection because turning your traffic  into TDM first like breaks a lot of the stuff that we talk about here because none of the IP  stuff actually makes it out the other end. Plus, even if we wanted to get away from the technical  side of things, right, like if you're a public safety answering point and you normally get like  80 calls in an hour and you get no calls for like three hours, you can probably start to imagine  that there's something up, right? So there's like, if you're just a smart person, you'll figure out  that you're under attack depending on what the nature of the attack is, and you can then contact  your systems administrator on line seven, or you could contact any people who run the emergency  services network and they can begin doing some sort of analysis or forensics to determine these  things. So these are bad things that absolutely 100% can happen today, but we have a reasonable  expectation that by getting people who are smart together in a room and working through it, that  we'll get there. Also, and that the process you just talked about can be automated actually.  There are people right now looking at it. So it turns out the 911 call is exceptionally regular.  We see it beautifully in terms of like the flow by time of day, day of week, etc. And so you can  start to automate things like around, okay, am I getting far more calls or far fewer calls than I  should reasonably expect? Standard deviation. Yeah. So we'll leave. Oh, sorry. I got a couple,  a couple more mitigations here. First off, we could start having, we talked earlier that the  location objects are not signed. We should absolutely be signing those. And that's actually  going to be part of a future revision to the standard, we think. Yep. Same thing with PSAP  service contours. Those should be signed as well once the CA exists. We can start to do some things  like low level sanity checking. We can say if the GPS chip in the cell phone says it's in Texas,  and it's showing the call is being presented at a PSAP in Las Vegas, well, okay, there's a  mismatch there and we should find out why that's happening unless we intended it to. And we can  also do things like we can say if this is attached to a cable modem that's in Kansas, then the call  should not be showing up at a PSAP that's in Florida. So we can start to do some of the  database stuff that we do today to kind of sanity check some of this. Also implementing TLS for all  the held lookups is really important. Go RC. That depends on the CA again. So we'll leave you guys  with a couple of parting shots. As we said before, it's really vital that 911 always work for everyone  because lives really are at stake. And there's a lot of work left to be done to make sure that all  of these things are secure to start with and become even more secure down the line. So one of the  big reasons that we put into present this year was to basically put out a call for help to say  our community in public safety, we're not as unfriendly as we seem sometimes. We desperately  need the folks in this room to be part of the community. And one of the ways you can do that is  by joining us at dev.neena.org. That's our standards development portal for those of you who've used  Covey before. It's a Covey site. And we would love to have you if you want to actively participate,  that's where to sign up. It's a little scary given the pervasive nature of 911 that this is  probably the largest group of security professionals that's ever been involved at all in this type  of security research. That should scare people. It's not a good idea the two knuckleheads or  the guys who are leading research on this. And so we'd ask you to do, if you're interested in this,  if you have like a persistent interest in NGSec and 911 security, tonight at 4 p.m. at Burgers,  we're going to be holding a meetup where I will personally pay for one round of drinks for half  of you, depending on the number of people who show up. So come for the beer and the jokes and the  conversation. But we want to start a community of people who actually get involved in research on  this. You can make a legit difference and we're here to support for that. Also shameless self-promotion,  we will have the first ever 911 security conference this October. It's going to be in Columbus,  Ohio, that garden spot. And we'll have at least four or five hundred security pros or mainly  public safety pros. We're going to be talking through some of these issues. So we'd love to have  anybody there that can join us. So shout out to our team. We had a couple of people who helped us  out. Tom Blackard with Team Secure Set, Jake Nelson with Team Secure Set, and with Team Texas  and in University, Walt Magnussen and this really awesome little network nerd, Derek Ladd, who just  made it hop. So cheers to them. So now I have one personal shout out. Yeah, please. So two years  ago I came here as a total noob, as a fucking lawyer, as someone who had no business at all being at  DEF CON. And the guy back here from queercon brought me in. They are my family now. They are  wonderful. These badges are the coolest thing you will ever see at DEF CON. Right on. Big hands. So  thank you to you guys for getting me up here. So now's the dangerous part of the talk. We open to  comments, prayer requests, song dedications, but no smug assertions of infosex superiority. Amen.  So there should be microphones I think some place. There's one down here.  One over there some place.  Hello. Since the HIPAA standard actually deals with 911 and emergency centers where a patient  cannot die simply because your computers aren't up. I was wondering how much have you actually  looked at and it's really scary if you actually consider emergency room security and improvement,  but actually it might be. How much of that standard have you actually looked at versus trying to  reinvent the wheel? So HIPAA applies in some very specific and relatively narrow circumstances.  There are certain types of information in certain types of transit that have to be protected  in certain ways. The objective of the I3 and NGSEXPEX was to make sure that that was at least a  minimum so that we were not trying to reinvent the wheel. A lot of that should be baked in. Now  personally, because our organization just this past year, we did the first ever NIST GAP assessment  of a 911 center. And what we found was frankly somewhat terrifying because it looked like basically  a house with no windows and no doors and maybe only part of a roof that was mostly on fire.  And so we're a little bit scared about where that is. We have had just this year about six or eight  hit with ransomware and thankfully those guys were just interested in getting paid, but they  could have equally been interested in taking people's data. And so we're very conscious of the need  to protect sensitive health information. Well, no, I was thinking at a more strategic level here for  a second because I've been making the case like the risk management case with a doctor. I mean  his risk management case is you're not going to die in 15 minutes. We're fine. What's the risk?  Okay. And the information security case says, okay, they're not going to die in 15 minutes. Why would  you spend $1,000 on security versus a heart monitor? Okay. And that's the risk management case  really that you're facing, which is- So we should absolutely talk about that. But I want to get  another- So catch up with us at four o'clock at Burgers and we will definitely talk about that.  Who's next? This guy. I've got a question prefaced with an explanation for you. Go for it. My  question is how robust is the load distribution and PSAP spin-up process? How what was it? How  robust is it in NG911? And the reason that I'm asking that question is that there was a fantastic  101 on Thursday regarding virtual PBX switch, SIP access, and being able to spam a phone number  with a shitload of phone calls. So if say a person who wants to cause chaos in a certain town  could buy 500 SIP lines and then spam 10,000 calls an hour. So never mind NG911 at all. Forget  that that exists for a second. We're just in today's NG911 world. The average 911 center has a  grand total of five or six inbound trunks. You pop one enterprise call manager at a small business,  not even a medium business. You can overload a region easily. And we don't have any way to  defend against that. Like there's no, you know, it's difficult and terrifying and so we don't  know what to do about that. I'd also say if you go, if you, yeah right. So and remember it's just  a lab environment but computationally to spin up a virtual PSAP. So that took about an hour and a  half to get that set. But like that thing eats like a hog, right? So if you throw enough traffic  at it, not just from like a telecom denial service perspective, but if you make that thing eat  enough, it's going to take itself down. So we have to be really careful about our implementation.  I'll be honest, I dozed myself twice, right? Like it's going to happen. So yeah, it's not as  robust as it needs to be. Is there a way to mitigate that on your guys' checklist? Not yet. Not yet.  There are some, and there have been attacks by the way. People have DOS PSAPs over their admin  lines. International SIP gateway exchanges have really messed up, messed with them. Go for it.  Two questions. First of all, the database that you mentioned earlier that has all the addresses.  Location information server. Yeah. Is it 1D or an E? Is it 1D database or does every telephone  company have their own database? Is it proprietary? So it depends on which one you're talking about.  If you're talking about in the E911 world, can you scroll back to that while I talk? In the  E911 world, there's a Master Street address guide in each town, basically. There is a  selective routing database and an alley automatic location identification database. In theory,  for each carrier, but in practice, they're all outsourced to about three companies. Yeah. So the  data is proprietary or? Yes. For now. My second question is regarding the NCS GETS system, are  they having similar problems in transitioning? Do they use as a net? So funny story, actually,  we used to work at DHS in the component that runs WPS and GETS. Thanks for knowing about it. You're  the guy. Yeah. You're the one. They are actually working now on next generation GETS and WPS.  I don't know where it is because I've been out of that now for six years, but yeah, that's  definitely happening. Anybody consider pen testing that too? Yeah. I mean, it still uses  underlying compromise, you know, like infrastructure, right? Like SS7 and a lot of other  infrastructure. So NGN GETS is not as secure as you might believe it to be because it's not TDM  based. So most of this is new to me. Is any of this 911 stuff crossover with the Amber Alert  system? No. Okay. So we'll say excellent talk. You mentioned funds are a major issue in a  severely aging infrastructure, especially in some of the more rural areas in Texas as well.  That being said, I'm a firefighter and first responder, so I have a unique  viewpoint rather dealing with city management for funds, not only for fire gear, but everything  else. Yes, sir. You start talking about a lot of this stuff to city and police and everybody  else. They're going to start looking like, you know, you're a heretic and want to burn you. So  how do you, how are you going to approach that? Very carefully. But no, that is like, that's  the biggest thing for our organization being the 911 association. We just decided, you know what,  burn us at the stake if you want. We are going to talk about this until it's all fixed. Yeah.  Like, dude, this has to happen for police, fire, EMS, civil servants, also just people, right? Just  everybody else. Like, my nightmare scenario is somebody screws the geolocation coordinates up  and they send your guys into a building and that's a chem fire instead of a regular fire, right?  That's, that's a clusterfuck. So this has to get taken care of. Okay. Thank you guys. You've  been wonderful. Thank you. Thank you.
DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_0_3143.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_3144_5603.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_5604_6119.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_6120_7055.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_7056_8111.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_8112_10007.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_10008_10055.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_10056_10979.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_10980_11027.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_11028_11123.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_11124_13703.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_13704_15071.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_15072_15467.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_15468_16007.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_16008_17591.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_17592_17879.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_17880_18131.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_18132_19871.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_19872_20183.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_20184_22391.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_22392_22871.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_22872_24947.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_24948_28055.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_28056_28199.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_28200_29699.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_29700_29951.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_29952_31679.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_31680_33623.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_33624_35195.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_35196_35759.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_35760_36215.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_36216_42107.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_42108_43799.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_43800_43883.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_43884_44627.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_44628_45407.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_45408_47591.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_47592_50267.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_50268_55691.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_55692_57635.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_57636_58391.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_58392_60791.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_60792_63275.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_63276_63359.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_63360_63611.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_63612_64427.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_64428_64583.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_64584_65135.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_65136_65999.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_66000_66491.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_66492_66683.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_66684_67559.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_67560_67619.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_67620_67679.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_67680_67727.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_67728_67775.png DEF_CON_24_-_CINCVolFLT__AK3R303_-_NG911__The_Next_Gen_of_Emergency_Ph0nage_2JztRvdIY1w_67776_67796.png
We've got a great presentation going for you on Next Generation 911 Security. We're calling it the Next Generation of Emergency Phonage. Myself, my name is Alex Kryline. I'm the CTO of SecureSet, a Cyber Security Academy in Denver. I used to be a strategist with the Department of Homeland Security and a researcher with NIST. I'm also a level 8 cyber wizard. That's me. This is my partner, Trey. I'm Trey Forgutty. I'm the director of government affairs and they call me the resident teenager at the NINA, the 911 Association. It's got a great face. We're the standards developer for everything related to 911. So when you get found, when you call from a cell phone, we're the reason that's actually possible. I'm also a former presidential management fellow. Alex and I did very similar tours. I was at DHS, FCC, and TIA, kind of all over the federal government. The reason that I'm still into like computers and security stuff in spite of being, and I'm going to use the official DEF CON term, a fucking lawyer. Fucking lawyer. In spite of that. The reason that I can still be into all this sort of stuff is because in addition to that, I'm a physicist and a navigator. So these are things that, technologies that are still very interesting and important to me and I kind of try to keep on top of stuff. Also a pirate, true story. So a couple of opening shots to set the stage a little bit. We're going to talk about some vulnerabilities in the way trust is implemented in next generation 911, which we're going to tell you all the sort of background about first. There's a really important reason that we're doing this in the public safety community. We're very comfortable with not telling people things. Like we, you know, everybody knows the police department, the fire department, they just love sharing information, right? Well, 911 is the same way. The problem is in today's information security environment, that doesn't work. The only way you get stuff fixed is by talking about it and bringing people like you together to say, oh, okay, how can we poke at this and figure out how it works and break it and make it better? So that's why we're doing this. And, you know, we believe very passionately our organization does that talking about vulnerabilities makes us stronger. And so we're going to be doing that. This October we're actually doing the first 911 cybersecurity conference. It'll be in Columbus, Ohio. It's going to be really cool. Same reason I tell my dates I cry in my sleep. So the, I'm going to talk a little bit in the first part of this, a little bit of history. And it's important to understand that today's 911, the 911 that you could use if you called right now, is it's called E911. That's a part of the telephone age. It's not a part of the computer age and it's certainly not a part of the internet age. It really is a part of the telephone age. There are things here like time division multiplexing and class 5 ESS switches that you just like, people like us don't ever want to see in our day jobs because that just means we're doing something wrong, right? But 911, that's all that it runs on. And that has some consequences. So historically trust in the public switch telephone network was this very sort of inherent thing. You had relatively high confidence usually that the person you were calling was the person that you got because there was physical security of the trunks running through conduits and overhead cable. The signaling was very obscure until folks like Cat and Crunch, Tea Profit and folks that the telephorics really got into poking around with the network. Things like medium frequency signaling and camo, which is centralized automated message accounting, which is no joke, a paper tape protocol invented in the 1950s, which is still used to connect 911 calls today. No joke, if you make a 911 call, it's probably being connected by a camera. And carrier pigeon. That too. You also had control plane segregation, legal protections, all these sorts of things. And that just meant that you didn't have to worry about things like certificates and authentication and cryptography and so forth. That just wasn't in the mindset. And it's still largely not in the mindset of public safety professionals. So back in the 1968, 1960s, the International Association of Fire Chiefs and ultimately a big thing called the President's Commission on Law Enforcement and the Administration of Justice got together and they really like imagined the public safety system of the future. This is a report that was issued in about 1967, I think. And in this report, they actually envisioned having 911, having computer aided dispatching, automatic vehicle location and radios on every copy. That's pretty amazing at a time when like a radio was something that you could just barely fit in the trunk of a car. So we've come a long way and this is kind of how we got there. So the fundamental problem that we're trying to solve with all of this stuff is who called us and where and with what. Those are important things. We need to know who needs help and how do we find them to get the help to them. And it's also important for reasons that we'll talk about in a second to understand what they were calling with because the 911 system was part of the wire line world, right? Telephones were these big heavy metal things that sat on tables that some nice man came and installed at your house. I've seen the videos. That changed though in the 1980s when all of a sudden a phone could be a three pound hunk of metal that you put in the floorboard of your car. And those no longer had convenient addresses. And then all of a sudden crazy people came along and started sending voice calls over this internet thing that nobody knew anything about. And we decided, okay, well, those should probably have access to 911 too because otherwise somebody's going to pick one up one day because it looks like a telephone and they're not going to get what they expect. So the world that all of this is designed for just to kind of set the stage in your mind, in 911, the way it really works, you've got when you when you establish telephone service with a wire line phone, the phone company takes your address from you on the service order and they validate it against this maroon box called the master street address guide. It's a list of all the street names in a jurisdiction and all the correct address ranges. They look it up in the fixed database, make sure that it's valid and then they record it in that purple box, the automatic location identification database. And then at call time when you when you call in the selective router, that's just a class five telephone switch. It uses your phone number to dereference your address and send that to the 911 center over typically a you know these days they might be up to like, you know, 14.4 kilobit modems. And I'm really not exaggerating that that's true. A lot of these are, you know, old very modern infrastructure. The 90s. The 92s still out there. And the great thing is because of that now, you know, in the early days of 911, all of the people in a town, regardless of which was like the right 911 center, the right police department in those days, all the calls went to one place, which was not great because you might be in the other part of the county that's actually served by the city. And so that's why this thing is called a selective router. It can also decide, hey, you're in Robertsville, not Alice Springs, send that to the other PCAP. PCAP is a public safety answering point. It's fancy time for 911 center. And this is important because what we're going to be talking about this same type of logical trust model is what's bolted on to IP networks, right? So understanding that the phone company trusts the phone company because it's all the phone company is really important because we didn't change that even though it's not the phone company anymore. That's where our exploitation is about to come in. The line we actually put on the conference CD is that in the beginning, the AT&T created the PSTN and the trust model was void and without form. Hallelujah. Because they were the phone company, damn it. Can I get an amen? So there are some problems with keeping this kind of stuff around because if you do this, and this has been talked about at DEF CON before, static databases become vulnerable to spoofing. If you can spoof the automatic number identification, then as provided you're sort of generally in the same jurisdiction as the 911 center you want to target, you can get a call to look like it's coming from someone else. And these sorts of things have been used in like swatting attacks to basically convince a 911 center that in fact this is Brian Krebs for example calling 911. Which happens. Which is probably not. Spoofing any automatically spoof sally, this is a terrible horrible miserably unethical thing to do and we strongly encourage you not to because it makes you a terrible human being. The thing is in the PSTN world there is no flag to say hey this looks kind of suspicious, maybe treat it differently. And all of this legacy equipment is getting really expensive, everything is going over the top, people want to communicate with RTT and videos and pictures and electronic medical records and all this stuff and you can't fit that over a voice channel. And so that's kind of the forcing function that is getting us to NG number one. So we have a better way. We'll just put that on the internet. Nope. Yeah. But seriously, a lot of people here next generation 911 they hear that it's IP based and they immediately say oh you're putting 911 on the internet, how could you be so stupid? Well first off no we're not. That's not the idea. Almost. We're not. Okay fine. Stop trying to make the internet happen. So it's going to be over private managed IP networks. It's all hopefully going to be very secure. But as we're going to talk about in a bit there are some reasons why things have to work differently for life safety systems. So other sort of externalities that matter for us. Carriers are walking away from their legacy TDM infrastructure. They don't want to be in this business anymore because it doesn't make money, it's expensive to maintain, it's highly regulated. So even in places where you know they are keeping up the copper network, they're no longer keeping up the copper network for the purpose of carrying analog voice. They're actually giving you like a DSL terminal adapter for your house and then spitting the telephone stuff out the back end of that. They're doing the conversion inside the home. And that has real consequences because now that changes the way that the voice call part of it is being carried even in the wireline world. And as I already said there are lots of different ways that people now want to communicate that from our perspective we want to accommodate because we want people to be able to get 911 natively the way they need it. There's even a proceeding right now at the FCC about PSTN sunset, right? So regardless of whether or not the carriers choose to do this, they're going to be required to do this in a very short term period of time. So that's why NG911 is very important is because it's the new standard that can sit on top of IP based networks which is what we're rolling to but we have to fix some things. Our organization and a few others got together and formed something called the NG911 Now Coalition. And basically our goal, you can find it's NG911Now.org. Our goal is to have NG911 rolled out nationwide by the end of the year 2020. That's really aggressive and it's going to be hard but we're pushing hard with Congress, the FCC, the carriers, everybody to try and get that done because we need it badly. So what's the purpose for wanting to do this, right? Because now we're starting to transition into a, okay, well we know we have to move to this new thing because the PSTN is going away. But there are lots of things that we could do to just preserve PSTN functionality on an IP network, right? But the thing that's also driving it is a desire for shiny new toys. We want things like dynamic location based routing, which we will very much talk about in just a moment. We want failover ease and the ability to transfer calls to the appropriate public safety answering point on a really dynamic basis because the telephone's hardwired. We want to be able to do mobile public safety answering points. We want virtualized public safety answering points. So imagine we have a hurricane and all the public safety answering points are blown away. Okay, cool. So understanding that that happens, then how do you respond? The way you respond is by spinning up a new public safety answering point. But remember that we have this problem with trust in the PSTN, right? Because we're not the phone company anymore. Now we're lots of different organizations who all want equal privileged access. That gets into some really interesting problems and NG911, while it is absolutely necessary, it is still totally the Jetsons on some level because we haven't quite figured out how to do the thing that we really want to accomplish. So I'm going to talk for just a moment about the i3 architecture. This is done by Nina, big shout out. i3 architecture has basically three different types of components. The first component is the carrier service environment, right? Or rather the originating service environment. These are the carriers like AT&T, Verizon, T-Mobile, Sprint, Comcast, everybody else who dials into the emergency services IP network or the EZNet. That's that central big blue cloud on the screen. Just to be clear, it is the carrier, she's absolutely right about that. The cool thing is with NG911, it's no longer just the carrier. That's right. So if Facebook and WhatsApp want to send emergency traffic to an NG911 system and they're using the ITF standards for how you do stuff like that, they can absolutely do it and it will work fine. Totally. But remember, now we have new service providers who are not traditional telcos who now are able to associate traffic with a 911 environment, right? Like, who's WhatsApp? Who knows who they are? Do we know? Well, you all have the app, but have you talked to the CEO of WhatsApp? No, you're not going to do that. So this gets to an interesting question of like, how do we validate trust end to end, right? Because this is what we're about to exploit. The third part of this architecture are these legacy and next generation public safety answering points, right? So ultimately, what the duration of this talk is going to focus on is the association between those public safety answering points and that EZNet, right? That emergency services IP network. So let's talk. Yeah, real quick. I want to give a shout out. The National Highway Traffic Safety Administration operates the National 911 office, which is really unfortunate within our government. There is like one person with a handful of contractors who's who's a boss. She's awesome, Laurie Flaherty. They actually put this diagram together. They're great for this stuff. So big shout out to NHTSA and the National 911 office. Thanks, Laurie. So let's talk protocols for a minute. So because this is really what we're going to be exploiting in the next couple of slides. We have this thing called the ESRP or the Emergency Services Routing Protocol. This is basically a SIP proxy, right? Handles all SIP traffic that's initiated with inside of the EZNet. The second piece that we have is this emergency call routing function or the ECRF. This determines the best or most appropriate PSAP. Not necessarily the closest, but the most appropriate, right? So like, if you're, can you give a use case about where one wouldn't be the closest but most appropriate? Perfect example of this. If you are standing right near the border between two counties, one county has its 911 system literally directly across the line within like feet of you, but you're here. The people that respond, the people that are supposed to answer that call are your counties 911 center. It may be farther away. Clear across the state. But it's still the right one because you're inside its service contour, which gets important in a minute. So then the last piece we have is the policy routing function, which really defines the non-geographic assets of routing, right? Like, you know, flag these calls, send all these calls to this one public safety answering point because they have like special analysts or, you know, telecommunicators who are there, who are the 911 call takers, right? Somebody who might be specially trained in some sort of methodology. And then the last one is ICAM, which we all know, identity credential access management. So these are really the four, the four different pieces of the network that we're going to interface with. So what's the trouble with trust? This is a really important piece because what we've done is we've talked about is we took this legacy methodology of trust from the PSTN. We laid it on the IP network. Remember that all calls under all circumstances must reach 911, even if the authentication fails. Everything has to go through. Why? Because if something happens, we want to make sure that somebody's taken care of. We've got a great quote on this in a second. It's just not acceptable to say, we're sorry your certificate is expired. Please hold and bleep to death. And we'll have someone with you in a wait time of five to ten minutes. But the interesting part here is what we've built underneath of this model of all calls must go through is a fail working model. And that fail working mode is really important and is what we're about to talk through the exploitation. So this is, I'm personally very proud of this. I this, I would love to say this was intentional and I hacked DEF CON knowing that someday I would give this talk, but that's total BS. But two years ago I asked Bruce Shiner a question about how do we get folks to, how do we drive adoption of secure communications technologies by making sure that access to emergency services, which for people experiencing some kinds of emergencies, it's really important. You know, if you're being abused, if you know how you have a medical condition, you don't want other people to know about that. We have to keep up trust. And Bruce thought about it for a second and he said, you know, if there's some reason the PKI doesn't work, if there's some reason the fucking PKI doesn't work, I want to fucking talk to 911. Amen. And I guarantee you everybody feels that way, right? I mean, you don't ever want to hear, we're sorry, the OCSP server is offline, you can't call 911 today. That's not, that's just not okay. So that has consequences though. You know, in military communications and financial communications and literally everything else we do, if the authentication fails or the encryption fails, we say don't handle that traffic because it's, you know, it's not good. We don't want it. It's potentially malicious. In 911, that's not an option for us. We don't get that privilege. So we have to work around it. And that has real consequences for vulnerabilities in deployed systems. So we're going to talk through what our methodology was for exploitation of the emergency services IP network and basically that's side of the architecture for NG911. So when we wanted to do our research here, we focused on not necessarily low hanging fruit, but the hard to solve problem. Because the hard to solve problem here is how do we make sure that all calls go through and could frankly, we haven't figured that piece out. And that's why we're here because we're going to talk about our exploitation. What we did figure out though is how to use the fail working model to our nefarious advantage. So I'm going to talk through the steps that we took. The first one was we exploited the underlying cryptographic vulnerability in the current implementation of the standard, not in the standard itself. We'll talk through that. Two, we got command and control inside of the Esynet. We were able to forge geolocation coordinates for both where our public safety answering point is supposed to be in the world. And thus it's also its inherent service contour. But also where all of your calls are supposed to come from is very different from where we tell the Esynet where they actually come from. We were able to set up a denial of service attack to DOS, the other public safety answering points, and capture all the failover traffic. So in three different ways we figured out how to subsume all of the possible traffic so we get all of the calls. So all calls flow to basically my laptop. Important caveat, very important caveat. We did not do this in the world. So I'm not going to jail for DEF CON. Sorry guys. Output was we did this at a research lab. We went to Texas A&M University to the Internet 2 lab. They were incredibly cool to have us. We're going to give a huge shout out at the end for them. But I want to note that there are some really important things here. This is a lab environment. It's not a production environment. So things are going to operate differently. They're both neater and cleaner in some areas. They're also way more fucked up in other areas, right? The other piece of this though is that some of this is just the way that the software is currently implemented. And because it's not running in a production environment, some things we were able to do, we don't know if they will fix in production. So we figured out what those really awful things were, like read write privileges and privilege escalation and figure out then how to take those and go back to the vendors to help them make a more secure solution. And I'll just point out there that a lot of this, so there are a lot of NG911 systems that are deployed today. They're sort of transitional. And so some of these things you probably could go and do if there was something attached to those other than like analog voice channels. But there isn't. So it's kind of hard to pop certificates over TDM voice. Yeah. So this is not an O-day talk. Sorry, guys. So let's start with our first step, exploitation of certificates. So NG911 uses certificates to assure trust. So they're not just letting people blank fire. There is in the standard a requirement for certificate authority, but it's called the PSAP credentialing authority and due to reasons mostly involving money, it doesn't exist yet. Womp, womp. So while it calls for that certificate authority, they're actually today just using self-signed certificates. Boom. So here's the problem with self-signed certificates. You can do easy certificate exploitation. So let's walk through the methodology. So we start by getting on the wire with SSL strip, sip vicious, wire shark, and a few other tools. We see the cert as it floats by on the wire. We pull it down. We now form it. And as you'll see in line six, the certificate says maximum ponage. That's really interesting. No way that's auto-generated. So we now supply our self-signed certificate to our own virtual public safety answering point, right? So we have access to a virtual one because Texas A&M was cool enough to give us one, but you can also go out and get them because they exist because we want emergency response to be dynamic. So we have this public safety answering point. We have our own certificate. We have all the drivers. We've got all the ports correctly configured. We associate it with a network. And what happens next? Boom goes the dynamite. We're now authenticated to the emergency services IP network or the EZNet in equal privilege to everybody else. It accepts our certificate and now we're on. And what happens? SIP sessions start moving because it has load balancers that are inherent in the network. We don't have to do anything but provide the network our base geolocation coordinates to start getting traffic. So we've invented a bullshit PSAP. We've supplied the EZNet with a bullshit certificate and we already start capturing 911 calls. But after we do this, because I'm a special brand of interesting person, I wanted to do two different types of geolocation attacks. The first one is I wanted to see if I could move my PSAP. So why would I want to do that? So I've got this rogue, you know, it's like a rogue base station attack basically. You want to put the victim in geolocation to your infrastructure. So I moved my infrastructure to be in geolocation of whatever I wanted. So in this circumstance, right, the ESRP uses this function called loss, the location and service translation and it requires the ECRF, sorry, to use the location data interface to figure out where I actually am. Do you want to? Yeah, and the cool thing about this is like it NG911 is designed using these like awesome IETF standards track things like lost and held and devices called forest guides that make it possible for your gadgetry to figure out where you are for the network to figure out where you are and then to communicate that information we hope securely to an NG911 system. They use for the part we're talking about here though, they also use something called GIS, geospatial information systems to define the service contours of 911 centers. That's right. This is all of the calls within this polygon go to this center and here's the IP address of its border controller. So we switched our service contour to move from Texas to Ballet's Paris hotel giving DEF CON its very first PSAP. So all calls in all calls in our part of Texas where we actually are are now received in DEF CON basically by my laptop. Not particularly cool. The other part though of this attack and this is the other interesting part is we were able to forge the geolocation of inbound calls. So it's one thing to change the geolocation of the public safety answering point. It's another thing to write a short script and run it on top of the Esynet that says put all inbound calls into a 10 meter radius of the middle of my service contour. So we grab, they have nowhere else to go. We grab all traffic even if we're not able to get to this level of exploitation. Even if for some reason there's something on the network that senses that's bullshit, that's not your geolocation, you're not supposed to be the correct PSAP. It doesn't matter because on the other side if we're able to attach at all we can direct all the calls to us anyway. In fact if we wanted to we could selectively, we could basically man in the middle your pitaflow, position information, data format, location object. That's the thing that the location information server sends into the 911 center to say here's where the caller is. We could actually man in the middle of that, alter it and then the forest guides will tell your carrier network to send the call somewhere else, basically somewhere of our choosing. And that's, we didn't, we didn't write that up here but that's certainly another way you could do this very simply because the pitaflows are not signed. The carrier doesn't have to sign that to say this person is actually where I assert that they are. Or you could look for a single phone number of an inbound caller, a single phone number of an inbound caller, you can track and identify an actual individual and you can make their call, not all calls, just that one call go to the public safety answering point you want. Anybody see Oceans 11? Because it was filmed here in Vegas. I mean that essentially happened. They had to like physically tap something to do that. Yep. Because of the nature of the 911 network but that wouldn't be required. Right. You could just say okay any 911 calls from within, I think it was the MGM grant in that case, please bring those to us. Totally. So not having Brad Pitt and George Clooney at hand, we also had to figure out a failover vulnerability. So when we talk about this fail working model that we discussed previously with all calls must go through, we're going to show two use cases. The way it's supposed to work and then the way we made it work. So when we did the failover vulnerability, we have this, you know, basically public safety answering point. So this is the NG911 function running on top of the Ezzie net. You have a good public safety answering point. This is like the legit good dues they're supposed to be there. They start connecting, right? They exchange their certificates, they're all copacetic, they start getting SIP traffic. We have another good public safety answering point, right? Because we have multiple public safety answering points in a state. Because these are the 911 call centers. So there's like 50 or whatever. You know, sorry for being a little flippant about the number, but you know, it depends on the state. And so, but what happens if we now sever this line of communication? Well, if they drop the session, the good PSAP goes away and it fails over to the other good PSAP, right? That's good. We want that to happen. In a hurricane, one public safety answering point gets knocked out, they lose power, something happens, it rolls over, calls get balanced, all calls still go through. What's the way that the other way that this could work? Well, we use this attack called VoIPer, straight got it off GitHub. I'm not going to invent like I wrote the code. But so we use VoIPer attack to go after the quality of service of the SIP connection between this bot, this cloud, ooh, the cloud, and the good PSAP, right? So we have the public safety answering point in our, just like we did in our last one. And it connects over here, but then we also have our evil PSAP, ooh. And so our evil PSAP initiates a SIP attack using VoIPer against the quality of service of that connectivity between the NG911 function on the EZNet and the good PSAP. And so when it starts doing that, what we're able to do is turn that good PSAP, because we're cutting off its line of communication, because we're fucking with QoS, right, into a sad PSAP. And now that we have our sad PSAP, we get all the traffic. All your 911 calls are belong to us. Boom. So why would we do this? Right? It's cool to be able to do this in a lab. But why is this actually important? Beyond the fact that we're looking to bring people into the security research field on this. Well, it's important to understand who the threat actors for these things would be. So I mean, it's one thing to be able to like, invent some cool vulnerability, but like, if no one's going to use it, then so what? Well, ultimate reality here is that this is the tomfoolery and trickery of the criminal element, right? You get them to look the other direction, then you punch them in the neck. And the way that we do that here is we think through a circumstance in which you would have someone or a group of people who would work, for example, in the criminal element, like organized crime or others who would want to be able to do things like rob a bank, capture all the 911 calls from people saying the bank's being robbed, and just basically move them to DevNol. And at the end of what we've done here basically is we figured out how people would choose to use 911 as a veneer, right? The comfort that people get when they call 911 and take that availability away from them. And you could easily imagine people wanting to do this in multiple fields. And because basically what we've done is we've used the system redundancy against the network itself, we have been able to express the same type of tactics, techniques and procedures that we would expect from criminal element. And I'll point out, let me give you kind of a hypothetical example of like where and why this could matter. So one of the big like sexy use cases for NG911, if you remember the Christmas Day bombing attack from New York City, that was stopped because someone called 911 and they said there's this creepy looking white van, here's the license plate, blah, blah, blah. That's great, that works. Creepy looking white van, it's a Ford license plate, etc. It would be much better for us in the public safety community if the person making that on one call could instead simply snap a picture of the creepy looking white van and send that to us so that we can then decide, okay, is this relevant? Yes, great, push it out to the cops on the street, go after this creepy looking white van. Because that stops, you know, I had a buddy that got, you know, yanked out of his truck and thrown to the ground with, you know, guns to his head, basically, because he was driving a truck that looked like one of an armed robber. You know, with photographs, it's harder for that to happen, hopefully. But somebody could easily, in a circumstance like that, alter that information. If they were lurking, the attacker could have said, okay, I see that photograph coming across the wire, let's make the white van red to her cell. Yeah, so I mean, you can fool the integrity and availability of these systems, but what's important to understand is it's not just the 911 network, it's a critical infrastructure network. Like, these are things that people use that we all pay money for that's supposed to work that we're supposed to be able to rely on, and that's why you have to do vulnerability research in these areas. But not all is lost, there are mitigations, Trey. Yes, so we talked earlier in my organization, we're the standards developers, and the great thing is we do actually have a small number of very dedicated, very knowledgeable people on IP networking and ITF standards and security to some extent, although that's probably our biggest limitation right now. They came up with two things, both the i3 standard, that's the standard for how you do ng911. It has tons of security related functional entities and protocols and so forth baked in. The border control functions do special things, the routing proxies do things, you know, we mark suspicious traffic, all that sort of stuff. But then on top of that, they actually published another standard called ngsec, that's the security standard for ng911. I will tell you, it is good, it's not great, it's not done. It is a wonderful document as it is, but there are tons of things that the public safety community has not yet thought about to put in there because we've never had intrusion detection before. What are you going to detect? The pizza guy called instead of, you know, a ng911 call, that doesn't help. We've never had a lot of these security related things that we're going to have to have now, and so just knowing about it enough to put it in a document is like step one for our community, it's very important. We have the ability, as I said, in the standard to mark unauthenticated traffic as suspicious, and now with some of the recent rule changes by the FCC, we should have much better capability to use reputation scoring for phone numbers and things like that to make decisions about, okay, do we think this is likely to be a nefarious call from the media standpoint. I have, we mentioned the PSAP credentialing authority, the special CA. That does not exist yet, but there is an RFP being put together for that, and I looked at what I hope and pray will be the final version that I have to edit last week, and so it'll be about another two months, I think, before an RFP goes out for the CA, which is a good thing, but we also still have to figure out how to pay for it because that, you know, in the public sector, everyone is so flush with cash that they just, you know, have tons of it lying around. Not really. Depends on which state, but not really. And for now, there's this sort of inherent mitigation, which is that even though most of the carrier networks are now natively IP, SIP, you know, VoIP basically, and even though there are NG911 systems out there that are natively IP and SIP, in the middle, everything is getting converted to TDM to go over like one set of trunks and use one particular switch so that it can still get to the place where it's just going to be turned right back into what it was to start with, which is not terribly efficient, but it is sort of a security protection because turning your traffic into TDM first like breaks a lot of the stuff that we talk about here because none of the IP stuff actually makes it out the other end. Plus, even if we wanted to get away from the technical side of things, right, like if you're a public safety answering point and you normally get like 80 calls in an hour and you get no calls for like three hours, you can probably start to imagine that there's something up, right? So there's like, if you're just a smart person, you'll figure out that you're under attack depending on what the nature of the attack is, and you can then contact your systems administrator on line seven, or you could contact any people who run the emergency services network and they can begin doing some sort of analysis or forensics to determine these things. So these are bad things that absolutely 100% can happen today, but we have a reasonable expectation that by getting people who are smart together in a room and working through it, that we'll get there. Also, and that the process you just talked about can be automated actually. There are people right now looking at it. So it turns out the 911 call is exceptionally regular. We see it beautifully in terms of like the flow by time of day, day of week, etc. And so you can start to automate things like around, okay, am I getting far more calls or far fewer calls than I should reasonably expect? Standard deviation. Yeah. So we'll leave. Oh, sorry. I got a couple, a couple more mitigations here. First off, we could start having, we talked earlier that the location objects are not signed. We should absolutely be signing those. And that's actually going to be part of a future revision to the standard, we think. Yep. Same thing with PSAP service contours. Those should be signed as well once the CA exists. We can start to do some things like low level sanity checking. We can say if the GPS chip in the cell phone says it's in Texas, and it's showing the call is being presented at a PSAP in Las Vegas, well, okay, there's a mismatch there and we should find out why that's happening unless we intended it to. And we can also do things like we can say if this is attached to a cable modem that's in Kansas, then the call should not be showing up at a PSAP that's in Florida. So we can start to do some of the database stuff that we do today to kind of sanity check some of this. Also implementing TLS for all the held lookups is really important. Go RC. That depends on the CA again. So we'll leave you guys with a couple of parting shots. As we said before, it's really vital that 911 always work for everyone because lives really are at stake. And there's a lot of work left to be done to make sure that all of these things are secure to start with and become even more secure down the line. So one of the big reasons that we put into present this year was to basically put out a call for help to say our community in public safety, we're not as unfriendly as we seem sometimes. We desperately need the folks in this room to be part of the community. And one of the ways you can do that is by joining us at dev.neena.org. That's our standards development portal for those of you who've used Covey before. It's a Covey site. And we would love to have you if you want to actively participate, that's where to sign up. It's a little scary given the pervasive nature of 911 that this is probably the largest group of security professionals that's ever been involved at all in this type of security research. That should scare people. It's not a good idea the two knuckleheads or the guys who are leading research on this. And so we'd ask you to do, if you're interested in this, if you have like a persistent interest in NGSec and 911 security, tonight at 4 p.m. at Burgers, we're going to be holding a meetup where I will personally pay for one round of drinks for half of you, depending on the number of people who show up. So come for the beer and the jokes and the conversation. But we want to start a community of people who actually get involved in research on this. You can make a legit difference and we're here to support for that. Also shameless self-promotion, we will have the first ever 911 security conference this October. It's going to be in Columbus, Ohio, that garden spot. And we'll have at least four or five hundred security pros or mainly public safety pros. We're going to be talking through some of these issues. So we'd love to have anybody there that can join us. So shout out to our team. We had a couple of people who helped us out. Tom Blackard with Team Secure Set, Jake Nelson with Team Secure Set, and with Team Texas and in University, Walt Magnussen and this really awesome little network nerd, Derek Ladd, who just made it hop. So cheers to them. So now I have one personal shout out. Yeah, please. So two years ago I came here as a total noob, as a fucking lawyer, as someone who had no business at all being at DEF CON. And the guy back here from queercon brought me in. They are my family now. They are wonderful. These badges are the coolest thing you will ever see at DEF CON. Right on. Big hands. So thank you to you guys for getting me up here. So now's the dangerous part of the talk. We open to comments, prayer requests, song dedications, but no smug assertions of infosex superiority. Amen. So there should be microphones I think some place. There's one down here. One over there some place. Hello. Since the HIPAA standard actually deals with 911 and emergency centers where a patient cannot die simply because your computers aren't up. I was wondering how much have you actually looked at and it's really scary if you actually consider emergency room security and improvement, but actually it might be. How much of that standard have you actually looked at versus trying to reinvent the wheel? So HIPAA applies in some very specific and relatively narrow circumstances. There are certain types of information in certain types of transit that have to be protected in certain ways. The objective of the I3 and NGSEXPEX was to make sure that that was at least a minimum so that we were not trying to reinvent the wheel. A lot of that should be baked in. Now personally, because our organization just this past year, we did the first ever NIST GAP assessment of a 911 center. And what we found was frankly somewhat terrifying because it looked like basically a house with no windows and no doors and maybe only part of a roof that was mostly on fire. And so we're a little bit scared about where that is. We have had just this year about six or eight hit with ransomware and thankfully those guys were just interested in getting paid, but they could have equally been interested in taking people's data. And so we're very conscious of the need to protect sensitive health information. Well, no, I was thinking at a more strategic level here for a second because I've been making the case like the risk management case with a doctor. I mean his risk management case is you're not going to die in 15 minutes. We're fine. What's the risk? Okay. And the information security case says, okay, they're not going to die in 15 minutes. Why would you spend $1,000 on security versus a heart monitor? Okay. And that's the risk management case really that you're facing, which is- So we should absolutely talk about that. But I want to get another- So catch up with us at four o'clock at Burgers and we will definitely talk about that. Who's next? This guy. I've got a question prefaced with an explanation for you. Go for it. My question is how robust is the load distribution and PSAP spin-up process? How what was it? How robust is it in NG911? And the reason that I'm asking that question is that there was a fantastic 101 on Thursday regarding virtual PBX switch, SIP access, and being able to spam a phone number with a shitload of phone calls. So if say a person who wants to cause chaos in a certain town could buy 500 SIP lines and then spam 10,000 calls an hour. So never mind NG911 at all. Forget that that exists for a second. We're just in today's NG911 world. The average 911 center has a grand total of five or six inbound trunks. You pop one enterprise call manager at a small business, not even a medium business. You can overload a region easily. And we don't have any way to defend against that. Like there's no, you know, it's difficult and terrifying and so we don't know what to do about that. I'd also say if you go, if you, yeah right. So and remember it's just a lab environment but computationally to spin up a virtual PSAP. So that took about an hour and a half to get that set. But like that thing eats like a hog, right? So if you throw enough traffic at it, not just from like a telecom denial service perspective, but if you make that thing eat enough, it's going to take itself down. So we have to be really careful about our implementation. I'll be honest, I dozed myself twice, right? Like it's going to happen. So yeah, it's not as robust as it needs to be. Is there a way to mitigate that on your guys' checklist? Not yet. Not yet. There are some, and there have been attacks by the way. People have DOS PSAPs over their admin lines. International SIP gateway exchanges have really messed up, messed with them. Go for it. Two questions. First of all, the database that you mentioned earlier that has all the addresses. Location information server. Yeah. Is it 1D or an E? Is it 1D database or does every telephone company have their own database? Is it proprietary? So it depends on which one you're talking about. If you're talking about in the E911 world, can you scroll back to that while I talk? In the E911 world, there's a Master Street address guide in each town, basically. There is a selective routing database and an alley automatic location identification database. In theory, for each carrier, but in practice, they're all outsourced to about three companies. Yeah. So the data is proprietary or? Yes. For now. My second question is regarding the NCS GETS system, are they having similar problems in transitioning? Do they use as a net? So funny story, actually, we used to work at DHS in the component that runs WPS and GETS. Thanks for knowing about it. You're the guy. Yeah. You're the one. They are actually working now on next generation GETS and WPS. I don't know where it is because I've been out of that now for six years, but yeah, that's definitely happening. Anybody consider pen testing that too? Yeah. I mean, it still uses underlying compromise, you know, like infrastructure, right? Like SS7 and a lot of other infrastructure. So NGN GETS is not as secure as you might believe it to be because it's not TDM based. So most of this is new to me. Is any of this 911 stuff crossover with the Amber Alert system? No. Okay. So we'll say excellent talk. You mentioned funds are a major issue in a severely aging infrastructure, especially in some of the more rural areas in Texas as well. That being said, I'm a firefighter and first responder, so I have a unique viewpoint rather dealing with city management for funds, not only for fire gear, but everything else. Yes, sir. You start talking about a lot of this stuff to city and police and everybody else. They're going to start looking like, you know, you're a heretic and want to burn you. So how do you, how are you going to approach that? Very carefully. But no, that is like, that's the biggest thing for our organization being the 911 association. We just decided, you know what, burn us at the stake if you want. We are going to talk about this until it's all fixed. Yeah. Like, dude, this has to happen for police, fire, EMS, civil servants, also just people, right? Just everybody else. Like, my nightmare scenario is somebody screws the geolocation coordinates up and they send your guys into a building and that's a chem fire instead of a regular fire, right? That's, that's a clusterfuck. So this has to get taken care of. Okay. Thank you guys. You've been wonderful. Thank you. Thank you.
my name is Alex Kryline. I'm the CTO of used to be a strategist with the Department of Homeland Security and a researcher with NIST. I'm my partner, Trey. I'm Trey Forgutty. I'm the to talk about some vulnerabilities in the way telephone switch. It uses your phone number to department in those days, all the calls went to is a public safety answering point. It's fancy on to IP networks, right? So understanding that where our exploitation is about to come in. The because if you do this, and this has been talked way. We'll just put that on the internet. Nope. internet happen. So it's going to be over private managed IP networks. It's all hopefully going to be very secure. But as we're going to talk about There's even a proceeding right now at the FCC they're going to be required to do this in a very well we know we have to move to this new thing PSTN functionality on an IP network, right? But Safety Administration operates the National 911 the Emergency Services Routing Protocol. This is may be farther away. Clear across the state. But methodology of trust from the PSTN. We laid it on in military communications and financial methodology was for exploitation of the emergency the architecture for NG911. So when we wanted to we're going to talk about our exploitation. What both where our public safety answering point is its inherent service contour. But also where all exploitation. So let's walk through the emergency services IP network or the EZNet in though of this attack and this is the other previously with all calls must go through, we're the way that the other way that this could work? network, it's a critical infrastructure network. standards and security to some extent, although with, which is not terribly efficient, but it is thing you will ever see at DEF CON. Right on. Big data. And so we're very conscious of the need to telecom denial service perspective, but if you