I’ve had some interesting experiences with two companies recently that I’d like to share. We all do business with companies online: we buy from them, we schedule appointments, we put in support requests, and so on. Today, I very seldom use the mail, and don’t shop in person very often. How these businesses treat customer security is interesting. Some places are very technically savvy and have robust, secure online transactions. Being realistic, though, I know that my dentist’s office does not employ a full-time sysadmin. They buy an off-the-shelf customer care solution and hire someone to install it on their website. Sometimes that’s good, sometimes that’s bad…

First was with my mechanic. I like my mechanic – they’ve saved me quite a bit in the past. But they’re notoriously bad about answering the phone. However, they are surprisingly up to date for such a shop. They have a website which allows you to schedule your appointments online, no need to call. That’s great!
Necessarily, this means you need to have an account on the website. Okay, this makes sense: they track your name, contact information, kind of car you have, and the car’s maintenance history including mileage. While nothing there is particularly incriminating or dangerous unto itself, it’s not the sort of information I’d like to have broadcast to the world, either. So it’s good that this information is kept in an individual account not available to others.
However, I admit that I couldn’t recall my password for that account. No problem, I put in the username and requested a password reset. The automated tool asked for my email, which I gave, and it sent me a new password.
Do you see the problem? It wasn’t asking me for my email address to confirm that I should be the recipient of that password. It was asking in order to know where to send the new password. There was no confirmation process; it just sent the password to the address I’d provided.
And that’s how I got into someone else’s account. My first clue was that I don’t own a Mitsubishi. No harm done – I didn’t even get the person’s contact information, I simply figured out my correct account name (I was off by one letter) and logged in properly. But that’s no security at all.

On the flip side, I wanted to get support for a piece of electronics I bought recently. I was looking for a driver for it, and couldn’t find anything, so I thought I’d go ahead and contact their support team. In theory this should be a straightforward enough thing. In practice, not so much. You have to open an account with the manufacturer. For which you need to own an actual product. Now, that’s a bit of an issue – what if I was looking at buying a product and wanted to know beforehand if the driver existed? But I already owned this item. So I went to open the account (and set up to handle all the forthcoming spam, I’m sure.) Part of the process involves saying just which device you own. Now, the item I had wasn’t listed. I made the best match, a similar item with a different model number. Shouldn’t make a difference, right?
Oh, but it does. The item I selected is listed, for some reason, as out of warranty. And on that I was frustrated – I cannot make inquiries about an item which is out of warranty.
I’m sure this system reduces needless support requests. In this case it also prevented a real request; I won’t be buying this company’s products in the future.

What can we learn here? Well, two companies, two lessons.

In the first case, make sure your system applies basic security. My mechanic has relatively trivial information on me, sure, but they have some information, and they’re not securing it well enough. The idea of a confirmation before resetting a password has been “best practice” for longer than I can remember. If you’re going to bother having individual user accounts, there’s no excuse to not treat them with at least some security.

In the second case, your security shouldn’t get in the way of your business. Sure it’d be nice to be able to make sure every single contact was authenticated and properly routed, but if you have any reason to deal with the public that’s just not going to happen.

The overall lesson is that even if you’re a small company, your security has to match your needs. An off-the-shelf solution without any thought behind its application won’t do you any good.

A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections – 17 USC § 512, from the Cornell University Law School

No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

A few years back, I was working as a tech writer for a company which made medical software. We were trying to get an important certification that we’d need to sell our product. And a crucial part of that was good documentation: we had to show how it worked, what it did, how it tracked everything, how it was secure, etc. Well, that’s what you have a tech writer for, so all is good.

It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

(more…)

The following events are based on actual facts and actual events. Names have been changed to protect the oblivious.

I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way.

Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I resorted to Ebay. Long story short, I found an LG Optimus S – a rather sturdy little phone for its age for $7 plus $4 shipping. The description said that it did not boot. Being the hacker that I am, I generally don’t let simple statements like that deter me.

A few days later I had the phone in my mailbox. It even included the battery, which I wasn’t expecting. I attempt to boot it up, and as described – it doesn’t boot. I plug it in to ensure it has a charge. It won’t charge. I pull out the voltmeter and quickly determine the battery is junk. Fast-forward two more days after a visit to Amazon (Prime). A new battery is awaiting me in my mailbox. Plug it in, viola, Android magic!

(more…)

So, SOPA is the news of the day, in terms of the Internet and security; it has been for well over a month now.
In case you’re not familiar, SOPA is the Stop Online Piracy Act. It will “authorize the U.S. Department of Justice to seek court orders against websites outside U.S. jurisdiction accused of infringing on copyrights, or of enabling or facilitating copyright infringement.”

