DEF CON 29 - Chad Seaman - UPnProxyPot: Fake the Funk, Become a Blackhat Proxy, MITM their TLS...

00:11 - Before we begin. I’m Chad seaman, but around here at DefCon you can just call me d1rt.

00:16 - I am part of the Akamai SIRT team. I’m actually a team lead and senior engineer on that team.

00:21 - For those of you unfamiliar with the SIRT team, which is probably all of you You may have heard of some of our research before.

00:28 - We focus on DDoS and emerging threats research, but that typically leads us down the path of malware and botnets and proxies and other good stuff.

00:38 - So before we begin, you’re going to see me talk about IOT.

00:41 - A lot of you are going to think IOT means internet of things.

00:45 - That’s not true for me. It’s the internet of trash.

00:48 - Whenever you see me say IOT, that’s what I mean.

00:53 - So what’s this talk about? Well SSDP and UPnP had been widely vulnerable in IOT devices for nearly 20 years.

01:00 - It’s not only possible, but also very easy to turn these devices into proxy servers.

01:05 - When attackers find vulnerable IOT devices susceptible to this kind of attack, they turn these devices into short-lived proxy server and delete their tracks when they’re done.

01:13 - If they don’t delete their tracks, the tracks will delete themselves.

01:18 - We’re going to cover SSDP and UPnP, previous UPnProxy research and campaigns conducted by me and finally UPnProxyPot, how it works and findings from a year of geographically distributed deployments.

01:31 - So, first things first SSDP and UPnP. SSDP stands for Simple Service Discovery Protocol.

01:40 - It’s a technology that’s built for the LAN.

01:42 - Uses broadcast addressing with HTTP over UDP.

01:45 - It essentially allows machines on a LAN to announce themselves and or hear announcements from their neighbors or network peers, and then expose them to UPnP, which will in turn expose services such as printing and media sharing and network configuration.

02:04 - All that kind of stuff. UPnP is Universal Plug And Play.

02:09 - It’s also built for the LAN. It’s good old HTTP and SOAP.

02:13 - SOAP as an XML. It lets machines on a LAN inquire about the services configuration options offered by that device.

02:21 - It also allows them to access those services and or potentially modify those configurations.

02:28 - So a good example of this is an Xbox, right? An Xbox or a PC game may need you to forward certain ports or certain traffic around the firewall rather than deal with the state of managing that in the net.

02:43 - So that’s what UPnP basically enables. It allows your X-Box to go forward and say, “Hey, poke a hole in the firewall, send everything on UDP 1, 2, 3, 4, over to me. ” So what is wrong with these technologies? Well, for SSDP, IOT devices are notoriously bad at deploying this correctly.

03:03 - The same is true for UPnP. It’s built for the LAN, but they stick it on the WAN just because, I don’t know, just cause.

03:12 - It was a reflected DDoS vector. Up and coming, most popular, MVP, king of the hill, whatever you want to call it, in 2014 to 2015.

03:25 - It’s still fairly popular for that, but it’s not as popular, mostly due to other vectors becoming more popular, not because it’s gotten that much less abused.

03:36 - We’re still finding this bullshit everywhere.

03:38 - Older products are still on the internet, amazingly “newer” products and new is there in quotes, but some “newer” products, and by “newer” I mean within the past few years, still have these problems.

03:54 - So 20 years later. At a minimum 14 years, and here we are still having the same old problems.

04:03 - So UPnP, Universal Plug And Play, once again, built for the LAN, but they seem to just love to stick this stuff on the WAN too.

04:11 - It treats the LAN as a safe space, which is fine, but the WAN is not a safe space.

04:17 - So, when you’re listening on the WAN and thinking it’s a LAN, it’s a little bit of a problem.

04:20 - It just does whatever it’s trusted network peers tell it to do.

04:23 - Does not require off. There’s not really a whole lot protecting it.

04:28 - Information disclosure. It will tell you everything.

04:30 - Model numbers, makes, serial numbers. On top of that, it will tell you how to talk to it, what services it exposes, what configurations, what data you can push in and what data you can expect to get out.

04:45 - It facilitates configuration changes on some devices.

04:48 - It makes it very easy to do those changes. In some cases, there are known RCE injections in the UPnP daemons in the SOAP handling.

04:58 - So your, basically, SOAP can get remote command execution on the underlying device.

05:08 - So let’s take a quick look at the history here and why I talk about 20 years.

05:11 - The first instance that I could find of somebody exposing something here is 2003, Björn Stickler.

05:20 - He came public with a Netgear UPnP information disclosure.

