A Story About Cookie Stealing.

I got this e-mailed from a reader and I wanted to share this story with you. It's a great example mainly on cookie stealing, but it also shows how systems c.q. users can be compromised in ways one would not anticipate upon. A mistake is quickly made even with rigorous security measures. Therefore to close off this year with a good rule of thumb: Security takes time, and a lot of effort. Stealing CookiesI have an account on rootshell.be (a free OpenBSD shell provider). We have a small forum on forum.rootshell.be but before a week or so, it was on www.rootshell.be/forum/ It was moved to 'forum' because 'www' is actually the same machine which hosts free shell accounts. The forum software is PunBB, which uses a HttpOnly cookie, consisting of serialize()d UID and password hash. And this installation (itself in /forum/ before move) would set cookie path to '/' which means any page below '/' could read the cookie.We (account owners) can host our homepages here, and access them as <http://www.rootshell.be/~user/>. As I've mentioned, on the same machine was our forum. So I wrote a simple script, which would log any $_COOKIE['punbb_cookie'] to a file. Then I posted a message on the forum, with a few lines about the misconfiguration and [img] tag linked to my script.Of course, the Great Root Xavier read the post, and I got his old autologin cookie, which wasn't expired because the forum was moved some 8 days ago. And there, instant admin access. Xavier (root) has confirmed this vulnerability, said that punBB uses cookie path '/' by default, and you have to edit config.php to change that (in phpBB, for example, this is an option in admin screen).The moral of this story? never be lazy when configuring a new app/script on a shared system.