So Microsoft and Apple are sparing over a flaw in Safari. The flaw allows drive by downloads of files onto a user’s desktop from a malicious website. Apple is calling it a feature request for a convenience functionality or some such BS, because apparently they don’t think a third party being able to force files onto a user’s computer is a big deal. Microsoft very much disagrees, seeing it as a great way to deliver malware. It happens to be just that, but that would require a two stage attack (you do need to get it to execute) which is why Apple doesn’t care (in general I think it obvious that Apple doesn’t care about security).

Ah, that is an unimaginative attack though. If one is interested in harm to individuals it can be used by itself to cause trouble. Say some attacker happen to hate the smugness of safari users and want to get them in some legal hotwater. They control an offshore webserver and dump a bunch of kiddyporn.rar files in a publically accessible directory. They name will get it flagged by Google immediately, who will turn it over to the FBI (both google and MS routinely do so) for monitoring. The FBI can’t do anything about it being overseas but they can watch all US traffic that hits it so they can track down pedophiles domestically. The use of a .rar file was to make sure it was something that typically doesn’t have a mime handler associated with it, but is commonly used to distribute archives of data among warez sites and the such, so that safari would automatically download it. The attacker also posts a small web page with exploit code on it to trigger downloads in safari. They then go to a bunch of apple specific sites that allow community feedback and exploiting one of the myriad of XSS vulnerabilities likely to be on the site they inject a CSRF attack that sends a fraction of the visitors (so as to not send an abnormally high amount that would trigger the FBI’s scrutiny) invisibly to the exploit site.

Now the FBI has a whole host of people to start investigating, and even if the person is ultimately exonerated, it is going to cause them some headache. Granted this whole scheme is pretty convoluted and far fetched, and would need to be executed exceptionally well, but I use it to show that the execution of malware is not the sole concern here. Simply receiving data you did not request can be dangerous, and that makes this a vulnerability.

Also, any decent SDL would have caught this vulnerability quite a while ago, as it appears that it is by design. Hey Apple, maybe you might want to start embracing the message you put across in those ridiculous commercials.

~ Joshbw

Yes, its true, web applications scare the hell out of me.  Back in the grand old days of remotely exploiting rich client apps the attack of choice was buffer overflow (ignoring retarded macro attacks, for which the design was just ineptly flawed).  Sure, there were others, but at the time you could pretty much count on any given app having some unchecked buffer copy.  Today that is largely a solved problem, with static analysis tools being pretty damn good at finding such flaws.  Coupled with decent banned API rules, buffer overflows should be a solved problem, like small pox (don’t tell Apple or Adobe that though, they might actually get around to catch up with the rest of the world).  I find it laughable when a buffer overflow is found in modern software.

The thing is though, exploiting buffer overflows wasn’t trivial (well, pre-metasploit).  It actually required that a person have a decent understanding of how memory worked (so your average scripter or java developer was out in the cold) in order to craft an attack.

With web applications, the two vulnerabilities of choice are XSS and SQL Injection.  SQL Injection is pathetically simple to protect against and yet is horribly prevelent.  On a US UTF-8 only website that doesn’t need to accept HTML, XSS is also very easy to protect against (unfortunately it quickly gets complex when you internationalize, or decide to accept HTML).  These attacks are often disgustingly simple, but work well.

That concerns me a great deal, but a well designed website can put up a decent defense.  That isn’t what really scares me.  It is the fact that many of these web applications store very sensitive data, anything ranging from PII, to one’s entire collection of documents.  It isn’t just that the attacks are so simple, but that the payoff (or cost depending on which side of the coin you are on) is so large.

So enter something like Google, which wants to store your emails, health records, personal documents and files, payment information, and everything else you might value.  It takes one tiny little flaw and all of that is exposed.  It takes one well put together phishing site, and it is all exposed.

What keeps me awake at night is knowing how much there is to lose from one tiny little mistake.  What scares the hell out of me is how much data is stored, how sensitive it is, and how easy it is to find vulnerabilities and exploit.  For crying out loud, bots are doing SQL Injection attacks as we speak.

(what also scares me is that many people actually think HTML and Javascript in a browser creates a compelling competitor to rich client apps.  It will be a cold day in hell when a web app can provide even a marginally compelling experience versus the likes of Office.  Even flash and silverlight are poor replacements.  Adobe is high as a bloody kite if they think that an AIR version of Photoshop is a remotely good idea)

