Category Archives: security
Yahoo admits to a billion customer records being compromised. The numbers are staggering, but the news of the exploit is mundane.
Doubtless the raw numbers are very largely inactive accounts. People who long-since stopped using Yahoo accounts. People who signed up with some other company that subsequently got borged by Yahoo. People who once signed up to access some service but never used the accounts. Etcetera. Just as with social media numbers (even just the number of followers of this humble blog), to be taken with a big pinch of salt.
Nevertheless, that’s a billion signups. Allowing for fakes and duplicates, that might be a nine-digit number of real people who once answered security questions. That’s a bunch of answers that, unlike passwords, travel with the user across multiple services, not just online but also those you might access by other means such as the ‘phone or even face-to-face. The name of your first pet or your primary school are no more secure than the classic mother’s maiden name.
And now a billion such records have leaked. Give or take: we don’t know how many users ever were genuine, nor how many such questions and answers each genuine user disclosed.
So what does it mean if you’re one of the billion? If someone wants to steal your identity, your security questions and answers have passed from the realm of something they have to research to something easily automated. Well, we don’t know that for certain, but it’s certainly a risk that can no longer be dismissed.
You’d better change your security questions everywhere that matters. What do you mean, you can’t remember which questions you signed up to Yahoo with twenty years ago? Don’t tell me you can’t change the city of your birth, or the initials of your first lover. Oh dear [shakes head].
And even if you’re not one of the billion, you may already have started to get the phishing emails purporting to be from yahoo (or others) about changing passwords.
I’ve argued here before that security questions are not fit for purpose. Perhaps the Yahoo leak might help persuade the world to stop using them for things that matter!
A couple of days ago, I was looking up a bus timetable from my ‘phone. All perfectly mundane.
The address I thought I wanted failed: I don’t have it bookmarked and I’ve probably misremembered. So I googled.
Google failed too. With a message about an invalid certificate. WTF? Google annoyingly use https, and I got a message about an invalid certificate. Who is sitting in the middle? Surely they can’t really be eavesdropping: with browsers issuing strong warnings, they’re never going to catch anything sensitive. Must be just a hopelessly misconfigured network.
I don’t care if someone watches as I look up a bus time, I just want to get on with it! But it’s not obvious with android how I can override that warning and access google. Or even an imposter: if they don’t give me the link I wanted from google, nothing lost!
So has my mobile network screwed up horribly? Cursing at the hassle, I go into settings and see it’s picked up a wifi network. BT’s public stuff: OpenZone, or something like that (from memory). This is BT, or someone on their network, playing sillybuggers. Just turn wifi off and all works well again as the phone reverts to my network.
Except, now I have to remember to re-enable wifi before doing anything a bit data-intensive, like letting the ‘phone update itself, or joining a video conference. All too easy to forget.
Hmm, come to think of it, that broken network is probably also what got between me and the bus timetable in the first place. That wasn’t https.
 There are good reasons to encrypt, but search is rarely one of them. Good that google enables it (at least if you trust google more than $random-shady-bod), but it’s a pain that they enforce it.
