UK lawmakers are sick and tired of shitty internet of things passwords and are whipping out legislation with steep penalties and bans to prove it. The new legislation, introduced to the UK Parliament this week, would ban universal default passwords and work to create what supporters are calling a “firewall around everyday tech.”

Specifically, the bill, called The Product Security and Telecommunications Infrastructure Bill (PSTI), would require unique passwords for internet-connected devices and would prevent those passwords from being reset to universal factory defaults. The bill would also force companies to increase transparency around when their products require security updates and patches, a practice only 20% of firms currently engage in, according to a statement accompanying the bill.

These bolstered security proposals would be overseen by a regulator with sharpened teeth: companies refusing to comply with the security standards could reportedly face fines of £10 million or four percent of their global revenues.

[…]

Source: The UK Just Banned Default Passwords and We Should Too

Also interesting: The Worst Passwords in the Last Decade (And New Ones You Shouldn’t Use)

As much as 38 percent of the Internet’s domain name lookup servers are vulnerable to a new attack that allows hackers to send victims to maliciously spoofed addresses masquerading as legitimate domains, like bankofamerica.com or gmail.com.

The exploit, unveiled in research presented today, revives the DNS cache-poisoning attack that researcher Dan Kaminsky disclosed in 2008. He showed that, by masquerading as an authoritative DNS server and using it to flood a DNS resolver with fake lookup results for a trusted domain, an attacker could poison the resolver cache with the spoofed IP address. From then on, anyone relying on the same resolver would be diverted to the same imposter site.

A lack of entropy

The sleight of hand worked because DNS at the time relied on a transaction ID to prove the IP number returned came from an authoritative server rather than an imposter server attempting to send people to a malicious site. The transaction number had only 16 bits, which meant that there were only 65,536 possible transaction IDs.

Kaminsky realized that hackers could exploit the lack of entropy by bombarding a DNS resolver with off-path responses that included each possible ID. Once the resolver received a response with the correct ID, the server would accept the malicious IP and store the result in cache so that everyone else using the same resolver—which typically belongs to a corporation, organization, or ISP—would also be sent to the same malicious server.

The threat raised the specter of hackers being able to redirect thousands or millions of people to phishing or malware sites posing as perfect replicas of the trusted domain they were trying to visit. The threat resulted in industry-wide changes to the domain name system, which acts as a phone book that maps IP addresses to domain names.

Under the new DNS spec, port 53 was no longer the default used for lookup queries. Instead, those requests were sent over a port randomly chosen from the entire range of available UDP ports. By combining the 16 bits of randomness from the transaction ID with an additional 16 bits of entropy from the source port randomization, there were now roughly 134 million possible combinations, making the attack mathematically infeasible.

Unexpected Linux behavior

Now, a research team at the University of California at Riverside has revived the threat. Last year, members of the same team found a side channel in the newer DNS that allowed them to once again infer the transaction number and randomized port number sending resolver-spoofed IPs.

 

Further Reading

DNS cache poisoning, the Internet attack from 2008, is back from the dead

The research and the SADDNS exploit it demonstrated resulted in industry-wide updates that effectively closed the side channel. Now comes the discovery of new side channels that once again make cache poisoning viable.

“In this paper, we conduct an analysis of the previously overlooked attack surface, and are able to uncover even stronger side channels that have existed for over a decade in Linux kernels,” researchers Keyu Man, Xin’an Zhou, and Zhiyun Qian wrote in a research paper being presented at the ACM CCS 2021 conference. “The side channels affect not only Linux but also a wide range of DNS software running on top of it, including BIND, Unbound and dnsmasq. We also find about 38% of open resolvers (by frontend IPs) and 14% (by backend IPs) are vulnerable including the popular DNS services such as OpenDNS and Quad9.”

OpenDNS owner Cisco said: “Cisco Umbrella/Open DNS is not vulnerable to the DNS Cache Poisoning Attack described in CVE-2021-20322, and no Cisco customer action is required. We remediated this issue, tracked via Cisco Bug ID CSCvz51632, as soon as possible after receiving the security researcher’s report.” Quad9 representatives weren’t immediately available for comment.

The side channel for the attacks from both last year and this year involve the Internet Control Message Protocol, or ICMP, which is used to send error and status messages between two servers.

“We find that the handling of ICMP messages (a network diagnostic protocol) in Linux uses shared resources in a predictable manner such that it can be leveraged as a side channel,” researcher Qian wrote in an email. “This allows the attacker to infer the ephemeral port number of a DNS query, and ultimately lead to DNS cache poisoning attacks. It is a serious flaw as Linux is most widely used to host DNS resolvers.” He continued:

The ephemeral port is supposed to be randomly generated for every DNS query and unknown to an off-path attacker. However, once the port number is leaked through a side channel, an attacker can then spoof legitimate-looking DNS responses with the correct port number that contain malicious records and have them accepted (e.g., the malicious record can say chase.com maps to an IP address owned by an attacker).

The reason that the port number can be leaked is that the off-path attacker can actively probe different ports to see which one is the correct one, i.e., through ICMP messages that are essentially network diagnostic messages which have unexpected effects in Linux (which is the key discovery of our work this year). Our observation is that ICMP messages can embed UDP packets, indicating a prior UDP packet had an error (e.g., destination unreachable).