I won’t bore you with the typical arguments about how it’ll infringe on free speech, or weakens safe harbor, etc. These arguments have been made, and they may have some validity, but let’s talk technology.

SOPA is the most recent in a long line of legislation intended to regulate the internet. Such legislation is doomed to failure. The internet was designed to be impossible to regulate. SOPA focuses on preventing search engines from directing users to sites, and ordering domain name registrars to delist sites. While there are other provisions, these are the primary tools for stopping piracy outside of US jurisdiction. They’re supremely ineffective tools, because neither search engines nor DNSes are necessary for the function of the Internet.

To understand this, let’s step back and look at what the Internet really is.

The Internet, or rather its precursors, were created in the 1960s as a result of an initiative by DARPA – the Defense Advanced Research Projects Agency. DARPA is notable for investing in all sorts of interesting projects that might have military applications – many are successful, and result in some of the most powerful technologies of our time. Granted, many are pretty off-the-wall and don’t look like they’ll ever amount to anything, but that’s the risk you take.
The Internet was created to enable communications even against attempts to disrupt the network – even against the loss of most metropolitan areas, such as might happen during a nuclear war. This is actually very hard to do: you have to come up with a design that works even if all of your central nodes are gone.
The Internet as we know it today has a number of elegant solutions which make it the most robust communications network ever known.
The first is in the data packet. All data sent on the Internet is broken up into packets – even when it’s called “streaming”, it actually consists of content that has been broken up into separate packets which are then reassembled at the destination. Each packet, in turn, has a portion that says to where the information is going (the address) and a portion which contains the actual data (payload). This means that any given packet can be lost or corrupted, and the entire rest of the message will still get through. Granted, with encryption or compression this might be a moot point, but on the other hand with error correction it can actually be made even more robust.
Beyond that, there are the routing protocols. Various routing protocols work somewhat differently in ways that are hard to describe, but they all serve roughly the same function. When a router receives a packet, it looks at the destination address and tries to find a route to that address. What’s especially clever is that if a given route fails, the router can then select an alternate route. In this way, the Internet can be self-healing. Bandwidth might drop as alternate routes are used, but so long as a path exists the message can still get through. And that path isn’t limited to even the same medium as was used in the past: Internet data can be sent over copper, satellite, radio, laser, physical media, even carrier pigeon!

Now, I haven’t mentioned DNS or search engines so far. That’s because we don’t need either.

DNS – Domain Name Service – is a technology that renders IP addresses into human-readable names. The addresses to which I alluded earlier are numerical. In IPv4 they’re a 32-bit binary number; in the newer IPv6 they’re a whopping 128 bits. Rendered into decimal, they’re a bit more manageable, but not by all that much – would you like to memorize strings of numbers like “192.168.15.106” for every website you visit? DNS is a service that your computer accesses which translates the much easier to recall names, like www.google.com into 74.125.227.147. It’s a nice convenience, but you don’t actually need it. And you’re not locked in to any one DNS server – you can set up your own, or you can actually use one that’s based outside of US jurisdiction.

And search engines?
Same thing – they’re a convenience. There isn’t even a specification on what a search engine is. And as you doubtless know, you can use whatever search engine you like, again including ones that are based outside of US jurisdiction.

There are technical solutions to these oversights, of course. But, thanks to the structure of the Internet, there are workarounds for those as well. The Internet was designed to be hard to disrupt. From a technical standpoint, attempts to regulate the Internet are basically the same as trying to disrupt it; it’s simply not a technology which was designed to be regulated.

I’m not too ashamed of myself to whore out a few select email addresses for personal gain, or even promote a certain company by liking or retweeting something if it will benefit me more than the actions required, but I always keep a hesitant nature towards most of these promotions. I mean who doesn’t like free money?

I received an email the other day supposedly sponsored by a reputable programmer-related site. What it entailed was signing up for a big vendor’s developer program. If I did so, they would send me a $15 gift certificate to one of the major online retailers. I’m trying to keep all parties in this matter anonymous simply because I do not want to promote anything involved in this so-called promotion, and the actual parties involved are irrelevant. The email went something like this:

 

Happy Holidays Developers!

Get a $15 [online retailer] Gift Certificate by joining the [vendor] Developer Program (no charge!)

Thanks to your [programmer site] participation, here’s all you have to do!

1. Visit The [hyperlink to vendor site] and register at no cost!

2. [vendor] will send you a validation email: confirm your registration following the URL provided in the email which will prompt you to choose a password

