Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tapplock IoT padlock has multiple security vulnerabilities

nakedsecurity.sophos.com

Post reply on HN
Print view View original

31–40 of 102 posts

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#31

Post by raesene9 »

tqkxzugoaupvwqr wrote: post #14

The article recommends: > Don’t allow plain HTTP any more. Make sure your servers insist upon HTTPS connections, and update your client software to use HTTPS exclusively. Does this mean I should turn off HTTP completely? Right now, I redirect any incoming HTTP requests to HTTPS. Is this considered insecure?

So it depends on your client population. If you've got general browsers hitting your site, I think HTTP-->HTTPS is a reasonable trade off and stops the poor experience of a user putting your site name into the browser bar and getting told there's no site there.

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.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#32

Post by user5454 »

snowwolf wrote: post #29

“Invincible to the people who do not have a screwdriver” 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...

> “Invincible to the people who do not have a screwdriver”

or a mobile phone.. or access to the Internet..

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#33

Post by nikanj »

hatsunearu wrote: post #2

Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices

Silicon Valley prefers teams to have epic backstories, not experience.

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.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#34

Post by [deleted] »

tqkxzugoaupvwqr wrote: post #14

The article recommends: > Don’t allow plain HTTP any more. Make sure your servers insist upon HTTPS connections, and update your client software to use HTTPS exclusively. Does this mean I should turn off HTTP completely? Right now, I redirect any incoming HTTP requests to HTTPS. Is this considered insecure?

[deleted]

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#35

Post by user5454 »

rapsey wrote: post #19
hatsunearu wrote: post #2

Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices

IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.

While true in many cases, in my experience it's not only the engineers. Unless you have the senior managers on board as well, they'll just lean on the engineers to "ship now".

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#36

Post by dirktheman »

thomasfedb wrote: post #21

Utterly horrifying, but ultimately irrelevant. No lock of this size is meant to be anything other than inconvenient to open. Angle grinders are cheap, and more easily wielded than HTTP request crafting.

Also, with a simple padlock you know that it can be cut open pretty easily. So you're aware of the risks and the basic level of security it offers. This "smart" padlock offers nowhere near the basic level of security you expect so you can't make a proper risk assessment.

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...

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#37

Post by helb »

ptx wrote: post #24

I wonder why the "message" field in the response says "API调用成功" ("API call succeeded", I think?) if this is a Canadian company. Did they just buy the locking solution from some Chinese OEM?

Maybe… https://www.aliexpress.com/wholesale?catId=3010&SearchText=f... (the case looks a bit different though)

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…

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#38

Post by mcintyre1994 »

tomsmeding wrote: post #9

> Web programmer? Don’t make account IDs easy to guess. In an otherwise secure system, account numbers that go 1,2,3… shouldn’t be a problem, but why make it easy? 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…

> 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.

It sounds like they still have this flaw, you just have to guess someone else's account ID now.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#39

Post by jon-wood »

ptx wrote: post #24

I wonder why the "message" field in the response says "API调用成功" ("API call succeeded", I think?) if this is a Canadian company. Did they just buy the locking solution from some Chinese OEM?

Yes, almost certainly. One of the IoT industry's dirty little secrets is that just about everyone is just rebadging OEM hardware from China, and often doing a minimum of due diligence on that hardware.

(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)

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#40

Post by friendzis »

tomsmeding wrote: post #9

> Web programmer? Don’t make account IDs easy to guess. In an otherwise secure system, account numbers that go 1,2,3… shouldn’t be a problem, but why make it easy? 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…

> 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.

"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.

Post reply on HN