Dark Reading

Major SSL Flaw Discovered

By Adrian Lane

A major flaw has been found that enables a man-in-the-middle attacks against SSL connections. Several other media outlets are reporting, but Kelly Jackson Higgins has a nice summary over at Dark Reading, and betanews has a much more detailed discussion. According to Marsh Ray at PhoneFactor:

"The bug results in a set of related attacks that allow a man-in-the-middle to do bad things to your SSL/TLS connection. The (attacker) in the middle is able to inject his own chosen text into what your application believes is an encrypted, secure communications channel," says Ray, a senior software development engineer for PhoneFactor. "This has implications for all protocols that run on top of SSL/TLS, such as HTTPS ... What's different with this (bug) is that both the client and server need to be patched to restore the full security guarantees that are expected with TLS."

The communication process two parties go through to establish a trusted connection inadvertently leaves some response information in clear text during part of the dialogue. Basically when they agree to change some of the session attributes the protocol leaves some information exposed:

"Methods exist for one or the other party to request a change in the parameters of their transactions, perhaps to switch to a different, stronger cipher suite ... In a situation similar to someone's e-mail application replying to your e-mail with a message whose subject line begins, RE:, the conversation between client and server over what to change to, contains a reference to the request for renegotiation -- the request that had, when sent earlier, been encrypted. Now it's not, and that's the problem. "

The fix for this should be relatively straightforward and, from what I understand, should be available within the next few days. The issue becomes deploying a patch to a piece of code used for just about any secure communication session. So plan on patching a lot of applications in the coming weeks!

PhoneFactor named their efforts 'Project Mogul', which has nothing to do with The Mogull so far as I know.

–Adrian Lane

SQL Injection Prevention

By Adrian Lane

The team over at Dark Reading was kind enough to invite me to blog on their Database Security portal. This week I started a mini-series on threat detection and prevention by leveraging native database features. This week's post is on using stored procedures to combat SQL injection attacks. But those posts are fairly short and written for a different audience. Here, I will be cross-posting additional points and advanced content I left out of those articles.

My goal was to demystify how stored procedures can help combat SQL injection. There are other options to detect and block SQL injection attacks, many of which have been in use with limited success for some time now.

What can you do about SQL injection? You can patch your database to block known threats. You can buy firewalls to try to intercept these rogue statements, but the application and general network firewalls have shown only limited effectiveness. You need to have a very clear signature for the threat, as well as a written a policy that does not break your application. Many Database Activity Monitoring vendors can block queries before they arrive. Early DAM versions detected SQL injection based on exact pattern matching that was easy for attackers to avoid, back when DAM policy management could not accommodate business policy issues; this resulted in too many false negatives, too many false positives, and deadlocked applications. These platforms are now much better at policy management and enforcement. There are memory scanners to examine statement execution and parameters, as well as lexical and content analyzers to detect and block (with fair success). Some employ a hybrid approach, with assessment to detect known vulnerabilities, and database/application monitoring to provide 'virtual patching' as a complement.

I have witnessed many presentations at conferences during the last two years demonstrating how a SQL injection attack works. Many vendors have also posted examples on their web sites and show how easy it is to compromise and unsecured database with SQL injection. At the end of the session, "how to fix" is left dangling. "Buy our product and we will fix this problem for you" is often their implication. That may be true or false, but you do not necessarily need a product to do this, and a bolt-on product is not always the best way. Most are reactive and not 100% effective.

As an application developer and database designer, I always took SQL injection attacks personally. The only reason the SQL injection attack succeeded was a flaw in my code, and probably a bad one. The applications I produced in the late 90s and early 2000s were immune to this form of attack (unless someone snuck an ad-hoc query into the code somewhere without validating the inputs) because of stored procedures. Some of you might say note this was really before SQL injection was fashionable, but as part of my testing efforts, I adopted early forms of fuzzing scripts to do range testing and try everything possible to get the stored procedures to crash. Binary inputs and obtuse 'where' clauses were two such variations. I used to write a lot of code in stored procedures and packages. And I used to curse and swear a lot as packages (Oracle's version, anyway) are syntactically challenging. Demanding. Downright rigorous in enforcing data type requirements, making it very difficult to transition data to and from Java applications. But it was worth it. Stored procedures are incredibly effective at stopping SQL injection, but they can be a pain in the ass for more complex objects. But from the programmer and DBA perspectives, they are incredibly effective for controlling the behavior of queries in your database. And if you have ever had a junior programmer put a three-table cartesian product select statement into a production database, you understand why having only certified queries stored in your database as part of quality control is a very good thing (you don't need a botnet to DDoS a database, just an exuberant young programmer writing the query to end all queries). And don't get me started on the performance gains stored procedures offer, or this would be a five-page post ...

