APT42, which is believed to work for Iran’s Revolutionary Guard Corps, targeted about a dozen people associated with both Trump’s and Biden’s campaigns this spring, according to Google’s Threat Analysis Group.

When Donald Trump's presidential campaign publicly stated last week that it had been successfully targeted by Iranian hackers, the news may have initially seemed like a sign that the Middle Eastern country was particularly focused on the candidate whom it perceived to take the most hawkish approach to its regime. It's since become clearer that Iran has had the Democrats in the sights of its cyber operations, too. Now Google's cybersecurity analysts have confirmed that both campaigns were targeted not simply by Iran but by the same group of hackers working in service of Iran's Revolutionary Guard Corps.

Google's Threat Analysis Group on Wednesday published a new report on APT42, a group it says has aggressively sought to compromise both the Democratic and Republican campaigns for president, as well as Israeli military, government, and diplomatic organizations. In May and June, APT42, which is believed to be working in service of Iran's Revolutionary Guard Corps (IRGC), targeted about a dozen people associated with both Trump and Joe Biden, including current and former government officials and individuals associated with the two political campaigns. APT42 continues to target Republican and Democratic campaign officials alike, according to Google.

“In terms of collection, they're hitting all sides,” says John Hultquist, who leads threat intelligence at Google-owned cybersecurity firm Mandiant, which works closely with its Threat Analysis Group. Hultquist notes that equal-opportunity cyberspying doesn't come as a surprise, given that APT42 also targeted both the Biden and Trump campaigns in 2020 as well. APT42's targeting doesn't necessarily speak to its preference for a single candidate, he says, so much as the fact that both candidates, Trump and now Vice President Kamala Harris, are of enormous significance to the Iranian government. “They're interested in both candidates because these are the individuals who are charting the future of American policy in the Middle East," Hultquist says.

Only one campaign, however, appears to have had its sensitive files not only successfully breached by the Iranian hackers but also leaked to the press, in an apparent replay of Russia's 2016 hack-and-leak operation that targeted Hillary Clinton's campaign. Politico, The Washington Post, and The New York Times have all said they've been offered documents allegedly taken from the Trump campaign, in some cases by a source known as “Robert.”

Whether those files were in fact compromised by APT42 remains unconfirmed. Microsoft noted last week that APT42, which it calls Mint Sandstorm, had in June targeted a “high-ranking official on a presidential campaign” by exploiting a hacked email account of another “former senior adviser” to the campaign. Google in its new report also notes that APT42 “successfully gained access to the personal Gmail account of a high-profile political consultant.”

While neither company has offered any confirmation of which individual or individuals may have been successfully hacked by the Iranian group, Trump adviser Roger Stone has revealed that he was alerted by Microsoft and then by the FBI that both his Microsoft and Gmail accounts were compromised by hackers.

Google says it has blocked “numerous” ongoing attempts to log in to the accounts of officials on both campaigns, has sent warnings to the affected individuals, and has worked with law enforcement investigating the attempted breaches. The FBI launched its investigation into the phishing attacks in June, according to the Post.

APT42 has long been one of—or perhaps _the_—most active Iranian hacking group in the Middle East, Mandiant’s Hultquist says. But the group has been “pretty limited to espionage” in the past, Hultquist notes. He points out, however, that the IRGC as a whole has used its access to victim networks to go far beyond spying in past cases, launching data-destroying disruptive cyberattacks or hacking and leaking emails in so-called “influence operations,” as may have occurred in the case of the Trump campaign. “It's a reminder that any access obtained for espionage can be used for other means,” Hultquist says.

In its report, Google lays out APT42’s typical phishing operations, which have ranged from directing victims to a fake Google Meet page that tries to trick them into entering their username and password to luring them into a conversation on a messaging platform such as Telegram, WhatsApp, or Signal, where the hackers then send the victim a phishing toolkit designed to intercept their credentials, as well as two-factor authentication codes or account recovery codes. Beyond its presidential campaign targeting, Google says APT42 has also been actively targeting Israeli organizations with phishing websites that impersonate Israeli and Israel-related groups, such as the Washington Institute for Near East Policy, the Brookings Institution, the Jewish Agency, and Project Aladdin.

APT42’s bipartisan political targeting—and its murky connection to hack-and-leak campaigns—should serve as a reminder of how hacking for political influence in US elections has expanded since Russia’s notorious influence operation of 2016, Hultquist says, with effects that are still unfolding. “It’s not just a Russia problem anymore. It's broader than that,” Hultquist says. “There are multiple teams in play. And we have to keep an eye out for all of them.”

A Single Iranian Hacker Group Targeted Both Presidential Campaigns, Google Says

Security researchers say they’ve extracted digital management keys from select electronic lockers and revealed how they could be cloned.

Thousands of electronic lockers found in gyms, offices, and schools could be vulnerable to attacks by criminals using cheap hacking tools to access administrator keys, according to new research.

At the Defcon security conference on Sunday, security researchers Dennis Giese and “braelynn” demonstrated a proof-of-concept attack showing how digital management keys could be extracted from lockers, copied, and then used to open other lockers in the same location. The researchers focused on various models of electronic locks from two of the world’s biggest manufacturers, Digilock and Schulte-Schlagbaum.

Over the past few years, the researchers, who both have backgrounds in lock picking, have been examining various electronic locks that use numerical keypads, allowing people to set and open them with a PIN. The work comes on the back of various examples of hotel door locks being found to be hackable, vulnerabilities in high-security locks, and commercial safes being alleged to have backdoors.

For the research, Giese and braelynn purchased electronic locks on eBay, snapping up those sold after some gyms closed during the Covid-19 pandemic and from other failed projects. Giese focused on Digilock, while braelynn looked at Schulte-Schlagbaum. Over the course of the research, they looked at legacy models from Digilock dating from 2015 to 2022 and models from Schulte-Schlagbaum from 2015 to 2020. (They also purchased some physical management keys for Digilock systems.)

Showing how security flaws could be abused by a prepared hacker, the researchers say they can take the electronic lock apart, then extract the device’s firmware and stored data. This data, Giese says, can contain PINs that have been set, management keys, and programming keys. The manager key ID can be copied to a Flipper Zero or cheap Arduino circuit board and used to open other lockers, Giese says.

“If you access one lock, we can open all of them in whatever the unit is—the whole university, the whole company,” Giese says. “We can clone and emulate keys very easily, and the tools aren’t that complicated.” Whoever owns the lockers manages them, Giese says.

Ahead of developing this proof-of-concept attack, Giese says, it took some time and effort to understand how the locker systems function. They took the locks apart and used cheap debugging tools to access the devices’ erasable, programmable read-only memory, known as EEPROM. Often, in the locks they tested, this was not secured, allowing data to be pulled from the system.

“From the EEPROM, we can pull out the programming key ID, all manager key IDs, and the user PIN/ User RFID UID,” Giese says. “Newer locks erase the set user PIN when the locker is unlocked. But the PIN remains if the locker was opened with a manager key/programming key.”

