A cup’o java for the opera… [Freebsd 8.0 amd64; Opera 9.x/10.x; Diablo-JRE 1.6]

Not exactly security related but an issue which digested about five hours of my time.  To get java applets to work with Opera on FreeBSD using the Diablo JRE:

1. Install Diablo 1.6 JRE, probably easiest trying to install from the port tree and then downloading what it asks, which includes the binary for Diablo.

2. You’ve got Opera amd64 installed, right?

3. Now, Opera does not use a plugin library as Mozilla does but rather uses the java shared libraries directly, specifically libjvm.so and libawt.so.  In the Opera configuration, set the Java path to /usr/local/diablo-jre1.6.0/lib/amd64/ and click ‘Validate’ – it should show as correct.

4. For some reason, libjvm.so is in the subdirectory ./server/ where Opera doesn’t find it.  The dirty way to resolve this is to just symlink it:

ln -s /usr/local/diablo-jre1.6.0/lib/amd64/server/libjvm.so /usr/local/diablo-jre1.6.0/lib/amd64/libjvm.so

5. Run Opera, et voilà – it works!

What was that you said? [Proof of concept GSM security break]

Well, it’s finally happened: the elements necessary to build a computer setup capable of passively decrypting GSM have been cobbled together by cryptographer/computer scientist Karsten Nohl. It has been known for some years now that A5/1 – the stream cipher used to protect most GSM calls – was weak, c.f. the wikipedia page on A5/1 for a list of results. Practical attacks were considered slightly more difficult due the requirement for radio equipment and computation time. So despite expensive commercial products being available for a long time, there hasn’t been anything concrete that the general public can try. Until now.

Unveiled at the Chaos Communications Congress, he presents a solution utilising easily available open source software, inexpensive radio equipment and recently available rainbow tables. The combination means that it is now possible to capture and decrypt packets with a high degree of certainty.

What does this mean? It means that monitoring mobile calls and text messages is no longer limited to the Police, Government and criminal gangs that can afford the existing equipment retailing at around £20,000 – any spotty teenager that can afford around £1,500 worth of equipment can in theory intercept your calls. And make calls from your number, and fake SMS messages from your number, etc.

The bright shining light that the GSM consortium had in mind to replace A5/1 – A5/3, which is really just the Kasumi block cipher – is not going to help. Well, on a cursory reading it seems to depend on who you ask: the documentation I had previously read suggested the protocol was changed and that although Kasumi has theoretical breaks, it would be beyond the boundary of a practical attack (where have we heard that before); the presentation slides provided by Nohl however suggest that the mobile handset can be forced to encrypt packets using A5/1 with the same key allowing key recovery, and that Kasumi is fairly weak. Perhaps I’m just mixing up 3G specifications with the older GSM specs… if anyone actually knows the details here I’d appreciate them.

Personally, I think all this is a good thing: it evens the paying field – now everyone should know the security risks with non-provider mobile phone monitoring, not just criminals and bored rich folk.

There are commercial products available – again at significant cost – that can protect mobile calls by using strong encryption and forwarding calls via the data channel; they only however work on certain mobiles and are not in wide use. Given the ever increasing bandwidth available on mobile devices, I cannot imagine it will be long before an open source project pops up with a cross-platform solution of similar nature. The one caveat is that both handsets in the call must use the same software.

Call me daft, but that isn’t secure. [Bank telephone security]

In the past few months, I have become increasingly aware of a glaring problem with the security model banks, utility companies, et al, use for their customer services. So a slightly irate and vitriolic post follows…

As online security gradually improves, the security of telephone based services has either stagnated or actually deteriorated. The old maxim of a chain being only a strong as it’s weakest link is sitting in eager anticipation of again being proven correct.

The problems can be split into some broad classifications:

i) the protection against replay attacks that (most) banks use for their online services are not used over the telephone;

ii) authentication credentials are often shared between strong online and weak phone services;

iii) static personal details are used as part of the authentication process over the telephone;

iv) there is an invalid assumption made that the phone call is private and secure;

v) telephone requests tend to “trump” anything done via online services;

vi) unsolicited calls are made from banks to customers that require only the customer to authenticate;

vii) catch phrases are overriding common sense.

The first problem highlighted above, (i), can be illustrated by example. Most banks request only a subset of a “PIN” or password when authenticating to an online banking service, however over the phone almost all banks ask for the full login credentials. For example, the Co-operative Bank has recently improved it’s online security immensely: logins only request a subset of details, there is a second stage of authentication whereby a random selection of one of four preset questions are asked, and most importantly before any transaction can be performed it must be authenticated via a smart card + card reader device. However, upon phoning, the automated service immediately asks for the full PIN. The problem is exacerbated by (iv), specifically that online services are at least encrypted using SSL/TLS, however phone calls are easily tapped if the attacker is physically in the local area.

