Thanks to everyone who came out to the OWASP LA event last night, it was a great meeting! I’ve had a ton of people write me for the slides, so I’m putting them up here for everyone. Be sure to view the annotations, there’s lots of background information in the presenter’s notes.
Thanks!
-Bryan
Hi all, Bryan here. If you’re in the Los Angeles area, I’d like to invite you to the presentation I’ll be giving at the OWASP LA chapter meeting on Wednesday, April 27th, titled “NoSQL, But Even Less Security.” We’ll be taking an in-depth look at some programming “worst practices” that can lead to vulnerabilities in applications using NoSQL databases such as MongoDB, Riak, CouchDB, Neo4j, or Cassandra. Here’s a sneak peek at some of the problems I’ll be talking about:
Eventual consistency. According to Eric Brewer’s CAP theorem, at any given time a system has to give up either consistency, availability, or partition tolerance: It’s impossible to always have all three. For many organizations, the whole reason they’re moving away from traditional relational SQL databases is that they want to improve scalability (i.e. partition tolerance). Since the CAP “P” is a hard requirement, you have to choose between consistency and availability, and some NoSQL databases choose availability. These are called “eventually consistent” databases, because at any given time you can’t be sure you’re seeing up-to-date data. Of course, to a security person, “eventual consistency” is just a fancy way of saying “race condition,” so we’ll be demonstrating some of those.
CSRF and REST APIs. Authentication and authorization are very weakly implemented in most NoSQL databases, if they’re implemented at all. Usually, if you can get to the port where the database is running, you have complete administrative access to it. Even assuming that you’ve closed off outside access to those ports with your firewall (I hope this is a good assumption!), you may still be vulnerable to cross-site request forgery attacks against the database REST APIs.
NoSQL injection. NoSQL databases may not have fixed schemas like SQL databases, but that doesn’t mean they’re any more resilient against injection attacks. In some cases, it makes exploitation even easier. We’ll show how ‘ OR ’1′ = ’1 still works wonders in the NoSQL space unless you’ve taken proper defensive measures.
Server-side JavaScript injection. The competition between Microsoft, Mozilla, Google and Apple to produce the fastest Web browser has given us incredibly fast JavaScript engines. (While I’m personally more than a little skeptical, some people are claiming that JavaScript outperforms C in certain benchmarks. But regardless of whether you believe this or not, you have to admit that JavaScript engines have come a long way in recent years.) Developers are taking advantage of the speed of these engines to create server-tier applications with them, notably Node.js Web servers and NoSQL databases. Now, when an attacker can inject his own script into a Web browser, we call that cross-site scripting, and we consider it one of the most serious Web application vulnerabilities there is (it’s currently #2 on the OWASP Top Ten list). But when an attacker can inject his own script into a server-side application, it’s even worse. Orders of magnitude worse. In some cases, these vulnerabilities can allow the attacker to upload and execute arbitrary binaries on the server – basically completely owning the machine.
Again, if any of this catches your interest, please stop by the OWASP LA meeting on Wednesday, April 27th. Hope to see you there! (If you’re interested but can’t make it, send me an email – brsulliv at adobe – and I’ll send you back the slides. If there’s enough interest, I’ll just post them here.)
Hi all, Bryan here – I’m back home in snowy Seattle after a fun-filled week in San Francisco for RSA Conference 2011. One of my favorite games to play at RSA each year is to identify the hot buzzword or phrase of the year: the one meme that keeps popping up in every session and every vendor’s booth. The last few years have, of course, belonged to The Cloud, and this year looked like it was shaping up to be the year of the Advanced Persistent Threat. But then a dark horse came out of nowhere and snatched the buzzword crown away. The award for most overused expression for 2011 goes to The Bear – as in: You Don’t Have to Outrun the Bear.
I’m sure everyone reading this has heard the old joke about outrunning bears before, so I won’t tell it again here. Personally, I’ve never been a big fan of this philosophy. Basically, it suggests that you don’t have to aim for perfect security; you just have to be a little bit harder to attack than the other people around you. Now I know that security is not an absolute, that there’s no such thing as perfect security. But is “let them do it to the other guy” really the best we can strive for as an industry? It reminds me of the Far Side cartoon where (ironically) a bear is caught in a hunter’s crosshairs, and he’s grinning and pointing at his friend standing next to him. It’s especially worrying to me that this message seems to resonate so well with so many people.
Since we’re already talking about clichéd expressions, take a look at the Tragedy of the Commons, if you want to know where this line of thought will take us. Or better still, adopt a security philosophy that benefits the community, maybe “a rising tide lifts all ships.” This is the attitude that the most security-mature organizations take. Adobe benefits from platform defenses created by Microsoft and Apple. Microsoft and Apple likewise benefit from application defenses we build into our products, like the Adobe Reader sandbox. Even if you don’t work for an OS vendor, you can always contribute time to an open-source security project like the OWASP projects or simply share your knowledge by writing about what you’ve learned and helping others to avoid the same mistakes.
Ok, I’m getting off my soapbox now. I promise that next time I’ll be back with a less philosophical post that has some code snippets in it. But in the meantime, remember that it’s not enough just to run faster than your friend. If he’s falling behind, grab his arm, pull him to safety, and maybe both of you can live to tell about how you outran the bear.
Security is an industry concern and not one that is limited to a select group of vendors or products. No organization is immune to vulnerabilities and exploits. It is critical that vendors and the security community at large partner and work together to try and stay ahead of the game and combat those with malicious intent.
Happy Valentine’s Day, ASSET blog readers! Bryan here, and while I don’t have any roses or chocolate truffles for you, I do have something sweet for you if you’re still struggling with Java DoS issues. As I noted earlier, Oracle has released a patch tool here; however, if you’re not able to apply this fix for some reason, I have some new malicious value detection code courtesy of Brian Chess (of Fortify/HP) that is greatly improved over my original detection code. Many thanks to Brian and to Jim Manico from OWASP for passing this along.
private static BigDecimal bigBad;
private static BigDecimal smallBad;
static {
BigDecimal one = new BigDecimal(1);
BigDecimal two = new BigDecimal(2);
BigDecimal tiny = one.divide(two.pow(1022));
bigBad = tiny.subtract(one.divide(two.pow(1076))); // 2^(-1022) 2^(-1076)
smallBad = tiny.subtract(one.divide(two.pow(1075))); // 2^(-1022) 2^(-1075)
}
public static boolean containsMagicDoSNumber(String arg) {
if (arg == null) return false; // arg is null? return.
String noDot = arg.replace(".", "");
// magic value not present? return.
if (!noDot.contains("2225073858507201")) return false;
BigDecimal bd;
try {
bd = new BigDecimal(arg);
} catch (NumberFormatException e) {
return false; // can't parse? return.
}
// smaller than the smallest bad value,
// or larger than the largest bad value? Return
if (bd.compareTo(smallBad) < 0 || bd.compareTo(bigBad) > 0) return false;
// if you get here you know you're looking at a bad value.
// The final value for any double in this range is supposed to be
// 2.2250738585072014E-308
return true;
}
Hi everyone, Bryan here. My friend Ralph is a huge gadget lover. Whenever a new piece of electronic gadgetry comes out, Ralph has to have it. 1080p 3D HDTV and Blu-ray player? Check. Latest mobile phone? Check. Wireless network music player streaming from a RAID 5 NAS home media server? Check. So of course, when Ralph bought a new car, he had to get the GPS navigation system option. Now, GPS is a very cool and useful feature: You’ll always be able to find the fastest route home, or to the nearest gas station, or in Ralph’s case, to the nearest Best Buy. But consider the cost of that feature, not in terms of dollars and cents but rather in terms of attack surface. What would happen to Ralph, if someone stole that new car? The thief would not only have the car, but he’d have directions to Ralph’s house thanks to the GPS, and when he got there, he’d be able to let himself in with the automatic garage door opener.
There’s an obvious parallel here between cars and software. Consumers love features, consumers love convenience, and these things sell products. It’s our responsibility as security architects and developers to ensure that those features and convenience don’t add unnecessary attack surface. A classic example of this is the Microsoft Web server (Internet Information Services, or IIS for short) that’s included with Windows. In Windows 2000 and earlier, IIS was not only included as part of the operating system but also installed and activated by default. For those users who needed Web server functionality, this worked well and saved them some installation time. But the majority of Windows 2000 users probably never needed a Web server. My mother ran Windows 2000 on her home PC for a while, and I’d be surprised if she even knew what a Web server was! So when a vulnerability in IIS was discovered that allowed remote anonymous users to access private files, this vulnerability ended up affecting millions of users unnecessarily.
While this lesson has been learned (Microsoft still installs IIS with Windows, but you now have to manually enable it through the administrative Console Panel), I still see a lot of unnecessary attack surface present in SaaS applications. It may be easy to set allow-access-from domain=”*” in your crossdomain.xml file, but do you really need the extra attack surface that comes from allowing the entire Internet access to your resources? In products with wiki or blog features, it’s nice to allow users to use markup in their posts, but this one simple feature greatly complicates the difficulty of defending against cross-site scripting attacks. Or let’s say you’re developing a multitenant application: Simply adding a new “ClientID” column to your database tables instead of segregating your clients’ data into separate databases may lower hardware costs, but now you’re just one SQL injection vulnerability away from leaking all of their data.
I’ll be in San Francisco for RSA Conference next week to present “Stop Exposing Yourself: Principles of Attack Surface Analysis and Reduction” (session# AND-108, Tuesday 2/15 at 3:40 PM) along with Michael Howard from the Microsoft SDL team. We’ll be discussing these scenarios and many others, and Michael will be demonstrating their new Attack Surface Analyzer tool. If you’re attending the show, I hope to see you there!
Bryan here again. First I want to thank everyone who came out for my BlackHat DC talk on application-level denial-of-service attacks last month. I got a lot of great questions and feedback from all of you. Keep it coming! And just to throw more fuel on the DoS fire, there were at least two other sessions that focused on DoS: Tom Brennan and Ryan Barnett’s “Checkmate with Denial of Service” and Laurent Oudot’s “Inglourious Hackerds: Targeting Web Clients.” While today is supposed to start the Chinese Year of the Rabbit, it’s shaping up to be more like the year of the snail…
As if to prove the point, more research surfaced this week on the “magic number” DoS vulnerability I discussed in my Black Hat presentation and in my last blog post. Konstantin Preißer discovered that Java apps, similar to PHP apps, will fall into an infinite loop and hang trying to process numeric values in the (approximate) range of 2.2250738585072011E-208 to 2.2250738585072013E-208. For the case where you’re parsing a double value in from a string, you can apply this blacklist filtering code to detect whether the string value is potentially malicious:
public static boolean containsMagicDoSNumber(String s) {
return s.replace(".", "").contains("2225073858507201");
}
Note that the range of this check is wider than the actual values that will exploit the vulnerability, so you may end up with false positive results. I’ll keep this space updated with any news of a more thorough fix from Oracle.
Update: Oracle has released a Floating Point Updater Tool to patch the issue. Please be sure to read the associated readme file for the tool before installing, as there are important caveats.
Hi everyone, Bryan Sullivan here. Nope, this isn’t just a guest post: since November, I’ve officially been a part of the Adobe Secure Software Engineering Team and I’m very excited to be here! I’ll be working on (and blogging about) Adobe’s cloud service security engineering efforts, just like I did as a member of Microsoft’s SDL team. I’m looking forward to talking more about cloud security issues and maybe posting some code snippets in a language other than C# for once. 
In fact, we can start today with some PHP code.
Earlier this week, Rick Regan, author of the Exploring Binary blog, discovered a flaw in PHP which causes PHP applications to go into an infinite loop when they attempt to process the numeric value 2.2250738585072011E-308. This one line of PHP code is enough for an attacker to be able to hang the application until it’s restarted:
<?php $number = (float) $_GET['number']; ?>
Denial of service (DoS) flaws like this one are referred to as application-level DoS vulnerabilities. The attacker doesn’t need to try to flood the target with malformed requests or use a botnet to create a distributed denial of service (DDoS) attack against the target; rather, he just exploits a hole in the application logic to throw the target into an infinite loop or an extremely long-running subroutine. Although it’s very serious and will probably end up affecting thousands of sites, the PHP flaw is just the latest of application-level DoS vulnerabilities. Other examples include zip bombs (files that decompress to sizes millions of times larger than their compressed forms), billion-laughs attacks (exponentially recursing entities in XML documents) and ReDoS (exponentially recursing regular expression evaluation strings).
The worst part about all of these techniques is that they’re both extremely effective at soaking up server resources and also extremely asymmetric in terms of attacker effort versus effect. In most cases, a single HTTP request of less than 1,000 bytes is enough to exploit the vulnerability. This essentially reduces the attacker’s cost to zero, makes it unlikely that he’ll ever be caught, and makes it even more unlikely that you’ll be able to prevent the attack with any kind of IPS or firewall. To defend against these attacks, you’ll have to make changes to your application code. (As a side note for the curious and/or terrified, the two most commonly suggested mitigations for the PHP issue are either to recompile the PHP processor itself with the -ffloat-store compiler option or to add input validation to check incoming requests for the malicious value.)
I’ll be giving a presentation at Black Hat DC later this month, titled “Hey You, Get Off of My Cloud: Denial of Service in the *aaS Era“, that takes an in-depth look at application-level DoS attacks and specifically their impact on cloud applications. With elastic computing resources, there’s less of an issue with DoS causing outages, where legitimate users can’t get access to the site, but you trade that off for a potentially bigger “economic denial-of-sustainability” issue. Since you’re paying for your cloud resources on a per-cycle/per-gigabyte/per-megabit basis, a DoS attack could very quickly overcome your budget and force you to take the site down yourself. For the attackers, this has an added bonus in that they can provide you with metrics when they deliver their blackmail demands. “Give us $25,000 or we’ll take down your site” is bad enough, but “Give us $25,000 or we’ll soak up $50,000 worth of cloud resources” is worse still.
I do look forward to seeing you in Washington, DC in a few weeks and to discussing this surprisingly under-appreciated problem in more depth. And if you can’t make it out but still want to learn more, please feel free to email me: My Adobe email alias is brsulliv. Thanks, and we’ll talk again soon!
