Secure Software

So you've spent weeks, if not months, producing a nice shiny piece of new software for folks. You've gone to great lengths to work with others to make sure it's as secure as you can make it. You've got all kinds of validation, sanity checking, path checking, and other things included in your code. Everything seems to have paid off. Your package has been on the web for months, and nobody has reported a problem despite it being used in at least a few popular locations. Every attempt you've witnessed on your own sites indicates people out there are trying, but getting nowhere aside from one or two random incidents which you promptly patched up. The efforts have paid off so well that not even the usual flood of spambots that plagues other sites is affecting yours. At least until you discover a web posting with an ominous claim:

Secunia Research has discovered a vulnerability in ---------------, which can be exploited by malicious people to conduct cross-site request forgery attacks.

The application allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to e.g. execute arbitrary SQL queries by tricking a logged in administrator into visiting a malicious web site.


Yes, in case anyone is wondering, that's an actual advisory report for something I'm a part of. Or at least I'm a part of apps which are based on it. Do your own digging if you want the actual name, because aside from that lovely vague advisory, Secunia hasn't bothered to explain what it means. They didn't even bother to send that notice in the mail. They sent me an email a couple of weeks back saying they found a vulnerability. First off, the email they sent got dragged into my spam folder by Thunderbird. Secondly, after I dug it out, it was dated the same day as a previous advisory I had already cleared up in two products based on this, so I had no real reason to assume it was for anything other than that.

I don't know exactly how "responsible disclosure" is supposed to work, but the only email they sent privately looks like this:

Secunia Research has identified some security issues in the --------- and ------------ projects. Please contact us via vuln@secunia.com to receive further information.


That's hardly enough information to go on. I'm sure I really should be telling them this but I'm not feeling that charitable toward how they handled this right now. So they can consider this an open letter to work on their policy of informing project maintainers of issues in their software. Being blindsided by it because you ran into it in the public advisory posting doesn't really sit well. They'll probably make some sort of excuse about how I shouldn't have ignored them, but really, a too vague notification on the heels of having fixed an advisory already?

So anyway, as it turns out, there are 3 advisories pending. Two of which shouldn't be terribly difficult to patch up since they were specific enough to address. This last one though, with the vague XSS business, I can't do anything about that unless I know where to look. As many of you who visit regularly are developers yourselves, I'm sure you can appreciate the need for good bug reporting. Their advisory posting even indicates they only gave whoever they claim to have talked to 5 days after getting a response back.

I guess the point is, be clear about what you're contacting someone about. Give them the courtesy of a proper incident report. And for the love of God, give them more than 5 days to do something about it!

Also, it would seem they haven't followed their own damn policy on this either: http://secunia.com/research/policy/
.........................
RIP United States of America

July 1776 - November 2012.

       
« Nerd Test
Stand Before the American People »