We can actually guess the ephemeral port in the embedded UDP packet and package it in an ICMP probe to a DNS resolver. If the guessed port is correct, it causes some global resource in the Linux kernel to change, which can be indirectly observed. This is how the attacker can infer which ephemeral port is used.

Changing internal state with ICMP probes

The side channel last time around was the rate limit for ICMP. To conserve bandwidth and computing resources, servers will respond to only a set number of requests and then fall silent. The SADDNS exploit used the rate limit as a side channel. But whereas last year’s port inference method used UDP packets to probe which ports were designed to solicit ICMP responses, the attack this time uses ICMP probes directly.

“According to the RFC (standards), ICMP packets are only supposed to be generated *in response* to something,” Qian added. “They themselves should never *solicit* any responses, which means they are ill-suited for port scans (because you don’t get any feedback). However, we find that ICMP probes can actually change some internal state that can actually be observed through a side channel, which is why the whole attack is novel.”

The researchers have proposed several defenses to prevent their attack. One is setting proper socket options such as IP_PMTUDISC_OMIT, which instructs an operating system to ignore so-called ICMP messages, effectively closing the side channel. A downside, then, is that those messages will be ignored, and sometimes such messages are legitimate.

Another proposed defense is randomizing the caching structure to make the side channel unusable. A third is to reject ICMP redirects.

The vulnerability affects DNS software, including BIND, Unbound, and dnsmasq, when they run on Linux. The researchers tested to see if DNS software was vulnerable when running on either Windows or Free BSD and found no evidence it was. Since macOS uses the FreeBSD network stack, they assume it isn’t vulnerable either.

Source: Linux has a serious security problem that once again enables DNS cache poisoning | Ars Technica

If there’s one thing we learned it’s that no one learns anything. Here’s the top 9

Source: Top 200 Most Common Password List 2021 | NordPass

Thousands of Firefox cookie databases containing sensitive data are available on request from GitHub repositories, data potentially usable for hijacking authenticated sessions.

These cookies.sqlite databases normally reside in the Firefox profiles folder. They’re used to store cookies between browsing sessions. And they’re findable by searching GitHub with specific query parameters, what’s known as a search “dork.”

Aidan Marlin, a security engineer at London-based rail travel service Trainline, alerted The Register to the public availability of these files after reporting his findings through HackerOne and being told by a GitHub representative that “credentials exposed by our users are not in scope for our Bug Bounty program.”

Marlin then asked whether he could make his findings public and was told he’s free to do so.

“I’m frustrated that GitHub isn’t taking its users’ security and privacy seriously,” Marlin told The Register in an email. “The least it could do is prevent results coming up for this GitHub dork. If the individuals who uploaded these cookie databases were made aware of what they’d done, they’d s*** their pants.”

Marlin acknowledges that affected GitHub users deserve some blame for failing to prevent their cookies.sqlite databases from being included when they committed code and pushed it to their public repositories. “But there are nearly 4.5k hits for this dork, so I think GitHub has a duty of care as well,” he said, adding that he’s alerted the UK Information Commissioner’s Office because personal information is at stake.

[…]

Source: Thousands of Firefox users accidentally commit login cookies on GitHub • The Register

The EU is at it again. Recently Mozilla put out a position paper highlighting the latest dangerous move by busybody EU regulators who seem to think that they can magically regulate the internet without (1) understanding it, or (2) bothering to talk to people who do understand it. The issue is the Digital Identity Framework, which, in theory, is supposed to do some useful things regarding interoperability and digital identities. This could be really useful in enabling more end user control over identity and information (a key part of my whole Protocols, Not Platforms concept). But the devil is in the details, and the details are a mess.

It would force browsers to support a specific kind of authentication certificate — Qualified Web Authentication Certificates (QWACs) — but as Mozilla points out, that would be disastrous for security:

At the same time, the types of website certificates that browsers would be forced to accept, namely QWACs, are based on a flawed certificate architecture that is ill-suited for the security risks users face online today. In the years since the original eIDAS regulation was adopted in 2014, an increasing body of research has illustrated how the certificate architecture upon which QWACs are inspired – namely, extended validation certificates – lull individuals into a false sense of security that is often exploited for malicious purposes such as phishing and domain impersonation. For that reason, since 2019 no major browser showcases EV certificates directly in the URL address bar.

As such, should the revised Article 45 be adopted as is, Mozilla would no longer be able to honour the security commitments we make to the hundreds of millions of people who use our Firefox browser or any of the other browser and email products that also depend on Mozilla’s Root Program. It would amount to an unprecedented weakening of the website security ecosystem, and undercut the browser community’s ability to push back against authoritarian regimes’ interference with fundamental rights (see here and here for two recent examples).

As Mozilla notes, the EU can still fix this. Whether or not it does is an open question.

Source: EU’s Latest Internet Regulatory Madness: Destroying Internet Security With Its Digital Identity Framework | Techdirt

it’s also one of the few apps that offer end-to-end encryption by default. This means that no one other than you the other party can read your conversations. Even WhatsApp can’t read your conversations because it doesn’t have the key to un-encrypt your chats.