The researchers say they reported the findings to both impacted companies, adding they had spoken to Digilock about the findings. Digilock tells WIRED it has issued a fix for vulnerabilities found. The researchers say Schulte-Schlagbaum did not respond to their reports; the company did not respond to WIRED's request for comment.

Your Gym Locker May Be Hackable

Please don’t, actually. But do update your Shimano Di2 shifters’ software to prevent a new radio-based form of cycling sabotage.

Professional cycling has, in its recent history, been prone to a shocking variety of cheating methods and dirty tricks. Performance-enhancing drugs. Tacks strewn on race courses. Even stealthy motors hidden inside of wheel hubs.

Now, for those who fail to download a software patch for their gear shifters—yes, bike components now get software updates—there may be hacker saboteurs to contend with, too.

At the Usenix Workshop on Offensive Technologies earlier this week, researchers from UC San Diego and Northeastern University revealed a technique that would allow anyone with a few hundred dollars of hardware to hack Shimano wireless gear-shifting systems of the kind used by many of the top cycling teams in the world, including in recent events like the Olympics and the Tour de France. Their relatively simple radio attack would allow cheaters or vandals to spoof signals from as far as 30 feet away that trigger a target bike to unexpectedly shift gears or to jam its shifters and lock the bike into the wrong gear.

The trick would, the researchers say, easily be enough to hamper a rival on a climb or, if timed to certain intense moments of a race, even cause dangerous instability. “The capability is full control of the gears. Imagine you're going uphill on a Tour de France stage: If someone shifts your bike from an easy gear to a hard one, you're going to lose time,” says Earlence Fernandes, an assistant professor at UCSD’s Computer Science and Engineering department. “Or if someone is sprinting in the big chain ring and you move it to the small one, you can totally crash a person's bike like that.”

Here's a video demonstration of the researchers’ hacking technique:

The researchers' technique exploits the increasingly electronic nature of modern high-end bicycles, which now have digital components like power meters, wireless control of fork suspensions, and wireless shifters. “Modern bicycles are cyber-physical systems,” the researchers note in their Usenix paper. Almost all professional cyclists now use electronic shifters, which respond to digital signals from shifter controls on the bike's handlebars to move a bicycle's chain from gear to gear, generally more reliably than mechanical shifting systems. In recent years, those wired electronic shifters have transitioned again to wireless versions that pair via a radio connection, such as the popular Di2 wireless shifters sold by the Japanese cycling component firm Shimano, which the researchers focused on.

To exploit those wireless components and sabotage a specific target bike, the researchers' technique does require that a hacker first intercept the target's gear-shift signals at some point before they carry out their attack. The hacker can then replay those signals—even months later—to cause the bike to shift at the hacker's command.

To carry out that eavesdrop-and-replay attack, the researchers used a $1500 USRP software-defined radio, an antenna, and a laptop. They say though that a $350 HackRF would work just as well, and point out that their hardware setup could be miniaturized to the degree that it could be hidden along the sidelines of a race, in a cycling team car, or even in the back pouch of a rider's jersey, such as by implementing it in a Raspberry Pi mini-computer.

Jamming wireless shifters with that toolkit would be considerably easier than even replay attacks, the researchers say. While a jamming attack could prevent a specific rider from shifting gears if a hacker were able to first pick up one of their wireless shifting signals, a saboteur could also simply broadcast a jamming signal at the frequency used by all Shimano shifters, potentially disrupting a large group of racers. The researchers even say that it would be possible to read the shifting signals from an entire peloton of cyclists and then jam everyone _except_ a chosen rider. “You can basically jam everyone except you,” says Northeastern professor Aanjhan Ranganathan, another author of the paper.

Shimano’s Di2 wireless shifting components and the researchers’ hacking toolkit. They say their hardware could easily be miniaturized, by using a Raspberry Pi mini-computer for instance, to make it small enough to be hidden along the sidelines of a race, in a cycling team car, or even in the back pouch of a rider’s jersey.Courtesy of UCSD and Northeastern University

The researchers first reached out to Shimano about their research in March, and the company's engineers worked with them closely to develop a patch. A Shimano spokesperson wrote in a statement to WIRED that the company “identified and created a new firmware update to enhance the security of the Di2 wireless communication systems.”

Shimano says it has provided that firmware update to the professional cycling teams that use its components. But it says its fix won't be more widely available until late August and declined to explain exactly how its update prevents the attacks the researchers identified. “We can share that this update is intended to improve wireless transmission across Shimano Di2 component platforms," the company writes. “We cannot share details on the exact fix at this moment, for obvious security reasons.”

Exactly how the patch will be deployed to customers isn't quite clear either. The company writes that “riders can perform a firmware update on the rear derailleur” using Shimano’s E-TUBE Cyclist smartphone app. But it fails to mention whether the fix will apply to the front derailleur. “More information about this process and steps riders can take to update their Di2 systems will be available shortly,” it concludes.

While Shimano's patching plan leaves a week or two-week gap between the researchers' public presentation of their bike-hacking technique at Usenix and the broad rollout of a fix for customers, UCSD professor Fernandes argues it's unlikely that average riders will be targeted with their technique—at least not immediately. “I find it hard to believe that someone will want to launch such an attack on me during my Saturday group ride,” Fernandes says.

Professional cyclists, however, should be sure to implement the early patch that Shimano has already provided, the researchers say. They note, too, that other brands of wireless shifters may be vulnerable to similar hacking techniques: They focused on Shimano only because it has the largest market share.

In the ruthless world of competitive cycling, which has been rocked to its foundations in recent decades by doping scandals, they argue that rivals hacking each others' shifters is not at all a far-fetched scenario. “This is, in our opinion, a different kind of doping,” says Fernandes. “It leaves no trace, and it allows you to cheat in the sport.”

More broadly, they argue that their radio-based bike hacking research is a cautionary tale about the temptation to add wireless electronic features to every technology, from garage doors to cars to bicycles, and the unintended consequences of that long-term trend—namely, that they've all become vulnerable to forms of replay and jamming attacks of the kind that Shimano is now scrambling to fix.

“This is a repeating pattern,” says Northeastern's Ranganathan, who has also developed solutions for replay attacks on cars’ keyless entry systems. “When manufacturers start putting in wireless features in their products, it has an impact on real-world control systems. And that can cause real physical harm.”

_Corrected at 8/14/2024 at 10:00 am ET to note the correct software-defined radio used in the researchers' experimental setup and remove an incorrect reference to Bluetooth._

Want to Win a Bike Race? Hack Your Rival’s Wireless Shifters

Security researcher Bill Demirkapi found more than 15,000 hardcoded secrets and 66,000 vulnerable websites—all by searching overlooked data sources.

