So I've been at Mississippi state for a number of years.  Got my graduate degrees there and now I'm a research professor.  I teach one class a semester.  It's a security course that I turned into a penetration course and reverse engineering course that teaches students how to reverse engineer malware.
     I have a consultancy, where we provide interesting services and my interests are in vulnerability analysis, general cyber operations.  I don't do a lot of defensive stuff.  That is for other folks.
     What we're talking about today is option rational security for penetration testers or any other type of attackers.  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.  But generally how to keep yourself safe and how to keep your client data safe during a penetration test.
     A lot of these are not straight bugs.  The ones I demoed last year in gorilla fashion and those I'm going to do today, these are bugs in the tools and in the default insulations of them.  A lot are communication and data security issues.  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 how you use it. You have to take that into account when dealing with this.
     I'm going to talk about how we can illustrate and classify the risk based on these tools.  We're going to look at a selection of tools from Calli and Linux and while they're great tools and we use them on our tests, how they might have problems with regards to communication, security, and data storage.  And provide some recommendations on how to change the practices to better secure these things.
     This talk is for penetration testers and those who hunt penetration testers.  How many of you hunt penetration testers?  There is more hands than penetration testers.  I like that.
     Previously I discussed the vulnerabilities in the pony express phone plug.  In that talk I warned people if they were buying pineapples in the vendor village somebody might find a bug and reck their pineapples and sure enough, the next year somebody did.  We demoed those last year.  It was a script running in my back off of a small TP linked router and one watt 90DBI and walking around autonomously popping these things.
     If you buy me a drink I'll show you the code for that.  It was a PHP authentication bypass where it was