This was all true, except for one scenario: WhatsApp chats backed up to iCloud were all unencrypted, so if anyone got their hands on your iCloud backup, they could read all your messages pretty easily. But now, WhatsApp has an optional feature to protect your WhatsApp backups with the same two-factor authentication using a password or a secure key.

How to enable end-to-end encryption for WhatsApp backups over iCloud

Before we begin, you should know that WhatsApp end-to-end encryption depends on a password or a 64-digit secure key. If you lose your password, you won’t be able to restore your chats, so make sure you use a secure yet recognizable password. If you use something complicated, make sure to save it on your password manager (it can be iCloud Keychain or a third-party service like Bitwarden).

To get started, first update your WhatsApp application to the latest version. WhatsApp is slowly rolling this feature out to its two billion users, so if you don’t see it yet, try again in a couple of days.

Open WhatsApp, and from the “Settings” tab, go to “Chats.” Here, select “Chat Backups” and tap the “End-to-End Encrypted Backup” button. Tap the “Turn on” button and from the next screen, choose the “Create Password” option.

Source: Why You Should Encrypt Your WhatsApp Backups in iCloud

Rowhammer exploits that allow unprivileged attackers to change or corrupt data stored in vulnerable memory chips are now possible on virtually all DDR4 modules due to a new approach that neuters defenses chip manufacturers added to make their wares more resistant to such attacks.

Rowhammer attacks work by accessing—or hammering—physical rows inside vulnerable chips millions of times per second in ways that cause bits in neighboring rows to flip, meaning 1s turn to 0s and vice versa. Researchers have shown the attacks can be used to give untrusted applications nearly unfettered system privileges, bypass security sandboxes designed to keep malicious code from accessing sensitive operating system resources, and root or infect Android devices, among other things.

Further Reading

Once thought safe, DDR4 memory shown to be vulnerable to “Rowhammer”

All previous Rowhammer attacks have hammered rows with uniform patterns, such as single-sided, double-sided, or n-sided. In all three cases, these “aggressor” rows—meaning those that cause bitflips in nearby “victim” rows—are accessed the same number of times.

Bypassing all in-DRAM mitigations

Research published on Monday presented a new Rowhammer technique. It uses non-uniform patterns that access two or more aggressor rows with different frequencies. The result: all 40 of the randomly selected DIMMs in a test pool experienced bitflips, up from 13 out of 42 chips tested in previous work from the same researchers.

[…]

The effects of previous Rowhammer demonstrations have been serious. In one case, researchers were able to gain unrestricted access to all physical memory by flipping bits in the page table entry, which maps the memory address locations. The same research also demonstrated how untrusted applications could gain root privileges. In another case, researchers used Rowhammer to pluck a 2048-bit encryption key out of memory.

[…]

Source: DDR4 memory protections are broken wide open by new Rowhammer technique | Ars Technica

Intel has disclosed two high-severity vulnerabilities that affect a wide range of Intel processor families, allowing threat actors and malware to gain higher privilege levels on the device.

The flaws were discovered by SentinelOne and are tracked as CVE-2021-0157 and CVE-2021-0158, and both have a CVSS v3 score of 8.2 (high).

The former concerns the insufficient control flow management in the BIOS firmware for some Intel processors, while the latter relies on the improper input validation on the same component.

These vulnerabilities could lead to escalation of privilege on the machine, but only if the attacker had physical access to vulnerable devices.

The affected products, according to Intel’s advisory, are the following:

• Intel® Xeon® Processor E Family
• Intel® Xeon® Processor E3 v6 Family
• Intel® Xeon® Processor W Family
• 3rd Generation Intel® Xeon® Scalable Processors
• 11th Generation Intel® Core™ Processors
• 10th Generation Intel® Core™ Processors
• 7th Generation Intel® Core™ Processors
• Intel® Core™ X-series Processors
• Intel® Celeron® Processor N Series
• Intel® Pentium® Silver Processor Series

Intel hasn’t shared many technical details around these two flaws, but they advise users to patch the vulnerabilities by applying the available BIOS updates.

This is particularly problematic because motherboard vendors do not release BIOS updates often and don’t support their products with security updates for long.

Considering that 7th gen Intel Core processors came out five years ago, it’s doubtful that MB vendors are still releasing security BIOS updates for them.

As such, some users will be left with no practical way to fix the above flaws. In these cases, we would suggest that you set up a strong password for accessing the BIOS settings.

A third vulnerability affects cars

A third flaw for which Intel released a separate advisory on the same day is CVE-2021-0146, also a high-severity (CVSS 7.2) elevation of privilege flaw.

“Hardware allows activation of test or debug logic at runtime for some Intel(R) processors which may allow an unauthenticated user to potentially enable escalation of privilege via physical access.” – Intel’s advisory

This bug affects the following products:

Intel has released a firmware update to mitigate this flaw, and users will get it through patches supplied by the system manufacturer.

Positive Technologies, who discovered and reported the bug to Intel, says that the flaw could allow threat actors to gain access to highly sensitive information.

“One example of a real threat is lost or stolen laptops that contain confidential information in encrypted form,” says Mark Ermolov.

“Using this vulnerability, an attacker can extract the encryption key and gain access to information within the laptop. The bug can also be exploited in targeted attacks across the supply chain.”

