Skip to content
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

Open
ValdikSS opened this issue Dec 9, 2024 · 10 comments
Open

[SECURITY] SSH exposed with root:root #198

ValdikSS opened this issue Dec 9, 2024 · 10 comments

Comments

@ValdikSS
Copy link

ValdikSS commented Dec 9, 2024

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

  1. Disable SSH daemon by default, enable it with a checkbox in web interface settings, which are available only after authentication
  2. Accept connections only from LAN ranges for both IPv4 and IPv6 by default, accept from everywhere with additional checkbox in the settings
  3. Do not use hardcoded root credential, but generate unique strong root password and show it on OLED display when SSH checkbox is enabled

Workaround

  1. Login via SSH as root:root
  2. Set different root password with passwd command
@CRCinAU
Copy link

CRCinAU commented Dec 12, 2024

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.

@schlypel
Copy link

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.

@Michal4K
Copy link

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.

@schlypel
Copy link

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.

@ValdikSS
Copy link
Author

ValdikSS commented Dec 13, 2024

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.

@CRCinAU
Copy link

CRCinAU commented Dec 13, 2024

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.

@taitix
Copy link

taitix commented Dec 13, 2024

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?

@CRCinAU
Copy link

CRCinAU commented Dec 13, 2024

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.

@ZeChArtiahSaher
Copy link

just turn it off by default, this shouldn't be a debate

@klosz007
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants