Toyz From China
Earlier today, I was “given” some toyz from China.
Some people look at network attackers and think that they’re just here to take, take, take… however, if you look at things from a different perspective (and you’ve got a convincing enough SSH honeypot) you may find that they’re actually very giving people.
For example, this morning some folks sourcing from Jiangsu, Nanjing China were nice enough to stop by one of my honeypots and download a “gift” for me. (謝謝 - Which Google Translate claims is “Thank you” in traditional Chinese).
First off, some background: The attackers hit the site and logged right in with the correct password for “root” - so obviously, they’ve knocked on the site’s SSH “door” with a brute force login attack sometime in the past (from a different IP). They kicked off an SSH channel session (I think that’s likely a method of weeding out honeypots… unfortunately - for them - my honeypot handles SSH channels quite nicely) and proceeded to:
- Try several different ways to shut down iptables (such a typical hacker move… almost a cliche…)
- Download a file called “s25” from 115.28.206.48:9981 (Zhejiang, Hangzhou China)
chmod 777the newly downloaded file- Run s25
So… what is this “s25” program? Well, it turns out to be a variant of the “Bill Gates DDoS tool” (described by the fine folks at Kaspersky here - tl;dr: It’s a combo backdoor/DDoS tool that’s increasingly been making the rounds of late). What’s interesting about this “tool” is that it has the built-in ability to perform DNS amplification attacks.
DNS amplification attacks?
Let’s say that you’re an enterprising young hacker/botnet herder who has managed to take over a stable of systems that can generate around 200 Mbps of traffic. While that might be enough bandwidth to knock your skeevy hacker buddiez off the ‘net for lulz, in the world of DDoS attacks, it isn’t really going to raise any eyebrows. While you could, potentially, wrangle more systems to increase your bandwidth, that takes… like, you know… work… and could seriously cut into your Call of Duty: Black Ops III time… What to do, what to do?
Back in the day (i.e., the early ‘90s), you used to be able to send an ICMP echo request from a spoofed address to the broadcast address of a netblock, confident that the router would happily forward it to every system in that block. Each of those devices would then respond to the spoofed address, and voila… you’ve suddenly created a metric crap-tonne of traffic directed at your target (i.e. the address you spoofed). For some unknown reason, this was called a SMURF attack, and it demonstrates the hallmarks of any good amplification attack:
Traffic that initiates a response can be sent over a connection-less protocol (ICMP, UDP) and therefore easily spoofed The response is significantly larger than the traffic that initiates it SMURF attacks have, happily, gone the way of cargo pants and slap bracelets, but amplification attacks live on in a different form. DNS fits both of our “amplification criteria” very well: requests are sent over UDP, and you can get a pretty decent “amplification” from a simple request:
tliston@honeypot» dig ANY ibm.com
; <<>> DiG 9.9.5-3 <<>> ANY ibm.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18156
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ibm.com. IN ANY
;; ANSWER SECTION:
ibm.com. 21599 IN A 129.42.38.1
ibm.com. 21599 IN NS usc2.akam.net.
ibm.com. 21599 IN NS ns1-99.akam.net.
ibm.com. 21599 IN NS ns1-206.akam.net.
ibm.com. 21599 IN NS asia3.akam.net.
ibm.com. 21599 IN NS eur5.akam.net.
ibm.com. 21599 IN NS usc3.akam.net.
ibm.com. 21599 IN NS usw2.akam.net.
ibm.com. 21599 IN NS eur2.akam.net.
ibm.com. 21599 IN SOA asia3.akam.net. hostmaster.akamai.com. 1462569396 43200 7200 604800 3600
ibm.com. 3599 IN MX 10 e16.ny.us.ibm.com.
ibm.com. 3599 IN MX 10 e31.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e35.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e38.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e34.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e12.ny.us.ibm.com.
ibm.com. 3599 IN MX 10 e33.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e32.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e11.ny.us.ibm.com.
ibm.com. 3599 IN MX 10 e15.ny.us.ibm.com.
ibm.com. 3599 IN MX 10 e14.ny.us.ibm.com.
ibm.com. 3599 IN MX 10 e37.co.us.ibm.com.
ibm.com. 3599 IN MX 10 e13.ny.us.ibm.com.
ibm.com. 599 IN TXT "yandex-verification: 6e0542153d39cb67"
ibm.com. 599 IN TXT "google-site-verification=tzdngH5fWH-k8uQoDVovOFJQZTwaGtDOP6S2cQlOvCs"
ibm.com. 599 IN TXT "v=spf1 mx include:zuora.com -all"
ibm.com. 599 IN TXT "MS=ms61389031"
;; Query time: 167 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue May 10 12:18:34 CDT 2016
;; MSG SIZE rcvd: 743
In this instance, the DNS query was 36 bytes, and the response was 743 bytes, an amplification factor of 20.64 times, which could be used to turn a paltry 200 Mbps trickle into a mighty 4 Gbps torrent. Spoofing the source IP address of your victim is easy, so all you need is a bunch o’compliant DNS servers willing to play along… (The more, the merrier… it spreads the love…)
I did a little digging in the innards of the “gift” I received and uncovered a listing of 197 different IP addresses that turned out to point to some very “compliant” DNS servers… Here’s a sample:
68.163.132.61.in-addr.arpa. 21599 IN PTR cache1.ahhfptt.net.cn.
68.213.102.202.in-addr.arpa. 21599 IN PTR cache.ahwhtel.net.cn.
101.200.102.202.in-addr.arpa. 21599 IN PTR 101.200.102.202.broad.static.hf.ah.cndata.com.
1.64.38.202.in-addr.arpa. 3599 IN PTR ns.ustc.edu.cn.
129.88.91.211.in-addr.arpa. 21599 IN PTR dns.ahhf.cnuninet.net.
2.180.138.211.in-addr.arpa. 21599 IN PTR ns1.ah.chinamobile.com.
2.78.104.218.in-addr.arpa. 21128 IN PTR 2.78.104.218.adsl-pool.ah.cnuninet.net.
68.199.102.202.in-addr.arpa. 21599 IN PTR cache2.ahwhtel.net.cn.
3.3.175.202.in-addr.arpa. 21599 IN PTR macau.ctm.net.
3.3.175.202.in-addr.arpa. 21599 IN PTR vassun1.macau.ctm.net.
The problem is that people running DNS servers leave them open to the world, willing to resolve addresses for anyone who queries them - known as “running a recursive resolver.” Now, were I a betting man, I wouldn’t put a dime on the liklihood of getting the recursive resolvers on my list to clean up their acts, but that doesn’t mean that something can’t be done. If your organization is running a recursive resolver (and you can test if you are, right here), shut off recursion NOW, configuring it to respond only to those IPs in your own netblock. For BIND, the configuration options look like this:
options { recursion no;};
options { allow-query {192.168.1.0/24;};};
Fun, fun, fun…
-TL
Tom Liston
Owner, Principal Consultant
Bad Wolf Security, LLC
Mastodon: @tliston@infosec.exchange
Twitter (yes, I know… X): @tliston
May 10, 2016