Registering dissectors for unknown MIME types in Wireshark

I came across a situation today where I was looking at some packets in Wireshark that used HTTP with a JSON payload. However, the Content-Type header was one unknown to Wireshark, and this led it to simply display the content unparsed. Since Wireshark supports JSON dissectors since version 1.6 for some Content-Types, such as “application/json”, I suspected it was possible to get it to recognize the Content-Type header I was seeing as one indicating a JSON payload.

Unfortunately, my usual approach of using the “Decode as…” entry in the right click menu wasn’t working, as it’s not a network protocol, and doesn’t appear there. I eventually found it in the Dissector tables, accessible via the Internals menu. There, one can find the “Internet media type” table, which appears to map MIME types to the appropriate dissector. Now I knew what I wanted to add, and where, I just needed to figure out how.

Enter Lua, the scripting language used by Wireshark. Chapter 11 of the Wireshark manual gives information and examples, but the specifics I needed were in section 10. The following line will register the JSON dissector as the one to be used when encountering a media type of “application/vnd.myapp+json”. To enter it, navigate to “Tools>Lua>Evaluate”, enter the code below, substituting whatever values you need for your particular situation, and click the evaluate button.

DissectorTable.get("media_type"):add("application/vnd.myapp+json", Dissector.get("json"))

For the curious, this gets a reference to the Internet Media types dissector table, and calls the add method with two arguments, the content type string, and a reference to the desired dissector. You can check that the dissector was registered successfully by navigating to “Internals>Dissector” tables and checking the “Internet media types” dissector table

Removing AVG Secure Search

I just spend the better part of two hours removing what can only be described as malware from a Windows computer owned by a friend of mine. This is the AVG secure search toolbar, proudly marketed by AVG and stuffed down the throat of my unfortunate friend, who doesn’t even use AVG products.

It manifests itself as a browser plugin for Firefox (apparently Chrome and IE as well), and worms its way into every part of the system to hinder removal. It also disables the “remove” button in the Firefox extensions list, changes all your Firefox settings to use its own search plugin, and runs background processes that “update” it each day. (read: reinstall without your permission if you delete its files) The uninstall instructions from AVG are useless rubbish, and just result in it reinstalling itself the next day.

First, disable both the extension and the plugin in firefox, and reset your settings using these uninstall instructions. Next, open up your control panel, and uninstall the “AVG Secure Search” program. You may need to also remove vToolbarupdater  from your startup services. Go to the task manager and kill “vToolbarupdaterXXXX” where XXXX is some version number. Also kill loggingserver.exe and the process named “vprot.exe” at this point, as they are also associated with AVG.  Now in your services list, stop vToolbarUpdater, and set the startup type to “disabled” in its properties window.

It also hides in the following locations. You will need to view hidden files to see some of these.

1. C:\Program Files (x86)\Common Files\AVG Secure Search\
2. C:\ProgramData\AVG Secure Search\
3. C:\windows\system32\drivers\avgtpx64.sys

More browser extension rubbish is found in your AppData folder, something like C://Users/yourusername/Appdata/. Look though your Mozilla and Mozilla Firefox folders in your Local and Roaming folders, especially under the extensions folders in your firefox profile. Also check the Temp folder for things like “FireFoxSearchBar.xml”, “toolbar_log.txt” and anything starting with “avg”. I found a few folders named something like “avg_a02000” and another text file that was named “AVGsecuresearch_log.txt”

