By- March 10, 2017
NOTE: Tinfoil’s web application scanner now looks for Strutshock! Sign up and start a free trial here. We also have a checker for only Strutshock here. Simply input your URL to see if you are vulnerable.
If you’ve been keeping up with the security community lately, you’ve probably heard about the Struts 2 vulnerability (CVE-2017-5638) announced by Apache a couple days ago. This allows for remote code execution due to improper handling of the Content-Type header by the Jakarta Multipart parser. Thus, an attacker can gain full access to and control of any information stored on a server.
How is this being exploited?
When an invalid Content-Type header is parsed by the Jakarta Multipart Parser, an exception is raised. The raised exception includes the invalid Content-Type header in the message. Unfortunately, if the header includes OGNL (Object Graph Navigation Language), the OGNL is evaluated before being returned. This allows an attacker to execute arbitrary code in the exception handler.
Who is affected?
Anyone currently using Apache Struts 2.3.5 - Struts 2.3.31 or Apache Struts 2.5 - Struts 2.5.10. If you’re not sure whether or not you’ve been affected, we’ve included our Strutshock test, for anyone, as part of our free trial once you’ve verified ownership of your website.
What should I upgrade to?
Upgrade to Apache Struts 2.3.32 or Apache Struts 126.96.36.199.
I can’t upgrade right now, is there a workaround?
Yes, two workarounds were recently published on the Apache Struts 2 documentation. However, we highly suggest upgrading to a patched version as soon as possible.
Why was there an increase in attacks after the patch?
When the patch was released on March 6, less than a day later, a GitHub issue was opened on Rapid7’s Metasploit framework, an open source project, that included sample code allowing anyone to exploit the vulnerability. According to Cisco Talos, this resulted in immediate exploitation, and the rate of exploitation has remained steady since. If the severity doesn’t worry you, the fact that this attack is easy to reproduce and incredibly widespread should.
By- October 06, 2015
If you’ve been keeping up with recent browser developments you may have noticed that in the past few weeks both Chrome and Firefox have started to support subresource integrity, with companies like Github making an active push for other sites to make use of the functionality. This is a low-risk change that offers tremendous security gains for your users, so we just pushed out an update that makes it easier to start using subresource integrity on your website.
As is the nature of loading arbitrary code, this has always opened up websites to the possibility of being attacked through their CDN: an insecure or malicious CDN holds the potential to insert malicious code onto any website to which it serves assets. Subresource integrity serves to mitigate this attack by ensuring that all loaded resources contain the exact content expected by the website. This is done through the use of a cryptographic digest, computed on all fetched resources, that is then compared against an expected digest. This provides the browser the capability of detecting resources that have been tampered with, allowing it the opportunity to abort the loading of the resources before any malicious code is executed.
Protecting a resource is done by adding the “integrity” attribute to an asset’s HTML tag:
<script src="https://example.com/include.js" integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE=" crossorigin="anonymous"></script>
It’s an elegant solution to a very serious risk, and it’s a solution we recommend implementing. It won’t secure all of your users, with Microsoft Edge still not supporting the feature, but it can serve as a valuable line of defense in the event of a breach of your CDN. Many of the popular web frameworks provide libraries that make it easy to enable subresource integrity on your assets, and further instructions on making use of the technology are available on the Mozilla Developer Network.
Going forward, all Tinfoil Security scans will flag external resources that are not protected by subresource integrity. Give it a try by signing up for our 30-day free trial.
By- June 03, 2015
Tinfoil Security is proud to announce a brand new partnership with Microsoft Azure, to provide their customers unparallelled web application security for their Azure Web Apps—the first such security solution to be offered on the Azure Marketplace. Microsoft has long been known for making it incredibly easy to build and deploy web applications, but customers always had to go elsewhere to ensure those same applications were safe and secure. Now, with the launch of this exciting partnership, it’s never been easier for you to secure your application. Tinfoil Security is built into your Azure Web Apps management portal, and can be set up with just the click of a button.
Microsoft Azure provides its customers industry-leading protection at the network and data-center level, but previously offered no web application security solutions. Now, with the aid of Tinfoil Security, Microsoft Azure’s customers finally have an easy way to secure their entire software stack.
Starting today, you can secure your Azure Web Apps by continuously scanning them for vulnerabilities. You’ll be scanned for over 60 types of vulnerabilities, including the OWASP Top 10, and we’ll provide detailed instructions on fixing every vulnerability we find.
Furthermore, we’ve added the ability to convert your scan results into ModSecurity rules. ModSecurity is a web application firewall (WAF) that Microsoft Azure includes as part of their Web Apps Service; think of ModSecurity as a layer in front of your application that inspects requests and decides whether or not to block them based on rules you’ve configured. As of today, you can enable our ModSecurity rules to help prevent attacks while you fix each underlying issue we discover. Tinfoil and Azure make this process easy, fast, and consistent.
Tinfoil has always had a great respect for Microsoft and, specifically, for the Azure team. When we first interacted with them back in 2013, we were left with the distinct impression that we shared both vision and goals: an extreme focus on the user experience, an intention to make development easier than ever before, and an understanding that security is a necessary and paramount part of the development process, especially as more and more companies continue to get breached and lose sensitive customer data.
This partnership has been a long time coming. We explored many different routes as we investigated how we could best offer our best-in-breed security and couple it with Azure’s top-notch build and deploy user experience. We’re proud to announce what we genuinely believe is the most valuable solution to Azure and Tinfoil customers alike.
We hope you’re as excited as we are about this exciting new offer for Microsoft Azure customers, so please don’t hesitate to let us know what you think.
Click here to get started on securing your Microsoft Azure Web Apps today.
If you’re not on the Azure platform, or if you want to integrate security deeper into your development and DevOps process, feel free to check out our main product at https://www.tinfoilsecurity.com.
By- March 17, 2015
Security is hard to get right. Between Cross-Site Scripting (XSS) and SQL Injection (SQLi) alone, there are more ways to make mistakes than any developer can possibly be expected to keep track of manually -- and those are just the two most well-known types of vulnerabilities. Most developers have never even heard of more obscure attacks, like XML External Entity Injection (XXE), and yet a well-placed attack can be just as devastating as the most egregious XSS injection.
We’ll explain what exactly an XXE attack is later, but first it’s important to have a basic understanding of the anatomy of an XML document. XML, or Extensible Markup Language, is a format used to describe the structure of documents, such as web pages. For example, the following XML document might describe a blog post:
<?xml version="1.0" ?> <post> <title>Smashing the Stack for Fun and Profit</title> <author>Aleph One</author> <content> Over the last few months there has been a large increase of buffer overflow vulnerabilities being both discovered and exploited... </content> </post>
In the above document, there’s a few key pieces of terminology to keep track of. Firstly, a tag is a pair of angle brackets surrounded a name. Both <author> and </title> are examples of tags. More important are the logical components of the document, known as elements. One such element above is <author>Aleph One</author>.
A slightly more complicated document might look like the following:
<?xml version="1.0" ?> <!DOCTYPE author [ <!ELEMENT author ANY> <!ENTITY author "Shane Wilton"> ]> <author>&author;</author>
In this case we’ve defined an entity: essentially a mapping from some name to a value. When this XML document is processed, any instances of “&author;” are going to be expanded to “Shane Wilton”. This is known as internal entity processing, and it is typically used to allow for the modular design of XML documents.
An XXE attack works by taking advantage of a little-known feature of XML -- external entities. The concept is the same as in internal entity processing, but the attack vector lies in being able to use external resources as the replacement text. For example, consider the following document:
<?xml version="1.0" ?> <!DOCTYPE passwd [ <!ELEMENT passwd ANY> <!ENTITY passwd SYSTEM "file:///etc/passwd"> ]> <passwd>&passwd;</passwd>
When the above document is parsed, the “passwd” element is going to be expanded to contain the contents of “/etc/passwd”.
If a web application accepts user-created XML documents as input, or input which is otherwise used in the creation of XML documents, an attacker is able to use XML entity expansion to load files or other URI-referenceable resources into the web application. If this information is then displayed back to the attacker at a later point, then they’ll find themselves able to exfiltrate possibly privileged information.
Furthermore, by loading a stream of infinite data, like /dev/urandom, an attacker is able to consume all of a system’s resources, denying access to other users.
In some rare cases, it may be possible to gain remote code execution by loading executable code (Such as PHP), or by using the XXE attack as a beachhead to access other, more insecure, internal services. This was exactly the case last year, when a Brazilian engineer used an XXE attack to gain remote code execution against Facebook, earning their largest bug bounty payout to date. His impressive write-up can be read here.
XML External Entity Processing is by no means a complicated bug, but it is difficult to test for. There’s so many variables involved in launching a successful attack, that software engineers simply don’t have the time to invest in performing a full audit of their XML parsing capabilities, if they’re even aware of the possibility of XXE in the first place. That’s why we’re proud to announce that Tinfoil Security now supports automated scanning for XXE attacks, and for the next month, we'll also be scanning all of our free members, at no charge.
Sign up today, so your engineers can spend their time building your product, and we can spend our time worrying about the minutiæ of XML parsing.
By- February 23, 2015
Very often, we scan a site that has hundreds or even thousands of vulnerabilities. Some of our customers are large Fortune100 companies with many web properties, so inevitably there will be some that are the metaphorical equivalent of swiss cheese, while others are absolutely bulletproof. We kept hearing feedback that while our reports were incredibly useful, for websites with a large number of vulnerabilities they could get a bit overwhelming.
"Overwhelming" is a word we do everything in our power to avoid being described as, so we've built a new view for vulnerability analysis that we hope you'll like and find to be much more concise and easy to read. Don't worry, it's not replacing the See & Fix view you've grown to know and love; rather, it is a separate view that aggregates many vulnerabilities into a simple and easy-to-parse condensed report. We're pretty proud of it, and it looks like this:
You can perform nearly all of the same actions as you can with our regular See & Fix view, but you can get an at-a-glance status on how you've progressed at fixing the vulnerabilities we've found, see immediately what's left to be done, and notice commonalities among the vulnerabilities that were found. Outside of using our API to grab reports and statistics (which you're still free to do), this simply wasn't possible before. We think it will help enable our larger enterprise customers to fix vulnerabilties faster, feel more comfortable with how their state of security is progressing, and know exactly what types of issues they need to work on and look out for more carefully.
Please let us know what you think. We're always trying to innovate and give you your data in ways you've never seen. Try it, use it, and tell us how to make it even better for you.
Tinfoil Security provides the simplest security solution. With Tinfoil Security, your site is routinely monitored and checked for vulnerabilities using a scanner that's constantly updated. Using the same techniques as malicious hackers, we systematically test all the access points, instantly notifying you when there's a threat and giving you step-by-step instructions, tailored to your software stack, to eliminate it. You have a lot to manage; let us manage your website's security.