UPDATE – 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:
- Upgrading to a new version of bash
- Replacing bash with an alternate shell such as zsh
- 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
Robert Hansen, VP of WhiteHat Security Labs, discusses large scale scanning of DNS traffic on the internet and how to store the data.
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.
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.
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.
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 email@example.com and a representative will be happy to assist.
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.
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.”
A patch issued in March for a previously known vulnerability in Apache Struts Version 2.0.0 – 2.3.16 has been bypassed. The vulnerability allowed attackers to manipulate the ClassLoader leading to possible remote code execution and denial of service. Struts versions 2.0.0-22.214.171.124 are all currently vulnerable to attack. As of today no patch is available however Apache has a detailed write up on how to mitigate the vulnerability while they work on a security patch. Details can be found at http://struts.apache.org/announce.html#a20140424
WhiteHat has added detection for the Struts ClassLoader vulnerability across all service lines. Both dynamic and static assessments have been updated and will begin testing as soon as the next scan begins.
Our Customer Success team would be happy to answer any questions you may have regarding this issue. They can be reached by emailing firstname.lastname@example.org
Editor’s Note: A patch has been released by Apache on Saturday 4/26 which should fix the ClassLoader issue in Struts. Users are encouraged to update to Struts 126.96.36.199 immediately. Details can be found at http://struts.apache.org/announce.html#a20140424
Editor’s note: Ari Elias-Bachrach is the sole proprietor of Defensium LLC. Ari is an application security expert. Having spent significant time breaking into web and mobile applications of all sorts as a penetration tester, he now works to try and improve application security. As a former developer who has experience with both static and dynamic analysis he can work closely with developers to try and remediate vulnerabilities. He has also developed and taught secure development classes, and can help make security part of the SDLC. He is a regular speaker on the field of application security at conferences. He can be found on Twitter @angelofsecurity. Given his experience and expertise, we asked Ari to review our 2014 Website Security Statistics Report which was announced yesterday to get his thoughts which he has shared as a guest blog post.
The most interesting and telling chart in my opinion is the Vulnerability class by language chart. I decided to start by asking myself a simple question: can vulnerabilities be dependent on the language used, and if so which vulnerabilities? I did a standard deviation on all vulnerability classes to see which ones had a high degree of variance across the different languages. XSS (13.2) and information leakage (16.4) were the two highest. In other words, those are the two vulnerabilities which can be most affected by the choice of programming language. In retrospect info disclosure isn’t surprising at all, but XSS is a little interesting. The third one is SQLi, which had a standard deviation of 3.8, and everything else is lower than that.
Conclusion 1: The presence or absence of Cross-site scripting and information disclosure vulnerabilities is very dependent on the environment used, and SQLi is a little bit dependent on the environment. Everything else isn’t affected that much.
Now while it seems that frameworks can do great things with respect to security, if you live by the framework, then you die by the framework. Looking at the “Days vulnerability open by language” chart, you can see some clear outliers where it looks like certain vulnerabilities simply cannot be fixed. If the developer can’t fix a problem in code, and you have to wait for an update to the framework, then you end up with those few really high mean times to fix. This brings us to the negative consequences of relying on the framework to take care of security for us – it can limit our ability to make security fixes as well. In this case the HTTP response splitting issue with ASP are both problems that cannot be fixed in the code, but require waiting for the vendor to make a change, which they may or may not judge necessary.
Conclusion 2: Live by the framework, die by the framework.
Also interesting is that XSS, which has the highest variance in occurrence, has the least variance in terms of time to fix. I guess once it occurs, fixing an XSS issue is always about the same level of effort regardless of language. Honestly I have no idea why this would be, I just find it very interesting.
Conclusion 3: Once it occurs, fixing an XSS issue is always about the same level of effort regardless of language. I can’t fathom the reason why, but my gut tells me it might be important.
I found the “Remediation rate by vulnerability class” chart to be perhaps the most surprising (at least to me). I would have assumed that the remediation rates per vulnerability would have been more closely correlated to the risk posed by each vulnerability, however that does not appear to be the case. Even more surprisingly, the remediation rates do not seem to be correlated to the ease of fixing the vulnerability, as measured by the previous chart on the number of days each vulnerability stayed open. Looking at SQLi for example, the remediation rate is high in asp, ColdFusion, .NET, and Java, and incredibly low in PHP and Perl. However PHP and Perl were the two languages where SQLi vulnerabilities were fixed the fastest! Why would they be getting fixed less often than other environments? XSS likewise seems to be easiest to fix in PHP, yet that’s the least likely place for it to be fixed. Perhaps some of this can be explained by a single phenomena – in some environments, it’s not worth fixing a vulnerability unless it can be done quickly and cheaply. If it’s a complex fix, it is simply not a priority. This would lead to low remediation rates and low days to patch at the same time. In my personal (and purely empirical non-scientific) experience, perl and php websites tend to be put up by smaller organizations, with less mature processes and a lesser emphasis on security and a greater focus on continuing to create new features. That may explain why many Perl and PHP vulnerability are either fixed fast or not at all. Without knowing more, my best guess is that many of the relationships here, while correlated, do not appear to be causal. In other words, some other force, like organizational culture, is driving both the choice of language and the remediation rate.
Conclusion 4: Remediation rates do vary across language, but the reasons seem to be unclear.
I started off with a very basic question “does choice of programming language matter”, and the answer does seem to be yes. While we all know that in theory there is no vulnerability that can’t exist in a given environment, and there’s no vulnerability that can’t be fixed in any given environment, the real world rarely works as neatly as it should “in theory”. Certain vulnerabilities are more likely in certain environments, and fixes may be easier or harder to apply, which impacts their likelihood of ever being applied. There has been a lot of talk lately about moving security into the framework, and this does provide evidence that this approach can be very successful. However it also shows the risks of this approach if the framework does not implement the right security controls and in the right way.
“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra
I like this quote because I think it sums up the way we as an industry all too often approach application security. We have our “best practices” and our conventional wisdom of how we think things operate, what we think is “secure” and standards that we think will constitute true security, in theory. However, in practice — in reality — all too often we find that what we think is wrong. We found this to be true when examining the relative security of popular programming languages, which is the topic of the WhiteHat Security 2014 Website Statistics Report that we launched today. The data we collected from the field defies the conventional wisdom we carry and pass down about the security of .Net, Java, ASP, Perl, and others.
The data that we derived in this report puts our beliefs around application security to the test by measuring how various web programming languages and development frameworks actually perform in the field. To which classes of attack are they most prone, how often and for how long? How do they fare against popular alternatives? Is it really true that the most popular modern languages and frameworks yield similar results in production websites?
By examining these questions and approaching their answers not with assumptions, but with hard evidence, our goal is to elevate conversations around how to “build-in” security from the start of the development process by picking a language and framework that not only solves business requirements, but security requirements as well.
For example, whereas one might assume that newer programming languages such as .Net or Java would be less prone to vulnerabilities, what we found was that there was not a huge difference between old languages and newer frameworks in terms of the average number of vulnerabilities. And when it comes to remediating vulnerabilities, contrary to what one might expect, legacy frameworks tended to have a higher rate of remediation – in fact, ColdFusion bested the whole field with an average remediation rate of almost 75% despite having been in existence for more than 20 years.
Similarly, many companies assume that secure coding is challenging because they have a ‘little bit of everything’ when it comes to the underlying languages used in building their applications. in our research, however, we found that not to be completely accurate. In most cases, organizations have a significant investment in one or two languages and very minimal investment in any others.
Our recommendations based on our findings? Don’t be content with assumptions. Remember, all your adversary needs is one vulnerability that they can exploit. Security and development teams must continue to measure their programs on an ongoing basis. Determine how many vulnerabilities you have and then how fast you should fix them. Don’t assume that your software development lifecycle is working just because you are doing a lot of things; anything measured tends to improve over time. This report can help serve as a real-world baseline to measure against your own.