Wednesday, December 12, 2012

MVIS Security Center Version 1.1

Good afternoon,

we have just released MVIS Security Center (MSC) version 1.1, which besides improvements and enhancements to its functionality and user interface, adds another exiting feature for MVIS PROtection subscribers - Weekly Status E-Mails!

Currently, the e-mail summarizes information about which sites have an active protection, how many vulnerabilities are known for each site and how many of those vulnerabilities are unsolved - meaning no patches/updates are available.

This weekly status information is very useful for users that are responsible for the security of many WordPress powered sites and will save them a lot time that is normally lost by manually checking each of the sites.

Stay tuned for updates, because we are already working on enhancing the weekly status mails to contain even more useful information.

So if you haven't given MSC a try yet, download it here to enjoy a secure WordPress experience!

Friday, November 23, 2012

Know Your Tools!

There are several mantras when it comes to developing secure software. The most important and therefore the number one is: "Never ever trust the users input!" The second one would be: "Use as much privileges as necessary and as little as possible!" aka "Least Privileges". There are many more, but usually these two rules can be seen as "Catch-All" rules. As soon as you start to design, implement and test according to these rules, all the other rules seem to be commons sense. You don't start to argue why you should use prepared statements -> Rule 1! Always check buffer sizes? -> Rule 1! Use different users during installation and production? -> Rule 2!

Still, during my secure development classes I add one more: "Know your tools!" With tools I do not mean your favorite IDE or a text editor, but the programming language and frameworks in use.

While modern IDEs and frameworks suggest how easy programming nowadays is this easiness lulls the developer into a false sense of knowledge and security. This starts by not knowing which output methods are XSS safe (and why) and doesn’t stop at the ignorance against LINQ-Injections. This is security by luck. Sure, frameworks are complex and as a real hard-core programmer you write your own frameworks which you know by heart. This leads to the equally important question: “How good do you know the programming language you wrote your framework in?” Without excellent knowledge of the programming language you are bound to make mistakes because of assumptions. Assumptions you don’t even know you make.


Can you predict the result of the following statement?

Integer var1 = 0;
Integer var2 = 0;
System.out.println(“var1 == var2?+ (var1 == var2));
System.out.println(“var1.equals(var2)?+ (var1.equals(var2)));

Easy, isn’t it? Both times we get a “true” as result.

But what happens if we replace 0 with 128?

Integer var1 = 128;
Integer var2 = 128;
System.out.println(“var1 == var2?+ (var1 == var2));
System.out.println(“var1.equals(var2)?+ (var1.equals(var2)));

Now the world looks different. While the “equals” method still returns “true”, the “==” now returns “false”. Can you imagine how long it will take to find a bug which only occurs if a certain value is higher than 127?

While we are on it:

Integer var1 = 128;
long var2 = 128L;
System.out.println("var1 == var2? " + (var1 == var2));
System.out.println("var1.equals(var2)? " + (var1.equals(var2)));

This time “==” returns “true” while “.equals” returns “false”

There is always a reason why Java behaves like this. It might not always be a good one and some reasons are obsolete now, but these features are still there. It’s not only Java, other languages have features like this too.
With the introduction of reflection in modern languages it gets even weirder. In my whitepaper “The Source Is A Lie” I point out how to manipulate seemingly constant strings. This technique isn't only working for strings, it can be applied to almost any type which is auto-boxed. Can you imagine what happens if you change the value of the constant “Boolean.TRUE” to “false”?

The point is…

As captain obvious would say: “We are living in a fast paced world” For IT this world is blazingly fast. There is a new programming language popping up almost every month. Keeping up with the hype is required if you want to stay on top of the hiring pool (or learn ancient languages like Fortran and Cobol).  Yet, to write secure and bug free code one has to learn and understand the programming language and its environment. This isn't done within one month, or one year. Like everywhere and especially in security, you have to make some compromise and set your priorities to fit your needs.

