Fixing Java Serialization Bugs with SerialKiller

On Friday, FoxGloveSecurity published a rather inaccurate and misleading blog post on five software vulnerabilities affecting WebLogic, WebSphere, JBoss, Jenkins and OpenNMS. By incorrectly attributing the vulnerability to the Apache Commons Collection library, the blog post generated misinformation on the root cause and possible fixes (e.g. this news.softpedia article).

If you're still unsure on what is the actual issue, Charles Miller published a short blog post illustrating the problem.

Probably thinking that the Apache project wasn't interested in fixing the bug, FoxGloveSecurity's post also contains working exploits for all products.

In fact, even though proof of concept code was released OVER 9 MONTHS AGO, none of the products mentioned in the title of this post have been patched, along with many more. In fact no patch is available for the Java library containing the vulnerability.

As it turned out, some vendors were not aware and others were already working on a patch in their products but haven't released it yet.

Summing up, we're now dealing with five pre-authentication remote code execution vulnerabilities affecting major products. Luckily, the specific services affected by those vulnerabilities are generally not exposed over the Internet thus reducing the overall risk.

Inspired by this story, I started thinking on how I could fix the problem in a systematic way. It didn't take me long to discover this article on using method override to create a look-ahead deserialization filter. While the article explains a potential solution, it didn't provide an easy-to-use library that can be used to protect Java applications.

Introducing SerialKiller

SerialKiller is an easy-to-use look-ahead Java deserialization library to secure applications from untrusted input. You drop the jar in your classpath, use SerialKiller instead of the standard java.io.ObjectInputStream and configure it to allow/block specific classes.

The library, together with a simple tutorial, is available on Github:
https://github.com/ikkisoft/SerialKiller

At the moment, it supports the following features:

• Hot-Reload for the config file, so that you don't need to restart your application after changing SerialKiller's config
• Whitelisting.  If you can quickly identify a list of trusted classes, this is the best way to secure your application. For instance, you could allow classes belonging to your application package only
• Blacklisting. The default config file already includes a few known attack payloads (thanks to YSoSerial). This can be used to block the exploits released by FoxGloveSecurity

If you want to contribute, ping me on Twitter or using Github.

Unofficial security patch for Ubiquiti Networks mFi Controller 2.1.11

On September 3, 2015 SecuriTeam disclosed a vulnerability in the Ubiquiti Networks mFi Controller, a software to configure and control automation devices such as power outlets, light/motion/temperature sensors, etc. To understand the capabilities of the machine-to-machine platform, please have a look at the vendor page.

The security flaw allows an attacker to retrieve the current admin password due to a bypass in the authentication mechanism used by the mFi Controller Server.

Just few hours after the public release of the SSD Advisory – Ubiquiti Networks mFi Controller Server Authentication Bypass, the page was removed to accommodate the vendor's request since a patch was not available for download. According to the advisory and Noam Rathaus's tweet, the vendor was aware of this critical vulnerability since the beginning of July 2015.

Digital Self-Defense

Considering that the advisory published on 09/03/2015 contained a technical description of the vulnerability, including a reliable exploit, it is reasonable to assume that the security flaw can be easily abused by unsophisticated attackers. While the information was removed from the SecuriTeam website and /r/netsec, a quick search on Google is sufficient to find the exploit for this bug.

Despite the public exposure, Ubiquiti has yet to publish a patch.

After waiting patiently for a few weeks, I created my own patch. Using mFiPatchMe, you will be able to easily patch your controller and leave it running without worries.

You can download the Unofficial Security Patch for Ubiquiti Networks mFi Controller 2.1.11 from here: https://github.com/ikkisoft/mFiPatchMe

Disclaimer: This is NOT an official patch provided by Ubiquiti Networks. 

Vulnerability Disclosure: what could that new approach look like?