“For example, an employee of an Intel processor-based device supplier could, in theory, extract the Intel CSME firmware key and deploy spyware that security software would not detect.”

Positive Technologies says that the flaw also affects several car models that use the Intel Atom E3900, including the Tesla Model 3.

Users should apply a BIOS update from the device vendor to address this flaw, so check your manufacturer’s website regularly.

[…]

Source: High severity BIOS flaws affect numerous Intel processors

[…]

Even those who consider themselves well educated about cyber crime and security threats—and who do everything they’ve been taught to do—can (and do!) still end up as victims. The truth is that, with enough time, resources, and skill, everything can be hacked.

The key to protecting your digital life is to make it as expensive and impractical as possible for someone bent on mischief to steal the things most important to your safety, financial security, and privacy. If attackers find it too difficult or expensive to get your stuff, there’s a good chance they’ll simply move on to an easier target. For that reason, it’s important to assess the ways that vital information can be stolen or leaked—and understand the limits to protecting that information.

[…]

Source: Securing your digital life, part one: The basics | Ars Technica

A very good 2 part article about how to stay relatively safe on internet

[…]

In a paper titled, The Security Risk of Lacking Compiler Protection in WebAssembly, distributed via ArXiv, the technical trio say that when a C program is compiled to WASM, it may lack anti-exploit defenses that the programmer takes for granted on native architectures.

The reason for this, they explain, is that security protections available in compilers like Clang for x86 builds don’t show up when WASM output is produced.

“We compiled 4,469 C programs with known buffer overflow vulnerabilities to x86 code and to WebAssembly, and observed the outcome of the execution of the generated code to differ for 1,088 programs,” the paper states.

“Through manual inspection, we identified that the root cause for these is the lack of security measures such as stack canaries in the generated WebAssembly: while x86 code crashes upon a stack-based buffer overflow, the corresponding WebAssembly continues to be executed.”

[….]

For those not in the know, a stack is a structure in memory used by programs to store temporary variables and information controlling the operation of the application. A stack canary is a special value stored in the stack. When someone attempts to exploit, say, a buffer overflow vulnerability in an application, and overwrite data on the stack to hijack the program’s execution, they should end up overwriting the canary. Doing so will be detected by the program, allowing it to trap and end the exploitation attempt.

Without these canaries, an exploited WASM program could continue running, albeit at the bidding of whoever attacked it, whereas its x86 counterpart exits for its own protection, and that’s a potential security problem. Stack canaries aren’t a panacea, and they can be bypassed, though not having them at all makes exploitation a lot easier.

And these issues are not necessarily a deal-breaker: WASM bytecode still exists in a sandbox, and has further defenses against control-flow hijacking techniques such as return-oriented programming.

But as the researchers observe, WASM’s documentation insists that stack-smashing protection isn’t necessary for WASM code. The three boffins say their findings indicate security assumptions for x86 binaries should be questioned for WASM builds and should encourage others to explore the consequences of this divergent behavior, as it applies both to stack-based buffer overflows and other common security weaknesses.

[…]

Source: Code compiled to WASM may lack standard security defenses • The Register

Surveillance software developer NSO Group may have a very tough road ahead. The US Commerce Department has added NSO to its Entity List, effectively banning trade with the firm. The move bars American companies from doing business with NSO unless they receive explicit permission. That’s unlikely, too, when the rule doesn’t allow license exceptions for exports and the US will default to rejecting reviews.

NSO and fellow Israeli company Candiru (also on the Entity List) face accusations of enabling hostile spying by authoritarian governments. They’ve allegedly supplied spyware like NSO’s Pegasus to “authoritarian governments” that used the tools to track activists, journalists and other critics in a bid to crush political dissent. This is part of the Biden-Harris administration’s push to make human rights “the center” of American foreign policy, the Commerce Department said.

The latest round of trade bans also affects Russian company Positive Technologies and Singapore’s Computer Security Initiative Consultancy, bot of which were accused of peddling hacking tools.

[…]

Source: US bans trade with security firm NSO Group over Pegasus spyware (updated) | Engadget

The wait is over. It’s now possible to encrypt your WhatsApp chat history on both Android and iOS, Facebook CEO Mark Zuckerberg announced on Thursday. The company plans to roll out the feature slowly to ensure it can deliver a consistent and reliable experience to all users.

However, once you can access the feature, it will allow you to secure your backups before they hit iCloud or Google Drive. At that point, neither WhatsApp nor your cloud service provider will be able to access the files. It’s also worth mentioning you won’t be able to recover your backups if you ever lose the 64-digit encryption key that secures your chat logs. That said, it’s also possible to secure your backups behind a password, in which case you can recover that if you ever lose it.

While WhatsApp has allowed users to securely message each other since 2016, it only started testing encrypted backups earlier this year. With today’s announcement, the company said it has taken the final step toward providing a full end-to-end encrypted messaging experience.

It’s worth pointing out that end-to-end encryption doesn’t guarantee your privacy will be fully protected. According to a report The Information published in August, Facebook was looking into an AI that could analyze encrypted data without having to decrypt it so that it could serve ads based on that information. The head of WhatsApp denied the report, but it’s a reminder that there’s more to privacy than merely the existence of end-to-end encryption.

