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: <[email protected]>
 250 2.1.0 [email protected] OK
 RCPT TO: <"[email protected]">
 250 2.1.5 "[email protected]"@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?

Improve this question
2
  • Did they actually confirm that they were getting successful relay with the malformed address? Or just the 250 response code?
    – Shane Madden
    May 30, 2012 at 2: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, 2012 at 9:28

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .