Foursys - protecting your network from threats

Last time I popped into the Foursys office one of the non-techie staff members cornered me and asked me to explain something to him. This was around the time of the LinkedIn password breach, and the subject he wanted to know more about was salting.

It occurred to me that there are lots of subjects and terms that both technical and non technical people throw around with little or no understanding of what they mean. The aim of this series of blog posts is to discuss in a little more detail some subjects that a lot of people gloss over with only a basic understanding. So in a cunning play on words we'll call this series of blog articles "Threatpedia". As in Wiki, but for IT security terms.

I’ll start with the subject that inspired this series of posts - salting - but before I do, lets rewind a little and explain password hashing.

Password Hashing

When you create an account, lets say for the Foursys website, you carefully select and then enter your password, in this case we’ll use ‘letmein’. We’ll use that password in the future to allow you to log in, so we’ll need to store it in our database to authenticate you.

Storing it in plain text would be very insecure, so we’ll need to hash the password before we store it. Hashing your password means passing it through an algorithm which converts it into a meaningless string of letters and numbers. So if we use the MD5 hashing algorithm your password ‘letmein’ becomes 0d107d09f5bbe40cade3de5c71e9e9b7.

If you want to log back on to our website we’ll ask you to enter your password again. We’ll pass whatever text you enter through the same algorithm and then compare it to the saved hash. Assuming you entered the correct password the two hashes will match and we will log you in. This whole process works because the hashing algorithm will always generate the same hash for the same plaintext string.

The MD5 algorithm has generated a hash which is not reversible, in other words it’s a one-way process and if that hash fell into the wrong hands it would be useless. Except it’s not, just copy and paste it into Google (or click here) and you’ll see it’s very easy to find out what text this hash originates from. Why? Well that’s pretty simple really.

As explained above, the algorithm will always produce the same result for the same plaintext word. This means that a hacker could simply take a dictionary and pass every single word through the algorithm one at a time, and then record the result for each and every word. This would result in a ‘rainbow table’, which is a list of words along with the corresponding hash. This is why the hash above was found on Google, and in fact it takes only a quick search to reverse pretty much any hash that is created using a dictionary based word. This is why we constantly remind users not to used simple words as passwords.

Salting

As we store your password as a hash in our database, you might assume that’s all there is to it - no risk to the password. The problem is that from time to time websites are compromised, and when this happens one of the most prized targets is the database containing all user information, including passwords. Imagine having access to a list of email address and hashed passwords, all you’d need to do is compare that list to the contents of your rainbow table and chances are you’d reveal a decent percentage of them. When LinkedIn were compromised this year more than 60% of the hashed passwords were cracked within a few days.

To make this simple attack more difficult we can salt our passwords.

Salting is a simple process whereby a string is appended to your password before we hash it, so in our example ‘letmein.salted’ is hashed and becomes 18093454e1f32fbf777cd2847f637f59. Try searching for that hash on Google and you’ll not have much luck this time (maybe you’ll find this article if Google has found us!). More likely you won’t find it, and that’s because ‘letmein.salted’ probably won’t be in any existing rainbow tables. Of course, if the website used the same salt for all passwords, you could create your own rainbow table simply by salting each dictionary word before hashing. This is why ideally each password is salted using a unique salt, making any such custom rainbow table incredibly difficult and time consuming to build.

So what have we learnt? Well hopefully a little about how passwords are stored and secured, and indeed how they are lost and cracked. Salting and hashing may sound fairly abstract and technical, but actually it’s a fairly simple concept. I’ll leave you with a couple of points...

• Hashing on it’s own does not secure your password.
• Salting doesn’t make it impossible to crack, but far harder.
• A non-dictionary password will be harder to crack even before the salt.
• Hashing is not encryption.
• MD5 is just one example of a hashing algorithm.

Trying hashing your password at md5hashgenerator.com and then seeing if it’s found using md5decrypter.co.uk.

And finally, if a website can send you your password when you forget it, can it have been hashed in their database?

CALLING ALL TECHIES (THAT HAVE TWITTER ACCOUNTS)!