Folks who know me will know that I’ve been taking an interest for some time in the problems of online identity and trust:
- Passwords (as we know them today) are a sick joke.
- Monolithic certificate authorities (and browser trust lists) are a serious weakness in web trust.
- PGP and the Web of Trust remain the preserve of geekdom.
- People distrust and even fear centralised databases. At issue are both the motivations of those who run them, and security against intruders.
- Complexity and poor practice opens doors for phishing and identity theft.
- Establishing identity and trust can be a nightmare, to the extent that a competent fraudster might find it easier than the real person to establish an identity.
I’m not a cryptographer. But as mathematician, software developer, and old cynic, I have the essential ingredients. I can see that things are wrong and could so easily be a whole lot better at many levels. It’s not even a hard problem: merely a more rational deployment of existing technology! Some time back I thought about setting myself up in the business of making it happen, but was put off by the ghost of what happened last time I tried (and failed) to launch an innovative startup.
Recently – starting this summer – I’ve embarked on another mission towards improving the status quo. Instead of trying to run my own business, I’ve sought out an existing business doing good work in the field, to which I can hope to make a significant contribution. So the project’s fortunes tap into my strengths as techie rather than my weaknesses as a Suit.
I should add that the project does rather more than just improve the deployment of existing technology, as it significantly advances the underlying cryptographic framework. Most importantly it introduces a Distributed Trust Authority model, as an alternative to the flawed monolithic Certificate Authority and its single point of failure. The distributed model also makes it particularly well-suited to “cloud” applications and to securing the “Internet of Things”.
And it turns out, I arrived at an opportune moment. The project has been single-company open source for some time and generated some interest at github. Now it’s expanding beyond that: a second corporate team is joining development and I understand there are further prospects. So it could really use a higher-level development model than github: one that will actively foster the community and offer mutual assurance and protection to all participants. So we’ve put it forward as a candidate for incubation at Apache. The proposal is here.
If all goes well, this could be the core of my work for some time to come. Here’s hoping for a big success and a better, safer online world.
Today I went to place an order with Argos, who I’ve used several times before and who have always – in contrast to some of their competitors – delivered very efficiently. This time alas the shopping process has become significantly more hassle, and they’ve introduce the VBV cuckoo into the process. But I was pleased to note that, when I came to the VBV attack, Firefox flagged it up as precisely what it is: an XSS attack, and in the context of secure data (as in creditcard numbers) a serious security issue.
I hope Firefox does that by default, rather than just with my settings. Though it would be courageous, to take the blame from the unwashed masses who might think VBV serves their interests when it doesn’t work. Doing the Right Thing against an enemy with ignorance on its side has a very bad history in web browsers, as Microsoft in the late 1990s killed off the opposition by exposing their users to a whole family of “viruses” in a move designed to make correct behaviour a loser in the market (specifically, violation of MIME standards documented since 1992 as security-critical).
Alas, while Firefox saved me from the evil phishing attack, the combination of that and other Argos website trouble pushed me to a thoroughly insecure and less than convenient medium: the telephone. Bah, Humbug.
I recently had email telling me my password for $company VPN is due to expire, and directing me to a URL to update it.
Legitimate or phishing? Let’s examine it.
It follows the exact form of similar legitimate emails I’ve had before. Password expires in 14 days. Daily updates decrementing the day count until I change it. So far so good.
However, it’s directing me to an unfamiliar URL: https://$company.okta.com/. Big red flag! But $company outsources a range of admin functions in this manner, so it’s entirely plausible.
It appears to come from a legitimate source. But since all $company email is outsourced to gmail, the information I can glean from the headers is limited. How much trust can I place in gmail’s SPF telling me the sender is valid?
A look on $company’s intranet fails to find anything relevant (though in the absence of a search function I probably wouldn’t find it anyway without a truly gruelling trawl). OK, let’s google for evidence of a legitimate connection between $company and okta.com. I’ve resolved similar problems to my own satisfaction that way before both for $company and other such situations (e.g. here or here), but the hurdle for a $company-VPN password – even one I’m about to change – has to be high.
Googling finds me only inconclusive evidence. There’s a linkedin page for $company’s sysop, only it turns out he’s moved on and the linkedin page is just listing both $company and okta skills in his CV. There’s a PDF at $company’s website with instructions for setting up some okta product (though it’s one of those that insults you with big cuddly pictures of selecting a series of menu options without actually saying anything non-obvious).
OK, maybe I can get okta.com to prove itself, with the kind of security question your bank asks when you ‘phone it. Let’s use okta’s “Password Reset”. I expect it’ll send a one-off token I can use to set a new password. If legit, that’ll work; if not then the newly-minted password is worthless and I just abandon it. But no such thing: instead of sending me such a token, it tells (emails) me:
Your Okta account is configured to use the same password you currently use for logging in to your organization’s Windows network. Use your Windows account password to sign in to Okta. Please use the password reset function in Windows to reset your password.
Well, b***er that. Windows account password? Windows network? I have no such thing, and neither does $company expect me to. I expect $company may have a few windows boxes, but they’re certainly not the norm. No doubt it just means the LDAP password I’m supposed to be changing, but if I know that then why should I be asking it for password reset? Bah, Humbug!
One more thing to try before a humiliating request for help over something I should be able to deal with myself. Somewhere in my gmail I can dig up previous password reset reminders, with a URL somewhere on $company’s own intranet. Try that URL. Yes, it still works, and I can reset my VPN password there. All that investigation for … what?
Well, there’s a value to it. Namely the acid test: does the daily password reminder stop after I’ve reset the password? If it’s genuine then it shares information with $intranet and knows I’ve reset my password. If it’s a phish then it knows nothing. So now I’m getting some real evidence: if the password reminders stop then it’s genuine.
They do stop. So I conclude it is indeed genuine.
Unless it’s so ultra-sophisticated that it’s been warned off by my having visited the site and used password reset, albeit unsuccessfully. Waiting to try again in a few months? Hmmm ….
Well, if $company hasn’t outsourced it then the intranet-based password reset will continue to work next time. If it doesn’t work next time then there’s one more piece of evidence it’s genuine.
I started writing a longer post about the so-called shell shock, with analysis of what makes a web server vulnerable or secure. Or, strictly speaking, not a webserver, but a platform an attacker might access through a web server. But I’m not sure when I’ll find time to do justice to that, so here’s the short announcement:
I’ve updated mod_taint to offer an ultra-simple defence against the risk of shell shock attacks coming through Apache HTTPD, versions 2.2 or later. A new simplified configuration option is provided specifically for this problem:
LoadModule taint_module modules/mod_taint.so Untaint shellshock
Here’s some detail from what I posted earlier to the Apache mailinglists:
Untaint works in a directory context, so can be selectively enabled for potentially-vulnerable apps such as those involving CGI, SSI, ExtFilter, or (other) scripts.
This goes through all Request headers, any PATH_INFO and QUERY_STRING, and (just to be paranoid) any other subprocess environment variables. It untaints them against a regexp that checks for “()” at the beginning of a variable, and returns an HTTP 400 error (Bad Request) if found.
Feedback welcome, indeed solicited. I believe this is a simple but sensible approach to protecting potentially-vulnerable systems, but I’m open to contrary views. The exact details, including the shellshock regexp itself, could probably use some refinement. And of course, bug reports!
I have a build script that may, as a matter of convenience, download and build a third-party software package. Before the build script goes into any release, I want to tighten up its security to ensure it verifies the PGP signature on the package.
OK, I can do that in a Makefile using two separate targets: the tarball, and the verified tarball. I thought I could make the latter a link to the former, using something like:
gpg –verify $(TARBALL).asc $(TARBALL) \
&& ln $(TARBALL) $(TARBALL-VERIFIED) \
|| (echo “### Please verify $(TARBALL) ###” && exit 1)
However, this is failing me, because gpg is too trusting:
$ gpg –verify nginx-1.7.3.tar.gz.asc nginx-1.7.3.tar.gz
gpg: Signature made Tue 8 Jul 14:22:56 2014 BST using RSA key ID A1C052F8
gpg: Good signature from “Maxim Dounin <email.suppressed>”
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B0F4 2533 73F8 F6F5 10D4 2178 520A 9993 A1C0 52F8
$ echo $?
(OK, now you know the identity of $(TARBALL))
It has not verified that the signature is trusted, but it still thinks all’s well. Ouch! I can verify the signature manually (if rather weakly) but I’d rather not try to script that. Nor do I want to concern myself with issues that might change with each new nginx release, or with changes of pgp keys.
A bit of googling finds this message, from which it appears this was a known bug but fixed in GnuPG version 184.108.40.206 back in 2006 (and yes, my gpg version is more recent than that)! Was that a non-fix that only tells you if it’s a BAD signature or no PGP data at all? That would be no more useful than an MD5 or SHA checksum!
OK folks, what am I missing? What do you use to script the verification of a package?
The fallout from heartbleed seems to be manifesting itself in a range of ways. I’ve been required to set new passwords for a small number of online services, and expect I may encounter others as and when I next access them.
The main contrast seems to be between admins who tell you what’s happening, vs services that just stop working. Contrast Apache and Google:
Apache: email arrives from the infrastructure folks: all system passwords will have to be reset. Then a second email: if you haven’t already, you’ll have to set a new password via the “forgot my password” mechanism (which sends you PGP-encrypted email instructions). All very smooth and maximally secure – unless some glitch has yet to manifest itself.
Google: @employer email address, which is hosted on gmail, just stopped working without explanation. But this is the weekend, and similar things have happened before at weekends, so I ignore it. But when it’s still not back on Monday, I try logging in with my web browser. It allows me that, and insists I set a new password, whereupon normal imap access is also restored. Hmmm … In the first place, no explanation or warning. In the second place, if the password had been compromised then anyone who had it could trivially have reset it. Bottom of the class both for insecurity and for the user experience.
There is also secondary fallout: worried users of products that link OpenSSL asking or wondering what they have to upgrade: for example, here. For most, the answer is that you just upgrade your OpenSSL installation and then restart any services that link it (or reboot the whole system if you favour the sledgehammer approach). Exceptions to that will be cases where you have custom builds with statically linked OpenSSL, or multiple OpenSSL installations (as might reasonably be the case on a developer’s machine). If in doubt, restart your services and check for the OpenSSL version appearing in its startup messages: for example, with Apache HTTPD you’ll see it in the error log at startup.
I’ve been banking online for quite a few years with generally good results. But I’ve just run up against the limits to it when I tried to access the information to transfer my cash ISA to another provider. The account number is not available online, for bogus “security” reasons! And when one thing fails, it seems everything falls apart.
Well, not quite everything: I was able to use an online messaging facility to get an answer after 48 hours. But with lots of gratuitous hurdles on the way. The followup online message I just sent them should be self-explanatory (it was slightly shortened to get within their 1000-character limit, so I had to lose things like the initial Thank You).
I regard a paper trail as a high risk, so I welcome paperless banking.
Paperless banking fails when I cannot access essential information online. Doubly so when [bank] has closed our local agency so I have no branch access as backup! Even if you blank out numbers in the overview, some means of accessing them is clearly essential!
Your phone service proved worse than useless. I gave up at the point where it required me to enter the very account number I was trying to find out (surely a far bigger security risk than anything online, since that would have disclosed the number in an ultra-easy-to-read form over an unencrypted medium)! In the absence of an option to speak to a human and identify myself using other information (such as my [current] account), this online message facility was my only option within your system.
Finally, this message service is defective. I composed a reply only to lose it when the system erroneously logged me out. It presented me a dialogue box from which I selected the option to stay logged in, but that led to the worst kind of failure: when I hit “send” it invited me to log back in and my message was lost without warning.
I recently installed an update of a software package running on an Amazon EC2 host.
In the configure step I found there was an unsatisfied dependency: it wanted ossp-uuid, which was not available on the system. Neither was yum able to find it: there was an alternative uuid, but no hint of anything from ossp. Turned up some problems with yum too (a hung security-update process from weeks ago and a corrupted database), but that’s another story. Checking my box at home, the reason I hadn’t stumbled on the dependency is that ossp-uuid is installed as a standard package here. A case of different distros having different packages in their standard repos.
In the absence of a package, installing from source seemed the obvious thing to do. So I made my way to ossp.org, from where navigation to an ossp-uuid source download is easy. Reassuringly I see Ralf Engelschall is in charge (whois lists him too), but worryingly none of the packages are signed. A summary look at the source package reassures me it looks fine, though I don’t have time for exhaustive review. In the unlikely event of a trojan package having found its way to the site, I expect some reader of my blog will alert me to the story!
Anyway, that’s getting ahead of myself. The unexpected problem I faced was actually downloading the package, which is available only through FTP. Firefox from home timed out; lynx or perl GET from the ec2 machine returned an unhelpful error. Looks like a firewall in the way of FTP building its data connection. Installing an old-fashioned commandline ftp I found neither active nor passive mode would work, meaning neither the client nor the server could initiate the data connection.
Before going into an exhaustive investigation of those firewall components over which I have control (my router being #1 suspect at home), I decided to try other routes. The problem was resolved when I was able to access the FTP server from my own (webthing) web server, then make the package available over HTTP from there to the ec2 box.
In the Good Old Days™ before the coming of web browsers and bittorrent, FTP was THE protocol for transferring files. In 1990s web browsers it shared equal status with HTTP and others, and even into this century it was widely seen as a superior protocol to HTTP for data, particularly bigger files.
Now by contrast, the widespread use of blind firewalls requires me to jump through hoops just to use the protocol. The rant I once published about everything-over-HTTP is coming to pass, and is not a good thing.