Research

Simple website compromises can feel like crimes with no clear victims. Who cares if the Joey’s Bag of Donuts website gets popped? But that is not a defensible position any more. Attackers don’t just steal data from these websites – they also use them to host malware, command and control nodes, and proxies to defeat IP reputation systems. Even today, strange as it sounds, far too many websites have no protection at all. They are built on vulnerable technologies without a thought for securing critical data, and then let loose in a very hostile world. These sites are sitting ducks for script kiddies and organized crime. In this paper we took a step back to write about protecting websites using Security as a Service (SECaaS) offerings. We used our Quick Wins framework to focus on how Website Protection Services can protect web properties quickly and without fuss. Of course it’s completely valid to deploy and manage your own devices to protect your websites; but Mr. Market tells us every day that the advantages of an always-on, simple-to-deploy, and secure-enough service consistently win out over yet another complex device in the network perimeter. The landing page is in our Research Library. You can also download Quick Wins with Website Protection Services (PDF) directly. We would like to thank Akamai Technologies for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without companies licensing our content. Share:

Today’s post will discuss database denial of service attacks so later we can consider how to stop them. From the security researcher’s perspective I cannot help but be impressed by the diversity of database DoS attacks. Many such attacks are pretty dumb – they seem to be written by a person who does not understand SQL, writing horrible queries that are the opposite of efficient. Some exploits are so simple – yet clever – that we are amazed the targeted vulnerability was not found in quality assurance tests. But dumb or not, these attacks are effective. For example you could start a couple different searches on a website, choose a very broad list of values, and hit ‘search’. The backend relational system starts to look at every record in every table, chewing up memory and waiting for slow disk reads. Let’s look more closely at a couple different classes of denial of service attacks: Abuse of Functions The abuse of database functions is, by my count of reported vulnerabilities related to DoS, the single most common type of database DoS attack. There have been hundreds, and it seems like no externally accessible feature is safe. This class of attack is a bit like competitive judo: as you shift your weight in one direction, your opponent pushes you in the same direction to make you lose your balance and fall over. A judo expert will use your weight against you, just like an attacker uses database features against you. For example, if you implement restrictions on failed logins attackers may try bad passwords until they lock all legitimate users out. If you implement services to automatically scale up to handle user requests attackers can scale the database up until it collapses under its own weight, or the bill becomes ruinous, or you hit a billing threshold and service is shut down. There is no single attack vector, but there is a whole range of ways to misuse database features. This class of attacks is essentially an attacker getting a database function to misbehave. Typically it occurs when a database command confuses the database, the query parser, or a sub-function enough to lock up or crashes. Relational databases are complex gestalts of many interdependent processes, so the loss of a single service can often cause the entire database to grind to a halt. One example is an attacker sending malformed Remote Procedure Calls, incomprehensible to the parser, which cause it to simply stop. Malformed XML and TDS calls have been used the same way, as well as SNMP queries. Pretty much every database communication protocol has, at one time or another, been fooled or subverted by requests that are formatted correctly but violate the expectations of the database developers in some way that causes a problem. SQL injection is the best known type of functional abuse: SQL strings are bound into a variable passed to the database, so the database processes a very different query than was expected. SQLi is not typically associated with DoS – it is more often employed as a first step in a database takeover because most attackers want to control the database but don’t want to be detected, but it SQL injection works and is used in both ways. Back to judo: every feature you have can be used against you. Complex Queries Complex queries are an attack class that works by giving the database too much work to do. Attackers find the most resource-intensive process accessible, and kick off a few dozen requests. Computed columns and views: Computed columns are virtual columns, typically created from the results of a query, and usually stored in memory. A view is a virtual table, the contents of which are also derived from a query. If the query selects a large amount of data the results occupy a large space in memory. And if the column or view is based on a complex query, it requires significant processing power to create. Exposure of computed columns and views has been the source of database DoS attacks in the past, with attackers continually refreshing views to slow down the database. Nested queries & recursion: Recursion is when a program calls itself; each time it recreates declared parameters or variables in memory. A common attack is to place a recursive call within a cursor FOR loop; after a few thousand iterations the database runs out of cursors or memory and comes to a halt. The IN operator: This operator tests whether a supplied variable matches any value within a set. The operation itself is very slow – even if the number of values to be compared is small. An attacker can inject the IN operator into a query to compare a large set of values against a variable that never matches. This is also called the snowflake search because it is like attempting to match two unique snowflakes, but the database continues to search regardless. Cartesian products and joins: The JOIN operation combines rows from two or more tables. A cartesian product is the sum of all rows from all tables specified in the FROM clause. Queries which calculate cartesian products on a few large tables generate huge result sets – possibly as large as the entire database. Any operations on a cartesian product can overwhelm a database. User defined functions: Similar to computed columns and views, any user-defined function gives an attacker carte blanche to abuse the database with whatever query they choose. Attackers leverage any of the above complex queries. Attackers attempt to exploit any complex query they can access. All these abuses are predicated on the attacker being able to inject SQL into some part of the database or abuse legitimate instances of complex operations. A couple complex queries running in parallel are enough to consume the majority of a database platform’s resources, badly slowing or completely stopping the database. Bugs and Defects Attackers exploit defects by targeting a specific weakness or bug in the database. To succeed the attacker needs to know or guess the type of database in use, and must know or learn of a weakness in code or design that can

During the week of July 4th in the US we cannot help but think about independence. First of all, it’s a great excuse for a party and BBQ, right? To celebrate our escape from the tyranny of rulers from a far-off land, we eat and drink beer until we want to puke, and blow up fireworks made in other far-off lands. Being serious for a moment (but only a moment, we promise), independence means a lot of things to a lot of people, and now is a good time to revisit what it means to you, and make sure your choices reflect your beliefs. With the recent media frenzy around Snowden and NSA surveillance, many folks are questioning how the government justifies their actions under the heading of defending independence. Lots of folk aren’t sure which presents a greater threat to our independence – the bad guys or the government. Regardless of which side of that fence you take, folks in the US at least have an opportunity to discuss and exercise our rights to maintain that independence. Many folks, in many countries, take to the streets in protest every day, fighting like hell to get half the rights Americans have. So as you slug down your tenth beer on Thursday, keep that in mind. The truth is that I don’t really think much about those macro issues. I’m one of the silly few who still appreciate that living in the US affords me opportunities I couldn’t readily get elsewhere. I choose to be thankful that the founding fathers had the stones to fight for this country, and the foresight to put in place a system that has held up pretty well for a couple hundred years. Is it perfect? No, nothing is. But compared to the other options it is definitely okay. I struggle to be optimistic about most things, but I’m pretty optimistic about the opportunities ahead of me, and I’ll be drinking to that on Thursday. And I may even drink some American beer for good measure. But independence has a different context in my day-to-day life. I spend a lot of my time ensuring my kids grow up as independent, productive members of society. Whether that means leading by example by showing them a strong work ethic, providing for their needs (and my kids want for nothing), or helping them navigate today’s tech-enabled social-media-obsessed reality, the more we can prepare them for the real world the less unsettling their path to adulthood will be. That’s why we send them away to camp each year. Sure it’s fun (as I described last week), but it also allows them to learn independence before they are really independent. A side benefit is that the Boss and I get a few weeks of independence from the day-to-day challenges of being actively engaged parents. I’m not sure what the Founding Fathers would have thought about sending their kids away to camp (although I’m sure the political pundits on cable news has an idea – they know what the founders would have thought about everything), and I don’t much care. It works for us. And with that it is time to head down to see the Braves scalp the Marlins tonight. Summer camp isn’t only for kids. –Mike Photo credit: “Independence Mine State Park” originally uploaded by Kwong Yee Cheng Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Database Denial of Service Introduction API Gateways Key Management Developer Tools Access Provisioning Security Enabling Innovation Security Analytics with Big Data Deployment Issues Integration New Events and New Approaches Use Cases Introduction Newly Published Papers Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Understanding and Selecting a Key Management Solution Building an Early Warning System Implementing and Managing Patch and Configuration Management Incite 4 U (Certified) content is king: Mozilla’s new mixed content blocker feature rolled out with the beta release of Firefox version 23. The feature provides three basic advantages: content privacy, man-in-the-middle (MitM) protection, and multi-site validation. It provides these capabilities by forcing HTTP to HTTPS and validating site certificates. All content is encrypted, and provided the site certs are valid, you get reasonable assurance that you are connected to your intended site. Content from non-HTTPS sources is ignored. I am one of the last at Securosis who continues to use Firefox as my primary browser. It has a bunch of weird usability anomalies but I find my combination of basic features and security extensions (NoScript, Ghostery, & 1Password) indispensable. – AL You must tuna SIEM: Yes, that is a lame play on the REO Speedwagon album (You Can Tune a Piano, but You Can’t Tuna Fish), but Xavier’s point “Out of the Box” SIEM? Never is right on the money. These tools need tuning, period. Xavier “… demonstrate[s] that a good SIEM must be one deployed for your devices and applications by you and for your business!” It cannot be generic – the out-of-the-box stuff provides a starting point but requires substantial work to be operational and useful in your environment. Xavier even includes screen shots and pokes fun at built-in compliance reports. One-click PCI reports? Not so much. This post is full of win! But don’t lose sight of the point. Monitoring out of the box is not very useful. Just dealing with the noise would be a full-time gig. So make sure that any planned deployment has adequate time and resources allocated to tuna SIEM. Unless you want some more very expensive shelfware. – MR Spurn the scumbag, update the law: Over the past twenty or thirty years technology has moved so rapidly, and changed society so fundamentally, that our laws haven’t come close to keeping up. The problem is exacerbated by lobbying efforts and elected officials and aides who lack the fundamental knowledge