If you know where to look, plenty of secrets can be found online. Since the fall of 2021, independent security researcher Bill Demirkapi has been building ways to tap into huge data sources, which are often overlooked by researchers, to find masses of security problems. This includes automatically finding developer secrets—such as passwords, API keys, and authentication tokens—that could give cybercriminals access to company systems and the ability to steal data.

Today, at the Defcon security conference in Las Vegas, Demirkapi is unveiling the results of this work, detailing a massive trove of leaked secrets and wider website vulnerabilities. Among at least 15,000 developer secrets hard-coded into software, he found hundreds of username and password details linked to Nebraska’s Supreme Court and its IT systems; the details needed to access Stanford University’s Slack channels; and more than a thousand API keys belonging to OpenAI customers.

A major smartphone manufacturer, customers of a fintech company, and a multibillion-dollar cybersecurity company are counted among the thousands of organizations that inadvertently exposed secrets. As part of his efforts to stem the tide, Demirkapi hacked together a way to automatically get the details revoked, making them useless to any hackers.

In a second strand to the research, Demirkapi also scanned data sources to find 66,000 websites with dangling subdomain issues, making them vulnerable to various attacks including hijacking. Some of the world’s biggest websites, including a development domain owned by The New York Times, had the weaknesses.

While the two security issues he looked into are well-known among researchers, Demirkapi says that turning to unconventional datasets, which are usually reserved for other purposes, allowed thousands of issues to be identified en masse and, if expanded, offers the potential to help protect the web at large. “The goal has been to find ways to discover trivial vulnerability classes at scale,” Demirkapi tells WIRED. “I think that there’s a gap for creative solutions.”

**Spilled Secrets; Vulnerable Websites**

It is relatively trivial for a developer to accidentally include their company’s secrets in software or code. Alon Schindel, the vice president of AI and threat research at the cloud security company Wiz, says there’s a huge variety of secrets that developers can inadvertently hard-code, or expose, throughout the software development pipeline. These can include passwords, encryption keys, API access tokens, cloud provider secrets, and TLS certificates.

“The most acute risk of leaving secrets hard-coded is that if digital authentication credentials and secrets are exposed, they can grant adversaries unauthorized access to a company’s code bases, databases, and other sensitive digital infrastructure,” Schindel says.

The risks are high: Exposed secrets can result in data breaches, hackers breaking into networks, and supply chain attacks, Schindel adds. Previous research in 2019 found thousands of secrets were being leaked on GitHub every day. And while various secret scanning tools exist, these largely are focused on specific targets and not the wider web, Demirkapi says.

During his research, Demirkapi, who first found prominence for his teenage school-hacking exploits five years ago, hunted for these secret keys at scale—as opposed to selecting a company and looking specifically for its secrets. To do this, he turned to VirusTotal, the Google-owned website, which allows developers to upload files—such as apps—and have them scanned for potential malware.

Thousands of Corporate Secrets Were Left Exposed. This Guy Found Them All

Allan “dwangoAC” has made it his mission to expose speedrunning phonies. At the Defcon hacker conference, he’ll challenge one record that's stood for 15 years.

Speedrunning video games, the competitive field of playing through digital games as quickly as possible, has in recent years been elevated into something between a virtuosic form of fingers-and-thumbs athletics and a highly technical science. The best speedruns reduce epic games meant to take dozens of hours to single-digit minutes through a combination of exploiting glitch-enabled shortcuts and inhuman skill.

A little too inhuman, in some cases. Speedrunning, it turns out, is plagued with fake records set by cheaters who splice together video clips to falsify evidence or use rule-breaking software to gain unfair advantages. One speedrunner and hacker named Allan Cecil has made it his personal mission to catch them.

In a talk at the Defcon hacker conference in Las Vegas today, the details of which WIRED reviewed in advance, Cecil plans to present what he alleges is evidence that a speedrunning record for the 1996 PC game _Diablo_, which has stood for more than 15 years and holds a spot in the _Guinness Book of World Records_, was in fact the result of rule-breaking techniques that should disqualify it. If Cecil and the team of investigators who have worked with him over recent months succeed at tearing down that seemingly untouchable benchmark, it will be the third such high-profile speedrun that he'll have helped to debunk, and the second in just the last year.

Cecil, who is better known in the gaming world by his handle dwangoAC, came into this strange role as a speedrun debunker from an equally niche hobby: He's known as an expert practitioner of so-called “tool-assisted speedruns,” using emulator software to run a game in a controlled environment to find the limits of what that game’s speedrun can be—an area of speedrunning that some purists once considered, itself, to be a kind of cheating. Cecil maintains instead that those tool-assisted speedruns, in which players meticulously rewind, replay, hone, and perfect their runs frame by frame, can be its own valid form of competition, or even art.

Cecil says he arrived at his fixation with catching cheaters in part out of a determination to protect this lesser-known field of speedrunning from those who would surreptitiously use the same tools in deceptive ways, essentially turning tool-assisted speedruns into a kind of speedrun doping, rather than an honest avocation. “Making a tool-assisted speedrun is a transformative work of art that humans laboriously spend months on, or even years,” says Cecil. “But you definitely do _not_ use tool-assisted speedrun techniques and then try to pretend that it was just human effort. And seeing people do that pisses me off.”

As a staff member at the tool-assisted speedrun website TASvideos.org and an organizer of many epic speedrunning feats—such as one that famously used coding glitches in the Zelda game _Ocarina of Time_ to rewrite the game's ending—Cecil has become a fixture of the speedrunning world. He's also the creator of TASBot, a robot that connects to the controller ports of video game consoles to reproduce controller inputs, so that recorded speedruns can be replayed and verified on original gaming hardware, a spectacle that gamers love so much that livestreams featuring the robot have raised $1.5 million in donations to charitable causes, according to Cecil’s count.

In recent years, however, Cecil has taken his obsession with tool-assisted speedrunning in a different direction: He's turned it into a means to catch the cheaters that threaten his pastime's legitimacy. If he can show that even a polished tool-assisted speedrun in a certain game isn't as fast as a purported human record—as he's done in all three records he's attempted to debunk—that demonstration can serve as the first step in suggesting that a record was likely falsified. He's found, too, that the process of creating that tool-assisted run often produces new revelations about what's possible—or impossible—in an unassisted human attempt.

TASbot wearing Cecil’s Defcon speaker badge.Photograph: Roger Kisby

Cecil's latest record-busting effort may be the most controversial one he's undertaken yet. At Defcon, he'll present evidence that he alleges should disqualify the record of Maciej “groobo” Maselewski, a Polish speedrunner who holds the Guinness record for not only the fastest _Diablo_ speedrun but also the fastest role-playing game speedrun of any kind. Maselewski's _Diablo_ run, 3 minutes and 12 seconds long, has withstood all challengers since 2009.

