Easy-To-Pick 'Smart' Locks Gush Personal Data, FTC Finds

An anonymous reader quotes a report from Ars Technica: A padlock -- whether it uses a combination, a key, or "smart" tech -- has exactly one job: to keep your stuff safe so other people can't get it. Tapplock, Inc., based in Canada, produces such a product. The company's locks unlock with a fingerprint or an app connected by Bluetooth to your phone. Unfortunately, the Federal Trade Commission said, the locks are full of both digital and physical vulnerabilities that leave users' stuff, and data, at risk. The FTC's complaint (PDF) against Tapplock, released Monday, basically alleges that the company misrepresented itself, because it marketed its products as secure and tested when they were neither. A product -- any product -- simply being kind of crappy doesn't necessarily fall under the FTC's purview. Saying untrue things about your product in your advertisement or privacy policy, however, will make the commission very unhappy with you indeed.

The lock may be built with "7mm reinforced stainless steel shackles, strengthened by double-layered lock design with anti-shim and anti-pry technologies," as Tapplock's website promises, but according to the FTC, perhaps it should have considered anti-screwdriver technologies. As it turns out, a researcher was able to unlock the lock "within a matter of seconds" by unscrewing the back panel. Oops. The complaint also pointed to several "reasonably foreseeable" software vulnerabilities that the FTC alleges Tapplock could have avoided if the company "had implemented simple, low-cost steps."

One vulnerability security researchers identified allowed a user to bypass the account authentication process entirely in order to gain full access to the account of literally any Tapplock user, including their personal information. And how could this happen? "A researcher who logged in with a valid user credential could then access another user's account without being re-directed back to the login page, thereby allowing the researcher to circumvent Respondent's authentication procedures altogether," the complaint explains. A second vulnerability allowed researchers the ability to access and unlock any lock they could get close enough to with a working Bluetooth connection. That's because Tapplock "failed to encrypt the Bluetooth communication between the lock and the app," leaving the data wide open for the researchers to discover and replicate. The third vulnerability outlined in the complaint also has to do with a failure to secure communication data. That app that allows "unlimited" connections? The primary owner can of course add and revoke authorized users from the lock. But someone whose access was revoked could still access the lock because the vulnerability allowed for sniffing out the relevant data packets. As part of the settlement, the FTC is requiring Tapplock to create a security program for its products. "That program is required to include training for employees; timely disclosure of 'covered incidents,' including both loss of personal information and also unauthorized access to systems; actual penetration testing of the network; and several other elements, including annual review," reports Ars Technica.

Read more of this story at Slashdot.

SecRule REQUEST_URI "@rx ..." "id:1001,phase:1,deny,status:403"

find /var/www -type f -name "*.php" -mmin -120

ss -tunp | grep -E ":(4444|1337|8080|9001)"

apt update && apt --only-upgrade install <pkg>

title: Detect Exploitation - Easy-To-Pick 'Smart' Locks Gush Personal Data, FTC Finds
id: eddc3e09-9357-46d0-a9e6-7bba906fe6d2
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-26
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access

rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-26"
        description = "YARA Signature for "
    strings:
        $str = "Easy-To-Pick \'Smart\' Locks Gus" ascii wide
    condition:
        any of them
}

index=security sourcetype IN ("cisco:asa", "pan:traffic", "zeek_conn", "suricata", "WinEventLog:Security")
("Easy-To-Pick Smart Locks Gush Personal D")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, dest_host, signature
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count

message: "*Easy-To-Pick Smart Locks Gush Personal D*"

CommonSecurityLog
| where Message has "Easy-To-Pick Smart Locks Gush Personal D"
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Activity
| extend DetectionRule = "iShareStuff-CTI-Compiled"
| sort by EventCount desc