Source: WhatsApp begins rolling out end-to-end encryption for chat backups | Engadget

If you have an iPhone, and your friends mostly have iPhones, you probably use Apple’s Messages app to communicate with them. That’s the nature of things. And aside from the platform’s convenience and ubiquity, one of the iMessage platform’s selling points is that its end-to-end encryption should theoretically ensure that only you and those you text can read your conversations. However, that might not be the case: Apple can likely access the messages for many, many iMessage users, even with end-to-end encryption in place.

[…]

How you back up your messages matters

So yes, your texts are encrypted as sent and received. But few of us delete every text as it comes in; we keep them around in case we want to revisit them later, which means we need to back them up somehow. And as it turns out, how you back up your messages might mean the difference between having an truly secure iMessage history, and giving Apple the key to unlock all your conversations.

[…]

iCloud Backup is not a secure method for saving your messages

Here’s the tricky thing; Messages in iCloud is end-to-end encrypted, just as you’d expect—that’s why there’s no way to access your messages on the web, such as by logging in to icloud.com. There’s one big problem, though: your iCloud Backup isn’t end-to-end encrypted—and Apple stores the key to unlock your encrypted messages within that backup.

[…]

It’s not just your messages; besides Keychain, Screen Time, and Health data, Apple has the key to decrypt all of your iCloud data

[…]

Source: How Apple Can Read Your Encrypted Messages

The Telegraph newspaper managed to leak 10TB of subscriber data and server logs after leaving an Elasticsearch cluster unsecured for most of September, according to the researcher who found it online.

The blunder was uncovered by well-known security researcher Bob Diachenko, who said that the cluster had been freely accessible “without a password or any other authentication required to access it.”

After sampling the database to determine its owner, Diachenko saw the personal details of at least 1,200 Telegraph subscribers along with a substantial quantity of internal server logs, he told The Register.

“A significant portion of the records were unencrypted,” he said. Screenshots he provided showed information including the user-agent string and device type, while categories of personal data included subscribers’ first and last names, email addresses, subscriber status, IP addresses and device type and operating system.

Affected users “should be on the lookout for targeted phishing and scams,” Diachenko advised. “Names and emails in the database can be used to send readers targeted scam messages.”

Aside from potential scam emails, the risk from this breach is relatively low unless having your news-reading habits collated in one place might cause professional embarrassment: Diachenko highlighted that in the data sample he viewed were a handful of gov.uk email addresses.

[…]

Source: Telegraph newspaper exposes 10TB of server, user data online • The Register

After finding several security flaws in Intel’s System Guard Extensions (SGX), security researchers have now revealed a flaw in AMD’s Platform Security Processor (PSP) chipset driver that makes it easy for attackers to steal sensitive data from Ryzen-powered systems. On the upside, there’s already patches available from both Microsoft and AMD to shut the exploit.

Recently, AMD disclosed a vulnerability in the AMD Platform Security Processor (PSP) chipset driver that allows malicious actors to dump memory pages and exact sensitive information such as passwords and storage decryption keys.

The flaw is tracked under CVE-2021-26333 and is considered medium severity. It affects a wide range of AMD-powered systems, with all Ryzen desktop, mobile, and workstation CPUs being affected. Additionally, PCs equipped with a 6th and 7th generation AMD A-series APU or modern Athlon processors are vulnerable to the same attack.

Security researcher Kyriakos Economou over at ZeroPeril discovered the flaw back in April. His team tested a proof-of-concept exploit on several AMD systems and found it relatively easy to leak several gigabytes of uninitialized physical memory pages when logged in as a user with low privileges. At the same time, this attack method can bypass exploitation mitigations like kernel address space layout randomization (KASLR).

The good news is there are patches available for this flaw. One way to ensure you get them is to download the latest AMD chipset drivers from TechSpot Drivers page or AMD’s own website. The driver was released a month ago, but at the time AMD chose not to fully disclose the security fixes contained in the release.

[…]

Source: Millions of AMD PCs affected by new CPU driver flaw need to be patched ASAP | TechSpot

“The expiration of a key digital encryption service on Thursday sent major tech companies nationwide scrambling to deal with internet outages that affected millions of online users,” reports the Washington Examiner.

The expiring certificate was issued by Let’s Encrypt — though ZDNet notes there’s been lots of warnings about its pending expiration: Digital Shadows senior cyber threat analyst Sean Nikkel told ZDNet that Let’s Encrypt put everyone on notice back in May about the expiration of the Root CA Thursday and offered alternatives and workarounds to ensure that devices would not be affected during the changeover. They have also kept a running forum thread open on this issue with fairly quick responses, Nikkel added.
Thursday night the Washington Examiner describes what happened when the big day arrived: Tech giants — such as Amazon, Google, Microsoft, and Cisco, as well as many smaller tech companies — were still battling with an endless array of issues by the end of the night… At least 2 million people have seen an error message on their phones, computers, or smart gadgets in the past 24 hours detailing some internet connectivity problems due to the certificate issue, according to Scott Helme, an internet security researcher and well-known cybersecurity expert. “So many people have been affected, even if it’s only the inconvenience of not being able to visit certain websites or some of their apps not working,” Helme said.

“This issue has been going on for many hours, and some companies are only just getting around to fixing it, even big companies with a lot of resources. It’s clearly not going smoothly,” he added.

There was an expectation before the certificate expired, Helme said, that the problem would be limited to gadgets and devices bought before 2017 that use the Let’s Encrypt digital certificate and haven’t updated their software. However, many users faced issues on Thursday despite having the most cutting-edge devices and software on hand. Dozens of major tech products and services have been significantly affected by the certificate expiration, such as cloud computing services for Amazon, Google, and Microsoft; IT and cloud security services for Cisco; sellers unable to log in on Shopify; games on RocketLeague; and workflows on Monday.com.
Security researcher Scott Helme also told ZDNet he’d also confirmed issues at many other companies, including Guardian Firewall, Auth0, QuickBooks, and Heroku — but there might be many more beyond that: “For the affected companies, it’s not like everything is down, but they’re certainly having service issues and have incidents open with staff working to resolve. In many ways, I’ve been talking about this for over a year since it last happened, but it’s a difficult problem to identify. it’s like looking for something that could cause a fire: it’s really obvious when you can see the smoke…!”

Digital certificates expert Tim Callan added that the popularity of DevOps-friendly architectures like containerization, virtualization and cloud has greatly increased the number of certificates the enterprise needs while radically decreasing their average lifespan. “That means many more expiration events, much more administration time required, and greatly increased risk of a failed renewal,” he said.

Source: Millions Experience Browser Problems After Long-Anticipated Expiration of ‘Let’s Encrypt’ Certificate – Slashdot

[…]

Should your AirTag-equipped thing not be where you thought it was, you can enable Lost Mode. When in Lost Mode, an AirTag scanned via NFC provides a unique URL which lets the finder get in contact with the loser – and it’s this page where security researcher Bobby Rauch discovered a concerning vulnerability.

“An attacker can carry out Stored XSS on this https://found.apple.com page by injecting a malicious payload into the AirTag ‘Lost Mode’ phone number field,” Rauch wrote in an analysis of the issue. “A victim will believe they are being asked to sign into iCloud so they can get in contact with the owner of the AirTag, when in fact, the attacker has redirected them to a credential hijacking page.

“Other XSS exploits can be carried out as well like session token hijacking, clickjacking, and more. An attacker can create weaponised AirTags and leave them around, victimising innocent people who are simply trying to help a person find their lost AirTag.”

Apple has not commented publicly on the vulnerability nor does it seem to be taking the issue particularly seriously. Speaking to Brian Krebs, Rauch claimed that Apple sat on the flaw for three months – and that while it confirmed it planned to resolve the vulnerability in a future update, the company has not yet done so. Apple also refused to confirm whether Rauch’s discovery would qualify for its bug bounty programme and a potential cash payout – a final insult which led to his public release of the flaw.

It’s not the first time Apple has stood accused of failing to respond to security researchers. Earlier this month a pseudonymous researcher known as “IllusionOfChaos” dropped three zero-day vulnerabilities affecting Apple’s iOS 15 – six months after originally reporting them to the company. A fourth flaw had been fixed in an earlier iOS release, the researcher noted, “but Apple decided to cover it up and not list it on the security content page.”

The company has also been experiencing a few problems with the patches it does release. An update released to fix a vulnerability in the company’s Finder file manager, capable of bypassing the Quarantine and Gatekeeper security functions built into macOS, only worked for lowercase URLs – although emergency patches released two weeks ago appear to have had better luck.

[…]

Source: Unpatched flaw creates ‘weaponised’ Apple AirTags • The Register

A flaw in Microsoft’s Autodiscover protocol, used to configure Exchange clients like Outlook, can cause user credentials to leak to miscreants in certain circumstances.

The upshot is that your Exchange-connected email client may give away your username and password to a stranger, if the flaw is successfully exploited. In a report scheduled to be published on Wednesday, security firm Guardicore said it has identified a design blunder that leaks web requests to Autodiscover domains that are outside the user’s domain but within the same top-level domain (TLD).

Exchange’s Autodiscover protocol, specifically the version based on POX XML, provides a way for client applications to obtain the configuration data necessary to communicate with the Exchange server. It gets invoked, for example, when adding a new Exchange account to Outlook. After a user supplies a name, email address, and password, Outlook tries to use Autodiscover to set up the client.

As Guardicore explained in a report provided to The Register, the client parses the email address – say, user@example.com – and tries to construct a URL for the configuration data using combinations of the email domain, a subdomain, and a path string as follows:

• https://Autodiscover.example.com/Autodiscover/Autodiscover.xml
• http://Autodiscover.example.com/Autodiscover/Autodiscover.xml
• https://example.com/Autodiscover/Autodiscover.xml
• http://example.com/Autodiscover/Autodiscover.xml

If the client doesn’t receive any response from these URLs – which would happen if Exchange was improperly configured or was somehow prevented from accessing the designated resources – the Autodiscover protocol tries a “back-off” algorithm that uses Autodiscover with a TLD as a hostname. Eg:

• http://Autodiscover.com/Autodiscover/Autodiscover.xml

“This ‘back-off’ mechanism is the culprit of this leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to ‘fail up,’ so to speak,” explained Amit Serper, Guardicore area vice president of security research for North America, in the report. “This means that whoever owns Autodiscover.com will receive all of the requests that cannot reach the original domain.”