An OpenStack Security Guide epub was released this week, and among the contributors was our friend Andrew Hay. Trying to find this info before was like locating a piece of hay in a haystack (not an Andrew Hay – he would be considerably easier to find in a haystack). We use OpenStack for the Cloud Security Alliance training labs, and I had to figure out a lot of this myself through painful reading of barely-legible documentation. The book was created in a 5-day sprint so it’s a little rough. Some sections are pretty light but they intend to improve it over time. The sections on hardening the Keystone identity service, picking a hypervisor, hardening core services such as the message queue, and secure networking, are pretty decent. You can’t secure OpenStack just by reading this – you need to understand the platform first – but this guide will definitely point you in the right directions. Share:

The FTC has issued new rules on data collection for minors: Now, the list of what counts as “personal information” has been expanded to include geolocation markers, IP addresses, pictures or audio of the child, and persistent cookies that can track users across sites. The rules also now apply to companies that make plug-ins or advertising networks, which often collect information but aren’t thought of as discrete sites that fall under the rules. I’m pulling my kids from daycare and having them do all my browsing. Then I can sue Google and anyone else who tracks me them. Share:

One of our favorite friends, Jack Daniels, has a new post on Active Defense: If you make the claim that “active defense” is only a euphemism for “hacking back”, you are either hyping an agenda, or selling a (probably outdated) security model. Or perhaps you’ve just been misled by the previously mentioned shysters. By my count that’s three flavors of wrong, although one may be slightly less bitter. … Let’s start with “active defense”. It is not a new idea, and it doesn’t necessarily mean hacking back. It may encompass counterattacks, but there are a lot of active defenses far short of attack. I refer you back to my post on active defense definitions last summer. I really don’t know where all the confusion is coming from – I meet almost no security professionals who don’t understand the difference. It seems to be more of a press/PR issue. Share:

For developers one of the most visible API gateway operations is key management. But dear reader this is not your father’s key management – the kind laden with X.509, PKI, and baroque foofaraw that security teams had to beg developers to implement. This is 2013 and the keys are OAuth access keys! And developers are asking us for the keys too, so what should we do? Before we answer that question, for those of you who are not programmers, let’s describe these “access keys” in a little detail. OAuth is a method for authorizing clients (end users and client applications) to use the third party APIs served by the API gateway. It is essentially how developers give access to consumers without consumers needing to share information such as user name and password. OAuth relies upon a trusted identity service to vouch for the client and pass an authorization token to the API, which in turn gives the client access. OAuth enables four parties (a user or consumer, a client application created by a third-party developer, the owner of the APIs, and an identity service provider such as Google or Facebook) to cooperate onto deliver services. As we have discussed, developers are not much keener on the theoretical underpinnings of different identity protocols than the consumers who use their applications. They just want to get their users access to the application so they can move on to more ‘meaningful’ development tasks – like building the client application itself… This shifts the responsibility of identity and authorization onto security teams, which is a new position for them to be in: managing the process instead of cleaning up afterward. Rather than engaging toward the end of a project to conduct a vulnerability assessment, security teams may select identity protocols to be used, establish identity requirements, and guide developers through the process of building them into their applications. This is an unusual collaboration between developers and security – in both degree and kind. The role of the security team as leader for a portion of the development process sets them up as a true design and development partner. Key setup & distribution Setting up keys can be handled in several different ways, but the process is typically initiated through self-service features of the gateway (we told you it’s not your father’s PKI). The developer registers their application and client(s). The steps of the OAuth protocol dance vary by implementation, but the core generally includes: Developer account: A master account for the developer, which could span multiple clients and services Client ID: The key that identifies the consumer and grants access Client secret: How the consumer authenticates Client types: Gateways use these to distinguish between different clients such as iOS and Android Resource: The URLs, redirects and other services the client is requesting access to Once this bootstrap process is complete – whatever variation your API gateway uses – the client application developer should have everything they need. Once the client has their authorization access token they are able to call the APIs and access data with their token. Each subsequent call to the APIs protected by the API gateway includes an OAuth access token. The tokens are passed along with every call from the client app to the API so the API can make access control decisions. This brings up an important part of OAuth’s value proposition: the process of acquiring a token and using a token are kept separate. One implication is that the enterprise security architect must ensure that though these two independent processes – token issuance and token usage – are separate, their policy and governance models are consistent. Users should only be allowed access to the APIs they are authorized for, and not to see other APIs or other users’ data. The access rights requested at token issuance must match runtime behavior. Key verification services Developers may not be that interested in identity protocols but they are all interested in whether their code works. Distributed applications are notoriously difficult to debug, so anything fundamental to operations must be tested. Once access keys are issued and ready for use the API gateway should offer testing tools to ensure there are no surprises at runtime. The API provider should actively help validate the client code to protect their API! There are a number of considerations: Ensure a production-like system is available for testing. Any networked application must deal with a myriad of issues such as ports, routing, and redirects. A token cannot simply be appended to access and refresh requests – each variant of API usage requires its own test cases. Make simple tools available – many APIs include simple cURL scripts to test applications. For example: “curl https://example.com/API/myservice -H ‘Authorization: your OAuth access token’” The gateway should include several scripts to validate client usage of the API. Provide documentation and guidance for more testing and debug functionality as needed for the client environment. Key lifecycle management OAuth isn’t magic security dust, and using it doesn’t make an application secure. API developers and consumers need to be clear on safe handling of OAuth tokens across their entire lifecycle. Some rules are straightforward, such as always use TLS/SSL. But most are context dependent, such as secure storage for tokens and safe handling of redirects. Two operations that generally require special attention in security policy are refresh and revocation. OAuth access tokens provide shorter-lived access but can create long-lived sessions through with refresh tokens. The refresh token is effectively a protection against an access token being replayed. So each consumer may have two different types of tokens. Security policy makers should align these policies and make use of the separation between shorter-lived access tokens and longer-lived refresh tokens. Policy is not as simple as “one and done”. In addition to refreshing sessions, access revocation requires consideration. Token revocation may seem minor but anyone who has lost their mobile device can say with authority that it is nice to be able to log into twitter.com and turn off access to your lost mobile phone so its clients no longer

