Category: OWASP

So since the ASVS 3.0 retired much of the malicious code requirements, and after actually doing a line by line search of ~20 kLOC of dense J2EE authentication code, I’ve been thinking about various methods that backdoors might be created and not be findable by both automated and line by line searches.

This obviously has an issue with the recent Juniper revelation that they found a backdoor in the VPN code of their SOHO device firmware. It also feels like the sort of thing that Apple suffered with GOTO FAIL, and Linux suffered a long time ago with the wait4 backdoor.

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-2003/

So basically, I’ve been thinking that there obviously has to be a group dedicated to obfuscated backdooring. Making code that passes the visual and automated muster of specialists like me. There is probably another group or portion of the same group that sets about gaining sufficient privileges to make these changes without being noticed.

So before anyone goes badBIOS on me, I think it would be useful if we started to learn what malicious coding looks like in every language likely to be backdoored.

We can help prevent these attacks by improving the agile SDLC process, and keeping closer tabs on our repos. We can also make it more difficult to slip these things in if folks stuck to an agreed formatting style that made slipping in these types of attacks much harder, primarily by using automated indentation and linting that detected the lack of block control and assignment during conditionals. Yes, this will make some code visually longer, but we cannot tolerate more backdoors.

I’ve been doing a LOT of agile SDLC security work in the last few years, working WITH the developers on creating actually secure development processes and resilient applications, rather than reviewing the finished product and declaring their babies ugly. The latter does not work. You cannot review your way to building secure applications. We need to work with developers.

This is important as we’re starting to see an explosion in language use. It’s not merely enough to understand how these things are done in C or C++, but any system language, and any up and coming languages, many of whom we have zilch, nada, nothing in the way of automated tools, code quality tools, and specialists familiar with Go, Clojure, Haskell, and any number of other languages I see pop up from time to time.

What I think doesn’t work is line by line reviewing. All of these pieces of code must be have been looked at by many people (the many eyeballs fallacy) and run past a bunch of automated source code analysis tools, and it was “all good”, but it wasn’t really. Who knows how many secure code review specialists like me looked at the code? We need better knowledge and better techniques that development shops can implement. I bet we haven’t seen the last of Juniper style attacks pop up. Most firms are yet to really look through their unloved bastard repos full of code from developers past, present and future.

I looked back at the “predictions” for 2010, a post I wrote five years ago, and found that besides the dramatic increase in mobile assessments this last year or two, the things I was banging on about in 2009 are still issues today:

Developer education is woeful. I recently did an education piece for a developer crowd at a client, and only two of 30 knew what XSS was, and only one of them was aware of OWASP. At least at a University event I did later on in the year, about 20% of the students were aware of OWASP, XSS, SQL injection and security. The other 80% – not so much. I hope I reached them!

Agile security is woeful. When it first came out, I was enthralled by the chance for a SDLC to be secure by default because they wrote tests. Unfortunately, many modern day practitioners felt that all non-functional requirements were in the category of “you ain’t gonna need it“, and so the state of agile SDLC security is just abysmal. There are some shops that get it, but this year, I made the acquaintance of an organisation that prides themselves on being agile thought leaders who told our mutual client they don’t need any of that yucky documentation, up front architecture or design, or indeed any security stuff, such as constraints or filling in the back of the card with non-functional requirements.

Security conferences are still woeful. Not only is there a distinct lack of diversity in many conferences (zero women speakers at Ruxcon for example), very few have “how do we fix this?” talks. Take for example, the recent CCC event in Berlin. The media latched onto talks about biometric security failing (well, duh!) and SS7 insecurity (well, duh! if you’ve EVER done any telco stuff). Where are the talks about sending biometrics to the bottom of the sea with concrete shackles or replacing SS7 with something that the ITU hasn’t interfered with?

Penetration testing still needs to improve. I accept some of the blame here, because I was unable to change the market. They still sell really well. We really need to move on from pen tests as a wasted opportunity cost for actual security. We should be selling hybrid application verifications – code reviews with integrated pen tests to sort the exploitability of vulnerabilities properly. Additionally, the race to the bottom of the barrel with folks selling 1-2 day automated tests as equivalent to a full security verification for as little money as they can. We need a way of identifying weak tests from strong tests so the market can weed out useless checkbox testing. I don’t think red teaming is the answer as it’s a complete rod length check that can cause considerable harm unless performed with specific rules of engagement, that most red team folks would think invalidates a red team exercise.