Solve our puzzle within the next couple of months and be in with a chance to win an Amazon Kindle!

I know, I know it’s not an iPad! But we’ve already given one of those away this year and they’re getting a bit boring (okay, maybe not, but a Kindle is still a cool prize – I hope you agree!)

So, you’re probably wondering how on earth you win this modern day gadgetry delight. Well, it’s got a couple of stages which involve a mixture of technical wizardry and social media compliance...

UPDATE

NON 'TWITTERERS' CAN NOW ENTER

Clue 1

Here is clue one, I do hope you find this fun, the Kindle picture is where you start, look inside to complete the first part

Clue 2

Hope you've solved the first clue now this is what you need to do, Caesar will help decipher 36 characters to get the file, then you’ll be close to a smile!

Clue 3

Now all you need is the password, look in the same place as your first part - decrypt a bit of binary and you'll be saying "finally"!

 

Follow us on twitter @FoursysLtd

 

We’re also putting up five runner-up prizes, of a Foursys mug, for those who completed the puzzle but didn’t win the star prize.

But be quick. We're all book worms here, so time is limited before we give way to temptation. You need to solve the puzzle before midnight on Tuesday 31 July 2012, GMT time.

Watch out for the hashtag #foursyspuzzle on Twitter to follow people’s progress and gain extra clues, or email andy.wool@foursys.co.uk for hints.

List of successful puzzlers

1. 2012-06-08, 12:37 - Andy Tatarczuk @AndyTats
2. 2012-06-08, 16:07 - Karl Kroger @karl_kroger
3. 2012-07-06, 10:49 - Derek Clarke
4. 2012-07-06, 11:25 - Richard Walker
5. 2012-07-06, 12:15 - Emma Paris
6. 2012-07-06, 15:47 - Will Millerchip
7. 2012-07-06, 21:27 - Frank Thomas
8. 2012-07-09, 13:18 - Will Storry
9. 2012-07-09, 13:26 - Chris King
10. 2012-07-09, 13:30 - Gary Pitchforth

I’ve spent quite a lot of time recently working on some material for a new Foursys training course, which is aimed at raising security awareness amongst regular users. Preparing the course meant spending time researching the kind of issues that however obvious they may be to a techie, end-users simply don’t care about or understand. The challenge, as I saw it, was finding a way of presenting these problems to our employees whilst remaining largely non-technical, and making the information relevant and genuinely useful.

My approach to this was actually fairly simple – trying to blur the line between workplace and personal security. Lecturing staff about the importance of passwords in the workplace is not interesting or useful, whilst explaining to them how a criminal might hijack their credit card information is. The basic message is the same, use good passwords - be careful with open wireless - don't ignore certificate errors, you get the idea.