Posted on Mar 19, 2010 12:02 am by Samson in: | 26 comment(s) [Closed]
Comments
First, as a point of an ongoing Sandbox concern, was the email address included in the email tags within the second quote up there not supposed to be a link rather than an email address between two bbcode tags within the quote? Perhaps nested bbcodes still do have an issue afterall? :(

Nice policy, bet you'd have noticed it if they'd sent you all the notices they indicate they're supposed to...

Nice helpful solution too:
Do not browse untrusted sites or follow untrusted links while being logged-in to the application.

And that's for the one that you quoted in the first quote up there. Probably good advice whether you're logged into one of those particular applications or not, but hardly a useful solution. :(

Frankly, for the other one currently still listed, I wouldn't consider:
Do not use the database backup functionality. Restrict access to existing backup files.

To be an ideal solution either. Perhaps something a bit more like "Change location path where the database backup functionality saves it's backup files and what permissions are given to it and use a less predictable naming schema for those backup files. Also change permissions for existing backup files and relocate them to non-web accessible location" would have been a more useful "Solution" to have offered.

I guess the third pending advisory isn't public yet because I couldn't find it on their site, but I definitely see what you mean about their advisories leaving a bit to be desired.

       
Yes, that email was supposed to be a link. I see why it didn't get converted too. Easy enough to deal with. Not important enough to hotfix another package over it. It'll hit subversion shortly - which you can see on the Google gadget I put on the Sandbox page :)

You bet I would have noticed if they'd followed that policy. May as well examine it point by point:

Item 1: Lets be generous and assume the email in my spam folder fits this. Since they didn't know who to contact, they guessed (correctly) that I was it.

Item 2: I'm still waiting for an email with the "vulnerability details" and the "preset disclosure date". We'll call this a failure.

Item 3: There were no resent emails. So another failure.

Item 4: They appear to have used this as their exit point, after not bothering to adhere to item #2 and 3.

By default, items 5 though 10 automatically fail since they did not bother with any further communication attempts. I guess I don't have enough money to fight back like Microsoft, IBM or Adobe who all have much older vulnerabilities listed in 2010 and in 2009 which have not been disclosed. A conspiratorial mind might make the leap that they're biased in favor of those 3 companies for some reason. Even Google has plenty that were listed, so I guess it's not about money to fight. Perhaps they don't like Google?

By the time I did get to respond back, the only reply I got was basically a "too late, we disclosed it". No attempt to explain the issue in any sort of usable detail. So now I guess I get to wait for it to show up somewhere like milw0rm.

       
Yeah, I saw that too when I was looking at their policy. It's really rediculous, but I also noticed that they seemed nearly merciless towards most of the products/companies they listed, isn't it nice that they were flexible about releasing issues they'd discovered for select software from only certain companies. :(

On the positive side, the one (of the two already disclosed) was vague enough that someone would have to download a copy of the package for themselves to see what backup file naming scheme to "guess" at, but their description of the problem at least gives enough info to see what you probably need to do to fix it. It's almost too bad they weren't that clear on the other one, but perhaps they felt, despite what they rated it as, that it was the more critical issue of the two.

       
Well, this posting got their attention. For good or bad, that was the hope. I've received a response back from the original guy who's mail ended up in the spam folder. Followed shortly after by an email from their chief security specialist who was clearly not happy to read what was posted here. He's insisting they followed their procedure to the letter, but I insist they did not and that the disclosure was the only other notification of any kind I got. Maybe they'll take my suggestion to heart about being less vague about the issues they're contacting someone about, even if it is through a web form.

The vague vulnerability notice covering the cross-site request forgery issue is pretty big actually. I did some quick research into it last night and it won't be something that's easy to fix. I'd never even heard of the particular attack before. The specialist sent me two short example HTML snippets that can trigger the issue and it's definitely a problem.

Given that I'm not a professional at this I read over the solutions listed and am really not sure of the specifics of how to address it. I get that there's some extra randomized values that will need to be passed back and forth to reduce the risk but it really looked as though there's no way to ever be 100% bullet-proof. It's going to take a while before I can even come up with something, because what looked like the easy way out depends too much on browsers and firewalls cooperating.

       
For anyone who happens by, reads this rant, and goes WTFHELPME! trot on over here: http://shiflett.org/articles/cross-site-request-forgeries

Looks like good info on how to prevent CSRF attacks. Seems so simple too, you'd figure more people would know about this.

Also... on the subject of Secunia's policy. I found this interesting: http://blog.mozilla.com/security/2010/02/22/secunia-advisory-sa38608/ Seems I'm not the only one to have been blindsided by a vulnerability report that wasn't properly handled.

       
Edited by Samson on Mar 20, 2010 1:00 am
Well, at least you got their attention then, though it sounds like you've got another group of very defensive people who are much more concerned about the reputation of their policy following than your actual security issues that they've discovered. :(

So, were they at least able to give you a bit more info about the issue itself now that they're talking to you again or are we still dealing with "you've got an issue that you really need to fix, but you're going to have to guess at what it really is..."?

Um, okay, after reading the article you linked there by Chris Shiflett, I have to ask, do you already know which parts of the php for these projects are potentially being impacted by this? Because it seems to me that you'd either have to have that information or start issuing authenticated session tokens for each user or issue an authenticated token for each place the projects use get/request/put/etc calls which could potentially be an awful lot of extra tokens to keep track of. (I also fully see what you mean about not being able to get it down to 100% bullet-proof, btw, but hopefully Secunia at least let you know where their specific concerns are with regard to the CSRF issue.)

       
Yes, the original researcher (who btw is a nice enough guy) gave me two examples of where this is a problem. In general it's going to mean just about everything in the ACP for the affected apps needs to have this level of protection added. It's also not as bad as it seems to fix. I've created two functions. One to generate a token, one to verify a token.

When generating the token, the value is attached to the $_SESSION array along with the timestamp for when it was created. The token value is then sent with the form to the browser. When the user submits the result, the token value returns back and is compared to the original. If it's older than 30 minutes (I picked that) then the form submission is rejected and the user will be told the token was either invalid or expired.

The $_SESSION tokens are independent of the general login cookie, so you can remain logged in to the site long after your token for whatever form it is expires. I figured 30 minutes was long enough to be convenient without getting ridiculous.

Out of curiosity, I installed Wordpress and checked their forms. They're using the same type of system, only from what I gather their tokens are all valid for up to 24hrs, which IMO seems rather high, but it might not be that big of a problem since an attacking website has to know what the token value is, and that's just not mathematically probable.

       
I was really hoping that you didn't go with the 5 minutes Mr. Shiflett suggested since I could easily see one of the forms in question being html template editing. I could just picture trying to make a significant change and getting everything the way you want it only to be told your changes were discarded because it took you more than five minutes to make them. :lol:

I agree that, given the nature of the actual issue, the token should definitely be independent of the general login cookie. Personally, I'm still not 100% clear on why an attacker couldn't intercept the token cookie, but I'll accept that it's just that I don't fully understand the nuances of this particular type of attack.

I must say I'm a little surprised that Wordpress issues such a token for 24 hours because that sounds excessive to me too, but as you say, overall, even that should still generally accomplish the task.

       
Session cookie information isn't stored on the client side, other than the session ID itself. So there's nothing to steal other than a session ID and from what I can gather that's much MUCH harder to get ahold of.

Further checking on this indicates that since the token is randomized, the value is stored on the server, and an attacker isn't mathematically likely to guess it, I can probably go with a larger time window on it. I was just thinking about that while trying to post to the Bethesda form and being greeted with a message saying that my security token was not valid. When I checked the HTML source for the form, sure enough, in the quickreply box I was using there was a security token. Invisionboard probably has the time window set too low because I was only in the box for a couple of minutes gathering information for the post. They're a closed-source project though, so I can't dig around to see if there's a setting to recommend Bethesda raise.

So I'm thinking I can safely go with something like 2 hours. If you're in a form that long, something's wrong with you :P

       
Edited by Samson on Mar 20, 2010 5:14 pm
Ah, that makes MUCH more sense then.

Sounds reasonable enough. I think even 30 minutes is probably safe enough or most situations, and two hours should certainly be sufficient for all others. Frankly, if it's taking you more than an hour to type something up, whether a post or a template change, you're best bet would be to copy/paste what you're working with to a notepad and then complete your editing there and finally go back to your original form (re-opened with a fresh token) to copy/paste from your notepad. Under half an hour, I could see just doing it, but if it's really that extensive that it's going to take more than an hour, let alone more than two hours, well...

       
And because the Secunia guys are still nagging me about this post, I bring you yet another example: http://amarok.kde.org/blog/archives/777-Responsible-Disclosure,-and-Amarok-1.4.10.html

Guys, lay off already will you? It seems you have a pattern of irresponsibly disclosing security issues without establishing proper contact with the project developers.

       
Wait, they're still nagging you about this post.. but have they yet provided you with more details regarding the three issues this post started because of?

The Amarok Blog you linked looks like a pretty good blog entry about the matter, btw. Sounds like they had it even worse than you did but it still comes down to the same main issue, these people aren't following their own rules and contacting the software maintainers about the issues they're finding properly.

It's a shame that they're not contacting the project developers more responsibly, if they were they'd be providing a really useful, helpful, and valuable service.

       
Beyond the two examples of how to trigger an incident of CSRF, no, I haven't heard back from them again, other than being nagged about how horrible my post was to them. Which seems a bit lame considering their head research guy tried to jump down my throat about maintaining adequate communication with them. Seems they're not interested in anything more than the publicity their hasty alerts generate for them.

       
Edited by Samson on Mar 21, 2010 5:31 pm
Man, that's a shame. Seriously. :(

       
Well the guy who sent me the two exploit example files finally got back to me to say that the methods I found on Shiflett's website will do the job. So I can get those patches out soon now.

An interesting tidbit about the token thing. I ended up having to remove the captcha system from the new user registration form because it wasn't compatible with PHP 5.3.0 and the updated version was broken too badly for me to fix. Since removing it, I've had 15 failed attempts to register bots. Akismet caught them all, but it's definitely interesting to note that the bots are processing the tokens because it also means they're configured to accept session cookies. Someone on one of these pages had suggested that the token thing would block bots completely because they just fire blind POST requests. Clearly they are not doing that because valid tokens mean they have to be reading the form in real time.

       
Good news! He got back to you on it and confirmed that you'd found the right answer at least. :)

That is interesting, and mildly disturbing as well. But would they really have to be reading the forms in real time to accept session cookies and process security tokens though? Or just reading the forms enough to scan for the need to include a cookie the site had sent?

So, I'm curious, even though they discovered this security issue in the three applications mentioned, since Sandbox wasn't one of the three, does Sandbox already implement some form of security token as such or did they just not review it?

       
Yes, they need to be reading the forms in real-time somehow because the tokens are randomly generated each time the form is loaded. Using an old one would break after 2 hours. So the bots are definitely processing the forms as though you or I were doing it. Unless the hits are actually from real people being paid by someone to spam sites with registration attempts. I guess I should look into getting a new captcha library since it had kept them all at bay for 3 years. Maybe one of those nifty math question things would do the job. That would actually be ridiculously simple to implement.

They just didn't review it and I've spent the last few days adding the CSRF protection to it. I think I've got it all now though. It's a pain in the ass and rather boring but had to be done. Unfortunately I still have to go through QSFP, and it's much larger than PDNS-Admin and Sandbox combined.

       
Edited by Samson on Mar 23, 2010 1:50 pm
Oh, I see what you're meaning by in real time, you mean as opposed to catching it and reading it later. I was thinking in terms of they could be just skimming the forms for cookie requirements and then still just using direct POST requests after "hitting" the form to get the required cookie/token. Well, I think the thing that makes the captcha works is that it's based on visual recognition of an image rather than answering a question in plain text, but I suppose a math question sort of thing is at least a compromise. I suspect that it's not nearly as effective, but it's going to at least help out with the problem by stopping the less complex bots.

I was trying to continue with not actually naming the apps in question under the belief you hadn't wanted to make them known more than necessary, but since you have now, I guess I can too... That does answer both parts of my question though, and it sounds like a very good thing to me. I certainly don't envy you the task of wading through the code for QSFP to add security tokens to every form, but at least having done it for the other packages you already know what you're doing and where to look for places it needs to be added to.

       
It doesn't do any good for them to capture one form and then fire a raw POST at it 3 days later. The token will have expired by then, and the bots are raising the count on these attempts faster than that. So they have to be reading and submitting it immediately, within the two hour time limit, or not actually be bots.

The math thing will probably block the simple ones, and if I randomize enough about it even the smart bots won't be able to readily answer. People shouldn't have a problem because they can cheat and use a calculator.

Not much point in hiding the names now since Secunia jumped the gun on announcing it to the world. It's all over the security vulnerability sites like roaches on rotting food.

       
Yes, but within two hours still isn't necessarily reading it live. And if they capture it and wait three days after analyzing what they need to do with it, they'd have plenty of time to realize that all they'd really have to do it have the bot "hit" the form to generate the token before pushing it's POST attempt.

True enough, though the problem is that if people have to resort to a calculator they probably just won't bother registering most of the time. Captcha is annoying enough already. :(

Ah, fair enough.. it's funny how one mention of roaches and they start showing up everywhere, almost like the real buggers. :lol:

       
Honestly I don't think they're bothering to analyze these things anymore. I think the bots are at a level of sophistication where they can read the form on the fly at the first encounter and process everything right there.

Using the math thing has the advantage that it will be in perfectly readable text and doesn't require external image libraries, which is what killed the captcha form. The image library calls kept breaking. Also, the captcha was difficult to read and even I'd mess up sometimes testing it. Some of the others in use out there now are really awful and I don't want to go down that road.

Anyway, all the updates for the CSRF problem are done, and barring a stupid mistake somewhere, it's all good to go. I've had about enough PHP for awhile, so it's back to the DB mod for me.

       
A bit of a scary thought, isn't it? We've got bots that are sophisticated now enough to read, interpret, and react to data on web sites much faster than a human could and yet still appear close enough to human in their output that one has a hard time saying for sure whether it really was a scripted bot or not. Just the thought makes me wonder a bit about where those bots could lead if the folks developing them decided to branch out into something other than spamming... :shudder:

I can't argue that point, when I signed up for the new mudstandards.org forums today I had re-enter my captcha response because I didn't catch it right the first time myself.

:lol: Well, at least that issue's resolved now then. I guess that means that you won't be interested in the other project that I emailed you about the other day either. ;)

       
Yeah, their captcha is terrible, I took 3 tries to get one I could even see. I bet the bots won't have much trouble though.

As for that other project, check your email. We crossed responses :P

       
Probably not. Given that the bots seem to be able to beat captcha, and we're submitting our responses to the captcha challenge in plain text, I have to assume that there's some way to remove the graphic overlay the the bot developers have figured out and we just haven't.

Yeah, I saw it on my phone this morning but haven't had a chance to respond in regular email yet. (Typing on my blackberry is so not the same as typing even on my laptop...) ;)

       
No, the bots are literally solving the graphic by brute analysis. Most captcha is setup the same way as these security tokens - the correct answer is hidden from view so there's no way to bypass it. It's rather amazing to realize just how much effort spammers put into this.

       
<< prev 1, 2 next >>
Comments Closed
Comments for this entry have been closed.
Anonymous
Register

Forgot Password?

SuMoTuWeThFrSa
 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31