Security is dead, long life security

This is a repost of my company blog: http://blog.xebia.com/2015/10/12/security-is-dead-long-live-security/

Last week the 7th edition of BruCON was held. For those unfamiliar with it, BruCON is a security conference where everybody with an interest in security can share their views and findings. As always it was a great mixture of technology, philosophy, personal opinions and hands-on workshops.
This year however I noticed a certain pattern in some of the talks. Chris Nickerson gave a presentation about "how to make a pentester's life hell" based on experience, Shyma Rose shared her views on risk management, Mark Hillick showed us how the security was improved at Riot Games and David Kennedy provided his opinion on the state of the information security industry nowadays. All four of them basically told pieces of the same tale from a different perspective and I will try to provide my viewpoint on the matter in this blog.


The security bubble
Both Shyma and Dave said the term 'Risk' is inflated and is nowadays used as a buzz word that no longer has a connection with actual threats. I couldn't agree more on this. Nowadays it is almost normal, when someone identifies a new vulnerability, to launch a complete marketing campaign including fancy names and logos, dedicated websites and huge social media presence. Risk is no longer used as an indicator of 'badness', but instead used as a catalyst for pushing 'money making silver bullets' to customers. And, since most clients don't know any better, they get away with it. And, as Chris showed, even customers who do know better, still enable them to push their crappy services by providing them ideal conditions to prove their effectiveness.

Hackers != unstoppable evil geniuses
Hackers are looked upon as the extremely smart guys with elite skills, where reality is that most breaches happen due to stupid stuff and decade old problems. The infosec industry's solution is products and services that no longer qualify for the fast changing world we now live in. Most services rely on stopping or identifying known attacks. In a world that is changing almost every heartbeat and especially in a world of mobile devices and cloud solutions the 'castle and archers' approach no longer works. Facts show that in many hacks exploits weren't even necessary due to the possibilities of modern platforms. If an attacker has the possibility to access some maintenance or configuration part of your system it's game over. If an attacker can access some scripting environment, it's game over. If an attacker can lure one of your employers into going to a website or installing something, it's game over.

Ivory Towers
Another problem is the huge gap between security operations inside a company and the business and development departments. Many companies have internal security guidelines that are hardly aligned with the rest of the organization and therefor bypassed or ignored. The natural response to this is that the security departments push the guidelines ever harder, only causing the gap to increase even more. Based on experience Mark stated that security departments should get out of their ivory tower and start to understand what is really important. It's more effective to achieve 80% security with 100% alignment, than try to reach 100% security with 0% alignment.

Duct-tape
Both the infosec industry and clients nowadays have enough money and attention to change things, so we should get rid of the technology driven approach and start focusing on talent and smartness. When you look at the root causes of many hacks it's not the technology that is to blame, but instead ego, culture, miscommunication and the working environment. As long as security is considered as something you can bolt on or use external expertise for it will fail. We, both the suppliers and clients, should consider security as a standard quality attribute where everybody is responsible for.

Telling instead of training
In most companies the ratio between security and non-security minded people is way off. Security teams should therefor start acting as supporters and trainers. By becoming more visible in the organization and start aligning with it, the security awareness will rise within everyone. Every single person in the company should get a basic understanding of what security is about. And it isn't that hard to achieve. Developers should know secure coding, testers should learn to use security tooling, operations should know how hacking tools work and can be identified and taught the basics of forensic research. People also need to be trained to how to handle in case of an issue: build a good incident response program with flowcharts that everybody can use and apply. It's not rocket science, you can achieve a lot with good old common sense.

Secrecy
Another key item is visibility. Often incidents, breaches and other security related issues are 'kept under the radar' and only 'the chosen few' will know the details. By being open and transparent about these to the whole organization, people will start to understand the importance and challenge each other to prevent these in the future. By creating internal security challenges and promoting good ideas a community will form on itself. Use leaderboards and reward with goodies to stimulate people to improve themselves and get accustomed with the matter. Make sure successes are acknowledged. To quote Mark (who also quoted someone else) "If Tetris has taught me anything, it’s that errors pile up and accomplishments disappear."

