CVE-2017-8587

Windows Explorer Denial of Service Vulnerability:

MITRE CVE-2017-8587

An Denial Of Service vulnerability exists when Windows Explorer attempts to open a non-existent file. An attacker who successfully exploited this vulnerability could cause a denial of service.

A attacker could exploit this vulnerability by hosting a specially crafted web site and convince a user to browse to the page, containing the reference to the non-existing file, and cause the victim's system to stop responding. An attacker could not force a user to view the attacker-controlled content. Instead, an attacker would have to convince a user to take action. For example, an attacker could trick a user into clicking a link that takes the user to the attacker's site

Exploitability Assessment:

Products Affected:

Windows Explorer in Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511 allows a denial of service vulnerability when it attempts to open a non-existent file, aka "Windows Explorer Denial of Service Vulnerability".

Impact:

CVSS v3.0 Severity and Metrics:

Base Score: 6.5 MEDIUM 

Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H (V3 legend) 

Impact Score: 3.6 

Exploitability Score: 2.8

Attack Vector (AV): Network 

Attack Complexity (AC): Low 

Privileges Required (PR): None 

User Interaction (UI): Required 

Scope (S): Unchanged 

Confidentiality (C): None 

Integrity (I): None 

Availability (A): High

CVSS v2.0 Severity and Metrics:

Base Score: 4.3 MEDIUM 

Vector: (AV:N/AC:M/Au:N/C:N/I:N/A:P) (V2 legend) 

Impact Subscore: 2.9 

Exploitability Subscore: 8.6

Access Vector (AV): Network 

Access Complexity (AC): Medium 

Authentication (AU): None 

Confidentiality (C): None 

Integrity (I): None 

Availability (A): Partial 

Additional Information: 

Victim must voluntarily interact with attack mechanism

Allows disruption of service

Known Affected Software Configurations Switch to CPE 2.2

 cpe:2.3:o:microsoft:windows_10:-:*:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_10:1511:*:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_7:*:sp1:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_8.1:*:*:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_rt_8.1:*:*:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_server_2008:*:sp2:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_server_2008:r2:sp1:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_server_2012:-:*:*:*:*:*:*:*

     Show Matching CPE(s) 

 cpe:2.3:o:microsoft:windows_server_2012:r2:*:*:*:*:*:*:*

     Show Matching CPE(s) 

Five Most Famous DDoS Attacks:

In recent years, DDoS attacks have only been increasing in both frequency and severity. Here, we’ll examine five of the largest and most famous DDoS attacks.

1. GitHub: 1.35 Tbps

On Feb. 28, 2018, GitHub—a popular developer platform—was hit with a sudden onslaught of traffic that clocked in at 1.35 terabits per second. If that sounds like a lot, that’s because it is—that amount of traffic is not only massive, it’s record-breaking.

According to GitHub, the traffic was traced back to “over a thousand different autonomous systems (ASNs) across tens of thousands of unique endpoints.”

In this graph, you can see just how much of a difference there was between normal traffic levels and those of the attack:

GitHub DDoS Attack

What’s worse is that GitHub was not entirely unprepared for a DDoS attack—they simply had no way of knowing that an attack of this scale would be launched.

As GitHub explained in the incident report linked above, “Over the past year we have deployed additional transit to our facilities. We’ve more than doubled our transit capacity during that time, which has allowed us to withstand certain volumetric attacks without impact to users…. Even still, attacks like this sometimes require the help of partners with larger transit networks to provide blocking and filtering.”

2. Occupy Central, Hong Kong: 500 Gbps

The PopVote DDoS attack was carried out in 2014 and targeted the Hong Kong-based grassroots movement known as Occupy Central. The movement was campaigning for a more democratic voting system.

In response to their activities, attacker(s) sent large amounts of traffic to three of Occupy Central’s web hosting services, as well as two independent sites, PopVote, an online mock election site, and Apple Daily, a news site, neither of which were owned by Occupy Central but openly supported its cause. Presumably, those responsible were reacting to Occupy Central’s pro-democracy message.

The attack barraged servers with packets disguised as legitimate traffic, and was executed with not one, not two, but five botnets. This resulted in peak traffic levels of 500 gigabits per second.

3. CloudFlare: 400 Gbps

In 2014, security provider and content delivery network CloudFlare was slammed by approximately 400 gigabits per second of traffic. The attack was directed at a single CloudFlare customer and targeted servers in Europe and was launched with the help of a vulnerability in the Network Time Protocol (NTP), a networking protocol for computer clock synchronization. Even though the attack was directed at just one of CloudFlare’s customers, it was so powerful that it affected CloudFlare’s own network.

This attack illustrated a technique in which attackers use spoofed source addresses to send mass amounts of NTP servers’ responses to the victim. This is known as “reflection,” since the attacker is able to mirror and amplify traffic.

Shortly after the attack, the U.S. Computer Emergency Readiness Team explained NTP Amplification Attacks are, “especially difficult to block” because “responses are legitimate data coming from valid servers.”

4. Spamhaus: 300 Gbps

In 2013, a DDoS attack was launched against Spamhaus, a nonprofit threat intelligence provider. Although Spamhaus, as an anti-spam organization, was and is regularly threatened and attacked, this DDoS attack was large enough to knock their website offline, as well as part of their email services.

Like the 2014 attack on CloudFlare mentioned above, this attack utilized reflection to overload Spamhaus’ servers with 300 gigabits of traffic per second.

The attack was traced to a member of a Dutch company named Cyberbunker, who seemingly targeted Spamhaus after it blacklisted Cyberbunker.

5. U.S. Banks: 60 Gbps

In 2012, not one, not two, but a whopping six U.S. banks were targeted by a string of DDoS attacks. The victims were no small-town banks either: They included Bank of America, JP Morgan Chase, U.S. Bancorp, Citigroup and PNC Bank.

The attack was carried out by hundreds of hijacked servers, which each created peak floods of more than 60 gigabits of traffic per second.

At the time, these attacks were unique in their persistence: Rather than trying to execute one attack and then backing down, the perpetrator(s) barraged their targets with a multitude of methods in order to find one that worked. So, even if a bank was equipped to deal with a few types of DDoS attacks, they were helpless against other types.

• Recommendations:

Block external access at the network boundary, unless external parties require service.

If global access isn't needed, block access at the network perimeter to computers hosting the vulnerable operating system.

Deploy network intrusion detection systems to monitor network traffic for malicious activity.

Deploy NIDS to monitor network traffic for signs of anomalous or suspicious activity such as unexplained incoming and outgoing traffic. This may indicate exploit attempts or activity that results from successful exploits.

Do not accept or execute files from untrusted or unknown sources.

To reduce the likelihood of successful exploits, never handle files that originate from unfamiliar or untrusted sources.

Do not follow links provided by unknown or untrusted sources.

Web users should be cautious about following links to sites that are provided by unfamiliar or suspicious sources. Filtering HTML from emails may help remove a possible vector for transmitting malicious links to users.

Do not use client software to access unknown or untrusted hosts from critical systems.

To limit the risk of exploits, never connect to unknown or untrusted services.