Security can be its own worst enemy

August 21, 2009
General Ramblings
Leave a Comment

This is a great article on some of the pitfalls of the security mindset – the post is essentially based around the quote “The more secure you make something, the less secure it becomes”. A quick snippet:

I recently attended two conferences on Usability, Security, and Privacy. The first, SOUPS (Symposium on Usable Privacy and Security), was held on the Google campus in Mountain View, California, the second at the National Academies building in Washington, DC. Google is a semi-restricted campus. People can freely wander about the campus, but most buildings are locked and openable only with the proper badge. Security guards were visibly present: polite and helpful, but always watching. Our meetings were held in a public auditorium that did not require authorization for entrance. But the room was in a secure building, and the toilets were within the secure space. How did the world’s security experts handle the situation? With a brick. The side door of the auditorium that led to the secure part of the building and the toilets was propped open with a brick. So much for key access, badges, and security guards.

Recently I encountered a policy that obviously dealt with user circumvention of security controls. It was the typical draconian AD password policy – 8 characters, upper, lower, numeric, special character, no repeats of the previous 24 passwords, change every 45 days, yadayada. On the surface the policy makes sense – it is sufficiently long and complex enough to prevent brute force, and the requirement to change the password and not repeat it should prevent any termed employees from having unlimited access to shared accounts. There are a couple other measures in place – every client has software that extends the normal delay Windows inserts into a failed login attempt to an even more annoying time (seriously, first failed attempt – 30 second wait, and it just goes up from there) and the AD will delay authentication as well, so brute forcing is already a bit impractical. A termed employee who is of the mindset to abuse a shared account that they still have access to isn’t going to wait 45 days, they will abuse it in a week.

In general I am fine with the policy myself as I can generally remember an esoteric string of characters fairly easily, provided it is within a short period of time of first being exposed to it or I have used said string three or more times. I think I am probably an exception. Many people, when faced with a complex password are just going to write it down, making the system much less secure. Clever people who dislike the policy will change the password 25 times in a row so they can just go back to their old password, and so forth. Unfortunately for the latter category there were equally clever AD policy setters who decided that a password cannot be changed if it had already been changed once in the previous two days. Arguably what this has done was cause people who had committed ONE secure password to memory to now either use variations of the same password (which really achieves very little – someone who knew the password was Secret!01 is naturally going to try Secret!02) or to be one of those folks who just writes it down.

And then there is the little scenario that cause me to think up this whole post. I had access to a shared account. It was set up quite a while ago so that we could grant access to a server for folks in a different AD hive without creating seperate users for each (which is lazy and not great practice, but they only need access for a small window at which point the password can be changed). I immediately changed the password after the account was setup, since the default password sucked, for a number of reasons. Unfortunately the folks that were actually going to use the account weren’t ready for it for a decent period of time, and by the time they were ready I had forgotten the password, as I never used it after that initial change (first thought from me – “Crap, I should have written that password down”). I ask our friendly admins to change it, and they do – to “Password1″ (not sure how they got passed the requirement for special characters), email me said password, and ask me to change it. I immediately go try, but since the password was changed in passed two days, I can’t. Hurray draconian password policy, because of you now I have to wait until tomorrow to update the password. Granted a two day exposure window for a crappy password isn’t a huge deal, especially since outside of a test SQL server and a webserver it has no access, but it does demonstrate that in our effort to make something *more* secure, we can be counterproductive.

So when deciding what security controls to put in place I think it is a good idea to not just look at the surface. One question I have not heard asked at very many design meetings of security controls is “How will the control we are implementing end up working against its own intent?”. One way a control will be its own undoing is if it sets up security as the enemy of the users, because then the users will invalidate the control. “Make me change my password to something I can’t remember – well my good friend post-it will remember for me.” “Make me buzz in all my friends at the conference just so they can use the toilet, then I am going to prop the door open”

~ Joshbw

Forget Virus Scanners

June 26, 2009
Uncategorized
1 Comment

Does anyone know of a decent program that allows you to whitelist which executables may be loaded (even better would be executables, dlls, and assemblies but that would be a bit of a headache to manage)? Conceptually it shouldn’t be that hard to write – just poll the running processes and kill any not in the list as soon as you see them but I don’t really want to take the time to create a whitelist of all of the OS components and services myself (compiling a list of applications I execute is work enough). It seems like a whitelist of executables is way easier to maintain, way less invasive, and potentially much more effective than the signature based virus scanners.

