Perhaps I was a bit misleading in the title as this is a flaw in an internet connected coffee machine (why, oh why, do we need this) that allows, among other things, access to a connected PC.

There are a couple lessons in this. First, no matter how trivial your product, you very likely still need to worry about security if it connects to something that does have value. Second, your system is only as secure as all of the systems that connect to it, unless the system is inherently paranoid about connections. In this web 2.0 world of mashups, in the world of connected enterprise applications, our applications are not living in a bubble. They are connected to multiple other systems, and in most cases there isn’t a whole lot of thought that went into security over these connections. A web application may be horribly paranoid about anything it receives from the user, but then blindly accept data from internal systems without a thought. If any of those systems is flawed and you don’t validate input from them, your application is just as susceptible to attack as it would be if it didn’t validate user input.

This just further cements in my head the need to push threat modeling out to more people. I think the real value of threat modeling isn’t the complex threat trees that get built for risk analysis. I actually find those pretty worthless. I think the data flow diagram is the big thing. It is a convenient visual diagram showing where a process or feature is pulling data from and where it is sending the data to. Any source of data is a source of attack, and the DFD is a useful tool for identifying where further scrutiny is necessary. Any output source is a particular asset that might be attacked through your application. I think every dev spec should require a data flow diagram simply because it gets people thinking.

Finally, the last immediate lesson from this is that it is a scary time to be a client. The OS may be pretty solid but there are a million ways to execute code that seem perfectly valid from the OS point of view. Every connected application, any application that pulls data or opens data originally from a remote source, is a potential open door. If a freaking coffee machine can be a source of attack client security is in a lot of trouble.

~ Joshbw

Apple just released an update for quicktime, no surprise there. Doing some digging I found the five security issues patched:

Playing maliciously crafted QuickTime content in QuickTime Player may lead to arbitrary code execution

Viewing maliciously crafted Indeo video media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted AAC-encoded media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Five exploits, all in how a variety of media (video, audio, and picture) parses code. This tells me two things pretty much immediately- 1) Apple does not do a great deal of Fuzz testing on their formats, but researchers are happy to do so for them and 2) if I do fuzz testing on quicktime myself I will probably find something exploitable as well.

Fuzzing is a horribly brute force method for security testing. It requires a lot of work to wire things to adequately monitor an application (you want to see memory spikes, process spikes, and all of the myriad of crashes) and automate the loading of media. Regardless, it is very effective at breaking parsing and validation code. Microsoft requires 100,000 iteration on all parsed formats. For complex formats (office docs, media files), they basically never stop. Apple would be well served by doing the same (or caring about security at all).

Fuzzing is also applicable to web apps. They process an immense amount of data from end users, and other than specific known attacks done by pen testers, most companies don’t seem to test for various malformed input. The problem is that it is very hard to detect where and why something failed when fuzzing a remote machine. It would be nice to see a good distributed testing harness that can monitor the application state on the server and produce decent debugging logs.

~ Joshbw

We all encounter websites that accept user generated comments and this is often a a source of cross site scripting. In the past couple of weeks I have contacted two larger websites about this. In many cases there is a simple solution- whitelist input validation (which becomes slightly more complex if supporting internationalization) and output HTML entity encoding.

In ASP.Net a simple call to System.Web.HttpUtility.HtmlEncode will handle the output encoding for you. I actually like PHP’s htmlentities function a bit more, as you have control over how quotes are encoded and can additionally choose a character set (I very rarely can praise PHP over ASP.net, but they deserve credit for that). Java apparently doesn’t have a native method for entity encoding, which is dumb, but the nice folks at OWASP have provided a method. One caveat, like much of the OWASP material it is very UTF-8 centric, so it is less than optimal for international support and alternate character sets.

The problem is that many websites like customers to be able to supply some HTML that does render. Social networking sites love all the nice HTML based output that a billion online quizzes generate, and users like to be able to have some formatting other than plaintext (wiki does this right with their custom markup). That shoots whitelist validation of characters right down, and prevents entity encoding. Instead it requires custom parsing to validate which tags are used, and further parsing to make sure they aren’t used in a dangerous way. For example <a href=”something” onmouseover=”alert(‘Give me a cookie’);”>this is pertinent </a> needs to be parsed to make sure that nothing malicious was in the legitimate attack. It isn’t as simple as just blacklisting any use of on* to stop events, since many of these sites want style tags to be used as well (I can’t imagine why, someone can do serious defacement this way), and good ol’ IE has this nice Expression value that can execute javascript inside of the style (the problem with this microsoft, is that the only people who use it anymore are people misusing it).