If you like waiting around for your next SQL injection 0-day patch, keep doing what you have been doing.

–Adrian Lane

Database Security: The Other First Steps

By Adrian Lane

Going through my feed reader this morning when I ran across this post on Dark Reading about Your First Three Steps for database security. As these are supposed to be your first steps with database security,
the suggestions not only struck me as places I would not start, it offered a method that I would not employ. I believe that there there is a better way to proceed, so I offer you my alternative set of recommendations.

The biggest issue I had with the article was not that these steps did not improve security, or that the tools were not right for the job, but the path you are taken down by performing these steps are the wrong ones. Theoretically its a good idea to understand the scope of the database security challenge when starting, but infeasible in practice. Databases are large, complex applications, and starting with a grand plan on how to deal with all of them is a great way to grind the process to a halt and require multiple restarts when your plan beaks apart. This article advises you start your process by cataloging every single database instance, and then try to catalog all of the sensitive data in those databases. This is the security equivalent to a 'cartesian product' with a database select statement. And just as it is with database queries, it results in an enormous, unwieldy amount of data. You can labor through the result and determine what to protect, but not how.

At Securosis, we're all about simplifying security, I am a personal advocate of the 'divide and conquer' methodology. Start small. Pick the one or two critical databases in your organization, and start there. Your database administrator knows which database is the critical one. Heck, even your CFO knows which one that is: it's that giant SAP/Oracle one in the corner that he is still pissed off he had to sign the $10 million dollar requisition for.

Now, here are the basics steps:

• Patch your databases to address most known security issues. Highly recommended you test the patch prior to operational deployment.
• Configuring your database. Consult the vendor recommendations on security. You will need to balance these suggestions with operational consistency (i.e. don't break you applications). There are also third party security practitioners who offer advice on their blogs for free, and free assessment tools that will help a lot.
• Get rid of the default passwords, remove unneeded user accounts, and make sure that nothing (users, web connections, stored procedures, modules, etc) is available to the 'public'.

Consider this an education exercise to provide base understanding of what needs to be addressed and how best to proceed. At this point you should be ready to a) you can document what exactly your 'corporate configuration policies' are and b) develop a tiered plan of action to tackle databases in descending order of priority. Keep in mind that these are just a fraction of the preventative security controls you might employ, and does not address active security measures or forensic analysis. You are still a ways off from employing more intermediate and advanced security stuff ... like Database Activity Monitoring, auditing and Data Loss Prevention.

–Adrian Lane

Pumping Out Noise

By Adrian Lane

I kind of get a chuckle from articles like this recent series at Dark Reading on phishing, spam and malware. First came the contradictory posts, both posting that Phishing Attacks are reaching record highs, while simultaneously trumpeting that the king of spam and botnets had been shut down. I don't suppose it dawned on the editors that if the channel that conveys the phishing attacks is "shut down", then we are not likely to see "Record Highs."

Then there is the headline that November 24th, the biggest shopping day of the year, could be a "Black Monday" in terms of malware threats ...

"PC Tools predicted Nov. 24 would be the most active day for malware threats after analyzing worldwide virus data on more 500,000 machines and data from last year's holiday season".

Then again, maybe not:

"And while spam and malware typically surge during the holiday season, this year may actually be a little less active than in years past, says Roger Thompson, chief research officer at AVG Technologies. No one should be especially worried about Nov. 24 ...".

Um, yeah. I am all for articles with interesting & topical information, and I understand the need to balance both sides of an issue, but if you are going to use attention grabbing headlines about some huge threat, you should at least provide some links or direction on what to do about it. Missing from all of this was a singularly relevant piece of useful information that most end users could easily use to help themselves in the battle against phishing and malware attacks, namely: DON'T CLICK EMBEDDED EMAIL LINKS.

–Adrian Lane

Thriving In An Economic Crisis- And Supporting Hackers For Charity

By Rich