05:25 - A couple of years later, I’m going to slaughter this guy’s name, Armijn Hemel, I think, in 2006, gave a talk at the same conference and he launched a website called UPnPhacks. org.

05:40 - There’s a ton of great info here. His talk really kind of blew the lid off of all the problems that UPnP actually had and all of the potential vectors it could expose people to.

05:52 - And then in 2011, Daniel Garcia gave a talk at Defcon 19 called UPnP Mapping.

05:58 - It was a great talk. It kind of touched on this proxy and capability and some of the problems with UPnP.

06:04 - I was in the crowd. It freaked me out enough that I think my TP-Link router at the time was actually impacted by this.

06:11 - And I went ahead and remoted into my home network and disabled UPnP from the talk, while I was in the talk from my phone.

06:24 - So, a brief history of UPnProxy. So UPnProxy, in 2014, like I said SSDP is the new up and coming DDoS specter.

06:35 - We’re starting to see it abused pretty widely.

06:38 - We, Akamai SIRT, at that time we were known as PLX SIRT, are asked to write about it, start digging into it.

06:45 - Put it on an advisory and all that good stuff.

06:48 - So in 2015, this was happening at the end of 2014.

06:53 - In early 2015, the SSDP research leads me to discover UPnP and it kind of turns on that 2011 talk in my head.

07:05 - And I’m like, “Oh man, I remember this being like a shitshow. ” So in 2016, I decide that since it’s been about a decade after the sane conference talk and the UPnP hacks, it might be fun to revisit this and see how bad this landscape is.

07:26 - Are we talking hundreds of thousands? Are we talking millions? And just talk about, and kind of try and bring the fact that this is 10 years later.

07:35 - These things are still a problem. And these threats still exist in the real world.

07:39 - And everybody just kind of seemed to have forgotten about it.

07:42 - So I start writing that paper. The reason it’s relevant is because I had to write a tool chain to test some of these theories and concepts.

07:52 - This is a tool chain here that was for testing the NAT injection capabilities on exposed UPnP devices.

07:59 - So in the top there, you see the SSDP banner that we get back.

08:04 - We take the 192. 168. 0. 1. We changed that to the public facing IP address that we found UPnP responding on.

08:14 - In our SOAP payload we set that port 5. 5. 5. 5 is going to point into 192. 168. 0. 1 which we know is the router at this point on port 80.

08:26 - We then issue that SOAP request via curl. And what we see here is before the injection and after the injection in the scan results there.

08:34 - TCP 80’s filtered, you couldn’t get to it. But once I opened TCP 5. 5. 5. 5 and then I hit it in a browser, I am greeted with the admin login page.

08:46 - So that’s a little bit of a problem being able to get around the firewall that easy.

08:52 - (large sigh) As I’m doing this research in September, 2016, we get hit with a 620 gigabit per second, sustained DDoS attack from a botnet.

09:03 - At that point, the botnet was unknown. It ultimately got named Mirai.

09:09 - So as I’m digging into that, I’m inspecting attack sources.

09:14 - I’m seeing lots of IOT. There’s a decent overlap with the existing identified UPnP data set that I had from my decade of disclosure research.

09:24 - I decided that the UPnP info leaks could maybe help.

09:28 - And I start scraping those and poking these devices in general.

09:32 - Trying to figure out what the heck they are.

09:35 - So it turns out correlation is not causation.

09:38 - The fact that these devices were present in the Mirai botnet has nothing to do with Mirai.

09:44 - It’s just that shitty devices are shitty. And if it’s comprizable one way, it’s probably comprizable about two or three.

09:52 - In the internet of trash space that is. So having already written the script to dump the NAT tables as part of the NAT injection testing, I started doing that just to see, you know, maybe there’s something weird going on in there that we can figure out.

10:10 - It, like I said, it was not related at all.

10:13 - But what I did notice when I did that was there were some really weird entries in some of these devices out in the wild.

10:19 - The entries pointed to DNS servers, they pointed to Akamai CDN servers.

10:24 - They’ve been pointing at HTTP and HTTPS web servers.

10:28 - Which is really interesting, but I have other shit to do.

10:32 - Got a really big botnet. I got to figure out what the hell is going on.

10:35 - So I kind of just stick that in the mental back-burner and move on.

10:40 - So on the timeline here, we’re down here at the Mirai botnet and huge DDoS.

10:44 - So while I’m investigating that, I accidentally uncover the UPnProxy stuff, but I’m too busy dealing with this botnet.

10:52 - 2017, things start to calm down. Mirai, at least I have tooling to be able to better track it and handle it.

11:00 - So, I start looking back at some of my other research and I decide I’m going to look at what some of those really weird NAT entries were on some of those devices.

