Upcoming Maintenance Alert:

The UBNT Community will be upgraded at 5pm MDT on April 25th. During this time the community forums will be set to read-only status.

Learn more

×
Reply
New Member
Posts: 3
Registered: ‎06-10-2015

Re: Possible new virus - august 2016

To make thing more dificult to malware in general, I intent to setup every device in my network to only accept input connections from a few servers that I generally use to manage them. This is similar to what the malware did. However, I need to make things permament.

 

How can I do that?

 

I would like to do everything using SSH commands, because I can use a program (in my case a pyhon program) to execute the SSH commands in all devices.

 

At first, I will apply the commands manually, check to see if the iptables have been updates correctly (where is the file containig such tables?) and test to see if the device is working normally after making thing permanent and rebooting.

 

Could a more experienced user help me?

 

Thank you very much.

 

One last thing, I also would like to know how to change the password through SSH without prompts (I can only send non iteractive command to several devices at one) and how to change SSH port, HTTP port and HTTPs port using SSH.

 

My plan is to change them to unusual ports and completely block those port in my firewall except if the call are originated from my administrative servers.

 

I cannot block ports 22, 80 and 443 in general because many users use them for various reasons.

 

Thank you again,

 

If I can mount s sucesfull sequence of SSH commands, I will share the script here.

 

   Marcelo

 

 

Established Member
Posts: 1,585
Registered: ‎05-20-2008
Kudos: 385
Solutions: 5

Re: Possible new virus - august 2016

you dont need to block the managment service ports.

Just block the incoming ssh/web/443 destined to your CPE IP addresses

You can do it with a simple rule 

in your main router with Mikrotik

 

Mikrotik> ip firewall filter chain=forward dst-address=10.0.0.0/8 dst-port=443,22,80 action=drop

 

(given that 10.0.0.0/8 is your CPE address block)

 

Also if you are using switches in between, you will need to isolate the ports from talking to each other except the uplink port to force them go thorough the router first to hit the above rule. Check Port Isolation in your switch configuration.

 

 

 

 

Emerging Member
Posts: 62
Registered: ‎01-22-2013
Kudos: 19

Re: Possible new virus - august 2016

So, and when you have yet devices in older versions, but this devices is not accessible from anywhere than a management network, one client can contact an other by icmp, with high ports, but any packet incoming on ports 0 to 1024 is dropped unless that came from one single IP used from our NOC.

 

With this security rules, we did think that we are safe, but unfortunately this not right.

 

We have seen that a number of devices have been infected, and this number is higher every day. The problem is that until days ago, we can acess the login page of infected devices, but like was said before, we can not access them, and no username/password error is reported by GUI interface, just a page refresh and asking for login again. Using SSH we can try access on port 32700, but no username/password that we tryed works.

 

Asking to client to reboot the device resulting in nothing.

 

Today we see same devices that GUI is inaccessible, and port 32700 are no more used to SSH (we not discovered yet to what port is used to ssh on these devices).

 

I just have 2 simple questions:
1 - How our devices was getting infected considering the rules that we use to prevent unwanted access?
2 - How we can recover these devices, without need to go on all client house and do the manual process of reset the device, update and reconfigure them?

 

Please, any help is very welcome!!!!

New Member
Posts: 1
Registered: ‎08-27-2016
Kudos: 1

Re: Possible new virus - august 2016


marcioelias wrote:

So, and when you have yet devices in older versions, but this devices is not accessible from anywhere than a management network, one client can contact an other by icmp, with high ports, but any packet incoming on ports 0 to 1024 is dropped unless that came from one single IP used from our NOC.

 

With this security rules, we did think that we are safe, but unfortunately this not right.



 

Devices don't get hacked on their own, so somehow someone is getting access to your management ports. Assuming your firewall rules are as you described (without any configuration mistakes) and survive reboots etc. then the first thing that comes to mind is upnp. Is it possible it's enabled and accessible to untrusted clients? There's a lot of radios out there with upnp enabled, listening on the public radio IP, and allowing malicious rerouting of traffic to and from private IP space. Unless you desperately need upnp you should disable it. My gut instinct is that it might even be possible for a malicious client on a wlan to get access to your private management ports via upnp in some circumstances. If upnp is running and you don't need it, don't just firewall it. Please get rid of it altogether.

 

Also, do you by any chance use the same login / password for all your devices? This is a very bad idea in general and thanks to the MF worm tens of thousands of Ubiquiti device login / passwords have leaked and are now actively being compromised. Password-reusing ISPs should at the very least change their passwords now. Ideally they should also think of ways to stop reusing the same login/password on devices (i.e. either use unique credentials for every device or migrate to a ssh pubkey setup).

 

Sorry for the rant, but the situation isn't good..

Emerging Member
Posts: 62
Registered: ‎01-22-2013
Kudos: 19

Re: Possible new virus - august 2016

[ Edited ]

Hello, no need to apologies.

 

So, the problem is that infected devices is not accessible any way than reseting to default configuration.

 

About upnp is a good question, I believe that some devices in deed has this feature enabled, but not all.

 

In this network segment that has been afected, 99% os devices is behind NAT with private ip address, and when this situation came up the first thing that I did has access one client device and try to any means gain access to an other device, and all ports from 0 to 1024 are closed.

 

About port isolation on l2 devices, in fact is not enabled for all segments, but for using this, the only thing that came to my mind is access from l2, but for do this the access should be made from mac address, once that every client has a /32 and for any IP communication will need l3 access.

 

Unless that the infection is changing the IP address received from PPPoE connection and making this a /24 for instance.

 

About passwords, yes, all devices has same credentials, but even on MF event, this segmento of our network do not have been afected, due these rules of security, so why now? And one mass password change has applied after MF infections.

