Friday, November 06, 2009

Security Now #221

I was a guest on Security Now this week and the podcast has now been released (as has a transcript). Steve Gibson and some other people asked me to provide the presentation in some relatively readable format.

The original presentation is here, but it, ironically, requires JavaScript and Adobe Flash. So here are two additional formats: old style Microsoft PowerPoint and PDF.


Tuesday, September 29, 2009

Solving the XSS problem by signing <SCRIPT> tags

Last week I talked about JavaScript security at Virus Bulletin 2009. One of the security problems with JavaScript (probably the most insidious) is Cross-site Scripting (which is usually shortened to XSS).

The basic defense against XSS is to filter user input, but this has been repeatedly shown to be a nightmare. Just yesterday Reddit got hit by an XSS worm that created comments because of a bug in the implementation of markdown.

I believe the answer is for sites to sign the <SCRIPT> tags that they serve up. If they signed against a key that they control then injected JavaScript could be rejected by the browser because its signature would be missing or incorrect and the entire XSS problem would disappear.

For example, this site includes Google Analytics and here's the JavaScript:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ?
"https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-402747-4");
} catch(err) {}</script>

Since I chose to include that JavaScript I could also sign it to say that I made that decision. So I could modify it to something like this:

<script type="text/javascript"
var gaJsHost = (("https:" == document.location.protocol) ?
"https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +

<script type="text/javascript"
try {
var pageTracker = _gat._getTracker("UA-402747-4");
} catch(err) {}</script>

The browser could verify that everything between the <SCRIPT> and </SCRIPT> is correctly signed. To do that it would need access to some PK infrastructure. This could be achieved either by piggybacking on top of existing SSL for the site, or by a simple scheme similar to DKIM where a key would be looked up via a DNS query against the site serving the page.

For example, could have a special TXT DNS entry for which would contain the key for signature verification.

To make this work correctly with externally sourced scripts it would be important to include the src attribute in the signature. Or alternatively an entirely new tag just used for signatures could be created to sign the HTML between the tags:

<sign sig="068dd60b18b6130420fed77417aa628b">
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ?
"https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-402747-4");
} catch(err) {}</script>

Either way this would mean that JavaScript blocks could be signed against the site serving the JavaScript completely eliminating XSS attacks.

Note that in the case of externally sourced scripts I am not proposing that their contents be signed, just that the site owner sign the decision to source a script from that URL. This means that an XSS attack isn't possible. Of course if the remotely sourced script itself is compromised there's still a problem, but it's a different problem.


Friday, September 25, 2009

JavaScript must die

I've just completed my presentation at Virus Bulletin 2009 which was entitled JavaScript Security: The Elephant running in your browser.

My thesis is that the security situation with JavaScript is so poor that the only solution is to kill it. End users have very little in the way of protection against malicious JavaScript, major web sites suffer from XSS and CSRF flaws, the language itself allows appalling security holes, and as data moves to the cloud the 14 year old JavaScript security sandbox becomes more and more irrelevant.

Here are the slides:


Saturday, August 15, 2009

Geek Weekend, Day 1: Bletchley Park

Left to my own devices to the weekend I decided to embark on a Geek Weekend with visits to two places within easy reach of London. Today I visited Bletchley Park which is simply wonderful for any geek out there.

Bletchley Park is where the cryptanalysts of the Second World War worked in great secrecy (including Alan Turing) to break the Nazi German Enigma and Lorenz ciphers. To break them they used a combination of intimate knowledge of language, mathematics and machines.

Here's a Nazi German Enigma machine:

And here's a look inside one of the rotors inside an Enigma machine to see the wiring:

Two of the code breaking machines have been reconstructed. One is the Turing Bombe, an electromechanical machine made to break the Enigma cipher. Here's a look at the wiring in the back of the Bombe:

The other machine is the Colossus, a binary computer built to decipher Lorenz. Enigma is far more famous than Lorenz, but I have a soft spot for the Lorenz code because of its close relationship to modern cryptography. Here's a Lorenz machine:

