[ELECTRONIC BEEPS AND SOUNDS]
[MUSIC PLAYING]
Welcome to the Hacker House hands-on hacking mail server
theory module.
We're now going to explore email and mail services in general.
So if you think about the vantage point
that we're taking at the moment we're the external attacker,
we're sitting outside of a target organization.
We know what we've learned from open source intelligence
queries from looking at a target's website.
We've looked at things like DNS queries,
learning information from DNS servers.
And part of that, we'll probably have learned some information
about the mail servers.
We may have learned MX records and where those servers are.
So we'll now run through email, email services,
and how to abuse them.
So most organizations will have these technologies
in use in there.
They will be using email.
They will most likely be using DNS for some things as well.
And they will also be using web and various others,
and we'll cover that in more in later modules.
But for the moment, we're focused on mail servers
and mail services.
[MUSIC PLAYING]
So mail services, defined in RFC 821 or the Simple Mail Transfer
Protocol, there are actually numerous amendments
and revisions of this RFC over the years
as email has evolved and grown into the veritable time
soul-sucking machine that it is.
It has numerous amendments that have
been developed and designed for enhancing it
for security purposes.
And these SMTP or Simple Mail Transfer Protocol
is the way in which email is actually delivered usually.
And these SMTP services usually exist in the MX records
for domains, and the MX records also
determine the priority for email services.
And what I mean by that is if you get two MX records,
the number with the lowest number gets the first priority.
So it will be the first email server
that the email is trying to be delivered to.
In the event that the email fails,
it may then try the second server.
So it's one of the most commonly used protocols on the internet,
and most people use the internet for sending and receiving email
at some point and it operates, most commonly,
over this TCP port 25.
But mail service ports can be found in all number
of different ports as well.
And as example, TCP 2525, 465, or 587
are all kind of widely used ports.
So you might find that the TCP port 25 isn't in use,
and instead, 456 is in use because it's using SSL.
But it's effectively the same service,
and you could test for the same vulnerabilities
against each port.
It wouldn't really matter where you found the service.
It could still be probed.
And the email transport layer, the actual email
can be encrypted with SSL itself,
and that can also be provided inside the socket
with something like a STARTTLS command.
So you could have a connection to a mail server
that's then upgraded effectively to SSL.
IMAP and POP3 provide remote mailbox services.
IMAP is a protocol for accessing your mailbox,
and POP3, a post office protocol, is a similar one.
And they run on ports 143, 110, 993, and 995
respectively or POP2 which is extremely legacy which
you may find on 109.
Now, these softwares are used for accessing mailboxes,
so it's kind of like for accessing your inbox.
And inside of there, they would have things
like welcoming banners as well.
So when you're targeting mail services,
you're looking at SMTP, IMAP, POP3, things like that.
You will often find that the welcoming banners will identify
exact software type and version information which it allows
us to profile our platform and profile
and identify vulnerabilities.
So it's a very useful way of gathering intel,
and this process of connecting to open ports
and grabbing those banners is known as banner grabbing.
What we need to think of now is the email chain.
And what that means is when you are at your computer,
and you type in an email, the first thing
you want to type your email into is what's
known as your mail user agent.
That's your email client.
And your email client could be something
like Outlook, Thunderbird.
It could just be a web browser, whatever
it is that you are actually using to send this email.
And that's known as the mail user agent.
The mail user agent will then send mail
through what's known as SMTP--
Send Message Transfer Protocol, and that
will get sent through a mail transfer agent.
That's usually the SMTP server, and that
could be running software like Sendmail or Exim.
And then you would have a mail delivery agent which is often
a more feature-rich mail software,
and that could be something like Exchange
or some other kind of citadel or some email server that
handles POP and IMAP.
And that mail delivery agent will then
allow that email to be read through POP or IMAP, Post
Office Protocol or IMAP, in the other mail user agent,
and then the other parties then would receive your email.
And that effectively is the email chain.
So from your typing in that email,
it's gone through your mail user agent,
it's gone through your mail transfer agent,
it's gone to a mail delivery agent,
back to a mail user agent, and then
it's displaying in somebody else's screen.
So that whole process, that chain,
each system in that chain can actually
leave a little mark on the email and tell you
the software type and version information that it might be
or might have.
So that's an example of the email chain.
And when you send an email to a company,
if you send an email into the company
and it is then returned via delivery status notification,
it fails.
So if you send, like, nonexistent@FBI.gov,
that email will bounce back from the server
because the email address is invalid or similar,
and you would find that along the chain,
every system in that chain has added a little stamp
along the way up to the mail delivery agent which
failed to deliver the email and then has passed it back to you.
So you can often find things like antivirus programs
this email was scanned by and other bits of information.
So email chain's a useful thing to check.
So when you're probing mail servers, what
you'll be looking for is a way to maybe misuse
that mail server.
So if you can send mail to the NSA
by looking at the MX record, whats
to stop you connecting to that mail server
and trying to deliver mail to Microsoft?
Well, that's basically what an open relay
is-- the idea of misusing a mail service to sending email.
And it's commonly used for sending, you know, spam
announcements, magic pills that will help you lose weight,
things like that.
So SMTP protocol can be used to send this kind of open relay
and also do this kind of user enumeration,
so enumerating different uses or email addresses which
might be present in the system.
And in fact, there are some commands built into SMTP,
part of the protocol such as EXPN and VRFY
and RCPT TO which can be used to identify
if a valid account is valid.
And it can help you expose, sometimes,
local accounts on the mail transfer agent
but also sometimes, as well, where the email addresses
are valid or not.
And if you can send it open relay, you would misuse it.
You could misuse it for spam--
things like that.
So that's why you need to check and identify these problems.
A DSN is a Delivery Status Notification report.
And these you can get from a company
just by sending to an invalid address,
and it will actually contain the IP addresses and information
simply by viewing the original email source.
And you can go ahead and try this now.
Just send an email to some company,
and just put boomerang@company.com,
and the email will return rejected.
And if you look at the headers, you
will actually see all of the delivery agents
and transfer agents and bits of IP information
that will be exposed in there.
So that's kind of useful, and you
can find antivirus and security software in there.
So remote mailboxes-- that is, you
know, accessing the mail delivery agent.
So logging into Exchange, if you go to webmail.company.com,
you might, then, be able to log in and access your inbox.
Or maybe you can load up your email client
and access your inbox that way.
So that's the idea of remote mailboxes using this Post
Office Protocol or IMAP.
And so Post Office Protocol services quite often
don't honor account lockout policies.
And 'cause it's kind of a bit of a legacy protocol, this Post
Office Protocol, it doesn't often
link in with some of the newer systems.
So it's maybe something that's just legacy there,
and it might not honor account lockout policy.
So usually, POP services are susceptible
to brute-force attacks.
The same is not true, conversely,
if IMAP services which will integrate with things
like Exchange, with Windows Active Directory which can
expose you to account lockouts.
So if you're trying to then brute-force
against IMAP services you might find yourself locking out
accounts because it's subject to the Windows Active
Directory or similar account lockout policies.
And again, web mail is widely used,
and it can also be susceptible to common web application
vulnerabilities, common weaknesses
in web servers, et cetera.
And also, SSL vulnerabilities-- vulnerabilities
that are relevant only to SSL services
can also apply to mail services when
they've been protected via SSL.
As an example is a vulnerability known as Heartbleed
which could be used on different SSL-protected services
and could actually leak back memory and information
from those servers and ascertain whether it contained
credentials or other sensitive data.
Sendmail vulnerabilities-- Sendmail is an old package
or is very, very commonly used package.
And in fact, it has a very long history,
has very myriad history.
But it's got a history of useful and very old vulnerabilities
as well.
You know, some of the more recent ones--
the remote signal handling bug, remote prescan code execution.
In fact, some of the vulnerabilities
even predate CVEs.
And we don't really look at any of these
because they're kind of a little bit too old now.
But just as an example, I wanted to dispel an InfoSec myth,
and that is the myth of the Sendmail wizard.
Sendmail had these back doors, or so it was rumored,
and one them, one of the famous ones
is actually this Sendmail wizard command which is pretty much
nonexistent today.
You would never see this.
But actually, I've looked through this bug
just because I was really curious as to how this worked.
And, in fact, it works very similar to how
Telnet worked back in the day.
And if you connected to a server--
here's an example of a connection to a server--
if you connected into it and typed
SHOW QUEUE, you would send the queue.
And then if you were to type KILL,
you weren't able to send the command KILL
because it says mere mortals mustn't matter-- that mantra.
And if you then type the command WIZ,
tell the system you were a wizard,
and give it the correct password, so wizard
and a password, it would then give you
the ability to kill the remote Sendmail server.
And some people speculated that you could also
run commands although I saw no evidence that you could.
And so wizard, you know, Sendmail
wizard, telling the Sendmail service you
are a wizard in the 1980s might have got you somewhere
but today, certainly not.
Exim is also widely used as an alternative to Sendmail.
Much like we had BIND being used for DNS
is Exim and Sendmail-- very common mail
transfer agent packages.
Exim is very widely used and has had numerous vulnerabilities
over the years.
So various remote format string heap overflows,
string_format heap overflow.
There's some privilege escalation attacks,
various escalation attacks, things like the GHOST libc()
exploits, various attacks against Exim over the years.
Likewise, to Exim, you might come
across things like PHP mail.
You might come across vulnerabilities
in the PHP mailer application.
In fact, one of them in particular--
CV-2016-10033 is less than 5 2.18--
you can actually use this command injection into mail
to execute commands.
And CV-2017-7692 allows you to use that same mailer
by basically getting command execution in SquirrelMail.
And this same vulnerability was also
found in kind of the WordPress host header.
So whenever you come across kind of email or contact
me forms, and it's using this PHP mail function,
it may be possible to add extra commands in when it's
trying to send an email, cause that system
to run extra commands, and we'll even
have a look at how that might manifest itself
under a different configuration to those reported here.
Likewise, again, when we discussed Heartbleed
earlier on, we were discussing an actual vulnerability
in the SSL library or open SSL implementation of SSL.
And the way that that vulnerability works
is when you created an SSL connection
to an SSL-protected service, you could send an SSL request,
what's known as a heartbeat.
And the heartbeat would contain a word-- let's say I said,
heartbeat hello--
and the server would say, OK, heartbeat hello.
And you would tell it the word hello is five characters,
and the server would respond and says,
here is the word hello as your heartbeat,
and its five characters long.
And the vulnerability came about in that you
could tell the server how long the word hello was.
So I would say, here is the word hello.
The word hello is 65,000 bytes long,
and the server would say, here is the word hello,
and begin to copy 65,000 bytes from memory.
Thus, it would leak information.
It would copy memory from everywhere on the system
that it wasn't intended to get, and it would
cause an information leak.
And you could actually use this Heartbleed attack
to leak information from a server to identifying
weaknesses and leak sensitive information and memory.
So that concludes the theoretical module
for this lab.
What we're going to do now is we're
going to need you to download the tools, the ISO.
Make sure you've got the mail server ISO and your resource
guides and other references, and then we
will basically approach the practical elements
of this module.
So thank you very much for watching,
and I look forward to seeing you in the next module.
[ELECTRONIC BEEPS AND SOUNDS]