[SECURITY] SSH exposed with `root:root`
Opened this issue · 10 comments
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.
# ss -nlpt | grep 22
LISTEN 0 0 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=470,fd=3))
LISTEN 0 0 *:22 *:* users:(("sshd",pid=470,fd=4))
# iptables -vnL INPUT
Chain INPUT (policy ACCEPT 3183 packets, 607K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
0 0 ACCEPT 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 state ESTABLISHED
# ip6tables -vnL INPUT
Chain INPUT (policy ACCEPT 362 packets, 33994 bytes)
pkts bytes target prot opt in out source destination
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
- Disable SSH daemon by default, enable it with a checkbox in web interface settings, which are available only after authentication
- Accept connections only from LAN ranges for both IPv4 and IPv6 by default, accept from everywhere with additional checkbox in the settings
- Do not use hardcoded
rootcredential, but generate unique strong root password and show it on OLED display when SSH checkbox is enabled
Workaround
- Login via SSH as
root:root - Set different root password with
passwdcommand
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...
Tried to access the ipv6 of nanoKVM, root:root got me in. No clue how many bots accessed before me...
# cat /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
Creating the sysctl.conf with those 2 lines disabled all ipv6 functionality on my nanoKVM, lets hope I'm not part of botnet allready.
No clue how many bots accessed before me...
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:
- check their ipv6 connectivity
- change the root password
- set up ssh keys for access as root
- and disable logins with password.
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.
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.
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...
The device should follow IoT Device Security Specification 1.0 (PDF).
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.
Please refrain from commenting in this issue. This ticket is for manufacturer, not for discussion.
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?
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.
At current state, from security perspective, this device is just a joke and usable only at home labs (and even this after some basic hardening).