An update in point form

Jun. 25th, 2016 08:08 pm
[personal profile] alexbayleaf
1. Still alive and kicking. Living a quiet life. Slowly digging out from under the dark pile of crap that has been the last year or so.

2. I'm still checking in on DW every few days at least to follow those who are still posting here, especially those who access lock. I might not always comment but I am reading and appreciating the insights into your lives. Thank you :)

3. As you may have seen I am handing over Growstuff to people who are better able to look after it. Sad to let it go, but glad to be letting go of the guilt about not having the mental wherewithal to deal with it. Pretty much all my old personal websites/domains are also expired/gone. I'm glad to be leaving it behind.

4. Please note username change. While I hated being forced to use my birthname, I actually like my current name, and have been using it more often online of late. Feel free to refer to me as "Alex" when talking about me in the third person. Pronouns are still "they" or "she" - either is fine, though I aim for mostly being gender neutral when refering to myself.

5. I have a new blog, Spinster's Bayley, which more or less replaces the old "Chez Skud" blog, in that it's about domestic life, but is less just "random crap that I feel like writing about" but has a bit more intent around it. I'm tossing up whether to crosspost it here - feedback welcome. If you're interested in simple/sustainable/resilient living, homegrown and homemade stuff, and subjects of that variety, go take a look.

6. I also recently started blogging at Eat Local Ballarat about locally produced food in the Ballarat region. Don't imagine it'll be of much interest to people beyond this geographic area but if you're interested in local food or relocalisation in general, take a look :) Definitely won't be crossposting that one here, but of course there's the usual collection of RSS, newsletter, and social media for those who want to follow it.

7. I would welcome suggestions of any DWs that talk about simple living, or related topics (as above). Anyone got recs?

I've bought some more awful IoT stuff

Jun. 21st, 2016 03:13 pm
[personal profile] mjg59
I bought some awful WiFi lightbulbs a few months ago. The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being lightbulbs. Since then I've bought some other Internet of Things devices, and since people seem to have a bizarre level of fascination with figuring out just what kind of fractal of poor design choices these things frequently embody, I thought I'd oblige.

Today we're going to be talking about the KanKun SP3, a plug that's been around for a while. The idea here is pretty simple - there's lots of devices that you'd like to be able to turn on and off in a programmatic way, and rather than rewiring them the simplest thing to do is just to insert a control device in between the wall and the device andn ow you can turn your foot bath on and off from your phone. Most vendors go further and also allow you to program timers and even provide some sort of remote tunneling protocol so you can turn off your lights from the comfort of somebody else's home.

The KanKun has all of these features and a bunch more, although when I say "features" I kind of mean the opposite. I plugged mine in and followed the install instructions. As is pretty typical, this took the form of the plug bringing up its own Wifi access point, the app on the phone connecting to it and sending configuration data, and the plug then using that data to join your network. Except it didn't work. I connected to the plug's network, gave it my SSID and password and waited. Nothing happened. No useful diagnostic data. Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn't created. Apparently this isn't permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It still didn't work, but that's because it let me give it a 5GHz network and it only has a 2.4GHz radio, so one reset later and I finally had it online.

The first thing I normally do to one of these things is run nmap with the -O argument, which gives you an indication of what OS it's running. I didn't really need to in this case, because if I just telnetted to port 22 I got a dropbear ssh banner. Googling turned up the root password ("p9z34c") and I was logged into a lightly hacked (and fairly obsolete) OpenWRT environment.

It turns out that here's a whole community of people playing with these plugs, and it's common for people to install CGI scripts on them so they can turn them on and off via an API. At first this sounds somewhat confusing, because if the phone app can control the plug then there clearly is some kind of API, right? Well ha yeah ok that's a great question and oh good lord do things start getting bad quickly at this point.

I'd grabbed the apk for the app and a copy of jadx, an incredibly useful piece of code that's surprisingly good at turning compiled Android apps into something resembling Java source. I dug through that for a while before figuring out that before packets were being sent, they were being handed off to some sort of encryption code. I couldn't find that in the app, but there was a native ARM library shipped with it. Running strings on that showed functions with names matching the calls in the Java code, so that made sense. There were also references to AES, which explained why when I ran tcpdump I only saw bizarre garbage packets.

But what was surprising was that most of these packets were substantially similar. There were a load that were identical other than a 16-byte chunk in the middle. That plus the fact that every payload length was a multiple of 16 bytes strongly indicated that AES was being used in ECB mode. In ECB mode each plaintext is split up into 16-byte chunks and encrypted with the same key. The same plaintext will always result in the same encrypted output. This implied that the packets were substantially similar and that the encryption key was static.

