Couple random thoughts, observations, stuff:

Last night my wife wanted to pay her Sprint bill – she didn’t want to get up and go down stairs to grab her purse and credit card so she asked me for mine and I just tossed her my wallet without thinking. Rather than grabbing my dedicated credit card out she grabbed my debit card, which wouldn’t have been my preference (easier to dispute credit credit card charges if necessary). I was prepared to start answering the various interrogation questions necessary for a card purchase, since the CVV code is intentionally missing from all of my cards (no need to make it extra easy for a would be pickpocket), and was sort of suprised that she didn’t need any information other than the card number. It turns out Sprint uses the STAR network with debit card transactions and all it needs is the credit card number – how is that a good thing? Credit cards are already great theft targets since you only need a couple pieces of information to charge them – I don’t think reducing the amount of information is wise. In Sprint’s defense, only a moron would place a charge with a stolen card on their own account, but in terms of industry trends I can say that offering debit transactions with just a card number is one that I feel should continue.

Unrelated to that, the vast majority of blog spam that gets trapped by the filters at the moment is related to amoxicillin ads – what the hell? Can someone explain the psychology behind that to me? First, amoxicillin is an antibiotic – typically something you are using because you went to the doctor, found out you have an infection, and want medicine sooner rather than later; it is also something you only take for a short period (what, 5 days or something like that) and don’t renew – how is that a good candidate for mail order? On top of that its about the cheapest antibiotic known to man – it isn’t like Walgreens is charging $50 for it after insurance. Last time I needed to pay for amoxicillin it couldn’t have been more than $5. Are people really looking to knock that price down even further? What makes it good chum for spam fodder?

Well, those are my deep thoughts for the day, cheers,
~ Joshbw

Google is currently getting reamed for their poorly handled roll out of Buzz to Gmail users. It is pretty clear that they made the choice to automatically enroll as many people as possible into Buzz in order to grow its initial market share, at the expense of user choice and privacy. This Ars article does a good job summarizing the privacy complaints.

For my part I was curious if Google had violated their published privacy policy. After all, Buzz wasn’t exactly optional for GMail users, but distinctly changes the way your Gmail information is used (for example, it automatically made your Address list into a public Buzz contact list, when it had not been public before), and it would seem that the new functionality would not have been anticipated in the initial draft of the Gmail Privacy policy. Indeed, following Buzz GMail did update its privacy policy to read:

You may choose to use additional Gmail features, such as chat, which connects to the Google Talk network, or Google Buzz. The Google Talk service has its own privacy notice available here, and Google Buzz here.

Personally I find it suspect that Google chooses to obscure the Buzz privacy details behind additional links, rather than making it front and center. It is, after all, now an integral part of GMail, and something they chose to make users opt out of rather than opt into. In general it is my belief that if new functionality or services require a change to a privacy policy (at least in terms of being more permissive in information sharing – if by some miracle the change is to be less permissive with information sharing I have no issue), that functionality should follow an opt-in model after a clear explanation of the privacy changes.

Anyway, given only the alteration above I think serious questions would be appropriate concerning Google’s use of privacy policies, however they have a nice ace in the hole:

Google may send you information related to your Gmail account or other Google services.

This provision has been in the Gmail privacy policy for ages (perhaps since day one, but I haven’t confirmed that). A similar statement is found in other Google services. This is a nice little loophole that makes their privacy policy pretty much worthless in my opinion. In order to judge the privacy policy of Gmail I also have to be knowledgeable about the privacy policy of any other Google service that Gmail might share data with, and how it uses data as well (Google did, after all, disclose that it does share information with other services, so I can’t complain if other services use the data in a manner I don’t find appropriate). This, I believe, is an impossibility, since there is no way to achieve such knowledge – do services that don’t directly face customers but access the data have published policies? Does it cover both current and future services?

In general I would like to see the privacy policy modified in one of three ways:
1) The policy explicitly state which services information it contains are shared with (not just services that it directly shares information with, but also services they will in turn share the information with, etc), a whitelist of services so to speak, and directly link to their policies in the same way it does for chat and buzz. This way a customer actually can be informed how the data is used.

2) The policy state that while information is shared with other services (first and third party), additional services will conform to the privacy claims presented in the Gmail policy.

3) The policy has all other assurances erased and simply state that information is shared with other services and there can be no expectation of privacy pertaining to any information in Gmail.

Right now I think #3 is an accurate representation of what they are currently doing, but they are being dishonest in not making that obvious. I find #2 to be preferable, as it doesn’t require the user to bounce around hunting down the policies for other services (which, if they similarly share information, could put the user in the same position they are in now if the user did need to track down policies). What this really illustrates is largely how worthless privacy policies are in making appropriate decisions. (incidentally, the hotmail policy similarly has a loophole about sharing information with other services, though at least they also include “We use the information we collect to provide the services you request” which would imply an opt-in approach rather than opt-out)

~ Joshbw

An old and well worn addage is “Do as I say, not as I do”, generally in a fit of hypocracy when the listener is asked to ignore the example being set by the speaker. The fallacy of that statement was addressed by the series of “I learned it by watching you” advertisements trying to drive home the point to parents that children are more likely to learn from example than from what the parent says.

