Archives for 2014

Drupal and WordPress frameworks are vulnerable to a denial of service condition within the XML-RPC service.

Details of the issue can be found here on the official sites for Drupal and WordPress. Basically the attack works by sending an XML-RPC call to the remote site with an initially small XML document. This element of the document is then iterated multiple times, expanding the document to an even larger size.

How does this work? Well, a small initial file of 200 KB will expand to 2.5 GB on the remote server due to a vulnerability called an XML Quadratic Blowup Attack. Attempting to parse multiple requests leads to all resources being consumed. This results in the application and even possibly the whole system falling over.

Using a simple proof of concept script it was possible to kill an entire site and underlying operating system within a few moments:

“System running out of memory. Availability of the system is in risk.”

Unless you have previously disabled XML-RPC or have patched your Drupal and WordPress frameworks in the last few days you are currently exposed to this denial of service attack and we would recommend that you update to the latest version of your framework as soon as possible.

So after a busy day at my graduation, I had the opportunity to fly out for day two of OWASP AppSec EU. An opportunity I took, naturally. Having been to a number of OWASP chapter meetings but never an AppSec conference, I was very much looking forward to it. I am happy to report that, with around 350 people from all over the globe and a variety of backgrounds, it didn’t disappoint!

Below is a brief overview of the talks that I attended.

OpenSAMM Best Practices: Lessons from the Trenches

By Seba Deleersynder & Bart De Win

The first talk I made it too was on the OpenSAMM project. It began with discussing what the OpenSAMM framework is and the challenges faced with adoption. The talk then moved on to look at what has worked well and what hasn’t for organisations try to implement OpenSAMM. This included a look at the lessons learned so far throughout the continued development of the project. Discussion was had on how to try and allow companies to assess where they are in relation to maturity towards education and awareness levels. Overall, OpenSAMM looks to be a great project and all involved seem to be making real strides with it.

Making CSP Work For You

By Mark Goodwin

A surprise talk as the original talk did not happen. None the less, Mark delivered a great job standing in and taking over with an interesting talk on Content Security Policy and its current place in security for defending against attacks such as XSS. He then went on to discuss some unsafe functions typically found within applications that make them vulnerable. Such as Eval in JavaScript and the need for separation between code and data due to the two becoming confused with each other. The talk contained some nice practical examples and interesting statistics. One big statistic that stood out was that out of the top million websites only 300 currently use CSP. Showing that more can be done to raise the overall security posture for applications.

ActiveScan++: Augmenting manual testing with attack proxy plugins

By James Kettle

A nice talk on the Python plugin ActiveScan++ that James created for use within burp suite. The talk cover the benefits associated with implementing vulnerability scanners into intercepting proxies as well as their drawbacks. It looked at how automating attacks, host header injection/poisoning, cache poisoning, DNS rebinding and relative path overwrite could be done with some good practical examples. The talk finished off by looking at fuzzy point detection and its potential effectiveness. ActiveScan++ was launched with this talk too!

Metro down the tube. Security Testing Windows Store Apps

By Marion Mccune

As the name suggests this talk was focused on security testing Windows store applications and the direction Microsoft are heading with these applications. Discussed were the different kinds of frameworks and applications currently utilised by Microsoft. Additionally what security is and is not employed including a nice extract of which of the OWASP top 10 are actively tested for. Also covered was the prospect of universal applications that Microsoft are looking to employ meaning that one single app could be ran on anything from a 4” smart phone to a Xbox One on a 50” screen.

Can Application Security Training Make Developers Build Less Vulnerable Code?

By John Dickson

My final talk of the day was from John Dickson and focused around a study he carried out last year in North America. The study looked at assessing software developer’s depth of security knowledge. It was targeted at software developers and the results were very interesting with outcomes such as: High turnover in staff in relation to software developers typically between 20-30% per annum and in areas such as Silicon Valley it can be even higher. There for if you trained your developers 2 years ago, they aren’t the same developers you have right now, for a varying number of reasons.  Meaning your development team can be completely different every few years so training must be recurrent. Other results included looking at how many developers had been given training, unfortunately the specifics were not questioned i.e. how long ago was it, and what did it actually consist of/its intensity. Something I believe John is going to look at in the future when carrying out further surveys.

