Tuesday, May 26, 2009

sslstrip: HTTP session hijack

About:
sslstrip provides a demonstration of the HTTPS stripping attacks presented at Black Hat DC 2009. It transparently hijacks HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. 

How to Use it?
Configure the attack machine to allow traffic forwarding.
Setup iptables to redirect HTTP traffic to sslstrip.
Run sslstrip.
Run arpspoof to convince a network they should send their traffic to you.
That should do it.

How does this work?
First, arpspoof convinces a host that our MAC address is the router's MAC address, and the target begins to send us all its network traffic.  The kernel forwards everything along except for traffic destined to port 80, which it redirects to $listenPort (10000, for example).

At this point, sslstrip receives the traffic and does its magic. 

For more info & the Black Hat DC 2009 preso, click here:

Saturday, May 23, 2009

SQL Injection: A primer II

In continuation with my earlier post, SQL Injection: A primer (http://ipositivesecurity.blogspot.com/2009/05/sql-injection-primer.html), I will be covering the following in this post:

a. Blind SQL Injection
b. Remediation Measures

About:
Blind SQL Injection is used when a web application is vulnerable to the SQL Injection but the results of the malicious input strings are restricted or not visible to the attacker.

Attacking using Blind Injection involves observing the variations in the page output after the malicious query input is feeded into the application. The page with the vulnerability may be different than the page which displays data. The output display is different depending on the results of the logical statement(s) included with the legitimate SQL statement for that page.

Since the output varies with the attack strings, this attack can be time-intensive.

Types of Blind Injection Attacks:
1. Conditional Responses
This attack involves observing the output from the database by appending different evaluative strings. For example:
select uname from employees where deptID = 'a500' AND 1=1;
will result in a normal output / page display. And if:
select uname from employees where deptID ='a500' AND 1=0;
results in a different result / page display, it would be clear that the page is vulnerable to SQL Injection.

The reason behind this inference is the the behavior of database for the appended query string -> AND 1=1 / AND 1=0. The output must not have varied & the queries would have resulted in the same output regardless of any appended strings as input, had the input validation been in place.

2. Conditional Errors
This attack differs from Conditional Responses by attempting to force the database to evaluate a statement which would eventually throw an error when the query returns TRUE. For example:
select 1/0 from employees where uname='Victor';
1/0 will be evaluated only when the record 'Victor' is found & would then result in an error. This would provide a confirmation to the attack of the existence of the uname 'Victor'.

3. Time Delays
Another important type of Blind SQL attacks is the Time duration taken by the database to execute a long running query or a time delaying statement depending upon the query. The attacker would observe & measure the time taken for the page to load & attempt to determine if the query executed successfully as TRUE.

Remediation / Preventive Measures Against SQL Injection Attacks:

1. Using Parameterized Statements
In this technique, SQL BIND variables are used as the placeholders for the user input. A BIND variable is a question mark for each input parameter. 

The SQL statement is created using these BIND variables, it is compiled (prepared) into an internal ready-to-use form, only awaiting the value of the placeholder now. Once the parameter value (placeholder) is received, this prepared statement is executed & the resultset is presented to the front-end.

For example, in Java:
PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?");
prep.setString(1, username);
prep.setString(2, password);
Here, the value of the 'username' & 'password' is passed as positional parameter - the question (?) marks, referenced by 1 & 2, respectively. The content of these variables do not have any impact on the final query because it is treated as 'plain data.' Hence, the application is now greatly immune to SQL Injection as against a normal query.

2. Using Stored Procedures
Stored Procedures provide encapsulation to rules for specific actions - Select, Insert, Update, Delete, etc. - into a single procedure. Business rules can be enforced so that if cond. A is TRUE, Allow Action A, else Deny Action A. For example, if a customer is a VIP, then allow him/her to avail a discount, else, apply full amount.

Stored procedures help prevent SQL Injection attacks by limiting the type of SQL statements that can be passed to their parameters. However, they are not the complete solution against SQL Injection.

3. Input Validation
Every input parameter & the value must be validated before the input reaches the database. The input fields could be input box, drop down box, check box, hidden fields, a Button, etc.. The important thing is to understand and chose the validation scheme.

There are 2 validation schemes-
1. Reject known blacklist
2. Accept known whitelist only

Using Blacklist as the sole criterion for filtering & validating the input is not a good idea. This is because of the availability of different schemes available, to convert the form of input, - Unicode, hex, base, etc.. A developer cannot & must not base his validation checks based on the Blacklist sets for it is bound to be incomplete, always.

Instead, Using Whitelist is an effective solution. Whitelist specifies the characters only which would be allowed to pass through. Period.
This allows a developer to exercise better control in defining the positive validation checklist for the input. And it is good for the security tester too :)

