I assume they didn't intend to put a mic on the KVM product, but they wanted to make a KVM product, already had this SBC product, which reusing their existing stock of helped keep cost low.
Should they have been more up front about it it? Sure, and it's not great that they had a bunch of security issues in the FW anyway, so not exactly great, but "hidden microphone in a Chinese KVM" lets the mind wander
Given it's history I suspect there is nothing malicious going on here, just a Chinesium approach to building something. Security isn't documented so it's made of tissue paper.
It doesn't strike me as that useful to have a hidden microphone in a KVM product as most of the time, they're going to be stuck in server rooms with just lots of fan noise to record.
Far more of an issue would be any kind of keylogger built into the software, which is why it's best to go for devices that support open source software.
You can exfiltrate data from a machine which is not connected to the KVM. A high-security machine may be even air-gapped most of the time, but be physically nearby.
I don’t think too many of these devices will end up in server rooms as opposed to home labs. And the ones that do end up in a datacenter are very unlikely to be allowed to ever reach the internet.
If the microphone was used for exfiltrating data, it would work against random targets that happened to let the KVM connect to the internet, and who have a nearby machine infected with some malware. That kind of non-targeted attack can be damaging but is semi-useless to the attacker.
The KVM just uses a devboard that's also sold separately and just happens to have a microphone, given how cheap the mics are having one extra SKU would probably just cost them more than savings.
Also I wouldn't really consider it "server room" product. Pretty much any new server has KVM, this is more "a hobbyist needing KVM for their home server"
Ultrawideband never caught on because it turns out that the speed of light and sound in air is frequency dependent, so you have to know the distance to the target pretty accurately and then skew the signal to send or receive. (Imagine a phased array antenna but also with a frequency domain to work out as well).
But that doesn’t mean you can’t make it function in a loud server room. The whole point of it is working in and around noise.
It would take an especially perverse mind to keylog using audio on a KVM, though. The KVM basically has access to everything, any secondary spying using a microphone or a camera would provide very little added value.
They mean the K in KVM could trivially have a keylogger. For the computers attached to that KVM. Audio is for logging for computers not attached to the device in question. Which could be up to and including a whole server room save a couple machines.
A long time ago (maybe in the mid-90s) I knew an elderly radio amateur who could not just "copy" CW by ear, but also RTTY. He could also pretty much tell what a teleprinter was printing just by listening to the noises it made, like he'd be facing away from it on the other side of the room reading out entire words from what was coming through.
Apparently in the 50s when he did his National Service he'd been in the Signals but "not in the regiment that's on his papers", make of that what you will.
I have noticed that with PSK modes and particularly PSK31 you can hear "CQ CQ CQ" as a distinctive pattern much in the same way as it is with CW.
IBM spent a fortune developing ATM keypads that - when correctly mounted - had keys that made the exact same noise no matter how you pressed them or how worn they were.
So I don't doubt that someone suitably clever could extract audio from a room and work out what was being typed.
One really-cool way to solve that problem is to embed a 7-segment LED under each keycap. You walk up to the keypad and the 0-9 digits appear in random order. No one can shoulder-surf, look for wear or IR emission from the buttons, or train on the click sounds.
Dell had those on every lab door in the building back in the early 90s. You felt like 007 every time you punched in your access code. I've never seen them anywhere since.
And now days I can't put in my card's pin without 10 overhead cameras aimed at the register area. All the cameras of which are network-connected, video stored persistently, and high res/fidelity enough to here the little beeps as I press the keys, and to know that I've hit the enter because the screen indicates it immediately. But then Dell cared about its own security, and the grocery store doesn't give a single shit about whether my life is ruined by identity theft.
Maybe. They were necessarily very cagey about it back then, but I might have some documentation kicking about in storage. I tended to keep copies of every service manual I could get my hands on back then.
You might be right but I think we cannot assume malice when it could be laziness.
It might be that the exact same board has multiple target audiences and they just rebrand it for different purposes with different pricing.
That said, the microphone is so weirdly positioned that it gets suspicious indeed.
Microphones and LEDs have been used famously for side channel attacks and also to circumvent air gaps. From a Least Power point of view this is troubling.
A lot of the complaints here don't make a lot of sense and read like the author has never used an embedded linux device. The previously reported bugs are more substantial - hardcoded secrets for JWT access and firmware encryption, everything running as root, etc.
However, "Chinese product uses Chinese DNS servers and it's hard to change them" or "no systemd nor apt installed" are totally expected and hardly make it "riddled with security flaws". Same with tcpdump and aircrack being installed - these hardly compromise the security more than having everything run as root.
I would expect most users of this device will not be exposing the web interface externally, and the fact that they ship with Tailscale installed is actually impressive. I can't imagine the lack of CSRF protection will be a vulnerability for 99% of users.
I am curious what the "weird" version of wireguard the author refers to but based on their apparent lack of knowledge on embedded systems in general I would not be shocked to find that it's totally innocuous.
Also what do you really expect for 30€ or 60€ price point? On relatively low volume product. It even doing what is promised is already a good start to me. And that probably tells their priorities. Start from some already working image with wide support for features. And then add the features that are needed in specific use case. And then ship it.
Hanlon's Razor at work; most of the shortfalls described in the article points to incompetence more than malice.
Though I find it strange though, because I would call this the shortcomings of a crowdfunded project, but the author took it as a malicious and planned act to take over target computers and networks.
As far as I remember, some of the botnets are formed by routers that vendors refused to patch, because they're no longer being sold and not profitable to do so.
yeah.. their list of issues speaks more to their lack of experience and understanding of linux and embedded linux devices wrapped in xenophobic nonsense...
> You can start with your iPhone - last year Apple has agreed to pay $95 million to settle a lawsuit alleging that its voice assistant Siri recorded private conversations. They shared the data with third parties and used them for targeted ads. “Unintentionally”, of course! Yes, that Apple, that cares about your privacy so much
the clickbait title makes sense after reading this paragraph
Not really, because the paragraph you quoted was highly misleading. Even the plaintiffs admit that the recordings were caused by accidental activation, not some sort of nefarious conspiracy by Apple. Moreover there's no evidence that Apple "used them for targeted ads", only that they handed over to third party contractors for improving siri.
And Siri promptly got disabled on my wife's iPad because she kept triggering it inadvertently. Something about her accent kept tripping it. (And, in reverse, Alexa will often not trigger when my wife tries. She comes from a tonal language and it creeps into her English extensively.)
I recently discovered a similar concerning security issue with my KVM. In my case it was a pretty standard KVM for multiple machines to share a keyboard, mouse, and screen but also Ethernet. One day while looking at my home network I noticed the KVM had its own IP and was transferring GBs of data everyday. I quickly blocked it from my network. But having used it for a number of months I worried that with screen capture and access to all my input devices, someone could have gotten access to pretty much everything I use. I wasn’t able to figure out if any data was actually being sent off my network and I really didn’t want to put myself in any more risk so I just threw it in an electronics recycling bin. Pretty scary what a network connected KVM could maliciously do.
Shame you threw it away. It would have been useful to collect the traffic with Wireshark and share that with info about the device in a post or a blog for others to investigate and be warned about that brand and model.
Why did you not just login to the device, and switched off "Broadcast to multicast", or changed the destination address?
Edit: Some brands of Network-KVM use this, so that you can control the target device from another device, like e.g. an App on a tablet. That way you don't have to stand next to the target device in the noisy and cold machine room
The KVM didn't have any documentation on anything related to its network interface. I ran a port scan on it but didn't know if there was a way to log into it.
Was the network port bridged to both PCs all the time (as the description makes it sound, or did only the "active" PC get a functioning network connection?
Could you tell from the FDB of the upstream device, if there were more than two MAC addresses active on the port?
Did you (hopefully) open it up and make PCB pictures before chucking it?
The network was active for both machines connected to it. And it had its own IP. So 3 MAC addresses in total. I didn't ever open it up. But maybe someone will be interested in buying one and exploring more.
This picture from the list of product pictures [0] indicates that the thing acts as an Ethernet bridge. It probably exposes itself as a USB-C gigabit Ethernet device to the machine it's plugged into.
Page four of TFM [1] supports this theory.
Also, this functionality is called out in the product listing and in the manual. I'm over here laughing my ass off because OP got so frightened by this clearly-documented feature that they immediately threw the thing in the trash, rather than first investigating to see if the source of the network traffic was the machines plugged into the device.
The manual, as OP said, does not offer any explanation, why the device might show up with an additional MAC/IP at the upstream switch port, and which services it might offer. OP sounds knowledgeable enough to be able to exclude the possibility, that the additional MAC/IP could be from one of the PCs, like e.g. when playing with VMs using an internal bridge in the Hypervisor.
Maybe the device has a bigger "cousin" device, that includes "control via APP", and this feature was not properly/fully disabled on this one.
> But what additionally raised red flags was the presence of tcpdump and aircrack - tools commonly used for network packet analysis and wireless security testing. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
Must be another AI slop article. Stop feeding your writings into GPT & co to turn into extra long nonsense.
systemd is so resource hungry that i'm sure they removed it to reduce the RAM bill. Apt... why install apt if the distro has a different means of updating?
2. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
This is purely fear mongering. Even the shell could be a "hacking tool that can be dangerously exploited". Let's remove the shell too.
There are some legitimate complaints in the article, like the use of the same key on all installs. The rest looks more like fear mongering and security theater.
Including the microphone. What were they supposed to do, desolder it manually and add $10 to the price of each device?
I don't see the article complaining that a PiKVM has so many unused peripherals when used as a KVM. To go in the spirit of item #2, the usb ports could be used as "dangerous hacking tools" so you should desolder your usb ports from a Pi used as a KVM, right?
Mics have a pretty standard look, and are hard to miss on the board. It would be more insideous if there were cheap film caps leading into a very expensive ADC. I work with with analogue audio, and it’s very important to design around the noise of cheap caps. They are for all intents and purposes microphones and if you were clever about different caps for different frequencies and good digital processing I have no doubt you could build something with comparable fidelity to some of the cheapers MICs in the vocal range.
Why is there a component on the board that isn't used in the product for any official purpose then? Even if you believe it was an accident and an oversight (which it could have been), you should be upset because it's something that could be pretty serious if you used in your home.
Just because you might claim it's not malicious, doesn't make it not negligence.
A kvm that requires Chinese dns servers? Just the fact it KvM over Ethernet should set off alarm bells from here till next Thursday. I would have a hard time trusting an internet based kvm.
> To summarize: the device is riddled with security flaws, originally shipped with default passwords, communicates with servers in China, comes preinstalled with hacking tools, and even includes a built-in microphone
So like pretty much any BMC out there, just with the benefit that an attacker taking over that thing doesn't have direct access to reflash your bios with a backdoored version?
Any halfway sane person deployed any kind of BMC or networked KVM to a access restricted management VLAN for at least a decade now because all of those things are a big mess, and the impact of them getting owned typically is pretty severe.
I dont see the issue here. Its not like they have not disclosed what board it is based upon. And I do feel like its correct not advertising a mic if you dont have it enabled on this one.
I dont really like nanokvm for being slow with updates and not patching stuff fast enough.
What an amazing device, but also the price is incredible. This kind of device would have been such a game changer 15 to 20 years ago. Thank you for the detailed security analysis. At least the developers are responsive, that does seem like a green flag.
Once I dissected the code of a FDA-approved medical device, Vendys Endothelix. If connected to the internet, the device would covertly send measurement data to a specific email address. The usernames and comments baked in the code suggested Chinese development. I would be curious to know what percentage of our highly sensitive data ends up overseas.
"NanoKVM-Cube hardware is built on the LicheeRV Nano platform. To coordinate production and maintain consistency with the LicheeRV Nano for the SMT project, the hardware retains the display, touch, MIC, and amplifier circuits. To address potential privacy concerns, versions 2.2.6 of the application and 1.4.1 of the firmware and above will remove the relevant drivers. We will also eliminate these components in future productions."
...you need a password to log in onto it to change it. That's hardly unique.
You could say "but they could make random one that is displayed on display!", but they also sell headless version with no display at all so that's not an option
This said wildly inappropriate features included do violate the principle of least user authorization. You expect if your KVM gets hacked your servers are pretty fucked, the problem now is any conversation you had by the KVM is suspect too.
Goes along with 'the S in IOT stands for security'.
No, because the drive circuit for a speaker is the opposite of the circuit for a microphone. The output stage of a speaker amplifier is just that, an output. The only way to record audio from a speaker, which is totally possible, is to have also purposely built an input stage also attached to the speaker. Which at that point you might as well just use a microphone...
I don't know what you mean here, I can plug a speaker into my mic slot and use that to record, just as plugging a mic into the speaker slot gives a (crappy) speaker.
From a hardware point of view I've also noticed that speakers work like poor microphones (and LEDs like poor solar panels / light sensors), but is there any way to actually make this work on most devices without physically changing wiring? If the circuits aren't made to take measurements (or the software can't get at the readings) but only set a voltage on the wires, there wouldn't be a way to (ab)use this. I don't know enough about electronics to know whether this is commonly the case
Not that it's not a good thing to be aware of, but do you have any sort of source for what kinds of devices can have their speakers turned into microphones? Then I'll believe you about the government part
I don’t think they meant literally “any” but more like a device with a speaker could be delivered to you that has a speaker/microphone. Like a Bluetooth speaker you order of the internet. It seems it would probably have to be personally targeted to you, but in that case, there are probably simpler ways.
Many a soundcard supports changing jack "direction". Here's a StackExchange answer from 2012, on how to do it with the GUI tool `hdajackretask` : https://askubuntu.com/a/911961
Any was an exaggeration and less than honest on my part, I apologize. I think the speakers in most smart devices though can because they have the circuitry as another comment mentioned to record the input in reverse via software.
I think most speakers would have that today, most modern speakers. Plain speakers that just take a voltage signal though, probably not. Though how many people use those kinds of speakers today I wonder.
Wow, HN is really desperate for the clickbait today.
(And no! Don't just say this isn't a substantive comment! Do better! This isn't the first ragebait top story that made commenters foam at the mouth today, and thanks to the bullshit asymmetry of AI slop, it's even easier to churn out posts like 'this cheap shitbox SBC lacks systemd but includes tcpdump'.)
To be fair, the microphone _is_ listed on the specsheet of the LicheeRV Nano
https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.h...
I assume they didn't intend to put a mic on the KVM product, but they wanted to make a KVM product, already had this SBC product, which reusing their existing stock of helped keep cost low.
Should they have been more up front about it it? Sure, and it's not great that they had a bunch of security issues in the FW anyway, so not exactly great, but "hidden microphone in a Chinese KVM" lets the mind wander
Given it's history I suspect there is nothing malicious going on here, just a Chinesium approach to building something. Security isn't documented so it's made of tissue paper.
"hidden microphone in a Chinese KVM" is the correct way to describe what is going on.
"Reusing existing stock" is not a valid excuse. They are currently selling this device without advertising that it contains a working microphone.
A working microphone and recording software and hacking tools like aircrack-ng on an otherwise stripped-down OS image...
It doesn't strike me as that useful to have a hidden microphone in a KVM product as most of the time, they're going to be stuck in server rooms with just lots of fan noise to record.
Far more of an issue would be any kind of keylogger built into the software, which is why it's best to go for devices that support open source software.
just fan noise?
https://arxiv.org/abs/1606.05915
Any signal that you can modulate can be an exfiltration channel, and fan noise is no different.
> Any signal that you can modulate can be an exfiltration channel, and fan noise is no different.
This KVM has HDMI input and can directly emulate USB mass storage; fan-modulation is the lowest-bandwidth (side-)channel available to the attackers.
You can exfiltrate data from a machine which is not connected to the KVM. A high-security machine may be even air-gapped most of the time, but be physically nearby.
I don’t think too many of these devices will end up in server rooms as opposed to home labs. And the ones that do end up in a datacenter are very unlikely to be allowed to ever reach the internet.
If the microphone was used for exfiltrating data, it would work against random targets that happened to let the KVM connect to the internet, and who have a nearby machine infected with some malware. That kind of non-targeted attack can be damaging but is semi-useless to the attacker.
I wonder if that's feasible in a room filled with many servers and fans going?
Yes, just modulate the fan noise on the transmitter, and apply a filter on the receiver.
Doesn't being able to modulate the fan presume you already control the target device?
The KVM just uses a devboard that's also sold separately and just happens to have a microphone, given how cheap the mics are having one extra SKU would probably just cost them more than savings.
Also I wouldn't really consider it "server room" product. Pretty much any new server has KVM, this is more "a hobbyist needing KVM for their home server"
Ultrawideband never caught on because it turns out that the speed of light and sound in air is frequency dependent, so you have to know the distance to the target pretty accurately and then skew the signal to send or receive. (Imagine a phased array antenna but also with a frequency domain to work out as well).
But that doesn’t mean you can’t make it function in a loud server room. The whole point of it is working in and around noise.
It is possible to keylog via audio.
https://ieeexplore.ieee.org/abstract/document/10190721
It would take an especially perverse mind to keylog using audio on a KVM, though. The KVM basically has access to everything, any secondary spying using a microphone or a camera would provide very little added value.
Maybe it's for the super secret stuff that the datacenter emergency ops worker knows not to type through the KVM? ;-)
But the point of a device like this is that you (and your keyboard) are NOT physically present.
They mean the K in KVM could trivially have a keylogger. For the computers attached to that KVM. Audio is for logging for computers not attached to the device in question. Which could be up to and including a whole server room save a couple machines.
A long time ago (maybe in the mid-90s) I knew an elderly radio amateur who could not just "copy" CW by ear, but also RTTY. He could also pretty much tell what a teleprinter was printing just by listening to the noises it made, like he'd be facing away from it on the other side of the room reading out entire words from what was coming through.
Apparently in the 50s when he did his National Service he'd been in the Signals but "not in the regiment that's on his papers", make of that what you will.
I have noticed that with PSK modes and particularly PSK31 you can hear "CQ CQ CQ" as a distinctive pattern much in the same way as it is with CW.
IBM spent a fortune developing ATM keypads that - when correctly mounted - had keys that made the exact same noise no matter how you pressed them or how worn they were.
So I don't doubt that someone suitably clever could extract audio from a room and work out what was being typed.
Do you have a pointer to learn more about the ATM keyboards? I would love to learn more about it
One really-cool way to solve that problem is to embed a 7-segment LED under each keycap. You walk up to the keypad and the 0-9 digits appear in random order. No one can shoulder-surf, look for wear or IR emission from the buttons, or train on the click sounds.
Dell had those on every lab door in the building back in the early 90s. You felt like 007 every time you punched in your access code. I've never seen them anywhere since.
And now days I can't put in my card's pin without 10 overhead cameras aimed at the register area. All the cameras of which are network-connected, video stored persistently, and high res/fidelity enough to here the little beeps as I press the keys, and to know that I've hit the enter because the screen indicates it immediately. But then Dell cared about its own security, and the grocery store doesn't give a single shit about whether my life is ruined by identity theft.
Maybe. They were necessarily very cagey about it back then, but I might have some documentation kicking about in storage. I tended to keep copies of every service manual I could get my hands on back then.
The Chinese part makes one think the Chinese could access the microphone.
Nevermind that, if they could access the device, they'd also be able to read your kvm i/o.
You might be right but I think we cannot assume malice when it could be laziness. It might be that the exact same board has multiple target audiences and they just rebrand it for different purposes with different pricing.
That said, the microphone is so weirdly positioned that it gets suspicious indeed.
> I think we cannot assume malice when it could be laziness
If you are too lazy to go back and check if you left the gas on, you bear responsibility if the place explodes.
At the very least, it's negligent to leave something like that in and not be very upfront about it.
> I think we cannot assume malice when it could be laziness
Why can't it be both?
Perception of laziness with an option for later maliciousness and somewhat plausible deniability.
>That said, the microphone is so weirdly positioned that it gets suspicious indeed.
How is it weirdly positioned? To me it seems there is rather few options for such small board.
Microphones and LEDs have been used famously for side channel attacks and also to circumvent air gaps. From a Least Power point of view this is troubling.
And rather than "the Chinese", how about "anyone robo-dialling some SSH connections"?
A lot of the complaints here don't make a lot of sense and read like the author has never used an embedded linux device. The previously reported bugs are more substantial - hardcoded secrets for JWT access and firmware encryption, everything running as root, etc.
However, "Chinese product uses Chinese DNS servers and it's hard to change them" or "no systemd nor apt installed" are totally expected and hardly make it "riddled with security flaws". Same with tcpdump and aircrack being installed - these hardly compromise the security more than having everything run as root.
I would expect most users of this device will not be exposing the web interface externally, and the fact that they ship with Tailscale installed is actually impressive. I can't imagine the lack of CSRF protection will be a vulnerability for 99% of users.
I am curious what the "weird" version of wireguard the author refers to but based on their apparent lack of knowledge on embedded systems in general I would not be shocked to find that it's totally innocuous.
I think you haven't gone far enough. Most of this thread is rampant ignorance and propaganda influenced bandwagoning.
1) It's from a company known for dev boards and SoCs- not consumer products.
2) The code is available on GitHub (nice!)
3) SiSpeed actively contributes to the mainline linux kernel for RISC-V in general as well as their SoCs.
4) Security in Embedded Applications is just... Bad. Amercian, Chinese, European, Russian, Indian- it doesn't matter.
Also what do you really expect for 30€ or 60€ price point? On relatively low volume product. It even doing what is promised is already a good start to me. And that probably tells their priorities. Start from some already working image with wide support for features. And then add the features that are needed in specific use case. And then ship it.
Hanlon's Razor at work; most of the shortfalls described in the article points to incompetence more than malice.
Though I find it strange though, because I would call this the shortcomings of a crowdfunded project, but the author took it as a malicious and planned act to take over target computers and networks.
As far as I remember, some of the botnets are formed by routers that vendors refused to patch, because they're no longer being sold and not profitable to do so.
yeah.. their list of issues speaks more to their lack of experience and understanding of linux and embedded linux devices wrapped in xenophobic nonsense...
> You can start with your iPhone - last year Apple has agreed to pay $95 million to settle a lawsuit alleging that its voice assistant Siri recorded private conversations. They shared the data with third parties and used them for targeted ads. “Unintentionally”, of course! Yes, that Apple, that cares about your privacy so much
the clickbait title makes sense after reading this paragraph
Not really, because the paragraph you quoted was highly misleading. Even the plaintiffs admit that the recordings were caused by accidental activation, not some sort of nefarious conspiracy by Apple. Moreover there's no evidence that Apple "used them for targeted ads", only that they handed over to third party contractors for improving siri.
And Siri promptly got disabled on my wife's iPad because she kept triggering it inadvertently. Something about her accent kept tripping it. (And, in reverse, Alexa will often not trigger when my wife tries. She comes from a tonal language and it creeps into her English extensively.)
I recently discovered a similar concerning security issue with my KVM. In my case it was a pretty standard KVM for multiple machines to share a keyboard, mouse, and screen but also Ethernet. One day while looking at my home network I noticed the KVM had its own IP and was transferring GBs of data everyday. I quickly blocked it from my network. But having used it for a number of months I worried that with screen capture and access to all my input devices, someone could have gotten access to pretty much everything I use. I wasn’t able to figure out if any data was actually being sent off my network and I really didn’t want to put myself in any more risk so I just threw it in an electronics recycling bin. Pretty scary what a network connected KVM could maliciously do.
Shame you threw it away. It would have been useful to collect the traffic with Wireshark and share that with info about the device in a post or a blog for others to investigate and be warned about that brand and model.
Why did you not just login to the device, and switched off "Broadcast to multicast", or changed the destination address?
Edit: Some brands of Network-KVM use this, so that you can control the target device from another device, like e.g. an App on a tablet. That way you don't have to stand next to the target device in the noisy and cold machine room
The KVM didn't have any documentation on anything related to its network interface. I ran a port scan on it but didn't know if there was a way to log into it.
> The KVM didn't have any documentation on anything related to its network interface.
My research disagrees. See [0]
[0] <https://news.ycombinator.com/item?id=46177462>
Is it possible for you to name the KVM model?
It sounds like a potential risk is to the public.
It is this one: https://www.amazon.com/dp/B0CP4PD3SM
I did post a review there citing my security concerns.
Honestly I didn't go further with the investigation because if someone really has all my data, I'm worried about retribution.
Was the network port bridged to both PCs all the time (as the description makes it sound, or did only the "active" PC get a functioning network connection? Could you tell from the FDB of the upstream device, if there were more than two MAC addresses active on the port? Did you (hopefully) open it up and make PCB pictures before chucking it?
The network was active for both machines connected to it. And it had its own IP. So 3 MAC addresses in total. I didn't ever open it up. But maybe someone will be interested in buying one and exploring more.
This picture from the list of product pictures [0] indicates that the thing acts as an Ethernet bridge. It probably exposes itself as a USB-C gigabit Ethernet device to the machine it's plugged into.
Page four of TFM [1] supports this theory.
Also, this functionality is called out in the product listing and in the manual. I'm over here laughing my ass off because OP got so frightened by this clearly-documented feature that they immediately threw the thing in the trash, rather than first investigating to see if the source of the network traffic was the machines plugged into the device.
[0] <https://m.media-amazon.com/images/I/71GglDmzCYL._SL1500_.jpg> (If this direct link fails, it's the image that has the header "A Stable Gigabit Ethernet Port".
[1] <https://avaccess.com/wp-content/uploads/2024/01/UM-_-iDock-C...> (This is the "DOWNLOAD USER MANUAL" link in the Downloads subsection of the More Information section of [2])
[2] <https://www.avaccess.com/products/idock-c20-kvm-switch-docki...>
The manual, as OP said, does not offer any explanation, why the device might show up with an additional MAC/IP at the upstream switch port, and which services it might offer. OP sounds knowledgeable enough to be able to exclude the possibility, that the additional MAC/IP could be from one of the PCs, like e.g. when playing with VMs using an internal bridge in the Hypervisor.
Maybe the device has a bigger "cousin" device, that includes "control via APP", and this feature was not properly/fully disabled on this one.
> [...] and runs a heavily stripped-down version of Linux that lacks systemd and apt. And these are just a few of the issues.
?!
Presumably Alpine. I bet it doesn't run GNOME either. And these are just a few of the issues!
Lacking software (apt) is a security issue. Having software installed (tcpdump) is also a security issue.
I don’t see this as noteworthy myself. It’s expected on a small embedded device such as this. You’re usually lucky to have busybox.
> But what additionally raised red flags was the presence of tcpdump and aircrack - tools commonly used for network packet analysis and wireless security testing. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
Must be another AI slop article. Stop feeding your writings into GPT & co to turn into extra long nonsense.
What was wrong with the above paragraph?
Let's see:
1. It lacks systemd and apt.
systemd is so resource hungry that i'm sure they removed it to reduce the RAM bill. Apt... why install apt if the distro has a different means of updating?
2. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
This is purely fear mongering. Even the shell could be a "hacking tool that can be dangerously exploited". Let's remove the shell too.
There are some legitimate complaints in the article, like the use of the same key on all installs. The rest looks more like fear mongering and security theater.
Including the microphone. What were they supposed to do, desolder it manually and add $10 to the price of each device?
I don't see the article complaining that a PiKVM has so many unused peripherals when used as a KVM. To go in the spirit of item #2, the usb ports could be used as "dangerous hacking tools" so you should desolder your usb ports from a Pi used as a KVM, right?
Cat is a hacking tool cause you can see the contents of /proc/kcore?
Cp is a hacktool cause bad files can be copied?
Grep is a hacktool cause only monster hackers use regex?
(This is obvious sarcasm)
Heck, everybody knows Linux is a hacker OS…
Hey I didn't think of that. They forgot to complain that the device doesn't use a properly licensed OS that they certified secure!
Absolutely with systemd and apt. Like apt couldn't be used to install "hacking tools".
Mics have a pretty standard look, and are hard to miss on the board. It would be more insideous if there were cheap film caps leading into a very expensive ADC. I work with with analogue audio, and it’s very important to design around the noise of cheap caps. They are for all intents and purposes microphones and if you were clever about different caps for different frequencies and good digital processing I have no doubt you could build something with comparable fidelity to some of the cheapers MICs in the vocal range.
Why is there a component on the board that isn't used in the product for any official purpose then? Even if you believe it was an accident and an oversight (which it could have been), you should be upset because it's something that could be pretty serious if you used in your home.
Just because you might claim it's not malicious, doesn't make it not negligence.
A kvm that requires Chinese dns servers? Just the fact it KvM over Ethernet should set off alarm bells from here till next Thursday. I would have a hard time trusting an internet based kvm.
Should I really be more trusting of some NSA controlled DNS server?
Yes. Hahaha. Of course not. Or maybe?? No, just kidding. But am i?
wait till you find out about iLO/iDRAC or vPro
> [It] runs a heavily stripped-down version of Linux that lacks systemd and apt. And these are just a few of the issues.
You mean it's not Debian-based? How is this an issue?
This is… not news. The base board has always had a microphone, the NanoKVM was just built around that base board.
> To summarize: the device is riddled with security flaws, originally shipped with default passwords, communicates with servers in China, comes preinstalled with hacking tools, and even includes a built-in microphone
So like pretty much any BMC out there, just with the benefit that an attacker taking over that thing doesn't have direct access to reflash your bios with a backdoored version?
Any halfway sane person deployed any kind of BMC or networked KVM to a access restricted management VLAN for at least a decade now because all of those things are a big mess, and the impact of them getting owned typically is pretty severe.
I dont see the issue here. Its not like they have not disclosed what board it is based upon. And I do feel like its correct not advertising a mic if you dont have it enabled on this one.
I dont really like nanokvm for being slow with updates and not patching stuff fast enough.
What an amazing device, but also the price is incredible. This kind of device would have been such a game changer 15 to 20 years ago. Thank you for the detailed security analysis. At least the developers are responsive, that does seem like a green flag.
Whoa I have a bunch of these.
But I never trusted them in the first place so they don't have internet access anyway. They're on a separate subnet. It'll be fine.
Also where my servers are there's nothing interesting to hear except more servers and 3D printers.
Once I dissected the code of a FDA-approved medical device, Vendys Endothelix. If connected to the internet, the device would covertly send measurement data to a specific email address. The usernames and comments baked in the code suggested Chinese development. I would be curious to know what percentage of our highly sensitive data ends up overseas.
I think it's safe (or maybe prudent) to assume that pretty much all phones, computers, and network switching gear are backdoored by someone.
https://wiki.sipeed.com/hardware/en/kvm/NanoKVM/introduction...
Probably an older NanoKVM.
"NanoKVM-Cube hardware is built on the LicheeRV Nano platform. To coordinate production and maintain consistency with the LicheeRV Nano for the SMT project, the hardware retains the display, touch, MIC, and amplifier circuits. To address potential privacy concerns, versions 2.2.6 of the application and 1.4.1 of the firmware and above will remove the relevant drivers. We will also eliminate these components in future productions."
Gotta be careful about them hidden microphones, they could be listening and recording all the keyboard clicks and translating them to the device.
> The device initially came with a default password, and SSH access was enabled using this preset password
That alone ends my trust in the brand.
...you need a password to log in onto it to change it. That's hardly unique.
You could say "but they could make random one that is displayed on display!", but they also sell headless version with no display at all so that's not an option
Anyone got a link to some community work on the open source side? Sounds like useful devices, if you fix the issues mentioned.
You are using a KVM. When not trusting the manufacturer a microphone is the least of your problems xD
This said wildly inappropriate features included do violate the principle of least user authorization. You expect if your KVM gets hacked your servers are pretty fucked, the problem now is any conversation you had by the KVM is suspect too.
Goes along with 'the S in IOT stands for security'.
If someone hacks your KVM, I’m thinking the onboard microphone is the least of your problems.
is there a recording sample to hear the quality?
Such a cool device.
Is it possible to buy something like this which is intended to be user installable for Linux that I could test/mess around with?
The device is based on linux devboard so... yes
any speaker can be tapped into as a microphone by a motivated government.
No, because the drive circuit for a speaker is the opposite of the circuit for a microphone. The output stage of a speaker amplifier is just that, an output. The only way to record audio from a speaker, which is totally possible, is to have also purposely built an input stage also attached to the speaker. Which at that point you might as well just use a microphone...
Audio input and output are not reversible.
I don't know what you mean here, I can plug a speaker into my mic slot and use that to record, just as plugging a mic into the speaker slot gives a (crappy) speaker.
> purposely built input stage
You moved your device to the purposely built input stage.
Not an expert, but your remark doesn’t compute with the parent comment
A DAC and amplifier circuit is electrically incapable of processing input (on its own.)
Physically unplugging and moving a speaker to a mic input works, sure, but very few devices can do this switching electronically.
Because on your computer the engineers purposely put a switch that can direct the signal to either the input hardware or the output hardware.
It's not a mic slot, it's a general analog I/O port with a 3.5mm form factor.
on many cards they are, check out the tool `hdajackretask` from package `alsa-gui-tools`.
From a hardware point of view I've also noticed that speakers work like poor microphones (and LEDs like poor solar panels / light sensors), but is there any way to actually make this work on most devices without physically changing wiring? If the circuits aren't made to take measurements (or the software can't get at the readings) but only set a voltage on the wires, there wouldn't be a way to (ab)use this. I don't know enough about electronics to know whether this is commonly the case
Not that it's not a good thing to be aware of, but do you have any sort of source for what kinds of devices can have their speakers turned into microphones? Then I'll believe you about the government part
I don’t think they meant literally “any” but more like a device with a speaker could be delivered to you that has a speaker/microphone. Like a Bluetooth speaker you order of the internet. It seems it would probably have to be personally targeted to you, but in that case, there are probably simpler ways.
Many a soundcard supports changing jack "direction". Here's a StackExchange answer from 2012, on how to do it with the GUI tool `hdajackretask` : https://askubuntu.com/a/911961
Any was an exaggeration and less than honest on my part, I apologize. I think the speakers in most smart devices though can because they have the circuitry as another comment mentioned to record the input in reverse via software.
I think most speakers would have that today, most modern speakers. Plain speakers that just take a voltage signal though, probably not. Though how many people use those kinds of speakers today I wonder.
[flagged]
Wow, HN is really desperate for the clickbait today.
(And no! Don't just say this isn't a substantive comment! Do better! This isn't the first ragebait top story that made commenters foam at the mouth today, and thanks to the bullshit asymmetry of AI slop, it's even easier to churn out posts like 'this cheap shitbox SBC lacks systemd but includes tcpdump'.)