We've got a great presentation going for you on next generation 9-1-1 security.
We're calling it the next generation of emergency phonage.
Myself, my name is Alex Kryline.
I'm the CTO of SecureSet, a cybersecurity 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 Forgety. I'm the Director of Government Affairs.
And they call me the resident teenager at NINA, the 9-1-1 Association.
It's got a great face.
We're the standards developer for everything related to 9-1-1.
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 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 9-1-1,
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, you know, everybody knows.
The police department, the fire department, they just love sharing information, right?
Well, 9-1-1's 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 9-1-1 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 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 9-1-1, the 9-1-1 that you could use if you called right now,
it's called E-9-1-1.
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 ESL.
There are things here like time division multiplexing and class 5 ESL.
People like us don't ever want to see in our day jobs because that just means we're doing something wrong, right?
But 9-1-1, 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 absurd.
Until folks like Cap'n Crunch, T-Profit, and folks, the telefreaks really got into poking around with the network.
Things like medium frequency signaling and CAMA, which is centralized automated message accounting,
which is no joke, a paper tape protocol invented in the 1950s, which is still used to connect 9-1-1 calls today.
No joke, if you make a 9-1-1 call, it's probably being connected by a CAMA.
And carrier pigeon.
That too.
You also had control plane segregation, legal protection.
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 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 9-1-1,
having computer-aided dispatching, automatic vehicle location and radios on every cop.
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 9-1-1 system was part of the wireline 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 3-pound cell phone.
A 3-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 9-1-1 too because otherwise somebody's going to pick one up one day
because, well, 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 E-9-1-1, the way it really works,
you've got, when you establish telephone service with a wireline 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 call in, the selective router, that's just a class 5 telephone switch.
It uses your phone number to dereference your address and send that to the 9-1-1 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's true. A lot of these are, you know, old...
Very modern infrastructure.
For the Bundys.
V-92 is still out there.
And the great thing is because of that now, you know, in the early days of 9-1-1,
all of the people in a town, regardless of which was like the right town,
the right 9-1-1 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 PSAP.
PSAP is a public safety answering point.
It's a fancy term for 9-1-1 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, 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?
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 9-1-1 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 9-1-1 center that in fact this is Brian Krebs,
for example, calling 9-1-1 when it's actually not.
Which happened.
Spoofing Annie automatically spoofs Allie.
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, right?
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-9-1-1.
So we have a better way.
We'll just put that on the internet.
Nope.
Yeah.
No.
But seriously, a lot of people hear Next Generation 9-1-1,
they hear that it's IP based and they immediately say,
oh, you're putting 9-1-1 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.
Okay, fine.
Yeah.
Stop trying to make the internet happen, Alex.
All right.
It's not going to 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 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.
Yeah.
Our organization and a few others got together and formed something called the NG911 Now Coalition.
And basically our goal, you can find us at 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 you 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.
Tough when it's hardwired.
Yeah, on a really dynamic basis because the telephone is 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 questions.
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, Kali.
Comcast.
Everybody else who dials into the emergency services IP network or the EziNet.
That's that central big blue cloud on the screen.
Just to be clear, it is the carriers.
He's absolutely right about that.
The cool thing is with NG911, it's no longer just the carriers.
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, 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.
Just 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 whose role it is to make…
And she's a boss.
She's awesome.
She's got a lot of clarity.
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?
It handles all SIP traffic that's initiated 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 piece
Not the nearest.
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?
So a 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 county's 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 flag these calls.
Send all these calls to this one public safety answering point.
Because they have like special analysts or 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 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 is 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 it's what we're about to talk through the exploitation.
So this is, I'm personally very proud of 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 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.
Mop.
That's not, that's just not okay.
So that has consequences though.
You know in military communications.
In financial communications.
In 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 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 quite 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 failed 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 ESI net.
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 ESI net 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.
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 privileged 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.
There's not.
It's kind of hard to pop certificates.
If it's over TDM voice.
Yeah.
So this is not an Oday 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.
Wireshark and a few other tools.
We see the cert as it floats by on the wire.
We pull it down.
We malform it.
And as you'll see in line six.
The certificate says maximum pwnage.
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 the network.
And what happens next?
Boom goes the dynamite.
We're now authenticated to the emergency services IP network or the EZ net 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 EZ net 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, NG911 is designed using these laws.
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.
That's right.
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 Bali's Paris hotel.
Giving DEF CON its very first PSAP.
So 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 EZNet that says put all inbound calls into a 10 meter radius of the middle of my service contour.
So they have nowhere else to go.
We grab all traffic, even if we're not able to get to this level of exploitation.
Right?
Even if we, if for some reason there's something on the network that senses that that's bullshit.
That's not your geolocation.
You're not supposed to be the correct PSAP.
Right?
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 pit of flow.
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.
Yep.
We could actually man in the middle 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 write that up here, but that's certainly another way you could do this very simply because the pit of flows are not signed.
Yeah.
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 Ocean's 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 Grand in that case.
Yep.
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 EZNet.
You have a good public safety answering point.
This is like the legit good dues that are 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 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 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 ESI net 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 good?
Yeah.
All of them 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 Dev Null.
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.
Right?
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, et cetera.
It would be much better for us in the public safety community if the person making that 911 call could instead simply snap a picture of the creepy-looking white van.
That's right.
And send that to us so that we can then decide, okay, is this relevant?
Yes.
Great.
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 sell.
Yeah.
So, I mean, you can fool with the integrity and availability of these systems, but what's important to understand is it's not just a 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.
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 IETF 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 in G911.
It has tons of security-related functional entities and protocols and so forth baked in.
The border control functions do special things.
Yep.
You know, 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.
Yep.
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 911 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?
Do we think this is likely to be a nefarious call from the media standpoint?
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 will 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 a day,
100 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 of the 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.
Right.
There are people right now looking at,
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 at this time?
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 RFC.
That depends on the CA.
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 in to 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.nina.org.
That's our standards development portal
for those of you who have 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, right?
That should scare people, right?
It's not a good idea that two knuckleheads
are 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 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.
Jake Nelson with Team SecureSet,
and with Team Texas A&M University,
Walt Magnuson,
and this really awesome little network nerd,
Derek Ladd, who just made it hot.
Cheers to them.
I have one personal shout-out.
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 guys back here from Queer Con brought me in.
They are my family now.
They are wonderful.
These badges are the coolest thing you will ever see at DEF CON.
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 InfoSec superiority.
Amen.
So there should be microphones, I think, someplace.
There's one down here.
One over there someplace.
Hello.
Hello.
Since the HIPAA standard
actually deals with 911 and emergency centers
where a patient cannot die
simply because their 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
an improvement,
but how much have you actually looked at
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 certain ways.
The objective
of the I3 and NGSEC specs
was to make sure that that was at least a minimum
so that we were not
we're not trying
to reinvent the wheel.
A lot of that should be baked in.
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 more of a 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.
So, catch up with us at 4 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 E911 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.
It's difficult and terrifying
and so we don't know what to do about that yet.
Don't do that.
So, if you go
and remember this is a lab environment
but computationally
to spin up a virtual PBX
app, so that took about
an hour and a half to get that set.
But that thing
eats like a hog, right?
So, if you throw enough traffic at it,
not just from a telecom denial of service
perspective, but if you make that thing
eat enough, it's going to take itself down.
So, we need to be really careful about our
implementation. I'll be honest, I dosed myself
twice. 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.
There are some, and there have been
some hacks, by the way. People have dosed PSAPs
over their admin lines.
International SIP gateway exchanges
have really 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.
Is there an NG or an E?
Is it one 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.
So, the data is proprietary?
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.
You might consider pen testing that too.
Yeah, I mean, it still uses underlying compromise
infrastructure, right, like
SS7 and a lot of other
infrastructure. So, NG and GETS is not as secure
as you might believe it to be because it's not
VM based.
So, most of this is new to me. Is
any of this 911 stuff crossover with the
AMBER alert system?
No.
Okay.
Boom.
So, I will 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. Yes, sir.
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
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 that's a chem fire instead of a regular
fire, right? That's a cluster fuck.
So this has to get taken care of. Thank you guys.
You've been wonderful. Thank you.