Attacks/Breaches

10/26/2016
06:00 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
100%
0%

DDos On Dyn Used Malicious TCP, UDP Traffic

Dyn confirms Mirai IoT botnet was 'primary source' of the attack, with some 100,000 infected devices sending the bogus traffic.

Domain Name Service (DNS) provider Dyn today provided new details about the massive distributed denial-of-service (DDoS) attack on Oct. 21 it suffered that disrupted major websites including Okta, CNN, Pinterest, Reddit, and Twitter, and confirmed that the infamous Mirai botnet was the main culprit.

Scott Hilton, executive vice president of product for Dyn, in a blog post said the attackers employed masked TCP and UDP traffic via Port 53 in the attack as well as recursive DNS retry traffic, "further exacerbating its impact," he said.

Dyn also confirmed that the widely suspected Mirai botnet was a "primary source" of the DDoS attacks, which came in multiple waves and affected various websites for nearly nine hours on Friday.

"TCP is interesting ... prior threats and big DDoSes tended to be UDP-amplification attacks that require spoofing," says John Bambenek, threat systems manager at Fidelis Cybersecurity. "There's so much crap out there with default passwords."

Default credentials indeed are one of the main culprits that allowed the attackers to use an army of online cameras, DVRs, and other equipment in the attacks, according to security experts.

But the big question of who was behind the crippling attack on the DNS provider remains under investigation. "Dyn is collaborating in an ongoing criminal investigation of the attack and will not speculate regarding the motivation or the identity of the attackers," Dyn's Hilton said in the post.

The DDoS attacks came in traffic bursts that were 40- to 50 times normal flows, he said. "This magnitude does not take into account a significant portion of traffic that never reached Dyn due to our own mitigation efforts as well as the mitigation of upstream providers," Hilton said.

The attackers also waged some smaller "probing" TCP attacks in the hours and days after the big attack, but Dyn was able to mitigate them.

He noted that the DNS traffic sent in the DDoS attacks also generated legitimate DDoS retry traffic, making the attack more complicated to parse, and the attack generated ten- to 20 times the normal DNS traffic levels thanks to malicious and legit retries.

"During a DDoS which uses the DNS protocol it can be difficult to distinguish legitimate traffic from attack traffic," he said in the post. "When DNS traffic congestion occurs, legitimate retries can further contribute to traffic volume. We saw both attack and legitimate traffic coming from millions of IPs across all geographies."

Most of the attack came from Mirai-based botnets, using an estimated 100,000 infected devices.

Related Content:

 

Black Hat Europe 2016 is coming to London's Business Design Centre November 1 through 4. Click for information on the briefing schedule and to register.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
10/27/2016 | 10:37:07 AM
Responsibility of Default Passwords
As denoted in the article, persistent default passwords on IoT devices are a major issue in terms of bot farming. The question from my perspective is; based off the data that there are many default passwords that go unchanged, would efforts be better focused on the vendor providing a different password for each device than relying on the end user for changing it? Regardless if that password remains unchanged it will still be vulnerable but the level of difficulty will increase because then the vendor can set the password complexity parameters and password guessing difficulty would increase as well.
Weaponizing IPv6 to Bypass IPv4 Security
John Anderson, Principal Security Consultant, Trustwave Spiderlabs,  6/12/2018
'Shift Left' & the Connected Car
Rohit Sethi, COO of Security Compass,  6/12/2018
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12557
PUBLISHED: 2018-06-19
An issue was discovered in Zuul 3.x before 3.1.0. If nodes become offline during the build, the no_log attribute of a task is ignored. If the unreachable error occurred in a task used with a loop variable (e.g., with_items), the contents of the loop items would be printed in the console. This could ...
CVE-2018-12559
PUBLISHED: 2018-06-19
An issue was discovered in the cantata-mounter D-Bus service in Cantata through 2.3.1. The mount target path check in mounter.cpp `mpOk()` is insufficient. A regular user can consequently mount a CIFS filesystem anywhere (e.g., outside of the /home directory tree) by passing directory traversal sequ...
CVE-2018-12560
PUBLISHED: 2018-06-19
An issue was discovered in the cantata-mounter D-Bus service in Cantata through 2.3.1. Arbitrary unmounts can be performed by regular users via directory traversal sequences such as a home/../sys/kernel substring.
CVE-2018-12561
PUBLISHED: 2018-06-19
An issue was discovered in the cantata-mounter D-Bus service in Cantata through 2.3.1. A regular user can inject additional mount options such as file_mode= by manipulating (for example) the domain parameter of the samba URL.
CVE-2018-12562
PUBLISHED: 2018-06-19
An issue was discovered in the cantata-mounter D-Bus service in Cantata through 2.3.1. The wrapper script 'mount.cifs.wrapper' uses the shell to forward the arguments to the actual mount.cifs binary. The shell evaluates wildcards (such as in an injected string:/home/../tmp/* string).