Penetration testing - service or commodity

Monday, February 23rd, 2009

We face this kind of issue everyday. There are two different approaches to web application penetration tests:

• An increasingly number of companies are buying automatic web scanners, run them, generate some results and put them in a report-shaped tin, ready to go to the client. No human interaction with the application is needed.
• Some other companies allocate X numbers of days of a highly skilled consultant to assess the security of your web application. Among many other tests the consultant will also run automatic web scanners, but that is only scratching the surface of a real penetration test. The consultant will use all his/her experience to analyse many other factors of the application.

Penetration testing is all about assurance. In the first case the client will get some useful results, no doubt about it, but what level of assurance is it going to get? The report will cover the vulnerabilities discovered by XYZ software. Is that enough? I don’t think so, but that is for the client to decide. There is no question that the report will be incomplete and many issues will be missed.

In the second scenario the client can get the assurance that the results obtained were the work of a motivated attacker focused on the application security for X numbers of days. Is that enough? Again, it is up to the client to decide but in my opinion it gets so much closer to an acceptable assurance level.

It all depends on what do you want to be protected against. The decision in yours.

Tags: information security assurance, penetest, penetration test, Penetration Testing
Posted in Penetration Testing, Risk Management | 1 Comment »

Practical attack against SSL certificates - Creating a rogue CA certificate

Tuesday, December 30th, 2008

In a presentation at the Chaos Communication Congress (Berlin, 27-30 December 2008) Alexander Sotirov, Marc Stevens and Jacob Appelbaum revealed how a weakness in the MD5 hashing algorithm could be used to create a rogue certificate.

Previous research showed the theory of this attack but this is the first practical implementation exploiting this flaw.

SSL uses server certificates to verify the identity of the server (this is the public key of the owner) and prevent man-in-the-middle attacks. When a user visits a secure (HTTPS) site the web browser retrieves the web server certificate issued by a CA (Certificate Authority). The fundamental security issue comes when a CA signs the certificate using a weak hashing function such as MD5.

Using “Chosen-prefix MD5 collisions” an attacker could manipulate a legitimate CA certificate and create a rogue one with arbitrary domain name with the same MD5 signature as the original one.

The researchers used a cluster of 200 PlayStation 3 to compute the correct MD5 hash. They used a field in the certificate called Netscape Comment Extension to inject the necessary code:

Injected code

A sample of the certificate can be found in the following URL:

https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/

The impact of this attack is that an attacker could sign fully trusted certificates and conduct perfect man-in-the-middle attacks.

As anyone could generate this kind of certificates, revocation of known malicious certificates is not a possible option. SECFORCE recommends that the content of the Netscape Comment Extension field (and other similar fields) are checked before accepting a certificate.

Tags: certificates, certificates authorities, md5, rogue certificates, signature collisions, ssl
Posted in Phishing, Risk Management | No Comments »

Penetration testing and risk management - Consultants vs Monkeys

Thursday, October 30th, 2008

There are no doubts that penetration testing is becoming mainstream now. It looks like business are eventually concerned about security. Compared to some years ago the number of companies requesting penetration tests has increased exponentially and therefore the number of companies conducting them has incresed too.

One of the important problems affecting some penetration testing companies is that they conduct penetration tests with a very narrow perspective, they don’t put things into context. I call it monkey work. It is quite easy running an automated vulnerability scanner and produce a nice report. However, vulnerability scanners are not clever enough to know how a specific vulnerability affects a bussiness.

A typical example is XSS vulnerabilities. Depending on the context they can be devastating or just a minor issue. It is up to the penetration tester to decide how important this security issue is for the business. I call it consultant work and it is where risk management comes into the game.

At the end of the day a business man just cares about the business. If he/she is conducting a penetration test it is not due to the pleasure of learning about buffer overflows and injection vulnerabilities - it is because he/she thinks the penetration test is good for the business (due to a number of reasons such as clients trust, compliance, etc.).

Therefore what they really want to know about a security issues is:

• What is the impact for the business
• What is the likelihood of happening
• How can be solved

What they are not interested in is:

• Why stack protection mechanisms can not protect you from a heap overflow
• How you control EIP on this exploit
• Why a fuzzer would have never discovered that vulnerability
• etc…

Tags: Penetration Testing, Risk Management
Posted in Penetration Testing, Risk Management | No Comments »