From: Rivest, Philippe (Rivestp@metro.ca)
Date: Tue Jan 08 2008 - 13:56:21 EST
Hello,
I'm very new to security as a penetration tester. In fact my whole background is basically books and RFC and these mailing lists. Anyhow I have been asked to do a penetration test of SQL in my enterprise and since this is the first I will do I wanted to know what steps I should follow to perform such a test. Surprisingly enough, I have been able to write down quite a few steps I will follow to perform the test. I want to give this to the public to get feedback on what I may miss, but more importantly give an example to those who may want to start somewhere like me.
Please note and remember, this is my first time and I will be missing a lot of stuff. Also, I tried to organise everything to follow a logical order. I put everything I thought was pertinent to a pen-test, if its not to yours or you don't have authority to perform a step, please refrain yourself.
This should be considered as a draft.
Note, to best view this please read the email in HTML format to get this in a clear fashion.
(I do hope this output works)
Process to do a penetration test on SQL
- Get writing approval and clarification of the needs of the test:
* This document must incorporate what needs to be tested and what is to not be tested.
o Should this test include a physical security aspect?
o Should the testing team test only the application or the whole environnement in which the SQL server reside?
* It should be noted at what time and day the tests are to be done.
* The names of the members of the penetration team should be in this document.
* The actual IP/MAC of the computers that will be used to do the test should be inserted and the security team and the administrators should be notified. Unless they're responses is to be tested.
* It should state that the test should be done from an internal or external network. If it is to be done by external network thru an ISP, they should be advised.
* Should this test be done with some knowledge of the enterprise (Blackbox testing or not)
* It also should be noted if the testing team can perform DOS attack.
* If they can a plan should be done that would state what action are to be taken if the servers are taken down. Who is responsible and what are the phone numbers to call.
* Can social engineering attack be performed? If so to which extend? Can we use the helpdesk and so on.
* It also should identify who will get the final report
* It should be agreed on the medium by which the penetration team will provide the report (CD-DVD,paper?) and how many copies and so on.
* And most important statement of all for the testing crew. A no fault statement should be added, stating that under the condition of the previous declaration and under no bad intent should the testing team be held responsible for any lose either financial or what so ever.
----------------------
-Information gathering
----------------------
* Verify the enterprise web URL for username/emails/information
o Those username will be use in a brute force attack later
o The emails can be used to identify if there is a
username --> email pattern like name.familyname@..
* On the web search identify important people and phone numbers (RH,Directors). This will help in the social engineering part.
* Validate the garbage cans of the company to see if there is any sensitive data (dumpster diving)
* Go thru the workstation area of employee to identify
o Passwords
o IP
o Network diagram
* Identify possible attack vectors. Like Front end and Web servers that use SQL.
o Web page with username/password fields
o Inventory page, cart with what you want to buy
* Identify the information given by WHOIS services (Arin for example)
* Try a zone transfer (DNS)
* Identify live host and add those information with the WHOIS & Zone transfer
o Establish a network diagram.
o Use Ping
o Traceroute
o Mturoute
* Try obtaining the banners of the remote systems (SQL mostly)
* Use google to get information you need.
o SQL site:enterprise.com
o Password site:enterprise.com
----------------------
-Automated tools
----------------------
* Use SQLVER to get the version of SQL
* Use SQLPING to identify the version
* Use a web crawler to get information on "Microsoft,SQL,Emails"
* Perform a full port scan (TCP/UDP) on the SQL servers.
o Identify the services that are running on those servers
o Get the banners of each of those service if possible
o Update the network diagram you already did.
* Identify SNMP services
O These service use easy to bypass password (also they are un- encrypted) they should be tested later in the MITM attacks
* List the network shares, try identifying IPC$ and C$ and so on (if they are windows based servers)
* Try to identify if there is an LDAP server, if they are in a domain. If they are in a domain try finding out which version they are using NT4, AD?
* Try navigating thru AD if it's in read only to everyone.
o Identify accounts that could connect to the server
* Use pwdump to get the remote SAM
o Use L0phcrack (or john the ripper) to crack the SAM
* Try connecting to the SQL service with the user SA with no password. Use SQLRecon for this.
* Use SQLDict to brute force the password of the SA account.
* Try a MITM (man in the middle) attack to sniff the SA password or any password used to connect to the server.
o Sniff port 1433
o You can use Cain & Abel
o You also can use Ettercap
* Use Nessus to identify vulnerabilities of the remote system
* You also can use MBSA if it's a windows server to get a bit more information
* Look up vulnerabilities with Nikto for web base SQL servers
* You can use Metasploit to exploit the servers identified vulnerabilites
* Use different vulnerabilities tools that you have at your disposal (some may be financially hard to get)
o Try SQLPING to identify SQL Injection weakness
o Try Absinthe for blind injection
o Try SQL Injector for sql injection
* Try using a fuzzers (technique called fuzzing) for any SQL injection vulnerabilities identified above.
* Try using the net and mailing list to exploit the vulnerabilities you just identified (this has a very large spectrum of possibilities since it all depends on the vulnerabilities you found.)
o Use the net
o Use securityfocus
o Use your imagination
------------------------------
-Write down the final papers
------------------------------
* You need to write down 2 final reports
o One with a survey of what you did and the explication of the result and impact. You will need to state what kind of impact the flaw XYZ has if it is exploited.
* A second report has to be done. In this report the entire test you did with the technical result needs to be given. In this report you don't need to bother with staying under a few pages, give everything you have. If your test did not yield any special flaws, don't worry this report will show the work you did and prove your result to be right. (Remember that a test is only as good as the testing team)
* Give out the report to the authorised people in the medium that was approved (CD-DVD,paper)
* Know that a live presentation to a comity may be possible, or asked.
* Usualy once the report is given to the client, you should destroy everything you have from that test. This is to protect you from information leek.
I do hope this will be helpful to someone.
Merci
Philippe Rivest, Certified Ethical Hacker
Analyste en sécurité de l'information
Métro Richelieu
450-662-3300x3115
P Est-ce vraiment nécessaire d'imprimer cette page ?
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:19 EDT