[RHYTHMIC ELECTRONIC MUSIC]
[MELODIC ELECTRONIC MUSIC]
Hello, and welcome to the Hacker House Hands
On Hacking practical module for the NAS module of our course.
So I've got here on my screen my VirtualBox environment.
I'm currently running my Kali Linux install,
and I've got here my lab set up to use the file server ISO.
I double checked my host only adapter
to make sure we're running in a sandbox,
so that we don't impact any other resources on our network
and we can test our attacks and systems exploits out.
So I'm going to boot this nice appliance now--
and remember, if you don't get an IP address straight away,
simply hitting return a few times
is often sufficient to give you the IP address.
But we can see here, once again, I've
been given the IP address 192.168.56.3,
and that's because I'm continually
reusing the same lab and swapping over the CD.
However, if you do that, it's important to remember that you
might need to clear your browser cache after each adventure,
because otherwise, you may find that your caching
some information on your local machine, which will be reused,
and you may not get the same--
the same output or experiences you're seeing on the screen,
here.
So ensure that you clear your browsing history.
Make sure you've got no kind of lingering data lingering
around in there.
And then we can ping that IP address, and we are good to go.
We're good to start scanning that server.
So the first thing we do when we're
trying to scan a server is initially review its footprint,
have a look at what kind of service ports
it might have open.
I'm just running a standardized Nmap Remember,
this isn't a comprehensive scan.
It will just find a couple of common ports for me
and show me what they are all about.
Because we're now on an internal network perspective,
and we're somehow situated inside the internal network,
we're perhaps not as worried about firewalls,
so we could now try out maybe some of those buying payloads
or all those-- because the firewall is
less likely to be in our way.
But we can see here that we've got a standard what
looks like a network appliance of some sort,
we've got FTP, Telnet, RPC--
common kind of Windows sharing services,
all this-- common internet file system.
Into ipp-- some kind of printer sharing-- rsync and something
called NFS.
So we've got a number of different services there.
We would begin with our banner grabbing process,
we connect to each of those ports on port 21.
You can see there we've got a welcoming banner that
tells us some information.
So if I was to connect to this service and try, OK, USER FTP,
PASS FTP--
ah, we can see here that this one's actually successful.
And if I type stat, we can see that it says here that this
is version 2.3.4 of the vsftpd.
So we can actually find the version number--
not from the welcoming banner, but from querying it
from the stacked command or status on the remote server.
It says client count was 1, and it gives me some information
about that system.
It gives you the status--
the status of what I'm connected to.
So if I was to come out of that system,
could I just type that by itself?
It says no.
If I was to try USER anonymous, PASS anonymous--
we can see that we can log into that FTP server.
So I'll now log into that FTP server using an FPT client,
and I'll try FTP FTP, and I'll list the files in there--
and what we can do is we can now explore the contents
of that FTP server.
I'm going to also have a look at some of the other ports that
are out there, but before I do so,
I'm going to kick off a more comprehensive scan.
I'm going to do Nmap minus sT -P, disable pings, disable DNS,
and then I will do default scripts, do aggressive mode,
vv, and then disable--
then once I've got those in, do a full 65K handshake.
So, connect scan, disable pings, disable
DNS-- to increase the speed of my scans.
You don't need to disable these two,
but you'll get faster responses when you do.
-sC, especially if you know the host is alive.
If you don't know whether the host is alive,
you might want to leave these on.
-sC will then do default scripts.
-A for be aggressive-- do some fingerprinting,
be verbose, tell me what's going on on the screen.
-p- And then I want to run the probes against this server.
And then I'm going to make sure that I dump it out to a file
called Nmap.txt and Nmap.xml.
Now, we can see here we've got a number of other open services,
including things like Telnet.
So if we were to Telnet to that server,
we can see now Telnet into that server has given us
Linux welcoming banner.
It's giving us the kernel version of the server,
and we can see that that is in fact an out of date kernel
version, we should recognize that it's a version that's
vulnerable to Dirty COW.
So we know that this server has privilege escalations,
we know that it's running out of date software-- just
by connecting to the welcoming banner.
But if we were on the FTP service
now, if we go in to see the backup ls,
we can see there's a file called Read Me.
If we go into incoming ls, we can
see there's nothing in there.
So I'm going to go to the backup directory on the FTP server,
and I'm going to type get Read Me.
So I've downloaded that Read Me file into my local directory,
and if I open that Read Me file, you
can see here it says, "the system backup account is
configured to run under the user backupserv,
and it uses rsync to access remote files
and install them in the FTP server for nightly collection.
Speak to Dave for help with this application."
So this is a kind of a backup account or some kind
of backup service that's using this storage account,
and it says here the user is backupserv.
So if I see something like backupserv,
I perhaps create some passwords, maybe.
If I go to Word Lists , have a look at weak passwords,
maybe I'll add the password backup into weak passwords,
I'll add the userbackupserv into weak passwords.
And then, perhaps I could do with hydra, and say well, OK.
Hydra, minus, minus, help.
Let's see if I can try a brute force
attack against that Telnet interface, do Hydra minus L,
and then we'll give it just a user--
and I'll give it the backupserv user.
And then I'll say, OK, well P, pass list.
I'll try word lists-- you know, weak passwords.
And we could try a brute force against this server
and see whether or not that would actually let us in.
Remember, you're not allowed to use this tool
if you're a member of the military
or if you're involved in a Secret Service organization,
as it would be against the license restrictions designated
by its author--
van Hauser from THC.
Now we can see the Telnet attempt, we tried to log in--
but we'll see whether we get any success with those brute force
attacks.
But looking through here, we can actually see now--
we look at our Nmap output, we can
see that Nmap has run a number of default scripts.
It's identified some other open services,
it's got some network filing services up there,
and we can have a look at some of those in just a second,
as well.
So we've got NAS, I think?
Did we just save that file?
Nmap.txt.
So I'm going to do xsltproc, Nmap.xml.
I'm going to convert that file now to NAS.html.
And then I'm going to open that file
and just look at it in a human, readable way.
Deal with this nice, pretty, formatted table--
so I can actually see what information I've
got from my port scans in a very clear and concise way.
And in fact, we can see all these various scripts
that have run, giving us extra information from things
like the SMB--
or Server Message Block service--
and we'll look at that slightly afterwards.
But for the moment, we're going to concentrate on these lower
ports down here.
We've done this FTP service, we found these files in here,
we found that there's a-- running an out of date
version of vsftp, perhaps.
We've also seen there's a Telnet service--
but above that, we can see there's an RPC info service.
So we're not having much luck with our brute force
attack for the moment, but what we'll
do is, we'll try RPC info and query that remote service.
And as you can see, with RPC info,
we can see port mapper, NFS, and lock manager mountd.
We can see these various options that might be available there.
So you can see it's [INAUDIBLE] 16 tries a minute.
Doesn't seem to be successfully doing a brute force
attack against there.
You could also perhaps try it against the FTP service--
I'll do rm minus rf hydra restore--
and try to do a brute force attack against the FTP service
and see if that works.
Oh, and in fact here, we now see the FTP service
was successfully brute forced.
The backup service user account password was backup.
So we want you to get into the habit of that--
same user, same password.
Maybe some variation.
So not a very-- not a very difficult password.
So that was backup.
So if I was to Telnet to that server now,
can I log in as backupserv, and the password of backup?
And as you can see, we're now logged
into that computer using a low privileged backup service
account.
So we've got some limited access to command shells,
we've got some ability to look around the file system.
However, there are other things on this server that
are of interest, and when we've run RPCinfo, we do RPCinfo -p,
we can actually see that we've got RPC information.
So when that port scan was returned there,
you saw that it was an open port 111.
This RPC buying service or RPC program number 100,000
is the RPC port mapper service, and its job
is to map remote procedural programs to port numbers.
We're going to do a lot of a deep dive
through some RPC and RPC vulnerabilities,
so I don't want you to panic too much
about what all of this stuff means for the moment.
Just know that here on the left is the program number--
that's the RPC, or the remote procedure called
the application that we can talk to,
the version of the protocol it supports,
and whether it's UDP or TCP, and the port number
that it relates to.
And here we can see we've got mountd in NFS--
these are some of the requirements that
are necessary for us to be able to mount a remote file system.
So how can we interrogate that file system?
When you see it's got 2-0-4-9, is an Open Service port.
So we need to check-- can we see 2-0-4-9?
Yes, we can.
We've got access to the NFC service,
and some of these higher ports down here
appear to be NFS related and RPC related.
You even have the program numbers there.
So you could map those from this--
from this output.
We can see we've got mountd, NFS, and Lock Manager--
common service ports that we might need
to mount an NFS file system.
The way we would do that is you show mount -e.
If you were to run showmount -e, 192.168.56.3, what that will do
is it will connect to the NFS service
and show us any of the exported mount lists.
And we can see here the export list for 192.168.56.3
includes slash data and slash home.
However, /home doesn't have a star next to it--
it has an explicitly defined subnet.
This is an access control list that
says that unless I'm in this subnet,
I'm not allowed to mount this file system,
so I would not be able to mount the home directory due to an IP
access control list.
However, the star says, anyone can access this
from any IP address, so I could attempt to mount that.
So I will do mount 102.168.56.3, colon, slash data, and then
I'll do slash mount, slash data.
You might have to make slash [INAUDIBLE],,
slash mount, slash data if you don't have a file there,
but I have it already created on my system,
so I'll ls-al slash data.
And if you check the output of mounts now,
you can see that there is a mounted NFS
share on my system--
192.168.56.3-- slash data has been mounted with NFS.
And you also have the various options
that were supported at the time of mount,
so I can see if there were any security options set--
in particular things like no swede, or things like that.
Route squash, another one I would be looking for.
I don't really see anything like that on there.
So what I would do is I would go to cd /mnt/data ls-al.
And what we can see here is we've got
numbers instead of usernames.
So we're back to that Unix permissions model, now.
What we can see is, we can see, OK, there
were some files here--
skeleton files.
These are default files that are in a user's home directory,
typically-- so it appears we've mounted a user's home
directory--
and we can see here that the user who
owns these files is the user ID 1006, and the group ID is 1006.
And here we can see that that user has read,
write user permissions, but it has read only permissions
to the group, and everyone else on the system
has read permissions.
Everyone else on the system includes me
from the network perspective, so I can also read these files,
because I have mounted those files
and that other flag applies to me, as well.
So if that wasn't there, then I may not
be able to open these files unless I
was a member of those groups or part of that user ID.
So we can see there, I can access any of these files,
because it's getting these permission flags, here.
So if I was to now look at the remote backup server,
cut the /etc/password file and grep 1006,
what you can see is 1006 is actually a backup user--
and if I was to do ls-al in this directory,
we can see it's almost the same file systems.
And in fact, it is the same folder and file
system we've mounted over NFS, but instead of 1,006,
it's now given us a human, readable mneomic
of that user name.
So that's actually the user on this remote system.
However, on my computer, there is no user 1006,
so these permissions don't really matter.
So, the-- it doesn't tell you that it's
the backupserv, because there's no such user on my account.
There's no such issues on my computer.
So what happens then, if I create a file here?
So if I make a file called x, OK?
We've now made an empty file owned by the backup user.
If I ls-al in this directory, I can now
see that there is a file called x.
OK, so I can add files in there from that backup user--
but what if I was to add a file now from here, and type touchx.
And then I was to go to this system and type ls-al.
Now, can you see the problem?
We've got a root owned file in that folder instead of one
owned by the backup server, and this
is because the network filing server
has taken the permissions from me, the connecting client,
and is using and trusting those--
so I'm able to specify whether or not--
what user owns a file on that share when I create it.
And of course on this server, I do not have root permissions--
I, in fact, am only a backup server.
So I'm now going to give myself root permissions.
The way I'm going to do that is I'm
going to copy the file bin/sh into this directory,
and I'm going to call it exploit--
and I'm going to do that from my Telnet shell,
because that's the same binary--
the same compiled shell--
as is running on the system currently.
So with my exploit there, sat on the server,
I would now go for my mounted NFS share--
and if I look at that file, I can
see the exploit is owned by the backup server.
So I would do chown, root, root on exploit,
which will give me the exploit--
will give me the exploit, there.
I've got root, root--
and I now own that by root-- and then I would do chmod.
And what I'm going to do is, I'm going to set
that imaginary sticky bit.
So I'm going to set that to stick the user's permissions--
and here you can see that this file is executable--
executable by group, and executable by everyone else.
Everyone can run this file, everyone's allowed to--
the root's user can read and write to it,
but I'm going to change that.
I'm going to make it 6755.
I'm going to make sure I've got read, write,
and execute for the root user.
I'm going to make sure it's got read and execute for the group,
and read and execute for everybody else--
but I'm also going to enable the sticky user and sticky group
bits.
So by doing that, if we now ls-al the exploit,
we can see that we've got read, write, and s-- instead of an x,
we now have an s-- and what that means
is, it will stick the user permissions
when you run that file.
So that file will be run as the root user,
and this group user, if you run it as the group,
will also stick.
So you will be root with a group of root
if you were to run that file.
So I will run that file, but not on this server--
on the remote server over here.
So I'm now the backup server, simply typing ./exploit
and ID--
you can now see that I've obtained the effective user
ID of ROOT, and the effective group ID of root,
and I now belong to the group root.
And in fact, if I was to just grep etc/shadow, head-n1,
you can see I can successfully extract the passwords
from this server, and begin exploring it as the root user.
So that's how we can use NFS to leverage these vulnerabilities.
You can do most of this NFS attacking manually
by the command line.
There are some tools to do it for you-- things
like NFS Shell-- they're very long in the tooth
now, and very kind of dated, and in fact, doing
this process manually is much easier.
So you can just do it like that.
You can, of course, specify all the user IDs.
You can, of course, change things around
however which you want--
and if you were to cache etc/bash exports
on this system, you can see here that there are some security
options set on the other option, which says root squash--
and this one has no root squash.
And in fact, the system administrator
can prevent these files when they are uploaded--
they could be changed to nobody, so that anyone uploading a file
would be set to nobody--
and also prevent you from accessing or running
files and uploading files with a sticky bit.
So NFS can be configured to prevent this attack, however,
in this option here, we can see that they haven't-- they have
unsuccessfully set the security options,
leaving that /data NFS mount exposed to a privilege
escalation attack.
So from there, we were able to escalate
privileges. we've gained root access to the server--
excellent-- through NFS.
And looking through backup files and connecting in from password
guessing and similar attacks.
So you wouldn't need to guess a password to use that NFS,
but you would need some way of running
that command on the system.
You could just mount those shares and upload files there.
You could have added it into the users bash profile,
see if they-- the next time they logged in,
you could have just added commands to there
and they would have executed.
So that's the NFS.
If we were to now go back to this,
here-- we've explored some of the NFS weaknesses.
You can see there that's most of the RPC services.
There are, of course, now some other NetBIOS name services
and some [INAUDIBLE] services.
But before I go on through cups and various others,
I want to have a look at the server,
because we're on an internal network perspective.
I want to perhaps have a look for some UDP probes.
So if I was to do a UDP scan against this host, remember,
it's probably much quicker for me
to just scan for common UDP ports manually by hand.
I'm looking for things like TFTP, SNMP, and probably NTP--
just for some information leaks, if they're there--
and then again, some VPN related services.
So I'm going to do for port in cat udp.TXT.
And then I'm going to do echo $ testing port,
and then I'm going to do h ping 3 -2,
and then I'm going to do -p $ port.
And then I'm going to give it the IP address
of the system I'm targeting.
And I'm going to give it -c1.
I want it to send a single packet
to each of those UDP ports and see whether any of them
are open.
And I can see I get ICMP port unreachable.
Port unreachable.
Port unreachable for most services--
with the exception of 69 and 161.
So these are port 1601 and port 69
appear to be open on this host.
So if port 69 appears open, simply connecting to it
with TFTP, and then typing get test,
would say OK, file not found.
So on this service, now, what we can actually do
is we can try and test for the presence of files,
and see whether or not they exist.
So I can do get things like backup, get config, get in it.
And I would just keep going.
And here we see actually there was a password file.
If I was to come out of that [INAUDIBLE] password file,
we can actually see that TFTP service also leaks
some information because it has a password file
accessible in its folder.
So we can see here all the different uses on the system,
we can see--
in fact, there are no other users on the system.
We can see FTP, TFTP, we can see some information about accounts
that are on there that we could maybe try and get access to.
We don't see that backup server or anything else,
so not 100% useful for us.
But we saw that we can use TFTP, and indeed,
if you go to a website like Packet Storm,
you could find something like TFTP Brute.
I believe there's a number of brute force scripts
and tools out there-- and in fact, there's one in Metasploit
as well, that you can use to guess those file names.
So, OK, TFTP is enabled--
But I also saw 161, which is usually used for SNMP.
So 161 can of course be proved with a tool called 161.
So 161 is a brute force tool which
will try to guess community strings for open SNMP services.
So we would do that by opening the community file,
giving it a list of passwords--
I'll try things like public, private, hacker--
you know, seven characters.
Hackers, support, testing, engineer--
you know, things like this that might hopefully
trigger something up.
And then I would do 161, give it the community string,
give it the files I want it to get--
so the IP address I want to target, which is this one--
and simply type run.
And as you can see here, it will scan that host
and see whether or not any of those community strings
are valid.
And we can see public and private are valid,
So if I was to do SNMP walk -c, then I would do public,
then supply the IP address 192.168.56.3--
and you can see here, it says "no security name specified"
because it's trying to connect with version three.
It's trying to connect with a newer version of the protocol.
So I'm going to specify -version 1.
And here you can see, SNMP walk for version one of the protocol
with an insecure community string
allows us to get maximum information,
such as the operating system kernel version,
and some other diagnostics information
that could potentially be used.
And we should be able to explore this mid table and perhaps find
things like Mac addresses or other malicious stuff--
boot arguments, perhaps--
and could maybe try to change some of these options
with the private version, which is a writable version.
And if we were to type private, you
could then try things like SNMP set,
and actually try to change some of these option
and interfere with the entries in there.
So, SNMP, a way of reading and writing entries,
and they may be beneficial to you
to compromise some system or service.
If I go back now to our output-- if I go back to our port scan
output--
we can see, well, we've looked at NFS.
We've gained route to the server.
But there's also this SMB related services, as well,
and some others later on in the CUPS area.
So before I go into the kind of other exploitation areas, what
we're going to try and do is we're
going to try and look at that Samba service
using a tool called NBT scan.
NBT scan will do a NetBIOS table lookup,
so it will be using things like server message
block and NetBIOS to do a scan, to identify
options and settings and group-- group IDs
and things that the server might have set,
and that can be useful to us.
And we're going to try-- we want to get
into that common internet filing system
to see what kind of files and things are on there.
So I'm going to just run NBT scan, -v, the IP address.
And what we can see here is--
I've done an NBT scan-- and it says here it's
a file server group, MS browse.
It's giving us a lot of information about group
for unique, you know, what kind of--
groups and work spaces and work groups it belongs to,
and whether or not it's a member of a domain.
And then these services actually equate back to the services
that it provides available.
So if I was to download, now, a couple of other tools--
and we're going to explore through these.
So I'm going to download from Hacker House stuff.
I'm going to download a tool called RI,
and another tool called ewalk.
chmod +x, ewalk.
ewalk is a tool for enumerating extra information out
of hosts when you've got a valid community string.
So I'll do Ewalk -SMTP.
And then it says, dump the art case.
Try and do complete sundries--
[INAUDIBLE] for sun systems--
we'll maybe look at that slightly later on, as well.
But trying it with public, you can see here, no.
Exit.
So you can see here that this ewalk tool will basically
try to do some enumeration as well, using that SNMP service
that we saw--
and it's also got a touch for a--
basic touch for some exploitation
purpose, but also has the ability
of looking at different processes
and looking through like doing a walk on HP-UX and getting
extra information.
So ewalk's a useful tool for probing RPC services,
because you can get some extra data with it.
Another
Useful tool from the NSA leak is a tool called RI,
which when we did that our RPC info tool,
and we did RI instead, and we could do grab all available
info with -c, and just simply supply it to an RPC port mapper
service--
and you can see this one is actually segfaulted.
Just trying to connect to that port service
and try to use UDP.
I'll try and see does it make a difference with TCP?
It doesn't seem to.
And I'll just try and see if I can do it with -c,
see if that changes it at all.
OK, and it seems to just be crashing on this RPC service.
But that when this tool works, it
can connect to some of those RPC services that it finds
and give you a bit of extra information--
not just the same kind of information
you get from 192.56.3.
So some of those NSA tools can be
quite useful for proving additional hosts and services
and gathering a little bit of extra information.
So we're looking back now at this NetBIOS team,
that NetBIOS scan.
If I was to do enum4linux at 1 and 2 to 56.3,
enum4linux will allow us to connect to the server.
Enum4linux makes use of these common windows service ports
and does various enumerations.
It connects into them and does things
like uses RPC checking tools to actually probe
some of these server message blocks and learn things.
So you can see here for instance,
it's actually changed those service numbers
into actual services.
And one of the things that you can see
is the number 20 is a file server service.
So we know that this Server Message Block service
offers the common internet filing system,
because it's got a service type defined as number 20, which
is the file server service.
So we can actually try to mount that.
We've also got some username enumeration.
You can see if we can find some users from that service.
We could try some brute force attacks.
So if we would just try enum4linux and let it enumerate
information from there, we might find extra information
that could be valuable.
And indeed it's even outputted all
of the shares that might be accessible on that host.
And I'll show you how to get those in just a moment.
This enumeration tool can give us
a lot of information when we see these so-called Windows Server
services.
So if I was to do now smbclient, for instance, smbclient -L,
and then the IP address of the server,
it simply says enter workgroup and password.
So I could supply username and password.
I'm simply going to return because this server seems
to have been set up for anonymous logging.
So we can actually connect to the service and list
the shares that are exposed.
So we can see here, well, it says
I can mount the data share.
So I will do mount -T6.
I'm going to un-mount the data share I already have mounted.
And I'm going to try mount it through Common Internet Filing
Systems.
So I'm going to do mount -T, Common Internet Filing System,
and then I'm going to -O. And in my options field,
I'm going to supply version=1.0.
Because server message about 1.0 is considered to be a legacy
and more insecure, you might have to explicitly set it
as new SMB.
And Server Message Block clients will enforce newer versions
of the protocol as opposed to using legacy insecure versions
which are susceptible to a number of man-in-the-middle
and replay related vulnerabilities.
So I'll do version=1.0, and I'll also do user=guest.
And then I'll supply the IP address of the server.
And I will also do a :/data, and then I will give it my folder
path, which is mount/data.
And I need to change this path now
to be what's known as a unified network or a UNC path.
And I will do slash-slash-slash-slash.
And remember to doublescape your slashes on Windows
and then it's also slash-slash like this.
So if you've ever mounted a share under a Windows
environment, you may be familiar with that path looking
like this.
But I would actually need to ensure that there are double
slashes to ensure that those slashes make it
into the command.
So we can see now we've got guest at this use.
So I'll hit Return.
And it says permission denied.
I can't mount this data share unless I have a valid username
and password.
So without a valid username and password,
I can't actually access that data directory.
But I could enumerate those usernames and passwords
from my list.
So I could then try a brute force attack.
I could try all of those users with weak passwords
and a brute force attack and see if I could get in.
But I already know the backup server uses password of backup
from password guessing.
So I'll try backup serve and then the password of backup.
And you can see that that allows me to mount the directory,
and I'm back in that users home directory.
And if I do Touch X, I can now also write to that directory
as well.
So that gives me a little bit of information
about the SMB service.
I can mount that file system and I can write files there.
So what else can I learn about that file system?
I've got Common Internet Filing System.
I've got an exposed Server Message Block
port that provides a number of services which
I can interact with, one of them being the Common Internet
Filing System.
So if I was to go back to my MDT scan, or in fact
my EnMAP output, and have a look at what information
came out from there.
And we can see from the SMB information
that port 445, it was possible to fingerprint this service
as being smbd 3.5.6.
So if I was to do SearchSploit Samba,
we can see here that the Samba server is 3.5.6.
It is considerably out of date and is
vulnerable to an attack known as is-known-pipename, which
is commonly known as SambaCry.
It's a way to upload a file onto a link system
and get code execution this using
this is-known-pipename exploit.
So if I was to have a look at this is-known-pipe exploit,
I believe that there was some limited worms that
tried to leverage this capability as well.
It was labeled as a vulnerability like WannaCry
for the Linux-like filing systems
because there's so many little things that would use this.
And in fact, I've been finding increasingly a large number
of embedded devices which don't keep their Samba services fully
up to date and have been exposed to vulnerable attacks
and weaknesses like this.
And in fact, several of them currently
are still awaiting patches from vendors.
So it is a continual problem.
So if you were to search through here and do a search for Samba,
we could see various exploits for Samba that might exist,
one of them being the is-known-pipe overflow.
And we can see here it says it's excellent in terms of rank.
So I'm not really going to be concerned
that this might crash the server or cause any corruption
or anything else.
When it starts to get to average, normal, great, things
like that, I might be concerned that they could
crash systems and services.
So let me have a look and see what we can do with this one.
I'll do Use, Edit, Paste, Show Information.
Here we can get an information as to the description, what
the problem is.
It says that if we can upload a file and it's writable
and we're using this version of Samba,
we can use this to exploit it.
And it even says in some cases, simple anonymous access
is sufficient.
So in our case we are going to actually set
[INAUDIBLE] various targets, automatic targets
on this system.
So if I was to do Show Options, we
can see here that the options are specified.
I'll set our host to specify the host I'm targeting,
set the SMB folder, which is the writable folder
that I can access.
And the name of the SMB share--
oh, I'm going to change that to SMB-sharename, data,
and the SMB folder I don't need.
And then I'm also going to set SMB-user to be my backup
serve user, which is missing from the readme of this module.
But simply setting SMB pass will make sure
that these are the SMB usernames and passwords that are used
to serve the message block.
So if I then do Show Options, you
can see that those options aren't specified there,
but they are required for this exploit to work.
And if I was to do Show Payloads,
you'll see there's only a single payload available.
And that payload allows me to have an interactive Unix shell.
So if I run this exploit, you can see now
that it's connected to the server.
It's uploaded an exploit and it's created a shared object
using that .SharedObject file.
We'll look at some more shared objects later.
And it's now opened a command shell.
And when I execute that command you can see
I have root permissions on this host.
And this exploit is a little bit unstable
as the process will eventually get terminated by the Samba
service, so you may only have root access
for a couple of seconds.
So there you go.
Command shell one session is closed.
That's how you could leverage SambaCry
to probe these services.
So using SMB client, mounting shares, probing shares, brute
forcing attacks, as I've said before,
it's worth trying these things out.
So once you've uploaded files, we
can see we can leverage that command injection
vulnerability there, or code injection vulnerability, I
apologize.
And now we have some things like printing protocols.
And we have a couple of other things available to us.
So we'll have a look at that printing protocol.
So by connecting to 192.56.2, powerage 631--
oh, I apologize.
It's 3.
So 192.168.56.3.
We now see we've got the CUPS service accessible there
with various printing capabilities--
introductions of CUPS, CUPS API, filter backgrounds.
If you were to click on Printers, click on Jobs,
click on Classes, you can see that this printer service
doesn't seem to have any kind of password protection.
And in fact, if I click into Admin,
I can seem to try and add printers.
And then it says I need to upgrade to SSL.
And once I've upgraded to SSL, I could add exception.
And it seems that this is an insecure printer service.
When you actually get to these kinds of services,
it's very typical that people haven't
configured them correctly.
And it says, allow remote administration,
share printers, and allow printing from the internet.
So I can actually manage the printers on here.
But one thing that I can see, and there's a little nice
trick about CUPSes.
It says, edit configuration file.
And inside this configuration file,
I could actually set the options that are being used for CUPS.
And if we have a look for CUPS set and directive set::ends
and passend, if we were to look at set::end and passend we
might be able to specify environment variables inside
of this configuration file.
So maybe I would specify at the very top of this file,
say set::end.
In my environment I'd like you to set tic my evil commands
and specify my benshare SH, 192, whatever.
So that when CUPS restarts, it will try to run my commands
using this set::end that we'll try and use for that parameter
in there.
And then saving that file.
Say OK.
We would hope that CUPS would then try and use
some password guessing to try and save it.
So I might use brute force that password and see what happens.
Simply typing route, maybe a blank password, route route,
things like CUPS CUPS, et cetera.
CUPS, CUPS.
But once you can set that configuration file,
the next time CUPS restarts, it would
try to read that configuration file
and subsequently execute your commands.
So that's a way of experimenting and hacking the CUPS service,
adding printers, trying to make use of these services,
trying to get them to load code or execute commands, command
line printing and options, changing things like that.
Trying to mess around with the printing service
to get code to run.
And again, as I mentioned earlier,
there's a really cool tool that I've
been using for years called Hijetter, which is
a really nice PFT and hijetter.
If you haven't ever done any printer hacking,
this is a really cool little tool
that's worth reading through and having a little play with,
as it allows you to do some fun and interesting things.
So CUPS printing services, command injection
sometimes vulnerable to shellshock as well.
Worth checking for vulnerabilities
too like shellshock on that system and service.
So I'm just going to look back on my port scan outputs here.
I want to ensure that we've covered
everything for this module.
We've done SNMP services.
We probed our TFTP service.
We've looked at our various different vulnerabilities.
We've been able to exploit the SambaCry service.
And I'm going to show you one more vulnerability
and how it works in Metasploit just because it's
an interesting one.
But you will never see this in the wild.
If I was to telnet to the FTP service on port 21
and try to log in as the user, testing with a smiley face
and the password of testing with a smiley face,
you'll see the application is halted.
And indeed, if I was to now net cancel
that server on port 6,200, you'll
find that I have a route shell waiting for me.
And I'll explain this now.
This basically is a backdoor that was implemented
into the vsftpd 2.3.4.
A hacker broke into the software service site, modified
the service code so that when you logged in
with a smiley face, it would open a little backdoor
and allow him to connect in and get root permissions.
And it was done to the very secure ftpd service
and was accessible for about three weeks.
So for around three weeks this backdoor
may have trickled down into some software packages,
although it's very rare to actually see it in the wild.
And if you do search vsftpd, you can see here there's
a module for vsftpd backdoor that you can use in Metasploit
to trigger this vulnerability.
So using Edit, you use Paste to show info.
You can see the description here.
It adds a malicious backdoor, a backdoor
when it was introduced and removed,
and gives you some information.
But all this Metasploit module does
is the exact same thing that we just did there in the terminal.
It simply tries to log in with a smiley face
and then opens a connection to that port.
So although it's not actually a complex exploit,
you can actually see what this is doing under the hood.
So you can get familiar with how these modules are written.
And I advise you to have a read through it
and see if you can see how to manually recreate that process
just from this module input.
And if you were to do Show Payloads,
you would get the same kind of output,
because it only allows one particular kind of payload,
because it's actually using a backdoor.
So if you were to then run this attack,
you'd see the port is already open because I've already
connected to it.
So if I was to come out of here now, kill the service,
and you can see now the back door was spawned.
It tried to log in with a smiley face,
and it's done the exact same thing.
But now we have the nicety of being
able to manage it with the Metasploit framework,
be able to background our session
and kill it if we no longer need it.
So we could actually make use of more management from there.
So there was one service, just referring back to that.
And as clients there, we can see there is actually
one service which we didn't cover,
which was this arcing service.
And remember, we touched on it in the theory.
We were able to look at--
there was an arcing vulnerability,
which was exploited previously in the past.
So to use arcing services, we simply provide a URL or URI
which has arcing:// and then the IP address of the system that
has the arcing service exposed.
And here we can see it will list out the data or home directory.
So if I was to go /data, you can actually see I could access
that users home directory.
And if I wanted to download a file from there,
I could do like that, .profile.
Download here, and then I can have a look at that .profile
file and see what was actually contained inside of it.
You probably don't want to overwrite your own profile
by doing that, but this one should be .profile,
as it's in a hacker house directory.
So I can copy files off that system using arcing,
because of course there's no authentication enabled.
And just connecting to it will list out information.
So if I do arcing/home, what we can see here
is that the arcing service exposes the home directories.
And if you look at those home directories,
you can see each of those home directories
are in fact usernames.
So we've got another username enumeration leak
that we could try and use to information leak
off the server.
And we've also got here what looks to be misconfigured
Unix file permissions.
You can see we've got Peter, Peter K. And remember,
we mentioned that the other field applies also
to people on the network.
Peter K has set his home directory
as accessible to anyone on the network.
So through this arcing service, if I tried to access Claire
A's folder, you can see that I don't have enough permissions
to access Claire A's folder because the other user cannot
access them.
However, I can access the file in Peter K's home directory.
And inside Peter K's home directory,
you can see there are so-called Unix skeleton files that make
that user's access--
sets up that user when he logs in.
And one of those files is the .plan file.
And I'll save that to my file called Peter's plan.
And if you then open up Peter's plan,
inside there you can actually see that his account
has a password of Monday1.
And if we were to simply connect to that service,
I type Peter K, Monday1.
We can see that there's another way in which we
could have accessed things.
So trawling through arcing-related services
to identify vulnerabilities.
And again it's worth looking at that case from 2003,
as the individuals responsible were never caught
and it did involve a zero day attack against a vendor's
arcing service.
So very interesting read.
So basically, that pretty much concludes the arcing
enumeration.
And remember again this is all about Unix file permissions,
that that other field also relates to network users.
So that concludes all of the practical demonstrations
for this module.
I do believe that you could also use dirty counter
privest on this server.
But the main takeaway really is I
want you to get comfortable with that concept of Unix file
permissions.
I want you to get experience with changing
these different file permissions around.
So copying files over, understanding
that permissions model, because it
is important to be able to find files on a system.
If you have a look at that file test now,
you can see we've got read, write, and execute for user,
read and execute for group.
And I want to try some of those theory numbers I tried.
So 754, the test, and you should see
that you get the same permissions as was demonstrated
in our charts.
And I want you to get comfortable with changing
those permissions and understanding the concepts
and process of the sticky bits.
Because when you're trying to audit systems,
one of the commands you maybe use is find/-perm and search
for files that have certain kinds of permissions.
So -4000 is find all the files that have the sticky bit, not
minus type L. Don't show me linked files
because they have some erroneous errors
that we don't care about.
Send all the garbage to the dev/null.
I only want to know about the files that
exist on the system that have this sticky bit set.
And when you do that, you can see here
it will list all of the files on the system
that could potentially be used to gain root permissions.
And you can see our exploits sitting right there at the top.
So that concludes our practical demonstrations
for the NAS appliance.
As I said, this module does mimic commonly seen network
attached storage in the wild.
And you'll find that some of these vulnerabilities
will be present on many of these appliances.
So I want you to repeat some of these exercises.
Try and breach that server.
Leverage the NFS vulnerability.
Try and do some kind of brute force,
probe some of those services.
Enumerate as much information as you can.
And try to think about how would you report this to your client?
How would you explain what these problems are?
It's really important that being able to use these tasks
and being able to conduct these assessments is fantastic,
however, you would also need to explain some of these findings.
When you're able to gain root permissions,
you need to be able to explain how you did that,
or why it's such a problem.
So it's important to be able to do things
like check the exports file and see
why that vulnerability exists and make recommendations
that say, hey, what is that vulnerability
and how to fix it.
And so that concludes the NAS appliance.
Thank you very much for your time
and I look forward to seeing you in the next module.