In an email to The Register, Serper said, “I believe that this was the consequence of careless, or rather, naïve design. [The] same flaws appear in other Microsoft protocols of similar functions.”

Sensing a potential problem with making credentials available to any old TLD with Autodiscover, Guardicore acquired several variations on that theme: Autodiscover.com.br, Autodiscover.com.cn, Autodiscover.com.co, Autodiscover.uk, and Autodiscover.online, among others.

After assigning these domains to its web server, Guardicore started receiving numerous requests to Autodiscover endpoints from assorted IP addresses and clients. It turns out a lot of Exchange servers and clients aren’t set up very carefully.

… with the Authorization header already populated with credentials in HTTP basic authentication

“The most notable thing about these requests was that they requested the relative path of /Autodiscover/Autodiscover.xml with the Authorization header already populated with credentials in HTTP basic authentication,” said Serper, who observed that web requests of this sort should not be sent blindly pre-authentication.

HTTP basic access authentication is Base64 encoded but is not encrypted, so this amounts to sending credentials in cleartext.

Between April 16, 2021 and August 25, 2021, Guardicore received about 649,000 HTTP requests aimed at its Autodiscover domains, 372,000 requests with credentials in basic authentication, and roughly 97,000 unique pre-authentication requests.

The credentials came from publicly traded companies in China, food makers, investment banks, power plants, energy delivery firms, real estate businesses, shipping and logistics operations, and fashion/jewelry companies.

There were also many requests that used alternatives to HTTP basic authentication, like NTLM and Oauth, that didn’t expose associated credentials immediately. To obtain access to these, Guardicore set up a downgrade attack.

So upon receiving an HTTP request with an authentication token or NLTM hash, the Guardicore server responded with an HTTP 401 with the WWW-Authenticate: basic header, which tells the client that the server only supports HTTP basic authentication. Then to make the session look legit, the company used a Let’s Encrypt certificate to prevent an SSL warning and ensure the presentation of a proper Outlook authentication prompt so potential victims enter their credentials with confidence.

[…]

Source: Microsoft Exchange protocol can leak credentials • The Register

A second leak of personal data was reportedly committed by the Ministry of Defence, raising further questions about the ministry’s commitment to the safety of people in Afghanistan, some of whom are its own former employees.

The BBC reported overnight that the details of a further 55 Afghans  – claimed to be candidates for potential relocation – had been leaked through the classic cc-instead-of-bcc email blunder, echoing the previously reported breach of 250 Afghan interpreters’ data through a similar failure.

An MoD spokeswoman said in a statement: “We have been made aware of a data breach that occurred earlier this month by the Afghan Relocation and Assistance Policy (Arap) team. This week, the defence secretary instigated an investigation into data-handling within that team.”

A defence official has reportedly been suspended from duty, following demands from defence secretary Ben Wallace for an immediate enquiry into how the blunder happened.

After the US-led military coalition left Afghanistan, a number of local civilians employed as translators were left behind as the Taliban re-established control over the country. Some of those civilians have since been murdered for their perceived support of the Western militaries.

[…]

Source: Ministry of Defence: Another huge Afghanistan email blunder • The Register

A database containing personal information on 106 million international travelers to Thailand was exposed to the public internet this year, a Brit biz claimed this week.

Bob Diachenko, head of cybersecurity research at product-comparison website Comparitech, said the Elasticsearch data store contained visitors’ full names, passport numbers, arrival dates, visa types, residency status, and more. It was indexed by search engine Censys on August 20, and spotted by Diachenko two days later. There were no credentials in the database, which is said to have held records dating back a decade.

[…]

Diachenko said he alerted the operator of the database, which led to the Thai authorities finding out about it, who “were quick to acknowledge the incident and swiftly secured the data,” Comparitech reported. We’re told that the IP address of the exposed database, hidden from sight a day after Diachenko raised the alarm, is still live, though connecting to it reports that the box is now a honeypot.

[…]

We’ve contacted the Thai embassy in the US for further comment. Diachenko told The Register a “server misconfiguration” by an IT outsourcer caused the database to be exposed to the whole world.

[…]

Additionally, it’s possible that if you’ve traveled to Thailand and stayed there during the pandemic, you’ve already been leaked. A government website used to sign foreigners up for COVID-19 vaccines spilled names and passport numbers in June.

Additionally, last month, Bangkok Airways was hit by ransomware group LockBit resulting in the publishing of passenger data. And in 2018, TrueMove H, the biggest 4G mobile operator in Thailand, suffered a database breach of around 46,000 records.

Comparitech said the database it found contained several assets, in addition to the 106 million records, making the total leaked information come to around 200 GB.

Source: Database containing 106m Thailand travelers’ details leaked • The Register

The UK’s Ministry of Defence has launched an internal investigation after committing the classic CC-instead-of-BCC email error – but with the names and contact details of Afghan interpreters trapped in the Taliban-controlled nation.

The horrendous data breach took place yesterday, with Defence Secretary Ben Wallace promising an immediate investigation, according to the BBC.

