Objekt mit 12 Linien & >300 Geräten angegriffen; 70% der Geräte kaputtprogrammiert

[Opfer 1]

Das ist normal. Das BAU Passwort besteht aus 4 Bytes. In Hex schreibweise sind das 8 Zeichen(0-9 und A-F)

Aber kann man auch einfach weniger Zeichen verwenden? z.B. nur ABCD oder müsste es dann 0000ABCD sein? Die Nullen werden bei Hex automatisch aufgefüllt oder? 🤔

[thewhobox]

Ich weiß nicht ob die ETS es zulässt weniger Zeichen einzugeben.
Aber so oder so werden die restlichen Zeichen aufgefüllt, dass es wieder 8 Zeichen sind. (Wie in deinem Beispiel zu 0000ABCD).
Im AuthorizeRequest müssen 4 Bytes übergeben werden.

Die einzige Kombination die nicht geht als Passwort ist 0xFFFFFFFF. Das ist nämlich das Standard Passwort, auch wenn keins gesetzt oder das vorhandene gelöscht wurde.

[ziceva]

Hello KNX Community,

First of all, sorry for posting in English on a Geman forum (if this breaks some rule of the forum, mods can delete this post easily).

I want to share my (complete amateurish) take on this problem; I have a friend that knows someone that faced the exact same problem described in this topic: sometime at the end of December an attacker gained access to the system and locked all devices with a BCU-password and there was no way to take back control of the system.

What I would like to mention from the start is that I am a complete amateur when it comes to hardware (my skills are mostly software), so some of my methods are .. amateur-level at best .. Anyway, I like hacking circuits together and reverse engineering stuff, so this seamed like a nice challenge given that I never worked with KNX before.

After spending days taking things apart (Gira 5133/5131/5142 buttons, Gira 8 and 16 channel actuators and even a Gira weather station) it became clear that, in this case, the method that Limes used could not be applied since I only had Gira devices, and although they are all powered by Atmel micros (with which I am quite familiar and comfortable probing and poking), all of the devices have the lock-fuses set so there is no way to access the flash/eeprom areas and get a more limited space for a bruteforce attack.

Indeed, trying to bruteforce the complete 32-bit space seems like impossible at first sight and it would take multiple years to complete on a single device at the low speed of 9600bps of the KNX bus. But having tens or hundreds of devices with (what it is assumed to be!) the same password, gives a glimmer of hope, even more so if some way of speeding up the process, even a little bit, can be found.

When probing for the flash/eeprom contents it became apparent that the buttons could be of help when in comes to the speed of the attack: the buttons (bear with me here, I knew nothing of the knx-system at the time) are not directly connected to the bus, but use the bus coupler 3 and the communication here actually uses a 115200bps UART: there is a microcontroller in bus coupler 3 that communicates with the KNX bus at the limited 9600 baudrate and with the buttons themselves at the much higher 115200 baudrate. Even better, the microcontroller in the bus coupler acts only as a gateway and the actual password is in the buttons microcontroller. Probing this 115200 bus (easily done with any logic analyzer, or in my case with a Rygol scope) revealed that the protocol used is knx-like; It is not all the way knx (and packed a nasty surprise for me because of my amateur-level probing), but the manual of serial transmission in KNX can be used to identify what it is sent to ask for authorization and the relevant reply).

