4. What is the OWASP Top 10?
Injection Cross Site Scripting
Broken Authentication & Session
Insecure Direct Object Reference
Management
Cross Site Request Forgery Security Misconfiguration
Insecure Cryptographic Storage Failure to Restrict URL Access
Insufficient Transport Layer Unvalidated Redirects and
Protection Forwards
Hi, we ’re Dave and Christian. Last couple of years we ’ ve spoken at Tech Day on breaking web applications. This year, taking a different approach: how to defend web applications from attack.
Today we ’re going to tell you a story .. and this story is broken into a few scenes .. in fact .. it’s more like a movie then a story .. anyway. For each of the scenes will highlight the impacts of a particular attack, and then relate that back to an identified OWASP Top 10 Risk .. then we ’ll discuss the controls implemented, and some not implemented. Before we begin though, we thought it worthwhile to have a quick refresher of the OWASP Top 10 for 2010
The goal of the Top 10 project is to raise awareness about application security by identifying some of the most critical risks facing organizations. Each of the Top 10, as classified by OWASP, consider the attack vector, the prevalence of the weakness, how easy it is to detect the weakness, technical impact and business impact. We don ’ t have time to cover all of the 10, but we ’ ll be referring back to these periodically throughout our scenarios.
Lets tell you a story of Steve. Steve runs a medium sized business selling widgets to the happy customers of Perth, and over the past few years he's been aggressively expanding his business. What first started off as word-of-mouth marketing shifted to print marketing and after returning from a business conference over east realises that he's not tapping into that market at all, I mean, he has a static website that mainly links to their email address, but they're not actively promoting or selling online. So after talking with a few other people in similar positions he decides he ’s going to do it.. He’s going to set up a blog.. Sound pretty familiar? How many people out there have a blog? What about, how many of you have read a blog? Whilst our examples are heavily related to blogging engines, these impacts and controls are equally applicable to micro sites, commercial off the shelf, 3rd party developed open source, sharepoint, owa, turnkey deployed apps. You don ’t always have the expertise or the ability to fix the code directly, so you may not be able to fix the underlying source code issues, but instead implementing other defensive mechanisms.
Demo: - demonstrate the site briefly. - Jump to attacker demonstrating Nikto .. - Jump back to the site .. ?? Or to an admin, who has no idea? - Explain that we ’ve now enabled OSSEC to monitor the Apache logs with email alerting and active-response. - Jump back to attacker, demonstrating Nikto, - Jump back to the admin and show the email/alert notification.
The impacts of scanning alone are a little difficult to quantify: Potential performance impact or DoS if the scanning is aggressive Scanning is often followed by other attacks If the attacker ’s scan finds vulnerabilities, they will often attempt to exploit.
The defensive strategy from this example scenario is quite simple - monitoring. Almost all systems , web-servers, applications have some form of default logging The important step is leveraging this logging (in near real time) to know when your system is under attack (or compromised!) Open source (OSSEC / SNORT) or commercial HIDS products can really help out here. In a worst case scenario, if your web application was compromised, being able to respond quickly to the compromise can limit the impact or damage caused by the compromise. It can help to limit the amount of sensitive information that is exposed Limit the potential reputational damage (eg. Defacement) The latest Verizon data breach investigations report found that 74% of their incidents took “weeks” to “months” between ‘compromise’ and ‘discovery’.. how much would that cost your organisation? Another feature of OSSEC that we didn ’t demonstrate, or enable, was “Active Response”. This feature enables particular actions based on alerts Eg. If you get a large number of “400” response codes from the same source IP address, it usually means that you are being scanned. Temporarily deny them access to your server with a local firewall rule. If this was enabled, the nikto scans would have all but crawled to a stop. An alternative approach to monitoring is through services like Sucuri Cloud-based / SaaS monitoring of public / published web content If content changes are detected, raise an alert Not as pro-active as HIDS (only really useful to detect compromises) but useful all the same.
Demo - the plugin, version. - back to the attacker, using the exploit, the ability to upload arbitrary content? - Back to the admin, patch the plugin - back to the attacker, trying the exploit again.
The impacts of a web application compromise can be many and varied: Loss of sensitive information (eg. Customer data) Potentially leading to customer ID theft and subsequent fraud Leading to customer dissatisfaction and loss of business Defacement Potential reputational damage Distribution of malware Again, potential reputational damage
How does this relate back to the OWASP Top 10? In this instance, the exploit was actively exploiting a “ Remote File Inclusion ” vulnerability Very prevalent a couple of years ago in older versions of PHP Was included in OWASP ’ s Top 10 of 2007. Current PHP disables the ability to ‘ include ’ remote content by default, and as a result RFI fell off the OWASP Top 10 of 2010. Application compromise could also arise from other vulnerabilities in the OWASP Top 10: Injection (SQL injection, command injection) Broken authentication Failure to restrict URL access and others…
There are a few defensive strategies that are relevant to this demonstation: Again, monitoring would have been useful. If we had HIDS in place, Stevie would have been alerted to the compromise Patching is the second strategy. Ideally this type of vulnerability could be addressed with code-changes. But you may not have access to the source, or the skills to fix the code -> therefore, patching is the best approach Important to patch comprehensively: OS, Web server, web application, any add-in components Penetration testing can also be really useful If you are pro-actively identifying vulnerabilities in your web applications, you can fix these issues before they are exploited by attackers
You can also see how the patch for this software removed the vulnerable statements. This was easy enough by looking for the offending ‘require’ statements.
Demo: - Show admin interface - Demonstrate attacker utilising Burp ’s intruder to brute-force password - Go back to admin - Enable the Google Authenticator 2FA plugin - Attacker tries again - Also mention/demonstrate/show them implementing .htaccess rules to limit access.
The impacts from this scenario would be very similar to the last Once the attacker has access to the administrative interface, they could do pretty much whatever they liked: Deface the site Upload their own content (eg. PHP shells) Extract sensitive information Add links to malware Create additional wordpress users
This example relates directly to OWASP ’ s “ Broken Authentication and Session Management ” risk. Whilst Wordpress ’ authentication method isn ’ t exactly “ broken ” , out of the box it is pretty weak: No SSL protection, so credentials are exposed to eavesdropping No account lockout No password complexity controls You can also see a selection of other good Authentication controls by reviewing the “ Authentication Verification Requirements ” in OWASPs Application Security Verification Standard (ASVS).
The defensive strategy that we demonstrated in this example was strengthening authentication. We implemented 2FA. This would render the brute force password attack useless Also, removes the risk of eavesdropping credentials, or credential theft through key-logging malware Could also strengthen auth by adding password complexity, account lockout, etc. Other strategies that are relevant to this scenario are: Protect administative interfaces Limit the source IP addresses that can connect Implement SSL protection on admin interfaces to avoid eavesdropping Avoid password re-use If you use the same password on your wordpress admin interface as you do for webmail, if your webmail password is compromised the attackers could use this to attack wordpress. There has been a lot of this happening recently (eg. HBGary).
The final defensive strategy that we wanted to talk about relates to DoS. It wasn ’t possible to put together a video for this, but we thought it was relevant to add into the mix. If DoS is one of your concerns for your web application, you should really consider leveraging a service like Cloudflare. Cloudflare essentially provide a reverse proxy service, wrapped up in DoS and DDoS protection controls. Instead of pointing your DNS record for your web application directly at your web server, you point it to cloudflare. Cloudflare receive HTTP requests from your site ’s visitors. They ensure that the requests are valid (ie. Not part of a DoS / DDoS attack) before forwarding the request onto your web server. Their service offerings start at free and there are commercial options above this. A testament to the quality of Cloudflare ’s service were this years’ Lulzsec / Anonymous operations. Lulzsec were compromising many high profile organisations ’ sites and publishing the compromised data on their website. They were obviously attracting a lot of attention from a number of fronts and many groups were attempting to take their website off the air – unsuccessfully. Lulzsec were using Cloudflare to protect their website. You ’ve got to think -> if Cloudflare is good enough for Lulzsec, it is probably good enough for my organisation
So, in summary, we have tried to present some pragmatic and low-cost controls that you can use to protect your Internet web applications. Although OWASP ’ s primary focus is on fixing web vulnerabilities through developer education and code remediation, all of the measures we presented can generally be implemented without touching a line of code. We certainly can ’ t guarantee that if you do all of these things, your site won ’ t be attacked or compromised… But the likelihood of a compromise is reduced… And the impact from a compromise should also be reduced. Thanks for your time. I hope that this presentation has provided you with some value. We ’ ve included some references on the next slide to the tools and services that we have referenced in the presentation. Hopefully this slide pack will be available for download after the event, if you are interested in further reading. We invite any questions…