11:08 - And I began scanning the entire internet and dumping all of the NAT tables of all of these exposed UPnP daemons.

11:15 - This is when we uncover the UPnProxy campaigns.

11:20 - So UPnProxy uncovered by the numbers. There were 4. 8 million SSDP responders in that data set.

11:29 - 765,000 had exposed UPnP, it’s roughly 16%.

11:34 - Of those, 65,000 were actively injected with UPnP entries.

11:39 - That’s 9% of the total vulnerable population and 1. 3% of the total responders.

11:45 - Of those 17,599 unique end points were identified as being injected in these devices.

11:52 - Typically, if a device had one injection, it had multiples.

11:56 - The most injected destination had 18. 8 million instances across 23,236 devices.

12:04 - The second most injected destination had 11 million instances across 59,943 devices.

12:10 - I point this out because it shows two kind of campaigns running simultaneously here.

12:15 - The most injected destination obviously had a lot more instances of injections across a much smaller pool of devices.

12:23 - And then the second most injected destination had a lot less injections, but a much larger swath of devices that they were injected on.

12:34 - All in all there were 15. 9 million injections to DNS servers, 9. 5 million injections to web servers and 155,000 injections to HTTPS servers.

12:46 - While I’m doing this research, I’m talking to some fellow researchers and friends, and one of the guys goes, “Hey, I think my friend’s working on something very similar.

12:55 - Would you be interested in talking to them?” Absolutely I was.

12:59 - I’m very sorry to the researcher I talked to.

13:01 - I don’t remember your name and I can’t find the email and Symantec did not give you a shout out on their blog.

13:07 - So thank you for your hard work and I’m sorry.

13:11 - What they ultimately found was that there was an APT group and they were running this inception framework.

13:17 - Where the attackers were basically using these UPnProxy instances and they were chaining them together.

13:24 - So they would log into their VPS. They would inject a proxy route that pointed to another UPnProxy vulnerable device.

13:34 - They would then use that injection to inject another route.

13:37 - Then use that injection to inject another route that ultimately pointed out to their target destination, which was a cloud storage provider for uploading their malware.

13:46 - And then they would use that to upload their malware to the cloud platform.

13:51 - And this is partly to get around detection, right? A lot of times you’ll have these lists of known proxies, known end points, TOR, et cetera.

14:02 - And when you’ve got a pool of, you know, tens of thousands of home devices that aren’t on any of those lists, you’re much less likely to set off some alarm bells when you log in and upload a nasty file.

14:14 - So, really interesting research. I gave him my tools.

14:20 - He was able to confirm it was what we thought it was.

14:22 - And then I was able to confirm in my data that I could see some of the similar clustering.

14:27 - So what you’re seeing here in the graph on the right is two different bubble graphs.

14:33 - The size of the circle is respective to the number of outbound routes found on that device.

14:39 - And then every blue line is pointing in the direction of a relationship.

14:45 - There’s an arrow. So where you see the thick blue on one side, that is the tips of the arrows running into one another.

14:51 - And there’s clearly two different strategies.

14:53 - The top cluster, you have a larger pool with a handful of routes that go out and they all point into a smaller pool of devices that may only route to one or two or three things.

15:05 - And in the bottom cluster, you see a centralized high route out collection, and then they all point out to different end points.

15:18 - So it’s a different structure, different strategy of building that chaining.

15:23 - But the chaining exists. And I thought that was pretty cool.

15:27 - So we find all this stuff, but it’s not super widespread.

15:32 - I’m just kidding. It’s everywhere. So there are 73 brands and over 400 models that we could identify.

15:38 - And it’s important there that I say we could identify because we were only able to successfully fingerprint with confidence about 24% of these based on information leaks.

15:48 - And those information leaks weren’t just what came from the UPnP daemon.

15:53 - Sure, it helped a ton because it’s a super chatty…

15:56 - It exposes quite a bit of information about the device, like I said, but we would also go so far as to attempt to see what other ports were there, SSH banners, anything like that that we could potentially fingerprint on, we tried.

16:12 - And still, we could only get about 24%. So that is quite a considerable amount.

16:21 - 73 brands, 400 models is a nice chunk, but you gotta remember that there’s 76% that we couldn’t even identify.

16:27 - So, who knows what they are. This publication goes live and, you know, the crowd goes mild.

16:37 - Nobody really cared. It didn’t really get a lot of attention.

16:40 - I was pretty disappointed. I thought it was a very cool finding, but.

16:44 - And I’m downplaying that a little bit. So, a couple people cared.

