All right, we're back live. And thank you, Tyler, for supporting DEF CON,
supporting the community, supporting the Red Team Village, in order to have you here.
And with that said, without any further ado, take it away.
Hey, good evening, late night DEF CON. This is 50 Shades of Pseudo-Abuse.
I'm Tyler Boykin, and this will be my talk.
So, we'll do a quick about. And the intended audience level for this kind of thing is
beginner to intermediate. And there's plenty of talks on some whiz, some cool advanced stuff.
But I figured we'd keep it in the beginner-intermediate range.
Or if you're a more seasoned professional, you may pick up a few things, maybe a good refresher.
We'll do a brief crash course on Pseudo, on where it stands on the TTP,
the MITRE realm of things. And then we'll cover the Pseudovers file.
And then we'll hit up some enumeration and recon.
And then we'll go into the fun stuff, which are all the examples.
So, a little bit about me. I'm an Aggie communications officer with the Marine Corps.
Cut my teeth with network engineering and information assurance.
And then now I do security engineering for BioLite Professional IT Services.
And so you can find me on Twitter and a few other places.
Okay, so superuserdo, whether you're calling it pseudo or sudo,
we're talking about the same thing.
And it's basically, it allows any permitted user to execute commands as another intended user.
Typically, 90% of the time, it's going to be approved.
And the security policy, which is what we'll dive into as we're going into this,
determines what privileges, what allocations, what all can that user do.
And the whereupon authentication, specific tokens are made on the pseudo tracks,
each and every failed or successful authentication.
And it'll remember you for five minutes, so if you ever notice that, and then so on.
And so when you execute a command, and you'll see this later on too, unlike su, as you were,
the security policy just states which environment you get.
So whenever you are actually running sudo, you inherit all of that users in full environmental variables.
For instance, you get the, unless it's explicitly stated otherwise.
So you typically get their environment variables.
You'll get a variety of IDs, right?
And unless you specify otherwise.
Real effective user IDs, group IDs, right?
You get a good variety of things up there.
But it's as the target user.
And these are straight out of the sudo man pages.
I'm just going inch deep, mile wide stuff, just to kind of give a little bit of a background.
There is no easy way, right?
There is no easy way.
And this is to prevent a malicious user from escalating, abusing stuff if stuff is allocated.
Simply because there's a whole breadth of things.
There's this breadth of applications and features that can be manipulated maliciously.
It gets rather hard.
And so, I mean, there are ways to mitigate this.
You force, at least you really crank down on the least privileged kind of method of security and whatnot.
But it's really, you have to be particularly stingent when allocating stuff.
Okay, so we'll kind of shift gears here into Mitre.
And so it falls under abuse elevation control.
So this shouldn't be anything new, right?
This is pretty similar vernacular to what we've been talking about the past couple of minutes.
Adversaries may circumvent mechanisms designed to control and elevate privileges to higher level and so on.
And so where the sudo and the sudoers falls into is now the new format, which they went to sub-techniques.
And I'll give you all a quick minute to read that.
I think I've got it.
No, I'm just kidding.
So basically it says the same thing.
Adversaries may perform sudo caching, and that's to where they go after those token files.
And so in the directory, each user that attempts to authenticate via sudo gets their own specific directory.
And then each attempt has its own little file. It's kind of cool.
And then adversaries may attempt to abuse the caching or misconfigurations in sudoers,
and that is where you'll actually wind up seeing a lot of the stuff for all this talk are mostly out of sudoers misconfigurations.
Okay, and that's a good segue.
So sudoers is the primary configuration file when you're working with sudo.
It resides in Etsy.
Technically, you can edit it with whatever you want to.
That is not encouraged because it is very syntax picky.
So generally speaking, you make a copy of it and you use visudo.
And if you use visudo to edit the file, it'll run the error checking, the syntax checking immediately upon exit.
Or you can just, let's say, if you wanted to tweak something, mess with something, you can always just run the standalone checker on the file.
So that's what it's basically going to look like.
You're going to have...
If you make a misconfiguration anywhere in sudoers, it'll yell at you.
Like that.
And then if you're good, then it tells you, okay.
So the sudoers specifies the who, what, when, where.
It's the be-all, end-all.
Other documents contribute to this whole security order, this whole policy.
But the main point of configuration is sudoers.
And so unlike... by default, password authentication is required, but you can specify no password.
But unlike su, where you authenticate as the user which you are trying to do stuff as, so let's say root.
You authenticate as root.
Sudo, using sudoers, you authenticate as the user calling it.
And so it's a little bit less.
And so the file is composed of two main parts.
It has some other sections, too.
And you can go into a little bit more detail about that.
But for the purposes of what we're doing here, you're going to have your aliases, which are kind of like variables and placeholders.
And then you have your userspecs, which are the five Ws.
And there's quite a few userspecs for these examples.
And so when multiple entries stack up, they're applied in order.
You see that a lot in userspecs.
And then if there's... and then it racks and stacks into the last one.
So, aliases.
The interesting thing is that these syntax on the man pages are actually a little less...
When you see them in a sudoers file, it kind of makes sense because stuff, right?
But the format kind of eh.
But essentially, it's alias type.
Name.
And then you go on and you can specify whatever you're trying to alias.
And then you have your defaults that you can always set to.
And so, moving on a little bit.
The sudo allows for shell-style globs and wildcards.
It's not actual regex, but if you've ever done anything in bash or shell or whatever, it's similar in functionality.
An asterisk is one or more.
And then question mark is any single character.
You can kind of do range, kind of splitting between brackets and so on.
But this isn't... it's not actual regex, but it functions similar to what you see in bash or any kind of shell.
Okay, so we're down to the user specs.
And this is actually a little bit more of the intuitive part, in my opinion.
Because it basically... it's the who, what, when, where.
You have the who, where.
In the parentheses, you have the as whom.
And you can use colons to delineate further detail into that.
And then the what.
And then sandwiched between the what are tag specs that kind of throw stipulations on some of the activities on how it's done.
And we'll go into that with the next slide or two.
And so the run as spec.
So, for example, me at server.
Me at host server.
You know, as operator, these commands.
It's not to the web.
And so tag spec, and this is what I was talking about earlier.
It sandwiches in between the as whom and the command part, right?
And this can either greatly, drastically make a red teamer's life easier
or it can make it a little bit more difficult, make it more complicated.
No password, you'll see sometimes.
Set in will also, you can deliberately manipulate the environment when you're calling those commands.
And no exec prevents dynamically linked applications from actually calling shell on themselves.
Or running commands themselves, you know.
And we have an example of that later on also.
But I'm going to hope for that no password.
So much easier.
Okay, so enumeration.
So there's manually, right?
You have sudo l.
And if you're lucky, and this could be for any kind of real-world pen testing, CTFs.
Could be for any type of thing, right?
You have sudo l.
And it might be as easy as that.
The user that you may have compromised may be a sudoers.
And when you do sudo l, you may get a listing of every, you know, what all that user can do, right?
You have etcdoers.
It should, hopefully it exists.
If you can read it as an unprivileged user, I think there are bigger things going on.
Or you're in a CTF, you know.
But, I mean, that would help you help enumerate and get a bigger picture of things.
In the event that you cannot, for instance, let's say you can't do sudo.
But you're still trying to look at version numbers or whatever else.
You can still get the version number from sudo with capital V and just do some googling.
You know, maybe you can find a user or service that can't use sudo.
And then you may be able to leverage that for exploitation.
Etsy group.
And so, same thing.
You can see additional users that may be in, you know, the sudoers group.
And then one of the places it logs is to var log or auth log.
And so, that's all manual stuff.
And generally speaking, because this is a subset of privileged escalation.
So you don't need as much expansive tools and resources to really enumerate what you have, per se.
You know, let's say if you're doing some other things.
But there are automated things.
For MSF, you know, you have post modules.
I think the interpreter has a few also.
And then there's some pretty well-known scripts, too.
Like linenum.
Anybody who's done CTLs and some other things has used linenum.
That's a pretty well-known one.
Follow sudo is actually pretty neat also.
And I make another reference to the creators of that.
And that particular one in the middle references that for that particular CVE.
Okay, so examples.
So this is from the creator, follow sudo.
And this is more the degree of examples.
Because it's kind of a spectrum.
And I like to use the fruit, the hanging fruit kind of analogies.
So the two examples, a complete lack of configuration.
It's nothing wide open.
It's low hanging fruit.
That's the lowest hanging fruit.
And you should go for the lowest hanging fruit first.
Because those are the beginnings.
Or you might see...
They've tried to configure secure sets of rules.
But there may be a bug in one of the applications.
It may be something flagged.
Or they just didn't know.
But they're trying.
Or it just may not be configured consistently throughout whatever they're doing.
Right?
Which is actually pretty normal for any other kind of real system hardening and whatnot.
And you get the lowest of the fruit.
You get the open sudo.
And then you've got the top part, which is the fairly secure, as he's mentioning.
But for today's purposes, we're going to be mostly residing mostly in the middle.
You'll have a little bit of low fruit.
And we'll have a little bit of the cool stuff up at the top.
But the middle is going to be...
That's where the fun playground is.
Because it's a little bit gamier, in my opinion.
Okay.
So when you're doing this, you want to get creative and inventive.
Because you don't necessarily have to get a fancy CVE, per se, with these.
You don't have to make an alphanumeric fricking rock chain or anything like that.
You're just using what exists creatively.
And so that's kind of the cool part about it.
And can you read something off limits?
Can you write to something?
If you can write to something, then you can go really far then.
Right?
This is where you're scouring the man pages.
And you're looking for flags.
You're looking for little subtle things that may be kind of useful.
And that's why it's more fun.
And it's kind of a misnomer, escalate laterally.
You may be able to move laterally.
I haven't really seen any non-root users specify in sudoers.
But that's an option.
You can do sudo as a different user.
But using that gets you to a different user.
I mean, that's worth mentioning on a pin test report.
And that may get you to something bigger and better.
It's not always about up and down.
Sideways works too.
Right?
And so with that, we are now entering low-hanging fruit.
So this is the easy stuff.
Open sudo, the classic example.
Wide open, user authenticates as himself, his or herself, whatever.
And then the system is their oyster.
Their one step, their keystrokes away from root.
And so you go into a little bit more.
So these, any applications that directly result in a shell, they're pretty much right next to there.
This is your SH, KSH, ZSH, whatever, right?
SU.
And any actual programming languages too, because those can, again, cough up shells.
Cough up shells, cough up functionality.
Those are pretty big gummies.
And so then we go, this is kind of like a little bit higher.
We're turning up the volume on the creativity a little bit, right?
And so you've got commands, right?
And so you're not, they don't give you, they can give you instant shells, but it's not right off the bat.
So you've got to dig for stuff a little bit.
And you have to use stuff unintended.
You've got to think outside the box.
And so that's why I think, that's why I kind of like some of these.
And so here are a few examples.
When you do wget, right, for instance.
If you supply I as an input file, it'll attempt to read each line in that file as its own URL and it'll attempt to shoot it.
So if you do sudo wget whatever, say Etsy shadow, right?
Each line of Etsy shadow is going to be, wget is going to try to resolve or make a request to each line of Etsy shadow.
I mean, it'll fail, but that's file read, right?
You're now reading sensitive files that you're not supposed to.
And same thing with curl.
And this one's actually kind of cool.
These are two web request applications.
And you don't even have to make an actual web request for them, really.
So it's kind of neat.
And so you continue to offset.
And then it'll automatically find where to resume.
And you basically specify the remote name, which is local.
And so then you specify file.
It actually accepts in this format here, file, kind of like you're doing FTP or whatever, or HTTP, the location on the local system.
And it'll download it and you can read it.
It's actually pretty neat.
Base64 is another interesting sample.
That's file read.
I think that's file write also.
I'll have to double check.
But essentially, you're looking at, it's file read.
And if you pipe it into itself and supply the D flag, you have the clear text.
You have it on 64.
And then GCC, if you supply wrappers, it'll run the command that you supply.
And all params are passed comma separated after the initial command.
And then at the very end, we're tagging along.
Let's say you have kind of a bug or like a big, gaping kind of bug thing.
And it's kind of a mix between the high level and low level.
But any bugs that are incurred at sudo are going to have sudo consequences also.
So, where's my demo thing?
Okay.
So, we will do some shell time.
How about this?
So, L, section one, open sudo.
So, yeah, sudo L, right?
Anything, you do sudo su cat root text.
That's what it looks like.
That's what I'm using for these particular purposes.
Looks like that kind of jazz, right?
So, apps, sudo L.
And so, this is pretty much the same thing too.
If you run sudo is in the top two, you're going to get an instant shell.
Creatively, I think the kind of neat one and one that you can use for if you're working,
trying to get a non-limited shell is with the Python.
And so, Python, most interpreted kind of languages and some things, except inline commands, correct?
So, pity spawn, pity the fool, bash, right?
And so then your root.
It's pretty cut and dry.
It was pretty straightforward.
So, now we're getting into a little bit more fun stuff with wget and whatnot.
So, if you notice, it accepts an input file.
And so, basically, that's what it looks like.
It tried to run the flag in our particular case.
It tried to make a request to it and obviously it's going to fail because it's nothing, right?
And so, that was pretty neat when I first learned that, right?
And so, base64, similar thing.
It comes in as you're basically piping it to itself and you're specifying the D, which means decode.
So, here we go.
Wrapper, we have got root.
It ran sh.
And then, lastly, for this little bit, curl.
So, it literally downloads and the spot into the local directory.
We've got the flag.
Bada bing, bada boom.
And so, in this particular instance, it's just a small program, say, mycat, right?
Just to show an example.
Obviously, and didn't mention this before, but as we progress along, you'll see a common trend of applications having more than one exploitation vector, right?
So, it may not just be file read.
It may can do file write.
It may be able to do commands, right?
It just depends on how you work it and whatnot.
And so, in this particular case, it basically takes in through standard input and sends that to system, right?
So, there's two, at least two with this one.
So, I do sudo mycat, do root text, write file read, sensitive file read.
You can also write bin sh, get root.
Typical string exploitation.
Okay.
Okay, now we're going to get a little bit fun now.
So, pager abuse.
Okay, those got mixed up.
Okay, so pagers.
So, whenever you run man or service or any kind of terminal editor, and those things where you can scroll up, down, left, right, it's called a terminal pager.
And the interesting thing is that people know what it is, but they don't know what it is per se.
But it's basically what happens behind the scenes is a terminal pager gets called.
And they accept extra commands.
When you supply an exclamation mark, anything proceeding that exclamation mark gets run as a command.
So, your editors, you know, vim, nano, etc.
And so, yeah.
We'll go ahead and show that right quick.
Like, l, section2, pagers, if I can type, l.
So, yeah, if I do sudo man man, quick example, we're now in a terminal pager.
You can go up, down, left, right, whatever.
By simply just typing stuff, it'll start parsing your input.
And by doing exclamation mark, everything after this will be run as a system command.
So, vim sh, we're now root, etc.
Same thing with service, too.
So, sudo service blank status.
I'm going to get all of them.
I'm going to open up a pager.
vim sh, easy peasy.
And so, a neat thing is you tend to forget these types of things.
But let's say you do a service, but it doesn't have that much output.
It's more just kind of terminal fundamentals, perhaps.
Let's say you do cron status, right?
And actually, it does do a pager right there, midway.
But for whatever reason, if the pager ends prematurely, let's say it finishes,
you can always just shrink your freaking terminal down to like here.
And then do it again, and it'll open up the pager for you.
So, I think that's kind of neat.
Yes, GTFO bins. A lot of these are on GTFO bins.
Now, I tried not to just go down and just start listing them off.
I tried to grab a variety of different things.
So, yeah, GTFO bins is definitely very, very handy.
If you're not using that, you're definitely crippling yourself in what you can do.
Okay, cron abuse.
So, this kind of goes without saying.
If you can edit, you can manipulate or run or do any kind of service type things
as root, that's going to have root-like implications.
And so, that's a pretty short slide.
But, so, sudo l, or s-u-l, sorry, section 3, cron l.
Yeah, and so in this particular instance, right,
and so it's actually worth noting that if you do cron tab,
if you haven't done it before in the system, and you don't have the right environmental variables set,
what's the first thing it asks you?
It asks you, what editor would you like to use?
And so then you have editor-style exploits with whatever kind of services you can do also.
So, in this particular case, sudo l.
So, let's do sudo cron tab e, and I already have something set up,
but now we're in Vim, right, so any kind of root, easy peasy.
But, it's also the implication that you can edit the root's cron tab and run stuff as root, any kind of services.
In this particular case, I have this little script here, and all it does is, just for the example,
it basically reads in root text and writes it to the current directory.
It's pretty easy peasy.
So, sudo service cron start.
And you'd have to wait a minute.
And let me see what's going on, on the Discord.
Okay.
So, at some point, probably in a minute, I might not just wait for it,
but we'll see root text should hopefully populate up here.
But, I don't think I'll wait for that.
So, you'll just have to deal with it.
Okay, so now we're getting into a little bit more fun stuff.
LDPreload is actually kind of neat.
And you need a bit of a background to understand what's going on.
So, LDPreload, it's an exploit.
You're using a feature that is intended to be used with dynamically linked binaries.
Whereas, all the methods and all the stuff is resolved at runtime,
whereas it's statically linked.
You get that bigger file if you statically link everything,
but you don't have to worry about shared objects being all messed up and whatever.
You have everything in one nice big package.
But, obviously, with dynamic linking, you do have a smaller file size.
You have your typical libc and a bunch of other things to worry about.
But, overall, it's a little bit more flexible.
And so, with the LDPreload, you can essentially tell it to load that stuff before it loads the other stuff.
And so, you can essentially overwrite any kind of method or function in whatever application you're running.
And so, we need to put a few things together.
You're combining a custom functionality with a binary that's being run as pseudo.
And, obviously, that's going to equal fun.
Pretty fun.
And so, you'll see this in the environment.
Whenever I've seen it, it's been in the environment.
And the binary also has to be compiled for it.
And so, the syntax for when you want to go about business with this, the pseudo LDPreload,
you can export it to the env, to your environmental variables,
or you can just run it all in one, like how we're about to do here in a minute.
So, demo.
So, L section for LDPreload.
So, in this particular case, we can run the example.
And I tried to cite, I got some of these examples straight off the internet.
I tried to cite them.
You can find these, I'll link to them, so if you want to look at them, reference them too.
So, in this particular case, the example was, it runs a loop, and it prints 10 random numbers.
It calls ran, and it outputs the standard out 10 numbers.
So, in this particular case, because it's a dynamically linked,
we can provide our own stuff, and we have the LDPreload environmental variable set.
So, in this particular case, cat drandom, and basically, it's going to overwrite the rand function,
and it'll just return 42.
So, example C, right here, right?
And so, you're basically going to, essentially, you're going to make that do what you want it to,
which is kind of cool.
So, for this particular example,
So, sudo ldpreload drandom, shared object, to example.
And, as you see, we basically made random do what we want to.
So, it's no longer random. It just prints 10 42s instead of a bunch of actual random.
So, taking that a step further, oh, we can manipulate the file as sudo.
So, what do we do?
We get evil.
And, in this particular case, we're overwriting init, which happens right off the bat.
And, you know, we basically pop shell.
And so, using a similar type thing, evil, we are now rooted.
It's pretty cool.
And another cool thing is that it'll finish running the rest of the application once we exit.
See?
Because we only overwrote init. We didn't overwrite the rest of it.
So, it's kind of neat.
Okay.
Okay.
Installers.
So, it goes without saying, right, that installing any kind of application is a security concern,
especially if you're going to install it as admin, as root, any kind of privileged accounts, right?
And so, these can definitely be leveraged in various kinds of ways.
Pip, apt-get, dpkg, you name it.
And so, for instance, a lot of these have multiple, let's say, apt-get and dpkg.
They both invoke a pager.
You can do stuff during install, providing custom functionality.
For example, pip, when you're in setup, you can specify entire methods for doing stuff.
It becomes your oyster.
So, obviously, installing things as root is a big, critical security consideration.
Okay.
We will hit that up.
Okay, so, sudo l.
Okay, so, how does one make that a shared object?
You compile and link.
You basically don't do the full process when you compile.
If somebody doesn't share that with you, we can grab that here after this.
But basically, you make it a shared object, and it can be used by other dynamically linked applications.
So, let me grab my thing real quick, y'all.
Okay, so, for the pager, right, pager abuse, sudo apt-get.
Not bad.
Change log.
See, we now have a pager.
So, the old stuff still applies.
And so, having that kind of mentality that, oh yeah, we're in familiar territory, it will help us for later on.
And so, in this example, we have apt-get shell package.
And all it's doing, you're basically providing custom functionality, and it runs at the very end.
So, all you gotta do, you can specify, instead of making a normal web request out, you specify a local file for which to draw from.
And then it basically goes like that.
It's pretty cool.
And the same thing with, when you go to setup, or setup, excuse me, pip.
So, in this particular case, we have a setup py, like what you'd see in any, if you're installing any kind of module, any kind of thing written in Python or whatever, you'll have your setup py.
And in this particular case, it actually does a reverse shell.
And so, I'm gonna use, I need to split screen for a minute.
I think that one was 1, 2, 3, 4, 5.
So, 1, 2, 3, 4, 5.
We do sudo pip install . to specify from the local directory.
And we do.
And we have.
Bada bing.
Pretty cool.
Exit. Exit all out.
All that jazz.
Okay.
Right on, right on.
So, path and secure path.
So, these, so if you recall back, right, globs and whatnot are acceptable within the sudoers file.
The asterisk, star, whatever, is what are more?
Question marks, new characters, and so on.
So, and this is kind of in the same family as your normal environmental variable path, right?
It's in the same vein of exploitation.
If you see asterisks, you see stars in the sudoers file, you can have similar consequences, too.
So, it's kind of similar in this particular case.
Not exactly, but for example, if you see a dot, an emf, it's gonna read from the current directory first,
wherever it's being invoked, and then it goes on.
It goes on down the line, right?
And if you see an asterisk, that means anything for that directory.
And so, that's what's happening in this particular case.
You know, anything in bin, you know, is free game.
And so, obviously, that's not particularly secure.
And so, interesting enough, for sudoers, right, you have the secure path.
So, if you don't actually trust the environmental variables at the lower level to be well-formed or whatever,
or to be secure, you can kind of override that with your own secure path.
But obviously, if the secure path is misconfigured, that's fun for more than one person involved.
So, and in this particular example, we made secure path temp to show that it's kind of a misconfiguration of sorts.
So, l section6 path.
I believe for this one, I'm doing the bin.
So, and it's also worth noting, right, in other kind of privilege escalation mindset,
that, you know, I can run anything in this directory.
And so, as sudo, so you can basically write your own shell.
You can do whatever, and it'll run what you want.
So, in this particular case, I just made id, it runs shell.
It's weird, but whatever.
You know, and so, sudo, let me copy all that, I ain't typing that stuff.
Boom, id.
It's pretty intuitive.
And then, sudo l.
So, this particular one, it's going to check temp first.
Because that's a misconfiguration on the secure path.
And it's a particular one.
And there's actually another exploit later on that utilizes double stars.
But this is for the example, this purposes.
You know, where is usually, where is ping usually at?
Ping is usually user bin, right?
But obviously, if we do sudo temp, and ahead of time, it's a temp to ping, right?
You get the flag, because in that particular file, it does the same thing.
It's just reading and printing, right?
And so, that's just insecure path considerations when you're using globs and whatnot.
Okay.
So, we're getting there.
We are getting there.
Okay, so this one's kind of neat.
So, editors and sudo edit.
So, you have your obvious kind of blatant stuff.
You already got your pager and whatnot.
And anything with editors, you have file read, file write, any kind of commands.
But how it does some things are kind of weird, right?
And so, there's a few new things I stumbled upon while I was even making this in the past months.
And we will include an actual CVE with this also, because it's kind of in the same line of things.
And this is the actual CVE.
It's on exploit DB.
Sudo edit does not check the full path.
So, if you use double globs.
And so, the POC for this is you create a send link to anything sensitive, right?
Anything sensitive, and it'll resolve that as correct, and it'll run it.
And you're good.
It's pretty cool.
So, we will get to keyboard mashing.
L, section, 7, editors, clear.
Sudo l.
Okay.
So, we can do that one first.
So, in this particular example, we have two directories.
Test2 with protected, which is the actual symlink to it.
It's going to Etsy Shadow right now.
And then we have...
Let me scooch that up a little bit for us here.
There we go.
All right.
And so, var...
I just made some dirs.
And this one is...
It's actually really nothing.
I think it has some stuff on it.
I forget what I put on there.
But, either way, the user can't access either of them, because it does not have the permissions.
All right.
But...
So, if I were to do...
Sudo...
Sudo edit.
Right.
And then specify...
Test2 protected.
Oops.
So, it is worth noting that if you fat-finger something, you fat-finger it,
it will ask you for a password.
So, if you specify no password on a security policy, and whatever you're doing is prompting you for a password,
then that action is not covered under the policy, and you're likely not going to be able to do it.
Sudo edit.
There we go.
Okay.
And so, now we are in anti-shadow.
I must have been fat-fingering something.
And so, this next example is actually kind of cool.
So, we have this entry right here.
No password.
So, they're trying to lock us down to them, but they also have no exec.
And so, if we recall what no exec is, it means no shells, or you can't run commands.
You especially can't pop shells, right?
And they are trying to lock us down to where we can only edit this particular file,
which doesn't exist, but you can obviously open it.
You can create the file and then save or do whatever in them.
So, and we'll test that theory, right?
Sudo them.
Let's say we want to do root.txt, right?
Can't do it because we're being prompted by password.
Let's say if we use sudo them, and we actually do go to this.
Right.
So, obviously, and if we try to do our typical shenanigans, right?
Nope. Denied.
No shell for you, right?
It's pretty cool, but here's a neat trick.
You can source externally from within editors to doing your own stuff.
So, colon E for edit, R for write, for read, right?
Exactly.
So, I think that's pretty neat.
And then you can basically kind of wiggle around from inside, kind of like that.
Okay.
We are hooking and jabbing.
We got a couple more, and then we are done-skies.
So, PwFeedback.
This one is an actual, this is also an actual CVE and has an exploit db entry.
So, basically, in older renditions of sudo,
it will ask you for your password, but when you supply stuff via standard input,
it gives little stars.
And, essentially, there is a stack-based buffer overflow,
too much input through standard input,
and you supply long enough of a string,
you can then put in whatever malicious badness, goodness that you want.
And it's actually a pretty simple exploit, and it's pretty simple to check out.
And we will go ahead and do that.
However, I need to see what user...
One second.
I need to get what I call these, because I don't call them all intuitive names, per se.
Eight.
Oh, that one is.
Okay.
Okay, pwfeedback, right?
So, sudo l, in this particular case, we do need it this time.
We do need it to prompt us for a password, so we can actually exploit,
we can smash the stack, basically.
And so, I have two POCs,
and then I think once you can find it on...
I think I'll link to at least one of these.
They're pretty self-explanatory.
So, this first one, it's 100 As terminated by a null, and it does this 50 times.
And then after that, you can pipe in whatever commands you want, generally speaking, after the S.
And so, for instance, if I were to do sudo, actually, POC, rear root, right?
And notice in here, we're not actually supplying a password.
It did ask us for a password, right?
So, if we do sudo whatever, it asks us for a password, and we had to supply it.
But because we smashed the stack, basically, and then supplied our own command,
that's basically how we went out of business there.
And the same thing with POC2.
It's the same concept.
It's just more fanciness.
In that case, it does a reverse shell, like before.
Okay, we have about 10 minutes left.
I'm going to go ahead and...
Yeah, we can do that one, too. Why not?
Why not?
Demux.
This one was 3.4.
POC2.
Hmm.
That's curious.
Oh my god.
Well, they all almost worked.
Hmm.
Might have to fuck with that later.
But they'll get the general principle.
Demo gods.
So...
Okay.
Limited shells.
This one's actually pretty neat.
And I learned this, actually, by doing Pentester Academy.
And if you're trying to look for different neat kind of ways to enhance your existing skill set,
or learn completely new things, I highly encourage that.
I'm not trying to show for Pentester Academy or BVIC, but he's a great instructor,
and they have some great coursework.
And so, in this particular one, just showing this particular example.
And it's kind of a hypothetical, too, right?
So, let's say you have a huge credentials.
Normally, you would be able to do sudo as a user, but you do not have a full TTY.
Let's say, for whatever reason, you can't make a full TTY.
You can't do the SOCAT, the STTYRAW echo trick, all those normal things.
Let's say those aren't working.
But you still have a limited shell, and you have the ability to run sudo,
because you can run sudo, and you have the user's credentials.
So, you can use, in this example, the expect command.
And the expect command basically simulates user interactivity.
And command, you know, on the man page, this is alphabetically,
but there's always, there's four of them that you would practically really need to know
in order to run this example.
Spawn, which spawns the command of whatever you supply.
Send is providing input to standard input.
Expect parses, I think it does both standard out and standard error.
I haven't tested that, but I think it does.
It does both, at least does standard out.
And then, you got interact.
And then, that basically goes hands-on at that point.
It's kind of like, if you ever used potent tools with Python, right?
It's like the interactive, similar kind of mentality there.
And so, I'll break this down.
Expect C, you're supplying the command.
You then spawn sudo S.
So, it's kind of like a spawn, the spawn, the spawn thing, right?
Sudo S, in this case, we're just going to read root.txt.
We spawn that process.
We then look for, with globs, it supports globbing too.
So, you don't have to be exact exactly.
You can, a little bit of wiggle room when you're doing your expect.
We look for password, because that's typically what you see whenever you're prompted by sudo.
We will provide the password,
which, in this case, it's always the username, because for demo examples,
you do have to provide your own enter,
and then you interrupt.
So, demo.
Okie dokie.
And this one will require a limited shell.
It will require a reverse.
These ones, three, four, five.
I forget.
Okay.
So, in this case, I made a shitty little, didn't really make.
Oh, it's one, two, three, four. I'm sorry.
Four.
Okay.
So, it's a little crummy shell.
You can't do anything.
You don't have an environment.
There's no terminals, no nothing.
It's bare bones.
What you might see, if you're doing a CTF, a real pen test,
where you don't actually have functionality,
you know, it's a limited shell, it's a limited shell,
it's a limited shell, right?
You got nothing, really, per se.
So, in this particular instance,
we can then supply the big glob that we had previously.
And so,
hit enter,
and there's our flag.
Okay.
So,
we're at the finish line now,
and this one's actually a pretty quick one,
and it's more recent, too.
This one,
it doesn't check for the existence of the user,
and so when it runs,
it executes with the arbitrary user ID,
and it returns a zero.
Zero is also root's ID, right?
And so, and then,
and that's executed for privileges,
or whatever you specify on the end of it.
And you test that out, too,
because if you specify,
see, in the as whom clause
of this user spec,
you can specify,
you can't run stuff as root, for instance.
Right?
And so,
this particular one,
I actually do need to copy and paste.
My username is
the,
it's not as intuitive.
Okay.
sudo l, right.
So, generally speaking, if I try to do anything,
either not as this particular application,
or if I try to do that,
but as root,
it's obviously not going to work,
because it is explicitly stated in the user spec.
However, given this particular
type of sudo,
you don't have to worry about that.
Right? And so,
let me get,
excuse me while I whip that out.
Okay.
So, yeah, you simply just do
sudo u,
and there's tons of scripts, too, where you basically
scrape the internet looking for this.
They're pretty nifty.
So, if I try to run anything
other than those two, you'll get prompted
by a password, which means
given that
there's no password, you see
it asking for password, you're wrong.
So, we'll just do id,
and we're root. We at least have the
root's uid. And if we do
a bash,
we are now root.
Okay. That
is good. So, a recap,
we covered sudo, sudoers,
we went through open,
sudo, we covered a bunch of easier
application stuff.
This is out of order a little bit.
Disregard it.
And so,
yeah, we covered a variety of things
from different angles,
from GTFO bins to some
CVEs from stuff from ExploitDB.
And just try to develop
the whole mindset that
you can really dig into sudo
and get creative and really have fun
with it.
And so,
I tried to cite as much...
I tried to cite everything that I could that I pulled
from, and I included that at the very end.
If you
happen to see your material featured in
here, and I did not
give you proper citation, just let me know
and I'll add it. I'm not
trying to plagiarize your stuff.
I try to give all
the citation credit where it is due.
And
that is my talk.
Okay,
do we have any questions?
I was trying to get
the mute button working, but
yeah, basically
first of all, thank you so much for
supporting us and for the great presentation
here. We're accepting questions
through Discord, and if you just
join us in the bottom of the screen,
there should be, whether you're on Twitch or
YouTube, there should be a link to our
website, and of course from there
you can actually get to our Discord
channel. So if you have any questions for
Tyler, please do so there.
We're going to go on a brief break,
and then the next presenter will start
in about 15 minutes. Thank you
again.