A few days ago AVG, which is a nice lightweight and free anti virus program, started giving me strange error messages when I tried to update my AV definitions. It was complaining that the “CTF control files” had been corrupted somehow, but offered neither explanation nor remedy. After realising it wasn’t going to go away by itself :P, I did some digging and found the “ctf” files it was complaining about. To save you time looking, the files can be found in :
C:\Documents and Settings\All Users\Application Data\Avg8\update\download
Luckily this problem is very easy to fix, just delete the ctf files in that directory (but don’t touch the bin files as I believe these are the incremental AV definitions) and run a manual update.
I hope that helps anyone in a similar position. 🙂
Oyster cards are cards containing RFIDs which facilitate transport on the London Underground (and overground) networks. I had been wondering for a while how exactly they worked, but not finding much detailed information online I based my conclusions initially on my observations.
Here is what I have deduced.
1. Each RFID card has a unique ID which is recorded during each transaction with a card scanner.
Any Oyster user can access their usage history, either online or via a Oyster top up machine. This presents an interesting problem – if you can check up on where your card has been, what is to stop Transport for London from using the same information? Either individually or as part of the collective, it presents a very detailed picture of individual and mass use of the transport network.
Given that the Oyster card needs to be ‘tapped’ on the reader every time, it is safe to assume that the RFID does not have an internal power source. Instead, it only becomes ‘active’ with the energy it obtains via induction from the electromagnetic field close to the surface of the Oyster touch point. This energy is sufficient to power up the (presumably) CMOS device which then sends the encrypted data to the reader. It is not clear at this point whether the reader then sends back a response with the new balance to the card, or whether the entire ‘transaction’ process is done on the RFID card.
3. The information stored on the EEPROM is encrypted, most likely with symmetrical cryptography.
4. When scanned, the information from the Oyser card is used, it is not pulled from a central server.
When updating the Oyster card the card itself must be touched against a scanner. If this is not done the balance is not applied. I initially believed all balance and travel card information was securely stored on a ‘mothership’ server. This clearly can’t be entirely the case. Although, when a top-up is bought online, it is stored in the Oyster system until the Oyster card is touched on a reader somewhere in London. This suggests there is a ‘mothership’ server which records all this information, although it is likely it is only linked to newsagent kiosks and top-up points, not the barriers themselves otherwise there would be no need to store the information on the card.
5. Not only can the RFID store a balance, it can also store season tickets for a variety of durations and zone validities.
However, the title of the post suggests the security is broken, and indeed it is, although not through my investigations. A Dutch team took this a step further.
It turns out almost all my assumptions were correct, the Dutch team used a portable device to ‘touch-in’ on an Oyster reader, this disclosed the encryption key used on the Oyster device which they then stole. In possession of this, not only could they decrypt any Oyster card to determine how the information was stored but they could also theoretically generate any balance or season ticket, which encrypted properly would be indistinguishable from the real (paid for) thing.
However, to avoid no doubt countless hours of reverse engineering, the Dutch team brushed up against commuters on the tube and wirelessly interrogated their cards, stealing the information that was on them. This allowed the team to effectively clone cards which were valid, entitling them to free travel.
But the story does not end there, it turns out the company that makes the RFIDs for Oyster cards is called MIFARE, and their chips are used in a wide variety of sensitive installations in a variety of countries.
Whilst it seems the Internet enjoys a good Microsoft Vista bashing (see previous post on topic) research today came out suggesting Windows 2000, an eight year old operating system that recently entered long term support phase by Microsoft, is more ‘secure’ than Windows Vista. (Cue fanboy and antiboy posts.)
But this is rather misleading, let us not forget, Windows 2000 was released in February 2000, a dark era where firewalls, security software and Windows Update were treated with suspicion previously reserved for black magic. Ok, so maybe I am exaggerating slightly, but back then the average PC had either a Pentium 2 or 3 processor between 600Mhz – 1.2Ghz, between 32-128Mb of RAM and a 20Gb hard disk and was aimed at the business market not consumers who had the privilege of running Windows ME (let the justified ME bashing commence.) But we are still missing the point here, now the only users that run Windows 2000 (which accounted for about 2% of all Internet traffic in March 2008 ) are those who are comfortable power users (like Steve Gibson) or those with old hardware (e.g. Third world etc.) As such, it is not worth the malware authors’ time to target such a small percentage of the userbase when they are more likely to snare the vulnerable XP or Vista users.
Worse still, serious doubts have been raised over the validity of this study given PC Tools did not scientifically determine the states of key security within the operating like Windows Vista’s UAC or even which service packs were installed on the computers. As noted by Ars technica, often the first action by typical malware is to download the target package(s) onto a system immediately after it has been compromised with the usually relatively small initial exploit. This could mean that their numbers are greatly misleading when three or four ‘infections’ could actually be a single instance of malware.
The only way to scientifically conduct such a test, would be with three virtual machines, one running Windows 2000, one with Windows XP and finally one with Vista each running a with a comparable set of security tools and the latest patches. That way, after each exposure, the virtual machine could be examined to determine if the exploit was successful and if so, the degree to which the target machine was compromised. At the end of the experiment, the virtual machine is ‘switched off’ without writing the changes to it’s virtual disk and restarted to test the next exploit. Using this methodology, all exploits can be tested equally and methodically and various configurational permutations can also be tried (e.g. Operating systems with only default security measures etc.)
Let us also not forget, there is no way to tell whether these threats are serious silent drive by download style exploits (which would constitute a serious threat) or as a result of user ignorance which even the most secure operating systems and security applications can not guard against. Playing Devil’s advocate, I can see a case that unscientific tests like these better represent real world conditions, however it can not be used to judge to reliability or security of Operating Systems nor the users using them as no conditions nor variables have been made constant. As such, unfortunately, these results have no validity as far as I am concerned.
I was bemused to read on bbc news earlier that a trivially simply ploy stung half a million file sharers. The concept is nothing new having been started a fair few years ago by virus / malware writers and adopted by Copyright enforcement agencies in recent years. Do the anatomy of a decentralised file sharing system, anyone can seed a file. Once this seeded file is made available to the peer-to-peer network it either becomes advertised to a localised central file distributor (referred to as a Super Node or Server) or is found during a spider search query run by another user logged into the peer to peer network. If these files are topical or sought after, they can be transferred onto a different node (client) rapidly. There they are stored in the second user’s ‘shared’ directory where more people can download it.
Once a seeded file has been downloaded and spread over a few tens of nodes the rate at which it can be downloaded by others increases almost exponentially with a cascade like effect. Other people of the peer to peer network are lured into downloading this file based on the number of people who have it therefore assuming it must be genuine and would be comparatively quick to obtain. Couple this with a topical or sought-after song / album or file aimed at the masses (who statistically would contain a fair percentage of PC-illiterate users and those with a penchance for agreeing to all the pop ups they come across) means these files explode across networks.
This malicious file in question appears to have masqueraded as a MP3 by Girls Aloud. Given the fact that on running the file pops up a message saying the computer requires a codec to play the song and tries to direct you to a website in order to download it, most computer users would stop and reexamine what they had just downloaded. People that brazenly proceeded and downloaded the malicious ‘codec’ package had spyware installed on their system which would ‘bombard’ users with pop ups. Also, the download file would spawn copies of itself within the User’s shared folder under different names to try to make itself attractive to a greater audience.
But what happened? How were people tricked into downloading an MP3 file but ended up running a malicuous program? The answer to this lies in the file type. Broadly speaking, there are two ways in which a file can be opened:
1) via script or binary execution (e.g. .exe, .com, .vbs, .java, .scr … and some others)
2) via program read from an external application (e.g. .txt, .doc, .wav, .mpg, .avi …. and MANY more.)
MP3 files (Moving Picture Experts Group version 1 audio layer 3) are the latter, upon execution, Windows searches through its list of known file extensions stored in the registry to see what it should do. It instantly finds the entry for MP3 and sees this type of file is handled by a media player like Windows Media Player, WinAMP, iTunes etc etc. Windows then executes the media player which, on loading, opens the MP3 file specified in the command line argument, decodes a block, fills its buffer and starts to play. Unless a clever trick like a buffer overflow is used, which have historically been responsible for security breaches in various Windows programs as well as console homebrew development, this renders all ‘program read’ type files harmless*. As such we have to look elsewhere for the source of this problem.
That brings us nicely to the point I wanted to raise in this post, file extensions and more specifically, security vulnerabilities in their implementation. Recent versions of Windows from XP (and possibly earlier, I can not remember) have automatically hidden the file extension by default leaving the user to distinguish between file types by iconographic representations. Whilst at times this is both cleaner looking and more functional, it does present an interesting security problem, what if there are two file extensions? Window will quite happily truncate the file .xxx from a file name leaving the first extension, despite the fact Windows ignores anything before the final .xxx . As a result, if you name a file SomethingInteresting.mp3.exe, in its default state, Windows will happily display the file as SomethingInteresting.mp3 but will execute the file as an EXE when double clicked. Obviously, if you quieried the file by right clicking on it and selecting properties you would be immediately told what type of file it is, but most people will take the file at face value.
Luckily there is a very simple way to gaurd against such black magic, in Windows XP and Vista** in the file browser, goto the Tools menu and select Folder Options.
In this dialog, uncheck ‘Hide extensions for known file types’ and click Apply followed by clicking Apply to all folders.
And that’s it! A simple check box and some common sense now separates you from being lured into downloading fake or malicious files.
* Some files like some movies can have containers which direct the media player or operating system to web pages. It is not just media files which are vulnerable but this is a completely different topic.
** In Vista you may have to enable the classic menu
Since I was on the topic of passwords, I ended up writing a brief post about how to choose a good password and general password security.
A good password should be four things:
1) Use at least two cases* (e.g. lower case, upper case, ‘number’ case and ‘character’ case.)
2) Be a suitable length – anything less than 7 characters should be avoided.
3) Not include repetition within the password and should not be used for more than one application.
4) Be something personal or easy to guess (a birthday, pet or family member name or related to the application – for example ’email’ as a password for your email account would be ludicrous.)
Let look at some examples:
The old favourite: “password”. As you can see from the rating below, it is a terrible password. Not only is it predictable (and one of the most commonly used passwords) but it uses only one case and has some repetition (sequential double ‘s’.)
A slightly better version of the old classic: “pa55word”. This time, all I had done is replaced the ‘s’ with the 733t-ified version. By adding numbers, the complexity of the password has increased dramatically although it is still hindered by repetition.
Lets go even further: “Pa55Word”. Now we are using three cases and the result is predictably much stronger than using two cases alone.
And finally, lets go nuts: “Pa5!Word”. Using all the cases available on the Roman alphabet and removing all sequential characters. It is still not a brilliant password, but it is head and shoulders above the others.
Whilst choice and selection of password is important, it is not always essential to pick random strings as your password. Whilst passwords like gY$5c0p[ are very strong (it scored 92%) it is difficult for most people to remember them due to their entropic nature. It is therefore important to marry practicality with security and my advice to anyone picking a password would be to think of a word (or phrase) and substitute some of the letters for numbers / capitals / characters as in the example above**.
1) If you are choosing a very important password, pick a passage from a book. For example, the first 3 (or as many as you want) words from the first line of a particular page** and add a good degree of randomness to it as described above. If you need to jog your memory in the future, simply refer to that page and it should normally come back to you.
2) If you must write or record your password, obfuscate (via a stenographic method) it! Split it in half (or more pieces) and hide the password/passphrase in several bits of innocuous data. For example: If you made your password Nice225 Woods987 then you could store the following contacts somewhere:
William Nice +44207 750 1225
Christian Woods +43133 987 3245
The same method can be applied for card PIN numbers which can be stored as part of a dummy contact on a mobile phone.
3) Never stick to the same password for more than one service – if someone compromises one password, all your services will be vulnerable.
4) Scale your password to the particular security environment. A password that is used for an unencrypted email account need not be as strong as one for a SSH / VPN / Remote Terminal or VNC account.
5) For accounts you are particularly cautions with, rotate your password frequently. This need not be very week or even every month. If you change your password every 2 or 3 months, it will provide a much better protection against online stalkers who may be lurking and checking your accounts / emails periodically.
6) Passwords can be passphrases! It is much easier to remember a line of a story / poem etc than a bunch of rubbish. Unfortunately, even if that line of text is long enough, it will not offset the problems** caused by character repetition, although it would be important to obfuscate it in some way.
* The reason cases are so important is simply a matter of maths. If an attacker knows the password is only one (or two) cases, it significantly reduces the amount of computational time to brute force (or guess) the password. Take for example, a password with only one case (lets assume its lower case). There are only, 26 characters in the Western (Roman) alphabet meaning the complexity of the password is:
…if the password is 4 characters long, there are : 456976 combinations.
If the password is 8 characters long, there are : 208827064576 combinations.
Now lets assume two cases (lower and upper case) are used. Now the attacker has to try a total of 52 character combinations for every character suspected to be in the password.
…if the password is 4 characters long, there are : 7311616 combinations.
If the password is 8 characters long, there are : 53459728531456 combinations.
You can quickly see the significance in the numbers. If to round it off, we try all the (printable) characters available (94), an 8 character long password would have 6095689385410816 combinations!!
** Generally speaking, when trying to create a password, we are trying to create as entropic an outcome as possible as this will be the most computationally time consuming to break. The entropic value measured per key is calculated on the basis that each key press is independent and the entropy per key essentially increases with increased character range.
Due to the manner in which language is constructed, the occurrence of letter like vowels is dramatically increased leading to a much decreased entropy per key. This means, in order to create a reasonable secure 64bit key, you would need approximately 58 characters as opposed to only 10 if all characters are used.e