Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. (more…)

An uproar was recently started in reference to some privacy concerns about the new release from Google, Google Buzz. One of the first to sound the alarm was a blogger who was quite explicit about disliking some of its default options (and by explicit I mean “NSFW language” explicit, the post is here) which prompted some quick changes from Google.  In order to start using Buzz, you have to create/modify your Google public profile which will appear next to all of your activity in the Buzz feed.  By default, the public profile would display all those you follow. Chances are you’ve followed everyone in your contact list, so you just made your whole contact list public.  Now in the new behavior:

A box titled “How do you want to appear to others” will now include a check-box that says “Show the list of people I’m following and the list of people following me on my public profile.” To hide your followers, click the box, or click the “View and edit the people you follow” to customize your account.

The interesting thing here to me is that Buzz is essentially a service like Facebook or Twitter, designed to let other folks know what you are up to.  The fact that there is a privacy uproar around it is somewhat amusing, because it is designed to provide the opposite of privacy – to provide your followers information about what you are doing.  If you don’t want to share this information, don’t use Google Buzz!

I’ll enlist a famous quote from Scott McNealy, then CEO of Sun Microsystems: “You have zero privacy anyway. Get over it.”

It is amusing to me what people – especially young people – are willing to post online.  As a child, my parents once told me that once you say something you can’t take it back.  In today’s Internet-connected age, this holds true and is even more significant: once you say something online, hundreds if not thousands of people will see it instantly, and potentially billions of people will be able to track it down in archives, Google searches, the wayback machine, or in countless other ways.  Be careful what you share online.  Be careful what you say.  It might–probably will–come back to haunt you.

We have recently taken a look at Internet Explorer 6 (IE6) to try and help convince a customer of ours to stop deploying it on workstations.IE6 still holds about 33% of the browser market share, but Microsoft stopped mainstream support for it in April of 2009.  IE6 runs ActiveX controls at the same privilege as the browser, which is the same privilege as the user – typically administrator level.  And according to Secunia there are 23 known unpatched vulnerabilities in IE6 – including one which has been around since 2003.

And in a timely post from Brian Krebs on his new site krebsonsecurity.com, there’s a very simple way to crash IE6.

If you’re curious and have IE6 lying around, type or cut and paste the following into the address bar (that last character is a zero):  ms-its:%F0:

So, what are we missing? Are there any other reasons I can throw at this customer to put IE6 out to pasture? Let me know in the comments.

According to a new article on TechTarget, a study by the Ponemon Institute has revealed the cost of a data breach has increased once again, to $204 per compromised record. The study is available for download at http://www.encryptionreports.com/ after giving away some personal details.

The “Fifth Annual U.S. Cost of Data Breach Study,” funded in part by encryption vendor PGP Corp., determines the annual cost of the breach by establishing a company’s cost of lost business as a result of an incident; expenses incurred by notifying individuals and authorities of a breach; costs associated with legal fees and consulting firms and new investments made in technology and employee education.

In our down economy, it is interesting that the cost of data breaches have been rising for five years running.  If I were cynical, I might suggest that one of the reasons for the constantly increasing costs in this study is the partnership with PGP, who sells products designed to protect you in the case of a lost laptop or storage device.

That said, I’m not even sure that those items above can accurately represent the cost of data breaches, especially in certain environments.  The loss or damage of reputation caused by a data breach can be so devastating that the monetary cost can’t even be calculated.  If you don’t know what I’m talking about, what is the first thing that comes to your mind when I mention Heartland Payment Systems, TJX, or the Department of Veterans Affairs?  These organizations have suffered tremendously because of wide (and widely publicized) data breaches.  Imagine the firestorm of criticism if some of the most trusted companies were to suffer data breaches along the lines of Heartland’s breach?

In addition to the loss of reputation, what are other costs of data breaches that the Ponemon study doesn’t reveal? Let us know in the comments.

