Category Archives: OWASP

Argumentum ad antiquitatem

This post is not in Latin, but essentially a call to the Information Security industry to end policies based upon argumentum ad antiquitatem, which includes:

  • Password change, complexity and length policies and standards that simply don’t make sense in the light of research and tools that show that we can crack ALL passwords in a reasonable time. It’s time to move on to two factor authentication, alternatives such as OAuth2 (i.e. Facebook/Twitter/G+ integration) or Mozilla Account Manager, and random long passphrases for all accounts.
  • “Security” shared knowledge questions and answers. These are commonly used to “prove” that you have sufficient evidence of identity to resume access to an account. We see these actively exploited continuously now. Unfortunately, most familiies including ex-spouses have sufficient knowledge of the identity and access to the person’s identity documents that such questions, no matter how phrased (like “What was your favorite childhood memory”), are simply unsafe at any speed as more than ONE person knows or can guess the correct answer.
  • That requiring authentication is enough to eliminate risks in your application. Identity and access management is important, but it’s only part of the picture.
  • That enforcing SSL or access through a firewall is enough to eliminate risks in your application. Confidentiality and integrity of connection is vital, especially if you’re not doing it today, but it’s only part of the picture.
  • That obfuscation is enough to deter hackers. Client side code is so beguiling and the UX is often amazing, but it’s not safe. Business decisions must be enforced at a trusted location, and there’s little business reason to do this twice. So let’s get that balance right.

What are some of your pet “argumentum ad antiquitatem” fallacies?

Securing WordPress with obfuscation

So in a fit of security through obscurity, I renamed my WordPress database tables and promptly broke WordPress with a highly informative “You do not have sufficient permissions to access this page.” error message when accessing wp-admin.

Changing the prefix is easiest done with a new installation, but my installation dates from the very first versions of WordPress when the dinosaurs roamed. Due to WordPress’s design, changing the database prefix (‘wp_’) is not as straightforward as you would expect.

Edit wp-config.php

In this exercise, we’re going to change from the default “wp_” prefix to “foo_”. If you’re doing this for security through obscurity reasons, don’t use “foo_”, use something you made up. Trust me, my prefix is NOT “foo_”. In wp-config.php, change:

$table_prefix  = 'wp_';

to

$table_prefix  = 'foo_';

Once you’ve saved the file, your WordPress installation is now officially broken. Move fast!

Rename your tables

use myblog
show tables

and for each of the tables you see there, do this:

rename table wp_options to foo_options;

At this point, your blog will now be viewable again, but you will not be able to administrate it. Accessing /wp-admin/ will say “You do not have sufficient permissions to access this page.”

Fix WordPress Brain Damage

Let’s go ahead and fix that for you:

UPDATE foo_usermeta SET meta_key = REPLACE(meta_key,'wp_','foo_');
UPDATE foo_options SET option_name = REPLACE(option_name,'wp_','foo_');

You’re welcome.

Time to update knowledge

This might be telling folks to suck eggs, but if you are doing secure code reviews and your development skills relate to type 1 JSP and Struts 1.3, it’s really time you got stuck into volunteering to code for open source projects that use modern technologies. There’s heaps of code projects at OWASP that need help, including helping me with code snippets that are in a modern paradigm.

I don’t care what technologies you choose, but your code reviews will not be using Type 1 JSPs or Struts for that much longer – if at all. Time to upskill!

I suggest:

  • Ajax anything. Particularly jQuery and node.js. GWT is on the wane, but still useful to know
  • Spring Security, Spring Framework and particularly Spring Web Flow are essential skills for any code reviewer doing commercial enterprise code reviews
  • .NET 4.5 and Azure are killer skills at the moment, particularly as Windows 2012 has just been released. Honestly, there is a good market to be a specialist just in this language and framework set, as it’s literally too large for any one person to know.
  • Essential co-skills: Continuous integration, agile methodologies (you have updated your services to be agile aligned, right?), and writing security unit tests so your customers can repro the issues you find.

It’s important to realise that good code reviewers can code, if poorly. Poor code reviewers don’t code and have never written a thing. Don’t be a bad code reviewer.

