security – D’Arcy Norman dot net

Fitbit on security

post updated with official response from Fitbit

I contacted Fitbit Support to ask them about this article, describing security vulnerabilities in the bluetooth radio of the wearable Fitbit devices. I’d sent it through their website, so I don’t have the exact text, but it was something like:

Do you have any information for Fitbit users in response to the Engaget article? (with a link to the article)

Their support team responded later that day with this:

Thank you for calling our attention to Engadget’s article.

We have clip and wristband trackers, both trackers type when are worn according to instructions are secure, pegs of the clasps should have gotten through the wristband base, in order to do this, we suggest to our customers, to press both sides of each peg with a plastic card.

However, a fall or a sudden pressure on your wrist may make the clasp accidentally unlatches

In order to add safety to the Flex clasps, there are gadget for sale through online retailers “safety rings” are called, that provide extra strength in case of accident.

How all wearable products, when possible we suggest replacing wristbands, in case they feel “loose” to the clasp pegs.

Any further question, please let us know, we are glad to assist you.

So. Um. The solution to an unsecured bluetooth radio is to make really sure that the clasp on the wristband is properly fastened. Problem solved.

Update: 2015-10-13 Fitbit has posted a statement:

On Wednesday October 21, 2015, reports began circulating in the media based on claims from security vendor, Fortinet, that Fitbit devices could be used to distribute malware. These reports are false. In fact, the Fortinet researcher who originally made these claims, Axelle Apvrille, has confirmed to Fitbit that this was only a theoretical scenario and is not possible. Fitbit trackers cannot be used to infect user’s devices with malware. We want to reassure our users that it remains safe to use their Fitbit devices and no action is required.

As background, Fortinet first contacted us in March to report a low-severity issue unrelated to malicious software. Since that time we’ve maintained an open channel of communication with Fortinet. We have not seen any data to indicate that it is possible to use a tracker to distribute malware.

We have a history of working closely with the security research community and always welcome their thoughts and feedback. The trust of our customers is paramount. We carefully design security measures for new products, monitor for new threats, and rapidly respond to identified issues. We encourage individuals to report any security concerns with Fitbit’s products or online services to security@fitbit.com. More information about reporting security issues can be found online at https://www.fitbit.com/security.

blocking distributed botnet attacks against WordPress (multisite)

I checked the Activity Monitor page1 for UCalgaryBlogs this morning, and noticed that there had been several thousand attempts by people (or “people”) to login using the usernames “admin” (the default WordPress admin account, which isn’t what’s used on UCalgaryBlogs) and “siteadmin” (which is the username for our server – scripts must have sniffed it from blog posts on the main site…)

Curious. I’d installed the fantastic Limit Login Attempts plugin to prevent people from brute-forcing logins, but that plugin only kicks in if the same IP address hits the login form repeatedly. This botnet attack was different – each request had a different IP address, and a different user-agent string. So Limit Login Attempts wasn’t blocking them, and my htaccess user-agent filter wasn’t catching them because they were either valid user-agents, or close enough to get through.

Looks like they were using a dictionary attack, starting at aardvark and working through zyzzyva. Thankfully, I don’t use actual words for passwords, but I decided to change the password to use something stronger than I’d been using. Thanks to 1Password for making that trivial. I don’t actually know the password now. And it has nothing to do with any word found in a dictionary (except that it might use some of the same ascii characters).

Some quick googling for “wordpress distributed botnet protect” turned up a new (to me) plugin called Botnet Attack Blocker. Sounds interesting. It was written in response to some recent distributed botnet attacks, and handles logins spread across different IP addresses.

Installed. Activated on the main blog site. And the attack stopped instantly. I can still login from the campus network even if the plugin kicks in and blocks admin logins. But the botnets can’t continue to brute-force passwords.

Screen Shot 2013 10 16 at 11 48 40 AM

So, now it’s been over 3 hours since activating the plugin. And the attack has (for now) been blocked.

Lessons learned:

Do not (ever) use actual words in passwords. Ever. Generate something secure, and use a tool to store/retrieve them.
Keep up to date on the security environment for the tools – including WordPress. I hadn’t been aware of a distributed botnet attack problem recently, nor of a plugin developed specifically to block that.
Install Limit Login Attempts to stop single-IP-address attacks.
Install Botnet Attack Blocker to stop distributed botnet attacks.

using an old version of the WPMUDev Blog Activity plugin [↩]

Bruce Schneier on privacy, security, control, and google

[Bruce Schneier](http://www.schneier.com/) speaks at the 2010 EWI Cybersecurity Summit.

Granular explicit control over privacy is unnatural…

Electronic commerce produces data. Everything we do produces data. (in ways traditional cash-based commerce did not)

Businesses and governments are forcibly changing social norms. Who gets to make the rules?

**We are not Google’s customer. We are actually Google’s product, that they sell to their customer.**

Data is the pollution problem of the 21st century.

watchtower

a lone security camera watches students arrive on campus from the C-Train station.

MediaWiki and Access Control

I’ve been asked by a couple of people about ways to restrict access to pages in wiki.ucalgary.ca. My initial response was often something like “wha? that’s just wrong. you don’t lock down wikis…”

Then, they explained more about what they wanted to do, and why they couldn’t just leave the pages out In The Wild and trust that it was private through obscurity. Things like collaborative student experimental writing, where it would be a Bad Thing™ if things like the Wayback Machine kept eternal snapshots of not-fully-baked writing, which could come back to haunt someone later. Shouldn’t have to throw the baby out with the bathwater – restricting access to pages within the wiki would let them play, without exposing them more than they’re comfortable with.

So I did some Googling over the last few months, and still haven’t come up with a solution I’m completely happy with. The closest I came to a workable solution is the Access Control extension – but that needed some tweaking before it would run as expected (my modified file), and I fear it exposes some pretty scary security risks. What happens if Joe Spamass edits Main_Page and adds a fake access control list to the page? I’ve installed it, but will be keeping a close eye on it, and maintaining nightly MySQL dumps of the wiki databases Just In Case™.

I also found this patch to enable a “restrict” feature, but it really just creates a “penalty box” where pages can be sent, and only people who are allowed to see the “penalty box” can see the pages – but there’s no fine granularity, it’s an all-or-nothing thing.

I really don’t know why this isn’t part of the core feature set of Mediawiki. Sure, the Wikipedia wouldn’t use it, but how many gazillion corporate/institutional wikis could benefit (or require) this feature? There are a lot of folks who are interested in this, but no real solutions that I’ve found…