Pwnpress Themes

Cross Application Scripting Demo / URI Vulnerabilities Demo (Picasa 0-day)

by: Nate McFeters - nate dot mcfeters AT gmail
Billy (BK) Rios - billy dot rios AT gmail
Rob Carter - cartrel AT gmail
Raghav "the Pope" Dube

We've posted a snippet of some of the research we've done on Cross Application Scripting and URI exploitation..It's time we showed another example of how dangerous these URI handler vulnerabilities can be... This example really highlights the functionality abuse that Billy and I have been talking about. A compilation of our exploit code can be found here. Fixing it up for an individuals server setup is left as an exercise to the reader.

THANKS TO ROB CARTER for the huge contribution on this code!

The Gory Details:

  • This attack can be initiated through XSS (especially dangerous for social networking sites like YouTube or MySpace).
  • User is XSS'd and the exposure loads a Picasa button file, button.pbf, which is represneted in XML code. The code for the button.pbf file might look something like the following:

    <?xml version="1.0" encoding="utf-8" ?>
    <buttons format="1" version="1">
          <button id="custombutton/blah" type="dynamic">
             <icon name="outputlayout/poster_icon" src="runtime"/>
             <label>Critical Security Update</label>
                Click Here to get a Critical Security Update for Picasa!
             <action verb="hybrid">
                <param name="url" value=""/>

    This is illustrated in the screenshot below, which shows the imported button.

    Screenshot 1:

  • The user clicks the button we've loaded and Picasa sends the local URLs of the users images to our remote Python CGI Script, This is illustrated in the screenshot below which shows the body of the POST request that Picasa's built-in web browser object sends to our server.

    Screenshot 2:

  • Our CGI script process the XML sent by Picasa and loads an HTML page that loads a Flash object back to the victim. This is illustrated in the screenshot below, which shows the flash loading in the context of the victim's browser. In this case, the Flash is quite obvious and we've masked it only by titling the loading page "Critical Security Updates" and showing a progress bar. Obviously this approach could be extended nicely to really convince the victim this is legit.

    Screenshot 3:

  • The flash actionscript provides a small timeout for us while we change our DNS record to point to, thus causing a DNS rebind
  • The flash actionscript makes calls to the site we loaded it from (which now points to and downloads the bit streams of the user's images into URLLoader objects.
  • The flash actionscript loads a cross domain policy file from another server in our control allowing it to upload the images to a remote server. The following screenshot illustrates all of the output of our Flash actionscript to the screen. Again, keep in mind, we could do this in a very convincing fashion if we chose to do so; however, in this case it is far easier to understand what is going on with the details displayed to the screen.

    Screenshot 4:

  • Our remote server has a Perl script listening to catch images and save them to disk. The screenshot below illustrates the simple perl script waiting to capture incoming images to the disk.

    Screenshot 5:

  • The attacker can view the results of the stolen images using the admin.php script. This php script has a directory indexing of captured images (see Screenshot 6) and the ability to display the stolen images (see Screenshot 7).

    Screenshot 6:

    Screenshot 7