Plans Calendar Cross-Site Scripting (XSS) proof of concept

Plans Calendar is vulnerable to cross-site scripting attacks.

So how does this XSS work?
FAQ
Go on then, show me

So how does this XSS work?

First, Nasty Hacker convinces you to visit his/her URL. Some possible ways to do this...
- Post a link saying "Claim your $500 now!" and hope you follow it (nasty)
- Send you a mail saying "I have already stolen your password, follow this link to see" (nastier)
- Post a link saying "Plans is vulnerable to XSS, go see my proof of concept".
  Well, worked for you, didn't it?
I'm a nice kinda guy, so I opted for the last option. Open, honest, polite.
Next, send the victim (you) to the vulnerable application (plans.cgi) on the target site (www.planscalendar.com), with some cleverly-crafted arguments. This is typically quite a long URL. There are several ways to do that too...
- Skip step 1 and get you to go directly to the long URL. Risky, as you might spot what Nasty Hacker was doing.
- HTTP Redirect. If I had done this, your cookies would ALREADY HAVE BEEN STOLEN. Nasty.
- Javascript redirect. As above. nasty.
- Meta redirect. As above. nasty.
- 0,* frameset. Similarly, your cookies would already be stolen. nasty.
- 1x1 / hidden iframe. Again, already stolen. nasty.
- Trick you into clicking another link, submitting a form, or similar. Possibly reasonably well disguised, but relies on you being foolish to click on a second link.
- Politely ask you to follow the link to the long URL and hope you're still gullible enough to do so.
Again, I'm a nice kinda guy, so I'm going to go for the last one.
Vulnerable app on target site runs. Displays carefully-crafted arguments in unsafe way. Usually this means javascript. This basically means you run Nasty Hacker's javascript, but runs it as if it had come from the target site. It thus has all sorts of access to info on/about that target site which normally wouldn't be possible. USUALLY (including in this example) this is about cookie-stealing.
Javascript collects interesting info from target site's security context (usually cookies, sometimes form fields, content) and submits it back to Nasty Hacker's site. There are several ways to do this too...
- redirect back to Hacker's site
- 0,* frameset, 1x1 iframe, etc etc
- form submission
- load an image from Hacker's site
I'll go with one of the types of redirect, mostly just because it's easiest.
Collect all the cookies / other info for the site. These might contain:
- Usernames
- Passwords for badly written web apps
- Maybe email addresses, if you've registered
- Most common of all: session cookies
These session cookies allow you to continue using a web app (EG forum, webmail, shopping cart, online banking) without having to keep typing your username and password for every operation... Thus...
Having stolen a copy of your cookies, this now also means that Nasty Hacker can probably "continue" to use the victim's accounts on the vulnerable site's forum / webmail / shopping cart / etc. Maybe change your delivery address, keep the same credit card, order a few items, change the delivery address back, maybe post as you on the forums, maybe read your webmail, depends what else is on the target domain.

FAQ

So what cookies does this demo steal?
All your planscalendar.com cookies. That's PROBABLY just your preferences for the demo, the wiki, and the session ID for the forums, assuming you've used any of them. If you're a forum admin, I might be able to pinch your admin rights. If you've never used the demo, the wiki, or the forum, it might not get any cookies at all. As far as I know, planscalendar.com doesn't have an online store or webmail or anything outrageously secure on it.
Will you show me what you steal?
Yup. If I was a really nasty guy, I wouldn't, I'd just send you to a fake error page or something after I'd copied everything I wanted.
So what COULD you steal?
Google tells me there are "about 2,130" instances of Plans out there. I could steal all your cookies from any of those sites. That MIGHT include webmail accounts, shopping carts, etc etc. If your ISP has plans.cgi on the same domain as your webmail / control panel / shop, you should probably ask them to move it to a different domain.
What can you NOT do?
I'm not gaining access to your machine, I'm not gaining access to files on planscalendar.com or making the server run my code, I'm getting access to whatever YOU have access to on planscalendar.com, which (for the purposes of this proof-of-concept) probably just means I can pretend to be you on the forum. If you're a forum admin, I might be able to pinch your rights.