Cecil says his suspicions that Maselewski had broken speedrunning rules were first triggered when he and another speedrunner, Matthew “funkmastermp” Petroff, set out to make a tool-assisted speedrun for _Diablo_ in January. They quickly came to the conclusion they'd never match Maselewski's 3-minute, 12-second time, no matter how much they perfected their run or how lucky they got in the game's randomized dungeon layouts. That led them to assemble a team of investigators who ultimately found what they believe to be a long list of inconsistencies in software versions and items, missing frames, and other signs of potential tampering in the video of Maselewski's run, all of which they've assembled in a detailed document posted to Cecil's website. “No one could get anywhere close to that time. Now we know why,” Cecil says. “The answer seemed to be that groobo had cheated in many, many ways.”

Maselewski, when WIRED reached him for a response, immediately denied any such foul play. In an email, he pointed to the fact that his run was always understood to be “segmented"—essentially edited together, level by level, a commonly accepted category of speedrun. “It was never passed off as anything else,” Maselewski writes. “Hearing that there has been a team of researchers working on this is wild.” In a subsequent text exchange with Cecil and his collaborators that Cecil shared with WIRED, Maselewski described the attempt to debunk his record as a “witch hunt.”

Maselewski's simple explanation that the speedrun was segmented, however, isn't enough, Cecil argues. He claims that some dungeon layouts in Maselewski's run couldn't be generated even in a single segment of a run without altering the game's data, and in one case, a crucial item conveniently appears that defies the game's logic—Naj's Puzzler, a staff that allows the player to teleport across distances—and alleges a piece of performance-enhancing software known as a “trainer” must have been used, all of which could disqualify Maselewski's run. (Maselewski did not immediately respond to WIRED’s follow-up question specifically about Cecil’s allegation that he had used a trainer.)

The night before Cecil's Defcon talk, Maselewski wrote in a final email to WIRED that he believes those alleging that he cheated are using faulty tools with an incomplete picture of _Diablo_'s complexities. “Dwango is out to tell a story. Did I cheat? No,” Maselewski writes. “But what is true or not does not matter at this point, because the wonder of exploration has already overstayed its welcome for a small group of people, and the script has already been written.”

When WIRED reached out to the _Guinness Book of World Records_ to ask if it would take down Maselewski's record, a spokesperson responded noncommittally that “we value any feedback on our record titles and are committed to maintaining the highest standards of accuracy.” An administrator for Speed Demos Archive or SDA, another speedrun record-keeping website where Maselewski holds a similar _Diablo_ record, seemed to be more persuaded by Cecil's evidence. That administrator, who goes by the handle “ktwo” and asked that WIRED not include their real name, says that SDA hasn't officially reached a verdict and is still waiting to hear Maselewski's explanation.

Things are not looking good for groobo, however. “To be clear, we have made a preliminary decision, based on the available information,” ktwo writes “The staff agrees that the analysis raises questions about the validity of the run that need to be addressed, or else the run will be unpublished from SDA. The admin team is currently discussing these questions with the runner. Once that discussion has concluded, a final decision will be made.”

Cecil's involvement in investigating gaming records began in 2017, when the speedrunner Eric “Omnigamer” Koziel, who was writing a book about speedrunning, began re-examining a record set by Todd Rogers for the Atari 2600 racing game _Dragster_. Rogers' record time, 5.51 seconds, had persisted for a remarkable 35 years. But when Koziel reverse engineered Dragster's code to try to understand how Rogers had achieved that time, he found that tricks Rogers said he'd used—such as starting the game in second gear—wouldn't have provided the advantage Rogers claimed.

“The goal was never to point to someone and say, ‘Hey, they're cheating,’” says Koziel. “It was to try to find the truth.”

Cecil, who knew Koziel from the speedrun community, offered to help develop a tool-assisted speedrun they could replay via TASBot on a real Atari 2600 to show that, even on that original hardware, Rogers' record was impossible. They found that TASBot's theoretically perfect performance was 5.57 seconds, slower than Rogers' alleged time. Despite Rogers’ objections, his three-and-a-half-decade-old record was erased from the annals of the gaming records keeper Twin Galaxies—along with all his other records on the site—and Guinness stripped his world record for “longest-standing video game record.”

"Although I disagree with their decision, I must applaud them for their strong stance on the matter of cheating," Rogers wrote in a lengthy public Facebook post responding to the Twin Galaxies decision.

After a seven year hiatus in which he was mostly focused on TASBot projects, Cecil found himself involved in investigating another legendary speedrun earlier this year when a group of gamers made it their goal to beat every level of _Super Mario Maker_. That Wii U game, released in 2015, allowed users to upload their own levels of the game for others to play—if they could prove that the level was beatable by recording a video of themselves finishing it. Yet one such level, called “Trimming the Herbs,” appeared to be impossible. For years, no one but its creator had been able to complete it.

In an effort to help this group of _Super Mario Maker_\-obsessed gamers, Cecil offered to develop a tool-assisted speedrun for the level. He found that it was nearly impossible to clear it reliably, in part due to variances in the Bluetooth communications between the Wii U and its controllers. In that case, the level's creator came forward in the midst of the investigation and confessed he'd beaten the level by altering the internal hardware of his Wii U gamepad—a trick he intended as a kind of friendly prank but had never publicly explained.

In his new attempt to debunk Maselewski's _Diablo_ record, Cecil doesn't expect any such amicable agreement on the facts—or a confession. But he's confident that he and the researchers who've worked with him can remove Maselewski's record and make room for speedrunners to approach the game again. To Cecil’s surprise, they found just in recent days that they _could_, in fact, beat Maselewski's record with a tool-assisted speedrun—thanks to new _Diablo_ techniques they found in their investigation—finishing the game in 2 minutes and 45 seconds without using any of his alleged rule-breaking alterations. Meanwhile, Cecil says _Diablo_ speedrunner “xavier\_sb” has completed a run of the game in just over 4 minutes and 40 seconds, which would stand as the new record if Maselewski's is expunged.

Cecil says this shows, already, how the “chilling effect” of what he alleges to be an impossible record is lifting. “People had just stopped trying, because there wasn't any point,” Cecil says. Now the _Diablo_ speedrunning race is on, once again.

Cecil says he hopes that his work to keep speedrunners honest will not only help traditional speedrunning to thrive, but fuel the tool-assisted kind that he has helped pioneer, too. The key, he maintains, will be drawing a clear line between those who use software tools to play games with inhuman precision as an honest art form, and those who use them for deception. “Both the jerk and the jester bend the established rules. We despise the vileness of the jerk and delight in the shenanigans of the jester,” Cecil says. “But one thing has held true: No one likes a cheat.”

The Hacker Who Hunts Video Game Speedrunning Cheaters

On the hunt for corporate devices being sold secondhand, a researcher found a trove of Apple corporate data, a Mac Mini from the Foxconn assembly line, an iPhone 14 prototype, and more.

