Archives for February 2015

Cyber Essentials

February 20, 2015 by David Stubley

7 Elements achieves Cyber Essentials Certification body status.

7 Elements, are now a certification body able to deliver Cyber Essentials (CE) and Cyber Essentials Plus (CE+) engagements for organisations that are aiming to meet this standard.

The move comes as 7 Elements looks to expand its service offering to include a cost effective security solution to all clients which now includes conducting this government approved assessment. The CE and CE+ accreditation has been developed as a method to significantly reduce business vulnerability at an achievable cost. More information on the scheme can be found here.

Passphrase Guidance

February 11, 2015 by David Stubley

A secure and functionally usable form of password authentication is passphrases. Passphrases are a combination of words that can be entered as a password. Recent attacks that have resulted in password leaks provide a wealth of knowledge about common password patterns. Passphrases provide a more secure but user-friendly alternative to traditional passwords.

A well-formed passphrase can be far more holistically secure than other password authentication alternatives. This additional security stems from maximising human memorability and cracking complexity in concert with minimising selection guessability, observability and recordability. Passphrases increase usability as they can contain special or unique significance to the user, are more memorable and their length and form can provide significant layers of complexity. Passwords are much easier to crack than passphrases, regardless of their cryptographic protocol. In addition, cracking passwords is becoming progressively easier by harnessing the power of cloud computing and new technology. The approximate time required to brute-force a complex eight character password lies between seconds and days for most cryptographic protocols, whereas for passphrases this time increases exponentially, making passphrases significantly more secure. Passphrases are therefore computationally more challenging to crack than passwords.

Passphrase Generation Recommendations

The following factors are recommended in the generation of secure passphrases.

• Use three or more uncommon words, for example “steep alphabet dawn win”.

• The phrase should not be common, for example a well-known saying or from a film or book.

• Use spaces or special characters between words to further enhance the security. For example, “steep-alphabet-dawn-win” or “steep!alphabet-dawn!win”.

• As with passwords, do not enforce excessive expiry of passphrases to avoid user fatigue that may result in users employing insecure coping strategies that ultimately degrade and diminish security. Enforcing new and distinct passphrase selection every three months should meet the needs of a risk averse organisation.

• A limit of 32 characters will give users freedom to create more secure passphrase word combinations, while not putting excessive demands on existing systems to maintain the data or computational tasks.

• As with complex passwords, secure passphrases should consist of at least two of the following elements however, users should be free to choose from any of these categories:

Uppercase letters
Lowercase letters
Numbers
Punctuation marks
Mathematical or other conventional symbols
Spaces

Passphrase Security Augmentation Elements

In developing a passphrase policy it is crucial that the system is practical for users. This can be achieved by ensuring that verification methods impose a minimal burden on users. To assist in this the following factors should be considered in developing a passphrase policy.

Memorability: Passphrases must not made overly complex as to be difficult to recall.

Guessability: Passphrases should be hard to guess. This means family, colleagues, friends and social engineers should not be able to guess passphrases by exploiting the varying degrees of intimacy with a passphrase holder. Passphrases should not contain meaningful dates, pet names, addresses, hobbies, interests or otherwise.

Observability: Passphrases should be entered easily. If a passphrase is overly time consuming to enter this enhances the ability of shoulder surfers to accurately observe password entry.

Recordability: Passphrase entry must be secure. Users should become naturally wary of highly observable key press combinations for instance, the passphrase “qwe rty uiop” is highly recordable due to the sequential means of entry on standard keyboards. As characters are being typed into the passphrase field they should also be immediately obfuscated to avoid screen recorders from recording passphrase input. The workstations in use must also be secure to ensure keyloggers are not in operation.

For more guidance on passwords, please visit the following link.

Password Guidance

February 11, 2015 by David Stubley

Most organisations utilise passwords as a method of authenticating users as part of their access control solution for their systems. 7 Elements have often found poor password policy or insufficient policy enforcement can be a severe point of failure in an otherwise secure system. For password authentication to be effective the security provided by using passwords must remain robust regardless of persistent attacks originating from either human or computer sources. Organisations can take steps to ensure that the passwords used to access their systems are sufficiently strong by employing a robust password policy. This guidance lays out some key steps organisations can take to develop a robust password policy and therefore help ensure that strong passwords are used on their systems.

Password Formation Guidance

To ensure that users have strong passwords the following basic guidelines on how passwords are formed may be used as part of a robust password policy. A robust password policy should stipulate that a password has the following properties.

• Passwords should be a minimum of nine characters long. They should also be sufficiently complex to offset the likelihood of a successful brute force attack or guessing of the password.

• Passwords should not contain personal information such as names, addresses, birthdays, car registrations, ID numbers etc.

• Complex passwords should consist of at least four of the following elements however, users should be free to choose from any of these categories:

Uppercase letters
Lowercase letters
Numbers
Punctuation marks
Mathematical or other conventional symbols
Spaces

• Use of common passwords should be banned. Common passwords can be compiled from the many repositories of passwords released after major account hacks.

• A history of old password hashes should be kept. This should be used to prevent users from re-using their previous passwords.

• Accounts should be locked out after a number of failed access attempts. This is ordinarily set to three attempts. This helps to reduce the likelihood of a successful brute force attack against accounts.

• Passwords should be changed at regular intervals. However, organisations should be aware that constantly enforcing password changes may cause users to develop password generation fatigue. This may result in users employing insecure coping strategies, such as writing passwords down or using non-complex passwords. This could eventually degrade the security of password authentication.