I can't steal cookies from other domains, only domains that have plans.cgi on (well, unless I find one of the multitude of other vulnerable web apps)
So are you keeping a copy of my cookies?
Not deliberately, but they almost certainly appear in my web logs, and if I wanted to extract them, I could.
Are you a Nasty Hacker?
No
Are you going to hijack my sessions?
No
Are you going to borrow my forum login?
No
Are you going to borrow my shopping cart?
No. Does planscalendar.com even have an online store?
But I have to take your word for it?
Unfortunately, Yes
How can I trust you?
I could give you my word as a Spaniard
No good. I've known too many Spaniards.
But seriously?
I could give you my word as an Englishman, which isn't much better, but no, seriously, how can you trust me? If I'd REALLY wanted to steal your cookies, I could have done so in a far more sneaky way, probably without you even knowing, and I hope the description above makes that clear. I've been up-front, I've warned you about the risks. If you still choose to give me a copy of your planscalendar.com cookies, I COULD abuse them, but honestly, I've got better things to do.
So should I avoid installing Plans?
No, it's a very fine app. Unfortunately it allows Nasty Hackers to borrow cookies from any site where Plans is installed. I'd therefore have to recommend you don't install Plans on any site which relies on the security of any other part of the site, so don't share a site with webmail, shopping carts, secure logins, online banking, etc. Put plans on a different domain. You should also definitely avoid the "choose_themes" option. It's definitely not the only XSS attack on plans.cgi, but it's the most trivial to abuse
You hate Plans, don't you?
No, I think it's a marvellous little web app, top notch usability, easy install, easy configurability, looks great, works great, splendid features. I use it myself, I just hide it behind a bit more security for the moment. If I hated it, I'd be running a different web calendar, and probably be putting more effort into securing that one instead.
So if you're so clever, why don't you fix it instead of proving you can break it?
I'll probably do both, but if I just fixed it, most people wouldn't realise the importance of updating it.
So how do I fix it?
There needs to be a fair bit more argument checking in plans.cgi. theme_url is definitely not the only argument that needs checking. Using perl's "taint mode" might help, but the program will probably be completely unusable until every little detail is fixed. Oh, and "perl -w" and "use strict" are usually well worth the pain too, but that's a different issue.
Does the author know you're doing this?
I dropped Lloyd an email describing my concerns, and he said:
Nick,

You're correct. The $theme_url parameter dates back to before it was possible to set each calendar's theme (and before I understood cross-site scripting attacks).

It needs to be either removed or heavily validated. I'm not sure if validation is possible, since even checking for the same domain as the calendar might not always work. I will probably remove it completely.

Thanks for the note. You should definitely post it to the forum. Hopefully it will get more folks thinking about security concerns.

- Lloyd
I told him I'd do so after I'd put together a proof-of-concept. I hope he doesn't mind how I've done the proof-of-concept. If he asks me to remove it, I'll gladly do so. In the meantime I am posting to the forums to get you folks thinking about security concerns :-)
So how is plans vulnerable?
At first, and when I wrote to Lloyd, I thought that ?theme_url=http://hacker_domain/bad_theme/ was a gaping hole. It allows you to load themes from other sites. Turns out it's not enabled in the default config though, so probably very few of those "about 2,130" installations use it. Those that do though, go straight to http://hacker_domain/bad_theme/plans.css and can be easily made to go straight to color_select.js too - bonus! Easy place to put my dodgy JavaScript :-)

This is the method I've used for the proof of concept. This method will NOT exploit (m)any other plans.cgi installations because "choose_themes" isn't USUALLY enabled. There are other parameters that can be abused though, probably on every single one of those "about 2,130", and yes, I've proved that some other args can be abused, this is no idle threat.

I chose the theme_url method because it's easiest to demonstrate against the main site without giving away a complete cookbook to break into every other plans.cgi on the net - "only" ones that have choose_themes enabled, which I hope is very few. Google says "about 34" and most of those seem to be misleading.
Have you really posted it to the forum? I can't find it!
Yup, here.

Go on then, show me

This is your last warning. Clicking on the link below will take you very briefly to http://www.planscalendar.com/demo/, where it will convince plans.cgi to point you at my javascript. My javascript will copy your planscalendar.com cookies and return here, where it will display your cookies for you.

Remember, if I was a really nasty guy, I wouldn't have given you all these warnings, your cookies would already have been stolen and you may never have even realised it. I could have been A LOT sneakier about this if I was feeling malicious.

Still here? OK, go for it, Show me my cookies