While I was there I signed a large stack of copies of my book, The Geek Atlas. If you are at Bletchley Park and pop into the shop you'll be able to buy a signed copy if that's your thing. Of course, Bletchley Park, Enigma, Lorenz and the National Museum of Computing (also on site) are covered.

50p from every copy of The Geek Atlas goes to Bletchley Park (if the book is bought in the UK) and so the folks at Bletchley treated me to a special geek moment: a chance to meet Tony Sale who worked at MI-5 and reconstructed the Lorenz breaking machine Colossus. He took me round the back of the machine, and past the No Admittance sign to see it in operation. A geek treat if ever there was one.

The Lorenz code is essentially binary. Letters were transmitted using the Baudot Code which is a five-bit code. To encrypt the Lorenz machine created a pseudo-random sequence of Baudot codes and then XORed them with the message to be transmitted. If both transmitting and receiving machines generated the same pseudo-random sequence then the nice property of XOR that if you perform the same operation twice you get back to where you started. Thus XORing once with the pseudo-random sequence gave you the ciphertext to be transmitted, XORing again gave you back the original message.

Breaking this binary code was achieved with a binary computer. After giving me a behind-the-scenes look at Colossus, Tony Sale stood for a portrait in front of the machine:

And behind the machine is where the valve-action is:

Standing and see the Turing Bombe, staring into Turing's office in Hut 8, being taken around the back of Colossus by the man who put it back together, and getting to see more Enigmas, Lorenzs and Typexs than anyone could ask for made it a real treat.

The National Museum of Computing is Britain's answer to the wonderful Computer History Museum in Mountain View, CA. It contains many machines from the mainframe through the 8-bit era of British computing. All the machines are working or being restored. If you've never seen core memory, massive hard disk packs the size of washing machines, or just Commodore PET it's worth visiting (and it's right next door to Colossus).

Lastly, it's worth knowing that the National Museum of Computing despite being part of the ticket price to Bletchley Park actually receives no money from them. Please consider either donating money directly to them (I gladly emptied my pockets of change) or buying something in their shop.

And tomorrow it's a step back into the 19th century with a special visit to a place important in the life of Isambard Kingdom Brunel.

Labels: ,

Tuesday, August 04, 2009

My Alan Turing petition

A while back I wrote about the appalling treatment of Alan Turing and suggested that the UK government should apologize. Someone suggested that I turn this into a petition to the UK government.

That petition has now been approved.

If 500 people sign it there will eventually be a response from the government to the petition. If you are a British citizen and wish to sign the petition you can do so on the Number 10 web site here.

Labels: , ,

Thursday, July 16, 2009

TechCrunch: Skating on Thin Ice

Back in the day I used to do naughty things to computers that I could access via dial-up modems, packet switching or the nascent Internet. Nothing that caused any damage, but it made me realize how insecure most systems are.

I don't do that stuff anymore (although I can't help noticing security holes that turn out to be exploitable) and yet it amuses me greatly when I see someone bleating about a third party's security troubles.

Take for example TechCrunch. Today they made fun of Twitter for using the password password for access to an administration web site. Yep, that's a really bad idea.

But if you're TechCrunch and you are going to publish that sort of gloating article you'd better be damn sure that your own security is solid. And your security envelope can be very large. It encompasses all the services you use like your domain registrar, DNS provider, hosting provider, mail service and the software used to run your site.

Any one of these elements could be a vector for an attack.

You really wouldn't want it to be the case that someone like me could trivially discover that one of those services was vulnerable because I could guess in 30 seconds what your username was likely to be, and then find that I could order a password reset using three pieces of personal information that were easy to find out.

You wouldn't want that to happen.

Because if someone like me did that they'd be able to mess with your web site, play with your email, and generally create havoc.

Happily, I've got better things to do.

PS Personal information like "the name of your first dog" or "your brother's middle name" needs to be phased out. Google allows you to set your own security question; if you don't have that choice do as I do: lie. Whenever I'm asked for the name of my first girlfriend I make the answer up.

PPS Some people have asked me if this post is a threat to TechCrunch. No, No, No. I'm not interested in threatening them. Why would I? It's also not an incitement to attack them. It's meant as a warning to them that spouting your mouth off about the security of other people's systems is waving a red flag to a bunch of people who'd like nothing better than to mess with your systems. Don't be silly like that.