Few weeks ago, Enno Rey published an interesting reflection around vulnerability disclosure blog post discussing how the industry needs to adjust the “traditional” practices for disclosing software defects to vendors. If you haven't read the post, it’s highly recommended as it exemplifies a genuine experience from someone who has been dealing with vulnerabilities for over a decade.

At the end of the post, Enno is suggesting an open debate asking the community “What could that new approach look like?”

It’s just: what could that new approach look like?

Being a multi-author blog composed by security professionals with different backgrounds, interests and opinions, we decided to provide our input to this important discussion.

Luca Carettoni - @_ikki

If you believe in the vision of building a secure Internet, disclosing vulnerabilities to the vendor is evidently a strong requirement. Since the traditional model of reporting defects “for free” has demonstrated its limitations, it’s important that we build a sustainable ecosystem where security researchers can disclosure vulnerabilities, get a decorous compensation and ultimately hand over the bug to the vendor. Bug bounties and few vulnerability brokers that do not rely on the secrecy of the information (e.g. ZDI) are the incentive for disclosing to the vendor, while alleviating the pain of the process. We need to increase those opportunities by having more programs and higher rewards. Even without outbidding the black market, many researchers will prefer this approach for its ethical implications, resulting in a win-win situation.

If the vendor doesn't care (hey Mary!), digital self-defense in the form of full disclosure is a valid alternative, so that the community can work together on creating mitigations and resilient infrastructure in a timely manner. In these situations, Google's 90-day disclosure deadline is an example of a mechanism used to improve industry response times to security bugs.

Michele Orrù - @antisnatchor

Freedom is the key. I’m tired of regulations and compliance to rules imposed by people who are not even in the security industry.  If I find a bug, I want to have the freedom to do whatever I want with it, for instance:  

• Keep it private and use it during legit penetration tests or red team engagements, then report it to the vendor 12 months later because it’s Unholy Christmas time; 
• Sell it just like a PoC, or sit on it to achieve full RCE and then sell it to some broker;  
• Just go Full Disclosure and publish as a fake persona to cause mayhem;  
• Privately report it to the vendor, helping them fixing it, etc. 

Let's say I find a bug in a (defensive) security product. I would never report it to the vendor unless they pay a (very) good amount of money. There are tons of security product vendors who make millions of dollars selling crap that works so-so and most of the time can be owned remotely, effectively becoming a pivot point in the customer’s network. Why should I help them for free to make even more money silently patching bugs in their systems?

Moreover, the annoying stories of people saying “hey, if you release that 0day, the black market will use it!”, or “hey, isn’t that open source hacking tool very dangerous if used by the wrong people?” can be demystified very easily. In my opinion governments use the black market as a resource, if they really need to, like the Italian government uses Mafia(s) to get intel/help in certain circumstances. Moreover, about open source hacking tools (same as vulnerabilities) being dangerous: how they are used is the key here. In fact I see a certain analogy between OSS hacking tools and 0days. If someone use an OSS hacking tool to own a financial institution and he gets caught, would you blame the developers of the tool or the guy who did the hack? Same thing for a 0day, would you blame who found it, who used it, or the vendor? Would you blame Vitaly for discovering and selling the infamous Flash 0day, HackingTeam who weaponized it to “rule-them-all”, or Adobe for caring so little about security?

Truth is, education and knowledge are the keys. If we will be able to teach the new generation how to write secure code, how to do fuzzing during software development and testing and to never blindly trust input, then we would really increase Internet security. If we continue to go down through the path of ignorance and security by obscurity, chaos is nearer.

Luca De Fulgentis - @_daath