Aftermath/conclusion

Overall I thoroughly enjoyed my first time at OWASP AppSec EU with the 7 Elements team, the talks were good; stands were excellent as were some of the freebies! Unfortunately I missed the Automatic Detection of Inadequate Authorization Checks in Web Applications. Thankfully however there is a YouTube channel for the conference with all the talks so if you are interested I recommend checking that out! It was also nice to see such a large number developers attending.

I will leave you with one final statistic from the conference, 83% of software Developers know what XSS is but only 11% know how to remediate against it. Definition of “know” to be confirmed. But still shows that a lot of education is still required.

Know what you’re asking for and what to expect

People often ask for penetration testing without knowing what it really means or does. The word has become ubiquitous within the field of information security and means very different things to individuals and organisations.

Even security professionals are at fault here, interchanging words such as pen test, vulnerability assessments and other related security words to fit the current situation. In some cases the same term is used differently within the same conversation! Unfortunately this can this can lead to an organisation failing to gain the right level of assurance required.

To help organisations understand what it is they require and assist them in provisioning the right security test we have laid out the different types of tests that come under the security testing banner and what you can expect from that test.

An Overview of Security Testing

There are four key types of testing that come under the banner of Security Testing, the most commonly referred to being a pen test or penetration test.  The following diagram lays out the different types of security testing and highlights the extent to which automated testing tools are used compared to manual testing.  As we move up the pyramid the level of skill required of the tester increases.  

We will now take a look at each of the types of security testing, detailing what it is and what you get from each.

Vulnerability Scan

What is it?

The scan uses automated tools to identify known security issues through matching conditions with known vulnerabilities.

What do you get?

The tool automatically sets the risk level for the results of the scan and no manual verification or interpretation of the results prior to issue takes place.  This is great for identifying technical vulnerabilities at a low financial cost. However, it also generates a high level of false positives while missing certain types of issues.  This limits the overall level of assurance gained.

Vulnerability Assessment

What is it?

A vulnerability assessment takes a vulnerability scan a step further by using a security tester‘s knowledge to drive an appropriate use of automated tools and test scripts.

What do you get?

The report for the results should be manually created, which places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and overall context of a finding. It is great for increasing the level of assurance gained through automated testing, whilst still helping to keep costs low.

Security Assessment

What is it?

A security assessment builds upon a vulnerability assessment by adding manual verification of the results to confirm the level of exposure.  It does not though include the use of exploitation code to gain further access to systems.

What do you get?

A security assessment is looking to gain a broad coverage of the systems under test but does not consider the depth of exposure to which a specific vulnerability could lead. False positives should be excluded through the analysis of the results. Security assessments are great for exposing business logic flaws and identifying security vulnerabilities that automated tools are unable to identify. This leads to a higher level of assurance. However, the time and effort required to complete a security assessment are higher than vulnerability scanning and assessments and require a higher level of technical skill to deliver.   This will increase the cost of an engagement.

Penetration Test

What is it?

Penetration testing simulates an attack by a malicious party by using tools and manual investigation to identify weaknesses. Testing involves the exploitation of found vulnerabilities to gain further access. Using this approach will result in an understanding of the ability of an attacker to gain access to confidential information, affect data integrity or availability of a service and the respective impact.

What do you get?

This approach looks at the depth and impact of a potential attack, as compared to the security assessment approach that looks at the broader coverage.  It is great for understanding the depth of exposure from a vulnerability but it can result in a narrow focus that potentially misses other vulnerabilities that would have been identified through a security assessment.  The level of assurance gained is directly associated with the ability of the tester, the scope of engagement and the time and effort allocated.

Finding the right level – some considerations

All levels of security testing are valid assurance activities but it is important that you choose the level that is right for your needs.  Organisations need to balance risk appetite, cost, the level of assurance required, the threat landscape and any regulatory requirements (if applicable).   In our next blog post we will consider how to align security testing with the threat landscape.