Re: penproxy accessing javascript?

[Rogan Dawes <discard () dawes za net>]

Mads Rasmussen wrote:

> Rogan Dawes wrote:
>
> > My personal preference would be to script a modification to the 
> > javascript itself that is executed in the browser, to expose the keys 
> > to you in some appropriate way. For example, when we receive a request 
> > for "crypto.js", rather than fetching it from the server, fetch a 
> > modified version from the filesystem, and return it to the browser.
>
>
> Hmm if the javascript is inlined in the html you would have to 
> substitute the html page. 

True. Or if you can programmatically script the substitution, that would 
also be an option. e.g. using HTMLParser to isolate the script elements, 
and replace just the script with a pre-hacked fragment.

> So you are saying you could intercept the 
> browsers request for the page and then enter with your own that would 
> expose the variables in question?

I would catch the browser's request for the page containing the script, 
and replace the script with a version that exposes the required 
information somehow. e.g. hook into an onSubmit trigger to append the 
key variable to the request URL.

That may include sending the unmodified request to the server and 
modifying the specific response that I get back, if the page is a 
dynamic one.

It would obviously be very dependent on the page/site, etc, and 
consequently very fragile, but it would probably work for a proof of 
concept.

> That could work when pentesting however my concern is that someone 
> develops a trojan to intercept the javascript for a specific page. 

It is obviously important to realise that an intercepting proxy approach 
cannot solve the SSL certificate question (i.e. this certificate does 
not match). However, a browser helper object approach would be able to 
get the necessary information, and would not even necessarily need to 
interpret the script itself, if it has a handle into the browser's 
session/state. c.f. the recent trojan that was snarfing SSL'ed passwords 
and posting them to some site.

> When 
> it sees the page it will expose the values stored in the javascript 
> variables and send them via ftp or email or something.
> Thats why I wanted to know if something doing that existed to measure 
> the risk of someone mounting such an attack.

I'd say that the risk of doing that is far greater for a BHO than an 
intrecepting proxy.

However, as a proof of concept at the time of the "IE accepts invalid 
SSL certificate if the first link is an image", I intercepted the HTTP 
request to a site's homepage, inserted a link to a bogus 
https/url/image, and consequently managed to intercept all SSL requests 
to that site without causing any alarm to the user.

If you are intercepting a non-SSL connection, you can do virtually 
anything you like, including replacing the wonderful secure algorithm 
with one that simply sends you the parameters that you need in the first 
place.

e.g. site X reckons that they don't need SSL, because they are using 
Secure Remote Password, with some javascript and an applet for 
generating the random numbers. It would be trivial for an intercepting 
proxy to send some script that provides the same interface that the 
calling HTML expects, but simply sends the username and password in 
clear instead, while the proxy performs the required calculations based 
on the provided information.

> Regards,
>
> Mads

Ciao,

Rogan
--
Rogan Dawes

*ALL* messages to discard () dawes za net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"