being done in the footer of the PHP code for some reason.
     In general when we talk about this, it's not just physical devices, not just toys that you buy.  It's the entire body of the tools that you're using that are software based.  The standard operating procedures and how you handle data security.  You have a lot of very valuable data as a penetration tester.  You sort of 'em bred (audio blipped) extract out a bunch of stuff and generate a report and embarrass people and because that data is incredibly valuable, it has to do with personal information.  It's going to be trade secrets and things like that.  The value of the data that you're handling is very high.
     The awareness and understanding of the risks and vulnerabilities involved in these tools is fairly low. We understand how to figure out risk for a normal business and everything, but it seems like the training and books and material that we use to train ourselves up, those tools do not -- that training and material does not cover how to do it safely.
     The first thing you learn how to do is neck out a shell from a compromised host to yours.  And a neck cat shell is tele net.  That's the worst you can do.  This is counter intuitive.  You expect 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 the presumed expert of offense but you're not mindful of your own defenses.  The reason is the training.  The training material is focused on getting the lowest denominator as far as minimum pre-recs as possible into a training program to get them to the minimum point they need to start operating as a penetration tester.  There is no time in a one-week course to spend on operational security or wrap things around encrypted tunnels.
     A lot of this they don't test, they don't teach in the classes and they don't write about it in the books. As the field matures and hopefully it will mature any day now, we need that.  We need to treat that data more (audio blipped).
     The tool chain.  I love Calli Linux and I use it. I use all the tools that are out there.  But it's not a solid tool chain as far as end usage or usage are regards to security.
     There's a lack of documented instance.  One last year with the Wi-Fi pineapples at DEFCON.  But how many penetration testers get popped.  There were for a time the anti-sect groups.  I miss those guy, the ZFO ... Too young in oh my gosh.  There is a lack of documented instances of security people getting hacked.  So it's not a concern for me.
     So the idea here is when we lack the capability to understand our own tools we operate at the mercy of those that do.  A lot of these devices, a classic example of that, the tool makes it easier.  Automates the process, enables somebody to do these things. Without the underlying understanding of what is involved in doing this thing such as the man in the middle and Wi-Fi connection, without the understanding of that and the issues of how you interact with that device and what the other people on the network see, without that understanding the people that do understand it are going to wreck it.
     So to talk about this, we have to make assumptions about what a reasonable attack is, a realistic attack is.  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 middle attacks are given short shift.  They're not seen as the most serious.  It's not like I can hit you over the public internet and know your IP address, run MS8067 on you and pop you.  I have to be in a certain place at a certain times.  Those attacks are seen as being less severe.
     But in the case of a penetration tester it's not exactly the least realistic thing in the world.  There is a good chance if you as a penetration tester are capable of getting into an organization remotely through whatever means you use, there is a good chance there is a guy already there that is not a penetration tester.  That individual might be able to compromise you in the same sort of network domain as that.
     The assumptions here for this work is essentially an attacker may on the part with skills and resources that exceed the pentester.  The bad guys are better than the pentester.  The ideas behind this work and presenting this is we make and repair the [indiscernible].  If most penetration testers were aware of this sort of thing, they would work towards being mindful.
     And for the sake of 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 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 with intercept that, somebody can change that.  Man in the middle may not be a general script kitty thing, but an advance attacker is at least as skilled as the penetration tester.  This is something reasonable.  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 deep into organizations.  So the pay back 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 not securely wiping things.
     So the goals -- so basically the goal of doing this to somebody, so the victimology, who are you targeting?  As an attacker I'm targeting the penetration tester or the clients themselves.  For the penetration tester, it's a business just like any other.  They have business information, compromise that.  Sabotage, embarrassing leaks.  ZFO type things.
     The client is the cool one, I think.  So if I pop a penetration tester, then I have access to all of that client's sensitive information, the vulnerability that are in the systems and I can probably gain persistence in those systems as well.  What is more, if I'm in a good situation, I'm really 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 collect all this information.  This is either an attacker attacking a penetration tester, having a specific client in mind or riding along for 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, the same information, the same exploits, this is attractive to the tester because the penetration (audio blipped) culture and structure.  This can help you.  Instead of dealing with the help desk or the IT folks or the normal ways in, dealing with the penetration tester and compromising that is an alternative route.
     This is somebody that exists outside the culture and structure of the organization but winds up with ridiculous amounts of access to the system.  They break policy by definition.  Their job is to break policy. To break past all these measures.  If you're riding along with a penetration tester you can do all these things, too, and it's not seen as strange.  Ride along with them.
     You can steal tools and techniques.  The assumption here is 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 the attacker has.  Some people shell out the extra money for private exploits.  Thieves of vulnerability information.  Tools, licenses, things like that.
     And you can hide bugs from the testers and modify the results of the test.  Just acts as a smoke screen. You come in with somebody who is probably very noisy and triggering every alert around there and you can avoid doing that yourself.
     The -- issues.  Talking about the issues that you might have.  So you're taught to find bugs or find known vulnerabilities in systems and you go out and research where the bugs are and download those exploits and everything.  We all know about back doored exploits.  That is pretty common.  The shell code is a thing that spawns a shell on your system.  It compromises the person that runs them.
     A lot of time ifs it's a memory corruption and it's shell code loaded into the system, that shell code is rarely annotated.  You can see some people really good.  They split off the strings and have an assembly line -- you don't know if that's where it assembles to unless you're really sharp.  So those payloads are rarely annotated.  The people using them are not equipped to evaluate them.  How many penetration testers do you know that are sharp with assembly language?  Not a whole lot.
     How many of those take the time to disassemble the code and make sure it does what it's doing?  The comprehension is important.  Most of the time if you're requiring a stand-alone exploit, you're doing so in desperation.  There is no -- module for this one.  You try to find whatever you can.
     You're happy when you find thing.  And without discretion.  You're so frustrated getting into the machine that you launch these without thinking about it.  Maybe it does the attack, maybe it doesn't.
     Each encoded string in the exploit represents code nah the penetration tester has to fully understand or place trust by association with the source.  I'm talking about exploit DB in a bit.  It's a pretty trusted source for exploits.
     The way we interact with it is an issue.  And this trust decision is forced.  You have no choice.  You