It's probably been a while since anyone thought about Apple's router and network storage combo called Time Capsule. Released in 2008 and discontinued in 2018, the product has mostly receded into the sands of gadget time. So when independent security researcher Matthew Bryant recently bought a Time Capsule from the United Kingdom on eBay for $38 (plus more than $40 to ship it to the United States), he thought he would just be getting one of the stalwart white monoliths at the end of its earthly journey. Instead he stumbled on something he didn't expect: a trove of data that appeared to be a copy of the main backup server for all European Apple Stores during the 2010s. The information included service tickets, employee bank account data, internal company documentation, and emails.

“It had everything you can possibly imagine,” Bryant tells WIRED. “Files had been deleted off the drive, but when I did the forensics on it, it was definitely not empty.”

Bryant hadn't stumbled on the Time Capsule completely by accident. At the Defcon security conference in Las Vegas on Saturday, he's presenting findings from a months-long project in which he scraped secondhand electronics listings from sites like eBay, Facebook Marketplace, and China's Xianyu, and then ran computer vision analysis on them in an attempt to detect devices that were once part of corporate IT fleets.

Bryant realized that the sellers hawking office devices, prototypes, and manufacturing equipment often weren't aware of their products' significance, so he couldn't comb tags or descriptions to find enterprise gems. Instead, he devised an optical character recognition processing cluster by chaining together a dozen dilapidated second-generation iPhone SEs and harnessing Apple's Live Text optical character-recognition feature to find possible inventory tags, barcodes, or other corporate labels in listing photos. The system monitored for new listings, and if it turned up a possible hit, Bryant would get an alert so he could assess the device photos himself.

In the case of the Time Capsule, the listing photos showed a label on the bottom of the device that said “Property of Apple Computer, Expensed Equipment.” After he evaluated the Time Capsule's contents, Bryant notified Apple about his findings, and the company's London security office eventually asked him to ship the Time Capsule back. Apple did not immediately return a request from WIRED for comment about Bryant's research.

“The main company in the talk for proofs of concept is Apple, because I view them as the most mature hardware company out there. They have all their hardware specially counted, and they really care about the security of their operations quite a bit,” Bryant says. “But with any Fortune 500 company, it’s basically a guarantee that their stuff will end up on sites like eBay and other secondhand markets eventually. I can’t think of any company where I haven’t seen at least some piece of equipment and got an alert on it from my system.”

Another alert from his search system led Bryant to purchase a prototype iPhone 14 intended for developer use internally at Apple. Such iPhones are coveted by both bad actors and security researchers because they often run special versions of iOS that are less locked down than the consumer product and include debugging functionality that's invaluable for gaining insight into the platform. Apple runs a program to give certain researchers access to similar devices, but the company only grants these special iPhones to a limited group, and researchers have told WIRED that they are typically outdated iPhone models. Bryant says he paid $165 for the developer-use iPhone 14.

Finally, Bryant says that manufacturing and assembly-line devices can be particularly revealing and can also be found on secondhand markets—especially platforms in China, since so many electronics are assembled in the country. Bryant was curious to see if he could find any equipment that had formerly been used in a Foxconn factory where iPhones are notoriously assembled. By analyzing Chinese listings with his computer vision system, Bryant says he was able to piece together how Foxconn’s asset management system works and how the company labels its devices—particularly those used on the factory floor. Eventually he found a Mac Mini that had a bunch of the Foxconn tags on it and had seemingly been used on a Foxconn quality-and-assurance testing line. But the computer was simply listed for parts, because the photos clearly showed that it had a large drill hole running through the device.

After examining schematics of various generations of Mac Minis, though, Bryant concluded that it was possible the drill had missed the magnetic tray where data would be stored on the hard drive. He took a chance and ordered the computer from China and assessed it himself. Bryant isn't a hardware expert, but once he received the device, it also seemed to him that the physical destruction had likely not achieved its goal. So he sent the Mac Mini to a forensics lab in Los Angeles, which was ultimately able to recover all the data from the drive.

“It had the internal software that Apple uses on their factory line to do testing, including special interfaces for communicating with prototypes and QA units,” Bryant says. “And the computer also contained credentials for Foxconn and logs.”

Bryant again reported his findings to Apple and returned the Mac Mini to them.

The project contains a warning for companies, both about the inevitability of having some device attrition and the importance of taking asset management and deprovisioning seriously. For hackers and eagle-eyed deal seekers alike, though, rogue corporate devices may be a new item for the shopping list.

Apple Prototypes and Corporate Secrets Are for Sale Online—If You Know Where to Look

The vulnerabilities, which have been patched, may have novel appeal to attackers as an avenue to compromising phones.

Demand for graphics processing units or GPUs has exploded in recent years as video rendering and artificial intelligence systems have expanded the need for processing power. And while most of the most visible shortages (and soaring stock prices) relate to top-tier PC and server chips, mobile graphics processors are the version that everyone with a smartphone is using everyday. So vulnerabilities in these chips or how they're implemented can have real-world consequences. That's exactly why Google's Android vulnerability hunting red team set its sights on open-source software from the chip giant Qualcomm that's widely used to implement mobile GPUs.

At the Defcon security conference in Las Vegas on Friday, three Google researchers presented more than nine vulnerabilities—now patched—that they discovered in Qualcomm's Adreno GPU, a suite of software used to coordinate between GPUs and an operating system like Android on Qualcomm-powered phones. Such “drivers” are crucial to how any computer is designed and have deep privileges in the kernel of an operating system to coordinate between hardware peripherals and software. Attackers could exploit the flaws the researchers found to take full control of a device.

For years, engineers and attackers alike have been most focused on potential vulnerabilities in a computer's central processing unit (CPU) and have optimized for efficiency on GPUs, leaning on them for raw processing power. But as GPUs become more central to everything a device does all the time, hackers on both ends of the spectrum are looking at how GPU infrastructure could be exploited.

“We are a small team compared to the big Android ecosystem—the scope is too big for us to cover everything, so we have to figure out what will have the most impact,” says Xuan Xing, manager of Google's Android Red Team. “So why did we focus on a GPU driver for this case? It's because there’s no permission required for untrusted apps to access GPU drivers. This is very important, and I think will attract lots of attackers’ attention.”

Xing is referring to the fact that applications on Android phones can talk to the Adreno GPU driver directly with “no sandboxing, no additional permission checks,” as he puts it. This doesn't in itself give applications the ability to go rogue, but it does make GPU drivers a bridge between the regular parts of the operating system (where data and access are carefully controlled), and the system kernel, which has full control over the entire device including its memory. “GPU drivers have all sorts of powerful functions,” Xing says. “That mapping in memory is a powerful primitive attackers want to have.”

The researchers say the vulnerabilities they uncovered are all flaws that come out of the intricacies and complicated interconnections that GPU drivers must navigate to coordinate everything. To exploit the flaws, attackers would need to first establish access to a target device, perhaps by tricking victims into side-loading malicious apps.

“There are a lot of moving parts and no access restrictions, so GPU drivers are readily accessible to pretty much every application,” says Eugene Rodionov, technical leader of the Android Red Team. “What really makes things problematic here is complexity of the implementation—that is one item which accounts for a number of vulnerabilities.”

