Old Mac Mini runs old OpenSSH with broken cipher set

I couldn't find much about this on the interwebs but I happen to know an OpenSSH developer so I went straight to the experts here.

Basically, if you run OpenSSH on a mac mini, you shouldn't trust Apple to give you updates and you're implementation may well be full of holes. The latest OpenSSH version is 7.1 and my 2009 mac mini with all the updates was reporting

$ ssh -V
OpenSSH_5.5p1, OpenSSL 0.9.8n 24 Mar 2010

Wow... That's not good.

If you MUST run with this version and you want to be security conscious (and NSA paranoid) so you've restricted your allowed cipher list on your client machines, note that aes128-gcm is advertised by this broken Apple build but not actually supported by the binary. This will look like an immediate disconnection after connecting. You have this problem if your system.log contains:

$ tail -n 100 /var/log/system.log| grep fatal
Dec 4 11:16:09 macmini.lan sshd[27028]: fatal: matching cipher is not supported: aes128-gcm@openssh.com [preauth]

The quick fix (you should probably upgrade OpenSSH anyway, somehow..) is to add a cipher line to /etc/sshd_config as follows:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour

Hope that saves someone else some confusion. :D

Playing with the ESP8266

We live in amazing times. For $2.50 each I got some ESP8266 on AliExpress and flashed nodemcu on them with minimal fuss. I've now got kilobytes of flash spare on a WiFi device with 10 digital IO, 1 analog input and a standby current draw of 78 micro amps!

Thanks to the author of this for the instructions. Basically just put the FTDI adapter in 3.3v mode and get breadboarding with the magic pinouts described on the esptool github page and flashed the latest firmware binary blob. Reboot and I get a Lua prompt via minicom. Worked flawlessly.

Next up, DS18B20 temperature sensor, an I2C humidity sensor and some soldering. :)

Reverse-engineering Efergy's internet-connected smart power meter

I just got myself one of these Efergy Home Hub Online things. I'm super impressed with the physical build quality. Sadly though, nothing's perfect. With this unit two fundamental things bothered me, both which are addressable to some degree.

1. Problematic DHCP?

I plugged it in and the network port came alive. Data LEDs blinked but the solid red light indicating the device was booting stayed on forever. I changed the Ethernet cable, port, lots of reboots, turned my 1Gbit ports down to 100Mbit... Nothing. It turned out whatever DHCP client they've implemented doesn't seem to work with a Fritz Box 7390. I've never seen this issue before. I returned the first unit thinking it was bad. When the second unit did the same thing I tried shoving the Ethernet cable into the Ethernet port of my desktop and fired up udhcp. To my surprise, that did the trick. Now I need to figure out some way to get this on my network without forwarding traffic through my desktop that isn't always on.. Urgh!

2. The all-your-data-are-belong-to-us cloudy thing.

Everything these days seems to want to provide an app. That alone isn't a problem, but in order to serve data to the app, your data generally lives in the cloud and this is where I reach for my tin-foil hat and begin the fun little process of reverse engineering the protocol this thing uses. :D

I don't think there is anything sinister going on here. I just want control of my data and would like my device to continue to work if (or rather when) the manufacturer decides to stop hosting it. The web interface this thing provides is pretty slick and there is both an iPhone and Android app but when it comes to my personal data, I'd rather hold it myself, thanks! So on that note...

The solution: Reverse Engineering!

The hardware I presume was actually produced by Efergy but it seems that the software for the "hub" device was provided by a company called Hildebrand based out of London and it's Hildebrand that actually receive the raw meter readings and store them on their servers. The Efergy website hosts the interface but the raw data goes to a sensornet.info domain that is registered to Hildebrand.

Boot Sequence

I have a box stamped with HK 1.1 Firmware AU on the bottom of it. I can't guarantee other regions behave the same way but here goes.

1. DHCP request is broadcast to network. Device waits for a repsonse.
2. DHCP response received. Device starts resolving using DHCP-provided DNS server the hostnames "uk.pool.ntp.org" and "ff.ee.dd.aabbcc.h2.sensornet.info" where "aabbccddeeff" is the MAC address of the device.
3. Device requests from the resovled sensornet host IP the URL https://<ip>/get_key.html. Response is HTTP/200 of the form "TT|ALPHANUMERIC"
4. Device requests from the same host IP the URL "https://<ip>/check_key.html?p=TT&ts=
   0000019D&h=<some hash>. HTTP/200 with an empty response is returned.
5. Device starts posting periodically to https://<ip>/h2 with "Content-Type: application/eh-data" and content of the form: "123456|1|EFCT|P1,0.00.".
6. Device periodically also sends requests to https://>ip>/h2 with "Content-Type: application/eh-ping" and an empty body, presumably just to let the service know it's alive.

Some other nice tidbits:

• SSL is used but certificates are never checked so MITM is very easy to do to read the data.
• The "ts" GET argument in check_key.html is not a timestamp. I've seen it go backwards and always seems close to zero. I suspect it's irrelevant as we can return "success" on any data. We don't really care about authentication here.
• The data format seems to be "<Sensor ID> | 1 | <sensor type> | <INPUT>,<Reading>."
• I suspect unit of measurement to be in milliamps but haven't yet confirmed this. The user will have to take voltage and power factor into account to work out kW and kW/h.

Update: A fake cloudy thing.

I had a Raspberry Pi that I wasn't doing much with so I turned it into my data logger by running my own DHCP, DNS and HTTPS servers, each pointing the device to the rPi instead of the hildebrand servers. I have a USB to Ethernet dongle to talk to the hub and the rPi ethernet adapter to talk to my LAN. Win! Source code is on github here.