Monday, November 19, 2012

Introducing: MVIS Security Center for WordPress

Hello WordPress Community,

I am excited to officially introduce the (Managed Vulnerability Information Service) MVIS Security Center, a plugin for your favorite Content Management System. Before explaining the functionality of the plugin, I want to share the story behind it with you.

Two friends of mine run a small online business which is their sole source of income and they rely on its uptime and integrity to earn their living. Their main website is build with WordPress and an e-commerce solution to allow their growing user base to read about the latest fashion trends and buy their imported products online. 

Unfortunately, one day they were hacked and their website was blacklisted for hosting malware, which reduced their earnings for that month significantly. They were desperate and asked me to help them with their problem at hands. It quickly became clear that the hackers got access to their site through a combination of insecure WordPress settings and outdated plugins and after cleaning everything up, one question remained.

How can we prevent this from ever happening again? 

Anyone who has ever spent some time on the WordPress forums will know that users get hacked every single day. The problem is that not everyone running a WordPress website is fortunate enough to have security savvy friends that can help and chances are that the majority of WordPress users won't be able to purchase professional security services either. This is where MVIS Security Center comes into play.

We analyzed the root causes of hacks for WordPress powered websites in order to figure out how these attacks can be efficiently countered, while at the same time keeping things simple enough to be followed and understood by everyone.

Knowledge Is Power - Arm Yourself! 

It is all about having the right information at the right time. MVIS Security Center will provide you with all the information you need to lock down your website. The plugin checks for most of the topics covered in the WordPress Security Codex and quite a few additional ones. You will see at a glance what needs to be done to make your site secure, because for each of the identified security problems, we provide detailed information on what the problem is and how to resolve it.

Understand, Evaluate, Resolve

One of the things that makes MVIS Security Center stand out is that it enables its users to understand the security risks of the identified problems as opposed to automatically "fixing" problems, which more often than not cause troubles with the site.

Each of the identified security issues are described in detail. This gives people the chance to actually understand the underlying problem and decide whether this specific insecurity is a real threat to their site or a risk that can be accepted. Every website is unique and so are their security requirements. MVIS Security Center is the tool that provides you with all the information needed to make educated decisions and eliminate the security risks that matter for your sites.

This way you will also know exactly what changes are being made to your websites and why they are made. You make the decisions and stay in full control!

The Game Changer

One of the most common reasons for successful attacks against WordPress powered sites are outdated plugins that contain publicly disclosed vulnerabilities. We have a dedicated team of security experts analysing all newly disclosed vulnerabilities, verifying them, rating their risk and entering them into our database. You can now subscribe to this professional vulnerability information feed from within the MVIS Security Center plugin. We will create an accurate profile for your site and send you alerts when a vulnerability in your installed software is found, along with instructions on how to make your system secure again. All installs, updates or removal of your WordPress components are tracked to ensure that you will always receive the most accurate information.

This is a subscribe and forget solution. You will be receiving an e-mail as soon as your interaction is required. Especially if you are responsible for multiple WordPress based sites, you will greatly benefit from the added convenience of getting the security relevant information to your inbox without needing to login and check multiple WordPress backends.

So who is this plugin for?

MVIS Security Center was created for everyone that loves WordPress and wants to enjoy it without loosing sleep at night, just like my friends who have an online business and anyone else that uses WordPress for commercial or non-commercial reasons and wants to become safe and secure.

Download MVIS Security Center here.
More information about the MVIS technology can be found here.

Wednesday, October 24, 2012

Application Security of Core Banking Systems - A first reality check

Nowadays the constant discovery of new vulnerabilities and an increasing interest from the public puts pressure on software vendors to improve their products. Also with a rapidly growing number of security incidents, companies and organisations start to realise that the aftermath of security breaches related to vulnerabilities in proprietary and 3rd party applications causes considerable costs. Therefore an increasing number of organisations in the public and private sector acknowledge the importance of application security and start to make it an evaluation criteria for software procurement.

