Online banking failure

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.

Grrrr ….

Whither FTP?

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.

The ghost of employment past

As is now semi-regular on a Wednesday, I had charge of Bud for the morning (dammit, that’s yesterday morning now – got distracted).  Great excuse for a walk and, in this season, a swim at Double Waters.

After lunch came the expected call from his daddy, and we wandered into town to return him.  I took the opportunity to use a cashpoint, and saw there at the bank a high-security van.  It was evidently loading/unloading high-value cargo: a man in full-face helmet and body armour was following an elaborate procedure involving locking himself securely in the van with his load before re-appearing and going back into the bank.  This happened a couple of times while I was there.

The van bore a G4S logo.  But what caught my eye was protected by DataTrak.  I haven’t seen that for a while, but in the distant past I worked for DataTrak, developing the technology.  Indeed, it’s one of the few jobs I’ve done where I was employed primarily as mathematician rather than as software/systems hack, and the work involved some serious maths, as well as programming the devices to run embedded in 128Kb (yep, remember kilobytes?  That’s how long ago) ROM.

Now, while the DataTrak work was (at its best) quite exciting, much of it had a clearly-limited lifetime.  The big investment in navigation infrastructure would be doomed to obsolescence if – as seemed likely – the GPS network became a viable alternative.  The data network had a longer lifetime but only until mobile telephony infrastructure offered a viable alternative at lower cost.  I have idly wondered what became of Datatrak after my time.

Actually, to be honest, yes I have googled, but seeing it again in real life prompted me to revisit it.  Seems it’s now a product of someone called Mix Telematics.  Yes, it’s moved to GPS and GPRS, but in terms of what the brochure tells us, it’s still clearly recognisable as what I once helped develop.

Here’s the site.

Training to be a victim

A couple of weeks ago, I received two essentially-identical letters in the post.  They claim to be from Capita Registrars. There’s a Capita logo, and a footer referencing contact details for Capita Registrars. So far so good, but does that mean they’re from Capita?  A competent fraudster might very well impersonate them to get my identity details and a foot in the door of my finances (whatever they may be).

The letters run:

IMPORTANT: Protecting your shareholding against fraud

Dear [me]

We have recently received an instruction to change details on your holding.
The following details have been changed:

- The way you receive your payments

If you did not ask for any changes, please contact us immediately by telephoning 020 8639 3312 or +44 8639 3312 if you are outside the United Kingdom.

This letter is sent in the interest of shareholder security so you can let us know if we have made any changes you did not ask for.

Yours sincerely

[scrawl]

For and on behalf of
Shareholder Security Team

I haven’t instructed them to make any changes, but I do have two new shareholdings with instructions to pay dividends direct to my bank account. If it’s genuine it’s good they’re taking care of security, but I can’t verify it.

• There is no reference to what shareholding they might be talking about.
• I can’t verify that phone number. Google finds it not on Capita’s pages, but in a list of 0208 numbers that have had complaints against them, which doesn’t exactly inspire me to ring it[1].

This is almost as bad as Verified by Visa.  Not quite as bad: the fraudster still has a way to go from convincing me to ‘phone their number to getting their hands on my assets.  But it’s the same principle: as soon as I respond to a letter, I’m doing exactly what a fraudster needs me to do to fall victim.  And of course, when I ‘phone the fraudster’s number, they will naturally need to ask a bunch of sensitive questions to verify I am really me: sufficient to identify me, and if they’re good at blagging they might get a whole lot more.

To follow this up, I started with Google and Capita, through which I established to my own satisfaction that the Capita Registrars website was genuine.  Searching it for contact information I could safely use, I found the choice of a couple of email addresses, or ‘phone numbers.  Or could I check it all myself online?

I tried signing up for Capita’s online shareholder services: if I can verify my shareholdings and associated payment details, I can see for myself whether the letters really need following up!  I’ve tried that before, but this time I carried it through.  I am indeed similarly signed up with other registrars: ComputerShare’s online service which works to a satisfactory level, and Equiniti’s which is amazingly bad but might at least have been sufficient to follow up these letters.

