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 https://mybank.com. 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 https://mybank.com.
So the attack works as follows:
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).
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..)
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  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"
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://188.8.131.52/ 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...
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..
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..