Penetration testing: Permission, ownership and "hacking laws" overview

When performing a penetration test it is very important to have permission from the parties involved, which may include third parties if a company has outsourced or managed services as part of it's IT infrastructure.

In recent times, outsourcing, managed services, cloud-computing and the global nature of IT infrastructure, combined with new legislation in various countries have added complexity to penetration testing.

This has made it increasingly important for pen-testers to have a very clear understanding of who owns the systems they are targeting, and infrastructure between the testing systems and the targets (which may be affected by testing).

This blog is a brief overview of things to watch out for with the permission and legality of tests. I also outline various laws relating to computer crime in several key countries.


Written permission

Written permission is the most important prerequisite before starting a penetration test. This is very important even in an internal penetration test, performed by internal staff, because testing may affect system performance, and raise confidentiality and integrity issues.

The system owner, or decision-maker must agree to put the scope of the tests in writing. If there are any doubts during the test, this may need to be clarified and amended with more detail.

A testers written permission document is their "get out of jail free card", but it is not above the law. Sometimes it is unclear who owns systems and infrastructure (even to the client themselves). If in doubt get clarification.



Discovering new systems

During the test, you may come across additional infrastructure and systems where you are not sure who owns them, or whether you have permission to proceed. It is very important that your tests do not impact third parties, either directly or indirectly. Reconfirm individual systems with the client as you go, to make sure they know who owns the systems, and that they are within the permission and agreed scope of the test.


External penetration tests across the internet

If you are performing penetration tests across the internet, you will likely need to notify relevant ISPs, primarily yours and your customers.

This is important for various reasons, including legal and informational, but also technical reasons.

There could be many reasons why intervening infrastructure is adversely affected by tests that you run, such as system/port scanners, and vulnerability assessment tools. The last thing you want is to get sued for affecting a third party.

It may be that one of these ISPs is actually filtering some ports and threats transparently, which could mean that some tests you run are invalid. If you are testing for threats, and either your ISP or your customers ISP is filtering your tests, then you may be missing threats that are there, that perhaps may be accessible from other locations or in other ways.

During your tests, your IP addresses may get reactively blocked or blacklisted, which again could invalidate any further tests, such that real threats are missed.

An alternative, to avoid some of the risks with Internet-based testing, is to connect the testing systems directly to the external router of the client, or have the client give the tester some form of VPN or SSH tunnel to a system in that location.


Laws to consider

In addition to permission and technical issues, it is very important to have a clear understanding of the law, especially when more than one country is involved.

As you know, ignorance of the law does not stand up very well in court, so here is a (very) brief overview of relevant laws in several countries. I am not a lawyer, so for further detail please consult with your legal counsel. This is by no means a comprehensive list, and will only give you a flavor of what is out there.


Cyber crime laws in the UK

• Computer Misuse Act (of 1990, updated 2008)
• Prohibits deliberate unauthorized access
• Additionally covers issues such as modification of content, blocking access, impairing operation and facilitating others to do any of the above
• Fines and prison terms of up to 2 years
• Recently updated to cover Denial of service
• Up to 10 years in prison
• Prohibits distribution of hacking tools for criminal purposes
• Makes possession of hacking/security tools illegal where criminal intent can be established

Cyber crime laws in the US

These are probably the strictest, most comprehensive (and complex) in the world and include:

• Title 18 (Criminal code) Sections
• Section 1029
• Prohibits Fraud in relation to access devices, account numbers, passwords, credit cards etc.
• Section 1030
• Prohibits unauthorized computer access for government, financial and commerce systems
• Section 1362
• Prohibits injury or destruction of communications equipment
• Section 2510
• Prohibits unauthorized interception of traffic (Clauses to enable service providers to monitor, and procedures for law enforcement to gain access)
• Section 2701
• Prohibits access to stored information without permission of owner (again, exceptions for service providers)

• Cyber Security Enhancement Act (2002)
• Covers attacks which recklessly causes or attempts to cause death
• Severe penalties including possible life in prison