Some more digging showed that someone had figured out the encryption key last year, and that someone else had written some tools to control the plug without needing to modify it. The protocol is basically ascii and consists mostly of the MAC address of the target device, a password and a command. This is then encrypted and sent to the device's IP address. The device then sends a challenge packet containing a random number. The app has to decrypt this, obtain the random number, create a response, encrypt that and send it before the command takes effect. This avoids the most obvious weakness around using ECB - since the same plaintext always encrypts to the same ciphertext, you could just watch encrypted packets go past and replay them to get the same effect, even if you didn't have the encryption key. Using a random number in a challenge forces you to prove that you actually have the key.

At least, it would do if the numbers were actually random. It turns out that the plug is just calling rand(). Further, it turns out that it never calls srand(). This means that the plug will always generate the same sequence of challenges after a reboot, which means you can still carry out replay attacks if you can reboot the plug. Strong work.

But there was still the question of how the remote control works, since the code on github only worked locally. tcpdumping the traffic from the server and trying to decrypt it in the same way as local packets worked fine, and showed that the only difference was that the packet started "wan" rather than "lan". The server decrypts the packet, looks at the MAC address, re-encrypts it and sends it over the tunnel to the plug that registered with that address.

That's not really a great deal of authentication. The protocol permits a password, but the app doesn't insist on it - some quick playing suggests that about 90% of these devices still use the default password. And the devices are all based on the same wifi module, so the MAC addresses are all in the same range. The process of sending status check packets to the server with every MAC address wouldn't take that long and would tell you how many of these devices are out there. If they're using the default password, that's enough to have full control over them.

There's some other failings. The github repo mentioned earlier includes a script that allows arbitrary command execution - the wifi configuration information is passed to the system() command, so leaving a semicolon in the middle of it will result in your own commands being executed. Thankfully this doesn't seem to be true of the daemon that's listening for the remote control packets, which seems to restrict its use of system() to data entirely under its control. But even if you change the default root password, anyone on your local network can get root on the plug. So that's a thing. It also downloads firmware updates over http and doesn't appear to check signatures on them, so there's the potential for MITM attacks on the plug itself. The remote control server is on AWS unless your timezone is GMT+8, in which case it's in China. Sorry, Western Australia.

It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn't give it to me, which is unsurprising but still disappointing.

The use of AES is still somewhat confusing, given the relatively small amount of security it provides. One thing I've wondered is whether it's not actually intended to provide security at all. The remote servers need to accept connections from anywhere and funnel decent amounts of traffic around from phones to switches. If that weren't restricted in any way, competitors would be able to use existing servers rather than setting up their own. Using AES at least provides a minor obstacle that might encourage them to set up their own server.

Overall: the hardware seems fine, the software is shoddy and the security is terrible. If you have one of these, set a strong password. There's no rate-limiting on the server, so a weak password will be broken pretty quickly. It's also infringing my copyright, so I'd recommend against it on that point alone.

Security Through Obscurity

Jun. 17th, 2016 05:33 pm
brainwane: The last page of the zine (zine)
[personal profile] brainwane
I was at a conference, talking with some men, on our way to an informal group dinner. We started talking about what we were reading. One of them (white, US American) and I started talking about comics; we both like comics. I said something enthusiastic about Saga.

He then stated a disclaimer: that he knew he was a bit of a snob, and that if someone asked him if he knew about/read something fairly popular, fairly mainstream, he sort of internally sighed a bit; he preferred pretty offbeat stuff. It seemed like he wanted to prevent bad feelings down the line by forestalling me from asking "have you read [superhero thing]" or "have you read [current critics' darling]" and triggering impatience. I asked if I'd just done that thing, by mentioning Saga, and he said, no, it was fine.

I asked: "So, what's your favorite Amar Chitra Katha?"

There were at least a few seconds of silence, solid eye contact and silence, before he said that he did not know what that was.

So I, pleasantly, told him about the comics I'd read in childhood, made by Indians for many decades, featuring Indian fables, mythology, history, and legends. We then talked about, for instance, Greek and Norse mythology in Marvel/DC mainstream comics, and so on. He mentioned that it did seem like new Indian comics lines were starting up. He did not ask how or where to get ACK comics, or how to spell Amar Chitra Katha so he could learn more.

He didn't say anything explicitly acknowledging my indier-than-thou move (and I didn't either). I wonder whether he noticed it. I will usually prefer enthusiasm over status play, but I do have a few dominance displays in my toolbox and on occasion I will use them.

Profile

terriko: (Default)
terriko

June 2016

S M T W T F S
   1234
567891011
1213141516 1718
19202122232425
2627282930  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 29th, 2016 02:35 pm
Powered by Dreamwidth Studios