~ Joshbw

Reading a lot of Bruce Schneier recently, and his excellent take on the security mindset, as well as working on a full security development lifecycle at work that is focused on getting security into each stage of the application, I have security mindset on the, er, mind.  Bruce phrases it much better than me, but I think the security mindset is being able to see a scenario or situation and enumerate the potential mischief that could be enabled there.

So I see that Northwest is planning to try out paperless e-tickets using PDAs and similar smart devices.  Essentially the screen displays a version of the ticket to the screen and that gets scanned.  I already think that the current print your own ticket is ripe for abuse (for example, it wouldn’t be hard for me to make a fake ticket that got me through the ticket-required TSA checkpoint), but my mischievous little mind is already at work when going over scenarios that a dynamic screen that I control could present.  As an exercise for the reader, to flex that security mindset, what can go wrong here?

~ Joshbw

Seriously, the webappsec community is abuzz with the new PCI requirements that allow either code review or application firewalls, and there are people out there debating the merits of both, as if it is a competition.  Are WAFs a band-aid?  Of course they can be, to compensate for crappy input validation, but even if one’s input validation is perfect and protects against all known attacks today having an added layer of defense isn’t likely going to hurt a great deal (though specific situations can cause issues), and is quicker to update when new attacks are developed.  Also, your input validation isn’t perfect.  Even your whitelist input validation isn’t perfect.  It is probably “good enough”, but it isn’t perfect.

Are WAFs a replacement for code review- not ever.  A WAF sucks at finding back doors or easter eggs, or finding pages that *should* have an authorization check at the top but don’t, or a myriad of other issues that can still be used right through the firewall.  Code review will find those things, even if it is a very inefficient and ineffective way of tracking down vulnerabilities in general. 

In truth, none of this is sufficient, but PCI isn’t really about securing customer data, at least the way it is written, but rather a way to avoid liability.  It is a minimum number of steps to say “look, we tried to do something”.  The fact that “Private Networks” are considered secure and data can be sent in the clear over them (even though less than 30% of successful attacks actually come from external networks) shows that it isn’t really concerned with really protecting payment card information.

For companies that want to meet the minimum requirements for PCI, the only question is which solution is cheapest and easiest.  For companies that actually care about protecting their customer’s sensitive information, the question shouldn’t be which to do, but what additionally can be done.  Neither of these solutions are sufficient to ensure that data is protected by themselves.  The first requirement to protect customer data is to get upper management to care, then to put security standards in place, a secure development lifecylce in place, and educate developers on the threats they face and the protections they should employ.

An ideal solution shouldn’t just have a code review, but a feature review when the feature is proposed (with security requirements included), a risk analysis and mitigation strategy during the architecure planning, threat modeling and detail design security review, code review, and both security control testing and pentesting both with and without a WAF, so that if the WAF fails the application is still strong.

That is what PCI should be.  Yes, it is a huge burden on development teams and companies that don’t do those things already, but at the same time, ask yourself if you would trust a company that did the current bare minimum to meet PCI as it stands now with your card information.  I sure don’t, which is why I am glad that my bank now offers onetime card numbers and more and more sites accept paypal. 

~ Joshbw

Well, this is pretty much by design, but poses a risk anyway.  The remote connect in Live Mesh is not RDP, it is a glorified VNC, which makes sense considering that the feature should work in more than XP Pro, and Vista Enterprise and Ultimate, the only Windows clients with RDP.  It would be far superior if it was actually RDP though (hey MS, here is an idea, if the system has RDP enabled, use that instead).

RDP has a nifty and well thought out feature.  When I remotely connect to a computer the local session goes to the locked screen and remains there.  That way people near the remote machine do not see what the remote user is doing, and if the machine was already locked remotely connecting does not unlock it.  With the VNC like bastardization this is not the situation.  The remote session is simply sending key and mouse interrupts and getting a screen grab, nothing anywhere near as fancy as what RDP does.  The result is that when someone remotely connects, anyone near the local machine now also have access and can see everything the remote user is doing.  The remote connection opens the local machine up to access.