Qualcomm released patches for the flaws to “original equipment manufacturers” (OEMs) that use Qualcomm chips and software in the Android phones they make. “Regarding the GPU issues disclosed by Android Security Red Team, patches were made available to OEMs in May 2024,” a Qualcomm Spokesperson tells WIRED. “We encourage end users to apply security updates from device makers as they become available.”

The Android ecosystem is complex, and patches must move from a vendor like Qualcomm to OEMs and then get packaged by each individual device maker and delivered to users' phones. This trickle-down process sometimes means that devices can be left exposed, but Google has spent years investing to improve these pipelines and streamline communication.

Still, the findings are yet another reminder that GPUs themselves and the software supporting them have the potential to become a critical battleground in computer security.

As Rodionov puts it, “combining high complexity of the implementation with wide accessibility makes it a very interesting target for attackers.”

Google Researchers Found Nearly a Dozen Flaws in Popular Qualcomm Software for Mobile GPUs

Six vulnerabilities in ATM-maker Diebold Nixdorf’s popular Vynamic Security Suite could have been exploited to control ATMs using “relatively simplistic attacks.”

There is a grand tradition at the annual Defcon security conference in Las Vegas of hacking ATMs. Unlocking them with safecracking techniques, rigging them to steal users' personal data and PINs, crafting and refining ATM malware and, of course, hacking them to spit out all their cash. Many of these projects targeted what are known as retail ATMs, freestanding devices like those you'd find at a gas station or a bar. But on Friday, independent researcher Matt Burch is presenting findings related to the “financial” or “enterprise” ATMs used in banks and other large institutions.

Burch is demonstrating six vulnerabilities in ATM-maker Diebold Nixdorf’s widely deployed security solution, known as Vynamic Security Suite (VSS). The vulnerabilities, which the company says have all been patched, could be exploited by attackers to bypass an unpatched ATM's hard drive encryption and take full control of the machine. And while there are fixes available for the bugs, Burch warns that, in practice, the patches may not be widely deployed, potentially leaving some ATMs and cash-out systems exposed.

“Vynamic Security Suite does a number of things—it has endpoint protection, USB filtering, delegated access, and much more,” Burch tells WIRED. “But the specific attack surface that I’m taking advantage of is the hard drive encryption module. And there are six vulnerabilities, because I would identify a path and files to exploit, and then I would report it to Diebold, they would patch that issue, and then I would find another way to achieve the same outcome. They’re relatively simplistic attacks.”

The vulnerabilities Burch found are all in VSS's functionality to turn on disk encryption for ATM hard drives. Burch says that most ATM manufacturers rely on Microsoft's BitLlocker Windows encryption for this purpose, but Diebold Nixdorf’s VSS uses a third-party integration to run an integrity check. The system is set up in a dual-boot configuration that has both Linux and Windows partitions. Before the operating system boots, the Linux partition runs a signature integrity check to validate that the ATM hasn't been compromised, and then boots it into Windows for normal operation.

“The problem is, in order to do all of that, they decrypt the system, which opens up the opportunity,” Burch says. “The core deficiency that I’m exploiting is that the Linux partition was not encrypted.”

Burch found that he could manipulate the location of critical system validation files to redirect code execution; in other words, grant himself control of the ATM.

Diebold Nixdorf spokesperson Michael Jacobsen tells WIRED that Burch first disclosed the findings to them in 2022 and that the company has been in touch with Burch about his Defcon talk. The company says that the vulnerabilities Burch is presenting were all addressed with patches in 2022. Burch notes, though, that as he went back to the company with new versions of the vulnerabilities over the past couple of years, his understanding is that the company continued to address some of the findings with patches in 2023. And Burch adds that he believes Diebold Nixdorf addressed the vulnerabilities on a more fundamental level in April with VSS version 4.4 that encrypts the Linux partition.

In spite of all of this, Burch says, it would probably still be possible to find a path to exploit similar vulnerabilities, but “it’s significantly harder now.” More importantly, though, he notes that it can involve significant infrastructure initiatives for large institutions to actually update enterprise ATMs and it's very possible that there are ATMs and cash-out systems that are still running old versions of VSS.

“We’re currently working to ensure our customers are up to date and using the current version appropriate for their environment,” Jacobsen tells WIRED. He added that Diebold Nixdorf's customers should not assume that implementing different disk encryption, like Microsoft BitLocker, would be feasible. “One of Matt’s recommendations for switching to an enterprise disk encryption product, especially Bitlocker, is vulnerable in our environments,” Jacobsen says. “A Bitlocker-encrypted machine can be compromised, and Microsoft will not address this, as the ATM use case is not in their scope.”

This may refer to ongoing, real-world attacks on ATM machines that use malware to steal cash from enterprise ATMs made by multiple manufacturers. These incidents illustrate that there are very real concerns about ATM vulnerabilities being exploited, even though most attacks require physically targeting ATMs and can't be carried out remotely.

“Doing the attack requires physical access where you open the top portion of the ATM, pull the hard drive out, and then patch the contents of the hard drive,” Burch says. “An unrehearsed execution would not be easy to do. But it's absolutely feasible if you know what you’re looking at. Similar attacks have been executed in under 10 minutes. Organized crime is presumably training people in how to do these attacks.”

As long as attackers are finding success and making money from ATM cash-out attacks, there will be Defcon talks about what the next frontiers of ATM hacking may look like.

ATM Software Flaws Left Piles of Cash for Anyone Who Knew to Look

Researchers warn that a bug in AMD’s chips would allow attackers to root into some of the most privileged portions of a computer—and that it has persisted in the company’s processors for decades.

Security flaws in your computer's firmware, the deep-seated code that loads first when you turn the machine on and controls even how its operating system boots up, have long been a target for hackers looking for a stealthy foothold. But only rarely does that kind of vulnerability appear not in the firmware of any particular computer maker, but in the chips found across hundreds of millions of PCs and servers. Now security researchers have found one such flaw that has persisted in AMD processors for decades, and that would allow malware to burrow deep enough into a computer's memory that, in many cases, it may be easier to discard a machine than to disinfect it.

At the Defcon hacker conference tomorrow, Enrique Nissim and Krzysztof Okupski, researchers from the security firm IOActive, plan to present a vulnerability in AMD chips they're calling Sinkclose. The flaw would allow hackers to run their own code in one of the most privileged modes of an AMD processor, known as System Management Mode, designed to be reserved only for a specific, protected portion of its firmware. IOActive's researchers warn that it affects virtually all AMD chips dating back to 2006, or possibly even earlier.

Nissim and Okupski note that exploiting the bug would require hackers to already have obtained relatively deep access to an AMD-based PC or server, but that the Sinkclose flaw would then allow them to plant their malicious code far deeper still. In fact, for any machine with one of the vulnerable AMD chips, the IOActive researchers warn that an attacker could infect the computer with malware known as a “bootkit” that evades antivirus tools and is potentially invisible to the operating system, while offering a hacker full access to tamper with the machine and surveil its activity. For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system.

