Contactless Credit Card and ID Card Skimming

This news post was brought to my attention, showing a steel-woven wallet to keep RFID credit cards safe. To some this may sound a bit far fetched and to others nothing new or to worry about, but hear me out.

With new contactless credit cards you can make small purchases without resorting to the Chip-and-PIN transaction that is most common. Instead, you just 'touch' your card on the reader and away you go. The problem with this is that you cannot turn your card off. I can bring the reader to you; I just need proximity. These readers are small and pocketable, and I can read your card without you taking it out of your pocket. The more high-powered my reader, the further away from you I can be to read your card. Initially, the cards gave out the name on the card, the card number and the expiration date. After people showed that it was easy to skim this information off the card, most have removed the cardholder's name from this list. They have also introduced transaction IDs to help protect the cards from being cloned. However, as the introduction of RFID identity cards increases, we will be giving the cardholder's name out again on those.

It has been argued that it is more productive to attack the databases of card details, and still far too easy, so people won't bother trying to read the cards in your wallet. However, I can still obtain a legitimate payment reader and just read your details off and collect your money directly, even if I can't clone the card. In the UK, these contactless transactions are for small amounts of money (£5-£10 typically), but I can collect that from you without your knowledge in a variety of ways. I can use a small pocket device to take a payment from your card directly, but this has to be one at a time and, in some countries, only for small amounts of money. (See the video below for a mobile phone that can process contactless credit card transactions.)



Maybe this isn't worth it to anyone but a petty criminal, but it is relatively easy and cheap. Another way would be to go to a crowded area (public celebrations or gatherings of tens or hundreds of thousands of people for example) and use a high-powered reader to read lots of cards at once. If I can steal £10 from 100,000 people, that's £1m in an afternoon! Somewhere in the region of half a million people gather in Trafalgar Square, and environ, for the New Year celebrations and similar numbers for the Chinese New Year celebrations a little while later.

RFID readers are all over the place and we don't pay them any mind. Shops use RFID readers to catch shoplifters at the entrances. Do you categorically know that they aren't reading your cards instead of catching shoplifters? Would you notice an extra £10 transaction in a shop that you did buy something in? All of our buses and tube stations in London use RFID readers for ticketing. A vast number of commuters will have their Oyster card in their wallet or purse along with their other cards. They don't remove the Oyster card to touch it, they just touch the whole wallet. I could read the other card information at the same time. In fact, do we know that these details aren't logged and just ignored? If they are logged, then maybe we could attack Transport for London's computer system and extract people's credit card details.

Maybe people won't do this with credit cards. What about large banks or other companies that use RFID door entry cards and ID cards? I could read their ID and possibly gain access to their building. Will the ID give me a username to work with? If I can gain physical access to a bank building then I have a huge array of attack vectors at my disposal; it is critical to keep the hackers out.

Even if a hacker can't clone these types of cards, they can still collect information about people and about companies. It is perfectly possible to identify all the employees of a company using RFID cards for door entry, as you can have a high-powered reader near their entrance or at public transport stations. This now gives a social engineer a target and some information to use. Maybe we should all be holding our wallets over the top of shop gates and away from other readers or buy one of the shielded wallets from people like ID Stronghold or Herrington.

Proposed Pseudo-Code for Hacking Process

It is quite common in Information Systems to use pseudo code to describe a process. I have often thought that the same principle can be applied to the process of hacking an organisation, which may help people understand the process and how to protect themselves. Below is my proposal for this pseduo-code for the hacking process. This is very much a work in progress. I would welcome feedback on it and I will update it as suggestions are made or as I feel it needs revising.

organisation = proposed target
organisation.footprint(value, effort, risk)
profit = value - (effort * risk)
if profit > 0 then
  organisation.enumerate()
  select attack_type
    case DoS
      engage_botnet(myBotnet)
      myBotnet.launchDDoS(organisation)
    case Access
      organisation.gainAccess(myAccount)
      myAccount.Elevate()
      organisation.installBackdoor(myAccount)
      organisation.cleanUP()
  end select
else
  exit
end if

This highlights the fact that we only need enough security to make it not worthwhile attacking, i.e. it will cost the attacker more to compromise our system than they will gain. Who would spend £1m to get £10 worth of information? We don't need (indeed cannot have) absolute security, just enough to protect our system. It also highlights another interesting point. Perhaps we should make our countermeasures public - not the actual implementational details or versions, but the fact that they are in place, e.g. that we have an IDS. Consider blatant versus hidden CCTV cameras. Cameras in plain sight deter most criminals, whereas hidden cameras spy on criminals while they perpetrate their crime.

We want to make the risk of being caught/prosecuted value high, so that hackers require a higher value:effort ratio, which we won't give them. Given two identically protected organisations with the same value, would you attack the one that doesn't monitor activity or the one that does?

Obviously, the above is very vague and doesn't provide methods to complete these tasks, but that is not the point of this post. Backdoors and Trojans are usually relatively easy to install if you have the right level of access to the system, so much of your security is going to hang on stopping a hacker from gaining access. Gaining access to an organisation is usually performed in one of four main ways:

• Malware
• Sniffing
• Direct Attack
• Social Engineering

There are ways to protect yourself, up to a point. Some of the most critical are:

• Installing Antivirus/Antispyware
• Latest OS and Application Patches
• Enterprise-level firewall, with IDS/IPS, AV, etc.
• Personal firewalls on all mobile devices
• Secure, hardened configurations
• Browser lock-down
• Encrypted communication (e.g. SSL/TLS, VPN, etc.)
• User Education!

The last point is often overlooked as a critical security practice. Please feel free to comment.

Blackboard (in)Security

The University recently recently paid for a vulnerability assessment and penetration test, which came back saying that, apart from a few minor things, everything was fine and secure. I take issue with this finding for several reasons, most of which I won't go into here. Now, I haven't actually seen the report produced by the company, but I have had verbal reports from the IT technicians that 'nothing serious' was found.

The University uses a hateful product called Blackboard as a Virtual Learning Management System. This is a web-based application allowing access to learning materials, grades, etc., from anywhere in the world. The problem is that it doesn't use an encrypted connection and uses a simple Session ID cookie to assert that you are an authenticated user. There are two problems with this. Firstly, if I capture your cookie and send it with my HTTP request, then I will be treated as you and can see or do anything as you. Secondly, and much more importantly, is that the username and password are sent in plaintext!

I shouldn't have to explain why this is such a bad idea, but I can't understand why this wasn't picked up as a major security hole. A simple packet sniffer will pick up anyone's username and password, giving full access to the network and other services, such as email, home directories, etc. The trouble is that it's not just students who login to this service, all the academics and admin staff do as well. You can imagine what could be done by grabbing a lecturer's username and password.