Secure supply chain is still an incomplete problem. No progress at all since 2009. Until liability is reversed from the unique position that software – unlike all other goods and services is somehow special and needs special protection (which might have been true back in the 70’s during the home brew days), it’s not true today. We are outsourcing and out-tasking more and more every day, and unless the suppliers are required to uphold standard fit for purpose rules that all other manufacturers and suppliers have to do, we are going to get more and more breaches and end of company events. Just remember, you can outsource all you like,  but you can’t out source responsibility. If managers are told “it’s insecure” and take no or futile steps to remediate it, I’m sorry, but these managers are accountable and liable.

At least, due to the rapid adoption of JavaScript frameworks, we are starting to see a decline in traditional XSS. If you don’t know how to attack responsive JSON or XML API based apps and DOM injections, you are missing out on new style XSS. Any time someone tells you that security is hard to adopt because it requires so much refactoring, point them at any responsive app that started out life a long time ago. There’s way more refactoring in changing to responsive design and RESTful API than adding in security.

Again, due to the adoption of frameworks, such as Spring MVC and so on, we are starting to see a slight decline in the number of apps with CSRF and SQL injection issues. SQL injection used to be about 20-35% of all apps I reviewed in the late 2000’s, and now it’s fairly rare. That said, I’ve had some good times in 2014 with SQL injection.

The only predictions I will make for 2015 is a continued move to responsive design, using JavaScript frameworks for web apps, a concerted movement towards mobile first apps, again with a REST backend, and an even greater shift towards cloud, where there is no perimeter firewall. Given the lack of security architecture and coding knowledge out there, we really must work with the frameworks, particularly those on the backend like node.js and others, to protect front end web devs from themselves. Otherwise, 2015 will continue to look much like 2009.

So the best predictions are those you work on to fix. To that end, I was recently elected by the OWASP membership to the Global Board as an At Large member. And if nothing else – I am large!

• I will work to rebalance our funding from delivering most of OWASP’s funds directly back to the members who are paying us a membership fee who then don’t spend the allocated chapter funds, but instead, become focussed on building OWASP’s relevance and future by spending around 30% building our projects, standards, and training, 30% on outreach, 30%  on membership, and 10% or less for admin overheads.
• I will work towards ensuring that we talk to industry standards bodies and deal OWASP into the conversation. We can’t really complain about ISO, NIST, or ITU standards if they don’t have security SMEs to help draft these standards, can we?
• I will work towards redressing the diversity both in terms of gender and region in our conferences, as well as working towards creating a speaker list so that developer conferences can look through to provide invited talks to great local appsec experts. We have so many great speakers with so much to say, but we have to get outside the echo chamber!
• We have to increase our outreach to universities. We’ve lost the opportunity to train the folks who will become the lead devs and architects in the next 5-10 years, but we can work with the folks coming behind them. Hopefully, we can invest time and effort into addressing outreach to those folks already in the industry in senior/lead developer and architect and business analyst roles, but in terms of immediate bang for buck, we really need to address university level education to the few “ethical hacking” courses (which is a trade qualification), and work on building in security knowledge to the software engineers and comp sci students of the future. Ethical hacking courses have a place … for security experts, but for coders, they are a complete waste of time. Unless you are doing offensive security as your day job, software devs do not need to know how to discover vulnerabilities and code exploits, except in the most general of ways.

It’s an exciting time, and I hope to keep you informed of any wins in this area.

Be a part of the upcoming AppSec EU in Cambridge!

* UPDATE! Eoin can’t be in two places at once, so our hack-a-thon has moved to Tuesday 24 June. Same room, same bat channel. *

Eoin Keary and myself will be running an all day working party on the Developer Guide On June 24 from 9 AM to 6 PM GMT. The day starts with Eoin giving a DevGuide status update talk, and then we get down with editing and writing. 

I will be working remotely from the end of Eoin’s talk to til 1 pm UK time, and I so I encourage everyone who has an interest in the Devguide to either attend the workshop in person, or consider helping out remotely. Sign up here!

https://www.owasp.org/index.php/Projects_Summit_2014/Working_Sessions/004

My goal is to get the entire text of the OWASP Developer Guide 2.0 ported to the new format at GitHub, and hopefully finish 4 chapters. To participate, you will need a browser and a login to GitHub. You will also probably want a login to Google+ so you can be a part of an “on air” all day hangout so you can ask me anything about the DevGuide, or just chill with other remote participants.

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?

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.

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.

If you are participating in the OWASP Developer Guide, I want to have another status meeting Friday next week.

Friday 2nd November 1300 UTC
Saturday 3rd November 0000 AEDST (my time zone)

Come be my friend on Google+, and ask to be in my OWASP Guide circle. This circle can participate in the Hangout.

Hope to see you there!

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+.

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.