A large managed DNS provider was taken down by a DDoS, we’ll tell you all about Dyn’s big outage.

Then we beat the dead dirty CoW, answer your questions, a breaking news round up & more!

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Patreon

Show Notes:

DYN, a large managed DNS provider was taken down by a DDoS

  • “Criminals on Friday morning massively attacked Dyn, a company that provides core Internet services for Twitter, Github, SoundCloud, Spotify, Reddit and a host of other sites, causing outages and slowness for many of Dyn’s customers.”
  • “In a statement, Dyn said that this morning, October 21, Dyn received a global distributed denial of service (DDoS) attack on its DNS infrastructure on the east coast starting at around 7:10 a.m. ET (11:10 UTC).”
  • “DNS traffic resolved from east coast name server locations are experiencing a service interruption during this time. Updates will be posted as information becomes available,” the company wrote.
  • “The attack on DYN comes just hours after DYN researcher Doug Madory presented a talk on DDoS attacks in Dallas, Texas at a meeting of the North American Network Operators Group (NANOG). Madory’s talk — available here on Youtube.com — delved deeper into research that he and I teamed up on to produce the data behind the story DDoS Mitigation Firm Has History of Hijacks.”
  • When I heard about the attack on Friday, I didn’t assume it actually had anything to do with Krebs…
  • Krebs: Hacked Cameras and DVRs powered massive Internet outage
  • Miria and Bashlight join forces to attack DYN
  • “According to researchers at security firm Flashpoint, today’s attack was launched at least in part by a Mirai-based botnet. Allison Nixon, director of research at Flashpoint said: At least one Mirai [control server] issued an attack command to hit Dyn. Some people are theorizing that there were multiple botnets involved here. What we can say is that we’ve seen a Mirai botnet participating in the attack.”
  • DYN’s official Blog statement about the attack
  • “It’s likely that at this point you’ve seen some of the many news accounts of the Distributed Denial of Service (DDoS) attack Dyn sustained against our Managed DNS infrastructure this past Friday, October 21. We’d like to take this opportunity to share additional details and context regarding the attack. At the time of this writing, we are carefully monitoring for any additional attacks. Please note that our investigation regarding root cause continues and will be the topic of future updates. It is worth noting that we are unlikely to share all details of the attack and our mitigation efforts to preserve future defenses.”
  • “At this point we know this was a sophisticated, highly distributed attack involving 10s of millions of IP addresses. We are conducting a thorough root cause and forensic analysis, and will report what we know in a responsible fashion. The nature and source of the attack is under investigation, but it was a sophisticated attack across multiple attack vectors and internet locations. We can confirm, with the help of analysis from Flashpoint and Akamai, that one source of the traffic for the attacks were devices infected by the Mirai botnet.”
  • DYN DDoS attack was the work of script kiddies, not politically motivated
  • Traditional Media is terrible at covering things like this:
  • Tens of Millions of IP Addresses Used to Take Down Twitter, Netflix in ‘Unprecedented’ Cyberattack
  • Twitter was not attacked, and they were not down. They just happened to use DYN for their DNS, so it wasn’t resolving for a lot of people
  • DNSMadeEasy.com

