[00:06.070 --> 00:09.130]  All right, for those of you just joining us, welcome to day two of HOPE.
[00:10.090 --> 00:13.350]  The next panel is wireless security flaws.
[00:14.810 --> 00:19.030]  And our three panelists here have swapped numbers.
[00:20.430 --> 00:23.710]  So, but what you do on weekends is sort of your own business.
[00:25.370 --> 00:28.490]  109, 20, and 32 are their numbers.
[00:29.850 --> 00:32.210]  We have Raven, Eric, and Brandon.
[00:33.890 --> 00:36.110]  And I'll let you guys go ahead and get started.
[00:40.130 --> 00:41.250]  How's everyone doing?
[00:41.650 --> 00:42.330]  Got coffee?
[00:42.530 --> 00:43.110]  Caffeine?
[00:45.490 --> 00:46.290]  All right.
[00:46.790 --> 00:51.490]  So, this story begins simply...
[00:51.490 --> 00:59.830]  Raven, Brandon, and myself had this incident where we were driving all over the place looking at packets.
[00:59.830 --> 01:03.050]  And we found some disturbing things.
[01:03.330 --> 01:07.510]  So, the net result is we decided to look a little deeper.
[01:07.990 --> 01:10.490]  Look beneath the covers and see what we have there.
[01:10.710 --> 01:13.630]  So, we're going to present some more findings.
[01:13.950 --> 01:19.750]  What we believe to be some serious flaws in the way people are implementing things.
[01:20.030 --> 01:25.650]  And we're going to show some packet dumps and some general statistics.
[01:25.650 --> 01:27.770]  So, starting right off.
[01:28.050 --> 01:28.530]  Brandon.
[01:28.950 --> 01:29.090]  All right.
[01:37.210 --> 01:38.170]  All right.
[01:38.410 --> 01:44.510]  As many of you may be aware, it's been made trivially easy to go out war driving over the past few years.
[01:45.570 --> 01:50.310]  Prices have dropped on various products and technology is, well, it's working out pretty well.
[01:50.970 --> 01:57.810]  I think we're all also pretty aware of how bad transferring information over clear text is.
[01:59.330 --> 02:05.150]  If you have any concerns about any sort of privacy or security, you probably don't want to be doing that.
[02:07.270 --> 02:17.970]  However, we found and we also believe that a lot of protocol architects and system designers remain somewhat clueless regarding sniffing and security.
[02:18.550 --> 02:25.670]  Specifically, they make bad assumptions like, well, we don't need to worry about security because the firewall will take care of it.
[02:25.930 --> 02:34.430]  Or, the router is actually physically locked up so no one could possibly get to it and change any of our configs or really do any sort of bad things to our network.
[02:36.370 --> 02:40.230]  But, well, that's just not entirely the case.
[02:40.410 --> 02:41.790]  But no one is that dumb, right?
[02:43.570 --> 02:47.010]  Well, if that were true, then I guess this would be a pretty short presentation.
[02:47.690 --> 02:48.350]  We have captures.
[02:52.670 --> 02:57.050]  So, we have a fair amount of captures dating all the way back to 2002.
[02:57.850 --> 03:02.130]  And it's pretty astounding evidence that there's a lot of problems in this area.
[03:02.830 --> 03:06.530]  Traffic captures from several different metro areas in the United States.
[03:08.930 --> 03:14.450]  And an important thing to note was that all these captures were basically sent to us by volunteers.
[03:15.510 --> 03:21.230]  And we weren't actually trying to target network infrastructure.
[03:21.470 --> 03:22.330]  This was just random.
[03:22.590 --> 03:26.450]  Let's go out, look around the city a little bit, and see what we can find.
[03:26.650 --> 03:35.710]  So, the fact that we did find a lot of very bad things relating to routing protocols being transferred over wireless is a little more frightening.
[03:39.450 --> 03:45.170]  So, here we have a map just showing some data that was collected in our hometown of Seattle.
[03:45.670 --> 03:51.330]  And as you can see, there's quite a bit of driving around in the downtown area.
[03:51.590 --> 03:54.810]  And for some reason, some people decided to drive out east.
[03:54.970 --> 03:57.530]  I guess maybe there was something interesting out that way.
[03:57.530 --> 04:00.790]  I thought they might find some interesting information, but...
[04:02.730 --> 04:04.090]  So, why are we here?
[04:05.850 --> 04:10.610]  I'm sure most of you have probably heard the old fable of the emperor's new clothes.
[04:12.810 --> 04:20.030]  And essentially, at the very end of the story, it takes a child to stand up and say, the guy isn't wearing any clothes.
[04:20.370 --> 04:21.510]  To state the obvious.
[04:23.130 --> 04:24.770]  And we are that child.
[04:26.530 --> 04:30.850]  So, there are about five things that we are really going to focus on here.
[04:31.450 --> 04:34.790]  And the first of which is network infrastructure information disclosure.
[04:35.910 --> 04:39.950]  Next, opportunities for unauthenticated infrastructure denial of service.
[04:41.090 --> 04:48.090]  Broadcast discovery protocols, which incorporate without authentication.
[04:48.650 --> 04:50.950]  Input validation is kind of important.
[04:52.930 --> 04:55.290]  Overly trusting routing and management protocols.
[04:55.710 --> 05:00.050]  You probably don't want rogue networks being attached, announced, and propagating across your own.
[05:00.990 --> 05:03.750]  New and poorly designed small management protocols.
[05:04.130 --> 05:09.310]  Easily spoofable by pretty much anyone with a packet crafting engine, five minutes, and Google.
[05:10.450 --> 05:15.990]  So, finally, you know, the main point that we want to say here is, really, you've got to stop the madness.
[05:16.450 --> 05:16.510]  Right?
[05:17.110 --> 05:19.250]  Take responsibility and take care of your stuff.
[05:22.190 --> 05:25.210]  So, the first thing here is Cisco Discovery Protocol.
[05:25.570 --> 05:26.010]  CDP.
[05:26.250 --> 05:27.230]  It's very chatty.
[05:27.230 --> 05:29.850]  It's required for some VoIP installations.
[05:30.430 --> 05:38.350]  And it basically advertises information about your device, as well as possibly what version of iOS that you're running under.
[05:38.670 --> 05:41.410]  Again, that's not information that you want being transmitted over wireless.
[05:41.610 --> 05:47.910]  And it's definitely not information that you want, say, people like Eric to be looking at in his car.
[05:50.370 --> 05:53.410]  So, again, basically, it's used for troubleshooting.
[05:54.010 --> 05:57.590]  And, really, if you're not troubleshooting, it should be turned off.
[05:58.150 --> 06:01.990]  And, unfortunately, a lot of network administrators forget to do this.
[06:02.590 --> 06:09.030]  So, you know, they have devices that are very chatty, advertising information over wireless that really shouldn't be talking.
[06:09.530 --> 06:17.250]  And so, what we have here is some information being transferred.
[06:17.250 --> 06:22.790]  And what I want to emphasize here is all the packet captures that we're showing here, these are all captured over wireless.
[06:23.250 --> 06:23.670]  Okay?
[06:23.990 --> 06:28.010]  We didn't hook up to someone's router and just start, you know, capturing packets.
[06:28.130 --> 06:29.750]  These are all captured over wireless.
[06:30.550 --> 06:39.350]  So, as you can see, we have 3600, the model of the router, as well as the version of iOS that's running on it.
[06:40.070 --> 06:40.770]  Not good.
[06:40.910 --> 06:47.230]  It's truly easy to just type into Google and look for exploits relating to the actual router or the operating system.
[06:50.540 --> 06:52.980]  Infrastructure information disclosure over wireless.
[06:54.000 --> 06:59.320]  Management traffic tends to have quite a large amount of logs.
[06:59.820 --> 07:05.220]  And a good example of this, and I'm sure everyone is aware of, is the venerable and widely deployed syslog.
[07:05.920 --> 07:08.640]  Information is usually sent out using an encrypted UDP.
[07:09.540 --> 07:12.960]  And really, in the most common versions, almost anyone can read it.
[07:14.440 --> 07:21.540]  So, your syslog data can disclose crucial enterprise data, including device versions, like we were just talking about with CDP.
[07:22.380 --> 07:29.200]  Or not actually that, but, you know, basically information relating specifically to your network setup that you don't want other people to know about.
[07:29.200 --> 07:38.140]  So, device versions, state, errors, account credentials, PII, and then attack tracking and remediation.
[07:38.340 --> 07:43.420]  So, if you have an IDS or firewall setup on there, you definitely don't want that announcing everything that it's doing.
[07:44.110 --> 07:46.000]  On the clear, to everyone.
[07:48.070 --> 07:54.780]  So, really, it's particularly tragic when security information is being broadcast in the clear over wireless.
[07:55.760 --> 07:59.790]  Allowing an attacker to basically watch responses to everything that they're doing.
[08:00.050 --> 08:02.290]  It makes their job just a little bit easier.
[08:03.140 --> 08:06.610]  And these people really weren't doing a very good job of this.
[08:08.100 --> 08:15.400]  So, you know, as you can see, there's some information being transferred here regarding packets that are being dropped by their firewall.
[08:15.400 --> 08:18.050]  Also note the blurred sections here.
[08:18.230 --> 08:20.540]  We wanted to, you know, be nice.
[08:20.820 --> 08:24.760]  And we weren't out to really wreck any businesses or corporations.
[08:24.960 --> 08:30.480]  So, we blurred out, you know, key points in the IP addresses so that people couldn't go out looking for them.
[08:31.360 --> 08:33.880]  Everything RFC 1918, we left alone.
[08:34.260 --> 08:38.660]  Anything that you see blurred was an actual Internet address that you can reach.
[08:39.280 --> 08:39.790]  Yeah.
[08:40.700 --> 08:44.420]  So, I was really excited when I started seeing syslog across wireless.
[08:44.420 --> 08:50.160]  I mean, you can port scan someone and see all the ports that are being blocked and what's getting through.
[08:50.400 --> 08:51.570]  I mean, that's pretty exciting.
[08:51.810 --> 08:59.100]  So, from an attacker's perspective, that level of information disclosure is really fairly sensitive.
[08:59.500 --> 09:07.160]  So, obviously, you know, having syslog broadcasted across a wireless link is a bad thing.
[09:07.330 --> 09:08.450]  Sorry to interrupt.
[09:12.620 --> 09:15.900]  So, just stupid information disclosure over wireless.
[09:16.190 --> 09:17.330]  We couldn't believe this one.
[09:18.260 --> 09:25.570]  We thought it was fairly obvious to everyone by now that some data just should not be transferred over wireless.
[09:27.690 --> 09:34.600]  You know, a lot of other stuff like social security numbers, credit card information, anything financial.
[09:35.120 --> 09:42.400]  You know, essentially anything that anyone might find valuable probably shouldn't be transferred over wireless.
[09:42.600 --> 09:43.450]  Especially clear text.
[09:46.360 --> 09:47.420]  So, here we have it.
[09:48.220 --> 09:52.950]  It may be hard to see in the back, but the highlighted area says state tax.
[09:53.120 --> 09:55.040]  In the clear, it's a database file.
[09:56.280 --> 09:58.330]  So, this is SQL server traffic.
[09:59.780 --> 10:00.830]  So, there you go.
[10:01.040 --> 10:04.900]  What they were doing with these tables and the structure is, well, left up to your imagination.
[10:09.380 --> 10:13.120]  So, we're sort of building up from the least bad vulnerabilities.
[10:13.340 --> 10:15.000]  Yes, that was the least bad section.
[10:15.260 --> 10:21.380]  To worse and worse management and similar traffic that we saw over wireless.
[10:23.000 --> 10:28.040]  And for those of you who may have seen me speak before, I tend to talk about network design and engineering.
[10:28.040 --> 10:29.400]  I've done a bunch of backbone stuff.
[10:29.540 --> 10:32.020]  I used to work in ISPs before moving into security.
[10:32.820 --> 10:42.300]  And one of the reasons that I left was I got ticked off at the utter failure of ISPs to really care about these sorts of attacks.
[10:42.640 --> 10:47.380]  So, I think after Cisco gate last summer, they care a little more.
[10:47.760 --> 10:48.880]  And that's improving.
[10:49.080 --> 10:51.620]  But there's still a lot of very stupid traffic out there.
[10:51.780 --> 10:58.020]  And with the increasing deployment of wireless networks, we're seeing things that were intended to only be done in data centers.
[10:58.040 --> 10:59.380]  Sent out to everyone.
[10:59.620 --> 11:06.420]  And this opens up just unprecedented opportunities for network manipulation, denial of service, et cetera, et cetera.
[11:06.660 --> 11:11.180]  So, just to reiterate our main point, none of this stuff should ever be seen over wireless.
[11:12.440 --> 11:15.420]  So, let's talk about protocols that are designed for high availability.
[11:15.880 --> 11:17.940]  You see this in most major networks.
[11:17.940 --> 11:22.160]  Anyone that wants, you know, five nines of uptime, they're going to have some sort of set up for redundancy.
[11:22.160 --> 11:29.500]  And a lot of the time, they have protocols like HSRP or VRRP that are designed to provide this.
[11:30.060 --> 11:36.700]  These protocols on a wired network, normally you just connect these two devices that are supposed to be redundant for each other with a crossover cable.
[11:36.860 --> 11:39.500]  And they send their little heartbeat, okay, are you alive?
[11:39.560 --> 11:40.040]  I'm alive.
[11:40.200 --> 11:41.160]  Who's got the IP address?
[11:41.460 --> 11:43.800]  I've got the IP address back and forth between themselves.
[11:45.020 --> 11:52.120]  But, increasingly, we're seeing that traffic not limited to, you know, two straight throughs in a hub or a crossover cable between those boxes.
[11:52.260 --> 11:56.240]  We're seeing it go out over the main network and often get rebroadcast over wireless.
[11:57.780 --> 11:58.600]  This is bad.
[12:01.040 --> 12:04.340]  So, let's look at HSRP and VRRP in particular.
[12:04.920 --> 12:11.260]  If you don't have a device on the network segment that is actively using this for failover, you really shouldn't see it.
[12:11.260 --> 12:15.300]  Just limit it to communication between the two devices that are doing it.
[12:15.460 --> 12:16.920]  Don't send it out towards your LAN.
[12:18.420 --> 12:21.420]  Unfortunately, people aren't really getting this and we have captures.
[12:21.900 --> 12:25.700]  Now, I know there's going to be someone in the back who's going to say, Wait, wait, there's authentication.
[12:25.980 --> 12:26.980]  There's a password.
[12:27.180 --> 12:28.160]  You can lock this down.
[12:28.400 --> 12:30.480]  There's a password in clear text.
[12:30.840 --> 12:31.320]  Fantastic.
[12:31.540 --> 12:32.440]  That will really help.
[12:33.660 --> 12:34.140]  Next.
[12:35.180 --> 12:40.420]  So, here's a packet capture of HSRP that we did see in the wild over wireless.
[12:40.420 --> 12:43.000]  And you can see that they are using authentication.
[12:43.380 --> 12:44.420]  It's very proper.
[12:44.600 --> 12:48.700]  It's got the default of Cisco as the password, which I'm sure no one would ever guess.
[12:49.700 --> 12:54.100]  So, if anyone spots their own networks in these captures, just raise your hand, okay?
[12:55.320 --> 12:56.800]  We'll help you fix it, really.
[12:58.840 --> 13:01.780]  And here's VRRP, the other major redundancy protocol.
[13:01.780 --> 13:04.960]  You see this one on a lot of firewalls and they'll use it for failover.
[13:05.480 --> 13:07.400]  And once again, you can see the version.
[13:07.720 --> 13:15.200]  You can see the authentication string, which we had taken out of the headers because it wasn't a default and were ever so slightly nice.
[13:15.360 --> 13:16.340]  Well, okay, I'm nice.
[13:16.480 --> 13:16.780]  They're evil.
[13:20.040 --> 13:23.460]  And it was just fairly appalling.
[13:25.180 --> 13:25.860]  All right.
[13:26.320 --> 13:27.920]  So, here's the really bad stuff.
[13:28.260 --> 13:42.380]  Not only are people using their redundancy and failover traffic, not only are they telling you what version of iOS they're running and all sorts of sensitive internal information, but they're also announcing their routing protocols to everyone over wireless.
[13:43.440 --> 13:43.920]  Genius.
[13:45.300 --> 13:52.440]  Now, we saw this ranging from 2002 when our first captures came from up until captures from last week.
[13:52.560 --> 13:55.020]  So, this is not an old problem that people have gotten over.
[13:55.120 --> 13:56.360]  This is still going on.
[13:56.820 --> 13:59.080]  And it's only getting dumber.
[14:00.160 --> 14:03.220]  Every major urban area that we looked at had this problem.
[14:03.380 --> 14:06.760]  It wasn't like, you know, oh, only in Silicon Valley do they do this or anything.
[14:06.760 --> 14:09.640]  This is endemic and it's a system-wide problem.
[14:10.280 --> 14:15.020]  For the most part, these routing protocols that we saw were OSPF and EIGRP.
[14:15.160 --> 14:20.020]  We saw dribs and drabs of other things, but predominantly those are the most popular internal routing protocols.
[14:22.160 --> 14:30.740]  Now, for the mostly bad but not god-awful, you can gather information about the routing structure of that network through hearing the routing announcements.
[14:30.920 --> 14:32.100]  That's, you know, just how it works.
[14:32.260 --> 14:36.280]  At the very least, you're going to hear, okay, here's the device that's looking for neighbors.
[14:36.280 --> 14:37.660]  Here's its IP address.
[14:37.800 --> 14:40.380]  Here's the protocol it's speaking and what version that is.
[14:42.160 --> 14:48.160]  But the obvious attack vector here is to set up your own little router and join their network.
[14:48.720 --> 14:56.840]  And when you start speaking routing protocol to these boxes, you know, a lot of the time either there is no authentication or there's authentication in the clear again.
[14:56.840 --> 14:58.540]  And so it's very easy.
[14:58.700 --> 15:03.660]  I mean, the way that many of these protocols work is they advertise and discover their own neighbors.
[15:03.960 --> 15:08.760]  And whenever you've got that going on, you can say, oh, why, yes, I am your neighbor.
[15:09.440 --> 15:11.280]  Would you like to route my subnet?
[15:12.000 --> 15:13.140]  And there you go.
[15:13.140 --> 15:19.800]  You've got essentially an ability to sit on top of their rack in their data center and participate in their network from the inside.
[15:20.080 --> 15:21.900]  They should not allow this to happen.
[15:23.480 --> 15:26.960]  Oh, that's a, the graphic there is a little router on a stick.
[15:27.120 --> 15:29.940]  It's about the size of a piece of gum and it works.
[15:31.920 --> 15:38.880]  So let's look at what you can actually do if you have access to speak to the routing protocol on someone's network.
[15:39.160 --> 15:45.480]  And I know we've said this five times, but from the parking lot, you know, with a laptop over wireless.
[15:45.680 --> 15:49.280]  You don't need physical access, you don't need data center access, nothing like that.
[15:51.840 --> 15:57.380]  So denial of service, again, the least bad possibility, you can just announce a competing route.
[15:57.380 --> 16:00.760]  Okay, we see that your web servers are on this subnet.
[16:01.000 --> 16:02.460]  I'm going to announce this subnet.
[16:02.600 --> 16:05.000]  I'm going to try and make it preferred through the routing table.
[16:05.200 --> 16:11.460]  And all of a sudden, all traffic that's routing its way through your internal network will come to my laptop and not to your giant web farm.
[16:11.620 --> 16:14.060]  And suddenly your giant web farm isn't doing you much good.
[16:14.320 --> 16:18.080]  Your whole data center just got funneled into her car.
[16:21.240 --> 16:24.140]  Or if you're slightly more malicious, you can hijack it.
[16:24.140 --> 16:29.420]  And instead of just sending the traffic to my car, you can actually do something with it.
[16:29.640 --> 16:31.760]  Respond as though you were the web servers.
[16:31.940 --> 16:32.760]  Manipulate the data.
[16:32.880 --> 16:33.820]  Route it somewhere else.
[16:33.940 --> 16:34.860]  You know, something like that.
[16:36.340 --> 16:41.680]  Or what I've seen is the worst possibility in one of my favorite stories from Life as an Incident Responder.
[16:42.060 --> 16:44.560]  You can pick an unused subnet in their range.
[16:44.580 --> 16:51.860]  You can generally tell, like, through easy ARIN lookups and a simple look at the routing tables, what they're using within their net block and what they're not.
[16:52.180 --> 16:53.940]  You can pick something that's not used.
[16:54.100 --> 16:54.980]  You can announce it.
[16:55.140 --> 17:00.760]  The other routers will pick this up and say, hey, to get to 10.10.1.0.24, go that way.
[17:01.140 --> 17:05.980]  And then you have a platform from which you can wreak great havoc.
[17:06.240 --> 17:07.720]  You know, you can start spamming.
[17:07.720 --> 17:10.300]  You can start sending out all sorts of malware.
[17:10.680 --> 17:12.460]  And it's from their network.
[17:12.460 --> 17:13.980]  And they're going to be left holding the bag.
[17:14.660 --> 17:23.580]  Something fairly similar to this happened with a routing announcement hijack with a very large company, which was actually in Pennsylvania.
[17:23.880 --> 17:26.220]  So many of you may have heard of this a couple of years ago.
[17:27.080 --> 17:43.720]  But essentially, the bad guys hijacked the whole routing block, announced it, got it accepted preferentially in the global BGP tables, and spent about two weeks, you know, spamming and hacking and doing all sorts of nasty things out of this block that was actually owned by another company.
[17:43.720 --> 17:47.060]  And eventually, they got discovered and their ISP cut them off.
[17:47.240 --> 17:51.320]  But now this company is on the blacklist of, like, everyone on the planet.
[17:51.540 --> 17:53.380]  No one will talk to their mail servers.
[17:53.700 --> 17:57.980]  They've got all these angry people knocking down their door saying, you sent me spam, you bastards.
[17:58.420 --> 18:00.080]  And, you know, it's their IP space.
[18:00.180 --> 18:06.060]  They're not going to be able to do much except try and clean it up, mostly unsuccessfully, for an extended period of time.
[18:06.200 --> 18:09.900]  They actually ended up going back to Aaron and saying, can we have another class A, please?
[18:10.080 --> 18:10.900]  And, uh, no.
[18:13.500 --> 18:17.900]  So, obviously, if you are a network operator, you don't want this to happen to you.
[18:18.660 --> 18:30.600]  This is like your nightmare scenario, where you are visibly responsible for all this bad traffic that you didn't want to allow, all because you let your admin set up that access point for convenience and it started broadcasting stupid stuff.
[18:32.920 --> 18:38.780]  So, here's an ethereal capture of EIGRP traffic, again, that we actually saw in the wild.
[18:39.260 --> 18:46.720]  And you can see EIGRP as a Cisco protocol announces the software version both of iOS and of EIGRP.
[18:48.700 --> 18:52.100]  Here's OSPF, unauthenticated, from the wild.
[18:52.100 --> 18:55.480]  The highlighted line says, auth type null.
[18:56.000 --> 18:57.740]  Again, super genius.
[18:59.440 --> 19:02.420]  And here's OSPF, actually authenticated.
[19:02.720 --> 19:13.020]  And this capture, I can't decide what to do about, because one of the things that I've been sort of thumping my podium about for years is that I want people to authenticate their routing sessions.
[19:13.140 --> 19:17.020]  I want them to try and establish some sort of trust relationship between their neighbors.
[19:17.020 --> 19:18.360]  And these people did that.
[19:18.500 --> 19:20.840]  The highlighted line says, auth type cryptographic.
[19:21.060 --> 19:25.360]  So, you know, big hug for actually doing the right thing and authenticating your OSPF.
[19:25.500 --> 19:28.640]  And then a big smack upside the head for sending it out over wireless.
[19:30.260 --> 19:32.160]  This was the only packet we saw.
[19:32.780 --> 19:36.060]  Yeah, out of our whole capture, we saw a lot of OSPF.
[19:36.140 --> 19:38.680]  This was the only one that had authentication turned on.
[19:39.680 --> 19:40.900]  So, no love.
[19:42.720 --> 19:51.620]  The other thing that is worth considering, people who maintain large networks usually have some sort of monitoring service that will tell them what nodes are up, what nodes are down.
[19:52.220 --> 19:57.880]  And the way that these services work is also vulnerable to the sorts of packets that we're seeing over this wireless.
[19:58.960 --> 20:06.720]  You can inject things that the management service will pick up on, and it will start sending interesting data to your spoofed point.
[20:07.260 --> 20:13.480]  We're not even talking about, like, you know, sending fuzzing or overflow data to the management system, although they're full of that too.
[20:13.480 --> 20:16.700]  A lot of them run on stupid database backends with default passwords.
[20:17.280 --> 20:25.620]  But even if you don't have that, say, all right, I'm going to set up a CDP broadcast, and I'm going to announce that I have a new Cisco device on your network.
[20:25.980 --> 20:31.540]  And what will usually happen is your network management system will go, oh, hey, a new Cisco device on my network.
[20:31.680 --> 20:36.100]  All right, I'm going to SNMP poll you, and I'm going to send you my string, and you're going to respond to that, right?
[20:37.240 --> 20:39.600]  Now you have their SNMP community strings.
[20:40.280 --> 20:46.520]  And even if it's not public, this is a design flaw of the management software and the way it's set up.
[20:46.780 --> 20:56.160]  You know, it's not specific to wireless, but the additional threat exposure of doing this over wireless makes it significant enough that we thought it was worth mentioning.
[20:58.720 --> 21:05.320]  Now, the biggest pushback I've gotten on my backbone security rant is, oh, that'll never happen.
[21:05.420 --> 21:06.660]  No one ever does that.
[21:06.980 --> 21:09.720]  You know, we need to deal with the real threats out there.
[21:09.840 --> 21:11.220]  We don't have time to waste on this.
[21:12.860 --> 21:17.940]  So, if we only have one point, it is, these are the real threats.
[21:18.060 --> 21:19.820]  This is something that needs to be addressed.
[21:20.120 --> 21:21.440]  There are exploit tools.
[21:21.620 --> 21:24.140]  There's a list that you can use to do this.
[21:24.700 --> 21:32.100]  In my time as a senior backbone engineer, I have actually seen, not over wireless, but people using similar things.
[21:32.340 --> 21:35.800]  And, you know, I haven't worked as an ISP engineer in about five years.
[21:35.980 --> 21:38.480]  So, if it was happening five years ago, you know it's bad today.
[21:39.840 --> 21:46.840]  A lot of people were depending on the lack of attack tools for EIGRP because it's a Cisco proprietary protocol.
[21:47.140 --> 21:51.000]  No one wanted to write things for a Cisco proprietary protocol that might get them sued.
[21:51.000 --> 21:54.220]  And, you know, someone did it.
[21:54.420 --> 21:56.460]  There's a Russian company called Arhant.
[21:56.600 --> 21:58.940]  They wrote the Hacking Cisco Networks Exposed book.
[21:59.140 --> 22:00.600]  And they wrote a Perl script.
[22:00.860 --> 22:03.240]  And they have a little EIGRP tool suite.
[22:03.480 --> 22:05.940]  And you can spoof EIGRP packets.
[22:05.960 --> 22:08.180]  You can set the fields to be whatever you want.
[22:08.340 --> 22:10.340]  And you can answer these networks.
[22:11.020 --> 22:15.900]  There's an open source protocol suite called Zebra, which will run DEMONS.
[22:15.900 --> 22:17.600]  We're using it here for OSPF.
[22:17.700 --> 22:20.800]  But it will also run BGP, RIP, other internal routing protocols.
[22:21.460 --> 22:34.200]  And so you don't need to have, like, a $10,000 router in the back of your car hauling around this huge gigabit switch router and running it off your inverter in order to attempt to speak these routing protocols.
[22:34.360 --> 22:39.080]  You can download and compile a software package and sit in your car and do this stuff.
[22:39.080 --> 22:41.480]  It is very practical and very possible.
[22:42.000 --> 22:44.360]  There's a Layer 2 tool called Yersinia.
[22:44.980 --> 22:52.740]  And it deals with HSRP and CDP and a bunch of other Layer 2, like trunking and VLAN-type stuff.
[22:52.980 --> 22:54.840]  And it will allow you to manipulate tools.
[22:55.560 --> 22:58.800]  There's a scanner and brute-forcer tool called Cisco Torch.
[22:58.820 --> 23:01.780]  It was also written by the Arhan guys, the Russian security folks.
[23:02.220 --> 23:09.500]  And in addition to trying to brute-force a bunch of the Cisco passwords and things like that, it will also try some known exploits.
[23:09.620 --> 23:12.660]  It will try, like, the iOS web server exploit, things like that.
[23:13.240 --> 23:19.000]  And finally, FX from PhenoElite has done some really good work and has a suite of tools.
[23:19.720 --> 23:28.960]  They are targeting most major backbone protocols and you can get really excellent data when you're doing a backbone pen-test from those sorts of things.
[23:29.640 --> 23:31.640]  So, guys, this is real.
[23:31.760 --> 23:38.620]  I know I'm preaching to the choir here, but this is something you should never see over your wireless because these attacks are eminently possible.
[23:42.670 --> 23:44.850]  And we can see who did the slides and who did not.
[23:46.010 --> 23:54.250]  So, I was going to write up a bunch of slides about how angry I was about the state of routing protocols, but I decided instead I was just going to rant for a moment.
[23:57.950 --> 23:59.070]  So, let's see.
[24:00.110 --> 24:01.670]  We have all of these protocols.
[24:01.670 --> 24:10.090]  Many of them have the excuse of, well, it was written a long time ago and, you know, we just need to get something that would work and needs to be reliable.
[24:10.410 --> 24:11.530]  Crypto is too hard.
[24:11.690 --> 24:13.410]  Security is optional.
[24:14.570 --> 24:28.010]  So, with that type of mindset, we end up with a lot of our production environments, you know, the things that allow us to download porn every day, right, are running on protocols that are in the clear.
[24:28.510 --> 24:31.110]  So, this really kind of angers me.
[24:31.530 --> 24:32.990]  It angers me quite a bit.
[24:33.550 --> 24:40.490]  So, you know, a lot of energy has been spent lately trying to break DRM systems, right?
[24:40.590 --> 24:42.010]  It's in the press all the time.
[24:42.750 --> 24:48.830]  You know, perhaps most of the people in this room have spent some time reading about it or cracking it or some one thing or another.
[24:50.250 --> 24:55.570]  So, within the domain of DRM, we know that it's pretty much f*cked, right?
[24:55.750 --> 24:57.650]  We know that the media is going to get rendered.
[24:57.930 --> 24:59.770]  The keys are on the device.
[25:00.050 --> 25:02.130]  You know, they're not going to win, okay?
[25:02.850 --> 25:12.470]  In the case of routing protocols and other type of management tools, we end up in this case where it is actually possible to lock it down and secure it.
[25:12.890 --> 25:14.350]  It's just people are choosing not to.
[25:14.550 --> 25:22.630]  They're designing new protocols all the time where, you know, you read through the specification and, you know, the designers, they're not dumb people.
[25:22.950 --> 25:31.110]  You know, they say, you know, there might be this hole here where an attacker could, you know, inject and modify parameters.
[25:31.270 --> 25:35.990]  But, you know, if you're worried about that, you can enable this security feature.
[25:36.410 --> 25:37.870]  And then there's a little star.
[25:38.010 --> 25:45.290]  And you read down below and it says, well, that's in version 2 and you need to have backwards compatibility to version 1.
[25:45.290 --> 25:48.530]  So, you know, if it doesn't work, fall back to just in the clear.
[25:48.690 --> 26:04.970]  So, we end up with a lot of protocol designs on many layers, not just backbone stuff, but, you know, even your web services, backend communications, corporations, own internal enterprises where they just make a lot of assumptions about, well, there's a firewall there,
[26:05.090 --> 26:05.950]  so it's safe.
[26:07.670 --> 26:09.710]  You know, many times that is not the case.
[26:09.710 --> 26:18.050]  I actually had one engagement where we had a client seriously say that they'd put the firewall behind the access point to protect it.
[26:21.970 --> 26:22.970]  Sorry, go on.
[26:23.310 --> 26:36.490]  So, within the domain of designing things for your backend network, making the assumption that, you know, you're in this safe little place where no bad packets will enter is usually a pretty bad assumption.
[26:36.490 --> 26:38.770]  We need to stop thinking about things in that way.
[26:38.950 --> 26:43.910]  We need to start thinking about the fact that bad packets may enter your system at any point.
[26:44.090 --> 26:58.830]  So, if you were to ask an engineer who's responsible for a large backbone and say, design your system so that an attacker can plug into your switch at any point and send bad packets, they'd probably make some different design decisions about how that network was architected.
[26:59.470 --> 27:08.970]  You know, obviously, you know, binding MAC addresses to ports and using strong cryptographic verification of all the routing protocols and other such things.
[27:09.210 --> 27:14.030]  But, you know, today that's not what's actually happening out in the field.
[27:14.270 --> 27:22.890]  I mean, these packets we're seeing here, we found one packet, one packet with all the captures report through that was actually doing proper cryptographic verification of OSPF.
[27:23.850 --> 27:24.850]  Why is that?
[27:25.290 --> 27:40.170]  So, the reason why I'm kind of ranting to all these folks out here right now is that we have a lot of energy spent on breaking systems that, you know, allow us to get free porn.
[27:40.410 --> 27:42.710]  You know, everyone wants free porn, breaking DRM.
[27:42.810 --> 27:45.150]  That's very sexy and hot right now, okay?
[27:45.570 --> 27:52.730]  But there's a lot of other things out there that are still really suffering and don't have enough visibility brought to them.
[27:52.830 --> 27:59.430]  I mean, many of these routing protocols are very old, but new things are being written all the time.
[27:59.610 --> 28:13.210]  I mean, when I look at some of these packet captures, I'm seeing new protocols that, you know, Ethereum may or may not know how to parse, but frequently there are RFCs or IEEE documents about what they're used and how they work.
[28:13.430 --> 28:16.390]  Just reading through the specifications, it's absolutely terrifying.
[28:16.590 --> 28:20.550]  These things are written, you know, six months ago and they haven't thought about security.
[28:21.090 --> 28:30.210]  So, I compel all of you to go look at these systems and spend some energy and think about what the impact might really be.
[28:30.730 --> 28:33.350]  So, let's see.
[28:33.990 --> 28:38.850]  All that I wanted to say is, you know, as hackers, you guys need to pick things that suck and break them.
[28:39.430 --> 28:40.290]  Go for it.
[28:47.500 --> 28:52.290]  Okay, so, I think that's all the time I have for a rant moving along.
[28:54.110 --> 28:59.720]  Looking at all the captures we have here, we have a huge number of packets.
[28:59.880 --> 29:00.780]  Obviously, it's on wireless.
[29:00.980 --> 29:09.900]  So, most of the traffic we saw was broadcast traffic, announcements, you know, access points spewing, a lot of just beacons, you know, here I am, own me, own me.
[29:10.040 --> 29:14.590]  But, you know, some percentage of that data is obviously fascinating to us for this talk.
[29:14.850 --> 29:18.590]  So, the relative percentages are quite small as shown here.
[29:18.590 --> 29:31.960]  So, the reason why that may seem insignificant, oh, well, it's only 0.04%, is that as an attacker, if I see that 0.04%, I see that packet pop up, that means I've got a really good target.
[29:32.700 --> 29:45.520]  You know, it doesn't take anything more than one packet for a dedicated attacker to then, you know, not just randomly be driving around, but, you know, pull up in your parking lot with a case of Mountain Dew in the back, and, you know, it's all over, right?
[29:45.520 --> 29:46.350]  So...
[29:46.350 --> 29:56.350]  And, as far as threat modeling goes, if you see someone who's announcing their routing protocol or something like that, odds are they don't exactly have the best security in the world, and they're probably a feature-rich target.
[29:59.310 --> 30:05.140]  Okay, so, you know, looking at just, like, percentages of traffic, this problem's not getting any better.
[30:05.290 --> 30:12.500]  It's not like all the recent press about how bad WEP is and how Wi-Fi is scary is actually making this problem any better.
[30:12.500 --> 30:18.330]  If you look at the percentages of management traffic coming out in the clear, it's staying almost completely stable.
[30:18.740 --> 30:27.940]  Despite the fact that there's, you know, millions of new access points today than there were in 2002, the percentage of bad management traffic is still the same.
[30:28.180 --> 30:31.760]  So, that means that people haven't really thought about this.
[30:32.880 --> 30:33.440]  So...
[30:36.330 --> 30:36.890]  Okay.
[30:38.470 --> 30:50.970]  Worldwide averages, according to Wiggle and other online repositories that track access points, is that, like, 42% or something of the world has some rudimentary security turned on on their access point.
[30:51.630 --> 30:58.970]  In the areas that we're looking at, which was mostly dense urban environments, not necessarily out in the countryside, we actually found that number to be much higher.
[30:59.110 --> 31:02.670]  You know, we're talking about places like Silicon Valley, Seattle, New York, Chicago, etc.
[31:04.430 --> 31:06.090]  So, you know, that's a good thing.
[31:06.230 --> 31:11.110]  Having the WEP switch turned on helps you a little bit, right?
[31:11.230 --> 31:19.130]  Because that means, if an attacker is driving around, it doesn't scream, own me, quite as loudly.
[31:19.330 --> 31:23.730]  But, obviously, a lot of people are still running WEP that, what, six minutes and it's gone, right?
[31:23.990 --> 31:25.590]  So, it's better than in the clear.
[31:25.590 --> 31:29.750]  So, they have to pull into your parking lot ever so briefly in order to find out how bad you are.
[31:32.370 --> 31:37.770]  Okay, so let's talk about what folks should actually be doing to fix some of this stuff, right?
[31:39.010 --> 31:48.790]  Protocol design aside, there are some things you can do to configure these existing devices to make them a lot more difficult to crack and much less attractive, right?
[31:49.130 --> 31:55.210]  So, basically, don't broadcast your management traffic on your general use LAN.
[31:55.390 --> 31:57.510]  Set up a separate management LAN for this stuff, you know?
[31:57.510 --> 32:06.150]  You don't want your general use network, you know, where your employees are sitting, you don't want them to plug in an AP and expose the backbone of your organization.
[32:06.550 --> 32:07.270]  You know, they should be...
[32:07.270 --> 32:11.890]  Management traffic should be on a management net, should not mingle with the public.
[32:12.370 --> 32:13.210]  That's pretty bad.
[32:13.330 --> 32:22.330]  And one of my other things I get a lot is, people will say, oh, no, you know, there's this trade-off between security and availability, security and redundancy.
[32:22.390 --> 32:23.310]  You have to pick one.
[32:23.310 --> 32:27.030]  Having good security means we have to sacrifice our five nines and we can't do that.
[32:27.290 --> 32:29.230]  This is an obvious counterexample.
[32:29.410 --> 32:33.550]  If you're going to have a management network, you know, people make out-of-bound manage...
[32:33.550 --> 32:35.790]  or out-of-band management networks for a reason.
[32:35.930 --> 32:37.370]  That has nothing to do with security.
[32:37.530 --> 32:44.850]  It's very helpful for security, but it's so that if something goes horribly wrong on your OC48, that you can still get to that router and fix it.
[32:44.850 --> 32:52.450]  And the places that I've worked that had good, solid, reliable networks had out-of-band ways to get to them.
[32:52.730 --> 33:08.810]  And if it's a big enough network and you can afford to invest in the infrastructure, if you run your management over this, you know, separate network, you can keep it off the wireless, you can keep it separate from what Joe average user is seeing, and you will help both availability and security.
[33:09.030 --> 33:10.190]  You don't have to pick.
[33:12.670 --> 33:20.550]  So when we talk about land isolation, I mean, if I was the chief security officer and all of my employees looked like this crowd right here, I'd probably make some different decisions.
[33:21.110 --> 33:38.270]  But, you know, frequently you end up with, you know, blue-collar, white-collar employees at large organizations all over the place where they're like, ah, you know, it's just our warehouse, and, you know, they're $10 an hour packing boxes.
[33:38.270 --> 33:45.010]  They don't pose any threat to us, so we're just going to make the network all flat, and it'll be fine.
[33:45.290 --> 33:46.390]  Don't worry about it.
[33:46.990 --> 33:49.610]  So, I think that may be an error.
[33:52.370 --> 33:53.510]  Other things you can do.
[33:53.990 --> 33:56.370]  On your router, setting your interfaces to passive.
[33:56.570 --> 34:00.010]  Obviously, they don't spew as much sensitive information out.
[34:00.210 --> 34:05.510]  It reduces your vectors quite a bit because you can configure interfaces just to be passive.
[34:05.510 --> 34:12.290]  It means they can still accept routes but will not be being noisy beasts on your network.
[34:13.310 --> 34:14.550]  Turn off CDP.
[34:14.790 --> 34:15.830]  It's great for debugging.
[34:16.110 --> 34:16.810]  It's really handy.
[34:16.950 --> 34:17.530]  Shut it off.
[34:18.850 --> 34:19.370]  Okay.
[34:20.610 --> 34:21.950]  Encrypt your management traffic.
[34:24.790 --> 34:32.790]  Whenever you deal with a lot of these management tools, they frequently run over HTTP or, God forbid, Telnet.
[34:33.270 --> 34:43.730]  You know, many of these tools, even ones that are recently built, don't use even basic encryption for the routing protocols themselves, as well as, like, the management of those devices.
[34:43.910 --> 34:51.990]  So, you're talking about you can log into, you know, a device that can cycle power on all of your servers over clear text HTTP over the Internet.
[34:52.630 --> 34:54.090]  Does that seem like a good idea?
[34:54.310 --> 34:55.410]  I mean, mm-mm.
[34:55.710 --> 34:56.230]  Don't do that.
[34:56.730 --> 34:57.150]  This...
[34:57.150 --> 35:01.270]  I feel like I'm preaching to the choir here because most of the folks sitting in this room know that these things are bad.
[35:01.470 --> 35:04.690]  But this type of stuff is very much out there.
[35:05.370 --> 35:05.790]  Anyone...
[35:05.790 --> 35:07.410]  Who here has done war driving before?
[35:08.470 --> 35:09.170]  All right.
[35:09.170 --> 35:13.050]  So, have you guys seen some nasty stuff in your PCAP files?
[35:14.830 --> 35:15.390]  Okay.
[35:17.510 --> 35:18.070]  So...
[35:19.070 --> 35:33.170]  For those of you that are network operators, one thing that I think would really help is to push back for the vendors and demand good authentication, demand good encryption, demand these security features, because a lot of what I hear from the vendors is,
[35:33.170 --> 35:34.410]  oh, no one wants that.
[35:34.570 --> 35:36.170]  Everyone likes SNMP v1.
[35:36.310 --> 35:37.210]  That's totally fine.
[35:37.390 --> 35:38.770]  It worked for my father.
[35:38.990 --> 35:39.790]  It's gonna work for you.
[35:39.970 --> 35:40.090]  Yeah.
[35:40.510 --> 35:44.230]  So, if you can actually say, no, we want the encryption.
[35:44.430 --> 35:45.450]  We demand this feature.
[35:45.550 --> 35:49.590]  This is a priority for us when we're evaluating your equipment and picking what to buy.
[35:49.730 --> 35:51.270]  They will start to change their behavior.
[35:51.530 --> 35:52.610]  They follow the money.
[35:52.710 --> 35:54.150]  They will respond to customer demand.
[35:56.750 --> 36:02.290]  So, finally, you know, if any of you guys are in charge of networks out there, you know, audit yourself.
[36:02.530 --> 36:03.430]  It's not hard to do.
[36:03.610 --> 36:05.190]  The tools are readily available.
[36:05.950 --> 36:06.590]  You know...
[36:06.590 --> 36:07.450]  We had a slide with them.
[36:08.310 --> 36:12.150]  The tools out there for auditing yourself, not just routing protocols, but wireless.
[36:12.310 --> 36:14.610]  You know, you fire up Kismet, look for open APs.
[36:14.670 --> 36:16.390]  If you see any, you know, fix that.
[36:17.450 --> 36:22.730]  When it comes to, oh, well, we're out in the middle of nowhere, so that's not really a threat.
[36:22.930 --> 36:26.430]  I mean, that's actually not true at all, as I'm sure most of the folks here know.
[36:27.730 --> 36:32.350]  It only takes a couple of packets to make yourself look like an really attractive target to an attacker.
[36:35.850 --> 36:37.530]  Finally, a plea for packets.
[36:38.330 --> 36:39.310]  So, we sent out...
[36:39.310 --> 36:40.590]  We saw a lot of you war driving.
[36:41.770 --> 36:45.790]  Yeah, all those hands that went up in the back, you know, all the dodgy folks in the back there.
[36:45.970 --> 36:47.150]  We want to see your packets.
[36:48.110 --> 36:50.910]  So, we've collected quite a few from lots of different folks.
[36:51.430 --> 36:59.410]  As you can tell by the presentation, we try to masquerade the details of all of your NASDAQ listed organizations in Silicon Valley.
[36:59.890 --> 37:06.950]  But, we would love to see more, because we'd like to get a better idea of what other types of vulnerabilities out there just sent out in the clear.
[37:07.790 --> 37:13.370]  So, if any of you have additional packets to send us, you can email us here and get it over to us.
[37:13.470 --> 37:14.790]  We'd immensely appreciate it.
[37:16.290 --> 37:17.590]  And, thank you very much.
[37:17.730 --> 37:18.890]  You've been a great audience.
[37:27.200 --> 37:32.400]  So, at this point, if anyone have any questions, please fire away.
[37:33.960 --> 37:38.100]  My question is regarding Sarbanes-Oxley compliance.
[37:38.820 --> 37:49.140]  As you probably know, there are parts of that that say that networks should be secured and the social security numbers and confidential information should not be made in the clear.
[37:49.840 --> 37:58.840]  Have you or are you working with the regulatory bodies to let them know of the companies which may be infringing that kind of compliance?
[38:02.720 --> 38:11.300]  So, I have attempted to notify a few different organizations when I've seen highly suspicious packets emanating from the network.
[38:11.460 --> 38:14.360]  I have not worked with any regulatory bodies at this point.
[38:14.680 --> 38:24.280]  Frankly, there's so much of it out there, it's kind of hard to be the good cop and report to a lot of those organizations.
[38:24.280 --> 38:30.020]  But, ultimately, I don't feel that it's necessarily my responsibility to help all of these companies lock down their own networks.
[38:30.240 --> 38:37.840]  I think reporting them to Sarbanes-Oxley, you know, that may be something that I'd consider if it was an extreme case.
[38:37.840 --> 38:40.420]  But, I have not done that in the past.
[38:41.560 --> 38:42.160]  Thanks.
[38:46.600 --> 38:48.060]  Any other questions out there?
[38:48.760 --> 38:48.880]  Ah.
[38:51.120 --> 38:55.680]  Is there, you know, a network management software...
[38:55.680 --> 39:03.020]  Is there a network management software that you think sort of sets a standard that you'd like to see that's currently available?
[39:04.080 --> 39:10.380]  It really depends on the purpose and the sort of network that you're monitoring and what you actually want to use.
[39:11.520 --> 39:12.640]  I found...
[39:13.620 --> 39:18.000]  I have to admit to a weakness for Nagios for the awesome 3D visualizations.
[39:18.140 --> 39:18.860]  That's just badass.
[39:19.520 --> 39:20.980]  But, you can...
[39:20.980 --> 39:23.180]  I also like Nagios for being pretty highly configurable.
[39:23.940 --> 39:28.780]  So, it's not so much pick a better software suite as configure your software suite intelligently.
[39:28.780 --> 39:30.080]  Do good thread modeling.
[39:30.520 --> 39:36.760]  Figure out where you're going to, you know, use it and if you're likely to have new devices pop up there or not.
[39:36.860 --> 39:44.400]  For example, if I'm monitoring a network that is my, you know, backbone routers, nothing should pop up there without me knowing about it.
[39:44.460 --> 39:48.640]  I don't want to have, you know, constant polling going on of devices that are not on the approved list.
[39:48.720 --> 39:49.320]  That shouldn't change.
[39:49.640 --> 39:57.680]  If I'm monitoring a network of, you know, mobile access devices where they may drop in and pop off of the network, then you may need something like that.
[39:57.680 --> 40:06.120]  But, it might make sense to say, alright, this client must authenticate itself with credentials to the server first and then we connect back or something like that.
[40:12.670 --> 40:13.350]  Go ahead.
[40:14.110 --> 40:14.270]  Alright.
[40:15.290 --> 40:27.090]  Would you have any specific ideas or recommendations regarding smaller networks such as those on schools or even home networks?
[40:28.830 --> 40:33.470]  Well, if you're on a home network, you're probably not announcing a lot of these background protocols.
[40:34.030 --> 40:41.790]  The things that you would need to worry about are clear text data in general and devices that are monitoring your own stuff.
[40:42.030 --> 40:46.430]  So, if you're running SNMP internally on your home network, you know, use V3 or something.
[40:46.510 --> 40:48.990]  Use something that's actually got encryption.
[40:50.330 --> 40:52.850]  It would really depend on what's on the home network.
[40:53.690 --> 40:57.730]  You know, a lot of this stuff is difficult for the budget restricted.
[40:58.190 --> 41:10.790]  But, you know, the good thing is that if you've got a smaller network and you're on a tighter budget, you probably also don't have the sort of equipment that's causing, you know, these syslogs of firewall data and such that we're sending.
[41:10.790 --> 41:15.910]  Just, in general, try not to send stuff in the clear and have authentication whenever you do send stuff.
[41:16.290 --> 41:18.770]  Again, there's a lot of open source software available.
[41:19.030 --> 41:20.210]  It pays to be paranoid.
[41:20.670 --> 41:22.970]  All you need to do is download it and figure out how to use it.
[41:23.990 --> 41:27.370]  In general, though, if you're just using WEP, you're in trouble.
[41:27.530 --> 41:30.650]  If you're using WPA with a pre-shared key, you're in trouble.
[41:30.650 --> 41:35.610]  So, using WPA2 is a decent option.
[41:35.750 --> 41:36.210]  Not great.
[41:36.550 --> 41:44.590]  But, usually, for most home users, using enterprise WPA authentication is a little bit difficult to set up.
[41:44.730 --> 41:47.950]  But you can do it with, you know, using free radius and whatnot.
[41:48.110 --> 41:52.130]  You can set up strong authentication with good key rotation on a home network.
[41:55.320 --> 41:56.480]  Any other questions out there?
[41:56.620 --> 41:56.860]  Go ahead.
[41:57.140 --> 41:57.420]  Yeah.
[41:57.560 --> 42:00.060]  I was just wondering, what is your involvement in IETF?
[42:00.060 --> 42:03.160]  Are you guys doing any sort of protocol development with IETF?
[42:03.240 --> 42:06.060]  Are you writing any best common practices documentation?
[42:06.780 --> 42:08.840]  Do you plan on being in San Diego in November?
[42:10.680 --> 42:12.740]  We were just talking about this last night.
[42:13.820 --> 42:20.020]  Yeah, I am beginning to work with some of the IETF people on a lot of the new protocol development.
[42:20.260 --> 42:22.360]  It's sort of a new personal project of mine.
[42:23.040 --> 42:27.480]  As, you know, sort of railing at the system from the outside has not been terribly successful.
[42:27.480 --> 42:30.340]  I've been bitching about this same stuff for, like, five years.
[42:30.620 --> 42:34.940]  And as we just saw with, you know, the captures from 2002, it hasn't gotten much better.
[42:35.180 --> 42:38.240]  I am about to tackle working from the inside rather than the outside.
[42:38.380 --> 42:39.200]  And we'll see how that goes.
[42:39.780 --> 42:40.520]  Second question.
[42:40.640 --> 42:44.320]  How much of your presentation do you think applies to wired point-to-point links?
[42:46.480 --> 42:50.640]  Well, the principles are still sound, but the accessibility is less.
[42:51.160 --> 42:58.760]  So, you know, ideally I would like to see people applying these principles of design and encrypting and authenticating regardless.
[42:59.160 --> 43:02.600]  But it's not quite as easy for someone to attack.
[43:03.200 --> 43:11.460]  When I was an ISP engineer, I did see people, you know, trying to set up neighbor sessions for devices that we were like, who's that?
[43:11.720 --> 43:12.740]  And things like that.
[43:13.020 --> 43:20.600]  And in at least one case, we are virtually certain that it was a malicious attempt rather than just someone plugging in the wrong port at, like, the May.
[43:21.020 --> 43:25.440]  So, it still does happen, albeit less frequently.
[43:25.440 --> 43:30.380]  But when it does happen, it's sort of a higher stakes, more deliberate, better attacker.
[43:30.720 --> 43:31.300]  Thank you.
[43:35.800 --> 43:40.480]  I recently inherited a couple of Cisco switches on a fairly busy network.
[43:40.700 --> 43:42.740]  And I don't have that much experience working with them.
[43:43.080 --> 43:56.040]  And I noticed, like, after we powered everything up and plugged everything in and it was running, I noticed that it required a firmware update to enable SSH and SSL for the management stuff.
[43:56.300 --> 43:58.940]  And the firmware update requires rebooting the switch.
[43:58.940 --> 44:01.060]  Obviously, it's not really an option if it's already on.
[44:01.060 --> 44:06.500]  Is there a cutoff point for these products when they actually have crypto on the firmware?
[44:07.300 --> 44:12.900]  Crypto on Cisco devices has actually been a difficult issue.
[44:13.320 --> 44:14.680]  They've gotten a lot better.
[44:15.000 --> 44:15.960]  You know, I will give them that.
[44:16.700 --> 44:29.260]  They used to not do it because they didn't have customer demand for it or they would enable it in their experimental releases of iOS but say, oh, well, you can have crypto or you can have good MPLS or something like that.
[44:29.260 --> 44:33.360]  And so, you know, for people who needed the other features, it wasn't really an option.
[44:33.580 --> 44:36.160]  But in recent years, they've had bigger demands.
[44:36.320 --> 44:38.060]  The difficulty is the support contracts.
[44:38.260 --> 44:46.520]  You know, a lot of times they require a Cisco.com login and a support contract bound to it before they'll let you download the things with the updated firmware.
[44:46.520 --> 44:50.220]  And that, I think, I can see why they're doing it financially.
[44:50.400 --> 44:52.920]  But security-wise, it is a problem.
[44:52.940 --> 45:00.300]  And they're not really helping people who, you know, inherited old devices, buy them off of eBay because they can't afford to pay Cisco a gazillion dollars for one, etc.
[45:02.380 --> 45:09.360]  Actually, at Black Hat, I'm going to be on a panel discussing vulnerability disclosure with the CIO of Cisco.
[45:09.360 --> 45:12.380]  And this is one of the things that I intend to bring up.
[45:12.920 --> 45:13.620]  Thank you.
[45:16.180 --> 45:17.420]  Thank you for your presentation.
[45:17.900 --> 45:23.440]  Talking about these clear text management protocols, routing protocols leaking out over wireless.
[45:24.000 --> 45:31.260]  Have you seen examples where the wireless network has WEP or WPA or whatever and you're still having those clear text management protocols leaking out?
[45:32.660 --> 45:39.320]  Well, since we just solicited these packet captures, we didn't actually go through and try and break anyone's encryption if they had it on there.
[45:39.720 --> 45:44.280]  We looked at statistics for, okay, there's X networks with encryption or X without.
[45:44.520 --> 45:54.020]  But essentially, the way that we collected this data was very similar to what we just did on the last slide, except we wrote our friends and said, hey, you know, please ask your locals to send us captures.
[45:54.180 --> 45:56.200]  We're collecting data for this purpose, for this talk.
[45:56.200 --> 46:06.840]  So, because it wasn't, you know, a, okay, let's go out and ourselves sit in parking lots targeting shit, you know, we didn't really try and crack into anyone's network, so.
[46:07.140 --> 46:18.960]  Since a lot of the protocols are broadcast, so, if they were running WEP or WPA encryption, would you be able to, from the outside, broadcast this management traffic and have it be broadcast then via the APs back into the wired network?
[46:19.200 --> 46:23.540]  Would some of your attacks still hold up, even if they weren't running their wireless and clear text?
[46:24.820 --> 46:30.440]  Well, if you break the encryption, then you can send with that encryption and you're cool.
[46:31.120 --> 46:31.140]  Okay.
[46:31.140 --> 46:37.580]  So, the attacks will work on the layer that they're intended to work, regardless of, you know, what you're doing on the base layer.
[46:37.840 --> 46:38.160]  Got it.
[46:38.240 --> 46:38.520]  Thanks.
[46:41.120 --> 46:47.560]  I wanted to ask you guys more about the database or the archive that you're building of packets that people are sending you.
[46:47.560 --> 46:55.520]  Can you give me a sense of how much data you have and how much you'd like to have before you'd release another sort of statistical analysis?
[46:57.180 --> 47:08.060]  Well, as far as the data that we have, we told the people that were sending it to us that it would all be held in confidentiality and we weren't going to release any data about it, other than, you know, very vague statistics.
[47:08.700 --> 47:09.360]  Yeah, anonymized data.
[47:09.580 --> 47:09.840]  Of course, yeah.
[47:10.020 --> 47:12.540]  So, you know, we can't really say much about that.
[47:12.640 --> 47:16.920]  As far as how much we have to have before we do something else, it's kind of fuzzy, I think.
[47:17.160 --> 47:20.560]  You know, oh, you know, okay, we've seen plenty of bad stuff.
[47:20.560 --> 47:22.340]  Now, we feel like we have something to say.
[47:22.400 --> 47:27.420]  I think it's an internal sense of, all right, this is worth yelling at people about.
[47:27.420 --> 47:32.320]  Can you at least give us a sense of how many people have sent you data?
[47:32.780 --> 47:36.440]  Or how much, just how much you have in terms of volume?
[47:37.520 --> 47:44.700]  Counting the people that I personally asked for data, I think I solicited it from about 100 people.
[47:44.840 --> 47:45.160]  Okay.
[47:45.480 --> 47:47.120]  And plus what these guys did.
[47:48.900 --> 47:49.520]  Thank you.
[47:49.620 --> 47:50.360]  That's very interesting.
[47:50.580 --> 47:50.700]  Thanks.
[47:53.930 --> 47:58.770]  I wanted to know what IP protocol you would use if you were setting it up.
[47:58.770 --> 48:03.510]  And also the remediation process and the process flow.
[48:03.770 --> 48:10.230]  If you were setting something Wi-Fi up, how would you go about setting it up secure?
[48:12.010 --> 48:21.950]  Well, after your device is up, if you do like a basic wireless audit, just getting a packet capture of what you've got and watching your own network will give you a good idea.
[48:22.130 --> 48:30.730]  You can, you know, like Eric was saying, even though this is a minute percentage of the actual data out there, like you can pull it up in ethereal and type in OSPF in the bar.
[48:31.010 --> 48:35.370]  And it will filter and, you know, any OSPF traffic will pop up.
[48:35.590 --> 48:42.470]  So if you know what's bad and you know what you're looking for, you can filter your packet captures for those specifically to see if anything like that is being transmitted.
[48:42.710 --> 48:46.910]  You can port scan your devices on your network and, you know, see what you're advertising out and to whom.
[48:48.170 --> 48:56.510]  If you'd like to send some email to that email address, we can send you the ethereal filter we're using to extract a lot of the more interesting packets out of our captures.
[48:56.850 --> 49:00.070]  So just shoot us an email and we'll bounce back with that filter if you'd like it.
[49:00.310 --> 49:03.830]  I wanted to ask you, if you were setting it up, what would you use?
[49:04.110 --> 49:07.210]  What IP protocol would you use if you had a company?
[49:08.230 --> 49:10.390]  Are you talking about routing protocols?
[49:10.390 --> 49:11.310]  Yeah, yeah, exactly.
[49:11.590 --> 49:12.430]  Routing protocols.
[49:14.110 --> 49:16.030]  OSPF is a pretty decent routing protocol.
[49:16.270 --> 49:24.190]  I would turn on the crypto authentication and set the interfaces that are facing in towards your LAN passive so that they're not advertising OSPF out towards your LAN.
[49:24.310 --> 49:26.330]  It only really needs to be done towards the inside.
[49:28.690 --> 49:30.350]  I don't like EIGRP much.
[49:30.930 --> 49:35.310]  But you have to pay Cisco basically to run that as a routing protocol.
[49:35.890 --> 49:37.590]  Zebra will do OSPF for you for free.
[49:39.710 --> 49:41.010]  So any other questions out there?
[49:42.810 --> 49:44.590]  Alright, I think we're going to call it a close then.
[49:44.710 --> 49:45.310]  Thank you for your time.
[49:45.430 --> 49:45.870]  Thanks for your time.
[49:45.870 --> 49:46.270]  Thanks very much.