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

61–70 of 102 posts

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#61

Post by jjeaff »

nikanj wrote: post #33
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.

I'm just guessing, but I think experience would actually get you more investment. But interesting backstory gets you more press. Thus the impression that backstory is more important. Most funded startup founders are older and experienced. They just don't get as much tech press coverage.

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.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#62

Post by dmurray »

mcintyre1994 wrote: post #38
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.

The recommendation is a lot kinder than the reasonable one of "throw the lock in the garbage and never buy anything from this company again".

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#63

Post by annabellish »

air7 wrote: post #56

> You could easily sniff out account IDs because Tapplock was too lazy to use HTTPS. 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 th…

Almost all flaws are "not that serious" on their own, because people aren't generally _that_ dumb.

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

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#64

Post by vivan »

This is a problem you see with a model of security where they have security on the front end (meaning the user can only see the bits they should have access to in the UI) but then the back end API is pretty much open to any authenticated user. The idea being that nobody should be able to send API requests if the UI isn't there.

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.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#65

Post by acchow »

nikanj wrote: post #33
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.

who is "Silicon Valley"?

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#66

Post by chii »

phito wrote: post #45
friendzis wrote: post #40

Earlier quoted context omitted.

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

Sometimes I wonder how technology can work, when so many people working in the field are unable to grasp the basic concepts of it

Either the competent pulls way more than their weight, or luck.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#67

Post by [deleted] »

annabellish wrote: post #63
air7 wrote: post #56

> You could easily sniff out account IDs because Tapplock was too lazy to use HTTPS. 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 th…

Almost all flaws are "not that serious" on their own, because people aren't generally _that_ dumb. "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.

[deleted]

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#69

Post by icebraining »

raverbashing wrote: post #44
rapsey wrote: post #19

Earlier quoted context omitted.

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

While EEs are part to blame, the other half is just graduated (or "bootcamp graduated" - let's put it this way) developers that know all the node.js shortcuts but don't know about the fundamentals of internet security.

Not sure we can blame bootcamps - I learned nothing about internet security in my software engineering college course.

Re: The Tapplock IoT padlock has multiple security vulnerabilities

#70

Post by mercer »

sudhirj wrote: post #18
kypro wrote: post #5

Earlier quoted context omitted.

Out of interest what strategies could be implemented to avoid this? 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.

I work on encrypting movies for distribution, so there's a spectrum of attacks we try to consider. 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 / Amat…

> 1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable.

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.

Post reply on HN