Category Archives: Web Application Security

#HackerKast 6: Microsoft Takes Over No-IP, LASCON 2014 Wrap-up, Shopping Cart Software Security

This week Jeremiah Grossman, Robert Hansen and Matt Johansen talk about interesting news and talks out of LASCON as well Microsoft taking over small Internet service provide No-IP and @mattjay gloats about taking the top spot in the recent WhiteHat HackerKombat competition with the most individual flags captured.

Resources:
How Microsoft Appointed Itself Sheriff of the Internet

‘Spam Nation’ Publisher Discloses Card Breach

#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

    Mile-High AppSec

    I just returned from AppSec USA last week in Denver. Many of you are likely familiar with this conference: it’s when our good friends over at OWASP pick a lucky city and converge on it, bringing together some of the world’s best-known application security practitioners, experts and hackers. WhiteHat Security had about 10 people floating around between sessions, booths, and several fun after-hours endeavours. As per past years, last week Denver was the place to be if you work in application security.

    I had the good fortune of being a panelist in one session discussing the use of Open Source software in the Enterprise. The panel was moderated by Sonatype’s Derek E. Weeks (@weekstweets) who helped put together the Open Source Security survey we were discussing. Other panelists included Josh Corman (@joshcorman), Damon Edwards (@damonedwards), and Jeff Williams (@planetlevel), who were all fantastic contributors and really bright guys in general. We had some really interesting takeaways from our conversation which were eye-opening:

    1. Open Source Security policies are rare and when they exist, they are even more rarely followed.
    2. Most companies still rely on *manual* testing of their codebase, including the Open Source libraries.
    3. Even when manual testing occurs it tends to happen mostly in production.
    4. Nobody knows what Open Source libraries they use or where they live.
    5. Responsibility for security of Open Source libraries is very varied (IT, Compliance, Risk, Security).
    6. -10. Heartbleed sucked hard.

    Here is a video of the panel.

    After the panel I also got a chance to present the Top 10 Web Hacking Techniques of 2013 with my esteemed colleague Johnathan Kuskos (@johnathankuskos). For those of you who follow the WhiteHat blog, this should be old hat for you (we ran this presentation via a webinar and living blog post here earlier this year). The content is fantastic, the researchers we pay homage to are all top-notch, and the hacks this year were really creative and some went very deep into the technical nitty gritty.

    If you want to see some of the AppSec talks check out the OWASP YouTube channel which they are updating daily as they process these recordings. I’m sure the Top 10 will pop up there in the next few days.

    Other than talks, you can all join me in congratulating Johnathan Kuskos in winning this year’s WaspNestCTF, developed by the OWASP Boulder, Colorado chapter. Johnathan tied for first place against a team of three… all by himself. This also means he won some additional prizes for most flags captured by a single person. Congrats Kuskos!

    We also took the opportunity to launch our new WhiteHat HackerKast web series while in Denver, after all it’s not often that three of us are in the same room together! You can view the first episode below. HackerKast will be a weekly conversation between three of us at WhiteHat in which we discuss the latest news that people are talking about on Twitter, latest news headlines or interesting pieces of research that we believe the industry will benefit from. In this first episode, Jeremiah Grossman (@jeremiahg), Robert Hansen (@RSnake) and I talk about interesting topics from the show floor.

    In general, we had a blast in Denver trying out some craft beer during the OWASP pub crawl, hanging out with the awesome team from BugCrowd who hosted a Bug Smash, and mingling with some of the top AppSec people in the world. Next year’s AppSecUSA is in San Francisco so we can all go bug Michael Coates (@_mwc) in his backyard. Hope to see many of you there!

    And now… HackerKast Episode 1:

    What the InfoSec Skills Gap Means for the Future

    One of the biggest challenges – if not the biggest challenge – facing information security is the lack of skilled talent. As yet another proof point in a long line of reports all saying the same thing, Cisco’s 2014 Annual Security Report says, “it’s estimated that by 2014, the [IT Security] industry will still be short more than a million security professionals across the globe.” You ask any hiring manager, and they’ll agree. And here’s the thing, we might be able to make a dent in the skill gap with education programs, but by-and-large, the information security skills shortage isn’t going to get solved any time soon.

    This says to me…

    1. Breaches will continue at least at the current clip resulting in increased industry and government regulations, which will lead to compliance job openings.
    2. Compensation for competent information security personnel will continue to rise and globalize, regardless of whether the person is experienced or not.
    3. Organizations in the best position to hire, train, and retain security talent will carry the day. Education isn’t going to come in the form of reading or certification, but on the job in a more “trial by fire” way.
    4. Organizations will continue to outsource their security needs to where security talent can be best centralized and scaled.
    5. People with limited background in security will be increasingly tasked with performing security jobs – or at least managing the processes.
    6. Super easy-to-use security products and services will be preferred over the more technically sophisticated and feature rich.
    7. The information security skill shortage is actually going to get worse as the economy improves.

    Everyone get busy automating!