Monday, 31 August 2009
Actually there are three overall approaches to system trust on networks. We can trust all of the people all of the time (bad idea, but much more common than you'd think), trust no one at any time (maybe too excessive and hinder functionality), or we can trust some of the people some of the time. The last one is usually the best strategy to adopt for your network.
Finally, we have to decide on the overall approach to security. Are we permissive or restrictive? In a permissive environment you can do everything, apart from those things on a blacklist. In a restrictive environment, you can do nothing, apart from those things on a whitelist. From a security standpoint restrictive is better, but from a usability standpoint permissive is better. If you can manage the whitelist successfully, this is the better solution and only trust some of the users some of the time.
"... a devious piece of criminal coding that has been quietly at work in a clutch of cash machines at banks in Russia and Ukraine. It allows a gang member to walk up to an ATM, insert a "trigger" card, and use the machine's printer to produce a list of all the debit card numbers used that day, including their start and expiry dates - and their PINs. Everything needed, in fact, to clone those cards and start emptying bank accounts."
This is possible because ATM Terminal vendors have succumbed to financial pressures, and the demand for greater functionality, and moved to using standard modular PC architectures and off-the-shelf operating systems, such as Microsoft Windows and Linux. These ATM devices then become vulnerable to similar malware as their desktop counterparts.
SpiderLabs, part of Trustwave, identified that in this case a new version of the 50KB lsass.exe Windows XP file is loaded onto the system via a compromised Borland Delphi installer utility, isadmin.exe (note, that's LSASS.EXE, not 1SASS.EXE as some have reported). You can view the full report from Trustwave as a PDF here. The legitimate lsass.exe executable is used to cache session data in Windows, so that users don't have to re-enter passwords when receiving new emails or returning to a website, which is essentially what the malware developers want to do with the card data. Actually, this has no place on an ATM, but may not be picked up, due to the fact that it is, by default, on most Windows XP installs.
If a trigger card is not detected, the malware stores the transaction data to a file called tr12 and key or PIN data to a file called k1 in the C:/WINDOWS directory. If a trigger card is detected, then a menu of 10 options is displayed for 10 seconds, with functions including: uninstalling, deleting logs, printing logs via the built-in printer encrypted with DES and possibly the ability to export the data onto the trigger card. This particular malware only works on transactions in US dollars, Russian Rouble or Ukrainian Hryvnia. It is also said that chip-and-PIN cards across Europe are not vulnerable to this malware as the PIN is encrypted in the secure PIN pad.
It has been speculated that deploying the malware was either an inside job or the result of bribes and threats; the reasoning being that an attacker would have to have physical access to the ATM to deploy the malware. However, the ATMs and banking network, although separate from the Internet, have not necessarily been hardened enough. Back on 25th November 2003 the first known case of a worm (Welchia) infecting Windows XP based ATM machines was reported, which used the closed financial network to propagate. This was possible because the ATMs weren't patched by the financial institutions in question. This brings on the whole problem of patch management on ATMs as well as placing greater restrictions on the financial networks. How long will it be before keyloggers are available for chip-and-PIN cards as well?
Friday, 21 August 2009
Don't use WEP; it can be broken easily. I won't bore you with details here, but I refer you to Google instead. However, there are several flaws such as using a linear Integrity Check Value, such that predictable bit-flipping can be used to send invalid messages that will appear to be valid. Secondly, the 40-bit shared secret is 'extended' by use of a 24-bit per-packet Initialising Vector. As any cryptographer will tell you, the more often you use the same key, the easier it is to recover the plaintext (particularly if you have known plaintext, which we do have in the headers of network packets of course). IV collisions happen surprisingly quickly, especially on corporate wireless networks, as they will usually have reasonably heavy load. TKMaxx found this out the hard way when they lost half a million credit card details to a hacker sitting in their car park. This also shows that they almost certainly didn't segregate the traffic and force it through a firewall.
So what can we do about this? Well, all modern equipment will support Wi-Fi Protected Access (WPA) and WPA2. A standard implementation of this is to use a Pre-Shared Key (PSK), i.e. a pass phrase, and the AES block cipher for encryption. This is the minimum requirement for a wireless LAN. Again, don't use simple passwords, as the security of your system is relying on them. You should use long complex pass phrases, with punctuation. Another idea is to encrypt a pass phrase using itself (or another) as a key in an encryption tool; then use the resulting base-64 encoded string as your PSK. However, automatic key negotiation and the use of digital certificates is a better option in a corporate environment (remember for wireless access you can run your own internal certificate server so that you don't incur additional costs).
This doesn't solve everything though. A little while ago the head of a department in an organisation I was involved with decided that he didn't want to have to use the docking station for his laptop as it constrained where he could work in his office. So, he didn't contact the IT department, but instead went to his local IT retailer and bought a cheap wireless access point. He plugged this into the network and, not only did he not configure any security, but he didn't even change the default password on the device. Do you categorically know that you don't have a rogue access point on your network? This can be stopped by using technologies such as 802.1X port-based authentication and a RADIUS server.
Wireless networks also need to be treated as insecure and separated from your wired network via a firewall, with real-time virus checking and an Intrusion Detection System. This doesn't mean that they have to be unprotected themselves; you should still protect them from outside attack by firewalling them off from the Internet. The important point is not to let traffic flow, unchallenged, from the wireless network onto the wired network. This is not often done though. I was in Vienna recently on business and the hotel I was staying at had free wireless access for guests. However, one night I couldn't get access and asked why. I was told that they had switched it off as someone was trying to access their servers (they weren't very proficient or experienced hackers fortunately). The point that I found more worrying was that their public wireless network was directly connected to their servers, which the hold names, addresses and payment details of guests and even the door card programming details! You can imagine what could happen if someone were to get into the servers...
Wireless networks and wired networks should not coexist on the same subnets. This is for two reasons. Firstly, it is easier to attack and, therefore, attach to a wireless network, so you don't know categorically that all stations are legitimate. Secondly, most wireless networks are used to connect mobile devices, such as laptops and netbooks, to the network. Do you know that these haven't picked up any malware whilst not connected to your corporate LAN? You can address the latter with network access control, but that's a different topic. However, all traffic from the wireless network should be treated with a level of suspicion and therefore separated. You don't have to have a separate Internet connection or new wiring to achieve this; VLANs (or Virtual LANs) can solve the problem by logically segregating the traffic into the firewall. This also allows you to provide public wireless access for visitors/customers as you can run two separate, VLANed wireless networks through the same access points onto the network - one with limited access to the corporate LAN and the other with none.
Wireless networks can be implemented securely, but remember to separate your wired and wireless networks and implement secure encryption and authentication.
Friday, 14 August 2009
Assuming that you need the data for business intelligence purposes and that the IT department can't or won't (for some good reason) allow this to be done online through a secure connection, then you must anonymise the data first and then encrypt it. Why do you need to know the names, addresses and credit card numbers of your customers when on the road TK Maxx? Why do you need the names, addresses, dates of birth, national insurance numbers, salaries and bank details of your employees when away from the office UPS? I'm afraid, that the only reason I can think of to have the non-anonymised data is for fraudulent purposes (please send me a comment if you can think of a legitimate reason).
Drawing from Pierangela Samarati's session at IPICS, I'll give a very brief overview of data anonymisation. There are two basic techniques to anonymise data: generalisation and suppression. With generalisation, we use a more general value in place of the specific value, e.g. birth year rather than birth date, postal district rather than full postcode (KT1 rather than KT1 2EE), credit card issuer rather than full credit card number (1234 56** **** **** rather than 1234 5678 9012 3456), etc. Alternatively, we can suppress the sensitive information by removing it totally.
Now there is a whole academic discipline surrounding data anonymity and how to achieve k-anonymity that I won't go into here. I'll just look at what the above means to data such as a normal company might want to use for business intelligence reasons, rather than surveys and data gathering purposes. In this sense, we are trying to protect the privacy of our customers, employees, etc., above all else, rather than have the minimum anonymity possible for the data set. I will use the following table to illustrate the anonymisation.
|Alice||02/02/64||KT1 1AB||1234 5678 9012 3456|
|Bob||16/02/64||KT1 1BC||1234 5678 9012 3467|
|Charlie||08/04/64||KT1 1CD||1234 6778 9012 3478|
|David||02/04/66||KT1 1DE||1234 6778 9012 3489|
|Edgar||04/04/66||KT1 2AB||1234 6778 9012 3490|
There are many schemes for anonymising this data, but I'm going to concentrate on Attribute Generalisation combined with Attribute Suppression. This basically means that we will generalise each value at the attribute level (i.e. the same level of generalisation will be applied to all values). Secondly, we will suppress any attribute that uniquely identifies someone. Using minimal generalisation we would get the following table. ('-' denotes suppressed data and '*' denotes generalised data)
|-||**/02/64||KT1 1**||1234 5678 9012 34**|
|-||**/02/64||KT1 1**||1234 5678 9012 34**|
|-||-||KT1 1**||1234 6778 9012 34**|
|-||**/04/66||KT1 1**||1234 6778 9012 34**|
|-||**/04/66||-||1234 6778 9012 34**|
We have had to suppress Charlie's birthday, because she was the only one born in April 1964. Similarly, Edgar is the only one who lives in KT1 2**. However, we haven't achieved anonymisation here. If we know Charlie was born in April 1964, then this date doesn't appear in the table and only one date is suppressed, so we know her tuple in the table. Similarly, if we know Edgar lives at KT1 2AB, then we know that his is the last tuple. The credit card details should be generalised more than this as well, as others may store the last four digits of a credit card number, so it may be possible to cross reference. Also, why do we need their credit card number for business intelligence? Surely issuer is good enough? So, we can do the following.
|-||**/**/64||KT1 ***||1234 56** **** ****|
|-||**/**/64||KT1 ***||1234 56** **** ****|
|-||**/**/64||KT1 ***||1234 67** **** ****|
|-||**/**/66||KT1 ***||1234 67** **** ****|
|-||**/**/66||KT1 ***||1234 67** **** ****|
This gives us a full count of customers, their geographic locations, age and credit card issuer. I suggest that this is enough information to cover most queries that you may wish to run for business intelligence purposes and, therefore, the maximum that should ever be stored on a mobile device or removable media. This data should also be encrypted.
Of course, this doesn't solve all problems. What if you know Edgar was born in 1966? You now know his credit card issuer, which enables you to launch a directed phishing attack on him. Data Anonymisation can fail in the face of attack, particularly when there is external knowledge, which you have no control over. The moral is, don't store sensitive data on mobile devices or removable media. If this really isn't possible to avoid, then you must anonymise it first and encrypt it.
Tuesday, 4 August 2009
"pptPlex uses Plex technology to give you the power to zoom in and out of slide sections and move directly between slides that are not sequential in your presentation."
"...pptPlex can help you organize and present information in a non-linear fashion."
If you don't know what any of this means, then you should ask me to do a presentation :-) or have a look at their videos. It's very simple to install and use. However, remember that you need it to be installed on your presentation machine in order to give the Plex version of the presentation, otherwise it will just show as a normal PowerPoint presentation.
If the pptPlex Ribbon Tab doesn't display in PowerPoint...
There are several reports of the plug-in becoming disabled on some systems and the ribbon tab not displaying. There are solutions on the forums for this, but most of them have an error in the selection of which plug-ins to manage, so I'll quickly give an explanation here. If you have any other problems, don't ask me, use their forums.
- Click the (round) Office button and then click on PowerPoint Options
- Select Add-Ins from the left
- If pptPlex from Microsoft Office Labs appears in the disabled list then carry on, otherwise you have a different problem
- Right at the bottom, select Disabled Items from the Manage drop down list box and click Go...
- Select the add-in from the list and click Enable, then click OK in the PowerPoint Options dialog (you may need to shut PowerPoint down and start again).