As some of our readers are well aware, last year many leading browsers finally closed a major privacy hole involving browser history that has been around for more than ten years.  Essentially, would-be trackers used JavaScripts to scan links with functions like getComputedStyle() to determine whether each hyperlink was styled as a visited site or unvisited (e.g. visited links are often purple and unvisited are blue).  This practice represents a serious threat, since not only can stints of browsing history be logged, but individual users can be tracked and identified with ease (this is one of several ways you can be tracked without cookies).  Since this practice of changing styles for visited links has been around since the early days of web browsing, Mozilla, Google, and other browser competitors worked hard last year to maintain the functionality while plugging up this age-old privacy concern.

A recent endeavor at Stanford University’s Security Lab found more sobering information on the reach and capability currently employed by trackers such as Epic Marketplace (formerly known as Traffic Marketplace).  The lab found that the scripts used on affected sites were very fast and loaded thousands of links in invisible iframes so few users would ever notice them.  Whenever the browser window closed, the scripts sent off their findings and also stored their progress in scanning links with a cookie.  In order to avoid having parallel scripts run concurrently and slowing down the process, some even used some semaphore-like cookies to start and stop.   By scanning thousands of hidden links, these scripts could quickly develop a comprehensive history of browsing, and the lab found that these links ranged from eBay listings to health clinics, a serious privacy concern.

While most browsers have worked to minimize this history sniffing issue, it is estimated that at least half of all Internet users are still quite vulnerable simply because many do not update their browsers on a regular basis.  Some affected users can also reduce this problem by setting their browsers to automatically clear all history whenever they end their session or by always running incognito/private browsing mode.  Of course, you can obviate any JavaScript attacks (history sniffing or otherwise) by disabling all scripts from running with extensions like NoScript for Firefox.  If you have an outdated browser (for testing purposes, right?), you can see a history sniffing script in action at StartPanic.com (The petition there is now obsolete since browsers have updated).   Given the extent of current history-stealing scripts found at Stanford’s lab, it is crucial to remain as up to date as you can on browser patches.  Remember that there are many ways to be tracked that do not involve cookies.

It was recently announced that Electronic Health Records (EHR) are in use in all military hospitals. Granted the article is mostly marketing screed for one company, but it still represents a big step. Outside of the Department of Defense (DoD), this probably doesn’t seem like a very big deal. Inside the DoD, it’s HUGE. This is the culmination of years of work and millions, possibly billions, of dollars spent. It’s an important step in improving the health care for Wounded Warriors.

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

(more…)

Comptroller Susan Combs offered another apology Thursday for the information breach in her agency, saying she now is offering a year of free credit monitoring to the 3.5 million people at risk of identity theft after their data was exposed on a public computer server…She announced in a written statement April 11 that the Social Security numbers and other personal information of 3.5 million people were left exposed for a year or more in a publicly accessible computer server at her agency.

Dallas News

According to this article in the Dallas Morning News, 3.5 million identities were left free for the taking on a public server for at least a year. That is a colossal security lapse. However, it is a fairly responsible remediation that credit monitoring is being made available for the affected users. (Contrast this with Sony’s recent Playstation Network breach; Sony won’t even confirm whether or not credit card information was accessed in their attack.) Still, had literally any effort been put into keeping that information secured, the state of Texas wouldn’t have to spend an estimated $21 million for the credit monitoring services.

The security arena is one in which the maxim “an ounce of prevention is worth a pound of cure” holds especially true. How much would it have cost to audit that server deployment? A few thousand dollars? Tens of thousands of dollars? Hundreds of thousands? Any answer less than “21 million dollars” means that this should never have happened.

Last week, we received a fax at the office from a branch of Virginia Commerce Bank. It was addressed to “Katie” and had our fax number clearly written on the cover sheet. The cover sheet had this interesting quote:

This facsimile, which may contain confidential or legally privileged information, is intended for the use of the individual to whom it is addressed only. If you are not the intended recipient (or authorized delegate for the recipient) of this message, please telephone the number listed above to advise us, so that we can arrange for its proper destruction and resend it to the correct recipient. Thank you.

It probably goes without saying that there isn’t a “Katie” working here at Gemini (yet). So of course we called the number to let them know we had received this fax in error. It took my office manager over 30 minutes on the phone to get through to the appropriate person to ensure that it was understood that the information went to the wrong fax number. We followed their instructions explicitly, but nobody at the bank seemed to know what to do. Ultimately it wasted our time.

