Tossing Active Cookies
Thomas Ptacek | June 28th, 2006 | Filed Under: Defenses, Uncategorized
Also from NetworkWorld, this time in “10 Cutting Edge Research Projects You Don’t Need To Know About”, “Active Cookies”.
Alice, Mallory, Bob. Assume Alice and Bob can talk securely once. Then Bob can give Alice a cookie sourced to IP(Bob) instead of Name(Bob).
Now,
alice -> mallory -> bob, after Alice has a cookie from Bob.
Mallory tries to be Man-in-the-Middle via DNS spoofing. Alice logs into Mallory. Mallory logs into Bob.
Bob issues redirect (intended for Alice) to IP(Bob).
Mallory can’t:
Get between alice -> IP(Bob), because Mallory can’t spoof IP.
Modify Bob’s redirect, because Bob is waiting for a cookie that will only be presented to IP(Bob).
Allow Bob’s redirect without disclosing his own presence, because (on the wire) Mallory appears to have initiated the login, not Alice.
Game over Mallory?
Uh, no. Apart from the glaring dependence on a prior authenticated transaction between Alice and Bob, after which cookies cannot be removed, this defense assumes Mallory’s only winning strategy is to consume requests from Alice, repackage them, and send them directly to Bob (the classic MITM formulation).
But that’s not Mallory’s only winning strategy. Mallory can intercept Alice, read enough from Alice to win, and pass her along directly to Bob none the wiser. I think this “defense” misunderstands the nature of active attackers.
I don’t think this technique makes Mallory’s job meaningfully harder.
Two other obvious “problems” that I feel are more easily knocked down by the authors:
Active Cookies only impact DNS spoofing attackers. But IP spoofing is much harder than DNS spoofing. While I don’t think the difference between IP and DNS spoofing is qualitative, especially when money’s on the line, it’s probably quantitatively different. That said, Active Cookies have no play for internal applications, where IP spoofing is much easier.
How is this any better than SSL? Because it delegates to the web application the task of verifying the channel. With modern browser UI, users don’t have enough information to do that.


drench
June 30th, 2006 10:44 amUnless I’m missing something, it sure seems like their “IP tracing” scheme breaks for AOL users, whose client IP often (always?) changes with every request. AOL’s not the only one using a NAT/proxy scheme where there’s a pool of outgoing addresses either.
Leave a reply