samtap / fang-hacks

Collection of modifications for the XiaoFang WiFi Camera
1.67k stars 340 forks source link

Security issue (KRACK). Maybe use patched wpa_supplicant from within custom sbin? #251

Open saulchristie opened 6 years ago

saulchristie commented 6 years ago

As you're no doubt aware the KRACK vulnerability announced last month would have serious security implications for anyone using these cameras on a WPA2 secured network (they could be forced onto an attacker's network from where the streams could be viewed relatively trivially).

Given how I doubt that Xioami will update the base version of wpa_supplicant it might be wise to change the firmware to install and use a new KRACK-patched version from within /media/mmcblk0p2/data/sbin (ditto hostapd). I believe wpa_supplicant has already been fixed so hopefully would just need compiling, including in the build and new explicit paths to the custom binary placing in the associated startup scripts.

(Of course, replacing the original (very old) binary in /sbin might actually be a better solution)

Links: https://www.krackattacks.com/

samtap commented 6 years ago

Any binaries on the sdcard are used in favor of equivalents in flash, because they appear earlier in PATH variable. So the scripts likely don't need any changes.

I believe wpa_supplicant depends on openssl (among others) so you'll have the opportunity to build and update that to a secure version as well! However that will also require recompilation of a bunch of other stuff, libcurl (and git) come to mind that are built against the openssl shipped by Xiaomi fw. Good luck ;-).

I've prioritised other stuff so if you want this soon-ish, you'll have to do a pull-request.

BlaY0 commented 6 years ago

Thanks @saulchristie for taking care of this. Can you share patched and compiled wpa_supplicant? Or better just make a pull request here. Thanks again!

davidjb commented 6 years ago

I've fixed this on my cameras by upgrading and compiling wpa_supplicant v2.7 dev. If anyone wants to make a PR out of https://github.com/davidjb/fang-hacks/commit/23ae89934d71580666e23436d401a0de82831b78 be my guest. The compilation instructions are there too in case anyone wishes to build it themselves, otherwise compiled libraries/executables are present too (@BlaY0). The use of the crosstool toolchain from the Sonix SDK is needed to build against the uClibc libraries that the camera has onboard; I did try with a custom buildroot toolchain but it was far simpler to use the toolchain the SDK.

I've separated the new compiled files out from placing them in existing data/ directories (eg data/lib) because I wanted to ensure this worked first (and be able to fallback on stock wpa_supplicant in testing) but also because /lib contains an older version of libssl-1.0.0. If existing apps tried to use my new libssl-1.0.2m, then they'd break and likewise the new wpa_supplicant can't use the old libssl or it'll break. Thus, it was easiest for me to separate new the wpa_supplicant out.

Note that changes to the 01-network script have been required to set up LD_LIBRARY_PATH but the commit above has those changes too. Enjoy!

I'm not using hostapd (eg AP mode) but that would absolutely need replacement too to mitigate KRACK.

@saulchristie FYI you can't replace binaries in /sbin because the filesystem is read only (comes from a cramfs image on the camera). Plus, it's safer if you at least have a working wpa_supplicant etc to fall back on, even if you could modify /sbin or /lib.

BlaY0 commented 6 years ago

So you did it instead of him :)

There's also a wpa_supplicant from LEDE project compiled against musl which doesn't depend on libssl.

You should know also that in some cases wpa_supplicant is not enough to mitigate KRACK. A kernel patch for mac80211 module was also made for that purpose.

saulchristie commented 6 years ago

Ha. So I finally get some time to look at this and see it's already been done by @davidjb . Good work! I've tried your changes and it all seems to work perfectly, many thanks doing all that and making it available to us. I also had a look around the rest of your project and liked the fixes to the system time script and pulling out the OSD into its own script (which is a good idea).

There's certainly not many cheap cams out there you can guarantee will be secure against KRACK so nice to have this available.

ril3y commented 6 years ago

I do not see a pull request from davidjb did this git pushed into master somehow?

On Fri, Dec 8, 2017 at 3:06 AM, saulchristie notifications@github.com wrote:

Closed #251 https://github.com/samtap/fang-hacks/issues/251.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/samtap/fang-hacks/issues/251#event-1378383021, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOJMy3Cw0CZzEKqJIrQaqtj4wX4nwXJks5s-O4XgaJpZM4QSj4L .

samtap commented 6 years ago

No pull request required, I'll sort it for the next release (if by that time Xiaomi haven't resolved it which would be much preferred...)

The repo is full of binaries so pull request are a bit problematic (davidjb's binaries are incompatible with mine). But I still appreciate everybody helping out and giving feedback! Compile instructions can be a huge timesaver as well.

ril3y commented 6 years ago

PatrickM,

I agree on the instructions. Can you put up an example of your ./configure options specifically --prefix used etc. Then the rest of us can use it as a guide? Also perhaps having a fang-hacks web page that could pull down binaries that you want loaded would be an option?

On Fri, Dec 8, 2017 at 8:27 AM, PatrickM notifications@github.com wrote:

Reopened #251 https://github.com/samtap/fang-hacks/issues/251.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/samtap/fang-hacks/issues/251#event-1378822912, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOJM8zhqr26yS9nSYUvMFY94Ml3y3fOks5s-TlGgaJpZM4QSj4L .

samtap commented 6 years ago

The problem is, it tends to change a bit depending on what you're building, what buildsystem is used and of course personal preference :wink: This is how I configure openssl: CC=arm-linux-cc AR=arm-linux-ar RANLIB=arm-linux-ranlib LD=arm-linux-ld ./Configure --prefix=/media/fh/data --openssldir=/media/fh/data/etc linux-armv4. But on my host, obviously I can't install to /media/fh/data so after compiling I use make INSTALL_PREFIX=$PWD/dist install to install everything to the 'dist' folder, then simply copy contents of dist folder to camera.

I've a git build for the cam as well so hopefully next versions will have some kind of automatic update to pull changes from github instead of having to flash a new image. Just have to figure out how to do that without overwriting changes to scripts and config-data etc. users may have.

BlaY0 commented 6 years ago

Guys, just to let you know... you are not safe with this wpa_supplicant only, you need patched kernel as well!

saulchristie commented 6 years ago

@BlaY0 : Do we know this for a fact - i.e. by running krack-test-client.py against a patched camera, for example? does having the unpatched kernel result in the device remaining vulnerable at all times or is it just vulnerable to one of the power-state attacks?

BlaY0 commented 6 years ago

Not at all time, that's for sure. When changing power states which can happen quite often. I haven't had the time to go into details on specs of this particular WiFi or its FW, so I can't tell for sure how often is this 'often' happening ;)

diegosueiro commented 6 years ago

@BlaY0,

What needs to be patched in the Linux kernel?. For instance, I just found patches to wpa package (wpa_supplicant and hostapd).