• US State laws
• In the US, state laws add an extra layer of complexity
• The following location provides a good summary of the laws that apply specifically to "Computer Hacking and Unauthorized Access" by state
• http://www.ncsl.org/IssuesResearch/TelecommunicationsInformationTechnologyi/ComputerHackingandUnauthorizedAccessLaws/tabid/13494/Default.aspx
• In short there are MANY state laws related to computer crime, and interstate crimes may break lots of them
• Often State laws are more recent, further reaching, and more specific than USC laws

Cyber crime laws in Germany

• Penal Code Section 202a (Data espionage)
• Prohibits obtaining data without authorization, where it was specially protected against unauthorized access
• Up to three years in prison
• 202c (Anti-Hacking Law)
• Prohibits creating, possessing or distributing tools used for computer attacks
• 303a and 303b
• Prohibits alteration and deletion of data and interference with data processing
• Up to 5 years in jail or a fine

Cyber crime laws in Japan

• Law 128 (1999) Unauthorized Computer Access Law
• Prohibits unauthorized access by
• Stealing access codes or bypassing access controls
• Fines and up to one year in prison

Other countries

Obviously there are a lot more countries than this. Some have no computer laws, but many have similar laws.

Enforcement can be very variable in some countries. Even where no specific computer laws are in place computer crimes can often be dealt with using existing laws such as fraud, theft, criminal damage etc.


Mitigations

• Make sure that security testers have permission in writing
• Consider the ownership of all systems which may be affected by the test
• Testers should be aware of the law and be in contact with legal council (in advance)
• Testers should consult legal council regarding specific laws in all countries where systems may be accessed as part of the test

Updates to my study plan and CTP

I am really enjoying studying currently, and putting in around 10 hours a day 6 days a week.

Ethical hacking and penetration testing require a wide range of skills and knowledge.

Take SQL Injection attacks for example; This is a multilayer attack, where the attacker needs to understand various database queries (MS-SQL, MySQL, Oracle etc) and some scripting languages (PHP, ASP, Perl etc). If the attacker is also going to perform some form of command injection and get a remote administrative shell, they would also need to understand the configuration and capabilities of the web-server, and likely some advanced networking techniques (Windows, Linux, IIS, Apache, advanced use of various TCP tools such as FTP, TFTP, Netcat, inline file transfers etc).

It's lots of fun, but difficult to keep track of everything I am studying, which is why I have just updated my study plan again, at least so that I can keep track of what I have done so far:

http://insidetrust.blogspot.com/2010/10/study-plan-for-next-few-months.html

I am trying to book up exams every month or so, so that I have specific targets to aim for as well.

I passed CEH and Security+ recently, but I found them too easy, so I will be looking to complete some tougher challenges over the next few of months.

I've just started CTP, which is one of the most challenging Penetration and Ethical Hacking courses available.

CTP covers advanced hacking techniques such as developing 0-day exploits, crafting your own custom shellcode, advanced web attacks, reconfiguring border routers to tunnel MITM attacks across the internet, avoiding Anti-virus, back-dooring existing executables, and bypassing new Windows protection mechanisms such as DEP and ASLR.

It will probably take me a while to get through the material ;o)

How to choose better passwords

If you have read some of my previous blogs, you will have an understanding that passwords are a very weak form of authentication, mainly due to the difficulty users have in choosing strong and memorable passwords.

Here I discuss four ways to improve your password choices.

This is the best advice I can give to help people choose stronger passwords.

A bit about poor password choice

Often users choose simple passwords, and use the same password for all their services, both at work and at home. These are both bad ideas.

Simple passwords are easy and fast to crack with widely available automated tools. I know from experience, as I have cracked many passwords recently under test conditions, many in under a second, and certainly most in under 5 minutes.

Using the same password in multiple places means that once a password is compromised on one system, say your home computer, an attacker could then be able to access your work login, your email account, Twitter, Facebook, Youtube, PayPal, eBay, Amazon, and any other online services you use with the same password.

Attackers would not be targeting you personally. Modern malware can automate many hacking techniques and attack many thousands of users at once, globally.

Malicious hacking is big business, and there is a whole criminal subculture geared-up to make money from stollen credentials.

Many people store a lot of information online these days. Imagine if you lost access to your personal accounts and profiles, or worse; someone copied, added or removed information, or sent messages to all your friends containing clever scams or viruses, or transfered some of your money through a series of stolen bank accounts.


So what can users do to choose better passwords?