How easy is it to actually launch a sniffing attack? Well, surprisingly easy (unless you are a pen tester, in which case it won't surprise you at all). Consider the fact that people do connect to this service from public wireless hotspots or from shared networks, such as the halls of residence or the university network itself. It isn't difficult for someone to sniff the network and extract the user's password. 'MAJOR SECURITY WEAKNESS' not 'nothing serious'.

I advise people to connect to Blackboard instances via SSL connections at the very least. It doesn't stop all the attacks, but it will stop simple packet sniffing.

Secret Sharing Algorithm for Protecting Files in the Cloud

Data stored in the cloud can be compromised or lost (see my previous post). So, we have to come up with a way to secure those files. We can encrypt them before storing them in the cloud, which sorts out the disclosure aspects. However, what if the data is lost due to some catastrophe befalling the cloud service provider? We could store it on more than one cloud service and encrypt it before we send it off. Each of them will have the same file. What if we use an insecure, easily guessable password to protect the file, or the same one to protect all files? I have often thought that secret sharing algorithms could be employed to good effect in these circumstances instead.

What are secret sharing algorithms? They are algorithms that will share a secret between several parties, such that none of them can know the secret without the help of others. Either all or a subset of them will need to get together and put their parts together to obtain the original secret. A simplistic solution can be achieved by XORing the secret with a random number, then giving the result to one party and the random number to the other. Neither one can find out what the secret was without the other. To retrieve the secret they only need to XOR the two parts together again. This can be extended to any number of parties.

A more sophisticated way would be to allow the secret to be retrieved from a subset of the parts distributed. In the previous example, if any of the parties loses their part, or refuses to disclose it, then nobody can reveal the secret. This isn't much good if one of our cloud service providers fails. On the other hand, if we can share the secret between three people, but only require any two to regenerate the original, then we have some redundancy. This is an example of a (k,n) threshold scheme with k=2 and n=3.

How do we achieve this though? Well, Adi Shamir proposed a simple secure secret sharing algorithm. It is based on drawing graphs. To uniquely define a straight line, you need two points on that line. Similarly, to define a parabola you need three points. A cubic requires four, etc. So, we can distribute points on a line to each party we want to share the secret with. The order of the line will determine how many of them need to get together to regenerate it. So, we could define a random straight line and distribute three points on it to three different parties. However, only two of them need to get together to regenerate the original secret.

We set up a (k,n) threshold scheme by setting the free coefficient to be the secret and then choosing random numbers for each of the other coefficients. The polynomial then becomes the following:


where a₀ is our secret. Now we can distribute points on the line to each of the n parties simply by calculating y for a series of different values for x. We can use the Lagrange Basis Polynomials to reconstruct the equation of the line from k points. However, we do not need to reconstruct the whole line, we are only interested in the free term. This simplifies the equations that we need to use. For example, if we have a straight line, then we only need two points (x₀,y₀) and (x₁,y₁). We can then calculate a₀ as follows:
Similarly, for a parabola and three points (x₀,y₀), (x₁,y₁) and (x₂,y₂) we have:
This should be fairly simple to implement and use. You would need to sign up to a few cloud services, but you wouldn't have all your eggs in one basket and you wouldn't be reliant on weak passwords.

PhoneFactor Security

I was asked recently to look at the security of the PhoneFactor 2-factor authentication solution. If you don't know what it is, then you can find out more here, but essentially you enter your username and password, then they phone you on your pre-defined number and press the # key to validate the authentication. The problem with just pressing the # key is obvious, but they allow you to configure entering a PIN number rather than just pressing the # key. To my mind, there should be no other option than having to type in the PIN number. However, this isn't necessarily a brilliant idea. As I've said before in this blog, a lot of phones log the digits dialled, in which case that PIN isn't secure.

I was also told that the PSTN and GSM networks are secure, so this is a good solution. I'm not sure I agree that PSTN and GSM networks have good security. Analogue PSTN is easy to listen in to with proximity and GSM can theoretically be cracked, and probably will be within 6 to 12 months. So that PIN number isn't really secure. Plus there is the cloned SIM card problem as well.

http://www.mobileindustryreview.com/2009/08/gsm-encryption-can-be-cracked-for-500.html

Having said that, PhoneFactor looks quite good as you enter the PIN on the phone line, not the login dialogue. The problem that Bruce Schneier has referred to is that of a Man-in-the-Middle attack. Most 2-factor authentication methods are susceptible to a MITM attack, including RSA tokens and other hardware tokens. Basically, if I set up a website, for example, to mimic your corporate portal, then you will enter all your details into my page, including your one-time pass code. I will forward them on to the real portal and do whatever I like logged in as you.

The one advantage is that I have to intercept every login attempt, and wait for you to login before I can gain access. Without a 2-factor system, once I've read your username/password combination I can login whenever I like. PhoneFactor would appear to mitigate some of this risk by doing the authentication out of band. However, there is still an attack vector for a MITM attack. In the same way as before, you login to my portal, I forward your credentials, PhoneFactor phone you and you put in your PIN, they enable my session! Obviously, there are other attack vectors as well.

Another potential issue is that you are charged for the phone calls made by PhoneFactor on your behalf. These can be significant costs. In the UK calls to landlines are free, but am I always at my desk when I want to log in? No, I'd want it on my mobile; that will cost me $0.23 per login (East Timor $3.25). So, I could rack up the bill for you company by getting them to call through to someone. If I do this enough times (especially if that person is on holiday in another country with higher charges) I can use up all your credit and none of your users can login.

There is a privacy issue as well. PhoneFactor will know every time you log in or access your bank, etc. How do they protect that data? Do you want them to know that information, even if you do trust they won't accidentally disclose it?

However, I am not against 2-factor authentication. Indeed I think it is a good thing, as users will choose poor passwords, reuse them everywhere and write them down. Similarly, they will give them away to phishing scams. 2-factor authentication removes all of those problems, but by no means is it absolutely secure. PhoneFactor seems OK, but it's not particularly cheap or phenomenally secure. There are some other good software solutions that are pretty cheap as well, and that can combat shoulder-surfing when entering PIN numbers, etc. There are a couple of examples on a blog post I did a couple of months ago: http://blog.rlr-uk.com/2009/06/user-friendly-multi-factor.html

The bottom line is that they are more secure than username/password, but none of them are absolutely secure against all attacks.

Security Questions for your Cloud Services Provider

Comodo Vision Video Blog

Cloud Services or Cloud Computing are getting a lot of attention in IT circles, promising cost-effectiveness, flexibility, and time-to-market advantages over traditional alternatives. However, they also increase your security risk by expanding your security perimeter to include that of your service provider. This video blog poses some key questions to ask your Cloud services/Cloud Computing provider regarding data security as well as advice to reduce the risk to your business introduced by Cloud Computing.

See my third video blog for Comodo Vision here.

APWG Report 1st Half 2009

On 27th September the APWG released their First Half 2009 Phishing Trends Report. This provides some interesting/worrying reading. Most notably is the rise and rise of rogue anti-malware programs.

Rogue anti-malware programs are programs that run on a user's machine and falsely identify malware infections. They then inform users that the malware can be removed by purchasing their anti-malware program. The installed software, in many cases, does absolutely nothing. The malware author has made their money off the user and doesn't care about them or the fact that their machine is left vulnerable to other malware. However, there is another breed of rogue anti-malware that will install other malware onto the user's machine, often adding them to botnets or adding trojans and spyware. According to Panda Labs' Luis Corrons, rogue anti-malware programs are proliferating with "exponential growth. In the first quarter of 2009 alone, more new strains were created than in all of 2008. The second quarter painted an even bleaker picture, with the emergence of four times as many samples as in all of 2008."

Most of these rogue anti-malware programs have a common root - they even look the same. So how come they aren't detected as malware? Well, often they employ server-side obfuscation so that each version is slightly different, thus defeating some signature-based scans. Also, you have to remember that many of these don't perform any malicious actions and, therefore, don't trigger other alarms.

What can we do about rogue anti-malware? Well, simply don't trust anything on the Web saying that you are infected or that they will scan you for free. Do not install any anti-malware from a company that you do not know and always check for validity of links and downloads. There are many companies out there providing free basic anti-malware or sophisticated products for a relatively low price that are legitimate, such as: Panda Security, AVG, Comodo, Symantec, etc. If you do get infected by one of these programs then you need to remove it. Instructions for removing the most common ones can be found at http://www.anti-malware-blog.com/ - N.B. be warned that I have not assessed or validated their instructions and there is no guarantee that they won't cause other problems.

What about the rest of the report? Well, phishing is still on the increase, with reported phishing highs for the first half of the year exceeding those of last year significantly (about 7%). 21,856,361 computers were scanned to determine host infection rates. 11,937,944 were found to be infected (54%), which is an increase of over 66% from the last quarter of 2008. Banking trojan/password stealing crimeware infections rose by more than 186%. Finally, payment services have taken the top spot in the most targeted industry sector from the financial sector, although this is still a close second. To see how this compares, a previous blog post of mine on this shows how things have changed.

For more information about the Anti-Phishing Working Group, to report phishing attacks or to see their reports yourself, visit http://apwg.org/