It turns out that Green Dam, the censorware that China want’s installed on all machines sold within its borders, is crap. The security researchers who wrote the article in that link found many major vulnerabilities within twelve hours of examining the software. First, it has buffer overlows, which can be exploited just by getting a user to go to a site with a long URL. It captures the URL from the browser and compares it to a black list – the buffer it holds a URL in is apparently fixed length, and less than the maximum length of a URL. Good to know that the developers apparently haven’t learned anything from a decade of widespread C++ exploitation. Also, it’s update mechnism allows arbitrary code execution by design.

The sad thing is that the software itself is pointless. Client software, on a client machine, can be defeated easily by the client. In fact, it has an uninstaller that appears to actually work, so the user doesn’t have to jump through the hoops that most malware would make them. On top of that, if it uses black lists to restrict the habits of would be surfers then its effectiveness is limited. In essance what China has done is mandate that a large number of their users expose their computers to exploitation while not seriously impeding those that want to view objectionable content. All this is going to get them is the ill will of their own citizens.

~ Joshbw

Vipin and Nitin Kumar have apparently released a proof of concept for their Vbootkit 2.0 attack against Win7 based machines. I’ve talke about the attack previously, as it is incorrectly labeled a Windows 7 attack- it is an attack against insecure boot process that then compromises Windows 7. Anyway, their rationale is -

The Kumars are concerned that the attack approach against Windows 7 they have unearthed might be modified by skilled miscreants to develop remote attacks, hence the decision to give white hat security researchers a leg up in developing defences. They also want to make the case to Microsoft that it ought to make improved security features available across all versions of Windows 7, not just the higher-end versions.

Apparently taking issue with the fact that BitLocker is only available on Enterprise and Ultimate versions of Windows. I’m not a huge fan of the tiered versions of Windows, but then again I have an alumni account at the MS company store so I don’t really mind paying $50 for Ultimate. At the same time, I think it is a bit crazy to expect bitlocker to be available for all users- the support costs associated with that idea are pretty high. Regardless, all of that is ignoring that a technical control is not ideal for their attack vector.

What leads to their VBootkit 2.0 being run is physical access to the machine- the ultimate enabler is that they are actually at the hardware. Technical solutions are an inherently poor mitigation to a physical problem. Physical controls are much more appropriate. In data centers simply putting the machine in a sufficiently designed locking server cabinent has neutered this attack, since the attacker would need to first break into the cabinent. For desktop users having a good locking, tamper proof case, the boot sequence set to boot from hard disk first, a BIOS password to protect the boot sequence, and a motherboard that isn’t prone to fail into bios when the keyboard buffer is full will prevent all but the most determined attackers. Physical controls for physical problems, technological controls for technological problems, and so forth.

Most of us are techies and immediately look for some nifty code that solves a problem, but enterprise security is only partially a tech problem. Some times a pad lock is better security than a strong password.

~ Joshbw

Johnny Long has a great auction of stuff available for his I Hack Charities organization. There is some good stuff, and it is a good cause.

- Joshbw

Dear Web Developers,

It’s not kosher to request login information for other websites. Both LinkedIn and Facebook are guilty of asking for your various email credentials so they can harvest your address list under the guise of “making it easier to find your friends” and they are by no means unique in this practice. Doing so does two things- first it makes users accustomed to disclosing credentials to websites unrelated to the site the credentials correspond to. Phishing is a huge issue folks, and we have a hard enough time just getting users to be aware that they really are on their bank website. About the last thing we want is to water down that message and get them accustomed to providing that information on sites they clearly see aren’t the site corresponding to the credentials. Unless you move to two factor authentication the only real way to protect against phishing is user education and training, and this practice completely torpedoes that effort.

The other issue is that you are introducing another link into an already vulnerable chain. Not only does google have to worry about the gmail credentials being properly handled on their site (only sent over SSL, hashed in the database, no sql injection to disclose them, etc), but they now have to worry about how your site secures those credentials (I bet you aren’t hashing the values, since you need to use them outside your system) and they really have no control over it.

So Please, quit asking for credentials to other sites- don’t do what attackers do, otherwise you don’t give people an easy way to distinguish between the two.

~ Joshbw

