There’s no security vulnerabilities as we’ve responded to your previous post. The robots are not controlled through Telnet. I believe you are confusing the tcp port with the Telnet protocol, which are different things. If for some reason you would like to change the tcp ports, that can be done in the web administration interface of the ezb. View the learn section for more information on using your robot. Have fun!

Thank you for the fast response. I am not referring to the TCP port, but to the options you provide when one telnets to the robot. The menu of options looks like the attached image.

Not sure if someone else brought this up in the past as well, but I did not receive a response to my email dated August 3rd, 2017. If you did send a response and I somehow missed it, I apologize.

The screenshot you displayed is the HELP list from the console on default port 8080. If you wish to disable that feature, do so in the web administration interface of the EZ-B.

Yes, I have listed all the options available to someone connecting to the robot through telnet. What I am trying to convey is that it is a security weakness of the system to allow any telnet user to discover a memdump, change servo speeds, flash the memory map, etc. Do you disagree with this statement?

The fact that I can disable the feature does not improve the security much: the disabled status should have been the default option, not the other way around. I assume that most users of the robot are not aware of these telnet capabilities, let alone disable them.

There is no security risk with the CLI active. Memdump or changing servo speeds are not security vulnerabilities. If you're using the EZ-B in a production environment, i assume you would configure it appropriate to your security requirements. Also, you can connect to the control port of the EZ-B and give it instructions. There's a dozen ways to control an EZ-B, much like I can control your TV if i have a compatible remote control. The best way to protect any device, specifically connected to a public accessible network is with a firewall and wifi password. You can find out more about security and securing devices with Google. have fun

A vulnerability is a weakness in the system (procedures, design or implementation) that might be exploited to cause loss or harm. This is the definition from the Pfleeger and Pfleeger Analyzing Computer Security textbook that I use when I teach college students. The easiness with which someone can control features of someone else’s robot through a well-known insecure application like telnet is by definition a security vulnerability.

There is no perfectly secure system, and I am not advocating that you start shipping products already configured with their own firewall. But there is a difference between excluding security considerations from product design and including some very basic levels of security (like using ssh instead of telnet and introducing authentication mechanisms).

As I said earlier, I am overall impressed by your products. As a cybersecurity researcher, though, I have to point out the cybersecurity risks that you seem to consider nonexistent with the hope that you make improvements in next versions.

Again - there is no security vulnerability. Anyone with the software can connect to an EZ-B within the network. This includes either CLI via telnet or ARC via the EZ-B protocol. There's no design to stop someone from connecting to the controller. If there was a password protected design that could be bypassed by a vulnerability, then it would be a concern. However, there is no username/password authentication built into the firmware. Therefore, there is no vulnerability.

If the door is purposely left open, you can't break in. And if you connect to control a robot, that's exactly what the purpose of it is. If I connected to your JD robot and made it wave, no one is at risk LOL

Lastly, your focus on the CLI using telnet does not imply there's vulnerabilities of the telnet protocol included in our design. The telnet protocol is not secure because there is no encryption and therefore passes user authentication data in plain text. There is no authentication data on the EZ-B and therefore does not have any risk of leaking personal information. Implementing SSH would be a resource overhead that does not solve anything because there's no authentication data to protect. There's absolutely nothing to protect because the EZ-B always open listening for connections and instructions and does not receive user authentication.

The EZ-B is open to allow connections to control it. Whether moving a servo from ARC -or- from the CLI, you can do so.

If you have questions on a different subject, i'd be happy to engage. Thanks!

Thank you for the detailed response. If I leave the door to a system open, even if it is on purpose, this design choice is the vulnerability.

We have different perspectives, and I will not engage into further discussion here as you suggest. However, I would like you to have the opportunity to comment on a research paper my students and I are preparing regarding the cybersecurity of some robots including JD. If you would like to have this opportunity, please let me know of a way to send you the document once it is ready. (I assume you can find my email address through my forum profile).

Thank you for the discussion.

@Depe: Everyone opinion is different.

We need to adjust the expectations, JD robot is not a final consumer product, is an educational kit / toy based on different building blocks: a wireless controller, servos and sensors.

The logic control block is the ARC (Mobile/Desktop Application).

I'm short on time... security, hacking are very interesting subjects. I would love to help or discuss your research findings.

If you please drop me an email (my email is in my profile). Thanks