The Tapplock IoT padlock has multiple security vulnerabilities
nakedsecurity.sophos.com
nakedsecurity.sophos.com
Is that the best advice to web programmers they can give based on this story? That's the "obscurity" part in the security by obscurity scheme. If you've got your security otherwise nailed down fine, some obscurity on the top doesn't hurt: security-in-depth, people seem to call that. But use only the obscurity, and only one person has to find out how your scheme works, and it's game over.
I'd, you know, recommend to think about authentication. Your authentication state is not "logged in", it's "logged in as user X". So the code that decides whether a client can see a specific page can and should (!) depend on what specifically you're authenticated as.
Oh, and yes, this company has proved that they don't know the least thing about security. But that was clear already.
https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...
It sounds like they still have this flaw, you just have to guess someone else's account ID now.
"the code that decides whether a client can see a specific page" should not care about authentication, this is authorization issue. I see these things conflated too often.
Identification, Authentication and Authorization are three different beasts. Separate identification seems unnecessary complication, which it is in simple web app, but in a more complicated case where ID is not user supplied (login over external service, read ID from smart card, etc.) it can become a necessity, which can be embedded into authentication mechanism. Authentication mechanism should only provide "authenticated" and similar (e.g. "authentication security level") flags, because authentication at its root is a mechanism to establish trust that client has control of certain ID, nothing more.
You (a potential beginner) have to basically implement everything yourself or use some 3rd party service. There just aren't any good libraries available.
I once tried some random framework I found where the example auth project that they provided had exactly the problem you described.
You could log in and then do everything if you called the api endpoints manually... Deleting and editing other users profiles? No problem.
“Security by obscurity” refers to the obscurity of the security scheme, not identifiers!
It's not even that specific. It's obscurity of the workings of the system which may or may not have any security in place.
Something like:
> "when we launched, our [thing] was totally insecure and we had just thrown together a bunch of spaghetti code over nights and weekends- anything that would ship. Then when we hit it big we started investing in the process and now our [thing] is the best, most secure one on the market"
Too bad in this case [thing] is a lock, where proper security is it's primary, and single reason for existing. There's no 10 years later for this one.
https://boingboing.net/2018/06/15/high-tech-lock-is-invincib...
Which incidentally is also maybe and issue for tapplock
https://www.theregister.co.uk/2018/06/15/taplock_broken_scre...
or a mobile phone.. or access to the Internet..
Who knows but after learning this I would be highly cautious to buy anything from this company until they‘ve proofen to be more careful in the future.
Being a Kickstarter project, the pressure to meet production deadlines is severe, and any technical debt inherent since the 'quick and dirty' MVP probably stays unpaid.
I've worked as a developer for a number of companies who handle sensitive data and I could have fairly easily have pushed malicious code. Even with mandatory code reviews, significantly complicated code with a well placed security hole would likely be missed.
1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable. Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.
2. Novice / Amateur attacks on the API or backend - make sure as much security as possible is in global middleware on the application, on by default, opt-out explicit. Long random access tokens, use either DB checks or constant time comparison to verify, do rounds of self and third party testing to make sure there's no cross privileges or escalation.
3. Protect against ourselves going rogue / being compromised - all keys in a HSM, the HSM also has the list of certificate chains it will trust, only modifiable by N of M keycards held by top execs, assume compromise at every stage and design the systems to mitigate impact. Ideally design so catastrophic attacks are impossible without collusion among top level company execs, and all other attacks, even when successful are downgraded to inconveniences, preferably minor.
Is that actually necessary/useful?
> Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.
why Oauth instead of just a regular user table, login POST form, and the rest as you describe?
Not disagreeing, btw. just curious.
> Is that actually necessary/useful?
Yes, removes guessing, incremental attacks and off by 1 errors/attacks. Obfuscation is bad encryption but good policy.
> why Oauth instead of just a regular user table, login POST form, and the rest as you describe?
Sessions are fixed and can last an indefinite amount of time as an example.
But [token based system X for client/server or some kerberos variant for semi-trusted or m2m] will fill this void as well.
And yeah, obscurity is not security but is useful in itself. Smaller attack vector (can’t leak info by iteration) less competitive info leakage (you’ll never figure out how many customers we have unless we tell you). Also has advantages with regards to database replication, backup restore and sequence management, but that’s another topic.
IoT is electronics people coming into the software world and building software like it's the 90s.
Not in my experience. But it's obviously not the same everywhere.
Security? Forget it.
I've never gone to a bootcamp, but I'd wager that they at least mention security in their classes. College was the equivalent of the PHP documentation that had incredibly insecure examples that people "learned" from.
you'd be surprised to learn how many pieces of code were designed, written and shipped by one man army.
Edit: pcb design is risky. But the system is very primitive having voltage regulator and single integrated circuit in it. I doubt this department with current performance would survive as independent company.
A first-year dropout from MIT and a Thiel fellow are much more likely to get funded than an engineer with a state uni BSc+25 years industry experience plus a former sales manager in the same industry.
Kind of like why many people fear sending their kids to school because they might be killed by a mass shooter. When in reality, the drive to school is much more dangerous.
From an article linked elsewhere in this thread:
> startup […] has claimed that issues with manufacturing in China were behind the months of silence which provoked aggrieved backers […] fearing fraud
So at least they didn't pretend to make the locks in Canada…
(Disclaimer: I work for an IoT startup. We have an in-house security engineer, and contract pen testers who we call in to do physical and software tests against any new hardware we ship)
It is a stupid practice.
I "hacked" a student newspaper back when I was at university with a similar "hack". They decided to roll their own CMS rather than using something like Wordpress, because, you know... that makes sense for a small team with little experience.
The user settings page was something like /user/edit/{userid}. I noticed that you can actually change any user's settings (including login) by just changing the userid. So, of course, you just change it to 1 because the first user will inevitably be the admin. This gave control over the whole system.
>Tapplock user? Get and install any and all patches provided. Apparently, the company has now addressed the most obvious web portal holes (guessable account IDs and no HTTPS), but we assume an app update will be needed as well.
Also, stop being a Tapplock user
Nothing went right in the design of this padlock.
If they wanted to knit their own cryptography, then cryptocurrency and ICO was their place to be.
"I'm going to make my own Bluetooth smart-lock. It's gonna be amaaaazing. Oh hai Mark."
SSL benefits are generally over-hyped IMO and might give a false sense of being 'Secure' as in this article where such an obviously flawed system receives "use SSL" as one of two recommendations.
The idea that unencrypted traffic allows any hacker to easily sniff it is wrong and misleading. The eavesdropper needs to be "close": In the same LAN as the target, or upstream of it, i.e on the same wifi (needs to be physically there, know/hack the wifi password and performing an ARP spoofing attack), or being/hacking the ISP itself.
Of course I'm not saying SSL shouldn't be used, only that it's a secondary security measure, like using a seat-belts vs having good breaks.
"You can find out somebody's account ID" isn't that big a problem in the presence of other decent mitigations. Without those mitigations, of which HTTPS is one to prevent request spoofing, everything is terrible.
Never heard of this product before but what a hilarious read. They seem to fix some of the issues pretty quick. But what a nightmare IoT are. I’m stressed out by not keeping up to date with computer/phone updates (mostly because I wait a bit to ensure programs I use still work). Can’t imagine owning even more products that I have to maintain software updates on...
Does this mean I should turn off HTTP completely? Right now, I redirect any incoming HTTP requests to HTTPS. Is this considered insecure?
But if you set the Strict-Transport-Security header[1] that will tell the client to go directly to HTTPS in the future, without needing to be redirected, so future requests will be secure as long as the initial redirect request is not intercepted.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
Preventing that kind of thing is the whole point of SSL. If you enable communication without SSL it's not prevented, so it's less secure.
I guess this applies more to non-browser client software than to people typing URLs in their browser address field, though.
If you control the client population, as in this case, there's no real need to allow HTTP at all, so I'd just disable it and have HTTPS only.
Does this mean I should turn off HTTP completely?
The reason is, if you're using any type of hosting that shares IP addresses - Cloudflare, S3, Cloudfront - then you can't close the HTTP port as it's needed for other sites hosted on the same IP.
Getting your domain added to the HSTS preload list is a more conventional way of reducing HTTP traffic.
Still fucked tho
This would allow for an attack where the lock appears to be operating successfully, but someone has unauthorised access.
We had a similar thing a couple of years ago with bicycle locks (I'm Dutch). AXA, a well known manufacturer of locks offered a range of very sturdy bicycle locks. Hardened steel, almost impossible to crack open unless you spend some time with a big, noisy angle grinder. A lot of these locks were mandated by insurance companies, so they must be good, right?
Wrong. A lot of these locks could be opened in seconds with just a blank (uncut) key. Which you could buy in bulk and not very hard to get hold of...
Consider using it for your gym-locker. The changing room is typically occupied by at least some people whenever the gym is open so if someone is pulling out a bolt-cutter or an angle grinder it would probably lead to someone notifying the gym-employees/police. Meanwhile someone who just walks up to the lock and seemingly opens it must be legit and goes unnoticed.
If someone wants to get past my low-tech padlock, it will be inconvenient. They will have to spend some amount of time with either an angle grinder, bolt cutters, or lock picking tools. What they’re doing will be suspicious and will likely draw attention. If they’re caught during the trip to or away from my lock, the possession of any of these tools will be suspicious.
With this lock, all those weaknesses are the same. Expect now the lock-pick tools are replaced with an app, and there's nothing wonky at all about someone walking up to the lock, tapping on their phone, and removing it. If they're caught en route to or away from the location, they have nothing on them to incriminate.
This lock is strictly worse than a standard padlock, when it comes to security. All the flaws plus new ones.
With that in mind - which are you more worried about? Something spoofing your Bluetooth pass code using some advanced tech, physically unscrewing the back and deconstructing the padlock, or the third option: chop open the shackle?
What I find amazing is that they thought they advertise this product as more secure than any other padlock with the same mechanism. This padlock is a finger print padlock, maybe people like that convenience, but don't try and pretend physical security isn't a concern.
Also with bolt cutters that leaves a mark. With a high tech back it doesn’t (unless they record and you actively look at unlock attempts). Which means that to find out if your lock has been hacked you’ll likely have to physically go there, open it up, and then look inside to see if anything is missing.
The vulnerabilities in the article might go unnoticed, so the user keeps locking gates, chains, whatever with the bad lock and the crooks can come again and again and rifle through your shed, garage, whatever.
It is absolutely worse than a chopped padlock.
Are you being obtuse? I'm worried about the options that are 1) easiest to perform and 2) arouse the least suspicion.
So, obviously the first two by a mile. The tech is not advanced.
Also, it costs $99. I'm pretty sure you could buy a fairly secure normal padlock for $99.