I do not suggest Python, Ruby on Rails, or PHP as these are rare skills in the enterprise market, but if they scratch your itch, go for it, but be aware that these skills do not translate out to commercial code review jobs. The fanbois of these languages and frameworks will hate on me, but honestly, there’s no reason to learn these languages except for the occasional job here and there, and if you’re any good at the list above, PHP in particular is easy to pick up. Fair warning, it’s a face palm storm waiting to happen.

OWASP Guide 2013 – Developers needed!

The Developer Guide is a huge project; it will be over 400 pages once completed, hopefully written by tens of authors from all over the world, and will hopefully become the last “big bang” update for the Guide.

The reality is our field is just too big to do big bang projects. We need to continuously update the Guide, and keep it watered and fresh. The Guide needs to become like a metaphorical 400 year old eucalypt, all twisty and turny, but continuously green and alive by the occasional rain fall, constant sunlight, and the occasional fire.

If you are a developer and have some spare cycles, you can make a difference to the Developer Guide. I need everyone who can to add at least a paragraph here and there. I will tend to your text and give it a single conceptual integrity and possibly a bit of a prune, but with many hands, we can get this thing done.

Why developers? Many security industry folks are NOT developers and can’t cut code. We need developers because we can teach you security, but it’s difficult to instil 3 years of post graduate study and a working life cutting code. I am not fussed about your platform. Great developers know multiple platforms, and have mastered at least a couple.

I am installing Atlassian’s Greenhopper agile project management tool to track the state of the OWASP Developer Guide 2013′s progress.

Feel free to join the mailing list, come say hi, and join in our next status meeting on Google+.

On penetration testing – harmful?

Over at Sensepost Security, there’s a new blog entry wondering about Haroon Meer‘s talk “Penetration Testing Considered Harmful“. Those who know me know that I’ve had this view for a very long time. I’m sure you could find a few posts in this blog.

Security has to be a intrinsic element of every system, or else it will be insecure. Penetration testing as a sole activity and piece of assurance evidence makes security appear on the fringes of the development, something that you pass or fail, something to be commodotized, a box to be ticked, and ultimately ignored. Penetration testing as is done by most in our industry is incredibly harmful. It’s a waste of investment to most organizations, and they know it so they try to minimize wastage by minimizing the scope, the time, and poo-pooing the outcomes.

Penetration testing should be a part of a wider set of security activities, a verification of all that came before. All too often, we come across clients who want to do a one or two day test the day before go-live. They’ve done nothing else, and when you completely pwn them, they’re terribly surprised and upset.

We need to move on to make penetration testing the same as unit testing – a core part of the overall software engineering of every application.

Penetration testing should never be ill informed (zero knowledge tests are harmful and a WAFTAM for all concerned), and it should have access to source, the project, and all documentation. Otherwise, you’re wasting the client’s money up against the wall and acting unethically in my view.

Tests should come from the risk register maintained by the project (you do have one of those, right?), as well as the use cases (the little cards on the wall) as well as from the OWASP ASVS / Testing Guides. More focus must be made on access control testing and business logic testing.

Penetration testing has become vulnerability assessment – run a tool, drool, re-write the tool’s results into a report, deliver. No! Write selenium tasks and automate it. If you’re not automating your pentests, how can your customers repeat your work? Test for it? They should be taught how to do it.

Folks at consultancies will shriek away in horror at my suggestion, but getting embedded is actually a good thing. Instead of hearing from a client once in a blue moon, you’re integrated into the birth and growth of software. This is a huge win for our clients and the overall security of software.

OWASP Development Guide – what do you want in, and what do you want out?

It’s time to do some curating of the OWASP Developer Guide. This is where my tastes meet the community’s – what do you want in the Guide, and what do you want out of the guide?

As much as I want to be comprehensive, there is a real risk that a 800 page book would never be read. There ARE easter eggs in the Guide that no one has found or bothered to e-mail me about yet, so I know it’s not being read widely.

I want to ensure the Guide is used, in a way that the OWASP Top 10 and ESAPI are used daily throughout our industry.

  • What would you like to see IN the Guide? Why?
  • What would you like to see OUT of the Guide? Why?