Said that full disclosure may not be that ethical in certain circumstances (remember Gobbles' apache-scalp?), I do neither truly believe in what is named “responsible” disclosure. Being “responsible” implies withstanding ethics that, in turn, implies naming things as “right” or “wrong”. Instead my own experience points me to think in term of what simply “works” rather than limiting choices – such as disclosing a bug – on the basis of a dualistic paradigm.

I never really understood the term “ethics”, especially if applied to the real-(security)world. We live in the dark ages of the Internet of Things where we are observing the rise of “ethical white knights”, which are building their fame and glory stealing someone else code or shitting on enemies (of the Internet, of course). While these useless characters only exist because of the “evil” the are trying to banish – and, hopefully, they will get of out scene now that the evil has been heavily hacked – what really makes me suffer is the term “ethical hacking”.

Ethical hacking’s deliverables are often intended as weapons to fuck up or deceive someone: technology or services providers, colleagues, managers and sometimes even customers. And let me say that out there most of the security firms and related professionals blindly accept this perverse “game”, even if they are claiming to be "ethical" or "white-something" - after all, business is business.

Back to the vulnerability disclosure debate, I’m not in the right position to properly identify a model that works, but let me say that it sounds like a NP-complete problem to be solved, and I think I’m not wrong when I’m saying that it can be compared to other well-know issues afflicting mankind.

So the whole topic could be shifted to a completely different level: we had, have and will always have insurmountable constraints, represented by subjects only interested in money, fame or power, that will always mark both the upper and lower bounds of "improvements" - name it, in example, a safer Internet via a robust vulnerability disclosure model. It's the same as the old plain physical world. It’s all the same, only the names will change.

Using Dharma to rediscover Node.js out-of-band write in UTF8 decoder

A month ago, Node.js released a security update for a bug in V8's utf-8 decoder affecting Buffer to String conversions. Since numerous native functions for networking and I/O are affected, a malicious user could deliver a crafted input to crash a remote Node.js process. A truncated four-bytes sequence can be used to create a misalignment in the WriteUtf16Slow function, resulting in a segmentation fault. For more details on the actual vulnerability, have a look at the V8 patch and the original bug report.

Just after the release of the patch, I started experimenting with this vulnerability to create a proof-of-concept:

Almost around the same time, I noticed that Christoph Diehl from Mozilla published a grammar-based fuzzer named Dharma. The tool parses formal grammar definitions and generates test cases. Although the concept is not new, Mozilla released a neat implementation with great efficiency.

Can we rediscover the same bug using Dharma? 

As an excuse to play with Dharma, I decided to try to replicate the same Buffer vulnerability. In this post, I will guide you through the setup and execution.

First, we need to create a grammar to define Node's Buffer functions. From the official API doc, I started classifying all APIs in three categories: definitions, permutations (from Buffer to Buffer) and operations (from Buffer to other types).

Based on this model, all test cases will resemble the following template:

The resulting buffer.dg grammar has been merged in the official Github repository.

With Dharma, we can now generate test cases with a simple command:

At this point, we just need to execute our test cases and wait for the results. After trying a few different solutions, I ended up using a very simple bash script:

After leaving the fuzzer alone for the night, I came back in the morning to discover a multitude of core dumps. Hidden among thousands of V8::FatalProcessOutOfMemory and SIGILL Illegal instruction errors, I finally discovered a sample that was triggering something interesting.

Looking at the backtrace,  we can confirm that we're triggering the same vulnerability. If you're interested, I've uploaded the auto-generated test case.

Now what?!

Node.js Buffer provides a very powerful API with raw memory allocation capabilities. Ilja van Sprundel outlined some of the risks during a recent webcast, and the latest vulnerability was a clear demonstration of the possible outcomes. Having already spent a few hours on building the grammar, I expanded this little fuzzing exercise with the goal of discovering similar vulnerabilities. After a few days of generation/execution and over 400,000 test cases, I have yet to triggered another segmentation fault in Node.js' Buffer. Although this exercise doesn't give us a definitive assurance, it is probably a good sign of the maturity of the API. Nonetheless, grammar-based fuzzing is fun and can lead to interesting results.

Adopt OSS. A new initiative by OWASP Italy.

NibbleSec blog is a place for neat vulnerabilities, new security research and (hopefully) food for thought. In today's post, I want to take the opportunity to promote a new initiative by OWASP Italy.

Adopt OSS

In the wake of the Snowden revelations and recent OpenSSL vulnerabilities, ensuring the security of the technology that powers our daily life is vital for individuals’ security and privacy on the Internet. Despite the collaborative and transparent nature of open source software, security flaws are still frequently discovered in popular applications.

Given OWASP’s mission to help organizations with application security, the Italian Chapter of OWASP has established a new initiative to provide free, voluntary based support to open source software projects. By building together open, free and secure systems, we can promote innovation and help building better software, resilient to modern threats.

Thanks to Adopt OSS​, security enthusiasts are paired with participating open source projects, thus gaining exposure to real-­life security engineering challenges and the opportunity for career growth. In turn, the participating projects are able to obtain free professional expertise to better improve their security posture, and ultimately build secure software. Examples of activities include, but are not limited to, thread modeling, performing security assessments, testing security patches, writing documentation on security topics, improving SDLC and vulnerability disclosure practices.

Over a six months period​, OWASP Italy will facilitate the effort by coordinating the initiative and providing support when needed. The first edition of this initiative will take place between May and November 2015. At the end of the six months period, OWASP Italy will publish results and feedback from both volunteers and OSS maintainers.

Many OpenSource projects need help, and hopefully more security enthusiasts will contribute and create similar initiatives. If you have time to complain about something, then you have the time to do something about it.

For more details, please refer to: https://www.owasp.org/index.php/Italy#Adopt_OSS._First_Edition

CVE-2011-2461 is back - FAQ

After our presentation at Troopers 2015, we have received numerous replies in the form of comments on Slashdot, Reddit or emails. In this post, we want to provide more details and clarify some points.

Q: What's the exploit vector here?
A: We've now released all details of an actual attack flow. Please refer to the "Exploiting CVE-2011-2461 on Google.com" blog post to understand the nature of the attack. This should give sufficient technical details on how this vulnerability can be exploited.

Q: Patching all vulnerable SWF files isn't a realistic solution, is it?
A: Unless Adobe introduces an additional check in the player, we don't have many options.

Q: Why doesn't Adobe patch the Flash player?
A: The bug affects Adobe (now Apache) Flex SDK. As a result, it was properly corrected in the compiler. Having said that, Adobe could probably implement a check in the Flash player itself in order to mitigate this issue. Considering that vulnerable SWF files need to be recompiled or patched, it would be beneficial to have a solution that can be easily deployed by Internet users.

Q: I'd love to patch my hazardous SWF files, but the link on Adobe website goes to an error 404. Where can I find this file?
A: Fail. We notified Adobe last week and they have now restored the tool page. Last time we checked, the official patch tool was available for download. Alternatively, it is possible to recompile the entire SWF with a new version of the Flex SDK.

Q: Can you publish more details around the number of vulnerable sites/files?
A: Considering that we've enumerated all SWF files using search engine results only, our numbers may not be accurate and are certainly influenced by numerous factors. As mentioned, 3 out of the Top 10 Alexa sites were hosting at least one vulnerable SWF file. We're interested in collecting metrics around this bug, so please let us know if you have performed extensive scans using ParrotNG.

Q: Where can I find a vulnerable SWF file to test my detection tool?
A: We've created a vulnerable HelloWorld Flex app compiled with an old version of the Flex SDK. You can download the SWF test cases archive, which includes a vulnerable and a non-vulnerable version of the same file.

Brought to you by Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)