succeed in the test or you don't.  And so you're forced into this decision on code that you don't understand by a lack of training and skill and programming vulnerability analysis, exploit development.  That is something that penetration testers don't get into until advanced classes if ever.
     From an early draft of the paper that I submitted for this, at the time that I wrote it, the DB, it operated over plan HTTP.  The way Calli pulled updates was HTTP.  The man in the middle could replace that code.  Now it's HTTPS by default.  The most recent Calli seems to pull it down over the app servers so that is more secure.  So kudos.  Then your trust is not in the network between you and DB, it's whoever is embedding the code there.
     You're a little safer there.  Exploit DB did all they can.  With the exploitation of the system, when running exploit against the system, how do you compromise the system without everyone 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 compromised the system?  There is 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 know that he wants to communicate or know he is about to communicate.  How do you establish secrets with him?
     And if you do have a good secure payload, how do you keep it from being modified in transit?  Who knows. The idea here as far as I can tell is to exploit the target as close to the target (audio blipped) to reduce that exposure.
     So ship an appliance to the client, DPM into ha and launch the exploits from that.  It's not as realistic as simulating an ATP against an organization but it's safer.  Reduces the exposure.
     So -- the gold standard.  The most versatile free payload you can ever find for any exploit is Meterprete re.  Since 2009 it supported encryption.  I have been shown shots of tools that can intercept.  There is encryption in there but you have to wonder, if you're establishing the keys, when are the keys establish.  It has to be after code is executing.  There is this whole stage of set thing and setting up code execution before Meterpreter executes.
     This is mostly for evasion.  To prevent IDS signatures from tracking in on Meterpreter packets. Otherwise how to you secure that.  Extending the network.  If you're a physical penetration tester and going on site and dropping the Wi-Fi pineapple or land turtle, whatever it is you're going to drop on the network, you have to be very concerned about extending the network.  Our university IT folks get nervous when I extended the network by adding switches or routers or device they don't know about.
     Every time you do that you're adding to your attack surface.  You're trying to alert people in on open Wi-Fi.  There is not much good setting up WPA2 (ph.) to connect to.  Cellular data.  That is probably about the safest way to have a back channel into the network.  SMS is good.
     These are the accessible things like rogue Wi-Fi and extra network cables running around.  Those might open up attack surface.  So that goes back to the Wi-Fi pineapple bugs.
     When we talk about data at risk, there is - so there's (audio blipped) stored in the process of this. 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 as you go and think you can write it up later and then you forget what you did and you have to do it all over again.  You're storing a lot of sensitive information about a client.  Where are you storing that?  On the end point server or on the CalliVM with the password. On encrypted volume.  It's not secure by default.
     Are the implanted devices storing sensitive data? Are they secure.  Are you encrypting the data. Encrypting the volume and who has access to the keys and when do you delete the data.  If you're going from engagement to engagement you're not wiping the system. You have the pentesting laptop and have an array of devices and whenever you're done with one engagement you RMF the folder with the client data hopefully.  You can recover that later.
     Maybe you don't delete at all.  You archive it. So in 6 months when you come back you have the old information.  What do you keep and how long do you keep it.
     And point of contact.  You have your get out of jail free card.  The emergency contacts.  Crap I knocked over the main server.  Sorry.  They're losing money constantly until it's back up.  You have that emergency contact in there that you call when you get into trouble or get them into trouble.  So this is how you set up the scope of a test.  This is how you deliver your report.
     These channels need to be secure.  You don't need to email the pen test report over plain text email.
