Help! We're trapped in the computer, and the computer is trapped in 2008! Someone call the time police!
0 Members and 1 Guest are viewing this topic.
(Why, yes, I came up with the name, and had to find some bugs to be ableto post this.)Summary------- There are three fairly interesting flaws in how HTTP cookies were designed and later implemented in various browsers; these shortcomings make it possible (and alarmingly easy) for malicious sites to plant spoofed cookies that will be relayed by unsuspecting visitors to legitimate, third-party servers.Impact------ Many commercial websites may be attacked to overwrite or delete stored preferences, session identifiers, authentication data, cart contents - with results ranging from minor annoyances to a possibility of fraudulent activity, depending on site design (bugs #1 and #2). On sites where authentication data is tied on a server to a session ID, the attacker may be able to acquire credentials by tricking the visitor to authenticate within a session initiated by the attacker (bugs #1 and #2) Some websites may be susceptible to malicious-activity-by-proxy attacks (bug #3). There is no immediate universal threat to life as we know it, but numerous web scripts are an easy target of specific variants of the attacks described below.Discussion---------- Let's begin with a quick primer on cookie parsing: when a new cookie is issued to the browser (via "Set-Cookie" header in a HTTP response), the server is expected to specify the domain and URI for which the cookie is meaningful. This mechanism is present so that pages could limit the scope of their cookies if needed, and prevent the data from being sent to unrelated addresses in the same domain. For security purposes, the browser will (theoretically) reject a cookie that is set for a domain that is either defined too broadly, or does not match issuer's location at all. (In other words, http://www.example.com/ may set a cookie that will be sent to http://mail.example.com/, but not to http://forums.example.com/; it cannot configure a cookie to be sent to all .com servers, nor to an unrelated server, example.co.uk, however.) Problem #1 - trouble with these pesky foreigners ------------------------------------------------ The mechanism for preventing overly relaxed cookie domain specification seems to be broken in all major browsers. Some ancient documents invoke the following flawed but reasonable rule: "Two dots are required if the top level domain is: .COM, .EDU, .NET, .ORG, .GOV, .MIL, or .INT. Three dots are required for any other domain. This is to prevent the subdomain from being set to something like .COM, the subdomain of all commercial machines." [ http://www.ciac.org/ciac/bulletins/i-034.shtml ] This is repeated ad nauseam in various cookie tutorials and FAQs, but my initial tests indicate that the rule is quite simply not true. Both MSIE and Firefox seem to be perfectly happy with two-period ccTLDs domain cookies (.xxx.xx). In other words, one can set a cookie for *.com.pl or *.com.fr, and override or corrupt credentials or other parameters on hundreds of thousands e-commerce websites in that country. It will be also possible to plant attacker's session ID on visitor's computer, and effectively, steal his credentials when he decides to sign in on the target site. Problem #2 - these cursed periods --------------------------------- Another twist on the story is that there is no checking if there's anything between periods in domain name - and extra trailing periods are accepted by most resolvers as a way to override local domain search path. One can set a cookie for ".com.", then bounce the visitor to http://www.victim.com./ . This address differs from the "real" one, and thus, unlike with #1, planted cookies would work only for this visit - but the trailing "." is not an alarming pattern for most users. In fact, seasoned users recognize it and sometimes purposefully append it - and as such, they won't be tempted to be suspicious, and may interact with the website (perhaps even authenticate within the session ID supplied by and known to the attacker). A surprise of sorts... I'm not the first person to spot this: http://www.nihongo.org/snowhare/utilities/triple_dot/ - credit goes to Benjamin Franz... vendors were notified in 1998, and certainly are not in a hurry to fix this. Ok, let's go back to cookie handling for a while... All the verification of domain path is limited to client-side; when the server receives a cookie ("Cookie" header in a HTTP request), there is no information about the original issuer. It is assumed that the browser behaves rationally, and is sending the cookie to a site or a set of sites that previously issued it. The only other option is that the user willingly tampered with the request, and is OK with any eventual consequences of his actions. This is a mistake. Problem #3 - it's the address that counts ----------------------------------------- The attacker may easily force random visitors to accept and relay arbitrary cookies to a third-party site by a) setting up http://example.com; b) issuing all visitors a cookie that mimicks victim's cookies, but is valid for *.example.com; c) setting IN A record for evil.example.com to the IP address of its victim; d) redirecting users to http://evil.example.com. This will cause visitor's browser to send attacker's cookie to victim's server exactly as if it were a cookie originally issued by the victim himself. This trick alone does not compromise, disclose, erase, or supersede user's settings should he later access the site through its proper address; and since a bogus address is displayed in URL bar, the user is not tempted to interact with the website. (There are some brain-damaged examples of sessionID-in-URL redirects, but these have a fair share of other problems.) I do believe there is some risk, however: using this trick, a brand new identity may be temporarily bestowed upon the user, and used to perform certain undesirable or malicious tasks on the target site before he has a chance to object (hiding attacker's identity or bypassing IP-based limits). DDoS or session ID brute-forcing uses are also tempting. That said, this alone is not a major problem for a well-designed website and a savvy user; alas, websites should be designed with the knowledge of this possibility; and furhter research on specific applications of this technique to existing backends might be quite valuable. Well... that's the story...Solution-------- Problem #1: There is no sane solution, other than altering HTTP cookie format so that the server gets a chance to figure out who issued that cookie in the first place. Workarounds by listing ccTLDs that use .xxx.xx/.xx.xx subdomains in the browser are better than nothing at all. Problem #2: Browsers should strip "idle" periods in cookie domain data. Browser vendors should take less than 8 years to address security problems. Problem #3: The immediate fix to this problem is requiring and carefully validating HTTP/1.1 "Host" header on all requests (this ensures that the browser's idea of who he's talking to matches the site's canonical name).Lame plug--------- http://lcamtuf.coredump.cx/silence/Cheers,/mz_______________________________________________Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/
