Google. What They Know About You Explained.

With yet another Google Privacy story in the news today, I thought it would be interesting to examine exactly what Google knows about the average internet user and how they gather their information. To simplify the article I have excluded any Google services that require some kind of authentication such as Gmail or Google Apps. All the information discussed below is harvested from so called anonymous browsing.

Firstly, irrespective of your Internet browser or even the HTTP protocol, every time you visit a web site, you must send your IP address to the destination so that the receiver knows where to send the reply. If you are a home user your IP address is allocated on a semi random basis from a large pool managed by your ISP. Even so, publicly available online tools can be used to narrow down your location from your IP address to at least the nearest city to where you browse from. Many sites use this information to target advertising at you. This is most obvious if you browse a site in a different country but see advertisements in your local language specific to businesses or services from your country. Your ISP of course can use the IP address to uniquely identify you.

Again, even before you start using Google products or web sites, each time you access a new web page you send the web server certain information contained in “headers”. One of these is called the user agent which tells the website your browser type and operating system.

So, before you even type the first character into Google’s search engine, they already know more or less where you live, your operating system and your browser type. This of course is not limited to Google but applies to any web site. Once you do access www.google.com for the first time you receive a cookie, nominally to record your preferences, e.g. language, number of results per page etc, but which also contains a unique ID. The next time you access the Google site the cookie, which is stored on your hard drive, is read and the ID from the first visit retrieved. Each search you perform is recorded by Google together with the ID to build up profile of your browsing habits. The information is used to target advertising at you, with the targeting becoming more effective as your profile expands.

Things get even more interesting for users of Google’s Chrome internet browser. As Microsoft highlighted last week, the address bar of Chrome is also the search bar. Every key stroke typed into the address/search bar is sent to Google to allow for an auto suggest of the term you may want to search for or the site you wish to browse to. Guess what. Your Google cookie containing the unique ID is also sent to Google allowing them to record every site you visit.

Many commentators also flag Google Analytics as a way Google can record your internet activity even if your web usage habits prohibit use of the previously mentioned techniques. Google Analytics allow web masters to record usage statistics for their site. It works by including a small amount of java script on each page that sends information to Google about the user’s activity. From what I can see, it doesn’t send the Google cookie and so identifying a user is limited to IP address.

What does this mean in practise? In a worst case scenario, a law enforcement agency with complicity from Google and your ISP can build a complete record of your internet browsing including time and location information. Eric Schmidt, Google’s CEO, has previously stated that if you’ve nothing to hide then what’s the problem? This may be true if you live in a Western Democracy although many people would argue otherwise. It’s certainly not the case if you live in a country where the human rights’ record is less ideal.

In European countries at least, abuse of this data is prohibited by the European Data Protection Directive and the country based laws that reflect it. This is just as well as imagine your employer, or anyone else for that matter, being able to get hold of all your internet activity including that from your home PC.

It’s also worth pointing out that none of these data gathering techniques are unique to Google but as it is the biggest player in the internet space, they can gather the most data and consequently attract the most criticism when people complain about privacy issues.

In theory there are a few things you can do to limit the information that you leak to Google. The simplest is to delete you cookies on a regular basis which makes it much harder to track your activity. There are also services like GoogleSharing that anonymise your Google traffic, but in reality you can never completely hide your browsing patterns. If you want to use the internet to the full, it is necessary to accept that some of your privacy is lost.

Privacy Online

The weekly podcast from the technology section of the Guardian recently did an item on online privacy. Although it was as informative and interesting as ever I was surprised that there was no mention of the data protection laws in place that, in theory at least, protect against many of the fears raised in the discussion.

Most European Nation data protection laws resemble, or should resemble, the European Data Protection Directive, EU 95/56/EC which is often summarized as follows:

Notice—data subjects should be given notice when their data is being collected;

Purpose—data should only be used for the purpose stated and not for any other purposes;

Consent—data should not be disclosed without the data subject’s consent;

Security—collected data should be kept secure from any potential abuses;

Disclosure—data subjects should be informed as to who is collecting their data;

Access—data subjects should be allowed to access their data and make corrections to any inaccurate data;

Accountability—data subjects should have a method available to them to hold data collectors accountable for following the above principles

From http://en.wikipedia.org/wiki/Data_Protection_Directive

At first glance, the directive appears to be fairly comprehensive and favourable to the privacy of the end user. Read deeper into the document and you find that the rules can be breached in cases of national security or public interest but otherwise is still sound.

My own experience of the directive in action came from a client in Germany for whom I was hosting a web application. They requested that I did not record the IP address of users who browsed the site as it breached the directive and they even came up with a court ruling to back up their argument. Like many web site administrators, I was recording source IP addresses for troubleshooting and security purposes but also to be able to produce statistics on the usage of the web site, particularly with regards to geographical location. Although browsing of the site was supposed to be anonymous, the IP addresses could ultimately be used to trace the individual user, which is what caused the problem with the data protection directive.