The second problem, (ii), has some not-so-subtle ramifications. If a phone call to a bank’s customer services is monitored by an attacker, they will often have the credentials necessary to login online. From an anonymity point of view, it would be much more favourable for an attacker to action transactions using the online service as opposed to the telephone service.

The third problem, (iii), is that most telephone services use an automated system that verifies account number against “PIN” or password, then passes the call onto a real advisor. At this point, the advisor will attempt to further confirm the callers identity by asking the standard “name, address, postcode, date of birth” questions. Unfortunately, unless you are the Messiah, things like date of birth won’t change that often. So considering that these details are usually easy to come by and are exposed over an unsecure line anyway, it is worrying that so much trust is placed in them.

The fourth problem, (iv), is that most banks, government departments, etc assume that the telephone is a secure method of communication. It is not. Technologically, it is trivial to tap a person’s phone line. I have lost count of the amount of very personal details and information that I have had no choice but to submit over the phone.

The fifth problem, (v), is that once you’ve authenticated yourself to a bank or similar institution over the phone – they will usually action almost anything. So if an attacker has managed to garner your authentication credentials from previous phone calls, they will pretty much have carte-blanche.

Now onto (vi). This is probably the most concerning development. In the last six months I have had a bank, a utility company, and several other similar institutions phone me without my prior request, then ask me to authenticate myself to them. Each time I have illustrated that I do not know who they are, and they they could be a complete stranger calling to obtain my details. Out of the lot of them, the only one to both understand what I was saying and to be able to appropriately authenticate themselves to me first was Scottish Power.

The last one is more insidious than it first appears, (vii). When I challenged the customer services representatives over (vi), the response I got to every question was “but it’s Data Protection”. It was obvious that the person on the other end of the phone understood what I was saying but it seems company policy generally overrides the security beneficial attribute of common sense. So the public are now left trying to swallow a bunch of meaningless catch phrases like “data protection” and “passing security”: I wonder how many of the people writing the guidelines for these departments has ever read the contents of the Data Protection Act.

There are of course mitigating factors. The two that come to mind are using a 3G mobile which has half decent encryption as standard for (iv), and caller id for (vi). However these are not always available and are not addressing the core problems: namely that trust in the security of phone services are vastly over estimated.

Ah well, rant over.

UPDATED 12th April 2010: Added [] extra meaning in title; changed author.

Open sesame! [WordPress 2.8.3 change password vulnerability]

Well that was fortuetous! I was trying to find details on why the Suhosin extension keeps segfaulting PHP 5.2.10, and somehow ended up at Milw0rm reading an article on PHP include security. It’s been a while since I’d read anything on the site so thought I’d have a gander at the list on the main page and low-and-behold a remote adminsitrator password exploit for WordPress 2.8.3 was there, and at the time of writing is two days old. The exploit is one of those really simple and effective ones, whereby passing an array instead of a string bypasses some conditional statements; the full article is here.

This is the kind of security failure that can really bite. It would be trivial to write a script to exploit en mass thousands of WordPress installations and then post spam messages; my only surprise is that after two days nobody has caught on. Well, maybe someone has caught on and my sites are far too small to be indexed, and hence were not afflicted. Having said that, Akismet catches about fifty spam comments a day so it is still a target, albeit small.

Needless to say, I’ve upgraded my WordPress installs. It has also forced me to think of tightening my database security. To date, I’ve never gotten more granular than assigning specific permissions to different tables, and even that is rare: usually I just assign blanket permissions for a database. Given that this exploit would have been stopped if the password column or the specific row for the administrator password was read-only, being a little more prudent in the future may be a smart idea. It doesn’t suggest that every row or column in a database has to be fine tuned, however protecting those critical records or fields that are easily targeted would likely pay off in the long term. MySQL does row and column level security… doesn’t it?

Another illustration of why defense-in-depth can save the day. Oh well, it looks like I’m tweaking my MySQL installation tomorrow. Having said that, I’m a little annoyed with whoever wrote that bit of PHP code in the first place. Personally, I’m no software engineering guru but checking types before comparison operators generally doesn’t escape me (no pun intended), and certainly within security critical code like password changing. The problem may be two fold: PHP allows the programmer to write sloppy code in the first place, there is no necessity to be particularly aware of changes of variable type; the other reason I surmise is that if someone has learnt programming using a strongly typed language like Pascal, ADA or the like then considering variable type is burnt into your brain. Even C forces you to think about it, although you are given a lot of latitude to screw things up. The combination of people who have either learnt to program using PHP or predominantly use PHP and the loose type checking in PHP has created a problem that will just keep recurring.

