A denial-of-service attack depends on asymmetry between attacker and victim. This is the leverage: when bad guys can expend a small amount of effort to cause the good guys to spend large amounts of resources, there is leverage that can lead to a DoS vulnerability. Any feature that creates such leverage increases risk for the system.Distribution lists are a prime example of leverage. One email from the sender morphs into hundreds or even thousands of messages destined for unsuspecting recipients’ inboxes. That is partly the reason Exchange allows controlling the users authorized to send email to a given DL. It is a good idea to restrict this to a small number of users in the case of large distribution lists. What happens when you don’t will be remembered as the infamous “Bedlam 3” debacle in Microsoft lore dating back to the late 1990s. (No wonder the old-timers who were around Bedlam– and it was remarkable enough to inspire its own tshirt with the slogan “I survived Bedlam 3”– were having a deja vu moment with the Blue Hat announcement.) As recounted in this entry from the Exchange team blog, Bedlam resulted from the interaction of an unrestricted DL with predictable human reactions to respond to spam with more spam commentary, some of it even urging other users to stop spamming the alias.

A distribution list with N users gives the attacker a leverage factor of N. For 1 message sent by the attacker, the system works N times as hard, using up roughly N times the storage space. (Interesting enough, the bandwidth requirements within one enterprise do not scale linearly because the system is intelligent enough to optimize delivery across different servers using a single copy.) That is not a bad starting point for a DoS attack: imagine sending a sizable message– perhaps containing an attachment such as image or video– to a very large DL with thousands of users, assuming you can find that misconfigured DL. But it does not work; in most cases only a single instance of that large attachment is stored for all the users sharing the same Exchange server.

But the experiment on Thursday proved one can do substantially better. Sending a message from the alias itself and requesting recall notifications– which are going to be delivered to the same alias, of course– broke new ground. Every one of those N users on the distribution list are going to get a status message for every one of the other N users. That’s N-square or quadratic leverage, achieved at a remarkable economy with only two messages. And 2K * 2K == 4 million messages is exactly what would have been exchanged if it were not for the fact that IT department stepped in after the backlogs grew out of control, legitimate email traffic slowed to a crawl and one of the Exchange servers pegged its memory.

Wreaking havoc on the enterprise scale with 2 messages ? Now that is an accomplishment worthy of its own Black Hat session.

cemp

It all started with 2 seemingly bening messages appearing in the Outlook inbox. The first one was an announcement for the upcoming BlueHat event. (BlueHat is a series of security-focused presentations for Microsoft employees styled after the more famous Black Hat briefings held in Las Vegas every year.) Arriving within minutes after that was a second follow-up message, recalling the first one.

The recall feature is an interesting piece of functionality built into Outlook and Exchange. It was the subject of a Sunday New York Times article couple of weeks ago, discussing how to handle the situation when you send a message that in retrospect comes to be viewed as perhaps written in a moment of anger or indiscretion. But contrary to what users might hope for, the recall does not automatically yank the message from recipients’ inbox. Instead it depends on sending a follow-up message announcing the intention to recall the original one. “Intention” is the key word, and that request has to be honored by the sender and/or senders’ email application aka the MUA, mail user agent. Outlook recognizes these messages and in principle opening the second message– either intentionally or by browsing with preview pane for example– the first message is removed from the Inbox. The catch is that the recipient could choose to open the first message first, even if the recall message has already arrived. In reality the recall virtually ensures the original one will be opened and scrutinized very carefully, by drawing attention to the unintended error. (In one case HR emailed a document containing sensitive compensation information to an entire building full of employees, followed up with a recall message and an even more helpful second email explaining why the first message is “highly confidential” and urging recipients to delete it without reading.)

In this case there was nothing particularly confidential or inappropriate about the original message, perhaps a misspelling here and there or an incomplete sentence. But the original sender– identity unknown because the message was sent out on behalf of the distribution list– dutifully recalled it. And that is when all hell broke loose. The first indication of something amiss emerged when this author, along with 2000+ employees on that alias, started receiving recall success/failure messages in his inbox. All of this is by design: when you recall a message, you can ask for confirmation from Exchange as to whether the recall succeeded or whether the recipient read the message. That generates one status message per potential recipient, returned to the original sender.

Except that in this case the message was sent on behalf of the distribution list, “Bluehat Alerts” which contained over two thousand employees. So the status messages naturally were also sent to the same DL.

That would be 2000+ status messages each delivered to 2000+ members of the alias.

Unwittingly the sender had just pulled off a remarkable denial-of-service attack against the corporate email system and succeeded in bringing the pilot deployment of the new Exchange Titanium to its breaking point.

And it only took 2 messages. One of which was intended to announce an event focused on computer security , on building/breaking systems that can survive hostile attacks. The irony was inescapable.

(continued)

cemp