In the Applications Security space we are big fans of telling developers what they should and shouldn’t be doing in order to produce secure applications, which is all well in good so long as we are not violating those very same instructions within our own properties. If developers are visiting their enterprise’s security portal and see examples in practice contradicting the secure coding and design standards on display on the very same portal, it completely undermines those standards.

Having raised this more than once and been given a liteny of excuses of why it is acceptable (there isn’t anything of value on this website, we wanted to get the content up now and we can always go back and fix the problems, it is only for internal employees anyway, etc), the same excuses that developers of any other project will put forth for why they don’t need to build security in for this release, I really wonder about the effectiveness of the message the application security community is trying to convey. If we can’t even get our own organizations to embrace our suggestions, obstensibly folks that “already have the religion”, what is our hope of getting converts to that message elsewhere.

So for various security organizations, the risk profile of your application is not an acceptable excuse to ignore your own security recommendations; if you are not going to abide by your own mandates do not bother asking others to do so. “Do as I say, not as I do” is a very ineffective strategy. Developers WILL notice your lapses and no amount of trying to create a justification of such a lapse based on the risk profile of the application in question will buy you any crediblity to restore that which was just lost. The risk is not to the confidentiality or integrity of the application, but rather to the integrity of the message the security organization hopes to convey. Even if the underlying message is completely valid, a kid being told by a parent presently working through another pack of cigarettes for the day isn’t going to buy that they themselves shouldn’t smoke.

And a special message to OWASP, the same applies to you, and your various caveats throughout your website do not make it ok to ignore your own advice. Saying

“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. “

when subscribing to a mailing list is not OK. It doesn’t matter that there is little security risk even if someone does compromise the password – the entire point of this post was to establish that security risk is not the only consideration. You undermine your message when you choose the easy route – why should I hash my passwords when it is obvious OWASP, whose job is communicating security, doesn’t think it is important that they do.  Similarly, I think it would be great if you set “AUTOCOMPLETE=off” on your login form, like you suggest in your various coding recommendations, and similarly switch to a generic message if either the username or password is wrong, rather than telling me that specifically the username or password is wrong. Incidentally, MediaWiki would be all the better if you had those changes adopted into their mainline branch, which is the least you can do having leveraged the project.

~ Joshbw

There is an interesting writeup on the Reddit blog about the particular vulnerability that lead to their exploitation. In general it is a reasonably informative writeup that delves into their mistake and I wish all security flaws recieved such an informative writeup (You occassionally see Michael Howard delve into details on a Microsoft vulnerability, but it is hardly the norm).

That said, there is a bit of silliness in one of their quotes:

As a matter of fact, these bugs were only exploitable because we are open source. The worm author had to scour the source of our output filter to find these holes. We cannot hide behind security though obscurity, and we like it that way. We also rely on our users reporting security bugs in a responsible manner.

There are a lot of reasons to choose the OSS model and extol its virtues, but it is craziness to PREFER that malicious users have access to the source code and thus have an easier time finding flaws; its a trade off of the OSS model for sure, and you can’t have the good without the bad, but I think largely it isn’t unfair to say that folks would be happier if only well intentioned individuals had access to the source code (save for Stallman, but he also believes a person should be more proud of contributing to the Linux kernel than raising kids so I think we can religate him to fringe nutjob). One could argue that it puts added pressure to fix even seemingly small issues because of public scrutiny or other such philosophies but at the end of the day that statement ultimately amounts to Reddit prefering the greater risk. That is not to say that the benefits don’t outweigh the risks for a particular company and a particular business model but from a standpoint of avoiding the exploitation of vulnerabilities security controls + obscurity is better than just security controls. The less an attacker can know about you the better you are; you can’t *rely* on them being ignorant of you but at the same time it is always better to try and keep them in the dark.

Obscurity alone does not ensure security, hence the various statements about security through obscurity being a fallacy, but it does have security utility (and indeed necessity at times – your encryption is only secure so long as your key is obscure). Obscurity raises cost for an attacker, all other factors being equal, since it increases effort to remove the obscurity. If two sites seem to have strong input and output controls and I want to break into either of them, I will choose the one with open source code because it will take me far less time examining code for flaws than trying esoteric attacks in the hope one sticks (and similarly increase the chances of tripping any IDS or IPS solution deployed). Thus being closed source in that regard has benefits. Indeed, if Reddit had been closed source the likelihood of this vulnerability being exploited would be far lower; the code would still be vulnerable but the cost to find that vulnerability is such that the attacker would probably spend their time elsewhere.

In the end obscurity doesn’t ensure security but it does reduce risk. Risk is the product of likelihood and impact, and obscurity does decrease the likelihood – it doesn’t reduce it to 0, but it does decrease it. That’s why most Pen Testers will write up any unneccessary disclosure of information, even if it is just server tokens, because it is BETTER to be obscure than not from a risk stand point.

And just to be a bit snarky, if Reddit really didn’t believe in Security through Obscurity they would favor Full Disclosure over Responsible Disclosure. The latter hopes to obscure the details of a vulnerability until it can be fixed while the former has no obscurity to speak of. Of course it also means the chances of a maelevolent party exploiting the vulnerability increases but that was pretty much the point of my post anyway.

~ Joshbw

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

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

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

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

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