A tool to harvest cookies left from secure browser sessions can now be built, following the release of information on the CookieMonster exploit, security training organisation the Sans Institute has warned.
Information about the CookieMonster exploit has been published, the Sans Institute said, providing a way for hostile parties to retrieve information passed during HTTPS connections.
CookieMonster was developed by researcher and Riverbed developer Mike Perry, who gave a presentation on the subject at the Defcon security conference in August. Information about the tool and its ability to retrieve HTTPS session cookies in cleartext was released on Tuesday, warned Sans.
"If someone can place themselves so they see your web traffic, they can… force your browser to provide the saved cookies in a cleartext response," wrote Sans Institute handler David Goldsmith in a blog post.
According to Perry, who also publicised the vulnerability, CookieMonster is a man-in-the-middle attack that works by obtaining DNS responses and caching them. The exploit listens for port 443 connections, the default TCP port for HTTPS. It then uses the cache to map the IP to the domain name and add the IP to list of targets. When a request comes to port 80, used for non-encrypted traffic, CookieMonster injects HTTP images for the target sites. The victim's browser then transmits unencrypted cookies for the sites, which CookieMonster captures.
A number of attack vectors could be used by hackers, Perry warned, including Dan Kaminsky's DNS hijacking attack.
Perry released details of the tool in his blog on Tuesday, and wrote that human-readable source code would be released in due course. He stressed that site administrators need to set cookies to be encrypted.
In a blog post on Friday, Perry added that, in addition to stealing insecure HTTPS cookies, CookieMonster also steals URL-based session ID details, which are used as a protection against cross-site request forgery. Stealing and using these details makes session theft attempts more likely to succeed.
Perry first published details of the vulnerability a year ago on the Bugtraq mailing list. However, in a blog post in August, Perry wrote that he had developed the exploit so vendors and developers would take the problem seriously.
"I waited a full year after submitting a detailed Bugtraq posting, as well as reporting the vulnerability to a major affected vendor, and still nothing happened," wrote Perry. "Without at least a demo, it seems that people are either not inclined to believe your vulnerability is real or not motivated to invest the effort in fixing it."
