This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware

You were promised Zoom news last week, but due to a late night of writing, that story was delayed to this week. So what’s the deal with Zoom? Google, SpaceX, and even the government of Taiwan and the US Senate have banned Zoom. You may remember our coverage of Zoom from nearly a year ago, when Apple forcibly removed the Zoom service from countless machines. The realities of COVID-19 have brought about an explosion of popularity for Zoom, but also a renewed critical eye on the platform’s security.

“Zoombombing”, joining a Zoom meeting uninvited, made national headlines as a result of a few high profile incidents. The US DOJ even released a statement about it. Those incidents seem to have been a result of Zoom default settings: no meeting passwords, no “waiting room”, and meeting IDs that persist indefinitely. A troll could simply search google for Zoom links, and try connecting to them until finding an active meeting. Ars ran a great article on how to avoid getting zoombombed (thanks to Sheldon for pointing this out last week).

There is another wrinkle to the Zoom story. Zoom is technically an American company, but its Chinese roots put it in a precarious situation. Recently it’s been reported that encryption keying is routed through infrastructure in China, even though the calling parties are elsewhere. In some cases, call data itself goes through Chinese infrastructure, though that was labeled as a temporary bug. Zoom was also advertising its meetings as having end-to-end encryption. That claim was investigated, and discovered to be false. All meetings get decrypted at Zoom servers, and could theoretically be viewed by Zoom staff.

Cabinet Meeting

Why does it matter? Is this just anti-Chinese rhetoric? Well, no. When a service like Zoom is hosted on a server in a given country, that service is subject to that country’s laws. China has a rather dismal history of abusing communications infrastructure to spy on and persecute its own citizens. (I am aware that the US has a dismal history there as well. I’m not excited about my conversations being in the clear on a US server, either.) While that’s not necessarily a huge problem for a school doing distance learning, government leaders should probably avoid holding cabinet meetings over the service.

How Secure is that Fingerprint Scanner?

It’s a Hollywood trope at this point. Our hero has to infiltrate the super secret organization, and to get in, he has to defeat a fingerprint scanner. No problem, the hero has lifted a fingerprint earlier in the movie, and with a bit of ingenuity, fools the fingerprint scanner. That’s just the movies, and real fingerprint readers are more secure, right? Well, the Talos group at Cisco put the myth to the test. They used a 25 micron UV 3d printer to make a series of molds, and then tried different materials to cast the fake prints. A fabric glue seemed to work the best, as it was able to fool capacitive sensors as well as visual.

A mold could be calculated and printed in an hour in 25-micron resolution. There is some additional time for the cast itself to set, and they conclude that the attack isn’t something that can be performed quickly.

Phones seemed to fare the worst, with a success rate somewhere around 80%. Of particular interest is the devices that were difficult to compromise. Interestingly, Windows Hello, a part of Windows 10, was entirely resilient to their attacks. The Talos researchers suggest that the key here is the comparison algorithm used to compare the scanned fingerprints. Another winner was the pair of USB keys that use a fingerprint scanner to unlock the stored data. Those keys also shrugged off this attack. The Talos researchers made sure to point out that this doesn’t mean that these devices are secure against this type of attack. Their work was intentionally low-budget, and it’s likely a more determined, well-funded attacker could overcome the rest of the devices.

But even if you just want to play around with this at home, with a little effort you can fool face and iris recognition yourself. And all this aside, you shouldn’t have to use biometric information in place of passwords anyway.

Browser News

Running Firefox or the Tor browser anywhere? Go update now, make sure you on 74.0.1 or better (or 68.6.1 if you’re using Firefox ESR). There are a pair of use-after-free bugs that are being actively exploited. There aren’t many more details available at the moment, possibly because of related bugs that still need to be fixed. According to the researcher that found the bugs: “There is still lots of work to do and more details to be published (including other browsers). Stay tuned.”

On the Google side of the fence, the big news is that the new same-site cookies policy is being rolled back. The Chrome blog has a link to a great explainer of the potential problem with 3rd party cookies, and how the samesite policy changes can help.