When one includes all of the myriad of ways to use encoding to obfuscate attacks, accepting selective HTML, especially if you accept more than just UTF-8 input, results in a seriously complex validation engine. Complexity is the enemy of security. Both of the websites I contacted (having used an isolated test area impacting only me- remember kids, it isn’t ok to do web vulnerability testing where you can ever impact another user) accepted some HTML tags and had flaws in how they validated them.

~Joshbw

Ivan Ristić has an excellent blog post about fixing session hijacking. He is absolutely right that the current hack to add state in web applications absolutely sucks. Storing session information in cookies means it will be stolen from some users, either because HTTPOnly wasn’t used and an XSS flaw allowed for a simple query of the cookie, or it was used and an XSS flaw allowed an attacker to query the response from XHR to get the cookie, or because it was tacked on some place it shouldn’t, or a million other web based attacks. Just as likely, a great deal of malware these days actually scans infected machines and harvests cookie data (since both IE and Firefox keep all of it in the clear in predictable locations). Cookies simply are not secure, so it is silly to store secure information there.

I like the idea of adding it to the encrypted transport layer, as it already manages state anyway. I do think there are some challenges there, particularly when it isn’t the web/application server managing SSL but instead a third party appliance, but it would be a much more secure way of tracking state. The DOM has no access to that, malware on the client system would have a much more difficult time getting that data (it could conceivably configure itself as an SSL proxy, but that is a non-trivial task), and whenever session information is being transmitted the connection should be encrypted anyway.

More worrying to me than sessions is the fact that the vast majority of authentication on the internet is a lie. It does not authenticate an individual, as most think, but rather it authenticates two pieces of trivia associated with a particular account. There is absolutely no assurance that a person using a particular userid/password happens to be the account owner, especially when the userid might as well be public data on most websites (it is either visible, or an email address that can be obtained many ways).

For the average, non-paranoid net citizen, there are hundreds of ways that those two pieces of trivia can be disclosed. Most disclose the same two pieces of trivia whenever they register or sign on to a different site. Some sites, like LinkedIn, actually prompt for the trivia to access other sites (yes, give LinkedIn your login to hotmail, gmail, facebook, etc). Phishers, SMSishers, etc all try to trick people into disclosing the trivia. Every company that hosts the trivia can be a source of breech for it. Dozens of applications exist to guess the trivia. It is inherently a weak and fragile mechanism that is ineffective at assuring identity.

Some companies, like PayPal, are concerned enough about this that they hand out rotating tokens. This is good security, for a handful of sites, but between paypal, my bank, and my VPN token for work I think I have reached my limit of tokens I am willing to keep track of. I know RSA is thrilled about the idea of all big websites giving users tokens, but I sure am not.

Microsoft recognizes this. Craig Mundie gave a good talk at RSA this year about enabling end to end trust- how the client can authenticate who the server is and the server can authenticate who the client is. Most people who misunderstood this thought it would be a return of Palladium (which they focus on protecting DRM, rather than in general the protection of system integrity which was actually the point. Yes, it could protect DRM, but it could also make sure something like Windows Update wasn’t compromised. The problem with security is that it can be used to secure things people don’t agree with) and flipped out, or thought it was some nefarious evil Microsoft plot for world domination (seriously, it is a business, not the villain in an bond movie). That’s a shame, because abstracted from Microsoft this is specifically the type of discussion and innovation that needs to be realized. We need a system that isn’t easily compromised that can identify ourselves to other parties, and vice-a-versa. An example of such a system is two way SSL, but that is not something that would be adequate for the usage scenarios of a human end user.

As an industry I think it is important that we shift to a new paradigm of authentication. I think we need to start talking about various models that can actually realize end to end trust. And unlike sessions and roll your own authentication, I think we need to stop using weak hacks and design it right this time.

~ Joshbw

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