Attachments

An attacker can create an attachment-overload attack by sending hundreds or thousands of e-mails with very large attachments to one or more recipients on your network.

Connections

A hacker can send a huge number of e-mails simultaneously to addresses in your e-mail system. Malware that’s present on your network can do the same thing from inside your network if there’s an open Simple Mail Transfer Protocol (SMTP) relay on your network (which is often the case). (More about that follows.) These connection attacks can cause the server to give up on servicing any inbound or outbound TCP requests. This situation can lead to a complete server lockup or a crash, often resulting in a condition in which the attacker is allowed administrator or root access to the system.

Countermeasures against connection attacks

Prevent e-mail attacks as far out on your network perimeter as you can. The more traffic or malicious behavior you keep off your e-mail servers and clients, the better.

Many e-mail servers allow you to limit the number of resources used for inbound connections, as shown in the Maximum number of simultaneous threads setting for IceWarp e-mail server in Figure 14-1. This setting is called different things for different e-mail servers and e-mail firewalls, so check your documentation. Completely stopping an unlimited number of inbound requests can be impossible. However, you can minimize the impact of the attack. This setting limits the amount of server processor time, which can help during a DoS attack.

Even in large companies, or if you’re using a cloud-based e-mail service such as Office 365, there’s likely no reason that thousands of inbound e-mail deliveries should be necessary within a short time period.

E-mail servers can be programmed to deliver e-mails to a service for automated functions, such as create this e-commerce order when a message from this account is received. If DoS protection isn’t built in to the system, an attacker can crash both the server and the application that receives these messages and potentially create e-commerce liabilities and losses. This can happen more easily on e-commerce websites when CAPTCHA (short for Completely Automated Public Turing test to tell Computers and Humans Apart) is not used on forms. I cover web application security in Chapter 15.

Automated e-mail security controls

You can implement the following countermeasures as an additional layer of security for your e-mail systems:

• Tarpitting: Tarpitting detects inbound messages destined for unknown users. If your e-mail server supports tarpitting, it can help prevent spam or DoS attacks against your server. If a predefined threshold is exceeded — say, more than 100 messages in one minute — the tarpitting function effectively shuns traffic from the sending IP address for a period of time.
• E-mail firewalls: E-mail firewalls and content-filtering applications from vendors such as Symantec and Barracuda Networks can go a long way towards preventing various e-mail attacks. These tools protect practically every aspect of an e-mail system.
• Perimeter protection: Although not e-mail-specific, many firewall and IPS systems can detect various e-mail attacks and shut off the attacker in real time. This can come in handy during an attack.
• CAPTCHA: Using CAPTCHA on web-based e-mail forms can help minimize the impact of automated attacks and lessen your chances of e-mail flooding and denial of service — even when you’re performing seemingly benign web vulnerability scans. These benefits really come in handy when testing your websites and applications, as I discuss in Chapter 15.

Gathering information

Figure 14-2 shows the banner displayed on an e-mail server when a basic telnet connection is made on port 25 (SMTP). To do this, at a command prompt, simply enter telnet ip or_hostname_of_your_server 25. This opens a telnet session on TCP port 25.

The e-mail software type and server version are often very obvious and give hackers some ideas about possible attacks, especially if they search a vulnerability database for known vulnerabilities of that software version. Figure 14-3 shows the same e-mail server with its SMTP banner changed from the default (okay, the previous one was, too) to disguise such information as the e-mail server’s version number.

You can gather information on POP3 and IMAP e-mail services by telnetting to port 110 (POP3) or port 143 (IMAP).

If you change your default SMTP banner, don’t think that no one can figure out the version. General vulnerability scanners can often detect the version of your e-mail server. One Linux-based tool called smtpscan (www.freshports.org/security/smtpscan/) determines e-mail server version information based on how the server responds to malformed SMTP requests. Figure 14-4 shows the results from smtpscan against the same server shown in Figure 14-3. The smtpscan tool detected the product and version number of the e-mail server.

Countermeasures against banner attacks

There isn’t a 100 percent secure way of disguising banner information. I suggest these banner security tips for your SMTP, POP3, and IMAP servers:

• Change your default banners to conceal the information.
• Make sure that you’re always running the latest software patches.
• Harden your server as much as possible by using well-known best practices from such resources as the Center for Internet Security (www.cisecurity.org) and NIST (http://csrc.nist.gov).

Account enumeration

A clever way that attackers can verify whether e-mail accounts exist on a server is simply to telnet to the server on port 25 and run the VRFY command. The VRFY — short for verify — command makes a server check whether a specific user ID exists. Spammers often automate this method to perform a directory harvest attack (DHA), which is a way of gleaning valid e-mail addresses from a server or domain so hackers know whom to send spam, phishing, or malware-infected messages to.

Attacks using account enumeration

Figure 14-5 shows how easy it is to verify an e-mail address on a server with the VRFY command enabled. Scripting this attack can test thousands of e-mail address combinations.

The SMTP command EXPN — short for expand — might allow attackers to verify what mailing lists exist on a server. You can simply telnet to your e-mail server on port 25 and try EXPN on your system if you know of any mailing lists that might exist. Figure 14-6 shows how the result might look. Scripting this attack and testing thousands of mailing list combinations is simple.

You might get bogus information from your server when performing these two tests. Some SMTP servers (such as Microsoft Exchange) don’t support the VRFY and EXPN commands, and some e-mail firewalls simply ignore them or return false information.

Another way to somewhat automate the process is to use the EmailVerify program in TamoSoft’s Essential NetTools (www.tamos.com/products/nettools). As shown in Figure 14-7, you simply enter an e-mail address, click Start, and EmailVerify connects to the server and pretends to send an e-mail.

Yet another way to capture valid e-mail addresses is to use theHarvester (https://github.com/laramies/theHarvester) to glean addresses via Google and other search engines. As I outline in Chapter 9, you can download Kali Linux from www.kali.org to burn the ISO image to CD or boot the image directly through VMware or VirtualBox. In the Kali Linux GUI, simply choose Applications ⇒ Information Gathering ⇒ SMTP Analysis ⇒ smtp-user-enum and enter smtp-user-enum –M VRFY –u <user name you wish to confirm> -t server IP/hostname , as shown in Figure 14-8.

You can customize smtp-user-enum queries as well using, for example, EXPN in place of VRFY and –U and a list of user names in a file to query more than one user. Simply enter smtp-user-enum for all the search options.

Relay

SMTP relay lets users send e-mails through external servers. Open e-mail relays aren’t the problem they used to be, but you still need to check for them. Spammers and criminal hackers can use an e-mail server to send spam or malware through e-mail under the guise of the unsuspecting open-relay owner.

Be sure to test for open relay from both outside and inside your network. If you test your internal systems, you might get false positives because outbound e-mail relaying might be configured and necessary for your internal e-mail clients to send messages to the outside world. However, if a client system is compromised, that issue could be just what the bad guys need to launch a spam or malware attack.

Automatic testing

Here are a couple of easy ways to test your server for SMTP relay:

• Vulnerability Scanners: Many vulnerability scanners such as Nexpose and QualysGuard will find open e-mail relay vulnerabilities.

• Windows-based tools: One example is NetScanTools Pro (www.netscantools.com). You can run an SMTP Relay check on your e-mail server with NetScanTools Pro, as shown in Figure 14-9.

  Although some SMTP servers accept inbound relay connections and make it look like relaying works, this isn’t always the case because the initial connection might be allowed, but the filtering actually takes place behind the scenes. Check whether the e-mail actually made it through by checking the account you sent the test relay message to.

In NetScanTools Pro, you simply enter values for the SMTP mail server name and Your Sending Domain Name. Inside Test Message Settings, enter the Recipient Email Address and Sender’s Email Address. If the test is successful, NetScanTools Pro will open a window that says “Message Sent Successfully.”

You can also view the results in the main SMTP Server Tests window and generate a formal report by simply clicking View Results in a Web Browser and then clicking View Relay Test Results.

E-mail header disclosures

If your e-mail client and server are configured with typical defaults, a malicious attacker might find critical pieces of information:

• Internal IP address of your e-mail client machine (which can lead to the enumeration of your internal network and eventual exploitation via phishing and/or subsequent malware infection)
• Software versions of your client and e-mail server along with their vulnerabilities
• Hostnames that can divulge your network naming conventions

Testing

Figure 14-10 shows the header information revealed in a test e-mail I sent to my free web account. As you can see, it shows off quite a bit of information about my e-mail system:

• The third Received line discloses my system’s hostname, IP address, server name, and e-mail client software version.
• The X-Mailer line displays the Microsoft Outlook version I used to send this message.

Capturing traffic

E-mail traffic, including usernames and passwords, can be captured with a network analyzer or an e-mail packet sniffer and reconstructor.

Mailsnarf is an e-mail packet sniffer and reconstructor that’s part of the dsniff package (http://sectools.org/tool/dsniff). There’s a great commercial (yet low-cost) program called NetResident (www.tamos.com/products/netresident), too. You can also use Cain & Abel (www.oxid.it/cain.html) to highlight e-mail-in-transit weaknesses. I cover password cracking using this tool and others in Chapter 8.

If traffic is captured, a hacker or malicious insider can compromise one host and potentially have full access to another adjacent host, such as your e-mail server.

Malware

E-mail systems are regularly attacked by such malware as viruses and worms. One of the most important tests you can run for malware vulnerability is to verify that your antivirus software is actually working.

Before you begin testing your antivirus software, make sure that you have the latest virus software engine and signatures loaded.

EICAR offers a safe option for checking the effectiveness of your antivirus software. Although EICAR is by no means a comprehensive method of testing for malware vulnerabilities, it serves as a good, safe start.

EICAR is a European-based malware think tank that has worked in conjunction with anti-malware vendors to provide this basic system test. The EICAR test string transmits in the body of an e-mail or as a file attachment so that you can see how your server and workstations respond. You basically access (load) this file — which contains the following 68-character string — on your computer to see whether your antivirus or other malware software detects it:

X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

You can download a text file with this string from www.eicar.org/86-0-Intended-use.html. Several versions of the file are available on this site. I recommend testing with the Zip file to make sure that your antivirus software can detect malware within compressed files.

When you run this test, you may see results from your antivirus software similar to Figure 14-11.

In addition to testing your antivirus software, you can attack e-mail systems using other tools I cover in this book. Metasploit (www.metasploit.com) enables you to discover missing patches in Exchange and other servers that hackers could exploit. Brutus (www.hoobie.net/brutus) enables you to test the cracking of web and POP3/IMAP passwords.

Software solutions

The right software can neutralize many threats:

• Use anti-malware software on the e-mail server — better, the e-mail gateway — to prevent malware from reaching e-mail clients. Cloud-based e-mail systems such as those offered by Google and Microsoft often have such protection built in. Using malware protection on your clients is a given.
• Apply the latest operating system and e-mail server security patches consistently and after any security alerts are released.

• Encrypt (where’s it reasonable). You can use S/MIME or PGP to encrypt sensitive messages or use e-mail encryption at the desktop level or the server or e-mail gateway. Better yet (i.e. an easier means), you can also use TLS via the POP3S, IMAPS, and SMTPS protocols. The best option may be to use an e-mail security appliance or cloud service that supports the sending and receiving of encrypted e-mails via a web browser over HTTPS.

  Don’t depend on your users to encrypt messages. As with any other security policy or control, relying on users to make security decisions often ends poorly. Use an enterprise solution to encrypt messages automatically instead.

  Make sure that encrypted files and e-mails can be protected against malware.

  • Encryption doesn’t keep malware out of files or e-mails. You just have encrypted malware within the files or e-mails.
  • Encryption keeps your server or gateway anti-malware from detecting the malware until it reaches the desktop.
• Make it policy for users not to open unsolicited e-mails or any attachments, especially those from unknown senders, and create ongoing awareness sessions and other reminders.
• Plan for users who ignore or forget about the policy of not opening unsolicited e-mails and attachments. It will happen!

Operating guidelines

Some simple operating rules can keep your walls high and the attackers out of your e-mail systems:

• Put your e-mail server behind a firewall on a different network segment from the Internet and from your internal LAN — ideally in a demilitarized zone (DMZ).
• Harden by disabling unused protocols and services on your e-mail server.
• Run your e-mail server and perform malware scanning on dedicated servers if possible (potentially even separating inbound and outbound messages). Doing so can keep malicious attacks out of other servers and information in the event the e-mail server is hacked.
• Log all transactions with the server in case you need to investigate malicious use. Be sure to monitor these logs as well! If you cannot justify monitoring, consider outsourcing this function to a managed security services provider.
• If your server doesn’t need certain e-mail services running (SMTP, POP3, and IMAP), disable them — immediately.
• For web-based e-mail, such as Microsoft’s Outlook Web Access (OWA), properly test and secure your web server application and operating system by using the testing techniques and hardening resources I mention throughout this book.
• Require strong passwords. Be it standalone accounts or domain-level Exchange or similar accounts, any password weaknesses on the network will trickle over to e-mail and surely be exploited by someone via Outlook Web Access or POP3. I cover password hacking in Chapter 8.
• If you’re running sendmail — especially an older version — consider running a secure alternative, such as Postfix (www.postfix.org) or qmail (www.qmail.org).

Scanning for vulnerabilities

Outside the basic network, OS, and web application vulnerabilities, you can uncover other VoIP issues if you use the right tools. The good news is that you likely already have these tools at your disposal in the form of network vulnerability scanners such as Nexpose (www.rapid7.com/products/nexpose) and web vulnerability scanners such as Netsparker (www.netsparker.com). Common flaws in the VoIP call managers and phones include weak passwords, cross-site scripting, and missing patches that can be exploited using a tool such as Metasploit.

Kali Linux has several VoIP tools built in via Applications/Vulnerability Analysis/VoIP Tools. Other free tools for analyzing SIP traffic are PROTOS (www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html), and sipsak (www.voip-info.org/wiki/view/Sipsak). A good website that lists all sorts of VoIP tools is www.voipsa.org/Resources/tools.php.

Capturing and recording voice traffic

If you have access to the wired or wireless network, you can capture VoIP conversations easily. This is a great way to prove that the network and the VoIP installation are vulnerable. There are many legal issues associated with tapping into phone conversations, so make sure you have permission and are careful not to abuse your test results.

You can use Cain & Abel (technically just Cain for the features I demonstrate here) to tap into VoIP conversations. You can download Cain & Abel free at www.oxid.it/cain.html. Using Cain’s ARP poison routing feature, you can plug in to the network and have it capture VoIP traffic:

1. Load Cain & Abel and then click the Sniffer tab to enter the network analyzer mode.

   The Hosts page opens by default.

2. Click the Start/Stop APR icon (which looks like the nuclear waste symbol).

   The ARP poison routing process starts and enables the built-in sniffer.

3. Click the blue + icon to add hosts to perform ARP poisoning on.
4. In the MAC Address Scanner window that appears, ensure that All Hosts in My Subnet is selected and then click OK.
5. Click the APR tab (the one with the yellow-and-black circle icon) to load the APR page.

6. Click the white space under the uppermost Status column heading (just under the Sniffer tab).

   This step re-enables the blue + icon.

7. Click the blue + icon and the New ARP Poison Routing window shows the hosts discovered in Step 3.

8. Select your default route or other host that you want to capture packets traveling to and from.

   I just select my default route, but you might consider selecting your SIP management system or other central VoIP system. The right column fills with all the remaining hosts.

9. In the right column, Ctrl+click the system you want to poison to capture its voice traffic.

   In my case, I select my VoIP network adapter, but you might consider selecting all your VoIP phones.

10. Click OK to start the ARP poisoning process.

    This process can take anywhere from a few seconds to a few minutes depending on your network hardware and each host’s local TCP/IP stack.

11. Click the VoIP tab and all voice conversations are “automagically” recorded.

    Here’s the interesting part — the conversations are saved in .wav audio file format, so you simply right-click the recorded conversation you want to test and choose Play, as shown in Figure 14-13. Note that conversations being recorded show Recording … in the Status column.

The voice quality with Cain and other tools depends on the codec your VoIP devices use. With my equipment, I find the quality is marginal at best. That’s not really a big deal, though, because your goal is to prove there’s a vulnerability — not to listen in on other people’s conversations.

There’s also a Linux-based tool called vomit (http://vomit.xtdnet.nl) — short for voice over misconfigured Internet telephones — that you can use to convert VoIP conversations into .wav files. You first need to capture the actual conversation by using tcpdump, but if Linux is your preference, this solution offers basically the same results as Cain, outlined in the preceding steps.

If you’re going to work a lot with VoIP, I highly recommend you invest in a good VoIP network analyzer. Check out WildPackets’ OmniPeek — a great all-in-one wired and wireless analyzer (www.savvius.com/products/overview/omnipeek_family/omnipeek_network_analysis) — and TamoSoft’s CommView (www.tamos.com/products/commview), which is a great low-priced alternative.

These VoIP vulnerabilities are only the tip of the iceberg. New systems, software, and related protocols continue to emerge, so it pays to remain vigilant, helping to ensure your conversations are locked down from those with malicious intent. Like I’ve said before, if it has an IP address or a URL, it’s fair game for attack.