Jeremiah Grossman asks a series of questions on his blog trying to determine if we disagree with the concept or implementation of WAFs, Certifications, Trust Logos, and Compliance Regulations, so I will indulge the questions.

For WAFs I agree with a certain concept of them. I believe they are bandaids rather than solutions, but that bandaids have their place. The solution is to fix the code and ultimately the robustness of the code is the only real defense for a website. However a problem can be fixed *immediately* with a WAF- a good SDLC would require time for the code to be changed. A root cause of the problem should be analyzed and the application should be inspected for related problems (very likely if the bug got into the code once, it got in more than once). The changes should be thoroughly tested to ensure that functionality is not jeopardized, that the fix works, and that different problems were not introduced. A proper change control process should manage the deployment of the fix. In short, I believe that even if resources can be thrown at the problem immediately, it does not follow that the fix would likewise be immediate. (Tangent- I believe that Firefox is too aggressive on their patch to market strategy and likely takes shortcuts that they shouldn’t. I think it better to fix something right than fast, but I am not certain that Firefox agrees) Web App Firewalls allow an interim fix to put in place between disclosure and a coded solution, and in reality not many organizations can throw immediate resources on the volume of issues that they have. WAFs also offer a bit of defense in depth, which isn’t a bad thing. So long as people focus on that conceptualization of a WAF I think things are fine- my issue is when they are treated as a solution in and of themselves, at which point their limitations will be apparent. A WAF is a generalized appliance, not a specialized solution for a specific site (even with good rules). It doesn’t understand business context and so won’t catch things like unathorized or unintended access.

Professional Certifications I believe serve little point. Their implementations are almost entirely horrible and conceptually there is no certification that says that I will be successful for a given role in a specific organization. They are a decent marketing gimmick to put on a resume to get a bit of attention, and organizations may enjoy advertising how many CISSPs they have to assure clients, but ultimately I will not trust a third party organization in place of my own impressions. When I look at the resume of a candidate I am going to look at what experience is listed to narrow down the folks I want to talk to, and then I am going to probe their knowledge to make sure that it satisfies the needs of my organization. Since that is my inclination when looking for coworkers for my own group, I put absolutely no stock in the number of certifications in outside orgs that I might engage with.

Website Trust Logos are horribly implemented- I can’t think of a single logo peddler whom I believe does a sufficient job of assessing a website (except for PCI Scanless, which is one of the few logos that does *exactly* what it claims to). I will let you in on a little secret though, since I don’t see great harm in it. I have a pair of ADT security placards outside of my home, but no security system installed. If a would be thief is going down my block he is going to see the signs in front of my house, with the possibility of an alarm system backing it up, and opt to hit my neighbor that has no visible security system advertised. It is an entirely deterrent based approach, and while worthless if anyone calls my bluff, the bluff in and of itself is not without utility. I see the various logos as something similar. At the end of the day there is nothing backing them up (and even if they weren’t utterly terrible, in order to make them at all cost effective they aren’t going to be anywhere near as thorough as a proper pen test) but if I have to choose between two otherwise equivalent websites to break into, I am going after the one that didn’t bother to even get the logo. Also, consumers don’t know any better, so it is a cheap way to get them to trust you.

And compliance regulations vary in the effectiveness of the implementations, but I don’t disagree with the concept. My view on regulations in general are that they are a way of mandating certain things that are societaly beneficial, but not necessarily beneficial to the bottom line of a company. As such, left to capitalistic pressures in a vacuum, those things would never happen (or only happen in companies not completely governed by the bottom line). For example, from an economic standpoint it is cheapest for a company to just dump pollutants in a nearby stream rather than properly dispose of them most of the time (depending on the economic power of the locale, and how likely it is for serious legal threats to originate out of the action)- see mountain top removal mining for just such a mentality in action. Thus the government needs to impose regulations to ensure that societal wellbeing is also taken into account. Conceptually I see nothing wrong with the interests of individual entities and the interests of the society being balanced by regulation- that is an optimal solution to natural trends in pure capitalism that allows for most of the efficiency of the system while managing some of the drawbacks.