Besides these 3 mitigating techniques, there are other methods as well which are helpful in controlling the attack surface available for exploitation.

4. Code Reviews
The Code Reviews checks the source code of the application for flaws with respect to security. A Security professional or a developer with good knowledge & experience on Secure coding practices should do a code review. This is a manual process & hence it is time-consuming process. There are automated tools now available for this purposes. Few of them are: Checkstyle (http://checkstyle.sourceforge.net), JNorm (http://www.jnorm.org), Perl::Critic module, Parasoft (http://www.parasoft.com/jsp/solutions/application_security_solution.jsp?itemId=322) etc.

5. Control Database Error Leakage
As important it is to use Stored Procedures or Parameterized Queries, equally important is to configure the error messages thrown by the database on receiving an expected or invalid input. Think of it - an attacker being able to gather table, database, column name info, or related 'joined' table info through error messages. All your SPs, Parameterized queries, code reviews are no longer effective. Hence, configure the database errors to restrict the details or the debugging information meant to help the developers. Put a generic custom messages, whereever possible.

6. Securing the Web Server
All the code reviews, automated assessments, & manual security assessments CANNOT ensure a 100% security. It is, therefore, essential to balance the web application security measures with a secure network design. Employ a defense-in-depth approach while planning for securing the server:
- place the server in a tier-ed architecture, or at least in a hardened DMZ.
- use Web Application Firewalls (WAF) - though OWASP 2009 showed us bypassing WAFs, it's still good enough. (I will have a post coming on WAF soon.)
- And, Log monitoring.

This concludes the second & final post on SQL Injection: A primer. Please note that this is not complete even now. SQL Injection is a vast topic in itself. I have tried to present the concepts here as clearly as possible, the attack methods, query strings, steps taken to recon & penetrate a target; all may vary from applications & their implementations.

I hope someone finds this useful.

Please feel free to share your feedback.

Thanks for your time.

SQL Injection: A primer

About:
SQL Injection is a query / code injection technique which exploits a vulnerability in the database of an application. The database back-end can be Microsoft SQL Server, Oracle, or mysql; i.e. any database which understands the Structured Query Language (SQL: http://en.wikipedia.org/wiki/SQL).

The vulnerability is present when the user input is not filtered properly for string literal escape characters. This user input usually is acting as the variable for constructing a SQL query when it reaches the back-end.

How do I test it:
In order to test if a field may be vulnerable to SQL Injection attack, there's a Magic String. The magic string is a simple string of SQL which always results in a TRUE condition. Although several variations are used to verify the vulnerability, the simplest string is mostly used on Login pages. The string is:
' OR ''='
String variations:
' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a
In case of a vulnerable login page, a successful attack will log you in as the first user in the table.

Keeping it Simple:
A simple example is of an input box which takes a numeric value as input. This value is passed as a parameter to the back-end & record(s) are returned from the table corresponding to the SQL query.

Let's say, if the variable recordNumber is used in a query as:
select * from secureTable where recordNumber = (userInput)
Giving a value to this variable as:
recordNumber = a' or '1'='1
will create the final query as follows:
select * from secureTable  where recordNumber = 'a' OR '1'='1';
The resultset from the WHERE clause will always be TRUE ('1'='1'), thereby resulting in all the records from the secureTable.

A serious query could be:
recordNumber = a';DROP table secureTable ; select * from data where uname like '%
This would result in the following query:
select * from secureTable where recordNumber = 'a'; DROP table secureTable ; select * from data where uname like '%';
This query results in all the records from the secureTable AND then drops the table 'secureTable ' AND fetches the recordset from the table 'data'.

Note that some sql server APIs like php's mysql_query do not allow for such multiple statements to be executed within one call.

What Next?
This post covered the basics of SQL Injection & discussed first order SQLi attacks. Another type of attacks are second order / Blind Injection attacks & I will cover them in the coming post(s) along with the remediation / preventive measures for the SQL Injection attacks.

Thanks for your time.

Tuesday, May 19, 2009

CCIE Security Lab Changes

The much-expected change to CCIE Security track has finally arrived.

From Cisco CCIE Security Track home (http://www.cisco.com/web/learning/le3/ccie/security/index.html) :

Effective June 15, 2009, the Cisco CCIE Security lab exam will feature a new type of question format in a section called Core Knowledge. In this new section, candidates will be asked a series of four open-ended questions that require a short, typewritten response (typically several words). The questions will be randomly drawn from a pool of questions on topics currently eligible for testing on the CCIE Security lab exam. No new topics are being added. Candidates will have up to 30 minutes to complete the Core Knowledge section of the exam, and may not return to the questions later. First introduced to the CCIE Routing and Switching lab exam in February 2009, Core Knowledge questions will eventually be added to all CCIE tracks. The changes allow Cisco to maintain strong exam security, and they help ensure that only qualified candidates are awarded CCIE certification.

The change was first implemented in the CCIE Routing & Switching track effective February 1, 2009.

CCIE Routing & Switching Track:
http://www.cisco.com/web/learning/le3/ccie/rs/lab_exam.html

The immediate candidate reaction after CCIE R&S change notification, as expected, has been to attempt CCIE labs before these changes got effective. Not to miss a similar reaction by CCIE Security Candidates, who registered in flocks, before the new syllabii version 3.0 came into effect in mid-April 2009.

I touched base on these 4 open-ended questions from the R&S guys who recently appeared (& passed) the CCIE Routing & Switching Exam. The questions are from the syllabi, & any candidate who has sincerely prepared for this mammoth exam should be able to answer them.

Well, now that the Security Track has a new version 3.0 syllabii, I strongly believe these 4 questions are definitely going to play a crucial part in filtering out the certified CCIE's. I wonder why Cisco didn't chose to integrate it earlier. A lot many candidates who I know, ofcourse CCIE certified now, would have still trying to get past these 4 open-ended questions, had these changes been implemented earlier. Not to say, these didn't knew the syllabii or didn't prepared well, but this is concerned more with the sound knowledge & experience over the technologies covered in the exam.

CCIE is THE test of a network security professional's knowledge of core concepts, configuration & troubleshooting abilities. And the products, though a handful only - (ASA, IOS firewalls, IPS, NAC) - require a thorough understanding & a good hands-on experience. This move will ensure a candidate has good knowledge of the technologies, domains, products & solutions along with hands-on experience towards certification & those training institutes who've been earning a fuckin', easy $$$ using pattern-based / (somehow) known questions that came in the exam will have to find another way to get their candidates pass this new bar.

Good move, Cisco.

CCIE Security Lab Blueprint v3.0:
http://www.cisco.com/web/learning/le3/ccie/security/lab_exam_blueprint_v3.html

SamuraiWTF 0.6 Released

About:
The Samurai Web Testing Framework is a live linux environment that has been pre-configured to function as a web pen-testing environment. The CD contains the best of the open source and free tools that focus on testing and attacking websites.

http://samurai.inguardians.com

New Release:
The SamuraiWTF project team is proud to announce the immediate release of SamuraiWTF 0.6. This release contains a number of fixes and updates as well as the first release of a VM image. This VM requires Vmware 5.0 or better.

It will also work in any version of VMWare Fusion.

Download samurai-0.6
:
http://sourceforge.net/project/showfiles.php?group_id=235785

Disclaimer

The views, information & opinions expressed in this blog are my own and do not reflect the views of my current or former employers or employees or colleagues.