I was pretty honored a couple months ago when Johnny Long asked me to participate in a new project for Hackers for Charity called The HFC Security Informer. Johnny is a seriously cool guy who founded Hackers for Charity, which provides a mix of services and financial support in underdeveloped countries. I think most geeks that aren't running evil botnets have a bit of altruism in them, and HFC is a great way we can use our technical backgrounds (and swag) to help out the rougher parts of the world.

HFC runs with basically no funding- giving everything right to its target communities. To better support operations as it grows, Johnny created the HFC Informer- a subscription site with all sorts of behind the scenes content you can't get anywhere else. This includes pre-release book chapters, discounts on books, exclusive content, and pre-release papers and posts from some of the top names in security... and the occasional lowly analyst. And every time someone contributes content, cash is donated to feed a child for a month.

Yesterday I posted a pre-release (and pre-edited) version of my next Dark Reading column The Security Pro"s Guide To Thriving In A Down Economy. Please check it out, and other great content like Rsnake's Clickjacking paper, and consider supporting HFC.

Securosis is a firm believer in the project and we're hoping to release more content on the HFC Informer, including some of our more in-depth whitepapers.

–Rich

New Poll (And Article) At Dark Reading

By Rich

Thanks to the unorthodox release of the DNS bug, there’s been a lot of debate in the past few weeks over disclosure. I posed a question here on the blog, and reading through the responses it became obvious that all of us base our positions on gut instinct, not empirical evidence. Andrew Jaquith, in the comments, suggested we take a more scientific approach to the problem, and this inspired my latest Dark Reading article, and a poll. Here’s an excerpt:

Sure, we all have plenty of anecdotal evidence to support our personal positions. We can all cite cases of this or that vendor tirelessly defending its customers, or putting them at mortal risk based on their handling of some vulnerability. We all know someone that suffered real losses at the hands of the latest random Metasploit exploit module, and someone else who used it to close critical holes in their security defenses before the bad guys made it in. We all talk about Blaster, Code Red, and other past incidents like they have any relevance in today’s world, which we all also admit has changed completely from a few years ago. There’s a word for picking and choosing examples to support a pre-existing belief without any scientific basis. It’s called religion. I propose that it’s long past time we brought some current science into the game. It’s time to move past anecdotal evidence or one-off cases into wider-ranging realm of epidemiological studies. It’s time to ask the users what they want, while developing risk metrics to allow them to make informed decisions despite their personal opinions. We may not reach definitive conclusions, and even if we do, they probably won’t last nor change the minds of the truly religious. But it’s always better to seek more data than to dismiss it before we even see it.

As a small first step, we attached a poll to the article to measure how different demographic groups, users, researchers/testers, and vendors, feel about disclosure. It’s not truly scientific, both due to the wording of the question and the self-bias of the readers, but I’ll always error more on the side of more data over less.

So take the poll, and we’ll get the results up in a couple of weeks. Until then, see ya at Black Hat and DefCon!

–Rich

Dark Reading Column: Attack Of The Consumers (And Those Pesky iPhones)

By Rich

I have a sneaking suspicion my hosting provider secretly hates me after getting Slashdotted twice this week. But I don't care, because in less than 48 hours it's iPhone Day!!!

Okay, so I already have one and all the new one adds is a little more speed, and a GPS that probably isn't good enough for what I need. But I use the friggen thing so darn much I can definitely use that speed.

It's been up for a few days, but with everything else going on I'm just now getting back to my latest Dark Reading column. This month I take a look at what may be one of the most disruptive trends in enterprise technology- the consumerization of IT. Here's an excerpt:

That's the essence of the consumerization of IT. Be it laptops, cellphones, or Web services, we're watching the walls crumble between business and consumer technology. IT expands from the workplace and permeates our entire lives. From home broadband and remote access, to cellphones, connected cars, TiVos, and game consoles with Web browsers. Employees are starting to adapt technology to their own individual work styles to increase personal productivity. The more valued the knowledge worker, the more likely they are to personalize their technology — work provided or not. Some companies are already reporting difficulties in getting highly qualified knowledge workers and locking them into strict IT environments. No, it's not like the call center will be running off their own laptops, but they'll probably be browsing the Web, sending IMs, and updating their blogs off their phones as they sit in front of their terminals. This is far from the end of the world. While we need to change some of our approaches, we're gaining technology tools and experience in running looser environments without increasing our risk. There are strategies we can adopt to loosen the environment, without increasing risks:

–Rich