An area that is rather uncharted in terms of its level of commitment to IT security is the domain of Core Banking Systems (CBS). Who has ever heard of products like Avaloq, Flexcube or T24? If you are not working in the finance industry the chances are not very high that you have. The terminology refers to software that enables a bank to merge information technology to suit with its core needs of banking. Credit and loan-processing, account and transaction management, interest calculations and performing payments are just a few examples for the powerful and wide ranging capabilities of these systems. CBS products incorporate many daily operations of a financial organisation therefore the protection and the security of these systems require the highest priority.

Considering the importance of CBS products not only for a single financial organisation but for the entire financial ecosystem, SEC Consult decided together with Capgemini to shed some light into the maturity of CBS products in terms of application security. The study was written, conducted and compiled over a period of nineteen months, consisting of two parts, a vendor survey and a security test for selected CBS products. Although most of the selected vendors (Avaloq, FIS (with two products), Infosys, Misys, Oracle, SunGard, TCS Financial Solutions) participated in the study, there were unfortunately some, which did not take part (Callata├┐ & Wouters, Delta Informatique, SAP and Temenos). This article focuses on the security testing part of the study, illustrating CBS vendor’s pretense about their security testing approach and their findings. Additionally results of our own application security tests of selected CBS products will be depicted.

Part 1: The survey

We asked CBS vendors about their promises, commitments and relevant activities relating to the application security of their product. A detailed questionnaire was sent to all vendors and we recommended that the person responsible for IT security should answer the questions or at least conduct a quality assurance exercise of the questions and answers. The questions can be categorised in the following areas.

      Level of commitment to application security
      Management of information security
      Training for developers in application security
      Methods of secure development
      Threat modelling and security requirements
      Size and complexity of CBS product
      Security Testing & Identified Vulnerabilities
      Security Incident Response
      Standards and best practices for application security

One of the first findings we made when analyzing the questionnaire is that all of the vendors have an unquestionable commitment to state-of-the-art application security. The vendors describe the maturity of their CBS products in terms of application security as high, mature or highly sophisticated. The industry recognizes application security as an important objective and that is great news for anybody who uses CBS products and ever wondered if they are secure.

In a typical software development lifecycle the security testing phase is one of the last possibilities to identify gaps in terms of security requirements.  In order to test if the desired assurance level for application security is achieved, three levels of test depth can be applied.

The answers from the vendors regarding their security test approach vary significantly from each other. On one side of the spectrum are vendors who claim to have full coverage of their code base using all three test approaches and on the other end there are the vendors who do not cover the majority of the code base or even do not perform security tests with medium or high assurance levels at all.

An obvious conclusion to these findings is that a low assurance level for CBS products is clearly not sufficient, therefore some of the vendors have to step up their security testing efforts. Vendors also have to be prepared to put their claims to the test. Banks are advised to actively test the security of CBS products and include detailed security testing as an important aspect of a product evaluation process.

The collected data about security vulnerabilities identified by vendors in their CBS products varies considerably in terms of the quantity of discovered security weaknesses. Some vendors indicated that they have not encountered a single vulnerability during their security tests; others said that they have found more than 100. During our many years of performing application security tests we virtually never had an application where we did not have at least any low impact findings at the initial test. Having no findings at all is a strong indicator for the low quality of the performed application security tests. For the sake of fairness it has to be said that having hundreds or even thousands of findings does not necessarily proof a high quality security test either. Especially automated tools are notorious for producing a lot of false positives. For this reason not only the volume of found vulnerabilities has to be taken into account but also the quality of the results.

Part 2: CBS security testing        

In order to validate the results of the survey we originally intended to conduct the second part of the study by performing application security tests for the vendor products we had surveyed. So we offered a free of charge application security test to be conducted by our security experts on a test system provided by the vendor. Certain vendors showed a serious interest in participating but unfortunately, after certain deliberations, all vendors declined to participate.

