7 ms·

The Tapplock IoT padlock has multiple security vulnerabilities

132 points by ptx 8y ago

hatsunearu 8y ago
Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
- rkh2018 8y ago
  Maybe they took the „f*ck it, ship it“ advice too seriously and shipped it a bit too fast? 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.
  - cyberferret 8y ago
    I am fairly certain that the lean methodology of "if you are not embarrassed by your first release, you released too late" may have been a factor. 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.
- kypro 8y ago
  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.
  - bojo 8y ago
    They should have paid for code audits, penetration testing, and the whole nine yards before putting anything in a customer's hand. The whole point of this company is based around a physical security device with online controls, to not do any of that is a downright folly in my opinion.
  - sudhirj 8y ago
    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 / 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.
    - mercer 8y ago
      > 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.
      - consp 8y ago
        Not my post but my answers would be: > 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.
      - 8y ago
- petethepig 8y ago
  Lack of experience?
- rapsey 8y ago
  IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.
  - user5454 8y ago
    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".
    - rapsey 8y ago
      And those managers don't care either because their area is in electronics not software. IoT is electronics people coming into the software world and building software like it's the 90s.
  - varjag 8y ago
    They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
    - rapsey 8y ago
      > and programmed by programmers Not in my experience. But it's obviously not the same everywhere.
      - varjag 8y ago
        Maybe in garage projects, but there it can as well be in the opposite way. Would be really surprised to see it mixed in a corporate setup or with even smaller design contractors.
  - raverbashing 8y ago
    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.
- nikanj 8y ago
  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.
  - throwawayqdhd 8y ago
    Aka the "Nerd Rockstar Bias"
  - emblaegh 8y ago
    If they had inexperienced developers, that's most likely because they're cheaper, not because they have an amazing narrative behind their backs.
  - jjeaff 8y ago
    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.
  - acchow 8y ago
    who is "Silicon Valley"?
  - tomhoward 8y ago
    This company is from Canada, not Silicon Valley, and has nothing to do with MIT or the Thiel fellowship. Please avoid polluting comment threads with this kind of off-topic sneering.
thatswrong0 8y ago
These seem like mistakes one would make if one was using tutorials to build a Rails application for the first or second time ever.
bobbles 8y ago
>What to do? >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
shroom 8y ago
> ”Incredibly, Tapplock’s back-end system would not only let him open other people’s locks using the official app, but also tell him where to find the locks he could now open!” 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...
tomsmeding 8y ago
> 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, 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.
- filleokus 8y ago
  Of course your authentication scheme should be secure even if someone knows how the user IDs are generated. With that said it might be a good idea to exposing something like GUIDs to the user anyways, for example if you are worried about a competitor getting an exact count of registered users / products / orders (which the competitor would get by themselves doing the action and observing the created ID). https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439 https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...
- mcintyre1994 8y ago
  > 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.
  - dmurray 8y ago
    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".
slivym 8y ago
Frankly, this all seems like quite a lock of fuss over nothing. Firstly, pad locks are generally very easy to just break open with a set of bolt cutters. Particularly, if you look at more secure traditional pad locks practically all of them share physical design features intended at minimizing the amount of the actual shackle that's accessible. So to be clear- the second you see the shape of that padlock you know that it's not designed to be super secure. 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.
- cwilkes 8y ago
  Most locks are in public places so the threat from a way that doesn’t draw suspicion is much higher than one that requires you to carry a huge set of bolt cutters in to do the job. 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.
- crottypeter 8y ago
  If someone chops open your padlock you find out about it next time you see it. 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.
- aekotra 8y ago
  > 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? 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.
