JOSH "m0nk" THOMAS: I'm Josh Thomas, m0nk.
A couple of intros to the talk.
I made a drinking game and then it got really lame and I don't have anything
to drink on stage.
But if you do and want to play around, this is Ricky.
Ricky likes to drink.
If you see Ricky, take a drink.
He'll come up a lot.
So ...
This talk has a couple faces, but before I even get started
with the actual talk, hands up if you are on Android.
All right.
Hands keep them up if you actually have your own kernel.
Okay.
Did you actually compile it?
Okay.
Did you ever look at the source?
Like any source at all?
Wow.
Okay.
All of it?
(Laughter.) Yeah.
So you have no fucking clue what's running on your phone,
that's we'll come back.
(Laughter.) Like even if like someone was in the room like,
yeah, I looked at every fucking line, no, you didn't.
Sorry.
(Laughter.) And we all know that.
But this is this talk is going to play with what you don't know
about what's already running on your phone.
So start.
I wanted to skip this because personally I really don't
like these slides.
But given what I'm going to be talking about,
I guess I needed a little bit of background,
so why you should trust me.
Don't if this makes logical sense to you thank you, man then believe me.
If not, have fun with the tools I'm going to show you.
These are my opinions, not my employer's.
And the tools on the second half of the preso are really, yeah,
they're fun, they're playful, they're offensive, whatever.
The whole point of me open sourcing them
is we don't know these type of tools exist, let's learn
about these tools, let's figure out how to protect against them.
I'm not really talking 0 days.
We'll get to that in a second and I'll get on a tirade.
But this is post 0 day, post EX.
Like I'm in the system.
We as a community don't really ever look at that type of persistence
and how to protect against it.
So I'm going to show you how I as an attacker would do things
and maybe we can all start figuring out to how to protect against me.
So I'm going to talk about boring ass things.
I'm going to talk about the actual WarGames that we're
going to talk about today and then today,
and then we'll go through a couple scenarios
on my tools and what they do.
Then we'll wrap up at the very send, so.
Boring kit.
I hear malware, I hear rootkits, I fucking think spam, it's boring.
It's really, really boring.
It makes money.
You know.
Someone wants to pop 50,000 boxes so
they can do something, blah, blah, blah, blah.
It's boring.
It's not not interesting at all.
But hackers love the malwares, right, because with the malwares you can get
the credit cards and then you can buy all the things.
Again, fucking boring.
(Laughter.) So it is.
Right?
I mean it's not innovation.
There's nothing new.
It's normally not actually anything sexy at all.
It's just iterative, boring.
You don't have to do anything cool
because you don't really care if your bots get popped, right?
I mean that's that's not the point.
You know you're going to lose them.
You know you can just pop another 50,000 next month.
It just goes back and forth.
Everything is disposable.
No one is specifically targeted.
Boring.
If you want to know more about that mentality, Mudge did
a great keynote two years ago.
Pretty much everything he's talked about since then talks
about that symbiotic relationship and how that's boring.
Whatever.
Our real fun.
For every game, we need rules, right?
So what do we need?
We need two players, we need game mechanics,
and we need goals for a game.
Player one.
I wonder who player one is.
I'm going to go with player one is any government worldwide,
any state sponsored organization.
So you're talking people with a lot of money or corporations
with a lot of money.
You know.
Bad guys.
Right?
Maybe more bad guys.
Prepping for it.
Maybe more bad guys.
(Laughter.) Player two.
So we've got a lot of money on player one.
Who's player two?
Oooh, fucking you and you and y'all.
It's pretty cool.
So in this game, when we start getting into mechanics,
we still need 0 days, because we want to pop things.
We're starting to target people for some reason.
So we still use 0 days, but really that's just the gift wrap.
That is disposable.
No one cares.
Well, a lot of people care and I'm trying to get you to not care so much.
What we really want is we want to get on devices.
That's the only reason we use 0 days.
0 days are not the real point.
They're disposable.
I'm going to spend money on an 0 day to get on your device
to then do something interest.
But because everyone likes to use 0 days ,and I'm saying it
a whole bunch, how much do they cost?
Do they cost money?
There's the Grug, with more money.
And fuck it, more money, right?
So Rick Ross is happy because there's a lot of money.
But I mean, again, it's, you may spend 10, 20, 30, 50K, 500K,
a million on some really sexy 0 day.
Remember that number, a million.
We'll pretend that all 0 days sell for a $1 million.
Every single 0 day is a $1 0 day.
I want to hack all the things ,so I need all the 0 days.
I don't really care about laptops anymore personally.
This is where it's at to me.
It's all mobile devices, it's all cell phones, they have everything.
I can listen to all your calls, I can read all your e mails,
I know exactly where you are.
I mean it's obvious, this is now what used to be our computer,
this is now us in digital form.
We carry them everywhere.
We use them for everything.
Oh, if you're targeting Symbian, 0 days are still worth $1 million.
But fuck it, right, everyone raised their hand, I'm Android,
I'm special.
There's no exploits there.
Sure.
And let's unless, you know, I had money,
at which point so we've got game mechanics for this type of world.
What we're really doing is taking an 0 day, we're jumping on the device.
So what I care about is that kit, whatever that implant is I'm putting
on a device, that is that's where the real money is.
That's what's doing something.
And let your minds run wild, what would you want to do
on someone's phone.
You know, whatever that is, that's what you're doing.
Doing that type of coding is boring.
Those are just lame ass developers in cube farms cranking out code.
It's typical software.
It's boring.
It takes dev time.
People have a real job.
But it costs money, too.
Typically it costs a lot more money than an 0 day.
Typically it costs a fuck ton more than an 0 day.
Think about it, right.
If you're trying to do something sexy, a million dollars for an 0 day,
$20 million for whatever you're going to do,
what do you want do you not want to lose, especially
if when you bought that 0 day it's got a shelf life.
What you really, really, really care about is protecting that large
investment, not this disposable thing that you bought that, I mean, you know,
may be around two months, may be around six months.
So we get a little more disturbed, and that's okay.
What do we want?
We want all the data.
That's what your cell phone is, that's what I want.
I want everything.
So we've got all of our players; let's have a game.
Who's gonna win this game?
How long is it going to take?
Very, very, very short, and I wonder who won.
Yeah.
They won, every time.
They it's no one is even remotely capable of writing
the tools right now that detect against advanced things,
because we're not looking at it.
We're still focused on malware and spam and all the boring shit.
So if I'm writing $20 million worth of code, I want
to protect that investment.
I want to protect it lots.
I want to make sure that it's never found.
I want to make sure that it's deep, it's not something that's going
to pop up on McAfee, it's not something that's going
to pop up on the "New York Times" front page
that we found X doing Y.
Like this needs to never, ever exist.
So, again, because we kind of picked on him a little earlier, he,
the Gruck, actually does talk about quite a bit of these things,
at least on the theoretical thing on Twitter, which is always kind of fun.
But what we don't want is we never want our gear to show
up because that will make Rick sad, and we don't want a sad Rick.
We want a happy Rick.
So we're gonna hide.
We're gonna hide deep.
We're gonna have a lot of fun hiding.
Before I move on, one definition, because I just tend to say it
and I've realized that not everyone knows what I'm talking about.
So if I say air to glass (Phonetic), what I mean is I'm coming off CDMA,
GSM, Wi Fi, I don't know, I'm coming from somewhere bluetooth,
outside of the phone, I'm getting on the phone.
Air to glass means I never touch storage.
So I've got an implant, it's in a device, you reboot that device, it's gone, right.
It's got to be reinfected.
If you do something like that, though, you're pretty damn secure
on the protection of your investment
because unless someone can forensically jump
in there and grab things out of RAM, volatile memory before they reboot,
you're safe.
The problem with air to glass is, I mean, you never know when you're going
to lose your implant.
That sucks.
And you've got limited space, right, if you don't want to start interacting
and being obvious that there's something wrong with the phone.
So WarGame one, let's move away from air to glass.
How can I get something on disk and hide it to where no one can find it?
So this is the NANDX Project.
This project was originally funded by DARPA's Cyber Fast Track.
Awesome, awesome, awesome project.
The goal of this was how can I do a proof
of concept for offensive work and then how can we take that
and try to defend against it?
So I'll do my demo.
So I'm going to run the demo twice on video and then once
at the beginning and once at the end of talking about it.
So what we have on the oh.
Is it not showing up?
Cool.
So what this video is going to do, yeah, I'm basically side loading
a kernel module, which we'll talk about and look at source in a second,
but this is going to kill a block on NAND.
So I've got an implant that's actually on disk, it's saved on disk.
Now I'm going to remove that block of memory from the phone.
I can still call in to it, but it doesn't exist.
DD won't pull it, forensics tools won't pull it.
It's just gone from typical devices.
I show this twice because I just really love how sexily
Android crashes here.
So we're side loading kernel module remotely.
And I'm forcing a kernel panic or a kernel thing as well.
And we reboot eventually and the block of memory is just gone.
Now I've got 512K I can play with for as long as I want.
How do I do this?
Sweet.
How NAND works, let's start there.
So NAND is very complicated.
You've got little bitty buckets that hold an electron.
If there's an electron on there, you've got a one.
If there's no electron it's a zero.
That's basic binary.
That's how this hardware works.
EEs decided to say, hey, these little buckets that hold one bit
need to be organized into pages.
Those pages are then logically created into blocks.
Blocks are pretty easy to deal with, it's what you're normally dealing
with if you're writing drivers at a block level.
I mean it's it's easier to latch on to for us
as security and software guys, right.
So block's typically half a meg.
When you wipe a NAND, everything gets set to ones.
The reason everything is FFs is there's an electron
in every little bucket.
Then when you're actually writing data to NAND,
you start popping electrons off.
You get a zero, so you kind of sculpt your data in NAND.
But that's trapping individual electrons is hard, right?
So the hardware wears out.
It dies over time.
I'm taking advantage of that the same way that the designers
of the hardware take advantage of that.
What they do is they know it's going to die.
They know it's going to die after 10,000 to a million writes,
that little bucket, so they build in tools to gracefully fail.
They have a threshhold of I can detect so many bits aren't
writing what I want them to, once I go past that threshhold,
that block is marked bad, it's never used again.
The kernel doesn't see it, the driver doesn't see it,
it's just there's a bit that gets flipped saying I am bad
and it's never touched again.
Anything that goes through the driver, the very first thing
in the driver code goes, is this block bad?
If it's marked bad, the driver just says, no, it's not there.
So that's handled in the bad block table, which is typically stored
on NAND itself, right.
So NANDX has a table somewhere saying you can trust
this block, you can't trust this block.
In NAND there's two types that we see.
Typically we see managed NAND, which has a little embedded controller
where all that logic goes.
On some NAND, like Sony phones, that's actually built into the kernel.
The kernel deals with it.
For how NANDX works, it's really irrelevant where that code is.
The code that's open source on GitHub is attacking
the raw NAND just because it's easier to stand kernel NAND, everyone kind
of gets that better.
Raw NAND has a very complicated driver
because it's got to do all this wear leveling and
all this bit checking and ECC values and whatnot.
Wear leveling is proprietary and closed and we don't really care
about for this.
I go into way more detail in other talks, so if you are interested in this deck,
it's also online.
But we're going to attack the MTD subsystem, which
is like this super epic massive driver for Linux that a ton
of things are run through.
I'll attack it again in a little bit.
But for NAND, it manages how everything is working.
So we can get into that driver and start arbitrarily saying this block
is bad, but go ahead and let me write data to it,
go ahead and let me read from it again, let's just make sure no one else can
but me.
Can we do that?
Yeah.
Thanks.
So if I went in to hide a NAND in general, you know, once you kind
of figure out blocks get marked bad and then they disappear, yeah,
I can do that at a shit ton of levels.
I can do that at the file system, but then the file system has
like trailing pointers and stuff to data that just got removed, which
is why you see that horrible crash on screen.
MTD subsystem is much lower.
It's clean.
I forget the actual number of lines of code that I had to change,
but it was like 30, something like that.
Like it was tiny.
And then I've got fault control.
So it's in Android.
It's also in Linux.
So any device you see that's running Linux or a Linux variant
or pseudo based off Linux, start thinking schema.
Everything that's running the hardware is susceptible
to this type of attack.
Everything that is running software pseudo based
on this code is also susceptible.
When I started the project, I expected full hardware.
I didn't have to do that, I just had to buy a shit ton of phones.
I bought a ton of phones, started playing with them.
I found one that had full MTD, like the whole NAND was basically
managed by MTD.
There was no I was like, sweet, this is really easy to code on.
I created a couple unit tests because that's what you do, right.
So I created a unit test that basically just killed,
arbitrarily read and wrote data to a block of NAND, marked it bad,
checked that nothing else could see it, and then read and write again.
Yeah, so the code was ungodly simple.
And if you are actually interested in how I'm pulling it off,
I spent more time writing notes in the source code that I checked
in to GitHub than I actually did the coding.
It's I tried to just walk line by line of exactly how everything works.
But in a nutshell, I'm grabbing a block, I'm erasing it, writing dead beef
all over it, I'm making it disappear from the system,
writing dead beef again and then reading it back out just
to kind of show that we've got full
arbitrary control.
Oh, and for the demo, then I'm doing a double release
on the driver just to force a reboot of the phone because when I do that,
then it reads back the bad block table from NAND and
the thing disappears.
So the demo that I have the video for kill block 37, just kind
of arbitrarily picked that block, that's where a system or, yeah,
Android.settings is stored, so it's no longer there.
That phone is I've got it with me if anyone wants to play with it.
It's quirky.
But, yeah.
So I can take data, it's gone from the system and yet I can still
arbitrarily read and write.
I took these phones after I did this full factory reset,
dead beef is still there, you know.
DD, didn't see dead beef.
Ran mind tools, saw dead beef.
Another factory reset, you know, throw other RAMS on there, do
a whole bunch of things, the phone is completely stable and it's just dead
beef all over it.
I've got like a quarter of the NAND that's just dead beef
and nothing sees it.
That's pretty fun.
(Applause.) JOSH "m0nk" THOMAS: So since I'm running a little fast, one
of the other fun things you can do with this is I'm making drives disappear
half a meg at a time, and after half a meg I'm forcing a reboot.
But you don't have to.
You can just disappear the drive under the OS.
You can disappear the whole damn drive and nothing can
recover that that device at that point.
It's just gone.
When you start talking cell phones, it's like, dude, that fucking sucks.
That's like 600 bucks, it's inconvenient, you get pissed off.
If that's SCADA, like that gets scary real quick
because it's remote.
I don't care if it's remote.
I mean, and it's not patchable.
You can't recover because there's no drive there,
like the hardware goes Mo dude, there's no storage space left
and it's just dead.
You've gotta replace the device.
So ...
yeah.
So that was the first cool.
Yeah.
And it's all on GitHub if you want to read about it.
I've got links, but it's basically my name
and then NANDX.
I've got a paper that goes into great ridiculous detail
on how NAND works and then a bunch of source code and
the presentation and it's out there.
There's no fix that I can see.
So since this is kind of an offensive for defensive type of a talk,
if you can think of a better way to protect against this, I'd love
to hear it, I really would.
Because it's based off an assumption that
the guys that originally sat down with pen and paper
on a napkin and figured out how NAND would work,
they made an assumption that it had to fail, and I mean, the hardware
is based on that.
The hardware is built on that assumption.
The software on top of it is built on that assumption,
and there's nothing that can keep me from taking advantage of that.
So as long as there's NAND around, we can hide and we can hide deep.
None of our tools can pull it out right now.
Any tool that you can start kind of thinking
about how I could protect against this starts failing real quick.
Yeah, I can wipe everything on boot that's in a bad block table.
Mmm, not really.
You can't validate that since blocks do go bad,
how do you validate that you wiped it or not?
I mean, and if I'm at that low of a layer, I can just block it anyway.
So and that was NANDX.
Second project I'm working on is clock clocking beats.
What this is looking at, it's like, okay, I'm hidden on disk, that's cool.
I still have to run at some point.
I want to be able to run and never have a user be able
to tell that something is going on.
You know, I mean, obviously you like don't want your thread showing
up and things like that.
That's great.
But what if I want to go deeper?
What if I want to make sure that the kernel just has no fucking clue that
anything is running?
What if I want to make the kernel have no ability
to even see that?
So clock clocking beats is looking at taking
a running operating system and slightly tweaking the processer
by overclocking it and then outside of full kernel space,
like in hardware damn near, I'm injecting a second process.
It's a thread that runs outside of the kernel that I
manage myself.
That thread runs my kit.
So no tool that you would write that's running in kernel space remotely has
permission to even see me, like I just don't exist.
I can reach in, but it can't reach out because it doesn't know I'm there
and it has no ability to know I'm there.
That project is at the very beginning and it will be
on GitHub, I promise, as soon as I'm done.
Wow.
I'm going to finish so early.
Burner.
This is the really fun one.
So, like I said, I've got 20 million invested
in whatever kit I'm shoving on to a device.
I'm actively monitoring that.
I know it's getting ready to get found.
I know that it's going to my phone's going to be
in someone's hands that's going to do a forensic deep dive.
Maybe I don't have all that much faith in NANDX anymore.
Maybe someone has figured out how to get rid of it.
Maybe there's other tools.
I want to make sure that nothing that I have on there gets out.
So I want to set the phone on fire remotely.
Fuck it, why not, right?
(Laughter.) JOSH "m0nk" THOMAS: So and I want to do this
all from a kernel.
This will be this project will be on GitHub probably
within about a month and a half.
I really wanted to demo it, but I swear to God it's the lamest demo ever.
It's like side load kernel module, phone turns off.
Like that's it.
Right.
It's hard to show it, it never boots again.
What it does internally is I'm playing
with all the voltages that run internal to the phone,
so I can target specific pieces of hardware, like the chip or
the NAND or the base band, and just start dumping a lot of power
to them and fry them.
And this seems to universally work on almost every Android phone I've
poked at in the run time of this project, which is pretty much probably what you
have in your pocket.
So I can attack and kill your phone dead, make sure that it
will never turn on.
The only way to ever pull data off of it at that point would be to take it apart,
desolder the chips and like put the NAND in a reader,
like maybe you can find me then, but that's that's it.
So now we've hidden, right.
Like I feel good that with those three projects together
you're probably not going to find any code that I'm running at all.
How do we combat against that?
Like us as users and hackers?
Like how do we make sure that shit that's that deep just doesn't happen
to us?
I'm open sourcing everything.
Like that's my solution is at least if I can think of these,
someone else can.
If I can open source them, hopefully at least we start talking about it,
maybe we start looking for things like this and at that point we're
at least a little we at least know where to look for security,
because we're not right now at all.
And maybe it will make us work a little harder.
So I felt pretty good about this.
I was like, yea, I'm awesome!
And that's pretty much it for me.
I'm ungodly early, but I'd love questions.
(Applause.) None?
Someone ask me a question, please.
(Laughter.) What's up, man?
(Inaudible).
JOSH "m0nk" THOMAS: So could a phone manufacturer, or anyone really,
write a driver that just wrote 0s to every bad block?
That answer is most definitely yes, but it doesn't work.
The reason it doesn't work is hardware tends to fail, right.
So you cannot rely on that bucket having or removing
to electron once it's failed.
So if I've got this low level of code, I don't have to store data in all 512,
maybe I just hand pick 10 bits per half a meg, at which point it's going
to look like typical failure, but it's not.
And I'm I'm at a lower level than your driver
is running at that point.
So it's erase condition.
But we can talk more because I see confusion
and disagreement on your face, which is awesome.
What's up?
(Inaudible).
JOSH "m0nk" THOMAS: His question was, who calls
into the NANDX blocks after I've wiped them.
At that point, I've got the ability to store a large block of code
on the device.
I'm not necessarily hooked in to things, but now I have I have everything that
I need to run.
So all I need is one little like air to glass thing that then jumps back
in and calls my code.
I don't have to that way I'm not having to fight
like over the wire to hide 2 megs of kit that I can pull down.
I can store it on disk and then arbitrarily call it remotely still.
So ...
Actually I'm just going to like answer, so ...
(Inaudible).
JOSH "m0nk" THOMAS: (Inaudible).
So anything that is NAND based, based on that same core assumption
that we need to be able to (Inaudible).