Grey bar Blue bar
Share this:

Mon, 9 Feb 2009

Vanilla SQL Injection is oh-so-90's...wait...is it? (Jackin the K)

aka.. Someone put the hurtski on Kaspersky..

The Twitters (via XSSniper and others) and the Interwebs were ablaze with news on a SQL Injection vulnerability that was exploited on AV vendor Kaspersky's site. Detail of the attack can be found here.

It's interesting that SQL Injection (though as old as the proverbial hills) is still such a major issue. In fact, I have it on good authority that the bulk of PCI-related compromises are still as a result of SQL Injection...

In our own work, we see this all over the show.

Also interesting is the fact that the DB in use by Kaspersky is MySQL - so much for the "I don't use MSSQL, I have x database with magical pixie dust SQL Injection protection - what me worry?" argument...

Once again, security one-oh-one...if you aren't *effectively* validating user input, you're going to get bitten some time...

/nick

ED* From the shameless self promotion department:

haroon and Marco have just finished their chapters in an upcoming book dedicated to SQL Injection. We will post more details here when its available. (the book aims to give SQL Injection thorough coverage from OR 1=1 to some of the insanity demo'd at BlackHat last year..)

Thu, 18 Sep 2008

Sarah Palin, a yahoo email account, and something more shocking...

By now everyone knows that John McCain's running mate Sarah Palin had her yahoo email account hacked. I guess a presidential candidate using yahoo for govt. related email was about as shocking as Sarah Palins nomination as possible future president ((unless of course you have ever heard of other govt. officials using yahoo/gmail/hotmail for serious business)(inside joke for south africans!)).

People have been talking about secure password resets for a long time [1] and this was pretty shocking all around..

But even more shocking for me (as a totally removed observer), was the Errata Security post (authors of hamster, which we commented on [here]) ending their post with an endorsement of the McCain/Palin ticket.. i thought all (american) hax0rs leaned towards "the change"

Fri, 1 Feb 2008

HTTP Mangling, Redirection etc.

So - here's the scenario.

Lohan is busy testing an application which uses remote web-services on a server called (example) www.target.com, but the program bypasses all proxy servers etc, making it impossible to trap and mangle requests.

So, we do the following:

1 - We make a note of the IP address of www.target.com (in this case, we'll assume it is 196.310.150.126 )

2 - Add a host entry in hosts, mapping www.target.com to 127.0.0.1

3 - Fire up a quick C# app written by yours truly which listens on 127.0.0.1:80

4 - Fire up a proxy server

5 - Configure the C# app to use proxy server 127.0.0.1:port of proxy
Now, the C# app does the following:

1 - Intercepts the HTTP request addressed to www.target.com

2 - Mangles the HTTP request to convert it into a proxied request (ie: Request "GET / HTTP/1.0" now becomes "GET http://196.31.150.216/ HTTP/1.0")

3 - Writes the request to the proxy server

4 - Writes the response back to the application

So, we're now able to intercept, fuzz, mangle etc all the requests and responses between the application and the web service. Not really rocket science, but rather handy...

The screenshot shows something similar, but using a web browser in place of the application here. I am using paros in this example because I am still doing large chunks of work on Suru...

HTTP Mangling

/ian

Tue, 1 Jan 2008

Applescript for HTTP BruteForcing..

A long time ago i blogged on the joys of using VBS to automate bruteforcing [1|2]when one didnt want to mess about duplicating an applications functionality at the protocol level.. Yesterday i had need to brute-force a web application which tried hard to be difficult and annoying..

Normally i would have used crowbar, Suru or a ugly mangled Python script, but the application was strangely difficult..

i.e. the login process is multi staged, with new cookies being handed out at various stages. 302 redirects are used heavily and then to top it off a healthy dose of JavaScript is sent back in replies that also affect your navigation.. Now all of this can be scripted (obviously) but i figured i would try automating Safari with applescript to get the same effect..

Co-opting the browser means i dont have to worry about redirects and javascript and (other stuff i didnt want to be messing with on new years day).. and so..

(click for full-size)

So this script effectively fires up Safari and iterates through my list of usernames. It then uses JavaScript to fill in the parts of the forms i need to fill in (only a few samples left in this example) and clicks submit when needed.. It uses username+123 as a password. Once it jumps through all the hoops it needs to, it screenshots the result and saves it in ~/captures/XXXX.png (where XXXX is the username being tested).

This was quick and dirty, if i had more time i would have chosen to read the results and only screenshot results that didnt match "your credentials are invalid".. ahh.. for another day..

*** a word of warning.. AppleScript is described as "an English-like language used to create script files that control the actions of the computer and the applications that run on it." This english-like-ness makes it extremely obtuse at times..

In a subsequent version of the brute force, i wished to use the username from my list, and the users First Name as his password. Now this is an obvious call for a hash/dictionary/associative array.. The sparse documentation that i was able to find on AppleScript records did not appear to help me a jot (but this could just be poor google skills).

Instead i opted for saving the username and password as a ":" delimited string. I then split the string at runtime and submit as before.. ugly, but effective..

its not perfect, but its neat and a nice tool to keep in your arsenal..

/mh

Tue, 11 Dec 2007

Rob Auger from OWASP/WASC/CGiSecurity on Timing..

Rob had a rant on his site on the timing attack, with a CSRF twist.. We met him after our Vegas talk, but im not really sure how his attack differs from our published one..

my on-list response:

-snip-
From: haroon meer 
To: bugtraq@cgisecurity.net
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] Performing Distributed Brute Forcing of CSRF
vulnerable login pages

Hi Robert..

Thanks for the kind words on the talk.. If you check out the visio at: http://www.sensepost.com/blogstatic/2007/08/dxsrt.png you will see that its pretty much the same attack.. In a shameless display of self-pimpage, check out the paper http://www.sensepost.com/research/squeeza/dc-15-meer_and_slaviero-WP.pdf from page 12.. Figure 23 for example shows the results in a victim/zombies browser, after he has visited our page.. Effectively he tries the userlist we send him (in this case on a standard squirrelmail login page). Once he detects a timing diff (again using a trivial algorithm to avoid latency disparity) he simply makes another request to the attacker to report his success..

We do give the important pieces of the script in the paper, but i suspect anyone with 2 minutes of time could have cobbled them together anyway..

/mh

-snip-