The flaws arrive in the actual implementation of the regulations. If implemented poorly they can prove to be too much of a burden, overly hard to implement or understand, not fully effective, or as usually the case, all three. PCI is a great example of this- Heartford was a nice and shiney gold partner, following the regulations, and it did absolutely nothing that actually stopped the disclosure of card information. At the same time, the overly specific nature of PCI means it has to be constantly revised, that more secure solutions can technically be non-compliant, and that it is a huge burden to understand and implement the mandates. The whole thing would be much better off if it said that systems and communication channels that deal with card information must have both confidentiality and integrity maintained, followed with recommended baseline guidelines. Rather than check the controls in place, the QSA simply checks to see if they can extract card information. The problem is that PCI is too focused on checklists and not at all focused on what it actually hopes to achieve, so its implementation is pretty worthless.

Regulations only work if they are clear, their restrictions are reasonable, and if they are focused on ensuring *a* solution to the problem, rather than *one* solution to the problem. If I had to choose between my bank information being stored on an encrypted drive in a generally open data center and questionable asset disposal programs, or plain text in a data center with detailed background checks for all employees, strictly enforced physical controls that limit access to the box, and a thorough and consistently applied asset disposal program, I am going to choose the latter because that organization has a clear intent on security, rather than on meeting a checkmark on a list. (ideally I would want the latter with an encrypted drive). I think most security regulations lose focus on this.

~ Joshbw

Giblets aren’t just the disgusting parts of the turkey, the foul (or fowl if you are no stranger to puns) organs that your grandma likes to try to fool you into eating for her own perverse amusement. In certain parlance they also refer to the external code that your applications is dependent on- source code for which you have little or no control. Giblets are typically libraries, assemblies, jars, or other such modules that a third party, whether it is an external company (for example, the excellent looking Elegant Ribbon), another internal team, a vendor, etc. wrote. They are also a huge security concern as you usually have little insight into what security was incorporated in the giblets’ development cycle, nor a great deal of control when vulnerabilities are discovered in the giblet. You can make your own code rock solid, but still find your application exploited because of Giblet code. MS Office has been hit by this a number of times, as legacy and third party file filters continue to be vulnerable despite the dramatic re-engineering of the Office file formats (.docx, .xlsx, etc) with security in mind.

Recently my colleagues and I have been playing around with several different HTML Encoders in Java. Despite what OWASP has posted on the subject for an international enterprise it is not as simple as encoding everything that isn’t A-Z,a-z,0-9 (though I don’t think OWASP is making any claim at the robustness of their recommendation). Having all of your Chinese radicals all of a sudden converted to full character encoded values is going to dramatically increase page size, especially on anything like a blog or other large text field with copious blocks of user input that gets echoed to the screen. Most people don’t want to figure out how to implement their own character set aware, internationalized Entity Encoder, and so naturally prefer to use canned solutions. The desire to use a canned library is by no means unique to HTML Entity Encoding; for any number of functions this makes sense, since many functions take specific expertise (do you think your average PHP programmer wants to worry about image manipulation implementations for example). However in this specific case it easily demonstrates why Giblets are a big fat bag of security suck. What happens when there is a flaw in the Encoder giblet? You really don’t know what the inside of it looks like- you don’t know how well written it is. You trust that it works, but if your output encoder isn’t encoding all output properly your defense against XSS is now vulnerable.

Really any giblet that processes or transforms external data is a point of concern. To some extent open source giblets can be better, as you can at least look inside and see how well written something is (though I suspect that the number of people who do so are probably in the minority), but for enterprises this can actually be a liability, as legal departments worry about license compliance and IP taint. For all other Giblets, there are a couple of recommendations to make you safer -

1) Ask for details about the Giblet Developer’s secure development lifecycle, vulnerability history, mean time to patch, and other useful behavioral questions about their security posture. It might be worth going with a giblet that has a bit less functionality if the security posture of the developers seems higher.

2) External, Vendor, or Internal, get an SLA in place that clearly defines obligations. Include obligations to patch vulnerabilities of various criticality ratings, time frames for said patches, agreed upon criticality scales (do you consider SQLi to be critical while they think it high?), and maintenance length (if a vulnerability is found five years after you purchased the giblet, are you out of luck getting a fix). This is often overlooked when working with internally developed code from other teams; however just as with external developers your security vulnerability may not be the internal teams priority. You need a commitment to address vulnerabilities in a timely fashion.

