[Problem] Freetz hacked into using ssh on high port. compromised password gets restored after restart

[frater]

I have a Freetz router that has been hacked into using SSH.
After that, the router gets used to attack sites and/or imap accounts.
I kill all the dropbear processes with a foreign IP and hacking stops momentarily, but soon it resumes.
If I change the password it stops.
However.... After a reboot the compromised password gets restored and hacking can continue.

I know these files are involved:

/etc/shadow -> /var/tmp/shadow
/var/tmp/flash/users/shadow

My guess is that the hacker has made sure that the password stays temporary and is not written into /var/flash/freetz.
When I run passwd only the file /var/tmp/shadow changes.
The /var/tmp/flash/users/shadow stays the same. Maybe this is normal. Is it?

I am able to write the password in /var/tmp/flash/users/shadow to a fresh one using nvi.
That will permanently change my password.

The problem that I can't change the password stays however.
I can't change the password permanently with passwd.

Can someone help me to find out how the hacker compromised the router to achieve this?
When is "passwd" supposed to write the new password immediately into flash? I would think this is done immediately.
I don't think the router has been reflashed as all the addons are still there and some of those are custom.
I even monitor the flash version of the router.

 

[JokerGermany]

If you want to find out how they have done this: Go on

If you just want a clear device
Factory Reset => New flash

 

[koyaanisqatsi]

Hello


You have to save freetz User/Password with...

help/howtos/security/user_management – Freetz

freetz.github.io

...modsave flash.

Also keep in mind that passwd ( freetz busybox passwd ) without -a md5 stores only 8 char ( max length ) passwords.

 

[frater]

It turns out that I was under the wrong assumption that "passwd" changes the password permanently.
I need to give a "modsave" after that to make sure the changes are written into flash.

On hindsight this is quite logical as "passwd" is a standard busybox command that is only supposed to handle /etc/shadow which points to a temporary file.
There is no code in that busybox command to write that to flash.
I'm a bit embarrassed that I am a long time Freetz user and never was aware.

BTW... The access hacking of the FB is for real and luckily doesn't get unnoticed as any foreign access gets monitored for years. The password I chose for it was however weak and should never have been used (2nd embarrassment). This will now change.

-- Aktualisiert --

This is what I will now use after I killed the foreign connections.

passwd -a md5 && modsave

Thanks all for this quick reaction

 

[er13]

A couple of hints:

• make sure your authorized_keys file doesn't contain any unknown entries
• disable the password based authentication and use the public key based one instead
• use some non-standard listen port for ssh

and questions:

• are you sure the reason was a week password? what makes you think so?
• which dropbear version do you use / was using at the time you found out you're hacked?

 

[frater]

• make sure your authorized_keys file doesn't contain any unknown entries

I did

• disable the password based authentication and use the public key based one instead

I know I should, but it makes it so easy to use whenever the key is not available. I should consider this as a wake-up call

• use some non-standard listen port for ssh

It is on a non-standard port,

and questions:

• are you sure the reason was a week password? what makes you think so?

Not 100% sure...

I have several reasons for this. First of all the password is weak. I am aware of the security issues of it, but I also need to convince others. This has happened now.
I can see it's an automated procedure after the password is changed and I monitor the output of "netstat -anp | grep dropbear". I can then see the process with the connection to my IP and then 2 connections on a foreign IP (sometimes Vietnam, France or Russia) for which the process number changes all the time. The latter means that they are kicked by dropbear.
On all my Linux servers I have a brute force protection in iptables using "recent", but I wouldn't know how to accomplish it with this firewall.
For years all my Freetz boxes are monitored by Zabbix. Whenever someone is connected to eithers SSH, Freetz or the AVM-interface from the Internet with the exception of a short-list I will get a message on my dashboard.
This never happened before, which means no-one didn't even connect to the obfuscated ports. Last Friday it started and not only on 1 box, but on more than 50 boxes.
After stopping it on 4 or 5 boxes it would start on 4 others a few hours later.

This has now stopped with the exception of 2 boxes where I killed dropbear completely as they kept on hammering.
I will turn it on later to see if they try again.

• which dropbear version do you use / was using at the time you found out you're hacked?

Dropbear v2017.75
Is there an issue with dropbear I should be concerned about?

 

[er13]

Is there an issue with dropbear I should be concerned about?

Check the Changelog and the CVE-DB. I however don't see anything what would explain that it started happening on more than 50 boxes at the same time. Are all boxes somehow connected with each other? E.g. via VPN? Or are they just monitored from the same server? If the latter then I could imagine that the monitoring server might have been hacked.