Category Archives: Technical Insight

#HackerKast 5: POODLE Attack, HackerKombat and Drupal SQLi Flaw

This week Jeremiah Grossman, Robert Hansen and Gabe Gumbs host HackerKast at Levi’s Stadium – the home of the SF 49ers – to discuss the recently announced POODLE Attack on SSL 3.0 and a critical SQLi flaw affecting Drupal making headlines. WhiteHat’s 6th HackerKombat capture the flag competition will also stream LIVE on Twitch.tv.

Watch HackerKombat LIVE starting at 3 pm PT on 10/17:
http://www.twitch.tv/hackerkombat

Other Resources:
POODLE Attack Information:
https://blog.whitehatsec.com/what-you-need-to-know-about-poodlessl-3-0-vulnerability/
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.openssl.org/~bodo/ssl-poodle.pdf

Drupal SQLi Flaw Advisory:
https://www.drupal.org/SA-CORE-2014-005
http://news.techworld.com/security/3581251/drupal-releases-patch-for-severe-sql-injection-flaw/?olo=rss

What you need to know about POODLE/SSL 3.0 vulnerability

UPDATE – 10/16 12:45 p.m. PT: For users with Akamai sites, Akamai has made the following updates:

  • Akamai is going to be disabling SSLv3 and SSLv2 support on an aggressive timeline
  • If SSLv3 support is necessary for legacy support clients can be exempted upon request

  • Users that utilize Akamai should contact Akamai for further details. Here are some Akamai blogs which clients may find helpful:
    SSL is dead, long live TLS
    Excerpt: How POODLE happened

    UPDATE – 10/15 7:15 p.m. PT: WhiteHat Security has added testing for the new POODLE attack. These vulnerabilities will be shown as ‘Insufficient Transport Layer Protection’ in the Sentinel interface. They will have the description ‘CVE-2014-3566 – POODLE Attack’. These tests will be run at the start of a new scan.

    Google researchers released a new SSL vulnerability yesterday nicknamed “POODLE Attack.” POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption, is an attack that targets SSL version 3.0 and allows interception and compromise of supposedly secured data.

    Only SSL version 3.0 is known to be effected by this exploit. Although SSL 3.0 is extremely outdated, connection failures will result in older versions of SSL being used in an attempt to establish connection. Attackers can leverage this and force connection reattempts with SSL 3.0.

    Disabling SSL 3.0 will fix the issue however unforeseen compatibility problems may exist on sites. The Google researchers recommended supporting TLS_FALLBACK_SCSV. It’s also important to note that RC4 encryption has no padding, and as such is not vulnerable to this specific attack – although RC4 is not exempt from known issues as well.

    WhiteHat Security is currently researching a check for the POODLE Attack and will implement it as soon as it is possible.

    If you want to protect yourself in your browser, as Robert Graham with Errata Security has suggested, disabling SSLv3 in browsers is easy. On Chrome, Chromium and Aviator, use the command-line flag –ssl-version-min=tls1, and on Firefox set security.tls.version.min to 1. Mozilla also has an add-on available for disabling SSL 3.0 in Firefox. If you choose not to do this, please make sure you avoid unknown wireless connections until an official update is available for your browser.

    We will continue to update this blog as more information about POODLE is known and as more information for our customers becomes available. If you have any questions please contact WhiteHat Customer Support at support@whitehatsec.com.

    How I stole source code with Directory Indexing and Git

    The keys to the kingdom pretty much always come down to acquiring source code for the web application you’re attacking from a blackbox perspective. This is a quick review of how I was able to get access to a particular client’s application source code using an extremely simple vulnerability: Directory Indexing. Interestingly enough, they also had a .git repository accessible at https://www.[redacted].com/.git/ (although the ‘why’ still baffles me). If you have access to this you also have access to any commits and all logs that may exist in the repo.

    The following screenshots are from a recreation of the environment being run locally that I /etc/hosts mapped to http://demo.jkuskos.com. All client information has been redacted.

    image1 copy_Kuskos_10.14.14

    First, I confirmed that Directory Indexing was enabled. You’ll see why this is great in a moment.

    image2 copy_Kuskos_10.14.14

    The easiest way to download anything would be with a recursive wget(you simply need to set the flag -r).

    wget -r http://demo.jkuskos.com/.git/

    image3 copy_Kuskos_10.14.14

    Now let’s investigate. With the repository downloaded we can perform git commands on it.

    image4 copy_Kuskos_10.14.14

    Now that we can see which files exist in the repository, access to them is as simple as checking them out.

    git checkout *.php; ls;

    image5 copy_Kuskos_10.14.14

    This example is clearly simplified; however, the real site allowed me to find several SQL Injections and authorization bypasses that would have been cumbersome to find through dynamic blackbox testing alone. It also allowed me to find several files that would otherwise have been available only if you had the appropriate credential access. These types of flaws are easily found through static code analysis and much harder to find through a dynamic assessment only. As a hacker, turning a blackbox penetration test into a whitebox penetration test is always a victory.

    Shellshock Vulnerability – What It Is & Recommendations

    Shellshock VulnerabilityUPDATE – 9/26, 1:35 p.m. PT: Customers with WAFs (Web Application Firewalls), IPS’, and other security devices may have noticed that we have some checks already in place, with results / vulnerabilities coming out of the system. The nature of the Shellshock vulnerability requiring only a single http(s) request means that the number of attack vectors are numerous and as such we will be continuing to improve our testing methodology in the days and weeks to come. It is of the utmost importance that we reiterate the importance of checking your systems directly and patching as other services may be available such as SSH, CUPS and DHCP.

    UPDATE – 9/25, 5:00 p.m. PT: The WhiteHat Research & Development team has been working hard to dissect the Shellshock issue and deploy additional checks as necessary to Sentinel.

    Prior to the announcement of Shellshock, WhiteHat Sentinel Source had already been testing for applications making use of untrusted data in conjunction with the operating system’s shell interface to execute native commands and applications writing untrusted data to a system environment variable. In the Bash shell, injection into an environment variable can also lead to remote code execution. Failure to properly validate and or encode data utilized by the shell allows an attacker to execute arbitrary operating system commands. This is dangerous because environment variables can be used in other parts of the application, external process on the host, or even other applications. Many applications implicitly trust environment variables to be safe, so this data is often not checked for suspicious activity. Both of the checks in Sentinel Source are able to accurately identify the type of behavior that Shellshock is vulnerable to.

    The ‘Shellshock’ exploit (CVE-2014-6271) announced yesterday is a vulnerability found in the Bash command interpreter. Bash is the shell, or command language interpreter, whose name is an acronym for the ‘Bourne-Again Shell.’ Injection vulnerabilities in web apps are a death blow: they are the one class of vulnerability that accounts for more data loss than all other vulnerabilities. The Shellshock bug is a code-injection vulnerability that allows an attacker to pass commands to Bash to execute arbitrary code. This is a critical issue for any application that evaluates user input and calls other applications via a shell. The CVE severity score for Shell Shock is 10 on a scale of 1 to 10. Given that this vulnerability is known to be ‘wormable’ 10 almost seems like it is not high enough. This issue is likely to be of greater concern than Heartbleed (which we posted about here and here) was earlier this year.

    The extent to which this vulnerability affects the web is still unfolding. WhiteHat has confirmed that cgi-script based web applications may be vulnerable, especially those that call other applications via the shell. Apache servers using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. We have also observed several working pieces of exploit code in the wild that requires a minimal amount of technical expertise to execute. WhiteHat is implementing a detection for this vulnerability to identify the existence of this critical vulnerability in their web applications. At this time is highly advisable that you patch all systems running Bash. Additionally, there are several working mitigations currently available for this vulnerability:

    1. Upgrading to a new version of bash
    2. Replacing bash with an alternate shell such as zsh
    3. Limiting access to vulnerable services, or filtering inputs to vulnerable services

    Editor’s note: Want to learn more about Shellshock? Register for our town hall discussion.

    We will continue to provide regular updates as they become available.

    Other Resources for more information on this bug as it unfolds:
    GNU bash Environment Variable Processing Flaws Let Users Execute Arbitrary Code
    Shellshock DHCP RCE Proof of Concept
    [SECURITY] [DSA 3032-1] bash security update
    Bash specially-crafted environment variables code injection attack
    Bash ‘shellshock’ bug is wormable
    Everything you need to know about the Shellshock Bash bug
    Bash ‘shellshock’ scan of the Internet
    Quick notes about the bash bug, its impact, and the fixes so far
    Bash specially-crafted environment variables code injection attack
    Environment Bashing

    The Ghost of Information Disclosure

    Information disclosure is a funny thing. Information disclosure can be almost completely innocuous or — as in the case of Heartbleed — it can be devastating. There is a new website called un1c0rn.net that aims to make hacking a lot easier by letting attackers utilize Heartbleed data that has been amassed into one place.

    The business model is simple – 0.01 Bitcoins (Around $5) for data. It leaves
    no traces on the remote server because the data isn’t stored there anymore,
    it’s on un1c0rn’s server. So let’s play a sample attack out.

    1) Heartbleed comes out;

    2) Some time in the future un1c0rn scans a site that is vulnerable and logs it;

    3) A would-be attacker searches through un1c0rn and finds a site of interest;

    4) Attacker leverages the information to successfully mount an attack against the target server leveraging the data.

    In this model, the attacker’s first packets to the server in question could be
    the one that compromises them. But it’s actually more interesting than that. As I was looking through the data I found this query.

    un1c0rn

    For those of you who don’t live and breathe HTTP this is an authorization request with a base64 encoded string (which is trivial to reverse) that contains the usernames and passwords to the sites in question. This simple request found 400 sites with this simple flaw in it. So let’s play out another attack scenario.

    1) Heartbleed comes out;

    2) Some time in the future un1c0rn scans a site that is vulnerable and logs it;

    3) Site is diligent and finds that they are vulnerable, patching up immediately and switching out their SSL certificate with a new one.

    4) A would-be attacker searches through un1c0rn and finds a site of interest;

    5) Using the information they found they still compromise the site with the username/password, even though the site is no longer vulnerable to the attack in question.

    This is the problem with Information Disclosure – it still can be useful even long after the hole that was used to gather the data has been closed. That’s why in the case of Heartbleed and similar attacks not only do you have to fix the hole but you also have to expire all of the passwords, and remove all of the cookies or any other way that a user could gain access to the system.

    The moral of the story is that you may find yourself being compromised seemingly almost magically in a scenario like this. How can someone guess a cookie correctly on the first attempt? Or guess a username/password on the first try? Or exploit a hole without ever having looked at your proprietary source code or even having visited your site before? Or find a hidden path to a directory that isn’t linked to from anywhere? Well, it may not be magic – it may be the ghost of Information Disclosure coming back to haunt you.

    Spooky!

    SSL/TLS MITM vulnerability CVE-2014-0224

    We are aware of the OpenSSL advisory posted at https://www.openssl.org/news/secadv_20140605.txt. OpenSSL is vulnerable to a ChangeCipherSpec (CCS) Injection Vulnerability.

    An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.

    The attack can only be performed between a vulnerable client *and* a vulnerable server. Desktop Web Browser clients (i.e. Firefox, Chrome Internet Explorer) and most mobile browsers( i.e. Safari mobile, Firefox mobile) are not vulnerable, because they do not use OpenSSL. Chrome on Android does use OpenSSL, and may be vulnerable. All other OpenSSL clients are vulnerable in all versions of OpenSSL.

    Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

    OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
    OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
    OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

    WhiteHat is actively working on implementing a check for sites under service. We will update this blog with additional information as it is available.

    Editor’s note:
    June 6, 2014
    WhiteHat has added testing to identify websites currently running affected versions of OpenSSL across all of our DAST service lines. These vulnerabilities will open as “Insufficient Transport Layer Protection” in the Sentinel interface. WhiteHat recommends that all assets including non-web application servers and sites that are currently not under service with WhiteHat be tested and patched.

    If you have any questions regarding the the new CCS Injection SSL Vulnerability please email support@whitehatsec.com and a representative will be happy to assist.

    Teaching Code in 2014

    Guest post by – JD Glaser

    “Wounds from a friend can be trusted, but an enemy multiplies kisses” – Proverbs 27:6

    This proverb, over 2,000 years old, is directly applicable to all authors of programming material today. By avoiding security coverage, by explicitly teaching insecure examples, authors do the world at large a huge disservice by multiplying both the effect of incorrect knowledge and the development of insecure habits in developers. The teacher is the enemy when their teachings encourage poor practices through example, which ultimately bites the student in the end at no cost to the teacher. In fact, if you are skilled enough to be an effective teacher, the problem is worse than for poor teachers. Good teachers by virtue of their teaching skill greatly multiply the ‘kisses’ of poor example code that eventually becomes ‘acceptable production code’ ad infinitum.

    So, to the authors of programming material everywhere, whether you write books or blogs, this article is targeted at you. By choosing to write, you have chosen to teach. Therefore you have a responsibility.

    No Excuse for Demonstrating Insecure Code Examples

    This is year 2014. There is simply no excuse for not demonstrating and explaining secure code within the examples of your chosen language.

    Examples are critical. First, examples teach. Second, examples, one way or the other, find their way into production code. This is a simple fact with huge ramifications. Once a technique is learned, once that initial impact is made upon the mind, that newly learned technique becomes the way it is done. When you teach an insecure example, you perpetuate that poor knowledge in the world and it repeats itself again and again.

    Change is difficult for everyone. Pepsi learned this the expensive way. Once people accepted that Coke was It, hundreds of millions of dollars spent on really cool advertising have not been able to change that mindset of that opinion. The mind has only one slot for number one, and Pepsi has remained second ever since. Don’t continue to enforce security in the mind as second.

    Security Should Be Ingrained, Not Added

    When teaching, even if you are ‘just’ calculating points on a sample graph for those new to chart programming, if any of that data comes from user supplied input via that simple AJAX call to get the user going, your sample code should filter that sample data. When you save it, your sample code should escape it for the chosen database; when you display it to the user, the sample code of your chosen language should escape it for the intended display context. When your sample data needs to be encrypted, your sample code should apply modern cryptography. There are no innocent examples anymore.

    Security should be ingrained, not added. Programmers need to be trained to see security measures in line with normal functionality. In this way, they are trained to incorporate security measures initially as code is written, and also to identify when security measures are missing.

    When Security Measures are removed for the sake of ‘clarity’ the student is being taught unconsciously that security makes things less clear. The student is also being trained directly by example to add security ‘later’.

    Learning Node.js In 2014

    Most of the latest Node.js books have some great material, but only one out of several took the time to properly teach, via integrated code examples, how to properly escape Node.js code for use with MySQL. Kudos to Pedro Teixeira, who wrote Professional Node.js from Wrox Press, for teaching proper security measures as an integral part of the lesson to those adapting to Node.js.

    Contrast this with Node.js for PHP Developers from O’Reilly Press, where the examples explicitly demonstrate how to insecurely code Node.js with SQL Injection holes. The code in this book actually teaches the next new wave how to code wide open vulnerabilities to servers. Considering the rapid adoption of Node.js for server applications, and the millions who will use it, this is a real problem.

    The fact that the retired legacy method of building SQL statements through insecure string concatenation was chosen by the author as the instruction method for this book really demonstrates the power of ingrained learning. Once something is learned, for good or bad, a person keeps repeating what they know for years. Again, change is difficult.

    The developers taught by these code examples will build apps that we may all use at some point. The security vulnerabilities they contain will effect everyone. It makes one wonder if you are the author whose book or blog taught the person who coded the latest Home Depot penetration. This will be code that has to be retrofitted later at great time and great expense. It is not a theoretical problem. It does have a large dollar figure attached to its cost.

    For some reason, authors of otherwise good material choose to avoid teaching security in an integral way. Either they are not knowledgeable about security, in which it is time to up their game, or have fallen into the ‘clarity omission’ trap. This is a wide spread practice, adopted by almost everyone, of declaring that since this ‘example code’ is not production code, insecure code is excusable, and therefore critical facts are not presented. This is a mistake with far-reaching implications.

    I recently watched a popular video on PHP training from an instructor who is in all other respects a good instructor. Apparently, this video has educated at least 15,000 developers so far. In it, the author explicitly states briefly that output escaping should be done. However, in his very next statement, he declares that for the sake of brevity, the technique won’t be demonstrated, and the examples given out as part of the training do not incorporate the technique. The opportunity to ingrain the idea that output escaping is necessary, and that it should be an automated part of a developer’s toolkit, has just been lost on the majority of 15,000 students because the code to which they will later turn for reference is lacking. Most, if not all, will ignore it as a practice until mandated by an external force.

    Stop the Madness

    In the real world, when security is not incorporated at the beginning, it costs additional time and money to retrofit it later. This cost is never paid until a breach is announced on the front page of a news service and someone is sued for negligence. Teachers have a responsibility to teach this.

    Coders code as they are taught. Coders are primarily taught through books and blog articles. Blog articles are especially critical for learning as they are the fastest way to learn the latest language technique. Therefore, bloggers are equally at fault when integrated security is absent from their examples.

    The fact is that if you are a writer, you are a trainer. You are in fact training a developer how to do something over and over again. Security should be integral. Security books on their own, as secondary topics, should not be needed. Think about that.

    The past decade has been spent railing against insecure programming practices, but the question needs to be asked, who is doing the teaching? And what is being taught?

    You, the writer, are at the root of this widespread security problem. Again, this is 2014 and these issues have been in the spotlight for 10+ years. This is not about mistakes, or being a security expert. This is about the complete avoidance of the basics. What habit is a young programmer learning now that will effect the code going into service next year? and the years after?

    The Truth Hurts

    If you are still inadvertently training coders how to write blatantly insecure code, either through ignorance or omission, you have no business training others, especially if you are successful. If you want to teach, if you make money teaching programming, you need to stop the madness, educate yourself, and reverse the trend.

    Write those three extra lines of filtering code and add that extra paragraph explaining the purpose. Teach developers how to see security ingrained in code.

    Stop multiplying the sweet kiss of simplicity and avoidance. Stop making yourself the enemy of those who like to keep their credit cards private.

    About JD
    In his own words JD, “Did a brief stint of 15 years in security. Headed the development of TripWire for Windows and Foundscan. Founded NT OBJECTives, a company to scan web stuff. BlackHat speaker on Windows forensic issues. Built the Windows Forensic Toolkit and FPort, with the Department of Justice has used to help convict child pornographers.”