One of the single most annoying things about CSRF and router hacking etc… is that you get the annoying popups on Basic and Digest authentication pages, asking you to log in. More and more devices are moving away from these popup style alerts and moving more towards form based authentication, which is better from a hacking perspective. But still, I would say the vast majority of firewall/switch/router devices out there use Basic or Digest based authentication. The problem with that from an attacker’s perspective is that it creates a noisy popup if it fails (if the user isn’t authenticated) that the user is bound to notice and question. Well, now we have an answer - at least in Internet Explorer:

<DIV STYLE="background-image: url(http://router/path.to.hack)">blah</DIV>

I know there are others tags that work, but probably not as well as this method from what I’ve seen so far. I haven’t found a reliable way in other browsers to allow this to happen, but I’ve only barely scratched the surface of the vast number of CSRFable tags out there. But anyway, yes, this doesn’t cause the Basic or Digest auth dialog to fire so it will be more stealthy upon performing a CSRF that fails. Of course for POST based CSRF you’re still out of luck…

It’s been a while since I’ve talked about Clickjacking, with only a few exceptions here and there. Mostly because I haven’t seen it much in the wild - at least not yet. But there’s still a lot of research out there to be done. I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:

The technique, found by Lava Kuppan describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET. It’s worth a read. I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York. But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process. Anyway, cool stuff by Lava.

It’s been a while since I’ve talked about Clickjacking, with only a few exceptions here and there. Mostly because I haven’t seen it much in the wild - at least not yet. But there’s still a lot of research out there to be done. I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:

The technique, found by Lava Kuppan describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET. It’s worth a read. I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York. But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process. Anyway, cool stuff by Lava.

by Christian Moldes

In Outliers, Malcom Gladwell analyses how plane crashes are the result of a combination of errors. I found this analysis very interesting because of the similarity with most security breaches. A brief excerpt of his book:

“Plane crashes rarely happen in real life the same way they happen in the movies. Some engine part does not explode in a fiery bang. The rudder doesn’t suddenly snap under the force of takeoff. The captain doesn’t gasp, “Dear God,” as he’s thrown back against his seat. The typical commercial jetliner – at this point in its stage of development – is about as dependable as a toaster. Plane crashes are much more likely to be the result of an accumulation of minor difficulties and seemingly trivial malfunctions.

The typical accident involves seven consecutive human errors. One of the pilots does something wrong that by itself is not a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to catastrophe. But then they make a third error on top of that, and then another and another and another and another, and it is the combination of all those errors that leads to disaster.”

Security breaches happen exactly like that. They are the result of a combination of minor or seemingly insignificant errors. Let me illustrate this. A few years ago, a merchant suffered a breach, and its case is one of the best examples for this topic. Their e-commerce website was developed in-house but some of the components had been developed by a third party. The application had been thoroughly reviewed for security vulnerabilities and none had been identified as risky. However, one of the components was not reviewed, it was added a few days after the application review had been completed, and since it was not related in any way with payment transactions, it was deemed as non-critical.

The merchant had a network IDS which was maintained and monitored by a MSS (managed security services) vendor. The device had signatures that were able to recognize SQL injection attempts and they were supposedly enabled. One of the vendor’s security analysts disabled rules monitoring attacks on port 80 and 443 for the e-commerce servers. This was probably because they generated many false-positive alerts, and was most likely intended as a temporary action. As a result, none of the attacks and unusual traffic on those ports was detected by the IDS.

The e-commerce site was using a trusted relationship to connect to the database. Credit card numbers had been encrypted in the database a few months ago. During the process as a contingency plan, the DBA exported the tables containing sensitive data before encrypting some of the columns. The backup files had been left on the database server since then.

Hackers found the security vulnerability in the e-commerce website; the third-party component was vulnerable to SQL injection. By exploiting the vulnerability, they were able to create local administrator accounts on the database server and run OS commands with local administrator privileges. Unfortunately, since the IDS was not monitoring traffic on ports 90 and 443, none of the SQL probes was detected by the IDS, nor was any other unusual traffic on those ports. Remote management tools were installed and password hashes were cracked off-line. The hackers reviewed every folder on the web server looking for scripts, source code, and data files. They found the backup files left behind by the DBA.

The merchant was only aware of the intrusion several months after the fact, when they were notified by law enforcement agents that their data was on sale on one of the carders websites.

This case clearly illustrates that even when proper security controls are in place, a breach could happen at any moment. Relying on single controls or single layers of security is never sufficient.

The case also illustrates the need to assess security controls independently of any other surrounding security or other layers of security. QSAs and internal staff in charge of PCI DSS compliance should not consider risk-based discussions until all the security controls have been independently assessed.

by Christian Moldes

In Outliers, Malcom Gladwell analyses how plane crashes are the result of a combination of errors. I found this analysis very interesting because of the similarity with most security breaches. A brief excerpt of his book:

“Plane crashes rarely happen in real life the same way they happen in the movies. Some engine part does not explode in a fiery bang. The rudder doesn’t suddenly snap under the force of takeoff. The captain doesn’t gasp, “Dear God,” as he’s thrown back against his seat. The typical commercial jetliner – at this point in its stage of development – is about as dependable as a toaster. Plane crashes are much more likely to be the result of an accumulation of minor difficulties and seemingly trivial malfunctions.

The typical accident involves seven consecutive human errors. One of the pilots does something wrong that by itself is not a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to catastrophe. But then they make a third error on top of that, and then another and another and another and another, and it is the combination of all those errors that leads to disaster.”

Security breaches happen exactly like that. They are the result of a combination of minor or seemingly insignificant errors. Let me illustrate this. A few years ago, a merchant suffered a breach, and its case is one of the best examples for this topic. Their e-commerce website was developed in-house but some of the components had been developed by a third party. The application had been thoroughly reviewed for security vulnerabilities and none had been identified as risky. However, one of the components was not reviewed, it was added a few days after the application review had been completed, and since it was not related in any way with payment transactions, it was deemed as non-critical.

The merchant had a network IDS which was maintained and monitored by a MSS (managed security services) vendor. The device had signatures that were able to recognize SQL injection attempts and they were supposedly enabled. One of the vendor’s security analysts disabled rules monitoring attacks on port 80 and 443 for the e-commerce servers. This was probably because they generated many false-positive alerts, and was most likely intended as a temporary action. As a result, none of the attacks and unusual traffic on those ports was detected by the IDS.

The e-commerce site was using a trusted relationship to connect to the database. Credit card numbers had been encrypted in the database a few months ago. During the process as a contingency plan, the DBA exported the tables containing sensitive data before encrypting some of the columns. The backup files had been left on the database server since then.

Hackers found the security vulnerability in the e-commerce website; the third-party component was vulnerable to SQL injection. By exploiting the vulnerability, they were able to create local administrator accounts on the database server and run OS commands with local administrator privileges. Unfortunately, since the IDS was not monitoring traffic on ports 90 and 443, none of the SQL probes was detected by the IDS, nor was any other unusual traffic on those ports. Remote management tools were installed and password hashes were cracked off-line. The hackers reviewed every folder on the web server looking for scripts, source code, and data files. They found the backup files left behind by the DBA.

The merchant was only aware of the intrusion several months after the fact, when they were notified by law enforcement agents that their data was on sale on one of the carders websites.

This case clearly illustrates that even when proper security controls are in place, a breach could happen at any moment. Relying on single controls or single layers of security is never sufficient.

The case also illustrates the need to assess security controls independently of any other surrounding security or other layers of security. QSAs and internal staff in charge of PCI DSS compliance should not consider risk-based discussions until all the security controls have been independently assessed.