unsafehex

What’s that padlock icon in your address bar all about? There are lots of places where you can get an explanation of what the symbol means, but in a lot of cases they’re pitched at tech nerds like myself, not the rest of the world – would a junior actuary or a retired interior decorator have a chance of understanding those? Not likely! And then there are some which swing the other way and reduce it to “Padlock = you’re safe”. What about the middle? The people who’d like to understand it a bit better but without having to learn half a networking degree? Now, I wouldn’t be able to plaster a wall for love nor money, but I can explain how that symbol is relevant to you in a way that you might understand.

You might have learned enough about the internet to know you need to look for a green padlock in your address bar when you’re doing something involving your password or credit card details but for a lot of people, that’s where it stops. Unless you understand why you’re looking for it, though, you could still be risking your email, the money in your bank account, and anything else that depends on information being sent securely over the internet. If you read the rest of this article hopefully by the end you’ll know why you’re doing it, and how to make sure you’re doing it right.

A few days ago several people pointed out on twitter that Waitrose’s shopping login form was delivered on a normal page instead of an encrypted one. This is what the presence or absence of the green padlock is telling you – green padlock = page was encrypted when it was sent to you, no green padlock = it wasn’t. What’s the big deal? You’ve only browsed to the site, not put in your password, so it should be fine, right? Obviously not, or I wouldn’t be writing this post.

(If you are a tech nerd like myself and you do want technical mumbo-jumbo, there is an excellent writeup of the issue on the blog of the security pro to whom the issue was originally highlighted)

When you request a web page, your computer first finds the server on the internet that holds the web page. If the page is encrypted your computer first arranges a secret key with the server that only those two computers will know (how they do this without revealing the key is a huge topic of its own – if you’re curious, look up “Public Key Cryptography”). The server then sends the web page, encrypted with the key if using that, or in plain text if not. The same thing happens when your computer needs to deliver information to the web server – such as which product it was that you clicked “add to basket” on, or your password, or your credit card details when you go to pay.

So how does this affect Waitrose? When your web browser sends information to a web server, there has to be something in the code of the page to tell it where and how to send whatever it is you plan on sending. If you go to their site, the page you get back will have a login form on it and the code that creates that form has a section that determines where your browser sends the information you enter into the form. The code that does so is defined with the “action” parameter inside a <form> tag:

<form action="destination page goes here">

Or, as it appeared on Waitrose’s site:

You can see in this example from Waitrose’s site that it is sending its information to an encrypted page (the address starts “https://”). Happy days! Or is it? Remember that the page you received from Waitrose wasn’t encrypted (no “https://” in the address bar and no green padlock):

Now, we know that this time, the destination is going to be Waitrose’s secure server, because we just checked – but do you know that will be the case every time? You’d hope so, but really that’s based on an assumption: that every time you request the page, what you get is exactly what Waitrose sent you. Now comes the bad news. Devices like routers and other network equipment are generally meant to pass on an exact duplicate of what they receive until it reaches its final destination. But there’s nothing to stop them from changing the data as it goes through. If the page is sent in plain text and goes through a number of devices between Waitrose’s server and you (their ISP > some internet motorway or ‘backbone’ as it’s known > your ISP > your router > your computer), any one of those has the opportunity to replace the part that says that says “https://www.waitrose.com/shop/AjaxLogon” with, for example, “http://www.unsafehex.com/stealer/send-me-your-credit-card-details”.

Think of it like getting your credit card statement with a prepaid envelope: how do you know the address on the envelope is the legitimate one? Unless you looked at the source code every time, you would never know for sure that that destination in the “action” field was Waitrose’s own site – unless your connection to Waitrose when you loaded their page was encrypted. Getting the page with the login form on encrypted instead of plain is like getting your card statement with the return envelope in larger envelope with the seal intact, instead of just held together with a rubber band (though HTTPS encryption is much more secure than the seal on an envelope). You know that the form will be sending your data to the right place because only the server and your computer know how to decode the data correctly.

The obvious question then becomes, can there really be evil devices between me and a website? There certainly can. This is another subject that could be an entire post (or three) of its own, but one example is that a lot of people out there get a bargain basement router supplied by their ISP, which their ISP sourced from the lowest bidder. It’s probably full of security holes, easily compromised and turned in to a slave at the bidding of someone who intends to make money out of it. There are plenty of other circumstances – the router in your local coffee shop or the hotel you stayed at could have been hacked. Someone could have created a fake WiFi hotspot just so they can do things like this… the list goes on.

At this point I’m going to hope that I’ve convinced you that you need to pay more attention to this padlock thing, so let’s get to the most important part of all: how do you make sure you’re secure? Fortunately this part is relatively easy: every time you are about to type in some information that’s secret, look at the address bar first. If you don’t see at the beginning (or if you use Microsoft’s IE or Edge, yours is at the end of the bar), don’t continue.

Feedback is welcome, especially if there’s something I haven’t explained clearly enough, or is technically inaccurate!

Obfuscation of code is an interesting technique used by malware authors to conceal what their code is doing from anyone looking at it. Finding out what it does can be tricky, especially if you’re not sure how to start. So, when a wave of WordPress compromises broke out a few months back and Zscaler wrote a nice overview of what the compromised sites were trying to do, I thought it was an excellent opportunity to go through the javascript they quoted and show exactly how to unwrap it; especially given that it’s a relatively simple example.

The first thing you need to do is to find the page with the obfuscated javascript on it. I can’t tell you exactly how you should do this; it will depend on how you are encountering the issue – it could be that it’s your WordPress install that has been owned, or it could be that you’re seeing alerts from your intrusion detection or antivirus systems that you need to investigate – any number of reasons. Once you have identified the source of the alert (proceed very carefully from here on in!) you need to get the source code of the page that you’re investigating. Use something like curl or wget in Linux/OSX for safety. I would never suggest pointing a browser at it unless you really know what you’re doing.

Obfuscated code tends to stand out to human eyes because it creates patterns that are very distinct from the code on the rest of the page. There are different styles, so this example won’t teach you to spot all of them but believe me when I say that once you’ve seen a few you will be able to rapidly scroll through a page and spot the blocks of evil code. In my example, the evil code looks like this:

Distinguishing features include:

large wall of text where code above and below is relatively short and spaced out
random looking letters that make no sense
lots of little groups of numbers
a “document.write” command
not seen here, but an “eval” command is often associated with malicious javascript – worth mentioning because this one is relatively rare in benign code whereas “document.write” is common.

None of these is evil in itself but they’re common things to see in evil javascript.

The first thing you need to do is break out the stuff between the script tags into a separate file to play around with it. I’m going to do my decoding using Python because that’s what I’m used to but you can use pretty much any language for this. Find statements separated by semicolons and split them on to new lines so it’s easier to follow (for large, complicated blocks you might want to use a tool like JSPretty but this one is quite simple).

Once you’ve done that you can start to get an idea of what is in there. In this example, there are variables ‘a’, ‘b’, ‘c’, ‘clen’, then a for loop, and finally an unescape statement. Breaking down the for loop further, it does the following:

iterates through every character in ‘a’
in each iteration, get the numeric ASCII value of the character
bitwise XOR that value with 2
convert the resulting value into a new ASCII character
append the new ASCII character to a string

This is something that converts very readily to Python, like so:

Followed by the output:

This gives us a URL-encoded string (character codes preceded by % symbols). Python has a built-in library, urllib, which can decode this for us.

Finally, we get a human-readable version of the content.

The “document.write” command would have written the decoded content to the browser which as you can now see would have created an 0x0 sized iframe calling a resource from teaserguide[.]com. If you haven’t already read Zscaler’s article showing what happens after that, I highly recommend that you do so now.

This was a pretty low-level example; some malicious code has obfuscation three or more levels deep. Others use weird tricks in javascript to produce code that is mind-bendingly hard to pick apart such as the JJEncode technique (warning: you might need a stiff drink and a lie down after looking at that one – I did, and I take my hat off to whoever wrote the script to reverse it). I hope this was helpful to get you started.