~ Joshbw

Opera Unite

June 17, 2009
General Ramblings
Leave a Comment

How do you make a web browser, already one of the most common attack vectors against a client, even less secure? I know, add a web server and have it serve up the whole damn client file system! What a great idea!

Is Opera insane? What does the Threat Model look like for this thing? Opera, you do know what threat models look like don’t you? You use them right?

~ Joshbw

China’s mandatory filter software

June 11, 2009
Uncategorized
Leave a Comment

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

Question on Disclosure

June 10, 2009
General Ramblings
Leave a Comment

So here is a hypothetical -

Say a small real-estate agency is using a simple PostNuke website (which is out of date) to gather rental applications – applications with all of the information necessary to both verify (and apply for) credit as well as history of passed residences. In other words, say they were collecting all of the information necessary to completely ruin someone’s life should the information be disclosed, to tie the would be applicant up in years of financial pain and legal hardship as they try to clear the ID theft from their record.

Now say that the version of PostNuke was woefully out of date and moreover nothing was over SSL.

Hypothetically a security minded person sees this and tries to fire off an email, but gets no response. Then calls the agency up and tries to explain in person how UTTERLY HORRIBLE this practice is, but it is filled with luddites that have no place running a website that collects this information and they just don’t get it (either the technical ramifications no matter how simple they are explained, or the ramifications to the applicants). Those fancy sort of attacks only happen in the movies after all. At that point, how does the would be Samaritan lawfully get the problem addressed, as the agency is an active security risk to every person who has ever provided information to it?

On the larger topic, man is our society screwed. A person can completely have their credit destroyed (and thus many years of their life since living in the US without credit has some major implications – no car or house loan for you. No credit card, which you need if you ever want to rent a car, etc) because some podunk mom and pop website decided they needed a credit application and had no idea how to securely handle the data they collect. We seriously need a better mechanism for asserting our identity than a bunch of easily disclosed historical data but there seems to be absolutely no pressure to move to that (probably because the big 3 credit bureaus are terrified of losing some of their power).

~ Joshbw

Patent on Input Validation

May 26, 2009
General Ramblings
Leave a Comment

From Acidus on Curiouser and Curioser – USPA 0090132950 – IBM’s patent on input validation:

The present invention discloses a system for providing real-time validation of text input fields in a Web page during text entry. Such a system can include a validation-enhanced text input element and an input text validator. The validation-enhanced text input element can be configured to contain a validation expression for a text field in a Web page. The validation-enhanced text input element can be contained in the source code document that corresponds to the Web page. The input text validator can be configured to validate a character entered into the text field against the validation expression in real-time. Characters determined as invalid can be visually indicated by the input text validator in the text field.

Hurray for our busted ass patent system. As Acidus says, IBM, go fuck yourself. It may not be a patent on all forms of input validation (notice the reference to “real-time” – this seems to suggest an AJAX powered system to validate input fields as the user is typing), but really any patent on input validation is a freaking mistake by the patent office.

~ Joshbw

The hardest decision when embracing effective Application Security

May 9, 2009
Secure Development
Leave a Comment

It is a truism in the application security world (or really any security) that in order to have an effective Security Program you need executive buyoff and executive support. To many this means that you need executives to care about security, be willing to fund it, and be willing to stand behind their security personel. This is certainly true, but there is a precursor step that is necessary for many development organization to move to truly institute effective Application Security – they need to mature as a software organization and embrace process.

When most software organizations start out they often embrace a seat of the pants development style, something often mistaken this as agile development, which has three very simple steps – Have Idea, Code Idea, Market Idea. As they mature they might realize that they should decide if they can sell the idea before they try to code it, rather than figure that out after the fact, and they decide they need to bring in testers to verify that they actually did code the idea. As a dev org matures they get to a platue were they have developed some process, but it resides on either side of the developers- they actually do analysis of an idea to see if it is worth the development costs, and they do testing and customer acceptance verification to make sure that the idea was implemented in a way that will meet customer’s needs, but at the end of the day all they expect developers to do is write code and testers to make sure the code does what it is supposed to.

The problem is, that is an arrangement that will not consistently produce robust code- security wise or otherwise. Verifying functionality only finds average use case flaws, but does not verify proper behavior across all concievable uses, and simply writing code without discipline will produce unmaintainable, fragile, redundant code. It is in this state that organizations start to care about security, but they aren’t willing to make real commitments to the changes necessary to see it happen. At this point they need to decide whether or not they are willing to change their development and test culture, and this is a very difficult decision to make and enforce.

If the decision is not made, the organization will trap themselves into an entirely reactive model to security threats- Problems are found by vulnerability assessment or customer reporting and fixed- tribal knowledge is gained among some developers and there is a short term downtick in that specific type of vulnerability among those specific developers- long term the org hasn’t learned much, and the information is not sustained. Almost no prevention will occur. This is because a preventitive model would require changes to how the code is written and verified.

If the decision is made, then the development team needs process placed on them and accountability to following that process. They can’t just write code anymore- they need coding standards detailing how they can write code and they need to get used to writing documentation. Developers hate writing documentation, but it is one of the most important things they can do- with documentation they can fully think through how they will code a feature before they start doing so (we don’t start pouring foundation before we decide on the blueprints for a house after all) spotting shortcomings of a particular method before they have spent a couple of days implementing it and they will provide something were the design itself can be tested rather than just the implementation. On the topic of testing, the dev org needs to get in the habit of hiring testers who are very skilled at thinking in terms of finding problems, rather than testers who are little more than stupid users that can determine whether a feature either works or doesn’t. Skilled testers are worth as much as a skilled developers, as effectively finding technical problems is just as hard as effectively coding solutions (one of the best interview test questions I have ever heard was “What do you think of your cell phone?”- a true tester may describe a couple of things they like, but then proceed to talk about the myriad of things that they wish were done better. A true tester is someone who perpetually sees the flaws in something, no matter how good it is). The testers also need to be given a strong voice- they are the verification for the developers and if their voice is not strong, then they can’t serve their purpose.

Doing this will give the security team a framework to then build in security controls into the development process. They need an actual process in place, otherwise they have no foundation to build off of. An existing and well defined development process is an input into any effective secure development lifecylce, and an SDL is ultimately the path to a preventitive approach to security. The problem is that it is very hard to change a development culture and it requires commitment from the top. Developers hate process, and they are going to be very resistant to implementing it. Executives need to make it abundandly clear that conforming to the process is the developers’ job- it is what they will be paid to do, and if they don’t do it they will not be paid. This will make no friends among the developers. That is why it is the hardest decision that a maturing development organization can make.

Incidentally, the same thing is true for OSS as for proprietary, however it is even more difficult to implement and enforce in an open distributed development environment. The payoff for either software is much more than just security- the overall quality of the product will improve as a result and the code will be easier to maintain as their will be documentation to refer to and a level of code quality enforced.

~ Joshbw

The right control for the problem

May 9, 2009
Uncategorized
Leave a Comment

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

The Ultimate Windows 7 Hack that wasn’t

April 23, 2009
General Ramblings
Leave a Comment

The blogosuare is atwitter with news of an unfixable Windows 7 Hack being shown off at Hack in the Box by Vipin and Nitin Kumar. The exploit, VBootkit 2.0, sequal to VBootkit 1.0, is reasonably sophisticated. It boots off of removable media, reads the MBR, and then loads the OS, compromising OS files in memory to do all sorts of nefarious stuff. I haven’t found the whitepaper to 2.0 yet, but you can read the whitepaper to 1.0 here. 1.0 essentially targetted Vista, while 2.0 goes after Windows 7.

Now this is a pretty clever little exploit, but it isn’t an OS exploit. It targets one of the great maxims of computer security- if the system is compromised before your code runs, you cannot definitively restore integrity, or put another way, he whose code runs first wins. Windows code does not have an exploitable vulnerability, other than the assumption that the system booted securely, an assumption that *has* to be made. The Kumars deserve recognition for very effectively exploiting this assumption, but their actual attack vector is nothing novel.

We can continue to increase the pre-boot integrity controls and increase the sophistication necessary to access the machine, but physical access is still one of the easier ways to gain access to a box. That isn’t going to be a problem solved soon.

~ Joshbw