“Imagine nation-state hackers or whoever wants to persist on your system. Even if you wipe your drive clean, it's still going to be there,” says Okupski. “It's going to be nearly undetectable and nearly unpatchable.” Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says.

Nissim sums up that worst-case scenario in more practical terms: “You basically have to throw your computer away.”

In a statement shared with WIRED, AMD acknowledged IOActive's findings, thanked the researchers for their work, and noted that it has “released mitigation options for its AMD EPYC datacenter products and AMD Ryzen PC products, with mitigations for AMD embedded products coming soon.” (The term “embedded,” in this case, refers to AMD chips found in systems such as industrial devices and cars.) For its EPYC processors designed for use in data-center servers, specifically, the company noted that it released patches earlier this year. AMD declined to answer questions in advance about how it intends to fix the Sinkclose vulnerability, or for exactly which devices and when, but it pointed to a full list of affected products that can be found on its website's security bulletin page.

In a background statement to WIRED, AMD emphasized the difficulty of exploiting Sinkclose: To take advantage of the vulnerability, a hacker has to already possess access to a computer's kernel, the core of its operating system. AMD compares the Sinkhole technique to a method for accessing a bank's safe-deposit boxes after already bypassing its alarms, the guards, and vault door.

Nissim and Okupski respond that while exploiting Sinkclose requires kernel-level access to a machine, such vulnerabilities are exposed in Windows and Linux practically every month. They argue that sophisticated state-sponsored hackers of the kind who might take advantage of Sinkclose likely already possess techniques for exploiting those vulnerabilities, known or unknown. “People have kernel exploits right now for all these systems,” says Nissim. “They exist and they're available for attackers. This is the next step.”

IOActive researchers Krzysztof Okupski (left) and Enrique Nissim.Photograph: Roger Kisby

Nissim and Okupski's Sinkclose technique works by exploiting an obscure feature of AMD chips known as TClose. (The Sinkclose name, in fact, comes from combining that TClose term with Sinkhole, the name of an earlier System Management Mode exploit found in Intel chips in 2015.) In AMD-based machines, a safeguard known as TSeg prevents the computer's operating systems from writing to a protected part of memory meant to be reserved for System Management Mode known as System Management Random Access Memory or SMRAM. AMD's TClose feature, however, is designed to allow computers to remain compatible with older devices that use the same memory addresses as SMRAM, remapping other memory to those SMRAM addresses when it's enabled. Nissim and Okupski found that, with only the operating system's level of privileges, they could use that TClose remapping feature to trick the SMM code into fetching data they've tampered with, in a way that allows them to redirect the processor and cause it to execute their own code at the same highly privileged SMM level.

“I think it's the most complex bug I've ever exploited,” says Okupski.

Nissim and Okupski, both of whom specialize in the security of low-level code like processor firmware, say they first decided to investigate AMD's architecture two years ago, simply because they felt it hadn't gotten enough scrutiny compared to Intel, even as its market share rose. They found the critical TClose edge case that enabled Sinkclose, they say, just by reading and rereading AMD's documentation. “I think I read the page where the vulnerability was about a thousand times,” says Nissim. “And then on one thousand and one, I noticed it.” They alerted AMD to the flaw in October of last year, they say, but have waited nearly 10 months to give AMD more time to prepare a fix.

For users seeking to protect themselves, Nissim and Okupski say that for Windows machines—likely the vast majority of affected systems—they expect patches for Sinkclose to be integrated into updates shared by computer makers with Microsoft, who will roll them into future operating system updates. Patches for servers, embedded systems, and Linux machines may be more piecemeal and manual; for Linux machines, it will depend in part on the distribution of Linux a computer has installed.

Nissim and Okupski say they agreed with AMD not to publish any proof-of-concept code for their Sinkclose exploit for several months to come, in order to provide more time for the problem to be fixed. But they argue that, despite any attempt by AMD or others to downplay Sinkclose as too difficult to exploit, it shouldn't prevent users from patching as soon as possible. Sophisticated hackers may already have discovered their technique—or may figure out how to after Nissim and Okupski present their findings at Defcon.

Even if Sinkclose requires relatively deep access, the IOActive researchers warn, the far deeper level of control it offers means that potential targets shouldn't wait to implement any fix available. “If the foundation is broken,” says Nissim, "then the security for the whole system is broken."

‘Sinkclose’ Flaw in Hundreds of Millions of AMD Chips Allows Deep, Virtually Unfixable Infections

A team of researchers have developed a method for extracting authentication keys out of HID encoders, which could allow hackers to clone the types of keycards used to secure offices and other areas worldwide.

HID Global's keycards—the company's radio-frequency-enabled plastic rectangles that are inside hundreds of millions of pockets and purses—serve as the front line of physical security for hundreds of companies and government agencies. They can also be spoofed, it turns out, by any hacker clever enough to read one of those cards with a hidden device that brushes within about a foot of it, obtain an HID encoder device, and use it to write the stolen data to a new card.

Now a team of security researchers is about to reveal how one of HID's crucial protections against that cloning technique—secret cryptographic keys stored inside its encoders—has been defeated, significantly lowering the barrier to copying credentials that let intruders impersonate staff and unlock secure areas worldwide.

At the Defcon hacker conference later today, those researchers plan to present a technique that allowed them to pull authentication keys out of the most protected portion of the memory of HID encoders, the company's devices used for programming the keycards used in customer installations. Instead of requiring that an intruder get access to an HID encoder, whose sale the company attempts to restrict to known customers, the method the researchers plan to show on the Defcon stage now potentially allows HID's secret keys to be pulled out of any encoder, shared among hackers, and even sold or leaked over the internet, then used to clone devices with any off-the-shelf RFID encoder tool.

“Once the chain of custody is broken, the vendor no longer has control over who has the keys and how they’re used,” says Babak Javadi, cofounder of the security firm the CORE Group and one of the four independent researchers who found the new HID hacking technique. “And that control is what all the security depends on.”

The team of security researchers presenting HID’s vulnerabilities at Defcon: (from left) Kate Gray, Babak Javadi, Aaron Levy and Nick Draffen.Photograph: Roger Kisby

The researchers' method, presented publicly for the first time at Defcon, mostly affects the majority of HID's customers with lower-security installations of its products, and it isn't exactly easy to pull off. HID also says it’s been aware of the technique since sometime last year and that it’s quietly worked with many of its customers to help them protect themselves against the cloning technique over the last seven months. But the possibility of extracting and leaking HID's keys considerably raises the risk that hackers—now even those without HID encoders—will be able to surreptitiously scan and copy keycards, says Adam Laurie, a longtime physical security researcher and head of product security at electric-vehicle-charging firm Alpitronic, whom the Defcon speakers briefed on their research ahead of their talk. “If you get that crypto key out of the encoder, then you can derive any component of the system from it,” Laurie says. “It is literally the keys to the kingdom.”

