You wouldn’t make your website slower on purpose, would you?

Perhaps it shows a bias on my part, but I tend to assume that people want their web sites to be faster.

so I was quite surprised when I saw some code on the homepage of a major high street retailer, which deliberately slowed down visitors to the site.

This wasn’t just a rate-limiting thing. It’s a proof-of-work algorithm – you have to earn the right to visit their site.

When you navigate to www.sainsburys.co.uk for the first time (you might want to do this with wget or similar, for reasons that will become apparent, you get a web page with no content, but the following javascript (beautified for your convenience):

function decode_string(in_str) {
    return decodeURIComponent(in_str);
}

function test() {
    var table = "00000000 77073096 EE0E612C 990951BA 076DC419 706AF48F E963A535 9E6495A3 0EDB8832 79DCB8A4 E0D5E91E 97D2D988 09B64C2B 7EB17CBD E7B82D07 90BF1D91 1DB71064 6AB020F2 F3B97148 84BE41DE 1ADAD47D 6DDDE4EB F4D4B551 83D385C7 136C9856 646BA8C0 FD62F97A 8A65C9EC 14015C4F 63066CD9 FA0F3D63 8D080DF5 3B6E20C8 4C69105E D56041E4 A2677172 3C03E4D1 4B04D447 D20D85FD A50AB56B 35B5A8FA 42B2986C DBBBC9D6 ACBCF940 32D86CE3 45DF5C75 DCD60DCF ABD13D59 26D930AC 51DE003A C8D75180 BFD06116 21B4F4B5 56B3C423 CFBA9599 B8BDA50F 2802B89E 5F058808 C60CD9B2 B10BE924 2F6F7C87 58684C11 C1611DAB B6662D3D 76DC4190 01DB7106 98D220BC EFD5102A 71B18589 06B6B51F 9FBFE4A5 E8B8D433 7807C9A2 0F00F934 9609A88E E10E9818 7F6A0DBB 086D3D2D 91646C97 E6635C01 6B6B51F4 1C6C6162 856530D8 F262004E 6C0695ED 1B01A57B 8208F4C1 F50FC457 65B0D9C6 12B7E950 8BBEB8EA FCB9887C 62DD1DDF 15DA2D49 8CD37CF3 FBD44C65 4DB26158 3AB551CE A3BC0074 D4BB30E2 4ADFA541 3DD895D7 A4D1C46D D3D6F4FB 4369E96A 346ED9FC AD678846 DA60B8D0 44042D73 33031DE5 AA0A4C5F DD0D7CC9 5005713C 270241AA BE0B1010 C90C2086 5768B525 206F85B3 B966D409 CE61E49F 5EDEF90E 29D9C998 B0D09822 C7D7A8B4 59B33D17 2EB40D81 B7BD5C3B C0BA6CAD EDB88320 9ABFB3B6 03B6E20C 74B1D29A EAD54739 9DD277AF 04DB2615 73DC1683 E3630B12 94643B84 0D6D6A3E 7A6A5AA8 E40ECF0B 9309FF9D 0A00AE27 7D079EB1 F00F9344 8708A3D2 1E01F268 6906C2FE F762575D 806567CB 196C3671 6E6B06E7 FED41B76 89D32BE0 10DA7A5A 67DD4ACC F9B9DF6F 8EBEEFF9 17B7BE43 60B08ED5 D6D6A3E8 A1D1937E 38D8C2C4 4FDFF252 D1BB67F1 A6BC5767 3FB506DD 48B2364B D80D2BDA AF0A1B4C 36034AF6 41047A60 DF60EFC3 A867DF55 316E8EEF 4669BE79 CB61B38C BC66831A 256FD2A0 5268E236 CC0C7795 BB0B4703 220216B9 5505262F C5BA3BBE B2BD0B28 2BB45A92 5CB36A04 C2D7FFA7 B5D0CF31 2CD99E8B 5BDEAE1D 9B64C2B0 EC63F226 756AA39C 026D930A 9C0906A9 EB0E363F 72076785 05005713 95BF4A82 E2B87A14 7BB12BAE 0CB61B38 92D28E9B E5D5BE0D 7CDCEFB7 0BDBDF21 86D3D2D4 F1D4E242 68DDB3F8 1FDA836E 81BE16CD F6B9265B 6FB077E1 18B74777 88085AE6 FF0F6A70 66063BCA 11010B5C 8F659EFF F862AE69 616BFFD3 166CCF45 A00AE278 D70DD2EE 4E048354 3903B3C2 A7672661 D06016F7 4969474D 3E6E77DB AED16A4A D9D65ADC 40DF0B66 37D83BF0 A9BCAE53 DEBB9EC5 47B2CF7F 30B5FFE9 BDBDF21C CABAC28A 53B39330 24B4A3A6 BAD03605 CDD70693 54DE5729 23D967BF B3667A2E C4614AB8 5D681B02 2A6F2B94 B40BBE37 C30C8EA1 5A05DF1B 2D02EF8D";
    var c = 1434197414
    var slt = "77Z3lKK5"
    var s1 = 'a'
    var s2 = 'e'
    var n = 4
    var start = s1.charCodeAt(0);
    var end = s2.charCodeAt(0);
    var arr = new Array(n);
    var m = Math.pow(((end - start) + 1), n);
    for (var i = 0; i < n; i++)
    arr[i] = s1;
    for (var i = 0; i < m - 1; i++) {
        for (var j = n - 1; j >= 0; --j) {
            var t = arr[j].charCodeAt(0);
            t++;
            arr[j] = String.fromCharCode(t);
            if (arr[j].charCodeAt(0) <= end) {
                break;
            } else {
                arr[j] = s1;
            }
        }
        var chlg = arr.join("");
        var str = chlg + slt;
        var crc = 0;
        var crc = crc ^ (-1);
        for (var k = 0, iTop = str.length; k < iTop; k++) {
            crc = (crc >> 8) ^ ("0x" + table.substr(((crc ^ str.charCodeAt(k)) & 0x000000FF) * 9, 8));
        }
        crc = crc ^ (-1);
        crc = Math.abs(crc);
        if (crc == parseInt(c)) {
            break;
        }
    }
    document.cookie = "TS91374f_75=" + "927c14961cd31e2d022d0c414f5c16c1:" + chlg + ":" + slt + ":" + crc + ";Max-Age=3600;path=/";
    document.forms[0].elements[2].value = decode_string(document.forms[0].elements[2].value)
    document.forms[0].elements[4].value = decode_string(document.forms[0].elements[4].value)
    if (document.forms[0].attributes['action'] != undefined) {
        document.forms[0].attributes['action'].value = decode_string(document.forms[0].attributes['action'].value);
    } else {
        document.forms[0].action = decode_string(document.forms[0].action);
    }
    document.forms[0].submit();
}

This code is effectively a password guesser. The server randomly generates a short password, and challenges the client to crack it.

Now, there are some technical problems with this code (and I go into the technical details below), but there’s a far more serious problem. This code is intended to keep someone out (most likely hackers trying to DDOS their site). The problem is, it hurts everyone equally – both legitimate users and hackers.

If anything, it hurts legitimate users even more. Legitimate users won’t necessarily be tech-savvy, so there’s a good chance they’re using an outdated browser, like IE6. On the other hand, hackers probably know what they’re doing, and are using the right tools for the job.

I did some benchmarking. Using IE6, it takes about 30 milliseconds to crack a password. Using either Chrome or Node.js (they use the same javascript engine), we can crack a password in 1.5 miliseconds. Using some Scala that I wrote myself, I could do this in 300 microseconds. Now, the difficulty of the challenge can be ramped up or down, but however you spin it, hackers can crack this 20-100 times faster than the slowest of your legitimate users.

So, if you increase the difficulty until that it takes hackers 1 second to load your page, then it’ll take some of your users 1 minute 40.

Another problem is that this design would be an absolute bitch to test. Many performance test tools don’t execute javascript on the pages they download, and there’s a big scalability penalty in the ones that do. The obvious conclusion then, is that this site simply hasn’t been performance tested.

And, testable code is good code, so it’s a fair bet that this code has bigger problems.

I’d really love to find out where this code came from and why. Was it pressure from management? Was this the work of a bored coder? Was this done by a junior developer who didn’t know better? Or, maybe it was dreamed up by an overpaid security consultant?

It’d be very interesting to find out. The internet seems to be somewhat equivocal on whether javascript proof-of-work schemes are a good idea – but in this case I’m not sure the benefits stack up.

In any case, for the geeks out there, here are the technical details:

The variables slt and c are the salt and “hash” for a password. We don’t know what the password is, but s1 and s2 tell us that it consists of letters between 'a' and 'e', and n tells us that it’s four letters long. The script “hashes” passwords fitting those parameters until it finds one that matches, adds it as a cookie, and proceeds to the site. The cookie appears to be cached for an hour, so the user doesn’t have to keep doing this every time they navigate to a different page. The password and hash appear to be randomly generated by the server. The various variables also suggest that they can ramp the difficulty of the challenge up or down (longer password, or more letters)

Now, as well as the ideological issues discussed above, notice that the “hash” algorithm is actually CRC32, which is not a secure hash algorithm. It’s relatively easy to get a preimage, especially since the password is 4 letters long in this case (CRC32 has 8 bytes of freedom in it, so we can recover the password exactly).

However, you might also notice that their implementation of CRC32 has a bug. On line 34 they use an arithmetic shift (>> in javascript), rather than a logical shift (>>> in javascript). Ironically, this bug makes it very slightly harder to crack, as there no off-the-shelf tools to do so, although I doubt they’ve accidentally invented a military grade hash.

Advertisements

9 thoughts on “You wouldn’t make your website slower on purpose, would you?

  1. Egil

    It COULD be a security device in front, such as big-ip asm, to ensure that an automatic or manual inspection would require a lot more work. I’ve seen this a couple of times on different jobs.

    Reply
  2. Egil

    To obfuscate the content to slow down hacker-tools, such as burp intruder. If you for instance send out 1000 requests to the webserver trying to fuzz a parameter, and the webserver responds with different content that must be decrypted first, this will seriously slow down the analyzing phase…

    Reply
  3. jamespicuk Post author

    It would certainly slow down hackers, but it seems like this creates more problems than it solves.

    For starters, it slows down legitimate users just as much, if not more. But more importantly, it slows down penetration testers (and other testers), reducing the odds of them finding any issues.

    It also sends a message to hackers. It tells them that at best, it hasn’t been thoroughly tested, and at worst, it’s a condom to cover a known issue.

    Reply
  4. ben g

    Hey, I made this crc32 cracker in Ruby for this exact script. Your post helped me understand it, so thanks!

    def self.crc32_crack(start_letter, end_letter, length, salt, hash) # Gets the crc32 code of the given length using the range from a start_letter…end_letter that matches the salt/hash

    (start_letter..end_letter).to_a.repeated_permutation(length.to_i).each do |guess|
    guess = guess.join

    return guess if (crc32_check(guess + salt).to_i == hash.to_i)
    end

    end

    def self.crc32_check(str, js_32_bit = true)
    table = Zlib::crc_table.map {|el| el.to_s(16).upcase} # hex crc32 table

    crc = 0
    crc = crc ^ (-1)

    max_32_int = (2**32)

    str.length.times do |k|
    a = (crc >> 8)
    b = (“0x” + table[((crc ^ str[k].ord ) & 0x000000FF)]).to_i(16)
    crc = (a ^ b)

    if js_32_bit # See http://stackoverflow.com/questions/17056263/getting-the-same-result-from-ruby-as-javascript-for-bitwise-xor?noredirect=1#comment24669730_17056263
    if crc > (max_32_int/2)
    crc = crc – max_32_int
    elsif crc < -(max_32_int/2)
    crc = crc + max_32_int
    end
    end

    end

    crc = crc ^ (-1)
    crc = crc.abs
    return crc

    end

    Reply
    1. jamespicuk Post author

      One thing to note about your Ruby version, is that the conversion of the crc32 table to string, and back, is unnecessary. I imagine the original author of the JavaScript version did this to work around limitations in JavaScript itself, but everything’s much nicer in the world of Ruby.

      Strictly speaking, the algorithm we’re looking at isn’t crc32, because it has a bug. it uses as arithmetic right shift, where crc32 uses a logical right-shift. If they’d implemented it correctly, there’d be an even faster way to crack it, as the algebraic properties of crc32 make it relatively easy to reverse.

      Reply
  5. Pingback: Scraping a website which employs a CRC32 check | Technology & Programming

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s