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

January 14 2013


Anti-debugging techniques and Burp Suite


No matter how good a Java obfuscator is, the bytecode can still be analyzed and partially decompiled. Also, using a debugger, it is possible to dynamically observe the application behavior at runtime making reverse engineering much easier. For this reason, developers often use routines to programmatically detect the execution under a debugger in order to prevent easy access to application's internals. Unfortunately, these techniques can be also extremely annoying for people with good intents.


Burp Suite

Over the course of the years, starting from the very first release, I have been an enthusiastic supporter of Burp Suite. Not only @PortSwigger was able to create an amazing tool, but he also built a strong community that welcome each release as a big event. He has also been friendly and open to receive feedback from us, ready to implement suggested features. Hopefully, he won't change his attitude now.

Since a few releases, both Burp Suite Free and Pro cannot be executed under a debugger. Unfortunately, this is a severe limitation - especially considering the latest Extensibility API.  The new extensibility framework is a game-changer: it is now possible to fully integrate custom extensions in our favorite tool. But, how to properly debug extensions in an IDE? Troubleshooting fairly complex extensions (e.g. Blazer) requires lot of debugging. Setting breakpoints, stepping in and out of methods, ... are must-have operations.

Inspired by necessity, I spent a few hours to review the anti-debugging mechanism used in Burp Suite Free. According to Burp's EULA (Free Edition), reversing does not seem to be illegal as long as it is "essential for the purpose of achieving inter-operability". Not to facilitate any illegal activity, this post will discuss details related to the Free edition only.  
Disclaimer: Don't be a fool, be cool. If you use Burp Pro, you must have a valid license.


Automatic detection of a debugger

In Java, it is possible to enable remote debugging with the following options:

-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n 

and attach a debugger with:

 jdb --attach [host]:8000