The old is new, again. CVE-2011-2461 is back!

Overview

As part of an ongoing investigation on Adobe Flash SOP bypass techniques, we identified a vulnerability affecting old releases of the Adobe Flex SDK compiler. Further investigation traced the issue back to a known vulnerability (CVE-2011-2461), already patched by Adobe in apsb11-25.

Old vulnerability, bad luck, let's move on. Not this time.

The particularity of CVE-2011-2461 is that vulnerable Flex applications have to be recompiled or patched; even with the most recent Flash player, vulnerable Flex applications can be exploited. As long as the SWF file was compiled with a vulnerable Flex SDK, attackers can still use this vulnerability against the latest web browsers and Flash plugin.

As soon as we understood the potential risk, we conducted a large-scale analysis by locating SWFs hosted on popular websites and analyzing those files with a custom tool capable of detecting vulnerable code patterns. This research has led to the identification of numerous websites vulnerable to CVE-2011-2461, including 3 sites out of the Alexa Top 10.

Disclosure

We're back to the hotel after another amazing day at Troopers 2015, where we presented the results of our research. The information provided in this blog post, together with the slides of the conference (download from here), should be sufficient to detect and mitigate the risk. As soon as we feel that there is a general understanding of this flaw we will be publishing more details, including a real exploitation scenario.

