Its with a (slightly) heavy heart I write this as I’m a fan boy of Ubiquiti‘s networking gear. For those that don’t know, Ubiquiti put business-class networking firmly in the consumer price bracket.
Alas, security researchers at Rapid7 recently found evidence of Ubiquiti‘s discovery port being used as part of an amplification attack, albeit tentatively as the general consensus is criminals are testing effectiveness.
An important note: at present (13 Feb 2019) Ubiquiti haven’t address this in a firmware release so updating your devices firmware will not disable the discovery service WANside.
How to disable the Ubiquiti Discovery Service (10001)
Usual disclaimer: this is for guidance only and any changes you make to your system are done at your own risk.
I’ll get straight in to it for those simply here to find out how to disable the service. You’ll need to SSH in to the device as there is no option within the GUI for disabling discovery. Once you are logged in via SSH, run the following commands:
ubnt@ubnt:~$ configure
ubnt@ubnt# set service ubnt-discover disable
ubnt@ubnt# commit
The above script is the generally accepted way but I have performed the extra step below due to the definition of the services on Ubiquiti’s website here:
This feature consists of two services and both are enabled by default:
ubnt-discoverControls whether the EdgeRouter is able to discover nearby Ubiquiti devices.Ubiquiti EdgeRouter Articles
ubnt-discover-serverControls whether the EdgeRouter is discoverable by other nearby devices.
The extra step simply disables a secondary discovery service that runs on some UniFi devices:
ubnt@ubnt:~$ configure
ubnt@ubnt# set service ubnt-discover disable
ubnt@ubnt# set service ubnt-discover-server disable
ubnt@ubnt# commit
How long has this been going on?
Rapid7 released their report on the 29th January 2018 but when I looked at the Ubiquiti forums, there are possible indications going back as far as 2013 of users seeing small repeated requests hitting their 10001 port (presumably to illicit an amplified response).
A search on Shodan currently shows over 700K devices: https://www.shodan.io/search?query=Ubiquiti+port%3A%2210001%22. I’ve tested a few and can confirm that I received back system information when sending a UDP packet.
. I’ve tested a few and can confirm that I received back system information when sending a UDP packet.
How to test if the service is responding?
You can use the following nmap command from a wan based host to check your devices WAN port for response:
echo -ne "\x01\x00\x00\x00" | socat -t 1 udp:123.123.123.123:10001 - | hexdump -C
When the discovery port is still open, you should receive a response something along the lines of the following:
00000000 01 00 00 97 02 00 0a 78 8a 20 38 74 38 a8 c5 e5 |…….x. 8t8…|
00000010 5b 02 00 0a 78 8a 20 39 74 38 c0 a8 01 14 01 00 |[…x. 9t8……|
00000020 06 78 8a 20 38 74 38 0a 00 04 00 03 76 b9 0b 00 |.x. 8t8…..v…|
00000030 0e 4e 61 6e 6f 42 65 61 6d 20 4d 35 20 31 36 0c |.NanoBeam M5 16.|
00000040 00 06 4e 35 42 2d 31 36 0d 00 10 47 69 67 61 73 |..N5B-16…Gigas|
00000050 61 74 5f 4d 75 63 75 72 69 5f 39 0e 00 01 02 03 |at_Mucuri_9…..|
00000060 00 23 58 57 2e 61 72 39 33 34 78 2e 76 35 2e 36 |.#XW.ar934x.v5.6|
00000070 2e 31 31 2e 32 39 37 34 35 2e 31 36 30 39 33 30 |.11.29445.125930|
00000080 2e 31 35 32 36 10 00 02 e8 15 14 00 0e 4e 61 6e |.1526……..Nan|
00000090 6f 42 65 61 6d 20 4d 35 20 31 36 |oBeam M5 16|
0000009b
As you can see, there are key details about the device included.
If your system is correctly ignoring these requests, you’ll get an empty response (nothing) or a connection timed out error.