Although many of the abuses of data raised in the Guardian podcast probably occur on a regular basis, in my opinion it is not necessarily due to lack of legislation but more because of inefficient enforcement of existing rules. The directive does allow for compensation to be paid in the event of damage caused by misuse of data so I guess a few high profile cases with large payouts would help tighten up data protection law compliance.

Protecting Your Email

As I blogged last week, email in the corporate setting is extremely vulnerable to being read by others. Although a typical company Email Usage Policy allows for employee email accounts to be read, perhaps for Data Leakage Prevention (DLP) purposes, you envisage this being in exceptional circumstances on the orders of the CEO rather than on an ad hoc basis by the IT department over their morning coffee and packet of Monster Munch. In addition, once your message leaves the corporate network, chances are that it is then transmitted in clear text over the public internet.

Looking at the external email problem first, most mail gateways can support Transport Level Security (TLS) which provides encryption and authentication. Unfortunately, TLS is often not configured and is not supported by some public mail systems such as Gmail. TLS can also be configured between the client and mail server depending on the individual setup of the mail system which reduces network sniffing attacks but does nothing to defeat abuse from rouge system administrators.

End to end encryption addresses all of the above issues and has been around for some time now. The leading solutions are Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME.) Both solutions use public/private key technology for encryption and certificates for authentication and integrity. The difference between them comes with the approach to the implementation of how certificates are trusted. S/MIME uses x509 certificates which have an hierarchical approach relying on a trusted certificate authority whereas PGP uses a web of trust.

Wide spread adoption of both technologies has been hindered by issues around certificate management and distribution as before you can send someone an encrypted message you need to get hold of their public key. Although automatic key retrieval is possible by a variety of techniques including LDAP queries of public directories, the management overhead has often been off putting for many people. It’s also necessary to have your key store on each system for which you wish to read and send encrypted mails. This is particularly annoying if you use a web client as although Outlook Web Access supports S/MIME and there are Firefox addons for both PGP and S/MIME that work with Gmail, both require local certificate stores.

Mobile devices don’t help much either. The iPhone has no support for either technology and although Blackberry devices do, they exist only as paid for extras.

One solution I found to the certificate locality problem with a web client was to use a portable version of Firefox with an S/MIME extension for Gmail. I could then read and send encrypted emails from any PC. The same is possible in theory with PGP. It is unlikely this would be feasible for Outlook Web Access given that there isn’t a portable version of IE and many of the enhanced features don’t work with Firefox.

An ideal solution would be to allow mail programs to access certificate stores located on something like a USB key and also to introduce a “miny” USB interface for mobile devices adopted by all the manufactures so that each user could use a single store from multiple devices. A single online public directory where everyone published their public key would also be useful. Why not something like Facebook or Linkedin?

Side Channel Attacks against SaaS

The Register highlights a paper from Microsoft Research and Indiana University on information leakage from popular SaaS applications. Interestingly, the attacks work even when only HTTPs is used and are most effective when the application is relatively sophisticated and uses modern development techniques.

The attack is based on observing the size of packets between a user and an application and subsequently deducing the content. Although this initially sounds rather far fetched, AJAX technology means data transfer has “low entropy” making it far easier to guess the content that for a more basic application. “AJAX (shorthand for asynchronous JavaScript and XML) is a group of interrelated web development techniques used on the client-side to create interactive web applications. With AJAX, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behaviour of the existing page.” * To put this in layman terms, AJAX allows the user and application to efficiently transfer data without the overhead of display and formatting information. It is subsequently much easier to determine the packet content by observing its length as there is less “noise” in the transmission.

The paper gives an example of determining a victim’s gross income by observing packets from an online tax preparation site.

What risk does this pose to everyday users of SaaS type applications? In the main, risk is probably very low as an attacker first needs to invest considerable time in profiling an application. They then need to be able to capture the traffic of the target at the right time. Information leakage, although highly dependant on the application, is unlikely to include specific data such as password or other fields that are not selected from a list. In the real world, an attack would need to be targeted against a specific user or group to have a chance of being effective.

In the list of things you need to worry about for internet security, this kind of attack is fairly low on the list. Of course this may change as exploit techniques develop and so is well worth keeping an eye on.

*Wikipedia

Who Can Read My Email?

I recently had a client who suspected that their email was being read by someone else in their company. They wanted to know if this was technically possible given their setup, which was the fairly standard Microsoft Exchange server with Outlook as the client. When including members of the IT team as possible suspects I could think of at least 7 possible attack vectors for reading someone else’s email. Starting with the most basic, these were:

Password Compromise: Failure to keep a password secret or easy to guess allows for anyone to logon to the associated email account.

