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.
By- October 23, 2014
In another blog post, I discussed a vulnerability called Cross-Site Request Forgery (CSRF) that allows an attacker to force a victim to perform actions on their logged-in sites inadvertently. The defense I recommended was called the Synchronizer Token Pattern, as the defense relies on using randomly-generated tokens to which attackers would not have access. Hackers are both clever and resourceful, however, and if your website is vulnerable to a technique called clickjacking, attackers can force victims of your site to perform unwanted actions even if proper CSRF protections are in place.
This attack is best understood visually. Let’s suppose, only for illustration, that eBay is vulnerable to clickjacking—meaning that an attacker could embed an eBay page in an iframe on their own site. A product listing page looks like the following.
An attacker can construct a website that contains a really enticing button, just begging to be clicked.
Then, they can precisely overlay the eBay iframe so that the “Buy It Now” button sits perfectly on top of the “FREE” button. The following uses a semi-transparent iframe for illustration purposes.
Lastly, they can make the iframe invisible, yet still technically “on top of” the site’s content, so when the user thinks they’ve just clicked on a link, they actually became proud owners of a new car.
In the above example, an attacker can trick an unsuspecting user into buying a Ford. Even if the “Buy It Now” button is inside of a CSRF-protected form, the request goes through, the website has no way to distinguish an intentional click from one contrived by an attacker. This same attack can be used to cause the user harm, such as tricking them into deleting all of their emails by lining up the “Delete All” button under the “FREE” button. An attacker could also trick the user into opening themselves up to further attack by disabling defenses and enabling your webcam. If that’s not scary enough, or you already cover your webcam with black tape, an attacker can construct a precise combination of malicious text fields and buttons and trick a victim into resetting their password for another service.
To prevent this attack, you need to prevent the ability for your site to be embedded as a frame in another site. There are two ways to solve this. In short, there is the established way and the new way. Since we’re in the middle of a transition phase—the new way is still very new and not widely supported—I recommend doing both, to prepare yourself for the inevitable day when the old way is deprecated.
The common way this is done is by adding an HTTP header that serves just this purpose:
X-Frame-Options. As you may know, the
X- prefix indicates that this is a non-standard header; however, this header is understood by all major browsers, including Chrome, Safari, Opera, Firefox, and Internet Explorer 8 and newer. Browsers refuse to load content in an iframe if that content includes this header and the header disallows it. The header has two possible values:
DENY is self-explanatory, and
SAMEORIGIN allows the page to be embedded only within the same domain as the embedding site. There does exist a third option called
ALLOW-FROM uri, but neither Chrome nor Safari plan to support it. Therefore, I do not recommend using
ALLOW-FROM at all.
There’s a new all-encompassing HTTP header that’s on its way to becoming a standard. It’s called
Content-Security-Policy (CSP). The
frame-ancestors, a whitelist of trusted sources that are allowed to include your page in a frame.
If you want to prevent framing of your page entirely, use the CSP header like this:
Content-Security-Policy: frame-ancestors 'none'
To allow framing only within your own site, you can replace
'self'. Alternatively, you can supply a list of allowed, trusted domains. Like all aspects of CSP, it’s very flexible.
Content-Security-Policy: frame-ancestors tinfoilsecurity.com example.com
You can use an automated web security scanner like Tinfoil to crawl your site and ensure that no page is vulnerable to clickjacking. Tinfoil provides the best web application security solution on the market, and it detects clickjacking vulnerabilities on your website along with many other types of web vulnerabilities.
By- October 16, 2014
The internet has been in an uproar over the past few days as a result of Google’s announcement of the POODLE vulnerability, which effectively breaks SSLv3 completely. We’ve scanned every single site that has passed verification with Tinfoil Security (that is, signed up and verified ownership) using our free testing tool, and sent emails to all those customers that have vulnerable sites. Our anonymized statistics of websites that have been tested show that 68%—that is, more than two-thirds—of the internet is vulnerable as I write this.
There has been a lot of misinformation flying around the internet over the past few days, and a lot of overly technical (or not technical enough) “how to” guides that are actually incorrect. This isn’t because the internet intends to mislead, but simply because cryptography of any sort, but especially TLS/SSL, is hard. We don’t claim to be experts, but we try really hard to be well-versed. With that in mind, this is our guide on how to protect your servers and what mistakes you’ve probably (unintentionally) made.
The simplest thing to think is “OK, so it looks like if I disable any cipher suite that has CBC in the name, I’ll be fine.” This is wrong, and everyone is doing it, because it is what everyone is recommending.
There are a number of cipher suites, specifically
AES256-SHA, and similar, that do not contain CBC in the OpenSSL cipher suite name. In reality, these cipher suites are named
TLS_RSA_WITH_AES_256_CBC_SHA, respectively. These cipher suites do work in CBC mode, no matter what OpenSSL chooses to call them!
We’ve disclosed this exact vulnerability to many companies at this point, including some large, extremely engineering-focused companies I guarantee you've heard of, all of whom have mitigated it now by disabling these last few ciphers. Given that we continue to see this exact mistake across most of the websites we’re testing, you should make sure you check it on yours too.
Disable SSLv3 completely. Do not support it as a protocol at all, and reject any clients which require it. Unfortunately, this proves hard to do for many companies, as they have legacy clients whom they need to support that only support SSLv3 (specifically, IE6 on Windows XP and older Android clients, usually).
Our recommendation is simple: if, in any way, you can completely disable support for older clients that require SSLv3 and disable support for that protocol entirely, please do it.
If you must maintain support for SSLv3, your next best option is to enable the
TLS_FALLBACK_SCSV cipher suite value. This cipher is a patch submitted to OpenSSL by Google (the same guys who found the exploit in the first place). This cipher solves the issue of retrying failed connections, thus preventing attackers from forcing browsers to use SSLv3. Additionally, it may also help prevent future exploits, as it prevents downgrading from TLS 1.2 to 1.1 or 1.0 as well.
Our recommendation: Make sure that you support the
TLS_FALLBACK_SCSV cipher suite value. If you use OpenSSL 1.0.1, make sure you upgrade to 1.0.1j. Similarly, if you use 1.0.0, make sure to upgrade to 1.0.0o, and if you use OpenSSL 0.9.8, upgrade to 0.9.8zc.
If you cannot disable SSLv3, and if you cannot upgrade OpenSSL to support
TLS_FALLBACK_SCSV for some reason, you have one additional option left: carefully disable all cipher suites for SSLv3 that run in CBC (cipher-block chaining) mode. Really, you should do this anyway, since
TLS_FALLBACK_SCSV doesn’t actually resolve POODLE for anybody using SSLv3, it just prevents any newer clients from downgrading to SSLv3 and thus becoming vulnerable, limiting the number of clients that are affected.
This means that if you have to use SSLv3, your only real option left is to use some form of an RC4 cipher. This also isn’t perfect (there is a known attack on it by way of Royal Holloway, but it requires 224 connections), but is better than using any of these CBC ciphers which can be broken much faster.
If your configuration doesn't allow you to disable these CBC ciphers only for SSLv3 (for example, if you run nginx), you should consider using something like HAProxy to terminate SSL traffic in front of it and disabling / redirecting around it there. This, however, is hard and prone to error so you can go with the next recommended option: make sure your preferred cipher is set to RC4, rather than any CBC cipher.
Our recommendation: The following cipher suites that SSLv3 is able to use must be disabled in order to effectively prevent POODLE:
IDEA-CBC-SHA, EXP-DES-CBC-SHA, DES-CBC-SHA, DES-CBC3-SHA, EXP-DH-DSS-DES-CBC-SHA, DH-DSS-DES-CBC-SHA, DH-DSS-DES-CBC3-SHA, EXP-DH-RSA-DES-CBC-SHA, DH-RSA-DES-CBC-SHA, DH-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA, EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-ADH-DES-CBC-SHA, ADH-DES-CBC-SHA, ADH-DES-CBC3-SHA, EXP-RC2-CBC-MD5, IDEA-CBC-SHA, EXP-DES-CBC-SHA, DES-CBC-SHA, DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA, EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, ADH-DES-CBC-SHA, ADH-DES-CBC3-SHA, AES128-SHA, AES256-SHA, DH-DSS-AES128-SHA, DH-DSS-AES256-SHA, DH-RSA-AES128-SHA, DH-RSA-AES256-SHA, DHE-DSS-AES128-SHA, DHE-DSS-AES256-SHA, DHE-RSA-AES128-SHA, DHE-RSA-AES256-SHA, ADH-AES128-SHA, ADH-AES256-SHA
We’ve been updating our tester constantly and improving its detection and results. We’ve added even more information regarding supported ciphers and the like. When you think you’ve fixed your server against POODLE, you should run another check.
We will continue to keep our eyes on this and attempt to update this post with more ways companies are making common mistakes in mitigating this attack, but if you follow the above directions, you should be OK. Scan yourself for even more vulnerabilities using the button below.
By- October 14, 2014
Today we're excited to introduce our newest enterprise feature: tunneled scans. Private tunnels are a secure, encrypted connection between your private web application and Tinfoil's scanners. We've simplified the popular open-source tool Ngrok to make it as easy as possible to scan your sites with Tinfoil, without having to host and manage an extensive on-premise solution. With the Bifrost Tunnel you can perform security scans on:
Get started by installing and activating a simple client application, available on all major platforms. Currently the Bifrost Tunnel is running in a closed beta for our enterprise customers. Interested in trying it out?
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.