UPDATE: TechCrunch got in contact and we had a quick back and forth. They confirmed that the security vulnerability I was pointing out was something they had worried about already and taken action to mitigate.

They also said "We have had thousands of breakin attempts over the past few days". No surprise really.

And they are planning some posts pointing out the vulnerable nature of apps in the cloud.


Thursday, June 25, 2009

Michael Faraday criticizes 'security theatre' from beyond the grave

I was reading David Knight's book Humphry Davy and at one point he describes the arrival of Davy and Faraday in France in 1813:

On arrival, Faraday reported, they were searched, an unusual experience for a true-born Englishman: 'he then felt in my pockets, my breast, my clothes, and lastly, desired to look into my shoes; after which I was permitted to pass', and could hardly help 'laughing at the ridiculous nature of their precautions'.

Lucky he doesn't have to fly anywhere.


Tuesday, May 05, 2009

Can you trust Paul Graham with your password?

The other day I asked Can you trust 37signals with your password? and the good folks at Hacker News responded on their forum and here on my blog. Driving back home the other day I suddenly wondered how good a job Hacker News was doing of keeping my password safe.

The answer is... only marginally better than 37signals. Since the source code of the web site is available it's possible to dig in and find out how Paul Graham handles password authentication.

The good news is that he doesn't store passwords in plain text. And even better he uses a one-way hash function (SHA-1) to verify passwords. When you enter your password it is hashed using SHA-1 (he uses OpenSSL's implementation of SHA-1 to do the hashing) and then stored in a file called arc/hpw. When it comes time to verify a password the hash from the password file is read and compared with a hash of the password you typed in.

