Adopting third-party libraries to encode user input in the development phase and using a web application firewall in the deployment phase could fool web security managers into thinking their web applications are completely safe from Cross-Site Scripting (XSS) attacks. While it’s a good idea to employ these techniques, the illusion of safety could prove costly. These protection methods do not guarantee that your web applications are 100% free of XSS vulnerabilities, and XSS attacks that use more sophisticated techniques still occur, so care should still be taken.
With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.
About 95 percent of HTTPS servers are vulnerable to connection hijacking, opening the door for hackers to launch man-in-the-middle and other devastating cyber attacks. That’s according to a Netcraft study released about a week ago. The reason for this concerning situation? Only 5 percent of HTTPS servers have a correct implementation of HTTP Strict Transport Security.
Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.
On March 1st the DROWN vulnerability in openssl was disclosed. Exploited successfully by an attacker it can lead to decryption of SSL/TLS sessions.
On March 2nd our internal scanning indicated that we had 3 servers that were susceptible to DROWN. These 3 servers were part of a partner facing version of an application that was in the process of being decommissioned. No DNS names were connected to the servers anymore, but the IP addresses were still accessible.
On March 3rd we received a number of queries regarding the configuration of these servers and their susceptibility to DROWN. After verifying with the partner affected to assure that there was no more use of the servers, we turned off access to the respective services.
The certificate that was served on these machines is being reemitted with a new private key.
A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.
This week Microsoft released a patch for a critical Silverlight issue, MS16-006, and since I worked on Silverlight signatures in the past it caught my eye. It’s a Remote Code Execution vulnerability which allows attackers to run code of his or her choice on the victim machine. I had a hunch that something more was hiding. I started to analyze it as soon as I finished writing signatures for the existing patch. When I was working on the analysis Kaspersky Lab published a great blog post about the story of this vulnerability.
In this blog, I’m presenting analysis of a different function that was also fixed in the same patch.
Open redirection is listed in the OWASP Top 10 for 2013 and 2010 (10th position in both lists) since it is still an active threat in modern web applications. Open redirection occurs when a vulnerable web page is redirected to an untrusted and malicious page that may compromise the user. Open redirection attacks usually come with a phishing attack because the modified vulnerable link is identical to the original site, which increases the likelihood of success for the phishing attack.
While open redirection is not exactly common, my research was able to uncover several open source applications that were vulnerable. In this article, I describe the results of my research, and some recommendations for avoiding open redirection vulnerabilities in your code.
A number of security researchers recently discovered that Dell laptops come pre-installed with an additional root certificate call eDellRoot. Since the private key is also available on the machine this exposes their customers to the risk of a Man-in-the-Middle (MITM) attack. In a MITM attack, the attacker sits on the network between server and client and uses the eDellRoot certificate to intercept and manipulate HTTPS connections. This vulnerability leaves anyone using these Dell laptops at risk for sensitive data exposure and even infections with malicious payload, all under the cover of a trusted connection.
A few days ago, SpiderLabs researcher Osaf Orpani disclosed an important vulnerability targeting Joomla, one of the most popular Content Management Systems (CMS). By exploiting this vulnerability, researchers were able to remotely gain full administrative access to the CMS.
Joomla versions 3.2 to 3.4.4 are affected by this major security issue. Since the vulnerability targets the core of the CMS, all websites based on Joomla are vulnerable, whatever the modules used.