Microsoft may have weighed the risks of this and gone ahead anyway.  Host machines are likely to be at home, where the user doesn’t necessarily worry about people seeing what is happening, either because no one should be there to begin with or because they trust anyone who conceivably should be.  Users interacting with the local instance would be apparent to a remote user, as all screen activity is mirrored.  And the computer is locked once the user logs off.

People who live with roommates may not be comfortable with this, especially college kids who may not particularly trust their roommates.  Plenty of users will be remotely logged in, but not actually active (for example, out to lunch without terminating the connection, though I haven’t tested for a timeout), so they may not detect local activity, and other such scenarios. 

Honestly, I can’t think of a great fix given the current implementation.  The client/server is very simple in design and probably can’t keep the OS locked locally without OS changes.  As a possible workaround, I would suggest that if the machine supported RDP Microsoft should instead use that for the connection, offering both a superior user experience and a more secure one.  Additionally, I would posit that people using XP Pro, or either Vista version, represent a different customer segment than typical non-RDP machines, and potentially are in environments that should have tighter controls (for example, business machines where the user is trying to circumvent remote access policies through an easier means, on a poorly configured network that allows them to do so).  Ideally these machines would have policies or network controls preventing such easy access, but the ideal world and the real one are rarely one in the same.

I have to wonder how discoverable this VNC like session will be via google dorks.  It is over port 80, and there are already dorks to find VNC machines.

~ Joshbw

GNUCITIZEN has an article on Live Mesh up, a product I have been thinking about as well.  Some folks like Joel Spolsky seem to think it is a failed idea to begin with, but from a user standpoint I have been hoping for a seamless means of synchronizing data easily across many devices, which is exactly what Live Mesh ultimately hopes to do.  I have used several solutions in the past, everything from the SyncXP/SyncVista power tools, to custom scripts that first synchronized to xdrive and then skydrive.  All of the solutions sucked for various reasons, and from my experience with Live Mesh, many of the things I have hated in previous solutions have been mitigated.

There are multitudes of security concerns with the product though, but I think GNUCITIZEN misses many of these:

1) It is based on Microsoft Live ID. This means that if someone hacks into your WebMail they essentially hack into your network as well. Cross-site Scripting attacks does not look that harmless now, do they? That messages is intended for all haters.

2) It works form the browser using SilverLight. This means that everything is accessible via the reach GUI environment of .NET. Sweet! Files, documents, etc.

3)It uses HTTP enhanced RDP to provide remote desktop connectivity. As the video on Channel 10 suggest, It bypasses the firewall! Now this is interesting. I wonder how my RDP shell injection attack will work here.

I think these three things are blown WAY out of proportion.  Point 1) seems to not understand how Live ID works.  It is really a glorified token granting service similar to kerberos.  It does not grant a unified sessionID that would allow the whole federation to be compromised by stealing the session out of the cookie (the cross domain restrictions on cookies would be an issue that would prevent a third party session ID from working to begin with).  Compromising one website to steal the LiveID token would not translate into compromising all LiveID websites.  In terms of XSS, Live Mesh has a very limited attack surface, so it is probably going to be quite difficult to get its specific LiveID token for a user.  

Now I think single sign-on is a really bad idea in general anyway, but not because to the fear of stealing sessions.  It puts all eggs in one basket- if the credentials are ever compromised then the user is screwed.   Phishing is my great fear with SSO attempts, though CSRF is also quite worrisome (as the chance that the user is logged in increases).  Having played around with Office Live quite a bit, MS seems to be expiring sessions fairly often to mitigate CSRF though.

I don’t understand point 2).  Yeah, the experience is much richer, but it is also sandboxed a great deal more than something all ajax-ified.  By this I don’t mean sandboxed from the system, but rather from the browser.  It puts a logical boundary between the application and the browser.  From a user experience standpoint this isn’t always great, since it presents the experience of another application that just happens to be open in the browser tab, rather than an application integrated with the browser functionality (which is why I HATE 90% of flash sites).  From a security standpoint, assuming no vulnerabilities in this boundary, the application is more protected from typical DOM focused attacks. 

Point 3) isn’t a new issue.  RDP already has firewall exceptions in its current state, it doesn’t really matter that it is going over port 80 rather than 3389, other than the traffic may not be as heavily scrutinized as it would otherwise be.

