Weak protection for a root shell - Disable Root Shell in Admin-UI

[hb9fxq]

The idea to have access to the system console in the /admin area, protected by just a password sets the entire networkt at serious risk.

Is there a way to disable the root shell in the Admin GUI or to prevent access to /admin at all? In a well protected network envirnoment, there is no way to expose a device to the public, that allows to root access a shell, protected by just a password.

[laemmy]

I have the same Problem. I could setup a Reverse Proxy, but that is more overhead.

[hb9fxq]

maybe the most ugly, but working solution would be a persistent iptables rule like:
iptables -I INPUT 1 -m string --algo bm --string "/admin" -j DROP on the beagle - remember to apply the same for IPv6....

[jks-prv]

Just set the admin password blank. A message in the entry field then says "No password set: no admin access from Internet allowed"

You'll still be able to connect to /admin from the local network ("local" meaning from the same subnet). The "admin auto-login" switch only applies when a password is set. It is meant to require a password be used if the connection is local. Like if you're in some sort of shared computer-use environment.

Now if what you want is admin access from the Internet, but just the console disabled, that's more complicated. That means a new option is required that is only settable from a local admin connection. And there is no concept of that the way the code is currently written.

The admin log tab and then console tab were added after increasing support problems. It was becoming impossible to talk certain non-*nix savvy customers through the process of using shell commands and forwarding log files to find problems. Problems that were often not related to the Kiwi server software itself.

[hb9fxq]

I've gone through the code and understood your idea of protecting the admin WS conn. I have not put it under heavy tests yet, but I fear a possible privilege escalation over HTTP/WS - maybe caused by a leak / overflow in that embedded webserver it is built upon. Without the console there wouldn't be so much damage possible.... easily, but with that root console via WS commands it is a bit scary. For now I'll go with the IPTables way and disable IPv6 until I've tested myself. Maybe I'll simply not put it online.

What I have to criticise that these devices usually run without TLS and the password ist not even hashed! Cleartext + then stored in the session cookie. So many anti-patterns at once make it an InternetOfTarget device of first class. Terminal access is supposed to be put behind SSH, even better with enforced key auth. A DumpLogsCallHome() function would maybe solve that debugging thing also!?

The argument with that non-*nix savvy customers is very weak. I guess these kind of arguments transforms all that IoT stuff into botnets and open doors to more heavy network infrastructure.

[hb9fxq]

Thx, @jks-prv for takting these points into account. I see cdf3623 looks like a good step towards a better security. ThumbsUp!

[hb9fxq]

Thx @jks-prv for the update, the rx is now online @http://kiwisdr.hamspirit.de:8073/
Consider the issue as resolved :-) https://twitter.com/HB9FXQ/status/924376781309796353

[HocusLocus]

krippendorf:

maybe the most ugly, but working solution would be a persistent iptables rule like:
iptables -I INPUT 1 -m string --algo bm --string "/admin" -j DROP
on the beagle - remember to apply the same for IPv6....

BEWARE of raw string matching the text portion of URLs on the packet/stream level! There is a convention where even displayable characters can be substituted by %xx character entities. Too many permutations for explicit matching. The following will all be interpreted as "/admin" and will sail past that filter,

/%61dmin
/a%64min
...
/%61%64%6d%69%6e