I have recently come up against a problem with using the 'new' wireless network at work. We are using Cisco kit and TACACS+ to interface onto Microsoft's AD in the back end. Technically, usernames should be able to be up to 31 bytes long (not a problem there) and the password up to 254 bytes. However, the web portal implementation that we are running has a problem with my password. It would appear that passwords of up to 16 characters are fine, but passwords in excess of 16 characters don't work.
We are currently investigating this, as it seems like a real problem, especially as we are recommending that people switch to using longer pass phrases, in excess of 16 characters. Hopefully vendors will catch up with this soon, as many still have problems with so-called 'special characters' such as punctuation and other common symbols.
Showing posts with label wireless. Show all posts
Showing posts with label wireless. Show all posts
Thursday, 4 February 2010
Friday, 11 December 2009
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.
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.
Thursday, 26 November 2009
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.
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.
Friday, 21 August 2009
Wireless Network Security Recommendations
Wireless Networks are still causing businesses problems. By their very nature they are insecure, as they are a broadcast network that frequently extends beyond your physical boundary - remember radio signals don't stop at your door. There ARE security mechanisms to make them secure, but too often these are not implemented properly or are circumvented by users. It is vital that all traffic on the wireless network be encrypted, and connections authenticated, otherwise anyone with a laptop can view all your traffic. There are many mechanisms for achieving this, but at the very least you should use WPA with long pass phrases (not simple passwords) and MAC address authentication.
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.
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.
Subscribe to:
Posts (Atom)