Your Fly Is Open

Netmenaces and Other Internet Stupidity

Toyz From China

2016-05-10 5 min read Attacks

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 777 the 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