• Password reuse should be limited so that unique passwords are not used across a single user’s multiple accounts. Furthermore passwords across accounts should not be similar permutations of the original password.

Password Security Augmentation Elements

In developing a password policy it is crucial that the system is practical for users. This can be achieved by ensuring that verification methods impose a minimal burden on users. To assist in this the following factors should be considered in developing a password policy.

• Memorability: Passwords must not be so complex as to be difficult to recall.

• Guessability: Passwords should be hard to guess. This means family, colleagues, friends and social engineers should not be able to guess passwords by exploiting the varying degrees of intimacy with a password holder. Passwords should not contain meaningful dates, pet names, addresses, hobbies, interests or otherwise.

• Observability: Passwords should be entered easily. If a password is overly time consuming to enter this enhances the ability of shoulder surfers to accurately observe password entry.

• Recordability: Password entry must be secure. Users should become naturally wary of highly observable key press combinations for instance, the password “qwerty” is highly recordable due to the sequential means of entry on standard keyboards. As characters are being typed into the password field they should also be immediately obfuscated to avoid screen recorders from recording password input. The workstations in use must also be secure to ensure keyloggers are not in operation.

• Complexity: A minimum password length combined with relative complexity is essential. Passwords do not need to be overly complicated to remember but instead fortified through the discussed elements of augmentation to prevent the success of current and emerging password hacking and encrypted hash cracking techniques.

For a more robust approach to password management, take a look at our guidance on using a passphrase.

BitTorrent Distributed Denial of Service

February 3, 2015 by Sam Hartley

We recently worked with a client that had suffered a denial of service on one of their websites. They wondered if we could tell them what had happened and how to stop it from happening again. So, time to start digging through logs to work out what was going on. It turned out that the attack was a Distributed Denial of Service (DDoS) attack using BitTorrent clients to attack the target site. BitTorrent Distributed Denial of Service attacks are a pretty under reported attack vector that I hadn’t come across before in the real world. So the following blog takes a look at the log analysis and investigation that led to this understanding.

DDoS attacks like this are often carried out using bots, infected computers on the Internet, which are all under the control of a malicious individual or group. These bots are then used to perform activities, such as requesting web pages repeatedly. This causes the victim site to be quickly overwhelmed with requests resulting in one of the following events:

Exceed the available network bandwidth.
Exceed the application processing capacity.

If successful, either event would result in removing access to legitimate users of the site.

However, in this case, the means of delivery was via BitTorrent clients and not infected machines.

Initial Log Analysis

A quick review of the logs showed that a large volume of traffic had been directed at the site from multiple sources within a very short space of time. We had requests for ‘announce.php’ coming from over 10,000 unique hosts in a specific geo location.

Here is an example of one of the logs captured by Apache (sanitised):

[source_ip] - - [date_time] "GET /announce.php?info_hash=%25B56%25B51u%252DU%2504Eb%2513%25EA%253BVFBu%257E%2512%25BA &peer_id=%252DSD0100%252D%25127%25F9%25AD%25ABd%252D%25CFN%2593%25FC%2521 &ip=192.168.1.31&port=11706&uploaded=1043070976&downloaded=1043070976&left=0 &numwant=200&key=6511&compact=1 HTTP/1.0" 301 655 "-" "-"

Looking at the announce.php and the parameters (upload, download, and left) in more detail we suspected it was BitTorrent traffic due to the format of the request. With a bit of googling this assumption was confirmed. In discussion with the client it was quickly established that their main corporate site was not acting as part of a peer-to-peer network and that this traffic was the source of the DDoS attack.

BitTorrent Analysis

All of the traffic appeared to be coming from the same geographic region, so we came up with two possible scenarios. One, that DNS cache poisoning was being carried out to send legitimate BitTorrent traffic to our victim server. Or two, that our victim server had been named as the torrent tracker server in the .bittorrent file. Knowing which scenario was in play would then dictate the best mitigation option, so back to the logs.

In their current format, our clients logs were not helping us figure out which of our scenarios were the most likely as they were missing detailed information as to what the ‘Host’ section of the request was. As the attack was ongoing, we quickly updated the apache logging by editing the `apache2.conf` file to add the parameter ‘%Host i\'.

Apache logs are easily configured to provide additional details such as this and for the small additional storage overhead, it is definitely worth while having this pre-configured to save time during later analysis.

With the new log configuration, we can now see the domain that is being requested (marked in grey):

We have removed our clients domain name here, but the Host header matched our clients domain name which indicates that this wasn’t DNS poisoning but rather that our clients server had been listed as a BitTorrent tracker in a .bittorrent file. If this was DNS cache poisoning we would have seen the domain name of the site the BitTorrent clients were trying to reach.

Remediation

Defending against the attack was easy enough once we understood what was going on. As our client isn’t actually running a BitTorrent server we simply dropped any requests for announce.php at the firewall and reduced the TCP timeout value on the Apache box to flush inactive connections.

Conclusion

What was especially interesting in our scenario is that the systems involved in the DDoS attack were not ‘bots’, these systems hadn’t been compromised at all. To perform this attack, the malicious actor doesn’t need any technical skills beyond creating a torrent file, and the attack is very low risk as once the .torrent file is created, no further interaction is required. While an attack like this doesn’t generate massive amount of traffic, with enough peers having downloaded the torrent file, the attack can be big enough to cause a denial of service.