16:48 - The people that needed to care cared. So I’ll take that as a win.

16:52 - The research did get some industry attention through some trust groups and work groups and stuff.

16:59 - Did get elevated and passed along. And it was ultimately used to help some ISPs support the case internally for clean up and sanitation efforts.

17:11 - So, progress is made behind the scenes. Some networks start filtering SSDP, that’s all good.

17:18 - You’ll you’ll see the result of that in the next couple of slides.

17:23 - Ultimately I get an email from a journalist, she’s doing some work and she was recording this new show.

17:31 - Her name’s Justine Underhill. And she wanted to talk to me about UPnProxy because the episode she was recording was on IOT and security and everything else.

17:40 - So while we’re recording this video, I decided that she’s asking questions about, “How hard is this? How long does it take? How much does it cost?” And I’m like, “Well, I’ll just show you. ” So I pull out the laptop, jump on the internet run ZMAP and I hit the first 1000 things that respond to my SSDP probe.

18:04 - And then I start dumping their NAT tables. And while I’m sitting there showing her this I’m like, “Man, I think we just found something new.

18:11 - Like, this wasn’t in the previous scans. “ And this is how I accidentally discovered the EternalSilence stuff.

18:16 - Which it was cool, cause we didn’t really have a solid case.

18:21 - I had proposed that attackers could use this to route around the firewall, but we didn’t really have a solid proof from our existing scans that that was occurring yet.

18:31 - So these are what the injections look like after they go through our logging process and are converted into JSON.

18:37 - You can see that they are targeting IPs inside the LAN 192. 1. 68. 10 space, probably from the information leak from the SSDP banner.

18:49 - And then so like there on 166, you can see that they tried to open a port forward to 139 in port 445.

18:57 - So they’re injecting routes into the LAN space and they are targeting Samba or SMB.

19:05 - We named it EternalSilence because Samba and SMB are clearly being targeted by EternalBlue, pretty heavily at that point and the Spanish there, in the Newport mapping description there’s some Spanish, and I am terrible at Spanish.

19:23 - So, my gringo Spanish is, “Galleta silenciosa. ” Go ahead and laugh at me, but it roughly translates to, “Silent cookie. ” So UPnP EternalSilence is discovered and published.

19:40 - Ultimately 3. 5 million SSDP responders. So, some of that cleanup effort worked.

19:44 - We found almost a million less devices than we did in our previous research.

19:50 - 227,000 instances of exposed UPnP. 45,000 had active, EternalSilence injections.

19:57 - There’s no way to really know what they were up to, but based on what they were targeting, the EternalBlue link is an educated guess.

20:05 - And that educated guest is based on, if I were evil, that’s what I would do, right? I’ve got this surefire, SMB exploit, but everything that’s running it on the internet has already been popped.

20:18 - But you know what, if I can find a way around some of these firewalls, I can probably find some devices that are still listening on that that haven’t been patched and now I’ve got a new place to drop my ransomware.

20:32 - So, that’s cool. All this research is cool, but we still have problems.

20:37 - The research up to this point, it has been via passive identification.

20:42 - This requires scanning the entire internet regularly to find stuff.

20:44 - It’s time consuming. We get lots of hate mail and threats for scanning stuff.

20:48 - People don’t like when you scan the internet.

20:50 - Guys, relax, relax. You’re allowed to scan the internet.

20:54 - It’s not a crime, okay? It’s still time-consuming.

21:00 - It results in a ton of logs because we’re dumping all of these NAT tables.

21:03 - So it ends up with gigs and gigs and gigs of logs per scan.

21:07 - On top of that, it’s very time sensitive, right? We know that the attackers can delete their entries.

21:12 - We know that the entries time out. So the odds that we’re finding anything at all is pretty surprising.

21:20 - Especially when you consider that reality. So the real problem here is that we can tell where they’re doing stuff and where they’re pointing stuff, but we don’t actually have visibility into what they’re doing with it.

21:35 - So if we see them injecting port 25, we assume it’s spam, but we have no idea.

21:40 - They could be dropping 0days against, you know, SMTP servers.

21:44 - No clue. So we need to fix that. And that’s where UPnProxyPot enters the fight if you will.

21:54 - So what is UPnProxyPot? The 50,000 foot view.

21:58 - It listens for SSDP probes and it directs attackers into a fake UPnP instance.

22:02 - The UPnP emulation is good enough to get to the injection phase.

22:06 - It’s not a full implementation. It could be improved, but it’s good enough.

22:12 - From there we offer on the fly proxy capabilities with man in the middle content inspection and logging.