(def good-login (user pw ip)
(let record (list (seconds) ip user)
(if (and user pw (aand (shash pw) (is it (hpasswords* user))))
(do (unless (user->cookie* user) (cook-user user))
(enq-limit record good-logins*)
(do (enq-limit record bad-logins*)

(def shash (str)
(let fname (+ "/tmp/shash" (rand-string 10))
(w/outfile f fname (disp str f))
(let res (tostring (system (+ "openssl dgst -sha1 <" fname)))
(do1 (cut res 0 (- (len res) 1))
(rmfile fname)))))

The good news is that this means that if arc/hpw were stolen a hacker wouldn't be able to read the password from the file directly. The bad news is that the file is readily attackable using a rainbow table. If you got access to his password file, the passwords within it (unless they were really, really good passwords) would be broken in seconds or minutes.

That's a pity since he could easily have implemented a salted hash and he would have had a first line of defense against a rainbow table. The current implementation is little better than a plain text password file.

Even better he could have swapped SHA-1 for a slow algorithm like bcrypt. With salted bcrypt rainbow tables are out of the window, as are password crackers that rely on running a dictionary plus salt through the hash algorithm.

Labels: ,

Friday, May 01, 2009

Can you trust 37signals with your password?

Recently, 37signals blogged touting their security in dramatic marketing terms. It's a pity that the reality doesn't match the claims.

Two of the major claims on the security page are Your data won’t be compromised and Our systems are hacker safe. And the related details talk about the firewalling and physical security of their data center. All that's great.

But there's a dirty little secret. 37signals stores passwords in plain text in their database (or, as commentators have pointed out, they could be storing the password encrypted using a key available to their application server; either way the password can be recovered by a hacker who gains access to their server). I found this out today when cancelling my Highrise account. I'd forgotten the password and so I went through password recovery. It instantly emailed me my password.

I'd expected to receive a temporary password and be asked to change it. But 37signals stored my password in their database and was happy to email it out. For me this isn't a disaster because I generate unique passwords for each registration, but for lots of people this is a big problem. Plenty of people use the same password on many different sites.

That means if one site is compromised hackers can get access to all those user's other accounts. And a compromise can come in various forms. It could be actually hacking into 37signals, or it could be getting access to an old backup of their database.

But there's a solution to this, it's easy to implement, it completely eliminates the problem even if their site is hacked, and it's a security best practice. There are plenty of good descriptions of how to implement it. The Unix operating system has been doing this since the 1970s, so why is 37signals not doing it? Hard to tell.

In a posting in 2007, Jason Fried said that they planned to change this, but now it's 2009.

There's no excuse for this sort of lax security, if 37signals got hacked they'd have to bow their heads in shame in front of every single one of their customers and admit that their password had been stolen. Why take the risk?

Labels: ,

Tuesday, February 12, 2008

The leakiness of web mail

Many people seem to use web mail systems like Hotmail or Yahoo! Mail as a way of providing anonymity. This is a mistake because all these systems leak the IP address of the machine the user is typing on!


Here are part of the headers of a message that a family member sent me from their Hotmail account:

Received: from mail pickup service by with Microsoft SMTPSVC;
Received: from by with HTTP;
X-Originating-IP: []

This leaks that original IP address ( twice: once in an X-Originating-IP header and once in the first Received header which indicates that it was received from the same IP address using HTTP (i.e. using the web). A quick lookup shows that that IP address is in Birmingham, UK (which I happen to know is correct). So, if they were trying to keep their location secret, they've failed.

A whois lookup on that IP address tells me even more information, including that fact that is belongs to an Aston University. So, it's easy to conclude that this family member was student or staff at that university.

Yahoo! Mail

Yahoo! Mail leaks in a similar way. Here are part of the headers of a message I received from someone with what looks like a random email address and no name:

Received: from [] by via HTTP;

Geo locating that IP address shows me that the writer is in Tunisia.

Another Yahoo! Mail leak from an old colleague in California let's me track down their home city from their DSL line.

Received: from [] by via HTTP;

AOL Mail

Here are some headers from a message sent from an AOL web mail account that reveal that the sender is in Germany and looks like it gives away the name of the company that they are working for in the DNS name of the machine:

X-MB-Message-Source: WebUI

The X-AOL-IP gives the IP address of the machine that generated the message (i.e. where the web browser is running) and the helpful X-MB-Message_Source tells us they are using the web interface.


Here's an email I received from the editor of Wired who was using Earthlink:

Nice one! When I get off dialup from the French countryside, I'll blog

Was he really in France?




A search of my own email showed me that X-Originating-IP is a popular leak point (used by,, Network Solutions, and others).

Google Mail and Hushmail

Neither Google Mail nor Hushmail appear to leak the IP address. They may include the IP address (for example, in the Message-ID) but it does not appear to be readily discoverable.


Monday, February 11, 2008

PPP3 (final version) in Java and C

Steve Gibson has released the final version of his PPP system: PPPv3 and so I've updated my code to be compatible.

Two versions of PPPv3 are available:

Both are released, as before, under the BSD license.


Wednesday, February 06, 2008

A clever, targeted email/web scam with a nasty sting

Steve Kirsch sent me an interesting message he'd received from (i.e. an email address from the Better Business Bureau) containing an apparent complaint from a customer submitted through the BBB. The email itself was actually sent from a BellSouth ADSL line (i.e. almost certainly a zombie machine). The address was not authorized to send as according to BBB's SPF records.

But the content of the email message is very interesting. Here's a screenshot:

Notice how the email contains the correct address for Steve, his name and the name of his company and thus appears to be a real complaint. The link below the complaint, where you can get full details, is the first of two nasty stings in this message.

The actual URL is:

i.e. the link actually goes to the BBB's own web site (making it seem even more likely that this is a genuine message). The link manipulates the search option on the BBB web site using the lnk parameter to perform a redirect to which in turn redirects to And it's on that, presumably hacked, site that the real scam starts.

If you are not using Microsoft Internet Explorer you'll be presented with the following web page:

Once you've upgraded you get told that the web site requires the "Adobe Acrobat ActiveX" control and you need to install it.

The control itself is embedded using the following code:

<object classid="clsid:D68E2896-9FD9-4b70-A9AE-CCDF0C321C45" height="0" width="0" codebase=""></object>

Notice how instead of pointing to Adobe's web site to get the control it's available locally as So when you follow the instructions you download and install an ActiveX control from the scammer web site.

Once you've done that you get told that in fact the customer has withdrawn their complaint and there's nothing to worry about:

Now for the second sting. There must be something about this ActiveX control that's malicious... the scammer didn't go to all that trouble for nothing. But none of the current anti-virus programs report any problems with the file.

For example, my Sophos anti-virus says nothing, and online scanners such as Kaspersky's say that it's clean:

So, perhaps the file really is clean, but I suspect that this is a new threat which isn't currently detected by anti-virus. I'll post again when I get a response from Sophos' anti-virus brainiacs. Perhaps, I'm wrong but be very wary of these mails.

Further information about BBB related scams on their web site.

UPDATE: McAfee WebImmune tells me that this is a new detection of the SpyWare which steals information about your web surfing.

UPDATE: A scan using VirusTotal shows that very few anti-virus programs are detecting this (although their version of Kaspersky is finding it---curious that the online Kaspersky scanner does not).

Labels: ,

Monday, January 07, 2008

First release of my 'shimmer' project

A couple of months ago I blogged about a system for open and closing ports based on a crytographic algorithm that makes it hard for an attacker to guess the right port. It's a sort of port knocking scheme that I called C3PO.

Many commentators via email or on the blog and in other forums requested that I open source the code. I couldn't do that because the code was a nasty hack put together for my machine, but I gone one better.

Today I'm releasing the first version of shimmer. shimmer is completely new, GPL-licensed code, implementing my original idea. Read more about it on the site.

Hit the right port and you're in, hit the wrong one and your blacklisted. Ports change every 60 seconds.

Labels: , ,

Thursday, November 15, 2007

Steve Gibson's PPP... new version 3 in Java and C

If you've been following along you'll know that I've implemented Steve Gibson's PPP system in Java and C. The Java code is in the form of a CLDC/MIDP project for cell phones and the C code is a command-line tool.

Steve's made a major change to the algorithm which he's calling PPPv3. My updated code is here:

The C source code is available in

The Java source code is available in

The compiled Java is available in ppp3.jar.

Read my original blog posts for details.

Labels: ,

Tuesday, November 13, 2007

Cryptographically and Constantly Changing Port Opening (or C3PO)

In another forum I was just talking about a little technique that I came up with for securing a server that I want on the Internet, but to be hard for hackers to get into. I've done all the right things with firewalling and shutting down services so that only SSH is available. But that still leaves port 22 sitting there open for someone to bang on.

So what I wanted was something like port knocking (for an introduction to that you can read my DDJ article Practical Secure Port Knocking). To avoid doing the classic port knocking where you have to knock the right way to open port 22 I came up with a different scheme which I call Cryptographically and Constantly Changing Port Opening or C3PO.

The server and any SSH client who wish to connect to it share a common secret. In my case that's just a long passphrase that we both know. Both bits of software hash this secret with the current UTC time in minutes (using SHA256) to get 256 bits of random data. This data changes every minute.

The 256 bits gives me 16 words of random data. Those 16 words can be interpreted as 16 different port numbers. Once a minute the server reconfigures iptables to open those 16 ports forwarding one of them (which corresponds to word[0] in the hash) to SSH and the other 15 to a blacklist service.

At any one time 16 ports are open (i.e. respond to a SYN) with only one being SSH and the other 15 being a trap to be sprung by an attacker. The 16 ports change once a minute.

Since both sides can compute the hash the client is able to compute where the SSH server is residing at that moment and contact it. Once contact is established the connection remains open for the duration of the session. New sessions, of course, will need to recompute the hash once a minute.

The blacklist service serves to tarpit an attacker. Any connection attempt to one of the other 15 sockets causes the IP address of the attacker to be blacklisted (again an iptables change) which means that hitting any of the 15 ports causes the attacker to shut off their access to the SSH server for the next 15 minutes.

A casual NMAP of my machine gets your IP address blacklisted and shows up a random selection of open ports. A real user connects to the SSH server first time because they know where it resides.

Of course, this doesn't replace making sure that the SSH server is up to date, and that passwords are generated carefully, but it seriously frustrates a potential attacker.

If this is of interest to others I'd be happy to release my code (which is currently in Perl) as a GPL2 project.

Labels: , ,