So those issues aren’t what bothers me a great deal.  They could be vulnerable, but I think that is less likely than with traditional web apps rather than more.  What bothers me is that the attack surface for this thing is HUGE for a consumer.  Every synchronized client, as well the website, are potential attack points.  The threat model must be crazy.  Moreover, the setup is a great way to propagate viruses (infect one file, have it auto-synchronize) to all of a user’s machines (and potentially smart devices), and while MS likely scans files for malware it necessarily has to be signature based (Skydrive and Office Live both do I believe, so that neither service can be used to distribute malware).  Signature based scans, like all blacklists, sucks.  So I think there are a lot of concerns with the product, things researchers should look into, but traditional web application attacks aren’t the most glaring worries in my mind.

~ Joshbw

Jeff Atwood of Coding Horror posted a flawed article on why session expiration is bad.  The gist of his article is that it presents poor user experience which should trump the security concerns.  I will not deny that the user experience with session expiration is less than ideal, the whole idea of sessions to begin with is an ugly hack to get around the fact that HTTP is stateless and that the best end user authentication scheme that we have come up with is a login screen with easily stolen personal credentials.  Until a better scheme is brought up, which will be no small thing, it is something that we just have to live with.

That is not to say that the user experience can’t be improved.  Saving a session state, so that when the user is forced to authenticate again they don’t lose progress, is imminently doable and would improve the experience when sessions expire.  Getting rid of session expiration entirely is a horrible idea though.  Jeff seems to think that the risk of persistent sessions is someone sniffing the sessionID over the wire and that SSL/TLS completely mitigates that.  To me that is a low concern (sensitive data should always go over an encrypted channel, but network sniffing is rarely efficient anywhere outside of an intranet), relative to the threat of CSRF, cross site script attacks against the cookie storing the sessionID, and if the HTML 5 working group gets their way, XMLHttpRequest going across domains and passing cookies (fortunately it seems both FireFox 3 and IE 8 are inclined not to do so- take that Opera).  Regardless of how long the session is valid there is some risk from these attacks, but having persistent cookies extends the length of exposure after the sessionID has been compromised.

With the widespread presence of cross site scripting and the relative lack of protection against CSRF these are very really security concerns that are highly likely to be present on most websites.  If neither were present it would be safer to have longer sessions, but I think it would be naive to assume their absence.  Defense in Depth is a mantra for a reason.  Yeah, it sucks for the user somewhat, but erring on the side of usability is a Windows 98 style mistake.

What bothers me about Jeff’s post isn’t that a developer feels that way, sadly that is pretty common, but that a fairly competent developer with a large readership is evangelizing an unsafe practice.  It is, in effect, the same thing as Joel Spolsky of JoelOnSoftware fame advocating the avoidance of Exception Handling.  It is a bad practice and it concerns me that someone with such high visibility would actively be promoting it.  I think it also illustrates how security ignorant developers really are, when even such senior individuals don’t understand how bad a suggestion really is.  I could be wrong though, Jeff may understand- many of his past points stress usability and he could be of the mindset that usability trumps all other concerns (it is important, but it is one of many considerations that must be weighed).

~ Joshbw

My coworkers and I were just BSing about CAPTCHAs and how to make them harder to crack while still usable.  Tangentially the conversation just previously was about the bastards that injected a highly animated flash file on an epilepsy forum (which is messed up), and my mind drew a random connection between the two.

I wonder how hard it would be for automation to break an animated CAPTCHA, for example a small flash file that loads the text dynamically from the server (so there isn’t even the overhead of generated a dynamic CAPTCHA image) and slowly scrolls the text across, never showing all of the CAPTCHA text at once (though immediately a concern is the text could be intercepted in transit; it might be better to dynamically create animated GIFs on the server).  The implementation for this obviously needs to be much more complicated than that simple description; it has to cover attempts to compromise the CAPTCHA system without needing to do image processing.  However, if the attacker was forced to do image processing, how much of a speed bump would the animation create?

Any image processing gurus happen to know?

~ Joshbw

Two posts in a day, I’m on a roll (well not really; most posts I complete the night before and read over again during the day, before publishing, when I am lucid and not splitting attention between what I am writing, an attention hungry five year old, my wife, and an affection demanding but otherwise clueless cat. This is one of the few posts I am actually composing while at work before I forget about it). Anyway, having just finished complaining to my coworkers about yet one more site that seems to be using stupid security questions for their forgot password functionality (not one of our company sites, we have pretty strict security standards regarding when questions are even acceptable and how they are implemented, generally stricter than this post pleads for) I feel the need to share some advice with the random folks that occasionally stumble in here.

