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