The talk began by pointing out a penetration tester’s over-reliance on open source/closed attack frameworks including Metasploit, Social engineering toolkit and Armitage; however, these tools only  come in handy if the target is reachable over a network. As these tools increase in popularity, antivirus vendors will start creating signatures to recognise them, alongside their exploits. Predictably it will reach a point where most of the tester’s tools are recognised by an AV/HIDS system.

The spotlight now moves to a scenario where the tester has access to a system which is within a highly restricted environment (say Citrix). The user role has very limited privileges and there is an AV running on the system which will capture all the malicious scripts that the tester might use and at this point PowerShell is introduced.  After a brief introduction of PowerShell basics, we dive right into PowerShell scripting.

The next stage of the talk covered some sample scripts on how to bypass some of PowerShell’s security features as a normal user and run malicious scripts which would not be detected by an AV. As a proof of concept, we then looked into exploiting vulnerabilities within the Windows 2008 Group Policy Preferences.

To conclude, some pointers were put forward to help inspire the audience to create cool PowerShell scripts for nefarious (or for penetration testing) purposes.

To read Nikhil’s full presentation, click here

The post Using Powershell to do the Nasty appeared first on 7Safe Limited Penetration Testing Services.

Often while carrying out an application security test, penetration testers focus very heavily on traditional input validation flaws and logical flaws are often overlooked. Sumit ‘”Sid” Siddharth, industry-renowned information security expert, will share his knowledge on how to identify logical flaws and where to look for them in a joint presentation with co-presenter Richard Dean. This will be the third time Sid has been invited to speak at Black Hat, having previously presented at Black Hat Europe and Black Hat Las Vegas.

More details about the talk can be found here.

To meet Sumit in Abu Dhabi, or to find out more about how 7Safe, a PA Consulting Group Company, can help your organisation using the latest penetration testing techniques to improve information security and resilience, please contact us now.

The post Meet 7Safe at Black Hat, Abu Dhabi 2012 appeared first on 7Safe Limited Penetration Testing Services.

If a password is stored in an encrypted format, then it implies it can be decrypted – so long as you know the key.  In fact, the LinkedIn passwords were stored in what is known as a “hashed” format, specifically SHA-1 (which stands for “Secure Hashing Algorithm”).  You can think of SHA-1 like a mathematical car crusher in a scrap-yard.  Whether you feed in an Aston Martin DB9 or a Citroen CV, what you get out is a mangled blob that looks absolutely nothing like what you put in.  And just like a car crusher, hashing is an irreversible process – there’s no way you can take that compacted lump of metal, plastic and electronics and turn it back into a car.  The output of SHA-1 if you feed it the word “password” looks like this: 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8.  If you make just a small change, by making the first letter a capital P so that the word is now “Password”, SHA-1 produces 8be3c943b1609fffbfc51aad666d0a04adf83c9d, which is wildly different (but the same length).  No matter what you feed into SHA-1, the output is always the same length.  The LinkedIn database contained millions of these hashes instead of storing the actual passwords in “clear text”.

Now comes a key question: if there’s no way to reverse a hash into its corresponding password, why does the hacker posting matter?  To answer this question, consider a more practical question: how does LinkedIn know that you’ve entered the right password when you log in?  When you enter your username and password, the clear text password is hashed and compared to the stored hash: if it’s the same, the password is correct.  That’s how things work normally.  Hackers can attack these hashes in a similar way: they guess a password, hash it and compare that hash to the one they’ve stolen.  If it’s the same, the guess is correct; if it’s not, try another guess!  Clearly this can be a lengthy process, even with a computer programme working on the problem.  But if you think about it, all this guesswork can be done in advance.  Just make lots of guesses, hash them and store both parts in a table – what is known as a “rainbow table”.  The structure of a rainbow table is too complex for this article but in essence, you simply look up the stolen hash in the table to find the password that generated it. 

To date, some 3.5 million of the 6.5 million stolen hashes have been cracked in this way.  But this technique will only work for a particular password if that password was one of the guesses made while compiling the table – and that is why LinkedIn users with strong passwords should still be safe.  But what is a strong password?  From a sample of approximately 160,000 cracked passwords that we have seen, the average length was 8.9 characters, and 21% contained a mixture of uppercase, lowercase and numbers.  These statistics suggest a number of passwords might be considered “strong” but, when it comes to rainbow tables, attackers have time on their side: there are computers running right now all across the globe dedicated to producing these tables.

LinkedIn’s response to the breach included “salting” passwords.  A typical salt is a large random number chosen when a user sets a password.  That number is prefixed to their password before running the whole lot through the hashing algorithm, and both the salt and hash are then stored (ideally, in different places).  Rainbow tables depend on the fact that all the hard work can be done in advance.  If the hash is partly generated from a random number, rainbow tables can’t be produced because for every password guess the table must take into account every possible value of salt.  Game over.

Salting is just one of numerous techniques to defeat rainbow tables and slow down attacks on hashes.  It’s important to realise, however, that salting doesn’t make hashes immune to cracking.  If the salts are compromised along with the hashes, the attacker can revert to the first technique: guess a password, prefix it with the stolen salt, hash the lot and compare with the stolen hash.  For more information on secure password storage, start by visiting: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet.

To find out how to ensure your data is secure through advanced penetration tests, or for more information about related training courses for your organisation, contact us now.

The post LinkedIn Breach Commentary appeared first on 7Safe Limited Penetration Testing Services.