Privacy, Security Archive

Google’s own Project Zero security research effort, which often finds and publishes vulnerabilities in both other companies’ and its own products, set its sights on Android once more, this time focusing on third-party kernel drivers. Android’s open-source ecosystem has led to an incredible diversity of manufacturers and vendors developing software that runs on a broad variety of hardware. This hardware requires supporting drivers, meaning that many different codebases carry the potential to compromise a significant segment of Android phones. There are recent public examples of third-party drivers containing serious vulnerabilities that are exploited on Android. While there exists a well-established body of public (and In-the-Wild) security research on Android GPU drivers, other chipset components may not be as frequently audited so this research sought to explore those drivers in greater detail. Seth Jenkins They found a whole host of security issues in these third-party kernel drivers in phones both from Google itself as well as from other companies. An interesting point the authors make is that because it’s getting ever harder to find 0-days in core Android, people with nefarious intent are looking at other parts of an Android system now, and these kernel drivers are an inviting avenue for them. They seem to focus mostly on GPU drivers, for now, but it stands to reason they’ll be targeting other drivers, too. As usual with Android, the discovered exploits were often fixed, but the patches took way, way too long to find their way to end users due to the OEMs lagging behind when it comes to sending those patches to users. The authors propose wider adoption of Android APEX to make it easier to OEMs to deliver kernel patches to users faster. I always like the Project Zero studies and articles, because they really take no prisoners, and whether they’re investigating someone else like Microsoft or Apple, or their own company Google, they go in hard, do not surgarcoat their findings, and apply the same standards to everyone.

William Brown, developer of webauthn-rs, has written a scathing blog post detailing how corporate interests – namely, Apple and Google – have completely and utterly destroyed the concept of passkeys. The basic gist is that Apple and Google were more interested in control and locking in users than in providing a user-friendly passwordless future, and in doing so have made passkeys effectively a worse user experience than just using passwords in a password manager. Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can’t be extracted or exported in any capacity. Both Chrome and Safari will try to force you into using either hybrid (caBLE) where you scan a QR code with your phone to authenticate – you have to click through menus to use a security key. caBLE is not even a good experience, taking more than 60 seconds work in most cases. The UI is beyond obnoxious at this point. Sometimes I think the password game has a better ux. The more egregious offender is Android, which won’t even activate your security key if the website sends the set of options that are needed for Passkeys. This means the IDP gets to choose what device you enroll without your input. And of course, all the developer examples only show you the options to activate “Google Passkeys stored in Google Password Manager”. After all, why would you want to use anything else? William Brown The whole post is a sobering read of how a dream of passwordless, and even usernameless, authentication was right within our grasp, usable by everyone, until Apple and Google got involved and enshittified the standards and tools to promote lock-in and their own interests above the user experience. If even someone as knowledgeable about this subject as Brown, who writes actual software to make these things work, is advising against using passkeys, you know something’s gone horribly wrong. I also looked into possibly using passkeys, including using things like a Yubikey, but the process seems so complex and unpleasant that I, too, concluded just sticking to Bitwarden and my favourite open source TFA application was a far superior user experience.

When this command line option is used with curl on macOS, the version shipped by Apple, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification. A secondary check that was not asked for, is not documented and plain frankly comes completely by surprise. Therefore, when a user runs the check with a trimmed and dedicated CA cert file, it will not fail if the system CA store contains a cert that can verify the server! This is a security problem because now suddenly certificate checks pass that should not pass. Daniel Stenberg Absolutely wild that Apple does not consider this a security issue.

The supermassive leak contains data from numerous previous breaches, comprising an astounding 12 terabytes of information, spanning over a mind-boggling 26 billion records. The leak, which contains LinkedIn, Twitter, Weibo, Tencent, and other platforms’ user data, is almost certainly the largest ever discovered. Vilius Petkauskas at cybernews Holy cow.

Government investigators in the United States have used push notification data to pursue people of interest, Sen. Ron Wyden (D-Ore.) said in a letter Wednesday to the Justice Department, revealing for the first time a way in which Americans can be tracked through a basic service provided by their smartphones. Wyden’s letter said the Justice Department had prohibited Apple and Google from discussing the technique and asked it to change the rule, noting that his office had received a tip that foreign governments had also begun requesting the push-notification data. Drew Harwell for The Washington Post Not surprising, of course. The one nugget of good news here is that while Apple’s policy is to hand over this data after a mere subpoena (“privacy is a fundamental human right“, everybody), Google requires an actual court order, meaning federal officials must convince a judge of the validity of the request. Assuming this is not a nebulous secret backroom deal but a proper judicial process, I’m actually okay with that – law enforcement does need the ability to investigate potential criminals, and as long as this happens within the boundaries of the law and properly overseen and approved by the judiciary every step along the way, I can support it.

There has been quite a bit of documentation about exploiting the CANON Printer firmware in the past. For some more background information I suggest reading these posts by SYNACKTIV, doar-e and DEVCORE. I highly recommend reading all of it if you want to learn more about hacking (CANON) Printers. The TL;DR is: We’re dealing with a Custom RTOS called DRYOS engineered by CANON that doesn’t ship with any modern mitigations like W^X or ASLR. That means that after getting a bit acquainted with this alien RTOS it is relatively easy to write (reliable) exploits for it. Having a custom operating system doesn’t mean it’s more secure than popular solutions.