So, at this point I kind of decided that sending multiple auth-requests to multiple devices in parallel over this faster bus could help. The next step would be to decide on the host (or hosts) that are to be used to format and send the packets to the devices. The first idea (as usual, the one that doesn't work) was to use a bunch of inexpensive esp32 dev boards since they have 2 (maybe even 3, if I can get around the bootloader log on UART0) hardware UARTs (at 115200 baudrate, I correctly assumed that only hardware UARTs are usable). Also, the WiFi can be used for higher level orchestration of the attack.
I already knew that even though at 115200 baudrate, the bus has some timing requirements: the host cannot send as fast as possible, and the device will delay quite some time before responding, so maybe some multiplexing could be done in software (some hardware considerations must be taken into account when connecting more devices on a UART, but in the end I never got that far with this idea) in order to connect two devices per esp32 UART port. This would require some 10 esps to connect 60 devices (10 esp x 3 UART x 2 devices) ... and at a speed of 30 tries per second (yeah, it was wishful thinking at this point), the total time for the complete 32 bit space would be no more than 30 days; while not great, this amount of time seems something that could work, doesn't it?.

Unfortunately, this proved to not work, because when I was probing the 115200 baudrate bus I completely missed the fact that the bus was actually using a 9E1 serial frame format which I assume is just a quirk of the Atmel implementation since this is not at all a standard frame format (9N1 is the closest standard I could find that was maybe-kinda used sometime far in the past on non-Atmel devices via the weird space/mark parity that in turn is not really standard). Anyway, this format is definitely not supported by the esp32 hardware UARTs. After fiddling a few more days with some SoftwareSerial libraries for the esp32 that supported the required frame format, this was definitely a dead-end (it's exactly what you would expect from multiple software serials running on a single micro-controller).

What was required, was an Atmel-based host for the frame-formatting, sending and receiving; Arduino Mega2560 (I did promise you amateur solutions, didn't I?) has 4 nice hardware UARTs just waiting to be used. A professional approach would be to maybe use one (or maybe more) FPGAs to implement more than 4 UARTs per host, but I had none of those, so Arduino it was (ended up having 23!! Arduinos working toghether ... I borrowed every Arduino I could find from all my friends and then also bought quite a few of them .. luckily, if you are buying non-branded ones - long live open-hardware! - they are quite cheap at ~10Eur here in Romania).

The setup that ended up working was hooking up 3 devices on 3 of the UART ports of the Arduino (I gave up on the multiplexing rubbish also) having the fourth UART connected to an esp32 for orchestration. This 4th port could have been a software serial since I decided that 9600bps is enough to just receive tasks and report statuses, but I knew for a fact that software serials mess up the timing interrupts in the Arduino and I was already more then fed-up with the software implementation, so I decided to just use one of the hardware ones for this purpose. In the esp32 I did use software implemented serials since I had no timing requirements (but I did end up using checksums for my task/status frames, because it was somewhat unreliable, but not enough to be a problem) because I wanted to connect four Arduinos to a single esp32 (I could have connected more, but I already had the esps to spare). I ended up also 3d-printing small racks to hold the devices and their Arduino together; even so, the wiring was an absolute mess ... This setup gave me ~18 tries per second per device (some devices - 5133/5131 were actually faster at ~19+ tries per second, and some were slower - the 5142s only replied fast enough for 8-9 tries/second; I guess the micro-controller was loaded more with the management of the small display, and that is why its replies were delayed more).

Having now 6 esp32s each having 4 racks (the sixth ended up having only three, because I was getting diminishing returns from the slower 5142s that I had available) each rack having in turn one Arduino and 3 devices, I split the entire 32 bit domain in 8192 "chunks" of 524288 keys each (2^13 chunks x 2^19 keys for easy management). Each device would then be assigned one random (this ended up helping a lot!) chunk and it would try each key in the chunk (one chunk is a number from 0-8191: shift the number 19bits to the left and start incrementing 2^19 times; then repeat, and repeat, and repeat ... quite an easy task to implement into the Arduino, after I figured out what frames to send to the device and how to parse the replies). The esp32s would then forward data to and from the Arduinos to a php script with a small sqlite database in order to keep track of the progress. With this setup one 5133/5131 would finish its assigned chunk in about 7h30-8h00; one 5142 would finish in about double that time.

The worst-case computed time ended up being closer to 45 days, but in the end the key was found after ~15days; The system had only checked ~37% of the complete 32bit space and the key, if taken in sequential order form 0x00000000 to 0xFFFFFFFF was at ~73% of the space (so by taking the search randomly, I got a 2x speedup, although this of course was no guarantee at the start ... I do not know enough statistics to conclude that random is better then sequential, but in my case it helped a lot).

Anyways, that is what I wanted to share with you about my first experience with KNX devices.
If reviving this old thread was a bad idea (or it is somehow considered thread hijacking), a mod of the forum should delete or move my post as appropriate.

Best regards,
John

[henfri]

Wow. Thanks for sharing!

[Beleuchtfix]

Impressive way to start into the KNX world and a great first post in this forum. Thanks a lot.
Regards, Florian

[Andreas]

... krass

[PhilW]

spechless...

[Hennessy]

Thanks for sharing and I‘m very impressed by your reverse engineering skills.

This highly parallelized bruteforcing attack does however only work, if the password is the same. Luckily in this case the password was the same on all devices.

As this might not always be the case, it is important to follow the recommendations of the KNXA: https://www.knx.org/knx-en/for-profe...cyber-attacks/

[ziceva]

[...]
As this might not always be the case, it is important to follow the recommendations of the KNXA: https://www.knx.org/knx-en/for-profe...cyber-attacks/

Not only that it works only in the particular case when the passwords are the same on all devices, it also needs many device to even begin to work (if you have 10-20 devices, it would take waaay longer) and the devices need to have this particular layout with bcu coupler and comms at a decently high baudrate. And even if you have all this, it still takes a long time
.
Following good security practices is always recommended!

For what is worth, I am thinking of even creating a honeypot-like device: during my investigation I killed a 5133 device, but only by mistakenly deleting its firmware (yeah, it was my first time with JTAG also ... 🤦♂️ ... ICSP is my go-to programming method for Atmel). I am pretty sure that with the information I have now, I could make my own firmware for this device that only needs to listen (never transmit) and just intercept M_SetKeyRequest frames (for any destination) and save the parsed key into a circular buffer in eeprom or in the flash itself. Then, there would be a method to recover the last couple of hundred keys (maybe even thousands) that this device has "seen" on the particular branch of the bus it was connected to (by taking it apart again an reading its memory; since the chip was already erased, the lock bits are also cleared). This could be useful if the system was attacked, or the password was simply lost/set by mistake. This device would not be part of the "active" system; it would only be connected somewhere on the bus, and be left to it's own business (a secure location would be highly recommended) ...
So, to put it simple, I would be implementing a simple KNX sniffer, and for this I only need to write some software (the dead 5133 would be the hardware)
If you are interested in this, I can give updates when (and if!) this works at all.

[Hennessy]

Your planned honeypot device is nothing else than a logging device specialized for KNX programming messages and with a new password in it. Or do I mix up something?

I'm not sure, if general logging would also log such programming messages. A lot of devices exist already on the market performing general logging of KNX messages.

[ziceva]

Your planned honeypot device is nothing else than a logging device specialized for KNX programming messages and with a new password in it. Or do I mix up something?

Well, it is very possible I am reinventing the wheel, if such loggers already exist (but I do enjoy this conversation because I am learning new things).
My honeypot device (which at the end of the day is just an exercise for learning more about the subject) would not "exist" on the bus .. it would not have an address of its own, and as such it cannot be locked itself.
Being a custom firmware, I can decide what features I implement in it (maybe a commercial device already exists that has these exact features):
- It only listens (think of the "promiscuous mode" of Ethernet interfaces when tcpdump-ing ) for any and all messages it can see, and I can indeed implement whatever filters I want in it (programming messages or otherwise; in this case, just take the passwords and log them to a persistant storage).
- no one can lock it (no one can even address something to it and no one will ever receive something from it, because it has no address to speak of)
- no one can read anything that was logged in it unless you take it apart and read its memory via JTAG/ICSP (inconvenient, but this is only limited by the 5133 hardware I am using ... had I killed a 5142 I could have used its display for a nice UI while also ensuring that only someone with physical access to the device has access to the logged data; making custom hardware, or just using an Arduino connected to a bus coupler 3 allows for whatever UI to ensure secure access to the logged data)

[concept]

for my opinion, a honeypot is something, thats attracts the intruder. but your device is invisible, a specialized data logger, so honeypot is perhaps the wrong name. but anyway an interresting idea! for a commercial product the device should have an user-friendly interface for read out, i.e. an usb interface.

and i‘m highly impressed about your work!

[ziceva]

Yeah, you are right ... "honeypot" is not the best word to describe what I had in mind ... Specialized data logger describes it better ...

[GLT]

Seh ich auch so. Wie viele Jahre wird hier schon gepredigt, dass man keine offenen Ports ins Internet stellt. Ich hab da irgendwie gar kein Mittleid.

Wurdest Du auch geweckt?

https://www.golem.de/news/unsichere-...03-163935.html

[vento66]

Nö, habs erst aus dem Radio erfahren....