Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2018-03-13 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Microsoft March 2018 Patch Tuesday

Published: 2018-03-13
Last Updated: 2018-03-13 18:32:58 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

March 2018 Security Updates (Preliminary. Work in Progress)

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity
.NET Core Denial of Service Vulnerability
CVE-2018-0875 No No Less Likely Less Likely Important
ASP.NET Core Denial of Service Vulnerability
CVE-2018-0808 Yes No - - Important
ASP.NET Core Elevation of Privilege Vulnerability
CVE-2018-0787 No No - - Important
CNG Security Feature Bypass Vulnerability
CVE-2018-0902 No No Less Likely Less Likely Important
Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0930 No No - - Critical
CVE-2018-0931 No No - - Critical
CVE-2018-0933 No No - - Critical
CVE-2018-0934 No No - - Critical
CVE-2018-0936 No No - - Critical
CVE-2018-0937 No No - - Critical
CVE-2018-0872 No No - - Critical
CVE-2018-0873 No No - - Important
CVE-2018-0874 No No - - Critical
CredSSP Remote Code Execution Vulnerability
CVE-2018-0886 No No Less Likely Less Likely Important
Hyper-V Information Disclosure Vulnerability
CVE-2018-0888 No No Less Likely Less Likely Important
Internet Explorer Elevation of Privilege Vulnerability
CVE-2018-0942 No No - - Important
Internet Explorer Information Disclosure Vulnerability
CVE-2018-0929 No No More Likely More Likely Important
March 2018 Adobe Flash Security Update
ADV180006 No No - - Critical
Microsoft Access Remote Code Execution Vulnerability
CVE-2018-0903 No No Less Likely Less Likely Important
Microsoft Browser Information Disclosure Vulnerability
CVE-2018-0927 No No More Likely More Likely Important
CVE-2018-0932 No No - - Critical
Microsoft Edge Information Disclosure Vulnerability
CVE-2018-0879 No No - - Important
Microsoft Exchange Elevation of Privilege Vulnerability
CVE-2018-0940 Yes No Unlikely Unlikely Important
Microsoft Exchange Information Disclosure Vulnerability
CVE-2018-0924 No No Unlikely Unlikely Low
CVE-2018-0941 No No Unlikely Unlikely Important
Microsoft Office Excel Security Feature Bypass
CVE-2018-0907 No No More Likely More Likely Important
Microsoft Office Information Disclosure Vulnerability
CVE-2018-0919 No No More Likely More Likely Important
Microsoft Office Memory Corruption Vulnerability
CVE-2018-0922 No No - - Important
Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0909 No No Less Likely Less Likely Important
CVE-2018-0910 No No Less Likely Less Likely Important
CVE-2018-0911 No No Less Likely Less Likely Important
CVE-2018-0912 No No Less Likely Less Likely Important
CVE-2018-0913 No No Less Likely Less Likely Important
CVE-2018-0914 No No Less Likely Less Likely Important
CVE-2018-0915 No No Less Likely Less Likely Important
CVE-2018-0916 No No Less Likely Less Likely Important
CVE-2018-0917 No No - - Important
CVE-2018-0921 No No - - Important
CVE-2018-0923 No No Less Likely Less Likely Important
CVE-2018-0944 No No Less Likely Less Likely Important
Microsoft Sharepoint Elevation of Privilege Vulnerability
CVE-2018-0947 No No Less Likely Less Likely Important
Microsoft Video Control Elevation of Privilege Vulnerability
CVE-2018-0881 No No Less Likely Less Likely Important
Scripting Engine Information Disclosure Vulnerability
CVE-2018-0891 No No More Likely More Likely Important
CVE-2018-0939 No No - - Critical
Scripting Engine Memory Corruption Vulnerability
CVE-2018-0889 No No More Likely More Likely Critical
CVE-2018-0893 No No - - Critical
CVE-2018-0935 No No More Likely More Likely Important
CVE-2018-0876 No No - - Critical
CVE-2018-0925 No No - - Critical
Win32k Elevation of Privilege Vulnerability
CVE-2018-0977 No No More Likely More Likely Important
Windows Desktop Bridge Elevation of Privilege Vulnerability
CVE-2018-0880 No No Less Likely Less Likely Important
CVE-2018-0882 No No - - Important
Windows Desktop Bridge VFS Elevation of Privilege Vulnerability
CVE-2018-0877 No No Less Likely Less Likely Important
Windows GDI Elevation of Privilege Vulnerability
CVE-2018-0816 No No - - Important
CVE-2018-0817 No No More Likely More Likely Important
CVE-2018-0815 No No - - Important
Windows Hyper-V Denial of Service Vulnerability
CVE-2018-0885 No No Less Likely Less Likely Important
Windows Installer Elevation of Privilege Vulnerability
CVE-2018-0868 No No Less Likely Less Likely Important
Windows Kernel Information Disclosure Vulnerability
CVE-2018-0811 No No More Likely More Likely Important
CVE-2018-0894 No No More Likely More Likely Important
CVE-2018-0895 No No More Likely More Likely Important
CVE-2018-0896 No No More Likely More Likely Important
CVE-2018-0897 No No More Likely More Likely Important
CVE-2018-0898 No No More Likely More Likely Important
CVE-2018-0899 No No More Likely More Likely Important
CVE-2018-0900 No No More Likely More Likely Important
CVE-2018-0901 No No More Likely More Likely Important
CVE-2018-0926 No No More Likely More Likely Important
CVE-2018-0813 No No More Likely More Likely Important
CVE-2018-0814 No No More Likely More Likely Important
CVE-2018-0904 No No More Likely More Likely Important
Windows Remote Assistance Information Disclosure Vulnerability
CVE-2018-0878 No No Less Likely Less Likely Important
Windows Security Feature Bypass Vulnerability
CVE-2018-0884 No No Less Likely Less Likely Important
Windows Shell Remote Code Execution Vulnerability
CVE-2018-0883 No No More Likely More Likely Important
Windows Storage Services Elevation of Privilege Vulnerability
CVE-2018-0983 No No More Likely More Likely Important

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Keywords:
8 comment(s)

