Examining the Internet's pollution
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Benson, Karyn
Network telescopes are collections of unused but BGP-announced IP addresses. They collect the pollution of the Internet: scanning, misconfigurations, backscatter from DoS attacks, bugs, etc. For example, several historical studies used network telescopes to examine worm outbreaks. In this talk I will discuss phenomena that have recently induced many sources to send traffic to network telescopes. By examining this pollution we find a wealth of security-related data. Specifically, I’ll touch on scanning trends, DoS attacks that leverage open DNS resolvers to overwhelm authoritative name servers, BitTorrent index poisoning attacks (which targeted torrents with China in their name), a byte order bug in Qihoo 360 (while updating, this security software sent acknowledgements to wrong IP addresses… for 5 years), and the consequence of an error in Sality’s distributed hash table. Bio: Karyn recently defended her PhD in computer science. Prior to starting graduate school she wrote intrusion detection software for the US Army. When not looking at packets, Karb eats tacos, runs marathons, and collects state quarters.
 Karen Benson, take it away. Hi everyone, thank you so much for coming today to learn about examining the internet's pollution as announced. I'm Karen Benson and I'm really excited to be talking here today at my first step-gone. To start off, a couple years ago on Reddit, somebody asked the garbage men on there about the illegal, strange and valuable things that they had seen while examining other people's trash. And you can go find this thread and read what they found. But the main takeaway is that they found a number of interesting and valuable items. So today I'm going to talk about the analogous question, but for the internet. We're going to ask what sort of interesting and valuable information can we find looking at some packets and traffic that you may consider the internet trash. And I feel that I'm pretty qualified to talk to you about this, not because I'm Oscar the Grouch, but because I just defended my PhD in which I spent the last four years looking at this type of traffic. And prior to that I looked at not so trashy traffic, but writing intrusion detection software. So I've looked at some packets. So quick outline of the talk, basically I'm going to go a little more into depth on what this trash is and the various ways that you can collect this. I'll talk about the ways that we collect this and the ways that you could possibly collect this on your own networks. And I'll go into a little bit about the data that I use for the presentation. And then the bulk of it is going to be about the interesting and valuable items that you can find in trash. And then there will be a conclusion. So what is internet trash? This is something I made up. So what am I calling this? So basically I mean any unsolicited packet. So this means you're not going out trying to get people to send packets to you. You're just passively capturing everything that comes to you with your own IP addresses. And this has a name other than trash. Internet background radiation or IVR. And people have studied this for a long time to look at worms and stuff like that. But I'll tell you kind of more of the things that have happened in the past couple years. So probably the most obvious example of IVR is scanning when you're searching for hosts that run a service. You're going to send packets to hosts that will respond to you as well as hosts that are behind firewalls and they're not going to respond to you. And possibly to people like me who are just kind of collecting the garbage of the internet. We also get backscatter packets, which is any packet that's a response to a forged or spoof packet. And typically you think of these in denial of service attacks. So you have a victim and the attacker. And the attacker doesn't necessarily want everyone to know that they are the one launching the attack. And so they may be able to forge the source address or the from field of the packet. And when they send it to the victim, the victim may have a hard time differentiating between forged and non-forged packets. And they may respond, but they're not going to respond to the attacker. Instead they're going to hopefully respond to us. Next we have misconfigurations, which is when you just erroneously believe that a machine is hosting a service. These can be small scale, like someone typing an IP address incorrectly, but they can also be pretty large scale and affect a lot of hosts. And we see this a lot in peer-to-peer networks. Similar to misconfigurations are bugs. And this is when you have some sort of software error that causes the packets to reach an unintended destination such as a byte order bug. So even if you know your DNS server correctly, you may, because of some issue in software, send the packet to an unintended destination. We also get a bunch of spoofed traffic where for some reason people are using the wrong address. They typically aren't trying to attack me, but we still get some packets like this. And then finally there's some traffic that we just don't know what it is. This can be TCP send packets to non-standard ports or UDP packets where we don't understand what the payload is. In one example, this is encrypted packets. They are difficult to understand what the intention of that packet is. So this is kind of a summary of the major classes of IBR. So how can we collect this? You've probably heard of Honey Pots where you purposely set up machines to be infected with malware. Maybe you run an old operating system or some sort of vulnerable service. And with this you can get really in-depth information because you're infected and you understand the attack vectors and the consequences of this. But if we don't want to do something so in-depth, we can have some other setups. The first example of this is just collecting one-way traffic. So if this is your network and these are the used machines in your network, you announce some BGP prefix. And you probably have some sort of middle box keeping state of the connections and which ones are bidirectional and which ones haven't received an acknowledgement yet. And if they never receive an acknowledgement, this is probably some sort of unsolicited pack traffic. So you can store this as your collection of IBR. Similar to this, you can have a gray net where your state is the IP addresses that are used. And then you just know which other ones you can rate to storage as they come into your network. Another concept related to this is if all of your addresses are in some small BGP prefix, but you have a much larger one, you can announce the whole prefix that you have and then based on the destination, decide which ones to route to the destination or write to storage. And then finally, an extreme example of this is a network telescope where you just don't use a BGP prefix that you have and you record all the traffic that comes in. And in the order that I presented these, it becomes easier to scale and implement and there's normally relatively fewer privacy concerns, but you lack the ability to do really in-depth analysis if you're not responding and people can avoid your IP addresses. For this talk, I am going to use traffic collected at a number of network telescopes. So we have multiple large academic network telescopes and we receive a ton of data from these. We're currently capturing about five terabytes of compressed PCAP per week and we have traffic going all the way back to 2008, so we can do some historical space with this. And with this data, we see traffic from all over the internet. In terms of the countries, we see all countries except a few islands in the Pacific Ocean. And in terms of IP addresses, we are seeing about 5% of the announced IP addresses in BGP, so it's a pretty good sampling. And I'm showing you data from July 2013, but if we look over time, this is, we were almost always seeing data. I didn't extend this graph, but it's just increased a lot recently too. There can also be events such as the Spam House attack, which was a really big DNS-based denial of service attack, and with this attack, we see this event, we were able to see traffic for more hosts. So now we get to go to the exciting part of the talk, where we talk about the interesting and valuable things found in the internet trash. So for this section, I'm going to go through the major classes of traffic besides Spoofed, and I'm going to tell you about the thing that I think is the most exciting for them. So in terms of scanning, I'll talk about some trends and some relationships to vulnerability announcements. And to collect this data, we use the historical data that we had since 2008, and we just applied BROS parameters for determining if an IP address is a scanner, which is if you send packets to 25 different IP addresses on the same protocol and port within five minutes, BROS would alert that you were being scanned. So this is maybe not the best definition of a scanner, because it obviously depends on how many IP addresses you have, and it's definitely not capturing slower scans, but it can give us a kind of a first look at the macroscopic scanning that's happening on the internet, or at least of our networks. So, I broke up the data into what was happening from 2008 and 2012 first, and you can see that the colors correspond to ports, and we see in terms of packets and IP addresses, the purple port is very popular, and this is TCP 445, and we see that the first increase is right when the config or outbreak occurred, and then we see subsequent increases often corresponding to new releases of config. But we can't say all of this is necessarily config, because there's other scans of this port, though most of it happens to be from config. And so we can come up with some heuristics to determine which packets originate from config, and to do this, we can exploit a bug that config has in its pseudorandom number generator, and for the most part, when it's randomly scanning the internet to propagate, it has a bug where it only targets IP addresses A.B.C.D, where B is less than 128, and D is less than 128, so it's only really scanning a fourth of the internet. And so we used a heuristic based on the birthday problem, which basically says, given a random group of people, what is the probability that two people are going to share a birthday? And often this, it's like surprising, it's only like 34 people, and it's pretty proud, and then it's likely that people share a birthday. So another way of asking this question is, how many unique birthdays can we expect to give in N people and 365 birthdays? So turning this into a identifying config, if we have IP addresses A.B.C.D that are being scanned, we can look at the individual bytes of the IP address, so if we look at D, and we say, how many unique D values can we expect to give in either targeting 128 or 256 targets, which are the possible values for D? And you can repeat this for the other bytes, and you can then start to differentiate between randomly scanning a quarter of the internet versus the entire internet in expectation. So if we look at the configure outbreak, and the amount of scanning that happened around that time period, and this graph is in log scale, we do have some missing data, but we do see an increase right when a configure was discovered. So what we would expect here is that we wouldn't see any hosts matching our configure heuristic. However, when we look at the number of IP addresses meeting the configure heuristic, this is what we see. So for up until about August, we didn't see no IP addresses met this heuristic, and then all of a sudden we started seeing some traffic. So this is what, before the configure was actually discovered. So this is evidence that someone was trying to actually test out their configure bug prior to this. And on the first day, the IP addresses were all in the same province, and the first couple of days, they were all in the same province in China. And so maybe this is helpful. As far as I know, nobody has claimed the Microsoft 250K bounty to collect the configure worm author, so perhaps this information could be useful for that. So that was before 2012. So if we look at what was happening since 2012, not surprisingly, configure is dying out. But the most popular port has been replaced with port 23, which is Telnet. And the best explanation I have for this is that people may be trying to scan for Internet of Things. If you have a better idea, let me know. And we can also see some other interesting things happening here. So this spike that is in gray, it was a variety of ports, and it corresponded to traffic from the Karnabotnet, which was somebody decided to create a botnet, scan the whole Internet, and then publish all of the results anonymously. So we see this, and we can verify that traffic was actually coming from the Karnabotnet based on their data. So if we look at the IP addresses, we notice some period of time where there's increased activity on a port. So if we look at Heartbleed, right around there, in here you can see in red where the Heartbleed vulnerability announcement occurred, and then like a week or so later, we see a lot of increased activity on the pink port, which is TCP 443, which is where Heartbleed was likely to be exploited. Similarly, a little bit later, we see a lot of traffic, a lot of scanning TCP port 5000. And so just Google searching TCP port 5000 during that time. We, Akamai, had a report that they were seeing lots of universal plug-and-play devices being used in denial of service attacks, and prior to that report, we see evidence of scanning on that port. So we were potentially seeing activity before it was used in an attack. All right, so that was scanning. Well, hopefully we will release our scanning data set pretty soon. But going on to backscatter, I'm going to talk about an attack that we're seeing, that we've been seeing on authoritative DNS servers. So just a reminder, backscatter is a response to a spoofed packet. So let's suppose you have a web server that you want to perform a denial of service attack on. You could do the denial of service attack directly on the web server. However, there is also another weak point. All legitimate hosts who want to contact that web server need to find the IP address associated with the name. So they have to do a number of DNS queries. So it turns out that you could also perform a denial of service attack on the authoritative name server. So one way that you can do this is with an open resolver. And an open resolver, typically with DNS, you should only resolve domains for machines that you administer. So UCSD's domain server should only resolve domain names for clients in UCSD. So it's typically considered bad because otherwise you could use them in DDoS attacks. But so you could use an open resolver to pull off this attack on the authoritative name server. In particular, the attacker can spoof a packet, a DNS query, send it to the open resolver, and since the open resolver resolves the data for everyone, it's more than happy to ask the authoritative name server and they get a response. And since the original query was spoofed, they do not respond to the attacker, but instead it's likely that they will respond to our network telescope. Or there's a probability that they will do that. So we're seeing a lot of traffic recently from open resolvers. So this is 2014 data. So prior to pretty much the end of January 2014, we didn't see pretty much any traffic from open resolvers. We saw about 3,000 open resolvers per month. And then starting in February 2014, we saw 1.5 million open resolvers per month. And we noticed that once this attack sort of took off, we were seeing traffic from the same open resolvers over and over again. This is only a small fraction of the open resolvers used on the internet. The open resolver project, which is scanning, active scanning at the same time, we saw about 20 times the number of open resolvers that we did. But this means that this attack is only using a subset of the open resolvers. But we can also look at some other data that we have from the attack, which is the status code that comes back with your DNS response. So if it's like, okay, everything's happy. But you can also get a number of failures, including a serve fail, which indicates that there's a problem with most likely the authoritative name server. And in the month of data, we got serve fail errors from nearly every open resolver that we saw, whereas in the open resolver projects, they see this error very seldomly. So this is evidence that this attack is actually overwhelming authoritative name servers. So one interesting thing is that you see, we see some data on January 29th, and then the attack seems to really take off in the beginning of February. And this first day, the domain that was queried was all for body.com, which is a popular website, so this reflects a testing phase here. Since then, there's been lots, the domains seem to be just used for a very short period of time. A number, most of them seem to have bogus registration information. And we're still seeing this, all this analysis from the first month of activity, and we're still observing this type of attack right now. So that was backscatter, now I'm going to go on to misconfigurations, which in particular I'm going to talk about bit torrent misconfigurations. So if you want to download a torrent, through bit torrent, you typically contact the bit torrent distributed hash table, and they will tell you the location of the torrent or some other bit torrent node that is closer to the torrent that you want. However, there can be malicious nodes in the distributed hash table, and they can lie to you about the location of the torrent. And if this happens repeatedly over and over again, it's going to be a lot harder for you to actually find the torrent and get the latest episode of Game of Thrones or whatever you want to watch. So this attack is called an index poisoning attack, where you're purposely inserting fake information into or about what's in the hash table. And so what happens after you receive this false information is you try to set up a connection. So when people send bit torrent packets to the network telescope, we get an idea of what torrents they are trying to download. And so this is some data from July 2012, and in terms of the boost packets associated with a torrent, and you'll notice that a lot of them happen to have the word China in their name. And a year later, we see about the same thing. So this attack doesn't seem to be going on right now, or if it is, it's a lot lower. But, oh, I'm sorry, and typically in this China attack, typically the IP addresses that are asked for the torrents satisfy this equation or this set of IP addresses. Basically they're in certain slash 13 blocks, and so it seems that they're being generated programmatically with a buggy pseudo random number generator. And this attack is sometimes we see a lot of packets from it, and then sometimes we don't see any, and currently we're not seeing very many. But more recently, about a year ago, we saw a huge spike in the amount of bit torrent traffic we see. We're getting traffic from about 250 times more IP addresses per hour. And we don't really know everything that's going on to try to investigate this. We were, so just as a recap, when you want the torrent, you ask someone, the DHT node, the location of the torrents, and they come back with the locations, and then they potentially contact our network telescope. So we want to know who's spreading this false information. So this node, so we can't really learn this by looking at the IBR. Instead, we can set up nodes to actually interact with the distributed hash table. So we set up two clients and examine what happened for a bird, two months, and they both contacted our network telescope fairly frequently. And so we looked at who was telling our clients to contact the network telescope. And the most popular client string was a lib torrent one, but this only accounted for about 70% of the clients, and it's a pretty popular client string among legitimate hosts as well. Most of the IP addresses were in China, but they were in multiple ASs. So this wasn't 2.6 vessel in identifying who is actually sending this false information. But we did notice one really suspicious behavior. So in the hash table, all the nodes have an ID. So that means that they think that the IP addresses in our network telescope also have IDs. And so the IDs that they request, they all have four as the third byte. So that's kind of weird. And typically, when you receive locations, you receive not just one location, but multiple locations at a time. And this behavior is similar for a lot of other IP addresses that we see. So we're receiving a lot of bit torrent traffic as a result of a bug in, or a misconfiguration in a peer-to-peer network. Peer-to-peer networks also caused a lot of traffic as a result of a bug in one of the systems. So if we look at the number of sources sending us traffic over time, we notice some interesting things like the configure outbreak, when we started seeing a lot of bit torrent traffic, and then all of a sudden in October 2010, there was all the shape of the graph definitely changes. It's very diurnal, and we weren't really sure what was happening here. And we were able to identify the responsible payload, and certain bytes seemed fixed, and then we could hypothesize about what the other ones were using it for. But we still had no idea what this was, and the popular ports, the most frequently used ports, we weren't really sure what those were either. But we did notice that in terms of the sources sending them, they were mostly located, a large number of them were located in China. In fact, we received in a month's time traffic from 30% of all BGP announced IP addresses in China. So this is like huge. Also interestingly, when the USA category for IP addresses belonged to the UCSD computer science department where it went to school. So we were able to coordinate with someone who could monitor the traffic going in and out of UCSD's network to basically capture traffic from these IP addresses. This ensured that this traffic wasn't spoofed and was actually happening. So all of the CSC machines basically contacted a common IP address, and in response they got a pretty large packet. And based on this packet, then they sent about 40 more packets to different machines, and they were all encoded in this original big packet. And it wasn't just one packet, they were exchanging a lot of packets. And eventually the UCSD machines would receive a packet like this. And so this packet is from 113704122, but instead they would respond to 12270113, just immediately after receiving this packet. So, and this packet met the BPF filter that we had used to identify all of this traffic. So this is a byte order bug, and this is why we were receiving a lot of this traffic. We identified that this software bug was in Quihu 360, and if you look at their license agreement, then this is like the most popular security software in China. And if you look at their license agreement, you see that they will use peer-to-peer technology to update program modules, malware definition databases, and components of the software. So basically we were getting information about when people were updating, getting software updates. We contacted Quihu and told them, hey, like, you have this bug. And so then we could see how long it took for them to fix it. The traffic had one kind of weird thing, which was like every four to five weeks. There was a large spike probably related to big update events, but there wasn't a big decrease following one of these. Instead, it decreased like about a month later, and this date was about the same time a new version of Quihu was available on their website. So we're still getting some traffic, but in general, this bug has been fixed. All right. Now on to the last part, which is looking at some unknown traffic. So the bug was also an example of unknown traffic, but I'll go through another one. So basically if you investigate some of these packets a little bit more, you might be able to come or identify where they're from. So in the beginning when I explained the unknown category, I said, here's a packet. It's payload appears to be encrypted. So basically this one IP address was getting a lot of traffic sent to it, and they all seem to be encrypted based on the entropy of the bytes. But we did a byte-wise analysis of what is the first byte, second byte, third byte, and stuff like that. And we found that this byte here always seemed to be somewhat related to the whole length of the packet itself. And then I read a bunch of white papers and found that the sality botnet, their encryption is such that these four bytes are an RC fork he used to decrypt or encrypt the entire rest of the message. So when we decrypted almost all the packets to this one IP address, we found that they all sort of started like this. So this confirmed that this is a sality commanding control packet. So this is kind of interesting because you're like, okay, I understand why someone would have a bug or someone would purposely put false information into a bit torrent DHT, or I understand how a byte order bug happens, but this also happens in peer-to-peer botnets as well, and that's why we received that much. We received a lot of traffic. In fact, if we look at how many IP addresses we're sending us traffic per month, basically to this one IP address, we see about the same number of infections as Symantec was seeing in the early part of this decade. So in conclusion, it's pretty likely that you are transmitting internet background radiation, and if you use network telescopes or other technologies, you can find a whole bunch of interesting things. In addition to just looking at these kind of security-related events, we can also learn about the networks and machines generating the traffic. Another example, you can do outage detection with traffic reaching network telescopes. This is a graph from a paper that analyzed events during the Arab Spring, and as you can see, the number of packets coming from Libya went down to zero at certain periods of time, and these corresponded to known times that the Libyan government had pulled the plug on their country's internet. We can also look at path changes. So when you send a packet on the internet, there's this TTL field that is decremented by every intermediate router to prevent routing loops. But based on this, you can infer how many hops away the source is. So if this changes, then you know that a path change occurred, and this can help you analyze outages and understand routing dynamics. So looking at some of this stuff, we can see if you have traffic like this, where the TTL is the same value over time, it's probably using the same path, but if it looks more like this, then you know that the path has changed. And then as a final example, we can also look at DHCP lease duration. So when you join a network using DHCP, you announce that you want to join the network, and you're given an IP address to use, and typically at some point in time, you no longer use that IP address, which means at a future time someone else can use the same IP address. So we can look at DHCP lease durations using any traffic that has some sort of ID associated with a client. So if these are the packets you receive over time, you know that the lease duration is at least this long, and at most this long. So as I noted before, BitTorrent has IDs as well. So we can use BitTorrent to identify how long lease durations are for various autonomous systems. So this autonomous system, almost everything, has a minimum lease duration of less than seven days. And this is really useful for understanding the effectiveness of blacklisting, or how if people are going to not be able to access the internet because you have blacklisted their IP. So hopefully you enjoyed the talk today where we discussed some of the crazy things that happen on the internet. And so thank you. Thank you. Hello. Hi. Very fascinating research and great presentation. Thank you. Looking toward the future, I noticed this was all IPv4. Have you done any consideration of IPv6-based telescopes, and you think it's practical with the sparseness of prefixes and v6 addresses? So I haven't, but some people wrote a research paper where they used an IPv6. They basically were able to announce a covering prefix and basically capture everything that wasn't. Other people weren't announcing in BGP, and they didn't find as much. But I think as IPv6 evolves, I think also this will evolve as well. Thank you. So thank you. That's very convincing that this is incredibly useful data. How can other security researchers get access to it? So I know that the data that UCSD has, that it is available to academic researchers. I don't know the whole process, but I mean, you can start with your own network too. Is there a question over there? Thank you.
 Karen Benson, take it away.  Hi everyone, thank you so much for coming today to learn about examining the internet's pollution  as announced. I'm Karen Benson and I'm really excited to be talking here today at my first step-gone.  To start off, a couple years ago on Reddit, somebody asked the garbage men on there about the illegal,  strange and valuable things that they had seen while examining other people's trash.  And you can go find this thread and read what they found.  But the main takeaway is that they found a number of interesting and valuable items.  So today I'm going to talk about the analogous question, but for the internet.  We're going to ask what sort of interesting and valuable information can we find looking at some packets and traffic  that you may consider the internet trash.  And I feel that I'm pretty qualified to talk to you about this, not because I'm Oscar the Grouch,  but because I just defended my PhD in which I spent the last four years looking at this type of traffic.  And prior to that I looked at not so trashy traffic, but writing intrusion detection software.  So I've looked at some packets.  So quick outline of the talk, basically I'm going to go a little more into depth on what this trash is  and the various ways that you can collect this.  I'll talk about the ways that we collect this and the ways that you could possibly collect this on your own networks.  And I'll go into a little bit about the data that I use for the presentation.  And then the bulk of it is going to be about the interesting and valuable items that you can find in trash.  And then there will be a conclusion.  So what is internet trash?  This is something I made up.  So what am I calling this?  So basically I mean any unsolicited packet.  So this means you're not going out trying to get people to send packets to you.  You're just passively capturing everything that comes to you with your own IP addresses.  And this has a name other than trash.  Internet background radiation or IVR.  And people have studied this for a long time to look at worms and stuff like that.  But I'll tell you kind of more of the things that have happened in the past couple years.  So probably the most obvious example of IVR is scanning when you're searching for hosts that run a service.  You're going to send packets to hosts that will respond to you as well as hosts that are behind firewalls  and they're not going to respond to you.  And possibly to people like me who are just kind of collecting the garbage of the internet.  We also get backscatter packets, which is any packet that's a response to a forged or spoof packet.  And typically you think of these in denial of service attacks.  So you have a victim and the attacker.  And the attacker doesn't necessarily want everyone to know that they are the one launching the attack.  And so they may be able to forge the source address or the from field of the packet.  And when they send it to the victim, the victim may have a hard time differentiating between forged and non-forged packets.  And they may respond, but they're not going to respond to the attacker.  Instead they're going to hopefully respond to us.  Next we have misconfigurations, which is when you just erroneously believe that a machine is hosting a service.  These can be small scale, like someone typing an IP address incorrectly, but they can also be pretty large scale  and affect a lot of hosts.  And we see this a lot in peer-to-peer networks.  Similar to misconfigurations are bugs.  And this is when you have some sort of software error that causes the packets to reach an unintended destination  such as a byte order bug.  So even if you know your DNS server correctly, you may, because of some issue in software, send the packet to an unintended destination.  We also get a bunch of spoofed traffic where for some reason people are using the wrong address.  They typically aren't trying to attack me, but we still get some packets like this.  And then finally there's some traffic that we just don't know what it is.  This can be TCP send packets to non-standard ports or UDP packets where we don't understand what the payload is.  In one example, this is encrypted packets. They are difficult to understand what the intention of that packet is.  So this is kind of a summary of the major classes of IBR.  So how can we collect this?  You've probably heard of Honey Pots where you purposely set up machines to be infected with malware.  Maybe you run an old operating system or some sort of vulnerable service.  And with this you can get really in-depth information because you're infected and you understand the attack vectors and the consequences of this.  But if we don't want to do something so in-depth, we can have some other setups.  The first example of this is just collecting one-way traffic.  So if this is your network and these are the used machines in your network, you announce some BGP prefix.  And you probably have some sort of middle box keeping state of the connections and which ones are bidirectional and which ones haven't received an acknowledgement yet.  And if they never receive an acknowledgement, this is probably some sort of unsolicited pack traffic.  So you can store this as your collection of IBR.  Similar to this, you can have a gray net where your state is the IP addresses that are used.  And then you just know which other ones you can rate to storage as they come into your network.  Another concept related to this is if all of your addresses are in some small BGP prefix, but you have a much larger one,  you can announce the whole prefix that you have and then based on the destination, decide which ones to route to the destination or write to storage.  And then finally, an extreme example of this is a network telescope where you just don't use a BGP prefix that you have and you record all the traffic that comes in.  And in the order that I presented these, it becomes easier to scale and implement and there's normally relatively fewer privacy concerns,  but you lack the ability to do really in-depth analysis if you're not responding and people can avoid your IP addresses.  For this talk, I am going to use traffic collected at a number of network telescopes.  So we have multiple large academic network telescopes and we receive a ton of data from these.  We're currently capturing about five terabytes of compressed PCAP per week and we have traffic going all the way back to 2008,  so we can do some historical space with this.  And with this data, we see traffic from all over the internet.  In terms of the countries, we see all countries except a few islands in the Pacific Ocean.  And in terms of IP addresses, we are seeing about 5% of the announced IP addresses in BGP, so it's a pretty good sampling.  And I'm showing you data from July 2013, but if we look over time, this is, we were almost always seeing data.  I didn't extend this graph, but it's just increased a lot recently too.  There can also be events such as the Spam House attack, which was a really big DNS-based denial of service attack,  and with this attack, we see this event, we were able to see traffic for more hosts.  So now we get to go to the exciting part of the talk, where we talk about the interesting and valuable things found in the internet trash.  So for this section, I'm going to go through the major classes of traffic besides Spoofed,  and I'm going to tell you about the thing that I think is the most exciting for them.  So in terms of scanning, I'll talk about some trends and some relationships to vulnerability announcements.  And to collect this data, we use the historical data that we had since 2008,  and we just applied BROS parameters for determining if an IP address is a scanner,  which is if you send packets to 25 different IP addresses on the same protocol and port within five minutes,  BROS would alert that you were being scanned.  So this is maybe not the best definition of a scanner, because it obviously depends on how many IP addresses you have,  and it's definitely not capturing slower scans,  but it can give us a kind of a first look at the macroscopic scanning that's happening on the internet,  or at least of our networks.  So, I broke up the data into what was happening from 2008 and 2012 first,  and you can see that the colors correspond to ports,  and we see in terms of packets and IP addresses, the purple port is very popular,  and this is TCP 445, and we see that the first increase is right when the config or outbreak occurred,  and then we see subsequent increases often corresponding to new releases of config.  But we can't say all of this is necessarily config, because there's other scans of this port,  though most of it happens to be from config.  And so we can come up with some heuristics to determine which packets originate from config,  and to do this, we can exploit a bug that config has in its pseudorandom number generator,  and for the most part, when it's randomly scanning the internet to propagate,  it has a bug where it only targets IP addresses A.B.C.D, where B is less than 128,  and D is less than 128, so it's only really scanning a fourth of the internet.  And so we used a heuristic based on the birthday problem,  which basically says, given a random group of people, what is the probability that two people are going to share a birthday?  And often this, it's like surprising, it's only like 34 people, and it's pretty proud,  and then it's likely that people share a birthday.  So another way of asking this question is, how many unique birthdays can we expect to give in N people and 365 birthdays?  So turning this into a identifying config, if we have IP addresses A.B.C.D that are being scanned,  we can look at the individual bytes of the IP address, so if we look at D, and we say,  how many unique D values can we expect to give in either targeting 128 or 256 targets,  which are the possible values for D?  And you can repeat this for the other bytes, and you can then start to differentiate between randomly scanning  a quarter of the internet versus the entire internet in expectation.  So if we look at the configure outbreak, and the amount of scanning that happened around that time period,  and this graph is in log scale, we do have some missing data,  but we do see an increase right when a configure was discovered.  So what we would expect here is that we wouldn't see any hosts matching our configure heuristic.  However, when we look at the number of IP addresses meeting the configure heuristic, this is what we see.  So for up until about August, we didn't see no IP addresses met this heuristic,  and then all of a sudden we started seeing some traffic.  So this is what, before the configure was actually discovered.  So this is evidence that someone was trying to actually test out their configure bug prior to this.  And on the first day, the IP addresses were all in the same province, and the first couple of days,  they were all in the same province in China.  And so maybe this is helpful.  As far as I know, nobody has claimed the Microsoft 250K bounty to collect the configure worm author,  so perhaps this information could be useful for that.  So that was before 2012.  So if we look at what was happening since 2012, not surprisingly, configure is dying out.  But the most popular port has been replaced with port 23, which is Telnet.  And the best explanation I have for this is that people may be trying to scan for Internet of Things.  If you have a better idea, let me know.  And we can also see some other interesting things happening here.  So this spike that is in gray, it was a variety of ports, and it corresponded to traffic from the Karnabotnet,  which was somebody decided to create a botnet, scan the whole Internet,  and then publish all of the results anonymously.  So we see this, and we can verify that traffic was actually coming from the Karnabotnet based on their data.  So if we look at the IP addresses, we notice some period of time where there's increased activity on a port.  So if we look at Heartbleed, right around there,  in here you can see in red where the Heartbleed vulnerability announcement occurred,  and then like a week or so later, we see a lot of increased activity on the pink port,  which is TCP 443, which is where Heartbleed was likely to be exploited.  Similarly, a little bit later, we see a lot of traffic, a lot of scanning TCP port 5000.  And so just Google searching TCP port 5000 during that time.  We, Akamai, had a report that they were seeing lots of universal plug-and-play devices being used in denial of service attacks,  and prior to that report, we see evidence of scanning on that port.  So we were potentially seeing activity before it was used in an attack.  All right, so that was scanning. Well, hopefully we will release our scanning data set pretty soon.  But going on to backscatter, I'm going to talk about an attack that we're seeing,  that we've been seeing on authoritative DNS servers.  So just a reminder, backscatter is a response to a spoofed packet.  So let's suppose you have a web server that you want to perform a denial of service attack on.  You could do the denial of service attack directly on the web server.  However, there is also another weak point.  All legitimate hosts who want to contact that web server need to find the IP address associated with the name.  So they have to do a number of DNS queries.  So it turns out that you could also perform a denial of service attack on the authoritative name server.  So one way that you can do this is with an open resolver.  And an open resolver, typically with DNS, you should only resolve domains for machines that you administer.  So UCSD's domain server should only resolve domain names for clients in UCSD.  So it's typically considered bad because otherwise you could use them in DDoS attacks.  But so you could use an open resolver to pull off this attack on the authoritative name server.  In particular, the attacker can spoof a packet, a DNS query, send it to the open resolver,  and since the open resolver resolves the data for everyone,  it's more than happy to ask the authoritative name server and they get a response.  And since the original query was spoofed, they do not respond to the attacker,  but instead it's likely that they will respond to our network telescope.  Or there's a probability that they will do that.  So we're seeing a lot of traffic recently from open resolvers.  So this is 2014 data.  So prior to pretty much the end of January 2014, we didn't see pretty much any traffic from open resolvers.  We saw about 3,000 open resolvers per month.  And then starting in February 2014, we saw 1.5 million open resolvers per month.  And we noticed that once this attack sort of took off,  we were seeing traffic from the same open resolvers over and over again.  This is only a small fraction of the open resolvers used on the internet.  The open resolver project, which is scanning, active scanning at the same time,  we saw about 20 times the number of open resolvers that we did.  But this means that this attack is only using a subset of the open resolvers.  But we can also look at some other data that we have from the attack,  which is the status code that comes back with your DNS response.  So if it's like, okay, everything's happy.  But you can also get a number of failures, including a serve fail,  which indicates that there's a problem with most likely the authoritative name server.  And in the month of data, we got serve fail errors from nearly every open resolver that we saw,  whereas in the open resolver projects, they see this error very seldomly.  So this is evidence that this attack is actually overwhelming authoritative name servers.  So one interesting thing is that you see, we see some data on January 29th,  and then the attack seems to really take off in the beginning of February.  And this first day, the domain that was queried was all for body.com,  which is a popular website, so this reflects a testing phase here.  Since then, there's been lots, the domains seem to be just used for a very short period of time.  A number, most of them seem to have bogus registration information.  And we're still seeing this, all this analysis from the first month of activity,  and we're still observing this type of attack right now.  So that was backscatter, now I'm going to go on to misconfigurations,  which in particular I'm going to talk about bit torrent misconfigurations.  So if you want to download a torrent, through bit torrent,  you typically contact the bit torrent distributed hash table,  and they will tell you the location of the torrent or some other bit torrent node  that is closer to the torrent that you want.  However, there can be malicious nodes in the distributed hash table,  and they can lie to you about the location of the torrent.  And if this happens repeatedly over and over again,  it's going to be a lot harder for you to actually find the torrent  and get the latest episode of Game of Thrones or whatever you want to watch.  So this attack is called an index poisoning attack,  where you're purposely inserting fake information into or about what's in the hash table.  And so what happens after you receive this false information  is you try to set up a connection.  So when people send bit torrent packets to the network telescope,  we get an idea of what torrents they are trying to download.  And so this is some data from July 2012,  and in terms of the boost packets associated with a torrent,  and you'll notice that a lot of them happen to have the word China in their name.  And a year later, we see about the same thing.  So this attack doesn't seem to be going on right now,  or if it is, it's a lot lower.  But, oh, I'm sorry, and typically in this China attack,  typically the IP addresses that are asked for the torrents  satisfy this equation or this set of IP addresses.  Basically they're in certain slash 13 blocks,  and so it seems that they're being generated programmatically  with a buggy pseudo random number generator.  And this attack is sometimes we see a lot of packets from it,  and then sometimes we don't see any,  and currently we're not seeing very many.  But more recently, about a year ago,  we saw a huge spike in the amount of bit torrent traffic we see.  We're getting traffic from about 250 times more IP addresses per hour.  And we don't really know everything that's going on to try to investigate this.  We were, so just as a recap, when you want the torrent,  you ask someone, the DHT node, the location of the torrents,  and they come back with the locations,  and then they potentially contact our network telescope.  So we want to know who's spreading this false information.  So this node, so we can't really learn this by looking at the IBR.  Instead, we can set up nodes to actually interact with the distributed hash table.  So we set up two clients and examine what happened for a bird,  two months, and they both contacted our network telescope fairly frequently.  And so we looked at who was telling our clients to contact the network telescope.  And the most popular client string was a lib torrent one,  but this only accounted for about 70% of the clients,  and it's a pretty popular client string among legitimate hosts as well.  Most of the IP addresses were in China, but they were in multiple ASs.  So this wasn't 2.6 vessel in identifying who is actually sending this false information.  But we did notice one really suspicious behavior.  So in the hash table, all the nodes have an ID.  So that means that they think that the IP addresses in our network telescope also have IDs.  And so the IDs that they request, they all have four as the third byte.  So that's kind of weird.  And typically, when you receive locations, you receive not just one location,  but multiple locations at a time.  And this behavior is similar for a lot of other IP addresses that we see.  So we're receiving a lot of bit torrent traffic as a result of a bug in,  or a misconfiguration in a peer-to-peer network.  Peer-to-peer networks also caused a lot of traffic as a result of a bug in one of the systems.  So if we look at the number of sources sending us traffic over time,  we notice some interesting things like the configure outbreak,  when we started seeing a lot of bit torrent traffic,  and then all of a sudden in October 2010, there was all the shape of the graph definitely changes.  It's very diurnal, and we weren't really sure what was happening here.  And we were able to identify the responsible payload,  and certain bytes seemed fixed, and then we could hypothesize about what the other ones were using it for.  But we still had no idea what this was, and the popular ports, the most frequently used ports,  we weren't really sure what those were either.  But we did notice that in terms of the sources sending them,  they were mostly located, a large number of them were located in China.  In fact, we received in a month's time traffic from 30% of all BGP announced IP addresses in China.  So this is like huge.  Also interestingly, when the USA category for IP addresses  belonged to the UCSD computer science department where it went to school.  So we were able to coordinate with someone who could monitor the traffic going in and out of UCSD's network  to basically capture traffic from these IP addresses.  This ensured that this traffic wasn't spoofed and was actually happening.  So all of the CSC machines basically contacted a common IP address,  and in response they got a pretty large packet.  And based on this packet, then they sent about 40 more packets to different machines,  and they were all encoded in this original big packet.  And it wasn't just one packet, they were exchanging a lot of packets.  And eventually the UCSD machines would receive a packet like this.  And so this packet is from 113704122,  but instead they would respond to 12270113,  just immediately after receiving this packet.  So, and this packet met the BPF filter that we had used to identify all of this traffic.  So this is a byte order bug, and this is why we were receiving a lot of this traffic.  We identified that this software bug was in Quihu 360,  and if you look at their license agreement,  then this is like the most popular security software in China.  And if you look at their license agreement,  you see that they will use peer-to-peer technology to update program modules,  malware definition databases, and components of the software.  So basically we were getting information about when people were updating, getting software updates.  We contacted Quihu and told them, hey, like, you have this bug.  And so then we could see how long it took for them to fix it.  The traffic had one kind of weird thing, which was like every four to five weeks.  There was a large spike probably related to big update events,  but there wasn't a big decrease following one of these.  Instead, it decreased like about a month later,  and this date was about the same time a new version of Quihu was available on their website.  So we're still getting some traffic, but in general, this bug has been fixed.  All right. Now on to the last part, which is looking at some unknown traffic.  So the bug was also an example of unknown traffic, but I'll go through another one.  So basically if you investigate some of these packets a little bit more,  you might be able to come or identify where they're from.  So in the beginning when I explained the unknown category, I said, here's a packet.  It's payload appears to be encrypted.  So basically this one IP address was getting a lot of traffic sent to it,  and they all seem to be encrypted based on the entropy of the bytes.  But we did a byte-wise analysis of what is the first byte, second byte, third byte, and stuff like that.  And we found that this byte here always seemed to be somewhat related to the whole length of the packet itself.  And then I read a bunch of white papers and found that the sality botnet, their encryption is such that  these four bytes are an RC fork he used to decrypt or encrypt the entire rest of the message.  So when we decrypted almost all the packets to this one IP address,  we found that they all sort of started like this.  So this confirmed that this is a sality commanding control packet.  So this is kind of interesting because you're like, okay, I understand why someone would have a bug  or someone would purposely put false information into a bit torrent DHT,  or I understand how a byte order bug happens,  but this also happens in peer-to-peer botnets as well, and that's why we received that much.  We received a lot of traffic.  In fact, if we look at how many IP addresses we're sending us traffic per month,  basically to this one IP address, we see about the same number of infections as Symantec was seeing in the early part of this decade.  So in conclusion, it's pretty likely that you are transmitting internet background radiation,  and if you use network telescopes or other technologies, you can find a whole bunch of interesting things.  In addition to just looking at these kind of security-related events,  we can also learn about the networks and machines generating the traffic.  Another example, you can do outage detection with traffic reaching network telescopes.  This is a graph from a paper that analyzed events during the Arab Spring,  and as you can see, the number of packets coming from Libya went down to zero at certain periods of time,  and these corresponded to known times that the Libyan government had pulled the plug on their country's internet.  We can also look at path changes.  So when you send a packet on the internet, there's this TTL field that is decremented by every intermediate router to prevent routing loops.  But based on this, you can infer how many hops away the source is.  So if this changes, then you know that a path change occurred,  and this can help you analyze outages and understand routing dynamics.  So looking at some of this stuff, we can see if you have traffic like this,  where the TTL is the same value over time, it's probably using the same path,  but if it looks more like this, then you know that the path has changed.  And then as a final example, we can also look at DHCP lease duration.  So when you join a network using DHCP, you announce that you want to join the network,  and you're given an IP address to use, and typically at some point in time,  you no longer use that IP address, which means at a future time someone else can use the same IP address.  So we can look at DHCP lease durations using any traffic that has some sort of ID associated with a client.  So if these are the packets you receive over time, you know that the lease duration is at least this long,  and at most this long.  So as I noted before, BitTorrent has IDs as well.  So we can use BitTorrent to identify how long lease durations are for various autonomous systems.  So this autonomous system, almost everything, has a minimum lease duration of less than seven days.  And this is really useful for understanding the effectiveness of blacklisting,  or how if people are going to not be able to access the internet because you have blacklisted their IP.  So hopefully you enjoyed the talk today where we discussed some of the crazy things that happen on the internet.  And so thank you.  Thank you.  Hello.  Hi. Very fascinating research and great presentation. Thank you.  Looking toward the future, I noticed this was all IPv4.  Have you done any consideration of IPv6-based telescopes, and you think it's practical with the sparseness of prefixes and v6 addresses?  So I haven't, but some people wrote a research paper where they used an IPv6.  They basically were able to announce a covering prefix and basically capture everything that wasn't.  Other people weren't announcing in BGP, and they didn't find as much.  But I think as IPv6 evolves, I think also this will evolve as well.  Thank you.  So thank you. That's very convincing that this is incredibly useful data.  How can other security researchers get access to it?  So I know that the data that UCSD has, that it is available to academic researchers.  I don't know the whole process, but I mean, you can start with your own network too.  Is there a question over there?  Thank you.
DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_0_119.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_120_167.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_168_1379.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_1380_2927.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_2928_3479.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_3480_4775.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_4776_4907.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_4908_4991.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_4992_5915.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_5916_6923.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_6924_7643.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_7644_8579.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_8580_8879.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_8880_10943.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_10944_12527.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_12528_13595.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_13596_15383.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_15384_16799.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_16800_16883.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_16884_16955.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_16956_17315.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_17316_20075.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_20076_21575.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_21576_22631.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_22632_23039.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_23040_25547.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_25548_26747.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_26748_26795.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_26796_27167.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_27168_31535.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_31536_32327.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_32328_34667.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_34668_35423.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_35424_36275.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_36276_38855.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_38856_38915.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_38916_39275.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_39276_39335.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_39336_39647.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_39648_40163.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_40164_40331.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_40332_41003.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41004_41099.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41100_41435.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41436_41555.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41556_41687.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41688_41771.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_41772_42491.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_42492_42575.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_42576_43079.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_43080_44015.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_44016_45383.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_45384_49319.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_49320_49895.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_49896_51083.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_51084_51455.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_51456_53939.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_53940_54431.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_54432_55463.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_55464_56855.png DEF_CON_24_-_Karyn_Benson_-_Examining_the_Internet_s_pollution_wjva6ZJyhwE_56856_56959.png