Signing up for this online service, I first gathered together all my Capita-issued share certificates.  Ten of them (seven distinct holdings; eight distinct stock codes).  Following the signup procedure, I entered the details for one of them and created an account.  From there I was able to verify that that shareholding was in order, but I was completely unable to access any other holding.

After trying every bloomin’ path in the system, I logged out, and tried logging back in using another share certificate.  It rejected the username/password I’d just created!  Seems the system requires me to create a separate account for every holding.  Indeed, not merely create it once, but log in eight separate times – each a complex process – any time I get a shareholder security letter in future.

Well, bugger this: surely I must be missing something????  OK, try emailing.  That got me an automated reply promising attention within 48 hours.  The following day a human reply, offering to ‘phone me and follow up on points I’d raised.  Great, I’m getting somewhere!

I took up the offer and they duly ‘phoned.  We were quickly able to trace the matter of the two letters to my new shareholdings, thus resolving the original issue.  I also raised my concerns about their system: letters indistinguishable from phishing, scarce information with which to follow up, and is their online system really as useless as it seems?

Encouragingly, the lady I spoke to sounded good: she wasn’t some call-centre drone reading from a script, and she sounded receptive to my points about phishing and unverifiable information.  She told me they were proud never to have suffered fraud, but that begs the question of how you count responsibility for a phishing victim who subsequently suffers identity theft but not loss of the specific shares.  I stressed that if it hasn’t happened yet, it can only be a matter of time.

On the question of their online services she confirmed yes, amazingly, they really are that bad!

Let’s see if anything changes following my call ….

[1] By posting here I’m creating another google result for anyone seeking to verify that number.  If you found it at random through a search, you probably don’t know me.  Am I who I seem, or part of the fraudster’s operation?

FOSDEM, and new PGP key

I’ve booked my travel and hotel for FOSDEM.  Arriving Friday early evening, leaving Monday after lunch, so I have a few hours beyond the core event.  Hope to meet some of my readers in person next weekend in Brussels!

In preparation for FOSDEM, I uploaded my PGP key to FOSDEM’s server for the keysigning – assuming I make it this year!  And in doing so, I found a spare round tuit to generate a new 4096-bit key in anticipation of a time when Moore’s law overtakes my existing 1024-bit key.  My new key has number B87F79A9 and fingerprint
3CE3 BAC2 EB7B BC62 4D1D  22D8 F3B9 D88C B87F 79A9
and should by now be propagating its way around the keyservers, along with my signature with the old key.

This year I’ll be actively looking at the jobs desk, for anyone whose needs might fit my expertise and aspirations.

Untainting in Apache HTTPD

Back in the early days of the web, before there was ever an Apache web server, the first widely-used language for web applications was Perl.  And the Perl community took a lead in raising awareness of security issues and promoting Good Practice, notably with their treatment of tainted data and untainting.

Not everyone has followed Perl’s lead.  Applications in, for example, PHP or C, must either re-invent the security of Perl’s untainting or do without.  Or they can delegate it to mod_security, at the expense of introducing a big third-party module and quite a lot more complexity.

So, what if you could do it within Apache itself?  Well, of course, you can, up to a point.  For example, to untaint your application’s cookie:

RewriteEngine On
RewriteCond %{HTTP_COOKIE} !cookie-match-pattern
RewriteRule .* - [E=MyCookie:substitution-string]
RequestHeader set Cookie %{MyCookie}e
.

Phew!  What a hideous hack!  Actually it’s untested: I don’t even know if it’ll work, but you get the point.  Complexity is the enemy of security, and this is already horribly complex before we even start to wrestle with the match pattern and substitution.

In fact it’s worse than that.  A client can send multiple Cookie headers (or any other header).  An attacker could do that to circumvent our protection: in outline, send a ‘good’ cookie to get through our rule, together with a malicious one to attack the application.  Oops!  Well, the directives we just used weren’t designed for security: we should’ve used mod_security instead!