A common technique to programmatically understand if a program is running under a debugger involves checking the input arguments passed to the Java Virtual Machine. The following is the pseudo-code of a very common technique:
 for(ManagementFactory.getRuntimeMXBean().getInputArguments() ...){
                if(Argument.contains("-Xdebug") || Argument.contains("-agentlib") ...){
                   // Do something annoying for the user
In practice, ManagementFactory returns the managed bean for the runtime system of the current Java Virtual Machine that can be used to retrieve the execution arguments (see RuntimeMXBean API for further details). In case of Burp Free, the application gets shutdown via a System.exit(0);


Bypass techniques, an incomplete list

First of all, it is always possible to attach the debugger once the Java process is already up and running. Any check performed during the application startup won't block the execution:   

jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=[Process ID]

Unfortunately, this is a read-only mechanism and cannot be used within traditional IDEs. A few better solutions require tweaking the application in order to modify the program execution. This can be achieved via static changes in the .class files or using static/dynamic bytecode instrumentation. The code above is pretty simple and can be bypassed in several ways:
  • Using ClassEditor, reJ or any other tool that allow .class manipulation, it is just necessary to identify all strings in the constant pool used during the string comparison within the if-statement. For instance, you could replace all strings with a bunch of "a" so that the program won't even enter in the if-statement body
Manually changing the Constant Pool of a .class file

  •  An even more portable solution, especially when strings obfuscation is used, consist of editing the bytecode using JavaAssist or similar libraries. This allows to write a piece of code that search a class and patch it:
    • For instance, we could force the getInputArguments() to return an empty List;
    • Or, we could insert an arbitrary unconditional jump jsr to skip the program shutdown;
    • Or again, it is possible to override the System.exit() method with a local method using an empty body. First, we need to create a fake static exit(int) method. Then, we replace System.exit() with the custom method within our class.
Using JavaAssist to replace an existent method within a Class

Patching Burp Free for debugging your custom extensions

With the honest intent to simplify the life of coders writing custom Burp's extensions, I have developed a small utility (BurpPatchMe) to patch your own copy of Burp Free - which will allow you to debug your code in NetBeans, Eclipse, etc.
    A few important details:
    • BurpPatchMe works for Burp Suite Free only. I have included a specific check for it as well as I have used a technique compatible with that release only. Again, you won't be able to remove debugging in Burp Suite Pro using this tool. Go and buy your own copy of this amazing tool!
    • BurpPatchMe is compiled without debugging info and it has been obfuscated too. A quick skiddie prevention mechanism to avoid abuses
    • BurpPatchMe does not contain any Burp's code, library or resource. It is your own responsability to accept the EULA agreement and its conditions, before downloading Burp Free. Also, this tool is provided as it is - please do not send emails/comments asking for "features"
    • Java JDK is required in order to use this tool. All other dependencies are included within the jar
You can download BurpPatchMe here and launch it with:
$ java -jar BurpPatchMe.jar -file burpsuite_free_v1.5.jar   
 Long life Burp Suite and happy extensions!

December 31 2012


UI Redressing Mayhem: Identification Attacks and UI Redressing on Google Chrome

Today I'm going to disclose a series of UI Redressing issues that could be exploited in order to extract information that may help an attacker to identify a victim-user whenever anonymity is a critical requirement. Moreover, a new extraction method, which has been successfully applied against Google Chrome, will be presented. Google's web browser disallows cross-origin drag&drop and what I'm introducing here is a completely different approach to achieve the extraction of potentially sensitive data.

Identification Attacks

I found that several world-renowned web applications lack protection of web resources from UI Redressing attacks, thus revealing data that can be abused to disclose a user's identity. An identification attack could be successfully performed by exploiting a UI Redressing flaw affecting web resources that include, for example, the name or the e-mail address of the victim.

A series of vulnerabilities are presented below in order to exemplify some of these attacks. The first issue affects a Google's web application: an authenticated Google user can be attacked by abusing a UI Redressing vulnerability related to the support.google.com domain. As shown in Figure 1, no X-Frame-Options header is adopted, thus allowing the cross-domain extraction of personal data such as:
  • Victim's e-mail address;
  • Victim's first and last name;
  • Victim's profile picture URL.
Figure 1 - Google Support vulnerable to UI redressing attacks.
A Proof of Concept exploit can be downloaded here. The following is a video demonstrating the attack:

Similar vulnerabilities have been found on other popular web applications. The following is a list of identified vulnerable web resources, exposing user's data:

Microsoft Profile (First name, last name, e-mail address, etc - Figure 2)
Figure 2 - Microsoft Profile web resource vulnerable to UI Redressing attacks.
Yahoo! (e-mail address, first name, birth date, sex, etc - Figure 3):
Figure 3 - Yahoo! web resource vulnerable to UI Redressing attacks.


Beyond the iframe-to-iframe extraction method

The Google Chrome web browser seems to have defeated any extraction methods, denying the use of the view-source handler and disallowing cross-origin drag&drop. Despite these adverse conditions, I identified some attack scenarios where a UI Redressing issue could be still performed in order to extract sensitive data. Once again, the method is extremely simple. Instead of a cross-origin drag&drop, the victim is tricked to perform a same-origin action, where the dragged content belongs to a vulnerable web page of the targeted application and the "dropper" is a form (text area, input text field, etc.) located on the same domain. Using a site's functionality that allows publishing externally-facing content, it is still possible to extract information. Under these circumstances, Chrome will not reasonably deny the same-origin drag&drop, thus inducing the victim to involuntary publish sensitive data. As a matter of fact, the attacker is exploiting a subsequent clickjacking vulnerability on the same domain, which causes the publication of the personal information. I refer to this kind of attack chain as a "bridge" that allows the attacker to move sensitive data from being private to public, while remaining on the same domain. Then, the attacker can simply access the (now) public information to obtain the extracted data. It should be outlined that the technique requires two vulnerabilities: a web resources that is not protected by the X-Frame-Options (or uses a weak frame-busting code) and a site's functionality that is affected by clickjacking.

The following list summarizes a series of functionalities that could be abused to extract the sensitive data:
  • Forum's post mechanism;
  • "comment this item" functionalities;
  • Public profile information updating function (or any "update function" that involves public available data - e.g. administrative functions that cause the updating of the web site's content);
  • Messaging functionalities (e.g. from the victim to the attacker);
The proposed method has been successfully applied against Google Chrome version 23.0.1271.97, targeting the Amazon web application. Amazon exposes a series of web resources that include user's data - such as the name, e-mail address, mobile number and "address book" details - that are not protected with both X-Frame-Options header or any frame-busting mechanism. As an example, the following vulnerable URL includes Amazon's user first name, last name and e-mail address:
A second issue on the comment function - our "bridge" - can be abused to publish the user's information as a comment for an Amazon item (e.g. a book), previously known by the attacker, and whose comments are "monitored". The following steps summarize the exploitation phases:
  1. The exploit frames both the vulnerable URL and the comment form of a attacker-chosen Amazon's book;
  2. The victim is triggered to drag his data and drop the information to the framed comment form;
  3. A clickjacking attack is then performed against the "Post" mechanism, in order to publish the dropped data;
  4. At that point the attacker can access all personal details by simply visualizing the submitted comment of the Amazon's item.
The exploit code can be download here, while the following is a video of the described attack:

December 19 2012


UI Redressing Mayhem: HttpOnly bypass PayPwn style

In the previous post, a new cross-domain extraction method - affecting the latest version of the Mozilla Firefox browser - has been presented. The iframe-to-iframe technique was successfully used in a UI Redressing attack affecting LinkedIn. Today, I'm introducing an instance of the aforementioned method that involves a known Apache Web Server security issue, in order to steal session cookies that are protected by HttpOnly flag, thus allowing the attacker to perform Session Hijacking attacks. A new attack targeting PayPal systems will be also presented.

CVE-2012-0053: HttpOnly bypass and beyond

In January 2012 - even if the Apache defect was known and exploited for a while - Norman Hippert disclosed CVE-2012-0053 bug affecting the Apache Web Server. The software was not able to correctly restrict an header field information disclosure in case of overlong or malformed HTTP requests. The vulnerability could be effectively combined with a Cross-Site Scripting attack to bypass the protection mechanism introduced by the HttpOnly flag and steal any session token stored as cookies value. Infact, an XSS vector could manipulate the document.cookie object to set an overlong cookie field, and forward a malformed request to the affected Apache Web Server with the intention to trigger the error message and extract the desiderated session cookies. The Apache bug can be abused in a series of attack scenarios such as the following:
  • Bypassing HttpOnly flag with a XSS vulnerability on the same domain that is affected by the CVE-2012-0053;
  • Bypassing the limitation introduced by cookie path whereas the XSS vulnerability affects a web resources that resides outside the defined path itself;
  • Bypassing HttpOnly flag if a XSS vulnerability is found on any subdomains of the host that is affected by the Apache disclosure issue, if exploited in conjunction with a UI Redressing attack - that allows the cross-domain content extraction of the information included in the triggered Apache error message.
    It should also be noted that the Apache Web Server is often used as a reverse proxy configuration. As a result, any session object on any server-side technology, could be attacked with the described vectors.

    Smashing PayPal for Fun but.. NO Profit


    During my security research on UI Redressing attacks I found multiple PayPal subdomains (e.g. https://b.stats.paypal.com) affected by the Apache disclosure bug as detailed in Figure 1 and Figure 2.

    Figure 1 - HTTP request with the overlong cookie. Figure 2 - Apache error message with the disclosure of the malformed Cookie header.
    Despite in the first instance the bug could appear as useless, I found that the PayPal application - www.paypal.com - delivers the session cookies defining the domain to .paypal.com (Figure 3 and Figure 4).

    Figure 3 - Post-authentication cookies delivery.
    Figure 4 - Cookies delivered to the personal.paypal.com subdomain.

    The highlighted security issues could be abused to attack authenticated PayPal users, implementing the mentioned UI Redressing attacks combined with the cookie disclosure bug. But.. I had a problem: I had no XSS vulnerability on any PayPal web application - not that there're not! I was able to circumnavigate the limitation identifying another vulnerability on a different PayPal subdomain, that allowed me to define a monster cookie with a single HTTP request. As first, please note the following URL:
    As detailed in Figure 5, the navigation of the above URL involves the setting of the cookie named navcmd and then a bit of client-side black magic defines two new cookie fields named s_sess and s_pers (Figure 6) that complete the desiderated malformed HTTP request.

    Figure 5 - Cookie defined with attacker-controlled input.
    Figure 6 - Final monster cookie.



    The exploitation is now trivial. The following are the logical steps implemented by the Proof of Concept exploit:
    1. The exploit triggers the victim to open an under pop (Figure 7) web page that generates the monster cookie - with domain=.paypal.com - involving the history.paypal.com application;
    2. The https://b.stats.paypal.com is then framed thus inducing the forward of a malformed HTTP request that triggers the disclosure of the Cookie header, containing the PayPal account's session cookies;
  • The malicious page allows the victim to play the d&d game with the extraction of the secret session cookies.

  • Figure 7 - Pop-under page with the navigation of the monster cookie's generation URL.

    The attacker now holds the cookies that can be used to perform a Session Hijacking attack against the victim's PayPal account. A working Proof of Concept has been developed and can be download here. The following is a video that illustrates the described attack:

    December 18 2012


    UI Redressing Mayhem: Firefox 0day and the LeakedIn affair

    In the past weeks I worked on UI Redressing exploitation methods. The UI Redressing Mayhem series is going to illustrate the results of my research, presenting 0day exploiting techniques and several vulnerabilities that involve high-profile web applications. Each post of the series will also provide detailed information about the vulnerabilities and techniques, together with working Proof-of-Concept exploits.

    The following article will detail a previously unknown Mozilla Firefox  vulnerability that affects the latest version (v.17.0.1) of the Mozilla web browser and allows malicious users to perform cross-domain extraction of sensitive data via UI Redressing vectors.

    It was a dark and stormy night...

    My security research on UI Redressing exploitation techniques grounds its roots in a web application penetration test where I was asked to exploit a UI Redressing bug with the explicit constraints to target Mozilla Firefox users. My objective was to achieve the cross-domain content extraction of an anti-CSRF token, in order to trigger the update of the victim's profile e-mail address: the powerful double drag&drop method was found to be appropriate in that context. To the best of my knowledge, the method was first introduced by Ahamed Nafeez and is based on the possibility to perform a drag&drop action between a framed web page, which displays the "sensitive" contents and is not protected by the X-Frame-Options header, and the framing page (the "dropper" page), which receives and stores the extracted content. The view-source handler is used here to bypass any framebusting code.

    The main problem with my exploit development, during the penetration test, was that the drag&drop method was recently killed by Mozilla. An interesting solution to the Mozilla fix is the fake CAPTCHA method that was introduced by Krzysztof Kotowicz — and demonstrated to be effective against Facebook and Google eBookstore — but I chose the hard way and tried to bring the drag&drop method back to the masses: so please welcome the iframe-to-iframe cross-domain extraction method.

    The iframe-to-iframe extraction method

    The extraction method is extremely simple: instead of performing a drag&drop action of sensitive data, from a framed vulnerable web page to the framing one (attacker-controlled), the victim is tricked to visit a malicious html page that includes two iframes: the vulnerable page - where the sensitive content resides - and another attacker's page that is used to drop the extracted content (Figure 1). Firefox is not able to block this kind of attack because no check on cross-domain drag&drop between iframes is performed. As mentioned before, the method was tested against Mozilla Firefox version 17.0.1 - the latest stable release at the time of writing. The iframe-to-iframe technique was also tested against Google Chrome but the browser has been proved robust to the proposed attack.
    Figure 1 - iframe-to-iframe d&d extraction method. The iframe-to-iframe method re-introduces the possibility to abuse the Firefox drag&drop mechanism to perform a cross-domain data extraction. Let me now introduce an high-profile vulnerability and attack that targets the LinkedIn application implementing the proposed method.

    All your LinkedIn accounts are belong to us

    LinkedIn implements a stateless anti-CSRF mechanism that associates tokens to the HTTP requests that result in a change of the remote application state, such as the update of a user's profile information (e.g. job title or the login e-mail address). A stateless anti-CSRF method is generally based on a secret token, delivered as a cookie parameter, and a token which is included in every state-changing HTTP request: the remote web application considers as genuine exclusively the HTTP requests that have the same token value for both the cookie and HTTP parameter. Otherwise, a request is considered untrusted and it is not computed. The LinkedIn's anti-CSRF mechanism involves a cookie parameter called JSESSIONID and an HTTP parameter named csrfToken in order to store the secret tokens (Figure 2). A stateless mechanism can be easily bypassed with well known web hacking techniques.
    Figure 2 - anti-CSRF tokens. For example, the attacker could abuse a Cross-Site Scripting issue on both www.linkedin.com or any LinkedIn's subdomains to poison the cookie parameter JSESSIONID and bypass the mechanism — this attack is also known as Cookie Tossing. During my security research I found a vulnerable LinkedIn's page that includes the anti-CSRF token within the HTML code, despite not being protected by the X-Frame-Options header. Under these circumstances, the iframe-to-iframe method can be used to attack authenticated LinkedIn users and steal their secret token in order to perform different kind of malicious actions on the victim's profile. The following URL refers to the LinkedIn vulnerable web resource as detailed in Figure 3:

    Figure 3 - Vulnerable LinkedIn web resource.
    The vulnerability can be easily abused to craft a UI Redressing exploit that triggers the victim to drag&drop the anti-CSRF token. The token can then be abused to edit any information on the victim's profile and even to reset the account password. In order to demonstrate the effectiveness of the attack I developed a fully working Proof of Concept exploit that adds the attacker's e-mail as a trusted address to the victim's profile and verifies the e-mail itself. At that point, the attacker can easily reset the victim's password using LinkedIn password reset mechanism.

    The following are the logical steps implemented by the Proof of Concept exploit:
    1. The malicious page frames both the LinkedIn vulnerable page and the attacker-controlled "dropper" page;
    2. The malicious page allows the victim to play the d&d game, which extracts the anti-CSRF token;
    3. The malicious page can now bypass the anti-CSRF protection and adds a new e-mail address to the victim's profile. The action involves the forwarding of a confirmation e-mail from LinkedIn system to the attacker box: an activation URL is included;
    4. The exploit interacts with an attacker's script — /linkedin/linkedin.php — which accesses the attacker's mail box via IMAP and waits for the Linkedin activation e-mail. Once obtained the e-mail, the URL is returned back to the malicious page, which is still loaded by victim's web browser;
    5. The script can now simulate the navigation of the fetched URL in order to confirm the new address.
    The attacker can now reset the victim's account password abusing the password reset functionality, where he will type the e-mail address previously added to the targeted profile. Figure 4 highlights the different HTTP requests exchanged between the attacked web browser, the attacker's servers and the LinkedIn web application, in order to achieve the password resetting.
    Figure 4 - Sequence diagram detailing the attack. A working PoC has been developed and can be downloaded here. The following is a video of the attack:


    Beyond the Mayhem

    LinkedIn Team was informed about this attack scenario. The following are a series of suggestions that should prevent this kind of attacks:
    • Protect every web resource that includes anti-CSRF tokens with the X-Frame-Options header. Nowadays, this mechanism is available in all major browsers;
    • Consider to adopt a stateful anti-CSRF mechanism that should not perform the validation on the basis of potentially attacker-controlled inputs.

    July 25 2012



    After 2 years, I'm convinced I will not get back to posting to this blog. Accordingly, Oversighting is now officially discontinued. I'm leaving the article online as they might be useful for someone in the future, but won't post any more updates.

    Can we eat the apple?

    As IT professionals, we are used to love-hate relationships. We invented Perl and LISP, so we know what we're talking about. But it's seems Apple is a white cow in a black herd.
    In a recent article on his blog (then blogged on Ars Technica) Vladimir Vukicevic revelead he found undocumented API in Apple's framework.
    While I don't think this is malicious behaviour in itself, think for a moment about Microsoft doing the same thing, and the following reactions.
    Instead, the thing went almost unnoticed.
    It's hard to hate Apple, or even to be angry with that company: Apple is innovating every day, doing amazing research, and is cool whereas Microsoft is not. And I did not mention the iPhone, the iPod and so on.
    But then, Apple is cheating,not releasing SDKs and in general acting like it could not care the less about fair play and the community.
    How long before we realize

    How to use google analytics on soup.io

    I'm running a soup blog for personal entertainment: soup.io is a great service for fast, quick blogging and has a great team, but it's missing statistics.
    So, I've used google analytics. Here's how:

    • Create a Google Analytics account

    • Copy the tracking javascript (new version)

    • Edit your soup description

    • Enter html mode

    • Paste the javascript code inside the description, then save.

    Here you are, google analytics up and running.
    I think you should not edit the description again, but I'm not sure.

    Web 2.0 IDEs

    How should we develope for the Web 2.0? That's an interesting question: as of today we lack methodologies,testing tools and a proper development environment for the web. That's it, if you go through the smoke: while any C developer can start coding and debugging in less than an hour from a clean system, most PHP developers are still stuck with echo and similar "debug stuff" from the 70s. If you look at java things get only slightly better: while you can have debugging for some part of the code, the ecosystem around J2EE is so crowded it's almost impossible to have proper methodologies.
    But the real nightmare is the frontend. I know CSS/JS gurus coding with Emacs! While Emacs is a very nice operating system, it's unbelievable there's nothing better out there.
    The idea of this post came from the recently announced release of the new version of WaveMaker visual studio, a "drag and drop" IDE for Ajax powered websites.
    The arena of web 2.0 IDEs is full of competitors. Mind you, I will only name a few but feel free to drop me a comment if you know some more. I will do a little mixing between Ajax/Client oriented IDEs and IDES supporting server side languages, but that's exaclty the point: in the new Web 2.0 we need to use both! What's more, most IDEs are not just being, well, IDEs, but they're supporting their own framework with proprietary libraries, different standards and so on.

    • Aptana is one of the best IDEs around, featuring an Ajax powered web server and supporting AIR too ( AIR vs Silverlight anyone?).Aptana is targeting PHP and ROR, two of the most popular languages in the internet, but... surprise, no support for PHP debugging, only Javascript. So even with the advanced Aptana you're cast to the stone age of echo $debug

    • Echo2 is a framework/ide aimed at Ajax and Rich Client development. It's obviously java based, and provides a nice and easy environment for the developer. I can't help but feel a "blackbox" look around echo-based applications.

    • qooxdoo is a complete framework for Ajax: it does not require any knowledge of html, css or whatever, being a huge juggernaut with its own libraries and a development environmente completely masquerading the underlying structure. Server side, it supports PHP, Perl and Java. Did I mention there's no debugging?

    • Morfik WebOS AppsBuilder is a another complete framework for ajax, featuring a visual environment for page building and browser side debugging via FireBug. And when I say complete I mean it: Morfik is a complete RAD tool, so you are either going to love it or hate it.

    • Eclipse PDT project is an Eclipse plugin powering the development of PHP code. It's still not very mature, but will eventually support complete debugging (it does, actually, by now, but it's a little tricky to setup) and it's my IDE of choice, by the way.

    • RDT is a complete Eclipse plugin for Ruby On Rails development.Nothing to say here, it's probably the IDE of choice of most Ruby developers.

    • Zend Studio should be a bigger player. It's Eclipse based now, supporting unit testing (finally!) and proper debugging. But yet, its relatively high price is a huge stop for buyers: most PHP guys nowaday were coding alone yesterday and could not afford Studio. The result is that they don't need it now, and they probably won't tomorrow. Bad move, Zend.

    • Netbeans has a surprisingly good support for Ruby on Rails, including debugging, semantic analysis and so on.

    • 4D's ajax support is a nice addition to the 4D suite. I must admit I never quite got to know 4D, being it a little too "closed minded" for me, so I'm just mentioning it here.

    But wait: how comes we are speaking about web 2.0 IDEs and we are not mentioning any IDE that is actually 2.0? Well, here you are:
    • Heroku is a feature-full, powerful and scalable ide for developing Ruby on Rails applications directly on the web. Heroku will take care of everything from giving you an IDE to actually running the applications in production. That's a tremendous improvement, but yet... you will be missing the most advanced features of a fulle IDE (debugging, call tracking and so on).

    • AppJet is a full-javascript solution: write your javascript code in their IDE and voila, it's up and running server side-.

    Conclusions: while we have dozens of players and softwares, not only we're missing the ultimate IDE, but most environments don't support even the most fundamental features that programmers have became accustomed to.
    Debugging, proper testing and continuos integration are nowhere to be found in the brave new web.
    The next time your favourite web application goes mad, you know why.

    Update: after a quick test, I've added 4D and Netbeans. Thanks go to freakface and Mickael (even if he is now using gedit).

    Cisco and KVM

    Virtualization.info published yesterday a breaking news: Cisco will use KVM on its brand new ASR 1000 router.
    KVM is a virtualization technology included in modern Linux kernels: it is the virtualization platform supported by Ubuntu and ready to replace XEN in most opensource environments as soon as it reach enough stability and usability (and possibly an user interface).
    The ASR 1000 is Cisco's highest end router, costing around 35k US$, and it's the first Cisco router using Linux instead of the proprietary IOS. The ASR 1000 will leverage on KVM to provide operating system redundancy without any dedicated hardware.
    While Cisco has invested in VMware in the past, and they are collaborating on the VFrame technology, the message is clear: there's no space in embedded, low fingerprinting virtualization for VMware anymore. The possibility to fine tune the operating system to its maximum and the source code availability of KVM offer unmatched advantages in such challenging high performances environments as routers and embedded devices.
    We can easily expect to see more and more virtualization embedded in appliances and hardware devices: what about an antivirus box able to trace the stack of malwares running them in a virtual box, instead of the

    iPhone SDK is available, enter the App Store

    Hats off, this time. Engadget has blogged in real time for the whole day from the iPhone SDK press conference. The results?
    • Exchange on the iPhone. That's it, Microsoft has built direct access to the exchange server, bypassing the good old ActiveSync. I see troubles coming from this behaviour, very Apple-style, but time will tell. For now, it's a good thing.

    • The sdk. This is the news. Apple got the hint and released the complete SDK from cocoa up. We'll see how much open it really is (unlike what happened in the past). That's what community pressions are all about. Is that all, folks?

    Enter App Store. I guess you all know iTunes. Ok, same idea but for applications. No charge for free applications, 30% of customer price for commercial apps, without any hint to entering fees. That's Apple for you: you don't just build a community, you start something bigger able to generate huge revenues.
    I'm suspending further judgment until I can actually see the thing running, but feel free to comment: will App Store be able to change the way we use software on the mobile devices? Consider this: in Italy the entertainment contents market on mobile phones is greater than the good old music-on-cdrom market. Why? For many reasons, but

    The best online CRM, intro

    A CRM software (where CRM stands for Customer Relationship Management) is one of the central software package of any business.
    What we once did by bare memory and "the human touch", today we do by using very very complex softwares (actually CRM is a strategic approach, but nowaday when we say CRM we mean just the software). Web oriented CRM are growing bigger and bigger: their ubiquity, low total costs of ownership and all the usual pros associated with web applications are very important factors when choosing a new CRM.

    A lot of free or low-cost CRMs surface every day, and some are gaining a good degree of popularity. In these articles, I will discuss some of the most used CRMs, examining both the technical and the business facts, from the perspectives of both an SMB and a Freelancer.

    The first one will be the VTiger / SugarCRM couple, coming tomorrow.

    Monitoring Software

    Zabbix Nagios & Zeus

    Virtual appliances forensics

    In the last months I've been most busy exploring virtualization security issues,

    October 21 2011


    "No More Free Bugs" Initiatives

    Two years after the launch of the "No More Free Bugs" philosophy, several companies and Open Source projects are now offering programs designed to encourage security research in their products. In addition, many private firms are publicly offering vulnerability acquisition programs.

    This post is an attempt to catalog all public and active incentives. This includes traditional "Bug Bounty Programs" as well as "Vulnerability/Exploit Acquisition Programs".

    Bug Bounty Programs

    Reward Barracuda Vulnerabilities in Barracuda appliances, including Spam/Virus Firewall, Web Filter, WAF, NG Firewall $500-$3,133.7 CCBill.com CCBill web application vulnerabilities $200-$500 Djbdns Verifiable security holes in the latest version of Djbdns $1000 Facebook Facebook web platform security bugs. No third-party applications Starting from $500 Google Chromium browser project and selected Google web properties bugs $500-$3,133.7 Hex-Rays Security bugs in the latest public release of Hex-Rays IDA Up to $3000 Mozilla Firefox, Thunderbird and selected Mozilla Internet-facing websites bugs $500-$3000, plus Mozilla T-shirt Piwik Flaws in Piwik web analytics software $200-$500 Qmail Verifiable security holes in the latest version of Qmail $5000 Tarsnap Tarsnap bugs, affecting either pre-release or released versions $1-$2000
    Vulnerability/Exploit Acquisition Programs



    BeyondSecurity SecuriTeam High and medium impact bugs in widely spread software $n/a Coseinc Unpublished security vulnerabilities for Windows, Linux and Solaris $n/a Digital Armaments Vulnerability and/or exploit code for high value software $n/a ExploitHub Legitimate market-place for non-zero-day Metasploit exploits $50~$1000 iSight Partners Bugs in typical corporate environment applications $n/a Netragard 0-day exploits against well-known software $n/a TippingPoint ZDI Undisclosed vulnerability research, affecting widely deployed software $n/a plus awards and benefits, depending on the contributor's status VeriSign iDefence Security vulnerabilities in widely deployed applications $n/a White Fir Design Bugs in WordPress code and plugins (with over 1 million downloads and compatible with the most recent WordPress) $50-$500
    Contributions are welcome! If you are aware of an initiative not listed here, please leave a comment and we will update this page over time.

    Just to clarify, we aim at indexing programs that are:
    • Legal. Although black/gray market places exist, we don't certainly want to list them here
    • Active. We want to keep track of ongoing initiatives. Even time-limited programs are eligible, as long as they are still accepting submissions
    • Public. All entries must have publicly available details. This may range from accurate guidelines and rules to just a simple sentence stating the nature of the incentive
    • Reward-based. In most cases, entries are "cash-for-bugs" programs. However, any kind of tangible reward is eligible. "No More Free Bugs" versus "No More Cheap Bugs" disputes are not considered here

    September 01 2011


    On exploits and assessing security

    Everything started on a summer Friday, August 19 2011, 23:23 BST (so it might be reported to Sat 20 Aug, depending on your timezone).
    Kingcope, a Greek hacker known for a long stream of 0days and trash Greek music soundtracks, posts a very short email on the Full-Disclosure mailing list. The email has a promising title, Apache Killer, and an attachment: killapache.pl.

    The script is extremely simple: 84 lines of perl, comments included, capable of killing any Apache web server.

    The core of the attack is extremely simple: the script sends a (perfectly legit) request to the Apache server, including a Range header similar to this:

    Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-
    66,5-[..and many many more..].

    What happens behind the scene is that Apache has to make separate copies of the response for each of those ranges and, guess what, it explodes.

    The Range header (defined here in RFC 2616) has legitimate uses: for instance, PDF readers use it while you scroll down the page. Let us reiterate that the attack is a perfectly well formed request: "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity."
    On a side note, IIS only allows up to 5 ranges for each HTTP request, and it is not vulnerable - with the notable exception of IIS 5, but you don't have those around anymore, do you?

    But back to our story. Apache reacted "quickly", issuing a security advisory [CVE-2011-3192] a mere 4 days after the release, on August 24 16:16 GMT [http://article.gmane.org/gmane.comp.apache.announce/58]. They acknowledged the bug, promising that "A full fix is expected in the next 48 hours.". Apache also provided a number of different mitigations, by using mod_rewrite, limiting the size of the request field or even a dedicated module.

    +1 for having included so many mitigations inside the advisory, -1 for taking so long to give an official answer.

    A number of different answers were surfacing by that time, including Spiderlab's suggestion of using ModSecurity (but truth be told the answer was already floating on some forums). The 24th was, in short, the moment where the general public started noticing the issue - also thanks to a The Register's article which, even though it drops a totally out of place comment on open source security, at least cites Zalewski.

    And this is the interesting bit of the story: the bug was well known!
    lcamtuf reported this exact issue in 2007 - just 4 years ago.

    The reactions were, to say the least, wrong. William A. Rowe [of the Apache Software Foundation] answered: "With the host of real issues out there in terms of massively parallel DDoS infrastructures that abound, this is, as you say, quite a silly report.". Yeah, sure. The issue was also thought to be connected to the sliding window (Rowe: On the matter of your 1GB window (which is, again, the real issue), you have any examples of a kernel that permits that large a sliding window buffer by default).
    Probably even lcamtuf did not understand the full impact of this issue - we are speaking about a full DOS against the default installation after all, even if it is very easily avoided - as he says: "William, again, this is not a critical issue; I did mention that, and if it were, I wouldn't report it that way". The issue was thus not really understood by both parties, or at least its full implications were not. If we go into the details of the bug report we must grant the fact that it focused more on the "network" attack vector - not exactly the one exploited by Kingcope's attack, which results in memory exhaustion. Siim Põder also tried to implement the attack, but failed. The thread then just died.

    Bottom line: general failure of the community to identify and evaluate a risk in the absence of an exploit. So long for all the "risk assessment without full disclosure" talks: without an exploit, an entire community looking at the description of a bug in the most widespread web server of the world failed to evaluate risk.

    At the same time, in the Apache dev@ mailing list there was not a single mention of the bug. Compare that to the mail thread [mod_deflate & range requests) from last August: http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/browser, or here. This exploit, in the end, resulted in a ticket on the ietf with a request for changing the standards [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311]: that's what we call impact.

    And all because an exploit was not developed in the first place...

    June 21 2011


    MS Access SQL Injection Cheat Sheet Reloaded

    SQL Injections are still very popular, for both ethical and unethical attackers.
    Although numerous research covering this topic have been published, SQL Injection vulnerabilities in Microsoft Access powered websites didn't receive much attention.

    Back in 2007, @_daath published the first MS Access SQL Injection Cheat Sheet. A few years later, NibbleSec decided to update the document in a brand new format. New stuff has been added as well as external resources have been merged.

    Enjoy the reloaded MS Access SQL Injection Cheat Sheet

    December 30 2010


    TYPO3-SA-2010-020, TYPO3-SA-2010-022 explained

    On 16th December, TYP03 released a new security update (TYPO3-SA-2010-022) for their content management system. Apparently, this web-based framework is widely used in many important websites.
    Within this update, TYPO3 team fixed a vulnerability that I've discovered a few weeks ago. In detail, this discovery pertains to a previous vulnerability fixed in TYPO3-SA-2010-020 and discovered by Gregor Kopf.

    TYP03 decided to follow a policy of least disclosure. Although it's an Open Source project, no technical details are available in the wild besides these (1,2). As I strongly believe that this practice does not improve the overall security (as mentioned in a previous post), I've decided to briefly explain this interesting flaw.

    From the advisory, we can actually deduce two important concepts:
    A Remote File Disclosure vulnerability in the jumpUrl mechanism [..] Because of a non-typesafe comparison between the submitted and the calculated hash, it is possible [..]
    In a nutshell, the JumpUrl mechanism allows to track access on web pages and provided files (e.g. /index.php?id=2&type=0&jumpurl=/etc/passwd&juSecure=1&locationData=2%3a&juHash=2b1928bfab)

    The patch (see this shell script) simply replaces the two equal signs with three (loose vs strict comparisons).

    That's the affected code:

    Having this knowledge, it is probably clear to the reader that the overall goal is to bypass the comparison between $juHash and $calcJuHash. While the former is user supplied (string or array), the latter is derived from a substr(md5_value,10) (string).

    In PHP, comparisons involving numerical strings result in unexpected behaviors (at least for me before studying this chapter).
    If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically
    If the string does not contain any of the characters '.', 'e', or 'E' and the numeric value fits into integer type limits (as defined by PHP_INT_MAX), the string will be evaluated as an integer. In all other cases it will be evaluated as a float.
    For instance, the following comparisons are always TRUE:
    if(0=="php")-> TRUE
    if(12=="12php")-> TRUE
    if(110=="110")-> TRUE
    if(100=="10E1")-> TRUE
    if(array()==NULL) -> TRUE
    And again, also the following comparisons are TRUE:
    Consequently, we can pad and wait till the substring of an md5 hash resembles this form. If you do the math, you will discover that the combined probability of having such calculated hash is considerably less than pure bruteforcing.
    ~37037037 max trials (worth case) VS 3656158440062976 all possibilities
    In practice, the number of iterations is even less as "0000E13131" and similar strings are also accepted.

    To further improve this attack, I've discovered another bypass (TYPO3-SA-2010-022) which allows the disclosure of TYPO3_CONF_VARS['SYS']['encryptionKey']. In this way, it is possible to retrieve the key once and download multiple files without repeating the entire process. Using multiple requests, this attack takes a few minutes (8-20 minutes in a local network). A real coder can surely enhance it.

    As you can see from the exploit (posted on The Exploit Database), the fileDenyPattern mechanism bypass is pretty trivial. A demonstration video is also available here (slow connection, sorry).

    Keep your TYPO3 installation updated! A patch is already available from the vendor's site.


    December 29 2010


    Unspecified vulnerabilities

    If you're a pentester, it's probably not news to you that "least disclosure" policies for disclosing vulnerabilities are fruitless. Unfortunately, they are even counterproductive for the entire security ecosystem and I will try to convince you within this post.

    Before going any further, let's explain what "least disclosure" actually means.
    In a nutshell, least disclosure is about providing the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be. No technical details, no exploits, no proof-of-concept code.

    As mentioned here, you may argue that it increases the overall security as a random "black hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability".

    However, we all claim that "security through obscurity" is bad:
    • Aggressors don't have time constraints. They can analyze patches, read all documentation and spend nights on a single flaw

    • No technical details in the wild generally means no signatures and detectors in security tools

    • "Least Disclosure" tends to degenerate in "Unspecified Vulnerability in Unspecified Components". Please fix your computer and don't ask why
    Although we cannot certainly force vendors' disclosure policies, sharing the outcome of any security research may be beneficial at the end of the day.

    Thoughtful reader, please note that getting profit from vulnerabilities does not necessary implicate concealing details. For instance, see the Mozilla Security Bounty Program FAQ.
    We're rewarding you for finding a bug, not trying to buy your silence
    If you enjoy the spirit, you may appreciate the following posts. Welcome back NibbleSec readers!

    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!