Threat actors are known for impersonating popular brands in order to trick users. In a recent malvertising campaign, we observed a malicious Google ad for KeePass, the open-source password manager which was extremely deceiving. We previously reported on how brand impersonations are a common occurrence these days due to a feature known as tracking templates, but this attack used an additional layer of deception. The malicious actors registered a copycat internationalized domain name that uses Punycode, a special character encoding, to masquerade as the real KeePass site. The difference between the two sites is visually so subtle it will undoubtably fool many people. We have reported this incident to Google but would like to warn users that the ad is still currently running. Ad blockers are security tools. This proves it once again.

I recently got my hands on an ordinary-looking iPhone-to-HDMI adapter that mimics Apple’s branding and, when plugged in, runs a program that implores you to “Scan QR code for use.” That QR code takes you to an ad-riddled website that asks you to download an app that asks for your location data, access to your photos and videos, runs a bizarre web browser, installs tracking cookies, takes “sensor data,” and uses that data to target you with ads. The adapter’s app also kindly informed me that it’s sending all of my data to China. Just imagine what kind of stuff is happening that isn’t perpetrated by crude idiots, but by competent state-sponsored actors. I don’t believe for a second that at least a number of products from Apple, Dell, HP, and so on, manufactured in Chinese state-owned factories, are not compromised. The temptation is too high, and even if, say, Apple found something inside one of their devices rolling off the factory line – what are they going to do? Publicly blame the Chinese government, whom they depend on for virtually all their manufacturing? You may trust HP, but do you trust the entire chain of people and entities controlling their supply chain?

Domain names ending in “.US” — the top-level domain for the United States — are among the most prevalent in phishing scams, new research shows. This is noteworthy because .US is overseen by the U.S. government, which is frequently the target of phishing domains ending in .US. Also, .US domains are only supposed to be available to U.S. citizens and to those who can demonstrate that they have a physical presence in the United States. The answer is GoDaddy.

The mess I’m describing — end-to-end encryption but with certain exceptions — may be a healthy balance of your privacy and our safety. The problem is it’s confusing to know what is encrypted and secret in communications apps, what is not and why it might matter to you. To illuminate the nuances, I broke down five questions about end-to-end encryption for five communications apps. This is straightforward and good overview of what, exactly, is end-to-end encrypted in the various chat and IM applications we use today. There’s a lot of ifs and buts here.

The UK’s elections watchdog has revealed it has been the victim of a “complex cyber-attack” potentially affecting millions of voters. The Electoral Commission said unspecified “hostile actors” had managed to gain access to copies of the electoral registers, from August 2021. Hackers also broke into its emails and “control systems” but the attack was not discovered until October last year. The watchdog has warned people to watch out for unauthorised use of their data. That seems like a state-level attack, and such data could easily be used for online influence campaigns during elections, something that is happening all over the western world right now. I wonder just how bad the hack actually was? “Millions of voters” sounds bad, but… The commission says it is difficult to predict exactly how many people could be affected, but it estimates the register for each year contains the details of around 40 million people. Holy cow.

I reversed the firmware of my Garmin Forerunner 245 Music back in 2022 and found a dozen or so vulnerabilities in their support for Connect IQ applications. They can be exploited to bypass permissions and compromise the watch. I have published various scripts and proof-of-concept apps to a GitHub repository. Coordinating disclosure with Garmin, some of the vulnerabilities have been around since 2015 and affect over a hundred models, including fitness watches, outdoor handhelds, and GPS for bikes. Raise your hands if you’re surprised. Any time someone takes even a cursory glance at internet of things devices or connected anythings that isn’t a well-studied platform from the likes of Apple, Google, or Microsoft, they find boatloads of security issues, dangerous bugs, stupid design decisions, and so much more.

So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set. This is especially true for laptop systems where physical access cannot be prevented for obvious reasons. For servers in colocation, the risk of physical access is not null. And finally for many servers, the risk of a rogue employee somewhere in the supply chain, or the maintenance chain cannot be easily ruled out. The author makes a compelling case, but my knowledge on this topic is too limited to confidently present this article as a good one. I’ll leave it to those among us with more experience on this subject to shoot holes in the article, or to affirm it.

In a joint effort, tech giants Apple, Google, and Microsoft announced Thursday morning that they have committed to building support for passwordless sign-in across all of the mobile, desktop, and browser platforms that they control in the coming year. Effectively, this means that passwordless authentication will come to all major device platforms in the not too distant future: Android and iOS mobile operating systems; Chrome, Edge, and Safari browsers; and the Windows and macOS desktop environments. A passwordless login process will let users choose their phones as the main authentication device for apps, websites, and other digital services, as Google detailed in a blog post published Thursday. Unlocking the phone with whatever is set as the default action — entering a PIN, drawing a pattern, or using fingerprint unlock — will then be enough to sign in to web services without the need to ever enter a password, made possible through the use of a unique cryptographic token called a passkey that is shared between the phone and the website. Passwords are a terrible security practice, and while password managers make the whole ordeal slightly less frustrating, using my phone’s fingerprint reader to log into stuff seems like a very welcome improvement.