Let me know by June. I’ll be sure to share your thoughts with the Developer Guide mail list.

OWASP Guide 2013 Development

It’s been nearly seven years since I finished the herculean effort of holding down a day job and leading, editing or excising the existing material, cat herding all the collaborators, and writing a goodly portion of the OWASP Developer Guide 2.0.

I finished PDFing 2.0 around 4.30 am and pushing it to the OWASP website. I was rush packing for BlackHat as my plane was due to depart at 11 am. I checked my mail as I was shutting down my home lab, and got a last minute set of edits from Michael Howard on the crypto chapter (which is definitely not my strong suit). So I fired up Word again, made the changes, and issued 2.0.1 in Word and PDF format pretty much just as I had to walk out the door to catch the plane.

That was the last time the Guide was formally issued.

It’s time to pick up the whip, and dip the pen in the inkwell (well, TextMate this time – we are working in Wiki format at Google Code).

I plan to write at least one blog entry a week to describe how we are going. I am determined this time to not write > 80% of the content. I simply don’t have the time, and honestly, if we’re going to do this before 2.0 can vote, I really need helpers.

The first steps have been put into place:

  • Put out a mail to the Guide mail list asking if I can take over
  • Got a bunch of public and private e-mails saying yes, plus most pleasing to me of all – offers of help!
  • Got an e-mail from Vishal Garg, the previous leader – 1, saying that he had actually stood down last year (!)
  • Got an e-mail from Abraham Kang, the previous leader, saying that he would be happy to co-lead with me (awesome!)
  • Asked the Global Projects Committee to assign the project to me, along with a PM. I’ve not heard back from them, but at this stage, I’m happy to do first, apologise later.

Current status

I’ve been reading the current materials out of the SVN repo. Oh wow. So much work to do. My plan is to use a few hours each day to write a precis of what I have in mind for each section, and then farm out the work to all those who volunteered.

I have to make a few basic executive decisions. These help get the project re-oriented in the right way, so as to encourage lateral thinking about some of the hardest topics in our industry. I need the Guide to lead the charge against group think that XSS or SQL injection is insolvable, or that (weak) passwords will be with us forever. Other decisions are just necessary for logistical reasons. I will try to make as few unilateral decisions as possible.

First executive decision: We cannot possibly know what will be the new hotness.

Developers are a creative and fickle bunch. Business would love us to code everything in COBOL or VB … or Java, but that’s not how the game is played. Freaking awesome developers (the taste makers) choose new and interesting things to them at least once or twice a year or more. A pool of talent builds behind the cooler / better marketed languages / frameworks. Not knowing what will be the next new hotness is my only real assumption whilst we develop the new version of the Guide. 

During Guide 2.0 development, classic ASP was winning the battle over ASP.NET, PHP was very popular and very insecure, and J2EE was just starting the process of moving from Struts 1.x to Spring, modulo a dead end or two (JSR-168 comes to mind). Ruby on Rails was a brand new plaything with a few fervent supporters. How times have changed.

What hasn’t changed are the underlying principles of web application security. I don’t care if you are writing in technologies like Ajax, GWT, Ruby on Rails, Haskell, or you’ve moved to a web flow type model – we know what works and what doesn’t, and to a large extent, it’s in the existing Guide 2.0.

So I want to move the Guide up a level to be a hybrid architecture / detailed design guide, rather than an implementation guide, a set of repeatable architectural / design patterns that are easily adaptable and applicable cross-language, cross-framework, and be aware of new fads that come and go without knowing exactly what they are.

Second Executive Decision: Diagrams must not suck

The Guide has always needed a lot more diagrams than it has. The diagrams I drew back in 2004 and 2005 … suck. I have the originals here, but honestly, I don’t feel we should re-use them.

I will be approaching the Projects committee to find us a good graphic designer to give a cohesive design language for us to do the diagrams in, or simply farm out our hand drawn diagrams to someone who can do them all in the one style in a way that looks good in the Wiki, Word, iPad and PDF versions of the Guide.

In the meantime, I will hand draw and photograph the diagrams I have in mind and include them in the wiki as markup. That way, we’re not spending hours in a diagramming tool when we really need to be writing at this stage.