How did it all start? Early Memcached DDoS Attack Precursors and Ransom Notes

Published: 2018-03-13
Last Updated: 2018-03-13 13:30:14 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

This is a guest diary written by Remco Verhoef . Remco is the founder of Dutchsec

The past weeks we’ve seen several large DDoS attacks taking advantage of public accessible memcached instances. By sending UDP packets to lots of memcached instances, with the source address being set to the victim, the return packet will be amplified (50.000 times) compared to the original packet, causing a DDoS of the victim. The largest attack seen so far has been 1.7Tb.

Several reports are referencing that the attacks contain a new method to deliver a ransom note and asking for Bitcoin or Monero. The ransom note (Pay_50_XMR_To) is included within UDP packets sent to the victim. (http://fortune.com/2018/03/02/crypto-hackers-monero-ddos-attack-ransom/)

We have seen attacks before where Elasticsearch, Redis and Mongodb instances had data replaced by ransom notes, claiming bitcoins. The vulnerable memcached instances have been around for a long time, which makes it possible that the data was replaced by an attacker not interested in the DDoS attempt, while another attacker used the same instance (with the content as is, in this case, the ransom note) for an amplification attack.

To effectively use a memcached server in a DoS attack, the attacker will first add data to the server. This will increase the size of the reply. So far, attackers have usually used one letter keys like “a b c d e f g h j k l m n” and then later requested the connect for these keys using the spoofed victim attacks. Within our honeytrap data we see first occurrences using the amplification signature “gets a b c d e f g h j k l m n” and UDP since 24th of February. An interesting fact is that for some reason key i isn’t being queried. In the period before we see a lot of “stats” commands (using TCP) probing our honeytraps. This could have been a first probe to see if there was a vulnerable memcached instance. Important to know is that to add a 1M large value into the database, TCP should be used.UDP is limited by the IPv4 datagram size to 64kBytes, effectively limiting the maximum value size to a little less than 64kBytes.

On 24th and 26th of February we’ve seen several gets being fired from (or spoofed to) host 103.60.13.34. In total we’ve seen gets from (or spoofed to) this host on 24th Feb, 26th Feb, 9th March and 11th March.

At the 26th of February, we’ve also seen host 185.165.31.26. The 27th we’ve seen host 162.212.155.220.

The 1.35 terabits attack on Github took place on the 28th of February. So apparently we’ve had some precursors of this upcoming attack 4 days before in our honeytraps.  On and after the 1st of March, at the time of the first publications about the attacks, we’ve seen an increase in the number of attacks.

The gets command being used will retrieve one or multiple exact keys, the DDoS attacker should have known (or prepared) the key.

We’ve added simple support for Memcached stats to Honeytraps. To be sure we don’t inadvertently participate in DDoS attacks UDP answers will be rate limited.

If you take into account the following, then we cannot exclude the possibility that instances had been ransomed before by different attackers than the attackers behind the large DDoS attacks.

  • vulnerable and abandoned memcache servers have been accessible for a long time

  • there have been ransoming of databases, indexes and caching servers before

  • it is not logical to ask for ransom while firing the largest attacks ever

  • no signs of replacing the data right before the DDoS attack

  • instead of the XMR ransom note, we now see BTC ransom notes

  • the cmd being sent to the server contained key names a till n, where many of the instances only contain key a. The initial packet could have been smaller, or the other b .. n keys have been flushed/removed already.

  • the value should have been set by TCP, because the size of the values we see is close to the default 1M size limit.

The following question arises, did the DDoS attackers took advantage of ransomed instances to execute the DDoS or did they prepare the memcached instances themselves for a longer period of time?

 

Keywords:
0 comment(s)
Diary Archives