Are you going to teach them to use PGP?  I don't know. You go and deliver by hand.
     This is the first slide with color in it for those watching on the TV.  Classifying tool safety.  I went through a small sampling of tools in Calli and ranked them on terms of how safe they are.  These are not saying if this tool is red, dangerous, do not use it. Obviously do not.  Use what you need to complete the job.  You have to be mindful.
     Something that is dangerous, it may cause known vulnerabilities or the communications it has are subject to interceptor modification.  And yellow is caution.  Things that defaults lead to dangerous situations but it's easy to configure this thing to not be insecure or things that are essentially naturally safe.  Safe for normal use, safe for normal configuration.
     And tools that didn't fit into this model that are not necessarily pentesting tools but they can improve the security of the other tools.  This 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.  So few penetration testing tools make any attempt to save the data that we don't consider it here.  It's down to use to use encrypted file systems.  If you're using a small device off a battery that can't cope with an encrypted file system, I don't know what to tell you.
     This is reproduced in the report, in the paper that is on the disk.  Don't worry about reading this. I wanted to put the table in to show you the idea.
     The top one is one of my favorite tools.  Your hooked clients on beef are communicating over the unencrypted HTTP.  I'm not that smart on using it. Perhaps there is a good way to change it.  But by default and by 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. You're not doing more things with them than the web application originally did.  You have to be very careful.
     And then other tools, those are not necessarily opening up a vulnerability but they are leaking data over public networks and things.  So you have to use those with care.  And finally if we go down to the one naturally safe one on that table, N cat.  It's net cat but with cell support that is very easy to use.  Use that instead of net cat.  No reason not to.  Set the certificates for it and you're good to go.
     Implantable devices.  Buying in the vendor village.  Two years ago and I typo'd that.  That is supposed to be DEFCON 21 there.  But in DEFCON 21, I released a series of vulnerabilities in the pony express phone plug and I triggered, I used a crafted packet to trigger a scripting vulnerability in the web interface which then injected -- commands and wreck the whole thing.  I had a nice pony express route kit going.  Last year was the hat five Wi-Fi pineapple vulnerabilities.  They have improved that device remarkably over the past year.  They patched that. Patched a few other vulnerabilities.
     They even got it into a thing where they developed a secure way of setting up the device.  You were just sitting out there in the open until you could quickly push the buttons to configure the way you wanted it before somebody came in with pineapples dot DY.  They had it where you punch in a sequence of lights that were on the device blinking and tell it what the pattern was.  That was easy to brute force.  Now you set dip switches on it in a certain sequence.  So you can't own the thing until it's fully configured.
     They worked hard on getting this up and going good.  There are a couple new vulnerabilities (audio blipped) patched in the latest version of the firmware, he has a cool network based worm that's pretty cool that he uses to demo this.  And today I'm going to demo a simple communication security man in the middle attack against it.
     The clone devices.  There are lots of things you can buy that have the same -- they have the Wi-Fi pineapple tools ripped off and put in.  Those are way worse.  They don't get patched.  So those are bad. Stuff that uses some of the pony express code.  They don't get updates.  It's a single person's project and they abandon it immediately.  And even the older devices, the older Wi-Fi pineapple devices don't see updates either.  Any bugs in those are likely to remain there.
     There is inherent problems with these low-powered devices that you have to be careful about.  They're not doing things like defaulting to SSL and they're trying to conserve the power instead of using it to lock stuff down.
     Here is new pineapple stuff.  That's a URL I released yesterday so folks can go on hunting expeditions.  The network situation was getting kind of rough.  There are a few of them popping up.  So I released that.  I'm not running around with a backpack, Wi-Fi pineapples like I did last year, that is y'all's job now.  The script we have on this site is not completely weaponized.  It demos it.  It doesn't autonomously seek and destroy and the payload is just adding a user.
     Modify the code to do as you please.  And use the I hunt -- y'all hunt pineapples tag to report your successes so that we can all point and laugh, right.
     So we're going to demo this.  We can't have nice things, right.  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 Sergi distract them while I hook this thing up via wired.  I have a wired interface to the pineapple under me.  Trust me it works across the interfaces.  With a Wi-Fi pineapple you have a couple of wireless interfaces and wired interface.  Logically you have the WPA2 network that is operator is configuring the device over and then you have an open network or series of open networks that is bringing in victims and you have a wired interface, up linker.  All of these interfaces are bridged together and everybody on every interface gets an IP address on the same sub net.
     It's trivial to these folks.  We can take a quick look at the code for that.
     If you go and grab it you get this.  You get some information on how to use it.  Places to put in automation.  The idea is we set up spoofing between the pineapple itself and the operator.  We're doing this from the open Wi-Fi interface or any interface on this. Make sure it's a Wi-Fi pineapple and not the official DEFCON.  We sniff for the session cookie and CRF token and use that to insert commands.
     So it all happens very quickly.  And so we have the Wi-Fi pineapple, I'm the jackass here trying to spoof network for everybody.  I'm not actually doing that.
     Here I am playing around, laughing at people at Starbucks.  And then on this side, hopefully I still have -- yes, I'm a victim.  Or I'm a bad guy who is pretending to be a victim and I'm on the same network. I want to figure out who the operator is.
     The easiest way to do that is to do a broadcast ping out to the broadcast (audio blipped) and see who responds.  So there are cleaner ways of doing this, but whatever.  And of course 131 is the IP address of the operator.  If you have multiple people responding, go with the lowest number.  The first guy there is going to be the one.
     And if we run y'all hunt pineapples with no information it gives usage.  Give it an interface and an operator IP address.  Y'all hunt pineapples.  (audio blipped) over the wired right.  Boring, lame.  But now we're going to target the operator.
     And this happens fast.  I'm telling you.  And we're in.
     Boom.
     So to recap the output.  It figures out the gate way.  Does it look like a pineapple.  It looks for the Wi-Fi pineapple logo.  Yep, trying this.  Looks like it.  Turns on IP porting.  Sets up the poisoning. Looks for the cookie.  There is always stuff going on back and forth between the web browser and the pineapple itself.  And so they don't have to be interactive, they just have to have something up.  It immediately finds the (audio blipped) and grabs the token and tears down the IP forwarding because it doesn't need it.  Runs the payload that adds R00T user to the device.  And then sets you up with an SSH connection where you're in.
     Fantastic.  From here you just destroy the thing or something, or leave a nasty message.  My favorite payload that somebody did is turned off IPD4 support so the person has to start learning IPD6.  That's good. Be creative.
     Don't be as mean as I was last year.  That was pretty rude.
     So that was my demo.  My recommendations for this, you can tell this bottle of anti-acids is mostly empty. Just check 6.  Be aware of the network and what you're transmitting and how valuable that information is versus the likely skill level of the attackers.  Test your skills before operational use.  Have a virtual network of EX server.  Don't just throw things to the client that you downloaded.  Reverse engineer those and figure out how they work.  If you don't know how to do that, learn.
     Be aware of the exposed information and know the target environment.  Minimize it.  Keep the client data safe both at rest and in transit.  Delete it between engagements.  It's tempting to keep it around but unless you can be sure that you can do it securely, delete it.  Secure that information with the client. Don't turn in the 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.  If you have penetration testers that have the capability of doing this.  So post exploitation you need a focus on establishing secure channels and infiltration.  So the contribution and hopes and dreams, reduce client exposure, improve tools and training and the maturity and advancement of penetration testing.
     I'm not holding my breath on that but give it a shot.  I'm not telling you to do shots.  Maybe it's early for that.  But take a shot at improving this.
     And so, do we have time?  We have time.  Talk to him about the land turtle as a bonus.  Wi-Fi, hack five guys that created the Wi-Fi pineapple.  They have a new device that I like.  It's called a land turtle and it is a USB to ethernet adapter and presents its as one on the computer.  But on the other end it's a separate interface and you the guts of a Wi-Fi pineapple without the Wi-Fi.  Managed over SSH so that is cool as far as security.  And it gives you man in the middle and persistent access with a very small device.  It does a lot of things that the pony express would do but it's 50 bucks instead of a lot.
     I highly recommend picks one of these up, because they seem like a lot of fun.  The day this thing came out I'm like, ha ha, I like land turtles.  I was on my phone in a meeting and didn't have the computer on me. This is the process that I went through when this thing came out.  Found the website.  That looks cool.  That's the device there.
     Google up the land turtle files.  GitHub.  This is like the delta between the base insulation and the land turtle and dive down into the user bin turtle update or whatever it was.  The update script and this is the first place to go.  Immediately running over HTTP and what it's doing on that secondary is grabbing a dot update file and then piping it ash.  And so this kind of gets scary right here.  This is where things get sketchy.  What is in that dot update file?  A script for updating device.
     The update process grabs the new update script that grabs the device.  This has the hash values and location.  This gives them 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.  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 No. 1 on our tracker.  We didn't have SSL so that is why it was like it.  It's going to be fixed in probably the next revision.  It's still a little scary.  You have this HTTPS server that is serving you up a script that you just run.
     I was talking with them, I think there is probably some way of having digital signatures for these instead of verifying hash values that you get from somewhere. There is probably a way of signing things on these devices that would help.  But how do you update the ones that are already out there.  A Jesus take the wheel moment where everyone has to trust one update.
     That happens a lot in penetration testing.  You just -- Jesus take the wheel.
     So it's scary but it's a really cool device. There seems to be a lot of focus on security these things and giving me a hard time and everything with each individual update.  But they're good guys and it seems like this is a really cool device and I look forward to playing with mine.
     I'm going to be around.  Ask me questions.  There is a paper on the CD.  This is my contact information. Hit me up.
     Ladies and gentlemen, please exit out the rear doors only, thank you.