Another important aspect when it comes to end-user education is the attitude of your IT department, something not so easily dealt with in a half-day training session! A recent article on DarkReading.com (http://bit.ly/xGTGC0) contained a statistic that, on the face of it, surprised me. They claimed that in the US only just over 1% of all IT staff were in information security. I’m convinced that the number can’t be that reliable – and what is classed as an InfoSec role? – however it did get me thinking.

Some positions are obviously security orientated (security officers et al), but all technical positions are security related. This seems quite obvious really, from 1^st line support technicians through to developers - DBAs - IT managers - server operators, every single position should have security at the very centre of everything they do. For most IT pro’s security is not something they do; rather it is the way in which they do something.

All too often IT staff are not encouraged to work in a secure way – and you don’t usually have to look far to find examples. I frequently encounter organisations where IT staff routinely do things such as asking users for passwords, removing antivirus software to “fix” issues, using seriously awful passwords for administrator accounts, and so on. All of these violations are ones we’d chastise an end-user for, and in fact we’ll often specifically tell them they mustn’t do such things – so why should it be any different for us?

Usually these misdemeanours are full of good intentions, and help us appease the end user who’s having a problem – but whilst asking their password so you can logon and resolve an issue over lunch might be easy, it’s sending all the wrong messages to the user.

Educating our users is clearly a crucial part of any organisation’s information security strategy, but IT departments need to keep their side of the deal as well. We too must ensure that everyone from helpdesk technicians up to the IT director follows the same rules, and that we no longer undermine those rules and policies we impose on the rest of our employees. So next time there’s a security incident stop for a moment before you blame a user and ask yourself, could I have done anything more to prevent it?

Follow Stuart on twitter @Stuart83w

Most IT departments have a fairly good understanding of the threats they face. It’s unthinkable that anyone would not be running a solid antivirus solution, external firewalls, and other traditional defences. Most will now be using an effective web and email content scanning solution, and organisations are slowly beginning to realise that client firewalls are a good idea too.

All of the technologies I mentioned above are fairly commonplace, easy to get hold of and implement, and not particularly expensive. They mitigate risks that most people understand, but there are many other vulnerabilities that very often aren’t even considered. In this post I’ll discuss a couple of attacks that many organisations are still vulnerable to, and attempt to explain why these risks are more difficult to protect against. We’d be interested to hear comments about what you believe to be the biggest threats to your organisation, and whether you feel vulnerable to the exploits explained below.

Apologies in advance, but it’s not possible to explain these attacks without getting slightly technical.

ARP poisoning
ARP stands for address resolution protocol. All networked devices have physical hardware addresses, they look like this 54-E3-FC-91-BA-5F and aren’t particularly easy to remember. ARP is the protocol which helps us to translate these addresses to and from IP addresses, which we’re more easily able to remember and manage. When one device communicates with another it needs the hardware (MAC) address of that device, so when you connect to 192.168.1.1 your computer uses ARP to translate that to a MAC address and then establishes a connection to it.

ARP poisoning (or ARP spoofing) exploits a vulnerability within the ARP protocol, whereby an attacker can send a fake ARP message to a victim which causes it to wrongly associate a MAC address and IP address. For example, I might ARP poison my victim so that the IP address of the default gateway is associated with my MAC address (I’d also poison the default gateway, making it associate my MAC address with the victim’s IP address). This would cause all of the victim’s traffic to be routed to my machine, allowing me to perform subsequent attacks on the victim’s computer- this is known as a man-in-the-middle (MITM) attack.

This attack is difficult to defend against, particularly on large networks. One option is to use static ARP entries, which need to be present on all devices on the network. This is not particularly practical because of the massive management overhead. The most obvious defence is not technical at all – prevent unauthorised physical access to your site, although an attacker could remotely use a compromised machine already on your network.

As ARP poisoning requires the attacker to be on the same subnet as the victim, using VLANs can help to prevent the exposure to this attack by limiting the devices an attacker could poison. Extra security could then be implemented on VLANs considered to be more sensitive. Other potential solutions include client software and OS changes to lower the risk of attack. Hardware devices are available that monitor ARP traffic, and some switches allow port level security which binds MAC address to specific ports. Implementing network encryption or IPSEC authentication could also help to reduce the risk of a successful attack.

Fake access points
The fake access point attack is quite simple. An attacker creates an access point and encourages users, or their devices, to connect to it. The attacker is then able to monitor traffic on the fake network, and perform attacks on any vulnerable devices that may connect to it. Users can be tricked into connecting to fake AP’s easily by using network names that are appealing, either because they offer free wireless, or because they appear to be legitimate.

Some devices automatically probe for previously used wireless networks when they aren’t already connected, and an attacker can easily see these network names. If a fake AP was then created using the same name, the target device could automatically connect to it without the victim even realising.

Although most organisations secure their wireless networks this is still a viable attack if your devices are able to connect to any network. For instance most devices will choose the wireless network with the strongest signal, and smartphones not configured for corporate wireless networks may automatically join any available network – possibly without the victim realising. This can then expose credentials used for services such as Outlook Web Access.

Restricting the wireless networks your devices are permitted to connect to is one way of preventing this attack (but requires client software). You may also utilise a wireless intrusion prevention/detection system to protect your own premises.

Follow Stuart on twitter @Stuart83w

If like me you spend a lot of time travelling, you’ll know that free public wireless is really useful. I’ll often pop into Starbucks or a motorway service station to download a few tracks on Spotify, reply to emails or download a new app for my iStuff. Staying safe on unsecured networks is obviously very important, and as the much publicised Firesheep extension for Firefox demonstrated, not much technical knowledge is required to take advantage of people using these networks.

Below are a few of my top tips for staying safe when using an unsecured network (in no particular order).

Think before you connect
The vast majority of free public Wi-Fi networks are genuine, provided by trusted names such as coffee shops and fast-food outlets. Unfortunately though, it’s pretty easy for the bad guys to create their own free wireless networks and try to trick you into using them instead. What’s the risk? Well if you’re using one of these networks all of your traffic is being passed through the malicious computer before it reaches the web – and the pages you see may not be genuine, or could have been modified. This is a form of “man in the middle attack”, and may well result in data theft – depending on what sites you access.

Before you connect to “free” Wi-Fi, stop for a moment and think. Does this hotel chain actually offer free wireless? Are there other more recognisable networks visible?

Let Windows help
If you’re using Windows Vista/7 then the moment you connect to a new network you should be asked to select what kind of network you’re using – Home, Work, or Public (example). Select “Public Network” and Windows will make sure you’re not unnecessarily sharing files and will switch to more secure firewall settings.

Update your browser
I’m not being dragged in to arguments about which browser is most secure, although if you are interested this Wikipedia article summarises unpatched vulnerabilities in the major browsers. My personal preference is Google Chrome, but whatever browser you prefer to use it’s important to keep it up-to-date and patched.

Use SSL
Information transferred over the unsecured network using HTTP will be visible to anyone who want to see it. Some websites, for example online banking, will force you to use HTTPS – which encrypts the traffic. Some websites will support HTTPS but will not automatically direct you to the secure version of the site, whilst others simply do not support HTTPS.

I have a simple rule – If a website offers SSL – use it. Whilst the details of my Google searches may not be very sensitive, it costs me nothing to secure them, and it’s a good habit to have. For Firefox users the HTTPS Everywhere extension will automatically direct you to secure versions of some websites you access, whilst Chrome fans can use KB SSL Enforcer. Neither extension will work on 100% of sites, but they certainly help.

Security begins at home
Although these measures will help you stay secure when you’re away from home, there’s no reason not to enable them at all times. That way you don’t have a raft of settings to change depending on where you are – and the Windows network location setting will remember your networks and automatically switch between the “Home” and “Public” profiles.

Beef up your browser
There are loads of add-ons or extensions out there that can help you in the fight to stay secure – particularly if you’re using Firefox or Chrome. One of my favourites (although not strictly just useful for remote working) is LastPass. LastPass not only manages and remembers passwords securely for me, but it generates strong random and unique passwords for every website I need to sign up to. Using multiple strong passwords won’t make you more secure in public networks, but it will mean that if one of your accounts is compromised – the same login details won’t work on every single other website you subscribe to. Just make sure your LastPass password is bulletproof! (other password managers are available).

Other extensions I find particularly useful are Web of Trust (IE, Firefox, Chrome, Safari) and AdBlock Plus (Firefox, Chrome). And of course, don’t forget you’ll need to keep the browser extensions up to date too!

I’ve posted before about how an organisation should use technology to help their users or customers stay safe. A simple example would be forcing users to pick strong passwords when creating accounts online – and this should be fairly simple to enforce, right? Especially if I had all the resources of one of the largest telecoms companies in the world..

Well at the weekend I was pretty shocked when I tried to create a new account on BT.com, hopeful of an upgrade to BT Infinity in the near future.

Here’s BT’s signup form:

Here’s the same form with my randomised password “h&pl0j*b19H$2nl?“

So apparently that’s a weak password. I spent a few minutes struggling before I realised what had happened. Clearly the logic used is strictly enforcing their policy “..must contain numbers & letters and be at least 6 characters long“. It seems the missing word in that sentence is only.

I tried again with the technically compliant password “ABCD12345“. Perfect! Not only do BT accept this password, they tell me it’s “Strong”.

I use a password manager to allow me to create strong and unique passwords for each website I visit, which thanks to BT I had to bypass and complete manually. So maybe this one can be put down to user error and my not understanding their instructions – but in my opinion BT could do a much better job of this.

Incidentally, I did try and bring this to BT’s attention via Twitter, but as yet have received no response.

 

Follow Stuart Wright on Twitter @stu_infosec

No that’s not a typo. I just accidentally socially engineered my bank (well, building society). They shall remain unnamed, simply referred to as “The Bank”

So it all starts with a Saturday morning visit to The Bank. I need to withdraw some cash from my savings account, for which I have an old-style pass book (example). I haven’t accessed this account in a while, in fact it has been at the very least two years since I visited The Bank and performed any transaction. In that time I have moved house no less than three times, so I have no clue to where this account is registered.

I present my passbook to the helpful assistant and ask for some money, she obliges. At this point I’m a little surprised I’ve not been asked for just one other form of ID to prove who I am – especially given I’m withdrawing several hundred pounds. I could just have found the book and learnt the signature after all. She’ll probably check before she hands the cash over. She doesn’t. OK maybe I’m being a little fussy here, I do after all have the passbook, and it does have a male name it it.

Money handed over and in my wallet, I realise that I don’t know which of my many previous addresses this is registered to. May as well update it whilst I’m in the branch. She hands me the form to complete.

Ah. The form needs my previous address. I explain to the lady I’ve moved several times and am not sure which address they would have on record and offer to list the three it could be for her, at least then she’ll know I’m genuine. There’s a queue forming and this would clearly take some time, so she just tells me the previous address, I complete the form, and that’s that.

So, with nothing other than the passbook (not much bigger than an iPhone, easily dropped or lost), I’ve withdrawn several hundred pounds from this account and changed the address.

I now keep the passbook locked up, in a secure safe worth several times more than the money saved in the account. Can’t be too safe huh?

 

Follow Stuart Wright on Twitter @stu_infosec

When discussing network access control (NAC) products with customers, we usually define two clear goals. Firstly, ensure that all devices accessing the network are compliant with a set of policies defined by the administrator – and secondly, ensure that any unknown devices are prevented from communicating with those that are known.

Assessing known machines is usually relatively straight forward. We can use installed or web-based agents to ensure that these machines comply with our standards (are patched, have Anti-Virus etc), but how do we isolate other devices?

DHCP enforcement is great, and does a very good job of preventing the majority of unauthorised devices from obtaining an IP address. This is mainly because most unauthorised access is not malicious, and in fact is more likely to be a staff member/contractor/visitor innocently connecting to your network, and generally they’ll be configured to use DHCP.

The obvious problem with DHCP enforcement is that we’re assuming that all devices will request an IP address from our corporate DHCP server. So what if they don’t?

802.1x enforcement is one potential answer, and is a very effective way of protecting your network from unknown devices. There are a few complications with 802.1x though, which can often make administrators reluctant to go down this road. Obviously all switches must support the technology in the first place, and even when they do will need to be configured. This can seem quite daunting, especially to smaller businesses, and it’s often the case that 802.1x enforcement is placed on the “to do list”. Another way of dealing with this issue is to implement “Server and Domain Isolation” (SDI).

SDI is the term Microsoft use to describe the use of IPSec policies deployed via Active Directory. By assigning IPSec policies to your domain, you can create a barrier between members of your domain and all other devices.

When two devices on your domain wish to communicate, they first authenticate and all packets transferred between them are encrypted. When a non-domain member tries to initiate communication with domain members, the authentication fails and your domain member is protected. IPSec policies can be flexible enough to allow unsecured connections where necessary, and define different requirements for different network segments and devices.

I should stress, SDI is not a new technology and is not a security silver bullet. SDI provides a logical barrier between your trusted network and everything else, but of course it’s just as important to ensure that devices on the trusted network comply with the relevant security policies. This is where endpoint assessment comes into its own, and why combining technologies like SDI with NAC can be an incredibly efficient way of securing your network.