And now the FBI gets in on the act....

The FBI recommends any owner of small office and home office routers power cycle (reboot) the devices. Foreign cyber actors have compromised hundreds of thousands of home and office routers and other networked devices worldwide. The actors used VPNFilter malware to target small office and home office routers. The malware is able to perform multiple functions, including possible information collection, device exploitation, and blocking network traffic.

If I remind you I've written several articles on this, going back a while and with the most-recent just a couple of days ago, noting that my HomeDaemon-MCP server, which takes care of security, control and monitoring at my home has been under quite-concerted probing attacks for some time.  

Folks, this crap is only going to get worse.  The simple truth is that an awful lot of coders can't code their way out of a paper bag, a huge amount of software development has been farmed out to "code kiddies" on H1b visas or even shipped overseas to India, and the prevalence of IDEs make coding fast and easy -- too easy.

I wrote the Android HomeDaemon-MCP app in about a week from start to first "breathing" code.  It's now about a month, roughly, since I started working on it.  I had never written a single Android app that did so much as posting up "Hello world" before sitting down to write this, and it's a fairly complex bit of stuff, comprising "always on" network code, display management and various forms of media including both stills and video streams.

Here's the problem: While the handful of external libraries that are publicly released and I use can be inspected in source doing so for the entirety of what is included by those IDEs is a ridiculously complex task bordering on the impossible and virtually all of it has some potential security implication.  Indeed if you read the monthly Android security patch lists at least one serious problem is usually found in MediaServer, which is the framework that handles user presentation of damn near everything multimedia of any sort on an Android phone -- sound, video, images, etc and all of which is embedded into the Android operating environment.  Could you audit all of that?  Well, maybe, if you have man-decades of time to put into it before you release a simple "hello world" app.... and nobody does, including Google who wrote the damn operating system originally!

For this specific reason the Android app stores no login or password data -- not to the system at your house that it connects to, not to the cameras at the house, nothing.  It obtains a key that is of limited validity (the length of which you choose when you set up HomeDaemon at your home or business) when you sign in and never stores the underlying credentials.  If and when the key expires it asks you to sign in again.  No big deal, and if that key gets pilfered due to some underlying issue in the OS then revoking it is as simple as either time or rebooting the controller which doesn't store those on a persistent basis either as part of its security model.

On the other hand someone has to store the actual credentials, and that task goes to the HomeDaemon server, running on the Pi, which is entirely written in "C", by myself, with its only outside dependence being basic Unix operating system libraries and the OpenSSL encryption routines against which it is linked.  That code is not only everywhere it's under active review all the time and, while OpenSSL is a large codebase it's also one of the better-studied pieces of software out there, never mind being able to be upgraded without recompiling HomeDaemon itself since it's dynamically linked.  At worst you have to re-link it.

Security implications are massively compounded as soon as any sort of "cloud" gets involved.  Why?  You haven't read about Meltdown and Spectre?  Note that there are now multiple additional variants that have been discovered and they involve the means to steal data from cloud instances, something I've warned about for years.  There is no mitigation for them available and in fact it may be impossible to fix without major architectural changes in CPUs -- which means for existing computers it will never be fixed and the performance implications of those architectural changes may make them prohibitive for general deployment in any event.  That this hasn't already caused the "cloud" folks to get hammered back to where they really belong (that is, as mass-distribution systems for content intended to be public, like the public contents of a blog) where there's nothing to steal is a shocking testament to the inanity of so-called "IT" people everywhere.

It doesn't help to have the best cryptography in the world if you either leave unencrypted data around or put the keys where someone can steal them!

I absolutely love the convenience that I get from the HomeDaemon-MCP software but I'd never put up with the security problems that come with being connected to any sort of cloud instance for anything like this no matter who's cloud it is!  A "cloud" computer is simply a computer you do not own but lease time on.  The owners are never responsible for your data if and when it gets stolen, because they'd be nuts to take that liability and thus none of them do.

If you want data to be secure it has to be on a machine you own the entire time in a place that is physically secure and under your control, so you know if an intrusion takes place and can do something about it.  The only alternative is that the data must at all other times be encrypted, especially when it is being transported and the keys to decrypt it must never be on a machine that is not owned by you.

You cannot meet that requirement with a cloud-based system because in order to use the data you must decrypt it and that means the keys have to be a computer that is not yours.

The goal of these present thieves appears to be to get inside what you think is a "secure" perimeter.  Most small office and home networks are ridiculously insecure, and many large corporate networks are too.  Why?  Because most of them are wired and the assumption is made that if you can plug into the wall you have permission to be there.  Thus you have all sorts of cute stuff on the "average" small office network included unsecured Windows machines, file servers with open share points and machines that will still take an unencrypted "telnet" or "ftp" connection -- and that's if they don't have wide-open vulnerabilities of other sorts such as unencrypted file storage protocols running (e.g. "bare" NFS or even SMBv1!)

If you can break into the gateway (which is what this newest attack is targeting) then you have established what amounts to a virtual presence inside the building but one the owner cannot see!

Wake up folks.... sending your conversation to a random person in your contact list is the least of your problems.

If you're in this space with regard to home security, monitoring and control, think about doing it the right way.  Look to the right and email me, read here, and here.