ISACA has introduced a new certification for risk managers – CRISC. I’ve got their CISA certification, and I’m not sure that CRISC is useful (other than as a way to make them money).

First off, risk management is not specific to the IT field, and most risk managers are not working in IT but in project management. Second, there are very few risk management methodologies in use, or even studied, so what exactly does this certification teach/require? There are scant details on the web site on what the test will cover, but they claim that these professionals will help enterprises design risk management controls for IS. Risk isn’t only about controls – that’s auditing – making sure the processes you put in place are being followed!

Risk management isn’t only about determining and mitigating risk, it’s all about what are the risks and what are we going to do about them? I’m not sure these skills are easily taught, except through case studies.

Any project manager is going to understand risks better than most IT people will (unless they’re also a PM). Go for the PMP cert rather than this one.

Google has just announced that HTTPS access would be “on by default” starting immediately. This is in response to the recently publicized attacks against Google and Gmail which are causing Google to reconsider their approach to China.

While I’m happy that Google will now be encrypting Gmail-related communication by default, I’m a little surprised and disheartened that it took an attack to cause this to be implemented. Sure, https has been an option since July of 2008, but Google had previously warned of a security / usability tradeoff with turning it on:

Because the downside is that https can make your mail slower. Your computer has to do extra work to decrypt all that data, and encrypted data doesn’t travel across the internet as efficiently as unencrypted data. That’s why we leave the choice up to you.

Today’s computers are fast enough to handle https without concern, thank you very much. And I think they meant to say your encrypted email “can’t be cached by proxy servers” instead of “doesn’t travel across the internet as efficiently” – which is a good thing, right? The use of always-on-HTTPS is an infrastructure problem – establishing and maintaining all those different secure sessions with different keys certainly takes time and processing power. It is unfair to solve your infrastructure problem by suggesting that the user might not want comprehensive security.

Are you aware of any other services that allow the user to make a poor security decision in the (perhaps unjustified) name of speedier access? Let us know in the comments!

Another iPhone killer is here. DROID. Whether you’re a fan of either product, or you’re still thumbing away on your Blackberry or WinMo device, there’s one thing to be said. There are plenty of apps now. A couple years ago it was a pretty daunting task to get any sort of application on your device that wasn’t already on your carrier’s supported list. WinMo users have been the only real open crowd here as every version of Windows Mobile has supported most of the older apps since the Windows CE days. But with the rise of more and more applications comes the rise of the risks associated with these applications.

(more…)

Fact: Twitter uses Amazon’s S3 AWS to store user images.
Fact: Twitter apparently only checks the file extension to determine the file type of uploaded images, not an image library or a method that checks for binary image data.
Fact: This can be used (or abused) to obtain un-metered free hosting of files that are less than 800K in size.

How is it done? A user can rename any file with a ‘jpg’ ‘gif’ or ‘png’ extension and upload it as their background image on a dummy Twitter account.

Then they can simply grab the URI of the “image” from the inline CSS declarations. Since the file is believed to be an image, it is uploaded and stored with no changes. The URI will point to a file having an image extension, but non-image content.

A good application of this is using Twitter’s AWS account to host javascript files. Simply enter the URI as the “src” attribute in a script tag like so:

<script type="text/javascript" src="http://s3.amazonaws.com/twitter_production/profile_background_images/151911/my_javascript.jpg"></script>

For high-traffic websites that use large javascript files, this could save a considerable amount of bandwidth. Amazon’s S3 acts as a CDN as well, so this might also improve performance.

There are some ugly security implications of this, however. Many web-based exploits use unaware 3rd-party hosts to serve up malicious javascript files.  This is particularly troubling since other types of files can be uploaded (exe, swf, mp3, etc). Unless they want their Amazon S3 storage account to become a free data repository for the bad guys, perhaps Twitter should be a bit more prudent with their user-submitted data.

