[WHIRRING AND CHIRPING]
[WHOOSHING]
[MUSIC PLAYING]
Hello, and welcome to the Hands on Hacking Unix
module practical demonstrations.
We're now going to run through all the necessary steps
to breach a Unix server from a practical perspective.
But we're going to import this lab in a slightly different way
to our previous modules, as we're going
to import it as an appliance.
So if you go to VirtualBox and click File,
Import Virtual Appliance.
And then you will need to supply the IP address--
the file, sorry, that you have downloaded.
So I've got hhunixserverv1.vbox.ova.
So I will now open that appliance--
import that appliance into my VirtualBox environment.
And as you can see on here, we've
got various settings that are preset.
You'll need to re-initialize the MAC address of your card
if you're connecting it to a network interface.
However, it does work in host-only networking.
But your mileage may vary under some laptop configurations,
so you might need to experiment with the network adapter
if you encounter problems like not getting an IP address.
And this is sometimes to do with virtualization and old Unixes
when handling network interface cards.
That sometimes causes a slight issue on this lab.
But it generally can be run with host-only networking.
So we're going to import this here,
and you can see it will suddenly speed up.
We've now got a rapider acceleration,
and the module should be imported.
We'll re-initialize the MAC address.
And what we're going to do is then double-check
the settings of this and change some of the options,
just in case you don't have USB extension packs.
There's an extension pack for VirtualBox
which enables USB 2.0 and 3.0 interfaces.
But if you don't have that installed,
you might get errors on this or other appliances.
So checking that you've got Enable USB Controller
1.1 specified, checking the network--
I specify my network to host-only adapter.
make sure that it's not set to Bridged.
Make sure your network adapter settings are correct.
Make sure your USB settings are correct if you're
getting any kind of errors, and then press Start.
And you should then be presented with a splash screen,
and it should then hopefully boot up this environment.
I'm going to go back to my Kali instance here--
make sure that I've got my Kali instance configured correctly.
And we can see here we've got 192.168.56.104.
I'm just going to clear these terminals
from our previous module so that we have a nice, blank terminal
to work with.
So when this machine boots up, what you'll see
is that you will also have a desktop environment.
And I want you to refrain from clicking inside
of that desktop environment.
I want you to refrain from just trying
to make use of the desktop, because we haven't disabled
the keyboard and mouse, as we wanted
you to be able to make use of this machine
after the end of the course, if you
wanted to research it further.
But we're going to show you how to breach
this system from a network.
And you can see that it's got the IP address 192.168.56.4,
So if I was to ping 192.56.4, you
can see that that host responds to my CMP packets.
So I'm now going to do a very basic port
scan against this host, and I'm going to do it at 192.168.56.4,
and I'm going to output this is just
a normal text file called Unix.
And I'm actually going to enable verbosity and disable DNS.
So I'm just doing a very generic scan,
and here we can see a number of ports that are coming
back because open on this host.
I've also told it I want to do a full port scan, minus p minus.
I haven't changed the options or connect scan,
but I am going to try and slow it down to t minus 2,
because you can see that we saw this increased send delay.
And obviously, this scan now would
take a significantly longer amount of time,
because it's doing a very slow scan against that host
for the full port listing.
And the problem with scanning old legacy equipment--
if you can't start going in there with the minus
A aggressive mode, all those default scripts,
you might trigger some crashes.
You might crash a few of these services.
You might make that host unresponsive.
So I would recommend, when you're
dealing with equipment which is older in nature,
or perhaps not running the latest,
it might not be able to handle things like gigabits
of Ethernet speed.
It might not be used to having such a heavy load placed
on it on its network interface, so you
might want to exercise some caution, slowing down
your scans.
Making sure that you don't do things
too aggressively, so that you can
get a very comprehensive scan listening back.
So I'm just going to leave it running
as the default with the common ports,
just so I can get a common list of ports back.
And we can see indeed, there are some very common ports
that we've seen.
We've got Telnet, FTP, SSH, et cetera.
So I'll telnet to that server on FTP.
And we can see there it says FTP server, so I'll try user FTP,
pass FTP.
Says I can't access with that user.
Pass FTP, user FTP, pass FTP.
Didn't work.
Stats-- couldn't log in.
Help gets me some more commands.
Can't do anything with this.
We can get some information like their hostname.
We can try to log into it, but it doesn't really
give us too much of any use.
If we go back to our port scans now,
we can actually see that the port scan results--
we found a number of additional services,
but we haven't run any of those default Nmap scripts,
so we'll actually have to do this stuff by hand.
So we could connect to that Nmap service,
we could [INAUDIBLE] grab.
And we can see here that this says it's a Sun SSH
1.1, running SSH 2.0.
Fun little fact is that there's currently
believed to be a zero day exploit circulating
in the wild, or was at some point circulating in the wild,
for this particular service, that has a current recommended
retail price, or had a recommended retail price,
of around $50,000 US.
So it is known that there is a vulnerability in this service,
which is being exploited in the wild
by adversaries, for which no current patch
or additional information is presently known.
So if you see this service, it may well
have that vulnerability.
It may well be flagging, with flagging up,
as it was certainly found in some of the gamma
group and hacking team leaks.
So this Sun SSH service, we can probe now
and see whether or not there are any misconfigurations in it.
And one of the ways we could do that
is by simply just trying to log into the service,
enabling a little bit of verbosity.
We could do something like that--
VV.
We can see the debugging information now-- it
will actually show us what kind of authentication mechanisms
are supported.
It's asking for a passphrase.
I'll just not give it the right password.
And we can see here now, it'll try
to log in with a private key.
So it supports private key authentication.
But the next thing it's asking for is keyboard interactive.
So again, we could actually try brute force attacks
against that SSH service.
But I'm going to look at the next one there.
You can see also the Telnet service.
And scrolling out through these various debug
options will tell us what's supported--
things were done on the SSH server, what kind
of key negotiation was set, or ciphers we used, et cetera.
So you can look for known and weak ciphers and things
in there, as well.
So connecting to this, we can see that there's
a Telnet service, as well.
And when it comes to Telnet, Sun Microsystems,
they kept screwing this up.
So if I tried to connect to that service
by Telnet into it, Tellnet that IP address, you can see.
I got a log in prompt.
I could try common Unix user names and passwords.
I was going to try binbin for instance.
Binbin.
And actually, you can see that we could also
try to do some password guessing attacks against this, as well.
So I'm now going to show you a Solaris vulnerability.
It was known as fruit, but it is in fact incorrectly labeled.
It should have been Ben but if you
were to type Telnet minus L, and then supply the username bin,
it will instead just prompt you for a password.
So you can actually supply an argument or a username
to the remote program that you're
going to try and log into.
Now due to a command injection vulnerability,
it was possible to supply additional arguments
to the Telnet service through bin login.
So we can actually inject some command arguments in here,
and one of the arguments we can add
just before the username was the minus F argument, which
says force login of this user, if the binary is called
by root.
And if it's called by root from the Telnet service,
then it would allow us to bypass authentication and log
in as this user on the system with no password.
So we can actually bypass the system's security,
and actually Telnet into that service,
and bypass it by default. And if you
were to do a search point by full Solaris,
you'll find that there'd been a number of Telnet and Telnet
related vulnerabilities that you can explore
on different Solaris systems.
So you can see that there's one for 2.67 and 8.0.
So when you see Solaris Telnet, it's worth
having a look to see, are there any weaknesses in there
can you bypass authentication?
Does it have the F root?
And you might say, well, why don't you
just log in as the root user then, which
is the minus F root.
And in fact, out of the box, Solaris
doesn't allow you to log in as the root user on anything other
than the system console.
So if you're trying to bypass authentication as the F root
user, giving it the "fruit" nickname
for this vulnerability, then you would actually
find that it will fail and tell you
that it can't log in, because you're not
on the system console.
So out of the box, unless that has
been disabled by the administrator,
the exploit won't give you root permissions.
You can only log in as any other user in the system.
So we would try some of the default users like bin.
And from there we could then begin
to explore the rest of the system.
But I want to go back to these ports outputs for the moment.
Having looked at the Telnet vulnerability,
we've now got access to that server,
and we can interact with that system
and begin to explore for vulnerabilities.
And if I was now simply open my Unix.txt file,
we can see that the next set of options
that we have about an SMTP service, and also
a finger service.
So if I was to Telnet to that host on SMTP on port 25,
and I could begin doing my mail server attacks again,
we can see that this service tells us
the version of send mail in use.
We can have a look to see if there
are any known vulnerabilities in that version of send mail.
If I was to type H-E-L-O Matthew, for instance,
just give it a name to the server,
I can actually now begin trying to enumerate users through
the SMTP service.
And we can see here that this expansion
has an actual valid user name enumeration attack.
We can actually expand the root user
and see that it would be this email address,
root out Unix server, so we know that the user
root is a valid user, and we know
that fake is not a real user.
So we could also do verification root and verification fake,
and it tells us that not user is not known,
and that user is valid.
So we have a user name enumeration weakness
that we could use to identify whether there
are users on that system.
And in fact, we can see that there
is a helpdesk user as well by simply typing verify helpdesk.
Likewise we can also test this mail server
to see whether or not we can send spam related email,
and see if we can send emails to arbitrary domains.
And we can see here that the relaying option is not
permitted so we can't send open relay through that mail
service.
And the remaining service that we saw on there
was a finger service.
And if we connect to a finger service,
simply supplying an empty line will tell us users logged in.
And we can actually see that the helpdesk user and bin
user are currently logged onto the system.
So we've got some information leaks from the finger service
there.
But I'll show you something else you can do with finger.
If you netcat to that service, on port 79, and then
you were to type apps.
You do routes apps, and then the IP address of a finger service,
you can actually get that finger service
to connect to a remote finger service.
So you can use finger to tunnel to other finger services,
and get that finger service to look up users.
And this can have an implication if you can finger users
internally, if they have a finger service running
somewhere.
But finger services, it's kind of going a little bit
like the dinosaur.
It's a little bit like Yellow Pages in this,
kind of non-existent technologies that sometimes you
see but sometimes you don't.
So worth knowing.
Whenever I see a thing or service,
I often connect to it and try things like 0123456789,
like this.
And then also try things like 123, very special characters.
Try and see if I can get this finger
service to leak information.
Because sometimes supplying strings like ABCDEFGHIJ,
things like this, can often cause responses
to come back due to a kind of mis-formatted GECOS
field entries.
And there are a number of information leaks or command
injections which can sometimes occur in fingers services.
And indeed if you tried the finger service of one
of our previous modules, and you flooded it
with lots of connections, you'd find actually it's
vulnerable to an unknown vulnerability, which
causes the service to crash and become unresponsive.
So you can experiment with things like that.
So we're looking at this service here.
We've got the finger service, we've
got the general Unix services.
We found an authentication, a command injection attack,
by doing things like search searchsploit.
If you had a look around for Solaris vulnerabilities,
and you did Solaris fruit, F root maybe.
You find the Solaris, or Sonos perhaps, just search like that.
You might find that in there, you'd find that remote
authentication bypass for 5.10.
And if you were to look at your and NMAP output
and you did some more fingerprinting,
you would maybe find the version of Solaris in there.
In this instance, we were able to successfully bypass
authentication so we know it's a 10 system.
However when you're doing these port scans,
remember that if you are very aggressive,
you might find that you crash some of these systems
and services, so you want to be careful with that.
So we've got a localized shell on this account.
We've got some perspective.
So I'm going back to my port scan output here.
And we can see we've got information leaks in the FTP
service, SSH service.
We've got an authentication bypass in Telnet.
There's SMTP, some Some finger services.
We've got some username enumeration attacks there,
so we could try password guessing, then
two attacks with Hydra.
We've also got some RPC services,
and some RShell services.
So let's ignore the RPC services for the moment,
because we'll do that in a second,
but let's just look at some of these other services.
So we've got this login, or R services, or RShell services
that we can see here.
So when we see these kinds of RShell services,
you might find that you need to use a tool like ASHA,
and in fact these tools have been replaced now by the more
see the more secure Secure Shell.
So they actually-- you need to find some legacy
packages to install, to interact with these services.
But if you actually go to static.hacker.house/stuff
and download a tool called RShellExploit.c this
as a little exploit tool I wrote a while ago.
It allows me to leverage vulnerabilities
in RShell services that are missing access control lists.
So if you were to just simply compile that file,
you can see here that RShell.x minus O,
we'll compile that file to RShell exploit.
And then if we run that exploit file, what you'll see
is it will allow you to supply a host, a username,
and the command you want to run.
So if I supply the host as 192.156.56.3 and then
I specify the username as root, and I'll
specify the command of ID.
And we try to connect to that RShell service,
using the username of root.
And we type the command ID, and we've
seen we've got no response back.
If I was to change that user to helpdesk ID.
Oh, we got no response back because I'm connecting
to the wrong IP address.
So if I was to do .4, you can see you get permission denied.
You're not able to connect as the root user.
But what we could do is use that username enumeration
vulnerability to try all the other uses that we
might find on that system.
And then we'll try it with the helpdesk user.
And if I try helpdesk, you can see
that actually that command is run on that remote computer,
and it's given us the output of the command.
If I do LS minus AL, you can actually see.
We're in the remote computer, and we can actually
browse files and execute commands as that user.
And the reason for that is if I cat the .rhosts file,
inside the rhosts file of that user,
you can see that they've added two wild cards.
This permits any user from any computer
to make use of the RShell settings of that specific user.
So when a user supplied their own rhosts file, and the access
control lists are not specified correctly,
you can misuse these RShell services
as an implicit trust from one machine to another.
And indeed you could try to spoof the valid machines
if you're able to do some TTP IP spoofing, et cetera,
and try to manipulate that RShell service.
But that RShell X will simply misuse the service
and run commands for you, providing it has an R host
sensory set incorrectly.
So you do LS minus IL, PWD, et cetera.
So that's R login, and RShell services.
Some of the ways that you can probe there, using
the tools that we already saw.
I'm just going back to my unix.txt file,
and I'm not in my own directory.
So here we can see, OK.
So we've got some RShells.
So we've got some RPC services.
There's also R login, as well.
We could try and use a binary like R login, which again
has been replaced by SSAH.
But you could try to log in as those remote systems,
and see whether or not you could interact with those services.
And if they have the AHO set incorrectly,
you should be able to get in with our password.
So looking now, we've got the rpcbind info.
So we're looking again at the network perspective
side of this system, and we'll do RPC info minus P,
supply that remote IP address to query the RPC port information.
RPC [INAUDIBLE] minus P, and then supply that IP address.
And what we can see here is it's connected to that port mapper
service, and we can see all of these different RPC programs.
So now, we're gonna do a little bit more
with RPC and RPC related vulnerabilities.
So you can see, if we look at this RPC info service,
we can see that we've got this program number.
Program number relates to the application
that we're targeting or that we're looking at.
And we then have this version information.
The version information says which version of the RPC
protocol we're going to use, and we've got TCP and UDP.
And then the actual corresponding
TCP and UDP port numbers.
So if you were to connect to TCP port 111
and send the right APIs, send the right procedures,
for this program number, program number 1,000,
using either 2, 3, or 4 of the protocol,
you would be able to get responses back
from the port mapper service.
And so you'd be able to get this list of ports, for instance.
But there are other services and other applications on here.
There is status.
There's some others, 1010113, that don't even actually list
what they're called, because these program numbers have not
been mapped back to any RPC services.
Some of these RPC services themselves
have vulnerabilities, and you might
need to look up those program numbers
to figure out which programs are actually running on this host.
Now right down here at the bottom
is a suspicious looking RPC service called ypupdated.
This is an old legacy service for yellow pages,
and has been prone to a number of different kinds of attacks.
So I would do maybe a searchspolit
and have a look for Solaris RPC.
And we can see that there's a number
of RPC related vulnerabilities.
Stacked DTTDB, and various others those.
And one of them in particular stands out
as ypupdated, remote code execution.
So we can have a look at that, and actually
have a read through what somebody has written
about how that attack works.
So do cats/user [INAUDIBLE] exploitDB.
Platforms.
And paste in that file.
Have a read through, and see what information you get.
You can see that there's an tar file that you
can download for an exploit.
And instead what we're going to do
is we'll have a look at the Metasploit split one.
So I'm going to go into my Metasploit module.
I'm still in my Solaris host here.
I'm going to run Metasploit.
If I was to do a search, ypupdated,
we can see we've got a Solaris exploit there
that goes as far back as 1994.
So this is a very old, a very well known, kind
of vulnerability that happened around--
if you use nested yellow pages or some other things,
you could misconfigure this RPC service.
And it says here that the exploit
targets a weakness in the way ypupdated
uses a command shell when reading the map update request.
So you can actually launch extra commands through this map
updates by simply supplying a pipe command,
and it will inject into Solaris 7, 8, 9,
and 10, when ypupdated is started with the minus I
command lie option.
So in a certain configuration, this particular RPC service
from 7 through to 10 can have a command injection vulnerability
in it.
So simply specifying the remote host
will specify for show options.
We can see we've got the UID to emulate.
It doesn't matter from that by default. It's using 0,
because it's using non-ephemeral ports.
If you use non-ephermeral ports on your machine--
or use the ephemeral port, sorry--
then the numbers from 0 to 1024.
If you're using those numbers in that port range,
it will believe that you are the root user.
It will believe you are a trusted user on your system.
So you may find that if you're not
using those ports, that some RPC services will downgrade
your permissions because you used the wrong source port.
Very strange behavior, but it's true.
So show options.
If we were to do show options, set show targets maybe,
you can see that the targets are set to automatic,
and I'll do show payloads to now select
my payload that I'm going to send with this RPC exploit.
So I'm going to try set payload.cmd/unix/reverse_perl,
in the hopes that this Solaris system has Perl installed.
Again you might find that it doesn't when
you try to run this exploit.
So we'll try it now.
Show options.
I didn't set my LHOST I didn't set my LPORT.
We're on an internal network perspective now.
So perhaps firewalling between me and this host
is not so much of a significant issue, and some [INAUDIBLE]
perhaps that maybe outbound network monitoring
isn't much of a concern.
So I'm just going to set any kind of port
that I really want, just to test this one out.
And if I run that exploit now, you
can see that it's connected to the RPC service.
It sends a map update request, and inside of that map update
request it contains a Perl one liner that gives us
a remote shell on that remote server,
and it's indeed running with root privileges.
So we are again once again on that remote system
and we're able to execute commands as the root user.
So again you'd need to set up a teletype interface and job
control if you are to start using
that system more correctly.
And again you could see that we have on here RPC services.
Very interesting.
But I want to show you another attack.
So instead of looking at RPC info services directly,
if we run .strokeRI and I'll try to run this RPC info tool
against this host, and see if we get any different kind
of responses back.
And again we're getting the same kind of error.
It seems to error out on this one.
RCI options, grab all, create [INAUDIBLE],, send debug to.
Grab all available, minus 3.
I'm not sure why that's given me a segmentation fault.
But it sometimes does things like connect in and query
the calendar manager, if the calendar manager is available.
It may well be that I've disrupted some of the RPC
operations just by doing these port scans and probes,
and made that unresponsive.
So your mileage may vary.
Other tools we'd obviously look for,
we could do that same hping command that we ran earlier.
And I will just grab that from here.
And we can see that we've got that hping 3.
If we were to just simply use one of those ports again,
we could test to see whether there's any UDP
ports on the system, as well.
So don't forget to do the UDP scans.
I'm just going to kill that because they're going
to get the wrong IP address.
Change the IP address.
And we can see now, same kind of thing.
We're getting ICMP port unreachable, port unreachable.
But it appears that the host has 161 or SNMP available.
So again, 161.
We could try and use some brute force,
try and give it some community strings,
supply the IP address of that host,
and see what information we can learn from the SNMP service.
And again we've got a public SNMP community string,
so I would then do SNMP walk, minus C public, minus V1,
test the community string out, see what information I could
get from that Solaris system.
And as you can see now, I'm getting much more information
back.
And if I was to try ewalk, for instance, I
could say given the current process
listing of that remote system, and then give it minus P.
And we could actually see whether it would
try to enumerate off that host.
Oh, and it should be public, like that.
It says there's 84 processes currently running
on that system.
So if I supply ewalk minus P like that,
you can see I can query how many processes
are running on that system.
So you've got a few other little bits of interest
that you might be able to do.
So if I do minus A, this will print the entirety
of that Solaris MIB entry table, and anything
that I might be able to change.
But I can read it, as I'm the public user.
But we can dump out a lot more information
than perhaps getting with just SNMP will.
And indeed some of that will cause errors.
And indeed this can cause SNMP DX directly
to crash on some systems, because I
believe it's a touch for another utility and tool.
So what we've got in here is--
now going back to various outputs.
We have our Unix sample here.
So we've got RPC services.
So when we looked at our RPC info,
we're now going to target RPC services in general.
So these ports, we'd look at each of these ports,
look at these applications.
Are there any vulnerabilities in it?
What versions are running?
Can we probe them?
Can we use some clients?
Can we use RPC client, can we use some tools on there
to interact with things?
This is a Windows one, sorry.
You'd have to import and write some CTools and stuff
to interact with these RPC services.
But once such exploit you could maybe download,
go down to static.hacker.house/ebb.tjz.
So this particular exploit was used by the National Security
Agency to hack into Greece Telecom's Solaris
systems and then spy on their prime minister.
So here we've abnew Linux abshaved.V4, abshaved.V5, which
contains a number of attack tools, which
is just the same exploit, but in two different versions.
And if we were to run abshave version 5.
Now we've done some reverse engineering on these binaries,
and they appear to be fairly benign
and do just as they say on the box.
They exploit these particular vulnerabilities,
and they do so in a very safe--
and well very forensically aware--
kind of behavior.
And I'll show you first what's known as a kind of needle shot.
It's a one shot exploit, meaning it sends a set of parameters
that if they work first time, because you have set
them ranked exactly the right program numbers and exactly
the right material, you will get a magic hit one time.
So what you'll need to do is you need to specify path=
because you see it needs "add new Linux wrapper" in its path.
So I need to do path=$path:./ I want it to be able to run this
add new Linux binary from its current working directory.
And if I use abshave.version5, and then I'll do minus O,
minus O is the option.
So I want to target which system I want to target.
And what I found is that actually the similarities
on Intel for 9.0 and 8.0, and similar,
they all tend to have the same kind of stack addresses
and same kind of memory layout, so you can in fact use
a 9.0 target against the 10.0.
So we're going to try and target maybe 100230, which
is program number for meta MHD.
And if I was to do rpcinfo info against that host, rpcinfo,
I'll exit out of this shelf.
And now rpcinfo minus P. Probe that Unix server.
rpcinfo minus P. We can then see we've got port mapper, status,
and lock manager, and we should see in here somewhere,
is there a program number?
100230.
And there we see it.
We can see that 100230 is running as--
it only supports protocol version 1.
It's running on TCP port 32775.
So if we're going to try this exploit out
against that service, we are going
to need to make sure that we get the right program
numbers for the right memory layout to exploit that bug.
And so we can see here for options,
we can supply minus 01.
So it's important to remember path minus 01.
The next phase in our options where we would set
would be minus V. Minus v is the program version number,
so that's the number 1 as well, because we're trying
to support RPC version 1.
We're now going to try and do minus C, to supply a target.
We're going to supply the target, which
is the IP address of the remote Solaris system,
and we're also going to supply a port number.
And our port number is 32775.
Now this exploit we'll do a one shot exploit,
and it will basically try to exploit that service
with that exact memory layout.
And if you send that, it will show you
the exploit buffer that's being sent,
which includes pointers and memory
addresses for the corruption [INAUDIBLE]
occur, to basically jump to memory.
And it actually fails on this one.
You can see it sent this XDR request, and it's failed.
We haven't got a connection.
We haven't we haven't been able to go any further with that.
If you were to try it with abshave shave version 4.
You can see here now that this one is a different version.
This one will brute force.
If it doesn't know the exact memory address,
and it can't get that single shot needle shot to work--
that one shot exploit to work--
it can try to guess it.
It can try to work out roughly what the memory is,
and it'll try to exploit it over,
and over, and over and again, and it'll guess it.
And this is where this tool is very interesting
because it contains anti-forensics technology.
It's designed to hide the way in which the exploit runs.
So in fact, if you ran this exploit in the wild
and it failed, and you tried to hack a box and it failed,
the exploit itself can go onto the system
and overwrite the memory of the core dump
to scramble it, to prevent somebody else
finding that vulnerability.
So this was obviously a very closely guarded secret
that it was in fact used in such a long period of time.
For over 10 years this vulnerability
has been kept a secret, and perhaps even longer.
And it could be used to effectively--
as a skeleton key to access any RPC service
because it exploits the XDR.
So it doesn't need a specific RPC service.
It can work against any.
So any single one of those RPC services,
depending on their version, and protocol, and use,
can of course be impacted by this attack.
So a very critical vulnerability.
So if we were to run this attack now like this,
we've got abshave version 4.
And you see we've got different options that we need to set,
the first one being exploited options that are set here.
So I can do minus T to specify my target.
And you see these targets here list different common targets.
And if you look, you'll notice that Intel targets, the 2.9,
and also Intel targets for 2.8, have the same memory star
and end address.
It does change for 2.7.
So in fact, what you can do is you can use an 8 or a 9 target
to exploit a 10 host, because it also
has a similar memory layout.
So what I would do is I'll do minus T.
And I'm going to supply 2.9.
I'll give it a target for Intel.
Remember we're targeting an Intel architecture.
You might find if you come across a spark,
you need to actually select the right kind of architecture,
and you need to do that from fingerprinting
with tools, like Nmap and others,
to make sure you have the right architecture.
Or maybe get an information disclosure
from some other area of the tool--
SNMP maybe would give you information like that.
So we've got there [INAUDIBLE] version 4 at minus T2.
So I supply my target 2, minus N.
The next option, minus N, specifies the port number.
So remember we've got to get this information from rpcinfo.
So if I simply type rpcinfo, I want the port number
of the service I'm going to exploit.
Well for me, that is 100230.
I'm going to exploit the meta MHD service.
So let's grab that service.
100230.
That's probably one of the more reliable services to target.
And we can see here that the information for that
is port 32775, using TCP.
So we need to specify minus N, 32775.
I'm gonna run my exploit with this Solaris 2.9 target,
against this port number here.
And I'm also going to specify minus T for TTP,
or minus U for UDP.
So I'll specify T. I Want minus TCP.
And then I will give it the hostname 192.56.4, and then
the IP address, which is 100230, And the version
number of that protocol, which I'm trying to exploit,
which is 1.
Again this information is come from rpcinfo.
Once we've mapped information correctly,
simply hitting return will allow the exploit to run.
And it will pause for a second or two, connect to this system,
and exploit that vulnerability.
And every time it's coring, it's actually
leaving some remnants of the attack on the system,
and the exploit even had a way of overwriting that
with garbage data to make it look less like an attack,
to try and cover up its tracks.
So this is really was a tool designed for field use,
for operational espionage.
It wasn't really designed to highlight a vulnerability
like a security researcher would do.
This is much more weaponized, with a very robust set
of targets.
And indeed, when the attack actually succeeds,
I do believe it's using a fine SOP routine to reuse the RPC
service and cause a shell to spawn,
so you do in effect just end up with a shell in that same RPC
session that it tried to exploit in the first instance.
I believe that's how it's working.
So if you read through that, you should be able to see.
At the end of this, once it gets down to the end,
and gets the core on target, then eventually
will effectively give you a shell.
It can take a few moments to run through this.
The address is a little bit far off.
So I'm just going to look at another window for a moment
and see if there are other things that we can probe
while that attack is running.
So looking at our unix.txt file, we can see we've got login,
we've got shell.
We got some other kind of fairly useless [INAUDIBLE]
type management interfaces.
We've got on 898.
We can try and target those as well.
Some services on submission.
If you were to go to 192.168.56.4/898 you would be
presented with a web interface, a Solaris management console.
It's currently not enabled or running,
but you could try again your web server techniques on that.
You could try your Nikto outputs.
You could try your various other attacks.
And I'm just gonna hit [INAUDIBLE] background that.
So we've got a couple of other services on there.
And before we go down and explore all these--
so some of these are like font services, et cetera.
We could probe all those.
These RPC services we've already explored.
But the next thing we're going to explore
is this 6,000 port, or this X11 service.
We're gonna have a little probe through that.
I'm just going to leave this running now for a second
so we can see this attack actually functioning.
I do believe it's getting closer to the required
address for this to exploit.
You could, of course, just specify that specific address
or change the range to make it run a little quicker, as again,
this is a very--
almost a Holy Grail of exploit for Unix hackers.
This was indeed a very treasured and converted tool.
It is a fairly lengthy process to get to the right return
address.
I believe it's around 8047D-something,
so we're not too far away now.
It seems like it is going to be a few more minutes.
So what we'll do then is while that scan is continuing to run,
I'll perhaps get ready for the privilege escalation element
of this module, where we will try another attack that
also came from the NSA, which was that extreme par.
So if we were to Telnet to this server using minus L,
minus F, helpdesk this time.
I'll try to log in as the helpdesk user.
So I've now got a shell on there is the helpdesk user, using
our authentication bypass.
And what I want to do is I want to escalate
my privileges to root.
So some of the ways I could do that is
do file permissions, browse through different weaknesses
on the system, and see if there are any files of interest.
So the way I would do that is I would simply
want to find command.
And the types of files I'm going to be interested in minus 4,000
because I want to know files that are set with the set user
permission.
I want to know the ones that I've got the sticky user's
permission, if you remember that from our file server module.
So I want to search for--
find /-4000 not minus type L, 2 pipe /dev/null.
And then I'm going to pipe that into a file called setu.txt.
If you cat setu.txt, find/-4000, not minus type L,
2 stroke dev/null.
Find/-4000 not minus type L.
Find/-perm-4000 not minus type L.
I'd missed an argument off there,
which is why we got that error at the beginning.
And if I just pipe that now into setu.txt,
what that find command will do is it will list every system
on the--
every binary on the system--
that runs with elevated privileges,
runs with roots or similar, or sticky permission.
I'll do minus 2000 because I want
to know all the ones that run with a group permission,
as well.
So I'd have a look at setgid.txt.
I want to find all the files and binaries that
might run with elevated permissions in setgid, as well.
I also want to have a look at any files I can write to,
if I'm any user on the system.
I want to see world writeable files,
and then I'll put those into a file called worldwrite.txt.
And I've now got a collection of files that have the sticky bits
set, the sticky group it set, and the world writable
flag set, which could be security-related issues.
And if I was to have a look at world write for instance,
having a look through what are some of the things
I can maybe write to, I could scroll through
and see there's a number of uninteresting things.
And there's one that called etc/hackerhouse/rootrun.sh,
which looks pretty interesting, and I'd definitely have a look
at that.
And another thing that we've got there
is a world writable crontab for the root user.
So if I was to go to var/spool/cdcron,
and then go into the crontabs directory,
you can see here that I've got those roots crontab
entry, which I can actually edit and manipulate files on.
However, if I tried to edit this file
directly I have to force the cron service to reload it.
So I need another cron bug to cause
cron.d to refresh the localized crontabs,
or force the machine to reboot so that it retakes it in.
So it may not be able to leverage this one directly,
but it looks like, inside of the schedule task here,
we see that there's a command that
runs every minute on this system, which
is etc/hackerhouse/rootrun.
If we were to go to etc/hackerhouse/routerun, LS
minus AL rootrun.sh, you can actually list through here
and see that we've got a world writable file
that anyone on the system can add commands to.
And if we look in that file, we can
see that this has been added by an intern.
This is a very common kind of mistake
where an inexperienced system administrator has
left his permissions too wide, and he
has made a command injection vulnerability
in some kind of automated process.
So we can add arguments into this file,
and technically they should be run every minute
as the root user.
We could even change that route uses crontab, if we wanted.
But again, you'll need to get the system to reunderstand
that crontab or reload it.
It won't just automatically accept it from that file.
So you might have to try to refresh it somehow,
kill it or something.
So LS-AL/etc/passwd, we can see that that file--
if I tried to do cat/etc/shadow, I
can't actually access the shadow file on this system.
So what I want to do is I'm going
to echo chmod 777/etc/shadow into the file rootrun.sr.
And if you now look at the file rootrun.sr,
you'll see that my command has been added to the bottom.
If I type here date, and wait a minute or so,
and now look at the shadow file, you
can see at the moment it's only readable by the root user.
I don't have permissions to access it.
And if we wait for a minute to go by, our commands in that
file we'll run, and we should hopefully
be able to escalate our privileges.
So I'll go back to our output here,
and you can see that RPC timed out.
Hopefully we'll have a shell shortly.
And it is now connected to binstroke.sh.
And if you type ID you'll now see
that I am the root user on this host by exploiting extreme--
by exploiting abisland or abshave, using this.
If so, you nailed this RPC service,
with this return address, on 149 attempts.
And it then gave us a shell and very politely informed
me to have a lovely day, have a nice day.
Good manners are free, and I'm glad that people
give good manners still today.
So cat/etc/shadow, date.
And you can see here on this system.
The minute has gone by.
If we now look at the etcshadow file,
we can now read and write that file, as well.
So we can actually just get that root user's password.
You can copy this data off, and you
might want to copy some of these passwords
off for a later slide.
But we can then see, you know we've got various passwords
and things on there.
So that's an example of how to use abisland.
That's another example of common file permission problems--
dinosaurs making file permission problems--
leveraging file permissions for privilege escalation.
These kinds of things that--
bespoke vulnerabilities.
People make these mistakes.
They change file permissions.
It's worth looking through them.
Also the next thing we'll do is we'll
load the privilege escalation attack for extreme par.
If I was to download wget http://static.ha
cker.house/stuff/exp.tar.z, you'll find here we've got
a binary package for a precompiled static binary
for various--
for a directory traversal vulnerability,
which if you are curious about its innards and working,
you could do DT app, gather hacker fantastic.
You could actually find a little writeup of these attacks.
I actually went through a lot of these exploits
when they were released to try to figure out
what each one of them did, and reverse engineered some of them
to rewrite my own version.
So if you're interested in how the directory traversal
attack works., there's a little writeup of it there.
And actually this vulnerability was fascinating to me,
because it was a vulnerability that was introduced in 1997.
And the way that the vulnerability works
is there was a directory traversal
vulnerability in common desktop environments, dtappgather.
So if we go to this host, and we type whichdtapgather,
or maybe do--
are we on the wrong host, perhaps?
I just need to come back into that as the helpdesk user.
I believe that's who I was already.
I was pretty sure that--
yes, we did.
greapdtapgather, perhaps, dot star.txt.
So you can see here, this user/dt/bin/dtappgather is
installed in the system.
It has root set permissions.
If we look at the file, we can see that dtappgatgher exists
with set [INAUDIBLE] root permissions,
and I'm sort of annoyed at myself for missing this bug.
Because when you look through this vulnerability,
there was a vulnerability in 1997
that allowed you to write files with a directory traversal
vulnerability.
A fix was applied, and the information
shared with the bug track mailing list.
However somebody at the National Security Agency
noticed that the fix was inadequate.
It allowed you to traverse a single directory.
And even though it allowed you to break out
of just one directory, it was sufficient enough
to be able to break out of that directory and upload
a root owned file elsewhere into the system,
escalate your privileges to root,
and abuse some of the functionality of the operating
system to gain root.
And because of its very simplistic nature,
it was a very universal, very unrisky, very straightforward,
standard attack.
So the NSA produced a binary to exploit this vulnerability
that then they hardened with anti-reverse engineering
techniques, heuristics, and all kinds of things
to stop people trying to figure out what it did.
So of course we reverse engineered it,
and we found out what it did.
And then we were able to recreate that exploit.
However in my opinion, there's no point reinventing the wheel.
The exploit they've already written
has been engineered and probably cost them more money
than my time did, so I just use that.
So we've nicked that tool, and we can use over here.
What we'll do is we'll upload that to the server.
And then we'll supply an FTP.
FTP and then we'll upload the exploit.
Oh I'm sorry.
I'm going to log in as the helpdesk user.
And I'm just going to use the FTP
service to upload that binary.
That compressed the archive to the system.
And if I'm now on as the helpdesk user,
we can see that I have that helpdesk, that binary
in this system, and I'm going to do
gzip minus D, unzip that file.
And then tar minus xvf exploit .tar.
And unpack that file.
And in this directory, now, we'll
see we've got lots of different binary files.
And the way that this exploit works here
is giving us options.
It's got exploit.s.
If you're running on a Solaris system, you can run exploit.s,
and you'll see that this is compiled for Spark.
So you can actually use this on a Sonos-related related Spark
system.
Or you could run exploit.s if it's
running on an Intel system.
And if you look at una-a, we can see
we're running an Intel system.
So we're going to use exploit.x.
Likewise for exploit.x to work, we
need to set the right versions of these binaries, which
are going to be uploaded to the system
to give us a command shell.
So we're going to copy su.so.2.1011x.
And we're going to copy that file to su.so.2.
So if you were exploiting a 9 or an 8, or a similar system,
you would need to change these numbers accordingly.
And then what we're going to do is
we're going to trigger this exploit to automate
the exploitation process.
We want to make-- what it does is
it uses a directory traversal.
It uploads a system locale, and then it
uses the 80 or the crontab related scheduling service
to automatically run, and load in, that shared object,
and thus give you root permissions.
So if you set AT=1, it will automatically exploit that bit
for you.
If you then do dot/EXPLOIT.X you can now run this tool,
and it should load in and give you root permissions.
And if you now type ID, you can see
I've escalated my privileges to root,
and indeed there are a number of commands that are then
run on this system, as well.
These commands effectively will turn the computer
back to the original state that it was in its beginning.
There's a little IT tool there.
And what they do is, it's actually covering up
its trace forensically.
It's changing things like the inodes, timestamps,
and various others, and making the system
look like it was never hacked.
So again not the kind of thing you
see in a security researcher's toolbox.
Much more used in the field for malicious, illegal intrusions.
So what you've got there is ID, uid=root.
And you can see we've got these executed.
I've given myself root permissions
using extreme power.
So that's an example of abisland and extreme power,
two of the crown jewels from the NSA's Unix hacking arsenal.
So we were able to pick through those
and use those against this host, as well.
Likewise one of the things that we could do
is we could use Nmap now to prove that X11 service.
So if we were to have a look at Nmap scripts again,
if you were to go into Nmap and look in its scripts directory,
you'll find that there's a number of scripts
for X11, perhaps, as one in particular.
And if you just simply access that script,
you would see this script says, are you allowed
to connect to the X server?
Very basic, very simplistic thing.
So let's try it out.
Nmap-P6000--script=x11access.
Can I connect to that server?
What is my access to it?
And I'll do -N, disable my DNS, P, and disable my pings.
It's just VB.
Let's have a little look what's going on there.
And you can see here it's connected to that X11 service,
and it says X server access is granted.
So it doesn't look like there's enough permissions on that host
to prevent me from interacting with that service.
You might find, as well, not to forget looking through things
like our reference guides.
You'll find some useful, helpful cheat sheets
for some of these modules.
And in particular for the X11 stuff,
you might find that you'll need to app get a couple of packages
for things like NFS and X11, if you
haven't noticed that already.
So you'll need to app get and the commands
are referenced on page eight, If you haven't got those set up.
And what we're going to do is, we can now
connect to the X11 service.
It says access 11 is granted.
So this port 6,000 actually is the display 0.
So if you were to do something like display=192.168.56.4:0,
that would then try to connect to that service on that port,
and run commands and tools.
So if I was to type xterm, for instance,
my tool would, should, load up on this terminal.
So I'm gonna log in and turn the screensaver off.
But you can see now that my program is actually
running on that computer.
And actually it's displayed it's the client as connected
to that remote computer, and it's running my program
on his computer instead.
Well that's not a really good thing.
I don't want to be running my program on somebody else's
computer.
I want to see what they can do.
So I will do XWD, which XWD allows
you to take a screenshot of the remote computer.
So what I would do is I'll take a screenshot
of the remote computer, see what services,
see what's going on it.
And we'll do 192.6.4:0.
I'll feed that into a file called screenshot.xwd.
And then I'm going to convert screenshot.xwd
to screenshot.jpeg.
And if I now load that screenshot.jpeg, what you'll
see is I can actually see the screen that
was on that remote desktop, so I can actually
interact with that remote desktop screen.
That's kind of useful, and there's some commands on there
as well to try and disable the screensaver.
But because it's a client server model, and the keyboards,
and the display, and everything else
are considered as clients, what we're going to do
is we're going to try and inject some keys.
So if I was the type display=--
Oh, first of all I'm going to type xwininfo.
I want to send some keys into that remote computer,
but I want to send the keys to the right application.
So I'm going to do xwininfo-tree-display.
I want to list all of the applications and things
that I'm running on that X window display.
And I'll set my display, as is unable to display power's name.
And I've changed that to a colon and a zero.
And remember it's important you to -tree,
and I need to add the argument -root, as well.
If you add that colon 0, if it was
port 6,001 that would be a one.
If it was to about 6,002 it'd be a 2.
6,003 it'd be a 3, 4, et cetera.
And 0 is for 6,000.
So when you run this tool here, what
you can see is we get various handles,
we get various pointers, references, numbers,
that reference different applications,
and we can see all the applications
that run as clients inside that environment.
So the File Manager, the desktop, the terminal,
everything that's there is visible in this xwin info,
because we can connect to that X11 services.
And what I'm going to do now is I'm
going to inject my keystrokes into that remote computer
and send some commands there.
So I'm going to supply display=192.168.4:0.
I'm then going to supply xdotool.
I'm going to send the word key alt+tab.
I'm going to send alt and tab as a command.
I'm gonna send the keystroke IDKP_enter.
And what that's going to do is, it's
going to send the keystrokes alt and tab, ID, and return.
If you now look at that terminal,
you can see that I have pressed alt and tab,
I've got control of that terminal window,
and I've sent the command ID, and I
can see the output of the ID command in my screen there.
And if I wanted to do that and see the output myself,
I could just simply retake that screenshot.
OK, so that's kind of useful.
But another more interesting thing
is to simply set display 192.168.4:0, and type xspy.
And xspy opens up that client server model,
and instead intercepts all the keystrokes.
So any keystrokes typed on that computer
will now be visible to me as the attacker.
But I don't just want to see what
keys are being typed on it.
I also want to see more stuff.
So I'm going to come out of here now
and I'm also going to try and use
a tool which you'll need to download from our stuff
directory called xwatchwim.
If I wget static.hacker.ho use/stuff/xwatchwin.tar.gz,
and then unpack that file, you'll need to have some
dependencies installed.
But the way that this is installed is xmkmf,
and the dependencies are listed on our resource guide.
Type make.
It then results with an xwatchwin argument,
and what I'll do is I'll supply the IP
address of the remote computer.
And for the window name, I will supply desktop.
Could not find the window as specified.
So your mileage mileage my vary with this.
So I'll try window name.
What else have we got?
And sometimes it causes the system to be unresponsive
or to crash.
I'll just try a desktop, lowercase.
Could not find the window you specified.
xwininfo.
It's definitely there.
I just can't seem to connect to it.
It may well be because I've caused the service to crash,
or maybe because I've got other things running like xfi.
Let me just see if that's it.
[INAUDIBLE]
So you may find that if you just simply run desktop,
you would then get a visible desktop screen.
But your mileage does vary on this application,
on these attacks, as sometimes the service gets into a state
where it cannot connect to the D root display for some reason.
If I was to reconnect with there again.
Root display.
It says it has no name.
It's got File Manager, it's got desktop.
It's got desktop window.
Nautilus maybe.
Just see if I can.
Nautilus.
Could not find the window specified.
It definitely says desktop window has no name.
Window ID 0X180001C.
Could not find the window specified.
045.
Could not find the window specified.
What about we'll just try [INAUDIBLE] and terminal,
which is not [INAUDIBLE].
So I'm going to just reboot this appliance now, just
to see if rebooting it will allow me to reconnect.
And I'm going to show you how to shut down this correctly.
Remember if you just turn off a Unix system,
it's a good way to make a dinosaur roar.
So make sure you shut down cleanly.
Otherwise if you do just pull this appliance out and restart
it, you will find that you need to reapply it, or re-import
it due to corruption of the disk,
and that's how dinosaurs roar.
So if you want to experiment with making a dinosaur roar,
simply turn this off without cleanly shutting it down,
and you will experience that same behavior.
What I to show you now is just being
able to monitor the desktop, monitor that user's
environment, and also observe their keystrokes
as they type in.
And the way you see this being used in the wild
is often remote management of hosts in a data center,
or perhaps are accessible from some remote access, basically
people who have tried to install a server heedlessly, and maybe
make it accessible for management
purposes from a management LAN.
And instead of using something like terminal services
or a multi-factor authentication solution,
they've simply enabled X11 windows,
and I'll show you how you can check the access control, as
well.
So the box is rebooted now.
Let's just see if that resolves our issue.
And you can see now that it's connected to the desktop,
and we've got xwatchwin running.
And xwatchwin will give us a kind
of real time stream of the desktop
so we can see there what's going on in the desktop.
And the other thing I'll do is I'll do display, give it
the IP address of server.
Run zero.
I'll do xspy on that host.
And what's happened now is, any keystrokes that
have been typed since that screen
will also come up on my computer.
So if I type here ID, LS-AL, SU, password.
If you now look at that computer in the background,
you can see that I can see what that user is doing.
I can see the commands that they're typing.
So I could also of course capture any passwords
that that system administrator might use.
And you can do things like monitor their web browsing
habits, monitor their use.
In fact if you was going to [INAUDIBLE],,
you'd probably be able to find dozens of these systems
out there, exposed in this kind of way.
So that's that kind of problem that you sometimes see.
And if you were to simply go to that computer and type xhost,
and I'll type it into here.
Typing xhost will show the access control is disabled,
and clients can connect from any host,
and simply type xhost- says access control is now enabled
and only authorized clients can connect.
So the problem with this was, somebody had disabled access
control on the desktop, and it allows anyone
to connect from any hosts.
In fact your callee instance will work the same way,
except that it just has these access controls disabled,
and it has no networking enabled, and things like that.
So it's just more secured version.
But X11 can be misconfigured and configured in an insecure way.
And I believe that that brings us
to the conclusion of this module.
So we've looked at various network-based threats
and network-based attacks to Unix estates.
We've demonstrated a number of privilege escalations,
common Unix file permissions, insecure file past, dinosaur
mistakes, and also we've seen local privilege escalation
attacks, and how to do things like exploit network services
and abuse, misuse X11 services.
So that concludes the Unix practical for this element
of the course.
What I want you to do is I want you to repeat those steps.
I want you to re-breach that system.
I want you to understand how those attacks work,
and I want you to try and gain privileges
from any of the number of different exploits
that we've shown you here.
I want you to explore the RPC services,
and make sure you're comfortable with the idea of RPC running
different programs on different ports,
and how you can map those back and understand
whether there are vulnerabilities
inside of each one.
So thank you very much for watching,
a I look forward to seeing you in the next module.