For non-commercial giblets, especially open source, you probably won’t get an SLA, so explore the ramifications and practicality of fixing the flaw yourself (see afore mentioned worry about license compliance and IP Taint). Non-commercial, non open source giblets (freeware) are very dangerous as you have no assurance concerning timely fixes, nor the capacity to fix them yourself.

3) Try to validate/sanitize all data before passing it to a giblet anyway, even if the Giblet developer has a great security posture and a very aggressive SLA. An added layer of defense is never a bad thing.

4) If the Giblet is consumed by a client, make sure any agreement with the Giblet developer includes the rights to distribute updated versions to the client.

Most importantly though, just keep in mind that third party code is a risk. Security should be as much a consideration as features when incorporating third party code and all of the security effort you put in may be for naught if your 3rd party code is vulnerable. When I draw threat models I like to label Giblets as External Entities even if they are processes or libraries consumed on the same box, as I have no control over them. It just helps to draw out the ramifications of their use.

~ 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

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

Sorry for the hiatus.  I have some posts culminating but I figured I would fire this one off while it still seemed relevant.  There is a lot of coverage about the current CanSecWest contest and the MacBook Air being compromised in two minutes, which has lead me to many different trains of thought.

First, I think the coverage of "Macbook Air Hacked in two minutes" illustrates very little research on the part of the authors, or an intentional aim at a misleading headline for sensationalist purposes, however my reasoning has nothing to do with the fact that a full day went by before the a successful attack (those arguments are really grasping at straws).  The details of the contest rules are posted here. It should be evident from the rules that the contest was broken up into three days, where each day represents a chance to attack a certain target on the computer.  Day one was essentially an attack against the OS and default services/daemons over a network, day two was an attack against default installed applications (web browsers, media players, etc), and day three was against popular non-default installed third party applications (acrobat, flash, etc), with each day representing a perceived easier target and thus less prize money.  If you read the rules there is one other thing that should stand out; they were posted a couple weeks ago. The hack took two minutes from execution to success, which isn’t surprising, but it took a great deal of time prior to the event for the researchers to find the vulnerability, which they did since they were given a heads up. The researcher didn’t find a vulnerability, write an exploit, and launch an attack in two minutes. The point really was to see what zero days would be found in a couple weeks of competitive research.

This is by no means a scientific way to evaluate security.  If you want to know the relative chance of your platform being vulnerable you have to look at trend data over a period of time and extrapolate the likelihood of a zeroday being known at a given moment, plus vendor patch rates, patch success rates (any recalls, history of not patching root cause), and a billion other factors.  It is complicated enough that the industry has not come up with any common metric of how "secure" an application/platform is.  A contest is not the common metric everyone has been looking for.

That said, this is a black eye for Apple, though one I think most researchers were expecting.  Apple has a strong rhetoric (by that I mean FUD) regarding their security relative to their competitor, but the fact of the matter is that when many very bright minds set their will to compromising the three platforms, Apple fell with perceived ease while neither of the competitors did.  This is going to hurt them, though as I said, I don’t think most security folks were surprised.  Apple has been very vocal about being more secure but their entire rationale seems to be that there is little malware available for their platform (which can be attributed properly to many non-security reasons; economics and propagation potential mostly, which is a post that I really need to finish), rather than the effectiveness of their secure development policy (a subject they have said precisely nothing about, which begs the question exactly what policy they do have) or the skill of their security experts (individuals who seem to have no public reputation, as opposed to the many vocal Microsoft security experts beginning with Michael Howard and working down the list).  An argument like that isn’t exactly convincing, especially when vulnerability data contradicts it.

That Apple got a black eye amuses me, I’m not a fan of false smugness, but I don’t even find that noteworthy.  What I do find noteworthy is the amount of misunderstanding on the various technical blogs/news sites in which this story ran.  Reading the likes of ArsTechnica, Slashdot, or to a lesser extent Engadget and Gizmodo, disturbingly few of the commenters have even a basic clue about security (but boy is it easy to spot the Microsoft employees; just look for the comments that have a clue and mention the SDL).  Misunderstanding or flat out false ideas are rampant among essentially the upper crust of the general consumer technology world.  If the more technical of the end users are this off base it paints a very grim landscape for end user security.  Security starts with education, education of both the developers and the end users.  If the end users don’t understand even the basics of what threats they are exposed to they are not going to understand what they need to do to secure themselves.  If someone doesn’t understand that anyone can walk into their house if they don’t secure the front door they aren’t going to know they need a lock.  Worse, if they think a lawn gnome is better security than a lock they are in trouble (unless it is the lawn gnomes from Invader Zim).