While developing an alternative approach to the second part of the study we managed to gain support from the financial service industry. Fortunately, three banks allowed us to have a look at their CBS systems, which were already implemented, by the banks in question. As a result at least three of the products described in part 1 have been included in the second part of the study.

All of the three CBS products were tested using a blackbox approach. For the security tests only low-privileged users were provided. For all of three CBS products severe and critical vulnerabilities had been discovered. None of the vulnerabilities had been discovered by the quality assurance process of the vendors. The following types of vulnerabilities and the resulting technical impact have been discovered during the application security tests:

  • Cross Site Scripting (XSS) - Stealing the identity and spy a CBS user 
  • Privilege Escalation - Become a more powerful CBS user
  • Weak encryption - Stealing the password of a CBS user 
  • SQL Injection - Direct access to the database 
  • Direct OS Command Execution - Remote control of the server of the CBS

All of the found vulnerabilities were fully exploitable and proof of concepts including videos were created for each of them. In order to protect the participating banks as well as other customers we will not disclose any details regarding the vulnerabilities, the tested products and the participating banks.


During a decade of working in the IT security industry we have seen it so many times in the past with our clients and also software vendors we are working with - security does not happen overnight. It is a process and for those software vendors who did not have security in mind at the time they designed the software or during the software development phase they usually start at the bottom and the bottom means no or very low security. CBS products are found usually in a bank's internal network, but as these systems incorporate more and more functionality and serve as backend systems for Internet facing systems the attack surface is definitely growing. The results of our study have shown that at least some CBS vendors have to significantly improve the application security of their products. Further owners of CBS products are strongly advised to actively validate their products and to incorporate security requirements in any future procurement process. 

How to get the study?

For the complete study, send an email to or visit

Thursday, October 18, 2012

Are web application firewalls useful? A pentester's view.

After doing some research on what I thought was a hot topic for the last few weeks - web application firewalls (WAFs) - I was surprised about what I saw at a recent vendor sponsored security conference: No mention of WAFs whatsoever! WAFs have been superseded by the Next Big Thing, which is "Next Generation Firewalls" (basically a revamped IPS/IDS that also includes a WAF).

It was also claimed at this conference that, based on a recent study, old-school packet filter firewalls block only 10% of attacks. This sounded about right. However it was also claimed that the remaining 90% would have been blocked if only a Next Generation Firewall had been in place. Web application attacks were given as an example of the kind of attacks being prevented.

If we assume that Next Generation Firewalls work like existing WAFs, this statement is simply not true. In fact, our experience with WAFs so far has shown quite the opposite: If there is a serious vulnerability in a web application, it doesn't matter if you put a WAF in front of it or not. Even if there is a WAF, a skilled attacker can almost always still exploit the application. In fact, because a WAF introduces an additional piece of software into your setup, it may even create additional possibilities for attack.

The main problem is: A WAF has to make extremely difficult decisions. A firewall is not a magic wall that somehow blocks attackers. It's a simple administrative tool. Traditional packet filter firewalls are so effective because they "just work". The filtering is done based on properties of the TCP/IP packet, so there's just a few things you can base your filter rules on. It's straightforward to configure and almost impossible to mess up.

Here is an iptables rule:

iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80--syn -j ACCEPT

This allows inbound HTTP connections. Let's compare this to at a typical rule from ModSecurity:

SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(?i:(?i:\d[\"'`´’‘]\s+[\"'`´’‘]\s+\d)|(?:^admin\s*?[\"'`´’‘]|(\/\*)+[\"'`´’‘]+\s?(?:--|#|\/\*|{)?)|(?:[\"'`´’‘]\s*?(x?or|div|like|between|and)[\w\s-]+\s*?[+<>=(),-]\s*?[\d\"'`´’‘])|(?:[\"'`´’‘]\s*?[^\w\s]?=\s*?[\"'`´’‘])|(?:[\"'`´’‘]\W*?[+=]+\W*?[\"'`´’‘])|(?:[\"'`´’‘]\s*?[!=|][\d\s!=+-]+.*?[\"'`´’‘(].*?$)|(?:[\"'`´’‘]\s*?[!=|][\d\s!=]+.*?\d+$)|(?:[\"'`´’‘]\s*?like\W+[\w\"'`´’‘(])|(?:\sis\s*?0\W)|(?:where\s[\s\w\.,-]+\s=)|(?:[\"'`´’‘][<>~]+[\"'`´’‘]))" 

What does this rule do? Right, you have no idea, because nobody can actually read regular expressions like this! And this is part of the first problem with WAFs. The rules required to detect or block any form of attack are extremely complex, if its even possible at all.

Same as with a packet filter firewall, the WAF is based on rules. But to define the right rules, you have to know in advance what an attack on the web application you are going to protect might look like. To know that, you need to know exactly how the web application works and what kinds of vulnerabilities it has. And even if you knew exactly how your web application was going to be attacked, it would be extremely difficult to define the right rules to prevent the attack. It is usually more difficult than fixing the application itself.

The following is a list of some of the main problems with WAFs.

WAFs only work with standard architectures 

Web application firewalls work well with standard web applications, such as simple PHP or Java Servlet applications. In the real world you have some of these standard web applications, but web applications can also look and behave very strangely. Just look at the kind of requests that Jetspeed and other Java Frameworks generate - without reading the source code of the web application you have no idea what's going on - and neither has a WAF. I have seen people developing their own Java scripting engines, using obscure programming languages (anybody heard of Erlang?) and even coding their own web servers. You cannot expect WAFs to deal with architectures like that.

WAFs only block standard attacks

WAFs can detect attacks only if they look like attacks are expected to look like. So usually that would be Cross-Site-Scripting, SQL injection, and so on that are exploited via the usual input channels. But there are many vulnerabilities that do NOT fit into these patterns. This kind of vulnerabilities is actually quite common.

As an example, a web application recently had a vulnerability where it was possible to upload ZIP archives which were then unpacked on the web server. The unpacking was done by some Java code that scanned the filenames listed in the archive and then unpacked the files into some target directory on the server. The problem here was that there was no sanity check on the filenames contained in the ZIP archive, so it was possible to extract a file directly into the web root of the application and by doing this, execute arbitrary code on the server.

Now if there was a typical WAF in place would it detect this kind of attack? Only if it was actually scanning the content of ZIP files that were uploaded. In theory it would be possible for a WAF to parse and inspect an uploaded ZIP archive. But then there would be a lot of other filetypes that would have to be inspected as well. Anyway, no WAF that I know of does this.

Restrictive rulesets generate too many false positives

If you actually want to prevent a large amount of attacks with a WAF you have to use a ruleset that is extremely restrictive. A good example for this is the OWASP core ruleset for mod_security. If you use this ruleset in the default configuration, it will block nearly everything that even remotely looks like an attack. If you have a ruleset like this, it indeed becomes more difficult to perform some kinds of attacks. But on the other hand, in most applications that have a lot of user interaction you will get a lot of false positives.

Here are some examples for things that would cause a false alarm with mod_security. Any of these sentences in user input would be blocked by the OWASP base rules.

today i selected orange juice from the juice machine
i am feeling well today :) and you?
that’s a nice curl you got there in your hair

WAFs do not protect against application logic attacks

There are many forms of attacks that WAFs do not detect at all. This includes all kinds of logical vulnerabilities. Imagine the following HTML comment on an admin login page:

<!-- The admin password is vnjr83rh43!, don't forget to delete this comment later! --!>

Somebody put the administrator password into the HTML source and you could simply use it to login the the admin interface and compromise the application. Now for a WAF, this would not look like an attack - the WAF has no way of knowing if the person logging in is a legitimate administrator or an attacker.

For a human attacker it is easy to apply the facts he learns about the web application. Sometimes we find trivial issues that cannot be detected by any kind of automated scanner of WAF.

Other logical issues include missing or insufficient authorization and issues with session management. Additionally, as the WAF does not actually know or understand the business rules of the application, it cannot detect possible violations of these rules.

There are many simple ways to bypass WAF rulesets

Even for the kind of attacks that should be prevented, there's an almost unlimited number of ways to bypass the WAF. SQL injection attacks are a good example. WAFs have a number of patterns that are unique to SQL injection attacks and check the supplied content for these patterns.

Let's say you find a simple SQL injection vulnerability and want to exploit it. Your goal will be to find out what exact pattern the WAF uses to detect this kind of attack and then obfuscate the attack so it does not match the pattern anymore. Here are some simple examples for rewriting a UNION SELECT statement that I have actually used to bypass WAFs.

p1 = 1+UNION++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++SELECT+cc+FROM+creditcards+--

?p1 = 1+UNION%09SELECT+cc+FROM+creditcards+--

?p1 = 1+UNION%0aSELECT+cc+FROM+creditcards+--

?p1 =  UNION\s+SELECT?p1=1+UNION/**/SELECT+cc+FROM+creditcards --

Attackers will study the database manual to find different ways to make the database query they want. They know that the WAF has a limited set of patterns that it can detect and in most cases it will be possible to find some way to make a query that is not detected.

WAF parsers are easily confused

Sometimes a WAF has such a restrictive ruleset that it is just not possible to get trough with an attack. The current version of mod_security with OWASP CRS is a good example for this, which is very restrictive even in the default configuration. In this case, the attacker has to rely on other techniques to bypass it. In that case, there is a whole other class of bypass techniques that rely on the following principle.

In a WAF setup every request that is received is parsed twice. First, it is parsed by the WAF to determine if there is an attack or not. If the WAF thinks that the request is legit, it passes it on to the web server for processing. Now in many cases, the WAF may interpret parts of the request in a different way from how it is then processed by the web application. And if we know exactly how, we will be able to evade detection by the WAF. Some also call this the "impedance mismatch" issue.

One example for this is HTTP parameter pollution. This sounds very fancy, but it simply means passing the same parameter to the server multiple times [1].

Another area that is traditionally problematic is multipart requests. A multipart request is the kind of request that is sent when you upload a file, for instance. Still, you can send every POST-request with a multipart encoding and this is processed like any normal POST request by the web server.

Parsing multipart requests is rather tricky and WAFs have the problem of having to match every parser by every web server and scripting language out there. It is often possible to bypass detection by a WAF by sending multipart requests that are interpreted differently by the WAF.

ModSecurity for instance has a very strict multipart parser to prevent this kind of attack. This means that it sets very strict limits for what kind of multipart requests it lets through. Even so, there are ways to bypass it. For example, a way to evade detection using single quotes in multipart requests was documented by Stefan Esser in 2009 [2].

Another bypass I found last month also has to do with parsing multipart requests. This time we use a double Content-Disposition header and terminate the first header with an additional carriage return. Again, this allows bypass of ModSecurity for arbitrary POST parameters [3].

Encodings are another problem area. My colleague Gerhard recently found a bypass technique for a commercial WAF called Airlock. In this case it was possible to completely bypass the WAF by supplying Null-bytes with an overlong UTF-8 encoding [4].

So even if you have a WAF with restrictive rules then it is usually possible to bypass it by using different forms of requests, encodings, and so on until something is found that the WAF parser does not understand but the web server does.

WAFs may introduce additional vulnerabilities

By installing a WAF you introduce an additional piece of software into your network and this software may have vulnerabilities of its own as well. A WAF has its own HTTP parser, for example. If this is not developed securely, then there will be buffer overflows, format string vulnerabilities and so on. So by turning on the WAF you might actually give an attacker additional opportunities to hack your server.

Commercial WAFs are usually not tested that much by security researchers as they are not that widely used and it is a bit tedious to obtain trial versions - you usually have to contact a sales rep. So it might be easier to find vulnerabilities in these WAFs than in well-tested software such as Apache and PHP.

During my latest research I have been looking at a commercial WAF and found a format string vulnerability that allowed execution by of arbitrary code on the affected system. Using this WAF would possibly allow an attacker to compromise the web server, even if the web application itself would have been secure (this vulnerability has not been made public yet).


While WAFs sound very good in theory they do not perform all that well in practice. In fact there are many problems with them. First, there are many types of vulnerabilities that WAFs do not protect against at all. And for those that they should protect against there are usually ways to bypass this protection.

The only scenario where WAFs should be used is as a workaround. If you know that a web application  you are running is vulnerable and you have really no way of fixing the application itself then you can use a WAF, but you have to remember that the default configuration will not be enough to protect the application. You need to know exactly which vulnerabilities the application has and you will have to configure the WAF to block exactly these attacks.

And finally, before you buy a WAF, make sure that it does not introduce new vulnerabilities into your system. Only use a WAF if you can be sure that it has been developed with secure software development practices in mind. Ask the WAF vendor what processes he has in place to ensure this.


[1] (Paper on HPP by Marco Balduzzi)
[2] (Stefan Esser's WAF Evasion)

Monday, July 23, 2012

Solving cloud security issues at the root

Cloud security is a popular buzzword in the security industry these days. New security challenges introduced by the cloud include issues related to compliance and law - such as where data is allowed to be located physically - as well as technical issues. However, we don't really face any new technical challenges. Cloud security in a technical sense is more a combination of old issues such as data segregation, virtualization and web application security.

It is of course important to deal with the new challenges posed by cloud computing. Standards and best practices are needed to allow for a secure transition to the cloud. The Cloud Security Alliance, a non-profit organization headquartered in Singapore, has taken on the task of providing the necessary security standards and is also providing education on the secure use of cloud computing.

Security vendors are jumping on the cloud security bandwagon as well, offering cloud security solutions as well as cloud-based security services. There is a market for these products for sure, but we should not let these products divert our attention from the fact that we are dealing with essentially the same problems we have been dealing with for the last 30 years: That the software, systems and protocols we build are inherently insecure.

In my opinion, this is a very important point. We like to go with the hype because hype sells. But we would achieve more if we would focus on the fundamental problems. And in IT security, the fundamental problem is missing security awareness - with system developers as well as end users. IT systems are designed and build without security in mind, and users are not aware of security threats. If we could only build secure servers, applications and protocols, and use them carefully, we would not have to add security solutions as an afterthought.

Imagine we had a new, secure operating system that is unlikely to be breached. Many of the security issues relevant to cloud computing and many other issues, including virus and malware threats, would vanish. With todays knowledge it would be possible to design a fundamentally secure operating system - only the market does not seem to see a need for it.

Web applications are another big topic in cloud security. Nearly all big cloud consumer applications are web based - examples include SalesForce CRM and Google Apps. While it is arguably difficult to build a truly secure operating system, building a secure web application is definitely something that's achievable. It would already go a long way if web developers could be educated to follow basic secure programming practices. If we would build secure web applications, we would eliminate another set of threats (and the need for a whole lot of security products).

Most other technical cloud security issues, like most other technical security issues, are related to secure architecture design and secure coding. Virtualization software has to be designed securely, and encryption of data in the cloud has to be implemented properly. Of course, all components used in a cloud infrastructure have to be configured securely as well, which is where cloud security standards come into play.

Granted, we are very far from a perfect security utopia where nobody needs firewalls and antivirus. Basic security principles such as secure coding don't have the hype factor of cloud security solutions. But I still think we should focus our efforts on the causes instead of fighting the symptoms if we want IT security to advance as a whole. This means designing and implementing more secure systems and applications, be it in the cloud or anywhere else.

Monday, June 25, 2012

The five worst web application security flaws

Web applications are the achilles heel of most corporate networks. In a given penetration test, it is almost always proprietary web applications that show the most critical vulnerabilities. We were interested which types of web application flaws we actually find and exploit most often with the highest impact - the "top worst security flaws" found in typical web applications. Our analysis shows that some of the most published flaws, such as cross site scripting and remote file inclusion, are not necessarily the most relevant ones in practice.

Our data source is a random sample of 50 web applications tested during the last two years. This includes penetration tests and source code reviews of all different kinds of web technologies. To determine the "winning" vulnerabilities, we plotted a chart that factors in the frequency and average security risk caused by the vulnerabilities occurring in the sample. The Y-axis shows the average risk (composed of exploit likelihood and impact) caused by the flaw. The X-axis reflects how often the vulnerability occurred in the sample.

* Occurrence rate: Percentage of web applications tested where at least one vulnerability of this type was found
* Risk: Average risk score (calculated as exploit likelihood x impact) of all vulnerabilities of this type within the sample
* The category "others" includes some of the more exotic flaws that occurred only once in the sample, such as forgotten backdoors, SWF file include and LDAP injection.

The winners

1. SQL Injection

This is still found in a lot of web applications. Possible exploit scenarios include theft of sensitive information or compromise of the web application. SQL injection is the clear winner of the web application flaw contest.

2. Weak passwords

Inadequate password policies are a very common issue. They usually lead to compromise of legitimate user accounts or administrative accounts, sometimes allowing to compromise a web application.

3. Autorisation problems

A common issue, especially in the more complex "Enterprise" applications. Usually slightly more difficult to exploit than weak passwords with similar impact.

4. Award for most critical flaw: Command or code injection

Command / code injection is the most critical vulnerability. It almost always allows an attacker to compromise the server. Unchecked file uploads are a close second.

5. Award for most common flaw: Information Disclosure

Almost all web applications have some information disclosure issues. Cross site scripting is also very common, with around 70% of web applications having one or several cross site scripting flaws.

The chart allows for a few other observations. Firstly, cross-site scripting issues, while easy to find and very common, are usually not very serious.  The reason is that XSS attacks scenarios are often very contrived and require a lot of user interaction. The exception is stored XSS, which sometimes allows for quite effective attacks. Personally I think that cross site scripting is overhyped. The same goes for CSRF - an attack vector that works practically everywhere, but is nearly impossible to exploit in any realistic way (for this reason I didn't include "failure to protect against CSRF" in the analysis - if you want, you can imagine it as another data point on the lower right corner).

It is also interesting to note that typical PHP application security issues, such as local and remote file inclusion, don't occur all that frequently. This has several reasons: For once, companies don't use PHP that much to build more complex applications. They also don't use "PHP picture gallery 0.1" or similar products that are the source of 90% of web application security advisories. Secondly, it has become very common to activate PHP security features that thwart at least some attacks. And maybe there is also growing awareness about PHP security threats.

We can also see that password-policy-related issues and logic problems (e.g. autorisation) are just as prevalent and critical as injection-type flaws. This is not really news to security experts, but companies have to account for these kinds of flaws to achieve comprehensive security for their web applications.

Monday, June 18, 2012

Welcome to the SEC Consult InfoSec Blog!

Over the last ten years, SEC Consult has assembled quite a large team of 40 dedicated hackers and ISMS experts. Besides our regular work most of us spend our weekends and holidays doing security research. Traditionally however, most of the results stay behind closed vault doors on SEC Consult's high security server - only a small percentage finds its way to the Internet in the form of security advisories and papers.

In this blog we will finally open up to the world a bit. We will blog on some of our current research and give our expert opinion on current infosec topics. Stay tuned for more to come in the following weeks!