Last Updated: 2014-05-01 16:36:25 UTC
by Russ McRee (Version: 1)
We've received multiple reports regarding impact to UltraDNS services which are allegedly the result of a 100Gb/s attack on one of their customers, which in turn is causing latency for others. Monitor #ultradns for the time being as no official report has been released yet by UltraDNS. One reporting party did indicate that they learned that the management of UltraDNS had said that one of their customers was being attacked and that they black-holed that customer to get back on trend. Resolver nodes around the world are resetting.
We'll update here as we learn more.
Update as of 1045 PST: UltraDNS is still not stable as customers are still having intermittent DNS resolution failures
Update as of 1100 PST: UltraDNS still propagating changes from the attack this morning and hope to be complete as of approximately 11:30 PST. Intermittent issues still remain for customers. Always a bit ironic when those who sell DDoS protection are themselves adversely impacted by DDoS. :-)
Update as of 1240 PST: Direct quote from Neustar UltraDNS - "Currently, the Neustar UltraDNS Operations and Security teams continue to work with our Tier One Providers to further refine upstream mitigations within the Carriers networks. Additionally, the Neustar team is working on adding additional UltraDNS Name Servers into active mitigation. The DDoS traffic continues to shift attack vectors and our teams are working on altering countermeasures to insure stability of
service as quickly as possible.
At Neustar, we are committed to providing the highest levels of performance and reliability through the products and solutions we deliver. Please feel free to contact our 24x7 UltraDNS Support Team at ultrasupport@Neustar.biz with any questions or concerns."
Update as 1400 PST: "The Neustar UltraDNS Operations and Security teams have the majority of the UltraDNS customer base in mitigation on our DDoS mitigation
network. Currently, only customers utilizing a segment of UltraDNS Name Server addresses (PDNS1-PDNS6) are experiencing resolution latency due to intermittent network saturation in the Western US. We continue to aggressively refine mitigations for these customers and hope to have the issue resolved shortly."
NOTE: Customers are indicating that Neustar UltraDNS has been providing constant updates (5 or 6 now) which should be seen as a positive response to a difficult situation.
Update as of 2300 PST: "As of 00:26 GMT on May 1st, DNS traffic for customers on the PDNS1-PDNS6 Name Server segment has been resolving and stable. While we currently have no network related alerts or customer identified issues, the PDNS1-PDNS6 announcements will remain on the Neustar SiteProtect network and all proactive mitigations will continue to be active until Neustar deems the potential threat to be closed. Customers on non-PDNS announcements segments did experience higher than normal latency and DNS time outs as a side effect of this event, however, those announcements were stabilized as of 1849 GMT. The Neustar Network and Security Operations teams continue to monitor traffic on both the SiteProtect and UltraDNS network closely in case of a renewal of the attack traffic. A full Incident Report will be provided to customers as soon as possible once we complete our investigation with our internal teams and network providers."
Last Updated: 2014-04-30 01:06:09 UTC
by Johannes Ullrich (Version: 1)
We got an email from one of our readers, including an interesting port 53 packet. While Wireshark and TCPDump try to decode it as DNS, it is almost certainly not DNS.
The payload of the packet is (I obfuscated the country the user is located in):
oracle:1c6F65E41DFC:www.kmplayer.com:192.168.1.2:[country of system]:SYSTEM:Windows XP:V139
The user does not have KMPlayer or Oracle installed in his network. This looks very much like some form of command and control traffic. At this point, we do not have any malware associated with it.
Here is how tcpdump decoded the packets (again, anonymized):
$ tcpdump -r strange-udp.pcapng -nAt
reading from file strange-udp.pcapng, link-type EN10MB (Ethernet)
IP a.b.c.d.20510 > w.x.y.z.53: 28530 updateM+ [b2&3=0x6163] [14897a] [27749q] [25398n] [17974au][|domain]
IP a.b.c.d.11185 > w.x.y.z.53: 28530 updateM+ [b2&3=0x6163] [14896a] [27749q] [12337n] [17988au][|domain]
The source was an RFC 1918 address in this case, and the target was close to the user's IP address, which is why both are anonymized here. I also removed the non printable part of the payload to make it fit the screen.
I installed KMPlayer on a virtual system and didn't see any traffic like this.