Reply
Senior Member
Posts: 3,130
Registered: ‎07-28-2009
Kudos: 898
Solutions: 40

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@UBNT-MindasI have had what looks like the same attack today.

 

https://community.ubnt.com/t5/airMAX-General-Discussion/CPEs-CPU-usage-goes-to-100-en-mass/m-p/24459...

 

I have blocked port 10001 at my edge and now show "attacks" coming regularly.  Why did UBNT not put out a possible threat alert so I could have already had these blocked while UBNT investigates?  It would save me from trying to contact several clients to reboot their CPEs.

Senior Member
Posts: 2,978
Registered: ‎07-17-2010
Kudos: 667
Solutions: 167

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

[ Edited ]

I've a handful offline in AC, that are up. No ssh or web, but respond to ping.

 

Whatever the cause, why are the radios in dummy mode? I have no attacks coming through firewall.

 

Will you be fixing this in a firmware update?

Senior Member
Posts: 2,978
Registered: ‎07-17-2010
Kudos: 667
Solutions: 167

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

6.1.4 and 6.1.7

Senior Member
Posts: 3,130
Registered: ‎07-28-2009
Kudos: 898
Solutions: 40

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

[ Edited ]

So I thought I had all the approriate ports blocked at our Edge for the UBNT CPEs.  SSH, HTTPS and HTTP.  Now I find out about port 10001 and this issue.

 

@UBNT-SNK @UBNT-MindasWhere do I find a list of all the ports that a UBNT radio listens or responds to so I can also add them to our Edge router's firewall?

Ubiquiti Employee
Posts: 588
Registered: ‎12-21-2017
Kudos: 102
Solutions: 16

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@sbyrd - Hi and thank you for your question. You could see the ports in nmap (from the outside) or netstat (from the device).

Emerging Member
Posts: 79
Registered: ‎12-30-2010
Kudos: 29

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

So I just ran nmap against a unit with this issue, and weirdly it shows the device as a Netgear ReadyNAS

 

Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open tcpwrapped
80/tcp open http?
10001/tcp open scp-config?
Device type: storage-misc
Running: Netgear RAIDiator 4.X
OS CPE: cpe:/o:netgear:raidiator:4.1.4
OS details: Netgear ReadyNAS Duo NAS device (RAIDiator 4.1.4)

 

Here is one working correctly.

 

Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh Dropbear sshd 2016.74 (protocol 2.0)
80/tcp open http lighttpd 1.4.39
|_http-favicon: Unknown favicon MD5: 6DCAB71E60F0242907940F0FCDA69EA5
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-title: Error 404 - Page Not Found
|_Requested resource was /nocookies.html
10001/tcp open tcpwrapped
Device type: WAP
Running: Linux 2.6.X, Ubiquiti embedded, Ubiquiti AirOS 5.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.32 cpe:/h:ubnt:airmax_nanostation cpe:/o:ubnt:airos:5.2.6
OS details: Ubiquiti AirMax NanoStation WAP (Linux 2.6.32), Ubiquiti Pico Station WAP (AirOS 5.2.6)

 

A little bit strange

Ubiquiti Employee
Posts: 484
Registered: ‎08-28-2007
Kudos: 82
Solutions: 8

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

Thanks guys for reporting. Just want to clear it a bit: is it TCP or UDP attack? As UDP is not responding to public IP addresses since versions even port is open: v6.1.6 and v8.1.4
Ubiquiti Networks, Inc.
System programmer
Ubiquiti Employee
Posts: 588
Registered: ‎12-21-2017
Kudos: 102
Solutions: 16

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@dthomas - thanks for sharing - what is the FW version for the device that turns up as Netgear NAS? Can you share the precise nmap statement you have ran? Can you reproduce the same results with another unit with "this" issue?

 

OS detection that nmap uses are based on various TPC/IP stack parameters is not 100% percent relieable - however it is worth checking this finding.

Senior Member
Posts: 3,130
Registered: ‎07-28-2009
Kudos: 898
Solutions: 40

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