Is it possible to construct a nice little security utility that checks PHP code and gives output of the form: “transparent cast from array to string on line xxx, do you really want to do this”? Would anyone use it?

UPDATED 12th August 2009 @ 22.00pm: According to a notice on the WordPress site, here, the vulnerability causes a new password to be emailed to the account owner’s email… so isn’t as bad as I thought. Suppose it also pays not to write posts at four in the morning.

UPDATED 12th April 2010: Added [] extra meaning in title.

Past expoits, new trend? [Attempted retrieval of /etc/passwd in httpd logs]

There isn’t precisely a flood of traffic on this site, so I occasionally take a gander through the logs. The webserver logs are invariably besought with a somnolent assortment of search engine crawls, spam postings, impotent securty attacks, footling scans, and – if I’m lucky – a few “real” page views. Today amongst the clutter, I saw something of some meagre interest. Someone had tried what would at first glances seem an antiquated attack: trying to retrieve the /etc/passwd file c.f. Firewalls and Internet Security: Repelling the Wily Hacker; Cheswick & Bellovin.  The appropriate line from my httpd log is as follows:

62.1.205.86 – - [26/Apr/2009:22:18:43 +0100] “GET //index.php?view=../../../../../../../../etc/passwd HTTP/1.0″ 301 – “-” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070400 SUSE/3.0.1-0.1 Firefox/3.0.1″

(The PTR record for the IP being venus.marinet.gr.)

At first, I was quite ammused; I thought that it was a refreshing change to see someone throwing an attack with at least a mien of intent, albeit out-dated by about a decade and probably scripted.

Indeed, if I had been running a very poorly configurated httpd server it may have given the attacker the /etc/passwd file.  Notwithstanding that, even if the attack had suceeded in retrieving the /etc/passwd file, they would have recovered no password hashes as I run FreeBSD; they are looking in the wrong place.  They would also have to invert the ‘Blowfish’ password hashing scheme used in FreeBSD against a high entropy password.  Finally, there is that minor peccadillo of not having a login service available to try the password against.

Aside from those minor complications, I thought the furtive little attempt rather cheeky, and had a chuckle. On a closer inspection however, I found another entry in my httpd logs:

66.249.70.42 – - [27/Apr/2009:00:28:08 +0100] “GET /?view=../../../../../../../../etc/passwd HTTP/1.1″ 200 44729 “-” “Mediapartners-Google”

An IP which is apparently owned by none other than the mighty Google itself.  So, why in holy googlebot is Google trying to retrieve the /etc/passwd file? This I have taken with more than a small pinch of demur.

There are two possibilities:

i) Google is going on a hacking spree – an unlikely reason unless the development team are insufferably bored after all the excitement of taking over the world;

ii) there is some peculiar search engine magic brewing, perhaps there are a few malcontents out there submitting these URLs to Google to crawl.

In an attempt to discern the origin of this, I’d emailed Google’s security lot at the beginning of the week. In a blatent act of solecism, I have decided to post this now instead of waiting the mannerly week. In the mean time, if anybody has seen similar logs or knows what this is then please post a comment.

UPDATED 12th April 2010: Added [] extra meaning in title.

Knowing me, knowing you… ah-ha! [The hidden 'credit reference agency' - N Hunter Limited]

This evening, I stumbled accross an article on the Guardian’s website; it details a little known agency which is apparently owned by banks in the UK and processes “fraud” data collected from credit applications.

Unfortunately, this agency is not well known at all – I certainly didn’t know about it. If nobody knows about it, then they cannot check the information held is correct nor challenge any data held. According to the article at least, the agency’s heuristics are also questionable: it uses previous application information to assess suspicious changes in a person’s income, employment, variations in identification documents and even if the same mobile phone number has been used on two different people’s applications. I can think of a number examples which would trigger those rules in legitimate scenarios.

According to the article, the company also charges the maximum charge for a subject access request under the Data Protection Act, whereas normal credit reference agencies charge a nominal £2.

To make things worse, the agency’s address is a “PO Box” address – something that I suspect if were on an normal application for credit would cause it to be turned down and marked as possibly fraudulent.

In the next few weeks, I intend to post several articles on the issue of how our data is handled by credit referencing agencies and financial institutions but I thought this was a corker to start off with.

The agency’s website is www.nhunter.co.uk, its advertised address is:

N Hunter Limited
PO Box 2756
Stoke-on-Trent
ST6 9AQ

It has no email or telephone number.

Looking up the whois entry for the domain name you get this address:

1 Bungalow, Rownall Road, Werrington
Stoke on Trent
Staffordshire
ST9 0JB
GB

which is pretty suspicious, as it looks like a residential address.

