[blutack]

Does anyone know or can see an actual concrete security concern with the current implementation of LAN mode?

https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.

I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.

[parasubvert]

To me this whole thing feels like they're trying to pass audit to sell Bambu printers to corporations that require secure communications. Mutual TLS with client certs is nearly universal, which is what they're trying to do with Bambu Connect. On the other hand, MQTT isn't a very secure protocol, plus the printer also uses FTP which is mostly banned on corporate networks these days.

[blutack]

I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS).

I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?

Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.

[parasubvert]

I don't think their MQTT was over TLS traditionally (maybe they added this), it used to be that you just sent a message over unauthenticated MQTT and FTP'd your 3MF; the FTP had a password but that also was sent in the clear. https://github.com/darkorb/bambu-ftp-and-print

Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.

[BeefWellington]

People have been using MQTT with TLS for years[1][2][3]. Long before the company and line of printers existed. It's not really an excuse to say "well they didn't use it" -- they should have simply offered people the necessary configuration options to enable it.

[1]: https://mosquitto.org/blog/2018/05/version-1-5-released/ [2]: https://forums.raspberrypi.com/viewtopic.php?t=287326 [3]: https://esp32.com/viewtopic.php?t=9747

[hWuxH]

Everything was sent in plaintext early on. But since 2022/2023 it's TLS: https://wiki.bambulab.com/en/security-incidents-cloud-traffi...

[iLoveOncall]

Look up old results about "BambuLab MQTT" on Google.

They use an online MQTT server instead of the local one for the following functions: initiating printing, heating the nozzle, and heating the heatbed. (see https://www.allaboutbambu.com/2024/06/14/p1p-p1s-new-firmwar...)

On https://forum.bambulab.com/t/bambu-lab-mqtt-limitations/8344... you can see their MQTT server got DDOSed by some faulty 3rd party "client".

I don't think it's so much about security of the users as much as it is about their own.

[nullc]

That article is referring to conflicting controls when using their cloud stuff.

In lan mode it doesn't use anything remote and works just fine completely isolated.

> you can see their MQTT server got DDOSed by some faulty 3rd party "client"

Right, when you use 'cloud mode' then bambu controls the printer, and your own control has to go through them.

[hWuxH]

> Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.

The problem is hackers don't need to play by the rules (accessing the display).

8 digits that never change is a joke in terms of security, it could be brute-forced within hours/days by sending a network request for each possible combination.

mitm: afaik Bambu Studio/Connect/Handy validate the printer's certificate during the TLS handshake, but most third party software probably doesn't (barely found documentation about it).

And there are a few other (although not as fundamental) weaknesses like no mutual authentication, access control or revocation of specific clients. Due to the nature of MQTT, every client can see messages sent by other clients once authenticated.