Having cracked many passwords with a variety of different tools and techniques, here are the four best pieces of advice I can offer.

• Password length is the most important factor. Try to use a "pass-phrase", i.e. a group of words that is longer than 15 characters.
• This is a sufficient length to make brute-force and hybrid attacks unfeasible with todays computing power.
• Using 15 characters or more also means that the password cannot be stored as an LM hash. (This is one of the weakest forms of password storage, that Microsoft still include on Windows systems today - for historical reasons, but it is a really big weakness)

• Add some numbers and symbols
• Though this does not affect password strength as much as length does, it can be helpful in making your password more unique, by using more of the available key-space.
• Here are some examples
• Friday%is&a4great*day!
• #thisisareallyeasyonetoremember!

• Use different passwords for the accounts you have
• It may be impractical to use a different password for every login to every system, but try to use unique passwords for your core services such as
• Home computer login
• Email access
• Bank accounts
• Work login
• Social networking

• Test your choices, to see if the types of password you are choosing are strong
• Try the Microsoft password strength checker, to get an idea of what makes a password stronger.
• https://www.microsoft.com/protect/fraud/passwords/checker.aspx
• Try putting your current password in. If it comes up "Weak" you're not doing very well with your password choices currently.
• You should be aiming to get at least in the strong category for passwords you use for important accounts.
• See if you can pick a memorable password, that meets the "BEST" category. Try several attempts so you will know what is important in choosing a strong password.

Now choose similar passwords for your own use.


PS: I use several password dictionaries of commonly used passwords, totalling over 200 million entries.

I find these very effective for password cracking, before attempting hybrid, rainbow-table, and brute-force attacks. They only take a few seconds to run for hash-cracking.

Most of these dictionaries are available on the web if you look, but if you are interested in me providing some copies, let me know in the feedback section.

CEH and Security+ Certifications

Over the past week I took (and passed) the Security+ and Certified Ethical Hacker (CEH) certifications (two more to add to my increasing list of certs).

Here are my thoughts about both exams.

Certified Ethical Hacker CEH

This was reasonably good exam, and passing it shows that you know something about IT Security in relation to hacking and countermeasures.

I found this exam easier than I expected (but having been on the Pentesting with Backtrack course, I guess anything in this field would seem easier).

The most interesting questions were around interpreting logs of hacker activity, and assessing what had been done or attempted. Having actually performed these attacks myself, I found it straight-forward, but interesting.

(I finished the exam in around half the time allowed, with a high passing score)


What does CEH prove?

