Netgear Prosafe Plus Authentication Fail

[watercooled]

Just another one of my random rants, for anyone interested.

So, I was after a new network switch for my home network, and I noticed a Netgear 'Prosafe Plus' was only about a fiver more than an unmanaged version and I thought it would be interesting to try out some of the features. I'd already read gripes about needing an Adobe Air app and so on, although I mistakenly thought it supported LAGG (IIRC some Netgear material implied the range of switches supported it, but I could have found it only applies to about two models if I'd investigated further) which would have been nice. Still, it supports port mirroring, VLANs ans QoS among other things, which could be useful.

Aside from the underwhelming experience of the Air app, which I'd expected anyway, I decided to sniff a few packets to see how it communicates. Turns out, it broadcasts everything (destination 255.255.255.255) in both directions using UDP, with some seemingly custom payload, although it always seems to include the switch's MAC address in the payload presumably as some form of higher-layer identification considering the above.

I read that some firmware version moved to 'encrypted passwords' which broke compatibility with older software versions. So, I captured the authentication sequence out of interest. Essentially, the software broadcasts the 'key' to the switch, which then essentially echos the payload with one byte incremented, presumably to indicate success. Problem is, the same key is transmitted every time, and through changing the password and trying again, you can see the key changes length with the password i.e. this is no secure hash.

Also, while it's not a simple XOR as a string of identical letters don't produce an output string of identical symbols, it seems that characters in the same location yield the same output. E.g. the 'a' in 'password' gives the same output symbol as the second letter 'a' in aaaaaaaa, and similarly the two letter s appear the same as the same positions in a string of the letter s. So some sort of counter/table is influencing the output, but it's not exactly secure, and it would be fairly simple to create a lookup table to map inputs to outputs at each position in order to extract the transmitted password. Someone might know exactly what is going on here, and I'd be interested if anyone does.

Anyway, the upshot of all this is, the access code for the device isn't protected very well in transit. If that weren't enough, it's transmitted to anyone who might be listening on the same broadcast domain, along with all other traffic between the two devices. Not brilliant, considering these devices might find their way into production networks. You could really cause some headaches if you gained unauthorised access to one of these.

[watercooled]

Just re-reading what I wrote while tired - of course it could be a simple XOR against a predefined key, but that key isn't a repeated symbol. That would of course be far simpler than some position-based lookup table. I might run some further testing on this to verify it, but from what I can see, 'encrypted passwords' isn't a phrase I'd comfortably use in this case.

Wasn't/isn't something similar used by non-bluetooth wireless keyboards?