cURL/libcURL CVE-2016-8623 Information Disclosure Vulnerability
 
 
cURL/libcURL CVE-2016-8621 Information Disclosure Vulnerability
 
cURL/libcURL CVE-2016-8624 Remote Security Bypass Vulnerability
 
cURL CVE-2016-8620 Remote Security Bypass Vulnerability
 
cURL/libcURL CVE-2016-8622 Remote Security Bypass Vulnerability
 
cURL/libcURL CVE-2016-8617 Remote Security Bypass Vulnerability
 
cURL/libcURL CVE-2016-8618 Remote Security Bypass Vulnerability
 

5 years ago, I posted a story on the Eastern Seaboard power outage of 2003 (https://isc.sans.edu/forums/diary/8+Years+since+the+Eastern+Seaboard+Blackout+Has+it+Been+that+Long/11374/ ). In that story I mentioned that we cant seem to help but have a large power outage every 10 years or so - the conclusion being that we shouldnt take a multi-day widespread power outage off the table for DR / BCP (Disaster Recovery / Business Continuity Planning) - we never seem to get the infrastructure 100% right.

I think its time to take that conclusion and expand it - time to add a new threat to our DR plans.

Weve always had DOS and DDOS in our plans - folks tend to multi-home for that, or buy a DDOS service from their ISP. Newer approaches might include implementing Flowspec to help set PBR parameters upstream on suspected attack traffic (stay tuned on this BTW).

However, what were seeing now, with the Mirai related DDOS events, is that the target of the attack is the upstream providers - Dyn for instance. Or in the case of krebsonsecurity attack, that targetted attack affected the provider (akamai).
What were seeing now is that DDOS attacks are getting large enough to affect large providers and all of their clients- there are precious few providers who can sink a multi-GB attack without affecting their customers. In the case of the Dyn outage, folks who had an alternate DNS provider for their server records were able to flip to that provider and recover fairly quickly. We need to think of DDOS events as natural disasters like hurricanes, floods or ice storms.
I think what we need to start planning for is attacks that dont target us directly - most organizations will be just collateral damage in most DDOS attacks going forward. Maybe we can call it blast radius planning - where if were in the blast radius of an attack, plan on moving our organization to another provider, hopefuly outside of the spatter range?

Eventually though, as an industry were going to have to find ways to deal with this at the core. Flowspec has some potential here, where provider A could tell provider B that this particular set of indicators identifies an attacking flow. As implemented today though, flowspec tables fill up muc to quickly to operate between providers, or against Mirai sized attacks.

What we really need is a method of taking the costs out of cooperation. Right now, if ISPs were to put together formal ways of combatting attacks like this, its a direct impact on profit. Nobody is really incented to fix attacks like DOS or DDOS - the incentive is to either sell more bandwidth or sell a DDOS mitigation service. With ISP margins so slim these days, spending money with no direct return doenst get a lot of air play with Sr Management. Im not sure that pulling governments into this is helpful (in fact Im pretty sure itll hurt more than help), but

Maybe Im being fatalistic - what do you think? Please use our comment form if youve got a happier spin on this?

===============
Rob VandenBrink
Compugen

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
cURL/libcURL CVE-2016-8615 Cookie Injection Security Bypass Vulnerability
 
cURL/libcURL CVE-2016-8616 Remote Security Bypass Vulnerability
 
QEMU 'v9fs_link()' Function Denial of Service Vulnerability
 
QEMU 'hw/9pfs/9p.c' Integer Overflow Vulnerability
 
QEMU 'hw/9pfs/9p.c' Information Disclosure Vulnerability
 
Internet Storm Center Infocon Status