Providing a small, simple untainting capability has long been on my wishlist, and now at last I’ve got around to writing a first draft mod_taint, simplifying the above to:

Untaint HTTP_COOKIE cookie-match-pattern substitution-string
.

with the added bonus of folding any multiple headers into a single line, to close off the multiple-header attack we identified.  In addition to request headers, it can check all aspects of the request line, including form data (though it cannot yet parse it).

The idea is that a simple and effective untainting directive could encourage the levels of usage seen in Perl/CGI, when the community rallied behind the idea of taint-checking every web-facing script.

Actually the mod_taint default is a little different: instead of fixing an unacceptable input, it will check that the request matches an acceptable pattern, and reject the request with HTTP error status 400 (Bad Request) if it encounters an unacceptable request field.  A server admin may also set an alternative error status.

Untaint RequestField match-pattern [error-status]
.

There are of course also things mod_taint won’t do.  It won’t do anything with POST data, nor will it alert you to intrusion attempts (beyond logging them).  That’s where you definitely want mod_security!

Question: do people think this feature should be in the core distribution?  Should I drop it in to trunk, so it’ll be standard in Apache HTTPD 2.4?

Bullied by Visa

I’ve banked with Nationwide for over 20 years.  During that time, I’ve been generally well-pleased with the service they offer.  From time to time the ‘industry’ has ganged up to impose new charges on customers: for example, annual charges to hold a creditcard, charges to withdraw money from each other’s cashpoint machines, or charges to use your card outside the UK.  Nationwide has always remained resolutely free of such things.  Furthermore, they don’t seem to cock up, and they’re the biggest UK bank to have escaped the crisis of the last couple of years without having to recapitalise (or much worse).  All in all, a huge relief compared to other banks I’ve used.

So when they messed up yesterday, my first inclination was to blame the merchant I was trying to use (Nokia).  This is part of shopping before VAT rises, and I was ordering some new kit to the value of over £500.  I wanted to query a couple of points, so I placed the order by ‘phone.  There followed an email confirming my order.  Five minutes later another email from billing@nokia:

Your order (No. 900937209) has been cancelled because we were unable to process your payment on the credit card that you provided.  We apologize for any inconvenience this may cause. Please visit our online store at http://shop.nokia.co.uk/nokia-uk to replace this order. Prior to re-attempting the order, we recommend that you contact your credit card company.

Sounds like a maxed out creditcard or something?  Nope, it’s about £5000 short of my limit, and is paid in full by direct debit every month.  Thinking the man who took my order might’ve cocked up, I went online and retried.

Same again.

OK, there’s a local Nationwide agency.  Not a full branch, but a little room in an estate agent.  They know me there.  I marched down there intending to give them a hard time until they’d sorted it.

They were closed.  Harumph!

Leaving a message is most likely going to miss the boat for 15% VAT.  Nothing for it, have to use the published ‘phone numbers and hope someone replies.  They did, and they were able to sort it out.  They also told me the Nokia purchase had put a security block on my card, which is what they had to remove!  After that I was able to place the order last night.

But hang on!  This is a purchase of physical goods.  That means there’s a shipping address.  The fact it’s the same as the billing address (which hasn’t changed recently) should be a pretty good indicator that it’s really me, not a fraudster.  What happens next time I need to settle a £500 hotel bill somewhere abroad, and perhaps in a remote timezone when there’s noone there to answer the phone.   Am I at risk of the same thing happening?  What’s the use of a creditcard if I can’t rely on being able to use it?

My strong suspicion is that this is because Nokia isn’t using phished by visa.  To me that’s a plus: I’m placing an order with them, and all is transparent and open (the quirks of Nokia’s system are another story, but no showstopper).  I’m guessing this kind of block might be becoming routine for online retailers who decline to be bullied into it.  Grrr

Postscript: as I write, I just had a phone call from the man I originally placed the phone order with, to tell me the order had failed.  Of course I already knew, but it’s good that he took the trouble.

Bah, Humbug.

Phished by Visa

