Banner Based Vulnerabilities For Microsoft Exchange smtpd

This Banner based Vulnerability is a common Exchange Server misconfiguration I see on PCI Compliance scans all the time. Try googling for this error and you just get a few forum pages telling you how to fix the issue; However, never explaining why this vulnerability happens in the first place.

Also, check out my HTTP Header Internal IP Disclosure tutorial. If you find this vulnerability also on your PCI Compliance Report.

Banner Based Vulnerabilities

Exchange Banner Based Vulnerabilities are caused by misconfigurations in the banner property on Exchange’s receive connectors. This is inadvertently giving out Information about your Exchange server like the Exchange Servers Fully Qualified Domain Name(FQDN).

220 DC01.EMPIRE.local

If nothing is set on the banner property, the Exchange receive connector kindly defaults to sending us some juicy information. This information includes the local Fully Qualified Domain Name(FQDN), type of Mail server and the local time.

A hacker could gather up this information about your internal network. Using this to find vulnerabilities or to help gain a foothold inside your network.

How to Test Your Exchange Server

The easiest way to test an Exchange server banner is with Telnet. You can just as easily use other tools like Netcat and get the same results.

From the Linux Terminal or Windows Command Prompt. Type telnet, then the IP address or hostname of the Exchange Server followed by port 25.

telnet your.domain.com 25

The Exchange banner is not only giving away the servers Local FQDN (DC01.EMPIRE.local). It is also letting the world know what type of SMTP server it is (Microsoft ESMTP MAIL Service ready). The end of the banner even includes the local time, allowing an attacker to work out its location.

Resolution

To resolve this issue we need to check the Banner property of the Exchange Receive Connector listening on port 25. Configuring it to display our external domain name, instead of the local FQDN of the server.

Login to your exchange server and open the Exchange Management Shell.

Once the Exchange management shell is loaded type Get-RecieveConnector. This display all the receive connectors on your Exchange server. Look for the receive connector bound to port 25. In my case, its DC01\Default Frontend DC01 but this name might be different for you.

Now use Format-List to print out all the properties of your chosen Receive Connector.

Get-ReceiveConnector -Identity "DC01\Default Frontend DC01" | fl

The Third setting in the list should be Banner. Notice how my setting for this is empty. You may also find this is where someone has set a local FQDN that is causing your PCI compliance issue.

The best practice is to Set the Recieve Connector Banner property to be 220 then your External Domain name. In my test Lab, this is mail.empire.com but you name this to whatever your external Domain name is.

Set-ReceiveConnector - Identity "DC01\Default Frontend DC01" -Banner "220 mail.empire.com"

If after hitting enter you get presented with a new line and no errors the banner property will have changed. You can always check this banner setting by using the Get-ReceiveConnector command with Format-List again.

Test again using telnet. The banner Response will now be 220 then the External FQDN that we set on the Receive Connector.

Smtpd Banner Rules!

The only restraint on the receive connectors banner is that it must start with 220. Its best practice to then follow with the external FQDN of the server but you can actually type anything here. That is as long as it starts with that initial 220.

Having the External FQDN after the 220 allows someone trying to confirm they are either sending mail or receiving mail from the right place. This reduces the likelihood that someone will think you are a spamming or spoofing.

Some admins put disclaimers or warnings into there SMTP banners after the 220 but I personally don’t see the point.

References :

• https://social.technet.microsoft.com/Forums/en-US/e55952d6-aa77-41f2-8b0b-c97982434451/banner-based-vulnerabilities-for-microsoft-exchange-smtpd?forum=Exch2016SD
• https://community.spiceworks.com/topic/833488-pci-dss-scan-failures-due-to-banner-based-vulnerabilities-in-https-iis-httpd

If you have found this Tutorial helpful Or you’re stuck on some other PCI Vulnerability let me know in the comments below and I will try and help you out. I may even try and write a tutorial on it.