• A reasonable knowledge for attack vectors, and some tools (though you don't need to be an expert hacker by any means)
• Knowledge of command line options, and interpretation of output, for various tools including
• tcpdump
• snort
• nmap
• hping
• Understanding of various reconnaissance and scanning methods
• Knowledge of several hacking techniques and methodologies
• A good working knowledge of Wireshark and networking protocols
• An understanding of DoS, rootkits and trojans

What doesn't it measure that I feel it should

• Ability to use these tools in a real world environment
• Ability to perform a penetration test, or defend a network

I would say this exam is focused more towards incident response teams rather than ethical hackers or penetration testers, but I enjoyed it, and would say that it was worth taking.

Security+

This exam was disappointing as I found it far too easy. Very much an entry level exam.


What does it prove?

• A very general understanding of basic IT Security principles and networking protocols
• Not sure other than that...

What doesn't it measure that I feel it should

• Far too much to mention (I really don't think it measured my skills or challenged me)

I'm not sure who this exam is aimed at, perhaps IT staff who are taking their first steps into IT Security.

In Summary

CEH is a reasonable exam to prove a basic understanding in incident response, hacking, and network security. I would say this exam is worth taking, though certainly not as in-depth as something like OSCP or CREST.

As for Security+: If you are thinking of taking, or hiring anyone based on Security+; I would say look at other certs as this one is very much entry level.

My recommended certs

For all the exams, courses and certifications I have taken so far, I would most recommend the following based on their difficulty, value to a company, and ability to measure a person's skills and knowledge.

• CISSP - For a very broad reaching view of IT Security
• OSCP - For it's technical depth, and understanding of attackers
• CISM - To help match IT Security to the needs, and risk tolerance, of a business

Password cracking: Using John The Ripper (JTR) to detect password case (LM to NTLM)

When password-cracking Windows passwords (for password audits or penetration testing) if LM hashing is not disabled, two hashes are stored in the SAM database.

The first is the LM hash (relatively easy to crack because of design flaws, but often stored for backwards-compatibility)

The second is the NTLM hash which can be more difficult to crack (when used with strong passwords).

LM hashes store passwords all uppercase, and split into 2 blocks of 7 bytes (which is part of the reason why they are so weak).

This makes LM hashes easy to crack (complete rainbow tables of all possible hashes can be easily obtained for super-fast cracking).

However, cracking the LM hash does not tell you the full story about the password, i.e. you won't know the case of the alphabetic characters in the password. The passwords could be all uppercase, all lowercase, or a mixture and finding the case of the passwords can be important.

Here I will show how to crack the LM hashes and use these to find the exact password from the NTLM hashes.

Please remember to use these techniques only for legitimate educational and testing purposes and not maliciously.


The hashes

For these tests, I first set up a test Windows XP machine and added six users with various passwords, some of which you may think would be strong, but they are not strong enough!

I extract the passwords from the SAM using fgdump.exe, and get the following:

bert:1011:5DF12C9F2162249EAAD3B435B51404EE:099C037B843FDCA6489B03635E87EA76:::
erik:1008:4E1FB9BDD16A8F51AAD3B435B51404EE:FDC342B83B8A552C742B013E8A1BCA99:::
ernie:1012:1B638DBD583CF83D64BBD09A598E07AD:01C4EA2C58B2A0326D5EDF613E60DCED:::
jack:1015:F41D0D9F9038C51884672E50BA7FB014:14EAE3724A706F637FFC150A085F6EB3:::
phil:1009:208752DBBBEC625EAAD3B435B51404EE:9762FAD5394D489BFD7F662E9BC13655:::
sam:1010:FA1961430A96F9BEAAD3B435B51404EE:53F0FAE7D53BBE6C90F843ECEB71DCA0:::

So in the following example this is the LM hash, and this is the NTLM hash.

bert:1011:5DF12C9F2162249EAAD3B435B51404EE:099C037B843FDCA6489B03635E87EA76:::

I have put these hashes in a file called crackmemixed.txt on a Backtrack 4 system in /pentest/passwords/jtr.


Cracking the LM hashes


We will be using John The Ripper, so first type

john

To crack the LM hashes it is always worth trying a dictionary attack first, as this is very fast, so I will use the following command:

./john --wordlist=/pentest/passwords/wordlists/bt4-password.txt crackmemixed.txt
Loaded 12 password hashes with no different salts (LM DES [128/128 BS SSE2])
HAPPY            (erik)
OW               (ernie:2)
SHOWMEN          (ernie:1)
GRRRRRE          (jack:1)
WIBBLE           (sam)
guesses: 5  time: 0:00:00:00 100.00% (ETA: Mon Jan 10 10:13:33 2011)  c/s: 26204K  trying: ZZAJ - {LOG}

This used over three million passwords, took less than a second and cracked some of the hashes. (For LM hashes, the passwords longer than 7 characters are crack in two 7 byte pieces)

There are a few more hashes to crack so we will let JTR do a brute-force attack on the rest:

./john --format=lm crackmemixed.txt
Loaded 3 password hashes with no different salts (LM DES [128/128 BS SSE2])
AT!              (jack:2)
FLUFF34          (phil)
4REF5            (bert)
guesses: 3  time: 0:00:00:18 (3)  c/s: 19370K  trying: 4RIIN - 4RO5A

So we are all done with the LM hashes in under 20 seconds (which is pretty good). For stronger passwords, if this method was taking longer than a few minutes, I would probably would move to LM hash rainbow tables next, which would speed things up a lot.


Check our LM hash-cracked passwords


To display what we have so for we can do

./john -show crackmemixed.txt
 
bert:4REF5:1011:::
erik:HAPPY:1008:::
ernie:SHOWMENOW:1012:::
jack:GRRRRREAT!:1015:::
phil:FLUFF34:1009:::
sam:WIBBLE:1010:::

8 password hashes cracked, 0 left

... but as you can see, this is all all displayed in uppercase, as we can't tell the case of the passwords from cracking the LM hashes.


Preparing for cracking the NTLM hashes

We are going to change the rules that JTR uses, so will will make two backups of the rules file:

cp john.conf john.conf.old

cp john.conf john.conf.ntlm

Then edit the rules file, as follows:

• In john.conf.ntlm
• Replace "List.Rules:Wordlist" with "List.Rules:Disabled" to disable the normal ruleset
• Then replace "List.Rules:NT" with "List.Rules:Wordlist" to enable our specialised attack

Our NTLM hashes

To show the NTLM hashes we are trying to crack use:

./john --show=LEFT --format=NT crackmemixed.txt

sam:$NT$53f0fae7d53bbe6c90f843eceb71dca0
phil:$NT$9762fad5394d489bfd7f662e9bc13655
jack:$NT$14eae3724a706f637ffc150a085f6eb3
ernie:$NT$01c4ea2c58b2a0326d5edf613e60dced
erik:$NT$fdc342b83b8a552c742b013e8a1bca99
bert:$NT$099c037b843fdca6489b03635e87ea76


Cracking our NTML hashes

First we need to create a dictionary file which will contain just the passwords we have already obtained from LM hash-cracking, with the following command:

./john --show --format=LM crackmemixed.txt | grep -v "password hashes" | cut -d":" -f2 | sort -u > lmcracked.txt


So we now have a list of just the passwords in uppercase in lmcracked.txt. Let's put our special password rules in place:

cp john.conf.ntlm john.conf

Now we can using our specific password dictionary and rules to crack the NTLM password hashes as follows:

./john -rules --wordlist=lmcracked.txt --format=nt crackmemixed.txt
 
Loaded 6 password hashes with no different salts (NT MD4 [128/128 SSE2 + 32/32])
4Ref5            (bert)
HaPpY            (erik)
fluff34          (phil)
wibble           (sam)
GRRRRReat!       (jack)
ShowMeNow        (ernie)
guesses: 6  time: 0:00:00:00 100.00% (ETA: Mon Jan 10 11:24:44 2011)  c/s: 44800  trying: GrrrRREAt! - sHOWMEnow

This took less than a second, and we have cracked the case sensitive NTLM hashes from the case insensitive LM hash-cracked passwords.


Returning JTR rules back to normal

After you are done, don't forget to put the rules back how they were:

cp john.conf.old john.conf



Mitigation

End to end, this exercise could have been done in under a minute. This just goes to show how weak passwords can be, and how easily they can be cracked with the right tools, network access and knowhow.

• Disable LM hashes
• Implement a strong password policy
• Check this is enforced and working correctly with regular audits

Accessing and cracking mysql passwords via vulnerable web applications

In this article we look at extracting passwords and cracking hashes from a MySQL database via a vulnerable web application. These techniques are equally relevant to other databases (MS-SQL, Oracle etc) though db syntax, exact capabilities and hashing algorithms will vary.

I'm not going to go into the details of specific web application attacks here, as there are plenty of examples of LFI, RFI, SQL injection, and other command injection attacks, on the following sites:

www.securityfocus.com
www.exploit-db.com

These types of attacks are very popular currently, with new vulnerabilities in web applications being discovered every day. Here I will simply talk about a couple of options for extracting MySQL passwords, following-on from initial attack vectors.

Please remember to use these techniques only for legitimate penetration testing, not for malicious purposes. Every action you take has consequences, and you will be heir to the results of your actions.


Direct knowledge of SQL passwords from config files

Typically a web application that needs to access a back-end database will have a configuration file that contains the database details and login credentials. This is essential for the web application to work.

The config file may be called something like "config.php", and would typically be stored in one of the web directories as part of the site.

Important lines in the file might look something like this:

$db_host = 'localhost';
$db_name = 'webdb';
$db_user = 'root';
$db_password = 'p@sswd1';

So it may be possible to get these credentials directly, using an attack which exposes the contents of the configuration file.

This could be via local or remote file inclusion attacks, sql injection etc.

Whatever the method, getting hold of this file is useful. Even if the database is not directly accessible, getting passwords can be an important step as passwords are often reused in multiple places.

Even if this password is found, it may have a low privilege, so may be worth continuing to follow the details below with other users. There may be several accounts in the database where the hashes are accessible.


SQL Injection to view table contents

It may be possible to get at the relevant user and password fields directly from the back-end database using SQL injection, and display the results in web page, either directly as part of the query results, or by creating a file with the details in.

A typical query to do this might looks something like this:

SELECT user,password FROM mysql.user;

...and would produce results in the following format...

+------------------+-------------------------------------------+
| root             | *1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93 |
+------------------+-------------------------------------------+


Single text field limitation

If you are limited to displaying a single text field in the query, then the user-name and password could be joined into a single field as follows:

SELECT CONCAT(user,':',password) FROM mysql.user;

+------------------------------------------------------------+
| root:*1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93             |
+------------------------------------------------------------+


Outputting password hashes to a file in a SQL query


Another way of extracting password data would be to write it to a file. You may be able to write to a new file in a web directory on the web-server, that you can then get to from a web browser.


This could be done with a SQL query similar to the following

SELECT user,password FROM mysql.user INTO OUTFILE '/var/www/images/hacked.txt';

This creates a new file, "hacked.txt", which could then subsequently be accessed with a web browser, by going to:

http://<site>/images/hacked.txt

Cracking the hashes

So what have we got here? These are password hashes, double SHA1 hashes to be exact (as denoted by the asterisk in front).

If the password is not particularly strong, these hashes can be easily and quickly cracked with John The Ripper, using a dictionary, brute-force or hybrid attack.

There are some large dictionaries of common passwords on Backtrack 4. There are a 40 million passwords in the following directory (though some duplicates between the files):

wc -l /pentest/passwords/wordlists/*

  3385284 /pentest/passwords/wordlists/bt4-password.txt
  1707657 /pentest/passwords/wordlists/darkc0de.lst
 35072354 /pentest/passwords/wordlists/wpa.txt
 40165295 total

Dictionary attacks on password hashes can be very fast. For example on my desktop (fairly new, but a basic spec) I get a hash-cracking rate of around 2 - 4 million characters per second, so this is a pretty rapid process.

I did some simple tests on the wpa.txt dictionary above, and it completes the 35 million hashes in around 13 seconds.

A dictionary attack could be started as follows.

john
./john hacked.txt --wordlist=/pentest/passwords/wordlists/wpa.txt

Loaded 1 password hash (MySQL 4.1 double-SHA-1 [mysql-sha1 SSE2])
guesses: 0  time: 0:00:00:13 100.00% (ETA: Thu Jan  6 19:34:24 2011)  c/s: 2675K

Note: It is very important to include the asterisk as part of the hash in your file. Don't take this out, otherwise JTR will not know that this is a double SHA1 hash, and will try to crack it as a SHA1 hash (which will fail)


To let JTR do an efficient brute force attack simply use

john
./john hacked.txt 

So, it's pretty simple, and weak passwords will certainly be cracked.


Your turn to have a go at cracking hashes

OK, so now you know that basics, here is your chance to have a go at cracking some hashes.

Below there is a mixture here of MD5, SHA1 and double SHA1 hashes for you to have a play with:


MD5 hashes

+----------------------------------------+
| pass1:cac36191e75ca4ddcbe5800c5cd25f92 |
| pass2:33c5d4954da881814420f3ba39772644 |
| pass3:c25846bdbf27696caa5541a474e9521b |
+----------------------------------------+


SHA1 hashes

+------------------------------------------------+

| pass4:d9d71ab718931a89de1e986bc62f6c988ddc1813 |

| pass5:348162101fc6f7e624681b7400b085eeac6df7bd |

| pass6:36e618512a68721f032470bb0891adef3362cfa9 |

+------------------------------------------------+

Double SHA1 hashes

+-------------------------------------------------+
| pass7:*1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93 |
| pass8:*EA107160A003D070FE3EFE409813807BBA5ECE03 |
| pass9:*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
+-------------------------------------------------+


See if you can crack them...

Top marks to anyone who can get all nine.


Mitigations

These threats can be mitigated in the following ways

• Choosing strong passwords
• Secure webapplication design and coding
• Patch management, product updates and configuration management
• Least privilege (use minimal privileges and a dedicated web application accounts)
• OS and database hardening
• Penetration testing to confirm the level of security and identify weaknesses