Blog: Red Teaming

Email Relaying. A how-to and a reminder

Lee Parkes 05 Feb 2021

On a recent internal infrastructure test I came across a server that had port 25/TCP open. This is normally the Simple Mail Transfer Protocol (SMTP) service, and sure enough a quick look confirmed it.

Now, such services on an internal network are not unusual. System and network administrators sometimes don’t switch them off, especially if they are unaware that the service is running, due to the operating system vendor enabling it by default or some third-party application requiring it for some mystical reason. However, what did surprise me was Nessus reporting that email relaying was possible. “No way, dude!” I thought, in my best Bill and Ted voice. Time for some manual investigation…

Email Relaying is an old vulnerability (think Jurassic period…). It used to be the case that a Mail Transfer Agent (MTA) such as Sendmail or Exim would let you connect to the listening port (25/TCP) and send email raw to and from anyone without checking the source and destination email addresses.

Nowadays, it’s a rare find with most MTA’s having relaying disabled by default. That said, anyone that installs an operating system or any other software should always check to see if any other packages or services are added.

The following shows the steps required to connect to the service, create an email, and send it on its merry way:

1: telnet 10.0.0.1 25
2: Trying 10.0.0.1...
3: Connected to 10.0.0.1.
4: Escape character is '^]'.
5: 220 mailserver.nosuchdomain.com ESMTP
6: HELO
7: 250 mailserver.nosuchdomain.com
8: MAIL FROM: <[email protected]>
9: 250 sender <[email protected]> ok
10: RCPT TO: <[email protected]>
11: 250 recipient <[email protected]> ok
12: DATA
13: 354 go ahead
14: Email test, Client, 16092020 at 10:42
15: .
16: 250 ok: Message 2009 accepted
17: ^]
18: telnet> quit
19: Connection closed.

In this post I’m going to go over why internal email relaying is a good thing for a Pen Tester and why system and network administrators should ensure that any superfluous services are disabled or blocked.

Commands

It’s quite simple to carry out email relaying, and it’s been documented extensively in various books and on the Web.

The Simple Mail Transfer Protocol (SMTP) has a number of commands. However, the following are the ones used for email relaying:

  • HELO (line 6): It’s always good to be polite, and this is exactly what we’re doing here: saying hello to the server! Note, EHLO has superseded HELO but a server must support HELO for compatibility with older clients.
  • MAIL FROM (line 8): This is who the mail is coming from. See lines 8 and 9 above.
  • RCPT TO (line 10): This is who the mail is going to. See lines 10 and 11 above.
  • DATA (line 12): This is the bit that contains the message itself. See lines 12 – 16 above.

Generally, if email relaying has been discovered whilst carrying out reconnaissance of the network, the next step is to manually prove it to using tools such as Telnet or NetCat. Telnet is normally installed on a UNIX or UNIX-like operating system. NetCat may be, but you may need to install it using the relevant package manager.

What can we put in the DATA section? ASCII text! Yup, that’s about it. However, that does mean that binary data can be sent if it is encoded using uuencode or base64 as both of those tools output ASCII. What’s important to realise here is that if documents in the organisation are watermarked or have headers/footers that contain protective marking directives (e.g. Commercial in Confidence, Secret Squirrel Super-Secret Document, etc) can be encoded and thus will likely bypass data loss prevention measures.

On site (remember that?)

This has happened a couple of times on internal infrastructure tests last year (2020, make of that what you will…). . It could potentially be used as a denial of service against the server . Or you may be able to spoof an email from a manager to one of their team. That could lead to problems between them.

However, sometimes it can be a lot worse. As a tester on an internal network you may not necessarily know the full path a service such as email can take. For example, a lot of companies have networks within their environment that are used for specific tasks that need to be kept separate, to a degree, from the main corporate network.

The network itself was mostly segregated from the desktop and other networks, although there were specific paths into it to allow management of the servers. General security of the environment was good, so all I was expecting from the email relaying was, well, not a lot really.

In order to test relaying, I sent an email from my PTP email address to the same. In theory, the email server should have told me to go away there and then. But it didn’t… The target email server wasn’t authoritative for PTP’s email so, similar to routing packets, it sends the email to the next hop in the chain. From the perspective of sitting on the internal network VLAN, there was no indication of where, or even if, there was a path out.

When the email arrived at PTP’s email servers. Because of that it was caught in the spam trap and a warning email sent to me:

The warning email contained the body, i.e. the DATA, section of the email which was the “Test message…” bit above. This is due to the email being flagged as suspicious, but the email did not contain any binaries or other potentially dodgy attachments (it would have been dropped instantly).

Now, an attacker would just spin up an email server in the cloud or as a VPS somewhere in order to exfiltrate the data, thus bypassing the caught-in-the-spam-trap issue.

Evading data loss prevention measures

Data Loss Prevention (DLP) software is used to prevent the loss of data (sometimes there’s just no better description!). In a nutshell, it’s a control to prevent the loss of sensitive data such as company intellectual property and so forth. Generally, what an organisation wants to do is to prevent data passing from a high security environment to a low security one. E.g., from the internal network to Pastebin…

Using this vulnerability to get data out of the organisation is a good way of avoiding DLP measures as the data can be encoded or encrypted then sent via the email relay. Any watermarks or protective marking would effectively be stripped from the data and thus allowed to pass unhindered to the outside world.

One thing that should be borne in mind with mail relaying is that it is anonymous. Unless an attacker is dumb enough to use their own, valid email address as the destination then there is no way to trace who connected to the port and sent the email. This can be abused to exfiltrate sensitive information out of the environment which possibly bypasses filters and so forth designed to block it.

However, in order to get the email out a routable email address is required. There’s a possibility that could be traced and help with a forensic investigation. That said, any attacker worth their salt would use disposable or anonymous email addresses. This can be abused to exfiltrate sensitive information out of the environment which possibly bypasses filters and so forth designed to block it.

Conclusion

As a System Administrator, what can you do to prevent data loss through such channels? The biggest problem, especially for large environments, is knowing what’s in there. There are a few things that can be done:

  • Get a regular Pen Test done. Don’t limit the scope, keep it as wide open as possible. You may think that the one server or network range you leave out doesn’t matter but I guarantee that’s the server that will cause the most damage if an attacker finds it.
  • Scan your own network. Port scan everything once a month as a regular task and carry out scans randomly in between. Knowing what services are listening is critical in reducing the attack surface an attacker can play with. Nmap is your friend here. The output can be easily manipulated and imported into something like Excel so that gap analysis can be done between pairs of scans. Also, trend analysis over longer periods of time can help in understanding what your environment looks like. E.g., has anything new been added? New services? Services that you aren’t expecting to be there?
  • Know your network. Have up to date network diagrams that include both physical and logical connectivity. The client for whom I found the issue was quite surprised that there was a path from inside a network that should have been segregated to the outside world.
  • Block outgoing connections in as many places as possible. Only need 80/TCP outbound? Then deny everything else. Look at network flows within the organisation. Block traffic between zones.
  • Look into Data Loss Prevention solutions and make sure they cover everything. Tools like uuencode are somewhat archaic but are still available and can be used to encode data.

The impact of data leaking out of the organisation can be quite severe. A loss of trust and reputation can do untold damage to a company, potentially causing it to go out of business.

References