There are several things to keep in mind when creating security questions, but mostly they should be easy for the customer to remember the answer to (and please use a tolower call on both the provided and stored answer before comparing people, I don’t want to remember which case I used) and very hard for an attacker to figure out.  The number of websites that don’t get this right are staggering.

To start with the last criteria first, security questions should be hard for most attackers (I say most because if a close friend/family member is the attacker there aren’t very many questions that would meet the first criteria that the attacker either wouldn’t know or couldn’t find out).  This means the question shouldn’t have a very limited possible answer set.  “What is your favorite color?”- well lets try blue (apparently the color most likely to be a favorite in America.  Good branding job democrats), red, black, pink, green, purple, grey and orange.  We could go further in depth, but those are the most prefered colors in the US (I have no idea if it is a cultural thing, or if by extension the rest of the world shares a similar ordering) and cover the majority of the population.  That can be brute forced very easily.  Likewise questions along the lines of “How old were you when…”, “What grade were you in when…”, “What is your favorite movie genre” and so forth all easily brute forced because most people’s answers fall into a predictable and small set.  Questions like these lend themselves very well to automated attacks hunting for credentials.

Questions that are easily publicly discoverable are also a bad idea even if they otherwise have a much larger brute force dictionary.  Questions about a person’s family (father’s middle name, mother’s middle name, etc) can easily be discerned through the various family tree websites.  Questions that could easily be gleaned off of a person’s myspace/facebook/whatever page are also a bad idea since most users of these sites use their real names and are easily found doing a google (or yahoo or live if you swing that way) search.  Most profiles on social sites list favorite band, book, tv show, etc, but also things like high schools and colleges.  Using questions that are easily publicly accessible makes it easy for attackers to compromise the system with nothing more than google searching for details about a known user (they don’t work great for blind attacks though).

As for the other criteria, that the answer should be easy for the user to remember, this acts more as a constraint for how esoteric a question can get (if they have to think about the answer when filling out the field initially, they probably won’t recall what they said when prompted) than as a genuine security concern.  If the user can’t consistently answer their own security questions the feature is pretty pointless.  One of the things to keep in mind is that even general easy to come up with answers can eventually become hard to remember.  Current “favorite whatever” questions are susceptible to the user changing their mind.  For example, a person’s favorite television show tends to change over time, and they shouldn’t be forced to recall what their favorite whatever at the time they signed up for an account.

So what are good security questions?  Here are a couple I have seen and liked:

• Who was your best friend in kindergarten?
• Who was your first significant other (though not so great for people who married their first SO)?
• Where did you and your current SO go on your first date?
• What was the name of your first pet (I actually like when this is more specific to cat or dog, since many people had both simultaneously; it is easier to recall the answer)?
• What did your mom/dad do for a living when you were born?

Not all of these questions apply to everyone but they have the benefit of being fairly hard for a stranger to discover without being overly hard for the person to remember.  As mentioned though, they will not apply to everyone, which is why the user should be presented with a list of secret questions and are allowed to pick a subset for their own security questions.  The list should be broad enough that everyone should be able to find a couple applicable questions.

Venturing further there are other ways to improve the forgot password functionality, such as requiring a user to answer multiple secret questions to further mitigate against data mined attacks.  Ultimately such questions will still likely be susceptible to attacks by close acquaintances and disgruntled family so developers need to weigh the risks and business requirements when deciding how strict to be with the functionality.

So please various web developers, stop using weak questions, and please for the love of whatever you hold dear, don’t display the password to the screen or allow a new password to immediately be set after the questions were answered.  Emailing existing passwords is also not a great idea.  Setting a new random temporary password (by temporary I mean with a timeout as short as possibly can be acceptable by your application sensitivity and business cases) that gets emailed and requires the user to change on first login is probably a good practice.  For very sensitive applications the widespread “forgot password->secret question” paradigm might not even be strong enough, nor am I advocating this paradigm over another.  I am simply asking that if it is what a web developer chooses that they can take some steps to make it less vulnerable than I typically see.

~ Joshbw