Here's my plan, right?
We're going to deliver our squirt virus in the email, right?
It's going to live on their mail server until the admin's clever enough to read it.
At that point, we're going to squirt his time.
Mmm, pretty cool plan.
Connect back shellcode out to us, listening on the public internet.
We're going to escalate some privileges, drop out a nice and prepared rootkit.
And then from there, we'll throw him his SSH up good and proper,
sniff his keystrokes, wait for the logs in the database server.
Yeah, it's all good, right? All good.
Those didn't look like email addresses to me.
All right, anyway, so.
Got a brand new Pine 0-8, run it through our mail spoofer,
send him something he's got to read, right?
Now that looks like a compelling piece of email to me.
And we fire up our netcap, and we hang on.
If you notice, for convenience, that's on 41327 instead of 443, but never mind.
And look at that. Shell. Right, find squirt, work perfectly.
Yep. You were the admin? Mm-hmm.
Yeah, he's a clever man, nice username.
Oh, shit, where did Pine go?
Nah.
Ah, look, damn thing dropped core, right?
He's probably going to notice that. He's sitting there, using his Pine, and bam, all gone.
Ah, shit.
So at this point, you know, he's probably going to spot us.
Hacksaw.com, pretty poor choice of reverse, I now admit.
And, ah, yeah, look at that, nice.
Starter Club Shell, he's going to start running around where the core is.
Ah, shit.
So right about now, if you're a clever man, you know, if you're a wise man,
it's time to drop carrier, right?
Plus, plus, plus, ADHMort, just get the hell out of here, right?
Things have gone horribly wrong.
Cool.
Apparently pear shape doesn't translate well into North American English, you know, I'm terribly sorry about that.
But yeah, did you see that? In the PSR I put back there?
No?
Look, look, look, SSH session, root, and then nameserver.
That sounds pretty good, huh?
Pretty good.
I like that.
If I drop carrier now, right?
I'm never going to get a chance like that, right?
Man, I really, really, really wish there was a way I could get to the other end of that SSH session.
It's authenticated, it's already root, right?
I don't even have to goddamn root the box.
All I gotta do is get down that SSH session, man.
If only there was a way.
Like fucking duh there is.
Which is why I'm standing here.
So, yeah, I smacked a few magic keystrokes, a little bit of this, a little bit of that, some bang.
Bangy-bang-bang.
SSH Jack.
Anyway, yeah, so my name's Metal Storm.
My mum calls me Adam.
I'm from New Zealand, which is why I sound a little fucked up.
For those of you who are not familiar, it's a very small island that kind of like connects people to any city in the entire North America.
And, yeah, we have lots of sheep and apparently hobbits. I haven't seen any right now that aren't.
Let me tell you right now, there are no hobbits.
There's no hobbitses.
They don't have preciouses.
They don't exist.
Sad, sad token fanboys.
See, I work for a Linux integrator.
I don't actually do much security for a living, so I'm kind of here in a personal capacity, which is why I can say fuck.
In the past, I've been a corporate or security consultant.
I've done network engineering.
I've done all sorts of stuff.
So, right, what the fuck, what the fuck did we just do, right?
We saw ourselves a pretty classic intrusion, right?
Slightly different modus operandi than you're probably used to, right?
Server box was pretty well secured.
Instead of attacking the server directly, I decided that the best way to do it is to attack the admin's desktop
and then from there to the server.
But there's desktops, right?
I mean, Linux desktops just as much as Windows desktops.
There's a whole bunch of complexity, right?
We don't have clipping, but we do have, you know, lots of candy and enlightenment and things that make your desktop look real pretty.
And all that complexity, all that kind of intellectual candy floss that's there to just rot your brain, right?
That's where all the bugs are.
So, I want to root up someone's big Linux server, right?
I'm not going to go after the server.
It's got intrusion detection all over the place and intrusion prevention like it works.
I'm going to go attack the desktops, right?
That's where it's at.
And certainly people who have Linux desktops, right?
They're real geeky.
They have glasses and long hair and beauty fears and shit, right?
And they look after all the good stuff.
So, that's where you're going to go.
But sometimes, right?
Sometimes you're not perfect, right?
Things go wrong.
In that particular case, you know, we got there.
We got busted.
We dropped Cor.
He's going to know this.
So, you know, you can drop Cor like some sort of little pansy.
Or maybe, you know, do something a little different.
Just play some adaptability.
Something a little new.
When you hack something, what do you do?
What are your goals?
Well, figure out what you want to do next.
Very rarely do you ever, you know, just get root on the box.
You won't.
You won't.
So, yeah, you have to do reconnaissance, right?
You're usually on your way to it.
There's kind of another thing you could do, right?
You could be a good guerrilla star, right?
You walk in there.
You get what you want.
You get the hell out real fast.
And that saves you a bunch of time and effort.
And I'd like to explain adaptability, right?
That's a big difference between all you fuckers and the people they pay to do this for.
At least, the cheap ones anyway.
I don't know.
You have to have a really big name for root and other stuff instead of the stuff you've got.
Cross-host privilege escalation, right?
So, privilege escalation is pretty normal.
You have a user account.
You want to get some root.
That's good.
I think root on another box is just as good as root on this box most of the time, right?
And local root, you know, it can be a distraction.
You're on your way to somewhere.
You don't have time to sit around and root, hit a box up, and drop it.
You know, local vulnerabilities are easy to exploit often, right?
We've got a lot more information.
What's the version stack layout?
You know what we're getting ourselves into.
It can be kind of tempting to sit around and escalate your privileges because you feel good about it, right?
You know, you're achieving something.
You feel good, right?
You feel good about yourself.
Yeah, easy is good. I like easy.
But what if there was something easier than local privilege escalation?
Trust relationships.
It's kind of old school, I know.
We must be, what, five, six, seven years ago talking about trust relationships?
It's kind of old school, yeah.
You know, you've got cross-hosts.
And back when ports below 1024 were just magically rooted.
Back when people exported slash readwrite to the entire world.
That was good, right?
We're just a bunch of long-haired unix hippies, right?
We love each other.
It's all good.
We just share.
You don't mind this space.
It's your disk space.
It makes you feel good, right?
It's old school.
You feel like your mummy's tucking you up in bed.
You know, it's good.
But we called that hacking, right?
That's just embarrassing, right?
That wasn't hacking.
That was just mounting stuff.
How many of you watched Unauthorized Access where a simple nomad goes, like, mount?
And he's a hacker?
Sorry.
You're in the room, so...
And that's my favorite thing about trust relationships.
Instant gratification, right?
You turn up.
There's a trust relationship between hosts, right?
It's like Christmas.
It's good.
Right now.
You get Root on another box.
Or Shell on another box.
It's great, right?
It makes you feel really good.
Traditional trust relationships, right?
I call them long transient trusts for no reason other than that I'm obviously about to talk about transient trusts.
So that's what I'm calling traditional kind of fixed trusts.
Things like host trusts.
Things like SSH key-based trusts.
They're trust relationships that exist as stored authentication predictions.
What Bruce and I would probably call one-factor authentication.
Or it can be authentication based on properties of the connection.
The source address, the whole thing below.
All that sort of thing, right?
Just your traditional run-of-the-mill garden trust relationship.
And then there's trust relationships which are transient.
Which are trust relationships that exist only for a period of time.
And generally the most interesting class of those is post-authentication connections.
Once you've initially carried out your authentication, the remainder of that session is effectively a transient trust relationship between hosts.
Unless you personally authenticate every single packet you send, then you have to accept some sort of transient trust relationship between hosts.
Let's look at a couple of methods, the traditional methods for exploiting trust and transient trust relationships.
And to do so, I picked a couple of methods just out of the air.
How easy it's going to be to do it.
How sneaky it is, how stealthy.
How close to right the fuck now you can do it.
And an overall kind of feeling of feasibility, right?
Because an attack's no use if you're only going to be able to use it one time in a hundred.
So yeah, we're going to evaluate them.
And for the purposes of this, we're just going to assume that we've got a non-root shell on the box.
Right, so your traditional non-transient trusts, right?
It's pretty straightforward.
And our job is to impersonate the credentials that are used to authenticate that connection for trust.
Whether it be by coming through the trusted box, using stored key material like a safe trust, or by spoofing.
And that's pretty straightforward, right? That's easy.
Everyone knows that.
It's pretty sneaky, right?
No one knows that you turned up, sorted all the trust and abused it, right?
It's pretty damn good.
When? Yeah, right now, right?
You turn up, you find a trust, you're gone. It's all good.
But, overall feasibility, it's not simple, right?
How often do people still rely on ports being low 1024, right?
Outside of like bank environments or whatever.
Not that often, unfortunately.
So you don't see this, which is a pity, because I like it.
Right, the other interesting way to attack a transient trust relationship, a traditional way of doing it, if you will, is key log, right?
So during authentication, you log the user's input, either by trojaning SSH having it, listening to your keystrokes,
or by logging it from the keyboard or the hardware keylogger, whatever you call it, right?
Even shoulder surfing, right? Something old school like that.
So you steal the credentials, and then later on, you reuse them for your own good.
Right? Classic technique.
Easy? Hell yeah.
Everyone does it, right?
It is the standard way of getting from one box to another.
Right, stealthy? Sure, you do it, right?
You rootkit the box up, you trojan it, all good.
When, this is the downside of this, is you have to wait for them to log back in, right?
And say like in our example earlier on, right, you're about to get busted.
So if you now go ahead and kill their SSH client, they're not going to reconnect, right?
They're wondering where the fuck Pine went.
So yeah, that's not so good.
Overall feasibility though, it's a really good technique, right?
It's kind of the gold standard.
It's what everyone does.
You can always fall back on a keylogger, right?
It's all good.
More advanced technique, right?
There's a man in the middle, right?
Similar sort of thing, except that we impersonate the server to the client,
and the client to the server.
We sit in the middle, we grab the authentication credentials.
Optionally, if it's encrypted, we have a little bit of jiggery-pokey with fake certificates,
fake host keys, that sort of thing.
And then, later on, we can either sniff their connection, see what they're doing,
and if we're feeling particularly narked, we can take it over.
Now the downside of that is, of course, the user's probably going to notice.
So ease, yeah, it's a relatively well understood sort of thing.
You know, it's not wildly complicated.
The downside is, as people deploy PKI systems, or at least look at their host keys, which I hope you do,
it's not so good.
Stealthy, yeah, same thing, right?
SSH pops up, huge mongers warning, saying, you know,
oh look, someone has messed with your host key, this might be bad.
When, same problem, right?
We have to wait until authentication time to do it.
But overall feasibility, yeah, it's okay, right?
We can do this occasionally.
Ah, now this is kind of old school, right?
The TCP hijack attack, right?
You take a running, open, post-authentication connection,
and you bust open sequence numbers, and you hijack it, right?
This is old school, it's been used quite famously by Mr. Kevin Mitnick.
But unfortunately when you go and do it, oh yeah, the user's noticing.
Look at that, that does look like Shimomura, don't you think?
He looks pretty pissed, he's got two exclamation marks next to him.
That's how you tell.
So yeah, ease, these days, not so good.
People have decent, hopefully, random number sequence generation.
And yeah, it's not so stealthy.
But the plus side, right, it has all the properties we're looking for, right?
We can do it right now, right now.
Open connection, it's got the credentials we want at the other end,
we can go and steal it, all good.
But the downside is, yeah, overall feasibility, not so good, right?
You're going to need raw sockets, you're going to need promiscuous interface
to try and see the sequence numbers if you're not going to be doing it blind.
Doing it blind these days is not as easy as it used to be.
So yeah, I like it, right?
I'd like to be able to do this, but it's not always feasible.
But this is the fun one.
So, after we've authenticated the session,
we turn up on the user's box,
and we sneak down their running connection from inside the box,
and they don't notice.
Hmm, that sounds easy, it is.
It sounds stealthy, it is.
It sounds like you could do it right now, hmm.
And is it feasible? Well, the code's on your CD.
Say what? Yeah, hijack the application.
Why not, right?
It is slightly different, right?
It demands slightly different methodology, right,
when you're going to hack someone.
Normally, you hack them on a public holiday, on a weekend,
you know, when they're getting married, something like that.
Here, what you're interested in is maximising the number of open
post-authentication sessions for you to sneak down.
So really what you want to do is you want to turn up,
during peak time, right, the middle of the day,
when everybody's right there at their desks.
And then you want to sneak in and take their route
right out from under them without them noticing.
Right, just daylight robbery.
And the funny thing is, right, it's not even that difficult.
Right, this is just a party trick.
I mean, all I did, right, was I thought,
you know, there's a lot to be learned from kind of
old-school DOS viruses.
There's a lot to be learned from things we've done in the past.
And this is just creative re-application of the same tricks
that, you know, binary reverse engineers and virus writers
and all those sort of, you know, kind of sneaky fuckers
have been doing for a while.
Right, so I took those numbers that I just pulled out of my ass earlier on
and I put them on a graph to make it kind of look legitimate.
And as this graph clearly demonstrates, right,
my technique is wildly better
than everything except classic trust relationships,
which you'd have to be a retard to deploy, right?
I mean, seriously.
So yeah, I graphed them.
And really the conclusion from this graph is that
transient trust relationships, exploiting them,
is almost as much fun and as easy as
exploiting traditional trust relationships.
So, for your hijacking pleasure,
I present to you my SSH jacket.
It doesn't actually look like that, right?
You don't need to clap, but it looks different.
It looks like a script and stuff.
So yeah, it's a Python script,
which, when pointed at an SSH session,
gives you a shell at the other end.
Just like that.
So we're going to talk about briefly how it works,
a few kind of implementation details,
a bit of nitty-gritty stuff so you can do it yourself.
And then we're going to diverge briefly into
considering anti-forensics whilst implementing and using it.
And then there'll be like one slide of mitigation,
you know, just the responsible bit of the talk.
And then, yeah, we'll talk about a few other bits and pieces
that you might have up your sleeves or I might have up mine.
Fullscreen, that's pretty futuristic.
I'm not familiar with this commercial software
with the two buttons and stuff.
I'm kind of a one-button sort of guy.
Hey, that's pretty sweet.
Hey man, I just hack your network, right?
I don't do presentations.
So yeah, SSH, right?
For those of you who aren't familiar,
which probably isn't anybody, I guess,
SSH provides this virtual channel metaphor, right?
Effectively, SSH provides a multiplexed transport, right?
You can run multiple sessions across a single encrypted TCP pipe.
And it provides a number of useful things
for you to connect to those sessions.
The typical ones you'll see is your TTY.
Apparently that's pronounced titty, I'm not sure.
A shell for you to talk to on the other end of your titty.
And of course, TCP sockets is the other thing
we normally shunt around.
X-connections, that sort of thing.
Things over TCP.
People are quite familiar with that.
So what we're trying to do here, of course,
is we want to be able to take the user's session away from him
and use his credentials.
But we don't want him to notice, right?
And this sort of virtual channel metaphor
is exactly what we're looking for.
So how's it work, huh?
Well, we're going to take the features provided by SSH
and we're just going to use them for evil.
That's what hacking's all about, right?
So what we do is we ask for a second shell.
We say, hey, server, I'm Bob, I'm authentic.
You saw that earlier, right?
I gave him my password.
I'm good, right?
You want to give me another shell?
I'll go another one.
Maybe two.
And then we're going to glue it to the hacker.
Give him a socket.
Connect it up.
Oh, look, a shell.
Just like that.
So using Python and a little bit of debug trickery,
we go ahead and we ptrace attach to the client process.
Now, this implies, obviously,
that you need to be able to ptrace attach.
So, obviously, you have to be root
or you have to be running as the same user, right?
And that's not as stupid as it sounds.
You think about all the Firefox bugs we've had lately, right?
Admins who run the links on the desktop
are almost always going to run Firefox.
There's been a few Firefox kind of zero-day run code sort of bugs.
You turn up on the desktop,
you find every running SSH connection,
you jump down them.
And then we just rummage around.
And we find ourselves the virtual channel setup code.
SSH session 2 open, if you're wondering.
And then we just go ahead and patch it.
So instead of talking to the user, it talks to us.
And then we run it.
And then we just put everything back like nothing ever happened.
Except that the shell just popped out my netcat.
Hehehe.
So yeah, this is, I like to think,
this is the sort of thing that your mother warns you about, right?
Hackers, we're sneaky. Sneaky.
Well, one of you guys is sneaky.
The guy earlier on, yeah.
Yeah.
Right, we don't just install LK4 anymore,
you know, just trojan ourselves LS and stuff, right?
That's kind of boring.
And we don't install BNC, because who cares about ISE, that's right.
That's crap.
Except the older ones get caught there,
they're always running egg drop bots and crazy shit like that.
And yeah, good hackers, a little bit of creativity here and there,
maybe they'll do something new and interesting like
jack your SSH connections.
And if you hire some pen testers, and they're good,
maybe they'll do it too.
So all we're really doing here, it's just automated debugging, right?
It's not crazy, it's not rocket science, right?
And of course, if you give me a debugger,
and one of your processes that happens to be doing something important,
of course I can fuck with it, right?
That's normal, that's what debuggers do.
And humans with debuggers can do sneaky things.
But what we really want, is we want to automate it, right?
We want the sneakiness of a human,
and the speed and portability of a script.
So that's what we do.
So we're using Python, we're using GDB,
gluing them together, and we've come up with,
effectively, an automated debugging toolkit.
Of course, one of the downsides about this,
and if you've done any binary reverse engineering,
is that debugging binaries,
when you don't have any symbol information,
is not really debugging, right? It's not fun anymore.
So you have to do a bunch of tricks
that normal reverse engineers,
people who are doing binary analysis, have to do.
And we'll talk a little bit about that in a second.
So yeah, the nitty-gritty implementation details.
Write a little bit about Python, about GDMMI.
One of the things we have to do is we have to find a safe place
that we're going to stop the program
and kind of mess with its execution flow.
Because obviously we can't just go wildly executing code
in its memory space and hope it's going to work.
And then we have to find the code we're going to run,
we have to execute that code.
Or we have to inject some code there first, obviously.
And then we have to put it all back again.
And of course, what I'm discussing is in specific reference
to my SSH jackup,
but it's equally applicable
to anything that you're doing this sort of stuff to.
And we'll talk about a few of the other interesting things
you could do later.
So yeah, gdb is the GNU debugger,
for those of you who aren't familiar with it.
I'm sure you've heard of Richard Stallman, right?
He writes some good stuff, one of them happens to be a debugger.
It's pretty cool.
And gdbmi is its programmatic interface.
Gdbmi is actually pretty suck.
It's about half implemented, but it's good enough.
So yeah, I went ahead and just wrote some Python bindings for it.
Implements pretty basic functionality,
but enough to get the job done, right?
So the SSH client,
as you normally use it, is single threaded.
It doesn't expect to be running other code
in the middle of other code.
So yeah, and there's all sorts of
kind of nasty global data structures
and arrays of function pointers
and shit like that, right?
So we have to be a little careful
about what we're doing.
It's also completely asynchronous.
So when you, for example,
when we ask for that virtual channel,
it doesn't get set up right there.
It goes in a queue with a list of packets
that have to be sent to set it up
and there's a whole kind of state machine
that models how the SSH client interacts with the server.
So we have to be kind of careful.
So we have to find the safe place
where we can run our code.
And what you're aiming for
in the choice of a safe place
is really minimal deviation
from the normal operation of the code.
And funnily enough, right,
that happens to be in the middle of the main line,
of course, around the select call
because that's where everything branches from.
So we read the findSource,
I find the select call,
I decide that's probably a good place.
So we ptrace attach,
we stop the process, we drop a breakpoint
in that safe place, and we let it run
until it comes back.
Just like that.
But where is select?
Normally, right, normally if you're debugging something
you just go, hey, gdb where select?
And it goes, oh, yeah, over there. It's all good.
But we don't have any symbol information
so we have to do a little, you know, work backwards.
And this technique is very well understood.
Everyone does this sort of thing.
So where does select come from?
It comes from libc. So how does it get in there?
Well, the loader puts it there.
Where does it put it?
It dynamically links it into address space.
So we ask, where do you dynamically link it?
It says over here, and that's all good.
And then, you know, we have to rummage around
in the global offset table.
Find it in there.
The ELF procedure linkage table,
another exciting piece of the ELF format.
And then we rather boringly rummage
through the code segment
until we find a piece of code
that calls that PLT entry.
In this case, actually, it's quite easy
because there is only one call to select
in the whole damn binary.
So we can put a breakpoint
right in the middle of the ELF PLT.
Save me a step. Nice.
So yeah, now we've found select.
So where are we going to put our evil code?
Well, we're going to go and patch
SSH session 2 open,
which is the piece of code responsible
for setting up a new virtual channel
and asking the server to connect
something to the NBR TCP socket,
or in our case, a shell.
Still no debug symbols, of course.
Fortunately for us, there's a unique error string in there.
It happens to bitch about the dupe failing.
And that's the only occurrence of that string in the binary.
So we rummage around, we find it in the read-only data section.
And walk the code segment
looking for calls to that, right?
Now we know roughly where we are in this function. Nice and easy.
So yeah, the evil code itself, right?
It's going to overwrite the first half
of the virtual channel setup code.
We're going to save the registers,
we're going to save the flags so we don't fuck things up too much.
And then basically we're going to inject
its shellcode, right? It looks like shellcode.
Same sort of thing, right? We're going to call socket,
we're going to call connect, we're going to connect it back to
wherever we happen to be listening.
And then we're going to substitute it for the file handles
that it's expecting to be a normal Unix TTY.
I like Unix, it's cool.
I see you do that in Windows where your
Winsock sockets are different from your file.
Ah, Jesus.
And then we're going to leave the registers set up just right
so that the second half of the function runs perfectly.
And for really no good reason at all,
I'm using libc calls instead of
kernel syscalls, which I could.
It's just, you know, a bit of variety.
Sick of kernel syscalls, very boring.
So, why all the effort, right?
Why do we go to so much effort to overwrite half a function?
Wouldn't it be simpler to just have a piece of code
which we've already compiled, which happens to set up
virtual channels, and we'll just kind of copy it into
its address space and run it, right? That would be a lot more straightforward.
Yeah, it might be.
But one of the really suck things
about that is you have to link it by hand
with no symbol information, right?
Which, if you've tried, it's not fun, right?
That's not a fun game at all.
And so I thought maybe it would be easier to just
let the bottom half of the function,
which contains all the symbol references,
just let it be, and inject stuff
up the top to take advantage of that.
It's particularly nasty for SSH, because it has
this whole kind of, you may remember from, you know,
programming classes, this data-driven metaphor
which was popular kind of late 90s or something,
where you have like wild arrays of function pointers
and you just let the data index into them and...
Right, that's pretty yuck to have to reverse engineer
on the fly.
It's especially tedious if you have to do it
for every binary.
In this case, we actually patch it up
at runtime,
to make sure that the shellcode we have
will run in this particular environment.
And you'll see, actually, it's surprisingly successful.
So what do we do? Well, we work backwards
from that unique Duke error message we found.
We find the appropriate place at the top of the function.
We just kind of walk up until we see a function preamble.
And then we learn a few bits and pieces,
like how big the local stack is,
and we patch in the command line parameters
so it's user-friendly.
And a few other bits and pieces that we discovered
as we were, you know, doing our thing.
And now we have a nice little piece of evil.
So, yeah, let's wedge it in.
Back up the instruction pointer,
so we know where we were.
Back up the old code that we're about to override.
Stash it somewhere in memory.
And then we go ahead
and just inject our code.
Now it's going to take care of a few bits and pieces.
We've got a breakpoint at the end to catch it
when it's finished.
Hmm, what do you think we're going to do next?
That guy over there, right?
He's busy. He's playing hunt the wumpus, right?
He's just doing his job.
That wumpus, it's still going to kill him.
And we got ourselves a shell.
Just like that. Transparent.
The user doesn't even notice, right?
He sits there running something interactive.
Shell pops out from underneath him
and he doesn't even notice.
Sucks for him, huh?
So maybe you're going to go home
and jack yourself, right?
So what are you going to do?
How are you going to do it?
How are you guys going to go home
and hijack yourself some action?
Well, it's pretty straightforward.
Well, what I did, and you don't have to
kind of do what I did, of course,
is I wrote the hijack code in C first.
Makes it nice and easy. Compiled it up.
I compiled it actually directly into SSH
because I wanted to prove that you could have
two shell sessions down in SSH.
And you can. So I hooked it up
like a magic keystroke and you smack the escape
tilde, or whatever the hell it is,
and bring up the command prompt
and open me a shell, please, and it gave me one.
Just to prove the point.
And then, of course, the compiler
had conveniently generated most of my shell code for me.
Gee, that's so hard. Glad I bought the book.
And then I went ahead and implemented hijacking
for a binary that had debug symbols. Make it nice and easy.
Just to prove that I get the code in and out of memory,
in and out of the half of the function, nice and easily.
And then the really suck bit,
which is you build a list of symbols you're going to need to find
and you come up with a strategy to find them
and then you actually have to go ahead
and write code to do it.
And then, ooh, look, jack your friends. Fun and profit.
And then, if you're really nice,
package it up for the security consultants,
put some 3D, some spinny round, you know.
Maybe do it in Flash, I don't know.
A few bits and pieces, right?
The things that didn't fit in elsewhere.
Think about how much you use SSH, right?
You use it for SCP.
You use it for CVS.
You pipe stuff over SSH all the time.
You have backup push, you have some CPIO,
or whatever other home roll backup solution
you're using on Unix
because you can't find a decent one.
Yeah, it gets around, right?
There's a lot of it.
And, yeah, this does work over SCP.
And, yeah, it does work over stuff over SSH.
You know, there's a few little wrinkles,
but it works just fine.
Actually, the code on your CD doesn't work just fine.
The stuff I have right now does.
And it'll be on, I guess, on blackhat.com
or Defcon or wherever they put this stuff
after I've finished.
But, yeah, so, yeah, it does.
It jacks SCP just fine.
You'll notice in the client,
you can hit tilde and I think it's hash
or something and it brings up a list
of the open virtual channels you have.
Does it show up in that list? Yeah, it does, actually.
How many of you knew you could list
the virtual channels open with tilde and hash?
One, one.
Horns, thank you.
But, of course, that's the client
that's listing it, so you want to go patch that?
Sure, no problem.
And what happens when they log out?
Well, anyone who's used port forwarding, right,
you know what happens when you've got an open shell,
you've got a port forward as well, you're using the port forward
to, you know, look at GoPorn or whatever,
right, and you log out, right, you haven't
finished looking at the GoPorn, the connection stays open.
Great, well, the same thing happens here.
So, you're SCPing, your SCP takes 30 seconds,
I happen to catch it in time, run a shell
over it, your SCP will stay running
once it's finished copying so that I can do some
hacking, play Hunt the Wampus.
And how does it, well, how well does it work?
Well, uh, at the moment, uh, any
open SSH3-ish it should work on.
Um, it's known to work on, on
the out of the box Stephen Sarge
RHEL3, RH9, it works on
Slack, uh, Slackware as well, 9.1.
Uh, it doesn't work on SUSE
because their compiler is just retarded.
Um, I, I work with a guy who used
to work at SUSE on their, on their AMD64
stuff and they, they got paid by AMD
to write loads of extra optimizations
for AMD64 and then they went and back ported
them over to Intel and now the compiler just generates
code that's so wildly broken.
Right, I, I can't, I look at it, right, I can't
believe it even executes. Right, I, I've
seen it miscompile, like, really basic stuff.
Anyway, so, it doesn't work on SUSE,
right, uh, ah...
I, I'll get round
to it, right, I'll probably just write some, some
one-off custom code that's gonna
work on SUSE because the, the magic heuristic stuff
that works on everything else doesn't work on
their compiler.
Silly SUSE.
Also, it's also worth
mentioning, I guess, uh, Python 2.2,
2.3, 2.4, it's known to work with.
2.1, it ought to work, but
I haven't tested on 2.1. Anything older than that
you're probably, uh, you know, there's a few bits and pieces
that are broken. Um, GDB,
I haven't noticed any version it doesn't work with yet.
Uh, it's a pretty straightforward text interface.
Now, if you'll indulge me, a brief, uh,
brief tangent into anti-forensics. Now, uh,
those of you at, who are at Black Hat,
uh, or, uh, RuxCon last
year may have seen, uh, the Grugs talk
on anti-forensic stuff. I don't know if he was doing
it at DefCon, was he? No?
No.
It's very interesting. Well, I saw it at RuxCon, uh,
two years ago, or a year and a half ago.
And yes, I remember very interesting things to say about
anti-forensics. And of course, when you're,
when you're attacking systems like this, right, in
the middle of the day, or when everyone's using them,
it assumes that you're taking pretty basic
anti-forensic precautions. You don't want to leave too
many, too many trails.
So yeah, I'm going to talk, uh, just a brief,
you know, very brief overview of anti-forensic
technique, and then how I've implemented
it, uh, successfully and unsuccessfully
in some places, uh, when I was using and
writing the SSH jacket.
So yeah, the most important thing, the most
important thing is don't put anything on disk.
Do it all in memory, right? Memory goes away
when they reboot the box.
Right? There's nothing on disk, there's no tripwire,
there's no, nothing for them to look at with Ncase
or whatever other expensive, uh, forensic
products they're using. You know, it's like if you get
swapped out the disk, you don't know well.
But really, you want to try and keep
everything in memory only.
Uh, use local tools, right? These are,
these are Turing-complete machines, you can write your
split code in whatever's available, right?
If you have to write a port scanner in ORC,
do it, right? Right, if it has a
Perl interpreter, great, use that. Right, if it has a
Python interpreter, use that. If you're good, right,
you turn up, you find what's there, and you
write your tools on the spot.
That way you don't have to go and, you know,
wget magic hacksaw tarball.tar.gz
from hacksaw.com, right, which is a real
fucking giveaway. You don't want
them to know what you did.
And yeah, try to make
new network connections, right? You don't want anything
for their intrusion detection or
cough prevention systems to spot.
And you don't want them sniffing your traffic
and kind of replaying it later and figuring out what the hell you did.
So yeah, reuse
your existing connection, hide in plain sight,
use encryption.
So,
how well do I do?
Well, we do use
general purpose tools, right? GDB is pretty
general purpose. I mean, if you turn up on a box that doesn't
have GDB, maybe it's not such a giveaway
to go ahead and install it, right? I mean, maybe you're just
helping, right? You're just doing a bit of administration for them.
Some of the best run Windows
boxes I've seen are admin by Russian hackers.
Remotely,
right? They don't even have to go on site to reboot it.
How nice.
So yeah, we do. We use general purpose tools. We use the
Python interpreter, we use GDB. That's nice.
SSH is
encrypted, so the packet is not much use.
And yeah,
our new shell that's
going across the existing SSH connection,
right, there's nothing new there. There's no new connection
for any intrusion detection
or things to spot.
Not very interesting. That's good.
We're looking okay so far.
Where do I start?
Well,
Python code lying around disk.
Not very elegant, right? I've got to copy the script across
and then I've got to go Python, SSH,
yada, yada, yada. That's not very nice. There's no script lying
around for them to look at. Even Python bytecode
lying around, you can turn that back into code pretty easily.
And of course
the other problem is we have that connection coming
from the SSH client out to
our network, which has a TCP
connection with the shell on the other end, right?
That's a new connection. That's not so nice.
And yeah, it's in the clear as well.
So obviously if I were a cunning man,
if I were a patient man, I would have implemented
SSH connect back, right? Because all the
code in the client is there, right?
I haven't done that yet, sorry.
But if you happen
to turn up over SSH, right? So say it's
the second box you've routed in a row,
and you just came in across an SSH connection,
why don't you set up a port for it?
Bring it back down like that. That would be a pretty good idea.
So let's not leave our scripts lying around on disk.
How about we just go ahead
and load that Python directly into memory?
All good, right?
So let's just
run up a Python interpreter, ask it to read
from Samjin, and execute it.
And then locally, we'll take the Python script
we want to run locally, we'll compile it up, we'll turn it into
Python, we'll compress it and paste it into work,
we'll send it across the wire, maybe with a
little loader at the other end to unpack it and run it.
And then send it across your shell.
That's all good, right? Nothing on disk.
That sound straightforward to anybody?
Pretty straightforward to me, right?
It's just three lines
right there, and then a little bit of jiggery-pokery.
I know you want a script.
You want scripts, don't you, right?
OK, I wrote a script for you, make it nice and easy.
It does all of the above, right?
So now if we load, we pass in a Python script,
list the Python libraries we might require,
mine our arguments, packs it up, sends it across,
runs it, you give it a shell and a modem,
it knows how to do the rest.
And then if you're really cool, right,
hack in Screen. Screen's really neat.
Screen is a terminal multiplexer, right?
So you must know Screen.
Screen has this really cool feature
called Bang.
It'll run a local command
and then it comes with other options,
but it will inject the output
of that local command into your remote session.
So I sit there on Screen, I go
CTRL-A and my screen escapes here.
I go bang, bang, bang, bang, bang.
Powerful load, SSJAC, process ID,
destination host port,
and it runs it on the remote machine,
just like I was there.
That's pretty cool, right?
You can almost forget you're running it remotely.
And obviously for your convenience,
that's obviously neat.
So what else can I do?
What else can I do with this?
Well, it would be nice to actually generate
the shellcode on it.
I didn't get around to writing it in Assembler yet,
and other people have already written it,
even in Python, right?
It doesn't have a lot of documentation,
so I read through it, but I haven't implemented anything.
Yeah, pure Python debugger,
so that would be cool.
Aha!
What other protocols have
virtual channel infrastructures
and are used on clients?
Lots. Especially poorly-packed
senior clients.
Hmm.
MS-IDP, Citrix.
I've already had a chat with some people
who like hacking on Citrix,
and they're pretty keen on this idea.
Citrix has got a virtual channel infrastructure
for running, you know, drive mapping,
and all sorts of things.
Yeah.
And all manner of things, right?
I mean, once you have an ordinated
programmatic debugging toolkit,
you start seeing all the things you can just beat with that hammer, right?
It's a really cool thing to have in your toolkit.
You can start, you know,
you can have it disassemble stuff on the fly,
figure stuff out, and patch it, right?
All programmatically. It's cool.
Right, now,
now, being as it is that, you know,
I'm obviously some sort of long hair, right?
And I'm from the Antipodes,
I'm not very fashionable, right?
I'm kind of stuck in the 80s and shit, right?
So, I'm not sure if this is
still fashionable, right?
Because, blaming Theo for everything.
Is that still fashionable?
Yeah? Yeah, okay.
Unfortunately for me, it's not Theo's fault.
Sorry.
It's actually a feature of all things.
The SSH protocol specification
says it's just fine
to have multiple channels on the other end.
That's a requirement, right?
That's pretty cool, huh?
I hadn't really thought about it before, right?
My SSH client, right? If I was to say,
get a shell, that's all there is to it, right?
But now imagine like a graphical client, like a CAD.
So yeah, it's a feature, right?
If you could get a shell from a server
back to the client, right?
That would be a bug. Unfortunately,
Theo took care of that. He's a good dude.
Same with unsolicited port forwarding.
If you could port forward from a server back to the client
without it asking you to do so,
that would be a bug also.
But no, I've taken care of that.
I haven't looked at any other SSH implementations.
Because SSH is, you know,
the client and the server are very, very similar
in functionality, they both have to deal with
this multiplexing and multiplexing.
Generally, most people write that code once,
right, and use it in both a client and a server
implementation, so you have to be pretty careful.
So if I were you, and you're using
a funny SSH server,
one of those crazy Cisco ones,
I don't know,
yeah, I might have a look at that.
It might work, wouldn't it?
But anyway,
it's not OpenSSH's fault. Please don't send me a bug report.
It's not a bug report. Blame me instead.
I don't want Theo to, you know, come and bring me up
and harass me, kick my ass or whatever.
But yeah, OpenSSH is cool.
For the record, OpenSSH is cool.
I like it. It's a big fat loaded piece of crap,
but I like it. I use it every day.
Mitigation technique.
Responsible slide, right here.
Don't get rooted. Nice and easy.
You could, if you were cunning,
patch ptrace, maybe, so you
couldn't do it as a user.
I suppose there's patches around to do that already.
One of the things that's not on there is
you could, the SSH agent,
they try to prevent this attack by making it set GID.
I don't know that making your SSH client
set GID is a good idea. I mean, there's probably
all sorts of other things that would go horribly wrong if you did that.
One of the most important
things that you can actually do to help
yourself is if you're running restricted, if you're running
trust relationships using keys between hosts,
there's a bunch of tools you can use
to restrict what those keys can be used for.
You can restrict what commands are executed,
you can restrict where port forwarding is allowed,
you can restrict x-forwarding, all that sort of thing. Use it.
Use it. Really do.
Oh yeah, and then Steve Gibson, he had some really good ideas
about those wall sockets right there. They're bad. Sorry, the buggers.
I think we should get him in charge
of the anti-bugger movement.
Yeah, why do you care?
It's just a party trick, right?
This is just like eroding the farms. That's all, right?
It's not wildly zero-day.
If you get rooted, you're screwed. You knew that.
Rich desktops?
Yeah, it's a good way, right?
Tacking desktop machines that are full of complexity is a very good way
to get to well-protected servers.
And especially willing to admins. Anyone running Linux on a desktop
is probably looking after interesting stuff.
And yeah, try it against
RDPM or ICA.
That could be interesting.
Very pretty mad greets.
There's not much of a scene in New Zealand. There's only a few of us.
We all drink beer. There's like, let's run through tables
the whole scene, but yeah, I thought I'd better say hi to them.
And GadooSpice, he gave me my first security hack
two years ago.
He's a good dude.
Oh yeah, and there were a few talks about this one that were interesting.
The Elf. Sean Flowers
Elf Encrypter, right? That's some crazy shit.
I gotta read that. It's like, symbiotic
p-tracing processes that
take memory in and out of each other
and unencrypt it. It's crazy. Go look at it.
Apparently, I'm out of time
so you don't get to shred me.
Sorry. There was also a demo
that I'm getting the head signal.
If you want to see it,
come see me afterwards. We'll do it on a box that doesn't
look like a screensaver.
Alright, thank you guys!