An American with the aid of two Russian conspirators stole 130 million credit card numbers in 2007. In 2009, 32 million usernames and passwords were obtained from a social network game developer. More recently, Lizamoon gained quite a bit of media attention. The same technique that made these attacks successful has even been attempted by printing messages on a car bumper driving down a highway. These attacks all employed a technique called SQL injection. By sending carefully crafted SQL commands into a HTTP web form (or some other database interface), the attacker is hoping that the HTTP form parser isn’t watching for raw SQL commands in the input. The intended effect is that the database will either send back more information than the administrator intended, or drop tables with data altogether.
Defending Against SQL Injection Attacks Using Cisco ASA, IPS, and IOS Firewall – Cisco TAC Security Podcast
Updated May 9th: After a thorough investigation of the TCP Split Handshake issue raised by NSS Labs, Cisco has confirmed that the Cisco ASA firewall is not susceptible to this issue. In all test cases examined, the ASA operates as expected, providing protection in its default configuration against the Split-Handshake as defined in the original TCP Split Handshake paper. As a result, the Cisco PSIRT closed this investigation on May 4th.
Cisco appreciates the extended engagement and data provided by NSS Labs as we’ve worked through these scenarios. During two recent visits to NSS Labs, Cisco was presented with a number of scenarios, including new test cases that deviated from the original Split-Handshake scenario. The Cisco PSIRT collected traces and provided feedback to NSS Labs on all scenarios. In each case, Cisco demonstrated successful network protection through the default ASA configuration or the implementation of firewall policies that are fully supported, documented and used pervasively in enterprise deployments.
As always vulnerability reports should continue to be reported to the PSIRT organization (firstname.lastname@example.org). Cisco customers are encouraged to contact their account manager with any questions.
Recently there’s been some activity in the press regarding an NSS Labs report on potential vulnerabilities in Next-Generation Firewalls (NGFW). The Cisco Adaptive Security Appliance (ASA) was one of the products mentioned as vulnerable to these attacks. Based on the investigation of this issue to date, the data indicates that Cisco customers are not exposed to this issue. As always, should the vulnerability be confirmed the Cisco Product Security Incident Response Team (PSIRT) will investigate, drive remediation and disclose per our normal communication channels. (PSIRT Vulnerability Policy)
On April 12th, NSS Labs published a report regarding vulnerabilities on a number of firewalls, including Cisco’s ASA product line. The full report has a hefty $3500 price tag, but NSS does provide a free (with registration) “Remediation Guide,” for users of these firewalls.
The NSS Labs Remediation Guide incorrectly lists the Cisco ASA as vulnerable to the TCP Split Handshake attack, and also mentions that there are no steps available to customers to mitigate or remediate this attack.
Following an investigation over the course of several months, involving well over a dozen Cisco engineers from various teams and working in conjunction with NSS Labs, no vulnerability of this nature has been observed on Cisco products. The following products have been investigated:
- Cisco ASA
- Cisco IOS Firewall
- Cisco Intrusion Protection (IPS) Appliances
It’s important to note that the NSS Labs report focuses only on one attack called the TCP Split Handshake, which is a third means to initiate TCP sessions that combines features of both the three-way handshake and the simultaneous-open connection.
However, the goal of this post isn’t to discuss the technical details of TCP handshakes, but rather to present what Cisco has done and is doing to investigate the impact to our products and protect our customers.
As a Silicon Valley technology industry worker, I often try to reconcile the humanitarian, environmental, or political aspects of global issues with business realities. I may wish it made business sense for companies to focus on alleviating poverty or improving health care and education, but—even with the best intentions—by definition, for-profit companies are not charities. As it is, big multinational companies spend millions on corporate social responsibility efforts.
Thankfully, the business argument for sustainability is fairly easy to make. At least until emerging market growth slows appreciably and manufacturers find alternative materials to use, the price of elements in our high tech gadgets, and the security risks of not finding alternatives, are both headed up.
While the IT industry is in many ways moving toward an outsourced model, with the widespread adoption of the cloud and XaaS, marketing has been moving in a similar direction as well. And while PR agencies have been around for quite some time and it has been normal to look to outside agencies for help with creatives, over the past several years a new kind of service provider, the Email Service Provider, or ESP, has emerged from the shadows. Not to be mistaken for cloud-based email security services, ESPs are in the business of sending mass email (typically opt-in), not blocking it. Unfortunately, for many, their first exposure to these companies (outside of an inbox full of enticing offers) has been via news around data breaches, first, in 2010 with Silverpop and now Epsilon.
In the previous installment of our series of IPv6 security posts, we covered some of the ways addressing has changed in IPv6 compared to IPv4. In this post, we’ll talk about some of the things to consider when securing IPv6 compared to IPv4. Before digging into this topic, however, it is important to remember that while IPv6 may have different security concerns than IPv4, it is not necessarily any more secure than IPv4. Furthermore, the post will focus on those aspects that are different or unique to IPv6, since many of the common best practices for IPv4 networks also apply to IPv6 networks.