- Before we actually
execute any one of them, I'm just going to show
you that I indeed can view the contents of the password file, and you can see, we have the
unprivileged user account there and the root user account right over here. So we'll exploit or use exploit one. So we'll just say exploit one, and we are executing the binary now. I'll hit enter. As you can see, the first step is it's going to back up the original /etc/passwd
to the temp directory, and it's gonna save it as passwd.bak. It's going to set the
root password to piped, which as I said, you can change yourself or generate a new password if you want. And then it's going to restore
the original /etc/passwd from the actual password file that was stored in the temp
directory, and there we are. So it tells us done! Popping shell. You can now run command. So if I type in ID, you can see we've elevated
our privileges to root. And of course, you can also
spawn a Bash session here. So there we go. So we can pretty much do
whatever we want now as root. There we are, so I can actually display the actual shadow file and yeah. So that's how to use the first exploit. (upbeat music) - So just before we
continue with the video, I split the video up into two portions. If you wanna just look at the exploit and the demonstration of the exploit, please go and have a
look at this timestamp. Otherwise, are we are gonna
continue with the interview. I've asked Alexis a
whole bunch of questions in this interview, and then
he shows us the demonstration. But again, go and have
a look at this timestamp if you just wanna go and
look at the exploit itself. Hi everyone, it's David Bombal, back with a very special guest. And I like to say that because
this is a very special guest. Alexis, welcome. - Thank you very much
for having me on, David. I really appreciate it. - It's great to have you. I've watched a lot of your
videos and for everyone watching, I strongly suggest that you subscribe to Alexis's channel below. You can give us the proper
name and give us some details about the kinda content
you've got in your channel. But before we get started, really recommend that all
of you go and subscribe. Alexis, tell us about your channel. Tell us about what you've been up to. - Yeah, so my channel
is called Hackersploit. I essentially create
content on pen testing, red teaming, Linux security, as well as some blue
team and DevSecOps stuff. So, I'm primarily focused around the offensive side of things. I really like covering topics
pertinent to pen testing, more specifically like
privilege escalation and to a certain extent,
red team operations, especially on Windows, so
active directory environments. Yeah, stuff like that. - Yeah, so today we're gonna
talk about Linux escalation, but hopefully, I can get you
back to talk about Windows, because that's a big one as well. But tell us where you're based, 'cause that's like really special to me. Whereabouts in the world are you based and how did you get into hacking? - Yeah, so I'm based in Nairobi, Kenya. And as for the second question, I got started with
hacking pretty early on, but not officially. So I essentially got into hacking sort of at a very young age, really when, probably
around the age of 12 or 13, but that was unofficially
and that's because the computer I had at the time
actually came with Ubuntu. So I had to sort of like
figure things I out manually. So that was sort of my
first introduction to Linux and it was quite a revelation. And as I said, it's
actually quite different than starting off with Windows. - I was gonna say, that's
quite a way to start. Sorry to interrupt you. That's quite a way to start
learning operating systems, to start with Ubuntu, you said. Sorry, go on. - Yeah, I mean, it was a
huge learning experience, a huge learning curve,
especially at that time 'cause of the lack of resources. But yeah, I started getting
into programming in C and C++, and that's when I came
across distributions like BackTrack at the
time, which is now Kali, and I started learning how to
work with the Linux kernel. So compiling stuff, developing
various kernel modules and just working at a
very low level with Linux in terms of actually
interacting with the kernel. I then moved on from there. I sort of moved into the Linux system administration side of things. That was as I was getting into university. And when I went to university, I sort of got additional
knowledge and information regarding networking,
development, et cetera. And after I left university, I actually got started as a
Linux system administrator. So I got a job for a company where I was essentially responsible for managing their current set
or cluster of Linux servers, making sure that everything was working, taking backups or automating
that process as it were. Also doing a little bit of networking, and at a certain point,
I was also provided or handed over the responsibility to actually secure these Linux systems. So that's where I got my
start in InfoSec, if you will. Today it's called blue teaming or just your standard
security engineer role. But at that time, it was
called information security. Yeah, I got started with learning how to secure Linux servers and critical infrastructure for a company that also had its tools
in the financial sector. So I really got a proper view of how to essentially make sure that the infrastructure is in accordance with various compliance
standards, all that good stuff. And then one day they actually called in a pen testing company
to perform a pen test. And that's the first time I
ever saw that side of things, whereby you can actually
test the actual defenses and the perimeter of a
company and its infrastructure by actually trying to hack it and trying to exploit vulnerability. So that was a really, really
cool thing for me to see. And yeah, so that sort of
like piqued my interest into pen testing now. And of course, I already
had previous experience with a few of the tools when
I was working with BackTrack. So yeah, I then started learning
about penetration testing, getting certifications and
sort of improving my skillset. And I actually started
getting a lot of friends within the industry where I was located and I started shadowing them,
getting advice from them. Just learning the actual
tools of the trade. Once I was ready or once I felt that I was capable of
getting into the field, I applied for a junior
pen tester role at a... I can't actually tell
you the company name, but yeah, so I applied as
a junior penetration tester and I got the role. So now I was essentially responsible for doing some of the mundane tasks for the senior members in the group. So that's how I got my start. So my objective was
typically reconnaissance and maybe a little bit of
active directory testing, but yeah, that I think was pretty much the most important experience, that whole process of following and shadowing experienced pen testers and seeing how they do it, getting understanding of the legalities involved in pen testing. To cut a long story short, I progressed within that company and got more certifications. I started getting more training and this is where I started Hackersploit. Now, the reason I started Hackersploit was primarily because when I was searching online for resources, I wasn't able to find any. And that's pretty much
where I got the idea that if I can at least
show someone something or give them a glimpse into this industry and the tools of the trade, then that'll be a really good thing. So that's when I started the
Hackersploit YouTube Channel. And yeah, it started out slow. I was just creating videos
regarding what I was doing or some of the new techniques and tools that I was learning or had learned. And it started picking up slowly. When I was the senior penetration
tester at that company, and I'd worked for probably
like two years in that role, probably less than two years, I decided to start my own firm, which I then called Hackersploit, which not only deals with
cybersecurity training, but also, penetration
testing and red teaming. That was around 2017. So that's when I started
Hackersploit as a company, and that's where I've been working as a penetration tester and red teamer, and also, providing training
in the form of videos, courses, and books, et cetera. So, yeah. - So you've been doing
this for a long time and you don't have to give it away, but how many years ago
did you start Linux? So you were 13 around. So give us like sort of a ballpark figure. How many years ago is that? - I would say I started using Linux around the time when
Vista was being released. You can sort of identify that range... Yeah, so it was really
the transition period between Windows XP and Windows Vista. So yeah, probably a good
time to actually use Linux. - Oh, yeah, so around like around 2007. Somewhere around there, yeah. So that's a long time, very long time ago. Yeah, I like that. That's when you... So Vista was so bad that
you decided to use Linux, but so what happened? Someone gave you a laptop
or was it at school or something like that, that you... - I actually got a laptop as a gift, but of course, the individual wasn't aware of the fact that at that time, Ubuntu was actually
delving into that market of having their distro installed by OEMs. So it actually came with
Ubuntu and a free Ubuntu disc, which I still have. So yeah, that's how I got started. And of course, it wasn't a real issue. The only thing was I had prior experience with the computer that I had growing up, which was running Windows XP,
but I didn't use that much. It was pretty much for
games and stuff like that. But then I sort of had to learn everything from that point in time, and at that time there weren't
any resources available. It was pretty much the man pages or online documentation and books. - It's a really cool story. It's always nice to get the stories behind how people got into this. So, it's a fantastic story. So around 13, you got a laptop, you were kind of like
pushing to the deep end for lack of a better word. You had to learn Ubuntu on the fly. That's quite a tough way to start, but there's no better age I
suppose than when you're young to try and learn that stuff. Are you a big advocate for Linux? - Absolutely. I mean, Linux is just awesome. And I always make sure to
actually recommend Linux for anyone who is getting into computing, although they eventually veer off to Windows at a certain point, but I think having that
experience with Linux, it doesn't matter what level, I think it sort of broadens your horizons in terms of how an
operating system can work and how it can be developed. - Yeah, I wanna ask you
a million questions now, but I don't wanna take too long. But which Linux
distribution do you prefer? Is it still Ubuntu, or
have you changed your mind? - So it really depends
on what I'm using it for. So on my personal laptop, I sort of switch between Ubuntu and Arch. I really like Arch. The only problem is it's
a rolling release distro, which means you're gonna
have issues most of the time, especially with updates and upgrades. But yeah, for my main
workstations, I still use Ubuntu primarily because it's always
been stable for me at least, but I've also really
enjoyed distributions, like Manjaro and a couple of other ones. But yeah, it's pretty
much been Ubuntu, Debian, and I also, of course, had to
work with Red Hat and CentOs during my time in sys admin. So yeah, I also like them, but I think those distributions are really for the enterprise environment. - So if someone was starting
today to learn Linux, would you recommend Ubuntu as your... Like, start with this one? - Yes, although today I think I would probably say if
you're a total beginner and you want sort of
like a familiar interface to what you had on Windows, then Linux Mint is pretty
much what I would recommend. Linux Mint and Ubuntu pretty
much a Debian-based distro. Because that's pretty much all the documentation that's out there. A majority of it is on
Debian-based distribution. So that's a great place to start. If you are looking for a resource
to get started with Linux, I recommend the following website. It's called Linuxjourney.com
and it's a free website, and it just takes you through
various steps or stages and sort of introduces you to everything. It's a resource that I wish I had when I was getting started. - That's great. So that's just a free
website that you can go and it teaches you the
basics, fundamentals of Linux. Is that right? - Yeah.
- Okay, so what about hacking? What's your favorite hacking distribution, or do you just use
Ubuntu like John Hammond as an example and install tools? Or do you use Kali or something else? - Yeah, so for my personal work, I still fire up a VPS with Ubuntu and then install my own tools using the PenTesters Framework. I really recommend that framework for anyone who's trying
to get tools installed on whatever distribution they're running. The reason for that is primarily because when I am performing
assessments or engagements, I really only like having
what I need for the job. And I can get that
installed really quickly, even with a couple of Bash scripts. For recording, for the actual
videos and training itself, I use Kali Linux. I still utilize Kali Linux quite a lot because it's very stable. It's a very minimalistic distribution when compared to other
pen testing distributions. So I really like Kali, I've
used it for a long time. I used its original version,
which was BackTrack, so, yeah. - So explain a little bit about the PenTesters
Framework for those... A lot of people may
have not heard of that. - So the PenTesters Framework is essentially a free framework
that's available on GitHub, and essentially allows you to... It works very, very similar to the way the Metasploit Framework
console looks and works in terms of its syntax and functionality. So all you need to do,
it's developed in Python. All you need to do is
just clone the repository and you can then execute the Python script and it'll then take you
into the actual console and you can search for different tools, these all pen testing
and red teaming tools. So you can search for Nmap
for example, or Metasploit, and you can then specify
your select, use that module. So just like Metasploit you say use, and then the module name, and
then you just type in install. And the great thing with
the PenTesters Framework is that it installs all
the dependencies for you. So for a huge tool like Metasploit, it'll get all of the
dependencies installed and sorted for you so you
don't have to go through that, the process of making sure
that you have the dependencies or building it or compiling
a tool from scratch. - Do you have videos on
that on your channel? - Yeah, I have one video on
that, it's still relevant. So you can, if that's where you want to learn about it, you can. - Yeah, okay, I'll link that below. So you can go have a look at that video if you're interested in
learning more about that. Alexis, I gotta ask you
the big questions now. I get this so many times
and I'm sure you do as well. Do you install Linux or Kali on native, on your laptop or do you... I think you've answered already. You said you use a VPS, but
like if someone wants to learn, do you recommend installing natively or on a virtual machine or a WSL? What would you recommend
for someone starting and generally, what do
you recommend people do? - I don't recommend going
for a bare metal install your first time around. With virtualization now and the improvements of
computer's performance, and the fact that specs
have gotten better, you can pretty much fire
up a virtual machine and that'll give you a
very good experience. Nowadays, it was pretty
much bare metal install or a dual boot, which was very nasty
experience to deal with. So once you're experienced enough, it really doesn't matter
whether you're doing a bare metal install
because the installers, the actual installers
for the distributions are fairly similar and simple to use. You just specify your
language, your locale, your time, the user you'd like to create, you partition your disk,
and that's pretty much it. So I would recommend virtual
machines as a way of starting. And then you can slowly try and perform a bare metal install. But on my personal laptop, I pretty much install Ubuntu
on it and run it natively. - That's great. So what's your preference, VirtualBox, VMware workstation, any recommendations or what do you prefer and recommend people use? - Well, I think it depends on
what your requirements are. If you are getting into this field, then start off with
VirtualBox, 'cause it's free. VirtualBox works really well. There's tons of options that allow you to customize networking so you can create your own NAT networks. You can also mount shared
folders, all of that good stuff. So it really has all the features that you typically expect
from a modern hypervisor. I would think VMware is very useful when you're starting to build complex lab environments at home where you want to have
subnetting and stuff like that. And of course, VMware,
there is a free version, but if you are going for a free option, I would recommend VirtualBox. And then of course, you can
test out VMware for yourself. The formats for the actual
virtual machine discs slightly change or there
is a slight difference. So as I said, once you pick
a hypervisor of choice, you are pretty much going to be using that unless you start converting
all your previous VMs. - So VirtualBox, 'cause it's free, it's a difficult one. I always find with VMware, VMware has better
performance in my experience, but VirtualBox is better
for like snapshots. VMware Workstation Player
doesn't do snapshots. It feels like VMware have
really crippled that product. It used to be a lot better I thought, but from a optimization point of view, I find VMware generally better. But there's good and bad
about both, isn't there? It's great to get your opinion. So VirtualBox is one
that you would recommend. Don't install natively
unless you want pain for your first time around, but in the real world, when
you go and do pen tests, are you taking a Linux, sorry,
an Ubuntu laptop with you or what are you doing? - The way I have it set up
is a couple of months ago, we actually developed our own distro. It's not really a new distribution, but it just has all the tools we need. It's based on Debian,
sort of like what Kali is, but this really has some of the tools that you don't find installed on Kali. They could be part of
the Kali repositories, but these are tools that
we have curated ourselves and we've also improved ourselves. So we have our own distribution
that we keep up to date and it's, as I said, it's based on Debian. The only thing we've done is customized it based on our own requirements
and we have multiple images for different types of engagements, whether it be a red team assessment or we're performing a
standard pen test, so yeah. - What's it called and
how do people get it? - We haven't given it
an official name yet. And I think we're working
on releasing it very soon, but again, it's not really gonna be... I don't want it to be
seen as an alternative. The only difference between us and other pen testing distributions is going to be the fact that we'll provide you
with different images for different types of engagements. So it's a very professional distribution that's focused around actual engagements. So there'll be one for
pen testing, red teaming, web app pen testing, et cetera. - And that's not available yet, or can someone get it from your website? Or how do they get it? - It's not available yet. We will be launching it later this year because we are still
working on repositories and stuff like that. Yeah, we actually plan
on making it public, but we're not looking to compete with any other distribution. It's just gonna be a very simple project. - That's great. It's always nice to have
these kind of resources. Based on your experience, what are the best tools to
take to a specific engagement? So if that's what you guys use and you use when you
go and do pen testing, what would you recommend
until that's available? So would it be like Kali or what would you recommend someone use? - Yeah, so I think I said this is based on your requirements. The reason we created
that is primarily because when we were using Kali Linux,
there's different versions, there's different release versions and different versions of packages. And when you go into an
environment or an engagement, you never want to have
one of your pen testers tell you that this tool has an issue. And then the other guy says, "Well, I don't have this issue on mine." So we use it to maintain or to set up a system of consistency whereby
everyone has the same thing, everything works, we've tested it and it'll work 100% of the time. And then we handle updates ourselves just to make sure that
everything is stable. So we were really focused on
stability when building that. However, if you are a beginner, then I definitely recommend Kali. I know there's Parrot OS and BlackArch, but in terms of stability, we used Kali for a very long time. And we used a really old version of Kali with a few changes to it. But Kali has been rock
solid for me, at least, especially when it comes down to doing some of my own projects or working on exploits
and stuff like that. - I think that's good advice. It's always nice to get people's
opinion on stuff like this. So that's brilliant. How long ago did you start
uploading videos on YouTube? - I started quite a while
ago, probably in 2016, but that was just very basic stuff. And then once we actually
got going in 2017, we then started uploading
pen testing stuff. So I think around 2016 or '17. - That's brilliant. You've been doing this for
a long time, which is great. It's always nice when people
share from their experience for people coming into the industry. So yeah, it's fantastic
that you've been doing that. Now, I've gotta ask you
like a nasty question. What's your opinion of a macOS
versus Windows versus Linux? - Yeah, at this point in
time, I'm completely agnostic. It really doesn't matter to me because I've used a Mac, it's really great when it comes to specific tasks. I've used Windows, exactly the same. Windows stability has really improved. I don't think from Windows 10 onwards I've ever had a blue screen of death. So that's an improvement. And Linux does what Linux does best. So I think it's really not a matter of picking one over the other and having this sort of
like having an ideology based on what operating system you use. I understand the advantages
and disadvantages of open source and proprietary software. As I said, I've used Mac before. Mac is fantastic operating system, but the only reason I
don't use it primarily is because I essentially need a few tools and my workflow is spread
across pen testing, video production and
multiple other projects that I'm working on. So I pretty much revolve
around Windows and Linux, but I did have a MacBook
Pro a couple of years ago. It served me for a very long time. And yeah, so I'm really
operating system agnostic. As I would say, it really depends on what you're using your computer for. If you're doing video editing, then Mac is pretty much the best option. You can also use Windows. If you're getting into pen
testing, then of course, spend as much time
around Windows and Linux, because at a certain point in time, you'll also have to get
into Mac pen testing, which is slightly different, so, yeah. - That's a great answer. I'm always amazed that people
get hot under the collar about this stuff, because I
have the same attitude as you. I've got Windows, I've
got Mac, I've got Linux. Mac is my main computer, but that's because of the applications. Normally it's the applications
that I use that drive it. And I just found like you, I find Mac to be rock solid, stable. And to me, it's like the middle ground between Windows and Linux. So it has the best of both if you like, but I think that's a great answer. Now, a question, I'm sure
you get all the time as well is what hardware? People always ask this question. What laptop should I buy? Do you have any recommendations for that? - Yeah, I can only speak
from personal experience. In my opinion, I've used
quite a few laptops, but the ones that I've used
for more than five years at a go is probably a
ThinkPad and the Dell XPS 15. So again, I know that those really don't have good graphics cards and stuff, and that's because I really
don't game on my laptop. But what I look for in
a laptop is of course, a good balance between
the processor and RAM and it really needs to
have a very good keyboard. So the ThinkPad has always
been my go-to option. So starting off from the T420's, all the way to the T450's
and then the X1 Carbon, which I've been using
for about five years now. I haven't had any issues
with it, no problems at all. It really works very well, but I will be looking to upgrade. And at this point, I'll
probably be heading over to... I'm not really sure, but I'll
say either a MacBook again, or probably a Dell or one
of the Lenovo laptops. So I've typically revolved around Lenovo, or at that time, it was IBM
ThinkPad and Dell and a MacBook. So yeah. - What about RAM and
CPU and stuff like that? How much, if I'm starting out, perhaps I don't have a lot
of money for a MacBook. What would you recommend as a minimum? - I would say that you
can get a very good laptop for a reasonable price. And I would say around eight gigs of RAM is perfectly enough to use. I've used that for a very
long time as a baseline. And yeah, as a processor, if you're going to be
doing virtualization, then I'll probably recommend an i5, even some of the older generation ones, but you probably want to
get one that is not affected by the Specter and
Meltdown vulnerabilities, because those older chips
really lost a lot of performance when those patches were released. - From a hacking point of view, this is a minimum that
you'd recommend, yeah? - Yeah, and of course, if you have a sort of
like a bigger budget, then I would recommend 16 gigs because if you are using Windows on it, Windows is gonna take a chunk of its own in regards to RAM consumption there. - Yeah, I think it's great advice. I think these days... Linux can run on almost anything. If haven't got a lot of money, then start with something basic. You started at 13 years old and I'm sure that laptop wasn't
the very, very best thing. Just to start with Linux, you don't need a very powerful laptop, but if you've got money, then
buy the best you can, I think. Any other advice for someone starting out? - I think if you are getting
into the field of pen testing, is I would really recommend
learning the fundamentals because cybersecurity in general is a field where you have the synthesis, a synthesis of multiple other fields. So you have Linux, you have networking, you have Windows, you have development, you have a ton of other fields that all come together into one. So I recommend really
getting a grip on networking, more specifically the OSI model,
TCP, UDP, stuff like that, how to use Nmap correctly. Understanding what each Nmap scan does, learning how to analyze packets. And then of course, from the
operating system perspective, learn how to install Windows, how to secure and harden Windows,
the same thing for Linux. And if you can pick up
a scripting language like Bash or Python, I think that will really come in handy. You don't have to get into development like in C or C# for now. That's something that can
actually get into as you progress. But just learning, having understanding of operating systems, networking, and a bit of scripting is a great way to actually get started. Once you know that, you can then start exploring the actual pen testing methodology, and all the tools that fit or
fall within that methodology. - Any certs that you would recommend? - Any certs for pen testing? - Sorry, for pen testing, like Security+. Some people recommend that, OSCP. What kind of certs, eJPT perhaps from INE, which certs would you recommend? - So I would typically recommend starting off with the Security+ because that sort of
gives you an introduction to cybersecurity as a whole. And it also covers how security works in a corporate environment. So there's compliance standards. So it'll give you a proper
introduction to cybersecurity. I would then recommend going for the eJPT because it's essentially
designed for individuals who are getting into pen testing and essentially take you from a point of not knowing anything, to a point where you
are fairly comfortable with performing a pen test. After that, I would recommend the OSCP. And the OSCP will really give
you pretty much the skills required to work
efficiently in pen testing, because that's another thing that not a lot of beginners
take into consideration, is that when you're working for a company on a particular pen test, is you need to be really
efficient with what you're doing. You need to know what you're doing, how you're going to do it,
and you're against a deadline. So yeah, the other additional thing, or the other additional reason
why I really like the OSCP is because it covers report writing, which is very important... It's a very important skill
to learn as a pen tester. And even as you climb the ladder into maybe a management position, the ability to read a report
is also very, very important. So, yeah. - Great, so Security+, eJPT, OSCP, yeah. - Yeah, that's pretty much
the template that I would use. And then once you get the OSCP, you can then start getting
into SANS certifications and advanced certifications like that. I think that's at least in my opinion, and the experience of others and my peers, that seems to have been the best way, because the actual learning
curve is much easier. If you're beginner in
cybersecurity or pen testing, you dive into the OSCP, it's
gonna be really difficult. - Gonna be painful. So what about prerequisite skills or would you just go
straight to Security+? So let's say, is there any, you mentioned you need
to know about networking, Windows security, Bash,
Python, as kind of skills, like you said, fundamentals. Would you do something before Security+? Or if you were talking to yourself, let's say you were like 15 or 13 again, what would you recommend
someone do if they were young or even if they were
doing a career change, would they start with like
Network+ from CompTIA? Would they do something else or would they just go straight Security+, and then eJPT, OSCP? - With regards to the fundamentals, I don't think you need
a certification really, but it is always useful, especially the Network+ certification. So I would've essentially
told myself, learn Linux. So that means install Linux, learn the command line utilities, learn how to troubleshoot, learn how to script in Bash, learn about environment variables, learn about how to update packages and how to modify the
kernel, stuff like that. That's a bit too advanced, but that's the direction
I would push myself in. In the context of Windows, and I think this is very, very important. I would've said install Windows, learn about the registry, learn where Windows stores its passwords and in what formats. So the different hashing formats. I would also say learn
about the group policies, as well as Windows Firewall, Windows Defender, how they work. Once you've done that, then learn how to install Windows. When I say Windows, I'm talking about the
standard desktop editions. And then Windows Server, how to harden them and how to secure them, and essentially learn about
how these operating systems are typically deployed and
how they can be secured. And yeah, so that's on the
operating system side of things. And then for networking, I would say, yes, the Network+ is a very,
very good place to start if you don't have any prerequisite
knowledge on networking. So the Network+ is guaranteed to give you the actual prerequisite knowledge required to actually get into pen testing. So, yeah, and then on the
programming side of things, you can either go for
scripting to begin with. So I would recommend
sticking to one, just one. So if you're going for Bash,
learn Bash and nothing else for at least a couple of
years, or probably one year. You can then move on to Python and another scripting languages. - So that's great. So this comes back to
the old, old question. Okay, so you've recommended learn Linux, learn a bit of Windows. Do you have videos on
your channel or somewhere where someone can learn Linux in the context of hacking
or something like that? - You can check out the Linux Essentials for
Hackers playlist on my channel. It essentially goes over pretty much the most important elements
of what you should learn when it comes down to Linux. So there's also a couple
of challenges in there, so to essentially validate
what you've learned. So, yeah, that's a great place to start. - So you've got Linux, have you got something on Windows as well? You've got a whole bunch of... I didn't check, how many videos
you've got on your channels? Lots and lots. - Probably around 400 and something. - That's brilliant. So do you have like Windows
videos there as well? - Unfortunately, the only
Windows videos I have are on the actual
offensive side of things. So I don't have anything
that covers the fundamentals, although that's something
that I will be working on. But yeah, so for Windows, I
really don't have anything. So if you are interested in pen testing, essentially performing a
pen test on a Window system, then I have content on that, but nothing or very little
to do with the fundamentals. - Do you have like fundamental
networking stuff as well? - Yes, within the Nmap
playlist on my channel, the first couple of videos
cover the OSI model, TCP, UDP, the TCP three-way
handshake, et cetera. - That's great. So basically if I'm starting today, I could go to your channel
and I could learn Linux, 'cause you've got that Linux in a pen testing or offensive
sort of environment. So I can learn some Linux there and I can learn how to hack Windows. I can learn basics of networking. I can learn some Nmap. You said we could go and do Network+ but that's not necessary. The idea is just to learn the basic skills and then security plus eJPT,
OSCP would be the path. Is that right?
- That's correct. Just for everyone watching, I would suggest go have
a look at those videos get your foundations right. Alexis, a lot of people that I talk to say exactly the same thing. You need to get the foundations. I think a lot of people
wanna jump the gun, for lack of a better word, go straight to like,
"I wanna hack Google," but it's like, "Dude,
you need to understand the basic stuff? You agree with that?
- Absolutely. - Now, that I've asked you
a whole bunch of questions, can you do a demonstration on how do you attack a Linux system? And I know you've got a
great demonstration lined up. So do you wanna take that away? Talk about this sort of hack on Linux and demonstrate how it actually works. - Sure. So again, I'm going to
be essentially showcasing the process of how to
exploit the Dirty Pipe, local Linux privilege
escalation vulnerability. So, I'm just gonna start
off with a couple of slides and then we'll move on to the environment that I set up to actually showcase this. All right, so let's get started. As I said, we're gonna be
exploring the Dirty Pipe Linux local privilege
escalation vulnerability also known as CVE-2022-0847. So to get started, let's get an introduction
to the vulnerability. So the Dirty Pipe vulnerability
is the latest vulnerability that affects Linux kernels,
version 5.8 and newer. So any kernel from version 5.8 and newer is affected by this vulnerability. There are a few exceptions with regards to the versions that are
actually not vulnerable. And that is something that I'll be sharing in a couple of seconds. So the vulnerability was discovered by Max Kellermann in April 2021. However, it was not made public as he was still trying to figure out what caused the vulnerability
and how it could be exploited. So to put it simply, the
Dirty Pipe vulnerability is a local privilege
escalation vulnerability in the Linux kernel, that
could potentially allow an attacker or an unprivileged
user on the Linux system to elevate their privileges by modifying arbitrary read-only files
like the /etc/passwd file on a Linux system. They can also, again,
elevate their privileges by abusing or hijacking SUID binaries. So again, the crux of this vulnerability is that it essentially
allows a nonprivileged user or in the case of Linux, a user without root privileges to elevate their privileges
to that of the root user. So they can essentially get
root access on a system, which means they pretty
much can control that system and do whatever they want. So this is a huge deal. - Sorry, when did he release this or when did it become public? - Yeah, so the actual... This was actually made
public in March of this year. So March 2022. And Max Kellermann actually
released a disclosure or a really cool blog post that I will be linking to this video. So you can actually take
a look at that blog post as it essentially... He essentially lays out the entire process of him discovering the vulnerability and then trying to exploit it and identifying what was
causing the vulnerability. - Yeah, it was a very
interesting blog post, and I'd recommend everyone read it. I mean, he kinda like
stumbled across it, didn't he? What was it? A year ago. So it's been out in the wild for a while, but it's only recently
become really public, yeah. Sorry, go on. - So let's get an understanding of what causes the vulnerability. Now, given the fact
that this vulnerability affects the Linux kernel, you'll need to have an understanding of how the Linux kernel works. More specifically how the
Linux kernel handles memory. Now, this can be quite difficult if you don't have any
experience with Linux and how memory management works. As a result, the explanation
of how this vulnerability works will be kept simple and easy
to understand at a high level. So in order to understand
how this vulnerability can be exploited and
consequently, how it works, we'll need to get an understanding of a few memory management concepts. The first of which is a memory page or just a page as it's called
in the context of Linux. So a page is the smallest unit of data, typically around four kilobytes, that is managed by the CPU and
is used for memory management by the Linux kernel. In the context of this vulnerability, we'll be primarily focusing on how pages are used to read and
write data from the disc or read and write data to the disc. We then have the page cache. The page cache also
known as the disk cache is a memory cache that
is used to manage pages. So, fairly simple concept here. We then have the two main elements that are really the cause
of this vulnerability, which is the pipe or pipes
and the splice system call. So the pipe, which is
denoted by the pipe symbol on your keyboard, is used to redirect or transfer standard
output from one command or program or process or file to another command or program
for further processing. So if you have any
experience with using Linux, you should be familiar
with the pipe command, and how it can be used to redirect output from one tool to another. So for example, I can cut
out the contents of a file and then pipe that into grip
and look for a specific string. So, just allows you to take
output from one tool or command and redirect it to another for processing. The next element is
the splice system call. So the splice system
call is used to move data between a file descriptor and a pipe without going through userspace. The splice system call is
used to optimize the transfer of data between a file
descriptor and a pipe, and it does this by moving
references to the page storing the data contained within a file, consequently, directing a pipe to a page that is loaded in memory
that contains the data from, in this case, a read-only file that was previously accessed. So that can be a little
bit difficult to understand at first glance, but it'll make sense in a couple of seconds
when I actually explain how the exploit works. The actual core of this
vulnerability, as I said, revolves around pipes,
and more specifically, the pipe buffer flags. So by this point, you
should be able to identify the cause of the vulnerability. An attacker could potentially
utilize the splice system call to transfer a page into a pipe and overwrite the data in the pipe buffer, consequently allowing for
read-only files to be modified. The only problem with that is if I do that or I follow through with that, then those changes are only in memory. We still need to write them to disk in order for those changes
to be made successfully. So the root cause of this vulnerability is the PIPE_BUF_FLAG_CAN_MERGE flag that was implemented in
the Linux kernel in 2020. This flag is applied to pipe buffers and instructs the Linux kernel to write the changes made to a file, to the original file stored on disk. So this particular flag here, again, if this flag is
applied to a pipe buffer, then it tells the kernel to make the changes
contained within that buffer to make the changes to the original file that is stored on disk. So this is essentially
what makes it possible. Furthermore, a vulnerability
in the Linux kernel allows various flags to be set for newly created pipe buffers. So the actual exploit takes advantage of the PIPE_BUF_FLAG_CAN_MERGE flag, and this vulnerability that allows you to set specific flags
for new pipe buffers. So if we take a look at
how the exploit works, this will really start to
clarify a lot of things. So the exploit works by
firstly creating a pipe. It then assigns the
PIPE_BUF_FLAG_CAN_MERGE flag and sends data from a
read-only file into the pipe. The exploit then drains the pipe, so clears out all the data, leaving the
PIPE_BUF_FLAG_CAN_MERGE flag set in all the pipe buffers. So the vulnerability is caused when this flag is not reset
for all the pipe buffers. So we can then utilize
the splice system call or the exploit utilizes
the splice system call to splice data from a
read-only file into a pipe or a pipe buffer that has that flag set, which means that the pipe buffer with the PIPE_BUF_FLAG_CAN_MERGE flag set will contain a reference to
the data we piped earlier. We can then write data
to that pipe buffer, consequently overwriting the content of the referenced read-only file. And again, this, you might be
thinking to yourself, well, doesn't the Linux kernel essentially... Doesn't Linux have a way
of segregating permissions. And indeed it does, but the
only reason why this works is because write permissions
are not applied to pipes because, they assume that
anyone who's using a pipe is doing it from userspace. With that out of the way, I think I can get started with
the practical demonstration. So I'm just gonna switch
into a new window here, into a terminal window, and I'll take you
through the various tools that we'll be using. So let me just switch over. All right. So I'm currently on the GitHub repository that I set up for this particular video and my previous video on my channel. It's called the Dirty
Pipe Exploits GitHub repo. It'll be linked to this video as well. It's essentially a
collection of two exploits that allow you to elevate your privileges by exploiting this vulnerability
in two different ways. So on this GitHub repo, you'll be able to get an
introduction to the vulnerability and right over here, you can take a look at
the affected versions and the versions of the Linux kernel that have patched this vulnerability. So these are the versions here. Now, one additional thing to note is that distributions were very quick to actually patch this vulnerability. And even though the Linux kernel that is running on a
target system might fall within the affected
range of Linux kernels, that specific kernel
could have been updated and sent out as a patch. So, an affected version
of the Linux kernel could indeed be patched
or could have a patch that fixes or gets rid
of this vulnerability. So do keep that in mind. Now you can also learn more
about the vulnerability by taking a look at the CVE MITRE website and taking a look at the actual
vulnerability details there. And as an added bonus, I actually referenced a Dirty Pipe checker or vulnerability scanner script here. The GitHub repo is linked there. This GitHub repo has a Bash script that will essentially
allow you to check and see if a target system is indeed vulnerable to the Dirty Pipe vulnerability. So I've already cloned this repository as well as the Dirty
Pipe checker repository into my lab environment. And we'll essentially be going through the compilation process. So in order to compile the exploit or the entire set of exploits, you need to have GCC installed, which is the new C compiler. And as I said, I've set up a
Bash script called compile.sh that will automatically compile both the exploits that are developed in C into their release ELF binaries, so that you can execute them. So let me just go over
the first exploit here and give you a bit of an
understanding as to what it does, and then I'll go over the second one. So exploit one, essentially, as you can see it references here that this repo contains two exploits. So exploit one was taken from
the original proof of concept exploit code that was
developed by Max Kellermann. So all credit goes to him. However, I have modified it
to change the root password or the password of the root
user in the /etc/passwd file. When we'll be exploring
the exploit code itself, I've modified it to essentially replace the root user's password with one that you can specify yourself. That's exploit one. Once you've compiled it, you only need to just run it without providing any
additional arguments. If you want to change the actual password to one that you want, the instructions on how to do that within the exploit code. Exploit two can be used to
inject and overwrite data in read-only SUID process
memory that run as root. So this essentially takes advantage of the same vulnerability,
but in this case, it allows you to essentially
hijack a SUID binary, consequently, elevating your privileges or providing you with an elevated session. So again, these exploits, I
did not develop them myself. These are just exploits or
proof of concept exploits that I found online, primarily
from the original disclosure. And I've modified them to
make them easier to use. And to essentially give you a sort of like a one run solution to
elevate your privileges. So to get started, I'm
just gonna switch over into my lab environment, which I'm going to access through SSH. So let me just switch over. All right, so I'm back
in my lab environment that I set up to demonstrate this, the exploitation of this vulnerability. So as you can see, I'm
already on the target system. Because this vulnerability is a privilege escalation vulnerability, you can only use it once you've
gained access to a system. So in this case, we are going to use this simple scenario that I set up where I've logged in, or I've got access as a user called unprivileged. And I can type in ID and you
can see unprivileged there. I can also display the groups
that this user is a part of. So I can say, groups unprivileged, and you can see, it's not
a part of the pseudo group and doesn't have any pseudo
or administrative privileges. So this is the account
that we'll be using. As for the actual detection
of this vulnerability, if I display the actual
distribution release version here, you can see that it's
running Ubuntu 20.04 LTS, and the actual kernel version
running in this case is... Let me type that in. Version 5.15.0. So how do we check and verify whether this version of the
Linux kernel is vulnerable? Well, as I said, I've already cloned the repositories that
I mentioned previously into the home directory here. So what I'll do is let me just list out only the directories. You can see that we have two folders. We have the Dirty Pipe checker
and the Dirty Pipe exploit. So I'll just navigate into the
Dirty Pipe checker directory. And if we take a look at the files within this particular directory, we have the dpipe.sh script, which is the actual
vulnerability scanner script. And you can pretty much
execute it directly. So I'll just provide it
with executable permissions so that I can execute it
without any issues there. And again, the reason I do
that is to indeed show you that I can't really do anything there because this directory was
cloned through another user, and I only just changed the ownership. So we can execute it directly here. So once I type in dpipe,
or once I run the script, it will print out the
version of the Linux kernel that is running on this system. And then it'll tell you
whether it's vulnerable or not. And if you actually explore the script, you can see that it essentially makes use of a couple of variables and utilities like uname and the cut utility to essentially get rid
of unnecessary text. And then we have an if statement here, and these are the versions
of the Linux kernel that are currently affected. So it essentially passes
the three variables here through the if statement. And if it doesn't... As you can see here through
the logical statement, if it matches any of these here, then it'll essentially display vulnerable. If it doesn't then not vulnerable. So, fairly simple to understand. So now we've confirmed that this system, or this version of the Linux
kernel is indeed vulnerable. We can take a step back
and we can navigate into the Dirty Pipe exploits directory. So let me just type that in there. And as you can see, you're going to be provided
with the compiled script and exploit-1.c and exploit-2.c. So let's take a look at
exploit-1.c really quickly here. So exploit-1.c, and as I said, I've actually navigated to the line where I've specified this, but I'll just navigate to the top here and you can actually see all phases of the exploitation process
being commented here. So you can see firstly, create a pipe where all the buffers on the pipe_inode_info ring, have the PIPE_BUF_FLAG_CAN_MERGE flag set, and then it fills the pipe completely so that each pipe buffer will now have the PIPE_BUF_FLAG_CAN_MERGE flag set. It then drains the pipe,
as you can see here. The pipe is now empty. So if somebody adds a new pipe buffer without initializing its flags, the buffer will be mergeable. And in this case, the actual file that will be modified, which is a read-only file is /etc/passwd. So /etc/passwd is a file that is readable by all users on the system. However, only the root user
can make changes to that file. The password file on Linux is where the user account
information is stored. On previous versions of the Linux kernel, this file also stored the actual passwords and then later on the hashed password, but now the hashed or the
encrypted Linux passwords are stored in the /etc/shadow file, which is only accessible by the root user. So just to explain how this exploit works, it essentially adds
the following password, salt to the /etc/passwd for the root user, and I've provided you with
instructions here as a comment at the end here on how to generate your own password or salt with OpenSSL. So you can just type in openssl passwd -1. You then specify that you want salt. And then the username,
which in this case is root. And the password that I set that is actually salted
here is just piped. So that's what it is going to set it to. Now, the really cool
thing about this exploit is before it runs, because
it's going to make a change to the password file, it's going to take a backup of the file and it'll then provide you with a... It'll actually log you in or
authenticate as the root user with the password that you set, and then it's going to execute
a Bon/Shell session here, as you can see, and it then restores the original password
file that was backed up in the temp directory and
essentially replaces it. So from this perspective, very little artifacts are left, and you can pretty much tell that this cleans up after itself. That's exploit one. Exploit two is, it pretty
much works the same way. The only thing it does is it takes over an SUID binary of choice that you specify, and then essentially replaces it with its own ELF code or
shellcode, if you will, and then provides you with a root shell. So to compile both of them, just execute the compile.sh script. As I said, make sure that
you have GCC installed in order to compile this. So I'll just type in or hit enter there. And if I list out the
contents of the directory, we now have the ELF binaries here. So we have exploit one and exploit two. So before we actually
execute any one of them, I'm just going to show you that I indeed can view the contents
of the password file. And you can see we have the
unprivileged user account there and the root user account right over here. And if I list out the
permissions for /etc/passwd, you can see that only the root user is allowed to read and write. All other groups and users on the system can only read or, you know, essentially read the content of the file, but not make any changes to it. So we'll exploit or use exploit one. So we'll just say exploit one, and we are executing the binary now. I'll hit enter. As you can see, the first
step is it's going to back up the original /etc/passwd
to the temp directory, and it's gonna save it as passwd.bak. It's going to set the
root password to piped, which as I said, you can change yourself or generate a new password if you want. And then it's going to restore
the original /etc/passwd from the actual password file that was stored in the temp
directory, and there we are. So it tells us done! Popping shell. You can now run commands. So if I type in ID, you can see we've elevated
our privileges to root. And of course you can also
spawn a Bash session here. So there we go. So, we can pretty much
do whatever we want now. As root, there we are. So I can actually display
the actual shadow file. And yeah, so that's how
to use the first exploit. - So you've taken the original work and you've just simplified
it and allowed us to... I mean, you basically
type like two commands and you get access, right? - Yeah, so what I did was
I essentially set it up for pen testers. The original proof of
concept exploit allowed you to modify values within a read-only file by specifying the offset. So you need to specify what
character you'd like to change and then what you'd
like to replace it with. So I've just simplified that process and I've essentially reworked it to make sense from the perspective
of a penetration tester, whereby it cleans up after itself. It replaces the root
password just to the point where it can execute a shell as root. Once that is done, it then restores the original password file. - Well, done. I mean, it's brilliant. Well done. Thanks for making it so
simple for everyone else. - Yeah, appreciate that. Yeah, so the second exploit is one that I really did
not make many changes to. It's fairly simple to understand. I'll actually just go through the exploit code here really quickly. So exploit-2.c. And again, all of these
exploits were originally forked from the original proof
of concept exploit code. And just a few changes have been made with regards to what
files you're modifying. So you can see that right over here, this provides you with
various instructions in regards to what it does. And right over here, we have the ELF code. This is the unsigned ELF
code that will be injected into the SUID binary that you specify. And then of course, it
goes through the process of creating the pipe, draining the pipe, et cetera, et cetera. And then at the bottom here where it comes to the actual execution, there we are. We can actually see it here. I'm not sure whether I can
explain what's going on here, but you can see that it
says, hijacking SUID binary, if the path or the
hack's path and ELF code, and we essentially pass in
the size of the ELF code are not equals to zero, then print failed and then exit failure. And then in the case of
these logical statements, what is then done, if it actually passes this logical check, then it drops the SUID shell. So system path is the
variable set up there and simply put, it provides you with an elevated Bon/Shell session. - I mean, you're just making it so simple because we just have to run a few commands and it does it. - I don't take credit for this exploit because this is something
that someone else developed, but I made a few changes
to it to make it stable because the original one
had a couple of issues. But yeah, running it is very simple. You firstly need to
identify an SUID binary, which again is fairly simple to do. And I've already highlighted
how you can do that within the GitHub repository. So when it comes down to running it, you just specify exploit two. So, you run the binary and then specify the path to the actual SUID binary. So in this case, ./exploit-2/user/bin/sudo hit enter. So it'll hijack the SUID binary, drop the SUID shell, restores the original SUID binary that had the actual ELF
code injected into it. And as it tells you right over here, don't forget to clean
up the following binary, which is the Bon/Shell binary, because this is the one that
was changed or modified. So, if I type in ID, you can see we currently root and we can pretty much
do whatever we want. So yeah, that's how to exploit
the Dirty Pipe vulnerability. - That's great. I mean, again, I wanna thank
you for putting the work in because you've made it so easy for us. What I like about this is you are taking the work of someone else, and all credit to the people
who've done the original work, but you've extended it and made it easier for us just to run a few scripts. Do you wanna talk any more about this or can I ask you some more questions? - Yeah, I think I've pretty much covered all aspects of the vulnerability. So yeah, I think I'm good for questions. - So, I mean, when I look at this code and I think a lot of
people are gonna be looking at that code and they're
just gonna be thinking like, wow, okay, whatever. How did you learn this? Is this like learning Bash? Is this learning C? How did you learn to get the knowledge to take the work of someone else and make these changes? - Well, yeah, that's a very good question. I think, as I said, I did
have experience with C, which is why I'm quite good
at looking at C exploits and learning and actually analyzing what they do and how they work and sort of getting an idea of how I can sort of make
it work in a different way or make it work better. So, and that's just not limited
to actual see C exploits. I also know how to develop in Python, so I can read Python exploits. I think the easiest way to actually get into exploit development and
even modifying other exploits and making them better, is to start trying to write
basic scripts and exploits. So one good way that I've
actually seen working is to take a script that is
written in an exploit script that's written in Python,
a very, very simple one and try and rewrite it
in another language. So that process allows you
to essentially find out what you're doing and
how it can be replicated, or you can try and rewrite
it and make it simpler and make it more efficient. So one of the great
things about programming is that it's, the best
way to learn programming is to actually just develop
whatever you want to develop. So you can always take a look at a script and perform a Google search
on particular command. So let's say you didn't know what the main function does in C. You can easily find
that info and you learn that the main function is executed first. Stuff like that. - So I mean, that exploit
was written mainly in C. Is that right? - Yeah.
- So, okay. So C is a hard language. Which language would you recommend someone start learning first? I think you said either Bash or Python, is that right? - Typically recommend Bash first, Because Bash will really... And the reason why I say Bash
is primarily because Bash, it sort of introduces you to
the whole process of scripting and writing scripts for
the purpose of automation or to accomplish a particular goal. Because if you're going to C and Python, you may be drawn projects that really don't have an end goal, and you can just... You'll essentially be stuck
developing ELLA world programs. Whereas if you go ahead and learn Bash and you learn how to automate backups, you can start getting an understanding as to why this is important. So you can also write quite
a few exploits in Bash, but you'd need to integrate
other languages as well. But once you learn Bash,
I would recommend Python. And, we have seen tons
of really cool exploits being written in Python. So take a look at a couple of simple ones, learn how to develop an Nmap
automation scanner with Python, how to scan for ports using
the various Python modules that you can import. And once you know how
to basically automate the exploitation phases
or the various steps involved in an exploit, it's
really very simple to do. So yeah, once you get
experience with Bash and Python, you can then start moving on to developing exploits for Windows, or developing a simple key logger. That's a good place to start. There's multiple resources on that. So, you can start getting an understanding of how exploit developers
and malware developers write their exploits,
how they evade detection. Yeah. So. - What do you think about Golang? - Yeah, Golang is something that's becoming increasingly popular. That's applicable, or that
makes sense in specific cases. So if you actually take a
look at the pen testing tools, the state of pen testing tools right now, Golang is being implemented
in specific tools that require speed and efficiency. So Golang allows you to
have multi threaded support, which is very useful if
you're developing a scanner and stuff like that. It's a language that's gradually growing. However, I don't think it'll
actually replace Python because Python has a ton of modules that can pretty much do
a lot of work for you when it comes down to networking and parsing in, web pages, et cetera. - So, I mean, always the
big question is, okay, so I need to learn Bash,
I need to learn Python. How do I do that? Do you have courses? Do you have YouTube
videos or recommendations? - I would recommend one book, which I think is actually free now. The book is called, "Automate
the Boring Stuff With Python." That's definitely a very good book, because it gives you really good examples that show you the power
of Python and scripting and how to automate various
aspects of your life. I think I would actually
recommend that to anyone who was asking me the same question. - And Bash? Do you have any
recommendations for Bash? - For Bash, I don't think
I have any recommendations in terms of courses and books. There are a couple of
websites that could be useful, but I'm not really sure
if I can remember them. If I do, I'll be sure
to give you the links. - I've added the links below. So click on those links if you wanna go and learn about Bash. Alexis, I really wanna thank you for sharing so much of your knowledge. Do you have any closing
thoughts before we wrap this up? - I would like to say,
thank you for having me on. I really appreciate it. And I think, the actual
content you're producing is really, really good. If you are getting into this field, get into it with the mindset of a beginner and just be willing to learn, because this is a a role or an industry whereby you have to be learning every day, as you were able to tell
with this vulnerability. So with every new vulnerability, there's always something
to learn on both sides. On both the red team and the
blue team side of things. So, yeah. Thank you very
much for having me on. I really enjoyed the session and hopefully I'll be
talking to you again. - Yeah, definitely. If you're up for it, I
definitely wanna invite you back. For everyone who's watching, please give me questions
you want me to ask Alexis so that when he comes back again, hopefully I can twist his arm, we can get him back to
teach us something else. Do you wanna learn about Bash? Do you wanna learn about Python? What about C? Anything you'd like him to teach us then put it in the comments below. Alexis, thanks so much. I really appreciate you taking the time. And just before we sign off,
please, everyone watching, go look at the links below. I've put Alexis's social
media links below. So please go and follow him on Twitter. Follow him on YouTube and other platforms. Alexis, Thanks. - Thank you very much, David. (upbeat music)
