How to Prepare Your Enterprise for the Recently Disclosed TCP Denial of Service Vulnerability
The TCP Denial of Service vulnerability that was recently partially disclosed by Outpost24 has left many InfoSec managers wondering whether any action is required to protect their enterprise. While there are no patches available, and no workarounds have been discovered, now is the time to begin preparations for actions that may need to be taken at a later time.
In general, InfoSec organizations should be doing much of the planning that should have been done previously. Now is the time to review patch management policies, discuss staffing issues with operations teams, and make sure that disaster recovery and business continuity plans are ready to deal with any crisis that may (or may not) happen in the future.
The Denial of Service Issue Explained
Robert E. Lee and Jack Louis of Outpost24, a Swedish security firm, recently disclosed fundamental problems with the TCP protocol that could lead to a Denial of Service. They’re currently working with many different vendors to create patches and/or workaround solutions, but none are currently available. As a result, the issue has only been partially disclosed, and the seriousness of the issue hasn’t even begun to be evaluated yet.
Denial of Service issues with Internet protocols are nothing new, and quite a few have been discovered over the years. The difference with the Outpost24 discovery is the few resources that are required by the attacking host to successfully accomplish a Denial of Service. According to Robert E. Lee, “from under forty packets per second, we could probably take off most TCP services that we interact with.” He goes on to note that there are several different attack scenarios, several of which will result in the attacked host being taken offline until it is rebooted.
The important part of the discovery is that all hosts that have been tested by Outpost24 have been found vulnerable, including Windows, Linux, and BSD servers, as well as routers, firewalls, and other network components.
The best source for information about the issue is the two podcasts that Robert E. Lee has recently done. CurbRisk has created and posted transcripts of the original podcast with a Dutch blog, as well as a followup with SC Magazine.
What this Means to Enterprise IT
Patching is certainly nothing new to enterprises. Any enterprise that uses computers has had to deal with Microsoft’s “Patch Tuesdays”, and other patches being released for other operating systems. The DNS vulnerability announced by Dan Kaminsky earlier this year was somewhat unusual, as it affected all DNS servers on multiple operating systems. This issue is very unique, as it affects all network-connected devices running any service on any operating system. IT organizations have never faced the challenge of patching all servers and networking devices simultaneously. As a result, it’s unlikely that many enterprises have plans in place to accomplish such a significant, previously unheard-of scenario.
Steps IT Organizations Should be Taking Now
Although the impact of this issue has yet to be fully understood, and it’s unknown whether vendors will be providing patches, it’s important to be prepared for anything that might happen as a result of this vulnerability.
Asset Prioritization
Update your list of assets, and ensure that you have full awareness of any critical part of the infrastructure. Be sure to include critical servers, routers, firewalls, IDS and IPS sensors, and any other part of the infrastructure that is important to the organization.
Create a Patching Plan
Work with your operations team to create a plan to quickly patch all of the critical assets in your organization. Identifying each asset in the order of its importance will make it easier to get the patches out to the most important systems first. In most cases, your network devices will be the most critical items. Also consider whether it’s appropriate to start patching your Internet-facing assets first, if your organization relies heavily on email or websites to communicate with clients.
Check your Business Continuity Plans
Make sure they account for the possibility of a sustained outage of the entire corporate network, or even an outage of the Internet. While it’s unlikely this vulnerability will take down the entire Internet, it’s a possibility that should be considered, and planned for. Even if this issue isn’t the “internet killer” that some have hyped it to be, there’s always the possibility of another vulnerability down the road with that devastating effect.
Verify Redundancy
If your organization does not have multiple carriers for Internet access, now might be the time to add some redundancy to your connectivity. Multi-homed Internet access is a best practice for any organization that relies upon its Internet connectivity for business. If someone manages to use this vulnerability to take down the routers at your primary carrier, you’ll want to have another for backup purposes.
Consider Using a Content Delivery Network
Content Delivery Networks like Akamai have the ability to cache your website content in many locations throughout the world. If your business relies on its websites to be available, a CDN might prove to be a valuable option to keep your sites available during a potential attack. It would be best to protect your source server, as the CDN will need to contact it to build and update its cache.
Plan to get Operations Staff to Colocation Facilities
If you rely on “remote hands” staff at a colocation facility, understand that they’re likely to be completely overwhelmed by the volume of requests if a massive, critical multi-vendor patch is released. At some facilities, they’re likely to be tied up managing the patches for the facility itself, and may not have time to work on client equipment. If your colocation facility isn’t in close proximity to your operations staff, start planning how you’ll get them onsite to handle patches.
Start Communicating Within IT
Begin the process of speaking to IT executives, to let them know that you’re on top of the situation. If and when this story starts making the rounds of the mainstream media, it’s always best to be sure that executives know that you’re already aware of the potential for an issue, and planning is in process.
It’s also time to start alerting the operations teams that something big may be coming, so they can consider staffing needs, and begin their own planning.
Communicate to your Users
Your users don’t need to know the specifics of this issue, or even that there is a potential issue. However, as part of your regular security awareness communications to users, stress the need for them to be very aware of anything they download from the Internet. If this vulnerability starts making its way into botnet or malware code, you want to ensure that your users aren’t likely to take down your network with that great game they found while browsing the web.
Don’t Panic
There’s much to be learned about this vulnerability as time progresses. It’s very possible that this is an urgent, serious issue that may have a tremendous impact on enterprises. It’s also possible that there’s an easy workaround, or the issue isn’t as serious as it seems. Start planning now, so that you don’t need to panic later.
Robert E. Lee Discusses TCP Denial of Service Vulnerability with SC Magazine
In the October 6th edition of the SC Magazine Podcast, Robert E. Lee of Outpost24 discusses the TCP Denial of Service vulnerability that was partially disclosed last week. I previously posted a transcript of an earlier podcast discussing the TCP Denial of Service vulnerability, and was asked to make a transcript of this more recent discussion available.
The full text of the SC Magazine interview follows.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dan Kaplan: Hello everyone, and welcome to the SC Magazine podcast for the week of October 6th. I am your host Dan Kaplan, Senior Reporter at SC Magazine. And today we are pleased to be joined by Robert E. Lee, who is the Chief Security Officer of Outpost24, and that’s a security firm based in Sweden. And Robert and another researcher there have made a potentially very big vulnerability discovery that could affect any device that accepts TCP connections.
So, something potentially pretty devastating there, and Robert, we are pleased for you to join us. So, thanks for being with us.
Outpost24 TCP Denial of Service Vulnerability Interview Transcript
The following text is the complete transcript of an interview of Robert Lee and Jack Louis from Outpost24. Robert and Jack discuss their discovery of a flaw in TCP that results in a denial of service with Brenno de Winter of De Beveiligingsupdate. The article (in Dutch) can be found here, and the full MP3 audio is at this link (note that the beginning of the podcast is in Dutch. Forward about 5 minutes to get to the English portion, including the interview with Robert and Jack.
I heard from Robert E. Lee via email earlier today, and he has indicated that he’d like to make some corrections to the comments that are shown below. I’ll be speaking with him soon, and will update this page with his comments. I’m in the process of transcribing another podcast which will be posted soon, and will also have an article here on CurbRisk with some suggestions for what enterprises should (and should not) be doing in response to the news reports of these vulnerabilities. Be sure to subscribe to the RSS feed, or subscribe via email to stay up to date. Links to both are on the top right side of this page.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Interviewer: Robert Lee and Jack Louis, you’re both of Outpost24. And using basically, your Unicorn scanner you did some amazing discovery. First off, what is Unicorn and what are we talking about?
Outpost24: Okay, well Unicornscan was a, an attempt to make a userland TCP stack. We were originally using it to collect information from large networks that we were being paid to do penetration testing against. I’ll let Jack briefly explain how that works. I, I guess we were doing the tests and we just couldn’t get the port scanning done in time. And so we decided to move the TCP stack into the program, so we could make it distributed. And one of the problems you run into when you make a distributed stack is that the state of the stack has to be, I guess you could say it has to be contained in some sort of way, to where each machine doesn’t have to track all the TCP connections. Which is why we kinda had to take a strange approach by using the reverse SYN cookies or whatever you want so we could do the three-way handshake part without necessarily tracking the connection each step of the way. And so that’s basically why or how we started noticing some funny things while scanning various networks. One other thing, too, that was important was Unicornscan was a really fast port scanner too. Which, of course, it would lead you to sometimes accidentally hit, like, network windows where the connectivity was bad, and so you would experience packet loss. And we didn’t really have much code for determining if packet loss was happening. And, so we, in the beginning at least, we would hit periods where we would just experience packet loss.
Interviewer: Wait, so packet loss basically then you mean that the system runs into problems?
LPL Financial Customers Speak Out on BranchNet Hack
After the SEC recently censured LPL Financial for not protecting their BranchNet trading system from unauthorized access, I wondered how LPL’s customers felt about the company and the safety of their personal information. I recently had the opportunity to speak to a few of their customers and financial advisers.
Julie Murphy Casserly, a Certified Financial Planner and author of "The Emotion Behind Money" started doing business with LPL last year when her broker-dealer, Associated Securities, was acquired by LPL. She’s concerned that the SEC went too far in censuring LPL, noting, "we need to help people in the public and protect them, not just protect them. If regulation gets so tight and I’m not able to do my job which my clients have asked me to do, then what are we all doing in this industry? Truly, this raises a concern that regulators will not take into account what the consumer is asking from us as advisors." She’s pleased with LPL’s technology, noting, "LPL is one of the last broker-dealers that has the technology sophistication for me to do my job easily and allow me to properly service my clients."
Others felt that the SEC didn’t go far enough in reprimanding LPL. Aaron Gordon, vice president of Schwartz Media Strategies, a Miami, Florida public relations and marketing firm, is a customer of LPL Financial. "I think the censure was appropriate. However, the fine seems low to me. Considering how much money was at risk, $275K seems arbitrary, if not too low. Perhaps another approach would have been to fine LPL a percentage of the assets exposed to risk by their negligence."
Aaron told me that he has been a victim of debit card theft in the past, and that experience increased his concerns about the security of his personal information. "Within 24-hours, $7,000 had been debited from my checking account. Thankfully, Bank of America refunded my money, but it was a hassle. Since then, it’s always on my mind when I swipe my card or make online transactions. The safety of my information is of utmost importance. I think data security should be a given in this day and age." He also feels that financial services companies should be held to a higher standard: "If they’re going to take on the risks associated with keeping highly-sensitive information, then it’s their obligation to protect that information."
Despite his concerns, Aaron is keeping his money with the independent financial adviser that uses LPL for his investments. "For me, it’s about my relationship with my adviser. I trust that the government will take care of the problem and that LPL will ensure it doesn’t happen again."
Tina Trombley, an IT Resource Project Manager from Ohio, is also keeping her money with LPL. She told me that she became aware of the SEC’s censure and fine of LPL Financial when news of the current global financial crisis caused her to do some research in Google regarding LPL’s financial stability. The hack of LPL’s BranchNet system hasn’t caused her to change her relationship with LPL, at least not yet. As she puts it, "I am not removing my money from my accounts with LPL, but I am watching them very closely and exploring other investment options for my long-term retirement investment accounts." She also noted that she’s not worried about her data being exposed in a security breach. "I am not overly concerned about my personal information and account as I do periodic credit checks to be sure my identity is safe."
Is it Sometimes Better to be Unaware of Your Vulnerabilities?
As I was writing about the hack of LPL Financial’s BranchNet system last week, I couldn’t help but wonder if the Securities and Exchange Commission would have been less harsh on LPL if the company hadn’t known about the vulnerabilities in its system.
In short, LPL Financial performed a security audit on one of its Internet-facing trading systems. The auditor’s report included details of a number of significant shortcomings in the system. BranchNet had no requirements for password length or complexity, and the plain-text passwords of all of the system’s users could be viewed by approximately 300 people in the IT department. A year after LPL was aware of the vulnerabilities, they hadn’t taken any action to correct them, and the system was inappropriately accessed to make unauthorized trades in customer accounts. In the SEC’s action against LPL, they called the company in “reckless disregard” of regulatory requirements for the protection of customer data.
I spent some time reviewing the SEC’s press releases for the past 18 months, and found no other actions taken against any company as a result of an information security problem. The vast majority of censures and fines are related to fraud.
So, would it be better to be blissfully unaware of your security issues, or be fully aware, and just refuse to act? Most laws in the US are written so that active or constructive knowledge (or “knew or reasonably should have known”) can be used to make a legal case against someone. In other words, you can’t claim innocence if you should have been aware there was a problem. However, in the minds of the people in a regulatory agency or on a jury, is it worse if someone knows and does nothing, or if they could have known but didn’t? It is, after all, people who decide the punishment based on the facts of the case.
I don’t mean to suggest that ignoring the need to perform a security audit is an acceptable substitute for fixing vulnerabilities. Nor do I mean to suggest that LPL would have been better off without a security audit. However, if a company knows there’s a vulnerability, the company must act to correct it, or it risks significant liability if and when the vulnerability is exploited. The reverse of that statement may also be true in some (albeit very few) cases. If you know that nothing will be done to fix the vulnerabilities in a system, you might be better off not knowing about them.