Last Updated: 2014-05-13 01:46:09 UTC
by Johannes Ullrich (Version: 1)
It hasn't really been reported much, but just after Microsoft sort of stopped releasing patches for Windows XP last month, we now have to get going on the next phase-out: Windows 8.1!
[In a first version of this diary, I stated that support ends tomorrow. As a reader points out in a comment, Microsoft announced earlier today that it extended the deadline by a month] 
As Microsoft wraps it in beautiful marketing speak:
"Since Microsoft wants to ensure that customers benefit from the best support and servicing experience and to coordinate and simplify servicing across both Windows Server 2012 R2, Windows 8.1 RT and Windows 8.1, this update will be considered a new servicing/support baseline... beginning with the May Patch Tuesday, Windows 8.1 user's devices without the update installed will no longer receive security updates." 
To make things a bit more interesting, there are 3 different versions of what people commonly refer to as "Windows 8":
"Windows 8" , "Windows 8.1" and "Windows 8.1 Update".
I guess in the old days, "Windows 8.1 Update" would be considered a "Service Pack". But then again, that would be something people are used to and not all that confused by, so Microsoft figured to mix it up and call this one "Windows 8.1 Update".
Sadly, there are reports that individuals have problems installing Windows 8.1 Update. You can now even deliver Windows 8.1 Update via WSUS, even though Windows 8.1 initially broke WSUS. 
So with WSUS fixed, and Windows 8.1 Update only breaking some of your systems, you will now be in grant shape for making Windows 8.1 Update your new baseline as this will be the last patch Tuesday for Windows 8.1 Pre-update patches.
Haven't upgraded to Windows 8.1 and still not missing the "Start" button? You should be good until 2023. Lots of time to get used to the new interface. But Windows 8 will only be available for retail sale until end of October .
Last Updated: 2014-05-08 13:47:08 UTC
by Johannes Ullrich (Version: 1)
It started with DNS: Simple short DNS queries are easily spoofed and the replies can be much larger then the request, leading to an amplification of the attack by orders of magnitude. Next came NTP. Same game, different actors: NTP's "monlist" feature allows for small requests (again: UDP, so trivially spoofed) and large responses.
Today, we received a packet capture from a reader showing yet another reflective DDoS mode: SNMP. The "reflector" in this case stands nicely in line for our "Internet of Things" theme. It was a video conferencing system. Firewalling these systems is often not practical as video conferencing systems do use a variety of UDP ports for video and audio streams which are dynamically negotiated. As a result, they are often left "wide open" . And of course, these systems not only let attackers spy on your meeting rooms, but the also make great SNMP reflectors as it turns out.
Here is an anonymized traffic capture (target anonymized with 192.0.2.1):
126.96.36.199 -> 192.0.2.1 SNMP 87 getBulkRequest 188.8.131.52.184.108.40.206.1.1
192.0.2.1 -> 220.127.116.11 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=1f48)
192.0.2.1 -> 18.104.22.168 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=1f48)
... [ additional fragments omitted ] ...
192.0.2.1 -> 22.214.171.124 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=54760, ID=1f48)
192.0.2.1 -> 126.96.36.199 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=56240, ID=1f48)
192.0.2.1 -> 188.8.131.52 SNMP 664 get-response [... large response payload ...]
That is right! A simple 87 byte "getBulkRequest" leads to about 60k Bytes of fragmented data being sent back. We can only assume that poor 184.108.40.206 is the victim of this DoS attack. The user reporting this saw about 5 MBit/sec of traffic.
Similar to what we have seen with other reflective attacks like this, the fragmentation of the traffic is likely going to make filtering even harder. Prolexic posted a white paper about some of the different DrDOS attacks, including SNMP attacks 
So what to do:
- SNMP should probably not traverse your perimeter. Stop it at the firewall. (and I don't think video conferencing systems need it)
- proper egress/ingress control is a good idea. But you already knew that.