There isn’t really a standard definition of what constitutes a “Critical” vulnerability in an application, but I think it can generally be agreed that when something is given that label, there’s a pretty serious problem that needs to be fixed ASAP.  So, when Adobe announced not only the existence of a <a href=’http://www.adobe.com/support/security/advisories/apsa09-01.html’>Critical Vulnerability</a> in its flagship Reader and Acrobat products but also that the flaw was already being exploited in the wild, a quick patch job would be expected.

The vulnerability in the Adobe software deals with a buffer overflow (seriously – how can we STILL be dealing with these???) flaw that seems to deal with how Acrobat deals with JavaScript (or at least, the exploits found in the wild use JavaScript), although the security bulletin is light on details.  The bug was disclosed on February 19th, and a patch was released on March 10th.  That’s not really an impressive turnaround time, especially for a remote code execution vulnerability.

Adobe’s patch release is interesting, though, in the fact that the update is, as of today, still only available for version 9 of both Reader and Acrobat, and then only on Windows.  A patch is forthcoming for versions 7 and 8, which are also affected by the same vulnerability, with Adobe claiming March 18th as a release date, as well as a stunningly far off release date of March 25th for Acrobat 9 on Unix.

I can imagine some reasons why patching an older version of the application may take a little longer…older versions of a product typically have a wider install base and are more sensitive to changes that may affect things like existing business processes and behavior of deployed plug-ins.  But, the sluggishness in response time seems to be directly correlated to how much money Adobe stands to make or lose by patching each respective version.  Why is this fix taking so much longer to apply to older and lesser-used versions of Acrobat?

I doubt that Adobe overhauled the relevant code that much during the development of Acrobat/Reader 9, as the flaw is exploited the same way on all versions.  Are there really extra weeks worth of validation tests that have to be executed?  Did all the people that worked on Acrobat 7 + 8 leave the company?  Or, could this just be a combination of cost saving by Adobe and subtle nudging of users towards purchasing upgrades to Acrobat 9, and just a cold shoulder to the smaller Unix market*?  The message being sent here appears, to me, to be that you can only expect updates to be prioritized on the latest and biggest version of Adobe’s products, and support for other releases isn’t nearly as much of a priority.  Whether this is an accurate description of the situation isn’t really important – it is, after all, based on a few substantial assumptions.  In this case, though, perception rules in the absence of an official explanation from Adobe why some of Acrobat takes weeks longer to patch the same problem.

*I don’t have any sales figures for platform-specific versions of Acrobat.  The Unix market being smaller is just my assumption.

Many people have been praising Mozilla’s Firefox 3 ever since pre-beta. I can easily throw myself onto that band wagon, but there is one feature that has been causing a little commotion, and I again can easily agree with the commotion.

Firefox 3 (FF3) limits usable, encrypted (SSL) web sites to those that have an approved digital certificate from an authorized vendor of Mozilla’s choosing, making it so you have to pay to be recognized. What’s the big deal?

When you visit an encrypted site in FF3, and that site uses a self-signed or simply unapproved certificate, FF3 doesn’t immediately show the page. Instead, you are greeted with what, at first glance, would seem to be an error page.

FF3's self signed cert error page

In order to move beyond this page and actually continue to the site as intended, you need to process through 4 clicks to add that site as an “exception.”

The use of a certificate is for SSL – which has two main purposes – allow connections to be encrypted so they can’t be snooped, and allow sites to be authenticated so they can’t be impersonated. Advocates of Mozilla’s policy seem to only focus on the latter, stating that a self-signed certificate has no value for authenticating a web site. The real concern is that snooping is much more of an easily attainable threat than impersonation. So, it is much more valuable to have a self-signed certificate than nothing at all, but doing so puts FF3 users at an inconvenience.

This, to me, sounds like it is blatantly going against the notions of Net Neutrality, something that has been fought to keep open for ages. Something like this completely discriminates against those not willing to purchase an “approved” certificate.