Shoulder Surfing: Reading someone’s email over their shoulder or more likely when the PC is left unattended without an activated password protected screen saver. For example, during a coffee or cigarette break.

Inappropriate Permissions: Although more commonly used for Calendar access, it is possible to share your mailbox with other users in the organisation. An inappropriate general rule could allow unexpected access to the inbox. A malicious user could setup such a rule with a few minutes access to an unattended PC.

Administrator Permissions: A mail administrator can modify permissions at the server level to allow other accounts to access a mailbox.

Message Forwarding: A mail administrator can forward a copy of all incoming messages to another mailbox, completely transparent to the mailbox owner.

Anti Malware Program Abuse: Such software can often be configured to filter messages based on keywords and forward a copy of filtered emails to another mailbox. The filter can be constructed in a particular way to ensure messages from a particular user are always trapped.

Network Sniffing: By default the RPC protocol, most often used to communicate between the client and server, is not encrypted allowing the email to be intercepted and read. The same is true for the SMTP protocol which is normally used for communication between servers in an organisation or for messages destined for outside of the company.

I intend to blog in the future about how best to protect against such attacks but thought it worth while listing the basics here. Protecting your PC where the email client runs with a secure password and making sure it is not left unlocked when unattended is the obvious first step. It’s worth remembering that you also need your colleagues who receive your messages to do the same. Reviewing the permissions on your inbox is also important. If the culprit is a mail administrator, it’s much harder to defend against or even identify. S/MIME is one technology that could help although it is not appropriate in all cases. At the organisation level it is vital the IT policies make clear what is and is not permitted with regards to email. Even if you can prove someone has been reading email not destined for them, if there is not a policy in place that states that such activity is forbidden, it’s unlikely you could undertake any disciplinary action.

Attacking the Virtual Machines

There was an interesting advisory posted by Core Security Technologies this week about a vulnerability in Microsoft Virtual PC. In actual fact no vulnerability had been discovered; instead weaknesses in Virtual PC had been identified which made exploitation of new vulnerabilities more likely. The problem was that the virtual machine memory management allowed the OS security mechanisms Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH) and Address Space Layout Randomization (ASLR) to be bypassed. This functionality mitigates the effects of buffer overflows and other attacks. So, although the issue presents no current risk to a system, it is more likely that future vulnerabilities will be exploitable in a Virtual PC environment when compared to stand alone systems.

This got me thinking about the risks presented by virtualisation and in particular side channel attacks. My first attempt at investigation in this area was after a seminar at Infosec 2009 where someone suggested an attack could be made against the graphics subsystem of a virtual host. Side channel attacks against virtualisation seemed to be a very new area at the time and I didn’t make much progress. I’ve subsequently come across a recent paper from the University of California, San Diego, which looked at attacking cloud architecture including Amazon’s EC2 and Microsoft Azure.

To summarize, the paper explains how it is possible to identify a physical host of a target VM in a cloud infrastructure and then activate a virtual machine on the same system. It then goes on to discuss possible side channel attacks using vectors such as the shared processor data cache. Perhaps the closest result that came close to presenting a risk was the possibility of identifying key strokes on the target VM. Several denial of service attacks were also proposed.

Assuming the paper is representative of current knowledge on side channel attacks against virtual machines, there is nothing really to worry about at the moment. The amount of effort required by a criminal hacker to gain useful information by this method is disproportionate to the expected return. It is an area of interest more or less exclusively to researchers. However this is likely to change and possibly quite quickly as more and more information is located in the cloud.

300 Billion Passwords in One Second

The Register reports more advances in brute force password cracking. Swiss security firm Objectif Sécurité used Solid State Drives (SSD) to store rainbow tables and consequently speed up each brute force attack. The read speed from an SSD is typically quicker than that from a traditional drive, which is why there is an overall performance increase.

Objectif Sécurité claims a throughput of 300 billion passwords per second when attacking a Windows XP MD4 password hash.

My own testing using Objectif Sécurité’s online proof of concept easily cracked the passwords from my test XP machine including the complex x%fF*Z3$. It couldn’t crack my 29 character pass phrase from Size Does Matter, but this is because Windows XP stores passwords longer than 14 characters in a different way.

Of course the default LMHash used with MD4 to store Windows XP passwords is weak and has largely been replaced in modern operating systems. However the speed improvement can be applied to accelerate brute force attacks on other algorithms.

What does this mean in real terms? It was already true that if someone could get physical access to your XP PC, they could extract your data. Now it is trivial to steal your passwords as well, which of course opens up all sorts of identity theft related crime possibilities. This makes disk encryption, and not reusing passwords more important that ever.

For info, I “harvested” the passwords on my XP machine by booting from my favourite Linux Live CD, Backtrack. I then used Bkhive to extract the key used to encrypted the SAM file where the LMHashes are stored. Finally I used Samdump2 to extract the hashes themselves.