A little introduction:
I was cruising a regular forum when someone posted a new toolbar that's supposed to automatically deposit money for you, in an text-based RPG game. So, people were posting about how they thought it was some kind of "bot" and etc. I decided to take a look at it myself and see what I could find.
What it appeared to be was a simple toolbar. However, it did some very strange and interesting things. First, it set a couple cookies in my requests. Some were rather interesting, while one made me laugh as it made itself clear as day to anyone who can look at a cookie. This value was UNIQUELOGINHIJACK. Then it tried to use the Myspace email to send out spam messages. However, the most interesting part was how it tried to get me to download a fully hijacked browser. It identified itself as Firefox 3.0.7, as my current browser was 3.0.5. The unique part was that it tried to pull this new hijacked browser everytime FireFox checked for updates. Every time an update check was called, the request for the new "updated" browser was called. What's interesting about this is most browsers, when they start, will automatically check for updates and this link will also try and get you to download it. Think of those people who don't know about how FireFox does its updates and installs this piece of spamware.
Suffice to say, after I gave my analysis on the forum, the post was deleted a couple minutes later.
Thursday, August 6, 2009
Saturday, May 30, 2009
Modifying content in HTTPS
I know I haven't updated in a while, but I'm here again to share my information with whoever wants it. This time, it's not something personal that I've discovered or an experience of my own.
Instead, I've recently read a paper published by Microsoft that really got me thinking about other possibilities that I'm going to be testing out and having fun with in the near future. The paper, written with malicious proxies in mind, points out browser flaws in handling certain events with HTTPS and intriguing research on modifying HTTPS content.
Personally, there was this one very inspiring technique that is rather easy to perform and something I'd consider dangerous. This was when a site such as https://bank.com/login.php calls for off-site file(s) or file(s) from their sub-domain, an example being a javascript file from https://scripts.bank.com/script.js. Now what happens is the person sends a request for https://bank.com, which also sends a request for https://scripts.bank.com/script.js, and the attacker sends back a 302 redirect to a different https script instead of https://scripts.bank.com/script.js. An easier to follow example:
A.) Victim sends request for https://bank.com/login.php
B.) https://bank.com/login.php calls script from https://scripts.bank.com/script.js
C.) Attacker does not return requested content, instead it returns a 302 redirect for https://script.bank.com/script.js which points to https://evil.com/script.js
D.) Now the attacker's script is loaded in the context of https://bank.com/login.php which means the attacker has access over the client-side content of the site and can use DOM manipulation to modify that client-side content.
The paper has other great new ideas that makes it completely worth the read. It also has other old ideas such as stealing cookies, of an https site, that do not have the secure bit set by modifying a page to put a hidden iframe that points to that same site, but over a regular http session. It is truly an inspiring paper that is on the path of deeper problems within how our browsers handle HTTPS sessions.
Paper located at: http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf
Presentation slides at: http://research.microsoft.com/pubs/79323/PBP-oakland-public.ppt
Instead, I've recently read a paper published by Microsoft that really got me thinking about other possibilities that I'm going to be testing out and having fun with in the near future. The paper, written with malicious proxies in mind, points out browser flaws in handling certain events with HTTPS and intriguing research on modifying HTTPS content.
Personally, there was this one very inspiring technique that is rather easy to perform and something I'd consider dangerous. This was when a site such as https://bank.com/login.php calls for off-site file(s) or file(s) from their sub-domain, an example being a javascript file from https://scripts.bank.com/script.js. Now what happens is the person sends a request for https://bank.com, which also sends a request for https://scripts.bank.com/script.js, and the attacker sends back a 302 redirect to a different https script instead of https://scripts.bank.com/script.js. An easier to follow example:
A.) Victim sends request for https://bank.com/login.php
B.) https://bank.com/login.php calls script from https://scripts.bank.com/script.js
C.) Attacker does not return requested content, instead it returns a 302 redirect for https://script.bank.com/script.js which points to https://evil.com/script.js
D.) Now the attacker's script is loaded in the context of https://bank.com/login.php which means the attacker has access over the client-side content of the site and can use DOM manipulation to modify that client-side content.
The paper has other great new ideas that makes it completely worth the read. It also has other old ideas such as stealing cookies, of an https site, that do not have the secure bit set by modifying a page to put a hidden iframe that points to that same site, but over a regular http session. It is truly an inspiring paper that is on the path of deeper problems within how our browsers handle HTTPS sessions.
Paper located at: http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf
Presentation slides at: http://research.microsoft.com/pubs/79323/PBP-oakland-public.ppt
Subscribe to:
Posts (Atom)