From the Mac user populace, at least in general, I don’t find this surprising.  They have been actively encouraged by their OS vendor to ignore security, which I think is a horribly bad idea, that security is not their concern.  However I would have thought that the more advanced Windows users would be more knowledgeable just based off of the hostility their OS faces regularly, and that Linux users would know more just based off of what they need to know to use the OS.  Sadly this doesn’t seem to be the case.  The top three misconceptions (and my rebuttals) among the threads on the subject seem to be as follows:

1. I don’t run as Root – I have user/os role seperation: Essentially the belief that if you need to sudo, go through UAC, etc, then malware is castrated.  This seems incredibly prevalent among Mac users and surprisingly from Linux users as well, and is a profound misunderstanding.  It first assumes that there is no means to escalate privileges through a flaw in the OS or common application running with increased privileges, which history has shown is not the case.  Worse, it assumes malware would need to.  They don’t seem to understand that malware can do anything that the current user can do.  If the current user has read/write/execute permissions to a resource (choose a combination) then so does the malware.  I don’t know of many users even in Linux that insist on running an account where they need to sudo for everything, because that would be tedious as hell.  Malware as a general user can read from any document that user has normal read access to (say, browser cookies, contact lists, personal documents) and even if there are pretty strict outbound firewall rules can probably use an existing application that already has outbound access to send data.  Firefox is quite extensible after all, and the IWebBrowser2 COM object has the same rules as IE (because it is IE).  Don’t get me wrong, I think account separation is a great thing, but it isn’t horribly limiting to malware, especially when they don’t need to hide from virus scanners. (it is also probably pretty easy to socially engineer a user on either Mac or Windows to allow your malware further access by naming its process iTunes anyway).
2. This wasn’t a big deal as it was an application flaw, they couldn’t compromise the OS: It seems many people think that since no one managed to hit the core OS and services on the first day of the competition that this somehow makes the attack against the browser less important.  I would argue that against the end consumer, even if the OS was open to remote code execution, malware authors would find it easier to target web facing applications like the browser, plugins (flash, quicktime, acrobat), email clients, etc.  OS exploits are dangerous when targeting a specific system, or when many systems are in proximity to each other to facilitate their spread.  It is great for intranet attacks, but not so great for internet attacks, in terms of being able to exploit.  I would posit that OS based attacks are primarily a bane of corporations rather than consumers.  Even in the heyday of the worm, when Windows OS security sucked, the worms most successful at propagation went through email, and relied on email client flaws (well, ignoring worms that had multiple attack vectors like Nimbda; obviously multiple means of propagation is beneficial, all other things being equal).
3. Who cares, this was a browser exploit, just don’t go to sketchy websites: There seems to be a huge perception among people that Internet/browser based attacks only come from questionable websites.  Even if this were true I think it ignores the surfing behavior of most users.  If they see a link in a forum or off of digg, or in a blog comment thread that seems interesting they click on it without thinking.  There are very few people who really are paranoid about everywhere they go on the Internet.  Further, it seems most users are utterly unaware that websites they trust can be compromised, either through some application level injection attack (with estimates of 80% of websites having XSS vulnerabilities of some form I think it is safe to say they will eventually view a compromised website) or through a host/network misconfiguration.  Study after study show that a large percentage of malware is hosted on compromised servers.  Social engineering really isn’t necessary to hit someone with a browser exploit; all that is necessary is to compromise a popular site.

I think the lessons to take away from this contest have little to do with the contest itself, but rather the general public’s response to the contest.  Awareness is the most potent tool security professionals can leverage but it seems clear to me that even among the reasonably knowledgeable geeks we have precious little awareness.  These three seemed the most common and egregious misconceptions, but it is hardly an exhaustive list.  I think it is simply a good demonstration of the incredibly minimal amount of progress made in public education and awareness about security. 

~Joshbw