 So this is the discovery and execution of entirely new classes of web attacks in order to meet your girlfriend. So before we begin, a little bit about me. I'm a security researcher. Narcissistic vulnerability pimp is what they're calling them these days, right? I do not do security professionally. I do it for fun, like most of you guys or some of you guys. I'm known for the SAMI worm, the worm on MySpace a couple of years ago. I co-founded Phonality, an IPPVX company. If you're familiar with Tricksbox, we developed that. And I love Lady Gaga, but I love Kesha too. It's kind of in between. I'm not sure. You're probably wondering, like, why haven't I heard of this guy or hasn't this guy done he's done nothing for a couple of years. Why is that? They didn't let me touch computers. It's true. It's true. A few years ago, I was raided by the Secret Service, electronic crimes task force. They came into my home. They took all of my computers, well, my laptop. They took my phone. They took any CDs, DVDs. They took my Xbox. Yeah. Yeah. I dealt with court, literally could not touch computers. I was banned for life. A couple of years later, I fought and I fought. And I am now back. Rob's touch computers, all right. But I'm not allowed on MySpace. All right. So what are we going to talk about today? Talk about the web. Why the web? Honestly, you know, I got bored of the web a couple of years ago. You know, it's really cool. There's so much you can do with it. But security is so much broader, right? There's so much cool stuff going on here at DEF CON, just in security in general, right? You have reverse engineering. You have network security. You do have web application security. There's hardware hacking, all this cool stuff. Some people have even made ATMs dispense cash. You probably haven't heard about that. It's a really cool new thing that they're talking about. But the web is actually really cool in another way. Everyone has a web browser. If you get a computer and you have an operating system, you have a web browser. So it's like the one piece of software that allows me to deliver code to you and for you to execute it. It is basically code delivery mechanism that I can attack anyone, anyone. Everyone has the Internet today. It's kind of like when the App Store came out for the iPhone, right? At that point, you could deliver any sort of content that you wanted. Of course, Apple bans malicious content and fortunately they give us freedom from porn. So the web browser is just like that except no one's guarding it. There's no one checking to make sure that your site's not malicious. I mean, obviously there are companies that are doing this in software that's working on this. But for a long time there hasn't been. So this is my home page. It's probably for many of you. Anna Ferris. She's amazing. I'm in love with her. So I was checking out, you know, just pictures of girls on a social network as I typically do before I get in a lot of trouble. And I found her and I think, man, she's amazing, you know. She's the kind of girl I want to get to know. So I'm looking at her profile, looking through her pictures. I can't really see too much. She's not my friend. Thought about that for a second. And then I saw, oh man, you know, I should message her. But then I saw she's in a relationship, not an open relationship. It's not complicated. She's in a relationship. So I'm like, who is this guy and how am I going to best him? So I look into him a little bit. All right. So this guy, he's a certified information security specialist professional, yeah, chief executive officer of SEC theory, co-author of XSS exploits, oh no, author of detecting malice, co-developer of clickjacking, really cool technology with the really awesome Jeremiah Grossman, runs hackers.org and slackers.org if you guys have ever been there. And he's a certified ass, which is an application security specialist. It's pretty impressive resume. A man who needs no introduction, Robert R. Snake Hansen, this guy. So here's the problem. I want to attack this guy. We all know we can attack random people on the web. You have a little bit of malicious content on there and you'll get some sort of hit rate and if you get enough visitors, you will be attacking random people. But I want to do a targeted attack to someone who is secure, someone like you people who understand security, who are probably running with a lot of technology to help secure yourself. So how do we do it? How do I attack him? You don't. You do not attack that person. You attack him directly. Ooh, that's what I'm trying to attack. Come on guys, come on. So he's on Facebook. Facebook is an awesome website. It's a social network. It's the cool one these days. Now if we go to Facebook, we'll see something in the URL bar. Index.php. I know what you're thinking. It's FIP. It's not. It's PHP. I looked it up. It's a computer language, typically used for the web. It's an extremely common web language. I'm sure all of you have at least heard of it. Many of you I'm sure program in it. It's great because it's extremely common. So it's well understood. The code is open source. You can all go and look at it and see what's going on in there. It has extremely, it basically has very good session management that everyone uses. Every single person who does PHP and uses sessions typically uses the built-in session management. If you're using frameworks like Coke, CakePHP, or Kohana, or Codeigniter, or any of those other things, they're also using this session management. So PHP sessions, what are they? They're basically a random string that's generated. It's passed either in the URL or cookies. So what are cookies? Yeah. It's my second favorite. A cookie is basically a persistent piece of text that remains with your browser. I'm sure all of you are familiar with it. This contains data, typically it will contain a session data. Session data is basically a random string so that when you go to any page on that website, it can identify you with other information the server has stored locally. So when you go to Facebook and you log in with a username and password, they provide you a random string that is assigned to that username. If you ever go to any other pages later on, they look at that random string that you're sending them and they say, oh, I know this guy, this is Sammy. So it authenticates you. So let's try to attack a session. Let's look at PHP session code. So WinStore. So we pull up session.c. This is the function session start. This is what creates a session in PHP. Basically what happens is it creates your random string right here in the snippet of code in this sp per nef. It's looking at a couple of things. It's looking at the IP address of the person authenticating or getting this session. It looks at the epoch, which is basically a time from January 1, 1970, the number of seconds. It's looking at the microseconds that that person acquired the cookie and it's looking at a random, just a random number that's created. So if we take all of that, that's 160 bits of entropy. We're going to get a little deep here just for a little bit. So 160 bits is a lot if I were to brute force it. Let's say I wanted to become our snake on Facebook. What I would do is I would brute force this session, that random string, but 160 bits, that's a lot. Now, bits can be a little confusing. We'll just do a really quick primer. You know, 64 bits is not double 32 bits. Every time you add a bit, you're doubling. So just a quick primer, what we can do is a little trick for every 10 bits. You can add three zeros. So 10 bits is a thousand, 20 bits a million, 30 bits a billion. Also if you can just remember the 10 bits, zero through nine equals one, two, four, eight, 16, 32, 64, one, two, eight, two, six, five, 12, you can take that number to figure out what you want. So 25 bits, we know five is 32, and the 20 bits, right, is six zeros. So 32 million in that scenario. So 160 bits is essentially 10 to the 48. If we could brute force at 100 trillion values per second, it would take 900 quadrillion eons to brute force. I didn't even know what an eon was. I had to look it up. It's 500 million years. It's a lot. Brittany knows. So again, 160 bits, we're not going to brute force this. It doesn't matter how fast of a computer you have. So let's take a look at this a little bit closer. Well, microseconds isn't really 32 bits. They're only million microseconds per second. Well, a million, if we remember, is only 20 bits, right, because they're six zeros. So we actually just reduced, without doing anything, the 160 bits. And we reduced 12 bits and got it down to 148 bits, which doesn't help us. That's a lot. So let's take a little closer look. If you're familiar with Facebook, it has chat. When you go online, or when someone logs in and you look in the chat window, you actually see that person come online. How is that happening? That's happening with Ajax. Your client is continuously checking with Facebook to see, is someone else logging in, is someone going offline, just to understand, get an updated status. Well, if you use something like live HTTP headers or a packet interface or something, you can see the HTTP request going back and forth. And you can recreate those if you'd like. And what you can do is you can just send that request, is there anyone new online, every single second. As you're sending it every second, one of these times, our sync is going to go on because he wants to check if anyone poked him. The cool thing about this is that if you see here in the red, the date in red is sent from the server. The server sends us their local time. Our local time doesn't help us too much because we don't really know the difference between our local time and the server's local time. That local time helped create that cookie, if you recall. So that 32 bits, if we are checking every second, we can now reduce that 32 bits as soon as our sync comes online. Just by watching that every second, we've got a program to do that. We see him come online. We take that date, convert it to epoch. We just reduced 32 bits. We've now reduced the 160 bits by 44 bits down to 116 bits. That's awesome. It's still a lot. Let's go further. So he comes online. We can send him a message. Well, why not send him to my blog, NAMB.LA, NAMBLA. So you send him there, and then what you do is you just track the IP address. Don't worry, there's no XSS. There's nothing on there. If he's running NoScript or something that's protecting him, there's nothing malicious on my website. So he goes there. Nothing happens to his browser. He sees a really cool blog post about how I did a DEF CON talk and everyone loved it. And what we do is we track the Apache logs and we see his IP address. There's another 32 bits of that cookie. So we're now down to 84 bits from 160. We're basically half, well, it's not really half, okay, bits. So confusing. All right. So anything left here that we don't know, we don't know 20 bits of the microseconds. And we're not going to guess that. There's no way we're accurately going to guess the microsecond that someone logged in on a remote system. You might be able to if you tried really hard, if you got a system really close and you timed things really accurately, but it's not worth it. So the only other thing left here is this random LCG value, 64 bits. What is this? An LCG is a linear congruential generator. It's a pseudo-random number generator. They've been studying for years. It came out like, I don't know, 25 years ago or something. It's older than I am. If they're really well studied and they're really well understood, you can actually look up information on how to reverse them. The LCG use here is actually two LCGs that are combined. So it's a little bit harder and I don't know that good at math. So I didn't understand it too well, but I looked over the code anyway. Now as soon as the LCG or the random number generator is called, it's seeded. The seed basically provides the actual random data that provides every single random number from here on out. Now the seed is critical to the randomness of the PRNG. So let's take a look at the seed function here, this LCG seed at the bottom side of the screen. What you'll see is we do a get time, there's two parts of the seed and it's 64 bits. It's 64 bits of entropy and every random number is also 64 bits. It's split into two, called S1 and S2, they're each 32 bits long. Now S1, if you can see, is this thing called TV seconds, XORed by the ones complement of TVU seconds. What that is is that's the epoch, as soon as it's seeded, XORed with the ones complement of the microseconds that the PRNG was seeded. S2 is the process ID. So let's just take a look at S1 a little bit more. That's 32 bits of entropy we're looking at right now. The interesting thing about this is the microseconds, the seconds that the PHP was seeded was probably when the web server started. We don't necessarily know when that happened, but we can potentially make an estimate. We could also send thousands and thousands of requests to a web server to get it to reset and to figure out when it started. One of the issues is we won't know which requests caused that restart, but we can make an assumption that it happened in the last hour if we send enough requests. Now what they do to make this harder to guess is they XORed with the microseconds. There's no way we're going to know the microsecond that the web server started. But they're XORing the most variable data of the epoch with the most variable data microseconds. The fixed data like what year, what month, what week it started remains the same. Basically it's being XORed, the fixed data remains fixed. So we end up with 12 bits that we can guess. If we know within a 12-day period of when PHP started, and again if we don't we can send enough requests to get that. The other 20 bits is just microseconds XORed with the other variable data of epoch. We don't know that. Whatever. That's 20 bits. We've just reduced 12 bits of entropy in the random number generator. So let's look at S2. Process ID. Get process ID. That's 32 bits of entropy. Well process IDs on Linux are only 15 bits long. So immediately you reduce 17 bits. And if you can execute PHP through any function, if you can acquire, if you can execute a program like PS, if you can hit an Apache server info page or something like that, you get the entire 32 bits. We've now reduced the 64 bits down to 20 bits in the PRNG. We are now at a total of 40 bits of entropy from 160 bit seed. I'm sorry, from 160 bit cookie for every cookie in PHP. That's awesome. But wait, there's more. We can take, normally you think, all right, well we have 20 bits and 20 bits, so that's 40 bits. Well we can actually calculate the PRNG, the LCG value, the 20 bits that we didn't know, separately. Separately means we calculate that 20 bits and then the other 20 bits, that's only 21 bits. We can calculate, with a time memory trade off and code I created on your DEF CON CDs, we can calculate that 20 bits in a matter of seconds, seconds. That reduces the other 20 bits and now we're at exactly 20 bits, the 20 bits of entropy from the microseconds that the user authenticated their cookie. That's a million cookies. On average, we'll be able to log in as in with 500,000 requests, which we can easily do in a day. So I've done it. I've become our snake. So what can we do at this point? Well first let's understand, how do we fix this? Make sure you're running a later version of PHP. Entropy is, I sent this over to PHP and they quickly released the patch. They added some more entropy. Or create your own session values. Use your own randomness. One of the great things about PHP is that it's very fast. It's meant to be fast. So they don't want to, it's also OS, it's cross compatible. So they don't do too much that's very system level. They're not going to access DevU random because that's not on Windows, for example. Create your own session values. Or seed your own random number generator. You don't need to understand crypto. Just use a strong seed that your system comes with. If you're running on Linux or VSD or something like that, use DevU random for your seed. Don't use a process ID. The attack is difficult to execute. It's much easier on social networks where I spend most of my time, unfortunately. One thing to note, Facebook is actually not vulnerable. This is not an attack on Facebook. If you're familiar, Facebook has created their own version of PHP called HipHop. Some sort of mash of PHP, turns into compiled C++, supposed to be much faster. I love Facebook. If you go on there, if you could just plant some crops for me in my farm, I'd appreciate it. So at this point, what do we do? I'm logged in as our snake. How am I going to meet this girl? She's happily boyfriended? I don't know what the word is. So using his cookie, I can now message her as him. So what do I say? Well, here's the thing. Why don't I send her to a malicious URL? Nambla. We're going to attack her network now. So this is your network. This is your network on drugs. We're going to learn a little bit about a network and a NAT here. This is a NAT. So a NAT, what it is, is basically a system that allows you to run multiple systems behind one public IP in a nutshell. All of your computers behind the NAT will typically run on private IP space. This allows you to, typically, your cable modem will only provide one IP address. They use a router which contains NAT software. And that will allow all of your system, all your network devices to run behind the NAT. It also is somewhat of a firewall. It prevents people from accessing services and ports that you have running on your computer whether you know it or not. So when you go behind a NAT and you're running, say, Apache on port 80, no one can connect to you except internally on your network unless you go to the NAT and you enable port forwarding or DMZ or something else. Well, let's talk about something that some of you may have heard recently called cross protocol scripting, XPS. The cool thing about this is HTTP servers can run on any port. This means the browser will allow you to communicate to other HTTP servers on any port. But HTTP is a new line-based protocol. What that means is each line has some data rather than some weird, let's say, XML formatted data or a binary stream of some sort. But there are other protocols that are also new line-based. So what we can do is we can actually communicate with a different new line-based protocol like IRC. IRC is a great place. It's good people. So this is what an IRC connection looks like, just so you can tell really quickly. I tell that to a reputable server like FNET. I log in. I basically say my name is Sammy. I respond to a ping request that they have one and then I join a channel and I find out where I can get WinNuke. It doesn't work anymore. So if anyone has a version that works, please send it to me. This is how we do an IRC client on the web. What's interesting about this is I create a malicious page that has this code running on the page. You visit my malicious web page. Now your client connects to the IRC server. Your web browser thinks it's an HTTP server and what it does is it sends the HTTP request with the post data of my IRC data. Now the IRC server says, well, I don't understand this HTTP request. I don't understand this line, line, line, line. Oh, I understand this. I understand join pound hackers. I know what that means. I'll interpret that. I'll just ignore all your other stuff. And at this point you're getting, I'm making your IP address connect to the IRC server. Now this can be used for SMTP, for example. Spammers have actually been using this for years and years and it hasn't been really well known, but they've been basically making people's browsers become spam servers. You visit a page and without you ever seeing on the back end there's a form that's connecting to an HTTP server on port 25 and auto submitting that form and then basically you're now sending Viagra spam. While you're going to Viagra site, I don't know, but that's what they have on the back. So this is what an HTTP post looks like. You see basically all the HTTP headers that your browser is sending and then you see the IRC data. Again, the IRC server ignores the data it doesn't understand until it hits the data it understands. So I'm going to bring this up. I'm going to talk about something called NAT pinning. Yes. NAT pinning. It's like XPS over times 9,000. So what is NAT pinning? Well, here's the thing. Your web browser was confused. It thought it was communicating with an HTTP server, but it was communicating with an IRC server. So NAT pinning takes this one step further and basically it makes the router also confused and thinks that it's communicating with a different protocol. So now your router thinks it's communicating with IRC, your browser thinks it's communicating with HTTP, and they start doing different things. What can we do with this? Well, let's take a look at a malicious server. That was supposed to say HP. I don't know what happened. So you have your network devices behind your NAT, you have a malicious server that you're going to hit a website, you're hitting a web URL on that malicious server. Now, if you're familiar with IRC, there's something called a DCC. It's basically how porn is sent over IRC. It's great. It's a great protocol. Basically what a DCC is, it's a direct client connection. So when you communicate with an IRC server and you're chatting with all the other really cool people, you say, you know what, I want to send you this file. So connect directly to me. I don't want the server to, you know, there's no point of the server bridging this file or this chat. So we'll connect directly. The way that works is you send a message to the person and you say, hey, I want you to connect back to me on this IP address, on this port. Now, years ago, Routers didn't understand this message. There was just another, it was just TCP traffic. And what would happen is if you didn't have that port opened or forwarded to yourself, then the connection would never establish. People complain, you know, this broke all sorts of things. It broke IRC, DCC, it broke FTP, it broke SIP. So Routers got smart. They started developing software that would actually watch the traffic, look for messages like this, the private message, Sammy, you know, DCC, chat me. And if they saw that message, then they would say, oh, a client on my network is trying to get a file sent. So I'll port forward that port back to them. Well, if you recall, they're assuming that you're a valid client that said, I want to do this. I actually want this person to connect back to me. But you can visit my malicious website and your browser sent this data. Well, what if I put that DCC message in the browser, in the JavaScript submit? I can, now you visit my website. The website submits that malicious form to just some random server. And it says, I want you to connect to me on port 22. And port 80, and port 4 for 3, and 25, and 21, and 23. I've now just port forwarded every port I want to attack you on just by you visiting my website. That's it. The browser has no idea what's going on. It's just filling out its request. And I am attacking you on every single port. Here's the code. It's also on your CD. Have fun. So this is really cool. Now, once the XPS stuff basically became big, the browser started working on blocking certain ports. They said, you know what? You shouldn't be communicating on port 6667. If you're running a web server on there, you're stupid. Choose a different port. So they started blocking ports. Now, the interesting thing about ports is their 16 bits is the size of a TCP or UDP port. Now, if the browser says, I'm not going to allow connections on port 667, does this port match 6667? No. Just overflow it. So if you add another bit, and you add 65,536 to it, you get this bigger number, right, 72,203. Your browser says, oh, that's not 6667. This will go fine. It gets sent to the TCP stack, which then shortens it. And now you have 6667. I did not think of this. It was actually the respectable security group, Goat C security, that came up with this. Very good people. Very awesome, very awesome. So at this point, Anna has clicked on my link. Wow. And now I've attacked her ports. So what did she have open? Well, a lot of OSX systems have a web server running by default. She was working on her website. So cute. So I connected back to her port 80 and saw she was making her own website about Team Jacob from Twilight. I love Twilight. Now I know how to get her. I'm just going to win her over. Here's the thing. I'm actually on Team Edward, but I'm not going to tell her that. So when I see her, I'm going to say, I'm on Team Jacob. So how do you stop NAT pinning? Well, there are so many ways that you want to have multiple layers. So you want to strict firewall, try to make it as strict as possible if you can. If you don't expect people using IRC on your network, block it off entirely. If you don't expect people being able to send stuff, block off. You can actually turn off UPNP and other protocols that allow this type of thing to happen. Client side run up-to-date browsers. WebKit was vulnerable to the port overflow. I believe they're resolved now. Other browsers might still be vulnerable, I'm not sure. Make sure you're running up-to-date browsers. Use NoScript if you're using Firefox. That'll block all sorts of types of things. When I released NAT pinning, NoScript a day later added protection in. Run a local firewall if you can, like little snitch. I mean, really, we all understand security is not just one level of security. You basically have to use multiple layers of protection, like I would with Anna. So at this point, I know what she's into. I know how to win her over, I think. So I'm going to send her a message to go to another malicious website. I'm going to say, you know what? This guy, Sammy, he's a really good friend of mine, he's going to come over and take care of you. Check out his Twitter on Nambla, slash Twitter. So now, the moment you've all been waiting for, triple X, SS. This is awesome. This is actually really awesome. We're going to be talking about geolocation via triple X, SS. So how does this work? Anna visits my malicious site. She then, triple X, SS scans her local network to figure out what kind of router she's running. This is very simple. Here's one example. There's a million ways to do it. Basically, I have iframes on a bunch of different URLs that are known router locations on your local network. I can't access that, but because her browser is on my site, it's now her network that's accessing it. So she's accessing 192.1.6.8 addresses. If any of those addresses work, an onload occurs, which says, oh, I detected a bulk in router. Oh, I detected a Verizon Fios router. And now we know what kind of router she's on. After that, we could log in with default credentials. No one changes their credentials on the router. They're like, who's going to connect? Hey, you need to have a really strong, let's assume you're running WPA, and the only way to connect is either knowing the WPA password or by getting physical access. So who's going to be able to access those internal IP addresses? Well, I can. So can you? So make sure you change your credentials when you have a router at home that has an HTTP-based authentication system. This is not necessary for this attack in many cases. But here's a way to log in to, I believe this is a bulk in router. There's actually a nice list of XSS, CSRF, and default passwords for every major router that you can find online. So in a visit to the site, we figure out the router type. We log in if we have to, which in many cases we don't. And then we XSS the router. And we load remote JavaScript. All right. So what's the JavaScript do? The JavaScript then uses Ajax and connects to another page on the router and acquires the MAC address of the router. All right. Well, who cares? It's a MAC address. What's the big deal? So briefly, what is a MAC address? It's basically every network device on your network has a MAC address, kind of like an IP address. It's in hardware. It can't change unless you're spoofing it. And it's how everything communicates with each other on your land. So why the MAC address? Why do we want to acquire it? What's so interesting about it? I'll take you through the steps. Just bring it. Open your browser. Type www.bing.com in the URL bar. When the search box comes up, type in Google and hit enter. So why Google? Oh, yeah. Because they know everything. Really. So some of you may be familiar with this. If you remember Aaron Andrews, the peephole video that came out. Google. Google Street View. Actually, peephole.google.com, I think. So this is a Street View car. Many, some of you may have seen it. Some of you, lots of you probably know what it is. It's the car. It's the one guy who drives around America taking pictures. He drives down every single street. This is going to be the worst job. Now, we understand Street View is really cool. You can go onto Google Maps and you can see all the different streets, the people flashing the cameras, marriage proposals, all sorts of awesome stuff. What you may have not known is that they're collecting data. Now, recently there was this big thing about Google collecting unencrypted Wi-Fi data. Well, this has nothing to do with that. I assume they don't have any of that Wi-Fi data, which they've already deleted in a lot of places. They're still collecting other, right, they're still collecting other Wi-Fi data. So what are they collecting? Well, as they're driving around, not only are they taking pictures, not only are they mapping GPS coordinates, but they're also looking at just Wi-Fi packets in general. Not the data portion. They're looking at the headers. Now, what's interesting about the headers? It contains MAC addresses, a hardware MAC address of your router. The same device that we acquired, the MAC address that we acquired just with our triple XSS. Alright, so why is that interesting? Well, at Wi-Fi you can detect strength. As they're driving down, they're actually detecting my network at home, Mojito's Mo Problems, if you ever see it. They're driving down the street and they say, you know, I detect a network, it's about 10 out of 100 strength-wise. It must be close. Driving a little further, taking their pictures, like, oh, it's stronger now, it's 50 out of 100. It gets to its maximum, say, 85 out of 100, and then it starts to basically go down. Well, they've just triangulated my position. They're actually not only are they going on that street, but they're going on every other street around it. And now they're getting even more accurate data. And I may see it actually goes up to strength 95 on the street parallel to mine. Now they know that I'm actually closer to that street than I am the other one that was at 85 strength. They are literally triangulating your network. It doesn't matter if you're encrypted. It doesn't matter if you're using WEP, WPA, WPA2. The packets are flying and the MAC address is in there, unencrypted. So, how do we use this to our advantage? Well, Firefox has this cool feature that very few people know about called Location Services. It's really cool. What happens is JavaScript will execute. You can go to a website and JavaScript will execute and it will say Firefox understands this and says, oh, I better collect the MAC address of my gateway and send it to Google and find out where I am. Well, they're smart. They said, you know what? We probably shouldn't do that by default, even though we'd like to. So what we're going to do is we're going to ask the user. We're going to have a little box come up that says, do you want to share your location with this website? They want to do it. You can't take it over with click jacking. I haven't really found any way to basically hack it in Firefox. Other browsers don't have support for it yet. I believe a developer build of Chrome does. So how is this interesting? We can't really access it. They visit our malicious website, but we don't want them to see that and they're not going to click it. Well, Firefox is making an HTTPS connection to Google and asking them for this information. Well, why don't we make that connection? I can write a program on the back end, so when you visit my website, I use triple XSS to acquire your MAC address and then I send it back to my little program running in the background that's not running on your browser anymore. I then connect to Google. I send your MAC address in this post request and it sends back your location, your coordinates. Jack Bauer level triangulation. Now, just to understand how accurate is this, this is an actual router I have exploited and I knew the address beforehand because Anna was there. So I went over there and I did a Google Maps request and I said, you know, take these coordinates and drive me to the location, the address. Let's see how far it was. Driving directions, 30 feet. I looked over the router. It was 30 feet away. Seriously, that's what it said, 30 feet. That's how accurate the coordinates are. I mean, it's on that router that I was exploiting. I think Zuckerberg said it best. Privacy is dead. Thank you.