pedroaraujo 8y ago
I thought this was a blog post about the guy who simply unlocked the padlock using a GoPro mount (https://www.youtube.com/watch?v=RxM55DNS9CE https://www.youtube.com/watch?v=RxM55DNS9CE - the video is worth watching from the beginning) but this was more amusing than I was expecting. Nothing went right in the design of this padlock.
- ptx 8y ago
  Apparently that was a quality-control issue with his lock - the lock is designed to have a small metal pin that prevents rotating the back, but it was defective on his lock.
  - mikestew 8y ago
    Same quality control that allows the shackle to be snipped with a 12" set of bolt cutters? It's almost as if at every turn, of two possible decisions, they consistently chose the wrong one.
- m4tthumphrey 8y ago
  This is a lot more interesting; the lock itself is useless before we even get to the software issues.
tqkxzugoaupvwqr 8y ago
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?
- Ndymium 8y ago
  Using HTTP to redirect to HTTPS is fine, but you should augment it with HSTS (to instruct browsers to always go to HTTPS) and HSTS preload (to let browsers know to go for HTTPS even before they visit your site the first time).
- ptx 8y ago
  It's insecure because whoever intercepts the unencrypted HTTP request could redirect it anywhere, i.e. to their evil site instead of your secure site. 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/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
  - icebraining 8y ago
    Allowing HTTP is not insecure; if someone can intercept the connection, they can do so even if you don't have HTTP enabled.
    - ptx 8y ago
      Hmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? 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.
      - 8y ago
thomasfedb 8y ago
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.
- raesene9 8y ago
  however there are cases where an attacker doesn't want to arouse suspicion, and Angle grinders are kind of noticable. This would allow for an attack where the lock appears to be operating successfully, but someone has unauthorised access.
  - thomasfedb 8y ago
    For this reason the scariest bit is the ability to access account information via their online systems - sounds like a map of locks that aren't locks.
    - imtringued 8y ago
      Why the hell do they store the location data of the locks. Are they secretly selling the location and unlock access to governments?
- dirktheman 8y ago
  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...
- user5454 8y ago
ptx 8y ago
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?
- helb 8y ago
  Maybe… https://www.aliexpress.com/wholesale?catId=3010&SearchText=fingerprint+padlock 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…
  - makomk 8y ago
    Some of the off-brand OEM locks are worse. Like, there's one model which apparently just has exposed Torx screws that can be undone to take the entire lock apart: https://www.youtube.com/watch?v=7Uje4pxfSlI https://www.youtube.com/watch?v=7Uje4pxfSlI
- jon-wood 8y ago
  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)
  - majewsky 8y ago
    That's not a "Disclaimer", that's a "Source".
newsbinator 8y ago
In a different market, with a different product, this could have been a funny success story 10 years later. 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.
ericnyamu1 8y ago
wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php
snowwolf 8y ago
“Invincible to the people who do not have a screwdriver” https://boingboing.net/2018/06/15/high-tech-lock-is-invincible.html 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_screwdriver/ https://www.theregister.co.uk/2018/06/15/taplock_broken_scre...
- user5454 8y ago
  > “Invincible to the people who do not have a screwdriver” or a mobile phone.. or access to the Internet..
thisisit 8y ago
> Canadian internet of things (IoT) startup Tapplock learned the hard way why you should never knit your own cryptography If they wanted to knit their own cryptography, then cryptocurrency and ICO was their place to be.
- raverbashing 8y ago
  Don't give them any ideas. Or they will want to save lock/unlock data to a blockchain, then read from it in order to unlock your padlock.
gfgffdf 8y ago
wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php
sschueller 8y ago
As mentioned in the article. Jerry Rig Everything did a review on this and found that you can just twist off the back...[1] [1] https://youtu.be/RxM55DNS9CE?t=3m39s https://youtu.be/RxM55DNS9CE?t=3m39s
- maaark 8y ago
  Taplock claim that was an exceptional unit and a spring loaded pin normally prevents this. Another researcher couldn't make it work. Still fucked tho
qazwsxedcrfv1 8y ago
wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php
air7 8y ago
> 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 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.
- annabellish 8y ago
  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 8y ago
    [deleted]
  - zip1234 8y ago
    I agree, the account ID is a complete non-issue as long as each endpoint limits results to the account ID associated with the credentials.
qazwsxedcrfv12 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
qazwsxedcrfv123 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
vivan 8y ago
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.
444441445435 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
imtringued 8y ago
There's an upside to the terrible security: no fingers have to be chopped to gain access.
notnot 8y ago
This may seem unrelated but I watched "The Disaster Artist" for the first time last night. It made me cringe, not for Wiseau but by reminding me of all the times I've been a Wiseau in my life as I disconnected from reality caught up in some fantasy of how I was going to make the world love me by something I was going to do. Reality can be a brutal place for the ego, but at least it's real. "I'm going to make my own Bluetooth smart-lock. It's gonna be amaaaazing. Oh hai Mark."
PGenes 8y ago
Hmm, how cheap were the developers?