22:17 - TLS stripping is also supported. All of this is easy to modify in the sense that if you want to pretend to be a different device, all you have to do is change some XML files and some text files on disc.

22:34 - It doesn’t require code changes to change your device profile, per se.

22:38 - So it offers session-based PCAP capabilities so you can come back later and inspect the traffic that went over the sockets and it’s written in Golang and bash.

22:49 - So, SSTP emulation. The SSDP response that is currently in the project was lifted directly from the most abused device that we discovered during the UPnProxy research.

23:03 - It stored a flat file on disk. You can change it without modifying any code.

23:07 - The one gotcha is if you update the SSDP banner and it changes the port on which the UPnP daemon is listening on, this is what the attackers pivot on.

23:16 - So you will need to change the listening port in code that the UPnP daemon listens on.

23:23 - I didn’t have a configuration file set up when I wrote this in my initial thing.

23:29 - It’s an improvement that could be made. UPnP emulation.

23:34 - So the UPnP responses are lifted also from those same most abused devices.

23:41 - All the HTML XML is stored in flat files, updating them requires no code changes.

23:45 - UPnP emulation serves basic files, handles NAT interactions.

23:50 - The attackers applied SOAP is parsed and handled via RegEx.

23:54 - It will respond with proper error payloads if criteria are not met, or XML is malformed.

24:00 - Responses must contain attacker supply data.

24:02 - So that these responses use standard printf formatting.

24:08 - So if you need to change your thing and the attacker supplied port needs to be in this chunk of XML, you can just put the %d and it’ll be there.

24:19 - So, on the fly proxy. This is kind of unique because the attacker gets to control their proxy configuration themselves.

24:27 - So we had to support that. So attackers submit their proxy config via SOAP just like they’re talking to UPnP.

24:32 - We parse them and then create a session of sorts.

24:35 - And then we scrape and log plain text across the proxied session in both directions.

24:40 - If they’re proxying to TCP 443, it’s a special use case and we assume that connection is a TLS connection and we do some special man in the middle link there.

24:53 - So, stripping TLS. And this is a hard slide to read.

24:58 - It’s very upsetting. So attackers actually do some verification when they’re using the TLS connections.

25:05 - The initial deployment saw connections, but they would bail before actually pushing data across that connection.

25:12 - Attackers are fingerprinting SIRTs. Initially they were doing this via the subject line.

25:18 - There is an automated cloning process where we began by pulling the domain out of the ClientHello.

25:25 - We then go forward to the injected endpoint and we get the SIRT with the respect of SNI that was provided in the ClientHello.

25:33 - We copied the subject field from the remote SIRT and we mirror it into a self-signed clone SIRT.

25:42 - And this all happens in real time when they first establish their connection.

25:46 - This allows us to, it was allowing us to bypass their fingerprinting and actually get plain text out of the TLS flows.

25:55 - Literally yesterday, as I’m recording this, literally yesterday, it stopped working.

26:00 - And I don’t know why. I don’t know if they’ve changed their fingerprinting.

26:04 - I don’t know what is really going on. But I have a year and a half.

26:10 - Well, I have months worth of logs at this point that have this functional and now that it’s about to go open source it breaks.

26:17 - So, I’m sorry. I hope we can figure it out.

26:22 - So the other feature is the automated PCAPing.

26:25 - The project uses gopacket. It allows us to create PCAPs on the fly using Berkeley packet filters that are scoped to the individual sessions, the individual proxy sessions.

26:37 - As attackers interact with the proxy injection, the PCAPs are automatically collected.

26:41 - If you find something interesting in the logs, you can find the associated PCAP and see the entire session easily in whatever your favorite, you know, PCAP packet muncher is.

26:51 - Wireshark, TCPdump, whatever. If you run out of disc space on your deployed honeypot, this is probably why.

26:59 - That is from a single, machine down there at the bottom.

27:02 - You can see that we had 81,100 PCAPs that we ultimately collected for different sessions and of those PCAPs it resulted in almost five and a half gigs of disk consumed.

27:17 - So, (large sigh) this part hurts as well.

27:21 - The initial deployment was for one year, and it was four nodes deployed across a single VPS provider.

27:28 - There were geos from Dallas to London to Tokyo.

27:31 - 300 gigs of PCAPs and logs were ultimately collected.

27:34 - Hundreds of millions of captured proxy sessions and billions of log lines.

27:40 - I downloaded all that and I destroyed the cluster and then I accidentally lost the backup.

27:48 - So I figured this out literally like a day after I submitted the CFP to Def con.

27:56 - Luckily I had a couple of months before everything was accepted and approved.

