Are You Piratebay? thepiratebay.org Resolving to Various Hosts
Thanks to our reader David for sending us this detect (anonymized):
GET announce?info_hash=....&peer_id=....&ip=....&port=....&uploaded=....&downloaded=....*left=....&numwant=.... HTTP/1.0
Host: a.tracker.thepriatebay.org
User-Agent: Bittorrent
Accept: */*
Connection: closed
David's web server was hit with a sufficient number of requests like the one above to cause a denial of service. The requests originated from thousands of different IP addresses, all appear to be located in China. A quick Google search revealed that he wasn't alone, but other web servers experienced similar attacks.
Given the host header (and David observed various "thepriatebay.org" host names), it looks like some DNS servers responded with David's IP address if queried for "thepiratebay.org".
I did a quick check of passive DNS systems, and didn't find David's IP. But when I queried Chinese DNS servers for the host name, I recieved numerous answers. Each answer was only repeated a couple times, if at all. It sort of looked like they all returned different IP addresses. US based DNS servers on the other hand usually don't resolve the host name, or respond with 127.0.0.1, a typical blocklisting technique. Only a handful responded with a routable IP address.
Overall, I am not sure what is happening. Looks like a "Chinese firewall" issue to me. But if you have any ideas or packets, please let me know.
IoT: The Rise of the Machines (Guest Diary)
[This is a guest diary submitted by Xavier Mertens]
Our houses and offices are more and more infested by electronic devices embedding a real computer with an operating system and storage. They are connected to network resources for remote management, statistics or data polling. This is called the "Internet of Things" or "IoT". My home network is hardened and any new (unknown) device connected to it receives an IP address from a specific range which has no connectivity with other hosts or the Internet but its packets are logged. The goal is to detect suspicious activity like data leaks or unexpected firmware updates. The last toy I bought yesterday is a Smart Plug from Supra-Electronics. This device allows you to control a power plug via your mobile device and calculate the energy consumption with nice stats. I had a very good opportunity to buy one for a very low price (25€). Let's see what's inside....
The documentation mentions a setup procedure and management via a mobile device (with a free app for IOS or Android) but the first reflex is to scan the box. Interesting, a webserver as well as a telnet server are waiting for packets. Let's try common credentials like admin/admin and...
$ telnet 192.168.254.225
Trying 192.168.254.225...
Connected to 192.168.254.225.
Escape character is '^]'.
(none) login: admin
Password:
BusyBox v1.12.1 (2014-07-31 06:32:52 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Immediately after the boot sequence, the device started to try to communicate with remote hosts:
Amongst DNS requests and NTP synchronization, a lot of traffic was generated to different IP addresses over UDP/10001. The same packet being sent to different hosts. The payload was a block of 60 bytes:
I was not able to decode the content of this payload, please comment if you recognize some patterns. The device also performs a regular connectivity check via a single ICMP ECHO packet sent to www.google.com (every 5 mins). This network traffic is generated by the process called RDTServer:
# ps
PID USER VSZ STAT COMMAND
1 admin 1400 S init
2 admin 0 SWN [ksoftirqd/0]
3 admin 0 SW< [events/0]
4 admin 0 SW< [khelper]
5 admin 0 SW< [kthread]
6 admin 0 SW< [kblockd/0]
7 admin 0 SW< [kswapd0]
8 admin 0 SW [pdflush]
9 admin 0 SW [pdflush]
10 admin 0 SW< [aio/0]
11 admin 0 SW [mtdblockd]
18 admin 1084 S nvram_daemon
19 admin 1612 S goahead
20 admin 872 R RDTServer
24 admin 1400 R telnetd
26 admin 872 S RDTServer
27 admin 872 S RDTServer
33 admin 872 S RDTServer
34 admin 872 S RDTServer
35 admin 872 S RDTServer
36 admin 872 S RDTServer
53 admin 1400 S /bin/sh
238 admin 0 SW [RtmpCmdQTask]
239 admin 0 SW [RtmpWscTask]
366 admin 1400 S -sh
505 admin 1400 R ps
678 admin 1400 S udhcpd /etc/udhcpd.conf
1116 admin 1396 S udhcpc -i apcli0 -s /sbin/udhcpc.sh -p /var/run/udhcp
1192 admin 872 S RDTServer
1207 admin 772 S ntpclient -s -c 0 -h ntp.belnet.be -i 86400
#
I grabbed a copy of the RDTServer binary (Mips) and using the "strings" command against the file revealed interesting stuff. The IP addresses used were found in the binary:
IP FQDN NetName Country
50.19.254.134 m1.iotcplatform.com AMAZON-EC2-8 US
122.248.234.207 m2.iotcplatform.com AMAZON-EC2-SG Singapore
46.137.188.54 m3.iotcplatform.com AMAZON-EU-AWS Ireland
122.226.84.253 JINHUA-MEIDIYA-LTD China
61.188.37.216 CHINANET-SC China
220.181.111.147 CHINANET-IDC-BJ China
120.24.59.150 m4.iotcplatform.com ALISOFT China
114.215.137.159 m5.iotcplatform.com ALISOFT China
175.41.238.100 AMAZON-AP-RESOURCES-JP Japan
Seeing packets sent to China is often suspicious! The domain name iotcplatform.com belongs to ThroughTek, a company specialized in IoT and M2M ("Machine to Machine") connection platforms:
Domain Name: IOTCPLATFORM.COM
Registry Domain ID: 1665166563_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2014-07-09T11:44:15Z
Creation Date: 2011-07-04T08:50:36Z
Registrar Registration Expiration Date: 2016-07-04T08:50:36Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: abuse@godaddy.com
Registrar Abuse Contact Phone: +1.480-624-2505
Registry Registrant ID:
Registrant Name: Charles Kao
Registrant Organization:
Registrant Street: 4F., No.221, Chongyang Rd.,
Registrant City: Taipei
Registrant State/Province: Nangang District
Registrant Postal Code: 11573
Registrant Country: Taiwan
Registrant Phone: +886.886226535111
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: justin_yeh@tutk.com
In fact, the IOTC platform is a service developed by ThoughTek to establish P2P communications between devices. I read the documentation provided with the device as well as all the website pages and there is no mention of this service. Manufacturers should include some technical documentation about the network requirements (ex: to download firmware updates). In this case, it's not a major security issue but this story enforces what we already know (and be afraid) about IoT: those devices have weak configuration and they lack of visibility/documentation about their behavior. Take care when connecting them on your network. A best practice is to inspect the traffic they generate once online (DNS requests, HTTP(S) request or any other protocol).
--
"If the enemy leaves a door open, you must rush in." - Sun Tzu
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x42D006FD51AD7F2C
Comments