Wednesday 22 July 2015

Morality vs Criminality: Ashley Madison Hack

As you may have read in the press, that the Ashley Madison website was hacked.   What's the big deal, you may think, it's another compromised website.  Ashley Madison,as it says on their website, "is the online personals & dating destination for casual encounters, married dating, discreet encounters and extramarital affairs", with the tagline is "Life is short, have an affair".  There are 37 million users, across over 50 countries, with around 1.2 million of whom live in the UK.

What was lost?

Personal data that was lost includes, names, postal addresses, credit card numbers and sexual fantasies.  Made worse is the organisation charged a $19 fee to carry out a "full delete" on user accounts, which appears to have not been the case.

Who did it?

The hackers taking responsibility are the Impact Team, where the database was comprehensively stolen.  In a recent article from The Guardian, it states that it was an insider threat, where the compromise was carried out by someone who had access to the systems, but was not an employee, highlighting the need for control on third party access.


I've read a few comments that said that people should not be using these sorts of sites.  A crime has been committed in the database being stolen, but we are judging the victim for the crime.  Who is to blame if your house is broken into?  The criminal or the victim?  


Be aware that there is no safe place on the internet.  The internet is effectively a public place, where a majority of people will have access.  You are entrusting a third party to look after your data, so in this case, a secure and unique password would not have helped the users.

The fault here lies with Ashley Madison.  Some security technologies would have prevented this from happening:  

  • A Privileged Account Security solution would have prevented the third party from recycling their access to the system, and with some solutions recorded the sessions of compromise.
  • A database encryption solution would have prevented the data from being used.
  • A Data Leak Prevention (DLP) solution would have prevented the data from exfiltrating the organisation.
  • A Security Analytics solution would have seen and prevented this.
I have mentioned the Cyber Kill Chain in the past, and these solutions would have stopped the compromise, and the data leaving the organisation.

For me, this is not a case about morality, but we allow that to cloud our thoughts and allow a criminal act to be downplayed because of it.  This is a crime, but worse a crime that could have been prevented.  The right solutions configured correctly, supported by polices and procedures would have prevented this hack from happening.

Monday 20 July 2015

Web Application Testing - Hacking with KALI Linux

Web Application Testing for beginners

I was asked to give a presentation on Web Application Testing, so as well as supporting information as to why and what a test involves, I highlighted why OWASP was important, and showed how easy a simple a SQL injection attack is to carry out.


Who or what are OWASP?  Wikipedia gives the definition as: “The Open Web Application Security Project is an online community dedicated to web application security.  The OWASP community includes corporations, education organizations and individuals from around the word”

OWASP gives information on security coding of web applications and following their guidelines will help ensure the development of secure web applications and that the security standards are upheld as part of this process.

KALI Linux

A common penetration testing tool is KALI Linux, which is available here as software or here as a virtual machine.  It’s a suite of testing tools that run on Linux, and includes tools to test web applications.


One of toolsets found in KALI Linux is to a tool called OWASP ZAP, which will test websites for vulnerabilities.  It’s a vulnerability assessment (VA) tool for web applications.

You enter in the website you want to test against.  I have to say ensure you have the permission of the owner of the website, although there are many websites that can be tested against.


One of the vulnerabilities that OWASP ZAP can test for are SQL injections.  Wikipedia defines SQL Injections as: "SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker)"

Find Database

Once you have a site that is vulnerable to an SQL injection, you can use the SQLMAP tool on KALI via a Terminal session.

To use SQLMAP to check a website for a database, use the following line of code:

sqlmap -u <vulnerable site url> --dbs

This command will show if there are any databases available on the site

Find Tables

Once you have the database information, the next task will be see what tables are available on that database, and that can be done using the following code:

sqlmap -u <vulnerable site> -D <database name> --tables

Once you have the tables, you’ll probably want to have a closer look at any interesting ones.

Find Columns

Once you find an interesting table, it would be useful to see what is available in the columns, which can be done using the following code:

sqlmap -u <vulnerable site> -D <database name> -T <table> --columns

Dump Data

Now you have the column information, it would be useful to dump the data, using the following code:

sqlmap -u <vulnerable site> -D <database name> -T <table> --dump

Once the data has been dumped, you’ll be asked if you want to use external tools to analyse the data, performing an attack using a default dictionary attack and whether you want to ignore common suffixes.

Review Data

Copy and paste the data into Leafpad to view the data, where you’ll see passwords as hashes, and where they are common passwords in the default dictionary, then they will be displayed as clear text.


As you can see, with very little experience, it’s incredibly easy to check for vulnerabilities and use simple commands to perform some very powerful tests against the sites.  The recommendation is to have any web application development team to follow the OWASP Top 10 and ensure regular testing against your web applications.  If you are commissioning an external organisation, ensure they are offering an SLA to delivering a secure application, so they have to pull the stops out to ensure security is built in, rather than it being of additional expense to you and your organisation for not building this into the contract.