Third executive decision: Distributed computing

In 2005, the problem of race conditions in web apps was only really in J2EE web apps that did the very wrong but very arcane things. I had planned for 2.0 (and then 2.1) to include a distributed computing chapter that discussed race conditions, but it’s time to include a detailed discussion on asynchronous, distributed computing: i.e. cloud computing.

Not only do we need to take into account the many threads / cores of a typical processor today, thus meaning that any server worth its salt will have multi-threading issues, there are parallel languages (F# with the parallel extensions to .NET, and Go for two), and there is Ajax and all the multitude of frameworks that support asynchrony. I don’t want to forget the oldest of them all – batch and background processes that can still produce surprising results.

So its time to bring this bunch of issues to the forefront, because the cloud genie is out of the bottle, Ajax is well and truly plastered all over the Internet, and if there’s ever a new single core CPU running a new single threaded OS ever again, I’d be immensely surprised.

Where to from here?

It’s time to gather the offers for support and start to build a road map, and build consensus on where we should be going. In my view, we need to and indeed must lead the industry by at least two-three years to be relevant on day one of our launch. 2.0 was ahead of its time, but only just, and in the last seven years, my lack of foresight / bravery in targeting the absolutely crazy bleeding edge meant irrelevance by 2008 at the latest.

If you want to help, please join the mail list and please offer your services. It’s time to get OWASP Developer Guide 2013 going again.

Security trends for 2012

  1. Folks will continue to use abc123 as their password. They will then be surprised when they’re completely pwned.
  2. Folks will continue to not patch their apps and operating systems. They will then be surprised when they’re completely pwned.
  3. Folks will continue to use apps as administrator or god like privileges. They will then be surprised when they’re completely pwned.
  4. Folks will continue to click shit. They will then be surprised when they’re completely pwned.
  5. van der Stock’s immutable law of gullibility: Folks will continue to be sucked in by incredibly basic scams. They will then be surprised when they’re completely pwned.
  6. Folks despite extensive and continuous evidence to the contrary for over 25 years, will continue to be sucked in by grandiose vendor claims (“buy X now, and you’ll be protected from X…”) in the unfounded belief that technological solutions can fix people problems. They will then be surprised when they’re completely pwned.
  7. Folks will continue to allow mobile and web apps to transmit their sensitive crap without any form transport layer encryption. They will then be surprised when they’re completely pwned.
  8. Folks will turn on a firewall and think they’re safe. They will then be surprised when they’re completely pwned. It’s not 1995 any more. Never was.
  9. Folks will continue to run old crap, or allow old crap to connect to them. They will then be surprised when they’re completely pwned.
  10. Folks will continue to think that they will be safe if they just virtualize or cloud enable their crappy apps. They will then be surprised when they’re completely pwned.
If we can’t learn from our most basic of basic mistakes, 2012 will be exactly like 1989 – 2011. And that’s sad.
Because I hate solution free hand waving posts like the above, here are some basic solutions:
  • Adopt strong authentication TODAY – passwords have NEVER been appropriate.
  • Patch your crap.
  • Implement low privilege users and service accounts.
  • Don’t click shit.
  • Learn about basic phishing and scams.
  • Fire folks who post on Twitter or Facebook all day. You know who they are.
  • Don’t buy any product marked “Protects against APT”. If you do, fire yourself as you’re an idiot.
  • Only use products that use SSL. If you don’t know, assume it doesn’t and find something that does.
  • Evaluate your security needs with 2012 in mind – firewalls alone are a few sheep short of a full paddock.
  • Upgrade to the latest OS and apps. Not only will your users love you, it’ll be harder to attack you.
  • Protect data assets no matter where they are. The plumbing is unimportant.

On APT

Recently, RSA was attacked by adversaries who targeted their two factor authentication fobs.

These devices have known MITM issues, but folks still used them because there was so little information out there to say that a better choice is required. RSA liked it that way.

RSA chose not to discuss the details of the attack, using the old furphy that disclosure will damage their customers (reality: it would damage RSA’s brand). RSA’s silence allowed

Advanced

Persistent

Threats

to execute the boldest cryptographic information warfare attack since Enigma.

RSA’s (IMHO) cowardly silence has actually damaged their customers in highly spectacular fashion. RSA told us nothing, so we couldn’t ask our clients to change vendors in a staged way, or to disable access, or put in other controls. We could guess, but business decisions are not made that way.

Now the brand damage to RSA will truly begin. This is the end of the simple RSA fob. Even if a better algoritm or fob is used, RSA are toast as no one will trust them any more, particularly in the sort of organizations that buy fobs by the palette.

APT boosters have said vociferously – “see, it was APT!”. Yep, I agree. It’s one of the few times that truly worthy attacks are out in the open enough for us to get a small glimpse into what’s really going on.

Unfortunately, due to widespread abuse of the term, APT is the laughing stock of the information security world. The folks who routinely use it with knowledge can’t discuss why APT is any different to the other threats out there today. Everyone else has no clue.

I’ve seen CSOs give up, thinking that since these attackers are so advanced, surely we can’t protect against them, or they buy stuff marked “Solves APT TODAY!1!” when in fact, hard work is required. Nothing very hard, just simple stuff like input validating every field and not tolerating insecure software any more.

But for your average CSO, finding out if an application was developed in a secure fashion and that every parameter is validated is impossible. It shouldn’t be. But that’s not the main point of today’s post.

It’s moderately clear in the fog of active disinformation that the weaknesses used in the RSA, Sony, and PBS hacks are well known and easily exploitable. The solution is like losing weight. There is a simple solution that works – albeit slowly. It’s called eating the right amounts of good food for a year or two and exercising hard every day. Anyone who has tried to lose weight, including myself, knows that we really just want an APT strength diet pill.

I think most of us in our industry will acknowledge that penetration testing has become “different” over the last few years, from literally shooting fish in a barell with the most rudimentary or no tools, to requiring a fair bit of work, and moving up the value chain to find interesting and exploitable issues the business cares about.

In terms of results, I think we’re still finding 10-20 things wrong in every app. Attackers need one. This is the attacker’s advantage. The number of weaknesses, the type of weaknesses, and the severity of the weaknesses are NOT “advanced” in any way shape or form in 95%+ of the code reviews and penetration tests I perform. The other 5% have been working with me for a while, are mature risk managers, and they’re hard to attack as a result.

But because of the hard core mystique surrounding the use of the term “APT”, we’re seeing completely inappropriate uses of the term everywhere from anti-virus scanners through to security appliances that promise data loss protection but forget that the information security triangle is people-process-technology. Putting one in place doesn’t solve the other two, nor negate your responsiblities to put in appropriate controls that PEOPLE can live with to do their JOBS and make the business MONEY.

My twitter icon is the famous drive around control image:

Access controls are only for those with easy access

Access controls are only for those with easy access

This is where folks promoting APT fail. I am not denying that the attackers who have found a end run around a widely known security control are

Advanced

Persistent

Threats

Anyone who targeted a particular firm, and utterly broke a long standing crypto system, and everything else required to obviate hardened controls of at least two military industrial giants are worthy of the term APT.

Unfortunately, APT as a term is so brand damaged in the info sec community (try saying it at a public event without being openly laughed at), that we have to choose a better one, one that marketers would never dream of using inappropriately. I don’t know what it is, but surely

Enemy Combatent

or

Soon To Be A Small Pile Of Glowing Ash (STBASPOGA, or the more friendly sounding Strasbourg)

are right up there.

Worse still, the fact that these Strasbourgs really are APTs doesn’t mean that we should forget to do the hard work, but instead demonstrates the paucity of protective information security research. Some of you might remember me saying a year or two ago that too much attention is paid to those who hack, and not enough on those who defend. Strasbourgs should mean more dollars in pro-active research. We need to make it difficult to develop insecure software. We should make easy to determine if Acme’s latest release of their widgets are insecure. We should have metrics that easily demonstrate insecure software costs more. We should make it legally untenable to ship insecure software, and give redress to consumers when their investments, privacy and intellectual property are violated due to stupid, simple weaknesses that we knew about in 1965.