28:01 - So I was able to deploy a smaller four node cluster for the two months between CFP and what you’re seeing now.

28:12 - So ultimately four nodes deployed. US, UK, India, Japan, 39 gigs of PCAPs and logs collected.

28:19 - 230,000 captured proxy sessions and 22 million lines of logs.

28:26 - The good news is I did have some notes, so not everything was lost from the previous deployment.

28:33 - And the trends that I saw in the new data are spot on for the trends I saw in the old data.

28:39 - There’s not a whole lot’s changed. Just a lot less data to back up the claims, but I promise you it’s pretty much identical.

28:49 - So, observations. The first thing is that they don’t blindly inject their proxies.

28:57 - They actually come and do some testing. So injections, they first come and they insert a test proxy instance.

29:06 - Once they confirm that it works, then they inject a real proxy.

29:10 - They utilize it and then they attempt to delete it.

29:13 - I say, attempt. Well, we’ll cover that. So this is the process of an injection.

29:22 - We see them show up with their M-SEARCH banner.

29:24 - We respond with our SSDP response here, and you see that we point them to 192. 168. 0. 1 on port 2048, and then etc/linuxigd/gatedesc. xml.

29:39 - We see them come back within the same second and they then request that.

29:44 - You can see SSDP and UPnP in there. They request that.

29:49 - And from there, they think that we are the device they’re looking for.

29:55 - Once they have confirmed that, then they come back and they attempt to add their port mapping.

29:59 - So in this case they’re adding an entry that will force us to listen to WAN port 22280.

30:07 - It’s a TCP socket, and any traffic received on that is going to be redirected to port 80 on the host at 74. 6. 231. 21.

30:19 - You can see down there, the new port mapping description kind of mirrors the external port that they use that’s sync and then a number.

30:26 - And then the new lease duration is 600 seconds.

30:29 - So, this will time out after 600 seconds. Then they come back and they utilize that newly injected proxy.

30:41 - So here you can see, they sync to 280.

30:45 - Everything up there between the curly braces is the proxy configuration.

30:51 - We can see the source. We can see where ultimately they’re going to point to.

30:54 - So 93. 190. 139. 76 on port 57388 is going to send traffic to 74. 62. 31. 21 on port 80.

31:05 - Ultimately we intercept a GET request to Yahoo with no header.

31:09 - So it’s super easy to spot. And Yahoo, because they moved to HTTPS, ultimately issues a 301 permanently moved.

31:19 - And this is all they really need for their fingerprint.

31:22 - Once that’s done, we see the attacker come back and they attempt to delete the port mapping, but they send us malformed XML.

31:31 - What’s interesting here is that the malformed XML apparently has, I don’t know if they forgot a null at the end of the envelope, but it continues as a buffer overread and what we ultimately see here is XML that is not related to this request, but it just happened to neighbor it in memory.

31:49 - What’s interesting here… In this case, it’s the same injection they just send us.

31:53 - Which isn’t that interesting. What’s more interesting, and there are other instances where there is XML information leakage from the buffer overread from other devices that they may have been talking to recently.

32:05 - So in this case, at some point they were talking to a D-link DSL, 2730U.

32:11 - If you check that out, you can see that it is a popular item on a popular e-commerce website.

32:17 - It’s actually a choice item on that e-commerce website and it has 3,100 ratings.

32:22 - So for 1,329 rupees, you can buy this device.

32:27 - And that’s about $19 US, I believe. And you can inadvertently be a black hat proxy too.

32:34 - So, these are some of the top talkers. Or sorry, some of the top injected test end points.

32:41 - So you can see there’s Akamai, Yahoo, a few others in there.

32:45 - That top one is clearly the standout winner, the 89. 39. 105. 12.

32:49 - And they’re going to ip. shtml. That’s a special page.

32:54 - It returns your public facing IP address, which here I’ve clearly modified it.

32:59 - And then this UBC IEG plug that they use for some kind of identification, I’m assuming.

33:07 - So there’s also a very large campaign being run against Google.

33:10 - This is predominantly all the TLS traffic. It’s very weird.

33:13 - I don’t know what it is. Out of the 59,924 intercepted requests going across the TLS sockets.

33:19 - All of them, 100% targeted Google. This is click fraud, SEO.

33:25 - I don’t know what it is. This is an example of a caught request.

33:30 - So they’re searching for a Cisco spark board factory reset.

33:34 - We can see their accept language. We can see their cookies.

33:36 - The user agent they used. All that good stuff.

33:39 - We can see even, they seem to be coming from Dallas based on the information leakage in the URL.

33:46 - But I can’t really confirm that. Also here we see the response.