What was in the fax? The materials attached were an absolute treasure trove of information. Names, addresses, phone numbers, birth dates, social security numbers, drivers license numbers… and that was just on the first page. A copy of two driver’s licenses. A copy of two credit cards. A letter of incorporation, a federal EIN, and copies of two credit reports.

This is more than enough information to steal the identity of two individuals and one business. And the terrifying part of it is that nobody would have been the wiser if we didn’t take the time to phone the bank to let them know we had received the information in error.

Which brings up an interesting question. Should we have called the bank? Sure, I feel bad for the individuals and the business who are having their most private information sent via fax. Their information couldn’t be in better hands though – we know better than to do anything with this information, and we securely shredded it. On the other hand, because we called them the bank now has a record that they accidentally sent us this information. If these individuals suffer identity theft, wouldn’t they immediately consider us a suspect?

In these days of heightened concern about identity theft, why are banks still using insecure transport mechanisms such as faxes without even bothering to call the recipients to ensure successful delivery?

You know those Facebook applications that occasionally pop up on your news feed, promising to add a “dislike” button, let you view who’s been looking at your profile, or implement some other feature that Facebook won’t ever support?  A lot of these applications are not much more than thinly disguised malware designed to harvest personal information or trick the user into participating in a click fraud scam.

Well, it looks like we’re in for a lot more of them, thanks to a new, cheap toolkit that allows users with little to no programming knowledge or experience create these malicious applications.  For the low price of $25, this application will guide you through the process of creating your own nefarious Facebook applications with promises of enormous return on investment by tricking your friends into filling out surveys for various third parties.

So remember, folks – be careful when you allow applications access to your Facebook profile – not all of them are safe, and not all of them deliver on their promises.  Personally, I haven’t installed any apps on Facebook, and I probably never will.

---

