-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SECURITY] SSH exposed with root:root
#198
Comments
It's also worth mentioning that you should never, never put devices like a KVM with open, unfiltered inbound connectivity. This includes cameras, printers, and just about every other device you would connect to a network. |
Ooh, this is bad, my router gives global ipv6 to all devices, if my ISP gives me a /64, which they do since a year or so...
Creating the sysctl.conf with those 2 lines disabled all ipv6 functionality on my nanoKVM, lets hope I'm not part of botnet allready. |
On IPv6 it's not that big deal. The address space is so big that scanning it without hints (DNS...) is practically impossible. But this change nothing on that you should have properly setup ipv6 FW on your router. |
You are absolutely correct, no internal system should be visible through the firewall of my router. But ISP provided routers frequently come with suboptimal defaults. Other users might wan't to:
|
No network device should come with unmentioned remote control function which is accessible using widely well-known credentials. Blaming the user for not treating the device as a threat out of the box is not an rational answer, especially for IP-KVM, which is made to be externally accessible. The device should follow IoT Device Security Specification 1.0 (PDF). Please refrain from commenting in this issue. This ticket is for manufacturer, not for discussion. The first post already has a workaround for the user. At least as of firmware v1.3.0, the device does not assign global IPv6, because it's a router #197, which disables Router Advertisement by default. |
Come on mate, back up a bit.... anybody placing an IP-KVM - no matter the vendor - on a publicly accessible, none filtered connection has already violated so many best practices, the username and password are so far down the list to not matter...
A KVM is not an IoT device. Unless you're going to extend the definition of IoT to include just about anything that can connect to a network.
I don't think you get to dictate the input on a public forum. |
I'm not a network savvy (especially ipv6) , but does this mean whoever observes a packet to the firmware update server can just look at the source ipv6 address and ssh into it? |
No. What it means is that if you have the device open to the internet with no firewall on any router etc, that if you don't manually change the password, people would be able to log in with the default username and password. This is the same on both IPv4 and IPv6 networks. |
just turn it off by default, this shouldn't be a debate |
Changing of root's password should be enforced by GUI, like it is with admin's password. Additionally SSH should be disabled by default and there should be GUI option to enable it. Leaving SSH enabled with direct root access enabled via SSH and simple root's password is extremely bad practice, even for home environments. |
I think it's a bit more complicated. A weak root login may be useful for factory reset using UART/TTL. In this case, SSH login for root should be disabled by default. In addition, the web application is currently running as root, too. So this is another issue that needs to be addressed. This is also true for the serial console. Binding to port 80 can be achieved without root with CAP_NET_BIND_SERVICE or iptables just to name two options. It would be nice if the whole distro (buildroot project) would be open sourced, so we could provide pull requests or build our own firmware. |
Weak root login over physical serial console (only) to allow reset of admin's password would be fine - it would require physical access to device to leverage such 'vulnerability'. But device has so little configurable options that resetting forgotten admin's password via just wiping off all settings via reset to factory defaults (or even by reflashing SD card) would also be an acceptable option here. Giving 'easy' root access over network just to allow reset of admin's password via network is just a big security hole. The device is great because it works and is cheap but from security point of view there's still a lot to be done to make it usable beyond expierimental/lab environments. |
@klosz007 don't forget the huge amount of closed source binary blobs that nobody can audit. |
And it wouldn't matter a global ipv6 does not mean it is on the net. You still have to allow your firewall to allow traffic through. |
This seems to be a little bit mitigated with the 2.1.4 version of the application d7ca7c4 sshd is still running, root can still login, but changing the user password via the GUI also change the root password. |
Let's call it fixed then, although I'd prefer the checkbox do disable ssh as well. |
So it's still a root-shell with a default password. People don't know about it and there is no explicit password setting to activate it? lol |
It's certainly not fixed. If you do not manually change the password or have not changed it yet, logging in with root:root will still work. It also doesn't enforce password changes on first login, it's just a suggestion which you can ignore. |
Let's tag @Z2Z-GuGu then, he's responsible for firmware releases as far as I understand. |
https://www.youtube.com/watch?v=plJGZQ35Q6I analyzes all issues with the current firmware. |
Pinged Sipeed on Twitter once again. |
@wj-xiao ^^^ |
yup that's me |
In the latest version, users will be prompted to change the default password. In the next version, SSH will be disabled by default. And users can enable or disable SSH through the web ui. |
NanoKVM v1.3.0 image (20241120_NanoKVM_Rev1_3_0.img.xz) comes with SSH server which accepts connections from everywhere with
root:root
credentials.This will result in a network breach in a matter of 15 minutes if anyone connect NanoKVM to the internet with a dedicated IPv4 address.
Moreover, when IP routing is disabled, the device assigns global IPv6 address in IPv6-enabled networks, which is used for NTP requests, and may expose the device to rogue NTP servers: Using IPv6 with Linux? You’ve likely been visited by Shodan and other scanners.
Such setup is very common for residential networks (contrary to dedicated IPv4), and may result in a network breach on a large scale.
Mitigations
Please follow IoT Device Security Specification 1.0 (PDF) to learn more about IoT device security best practices, design and checklists
root
credential, but generate unique strong root password and show it on OLED display when SSH checkbox is enabledWorkaround
root:root
passwd
commandThe text was updated successfully, but these errors were encountered: