Category Archives: security

computing, security

Who watches the certificate authorities?

Leave a comment

In November, I was following a news story the Washington Post broke about Trustcor, a Certificate Authority with root certificates pre-loaded in all popular browsers. A few academics identified some problematic relationships and facts about Trustcor that puts into question the process used by Chrome, Firefox, and Safari to determine which companies can issue the certificates that our browsers use to indicate a connection is secure. From the article:

The website site lists a contact phone number in Panama, which has been disconnected, and one in Toronto, where a message had not been returned after more than a week. The email contact form on the site doesn’t work. The physical address in Toronto given in its auditor’s report, 371 Front St. West, houses a UPS Store mail drop.

Would this company pass your audit? I was familiar with the role played by root certificates in browsers, and understood there was an assessment process for inclusion completed by the teams that build browsers. I get that a process can’t catch everything, but I was surprised about how flagrant this evidence of untrustworthy behaviour was.

I was pleased to see in the Post’s follow up story that Mozilla and Microsoft are removing Trustcor’s root cert from their browsers. This follow-up article also presents the possibility that the root cert was leveraged by Packet Forensics for man-in-the-middle interception of encrypted traffic:

Packet Forensics first drew attention from privacy advocates a dozen years ago.

In 2010, researcher Chris Soghoian attended an invitation-only industry conference nicknamed the Wiretapper’s Ball and obtained a Packet Forensics brochure aimed at law enforcement and intelligence agency customers.

The brochure was for a piece of hardware to help buyers read web traffic that parties thought was secure. But it wasn’t.

“IP communication dictates the need to examine encrypted traffic at will,” the brochure read, according to a report in Wired. “Your investigative staff will collect its best evidence while users are lulled into a false sense of security afforded by web, email or VOIP encryption,” the brochure added.

Researchers thought at the time that the most likely way the box was being used was with a certificate issued by an authority for money or under a court order that would guarantee the authenticity of an impostor communications site.

They did not conclude that an entire certificate authority itself might be compromised.

Can you imagine the potential for man-in-the-middle abuse by ISPs and VPN service providers if they had root certificates in our browsers (examples of untrustworthy behaviour by VPN providers)? Given the challenges with this model, it’s interesting we haven’t seen more evidence of widespread abuse:

  • Was this situation isolated and unique?
  • Why doesn’t every malicious actor get a root certificate?
  • Are there limited incentives to intercepting traffic?
  • Perhaps regular law/ethics are sufficient to deter intercepting traffic?
  • Is this happening everywhere all the time, and there’s limited impact?
  • Perhaps most traffic isn’t of value, so traffic interception is limited and targeted?

I recommend reading Delegating trust is really, really, really hard, a reflection on the matter by Cory Doctorow. Hopefully, the Trustcor story brings greater attention to the issue, and more attention will be paid by development teams & users to the root certificates pre-loaded in their browsers.

computing, project, security

Exploring Bluetooth Trackers at GeekWeek 7.5

Leave a comment

I recently participated in GeekWeek 7.5, the Canadian Centre for Cyber Security’s (CCCS) annual cybersecurity workshop. I was assigned to a team of peers in banking, telecom, government and academia. We were to work together on analyzing how Bluetooth item trackers (eg: Apple AirTags, Tile) can be covertly used for malicious purposes, and developing processes and tools to detect them.

It was my first time attending the event, and I wasn’t sure what to expect. Here’s how it worked. The CCCS builds teams from the pool of GeekWeek applicants, based on interests and skills identified by the applicant in the application process. Leading up to the event, CCCS appoints a team lead, who defines goals for the team.

A map with a drive to Vaughan that was tracked at multiple points.
Testing a homemade AirTag clone

I was appointed as a team co-lead and assigned a team. My co-lead and I were to define a challenge in the IoT space. Inspired by recent headlines concerning stalking facilitated by AirTags, my co-lead suggested analyzing how item trackers can be covertly used for malicious purposes, and developing processes and tools to detect them.

The team worked in 5 streams:

Collecting Data

An existing baseline data collection tool was modified for our purposes for logging Bluetooth LE data for further analysis.
https://github.com/raudette/geekweek-7.5_1.3_loggingble

Detect Stealth AirTag Clones

“Can you find my stealth AirTag clone in this data?” we asked the data scientist on our team.
🍰 <piece of cake>, he responded.

As various news outlets reported about the malicious use of these trackers, manufacturers implemented anti-stalking measures which were quickly defeated by research efforts such as find-you. The find-you tracker avoids detection by rotating through identifiers – to an iPhone, it appears no differently from walking past other people with iPhones.

The team built find-you stealth trackers which rotated through 4 keys and went to work. We wanted to see if we could develop a technique for detecting and identifying the trackers. Data was collected by stalking ourselves, walking through busy urban areas with find-you trackers, and logging all Apple Find My Bluetooth advertisements.

Our hypothesis was that we could identify the find-you tracker based on signal strength patterns. We believed that the signal strength of the find-you tracker we were wearing would be consistent over time, as its location relative to our data logger wouldn’t change, and other Find My devices would vary, as we walked past other pedestrians carrying devices.

A team member assessed the data and built a model for identifying the keys based on signal strength.

Stealth Tag Easily Identified
Stealth Tag Easily Identified

The stealth tag, with its four keys, could easily be picked out in the data.

We experimented with randomizing the transmit power and time between key rotations of the stealth tracker.

Stealth Tag with Varying Transmit Power

Even at its lowest transmit power, the stealth tag’s four keys could still be could easily be picked out in the data.

Enhancing Stealth AirTag Clones

We created a “SneakyAirTag“, which tried to increase the stealthiness of Positive Security’s Find-You tag, found here: https://github.com/positive-security/find-you, which itself was built on the excellent work of: https://github.com/seemoo-lab/openhaystack

It tries to improve the stealthiness as follows:

  • Rotates keys on a random interval, between 30 and 60 seconds (Find-You rotates every 30 seconds)
  • Transmits at random power levels, in an attempt to avoid detection based on a consistent signal strength.

In our testing, even with these changes, we were still able to identify stealth tags in an area with other Apple Find My devices. Even at the ESP32’s lowest power level, the stealth tracker can be identified as the signal strength of the stealth tracker is higher than other devices the vicinity of the tracked subject.

Further areas for exploration would be reducing signal strength with shielding material or some other means, and adding an accelerometer such that the device only transmitted Bluetooth advertisements when the target subject is in motion.

Building a Clone Tile Tracker

The team was inspired by Seemoo Lab‘s work on the AirTag. Could we do similar things with the Tile tracker?

And, we figured out some things, but got stumped. Tile uses the Bluetooth MAC address to track a Tile. We got our clone Tile to the point where we could take MAC of a tile registered to our account, load our firmware with the MAC onto an ESP32, and walk around with our Tile app and it would track it.

But, it seemed like if we sent our Tile’s MAC ID to someone else to load on to their ESP32, and track with their Tile app, it wouldn’t report the location. And, although Tile reports thousands of users in my area, even a genuine Tile didn’t seem to get picked up by other Tile users walking through office food courts, malls, or transit hubs. As a result, at the end of two weeks, many questions remained unanswered.

We also experimented with altering transmit power and rotating through MAC addresses as a means of avoiding detection. Our work can be found here:
https://github.com/raudette/geekweek-7.5_1.3_tileclone

Blueprints

One of our team members had access to a few HackRF One Software Defined Radios (SDRs), and set about learning how to use them. They wanted to duplicate the results of a paper that demonstrated that with an SDR, one can identify individual bluetooth devices based on differences in how they transmit as a result of minute manufacturing imperfections. The team member called their Bluetooth device fingerprint a Blueprint, and documented their work here: https://github.com/raudette/geekweek-7.5_1.3_blueprint

Overall Experience

The experience of stepping away from the day-to-day, learning about different technologies and building things was very similar to my previous experiences participating in corporate hackathons.

What made GeekWeek exciting for me was leading a team of people from different companies, with different professional backgrounds. At a corporate hackathon, everyone already knows their teammates, what they’re capable of, they share the same corporate culture, they typically work on the same software stack, and have the same collaboration tools pre-loaded on their laptops. At GeekWeek, it was interesting just breaking down the problem, and finding out who had what tools, what experience, and was best suited to take on a task. Also, it was interesting to hear about everyone’s professional work – some were really pushing boundaries in their fields.

I hope to participate again in the future!

computing, security, thoughts

Mesh network in my neighborhood. Not how I had envisioned it.

Leave a comment

I got an email from Amazon today. I’m automatically opted-in to “Amazon Sidewalk”, unless I choose to opt out. Amazon Sidewalk allows devices participating their Sidewalk program to connect to the Internet through Amazon devices, like the Amazon Echo.

Amazon Sidewalk – a mesh network for Amazon devices to connect to the Internet:
https://www.amazon.com/Amazon-Sidewalk/b?ie=UTF8&node=21328123011

Not exactly how I’d envisioned a neighborhood mesh, but their “read the fine print to opt out” strategy will probably work better than my asking neighbors to build a network.

computing, security

Detect web skimming with web automation

Leave a comment

I was listening to the Darknet Diaries Magecart episode before the holidays and was thinking, “Magecart attacks should be pretty easy to detect with web automation”, so I wrote up how I would do it. If you run a web property that processes sensitive data, it might be of interest. Check it out here: https://articles.hotelexistence.ca/posts/browserautomationtodetectwebskimming/

I have been thinking about changing how I host this site, and decided to try it out for this article – more on this later.

computing, security, work

Security: Not a new problem

Leave a comment

Here’s an OLD story about famous scientist Richard Feynman, who had fun cracking the safes of all his fellow scientists working on the Manhattan project in WW2:
http://www.cs.virginia.edu/cs588/safecracker.pdf (this is a long read best left for an evening at home).

What’s interesting is how easily you can draw parallels to the security issues we face today.  You could almost swap the word “safe” with “web application”, and “atom bomb design” with “financial data”, and the story almost carries over to today. These safes/filing cabinets contained documents relating to the atomic bomb (ie: something worth protecting).

To break the safes, he used:

  • social techniques
  • default safe codes
  • known design defects

Sound familiar?  What’s funny, is the reaction to his activities was not to improve security, but to try keep him out of the rooms, and pretend the problem didn’t exist.