Mobile Apps and Input Validation

A novel paper came across my digital desk this week (PDF) that introduces a new way to ask an old question: What secrets is this closed-source app hiding? We’ve talked about backdoors, hard-coded passwords, and hidden administrator menus in the past. Most of the time, these are unintentional; bits of debugging code that were forgotten about and never removed. In the linked paper, a technique was developed to examine the input validation code of an app, looking for hidden hardcoded options.

For example, a 3rd party screen lock will take user input, and then make a system call to compare that input against the system password. If there is a string compare that happens before the expected system call, then there might be a secret backdoor password hard-coded into the app. In another example, a translation app had a secret menu, unlocked by entering a hardcoded key, where debugging tasks could be done, like disabling ads.

After scanning 150k Android apps, about 12k were discovered to have hardcoded backdoors, passwords, or debugging menus. In other words, just over 8% of the most popular Android apps have some suspicious behavior built-in.

Via Heise Online

Yet Another Reason to Remove Bloatware

Ahhh, there’s not many things that satisfy quite like unboxing new hardware for the first time. You finally pulled the trigger on a new laptop, and now it’s ready to boot up for the first time. Many of us have a similar policy in these situations: Boot the laptop, uninstall the OEM bloatware. If that isn’t your habit, then maybe
[Bill Demirkapi]’s research on HP bloatware will convince you.

There’s quite a bit here, but the most interesting attack chain, an RCE, takes advantage of some seemingly unrelated issues. The first is an open redirect on HPs site. This seem innocuous enough. “” would automatically redirect you to Google. The second issue is an HP service that registers a custom URL protocol. That protocol downloads and runs or opens the downloaded file. Before starting the download, there is check run that this download is coming from an HP domain. The open redirect comes in handy here, as the redirect is followed after that domain check is performed. An official looking link can then trigger HP’s update downloader, which then will automatically open a downloaded zip file. Yes, it requires two interactions to compromise, but is a clever chain nonetheless.

Covid-19 Scamming

Yet another installment of our Coronavirus scamming story. This week we’ll look at emails claiming to be from the US Small Business Administration (SBA).

I received this email Tuesday the 7th, and took a moment to realize it was a fake. The first giveaway is that the attachment is a .img, rather than a PDF or other image file. That disk image contains a “SBA_Disaster_Application_Confirmation_Documents_COV_Relief_doc.exe” executable. There are a few other tip-offs that this probably isn’t a legitimate communication, like the spelling of “centres” and “endeavour”, using the British spellings. The last, and perhaps most obvious flaw, is that the date has already passed.

Hold on to your hats, because we’re about to speculate. You see, this email came in only a few hours after I filled out some online paperwork for an Economic Injury Disaster Loan, on the official SBA website. I very nearly fell for this, because the timing was so spot-on. It appears that the SBA is leaking information about grant applicants, and someone is using that leak to run a phishing campaign.

9 thoughts on “This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware

  1. Thanks for pointing out that spying by *any* government or other entities on their citizens is bad.

    And please Hackaday, if you want to continue deleting my comments, please do so, but don’t delete comments of people replying to me. You can do it. And add the edit button.

    1. But spying by Apple and Google is OK. You agree to their terms and conditions after all, every time you use their service…even when they embed their trojan bloatware without your knowledge or consent.

  2. “When a service like Zoom is hosted on a server in a given country, that service is subject to that country’s laws.”


    “The United States government has the right to demand the emails of anyone in the world from any email provider headquartered within US borders, Department of Justice (DoJ) lawyers told a federal appeals court on Wednesday”

    1. Calling it speculation based on a sample size of one…seriously? Your final claim is like yelling fire in a crowded theater. Neither the sourced article nor the IBM research behind it made that leap. I’d love to hear any additional data you have that lead you to that conclusion, e.g. a large number of similar incidents from others. Just say it was an eerie coincidence and leave the tinfoil hat implications to the reader…or responsibly state it as an open question while stressing it is uncorroborated.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.