Andy Ellis (yes, @csoandy) had a good educational post on DNS Reflection attacks. The DrDos (no, Digital Research DOS isn’t making a comeback – dating myself FTW) has proven an effective way for attackers to scale Denial of Service (DoS) attacks to over 100gbps. Andy explains how DNS Reflection works, why it’s hard to deal with, and what targets can do to defend themselves. The first line of defense is always capacity. Without enough bandwidth at the front of your defenses, nothing else matters. This needs to be measurable both in raw bandwidth, as well as in packets per second, because hardware often has much lower bandwidth capacity as packet sizes shrink. He also mentions filtering out DNS requests and protecting your DNS servers, among other tactics. If you haven’t had the pleasure of being pummeled by a DoS, and having it magnified by reflection attacks, you probably will. So learning as much as you can and making sure you have proper defenses can help you keep sites up and running. Share:

Our schedules are already filling up for Black Hat this year, so if you want to meet please drop us a line. And for those who want a real schedule, [James Arlen put one together for easy import into your calendar].(https://www.google.com/calendar/ical/f9lvmur9pjc2r1oi7psi3li40s%40group.calendar.google.com/public/basic. Share:

Branden Williams is exactly right: 2013 is a pivotal year for PCI DSS. A new version of the guidance will hit later this year. So why is 2013 so important for PCI DSS? In this next revision (which will be released this year, enforced in 2015, and retired at the end of 2017) the standard has to play catch up. It’s notoriously been behind the times when it comes to the types of attacks that merchants face (albeit, most merchants don’t even follow PCI DSS well enough to see if compliance could prevent a breach), but now it’s way behind the times on the technologies that drive business. Enforced in 2015. Yeah, 2015. You know, things change pretty quickly in technology – especially for attackers. But the rub is that the size and disruption of infrastructure changes for the large retailers who control the PCI DSS mean they cannot update their stuff fast enough. So they only update the DSS on a 3-year cycle to allow time to implement the changes (and keep the ROC). Let’s be clear: attackers are not waiting for the new version of PCI to figure out ways to bust new technologies. Did you think they were waiting to figure out how to game mobile payments? Of course not – but no specific guidance will be in play for at least 2 years. Regardless of whether it’s too little, it’s definitely too late. So what to do? Protect your stuff, and put PCI (and the other regulatory mandates) into the box that it belongs. A low bar you need to go beyond if you want to protect your data. Photo credit: “Don’t let this happen to you! too little, too late order coal now!” originally uploaded by Keijo Knutas Share: