RETURN $ecure;

Security, Technology and Life

Archive for May 2008

PowWeb passwords

with one comment

Just another rant about a remotely possible scenario. Earlier this week I had forgotten the password to the control panel of one of my sites. I went to recover the password and found out to my dismay, that you can use domains to actually change the password. I was curious so I put my domain in. I found out that my password was instantly changed to jibberish. This normally wouldn’t be a huge deal, but this host’s master ftp/sql/etc accounts are based off this same password, so if you used them for anything…they now are totally non-functional until you change your password and the scripts that use it. The password change form declares that I can’t use previous passwords(DO THEY KEEP A LOG!?). So, I can’t simply change it back and have all my stuff working again. That would be a weird DoS, eh? Write a script to automate this process and eat up all of the victims common passwords, while needing them to change a bunch of config files all the time. Sure, they can prevent it from simply creating alternate accounts for ftp and whatnot, but it’s still weird.

Written by Rodney G

05/20/2008 at 9:09 am

Posted in Security

Tagged with , ,

Enabling CSRF

with 3 comments

There was some talk on the WASC mailing list about CSRF recently, specifically with how to defeat tokens/nonce-based defenses. I have wanted to write about this for awhile but haven’t had the time. A quick rundown of the threads; people simply claimed that using XSS and other attacks to perform CSRF was the way to defeat tokens. Which while true, is also not specifically just CSRF. I’m a bit on the line here. I believe CSRF is a totally separate problem from everything else and simple tokens and captcha-like devices(not current image captchas, mind you; as per they blow.) are enough to defend against CSRF.

The real issue are other attack vectors that enable a malicious user to perform CSRF regardless of the tokens. XSS-enabled CSRF is the most common problem in this area. Forcing the user to do an arbitrary action is almost a non-issue to complete since it can be so easy. I mentioned this before during the HackerSafe era on sla.ckers and DarkReading, what matters at the end of the day is total site integrity. ¬†Although you likely won’t ever reach 100% security, every little drop makes a big difference and further compromises the otherwise secure remainder.

On a slightly related note, I do have a few ideas to help — at the least slow down or; stop CSRF abusing worms. A site could implement an IDS-like system that would watch important site features/actions. If the activity of say, the logout button; increases dramatically, then you either have a large loss of user base for some other reason which is an issue into itself or there is a somewhat benign worm annoying your users. Or perhaps for repeatable actions(sending private messages within the site), an ‘impact’-like value that would increase each time it is done in rapid succession. If a user reaches a certain value, they are either spamming and/or propagating a worm and you should at least temporarily block the feature in question while you fix the issue.

Anyways, enough ranting! Keep an eye out. I’ll be releasing some semi-interesting stuff on worm history and future progression with specific regards to propagation and reach.

Written by Rodney G

05/2/2008 at 7:34 pm

Posted in Security