New Member
Posts: 12
Registered: ‎04-30-2012

Re: Possible new virus - august 2016

Pretty same problem here:

 

only few CPE, which had SSH port reachable on public IP due to Customer request have been affected from this new virus.

 

The virus renamed the device with name UBNT, blocked SSH connection, HTTP works, but password has been changed.

The read-only account has been enabled with user and pass ubnt / ubnt

 

The virus doesn't disappear after reboot.

 

Every CPE was with 5.6.6 or newer FW, that was supposed to be safe.

Luckily we have public IP CPEs management port not exposed to internet, but however is an annoying thing to go to the customer and restore settings via TFTP.

 

What should we do otherwise?

Isn't these newer FWs secure?

Ubiquiti Employee
Posts: 8,465
Registered: ‎11-27-2012
Kudos: 2330
Solutions: 534
Contributions: 73

Re: Possible new virus - august 2016

I would advise changing the password on any unit that has seen this.   It would also be a good idea to change the username to something non-standard as well.

 

@davzar  Are you running the -cs (custom script) version of 5.6.9?

New Member
Posts: 12
Registered: ‎04-30-2012

Re: Possible new virus - august 2016

@UBNT-JamesCPE affected have 5.6.6 and 5.6.8 FW without custom script capability

Ubiquiti Employee
Posts: 8,465
Registered: ‎11-27-2012
Kudos: 2330
Solutions: 534
Contributions: 73

Re: Possible new virus - august 2016


davzar wrote:

@UBNT-JamesCPE affected have 5.6.6 and 5.6.8 FW without custom script capability


There are a few different variants going around.  Some users are reporting that rebooting the radio will restore access.  In those cases, it looks like the worm is trying to save to the persistent partition, but not the system.cfg.  In other cases, we have seen it change the user/password in system.cfg.  In those cases, a reset will most likely be in order.

New Member
Posts: 12
Registered: ‎04-30-2012

Re: Possible new virus - august 2016

@UBNT-James I've tried normal reset and it didn't work, so i guess that the only way is TFTP recovery.

 

Is it impossible to use the same exploit for making a cure for this worm?

Emerging Member
Posts: 66
Registered: ‎08-30-2010
Kudos: 12
Solutions: 4

Re: Possible new virus - august 2016

I have to ask again. Are we safe with fw 5.6.2+ ??

 

Is there a new threat that needs 5.6.9 to be safe from?

 

Established Member
Posts: 1,274
Registered: ‎10-05-2014
Kudos: 194
Solutions: 30

Re: Possible new virus - august 2016


UBNT-James wrote:

Since the last outbreak, we removed support for rc.scripts in the version of airOS on downloads.ubnt.com.  A reboot will clear them out (not persistent).  Looks like no permanent changes were made to the config.  


 Not because it is impossible, just they play nice for the moment.

 


UBNT-James wrote:

If possible, block inbound traffic to customer management interfaces. (80/443/22)

 


AndIF we block the access to management port's we will not have to play the "cat-and-mouse" game of constantly pushing new firmware onto production devices, do we?

 

Regards,

Do not expect me to reply to this post, I'm not sure that I will be able to find it, thank's to ....

Ubiquiti Employee
Posts: 5,855
Registered: ‎05-13-2009
Kudos: 1798
Solutions: 167

Re: Possible new virus - august 2016


davzar wrote:

Pretty same problem here:

 

only few CPE, which had SSH port reachable on public IP due to Customer request have been affected from this new virus.

 

The virus renamed the device with name UBNT, blocked SSH connection, HTTP works, but password has been changed.

The read-only account has been enabled with user and pass ubnt / ubnt

 

The virus doesn't disappear after reboot.

 

Every CPE was with 5.6.6 or newer FW, that was supposed to be safe.

Luckily we have public IP CPEs management port not exposed to internet, but however is an annoying thing to go to the customer and restore settings via TFTP.

 

What should we do otherwise?

Isn't these newer FWs secure?


@davzar since only devices with exposed SSH port on public IP were affected, it's either weak username/password were used or SSH server (dropbear) vulnerability which is unknown at the moment...

New Member
Posts: 12
Registered: ‎04-30-2012

Re: Possible new virus - august 2016

@UBNT-EdmundasSSH user&pass were not weak (i.e. we also changed admin username in something unusual, no root, admin, administrator etc).

Established Member
Posts: 1,274
Registered: ‎10-05-2014
Kudos: 194
Solutions: 30

Re: Possible new virus - august 2016


doush wrote:

you dont need to block the managment service ports.


 I have a different opinion here.

 

 


doush wrote:

Just block the incoming ssh/web/443 destined to your CPE IP addresses

You can do it with a simple rule 

in your main router with Mikrotik


 

You don't have to block anything , by default the router(s) don't have forward rules set.

It is the user who create the port forward rule(s) , and the user should disable or delete the port forward.

 

Conclusion:

This devices are "set-and-forget" type, if configured properly should work for years without any touch.

Once the initial configuration is done and tested the internal http server is useless and must be disabled for the following reasons:

  1. Consume resource (CPU, RAM) for no reason at all.
  2. It is a security risk
    • Flaws can be discovered in time.
    • No mechanism to prevent brute force attack.

 Best practice:

  1. Enable SSH Key-Based Authentication.
  2. Test SSH Key-Based Authentication.
  3. Disable SSH  password authentication.
    sshd.auth.passwd=disabled
  4. Disable http server(daemon)
    httpd.status=disabled
    httpd.https.status=disabled
    pkill lighttpd
  5. Enable http on demand only.
  6. Set a different NTP server like pool.ntp.org, will be faster and will not attract "visitors", in my case the local router provide NTP server facility.

 

Regards,

Do not expect me to reply to this post, I'm not sure that I will be able to find it, thank's to ....

Reply