TunnelBear, the privacy and security-focused VPN service provider, has undergone a third-party audit that it is making public. Beginning in the winter of 2016, Cure53 performed infrastructure audits of TunnelBear apps, servers, and clients.
The first stage was a 30-day review of everything from the accessible API to clients, uncovering some critical and high priority vulnerabilities. Six months later, Cure53 returned for an 8-day review of fixes and a general rereview of the infrastructure, finding no critical vulnerabilities and a single high priority vulnerability that was swiftly fixed.
It’s great to see a provider seeking third-party audits and making them public. VPN providers are positioned to easily and quietly spy on users to exploit their data, just by the nature of the services they provide.
However, the audit’s focus on security leaves evaluation of marketing claims by the wayside. For example, the short technical summary pdf that is available doesn’t mention or verify TunnelBear’s “no logging” claim at all.
Hopefully, transparent evaluation of such claims occurs in future audits, and other VPN providers would do well to follow TunnelBear’s example in not only conducting independent audits, but making them public as well. While using an untrusted VPN provider is certainly not recommended, there are some things you can do to reduce a VPN provider’s visibility into your traffic:
The world of the Internet of Things (IoT) is known for goofy gadgets and practical tools that, almost as a rule, are both insecure and connected to the Internet. Securely developing, producing, and maintaining these devices is certainly no small task, and we aren’t the only ones to have spilled gallons of e-ink on this already, so we’ll just get to the goods. Some models of a lock from LockState were rendered inoperable and unable to remotely lock after a botched software update.
The core issue is a common mistake for device tinkerers everywhere: cross-flashing firmware to different devices. Some 6i model locks were given an update for 7i model locks, breaking their remote locking and remote updating features. Remedies require returning locks for service, or requesting replacements, which could take a week or more. Fortunately, the devices can still be unlocked with a physical key, but that’s just not very cyberpunk.
For 17 days, from July 17 to August 4, server and network management products from NetSarang were infected with an advanced backdoor, giving attackers full access to infected machines and the networks they were on. Compromising NetSarang’s infrastructure, attackers backdoored a signed dll that was then delivered to customers.
The backdoor used tiered layers of encrypted code to hide itself, only activating on a specific DNS TXT record response. Thankfully, watchful system administrators noticed a machine making strange DNS requests, leading to the investigation that uncovered the backdoor rather quickly.
Similarly, attackers have recently been phishing Google Chrome extension developers. These attacks use stolen developer account credentials to inject malicious code into Google Chrome extensions, which are then delivered to users. Though seemingly focused on spam, advertiser substitution and affiliate program scams, infected extensions can also steal other credentials to be used as other points of access for attackers.
While effective, these supply-chain attacks additionally undermine confidence in the security of update mechanisms and the integrity of updates, which may lead some to leave software unpatched and insecure. It’s crucial for vendors, developers, and anyone that delivers software to very carefully monitor update infrastructure and published updates to ensure users can trust updates aren’t tainted with malware.