The title is in honour of Ben Laurie’s excellent piece here.  Ben is by any standard a leading expert in online security, and his short article is strongly recommended reading for anyone who shops online.

I’ve just placed an order with ebuyer, timed to get a few bits & pieces before VAT goes back up.  Ebuyer seems like a good bet these days: they’ve done nothing to force me to blacklist them (e.g. Dabs), nor is their website full of flash crap to make it painful to use (e.g. Scan).  And I’ve been happy with them in the past, as a low-cost retailer that delivers efficiently.

The shopping and ordering process went smoothly, marred only by one item of six on the shopping list being out of stock (I’ll try Argos next – they probably have an equivalent).  I entered all the usual details including my Visa creditcard, and it appears to have accepted my order.

It then took me to a “Verified by Visa” screen.  This was in a frame, and the frame contents were generated by a script, so I could not easily verify where my sensitive data were being sent.  This is precisely the phisher scenario, and a magnet for identity theft, as Ben describes!  I reluctantly submitted the first VBV screen, as it hadn’t required sufficient sensitive information to complete a phish.

The second screen then asked me to create a new VBV password.  Since I am already (reluctantly) signed up for VBV, I pulled out at this point and sent a note to ebuyer under the heading of reporting a website security issue.  Having said that, the issue appears to be with VBV rather than with ebuyer, and the fact that my purchase was accepted seems to indicate that VBV was, despite appearances, not actually required.

Grrr ….

mod_security handbook

I’ve just download a preview of Ivan Ristic’s latest work: a handbook for mod_security.  Readers will recollect that Ivan is both the original developer of mod_security, and author of the most comprehensive existing book on Apache security (reviewed here), so his handbook should be worth a look.  He was also tech reviewer for my apache modules book, so I guess I owe him any feedback I can find time for!

As befits a handbook, it’s a lot shorter than his previous book: currently about 100 pages, though that’s with gaps that’ll grow the page count quite a lot when filled.  It comes with the promise that it will be continually updated, which clearly favours electronic distribution, though paper will also be available.

The first question I usually ask about a techie book is: what does it add to the documentation available online?  A glance at this book suggests, quite a lot.  My impression of mod_security hitherto has been that it’s interesting (especially after seeing Ivan’s talk at ApacheCon 2008) but under-documented compared to httpd itself: this book fills a gap.  It could become the One True reference work on the subject for anyone deploying the module.

For my part, I’ll be looking with particular interest at how he deals with rulesets.  They’re the aspect of mod_security that’s outside my core competence as developer and in the realm of the sysop.  I don’t believe I have a use for mod_security myself, but a new insight into how he maps use cases to rulesets might provoke me to re-evaluate that.

I have one reservation about reading this: I have several ideas for the apache core that very probably duplicate things mod_security offers.  No, they wouldn’t be in competition with it, they’d just be offering comparatively minor features: for example, extending the “RequestHeader edit” feature of mod_headers (apply a regexp search-and-replace to incoming request headers) to a security feature.  Reading the book runs the risk of my ideas becoming ripoffs of mod_security.

mod_noloris: defending against DoS

The slowloris script kicked off a lot of discussion, including my own recent blog piece.  A range of defences have been discussed, and deployed by individual users.  But I think this discussion highlights the need for a proper response from the apache community.  Not just in the future, but now: something users of at least our current stable releases (2.2.x) can deploy.

So today I committed a new module mod_noloris to svn.  mod_noloris works by taking snapshots of the total number of connections in READ state per-client, and denying new connections to clients having already too many such connections.  Configurable parameters are the interval between snapshots (default: 10 seconds), the number of connections permitted per client (default 50), and a “whitelist” of trusted clients that will be allowed unlimited connections so you don’t, for example, lock out users of your company’s proxy on your company site.

This is work in progress, and far from perfect.  One issue is that an attack won’t be detected until the next snapshot, and that still leaves an attacker scope to DoS a small server with a small number of slowloris clients.  But having it in the repository should attract eyes to it, and help it mature.