 So I've been in Mississippi State for a number of years. I got my graduate degrees there and now I'm a research professor. I teach one class a semester, an information security course that I sort of turn into a penetration testing course and a reverse engineering course which teaches students how to reverse engineer malware. I also have a consultancy, the Halberg group where we provide interesting services. And my interests are in vulnerability analysis, exploit development, reverse engineering, forensics, general cyber operations, just the blanket offense of things. I don't do a lot of defensive stuff. That's for other folks, right? So what we're talking about today is operational security for penetration testers or any other kind of attacker, right? So you may be on a scoped penetration test, but generally you have the same concerns here. We're not trying to rip off the grunt here. This isn't, we have to do FTP jail or anything. But generally how to keep yourself safe and how to keep your client data safe during a penetration test. And a lot of these are not just straight bugs. So the ones that I've demoed last year kind of in guerrilla fashion and the one that I'm going to demo today, these are bugs in the tools, bugs in the default installations of them. But a lot of these are just communication and data security issues. So these are things that, you know, the tool was never designed to have a security model to protect against it. So it's not exactly a bug, but it is a problem of how you use it. And you have to take that into account whenever you're dealing with this. We're going to, I'm going to talk to you about how we can kind of illustrate and classify the risk based on these tools, posed by these tools. We're going to look at selection of tools from Cali, Linux and anything and how, while they're great tools and we all use them on our tests, how they might have problems with regards to communication security and data storage. I'm going to provide some recommendations on how to change your practices to better secure these things. And so this talk is for penetration testers and for those of you who hunt penetration testers. How many hunt penetration testers? There's more hands than penetration testers. That's pretty good. I like that. So previously I discussed the vulnerabilities in the Pony Express phone plug. And in that talk, I did warn people that if they were buying Wi-Fi pineapples in the vendor village that somebody might find a bug in them and wreck their pineapples. And then sure enough the next year somebody did. So previously there were bugs in the Wi-Fi pineapple. We dimmed those last year and that was a script running in my backpack off of a small TP-link router and that and a one watt alpha of a non-DBI antenna just walking around autonomously popping these things. If you buy me a drink I'll show you the code for that sometime. But generally it was a PHP authentication bypass where the authentication was being done in the footer of the PHP code for some reason. But in general when we talk about this it's not just physical devices. It's not just toys that you buy. It's the entire body of the tools that you're using that are software based. The processes that you're using, your standard operating procedures and essentially how you're handling data security. You have a lot of very valuable data as a penetration tester. You sort of embed yourself in an organization, extract out a bunch of stuff. You generate a report on it. You embarrass the hell out of some people when you give your presentation on it. But because that data is incredibly valuable. It has to do with it's going to be personal information. It's going to be trade secrets and things like that. So the value of the data that you're handling is very high. But the awareness and understanding of the risks and vulnerabilities involved in these tools is fairly low. So we kind of understand how to figure up risk for a normal business and everything. But it seems like the training and the books and the material that we use to train ourselves up as penetration testers. Those tools do not, or those training and material does not cover how to do it safely. You know, the first thing you learn how to do is net cat a shell from a compromised host to yours. And a plain net cat shell is, you know, that's tell net, right? I mean, that's basically the worst you can do. And this is counterintuitive. So you expect, you know, being a good penetration tester, you expect to be the smartest one in the room or the smartest one on the network. And chances are you're not. You're a presumed expert of the offense, but you're not mindful of your own security. You're not mindful of your own defenses. The reason behind this, again, as I said, it's the training. So the training material is focused on getting, you know, the lowest common denominator as far as minimum prerequisites as possible into a training program to get them to the minimum point that they need to start operating as a penetration tester. And so there's no time in a one-week course to spend on operational security or how to wrap things around into encrypted tunnels and things like that. And so a lot of these things, they don't test this in the certifications. They don't teach it in the classes and they don't write about it in the books. But, you know, as the field matures, and hopefully it will mature, right, any day now, you know, we'll, we need that. We need to have, we need to treat that data more securely. The tool chain. So, you know, I love Cali Linux. I use it. I use a lot. I use pretty much all the tools that are out there, you know. But it's not a solid tool chain as far as end-to-end usage or consistent usage with regards to security. And there's a lack of documented incidents. You know, there's, there's the one last year with the Wi-Fi pineapples at DEF CON, right? But how many stories have you heard about penetration testers getting popped? You know, there for a while is, you know, anti-sec type groups, ZF0, I miss those guys, right? Y'all? ZFO? Too young? Oh my gosh. Okay. So there's a lack of documented incidents of actual offensive security people getting hacked. And so it just isn't a concern for many. So the idea here is when we lack the capability to understand our own tools, we operate at the mercy of those that do. And so a lot of these devices are a classic example of that. The tool makes it easier for us. The tool automates the process. The tool enables somebody who doesn't already know how to do these things to do these things. But the problem is without the underlying understanding of what is involved in doing this thing, such as man in the milling or Wi-Fi connection, without the fundamental understanding of that and sort of all the issues and all the ins and outs of how you're interacting with that device and what the other people on the network see. Without that understanding, the people who do understand that are just going to wreck it. So to talk about this, we have to make assumptions about what a reasonable attack is. What a realistic attack is on this. And so a lot of times the attack surface for penetration tester is not seen as something that's a serious vulnerability. A lot of times man in the mill attacks are kind of given short shrift basically. They're not seen as the most serious. It's not like I can hit you over the public internet, know your IP address, run MSO 8067 on you and pop you. I have to be in a certain place at a certain time. And so those kinds of attacks are usually seen as being less severe. But, you know, in the case of the penetration tester, it's not exactly the least realistic thing in the world. There's a good chance that if you or as a penetration tester are capable of getting into an organization remotely through whatever means you used, there's a good chance there's another guy already there who's not a penetration tester. And that individual might be able to compromise you in the same sort of network domain as that. So the assumptions here for this work is essentially that an attacker may operate with the sophistication skill and resources that exceed that of the targeted pen tester. So the idea here is the bad guys are better than the good guys. And that's usually a pretty safe assumption, right? The idea behind this work and presenting this is that we may can repair this in and out. I believe if most penetration testers were aware of this sort of thing, then they would naturally try to work towards being mindful of this. Because it doesn't take a whole lot. And for the sake of, you know, addressing the man in the middle type situation, we have to assume that an attacker can be positioned physically or network wise convenient for the interception and modification of traffic. And so if you're launching a penetration test across the internet, there is no telling how many hops between you and that target. And each one of those hops represents a point at which somebody can intercept that, somebody can change that. So man in the middle may not be a general script kitty thing, but an advanced attacker, one that is at least as skilled as the targeted penetration tester, this is something that's reasonable. And the value of the data makes it worth doing for an attacker. So the penetration tester is going to have multiple clients. They're going to be doing this over a long period of time. They're going to be going very deep into organizations. So the payback for compromising that is that you get to ride along with them. You get to ride along with them on future engagements if they're purely wiping things. So the goals here, so basically the goal of doing this to somebody, so the victimology of this, who are you targeting here? As an attacker, I'm generally either targeting the penetration tester or the clients themselves. So for the penetration tester, you know, it's a business just like any other. So they have business sensitive information, you know, compromise that. Sabotage, embarrassing leaks, ZFO type things. The clients really the cool one, though, I think. So if I pop a penetration tester, then I have access to all of that client sensitive information, the vulnerabilities that are in those systems, and I can probably gain persistence in those systems as well. And what's more, if I'm in a good situation and I'm really, you know, on my game as the bad, bad guy attacker, I can modify things in this penetration test. Maybe it looked like to the penetration tester that the exploit didn't work when in fact it did. And I stole it. Or perhaps I'm just stealthy and I just collect all this information. And so this is either an attacker attacking a penetration tester, an attacker having a specific client in mind for this, or simply riding along for a series of these, a series of these engagements. So this is attractive. Targeting a client like this is way better. So even if you had the same vulnerabilities as the penetration tester, all the same vulnerability information, all the same exploits, this is very attractive to the tester because the penetration tester, they exist outside the client's culture and structure. So this can help you get in. Instead of having to deal with the help desk or the IT folks or anything like that or the normal ways in, dealing with the penetration tester, compromising that is an alternative route. So this is somebody who exists outside the culture and structure of the organization, but winds up with ridiculous amounts of access to the system. They break technical and policy measures by definition. So their job is to break policy. Their job is to break past all of these measures. So if you're riding along with a penetration tester, you can do all those things too, and it's not seen as strange. And so ride along with them. You can steal tools and techniques. So the assumption here is of course that the bad guys are better than the good guys. And that anything that the penetration tester might have is probably not as good as what the attacker attacking them has. But you know, some people show up to extra money for private exploits, feeds of vulnerability information, commercial tools, dealing with licenses, things like that. And you can hide bugs from the testers. You can modify the results of the test. And it just acts as a smoke screen. So you're coming in with somebody who's probably very noisy, probably triggering every IDS alert around there. And so you can avoid doing that yourself. The OPSEC issues here. So talking about some of the issues that you might have. So you're taught to find bugs or find known vulnerabilities in systems. Then you go out and you research where the bugs are. And you download those exploits and everything. So we all know about backdoor exploits. So that's pretty common, right? The shell code is actually a thing that spawns a shell on your system. You know, any time there's a new zero day, there's fake exploits that compromise the person that runs them. The payloads for these exploits, a lot of times if it's a memory corruption exploit and it's actual shell code being loaded into the system, that shell code is rarely annotated. I mean, you can. You see some people who are really good. They split off the strings down and they have the common and assembly language off to the side. But you don't even know if that's what it assembles to unless you're really sharp or you load it up into IDA and see what's going on with it. So those payloads are very rarely annotated. The people who are using them are not equipped to evaluate them. So how many penetration testers do you know that are very sharp with assembly language? Not a whole lot, really. And how many of those take the time to disassemble that code and make sure that it does what they think that it's doing? So the comprehension of that assembly language is important. Most of the time, if you're requiring a standalone exploit, you're doing so in desperation, right? There's no metasploit module for this one. Uh-oh. So you just try to find whatever you can. And you're just happy when you find something. And wielded without discretion. So you're just so frustrated about getting into the machine that you launch these things without really thinking about it. Maybe it does the attack. Maybe it doesn't. Maybe it does the attack in a little extra, right? So each encoded string and payload part of the exploit represents code that the penetration tester has to either fully understand or place trust by association with its source. And I'll talk about exploit DB in a little bit about that and anything. And that's a pretty good source, pretty trusted source for exploits. But the way we interact with it, it might be an issue. And this trust decision, it's forced. It's forced. You have no choice. You either succeed in the test or you don't. And so you're forced into this decision on code that you don't understand by lack of training and skill and programming, vulnerability analysis, exploit development. And that lack, that's something that penetration testers don't get into until some very advanced classes, if ever. So from an early draft of the paper that I submitted for this, at the time when I wrote it, exploit DB, the most popular way to get standalone exploits, it operated over a plain HTTP normally. The way Cali pulled updates for it was over plain HTTP. And so a man in the middle could rewrite and replace that code. But that is no longer true. You go to exploit DB now. It's HTTPS by default. As far as I can tell, I haven't played with Cali two yet, but the most recent Cali scripts and everything seemed to pull it down over, pull down updates over the app servers. So that was a lot more secure than just running a bogus script that pulls over HTTP. So kudos to exploit DB for this. It's a lot safer to get exploits from them. Then your trust is not in the network between you and exploit DB. It's with whoever is vetting the code there. And so you still really should understand what you're running there, but you're a little bit safer there. And exploit DB has done all they can, right? That's their job. So with the exploitation of the system, when you're running an exploit against the system, how do you compromise a system without, quote, everyone, everybody in visibility knowing how you compromise that system? How do you establish, how do you trade that secret sauce of exploit code and payload with that unwitting system without everybody knowing how you compromise the system? And so there's mechanisms for securing your communications after you're on the system, but that initial exploitation, it's like Alice and Bob, but Bob doesn't even know that he wants to communicate, doesn't know that he's about to communicate. How do you establish secrets with them? And even if you do have a good secure payload, how do you keep it from being modified and transit? And the answer to this is who knows, right? Basically the idea here, as far as I can tell, is to exploit the target as close to the target as possible to reduce that exposure. So ship an appliance to the client, VPN into that and launch your exploits from that. Now it's not as realistic of an attack as simulating an APT against an organization, but it's a lot safer. It reduces the exposure. So Metasploit is the gold standard on this. The most versatile free payload that you could ever find for any exploit is Meturpreter. I love Meturpreter, it's great. Since 2009 it's supported encryption and this is not something that I've done a whole lot of research into, although I have been privately shown some shots of tools that can intercept and Meturpreter shells and things like that. There is encryption in there, but you have to wonder how are the keys, if you're establishing the keys, who entered those keys established? It has to be after code is executing. So there's this whole stage of setting up everything and setting up code execution before Meturpreter ever executes. And so this encryption, this is mostly a for evasion. It's to prevent IDS signatures from tracking in on Meturpreter packets. But otherwise, how do you secure this? And I'm not a crypto guy, but maybe somebody smart can figure that one out. Extending the network, if you're a physical penetration tester, you're going on site, you're dropping your Wi-Fi pineapple, your phone plug, your land turtle, whatever it is that you're going to drop on this network, you have to be very concerned about extending the network. Our university IT folks get very nervous when I or other employees extended the network by adding switches, adding routers, adding interesting devices they don't know about. Every time you do that, you're adding to your attack surface. And so any kind of rogue Wi-Fi that you're setting up, you're probably trying to lure people in on open Wi-Fi. You're not, there's not much good in you setting up something WPA2 for them to connect to. Cellular data, that's probably about the safest way to have some back channel into the network, SMS, that's pretty good. But more open things, easily accessible things like rogue Wi-Fi and extra network cables running around, those might open up attack surface and intercept opportunities for an attacker. And so that kind of goes back to the Wi-Fi pineapple bugs. When we talk about data at rest, so there's all sorts of data that's being stored in the process of this. You know, I like to record engagements. I like to take lots of screenshots for the reports afterwards. You only do one or two engagements where you don't document things as you go and you think, oh, I'll write this up afterwards. And then you have to report on everything that you did and you've forgotten and you didn't take screenshots and you have to do it again. You only do that once or twice, right? And so you're storing a lot of sensitive information about a client. And so where are you storing that? Are you storing that on your end point server? Are you storing that on your Kali Linux VM that has the default root TOOR password? Are you storing it on an encrypted volume? You can set up this stuff securely, but it's not necessarily secure by default. Are your implanted devices storing sensitive data? Are those devices physically secure? Are you encrypting the data? Are you encrypting the volume and who has access to the keys? And when do you delete the data? So that's important. If you are going from engagement to engagement, you're not wiping the system. You don't have a stock penetration testing build. You just have your pen testing laptop that has Kali installed and you have your array of devices. And whenever you're done with one engagement, you are MRF the folder that has the client data, hopefully. Well, you know, you can recover that later. So maybe it's not secure. Maybe you don't delete it all. Maybe you archive it all so that the next time you in six months come back, you still have the old information. What do you keep and how long do you keep it? And point of contact. So you always have your get out of jail free card. You have your emergency contact. So crap, I knocked over the main server. Sorry. You know, they're losing money constantly until it's back up. So you have that emergency contact in there that you call when you get into trouble or you get them into trouble. You know, so this is how you set up the scope of a test. This is how you deliver your report. You know, these channels need to be secure. You don't need to email the pen test report over plain text email, obviously. But are you going to teach them how to use PGP? I don't know. So you go and deliver it by hand. So classifying the tool safety, this is the first slide that actually has color in it for those of you watching on the TV. So classifying tool safety, I went through just a small sampling of tools in Cali and sort of intuitively ranked them on terms of how safe they are. Now, these are not saying if this tool is red, dangerous, do not use it. Obviously do not. Use whatever you need to do to complete the job. But you have to be mindful. You're going to have to wrap security around these things. So something that's dangerous is something that may cause vulnerability. Either it has known vulnerabilities or the communications it has are clearly subject to interceptor modification. And then yellow sort of caution, things that defaults lead to a dangerous situation, but it's very easy to configure this thing to not be insecure. Or things that are essentially naturally safe, safe for normal use, safe for its normal configuration. And then sort of there were tools that didn't really fit into this model that were not exactly pen testing tools, but things that can assist in improving the security of the other tools. This kind of classification is not perfect. It's not a formalized model or anything like that. And one thing that I did not take into consideration is how saved results are stored. Because so few penetration testing tools make any attempt to save the data in a secure way that we just don't even consider it here. It's just down to you to use encrypted file systems. And if you're using a small device running off a battery that can't really cope with an encrypted file system, I don't know what to tell you. So here we've got, this is reproduced in the report, in the paper that's on the disc. So don't worry about reading this very carefully. I just wanted to put that table in here to show you basically the idea about it. The top one there is one of my favorite tools, beef. But a lot of times your encrypted, your hooked clients on beef are all communicating with the server over an unencrypted HTTP. I can't figure out how to change it. I'm not that smart on using it. So perhaps there is a good way of changing it, so that'd be fantastic. But by default and by every normal configuration, they're communicating unencrypted with your server. And this may not be an additional concern in some situations because you acquired them over an unencrypted channel, but you're also now doing more things with them than the web application you originally did. So you have to be very careful with software like that. And then some of the other tools like SQL Ninja, Durbuster, things like that, those are not necessarily opening up a vulnerability, but they are leaking data over public networks and things like that. So you have to very use those with care. And then finally, if we go down to the one naturally safe one on that table, NCAT. It's NCAT, but with SSL support that's just very easy to use. And so use that instead of NCAT, right? No reason not to. All you have to do is set the certificates for it and you're good to go. So here we get to implantable devices. The toys you're buying in the vendor village. So the two years ago, and I typoed that, so that's supposed to be DEF CON 21 there for pulling the Pollen plug. But in DEF CON 21, I released a series of vulnerabilities in the Pony Express Pollen plug. And that was an interesting thing where I triggered, I used a crafted packet to trigger a cross-site scripting vulnerability in the web interface, which then injected our cross-site request forgery to form, to inject some commands and just wreck the whole thing. And at that point, I have a nice little Pony Express root kit going there. Last year was the Hack 5, Wi-Fi, Pineapple, Mark 5 vulnerabilities. And that was an authentication bypass in the footer of the PHP code. They have improved that device remarkably over the past year. They patched that, they patched a few other vulnerabilities. They have, they even got it into a thing where they developed a secure way of setting up the device because you were just kind of sitting out there and open until you could really quickly push all the buttons to configure it the way you wanted it before somebody came in with Pineapples.py, right? And so one thing that they did for a while is they had it where you had to punch in a sequence of lights that were on the device blinking. You had to tell it what the pattern was. And it turned out that was easy to brute force. So now you have to set dip switches on it in a certain sequence on the firm, in the boot up sequence to actually set it up. So you can't own the thing until it's fully configured. So they've really worked hard on getting this thing up and going good. There's a new, there's a couple of new vulnerabilities. Catatonic in the Wi-Fi village has a new O-Day that was patched in the latest, not the latest, yeah, the latest version of the firmware. He's going to talk about that. He has a really cool network based worm that's pretty cool that he uses to demo this. And today I'm going to demo a very simple communication security man in the middle attack against it. The clone devices, so there's lots of things that you can buy that have the Wi-Fi pineapple tools ripped off and put in there. Those are way worse. They don't get patched. And so those are bad. You know, stuff that uses some of the Pony Express code. They don't get updates. It's a single user's project, a single person's project and they need to abandon it immediately, right? And even the older devices, the older Wi-Fi pineapple devices don't see updates either. And so any bugs in those are likely to remain there. And so there's inherent problems with these low powered devices that you have to be careful about because they're not doing things like defaulting to SSL and things like that. And they don't, they're trying to conserve the power instead of using it to really lock stuff down. So here we have some new pineapple stuff. Y'all hunt pineapples. That's the URL. I actually released this yesterday so that folks could go on hunting expeditions. This, so the network situation was getting kind of rough so there are a few of them popping up and so I released that. So I'm not running around with a backpack, pack manning up Wi-Fi pineapples like I did last year. That's y'all's job now. So the script that we have on this site is not completely weaponized. It demos it and I'll show you what it does here in a second. But it doesn't, it doesn't autonomously seek and destroy and the payload is just adding a user so you can SSHN. So modify the code to do as you please. And use the Y'all hunt pineapples hashtag to report your successes so that we can all point and laugh, right? All right. So we're going to demo this so we can't have nice things, right? That's not the right password. So we can't have nice things because I can't turn on my Wi-Fi pineapple up here without one of you hacking it before I get a chance to demo it. So, so, so Sergey dancing distract them while I then hook this thing up via wired. So right now I have a wired interface to the Wi-Fi pineapple that's sitting directly under me right here. Trust me, it works across the interfaces so the idea is with a Wi-Fi pineapple you've got a couple of wireless interfaces, you've got a wired network interface. Logically, you have the WPA2 network that the operator is configuring the device over and then you have a open network or a series of open networks that's bringing in victims and you have a wired interface that can have an uplink or that can be your management interface. All of these interfaces are bridged together and everybody on every interface gets an IP address on the same subnet. So it's trivial to ARPS these folks and so we can take a quick look at the code for that. And so basically if you go and grab it you get this and you get some information on how to use it, some places to put in your automation and everything. And so the idea is we set up the ARPS spoofing between the pineapple itself and the operator. We're doing this from the open Wi-Fi interface or from any interface on this. We make sure it's a Wi-Fi pineapple, not the official DEF CON network which I don't advise playing on. We ARPS spoof them. We sniff for the session cookie and CSRF token which is static across the session and we use that to insert commands. And so it all happens very quickly. And so we've got the Wi-Fi pineapple. I'm the Jackass here trying to spoof network for everybody. I'm not actually doing that. So here I am playing around, laughing at people at Starbucks. And then on this side, hopefully I still have, so I'm a victim or I'm a bad guy who's pretending to be a victim and I'm on the same network. I want to figure out who the operator is. And so the easiest way to do that is to do a broadcast ping out to the broadcast address and see who responds. And so there's, you know, cleaner ways of doing this, but whatever. And of course, 131 is the IP address of the operator. If you have multiple people responding, just go with the lowest number once. The first guy there, that's going to be the one. And if we run y'all hunt pineapples with no information, basically it gives us usage. Give it an interface, give it an operator IP address. So, y'all hunt pineapples. ETH0 because we're going over the wire, right? Boring, lame. All right. But now we're going to target the operator. And this happens fast. I'm telling you. And it's the end. We're in. Boom. All right. So to recap the output from this thing, basically it figures out what its gateway is. This thing looks like a pineapple. It looks for the Wi-Fi pineapple logo, right? It's like, yup, okay. Trying this. It looks like it turns on IP forwarding, sets up the art poisoning, looks for the cookie. The thing is this is an Ajax interface. There's always stuff going on back and forth between the web browser and the pineapple itself. They don't have to be interactive. They just have to have something up. And so immediately it finds the PHP session ID, grabs the token, and then tears down the IP forwarding and the ARP spoofing because it doesn't need it anymore. Runs the payload which basically adds an R00T user to the device and then sets you up with an SSH connection to it where you're in. And so we're root. Fantastic, huh? And from here, you know, you just destroy the thing or something or leave a nasty message. My favorite payload is that somebody has done is that they've turned off IPv4 support so the person has to start learning IPv6. That's good. Be creative. Don't be as mean as I was last year. That was pretty rude. All right. So that was my demo. My recommendations for this, you can tell that this bottle of N-acids is mostly empty, right? So the idea here is just check six. You know, be aware of your network situation. Be aware of where you are and what you're transmitting and how valuable that information is versus the likely skill level of the attacker. Test your tools and exploits before operational use. Have yourself a virtual network of ESX server or something that you do this stuff in. Don't just throw things at a client that you just downloaded. Reverse engineer those exploits. Figure out how they work. And if you don't know how to do that, then learn. Be aware of that exposed information and know that target environment. Minimize it as much as possible. Take care when you're extending networks. Keep the client data safe both at rest and in transit. Archive the data securely. Delete it between engagements. You know, it's tending to keep it around, but unless you can be sure that you do it securely, maybe just delete it. And secure that communication with a client. Don't just turn in that report over plain HTTP or plain email. Stay alert. And as a community, we have to improve the way we train penetration testers. We have to improve the education and instruction on this. So you have penetration testers that have the capability of doing this. And so post-exploitation, you need to have a focus on establishing those secure command and control channels and exfiltration. It can't just be a net cat shell anymore. So the contribution and hopes and dreams of this. Reduce client exposure. Improve tools and training. And the maturity and advancement of penetration testing is a profession. I'm not holding my breath on that, but maybe you could give it a shot. I'm not telling you to do shots. That's a little early for that maybe. But take a shot at improving this. And so Wes, do we have time? Yes, we have time. So how about you talk to them about the land turtle as a bonus? So Wi-Fi, it was the hack five guys, the creators of the Wi-Fi pineapple. They have a new device that I actually kind of like. It's called a land turtle. And it looks like a USB to ethernet adapter. And it presents itself as one of the computer. But on the ROJ 45 end, it's a separate interface. And in between, you basically got the guts of a Wi-Fi pineapple without the Wi-Fi. It's managed over SSH. And so that's pretty cool as far as the security of its concern. And it basically gives you man in the middle and persistent access on the network with a very small device. It does a lot of the same things that a pony express device would do, but 50 bucks, right, instead of a lot. And so definitely, you know, I highly recommend picking one of these up because they seem like a whole lot of fun. But the day this thing came out, of course, I'm like, I hunt land turtles. So I was on my phone, I was in a meeting. And so I didn't have my computer on me. And so this is basically the process that I went through looking at this thing when it first came out. Don't have one. I just bought one yesterday. I hadn't even plugged it in. Find the website. Okay, that looks cool. And so that's the device there in the do not remove part right there. Google up the land turtle files, GitHub. And basically this was like the delta between the base installation and like the land turtle, not just like a full firmware image. Dive down into user bin turtle update or whatever it was. And so the update script for this, and this is where it first place to go, right? Immediately we see it's running over HTTP. And what it's doing on that secondary you see is it's grabbing a dot update file and then piping it to bash. And so this kind of gets a little bit scary right here. This is where things get a little sketchy. And so I was like, okay, what's in that dot update file? A script for updating device. So the update process grabs the new update script which then updates the device. And this update script has information on like the hash values and the location of the thing. This gives them a little flexibility on the update process. But in general this is a very, very scary way of doing it. And a lot can go wrong here. So for starters, they know about this problem. When I told them about it, I just dropped it right there on Twitter. And they were like, yeah, this is issue number one on our tracker and our dev environment. We didn't have SSL. And so that was why it was like that. And it's going to be fixed in probably the next revision. It's still a little scary, right? So you've got this HTTPS server that's serving you up a script that you just run. I was talking with them a little bit. I think there's probably some way of having digital signatures for these things instead of just like verifying hash values that you're getting from somewhere. There's probably a way of signing things on these devices that would help out with this. But then how do you update the ones that are already out there? They're just going to have to be, you know, Jesus take the wheel moment there where everybody has to just trust one update. And so that happens a lot in penetration testing, right? Jesus take the wheel. And so it's scary, but it's actually a really cool device. There seems to be a lot of focus on securing these things and giving me a hard time and anything with their each individual update. But they're good guys and it seems like this is a really cool device and I'm looking forward to playing with mine. But that's it. So I'm going to be around around. So as far as questions are concerned, I'm going to be trying to get off the stage pretty quickly, but follow me around, ask questions. There's also a paper on the CD. So this is my contact information with GRU Security on Twitter. Hit me up. Ladies and gentlemen, please exit out the rear doors only. Thank you.