 I'm Sebastian Kinnah. I'm Darren Kitchin. And to reverse that together, we form the power of Wi-Fi panel. Goodness, hack five. Hack five just turned 10 years old on the 5th of August. That was pretty insane. So if anybody can tell me the name of the original theme music, they get Freeland Turtle. Yeah, I didn't think so. So what we're going to talk about today, we do a little pineapple primer. For those of you who aren't familiar, we're going to quickly recap the changes in the Wi-Fi landscape as this is a game of cat and mouse that we're continuously enjoying. Going to talk a little bit about Pine AP, the success of that, what we've done to make it better, some of the new features. We're going to get into a little analysis of some of the captures that we've done with that. And we're going to talk about security. And then we're going to talk about the future of the fruit. So what is the Wi-Fi pineapple? It's a rogue access point. It's so many things. It's a Pentes pivot box, obviously. It's most known for its intuitive web interface. You know, the way that we just basically package up these tools and make it simple, because like, OK, sure, you may know all of the esoteric, tac, tac, p, colon, underscore. That's cool. Don't get me wrong, I love that. Sometimes I just want to make it do the thing. With that, what it does best is it's kind of most known as its first rogue access point feature, again, the Pine AP Suite. And that what that provides is, being a rogue access point, says like, hey, I'm really interested in collecting clients, but why? Because that's only one step of the game. And the idea is to poise yourself on the network as the man in the middle, much like Comcast is at home for you. We also do really well remote management out of band, which is a lot of times fun, especially if you're using this as like a pentest pivot box. Drop it on an organization. Get a 3G signal out that leads in with pentest pivot. And of course, the extensible platform that we've built that a lot of people have contributed to in the way of infusions and whatnot. So really trying to build a platform that's as easy as possible to develop for. And we're constantly amazed when we come to DEF CON and we hear the stories of the esoteric things that the Wi-Fi pineapple is being used for. So I love that stuff. It's not space, dude. He's used to more, not less. Sorry. Yeah. So anyway, our mission is to create simple, affordable, and effective tools for the penetration testers, the systems administrators, the geek meteroids. And quite simply, our philosophy is make it do the thing. Those are turtles. Seb, you want to walk us through the Wi-Fi landscape and how it's evolved? So hopefully most people here are familiar with the karma attack that used to exist before. Yeah? No? Wow, two people? That's three people? Four people? All right, okay, that's better. Right, so there used to be this thing called, or there still is, but there used to be this thing called karma. And the way it worked is basically that your wireless devices would search for a certain network and say, is my ACME Wi-Fi around? And all that karma would say, or the pineapple in that case would say, is yes, I am. And then the connection would be made. So that obviously doesn't work well anymore. Well, it worked really well for its time. It worked the same way that, say, the mirror in Harry Potter worked, which was you look it in and you see what you want to see. So if what you're looking for is linksys, you're going to see linksys. And what you're looking for is coffee shop wireless. You're going to see coffee shop wireless. But that doesn't necessarily the way that devices work anymore. Before we go any further, of course we need to real quick touch on some real basics of Wi-Fi. Mainly the management frames those are the things that we're most interested in. And that's what allows us to do some fun little tricks. So beacon frames, there's only one type. They're just beacons. They're just little advertisements. They're like billboards on the side of the road. So that everybody can see them and say like, hey, come over to here to this place. Probes come in two forms, probe requests. Again, I'm looking for linksys. I'm looking for that coffee shop. And of course the subsequent probe response, which would be I am that linksys or I am that coffee shop. And the probe response is actually very similar to a beacon. I think there's only a few hex values that are even different in the packet. It just basically says like, here's the modes that I support. Here's my encryption standard. Here's all the ways that I like to do things. And then there's either creating the relationship or destroying the relationship. The association and the authentication and likewise the disassociation and the deauthentication. And those are just packets that say, let's be friends or GTFO. Okay, so Karma worked as I said before because it's convenient. You want your device to turn on. You wanna open your laptop lid and you want to automatically connect. And before that was done because you were probing for your PNL, your preferred network list. Most devices or a lot of devices, surprisingly some have reverted what they were doing but we'll get into that later. So a lot of devices they probe to broadcast now versus for probing for a specific SSID. So they won't ask for Acme Corp anymore. They will ask for broadcast and then every access point responds and then they can pick from the access points that they want. So that pretty much thoughts the entire Karma attack, the way it used to work. And it's because of Karma and Karma success that this whole landscape has changed and vendor implementations have changed as such. And it changes the convenience. I mean, as we know, like, convenience and security are constantly at odds. It's obviously faster if you know the access point you want to directly query it and say, like, let's be friends instead of like saying, is anyone out there? And waiting around. And so what it does is it means that the landscape is more like a game of go fish now. Where it's like, hey, are you still there? And then of course that varies by the vendor's implementation but you kind of have to know ahead of time what may possibly be in that device's preferred network list. Right. And not only that, the variation in terms of how these things are implemented is so different from vendor to vendor. So for example, some devices will still probe for the network they want but if they do not see the actual beacons but only see probe responses or association responses, the requests or responses in that matter, the access point will notice it's not a real access point and it'll actually blacklist that. So it'll not connect even though it's probed, it got a response, it'll say, okay, well, you're not a real access point. So there's that. Then we have devices that just probe to broadcast as we were saying. Then there's devices that have both of that. Some devices we'll get into that a little bit later again but huge range in the implementations and some are more vulnerable than others and some are very locked down. I don't know, black phone, if you guys know that, you should. They changed a few things lately and it's awesome and it protects you against these type of attacks. So in this ever-changing Wi-Fi landscape would of course as a Wi-Fi pineapple to do which led us to introduce the PineAP suite which extends on karma because karma was great at just saying yes. Anybody here recall the code name for the project before just Wi-Fi pineapple? Like guys fight over the land turtle, totally missed. You can't throw. Okay, right, so. So that led to building an entire suite because there's lots of other ways that we can basically make the honey pot sweeter. Karma is just like a hook and just like hanging out in the pond and PineAP is like a hook with a worm on it, if you will. Right, so as I was just saying, basically devices don't start probing for their PNL anymore. They are probing to broadcast and it's hard to now know what they're probing for. There's different methods of getting the PNL of devices or getting the best guess that we know. The way we do it is we do it over something called SSID harvesting where we take all the probe requests and all the beacons that we see and we memorize them. We consort them, we have a database for them and we can then see what devices would probably respond to what SSIDs. And we reinforce that by doing beacon injections which is basically just we're beaconing out that we're at this access point. So we're actively saying we are this access point because we've seen other devices probe. The reason why that works is normally in a certain location, you or a certain site that you're working on is going to have devices that are differentiating in terms of who, sorry, the manufacturers, the policies that they have implemented. So you're going to be getting some overlap in terms of what SSIDs they're looking for, what APs they're looking for. So that's what beacon injection is. And then beacon response is actually something quite odd. It's kind of an anomaly here. You can send beacons, normally beacons are sent to broadcast. You can target a specific MAC address with them. You just switch out the MAC. And what happens is most devices will just ignore that frame because it's not meant for them, right? So they don't care, they ignore the packet and they won't show it. So it won't show up if you look at your phone and you look at all the APs that are around you, you're not going to see the ones that are not targeted towards you. So I was saying the vendor implementation where the vendor requires beacons to be visible before it will actually associate. So you have to be actively beaconing what they're looking for. The way we do that is we actually send them targeted so that when you look on your phone or at least when the normal clients that are around, when they then look at their devices, it doesn't seem obvious. Obviously the packets are there. So if you use Wireshark or wireless IDS, this is going to throw up a lot of red flags and we'll talk about that a little bit too. But yeah, what do you want to add? Right, and then recon mode, which is basically a, and we're going to expand on that more in a bit, but basically it's part of the suite that allows you to visualize the wifi landscape, which aids considerably in targeting and filtering and making sure that you are auditing just the access points and just the clients that you're particularly interested in. And so it's kind of like a front end to a lot of the features of the Pineapy suite. Right, and that's a quick overview of what we implemented. We gave a poll talk on that last year. And then the idea there is building the recon mode. The idea was to give you a landscape so that you're not just turning on the pineapple and turning on karma, which was pretty much, I mean, this is the revolution we're in like the fifth iteration, the mark five, you know, the original is just like on and off, right? You turn on karma and like, well, there goes the neighborhood. And now we don't think that's really the best way to use the tool. So we've set it up in such a way where you can actually specify filters. So there's allow lists and deny lists and you can do that based on SSID. If you're only interested in a particular access point, say everybody in the company associates with this set access point or the company is across the street from a coffee shop where they use that set access point, you can filter by that or by the MAC address. So if you're contracted to just target the CFO, you can get the CFO's MAC address and make sure that only he can connect to or he or she can connect to your device and allow you to do that man in the middle attack. What's also really interesting here about the Pineapy suite is that not only are we able to set targets, as opposed to just broadcast, meaning everyone, we can actually also set the source, which is kind of novel. Right, so again, this is something that we can do because we're just injecting frames. We can take any type of pineapple, so say you have multiple pineapple set up in a certain vicinity and they're connected in one shape or form or even if they're not, you'll be able to set the source to one pineapple. So say you want to use five pineapples around a certain site to tell clients to connect to one pineapple, you can do this by changing your source, making it seem like it's coming from the original, the one pineapple you're using as a collection and as the actual access point, which might be providing internet. So you can actually couple pineapples that way. And then we can of course set it to use different intervals and we'll take more about that later, but basically it's speeding up the attacks and being more just saturating the airways more with these kinds of attacks. And actually on the interval thing, 802.11 is expressed in things called time units and it has to do with the maths, but really when it comes to 802.11 are really a lot of wireless protocols. Timing is everything and with Wi-Fi everything's done in microseconds, but we learned this in particular while we were hanging out in San Francisco at three in the morning, camped outside of T-Mobile to be the first in line for some god awful reason to buy the Nexus 6. I don't recommend hanging out on Third and Market in San Francisco at three in the morning, but we did learn that there's security that patrols this one particular building that had scaffolding all around it. They were doing some construction. Security guard comes out on a set interval and then this random tweaker shows up and in our hoodies we literally have mason tasers ready to go and he's like, hey, will you watch my bag? So we didn't really wanna watch this random guy's bag and we're like, well, we'd prefer not to and he just drops his bag and says, all right, cool. Drops his bag on the side and then like a spider climbs that scaffolding up about, I don't know, 12, 16 floors, something like that, climbs up, cuts a hole in the tarp that's covering the window I suppose and climbs in. What? So climbs in and on his way out, well, at some point, spends five, 10 minutes gone. We're thinking what the hell is going on, but just focus on just ignoring this. And security guards know where to be seen and then he climbs back down, doesn't seem to have done anything, but he climbs back down and grabs his bag and comes up to us and just goes, dude. And we're like, okay, I guess I have to fist bump because I don't know what he's gonna do next. And he goes, timing is everything. And at that exact moment, the security guard shows up. Okay, so with 8 or 2.11 time units, they're roughly 10, 24 microseconds. It has to do with clock cycles. There's roughly 976 of them per second. And what that means is beacon frames are typically addressed as an interval, right? So how many time units are we going to wait in between each chirp? And that chirp just says, hey, I'm Linkless, connect me. So typically most routers will wait 100 time units or they do it nine times per second. And with that, what you end up doing is you end up chirping out about 108 possible ESS IDs per second. Right, and that's if you go with a standard time unit that's recommended. We don't really do that. We want it to go faster. So we do about twice as many. Nope, that's not true. Almost, almost? Yeah, many. Three, almost, many. We go faster. And that's the default interval. And the reason why we do for the normal interval, the reason why we go at this speed is just because we can go faster. We don't have to wait on certain other activities that another AP would have to. But it's also very CPU intensive if we go much faster than that as in between packets. So we have aggressive mode. We implemented that and it is a lot faster. We're down to about 600 microseconds between beacons. And so what that means is we can basically beacon out, not just Linkless over and over and over again nine times, but we have the opportunity to do hundreds of times per second. And the way that devices, channel hop, looking for devices, so they'll come online and they'll listen on channel one, anything around. Okay, move to channel two and do that. And they'll loop over and over and over. So they may only see one and that may be good enough for it to just show up in the network list. Which means that at these intervals, we're able to handle thousands of SSIDs in the SSID pool if you will and successfully transmit those out. And I know what you're thinking. Yeah, we can go faster. So while developing this, we decide to go a lot faster, put powerful hardware behind the i7, fast wireless cards and just, you know, thought let's blow that out and see what happens. And if you ever wanna learn how to turn an Android phone into a turtle, that is how you do it. Hey, hey, hey, I take offense to that. The turtle's pretty rad, turn it into a... No, I meant more in terms of speed, but you know. Let's say snail, it's another thing with a shell. Okay, well anyway, to slug your Android, all you have to do is beacon out how many time unit intervals? None, none, just do them all. All right, well, yeah, kind of. There's one in here, problem with that of course, if you keep saying, hey, connect to me on channel one, hey, connect me on channel one, hey, connect to me on channel one. Because unlike all of the other, like datagram frames that use the control frames, which use things like clear to send and request to send and things of that nature, these are like ADS-B or any other dumb protocol that doesn't know what's around and it's basically a really bad time division multiplexing or something, it's just like, it's just gonna squash anything. Inherently knowing that, well, you know, it's TCP that we're gonna be squashing, so they'll resend and everything will be cool. So yeah, if you do that, you just f over the entire spectrum, so don't do that. That's no good. All right, so we covered harvesting a little bit before. Basically, we harvest pro requests, we harvest beacons using recon mode. You could use wiggle to do a bit of recon on your sense and we actually, the talk we did at B-Sides, we were told that we have to implement wiggle onto the Pineapple or at least an API for it. If you're not familiar with wiggle, wiggle.net, wiggle.net with 1G, by the way, is kind of like a open source version of Skyhook or some of those other geolocation services that collect the locations of access points, which is great as augmentation to GPS and things like that. And this kind of spawned out of the whole early 2000s war-driving movement, and it's really cool because people still today are dumping Kismet logs full of SSIDs and GPS, which are pretty fantastic too, because if you wanted to know, hey, what are all the access points around 1600 Pennsylvania Avenue, you can just go on wiggle and find out. And then you can download those and pop them into your management list and now Dogmo would start making it look like you're in downtown DC, which is fun. Yeah, exactly. Yeah, and there's a lot of things you could do with that. So if you know you have a site and you know that there's information on wiggle, you might as well plug it into PineAP and you'll be able to use that again, that way you can ensure that you get the most out of it. So while it's not as easy as karma used to be, it is the best there is for the current situation right now. Of course, the situation that you're most likely gonna be in is if you come into audit and organization, you may be given a scope of engagement, in which case it would probably behoove you to fire up recon mode, see what the landscape is around there. And then right from within recon mode, you can go ahead and add to that SSID list based on the access points in the area, what you want to clone. Oh, and we have a tractor. Okay. You wanna do that one? Yeah. So if PineAP is the ammunition and then recon mode is the battlefield, it provides that situational awareness where you have like a good sense of what's around you and we've seen site surveys before, you can pull up a site survey on your phone or whatever have you, but that typically only shows you the nearby access points and that's only like half the picture. In fact, it's probably even less than that because what we're truly interested in are clients and specifically the intelligence we can gather from which clients are connected to which access points. So the way that recon mode works is it displays to you all of the access points nearby, but then underneath them, it displays all of the MAC addresses of the access points or sorry, the stations connected to that base station, the clients connected to that AP. And with that, you know, okay, so I'm here to target ACME, now I know here's the MAC addresses that are connected to that ACME access point, regardless of whether it's WPA, enterprise or whatever have you. And so with that, you can go ahead and set your filters so that you can limit the scope of your engagement. And likewise, you can also see not just clients that are connected to access points, but you can also see unassociated clients. And so what that means is these are clients that have Wi-Fi on and particularly that are sending out probe requests. So they're like the lowest hanging fruit. These are the clients that just want to connect to an access point. It just so happens that the access point that they're looking for isn't in the vicinity, otherwise they'd be on one of the other ones in the list. So the last one is a bit of a weird one. It's out of range clients and most people get really confused by that. What that means is we are able to, we have two radius on the pineapple and one is a bit stronger than the other and there's a few differences between them. But basically what this comes down to is that we have the WLAN zero which is the one that we get all the clients to connect to. It's a little bit weaker than WLAN one which is what we use to scan for clients which is what we use to gather this data this on the site. And then we match the two up. So there are some clients that you're not able to actually currently get onto your pineapple because you're too far away or because the access point at least that they're connected to is too far away. So they might be connected to something or they are connected to an access point. However, we can't see that access point using WLAN zero. So we're probably out of effective range of if we do kick it off from the access point to bring it back to us. So it's something to be aware of because if that's one of your targets that you're meant to test for or find, then you might have to move closer. You might have to change locations or you might have to just, you know, know. Rika Naoud also provides a really convenient interface to a lot of the other plan AP, stuff like being able to de-authenticate a client. So you're like, okay, great. So I was brought into Target just the CFO. I've got his MAC address. There he is connected to the ACME Wi-Fi and I can see him. Fantastic. Click on him, say de-auth. He drops off, do that maybe a few times and eventually the device may just get tired of trying to reconnect to that network, start looking at other networks in their PNL and then, you know, connect to you. That's the hope. This also allows you to do that said filtering. So, you know, add him to or your filter list so that only the CFO will connect to you. Likewise, if you're brought into it or audit the entire organization, you may just de-auth the entire organization by clicking on the SSID of ACME Co and then, you know, kick off all of those clients. And then, of course, adding those SSIDs to your pools. So, you know, I want to go ahead and clone that. So I know that they work here and I want to clone that so that I can then go elsewhere. So I'm like, oh, hey, you're on corporate-guest and it's an open Wi-Fi and you've connected to there before because there's some IT issues and you know you weren't supposed to but you did it anyway because it was open. You didn't even need a password. It's fun. And so now we clone that and we go elsewhere and when you go there and you're probing for it, you're probably going to connect. And then that also leads into reporting which we'll touch on more in just a bit. So we've added a lot of new features to Pineapple. Actually, we've added a lot of features to the Wi-Fi Pineapple, marked five over the last almost two years now anyway, now in version 2.4. And so two of the really big ones are reporting and tracking. Do you want to speak to you through this? Yeah, sure. So the first one we have is reporting. It wasn't very easy before to get a good report on what's actually going on with your Pineapple. You could deploy it somewhere and then pull the logs off at some later point. You could log it to the SD card but you need physical access. So we implemented reporting which will basically gather your Karma or PineAP log. It'll take a command line version of the site survey or the recon mode and it's going to implement the tracking which I'll talk about at the next point. But basically, it'll take all the information that we gathered. Sorry, and this CSV of Max and the SSIDs they've probed for. So you get a nice clean view of that which you can import and actually analyze. And that can be emailed to you. It can be stored to the SD card in, you know, is histographical? Yeah, is that the word? Sure, let's go. Dates, dates, thank you. So a date stamped format, right? So you have those options down. Yeah. This is a really interesting one too because we can just set up a Pineapple, say, in a completely passive mode. Actually, we're skipping on some of these things that were added in 2.3 but a lot of passive logging capabilities were added in that version which makes reporting all the more useful if you drop it at a site and you have it powered, say, in an ominous box or something like that. And it's doing just this reconnaissance and emailing you those reports or saving those reports to SD card. And that site survey can be really useful if you can now map where your clients of interest happen to go and when they go there. So if it's the corporate guest Wi-Fi network and it sees these clients on these certain days, you can kind of come up with patterns and this is something that might have been useful for our tweaker friend to know when the security guard was coming around which leads really into tracking. Right, and then we added tracking and tracking is not completely new concept to the Pineapple. So what it does is it takes all the information we get about clients when you have logging turned on at least. So probe requests or in general if we see data in the air and you're scanning for it if a client or a MAC address that you've specified is seen in the air, it will fire off a user configurable script. So you can say when that event happens you want it to blink an LED or you want it to send you an email or something along those lines, right? So it's totally user customizable but it means that there's a hook to every time you see a certain MAC, it'll do a certain, it'll fire off a certain event. And again with the reporting it ties in with that and can actually then fire off an email to you or be added to a list. So there's a timestamp list of when an SSID was seen, what it was doing, or sorry, when a MAC address was seen, what it was doing or what it was currently looking for and if it's got an SSID associated with it'll list the SSID and it'll email you that again in a report, no. Those are ducks. So what we're trying to do is make it easier to make sense of the PineAP log and to really get some interesting, just get some value from that because there's a lot happening even if you're not running Karma and also accepting those clients to connect to the Wi-Fi pineapple. There's a lot of interesting information that you can glean that can be useful for you on your pen test. So kind of going forward, that's a lot of the emphasis, especially right now with the reporting, gathering that data and getting it to you in a convenient means, means that you'll be able to run it through some sort of analysis and see if there's something interesting there. So we'll just do that now. Let's step this up. Yeah, sure. So we visited this place in Mountain View, California. Just, you know, we're there to visit and we had a pineapple with us. Obviously passive logging, totally legal. And we got some really interesting results as we were talking about, you know, how devices stop probing. I think this is a really good place to, you know, test this on. So these were the results. And I'll be going ahead and publishing the script file on the hack file forms but essentially what this does is it takes your pineapple log and it processes it in conjunction with the IEEE OUI list, the list of manufacturers. And so just from this little short engagement in the cafeteria where the food is all free and amazing, we were able to find out that there were about 255 unique probes and of those they were from 334 devices. Those devices spanned 154 OUIs. But of course, lots of manufacturers have various OUIs, those being the first three octets of a MAC address. So really when you just take it down to the manufacturers, it's really only 30 manufacturers. We were also able to say, okay, well here are the top 10 manufacturers, which I was really surprised at this place in Mountain View. You used so many Apple products. Motorola's kind of good too, I guess. Yeah. Yeah. But what surprised us more, I think was the probes we received or saw. Just take a look. I like the one because they're unique. I like that 16 devices were probing for that one thing. Yeah, that's not 16 probes, that's 16 unique devices. They're weird. Maybe it's a hacker space. Some other improvements in version 2.4 added to the, no, not. So some of them added in 2.4 include the ability to de-auth all of the clients off of a specific access point. Again, I'm brought in to audit this network. Here's Acme, Gas, Acme, Corporate Wi-Fi, whatever have you. I just want to be able to click it and say, you know, kick them all because previously it was just a matter of clicking all of them. I know it's a convenience thing, but it's important and you want to speak to that, don't you? Yes. So you guys all know tools like MDK3, right? You know. AirDropNG. AirDropNG. You're able to kick off clients from access points and that's all fun. And MDK3 has that thing called AMOCK mode where you can kick off everything from every access point unless it's in your allow list or just Apple devices. Or just Apple or Google Glass or what have you, right? But that's, well, fun, oftentimes not really what you want in a proper test. So what we added is de-authentication from recon mode, which allows you to, once you have a client scan done, you're able to see the clients. You can click on a single client and you can kick that client off. That by itself isn't fun. So we added kick all clients from AP because you might have to do that for some scenarios. We did not want to though do a proper de-auth where we scan and look for everything that is currently on the access point for the duration of the de-authentication attack and kick off everything that we might have not seen. So what we do is we actually send targeted de-auths to only the client devices you just saw and that you approve for the kicking off. So only those devices will be disassociated or de-authenticated and not devices that might have connected in the meantime just because you want to keep it clean and you want to limit collateral damage as much as possible. Right. And likewise, the tool isn't built to also do any sort of continuous de-authing and that kind of leads into the de-auth multiplier. So we're trying to think of like what's a good way to set it up in such a way so that like sometimes some devices, you know, you kick them off, you know, maybe it takes, I don't know, what six, seven de-auth packets and then more, okay. And then it decides, okay, well, this access point doesn't want to be friends with me anymore. That's cool, I'll disconnect. What is the most vendor implementations immediately want to now become friends again? Like, wait, what? Lost Wi-Fi? Oh, woo, Wi-Fi. And they'll do that so many times until they finally eventually give up. What we didn't want to do though was just have it be continuous. So we set up multipliers where you could get that like say three attempts before they stopped trying and then go on to the next one in their PNL. And so it just seemed like the most obvious choice was to set a multiplier. So if you set it to two, that's gonna be twice as many. If you set it to 10, that's gonna be a lot. CLI? Yeah, and moreover, going in with the reporting and tracking functionality, spawned the ability to then also do the recon mode from the CLI. If that's where you're more comfortable, the command is? Site, underscore, survey. Yes, and so you basically get the same output, but of course now you don't get that contextual thing where you can click on an SSID or a MAC address and add them to lists and filters and de-auth them. And we made it more prettier. So now we're gonna talk about security, some of the things that worked and some of the things that didn't, and I want to take the first one. Who here uses pineapple or yummy as your password on your pineapple? Okay, you probably have a mark for. That didn't work out so well. Who's using Tor as their password on Cali? Yeah, okay, so you guys, everybody but Mubix is smart. So yeah, that didn't work obviously. And yeah, so hard-coded passwords are bad. Not doing that. So another thing, oh, do the shuffle, okay. So anyway, that was the mark four days. On the mark five, we went through a lot of different things. One of the first things we did to kind of try to secure the tester a lot more from potential attacks was to implement the WPA2 management interface which meant that your packets can't just be sniffed out. You can't just get your session ID. You can't get your session ID out of the air which made it really easy to compromise the pineapple. Don't really like that. So we added the WPA2 management interface. We added- Oh, and it's forced, it's the default. Right, yeah. So to set it up- The initial setup, you have to configure this management interface. We also protect against cross-out request forgery now which is something we just didn't really do before and it's important that we do. Yeah, yeah, I know. You can give me trouble for that, it's okay. But the scenario of where you're on a test and you're on a website that's targeting pineapples is something that we didn't really consider much. And then we did presence verification. We previously did this with LEDs and this is actually something that's gonna lead into the point underneath. But we said, okay, your pineapple has got four LEDs. One of them is fixed, it's a power LED. But, you know, and to set up your pineapple you have to say which LED is either on, off, or blinking. That's- Well, the importance of that and our thinking there was, well, let's make sure that only the user of the Wi-Fi pineapple is setting up their own pineapple and that it's not somebody else accidentally connecting to theirs and trying to set it up because previously they were all set up with pineapple five underscore, you know, last two octets of the MAC address. Of course, now we force them to create a really creative management interface, SSID and all of that. But, yeah, so that didn't really work out so well though because it turns out there's how many combinations? Not enough so that when we locked ourselves out at some point because we broke the LEDs we just brute-forced it by saying on, on, on, on, on and just hitting enter 10 times when we were in. So that did not work. So what we do now is to make the initial setup which was the most dangerous portion of the pineapple because somebody can race you to it and set it up and brute force his way in or his or her way in. But so what we do now is we require you to flip a dip switch. Now that sounds scary because some people do over-the-air updates or they might not have access to their pineapple because it's in an ominous box and plugged into all something they don't wanna have to undo the screws. Talk about that in a second but basically what we did is we included the possibility to by flipping down the dip switches it tells you to flip down, it'll disable the radios and then let you proceed with a setup by re-flipping them up. So that means the radios are disabled during the initial setup. So it really is just you over ethernet connected to the device so you can set it up safely you've got the time to do so and you can't proceed with it. Unless your ethernet cable is made in the middle. Right, yes. And then on the other one is you just flip one of the dip switches that tells you to flip and it's gonna just leave wifi on and let you proceed because you might be at home setting up your pineapple for a test and you don't really need to be that safe there. Of course there's a workaround to that or not a workaround but there's a convenience thing. Right, yeah, exactly. So this is convenience. It's always convenience versus security. And for this, if you wanna skip this entire dip switch up totally you just on the SD card add a file that's listed in our changelog skip dips or skip dip setup and if you have that file on there it'll just skip that portion entirely so you can actually deploy it like that. Because if you have physical access to the device anyway it's owned, so. The next point is the reason why you should just stay in this room for the next talk. I know that we will be because this sounds really interesting. Because Kenny's standing right there. He's got a black hat on. I don't know what that's supposed to mean. Where's Brown? Okay, you wanna speak to the CVE? Yes, sure. CVE 2015 4624. That is a really fun vulnerability on the pineapple that was basically a way to, first of all, you brute force the initials. We don't wanna take away from the talk too much. No, do you want me to explain anything or skip it? Okay. Yeah. I figured. All right, to give you a really quick rundown though. There you are. All right, so to give you a really quick rundown, basically you were able to skip because of the LED setup. You were able to get past that quite quickly by brute forcing it. And then you were able to, by having the default password, being pineapples are yummy. You know, because you're meant to change it. But you could skip that part, go directly to the login interface, log in and then change the password and execute commands and so on and so forth. Yay. Yay. Yay. So actually quite a while ago or I guess at least a year ago, we started looking into like, yo dog, we should just use SSL. That was even before the WPA management interface, which was really just like, SSL is hard, let's do WPA. But there's some inherent problems with doing SSL in this kind of embedded device nature. Who here really enjoys installing certificates in your browser? Okay, McGrew really likes installing certificates in his browser. It used to be like what, file import or something. It used to be that easy. And at least with Chrome and Firefox lately, it's just a real pain in the ass. So we're... It's worse on Android. Yeah, a lot worse on Android. And so it's again balancing the convenience and the usability and the security. And we should absolutely find some more convenient way to do this because I know when you were researching this, you've come up with something, but it's just like for that subset, for like everybody else, it's just gonna be a real hassle. So it's built in actually, and there's a wiki page on how to set it up. So you can do this. We're just trying to find a way to like automate that process and make it more simpler-er. Yes. Right, and then we have things like today's y'all hunt pineapples right there. No, so we fixed the things that are on this list mostly. But the inherent flaw on the network is that you can be our cash poisoned. So if you're connected to the same network and you have to be the way that pineapples currently set up, say you're connected to over ethernet, you're using yourself as the default gateway, the victims have to have a connection through to you, which means an attacker can use that and he can get in between you and the actual pineapple and now you're getting your sessions stolen again. Right. There are a couple of ways to go about this. I guess one of the most simplest would be to implement client isolation. But again, that creates a problem in that I want to be able to actually see my targets, not just their traffic, because I want to scan them for any potential volans and exploit them. So that's another one that we're just kind of still working on. And we've mocked up some stuff that works in certain scenarios, but not in others. And it really has to come down to like, well, what's the usability aspect here? And how do we find a way to put something together that's secure that's not also hindering a lot of your abilities? And if it's just a checkbox that you're gonna uncheck because you need to be able to access those, then that's not gonna work either. So that's still one that we're toying with. And then of course, the bug reporting aspect of it. I'm fine with any method of disclosure, but I should point out that we also do accept bug reports at bugs.hack5.org, as well as wifipineapple.com slash security. And we have a bug tracker there as well. And actually, Kenneth, who's gonna speak after us, came directly to us at Pentus with Hack 5, which was pretty cool. And we're both standing there looking over his code going, oh, that is so rad. So I can absolutely respect that. So going forward, I could probably list like 50 esoteric features that I want implemented that are in the Trello doc, you know, the list of all of the things that we want to add the... He means what I need to do. Yeah, yeah. I really like that one where you can just punch in a cross-section of a street and then it will download all the SSIDs from wiggle.net and then put them in your SSID pool, which is gonna be epic. Because I don't have to code it. Or I could, but it would look like the script that I'm about to show you. Anyway. But the two biggest pillars though the paths that we're going down in the future is both abstracting the engine and working on the Pentest workflow. So I'll let you talk about abstracting the engine because PineAP, the engine itself is really well-built and there's a lot of awesome functionality there. But it's also in some ways tied to the interface and what we want to do is get out of the way so that you can do what you do best. Right, so we would like to differentiate between what is the pineapple or the pineapple's engine and what is the way to manage it? What is the way to hook into it? What are the tools you can run in it? Because we simply have this device and the device, the Mark V right now is great at doing wireless. That is what it excels in, at least what I think or what we think. What we're not so great with is it's a 400 megahertz processor. So you're not gonna be running your Metasploit suite on it. You're not gonna be running full I don't know, all the man in the middle tools that are written in Python or Ruby that are ginormous and have giant dependencies and require four gigabytes of RAM to run properly. Or you could get them to work slowly. But then- In my next year. Exactly, well no, you could get them to work slowly, but not with many clients. We can handle like 200 clients is no big deal. Wi-Fi side, yes. Yes. So the issue isn't the Wi-Fi. It's what you do after you have the clients. So we're working on a way that you can basically take the clients and get them to a location where, so they abstract the engine. The thing that does the thing, keep doing the Wi-Fi and then offload tools and so on to other devices, be it your ARM devices or your laptop or a device in the cloud which ones your tools. But basically, we're going in that direction with this engine so that you run a pineapple. It does the pulling of the clients and- Right. Because you've done a fantastic job already with the API of making it really easy to write those infusions for say the web interface and all of those tools. But it would be really better if in addition to that, we could also take those same clients and just kind of like run them through what we're already used to doing. We don't need to reinvent the wheel here if you have a workflow, if you have tools that you're using. And so that's the other thing that we're working on is workflow and that looking back at the 1.0 version of the Mark 5, it's really grown a lot and there's like so many features now. And so if you've been with the project for a long time, you're probably very familiar with where all of those options are. And when you get a new version, you're clicking around and realizing that we've done a lot to make it easier. There's no help bubbles next to most of the big features that kind of explain what they do and how they work. But our next emphasis in addition to abstracting the engine would also be on creating like what is the pentest workflow and it may differ dramatically depending on who the client is and what kind of audit they're looking for. So what we're hoping to do is make it clearer. Like, okay, here is the recipe for success. And if you're doing this kind of, you know, select a profile, if you're doing this kind of an audit, then these are the steps you may wanna go through. And if you're doing that kind of, then these are the steps and this is the report that you're gonna get at the end of that. And if you've then done that and you're like, well, this works great, charged a bunch of money, did an audit, got them the report, they're happy, they call me again next year and want the same thing. I want you to be able to more easily do that again without having to, you know, find all the things again. Before we do that, do you wanna speak on this? So there's also things you should not do with a pineapple. One of those things is this, don't do that. You look, you'll get arrested. It's just slightly obvious. Yeah. But you've got the interesting information. Yeah, there's lots of fun things you can do passively but then like trying to explain it to the NPS is always interesting too. Wi-Fi geocaching, just go with that. There is, find us off camera. And with that, let's do some ASCII Q&A. Yes. What we've found is that we get the best throughput when we use a third radio and we recommend of course the Alpha NEH, which we supply, yes? That's okay. Well, I guess we should address that in saying that initially from the onset of the Wi-Fi pineapple, I mean that you're looking at it, the two of us, launching the Mark V, big dreams of Pine AP and of course, some things get finished before others. So when we launched the device, we really went with the software-wise, there were a lot of improvements but it was also the best that we had had on the previous generation. But of course we built the custom hardware, dreaming of what is possible when we have a dedicated interface for that constant sniffing and packet injection and there was the sketch on the board of like this is what the Pine AP future is going to look like. So let's make hardware for that. So we put the cart a little bit before the horse there and in that case we're like, okay well, what are we doing with WLAN 1? So we threw in client mode, which turned out to be like a huge feature that everybody loved. So then later when we came out with Pine AP, which requires WLAN 1, it then got a little trick here where it's like, okay well, okay well we want to make it optional because some people are using this but really we want it to be the dedicated interface that you use to support that first interface. We don't want to tie up WLAN 0, the atheros doing karma with too many other tasks because then we're going to start dropping clients and that's what we want. And yes we did also run into throughput issues and so we did dev another board and solved one issue and broke several others and I wish it was as easy as it is because Seb's got it easy, he just has to do code. He just hits F5 and it says warning or doesn't compile and then he like put, does the, he's hit something called, this is what you do, so you just like that and then like the code happens and so he just hits F5 and compiles again. Like we've got to like do, yes. So it's much more difficult to do raves and I can show you boards that like, hey this is fixed and now we totally screwed over storage. So yeah, maybe we'll put those in the museum. We've got like all these shadow boxes of all of the various prototype boards that for some reason or another are derpy. Working on new things because there are clearly things that we can improve, we could add more process and we could add five gigahertz, we could add an SSD, you never know, right? So I'm not saying there's not going to be a Mark 6 but it is definitely one of those things where with this abstraction of the engine it wouldn't impact that either because the engine would be abstracted from the device and from the tools that would be running on your computer or on your Android phone or on your, where have you, right? So we want to kind of be able to, you pull out your Android phone, you connect to your pineapple, manage it from there, might be through an Android app because it's agnostic, right? It wouldn't care what you're doing for management which also means that anyone can write apps for it, anyone can hook into it, you can have big integrations into entire other systems and so on. So working on that, we want to go get hooks into Cali that just make that totally painless. We want to get hooks or like modules for Metasploit out and just kind of make ourselves more integrated. Yes, but no, I mean, that's like asking Apple if there's going to be an iPhone 7. So, I think they're stopping though. Yeah, no, 802.11 AC, we could go on and on and on. In fact, I love hearing people shout out, like we had people at B-side sell us they wanted BTLE. Okay, maybe we can also work better with things like Ubertooth or something like that. But yes, there was another question over here. No, completely original. All right, thank you so much for letting us do this.