Included in the breach were profile pictures associated with some email accounts, according to the state-owned broadcaster. The initial email was followed up by a second message urging people who had received the first one to delete it – a way of drawing close attention to an otherwise routine missive.

The email was reportedly sent by the British government’s Afghan Relocations and Assistance Policy (ARAP) unit, urging the interpreters not to put themselves or their families at risk. The ministry was said to have apologised for the “unacceptable breach.”

“This mistake could cost the life of interpreters, especially for those who are still in Afghanistan,” one source told the Beeb.

Since the US-led military coalition pulled out of Afghanistan at the end of August, there have been distressing scenes in the country as the ruling Taliban impose Islamic Sharia law – while hunting down and punishing those who helped the Western militaries. Some interpreters have reportedly been murdered, with others fearing for their lives and the well-being of their families.

[…]

Source: MoD apologises after Afghan interpreters’ data exposed • The Register

Researchers from Ben-Gurion University have come up with a way to listen in on a speaker from afar by just monitoring the subtle changes in brightness of its power status LED.

The Glowworm Attack, as the discovery is called, follows similar research from the university published in 2020 that found an electro-optical sensor paired with a telescope was able to decipher the sounds in a room. Sound waves bounced off a hanging light bulb create nearly imperceptible changes in the lighting in the room. With the Glowworm Attack, the same technology that made Lamphone possible is repurposed to remotely eavesdrop on sounds in a room again, but using a completely different approach that many speaker makers apparently never even considered.

[…]

Pairing the sensor with a telescope allowed the security researchers at Ben-Gurion University to successfully capture and decipher sounds being played by a speaker at distances of up to 35 meters, or close to 115 feet. The results aren’t crystal clear (you can hear the remote recordings the researchers made on Ben Nassi’s website), and the noise increases the farther away from the speaker the capture device is used, but with some intelligent audio processing, the results can undoubtedly be improved.

Source: Glowworm Attack Captures Audio From Power LED Light Flickers

QLED-loving thieves, beware: Samsung revealed on Tuesday that its TVs can be remotely disabled if the company finds out they’ve been stolen, so long as the sets in question are connected to the internet.

Known as “Samsung TV Block,” the feature was first announced in a press release earlier this month after the company deployed it following a string of warehouse lootings triggered by unrest in South Africa. In the release, Samsung said that the technology comes “already pre-loaded on all Samsung TV products,” and said that it “ensures that the television sets can only be used by the rightful owners with a valid proof of purchase.”

TV Block kicks in after the user of the stolen television connects it to the internet, which is necessary in order to operate the smart TVs. Once connected, the serial number of the television pings the Samsung server, triggering a blocking mechanism that effectively disables all of the TV’s functions.

While the release only mentions the blocking function relative to the TVs that had been looted from the company’s warehouse, the protection could also ostensibly be applied to individual customers who’ve had their TVs stolen and report the device’s serial number to Samsung.

[…]

Source: Samsung Smart TVs Can Be Remotely Disabled If Stolen

This means that you could reroute the TVs to your own server and trigger the blocking mechanism yourself quite easily. Nice way to brick a whole load of Samsung TVs!

Infosec pros and other technically minded folk have just under a week left to comment on EU plans to introduce new regulations obligating consumer IoT device makers to address online security issues, data protection, privacy and fraud prevention.

Draft regulations applying to “internet-connected radio equipment and wearable radio equipment” are open for public comment until 27 August – and the resulting laws will apply across the bloc from the end of this year, according to the EU Commission.

Billed as assisting Internet of Things device security, the new regs will apply to other internet-connected gadgets in current use today, explicitly including “certain laptops” as well as “baby monitors, smart appliances, smart cameras and a number of other radio equipment”, “dongles, alarm systems, home automation systems” and more.

[…]

The Netherlands’ FME association has already raised public concerns about the scope of the EU’s plans, specifically raising the “feasibility of post market responsibility for cybersecurity”.

The trade association said: “If there is a low risk exploitable vulnerability; at what level can the manufacturer not release or delay a patch, and what documentation is required to demonstrate that this risk assessment was conducted with this outcome of a very low risk vulnerability?”

While there are certainly holes that can be picked in the draft regs, cheap and cheerful internet-connected devices pose a real risk to the wider internet because of the ease with which they can be hijacked by criminals.

[…]

Certain router makers have learned the hard way that end-of-life equipment that contain insecurities can have a reputational as well as security impact. That said, it’s perhaps unreasonable to expect kit makers to keep providing software patches for years after they’ve stopped shipping a device. Consumers cannot rely on news outlets shaming makers of internet-connected goods into providing better security; new laws are the inevitable next stage, and there’s a growing push for them on both sides of the Atlantic.

Device makers being banned from selling in the EU over security and data protection issues is not new. In 2017, the German telecoms regulator banned the sale of children’s smartwatches that allowed users to secretly listen in on nearby conversations and later that year, the French data protection agency issued a formal notice to a biz peddling allegedly insecure Bluetooth-enabled toys – Genesis Toys’ My Friend Cayla doll and the i-Que robot, because the doll could be misused to eavesdrop on kids. The manufacturers are also obliged to comply with the GDPR. However, the new draft law is evidence that certain loopholes might soon begin to close

Source: European Commission airs out new IoT device security draft law – interested parties have a week to weigh in • The Register