The old is new, again. CVE-2011-2461 is back! from ikkisoft

During the past months, we've done our best to privately disclose this issue to some of the largest websites, but we won't be able to reach a broader audience without publicly releasing the technical details. As suggested by the many vulnerable applications that we've encountered, it is clear that CVE-2011-2461 did not raise the adequate level of attention back in 2011. By explaining the potential impact and releasing a tool capable of identifying vulnerable SWF files, we hope to contribute towards eradicating this issue.

Impact

This vulnerability allows attackers to steal victims' data (via Same-Origin Request Forgery), or perform actions on behalf of the victim (via Cross-Site Request Forgery), by asking them to visit a malicious web page. Practically speaking, it is possible to force the affected Flash movies to perform Same-Origin requests and return the responses back to the attacker. Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user's data.

Summarizing, hosting vulnerable SWF files leads to an "indirect" Same-Origin-Policy bypass in fully patched web browsers and plugins.

Vulnerable Component

Starting from Flex version 3, Adobe introduced runtime localizations. A new component in the Flex framework — the ResourceManager — allows access to localized resources at runtime. Any components that extend UIComponent, Formatter, or Validator have a ResourceManager property, which allows the SWF file to access the singleton instance of the resource manager. By using this new functionality, users can pass localization resources via a resourceModuleURLs FlashVar, instead of embedding all resources within the main SWF.

In practice, Flex applications compiled with SDK >= 3 support the following resource loading mechanism:

In Adobe Flex SDK between 3.x and 4.5.1, compiled SWF files do not properly validate the security domain of the resource module, leading to Same-Origin requests and potentially Flash XSS (in older versions of the Flash player). A detailed root cause analysis is included in our slides deck.

Identifying vulnerable SWF files with ParrotNG

ParrotNG is a Java-based tool for automatically identifying vulnerable SWF files, built on top of swfdump. One JAR, two flavors: command line tool and Burp Pro Passive Scanner Plugin.

Download the tool from https://github.com/ikkisoft/ParrotNG/

ParrotNG Burp Pro Plugin

ParrotNG Command Line

To use the command-line version, simply execute the following:

$ java -jar parrotng_v0.2.jar <SWF File | Directory>

To use ParrotNG Burp Pro Plugin, load parrotng_v0.2.jar from Burp's Extender Tab-->Add as a standard Java extension. With Passive Scanner enabled, all SWF files passing through Burp Suite are automatically analyzed. For more details, please refer to Burp's official documentation.

There are still many more websites that are hosting vulnerable SWF files out there. Please help us making the Internet a safer place by reporting vulnerable files to the respective website's owners.

Mitigations

After having identified all Flex SWF files compiled with a vulnerable version of the Adobe Flex SDK, there are three possibilities:

• Recompile them with the latest Apache Flex SDK, including static libraries;
• Patch them with the official Adobe patch tool, as illustrated here. This seems to be sufficiently reliable, at least in our experience;
• Delete them, if not used anymore.

Brought to you by Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)