132 points by ptx 8y ago

hatsunearu 8y ago

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

rkh2018 8y ago
Maybe they took the „f*ck it, ship it“ advice too seriously and shipped it a bit too fast? 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.
- cyberferret 8y ago
  I am fairly certain that the lean methodology of "if you are not embarrassed by your first release, you released too late" may have been a factor. 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.
kypro 8y ago
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.
- bojo 8y ago
  They should have paid for code audits, penetration testing, and the whole nine yards before putting anything in a customer's hand. The whole point of this company is based around a physical security device with online controls, to not do any of that is a downright folly in my opinion.
- sudhirj 8y ago
  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 / 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.
  - mercer 8y ago
    > 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.
    - consp 8y ago
      Not my post but my answers would be: > 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.
    - 8y ago
petethepig 8y ago
Lack of experience?
rapsey 8y ago
IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.
- user5454 8y ago
  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".
  - rapsey 8y ago
    And those managers don't care either because their area is in electronics not software. IoT is electronics people coming into the software world and building software like it's the 90s.
- varjag 8y ago
  They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
  - rapsey 8y ago
    > and programmed by programmers Not in my experience. But it's obviously not the same everywhere.
    - varjag 8y ago
      Maybe in garage projects, but there it can as well be in the opposite way. Would be really surprised to see it mixed in a corporate setup or with even smaller design contractors.
- raverbashing 8y ago
  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.
nikanj 8y ago
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.
- throwawayqdhd 8y ago
  Aka the "Nerd Rockstar Bias"
- emblaegh 8y ago
  If they had inexperienced developers, that's most likely because they're cheaper, not because they have an amazing narrative behind their backs.
- jjeaff 8y ago
  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.
- acchow 8y ago
  who is "Silicon Valley"?
- tomhoward 8y ago
  This company is from Canada, not Silicon Valley, and has nothing to do with MIT or the Thiel fellowship. Please avoid polluting comment threads with this kind of off-topic sneering.

thatswrong0 8y ago

These seem like mistakes one would make if one was using tutorials to build a Rails application for the first or second time ever.

bobbles 8y ago

>What to do? >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

shroom 8y ago

> ”Incredibly, Tapplock’s back-end system would not only let him open other people’s locks using the official app, but also tell him where to find the locks he could now open!” 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...

tomsmeding 8y ago

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

filleokus 8y ago
Of course your authentication scheme should be secure even if someone knows how the user IDs are generated. With that said it might be a good idea to exposing something like GUIDs to the user anyways, for example if you are worried about a competitor getting an exact count of registered users / products / orders (which the competitor would get by themselves doing the action and observing the created ID). https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439 https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...
mcintyre1994 8y ago
> 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.
- dmurray 8y ago
  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".

slivym 8y ago

Frankly, this all seems like quite a lock of fuss over nothing. Firstly, pad locks are generally very easy to just break open with a set of bolt cutters. Particularly, if you look at more secure traditional pad locks practically all of them share physical design features intended at minimizing the amount of the actual shackle that's accessible. So to be clear- the second you see the shape of that padlock you know that it's not designed to be super secure. 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.

cwilkes 8y ago
Most locks are in public places so the threat from a way that doesn’t draw suspicion is much higher than one that requires you to carry a huge set of bolt cutters in to do the job. 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.
crottypeter 8y ago
If someone chops open your padlock you find out about it next time you see it. 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.
aekotra 8y ago
> 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? 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.

pedroaraujo 8y ago