[ Edited ]

@UBNT-keba - I created 2 firewall rules.  One to block TCP 10001 and one to block UDP 10001.  The TCP rule has over 10X more hits than the UDP one so I would say the attacks are TCP.Capture.PNGLog Snip of attacks

Senior Member
Posts: 3,130
Registered: ‎07-28-2009
Kudos: 898
Solutions: 40

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@UBNT-keba If you want I can do some packet captures from my Edge router on any attempts to reach TCP port 10001 and then send you the file.

Senior Member
Posts: 2,644
Registered: ‎09-11-2009
Kudos: 1073
Solutions: 60

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

This attack certainly has ramped up lately, one of our techs dropped the 10001 firewall rule accidentally on a subnet and they pegged to 100% within 24 hours....  

Ubiquiti Employee
Posts: 588
Registered: ‎12-21-2017
Kudos: 102
Solutions: 16

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@Wifimax - thanks for letting us know - any possibilities to get packet captures?

Senior Member
Posts: 3,130
Registered: ‎07-28-2009
Kudos: 898
Solutions: 40

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@UBNT-Mindas - Any progress on the root cause and a fix.  I have not had another occurance of this since blocking TCP/UDP 10001 at our Edge.

Ubiquiti Employee
Posts: 8,674
Registered: ‎04-14-2017
Kudos: 1633
Solutions: 249

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

Thanks for the nudge @sbyrd. @UBNT-Mindas let's discuss.
Member
Posts: 177
Registered: ‎02-15-2008
Kudos: 17
Solutions: 2

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

We are seeing this exact issue as well.  No SSH HTTP/HTTPS on CPE's with public IP's.  Most customers radios are set up in router mode with no management VLAN.  I have dropped TCP/UDP 10001 at our edge also along with telnet and ssh and still seeing the problem.  We are using 2.1.1-Beta AirControl to monitor.  Most firmwares are current (doesn't seem to matter).  We have legacy B/G stuff that never is effected seems to be N and AC radios that display this behavior.  Customers that are effected still have internet but we have no management access.  We have also tried logging into radio from customers LAN side with same results. I would like to add that the 2 that we restarted today (power cycle) when they came back they got a new public IP address which doesn't normally happen (keep in mind they have had internet the entire time).  This leads me to believe there is something happening with DHCP client.

 

Anybody have any ideas on this one? 

There are 10 types of people in the world, those who understand binary and those who don't.
Senior Member
Posts: 2,978
Registered: ‎07-17-2010
Kudos: 667
Solutions: 167

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

Ubiquiti Employee
Posts: 8,674
Registered: ‎04-14-2017
Kudos: 1633
Solutions: 249

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

We are looking into this one.
Veteran Member
Posts: 5,448
Registered: ‎07-03-2008
Kudos: 1709
Solutions: 134

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs


@UBNT-Mindas wrote:

Our kernel version is quite new to support that. Adding @UBNT-SNK for a discussion on this feature: multiple routing table support for mgmt and client traffic separation.


AFAIK this (assuming you mean VRF) is dependent on a v4 kernel (likely v4.14, assuming you want to avoid dealing with network namespaces).  It would be fantastic to have this on both EdgeOS and airOS.

SuperUser
Posts: 5,797
Registered: ‎08-26-2009
Kudos: 1771
Solutions: 55

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

++

Ubiquiti Employee
Posts: 588
Registered: ‎12-21-2017
Kudos: 102
Solutions: 16

Re: Possible Exploit - Losing access to SSH and HTTP/HTTPS on CPEs

@MimCom - I meant the "Multiple FIB tables and FIB rules" approach mentioned in the linked article.

 

As I understand this was brought up for mgmt / client traffic separation for IP traffic. However the benefits are still not clear to me, with respect to this case especially. If the port 10001 was accesible to the public the same things would have happened whether the service uses same or different routing table. If mgmt access would be blocked - then the proposed "attack" scenario would be prevented (we are by default blocking mgmt access on WAN port router mode).

Reply