Hackers don't only knock on the front door
Lastly start to implement defense by default and assess every situation as if a breach had occurred. Assume bad stuff will happen at some point and see how you can minimize the damage from each point. Do this on all levels; disable local admin accounts, use application protection like EMET and Applocker, implement strict password policies, apply network segmentation between byod, office automation and backends, using coding frameworks, patch all the time, test everything, monitor everything, and start analyzing your external and internal network traffic. The ultimate goal is to make it pentesters (and therefor hackers) as difficult as possible. Pentesters should cry and require weeks, months or even years to get somewhere.

There is no I in team!
We, as an infosec industry, are facing a future where change is the constant factor and we have find a way to deal with that. In order to be successful, we have to understand and acknowledge that we can no longer do it on our own. Unless we start to behave as a member of the team, we will fail horribly and become sitting ducks.
Inspiration

Just some testing related links (updated)

Training online

Hacker Contests / War Games

Deliberately Vulnerable Websites

Deliberately Insecure Applications

Deliberately Insecure Distributions

Vulnerable 'real' applications

Testing Tools

Security Tool Suites

Frameworks / Testing resources

Security Models

First Burp Extension


Yesterday I started converting the few Hiccup scripts I created (as in: tinkering with a mashup of existing scripts until it worked) in the past to the new Burp Extender format.
After some initial startup problems (with which http://www.burpextensions.com really helped out) I am proud to present my first simple extension :)

It doesn't do much more than highlighting requests of content-type text/xml and text/xhtml in the proxy tab. The reason I want that is that these content types are possibly vulnerable to html encoded XSS attacks and are often missed by scanners (thanks to mario heiderich for pointing that out to me in the past!). It is therefor useful to test them manually.

See http://www.thespanner.co.uk/2011/09/12/protecting-against-xss/ for some background info and PoC.

Link to the Burp Extension



Privacy is minder waard dan een cookie

Vandaag is het dan zover; de cookiewet is actief geworden. Vanaf vandaag moeten alle websites toestemming vragen voor het plaatsen van cookies die niet puur bedoelt zijn voor het functioneren van de site. Daarbij wordt geen onderscheid gemaakt tussen first-party en third-party cookies en ook maakt het niet uit of er nu wel of geen privacy gevoelige informatie in staat; alleen cookies bedoelt voor bijvoorbeeld het bijhouden van een sessie of winkelwagentjes mogen 'stil' worden geplaatst, alle andere cookies moet je vooraf toestemming voor vragen aan de bezoeker. Verder is de naamgeving 'cookiewet' misleidend, omdat het om alle mogelijkheden van 'local storage' gaat en niet alleen om de standaard cookies. Flash cookies en alle mogelijkheden van HTML storage vallen daar dus ook onder!

De wet heeft ook gelijk flink wat munitie gekregen; overtredingen kunnen door de OPTA beboet worden met sancties die op kunnen lopen tot € 450.000 ! Verder kan de wet ook met terugwerkende kracht worden toegepast; foute cookies die wel ooit geplaatst zijn (na vandaag), maar niet meer gebruikt worden kunnen ook beboet worden. Daarnaast is de OPTA niet verplicht eerst een waarschuwing te geven en mag het bij ernstige overtredingen direct overgaan tot beboeten.

Dit heeft nogal wat consequenties. Om te beginnen zijn alle site die gebruik maken van tracking of analyse mogelijkheden (zoals bijvoorbeeld Google Analytics) per direct in overtreding. Ook is het opslaan van persoonlijke voorkeuren in cookies niet meer toegestaan en zal iedere website dus een profiel voor iedere klant moeten gaan bijhouden.

En daar komen we gelijk op een heikel punt; door de cookiewet worden websites gedwongen om meer gegevens van de klant te verzamelen aan de server kant om personalisatie te kunnen aanbieden. Alle voorkeuren van een klant zullen voortaan in een klantprofiel moeten worden opgeslagen. Om dit klantprofiel uniek genoeg te maken moeten of alle klanten voortaan inloggen of zal de website zoveel mogelijk informatie moeten verzamelen over de klant. Gelukkig is hier geen persoonlijk identificeerbare informatie voor nodig; zelf met de informatie die je browser naar een website stuurt is een klant al behoorlijk uniek te identificeren, zelfs zonder dit direct te koppelen aan het IP adres. (ter info: de uniekheid van je browser kun je hier testen (je IP wordt hier niet bij gebruikt): https://panopticlick.eff.org/ )

Theoretisch levert dit natuurlijk een extra risico op in de vorm van datalekken die onder de Wet Bescherming Persoonsgegevens vallen, maar gelukkig moet zo'n lek eerst plaatsvinden en moet er aangetoond worden dat dit een overtreding is van de WBP. En zelfs als je verzuimd een lek te melden en dit wordt toch ontdekt dan is de maximale boete slechts € 200.000.

Vanaf vandaag is privacy dus minder waard dan een cookie!

Mostly Free Online Testing and Security Magazines

Just a list I collected over time. Many are free or provide free issues.

Software Test & QA
http://www.softwaretestpro.com/Publication/p/STPM

(IN)Secure Magazine
http://www.net-security.org/insecuremag.php

Hack in the Box Magazine
http://magazine.hackinthebox.org/

IT Expert Magazine
http://www.itexpertmag.com/

Hakin9 Magazine
http://hakin9.org/

Datacenter Magazine
http://datacentermag.com/category/magazine/

Pentest Magazine
http://pentestmag.com/

Security Acts
http://www.securityacts.com/

Security Kaizen Magazine
http://www.bluekaizen.org/security-kaizen-magazine/

Testing Experience
http://www.testingexperience.com/

N2100 modules mirror

For some years now I am a happy owner of a Thecus N2100 NAS.

Although it is getting a bit slow compared to the newer generations of NAS devices, one of the things I like about it is the way you can customize it to your own needs by using modules. Over the last years a fairly active community developed many of these modules and discussed them on the Thecus user groups Thecus Usergroup Forum.

Unfortunately the community is declining and moving to newer devices and many of the modules can no longer be downloaded from the original locations. I therefor downloaded as many modules as possible while I could and I am providing a mirror for it on Google Docs. You can find my mirror to the N2100 modules here.

Ideal Skill Set For Web Application Security Testers

Today I saw an interesting post by Keatron Evans on the "Ideal Skill Set For the Penetration Testing". You can find his blog here.

While I think it is a good summary about the skill-set for pentesters, I think it is not the correct skill-set for web application security testers. So I have made a slightly modified version of it for (what I think to be) the basic skill-set of a web application security tester.

I tried to maintain the original list as much as possible and provide the webappsec analogies of the items. I also copy/pasted the good bits and the things I thought to be applicable in both lists.

1. Mastery of web and application servers. Each and every web and application server has its own configuration options, behaviour, quirks and file locations. Learn them and learn how to abuse or break them.

2 Good knowledge of the HTTP protocol. Understand and learn the header fields, how cookies work and the different request methods. Understand how HTTPS works. Get the basics of AJAX, JSON, serialized streams, etc.

3. If you don’t understand the things in item 2, then you can’t possibly understand how session management, CSRF or a (layer 7) MiTM attack actually works.

4. Learn the ins and outs of HTML, javascript, CSS. Learn the different encoding mechanisms, their uses and limitations. Also learn how each browser handles exceptions and strange input (see 6)

5. Learn the ins and outs of the mechanisms behind IDS and IPS. Learn how to pass data past them using basic encoding and other simple techniques. There’s no better way to understand these concepts than to apply them. Once you’re mastered this, you can move to a WAF and start the process over again. Start experimenting with different encodings and obfuscation techniques and other attacks.

6. Know your browsers. Despite all the standards browsers tend to handle HTML, javascript and encodings in a (slightly) different way. Next to that, each browser has its own configuration options, behaviour, quirks and file locations.

7. Eventually learn a programming language. Focus on Java, Python and Ruby. Figure out something you want to automate, or think of something simple you’d like to create. For example, a simple fuzzer or request/response interceptor.

8, 9 and 10. Same as Keatron Evans' list.