I thought this was a blog post about the guy who simply unlocked the padlock using a GoPro mount (https://www.youtube.com/watch?v=RxM55DNS9CE https://www.youtube.com/watch?v=RxM55DNS9CE - the video is worth watching from the beginning) but this was more amusing than I was expecting. Nothing went right in the design of this padlock.

ptx 8y ago
Apparently that was a quality-control issue with his lock - the lock is designed to have a small metal pin that prevents rotating the back, but it was defective on his lock.
- mikestew 8y ago
  Same quality control that allows the shackle to be snipped with a 12" set of bolt cutters? It's almost as if at every turn, of two possible decisions, they consistently chose the wrong one.
m4tthumphrey 8y ago
This is a lot more interesting; the lock itself is useless before we even get to the software issues.

tqkxzugoaupvwqr 8y ago

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?

Ndymium 8y ago
Using HTTP to redirect to HTTPS is fine, but you should augment it with HSTS (to instruct browsers to always go to HTTPS) and HSTS preload (to let browsers know to go for HTTPS even before they visit your site the first time).
ptx 8y ago
It's insecure because whoever intercepts the unencrypted HTTP request could redirect it anywhere, i.e. to their evil site instead of your secure site. 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/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
- icebraining 8y ago
  Allowing HTTP is not insecure; if someone can intercept the connection, they can do so even if you don't have HTTP enabled.
  - ptx 8y ago
    Hmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? 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.
    - 8y ago

thomasfedb 8y ago

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.

raesene9 8y ago
however there are cases where an attacker doesn't want to arouse suspicion, and Angle grinders are kind of noticable. This would allow for an attack where the lock appears to be operating successfully, but someone has unauthorised access.
- thomasfedb 8y ago
  For this reason the scariest bit is the ability to access account information via their online systems - sounds like a map of locks that aren't locks.
  - imtringued 8y ago
    Why the hell do they store the location data of the locks. Are they secretly selling the location and unlock access to governments?
dirktheman 8y ago
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...
user5454 8y ago

ptx 8y ago

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?

helb 8y ago
Maybe… https://www.aliexpress.com/wholesale?catId=3010&SearchText=fingerprint+padlock 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…
- makomk 8y ago
  Some of the off-brand OEM locks are worse. Like, there's one model which apparently just has exposed Torx screws that can be undone to take the entire lock apart: https://www.youtube.com/watch?v=7Uje4pxfSlI https://www.youtube.com/watch?v=7Uje4pxfSlI
jon-wood 8y ago
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)
- majewsky 8y ago
  That's not a "Disclaimer", that's a "Source".

newsbinator 8y ago

In a different market, with a different product, this could have been a funny success story 10 years later. 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.

ericnyamu1 8y ago

wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php

snowwolf 8y ago

“Invincible to the people who do not have a screwdriver” https://boingboing.net/2018/06/15/high-tech-lock-is-invincible.html 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_screwdriver/ https://www.theregister.co.uk/2018/06/15/taplock_broken_scre...

user5454 8y ago
> “Invincible to the people who do not have a screwdriver” or a mobile phone.. or access to the Internet..

thisisit 8y ago

> Canadian internet of things (IoT) startup Tapplock learned the hard way why you should never knit your own cryptography If they wanted to knit their own cryptography, then cryptocurrency and ICO was their place to be.

raverbashing 8y ago
Don't give them any ideas. Or they will want to save lock/unlock data to a blockchain, then read from it in order to unlock your padlock.

gfgffdf 8y ago

wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php

sschueller 8y ago

As mentioned in the article. Jerry Rig Everything did a review on this and found that you can just twist off the back...[1] [1] https://youtu.be/RxM55DNS9CE?t=3m39s https://youtu.be/RxM55DNS9CE?t=3m39s

maaark 8y ago
Taplock claim that was an exceptional unit and a spring loaded pin normally prevents this. Another researcher couldn't make it work. Still fucked tho

qazwsxedcrfv1 8y ago

wow.check out this cool forum http://mawazo.byethost7.com/index.php http://mawazo.byethost7.com/index.php

air7 8y ago

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

annabellish 8y ago
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 8y ago
  [deleted]
- zip1234 8y ago
  I agree, the account ID is a complete non-issue as long as each endpoint limits results to the account ID associated with the credentials.

qazwsxedcrfv12 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

qazwsxedcrfv123 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

vivan 8y ago

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.

444441445435 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

imtringued 8y ago

There's an upside to the terrible security: no fingers have to be chopped to gain access.

notnot 8y ago

This may seem unrelated but I watched "The Disaster Artist" for the first time last night. It made me cringe, not for Wiseau but by reminding me of all the times I've been a Wiseau in my life as I disconnected from reality caught up in some fantasy of how I was going to make the world love me by something I was going to do. Reality can be a brutal place for the ego, but at least it's real. "I'm going to make my own Bluetooth smart-lock. It's gonna be amaaaazing. Oh hai Mark."

PGenes 8y ago

Hmm, how cheap were the developers?