We're all doomed anyway

IoT botnet goes nuclear:

formatting link
formatting link
formatting link

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs
Loading thread data ...

I recall D-Link released a bunch of Wifi-enabled home-automation wall sockets where the PHP request handler code had a line sort of like:

char input_buf[500000];

Usually getting to that point in code execution required auth, but there were a few request handlers (like for device identification) that dumped the input right into that buffer, no problem at all.

No sanitization on request string character type or length employed whatsoever, natch.

Reply to
bitrex

One fairly balanced article, from a noted expert in the field

formatting link

For those that don't know, Schneier wrote the definitive textbook "Applied Cryptography", and has more recently branched out into pointing out how systems fail and succeed.

Reply to
Tom Gardner

"Security" is most typically "tacked onto" products instead of being inherently designed-in from the product's inception. Its a secondary design criteria that often gives way to other "featurism".

*Why* is there a "default password" on ANY product? Is there some NEED for such a default? Why can't the product, instead, be designed so it won't work UNTIL you have specified a password? And, impose constraints on the quality of that password?

Or, *offer* a randomly generated password to the user: "Make a note of this: 'six yellow geese run fast' (contrast with 'three blue cars die soon'). In the event it is lost, you will have to manually reset the device and obtain a NEW password"

Also, increasingly, developers are incorporating codebases of which they have little detailed understanding. Rather than educate themselves on the vulnerabilities of those codebases (network stacks, operating systems, etc.) they gleefully exploit them as shortcuts to an earlier release date (release soon and release OFTEN! :> )

Why should a (particular) IoT appliance be capable of initiating outbound connections? D'uh...

Reply to
Don Y

For a minute there, I thought the IoT was getting into hacking the Americium-241 in smoke detectors. :p

Michael

Reply to
mrdarrett

You forget that there are other aspects to a product than its security. Usability and out-of-the-box experience, for example.

Users (and reviewers) don't like to study a manual or to go through procedures like choosing and remembering a password before the product can be used. Support desks don't like the situation where customers on the phone cannot be helped when they have forgotten their password.

Today it is very important that a product works without reading the manual and from the moment it is first plugged in. When this is not the case, it receives negative marks in reviews and on social media.

Passwords generated in advance, printed, for example, on a label on the bottom have been tried. Because manufacturers of course don't want additional procedures during the manufacturing, it often is implemented as a hash function on the MAC address or another serial number. It never takes long before little programs are going around that repeat this action and figure out the password, especially in the case of Wi-Fi gear. (where the MAC address, after all, is transmitted by radio)

Reply to
Rob

I only buy the Battlestar Galactica versions of LED bulbs.

Cheers

Reply to
Martin Riddle

Of course there are! Every product offering -- every engineeered solution -- is a balanced compromise between competing constraints. It can't be infinitely expensive or perpetually in development. It can't break on first use nor require a PhD to operate. etc.

But, security almost always takes a back seat to other issues. Look at how long it took to get "chipped" credit cards. Look at how many "passwords" are *still* 4 digit PINs. The "solution" is to tell people how to practice "more secure computing" -- instead of a genuine solution (which would require cooperation from multiple vendors, industries, etc.).

"Don't reuse passwords on different accounts" "Pick a combination of upper and lower case with some digits and punctuation" "Check your accounts frequently for signs of fraud/abuse" "Don't open attachments"

yada yada yada

And, then folks are SURPRISED when their accounts are compromised, their devices hijacked, etc.??? Or, that vendors are monitoring their movements (by tracking their cell phone emissions) around their commercial property while simultaneously watching to see the items in which they express interest. Then, BINDING their cell phone emissions to their credit card name when they eventually approach the checkout counter ("Ah, unknown-user-12343 -- who has visited us on the following different days -- is, in fact, Jane Dough! Maybe she's got one of our member cards and we can start sending her offers based on what we've OBSERVED about her behavior while in our store??")

Or that a web site knows who you are -- despite your never disclosing that information, consciously: "Ah, the guy with the Windows 7 PC from IP address a.b.c.d running Firefox 42 with Flash disabled is back! Facebook has identified him as Bob Smith..."

Anyone who owns a PC/Mac has already accepted that constraint. What they resent is having to remember DIFFERENT passwords for all these different devices.

Each of my "devices", here, has a self-adhesive label (Ptouch) that identifies the device (host name). Another label alongside indicates the "superuser's" account name and password.

[! Someone can break into your house and figure out my passwords!" "Um, if they're in my house, they can TAKE the devices and crack them in the leisure of their own home WITHOUT my having tagged each with passwords!"]

Its easy to help folks who have forgotten their password: "Press the red reset button on the back of the device and it will return the device to its initial state -- prompting you for a NEW password. Please write this down. In the process, you will, of course, have lost any private information that the password protected..."

You can question how much of the device's state NEEDs to be wiped in such a procedure. You can also incorporate mechanisms to allow subsets of its state to be preserved and/or restored (why can't you cache the last known values and mark them as "deleted"; then, offer to restore them?)

And, when some private conversation that your baby monitor picked up is posted on-line, that is "well received"? Or, if folks can access your home security camera and *watch* you breast feeding your infant?

Educate users as to why these measures are IN THEIR BEST INTEREST. Instead, most devices just DICTATE what the user MUST do to use the device.

And, don't give devices capabilities they don't need -- simply because you were too ignorant of the codebase that you "lifted" to make your development job easier.

My automation system employs ~120 processors scattered around the house. They share the same network fabric with ~20 conventional devices. And, that fabric allows me to add new appliances (smart TV, etc.), guests to use my internet access while here, etc. Yet, nothing can talk to anything else. Sit in the guest bedroom trying to access the security camera at the front door and you'll find "no device". Try to access one of my development computers and you'll encounter a similar black hole -- despite the fact that you can see me sitting

*AT* that computer transfering files to another device on the network.

Walk around to the back side of the house and try to gain access to the network -- or, my internet connection -- from the network port on the back porch and you'll discover you have no connectivity. In a fit of rage, try to muck with my system by shorting the output of a tesla coil into that RJ45 and you'll toast that port (making it IMPOSSIBLE for you to use it as an attack vector) but the rest of the system will continue to function.

... because I considered these aspects *in* the design and didn't just bolt them on after-the-fact.

Reply to
Don Y

Sure. But the picture is not as black-and-white as it is sometimes sketched.

Passwords are not useful for secure authentication. And the more rules one gives out, the less useful they become.

One of the big problems is the lousy security on user databases on websites. Once the bad guys can download a list of users and hashed passwords, they can have their go, both because of mistakes that users make when selecting and using passwords, and because the lazyness of developers that all use the same hashing function.

When access is only through the login mechanism, compromising passwords is a lot harder due to slowness and even limits un the number of attempts.

IoT devices should normally not be available for login so easily. Most users will use a NAT router or some other unidirectional access, and an open telnet port on a device should not hurt at all as long as local network users can be trusted. But lots of devices use UPnP and other methods to get themselves accessible from the internet, and that is where the problems start.

Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.