The researchers' technique extracts HID's crucial authentication key out of an HID encoder's Secure Application Module—the most protected element of the encoder's memory—by reverse engineering the software that controls how an encoder interacts with a so-called “configuration” keycard. Those configuration cards are how HID and its customers move authentication keys between elements of the system, such as from encoders to the readers on doors and gates. Javadi uses the analogy of an armored car designated to pick up bags of cash from a bank's vault. “As it turns out, we found a way to fool the bank manager and fabricate the transfer orders that would allow that key transfer to take place,” says Javadi, “We basically took our own armored car—our own configuration card—to the vault, and it gave us the keys.”

(From left) An HID keycard, reader, encoder and configuration card.Photograph: Roger Kisby

Compared with that key extraction, the earlier step in an HID cloning attack, in which a hacker covertly reads a target keycard to copy its data, isn't particular challenging, Javadi says. Javadi, who often performs physical penetration testing for clients, says he's cloned HID keycards to surreptitiously break into customers' facilities, scanning the keycard of unsuspecting staffers with an HID reader hidden in a briefcase with the device's audible beep switched off for added stealth. “It takes a fraction of a second,” Javadi says.

An HID reader capable of pulling data off a keycard from 6 to 12 inches away is relatively large: a 1-foot-square panel. But in addition to hiding it in a briefcase, Javadi has also tested out secreting the reader inside a backpack or a pizza box to silently read a target's keycards. His team even hid one in a paper toilet seat cover dispenser to read the keycard of employees inside a bathroom stall. “We've gotten creative with it,” he says.

The researchers have demonstrated it’s possible to extract HID’s sensitive keys by plugging an encoder into a PC running their software that instructs the encoder to transfer the authentication keys from the encoder to a configuration card without encrypting them. A “sniffer” device that sits between the encoder and configuration card reads the keys, as shown here.Photograph: Roger Kisby

**A Complex Fix in Progress**

When WIRED reached out to HID, the company responded in a statement that it's actually known about the vulnerabilities Javadi's team plans to present since sometime in 2023, when it was first informed about the technique by another security researcher whom HID declines to name. While details of the researchers' key extraction technique will be presented publicly for the first time at Defcon, HID warned customers about the existence of a vulnerability that would allow hackers to clone keycards in an advisory in January, which includes recommendations about how customers can protect themselves—but it offered no software update at that time.

HID has since developed and released software patches for its systems that fix the problem, it says, including a new one that it intends to release “very soon” following the Defcon presentation. The company declined to detail what exactly this latest patch is for or why it was necessary after its previously released software updates, but stated that its timing is unrelated to the researchers' Defcon talk. “Once available, we recommend that customers implement these new steps as soon as they are able,” HID's statement reads.

HID and the team researchers who found its vulnerabilities both say that the cloning technique works most practically against the majority of HID's customers who use so-called “standard” or “shared key” implementations of systems. In those installations, a single set of keys extracted from an encoder could be used to clone keycards for hundreds of customers. So-called “elite” or “custom key” customers, on the other hand, use a unique key for their installation, so it would require hackers to obtain an encoder or extract an encoder's keys for that specific customer, a far more difficult prospect.

A trash bin of all the HID readers the researchers destroyed in the process of developing their technique.Photograph: Roger Kisby

The team presenting at Defcon say that they also found a method to convert an HID reader taken from a customer into an encoder, which would allow cloning of keycards that use those custom keys, too. But that method requires removing the reader from the wall of a customer's building, vastly raising any intruder's risk of being caught or foiled. As such, HID recommends that customers switch to that higher security—and more expensive—custom key implementation.

HID also points out that for many customers, stolen keycard data would only allow cloning if it's written to valid HID keycards. (“HID keycards are not hard to come by,” Javadi notes.) But that safeguard doesn't apply to a common situation in which HID customers' readers are configured to allow for the use of older keycard technologies. So HID recommends that customers also update their cards and disallow the use of older card types in their facilities.

Finally, HID says that “to its knowledge,” none of its encoder keys have leaked or been distributed publicly, and “none of these issues have been exploited at customer locations and the security of our customers has not been compromised.”

Javadi counters that there's no real way to know who might have secretly extracted HID's keys, now that their method is known to be possible. “There are a lot of smart people in the world,” Javadi says. “It’s unrealistic to think we’re the only people out there who could do this.”

Despite HID's public advisory more than seven months ago and the software updates it released to fix the key-extraction problem, Javadi says most of the clients whose systems he's tested in his work don't appear to have implemented those fixes. In fact, the effects of the key extraction technique may persist until HID’s encoders, readers, and hundreds of millions of keycards are reprogrammed or replaced worldwide.

**Time to Change the Locks**

To develop their technique for extracting the HID encoders’ keys, the researchers began by deconstructing its hardware: They used an ultrasonic knife to cut away a layer of epoxy on the back of an HID reader, then heated the reader to desolder and pull off its protected SAM chip. Then they put that chip into their own socket to watch its communications with a reader. The SAM in HID’s readers and encoders are similar enough that this let them reverse engineer the SAM’s commands inside of encoders, too.

Ultimately, that hardware hacking allowed them to develop a much cleaner, wireless version of their attack: They wrote their own program to tell an encoder to send its SAM’s secrets to a configuration card without encrypting that sensitive data—while an RFID “sniffer” device sat between the encoder and the card, reading HID’s keys in transit.

HID systems and other forms of RFID keycard authentication have, in fact, been cracked repeatedly, in various ways, in recent decades. But vulnerabilities like the ones set to be presented at Defcon may be particularly tough to fully protect against. “We crack it, they fix it. We crack it, they fix it,” says Michael Glasser, a security researcher and the founder of Glasser Security Group, who has discovered vulnerabilities in access control systems since as early as 2003. “But if your fix requires you to replace or reprogram every reader and every card, that's very different from a normal software patch.”

On the other hand, Glasser notes that preventing keycard cloning represents just one layer of security among many for any high-security facility—and practically speaking, most low-security facilities offer far easier ways to get in, such as asking an employee to hold a door open for you while you have your hands full. “Nobody says no to the guy holding two boxes of donuts and a box of coffee,” Glasser says.

Javadi says the goal of their Defcon talk wasn't to suggest that HID's systems are particular vulnerable—in fact, they say they focused their years of research on HID specifically because of the challenge of cracking its relatively secure products—but rather to emphasize that no one should depend on any single technology for their physical security.

Now that they have made clear that HID's keys to the kingdom can be extracted, however, the company and its customers may nonetheless face a long and complicated process of securing those keys again. “Now customers and HID have to claw back control—and change the locks, so to speak,” Javadi says. “Changing the locks is possible. But it’s going to be a lot of work.”

Source

Wired