33:52 - So we get a 200, okay, for their search. We see the cookies.

33:56 - We would, it’s not here, but we would actually have the full page content and everything.

34:01 - It’s disabled in this case, because that was a lot of log lines.

34:04 - I mean, gigs and gigs and gigs of Google pages.

34:08 - So in total, they sent 57,237 searched terms.

34:13 - There are no really clear patterns. They’re from all different geos that they target.

34:17 - They use a ton of different user agents. And each request gets basically one search per session.

34:25 - So you can see that top result there has only shown up 55 times out of 57,000 requests.

34:31 - And it’s just a search for the word Samsung in quotes.

34:34 - Which is weird. Some of the funnier searches that were captured.

34:41 - 72 hour deodorant, antivirus download now, Marlboro summer camp, leather trousers outfit, fafafa slot hack.

34:49 - I don’t even know what that is. I should probably Google some of these to see, but I haven’t yet.

34:57 - And like I said, they’re very geographically distributing their stuff across the Google platform.

35:04 - There are domains in here that I don’t even know what country they’re affiliated with.

35:10 - So did you know, there’s a. bj,. as,. jm,. md,. ee? You know, so they they’re clearly targeting google. com the most, followed by co. uk.

35:28 - But still there’s so many that they’re hitting.

35:31 - It’s crazy. This is the user agent profiles.

35:36 - So they sent 293 different user agents. And then you can see, there’s almost normalized clusters of users and distribution across the abuse.

35:47 - And these are some of the top talkers. So, it’s not what you’d expect, right? You would, I guess, I mean, I guess it is what you’d expect if it’s a single abuser.

35:59 - But the nature of the queries almost make it seem organic.

36:03 - It doesn’t seem like it has an abuse pattern.

36:05 - It almost seems like real end-users, but then it’s not real end users showing up and popping holes in this stuff.

36:10 - They’re all being ferried through a handful of top talkers.

36:13 - And then you have your outliers. If we look at the top 10, we see that Worldstream, Worldstream, Worldstream, Worldstream, OVH, Worldstream, OVH, Worldstream, OVH and Avast.

36:28 - So let me just put it this way. If you work at Worldstream, find me at the bar.

36:33 - If you work at OVH, find me at the bar. If you work at Avast find me at the bar and I’ll buy your drink, if you tell me what the hell is going on there.

36:41 - Cause I don’t know why Avast would be showing up in this data set, but there they are.

36:48 - So some theories on this. The queries to me seem too oddly human.

36:52 - They’re in a bunch of different languages. They’re stuff like, you know, the best car insurance in Dallas Fort worth area.

36:59 - Okay. So it’s too organic to be just purely automated abuse in my opinion.

37:06 - And I’m not sure that the people that are using these proxies are aware that they’re using them.

37:11 - I have this theory that it may be some kind of residential proxy reseller, or some kind of ultimate anonymous VPN service provider or something.

37:23 - And these people think that they’re getting these super secret high privacy stuff.

37:28 - And I’m just sitting here in the middle reading their traffic.

37:31 - Which is a problem. So, those are my theories.

37:34 - I’d love to hear more theories. You’ll also intercept some other stuff outside of TLS.

37:42 - Here, for example, are some spam messages that were being routed.

37:46 - These guys were injecting Outlook servers, and then, you can watch the entire interaction.

37:50 - You can watch as they send their, their hello.

37:53 - You can see as they confirm different addresses are deliverable and then they build their message and shoot it across.

37:59 - You get to see all of that. The good news here is that Spamhaus is doing God’s work and stopping a lot of that abuse from actually succeeding.

38:09 - This was just a fun finding from the older data set.

38:14 - So while this project was going on, Belarus had a very tumultuous political event where a bunch of people went out and protested the recent election.

38:28 - And as a result, Belarus shut down their internet to news and political websites.

38:35 - And while that’s going on, suddenly I started seeing these guys popping up in UK in proxy.

38:42 - So the top site was sb. by which is a news website.

38:46 - And it looks like they were trying to get to the registration and then solve some CAPTCHAs.

38:52 - The other was photobelta. by which is a stock imaging host, I think, or something.

38:59 - But they were actually doing command, not command, injection, SQL injections.

39:03 - Which I found pretty funny. And then the third one here is mail. rec. gov. by.

39:10 - According to Google translate, this is the Central Commission of the Republic of Belarus Elections or something along those lines.

39:16 - And they were just trying to check their mail it looks like.

39:20 - And then on the bottom one here, we’ve got a news outlet ont. by and then they’re trying to get to what appears to be their exchange server.

