49 lines
28 KiB
XML
49 lines
28 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:lab="https://labradorcms.com/ns/rss">
|
||
<channel>
|
||
<title>www.theregister.com - Articles</title>
|
||
<link>https://www.theregister.com</link>
|
||
<description>Articles from www.theregister.com</description>
|
||
|
||
<item>
|
||
<guid isPermaLink="true">https://www.theregister.com/a/5266161</guid>
|
||
<link>https://www.theregister.com/security/2026/07/05/mfa-optional-banks-leave-safe-doors-and-accounts-wide-open-for-thieves-to-pillage/5266161</link>
|
||
<pubDate>Sun, 05 Jul 2026 17:01:00 +0200</pubDate>
|
||
<title>MFA-optional banks leave safe doors (and accounts) wide open for thieves to pillage</title>
|
||
<description><![CDATA[ Financial institutions are putting their clients at risk in the name of convenience. ]]></description>
|
||
<category>security</category>
|
||
<lab:kicker><![CDATA[ Security ]]></lab:kicker>
|
||
<dc:modified>Fri, 03 Jul 2026 00:01:12 +0000</dc:modified>
|
||
<content:encoded><![CDATA[ OPINION I write a weekly column called PWNED, about how poor security practices can lead to serious damage. Usually, there’s something funny in the malfeasance, like a CEO who kept every employee’s password in an Excel file on his desktop. However, I wasn’t laughing back in May when professional thieves invaded my 84-year-old mother’s entire financial life and managed to make off with $30,000 from her bank accounts alone. And they wouldn’t have gotten in if her financial institutions required multi-factor authentication (aka MFA or 2FA), a step too many institutions won’t take. One day in May, Mom got a call from the institution that runs her retirement savings account, who had identified a suspicious transaction and asked her if it was legit. She said no and they immediately protected her account. Then she checked her bank account at a different institution to see if it was compromised and found thousands of dollars transferred out of her checking and savings accounts. The thieves knew exactly how much they could withdraw each day, and used both withdrawals and transfers to a strange account. But the financial institution hadn't flagged the fraudulent activity. The thieves were so slick that they broke into her Gmail account and created spam filters to filter any mail from her bank or retirement savings provider to the trash so she wouldn’t get alerts about the transfers or about the fake accounts they made in her name. She spent hours on the phone reporting the theft to an unhelpful and incredulous fraud department who asked “Are you sure a relative didn’t do this?” We don’t know for certain how the crims got into my mom’s accounts, but we know she used the same or similar passwords on all of her accounts, and at least one of her accounts was part of a data breach a few years ago, so that info was probably available somewhere online. The miscreants then could have used this info to get into her retirement account, her bank, and her Gmail. None of this would have been possible if she had MFA enabled on those accounts, but neither Google nor her financial institutions require it. “Many consumers assume every bank requires 2FA, but that's not the reality,” said Gregory Shein, CEO of Nomadic Soft, a SaaS company that serves fintech clients. “Some financial institutions still treat it as an optional feature because they're balancing security against friction. Every extra login step can reduce conversions, increase support tickets, and frustrate less technical customers.” Indeed, while some banks such as PNC require MFA, others such as Bank of America, Chase, Capital One, and Citibank leave it as optional. Google’s accounts are also MFA-optional. Fortunately, after they spent hours telling my mom that someone in her family could have done the deed, and repeatedly putting her on hold, then forcing her to navigate a labyrinthine phone tree, the bank eventually agreed to investigate. A few weeks later, they restored the stolen funds. A not entirely happy ending My mother was lucky, because if money is stolen from your bank account, there is no guarantee that you will get it back, at least in the US. According to the Consumer Financial Protection Bureau, you have 60 days from the date of a bank statement to dispute any transactions. The bank also has 45 days to investigate, unless your bank account was just opened in the last 30 days or the fraudulent transactions took place outside the US. But the bank could very well decide that those fraudulent transactions look legitimate and refuse to reimburse you. If the bank doesn’t agree to reimburse you, your next step is to get a lawyer and attempt to sue. A quick search revealed dozens of lawyers in my area who specialize in dealing with this problem. It would be easy to blame my mom for being robbed. Using the same password in multiple places left her wide open for exploitation. However, her bank’s lack of a required second authentication factor also contributed. The bank doesn’t let you transact without a password, and it doesn’t issue you an ATM card without a PIN, because it knows that there has to be a required minimum level of security. Banks and other financial institutions know better. Google knows better. But they’re all putting convenience ahead of security when it’s your money that’s on the line. “Different segments of the population adopt technology faster or slower. If I’m a bank, I have to consider that very closely because I don’t want to lose any banking relationships.” Andrew Shikiar, CEO of the FIDO Alliance, an industry association that advocates for stronger login security, told me in an interview. “So I think there’s some concerns around friction that have held some banks and other service providers back from really pushing this more aggressively.” How effective is MFA? According to a 2019 article from Microsoft, MFA prevents 99.9 percent of attacks on your accounts. However, other experts say this number is exaggerated, as there are many ways to get past MFA if you’re a criminal, including social engineering and interception. One of the most common types of MFA, issuing a one-time passcode via an SMS message or an email, is inherently flawed. A determined thief can use social engineering to get a SIM card with your phone number on it, then get to your texts. And if your email itself isn’t perfectly secure and it is receiving an OTP, they can get to that too. Phishers can also trick you into giving up your OTPs by creating a fake website that looks like your bank’s login page. The right way to do MFA today is with a passkey. Passkeys are cryptographic key pairs where there’s a private key on the user’s device and a public key on the server. To access the key on the device, the user must either enter a PIN, touch a physical security key like a Yubikey, or enter a biometric login such as their face or fingerprint. Passkeys cannot be phished or intercepted, which is why they are known as “phishing-resistant MFA.” Unfortunately, a lot of banks are sticking with their OTPs. For example, when I went to set up MFA for a family member’s account with US bank Chase, using its website. Chase offered the chance to receive an OTP via email, SMS, or a phone call. The bank is rolling out passkeys, according to the FIDO Alliance. So are Wells Fargo, US Bank, and Bank of America. Some banks may be using better MFA only within their mobile apps. Chase’s app, for example, asks users to use a fingerprint or facial recognition at login, even though the website does not. However, if a thief wants to log in at Chase's website, there will be no biometric challenge. And if a user doesn’t have MFA enabled at all, it’s even easier for thieves to get in. “OTP is just another password. So it’s a shorter-lived one, but it really is just another password,” Shikiar said. “And there’s also usability issues. You’re juggling between your mobile and your desktop. It’s insecure, inefficient, and a really inadequate user experience.” What banks don’t seem to understand is that you’re only as secure as your weakest entry point. If security controls only exist on mobile apps, it doesn’t help with web-based attacks. If a level of security is optional, the majority of people won’t enable it. Thieves will take the path of least resistance, so service operators need to lock down all entry paths equally by default. Unfortunately, an approach that favors convenience over security will lead to a lot more people losing their money. And, ultimately, banks will lose money when they have to reimburse people for those fraudulent transactions. “I don't expect banks to be mandating passkeys and only passkeys for some time, but the more they push them, the more comfort there is,” Shikiar told us. “The sooner we’ll get to that point where it becomes a de facto default and then becomes really something that's either required or essentially required.” That time should be now. ® ]]></content:encoded>
|
||
<enclosure url="https://image.theregister.com/?imageId=224126&width=800" type="image/jpeg" />
|
||
<media:thumbnail url="https://image.theregister.com/?imageId=224126&width=800" />
|
||
</item>
|
||
<item>
|
||
<guid isPermaLink="true">https://www.theregister.com/a/5266056</guid>
|
||
<link>https://www.theregister.com/security/2026/07/04/confidential-computings-core-trust-mechanism-is-broken-the-fix-may-not-exist/5266056</link>
|
||
<pubDate>Sat, 04 Jul 2026 12:03:00 +0200</pubDate>
|
||
<title>Confidential computing's core trust mechanism is broken. The fix may not exist</title>
|
||
<description><![CDATA[ Attested TLS: the handshake that can't prove who's on the other end ]]></description>
|
||
<category>security</category>
|
||
<lab:kicker><![CDATA[ SECURITY ]]></lab:kicker>
|
||
<dc:modified>Fri, 03 Jul 2026 07:47:18 +0000</dc:modified>
|
||
<content:encoded><![CDATA[ Vendors are trying to position "confidential computing" as the technical backbone of Europe's sovereign cloud ambitions. But new research shows that a security protocol used to prove cryptographic trust in the system may have a fundamental architectural flaw. Confidential computing rests on a mechanism called remote attestation, in which a server cryptographically proves to a client that it is running inside a genuine, unmodified Trusted Execution Environment (TEE) before any sensitive data changes hands. Intel's product pages promise TDX will "add safeguards to data sovereignty and governance." Google Cloud describes its confidential computing infrastructure as offering "full, auditable control over access to customer data." In May, The Register reported that the chip beneath the chip, the management engines running below the operating system on Intel and AMD silicon, falls outside what European sovereignty frameworks like SecNumCloud actually assess. That left an open question about the layer above the silicon: the protocol meant to prove the chip itself can be trusted. New, independently verified research answers it, and the answer is not reassuring. A protocol that promises more than it proves Muhammad Usama Sardar, a researcher at TU Dresden, has spent the past two years formally verifying whether that protocol, known as attested TLS, actually does what it claims. Using ProVerif, a tool for the symbolic security analysis of protocols, he and his co-authors discovered that it largely does not. Their recent paper, Identity Crisis in Confidential Computing, published with co-authors Mariam Moustafa and Tuomas Aura and presented at the AsiaCCS 2026 conference, found diversion attacks against two state-of-the-art attested TLS protocols. A connection intended for one server can be silently redirected to a different, compromised machine running identical software, anywhere in the world, without the client ever knowing. The intended server has done nothing wrong. The attacker simply exploits the fact that the protocol checks the software's integrity, not its location. The most recent paper, Intra-handshake.fail, published with co-authors Viacheslav Dubeyko and Jean-Marie Jacquet and accepted for ESORICS 2026, goes further. It examines what the industry calls intra-handshake attestation, where evidence is generated during the TLS handshake itself, and tests seven different ways of cryptographically binding that evidence to the underlying connection. None of them prevent relay attacks, in which a client verifies the evidence of a genuine, trustworthy AI agent or server but ends up encrypting its traffic to an entirely different, malicious one. The starting assumption in all of this is that the hardware itself can be trusted. "In confidential computing, you have to trust the hardware manufacturer anyway," Sardar told The Register. "There is absolutely no way around this." With that root of trust accepted, he argues, the protocol layer was supposed to provide everything else. His research shows it provides far less than assumed. Three levels of trust The researchers formalise the problem as three increasingly strict levels of cryptographic binding between the attestation evidence and the actual TLS connection it is meant to vouch for. The weakest, level one, ties evidence only to the very first key exchange in the handshake, the Diffie-Hellman step, where client and server agree on a shared secret before either side has proven who they are. Level two ties it to the client's handshake traffic key, covering everything up to the server's identity confirmation. Level three, the strongest and the one that matters most in practice, ties evidence to the application traffic key itself, the key actually used to encrypt the sensitive data a client sends once the connection is live. Sardar's extensive analysis in ProVerif focused on intra-handshake attestation; post-handshake attestation fell outside its scope. Three of the seven binding mechanisms examined achieve level one. The rest fail even that baseline. His team's own proposed mitigation, a cryptographic binder built from the TLS handshake secret combined with the server's public key, formally achieves level two. Level three, the paper concludes, "may not be possible" within intra-handshake attestation as currently architected, without breaking properties of TLS 1.3 that the protocol was never designed to give up. In plain terms: the best fix available today proves a client is talking to the right machine at the start of a handshake. It cannot prove that the data sent minutes later is still going to that same machine. Production systems, not laboratory proofs of concept The vulnerability is not confined to academic models. Sardar's team formally analysed four real-world implementations of intra-handshake attestation: Meta's Private Processing system for WhatsApp, Edgeless Systems' Contrast, the open-source Cocos AI platform, and a proof-of-concept maintained by the Confidential Computing Consortium's (CCC) Attestation Special Interest Group. The first three of the four are running in production today. The attacks apply to every version of Cocos AI between 0.4.0 and 0.8.2. The class of flaw itself is not new. Sardar's team notes the attacks are subtle enough to have gone undiscovered for years before formal analysis caught them. The responsible disclosure resulted in CVE-2026-33697, rated 7.5 on the Common Vulnerability Scoring System, high severity. For comparison, the researchers note in their paper that BadRAM, the 2024 memory aliasing attack against AMD's SEV-SNP that made headlines in its own right, scored 5.3. The CCC Attestation SIG's repository lists CVE-2026-33697 as the highest-scoring vulnerability among a cluster of recent confidential computing flaws, ahead of Fabricked (5.9), BreakFAST (5.9) and Staleus (4.0). The working group and the IETF's TLS working group have both formally acknowledged the relay attacks. "As implemented today, attested TLS is not mature yet," Sardar told The Register. "We are investigating further, and we are confident there are more issues yet to be discovered." What makes the finding more pointed is who missed it first. Meta commissioned an extensive security review of its WhatsApp implementation from Trail of Bits, a well-regarded security firm, before Sardar's team examined it. That review did not detect the relay attack. It is methodology, not incompetence, that explains the gap. The ESORICS paper records that Sardar's team contacted Trail of Bits directly, who confirmed no formal methods were used in their review process. Formal verification tools like ProVerif check a protocol exhaustively against every scenario a defined threat model allows. A manual audit, however thorough, samples. A subtle flaw in how evidence is bound to a connection can slip past a sampled review and still be provably broken under exhaustive formal analysis. The Attestation Special Interest Group of the CCC, which governs the adopted proof-of-concept project Sardar tested, found its own system vulnerable to the same relay attacks. A repository nobody would create The vulnerability itself had already been through a lengthy, orderly disclosure process. Sardar's team flagged it to Cocos AI in October 2025, the vendor acknowledged it two months later, and the CVE was published in March 2026. What happened next was different. On 14 June, Sardar wrote to the chairs of the CCC's Attestation Special Interest Group requesting a new public GitHub repository, named relay-attacks-in-intra-handshake, so his formal analysis artefacts for the relay attacks could be released under an Apache 2.0 licence, for use by researchers and the standardization community. He referenced an existing, adopted project under the same group's governance, the kind of administrative step that, on paper, should take minutes. Three days later, on 17 June, he sent a reminder. The following day, a second, noting the artefact link was needed for the paper's final version. On 24 June, ten days after the original request, he wrote again, this time without the diplomatic padding: "I do not see a good reason for such a delay, since the requested repo is part of an adopted project and creation of a new repo is not such a time-consuming task." The new repository still did not exist. The CCC's Attestation Special Interest Group is made up of representatives from the hardware and cloud vendors whose products the research concerns. That fact requires no embellishment. A working group populated by the companies whose attestation implementations were just shown to be vulnerable to relay attacks did not act, for over a week and across three written reminders, on a request to publish proof of that vulnerability. Since no repository had been created before the paper's final version went to the publisher, Sardar published the artefacts anyway, but inside an existing CCC-affiliated repository rather than the dedicated one he had asked for. He told The Register the repository had originally been built for an unrelated project: "Since the monopoly [of vendor-dominated working groups over this infrastructure] continues, we have released the artifacts to inform the community and for researchers to analyse it independently." The CVE stands regardless, credited and public. The delay changes nothing about the underlying mathematics. BSI reaches the same verdict None of this requires taking Sardar's interpretation on faith. A world away from the IETF mailing lists, Germany's Federal Office for Information Security (BSI) arrived at a closely related conclusion through its own, entirely separate channel. Carina Hilt, deputy press spokesperson at BSI, was asked directly about confidential computing's role in digital sovereignty. She told The Register the technology functions as "a defense-in-depth component," strengthening tenant isolation and protecting confidentiality and integrity, but not availability. Crucially, she added that "dependencies on other services, such as identity and key management etc., are also not mitigated by CC." That is, in other words, an institutional echo of exactly the gap Sardar's protocol analysis exposes: confidential computing's guarantees stop well short of guaranteeing who actually controls the keys and the identity infrastructure a deployment depends on. Pressed further on vendor marketing claims, BSI did not soften its position. "The vendors' positioning on CC might give too much weight to its technical capabilities," the spokesperson told The Register. "CC alone cannot satisfy the requirements for digital sovereignty." What the chipmakers say Mikael Moreau, Intel's France Communication Manager, was asked specifically about the attestation infrastructure underpinning its TDX confidential computing technology, and whether Intel's own role in that infrastructure constitutes a dependency. He said the company does "not consider its attestation infrastructure to be a limitation to sovereignty guarantees," arguing that any reliance on Intel's silicon and certificate root of trust is "bounded." Intel is not in the customer's workload data path, does not receive customer plaintext through attestation, and the operational trust decision can be delegated to an independent verifier or retained by the customer. That is a carefully constructed, technically defensible answer. It explains the architecture, not the law. Intel was asked whether its attestation infrastructure poses a sovereignty risk under RISAA, the 2024 US law that can compel hardware manufacturers to cooperate with secret intelligence orders. That question went unanswered. Google did not respond to a request for comment for this article. Acknowledged everywhere except the sales pitch Sardar's findings prompted four different institutional responses. The IETF's Secure Evidence and Attestation Transport (SEAT) working group, formed after a group including Sardar successfully argued for it at a Birds of a Feather session at IETF 123 in Madrid in July 2025, wrote his correlation properties directly into its charter as an explicit, mandatory requirement for any new specification work. That is a standards body doing exactly what it should, building formal verification into the process rather than bolting it on afterwards. The IETF's TLS working group formally acknowledged the same attacks, without adopting a binding requirement of its own. The CCC's inaction over ten days meant Sardar published the evidence himself, without the working group's help. None of that reached the sales conversation. Intel and Google continue to market confidential computing as proof of sovereign, verified protection. Asked directly about the infrastructure underpinning that claim, Intel's answer stopped short of the legal question at its centre. Google did not answer at all. For European CIOs and procurement officers, this raises a question beyond the one usually asked. It is no longer only which company owns the cloud or which government can compel which hardware manufacturer. It is whether the cryptographic handshake meant to prove a workload is running where it claims to be running can be trusted at all. The level that timing rules out Sardar's own mitigation reaches level two. Level three, the one that actually matters to a customer trying to verify their workload is still protected once data starts flowing, may not be achievable at all within the current architecture of intra-handshake attestation, where evidence is generated during the handshake itself. The timing is the problem. Level three requires binding the evidence to the key that encrypts the actual application data, but by the time that key exists, the evidence has already been sent, unless the TLS protocol itself is significantly changed. Post-handshake attestation waits until after that point, when the key is already there to bind against. "We believe post-handshake attestation alone can achieve level three binding," Sardar told The Register, warning that newer proposals combining both approaches add unnecessary complexity without adding security. His recommendation to the IETF's TLS working group is blunt: developers should abandon intra-handshake attestation altogether. ® ]]></content:encoded>
|
||
<enclosure url="https://image.theregister.com/?imageId=5266120&width=800" type="image/jpeg" />
|
||
<media:thumbnail url="https://image.theregister.com/?imageId=5266120&width=800" />
|
||
</item>
|
||
<item>
|
||
<guid isPermaLink="true">https://www.theregister.com/a/5266512</guid>
|
||
<link>https://www.theregister.com/security/2026/07/03/adapthealth-crooks-stole-our-passwords-patient-health-data/5266512</link>
|
||
<pubDate>Fri, 03 Jul 2026 16:29:00 +0200</pubDate>
|
||
<title>AdaptHealth says attackers sweet-talked their way into cloud systems and stole patient data</title>
|
||
<description><![CDATA[ Third-party contractor compromise exposed health information and insurance billing passwords ]]></description>
|
||
<category>security</category>
|
||
<lab:kicker><![CDATA[ Security ]]></lab:kicker>
|
||
<dc:modified>Fri, 03 Jul 2026 13:50:25 +0000</dc:modified>
|
||
<content:encoded><![CDATA[ AdaptHealth says attackers used social engineering to breach its systems and steal sensitive patient data, including passwords associated with insurance billing. The medical equipment company disclosed the attack to the Securities and Exchange Commission (SEC) on Thursday, noting that attackers accessed internal patient management systems, document storage platforms, and external electronic health record system portals. The attack targeted an unwitting third-party contractor, through which the cybercriminals gained entry to the company's cloud environment, where they accessed business applications holding sensitive data. AdaptHealth activated its incident response protocols soon after the attacker contacted the company on June 15 and disclosed the theft. It did not specify whether an extortion demand was made, nor whether one was paid, and no cybercrime group had claimed responsibility at the time of writing. The company's response included disabling the contractor's user account, resetting credentials, and implementing additional access controls. It believes the attack is now contained. In addition to the "password file associated with insurance billing," AdaptHealth confirmed that personally identifiable information (PII) and protected health information of certain patients were also stolen. Social Security numbers and payment details are not thought to be affected. On June 27, AdaptHealth determined that "due to the nature and potential volume of the data that is at risk," the attack can be considered material, requiring disclosure to the SEC. The company did not comment on the exact scale of the attack or the related data theft, but said investigations continue to determine the scope of the breach. It also said it "has since taken steps intended to mitigate the risk of dissemination of the exfiltrated data." The Register asked AdaptHealth for more information, including whether it received any extortion demands and what steps it took to reduce the risk of the stolen data being distributed or misused. Pennsylvania-based AdaptHealth provides home medical equipment and related services for patients with chronic and serious conditions. Founded in 2012, it specializes in respiratory, sleep, and diabetes therapies. According to a 2024 annual report, it serves more than 4.2 million patients across all 50 US states. ® ]]></content:encoded>
|
||
<enclosure url="https://image.theregister.com/?imageId=5266544&width=800" type="image/jpeg" />
|
||
<media:thumbnail url="https://image.theregister.com/?imageId=5266544&width=800" />
|
||
</item>
|
||
</channel>
|
||
</rss>
|