Okay, this one's porn to porn plug. Okay, I hope I said that right. Wesley, let's go,
give him a big hand. Thank you. So how many of y'all out there have been basically emptying
the vendor area of all these crazy little devices? Pwn plugs, pineapples, I got to watch
my peas. They've got this thing called a rutabaga now. Mini poners, things like that. How many
of y'all have been buying these things? Make a little noise. All right. So how many of
y'all are going to be using those for good? How about for evil? All right. So there's
definitely some people doing some bad things with these things, and that's pretty cool.
So what we have here is why those of you who are using these things for good and for evil
might want to be a little more careful about when and where you turn these things on.
And how you use them. So the talk is porn to porn plug, analyzing and counterattacking
attacker implanted devices. So the idea here is we're going to be breaking things that
break things. My name is Wesley McGrew, and I am essentially the elder statesman of the
Mississippi State contingent here. Effectively, I guess, DC662. Mississippi State folks,
make a little noise. All right. Great. Cool.
I'm an assistant research professor at Mississippi State University, and also I run McGrewsecurity.com
and the McGrewsecurity Twitter account that you unfollowed last week.
So what I do is I break things. I love breaking things. And I'm occasionally good at it. So
I'm into any kind of vulnerability analysis, any kind of exploit stuff. I don't care what
it is. I want to find the problems with it. I'm into reverse engineering. I teach a reverse
engineering class at Mississippi State University that went really well in the spring. And I've
also been involved in the National Forensics Training Center, which teaches free digital
forensics classes to law enforcement and wounded veterans.
Recently I finished my dissertation. So I now have my Ph.D. for those of you who keep bugging
me every year at DEF CON to finish that up. So that's prepared me for my new role as the
12th doctor. In the meantime, I'm a professor at Mississippi
State University sort of leading the charge on doing some cool offensive breaking things
type research. What we're going to be talking about today
are attacker implantable devices. And this is sort of a term I've sort of applied to
a wide variety of things. There's a crisis of terminology for these things right now.
The traditional name for these are a drop box. And unfortunately there's a really bad
name collision with that right now. The storage guys kind of took that one from us.
But what I'm talking about are all these little kind of all in one embeddable type
things that you can buy over there in the vendor area. Things like the Pone plug, the
power strip, the Pone whatever they call that one now. The Pone plug R2 that just got released.
I haven't had a chance to get a hold of. Pone pads. You've got these little TP link router
devices like you see in the lower left there that can kind of run stripped down versions
of open work. And finally, the Raspberry Pi. So these new ARM sort of credit card sized
computers are perfect platforms for this sort of activity. So there's basically a Pone OS
type thing for the Raspberry Pi.
I presume it's probably called the Raspberry Pone, but I can't remember right now.
So what these things have in common is they're small and they're what I call attacker implantable,
whether you're a pen tester or an attacker. You can take these and hide them pretty much
anywhere in an organization. You can use that as sort of your end. You can use it to sniff
packets. You can use it to launch attacks from. And it's basically a do it yourself
pivot point in case you suck at phishing.
So these things have applications for both penetration testers and malicious attackers.
I'm sure all the folks that sell you these things want you to be a penetration tester.
But there's also something to be said for somebody maliciously using one of these things.
So the question here ‑‑ or one question, if we're a good guy, how do we respond to
one of these that we find in our organization? So we find a new toy in our server room that
we did not purchase from Pony Express. And how did this get here? And who's running
it? And what is it doing to my network? And also for both good and bad guys, what are
the implications of there being vulnerabilities in these devices? So if I'm a penetration
tester, what does it mean for my penetration testing tools to get attacked and compromised
and persistent compromised over a long period of time? If I'm an organization that's found
one of these that are malicious attackers.
Can I counterattack it? Why not? And assuming all the legal considerations are in order,
we don't have the same ‑‑ we don't have the same sort of problems with attribution
of attack at this point. It's not like we're counterattacking some random IP address somewhere
else on the Internet and we don't know if that's a hot point or not. If there's a Pwnplug
or some Raspberry Pi plugged up to our network inside our building that we don't know about,
well, that's obviously ‑‑
Yeah.
Something we can attack. Why not? I say why not. So this slide is basically
on identification, and I'm not going to go into all the different ways of identifying
one of these on your network. Honestly, if you got proper network access and control
and monitoring in place and anything, you should see one of these things pop up the
second it starts doing anything kind of noisy. Physically, they're meant to be sort of inconspicuous
but to the trained eye, it's not so much. So you look at these things and those are
the two stickers that come with the Pwnplug one. And one of them has a reference to SSH
on it and the other one is a printer power supply and I think that's the best application
for the Pwnplug itself. It looks like a printer power supply but part of its part number is
1337. So, okay. Actually, now that I look at this picture, I'm not sure what the barcode
is. It's probably like for a pack of Skittles or something. Who knows? I'm not sure. I'm
not sure. Who knows? So if you're going to be a pen tester using these things or even
better if you're a malicious attacker using these things, print up your own stickers.
Get an HP printer power supply and run that off on it. But if you find these things,
that's cause for concern. So what do we do? We can respond to it. And so the first thing
here ‑‑ and I just love this picture because Riker is hosting this thing. I forgot
about that.
First thing we want to do is pick this thing apart. What's going on with it? So we want
to seize this thing. We want to image it. We want to figure out what is it compromised
already if we can find that out. We want to attribute this to somebody. Is this somebody
inside our organization that's trying to do their own sort of unauthorized pen test but
they've got good intentions? Is it somebody who's managed to sneak in? Do we have a physical
security problem now, too?
We want to know who's getting this sort of information back. And there's a good chance
that with these devices that you can find, you know, where is this thing phoning home?
Who's grabbing the data off of it? And it may not be in the logs immediately because
these things are small and they're meant to not log a whole lot anyways. So maybe we
have to sit there and wait until somebody actually tries to connect to it and get their
data off of it. So the challenge here for forensics on these devices is essentially
how.
How?
There's going to be no procedures for pulling the plug on a computer or taking RAM image
and imaging hard drive and things like that on a normal PC or Mac or something like that.
But for an embedded device, do we know exactly how we're going to acquire a forensic image
of this thing without inadvertently changing evidence or destroying the thing or what have
you or breaking it, you know? So that's one concern is how do we do incident response
on this.
And another is if we decide to, how do we counterattack it? And so obviously if this
thing is sitting in our organization, we can pull the plug on it and after we take our
own forensic image of it, we blast our own image out to it that's backdoored to hell
and back. And that's not too terribly hard. But what if we want to attack it in place?
We don't want to remove power from it. We want to compromise this thing as somebody
is using it.
And that's the main challenge.
That's the main meat of this talk.
And so once we get into this thing, then we can monitor the attacker. We have a better
chance at attribution. We have a better chance at determining the motive.
I don't know about you, but, I mean, it's okay to stop an attack, but I'd rather know
who's trying to attack me and what are they trying to get at? What are they after? Because
that can help me defend against them in the future.
Essentially we can turn this device into a honeypot. It's the vulnerable system that
they are in and trying to attack us from. You know, it's a very complex system. It's
a very complex system. And we can monitor their actions from it.
So for pen testers, the typical use case for this, there's two different use cases. One
is the lazy pen tester who doesn't want to take a flight out and go in person and everything
to do an internal behind the firewall pen test. Sends it out and says plug it into
the network here, plug it into the network here, and sort of coordinates with the I.T.
staff on this.
And so that's one use case for this. And it's all set up, you know, it's all set up,
plug in power, plug it in the network, it's ready to go, it phones home, it establishes
an SSH connection, whatever.
Then you have your nerdy James Bond type payload situation where this is somebody who's
a little more sophisticated pen tester and actually has a physical component to his penetration
test where he'll go in and he'll drop this device off surreptitiously in a network. And
this is the same thing that an attacker is going to do. He wants to place this thing
into a position on your network.
That gives him access without anybody knowing about it.
These devices are going to be typically ‑‑ are typically reused from test to test, client
to client, I don't know, but they probably emptied your wallet over there at the vendor
area when you bought one of these things. So you're not leaving it anywhere permanently,
probably, unless you're very malicious and you're profiting enough from one of these
to buy 50 more. And so when you're using this thing ‑‑ but most pen testers are going
to want to pick this thing back up and use it on their next client's engagement.
So between these tests, are you wiping it? Do you know how to wipe this thing? It's an
embedded device. The clean‑up procedure on it may not be completely obvious as it
would be, you know, where you can just blow out a new installation of Windows or something.
It's probably a little more complex than that. And are you actually bothering to do that
from client A to client B? And that ‑‑ we can use that to our advantage when we
attack these.
From here on out ‑‑
I'm going to take the stance of an attacker attacking pen testers because, come on, they
deserve it, right? All right. So now we're going to put on our black hat. And this is
the only free image of a cool‑looking black hat I could find on image search. I like
this guy. He looks cool. So you put on your black hat, and we're going to talk about hacking
a pen tester's implantable device either in the field or on his bench. So the attack
is fine and dandy if you see this on a client network and you can compromise it using this
attack. But this attack can also be used if the pen tester is testing the device or
provisioning the device for a new test on the bench in his lab, getting ready for a
penetration test. It actually might be even a little bit easier due to the way that we
do this attack. The benefits of an attacker doing this are great. So the implementation,
implication of breaking into one of these devices and before I get any further, if you're
running a Wi‑Fi pineapple you might want to turn that off pretty soon unless you want
it bricked. Because somebody in here is going to do it. And they're going to do it fast.
The implications of owning one of these things is one, we can intercept things. So if a penetration
tester is doing the work for you, he's scanning for vulnerability. He's breaking into systems.
I don't have to do that now. So I just collect what that penetration tester is doing for
me. And we can modify these results. So let's control what gets back to the penetration
tester. He popped root on the database server. Cool. Let's not let him know that and let's
keep that for myself. And so we can filter these results. And it never shows up in the
report to the client. And everything is cool. Yeah, that database is totally secure.
Okay.
We can camouflage ourselves. Maybe the pen tester sucks and he's not running all the
attacks that you want him to run. Well, just launch your own attacks from the device. And
the thing is supposed to be launching attacks. So nobody is going to care. And so your attacks
are part of the test at this point. And it's also competitive intel. If you've got a really
clever pen tester that leverages mode A, you steal it. And essentially this is the gift
that keeps on giving. You can do this again and again. As he reuses
that device across multiple clients, you can maintain access to these organizations. You
can get back into the pen tester's company's network whenever he takes it back home and
plugs it up again. Cool stuff. So there's difficulties in preventing this
sort of thing. And the reason why these sorts of systems have these vulnerabilities is because
there's very small platforms and they're running sort of off the top of these servers. And
shelf penetration testing tools. These tools are ‑‑ I mean, attack tools are great.
People write quick Python script to leverage some particular vulnerability or some particular
network attack or something like that. It will work. So everybody starts using it. But
the problem is, as soon as it works, we're very fickle creatures. We get something working
and then we move on to the next attack. So we don't exactly do a whole lot of testing.
We don't really think of the attack surface of our tools. So if you think about penetration
testing tools, you're connecting to all sorts of services that are not under your control.
These services is, you know, implement protocols probably to a level that even your attack
tool doesn't fully implement. You're pulling in data from lots of sources.
You're parsing that data. You're parsing file formats. So your attack surface is essentially
your entire code. If it didn't have to do with processing things from another service,
your code wouldn't be doing it. So essentially a vulnerability in any part of your attack
tool really opens up for you. Most of these tools are proof of concept tools and that's
always a disclaimer. That's always my disclaimer when I write a security tool is this is a
proof of concept. I got it working and then I stopped.
And I'm as guilty of this as anybody.
So the disclaimer there is don't use this in a production setting, don't use this in
your production malicious attack, your production penetration test, unless you fully understand
the implications of what you're doing and you can control it.
But unfortunately these things are open source and folks who put together these small embedded
attack appliances will take these open source tools, put them on the devices as is and wrap
a user interface around it and send it out.
So there's no ‑‑ at no point in this process is there any kind of audit of what are the
vulnerabilities in these tools.
These are very small, weird platforms.
ARM is getting less and less weird, I guess.
But these things are not ‑‑ you know, these aren't PCs.
These aren't ‑‑ these aren't ‑‑ you know, these aren't PCs.
These are outside of the comfort zone of a lot of the people who are using them.
So once you get these tools running on that platform, then you just pray to God and you're
like, all right, that's great.
Let's just move on and do something else now.
When you send these things out, they're out of your physical control.
So obviously unless you're implementing some sort of encrypted file system on this thing
and even then how would you do it, I mean, where's your key?
Who's going to type in a key on this thing once it's out there?
So it's hard to protect this thing once it's out of your physical control.
We know ‑‑ I mean, we have access to a computer.
We have access to a USB port we're in.
And finally, like, the update procedure for these things.
Once they work, they work.
The chances of somebody, you know, actually seeking out between tests the new firmware
for their pawn plug, the new firmware for their mini pawn or raspberry pawn or whatever
is very slim.
As long as this thing is working and doing the job.
There's not a whole lot of chance that they're going to think to go out there and look for
it.
So it needs ‑‑ if you're going to do something like this, it needs to be an automated
update procedure.
But you can't have automatic updates on one of these devices out in the field.
That will be a whole new attack surface for me to talk about next year.
So these things will run old code.
And they'll run old code for a very long time.
Security geeks are easy targets.
So there's ‑‑ it's hard ‑‑ there's another problem.
I talked about the problem of the naming scheme for these types of devices, you know,
Dropbox being taken.
And so I'm going with the wordy attacker implantable devices.
There's also a similar semantics problem with doing research on this problem.
So if we're talking about finding vulnerabilities in vulnerability analysis software, that's
a really tough thing to Google.
Finding exploits in pen testing software.
Very ‑‑ not exactly the easiest thing.
But it's a really tough thing.
But there's a lot of it out there.
And there's a lot more that's yet to be found.
So I'm not sure who is currently working on breaking things that break things.
But there's a lot left out there.
You're already familiar with the million, bojillion, wireshark vulnerabilities out there.
And that's very typical of this genre of software.
We're talking about things that implement protocols, parse things and have a huge attack
surface.
We have, you know, vulnerabilities.
We have some screenshots of the titles of talks that are here at DEF CON and back at
Black Hat this past weekend.
So the tools that security geeks use are no less vulnerable ‑‑ are perhaps even more
vulnerable than the tools we're attacking because there just hasn't been enough attention
and there's not been enough audit on these tools.
Okay.
All right.
So the case study for this, and I'm picking on the poem plug for this, but honestly, these
same problems exist in other devices.
I'll talk about that in a little bit.
But today we're going to be playing with the poem plug.
I have one plugged up underneath the podium here and wired up and everything, and hopefully
it will behave itself long enough for a good demo at the end of this.
What we have is a discussion of the forensics of it and a demo of a counterattack against
this thing.
It will be a straight‑up attack against it.
It depends on how you look at it.
So for forensic acquisition of a poem plug, this is what I do the first time I get a
hold of any new devices, I want to know how to perform a forensic analysis of this thing
which involves imaging it, which basically gives me something that I can go back to the
original state of the device when I screw it up, when I attack it.
So forensic acquisition is always something that I'm interested in.
There's explicit detail in the white paper.
paper for this. I haven't looked at the DVD. My retina doesn't have a DVD drive on it.
But the DVD that came with the conference materials has the white paper for this. It
has these slides. It has all the attack code and payloads and all the crap that you need
to do this stuff for your own. But the white paper has all the stuff about the forensics
of this. So I'm not going to go into all the different U-boot commands and things like
that. But the essential step for this is the essential
idea of this is that the poem plug, which is based off of the Shiva plug platform, so
if you want to play around with these devices, you can just buy a little $99 Shiva plug.
Honestly, nowadays you're better off with a Raspberry Pi or something.
The idea is this Shiva plug hardware that the poem plug is based on can boot off of
a USB drive if you ask it to nicely. Essentially you can grab a Debian image for
a Shiva plug, which will have everything you need to DD a drive.
And more importantly, you're not relying on the file system and tools that's already on
the poem plug itself. You can boot it up into the serial console, interrupt U-boot,
tell it to load a kernel and a file system off the USB drive and go.
And it will boot up into your USB drive instead of the Shiva plug.
So you can play around with some alternate firmware for this thing without blowing away
the base instance. So you can play around with some alternate
firmware for this thing without blowing away the base instance.
So you can play around with some alternate firmware for this thing without blowing away
the base instance. But more importantly for forensics, you can
DD the root file system once you get in there.
Now it turns out it's just as well on this device just to copy from root down.
Since for the analysis of it, the UBI file system that's on these devices and other similar
compressed file systems are on a lot of these embedded devices.
Our options for forensic analysis on these are kind of limited.
So there's lots of compression on these. At any given point, you don't necessarily
know exactly how much free space you have. It depends on what you're storing, really.
The flip side of this for forensics is you can probably forget about recovering deleted
files on this thing because the whole thing is part of this sort of compressed image and
if you lose chunks of it, you know, you're basically out of luck with the rest of it.
The rest of it is just noise. So there's really no tools for doing good forensic analysis.
Things that I know of right now for recovering deleted files and things like that.
But if you have the file system image, which you can then blow out to another phone plug
if you wanted to, so that's useful, you can use MTD utils on Linux to mount this image
and start processing it at the logical file system level.
You can go through and look at the files and things.
These devices support attached storage and the storage on board most of them is fairly
limited.
Talking about this is doing forensics on the little small USB drive that's hooked up
to this thing is going to be a lot easier than doing the forensics on the device itself.
And it's going to be standard procedures, you know, pop the thing out, hook it up to
FTK manager through a write blocker, if you please, and start analyzing it.
Chances are it's going to be a normal-ish file system. It's going to be EXT or FAT32
or something like that.
And the cool thing is, is the stuff that's going to be on that, that's going to be a
real goods there.
That's going to be all your packet data and things like that that aren't necessarily feasible
to store on the internal storage.
The cool thing about these devices is anything that's different from the base image on one
of these phone plugs is likely to be of interest to you because it's something that's changed.
It's something that's a result of the attacker using it or a result of the tools that are
running on it.
It's a result of network traffic coming into it.
So what you can do is you can take that file system that you've acquired and run it through
FTK or whatever tools you have for making a known file hash set, hash all the files
on the base image.
You can download the base images off of Pony Express or whatever.
So you have that hash set and you look at this file system and you blow away everything
that matches the hashes in there.
I don't care about that.
That's the same as the factory config.
Then the files that are left are the files that are going to tell you something.
Cool stuff.
Now we're going to get into attacking these things.
We're going to put our black hat back firmly on and we're going to attack some penetration
testers.
The particular exploit that we're dealing with here is in the phone plug user interface.
So congratulations for those of you who bought a Shiva plug and put the community version,
the free version of the phone plug firmware on it.
You're not vulnerable to this.
Okay.
So this is only in the interface, the web-based interface that's on the commercial versions
that they sell to you.
So this plug UI or ponix, I've seen it called both things in different parts of the documentation.
This user interface is a web interface for the commercial version of the phone plug.
And it lets you do things like turning on passive recon so you can sniff HTTP requests,
look at the passive OS discovery stuff.
Set up the reverse tunnels.
And so there's all sorts of fun things that this interface can do.
They tell you in the documentation when you put this thing into stealth mode, if you're
going to have it in stealth mode in an organization, this interface isn't up and going.
The problem is you can't do some of these cool graphical things.
So a lot of people aren't going to put it in stealth mode.
Who cares if it's noisy?
Another thing is when you're setting it up on the bench back home.
Back at your lab or whatever, chances are you're going to be using this interface.
So how do we break it?
So we have a bunch of boring vulnerabilities.
So yes, I did get a DEF CON talk accepted for cross-site scripting.
These are very boring vulnerabilities.
They're easy vulnerabilities.
So if you haven't attacked much, you're going to be able to follow this.
We have three different vulnerabilities in this.
We have some cross-site scripting.
Boring.
Cross-site request forgery.
That's everywhere.
And sort of interesting, we have some command injection.
So we can run commands on this device.
That's kind of cool.
But you have to be logged in to do it.
So who cares?
But if we combine these X points, let's say our cross-site scripting is triggered by an
injected packet that we send to this thing.
It doesn't have to be directly to it.
It can be anything that it sniffs.
So we send a packet to this thing.
So that's a cool way of triggering XXS.
Cool.
Better than phishing emails or links on Twitter and things.
What if our XSS payload triggers the cross-site request forgery vulnerability?
So we have one page on the interface that's vulnerable to cross-site scripting.
That payload hits another page that we can submit forms to on the behalf of our penetration
tester.
Cool.
What does that get us?
Well, our cross-site request forgery is in the page that has command injection.
So why don't we have our cross-site request forgery vulnerability, our payload, go ahead
and inject a command for us, again, on the behalf of the penetration tester that's logged
in.
As a result, we get remote root.
So cross-site scripting leading to remote root on this.
And it requires a little bit of setup.
It has to be the star's line.
But it's pretty realistic.
And I'm going to make you all watch that slide again because the animations are cool.
Boom.
Okay.
Thank you.
Thank you.
Thank you.
It's all down to keynote on that.
I didn't, you know, I didn't render that fire myself.
So here's your payload.
This is what you send in the exploit packet to the device.
This is what you're going to pass into HP to get this thing rolling.
So this part of it right here.
It just passes the regex to get it on to the passive recon page.
This is what it's looking for in a packet.
You know, you might want to make something a little more believable than user agent high.
This is the bit that you need to get cross-site scripting going on.
Everything inside of that is going to render in the page and we'll see that in a bit.
The cross-site request forgery in here.
We've got a form in here and you've got a whole bunch of crap that you have to fill
out for this form to actually take.
But we submit this to the SSH tunnel set up page on the pawn plug interface.
And it goes ahead and submits it on the penetration tester's behalf.
Then finally the command injection is in there.
And this can be in any field.
These same vulnerabilities exist throughout this interface.
So basically you can mutate this to go to basically any page on the pawn plug.
So basically what we have here.
We say the SSH tunnel IP address is now semicolon CD user bin, W get my malware, run it, remove
it and keep going.
So what are we run as a result of this.
We're not alerting XSS here.
We want to do something with this.
So there is some proof of concept, you see my disclaimer proof of concept.
Don't run this in the real world or you will get owned.
My proof of concept malware.
It's not specific to this device, you can not adapt this to anything, it's just a crappy
little Python script.
But it's a little bit better than alert one, alert XSS.
It cleans up a bit after itself, it installs itself into user bin, user S bin, it sets
up some persistence in RC local and cron and all that crap to make sure it keeps running.
It sets up a lock file so it doesn't run more than once at a time.
The PwnPlug specifically disables the bash history for the root user, I go ahead and
reenable that so I can keep up with command logs.
And occasionally it phones home and tries to get more code to run because that's awesome.
And every so often it gathers a process list, command history, file listing, set of network
interfaces and connections, all the log files for the most interesting tools in the PwnOS
and wraps it up and sends it to my FTP.
So this is something that you can kind of start from on this.
So the demo for this, there's everything you need to replicate this on the DVD.
You need a floor model or above PwnPlug, an actual commercial PwnPlug to replicate
this.
From those guys at the vendor area, tell them I sent you.
Tell them if there's a patch for this to give you the old one so you can play with this.
Or just use an unsuspecting friend or enemy.
So we're going to bounce out of here and hopefully this demo will work.
If not, I'll have a recording.
All right.
So what we have here is ‑‑ and we'll take you on a tour of the different views
here.
What we have here is our hapless penetration tester setting this thing up.
Over here we have our attacker basically with, you know, where he's launching the attack
from.
and the web server that's hosting the stuff off of the FTP and some info on what's going
on here.
The players that we have here are the PwnPlug on 10, the pentester slash victim on 15, and
the attacker here on 20.
And here we have basically a view on the code of the PwnMon software in case I want to refer
to anything for y'all.
What we're going to do, first off we're going to start up our attacker web server so that
we have this ‑‑ I'm going to show you what's in here right now.
The UBI.py ‑‑ now, these UBI file names, since I had to do a bunch of research to figure
out what the hell is going on with the UBI file system, I figure adding some more UBI
named commands to this operating system is a good way of hiding my malware in that none
of it makes sense anyway.
We have UBI.py and UBI mount here.
UBI.py is the name of the UBI.py server.
UBI.py is the PwnMon malware.
UBI mount is the command that ‑‑ or the file on the web server that PwnMon occasionally
pulls for new commands and I'll show you what's in that.
Okay.
You know, classic, you know, buying shell type crap here.
We're going to host this web server.
If you learn nothing else from this talk, you can set up a web server out of your current
directory with just that command.
And that's just tons of fun.
It beats setting up Apache or whatever.
Don't run your blog off of it or anything, but payloads are great.
So that just fires you up a web server on port 8000.
Cool.
Let's see.
The PwnPlug is still awake.
That's good.
We have our FTP dead drop here where it's going to go.
And everything seems fine.
So we're going to be the hapless penetration tester again.
And we're going to turn on the ‑‑ under plug services here.
We're going to turn on the passive recon stuff.
Oh, dear.
We were already ‑‑ I may have already triggered the vulnerability.
That's cool.
So he's going to enable this.
And we're going to see here in a second whether or not that's actually ‑‑ so we're enabled.
We're going to see over here ‑‑ it hasn't requested anything yet.
That's good.
It might not.
So what we're going to do is we're going to ‑‑ we have our exploit payload there which I
reviewed with you.
And just a simple HPN command sends this out.
So there's a trick to this.
We're sending it ten times because it's kind of goofy.
The passive recon page is pulling from a log file.
And unless you send ‑‑ unless there's a good bit of traffic on the network, it takes
a bit for the buffers to flush and for it to actually show up in the page.
So I just send it ten times.
The exploit is set not to run more than once anyway.
Sometimes it will request two of them, but whatever.
So we're going to ‑‑ I'm going to do this.
I'm going to blast that out.
And while that's going, I'm going to set up inspect element on this guy right here so
we can see it when it shows up.
All right.
So let's inspect right here.
So what we see here is our, you know, cookie high form, all that crap going on there.
So pretty soon we should see a request here and we have.
So the ‑‑ okay.
So cross site scripting vulnerability has ‑‑ come on, get me off the blue screen here.
Unhighlight all.
All right.
It has set up a standard reverse SSH shell of get all my crap.
And that's scheduled to run every minute.
And thankfully it's already run.
Sometimes if you hit it wrong, I'd be standing here and have to tell you a joke or something
before it actually does anything.
But it's gotten the UBI mount script for coding.
Hard to run.
It's already phoned in with a ‑‑ basically a tarred up image of all the cool crap on
the plug.
And so let's take a look at what we've got here.
With the UBI mount, we should have a reverse shell running.
So 192.168.9.10 on port I think it was 9,000.
Yep.
Drum roll, please.
Root.
I've always wanted to do that on stage at DEF CON.
All right.
So over here at our FTP dead drop, this is actually cool.
Who cares about getting root?
We want to get stuff, loot.
All right.
So what we have here, and this is actually kind of funny, the phone plug isn't so hot
on its realtime clock or anything.
So this is time stamped.
So with Unix time stamps.
And you'll notice I have the underscore and a dash here and I was like, I fucked up in
my script and I have a dash in here also.
No, that's a negative time stamp there.
So my phone plug has lost its shit and we'll see what it thinks the time is.
Oops.
What?
Oh, what?
What the hell is going on here?
Oh, I see.
It's already grabbed another one.
Okay.
We'll grab that one.
Implausibly old time stamp, 1946.
We have defeated the Germans and now we're wrecking shit at Bletchley Park, I guess.
So what we have in here, and you couldn't see it from that because it was complaining
about the time stamps, is we have, you know, a listing of files, interfaces.
Logs from Metasploit, John, Bluetooth.
We've got the command histories and things like that on here.
And everything on this device runs as root.
The web interface is running as root.
So there was nothing to keep us from doing any of this.
And that's about it.
The whole thing is broken now.
And it takes like ten minutes to get everything back into a good state.
So I'm glad that worked.
So back to my slides.
My slides, wherever those are.
And so for conclusions for this, these attacker implanted devices can provide good counterintel
info.
If you find one of these in your organization as a defender, it's a curse, I suppose, depending
on what they've already gotten.
But you also have ‑‑ you know that somebody was there that's going against you.
And also you've got all the tools in front of you that are necessary to start counterattacking
this thing.
The forensics want to figure out who is doing this to me and why and what are they after,
what have they already got.
For those of you who are pen testers out there, for those very few of you who actually
said that you're going to use these devices for good, know your tools, test your tools,
use them safely.
Hell, if you're an attacker, do that.
Monitor carefully and clean up between engagements and things like that.
You need to be a little more literate with your penetration testing tools than simply
using them.
You need to understand how they work.
You need to maybe even try breaking them every once in a while.
And for breaking things, people who break things, pen testing tools make good targets.
So with that, I appreciate you all coming to my talk.
There is no Q&A room.
So you're just going to have to track me down before I go off and get bored and do something
else.
Thank you.
Thank you.
Thank you.