Grey bar Blue bar
Share this:

Sun, 7 Jun 2009

Excellent paper from MSFT Research on inline proxies vs. SSL

Ron Auger sent an email to the [WASC Mail list] on some fine work presented recently by Microsoft Research. The paper (and accompanying PPT), titled [Pretty-Bad-Proxy: An Overlooked Adversary in Browsers' HTTPS Deployments] is pretty cool and shows several techniques for a malicious inline proxy to sniff SSL sessions passing through the proxy. Its genuinely a bunch of cool findings and has been handled neatly (with the exception of some shocking clipart!).

The attack logic is fairly simple. User tries to browse to The browser sends a connect message to the proxy. The proxy returns an HTTP 502 proxy error message. The magic comes in here. The browser interprets the returned 502 message within the security context of

So the attack works as follows:

  1. User tries to browse to
  2. Browser sends connect message to evil-proxy.
  3. Evil-proxy sends back a 502 message, with evil-Javascript and opens an iframe to
  4. Evil-proxy lets the request go to and the page loads in the users browser.
  5. Evil-Javascript is now running in the same context as the banking session, so it has full access to page..

With a little more arm bending the paper even goes on to remove the neccessity of full control of an evil proxy, relying on an attacker on the local network sniffing traffic and then racing the valid proxy server..

The findings have been disclosed to the browser vendors and have already been remediated, which means we can collectively breath a sigh of relief, but clearly, it has not been a good year for SSL (and SSL implementations).

Mon, 9 Feb 2009

Vanilla SQL Injection is oh-so-90' 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...


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), 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 (in this case, we'll assume it is 196.310.150.126 )

2 - Add a host entry in hosts, mapping to

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

4 - Fire up a proxy server

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

1 - Intercepts the HTTP request addressed to

2 - Mangles the HTTP request to convert it into a proxied request (ie: Request "GET / HTTP/1.0" now becomes "GET 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


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..