2

I have a Small Business Server 2003 (Exchange 2003 SP2). During a PCI Compliance audit, it was flagged as failing the open relay. I've used telnet to test, and here is what I've found:

 MAIL FROM: <test@test.com>
 250 2.1.0 test@test.com....Sender OK
 RCPT TO: <"relaytest@test.com">
 250 2.1.5 "relaytest@test.com"@mydomain.com

The relay is failing whenever the address is malformed. The server always returns a 250 status, but also always adds my domain name to the end of the address.

I have the server configured to only relay for an internal ip address configured on an IIS site's error reporting module.

Testing with a valid email address (but malformed with quotes and angle brackets) resulted in no mail received. Is there a way to exploit this, and if so, how do I disable this?

Dave Simione
  • 143
  • 7
  • Did they actually confirm that they were getting successful relay with the malformed address? Or just the 250 response code? – Shane Madden May 30 '12 at 02:41
  • They consider getting a 250 result on a to that is not part of the domain as a relay. If adding the domain name to the end of the address prevents the relay, I'll use that to argue with them to allow this to pass. I just want to verify that fact before I argue with them. – Dave Simione May 30 '12 at 09:28

1 Answers1

1

I'd say the burden of proof is on them - they need to demonstrate that it's actually relaying to the encapsulated address for this to be a vulnerability.

You can't prove a negative; there's no way for you to demonstrate that every possible combination of address malforming will be rejected. Fuzzing the recipient address field of your email server should not be expected of you in order to prove compliance; testing these things and reporting on any issues found is what the scanner's getting paid for.

An accept response happens all the time for messages that aren't delivered (for spam in particular) - it's irresponsible of them to assume an open relay based on a particular response code. Every scan vendor of this type I've seen actually sends the message to an internet address, so that they're able to confirm whether they could successfully relay.

Your testing has shown that despite the response code, the message is not relayed, and the addition of your domain at the end is additional evidence that the message is going absolutely nowhere. However, they may have malformed the address in a different way and seen different behavior. Ask them for the exact traffic they send and what exact response they got, and whether their scan confirmed relaying over the internet. If they did, reproduce it; that should be the extent of the due diligence that you need to perform here.

If they won't prove that you're actually vulnerable to this vulnerability, then their scan is meaningless and you should contest their findings.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251