3. Once you have chosen a password, [vendor] will then send you a password reset email: forward the password reset email and the sign up email address used to [promotional site email]

4. Once verified on our end, a gift certificate will be sent to you promptly after the program ends!

Hurry! This is limited to the first 600 respondents, one per person.

For full terms and conditions please visit [marketing link to promotional site]

Step 3 is the one that caught my eye here. You want me to forward you an email sent to me that allows me to reset my password? By doing this I would essentially be sending the promoter an email that contained a link with an embedded token allowing them to authenticate as myself and then change my password, essentially gaining access to my account at this vendor site. Mind you, this isn’t exactly a critical account. But still these are very poor security practices.

So, what’s to be learned from this? Pay attention to what’s being asked of you. If it seems slightly out of the ordinary, it probably is. Inboxes are being filled with more and more spam these days, some make it through, and some even seem legitimate. It’s up to the users to educate themselves on how to detect and avoid these types of situations. In closing, I’ll leave you with a list of things you can do to help protect yourself.

• If it seems too good to be true, it probably is. So use common sense people!
• Do not click on links in emails – period! Just because it says it’s a link to SiteA doesn’t mean it’s actually going there.
• Enable spam controls on your email client – if you’re using Outlook, Thunderbird, or even Gmail’s web interface – they are all pretty good at detecting what may or may not be spam.
• Use multiple emails or use gmail’s ‘+’ email features or mailnull to help sort out those mailing list emails and let you know which emails are being distributed to others.
• Do not load images by default or at all.
• Do not enable scripting at all!

These are just the tip of the iceberg, but you get the idea. Help protect yourself and you’ll be helping to protect all of us.

A few years ago, a friend of mine served in Afghanistan. It was, as he described it, a long and mostly dull duty. When not busy with soldierly duties, he wrote on his blog and took pictures, often of the rather picturesque – to those who didn’t have to traverse it – scenery. At one point, however, he was informed that these landscape pictures were, in fact, an operational security violation. Not the ones taken in-camp, but the gorgeous panoramas of Afghani mountains and valleys. The theory was that, using those pictures, insurgents could find their position. My friend’s response was succinct: “I think they already know about the mountains, sir.”

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

Earlier today, news began to spread about an exploited certification authority (CA) spotted in the wild. The Tor project blog has an excellent write-up on how they detected the presence of patches blocking particular SSL certificates and worked backwards to determine that a Comodo issuer had been compromised. The folks at Tor suppose (rightly) that if people who monitor the patches for Firefox and Chrome hadn’t noticed, this entire incident might have been swept under the rug. Since that time, Comodo has come clean with an incident report which describes in detail the certificates that were issued and even states

 All of the above leads us to one conclusion only:- that this was likely to be a state-driven attack.

I am not as convinced – I think it might have been referenced more to try to deflect interest and speculation away from their own poor management. Also, I would think that a state attack would be more involved than a simple username and password.

Yes, Comodo notes in a separate blog post that the compromise was related to the theft of a username and password of a registration authority (RA) account. I was shocked to find out that their registration authority users are able to log in with a username and password, and not requiring a more secure method of login (for example, public key infrastructure (PKI) login with a smart card). I took a look at the Comodo Certification Practice Statement (CPS) and found that “Trusted roles” (section 3.10.1) should in fact require it. The CPS states (for Trusted personnel) “Identification is via a username, with authentication requiring a password and digital certificate.”

Of course my first issue is with the semantics of the statement.  Presenting a digital certificate is not authenticating anything because digital certificates are public information; one must prove the possession of the private key corresponding to the digital certificate to be authenticated.

My second issue is that it is not clear in the CPS whether an RA would actually be a “Trusted role” or not. In section 3.9.3 they indicate the following:

All personnel in trusted positions handle all information in strict confidence. Personnel of RA/LRAs especially must comply with the requirements of the English law on the protection of personal data.

To me, this reads that personnel of RA/LRAs are “personnel in trusted positions” and therefore should qualify for the “Trusted role” in their CPS, which would have required certificate-based login. Unfortunately, I cannot find any more definitive statements in the CPS that would put the RA into or out of the “Trusted role” as defined.

Ultimately, I hope this compromise will help Comodo improve their practices and update their policies. Most organizations that run a PKI (whether internal or external) know that RAs should always be considered a trusted role in a PKI. The RA’s role is to direct the actions of the CA, the entity that issues the certificates and certificate status information. These certificates, in turn, allow us to trust transactions between parties (such as SSL sessions). If the RA is not trusted, then nothing in the PKI should be.

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?