The internet has become an integral part of our life. We use it for various functions, such as online banking, social media, retail purchases and online gambling. When browsing through various web sites, a lot of personal and financial information is being transmitted and stored across a number of systems. It’s no wonder that security has become a top priority when developing web applications.
Five years ago we noticed a trend among our customers. The same high-risk vulnerabilities appeared in consecutive penetration tests. While the underlying reasons for this varied from a lack of technical resources to the inability to make changes to proprietary software, the end result was the same. Attackers were exploiting flaws in web applications leading to both financial and reputational loss.
Well, to put it simply, with the right type of request, certain implementations of the widely used OpenSSL suite were leaking sensitive data stored in memory. The vulnerable version of OpenSSL was found to be OpenSSL version 1.0.1 up to and including 1.0.1f, and 1.0.2-beta1.
On the 8th April 2014, a security advisory was released stating that a missing bounds check within openssl could be used to reveal up to 64bits of data stored in memory.
Recently the Pure Hacking technical team completed a regular skills update session on iPhone application security with a company that is a world leader in identifying mobile application vulnerabilities. Most mobile application vulnerabilities occur when developers either insecurely store sensitive information in the application or use client side controls to enforce server security. With 1,000,000 apps in the app store today this has serious repercussions for naive consumers.
I am happy to announce the ModSecurity SVM Bypass Charity Challenge. This is a SQL Injection, XSS and Path Traversal Filter Evasion Challenge. Similar to the Trustwave ModSecurity SQLi Challenge, I setup ModSecurity to proxy to the following four commercial vulnerability scanner demo sites:
Often when implementing customised ModSecurity solutions we need to extend the built-in functionality via Lua scripting. One of the disadvantages to this approach is the added latency penalty paid for not using the native rules language. When web site performance is critical for business continuity, every additional millesecond counts. The current trunk code fixes a long-standing limitation where ModSecurity needed to create a new VM for each request, which added latency every time a Lua script was executed.