39:27 - So I just found that kind of interesting. All right so that’s a lot of history, a lot of observations, but now it comes to cool part.

39:35 - I’m open sourcing all of this. So anybody that wants to take this, stick it on the internet, play with it, modify it, whatever you want to do.

39:45 - Have at it, it’s yours. And this way we can all kind of share the fun and see what’s going on with these campaigns.

39:51 - And if you find really cool stuff, I’d love to hear about it.

39:56 - So with that open source announcement, let’s get some stuff out of the way.

40:00 - First things first, this project was for fun, is for research and it was for me to practice my Golang during COVID.

40:08 - Second, I apologize for my shitty code. I know it’s shitty.

40:12 - I’ve learned more Golang since then and learned more design patterns in Golang since then.

40:16 - And I really understand how shitty my code is.

40:19 - I’m sorry. Like I said, it was a research project.

40:22 - It’s not commercial grade software. It served its purpose and it did well enough to serve that purpose and that’s all I really needed out of it.

40:31 - Yes. There are bugs. Thank you for noticing.

40:33 - If you open an issue, there’s a great chance I’m not going to address it.

40:38 - Maybe someone else in the community will, but this is not my top priority anymore.

40:42 - So I would encourage you to learn some Golang and maybe submit a pull request instead.

40:47 - If you’d like to fix that bug. Yes, it’s hacky.

40:51 - I know. I am a hacky developer. I’m not your enterprise leading scrum, running everything else, developer.

40:58 - So, it is what it is. If you have ideas to fix or improve stuff, it’s open source.

41:06 - Have at it, hoss. Fork away. Send pull requests, whatever.

41:10 - I’ll likely accept a pull request. I will likely ignore your issue that you submit to the GitHub repository.

41:22 - So, some ideas for improvements. If you want to hit the ground running.

41:27 - Logging could be improved. Content injection could be a thing.

41:31 - In a world where people are abusing this stuff.

41:34 - I imagine that you could stick JavaScript in pages, or you could tamper with cookies, or you could inject plugs of texts that might be indexable.

41:42 - That you could maybe turn up on a search engine later.

41:44 - I don’t know. These are just some ideas I’ve had.

41:48 - There is a memory leak. I know. The run script actually restarts the binary every hour to get around this because I haven’t had time to actually troubleshoot it.

42:00 - Yes, it runs in screen. I regret nothing.

42:04 - Feel free to properly daemonize it if you’d like.

42:08 - This, I think would be the biggest benefit.

42:11 - If you randomize the SSDP banners and listen on multiple popular exposed UPnP ports, I have a feeling you’re going to see a much more diverse set of attackers show up.

42:21 - My findings may be myopic because I’m pretending to be a single device.

42:25 - And that single device is what’s being targeted by these people.

42:29 - If you were to diversify the target that you paint for your attacker.

42:34 - It’s possible you will also diversify your findings.

42:40 - Some additional ideas for improvement. The SIRT caching, when I wrote this, the SIRT caching was not taking in SNI differences.

42:48 - So, it works on Google because all Google servers are just Google.

42:54 - But if you were to say, have an injection that pointed to someplace that was multiple domains associated with it, you’re one clone SIRT is only going to be the one that is aligned with that initial request.

43:08 - So you could improve that by in the SIRT cache, actually using the SNI value, the domain name that was used when that SIRT was cloned.

43:17 - Improved TLS handling and proxying, like I said.

43:20 - It was working. It has stopped working. Improving that would probably fix the problem.

43:26 - Improved SIRT cloning. Clone more fields to better emulate the remote, the endpoint SIRT that you’re trying to clone.

43:34 - Improved error handling. Cause I didn’t really handle any errors.

43:37 - So anything is an improvement. And improved, basically everything else.

43:44 - You can find most of the information you’ll need in the readme file.

43:48 - If there is anything I missed, please feel free to submit a pull request with the updates that you found when deploying this stuff.

43:55 - It’s written in Golang, but it does have Linux dependencies.

43:58 - So it will run on any operating system so long as it’s Linux.

44:02 - You can deploy a node in VPSs very easily. You could also run it on Raspberry Pies or ODroids or anything else.

44:09 - Just stick it on the DMZ and you’ll be good to go.

44:12 - Typically you start to see abuse within the first 24 to 48 hours of deployment, and it may be even lower than that.

44:20 - So the last thing. If you find something cool, please hit me up on LinkedIn and let me know about it.

44:26 - I’d love to hear if you find new and interesting trends in some of your deployments.

44:34 - And that wraps it up. So, go grab the project, pull it down, hack it up, compile it, deploy it.

44:41 - Let me know what you find. Go have fun. .