On an unrelated note, don’t forget – today is patch Tuesday!  Keep your Windows machines secure(ish) by applying those patches as soon as you can.  (Details: http://www.microsoft.com/technet/security/Bulletin/MS11-feb.mspx)

I just got a rather interesting email in my inbox. It’s from a travel document service. The email was about an order I had just made regarding a lost passport. Which is a bit of a trick, seeing as I’ve never done business with this company, I know exactly where my passport is, and I am not traveling internationally in the immediate future. So, at first I thought it was spam; I get emails like that all the time for services I didn’t request. Usually the spam filter catches them, but one or two do get through.

But, you know, I’d never seen this one before. I had to read it to see what the scam was. And that made it far more interesting. There’s no scam. The company is perfectly legitimate, and they’re not trying to sell me anything. It’s a real order confirmation for a real order. Benjamin Hartley really did make this request.

Just, you know, not me. My name isn’t common, but there’s at least one other person with that name. And he’s not at all careful about email addresses. I’ve had email from him in the past – or, rather, from organizations to whom he’s given my email address. I feel as if I know him. I know where he went to school; I know who he works for. I know who he donates money to. I think I even saw his birthday in one of the emails. And now I know he lost his passport. I know when he’s leaving the country. Oh, and I have all the confirmation information to get his replacement passport sent wherever I please, so if I really wanted I could have, well, quite a bit more.

I’m not going to do this of course. But I obviously could. This is potentially very damaging information. And it was just emailed to me. Not even signed or encrypted – just emailed. I’ve not been stalking this guy; I’d be happier to not be receiving this information, but it keeps coming. And, ironically, the one piece of personal information I don’t have about him is his contact information. Actually, that’s not true. I called the company, and – even though I was entirely clear to them that I was not the person who made the order – they still gave me his phone number, which is a whole different security failure.

This is really rather disturbing for two reasons. First off, my nominative doppelganger needs to be far more careful with his information. I don’t know why he doesn’t worry that he never receives the emails he’s expecting; maybe he forgets about them, or checks his email so infrequently that it doesn’t matter. But he’s not getting information which he clearly should be receiving, including some potentially compromising information. Second, the travel document service needs to be far, far more careful. They should have asked me to confirm my identity before discussing the order – at minimum a birthday, but a passport number or social security number would have been better. Of course, given that I told them beforehand that I was not the person who made the order, confirmation is the least of the problems there.

In technology, we’re generally good about confirming the destination for data. Our medium may not be secure, but the technology usually knows if it has connected to the right destination. But that’s because computers do it for us. Out here in meatspace, we’re not so careful. Like this other Benjamin, we generally just assume that our data will go to the right place – or if we don’t get it, then it’s not a problem, it just got lost. And like the travel document service, we simply assume that anyone asking about specifics must be allowed to know about them, and we don’t confirm. And that’s really all that needs to be done here – get a little confirmation that data is going to the right source before sending sensitive information. If that had been the case here, I wouldn’t have been handed this man’s personal information this way. As it is, though, it makes you wonder what other information might have gone astray. The other Benjamin is lucky; his personal information went to someone without ill intent. Others may not be so fortunate.

For a while, it looked like the crypto wars had been won. Strong encryption was available, and governments were even encouraging the development of better encryption standards like AES and 3DES. Implementation is – and will likely always remain – an issue. But it was there, it was possible, and there weren’t any legal barriers to using it. And it couldn’t have happened sooner: more and more business processes are moving online, from nigh-ubiquitous email, to rolling out VoIP to save on telephony costs, to increasing outsourcing to the cloud.

The victory in the crypto wars didn’t last long. Today, there are a slew of laws in place in various countries controlling the use of strong encryption. Some, like the UK’s “Regulation of Investigatory Powers” Act allows encryption but allows law enforcement to require that information be decrypted. Others, like France, require the use of trusted third parties in case law enforcement desires the keys. Still others, like the Communications Assistance for Law Enforcement Act (CALEA) in the US require other forms of encryption backdoors be in place. In a few places, certain forms of encryption are simply illegal.

There’s good news here, after a fashion. If ever we needed independent confirmation that the current level of cryptographic technology is pretty good, here it is. Governments, in the form of law enforcement, espionage, and military are all concluding that it’s not practical to break existing encryption. (Of course, this doesn’t mean they can’t, just that they either don’t think they can do so fast enough, or that it’s too costly). Still, this is a good sign for the quality of the encryption.

The bad news, however, is that complying with the law may make your data insecure. Notwithstanding how you feel about a given government reading your files and intercepting your communication, it’s a given that if a backdoor exists for one party, it exists for anyone sufficiently motivated to find it. So what are your options?

Well, pretty much the typical ones. First of all, learn the relevant laws about cryptography wherever you’re doing business. This is actually pretty hard, as there doesn’t seem to be any authoritative list, even just for the US, and it’s pretty hard to figure out who would even know. But once you do, it’s time for some hard decisions. You may decide that you can be sufficiently secure within the limits imposed on you. You may choose to keep truly sensitive information off the network, maybe keep something in-house that you’d rather outsource. In some cases, you might even decide you can’t do business, though that’s a pretty extreme measure.

Facebook recently introduced some interesting functionality that’s being touted as an “opt-in security feature.” When I first heard that they were incorporating one-time passwords (OTP), I figured it was probably a pretty good idea. In theory, OTP seems straightforward to implement, and can offer some substantial benefits when done correctly.

However, after learning how Facebook expects people to request the one-time passwords (via mobile SMS), a potentially negative side-effect becomes apparent. Passwords are often the first line of defense encountered by an attacker. But in this case, OTPs actually undermine the benefit of the original password by creating a temporary token that can be used instead. This creates a security tradeoff, whereby the benefit of a secret password is sacrificed for protection against an untrusted system (kiosk, library computer).

This tradeoff isn’t inherent to OTP systems, and only exists for Facebook because the person requesting the access token is not required to prove their ownership of the respective account each time. Access to the mobile phone linked to the account is all that is required to access the goodies. In the time it takes to send a text message, an attacker could essentially hijack an account.

Curiosity and a few minutes alone with someone’s phone might be all you need to turn Facebook’s shiny new “security feature” into another privacy misstep.

So you’ve been hearing lately about how some Android applications are going rogue and being used to steal users’ data and infiltrate their phones, to sit idly by only to wreak havoc when the user least expects it (ok, so maybe I exaggerated a little there). But there has been a lot of buzz lately about certain apps not playing by the rules, or including certain calls to leach user information. A lot of this buzz has been spun as backlash against Google for allowing these types of applications to exist (instead of having some asininely draconian filtering process like some ‘other’ phone provider).

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

(more…)

A colleague lent me his most recent copy of IEEE’s Computer magazine.  Inside was an article entitled A Web 2.0 Model for Patient-Centered Health Informatics Applications (IEEE membership required to read).  Some possible benefits of their proposed approach were listed, including:

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.