A few months ago I found a security bug in Microsoft Exchange Server 5.0 that I think is worth writing about, both because of what the bug does and because of what happened after I reported it.
I work at Philadelphia Newspapers, where we run Exchange for email. We had recently set up POP3 access so people could check their mail remotely. I was testing the system and noticed something strange: after changing a user’s password, the old password still worked. Both the old password and the new password could be used to log in.
That is a serious problem. The whole point of changing a password is to lock out anyone who knows the old one. If a password is stolen or an employee leaves the company, the standard procedure is to change the password immediately. But with this bug, changing the password does nothing. The old password keeps working. An attacker who had the old password could continue reading someone’s email indefinitely.
I investigated further and determined that the issue was in how Exchange cached passwords. When you authenticate via POP3, Exchange stores your password in a cache so it does not have to verify it against the domain controller every time. The problem is that when an administrator changes the password, Exchange never flushes the cache. The old password sits there and continues to be accepted.
I documented the problem and posted a security alert on my web site on August 20, with details at http://rajiv.org/active/. The information was then cross-posted to the Bugtraq security mailing list and to the microsoft.public.exchange.clients newsgroup.
The response was faster than I expected. Microsoft posted a public note on October 15 responding to the issues I had raised and promising a full source code review. On October 22, they released a patched version of the server extensions with a fix.
It also turned out that the problem was bigger than I initially found. David LeBlanc, a security researcher, pointed out that Microsoft’s FTP, HTTP, and Gopher services suffered from the exact same password caching flaw. The bug was not specific to Exchange’s POP3 service. It was in the shared authentication layer that all of these internet-facing services used. The only thing not affected was the core Windows NT login system itself.
The fix involved editing three registry keys to set the credential cache parameters to zero:
HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials
Cache Age Limit (Default = 120 minutes)
HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials
Cache Idle Limit (Default = 15 minutes)
HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials
Cache Size (Default = 256 buckets)Setting all of these to 0 forces the system to verify passwords against the domain controller every time, which eliminates the caching problem entirely.
I learned a few things from this experience that I want to share.
First, security testing does not require special tools or advanced knowledge. I found this bug while doing routine work. I changed a password and then tested whether the old one still worked. That is a basic check that anyone administering a mail server should do. The fact that it had not been caught before tells me that many organizations trust their software more than they should.
Second, when you find a real security problem, document it carefully and make it public. I posted the details on my web site with a clear description of the problem, the impact, and the steps to reproduce it. That is what got Microsoft’s attention. If I had just filed a support ticket, I doubt it would have been fixed in a week.
Third, one bug is often a symptom of a larger problem. David LeBlanc’s discovery that FTP, HTTP, and Gopher had the same flaw shows that the password caching issue was not a one-off mistake in the POP3 code. It was an architectural decision that had the same consequence everywhere it was applied. When you find a bug, it is worth asking whether the same mistake could exist in other parts of the system.
This is a time when more and more companies are connecting their internal systems to the internet through protocols like POP3, HTTP, and FTP. The security of these connections matters. A flaw at the boundary between your internal network and the public internet can compromise everything behind it. I hope that sharing this experience encourages others to test their systems carefully and to report what they find.