Finally, go to the Windows registry editor and search for “AVG”. This should turn up a lot of hits. Other than the windows “dfrg” one, which appears to be legit, most of the hits had something to do with the toolbar. Delete these, and change the IE homepage one back to something sensible (https://duckduckgo.com for me, but you can choose another home page).

Now restart your computer, and pray that AVG never does this again. If you’ve got any of their software running, I’d nuke that too, but that’s a topic that I don’t have the expertise for covering here. Hopefully this post will help anyone who wants to get rid of this crap, but I don’t claim any particular knowledge or expertise in this area, so your mileage may vary.

Edited to add:

This blog post was helpful, and someone has helpfully posted the browser settings that AVG changes here so that you don’t need to visit AVG’s site to get them.

Encrypted USB drives with eCryptfs

I’ve got several USB flash drives that I carry around with me on a regular basis, and it’s nice to be able to use those for small backups of important things, in addition to my usual system-wide backups that get dumped onto a couple external hard drives. This way, even if something happens to my computer and the backup drives, (the house burns down, my computer and hard drives are stolen, or an EMP bomb goes off in the garage) I still have the important things with me. Being me, I like these important things to be encrypted so that if I lose the USB drive, it’s not cause for panic.

That said, I also use my USB drives for more mundane things, like transferring files between two computers and carrying around my music. Since I’m a Linux geek surrounded by people using Microsoft and Apple products, it’s nice to have something that works with both. After all, it’s hard to sing the praises of Linux effectively when they’re asking questions about why your USB drives won’t work.

Today I drew up a list of features that my ideal USB drive would have.

1. Must be capable of storing encrypted data in such a way that it can be mounted as a filesystem. Backup software shouldn’t need to worry about the encryption.
2. The USB drive must be capable of being read and written by Linux, Windows, and Mac OSX. The encrypted data only needs to be read on my personal computers, which all run Linux.
3. If I have free space left over after backing up, I should be able to use it to transfer files, store music, or whatever else I want to use the USB drive for.

The second requirement means that the USB drive will have to have at least part of it formatted as a filesystem that everyone can read and write to. I could format it as NTFS, which is what Windows uses now, but I don’t believe Mac OSX allows writes to NTFS filesystems, and I have previously had issues with using NTFS on Linux myself. It may be the case that I could work around any Linux-NTFS issues, but I don’t want to have to convince Mac users to install things or tweak system settings to make my USB drive work. I can’t use Mac’s normal filesystem, HFS+,  either, because Windows users wouldn’t be able to use it without installing new drivers. Finally, I can’t use something like ext4 or Btrfs, because then it would be limited to Linux users only without extra software. FAT32 is not my favourite filesystem, but it’s supported on all the target platforms with no extra software needed, so that will be my filesystem of choice, guaranteeing that whatever systems I’m likely to encounter will be compatible with my USB drive.

Turning to the first requirement, I need to be able to store encrypted data such that it can be mounted and used like a regular filesystem. In Linux, there are two basic ways of going about this, you can use block level encryption like dm-crypt/LUKS, which I use for encrypting my hard disk or you can use filesystem-level encryption, like eCryptfs, which I also previously mentioned. To figure out which of these two solutions to use, I’ll look at the final requirement, which is the ability to dynamically resize to avoid wasting space.

I could partition my USB drive and format the first part as FAT32 with the rest encrypted using dm-crypt with whatever filesystem I like (encrypted data only needs to be usable in Linux) on top of the encrypted block device. This is not very nice however, as I’m pre-allocating the space before I know what I’m storing. If I don’t store much in my backup area, then the space is wasted and I can’t use it for other things. On the other hand, if I suddenly need more backup space, I’d have to manually repartition, expand the filesystem, and so on. That’s annoying, so I won’t go that route.

The second alternative, eCryptfs, is a lot better suited to this dynamically resizable storage problem. I can format the entire drive as FAT32, then create a directory to use for eCryptfs backing files. If I then mount an eCryptfs filesystem with that directory as the backing directory, all the files I write into the mount are encrypted before being written onto my USB stick. Now I can just use that as output for my backups, and I have the dynamically resizable encryption scheme that I wanted. It only takes up as much space as the encrypted files, since they are just files stored in the FAT32 filesystem. If I create a new file in the eCryptfs mount, one new file is created in FAT32, and if I delete something in eCryptfs, the file goes away for FAT32 as well.

So the final solution is to format the whole USB drive as FAT32, then stack eCryptfs on top of that. Now I can safely carry around my backups and still have room should I need to use a USB drive like a normal person, or should normal people want to use my USB drive.

What I’ve been up to recently

As part of my degree requirements, I’ve got to complete a large project within a group of four people. The project goal is self selected, but must be useful and related to software engineering. I’ll be working with Michael Chang, Zameer Manji, and Alvin Tran until early 2014 to add integrity protection to eCryptfs, a cryptographic file system that can be used on Linux. In this post, I’ll present some concepts related to the project along with some details about the project itself.

Confidentiality and Integrity

Two important concepts in computer security are those of confidentiality and integrity. There is also usually a third concept mentioned alongside these, that of availability, but I’m only mentioning it here for completeness.

Confidentiality protection attempts to prevent certain parties from reading information while allowing other parties to access the information. In the case of a cryptographic file system like eCryptfs, this is done by encrypting the files before writing them to disk, and decrypting the files when they are needed later. This could be done manually, but it is much easier and less error prone to have the file system handle this sort of thing than to try to encrypt all sensitive information by hand.

Integrity protection attempts to ensure that information has not been unintentionally changed. This might entail actually trying to prevent modifications to the information, or it may simply indicate when the information has been changed. Cryptographically, this can be done using a Message Authentication Code (MAC), which is a short binary string that can be easily calculated with a file and a key, but cannot be calculated without both. Additionally, if the file changes then the calculated MAC will be different. Anyone knowing the key and having access to the file can calculate the MAC and compare it to one that was calculated and stored earlier, and if the two are different, then the file must have been changed.

Current state of eCryptfs

The eCryptfs file system is a stacking file system, which means that it relies on a lower file system to handle stuff like I/O and buffering, and just manages file encryption and decryption. Currently, that is all it manages, as it does not include any integrity protection. The contents of files are made unreadable to anyone without the correct key, but it is still possible to modify those files in partly predictable ways, as presented below.

There is already a wide user base for eCryptfs, with Ubuntu and it’s derivatives using it to provide the encrypted home directory feature, and within Google’s ChromeOS.

Attack against CBC mode

Cipher Block Chaining (CBC) is one of the most common modes of operation for block ciphers, and is used currently by eCryptfs. In this mode of operation, each block of plaintext is XORed with the previous ciphertext block before encryption. This ensures that the same block of plaintext won’t encrypt to the same ciphertext, unless the previous ciphertext block is the same as well. A one-block initialization vector stands in for the previous ciphertext block during the first encryption. CBC decryption just reverses the process, first decrypting the ciphertext block, then XORing it with the previous ciphertext block.

Operations can be expressed in the following way (Taken from Wikipedia)

Encryption:

Decryption:

Now let’s perform the attack. Let’s say we want to change a certain plaintext block into a different plaintext by flipping some bits. We’ll denote this change as . That is,

It turns out that if we don’t care what happens to the previous plaintext block, , all we have to do is replace with

We can substitute this into the decryption formula above to see what will happen.

This is an integrity issue, as an attacker can now modify files without ever knowing the key used to encrypt them. It’s also not guaranteed that this modification is detectable, depending on whether the previous block can be checked for validity. If it can be checked, great, but that’s just another form of integrity protection, and the project I’m working on aims to implement integrity protection regardless of the data stored. If it can’t be checked for correctness, or is ignored (maybe it’s a different record in a database) then the modification will go unnoticed.

Galois Counter Mode

Galois Counter Mode (GCM) is another mode of operation for block ciphers, but in addition to encryption, also produces a piece of data known as an authentication tag. This tag acts as a MAC taken over the data that was encrypted. An attacker could still modify the ciphertext, but now the resultant changes to the plaintext will invalidate the tag, making them detectable. The attacker cannot modify the tag so that it validates the new data, because calculating the tag requires the cryptographic key that was used to encrypt the data, and the attacker does not know this key.

Another benefit to GCM is speed. It’s true that the same effect on security could be had by encrypting the data and calculating a MAC separately, but that requires two passes of the file, one for each operation. GCM does both in one pass over the file, speeding things up. This is important in a file system, as you’d rather have access to your files quickly.

The project aims to implement GCM as the mode of operation for eCryptfs, thus providing both integrity and confidentiality protection. Integrity protection was something the original developers wanted to have from the beginning, but didn’t have the time to implement. I’m proud to be helping to create the first widely used integrity protected cryptographic file system.

Password Restrictions Really Bug Me

Warning, rant ahead.

Maybe it’s just me, but when I hit restrictions on what I can use as my password, I get annoyed. Lower limits, such as “at least 6 characters long” are fine, but there are several things that I can see no reason for, that make me doubt the competence of the programmers involved in the system. When I realised that my bank’s website did all of the things mentioned in this post, I was really annoyed. Thousands of dollars of my money are sitting there, just one string of characters away from an attacker getting it all, and of course, reading the fine print of their security agreement reveals that it’s not their responsibility if my password or reset questions are compromised.

Character restrictions
Passwords are passwords, not HTML, not shell scripts, not anything that needs to be parsed by machines. They should be treated as opaque sequences of bytes, and the only thing that should be done with them while logging in is salting and hashing. When I see restrictions like, “To preserve online security, your information cannot contain unacceptable symbols or words (for example, “%”, “<“, “{“, “www.”, “ftp”,”https”, etc.)”, I’m astounded that they let these people touch code at all. There is no reason at all that they should need to check for that sort of thing in passwords. Passwords should never be displayed, not on their website, not in email, not anywhere. There should be no cause to worry about XSS attacks, SQL injection, or any other sort of incomplete mediation attack via passwords if they’re properly handled as opaque data.

I’m not complaining about entropy figures here. A 12 character string composed of random alphanumeric character would be approximately 71 bits of entropy. Adding in the printable punctuation and whitespace characters on a standard US keyboard only adds about 5 bits of entropy to that figure for a random 12 character string. The reason I’m annoyed by these restrictions is that they hint at deeper problems about how the password is handled by the system. They also impede those of us who do want to use “special” characters in our passwords for whatever reason, from non-ASCII characters in a preferred language to an obsession over password entropy.

Upper limit on length
I would have thought that the days of small fixed size strings were behind us, but apparently not. My bank puts an upper limit of 12 characters on password length, which precludes using an easily memorable passphrase. They put a similarly low limit of 25 characters on the password reset questions and answers. One of the few things they did right is allowing me to write my own security question, as I definitely didn’t want to use the default questions. I then got cut off halfway through writing a short sentence by this low character limit. Is this due to some aspiring database administrator learning that CHARs were faster than VARCHARs, and deciding to speed up logging in by a few milliseconds? Is the process of logging into an account, or resetting a password really where the bottlenecks are? If the problem doesn’t lie with the storage, but with the login system itself, then it’s time the programmers learned about dynamic allocation.

In addition to making it impossible to use longer passwords, this upper length limit also hints at improper handling of the passwords, as properly salted and hashed passwords would be constant length, and the length of the original password would be completely irrelevant to the storage requirements.

Required character classes
This sort of attempt to increase security is what leads to users choosing “Password1” instead of “password” to protect their life savings. No system is idiot proof, so rather than treating the symptoms by attempting to programmatically enforce good passwords, try to treat the problem by educating the idiots on how to choose a good password, and mentioning why they care. Suggest using a diceware passphrase, or use my password suggestions. Of course, this is only effective if users actually can use good passwords, so fixing the first two issues is a priority.

While I’m ranting about programmatically enforcing password strength, I should mention that I’m of the opinion that the only checks that I think are valid for this would be checking against a list of common passwords, and checking against information like account name or other public details associated with the account. These are going to be among the first things a social engineering attacker would try, and common workarounds for required character classes are not going to stop them, making that method of enforcement worthless.

Default password reset questions
Not really a password restriction, but it’s related, and it ticks me off. The usual culprits, along the lines of “what was your first [job, school, pet’s name, car]”, just train people to think this information is unguessable. After all, if so many places use the same questions, there must be a good reason right? I did a quick experiment where I looked at the public information about some of my friends on Google+, searched through their post history, and if I could find a link to their website, looked at that as well. In many cases, I could find answers to at least one of those questions just from these sources of information. The current system might as well be an all-you-can-eat buffet for social engineers.

Perhaps more obscure questions could be used by default, or perhaps websites should start using alternate methods of authentication, for example, resetting via SMS or OpenID.  Approached from an alternate perspective, why should we even need to give answers to these questions in the first place? What business do random websites have knowing trivia about me, and more importantly, why is it the same default trivia that protects my bank account?

</rant>

Killing Machines

Automated systems are already doing much of our work for us, making everyday decisions to remove the burden from humans. Anything from Google’s licensed self driving car navigating the roads alongside human-guided vehicles to the computers doing stock market trading on behalf of investors. Both of these are technologies that do what humans can do, but better, faster, or more reliably. Humans suffer lapses of concentration and fatigue, and do so unpredictably, whereas computers don’t. Computers have their own set of interesting problems, like the priority inversion bug that crashed Mars Pathfinder, but those can be found and removed from systems.

The question that springs to mind for me is “Is there anything we shouldn’t let a computer decide, even if it could make that decision faster or more reliably than a human?” My answer is that a machine should not be allowed to decide whether to kill a human. I’m not against computers aiding humans in acts of war, that’s just technological progression, and it’s happening already. Modern fighter jets are extremely unstable, to aid in maneuverability, so much so that a human pilot could not possibly stabilize the aircraft, so the jets are stabilized by computer. The human pilot still has the decision of whether or not to fire the weapons, and at what targets.

I’d also like to point out that I’m not mentioning anything about sentient computers when I say “decision”. Computers make decisions every time they execute conditional statements, without any sort of capacity for sentience or consciousness. A machine could be programmed to identify humans and kill some subset of them without human intervention, and it would be making a decision whether or not to kill humans. A machine that identified humans and then asked whether or not to kill them would not be making the decision to kill a human, as it would be passed off to a human operator.

By giving a machine the decision to kill a human being, we have created something capable of autonomously waging war. Most people consider war to be something to be avoided and minimized if possible. It is also known that the more indirect the method of killing, the easier it will be for a person to rationalize it, and the less aversion to performing the killing they will have. Psychologically, it is much easier to kill someone by pressing a button that launches a missile than to shoot someone that you can see, and shooting someone is psychologically easier than stabbing someone to death. If we remove the decision entirely from humans, the killing is now out of sight, out of mind, making it much easier for mass killings to take place without psychological consequence for those waging war.

One problem with this answer is how to define “deciding to kill”. Through various means, computers can control much of how we view the world. For example, information people view on the Internet is managed by computers. If the search engine ratings on some website are low, fewer people will be impacted by that website. If the search engines raise the rating, more people are likely to see it. By controlling what we see, computers could indirectly control what we think, and could theoretically manipulate one human into killing another. As such, it is likely an exercise in futility to try to prove that a computer could not decide to kill a human, even though that scenario seems to be very unlikely at this point in time.

SSH X Forwarding

Recently I was messing about with X forwarding through SSH, and I realized something that perhaps should have been obvious, but caught me off guard, so I’ll share it here.

The scenario involves 2 computers and a fairly resource intensive graphical application that could take advantage of 3D acceleration. The computers involved were a desktop computer with a reasonable graphics card, and a netbook with whatever graphics capabilities were built into the motherboard, but no 3D acceleration. I wanted to take advantage of the netbook screen, effectively using it as a second monitor, but running the application on the more powerful desktop. I figured I should be able to forward the X session over SSH, and end up with the netbook displaying it, but all the hard work done on my desktop. Unfortunately, when I set this up, I found the application could not take advantage of 3D acceleration anymore.

The reason for this is that when an X session is forwarded, only the X traffic is transferred across the network. This traffic consists of things like “draw a rectangle here” or “draw this bitmap there”. Where I had gone wrong was assuming that my graphical application would have the 3D acceleration done on the desktop’s fully capable graphics card, then have the resulting bitmap sent over the network. In reality, the netbook was doing all the graphical rendering, leading to a lack of 3D acceleration capability.

Despite the fact that I couldn’t get my 3D acceleration, this is actually a much smarter way of doing things, as it significantly reduces the network traffic involved. My netbook’s screen size is 1024×768, and let’s assume I wanted 30fps and 32 bit colours. The resultant network traffic would be (1024×768 pixels/frame)x(30frames/second)x(32 bits/pixel), coming out to a little over 750Mb/s just for the image going one way. If I recall correctly, the actual network load while I was doing this was a little over 100Mb/s.

The lesson learned here is that hardware acceleration is done on the display end (the X server) rather than the client end of an X connection.

Turkey Trivia

It’s Thanksgiving here in Canada, and so instead of the usual range of topics, here’s some trivia about that favourite food, the turkey.

1. Canadians consumed 143.4 million kg (Mkg) of turkey in the year 2011.
2. At Thanksgiving 2011, 3.0 million whole turkeys were purchased by Canadians, equal to 32% of all whole turkeys that were sold over the year.
3. At Christmas 2011, 4.4 million whole turkeys were purchased by Canadians, equal to 46 % of all whole turkeys that were sold over the year.
4. Turkeys are omnivorous. Most of their diet is grass and grain, but they will also eat insects, berries and small reptiles.
5. The wild turkey’s bald head can change color in seconds with excitement or emotion. The birds’ heads can be red, pink, white or blue.
6. Turkeys see in color and have excellent daytime vision that is three times better than a human’s eyesight and covers 270 degrees, but they have poor vision at night.
7. The long, red fleshy growth from the base of the beak that hangs down over the neck of a turkey is called the snood.
8. The fastest time to carve a turkey is 3 min 19.47 sec and was achieved by Paul Kelly (UK) at Little Claydon Farm, Essex, UK, on 3 June 2009.
9. Turkeys originated in North and Central America, and evidence indicates that they have been around for over 10 million years.
10. Wild turkeys can fly for short distances at up to 88 kilometres per hour. Wild turkeys are also fast on the ground, running at speeds of up to 40 kilometres per hour.

Info taken from

• Turkey Farmers of Canada
• Foodreference.com
• About.com
• Guinness Book of World Records
• Baltimoremd.com

They’re Always Watching

Right now, as you read this page, you are secretly being watched. Ad networks and analytics companies are tracking you across the Web, using a variety of techniques designed for one purpose: knowing everything about you. There is an entire industry built upon identifying and tracking web users, and chances are you haven’t heard of most of them. This post will discuss some of the ways they track you, how you can make it harder for them, and why you should.

You may be wondering why tracking is so bad, and why you should care. You might think that there are so many people that picking you out of the crowd is practically impossible. It’s not. The problem is that you don’t know who has your data, you don’t know what they have, and you can’t control how they use it. The data associated with you might seem fairly innocuous, such as the IP addresses you’ve used, what sort of sites you visit, or your email address, but in the wrong hands it can be rather dangerous.  Potential employers could see your search history, including not only search terms, but what you clicked on. Phishers and identity thieves could launch targeted attacks using information off your social networking sites and your location from the IP addresses you’ve used. Commerce sites could adjust their prices and charge you more for things you’re interested in, assuming you’re still likely to buy them.

From the point of view of the people doing the tracking, there are two main goals. First they have to get as much information as they can from each place you visit, and second, they have to link it together to create a profile of you. This allows them to build the detailed view of your Web history that they can then sell to anyone willing to pay them for it.

Gathering Information

Every time you make a request to a web server, your browser sends a bunch of information along with that request. It will generally send an “agent string” identifying the browser you use, the operating system you’re using it on, and some other information such as version numbers. It also sends a header telling the server what the last web page you looked at was, one telling the server what languages you prefer, and if you connect through an HTTP proxy, it will add a header with your original IP address. On top of all this, any cookies previously set by the domain (more on this later) will be sent to the server. This is quite a lot of information, and it may be sent out multiple times, not only for the web page itself, but also for any extra resources in the page, such as images or ad banners.

This is one major source of information for the tracking companies. All they have to do is arrange for some resource hosted on their servers to be included in the web page you visit, and all that information will be sent to them when the page loads. This isn’t hard, it happens every time you see an advertisement on a page you visit. Even if you don’t see any ads on a page, you’re still not in the clear. Web analytics companies will often place transparent 1×1 pixel images, also known as “web bugs”, in the pages they keep stats on. Every time someone loads the page, their browser sends all that information to the tracking company along with their request for these images.

So how do you stop this from happening? There are two ways to do this, either you can change or reduce the information in the headers, or better, you can avoid fetching the third party content altogether. If you never request things from their servers, it becomes much harder to track you. Two browser extensions that help you avoid connecting to these servers are Adblock Plus for Firefox and Chrome, and Do Not Track Plus For Firefox, Chrome, Safari and IE. These extensions attempt to keep you from loading the third party resources that come from advertisers and Web analytics companies without affecting anything else. If the site you’re connecting to directly is tracking you, then they won’t help, but they do a pretty good job at blocking third party tracking.

The other method for reducing the information given out is to avoid giving it out, or at least make it meaningless. There are extensions for Firefox and Chrome (And probably others) that will allow you to suppress sending the URL of the last page you visited along with each request. To protect yourself from trackers identifying where you live based on your IP address, you can use something such as Tor to hide your location. (Remember what I said about proxies sending the original IP address along with the request. Tor is safer, if slower) Other extensions exist that will allow you to modify the requests you send to web servers by removing or changing other headers.

Building a Profile

To track you across the web, the tracking companies need some way of identifying who is making a request to their servers when a web bug or ad banner is loaded. The easiest way to do this is with HTTP cookies, which are pieces of information that your browser stores, and then sends back to the server on each new request. This works across sites, as long as there’s some third party resources to fetch from the same domain on each site. Let’s say you log in to Facebook to check up on your friends. Along with the main page content, your browser fetches some ad banners from ads.tracking.com. Along with these come some tracking cookies, which just contain some unique string. Later on you visit an online store, which also has ads hosted on ads.tracking.com. When your browser goes to fetch these ads, it sends back the cookie it got while you were on Facebook. Now the tracking company knows that those two requests came from the same web browser, and they can link your social information to your shopping history. Of course, as you continue to browse the Web, they’ll link in other stuff, like all your search terms, or the list of all those sites you don’t want people finding out that you visit.

To make matters worse, HTTP cookies are only one type of information that can be stored and sent back later. Flash also allows special cookies to be stored, and these won’t be thrown out when you clear your browser cookies. Java applets and Microsoft Silverlight can do similar things, and are just as dangerous to your privacy as Flash. I recommend turning these off entirely except for a few trusted sites, e.g. Youtube.

An alternative to cookie-based tracking is to use something like JavaScript to fingerprint browsers. Information such as your browser version, operating system, any fonts or plugins installed, and much more can be collected and sent back after the page loads, even if you didn’t send it along with the page request. This information may be enough to uniquely identify you, or at least to place you into a very small group of users that share your exact settings.

To avoid tracking companies linking your requests together, you would need to avoid storing cookies from their servers and avoid running any code that they provide. The suggestions above for avoiding connecting to tracking servers in the first place will help you out here, but some additional protection is warranted as well. Most browsers have a setting to prevent them from storing third party cookies. This is a good defence against tracking via HTTP cookies. Additionally, most browsers let you clear cookies when you shut down the browser. While this will result in your logins not being remembered across browser sessions, it can help avoid you being tracked across browser sessions as well. Finally, you can also use your browser’s private browsing mode. This will generally prevent cookies from being saved and used outside the private session, in addition to not saving history to your computer. Keep in mind that none of this helps against Flash, Java, or Silverlight.

To avoid browser fingerprinting through JavaScript (as well as a lot of other annoying or dangerous stuff) you could turn JavaScript off completely. This will break the functionality on a lot of sites however, so I would recommend NoScript for Firefox or ScriptNo for Chrome to help you manage which sites you trust to run code in your browser. This will require some tweaking at the beginning as you choose which sites you trust and which you don’t, but it becomes much smoother afterwards, and you’ve greatly reduced the potential for attacks on your browser through these channels too.

If you follow the advice given in this article, you can go a long way towards regaining some control over your personal information. There is likely no magic bullet, and never will be, but you can make it a lot harder for the usual range of tracking techniques to build a profile of you. You can’t take back what you’ve already given away, but you can limit the information you give away in the future.

Runescape J.A.G.

Jagex, the company behind the MMORPG Runescape, recently made an announcement of a new security feature for protecting accounts from being hijacked. There has been an ongoing problem with players falling to phishing attempts or keyloggers, and having their account information stolen, the account hijacked, and all the time they put into the game now gone. This new security feature, called Jagex Account Guardian, or JAG, aims to make this harder, but I believe that it has several flaws in its design.

JAG works through a combination of device identification and email verification. When you attempt to log into the game, details of the device attempting to log in are somehow matched against a list of trusted devices stored on the server with the account. If the device cannot be matched, even if a correct password is provided, then you must correctly answer 3 verification questions chosen randomly out of a pool of 5 to get an email sent to an account you provide. This email will then allow one to add the device to the list of trusted devices, either permanently or temporarily. At any point, one can add or remove devices from this list, by completing this procedure again. No more than 3 attempts may be tried in a day without locking the account out for 24 hours. The 5 verification questions are chosen from a list, and you are unable to add your own questions, though obviously, the answers can be set to anything you want.

This sounds all well and good at first glance, but a closer read reveals that the five verification questions cannot be changed once set. This leads to an inability to recover, even if it is known that an attacker possesses some of the answers to the verification questions. The chances of an attacker who knows answers to only 3 of the verification questions being able to answer the questions presented is 1/10. (5 choose 3 gives 10 possible sets of questions, and the attacker knows one set) An attacker knowing 4 of the answers has a 4/10 chance of being able to answer, (they now have answers to 4 different sets of 3 questions) and an attacker knowing all the questions will always be able to answer correctly. This leaves the security of the account resting solely on the security of their email account, and it’s apparently not that hard to social engineer your way into those. To make matters worse, JAG replaces the existing password recovery system. This allows an attacker who gets past JAG to change the account owner’s password whenever they want, using information that will always remain the same, and access to the configured email account.

Let’s imagine a scenario where a player decides to log in to play from an internet cafe somewhere, perhaps while on vacation, and is using JAG to protect their account. Furthermore, let’s assume that this particular computer has a keylogger already installed. As the player attempts to log into the game, they are presented with a message telling them that the device is not trusted. They proceed to answer the three questions that are presented to them, and then are told that an email has been sent to their account. They open their email, and follow the instructions to add the device to the trusted list. They configure JAG to only trust the device for this one game session, and then continue into the game.

The owner of the keylogger now knows three things, the Runescape account password, the answers to at least three of their verification questions, and their email account password. This is likely enough information to take over the email account, assuming two-factor authentication isn’t used. It also gives the attacker enough information for attempting to brute force the verification questions on any device, which will on average take a little over 3 days. Meanwhile, the account owner is prevented from adding any new trusted devices by the lockout feature. At this point, the account owner will probably end up with their account hijacked and their previously trusted devices removed from the list. They can’t do much of anything about this, due to the inability to change the verification questions. Since the system acts as a password recovery system as well, changing the account password won’t help, as the attacker still has enough information to reset it. If the attacker has stolen the email account as well, then the player cannot even try to recover the password, or add their own devices back to the trusted list.

To top it all off, Jagex is using a policy of security through obscurity, intentionally avoiding giving details of how the system identifies devices. The JAG FAQ claims “For your security this is top secret.” I believe this is evidence of Jagex’s attitude towards security, and the notion that if they don’t tell anyone how it works, nobody will figure it out. This attitude has already failed in the past, as bot makers have already reverse engineered the game far enough to create advanced bots capable of a large array of different behaviours and actions in the game.

To sum up, JAG provides account security until it is compromised, at which point it provides attackers with a permanent backdoor into the account. Because it uses only a single device for both the verification questions and the email, it is vulnerable to compromise through keyloggers. Had Jagex opted for something like SMS authentication, or something similar to Blizzard’s physical authentication tokens, then the system would provide actual two factor authentication by adding the “something you have” category, rather than more “something you know” information. Since this is not the case, I’m of the opinion that this new system is more of a liability than an asset to account security in Runescape.