Are the days of booter services numbered?

  • A lot of discussion has been going on about BCP38 (ISPs blocking outbound traffic from IP addresses they do not own, to stop spoofing attacks), but as far as I am aware, not of these recent record setting DDoS attacks rely on spoofing or amplification, they are just pure volume attacks, using 100s of thousands of devices.
  • However, most of these booter services use reflection and amplification techniques, because taking out smaller websites and individual private game servers does not require the resources of an entire botnet. A single server can accomplish this with a small amount of amplification
  • “These Web-based DDoS-for-hire services don’t run on botnets: They generally employ a handful of powerful servers that are rented from some dodgy “bulletproof” hosting provider. The booter service accepts payment and attack instructions via a front end Web site that is hidden behind Cloudflare (a free DDoS protection service).”
  • “To find vulnerable systems that can be leveraged this way, booters employ large-scale Internet scanning services that constantly seek to refresh the list of systems that can be used for amplification and reflection attacks. They do this because, as research has shown (PDF), anywhere from 40-50 percent of the amplifiers vanish or are reassigned new Internet addresses after one week.”
  • “Enter researchers from Saarland University in Germany, as well as the Yokohama National University and National Institute of Information and Communications Technology — both in Japan. In a years-long project first detailed in 2015, the researchers looked for scanning that appeared to be kicked off by ne’er-do-wells running booter services.”
  • “To accomplish this, the research team built a kind of distributed “honeypot” system — which they dubbed “AmpPot” — designed to mimic services known to be vulnerable to amplification attacks, such as DNS and NTP floods.”
  • “To make them attractive to attackers, our honeypots send back legitimate responses,” the researchers wrote in a 2015 paper (PDF). “Attackers, in turn, will abuse these honeypots as amplifiers, which allows us to observe ongoing attacks, their victims, and the DDoS techniques. To prevent damage caused by our honeypots, we limit the response rate. This way, while attackers can still find these ratelimited honeypots, the honeypots stop replying in the face of attacks.”
  • “In that 2015 paper, the researchers said they deployed 21 globally-distributed AmpPot instances, which observed more than 1.5 million attacks between February and May 2015. Analyzing the attacks more closely, they found that more than 96% of the attacks stem from single sources, such as booter services.”
  • “To distinguish between scans performed by researchers and scans performed with malicious intent we relied on a simple assumption: That no attack would be based on the results of a scan performed by (ethical) researchers,” said Johannes Krupp, one of the main authors of the report. “In fact, thanks to our methodology, we do not have to make this distinction upfront, but we can rather look at the results and say: ‘We found attacks linked to this scanner, therefore this scanner must have been malicious.’ If a scan was truly performed by benign parties, we will not find attacks linked to it.”
  • “What’s new in the paper being released today by students at Saarland University’s Center for IT-Security, Privacy and Accountability (CISPA) is the method by which the researchers were able to link these mass-scans to the very amplification attacks that follow soon after.”
  • “The researchers worked out a way to encode a secret identifier into the set of AmpPot honeypots that any subsequent attack will use, which varies per scan source. They then tested to see if the scan infrastructure was also used to actually launch (and not just to prepare) the attacks.”
  • Using hop count, trilateration, and BGP path searching, the research team was able to link scanners to attack origins
  • “These methods revealed some 286 scanners that are used by booter services in preparation for launching amplification attacks. Further, they discovered that roughly 75 percent of those scanners are located in the United States.”
  • “Even if these newly-described discovery methods were broadly deployed today, it’s unlikely that booter services would be going away anytime soon. But this research certainly holds the promise that booter service owners will be able to hide the true location of their operations less successfully going forward. and that perhaps more of them will be held accountable for their crimes.”

DirtyCow: Most serious Linux privilege escalation bug ever — actively being exploited

  • “A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.”
  • “While CVE-2016-5195, as the bug is cataloged, amounts to a mere privilege-escalation vulnerability rather than a more serious code-execution vulnerability, there are several reasons many researchers are taking it extremely seriously. For one thing, it’s not hard to develop exploits that work reliably. For another, the flaw is located in a section of the Linux kernel that’s a part of virtually every distribution of the open-source OS released for almost a decade. What’s more, researchers have discovered attack code that indicates the vulnerability is being actively and maliciously exploited in the wild.”
  • “The vulnerability is easiest exploited with local access to a system such as shell accounts. Less trivially, any web server/application vulnerability which allows the attacker to upload a file to the impacted system and execute it also works.”
  • What makes the Dirty COW bug unique? “In fact, all the boring normal bugs are way more important, just because there’s a lot more of them. I don’t think some spectacular security hole should be glorified or cared about as being any more “special” than a random spectacular crash due to bad locking.”
  • Anyone sharing or have details about the “in the wild exploit”? “An exploit using this technique has been found in the wild from an HTTP packet capture according to Phil Oester.”
  • What can be done to prevent this from happening in future? “The security community, we included, must learn to find these inevitable human mistakes sooner. Please support the development effort of software you trust your privacy to. Donate money to the FreeBSD project.”
  • Official site for the vulnerability: dirtycow.ninja
  • “At the time of public disclosure, the in the wild exploit that we were aware of did not work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.
    Since public disclosure several Proof of Concepts (POC) have been published, that use ptrace method, which do work on Red Hat Enterprise Linux 5 & 6.”

Feedback:

Round Up

Question? Comments? Contact us here!