The IP seems to belong to Avensys Networks, AS8553.

If anybody has additional information on this agency, or how widespread their use is within the banking sector, then please post a comment or contact me.

UPDATED 12th April 2010: Added [] extra meaning in title.

Fiddle, fuddle [Unicode characters in Openoffice under Gnome]

Slightly off topic, but annoying enough that I thought it worthwhile.

If you’re ever trying to work out how to enter unicode characters with keyboard shortcuts in Openoffice under Gnome, then it’s Ctrl+Shift+u+XXXX+Space (where the XXXX is the unicode number), the space is the extra spice needed in Openoffice that isn’t needed in other Gnome apps. You wouldn’t believe how annoying that was to find.

UPDATED 12th April 2010: Added [] extra meaning in title.

Sgàil Revisions & Corrections

Well, its finally been done – Sgàil has been updated to fix the error described in this post which allowed second pre-image and collision attacks. An error in the reference implementation has been remedied, and a number of typographical corrections have been made to the specification. The known answer tests and intermediate value results have also been regenerated.

Although version 0.4 is considered to be immune to the previous design error and was submitted to NIST, it has not yet been approved/rejected as an official change. Updates will be posted as they happen.

Changelogs have been included in the Supporting_Documentation directory.

The performance of the reference implementation has dropped from 62 cycles/byte to 71 cycles/byte in asymptopic behaviour due to the corrections made to the key schedule. It is expected that an optimised version can improve this to at least 40 cycles/byte; I’m looking at coding this in the near future.

UPDATED 11th December 2009: I really should have updated this about six months ago; the corrections were not accepted by NIST and Sgàil did not progress to Round 2.

It’s crypto, but not as we’d like it cap’in. [Cryptography implementation failures and misattribution of trust]

How many times have you looked at an apparent security measure and wondered what on earth was going through the mind of the person who implemented it?  Take the example of the humble garden shed; usually constructed from painfully thin wood panels nailed to a dodgy timber frame.  Then you look at the door and you see a padlock that looks like is was bought in a fire-sale from Alcatraz.  In reality, anybody wanting to steal from the garden shed would just kick in a few of the wood panels.

This sad state of affairs is pretty much what we’ve got as far as web and email security these days.  The recent proof of concept that created a real rogue CA certificate using MD5 collisions is a prime example. Everybody has known for quite some time now that MD5 is not collision resistant, it is so broke that collisions can be found within minutes on any standard desktop or laptop. That combined with the normal issues that arise with the use of HTTPS as I discussed previously really does leave web security in a sorry state of affairs.

There are sites that use decent certificate authorities (the ones that issue their certs using the SHA family and do more thorough checks before issuing a cert in the first place), and also implement HTTPS in a proper and secure manner. Most financial institutions, for example, follow good practice. Unfortunately, banks and financial institutions have also tacitly instilled a sense of trust amongst the web user. We assume online banking is secure, and online banking uses SSL/TLS: so other sites that use SSL/TLS must also be secure – and there-in lies the problem. It is in part why phishing sites work so well, we know our online banking is secure and the website in front of me is my online banking site… well, er, it certainly looks the same. How many times have you actually read and checked the warning your browser periodically spits out about certificate validity? For me its 50/50 at best, and I know better.

A fine example of this misplacement of trust was no better demonstrated than in a conversation I had the other day. The conversation in question was about how PGP public keys are exchanged. I’d highlighted that you have to get the fingerprint verified (either in person, over the phone, or by a trusted third-party keysign) before accepting or signing someone else’s public key. The response I received was somewhat dismissive – and this was from a group of information security professionals. Missing that one critical step may seem insignificant but it completely defeats the entire security model, hence rendering the use of cryptography in that situation nothing more than a big padlock on a wobbly garden shed.

So what’s my point? Firstly, technologies that employ the use of cryptography have to do it properly, or not at all. This blasé, half-assed, approach by developers and users alike is actually harmful; it takes hard earned trust from one area and transfers it into a wide-spread false sense of security. The second and more important point is that developers and system designers really need to shoulder much more of the responsbility. It’s not your email provider that’s going to have to deal with the fall-out of your account being hacked, it’s you. The business that’s purchased a cert from a CA that uses MD5 and had a load of their customers defrauded will have its reputation in gutter while the CA sits pretty.

The result of this is that its in our hands. If our browser spits out a warning about a site certificate, check it and find out why, then promply complain to the company in question. If your webmail provider isn’t using SSL/TLS properly then complain, if it’s not fixed then move providers. Probablty the best example of what end users screaming about an issue en masse can do is with Microsoft: for years their products were pretty bad in the security stakes, I would argue that there have been vast improvements since.

UPDATED 12th April 2010: Added [] extra meaning in title.