Security researchers have discovered a cryptographic flaw that leaves the YubiKey 5 vulnerable to attack.

The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-sized device vulnerable to cloning when an attacker gains temporary physical access to it, researchers said Tuesday.

The cryptographic flaw, known as a side channel, resides in a small microcontroller used in a large number of other authentication devices, including smartcards used in banking, electronic passports, and the accessing of secure areas. While the researchers have confirmed all YubiKey 5 series models can be cloned, they haven’t tested other devices using the microcontroller, such as the SLE78 made by Infineon and successor microcontrollers known as the Infineon Optiga Trust M and the Infineon Optiga TPM. The researchers suspect that any device using any of these three microcontrollers and the Infineon cryptographic library contains the same vulnerability.

**Patching Not Possible**

YubiKey maker Yubico issued an advisory in coordination with a detailed disclosure report from NinjaLab, the security firm that reverse engineered the YubiKey 5 series and devised the cloning attack. All YubiKeys running firmware prior to version 5.7—which was released in May and replaces the Infineon cryptolibrary with a custom one—are vulnerable. Updating key firmware on the YubiKey isn’t possible. That leaves all affected YubiKeys permanently vulnerable.

“An attacker could exploit this issue as part of a sophisticated and targeted attack to recover affected private keys,” the advisory confirmed. “The attacker would need physical possession of the YubiKey, Security Key, or YubiHSM; knowledge of the accounts they want to target; and specialized equipment to perform the necessary attack. Depending on the use case, the attacker may also require additional knowledge, including username, PIN, account password, or authentication key.”

Side channels are the result of clues left in physical manifestations such as electromagnetic emanations, data caches, or the time required to complete a task that leaks cryptographic secrets. In this case, the side channel is the amount of time taken during a mathematical calculation known as a modular inversion. The Infineon cryptolibrary failed to implement a common side-channel defense known as constant time as it performs modular inversion operations involving the Elliptic Curve Digital Signature Algorithm. Constant time ensures the time-sensitive cryptographic operations execute is uniform rather than variable depending on the specific keys.

More precisely, the side channel is located in the Infineon implementation of the Extended Euclidean Algorithm, a method for, among other things, computing the modular inverse. By using an oscilloscope to measure the electromagnetic radiation while the token is authenticating itself, the researchers can detect tiny execution time differences that reveal a token’s ephemeral ECDSA key, also known as a nonce. Further analysis allows the researchers to extract the secret ECDSA key that underpins the entire security of the token.

In Tuesday’s report, NinjaLab cofounder Thomas Roche wrote:

> In the present work, NinjaLab unveils a new side-channel vulnerability in the ECDSA implementation of Infineon 9 on any security microcontroller family of the manufacturer. This vulnerability lies in the ECDSA ephemeral key (or nonce) modular inversion, and, more precisely, in the Infineon implementation of the Extended Euclidean Algorithm (EEA for short). To our knowledge, this is the first time an implementation of the EEA is shown to be vulnerable to side-channel analysis (contrarily to the EEA binary version). The exploitation of this vulnerability is demonstrated through realistic experiments and we show that an adversary only needs to have access to the device for a few minutes. The offline phase took us about 24 hours; with more engineering work in the attack development, it would take less than one hour.
> 
> After a long phase of understanding Infineon implementation through side-channel analysis on a Feitian 10 open JavaCard smartcard, the attack is tested on a YubiKey 5Ci, a FIDO hardware token from Yubico. All YubiKey 5 Series (before the firmware update 5.7 11 of May 6th, 2024) are affected by the attack. In fact all products relying on the ECDSA of Infineon cryptographic library running on an Infineon security microcontroller are affected by the attack. We estimate that the vulnerability exists for more than 14 years in Infineon top secure chips. These chips and the vulnerable part of the cryptographic library went through about 80 CC certification evaluations of level AVA VAN 4 (for TPMs) or AVA VAN 5 (for the others) from 2010 to 2024 (and a bit less than 30 certificate maintenances).

In an online interview, Roche elaborated:

> Infineon produces “security microcontrollers” or “secure elements.” You can find many of them out there. Some of them (and this is the case for YubiKey 5 Series) run the Infineon cryptographic library (that Infineon develops for their customers that do not want to develop their own).
> 
> This cryptolibrary is highly confidential (even its API is secret, you need to sign an NDA with Infineon just to know the API). Nobody, but Infineon, knows the cryptolibrary details and notably its countermeasures choices.
> 
> This cryptolibrary, as many others, implement the ECDSA (core crypto function of FIDO, but also used in many different applications/protocols). Inside the ECDSA scheme, there are several sub-functions calls, one of them is the modular inversion of the ECDSA ephemeral key. This is a very sensitive operation: any information leaking about the ECDSA ephemeral key would eventually reveal the ECDSA secret key.
> 
> In the Infineon cryptolibrary the modular inversion is not constant time: different ephemeral key will lead to different inversion execution time. When acquiring the electromagnetic radiation of a chip running this function one can extract tiny differences of execution times throughout the inversion computation. These small timing leakages allow us to extract the ephemeral key and then the secret key.

The attacks require about $11,000 worth of equipment and a sophisticated understanding of electrical and cryptographic engineering. The difficulty of the attack means it would likely be carried out only by nation-states or other entities with comparable resources, and then only in highly targeted scenarios. The likelihood of such an attack being used widely in the wild is extremely low. Roche said that two-factor-authentication and one-time password functionalities aren't affected: because they don't use the vulnerable part of the library.

Tuesday's report from NinjaLab outlines the full flow of the cloning attack as:

1.  The adversary steals the login and password of a victim’s application account protected with FIDO (e.g., via a phishing attack).
2.  The adversary gets physical access to the victim’s device during a limited time frame without the victim noticing.
3.  Thanks to the stolen victim’s login and password (for a given application account), the adversary sends the authentication request to the device as many times as is necessary while performing side-channel measurements.
4.  The adversary quietly gives back the FIDO device to the victim.
5.  The adversary performs a side-channel attack over the measurements and succeeds in extracting the ECDSA private key linked to the victim’s application account.
6.  The adversary can sign in to the victim’s application account without the FIDO device and without the victim noticing. In other words, the adversary created a clone of the FIDO device for the victim’s application account. This clone will give access to the application account as long as the legitimate user does not revoke its authentication credentials.

The list, however, omits a key step, which is tearing down the YubiKey and exposing the logic board housed inside. This likely would be done by using a hot air gun and a scalpel to remove the plastic key casing and expose the part of the logic board that acts as a secure element storing the cryptographic secrets. From there, the attacker would connect the chip to hardware and software that take measurements as the key is being used to authenticate an existing account. Once the measurement-taking is finished, the attacker would seal the chip in a new casing and return it to the victim.

Left: a YubiKey 5Ci intact; Right: the logic board found inside.

Courtesy of NinjaLab

Two images showing how the electromagnetic radiation is measured using a probe.

Courtesy of NinjaLab

The attack and underlying vulnerability that makes it possible are almost entirely the same as that allowed NinjaLab to clone Google Titan keys in 2021. That attack required physical access to the token for about 10 hours.

The attacks violate a fundamental guarantee of FIDO-compliant keys, which is that the secret cryptographic material they store can’t be read or copied by any other device. This assurance is crucial because FIDO keys are used in various security-critical environments, such as those in the military and corporate networks.

That said, FIDO-compliant authentication is among the most robust forms of authentication, one that’s not susceptible to credential phishing or adversary-in-the-middle attacks. As long as the key stays out of the hands of a highly skilled and well-equipped attacker, it remains among the strongest forms of authentication. It’s also worth noting that cloning the token is only one of two major steps required to gain unauthorized access to an account or device. An attacker also must obtain the user password used for the first factor of authentication. These requirements mean that physical keys remain among the most secure authentication methods.

To uncover the side channel, the researchers reverse engineered the Infineon cryptographic library, a heavily fortified collection of code that the manufacturer takes great pains to keep confidential. The detailed description of the library is likely to be of intense interest to cryptography researchers analyzing how it works in other security devices.

People who want to know what firmware version their YubiKey runs can use the Yubico Authenticator app. The upper-left corner of the home screen displays the series and model of the key. In the example below, from Tuesday’s advisory, the YubiKey is a YubiKey 5C NFC version 5.7.0.

YubiKeys provide optional user authentication protections, including the requirement for a user-supplied PIN code or a fingerprint or face scan. For the cloning attack to work against YubiKeys using these additional measures, an attacker would need to possess the user verification factor as well. More information about using these additional measures to lock down YubiKeys further is available here.

A key question that remains unanswered at the moment is what other security devices rely on the three vulnerable Infineon secure modules and use the Infineon cryptolibrary? Infineon has yet to issue an advisory and didn't respond to an email asking for one. At the moment, there is no known CVE for tracking the vulnerability.

_This story originally appeared on_ _Ars Technica._

YubiKeys Are a Security Gold Standard—but They Can Be Cloned

In my opinion, mandatory enrollment is best enrollment.

Thursday, September 5, 2024 14:00

As most quality thoughts go, my most recent musing on security came about because of fantasy football. 

I had to log into my Yahoo Sports account, which I admittedly only ever have to log in to, at most, three times a year for the one fantasy football draft I have on that platform each year and then the handful of other times my phone logs me out during the five months that I’m adjusting my lineups on a weekly basis.  

Admittedly, I’d never thought much about the security of my Yahoo Sports account because I don’t have any sensitive information tied to it, and if someone did want to break in, they could probably do a better job of managing my team in that league than I have the past few years. It’s the old “out of sight, out of mind” compared to something like my work email account where I’m logging in every morning, or online banking which I’m using several times a week, and the knowledge that my financial wellbeing is tied to those account credentials. 

But I have to give credit to Yahoo for how they handled my account being less secure. When I logged in, probably for the first time since January, this weekend, before it would even display my homepage or enter the fantasy draft, it took me to an account management page where it warned me that I was using a “less secure” password and still hadn’t enrolled in multi-factor authentication. It took me less than a minute to update my password to something more secure, and maybe another two minutes to enroll in passcode MFA. 

The account management page also had some helpful information, such as how long it had been since my last password change, offering the ability to manage my password through a third-party app, and multiple options to set up MFA, including using the Yahoo Sports app directly (this is always more appealing to me than having to download yet another MFA app on my phone). 

This also got me thinking about the ways in which I don’t like being asked or reminded to enroll in MFA. It never made any sense to me that sites would give users the option to click away from the screen when being asked to enroll in MFA — make it mandatory or don’t. Also, one of my biggest pet peeves in using the internet is when you confirm this is a personal device or “Remember Me” for the next time I log in and the site doesn’t, in fact, remember me, and I have to go through the same approval process multiple times in the same day. 

Our friends at Cisco Duo also have a few other great recommendations for getting people to enroll in MFA, but in my opinion, mandatory enrollment is best enrollment. If I had never displayed that screen on Yahoo’s login page, I wouldn’t have even thought twice about how secure my account was. And seeing a red “!” next to my password gave off an immediate sign that my password needed to be improved, which is something I wish other sites would start doing.  

It’s not like having my fantasy football login credentials compromised would be the end of the world, but when it comes to something more high stakes, there are a few small UI steps sites could take to help nudge us in the right direction. 

**The one big thing **

Threat actors are increasingly using a traditional Red Teaming tool called MacroPack to create new malware payloads. These malicious files deliver multiple payloads, including the Havoc and Brute Ratel post-exploitation frameworks and a new variant of the PhantomCore remote access trojan (RAT). Several different actors are using this tactic based on files uploaded to VirusTotal that Talos analyzed. They are written in different languages and rely on different themes centered on different geographies, which leads us to believe these are disparate campaigns.  

**Why do I care? **

The threat of VBA macros has diminished since Microsoft prevented the execution of macros in Microsoft Office documents downloaded from the internet, but not all users are using the latest up-to-date Office versions and can still be vulnerable. MacroPack can generate several types of payloads packaged into different file types, including popular Office-supported formats, scripting files and shortcuts. The code generated by the framework has the following characteristics, making it more difficult to detect using file content signatures. 

**So now what? **

Talos released a new Snort rule set and several ClamAV signatures to detect and block the malicious files Talos analyzed as part of this research. Our blog post also has an in-depth breakdown of the four major themes used across these malicious documents, information that could be crucial to informing potential targets about these threats.  

**Top security headlines of the week **

**A new report from Google’s Threat Analysis Group found that Russia’s APT29 is exploiting some of the same vulnerabilities as two popular spyware vendors.** The analysis comes from watering hole attacks that researchers saw in the wild between November 2023 and July 2024 targeting Mongolian government websites. APT29, largely thought to be connected to Russia’s government, exploited the same vulnerabilities in Apple iOS WebKit and Google Chrome that two spyware vendors, Intellexa and NSO Group, are also known to use. The actor (also known as Cozy Bear and Midnight Blizzard) compromised the government-controlled websites to embed malicious payloads in hidden iframes on web pages. These iframes pointed users to attacker-controlled websites, where the exploits were deployed to steal user data from iOS and Android devices. Intellexa, which Cisco Talos has reported on several times, was recently blacklisted by the U.S. government for its role in creating and distributing the Predator spyware. And the Israeli NSO Group is infamous for its Pegasus spyware, commonly used to target at-risk individuals like journalists, politicians and activists. (Google TAG, The Record) 

**A North Korean state-sponsored actor known as Citrine Sleet is actively exploiting a zero-day vulnerability in the Google Chrome web browser to steal users’ cryptocurrency.** Microsoft wrote in an advisory regarding the vulnerability, identified as CVE-2024-7971, that users had been "targeted and compromised" by the zero-day attack. Google has since released a patch for the issue. CVE-2024-7971 is a type confusion vulnerability in the V8 JavaScript and WebAssembly engine that could allow an attacker to execute remote code on the targeted machine. Citrine Sleet is believed to be based in North Korea and primarily targets financial institutions, especially those that manage cryptocurrency accounts. Its social engineering techniques focus on the cryptocurrency industry and individuals believed to be associated with it. Exploitation of the vulnerability started by tricking a victim into visiting an attacker-controlled website. Then, because of a different vulnerability in the Windows kernel, Citrine Sleet could install a rootkit on the target’s computer, essentially giving them complete control of the machine. Cryptocurrency has long been a target for North Korean state-sponsored actors, who often use the stolen currency to fund the country’s military operations. (TechCrunch, Decipher) 

**The FBI released a new warning this week that North Korean actors could soon launch a wave of cyber attacks targeting "organizations with access to large quantities of cryptocurrency-related assets or products.”** A public service announcement released Tuesday said that actors had been carrying out reconnaissance-related social engineering campaigns for months targeting individuals believed to be involved in the cryptocurrency industry, or employees of financial institutions who handle virtual currency. Most of the potential targets are found by the actors by monitoring their social media activity, particularly on professional networking or employment-related platforms. These actors also are impersonating legitimate employees, looking to gain remote employment at these companies using fake names, identities and profiles. “Given the scale and persistence of this malicious activity, even those well versed in cybersecurity practices can be vulnerable to North Korea's determination to compromise networks connected to cryptocurrency assets,” the PSA reads. (Dark Reading, FBI) 

**Can’t get enough Talos? **

*   Vulnerabilities in Microsoft apps for macOS allow stealing permissions 
*   BlackByte ransomware group targets VMware ESXi bug 
*   Cisco: BlackByte ransomware gang only posting 20% to 30% of successful attacks 
*   Bug Leaves Microsoft Apps for MacOS Open to Silent Takeovers 

**Upcoming events where you can find Talos **

**LABScon** **(Sept. 18 - 21)**  

_Scottsdale, Arizona_ 

**VB2024** **(Oct. 2 - 4)** 

_Dublin, Ireland_ 

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 0e2263d4f239a5c39960ffa6b6b688faa7fc3075e130fe0d4599d5b95ef20647   
**MD5:** bbcf7a68f4164a9f5f5cb2d9f30d9790   
**Typical Filename:** bbcf7a68f4164a9f5f5cb2d9f30d9790.vir   
**Claimed Product:** N/A   
**Detection Name:** Win.Dropper.Scar::1201 

**SHA 256:** 5e537dee6d7478cba56ebbcc7a695cae2609010a897d766ff578a4260c2ac9cf   
**MD5:** 2cfc15cb15acc1ff2b2da65c790d7551   
**Typical Filename:** rcx4d83.tmp   
**Claimed Product:** N/A     
**Detection Name:** Win.Dropper.Pykspa::tpd 

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91    
**MD5:** 7bdbd180c081fa63ca94f9c22c457376   
**Typical Filename:** c0dwjdi6a.dll   
**Claimed Product:** N/A    
**Detection Name:** Trojan.GenericKD.33515991 

**SHA 256**: c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0    
**MD5:** 8c69830a50fb85d8a794fa46643493b2    
**Typical Filename:** AAct.exe    
**Claimed Product:** N/A     
**Detection Name:** PUA.Win.Dropper.Generic::1201 

**SHA 256:** 161937ed1502c491748d055287898dd37af96405aeff48c2500b834f6739e72d   
**MD5:** fd743b55d530e0468805de0e83758fe9   
**Typical Filename:** KMSAuto Net.exe   
**Claimed Product:** KMSAuto Net   
**Detection Name:** W32.File.MalParent

The best and worst ways to get users to improve their account security

With 20,000 internet providers across the country, the technical challenges of blocking X in Brazil mean some connections are slipping through the cracks.

The social network X has been largely inaccessible in Brazil since Saturday, after the country's Supreme Court ordered all mobile and internet service providers to block the platform. The court order followed a months-long dispute between Judge Alexandre de Moraes and X CEO Elon Musk over the company's misinformation, hate speech, and moderation policies.

With Brazil's population of 215 million people, its mature democracy, its sprawling land mass, and more than 20,000 internet service providers, blocking a web platform in the South American nation isn't straightforward. And while the biggest ISPs have implemented the ban, many are still scrambling to comply with the order, leaving a patchwork of access to the site.

“Brazil has made headway blocking X on the main internet providers, but our telemetry indicates there’s a long tail of local and regional ISPs where the service is still available,” says Isik Mater, director of research at the internet censorship analysis group NetBlocks.

The Open Observatory of Network Interference reported that a similar progression played out when Brazil’s Federal Police obtained a court order in April 2023 for ISPs to block the communication platform Telegram because it would not fully share information about users involved in neo-Nazi group chats. Some large ISPs began blocking Telegram immediately. “However, the block was not implemented by all ISPs in Brazil, nor was it implemented in the same way,” the group wrote. “This suggests lack of coordination between providers, and that each ISP implemented the block autonomously.”

A similar progression has been playing out with the X ban. Brazil's 20,000 ISPs produce a notably competitive market, but only a few have infrastructure nationwide. About 40 percent are tiny regional providers with 5,000 customers or fewer. The human and digital rights watchdog Freedom House rates Brazil's internet freedom as “partly free” and trending to be more restrictive, because of the country's far-reaching efforts to crack down on political misinformation in recent years and its three-day ban on Telegram. Brazil also blocked the secure communication platform WhatsApp in December 2015 and again in May 2016 because it did not respond to similar data requests.

Brazil's National Telecommunications Agency did not respond to WIRED's multiple requests for comment.

Unlike in countries including Russia, Iran, and China, there is currently no legal apparatus or technical infrastructure by which the Brazilian government can systematically and comprehensively restrict access to particular websites or online platforms, or impose connectivity blackouts on its citizens.

Reports indicate many Brazilian ISPs that have implemented the ban are using the technique known as “DNS filtering” to block access to X. The domain name system is the internet's phonebook for looking up the IP addresses associated with URLs such as www.wired.com. DNS queries are sent to a DNS “resolver” that does the IP address lookups, and ISPs can configure their resolvers to filter or block requests for particular websites.

Mobile apps like X's Android and iOS apps don't rely on DNS, though, so DNS filtering alone is not enough to block all connections to a web platform. Some Brazilian ISPs seem to also be using IP address “sinkholing”—redirecting online traffic to a different server than the users intended to visit—as a way to send traffic meant for X into the abyss.

“We’re seeing variation by provider in Brazil, and right now it looks they’re each trying their own thing to see what works,” NetBlocks’ Mater says. “Brazil has a diverse network infrastructure with lots of ways for data to enter and leave the country, so there isn’t that centralized choke point and ‘kill switch’ we see in \[some\] authoritarian-leaning countries.”

VPN usage has surged in Brazil this week under the ban as a way around ISP attempts to block X, but the court order ban includes a provision stating people could be charged a fine of 50,000 reais—around $8,900—per day for using circumvention tools like VPNs.

Why It's So Hard to Fully Block X in Brazil

Using special software, WIRED investigated police surveillance at the DNC. We collected signals from nearly 300,000 devices, revealing vulnerabilities for both law enforcement and everyday citizens alike.

As thousands took to the streets during August’s Democratic National Convention in Chicago to protest Israel’s deadly assault on Gaza, a massive security operation was already underway. US Capitol Police, Secret Service, the Department of Homeland Security’s Homeland Security Investigations, sheriff’s deputies from nearby counties, and local officers from across the country had descended on Chicago and were all out in force, working to manage the crowds and ensure the event went off without any major disruptions.

Amid the headlines and the largely peaceful protests, WIRED was looking for something less visible. We were investigating reports of cell site simulators (CSS), also known as IMSI catchers or Stingrays, the name of one of the technology’s earliest devices, developed by Harris Corporation. These controversial surveillance tools mimic cell towers to trick phones into connecting with them. Activists have long worried that the devices, which can capture sensitive data such as location, call metadata, and app traffic, might be used against political activists and protesters.

Armed with a waist pack stuffed with two rooted Android phones and three Wi-Fi hot spots running CSS-detection software developed by the Electronic Frontier Foundation, a digital-rights nonprofit, we conducted a first-of-its-kind wireless survey of the signals around the DNC.

WIRED attended protests across the city, events at the United Center (where the DNC took place), and social gatherings with lobbyists, political figures, and influencers. We spent time walking the perimeter along march routes and through planned protest sites before, during, and after these events.

In the process we captured Bluetooth, Wi-Fi, and cellular signals. We then analyzed those signals looking for specific hardware identifiers and other suspicious signs that could indicate the presence of a cell-site simulator. Ultimately, we did not find any evidence that cell-site simulators were deployed at the DNC. Nevertheless, when taken together, the hundreds of thousands of data points we accumulated in Chicago reveal how the invisible signals from our devices can create vulnerabilities for activists, police, and everyone in between. Our investigation revealed signals from as many as 297,337 devices, including as many as 2,568 associated with a major police body camera manufacturer, five associated with a law enforcement drone maker, and a massive array of consumer electronics like cameras, hearing aids, internet-of-things devices, and headphones.

WIRED often observed the same devices appearing in different locations, revealing their operators’ patterns of movement. For example, a Chevrolet Wi-Fi hotspot, initially located in the law-enforcement-only parking lot of the United Center, was later found parked on a side street next to a downtown Chicago demonstration. A Wi-Fi signal from a Skydio police drone that hovered above a massive anti-war protest was detected again the next day above the Israeli consulate. And Axon police body cameras with identical hardware identifiers were detected at various protests occurring days apart.

“Surveillance technologies leave traces that can be discovered in real time,” says Cooper Quintin, a senior staff technologist at the EFF. Regardless of the specific technologies WIRED detected, Quintin notes that the ability to identify police technology in real time is significant. “Many of our devices are beaconing in ways that make it possible to track us through wireless signals,” he says. While this makes it possible to track police, Quintin says, “this makes protesters similarly vulnerable to the same types of attacks.”

The signals we collected are a byproduct of our extremely networked world and demonstrate a pervasive and unsettling reality: Military, law enforcement, and consumer devices constantly emit signals that can be intercepted and tracked by anyone with the right tools. In the context of high-stakes scenarios such as election events, gatherings of high-profile politicians and other officials, and large-scale protests, the findings have implications for law enforcement and protesters alike.

WIRED initially focused on finding cell-site simulators due to the secrecy around their use, especially at protests. Cell-site simulators work by tricking nearby phones, cars, and other devices that use cellular infrastructure into connecting to them. They can be used on planes or retrofitted onto trucks.

The dragnet surveillance tool has largely been used by law enforcement to track a specific target’s location, but due to the indiscriminate way it functions, the devices will log the IMSI (international mobile subscriber identity) numbers, unique to each SIM card, of every single device that connects to it.

For years, protesters have suspected that the surveillance technology has been deployed against them during demonstrations. In 2014, following a wave of protests in Chicago over a grand jury's decision not to indict Ferguson, Missouri, police officer Darren Wilson for fatally shooting Michael Brown, a Black teenager, activists overheard a police officer on a scanner asking another officer if he was gathering information from the protest organizer’s phone. Protesters at the time believed this to be a sign that an IMSI-catcher was deployed.

In Illinois, local law enforcement is required to obtain a warrant to use cell-site simulators. However, according to the ACLU of Illinois, the public is not able to verify whether the Chicago Police Department complies with this law, as CPD lawyers have instructed technicians managing cell-site simulators not to keep a log of their use.

Similarly, federal agents, including those from Homeland Security at the DNC, are also required to secure warrants before deploying one of the devices, except in the in cases of immediate threats to national security. A 2023 DHS Inspector General report found, however, that both the Secret Service and Homeland Security Investigations did not always do so.

Given that some lawmakers have attempted to link American anti-war demonstrators to groups like Hamas, which is classified as a terrorist organization by the US government, demonstrators have been concerned that cell-site simulators will get deployed against them. “They think we are terrorists, so they treat us like terrorists,” an anti-war protester who declined to give their name told WIRED at a protest on the first day of the DNC. They say that they wouldn’t be surprised if any of the law enforcement agencies present at the DNC were using an IMSI-Catcher. “I feel my phone getting hot, and I know they are watching.”

For years, the EFF has been developing tools to detect cell-site simulators. In 2019, it released Crocodile Hunter, which uses software-defined radios to identify unusual activity from 4G towers in a specific area. More recently, Quintin, and Will Greenberg, another staff technologist at the EFF, started working on a cheaper and more user-friendly tool called Ray Hunter, designed to detect unusual cellular activity in a similar way.

WIRED worked with Quintin and Greenberg to install Ray Hunter on three wireless hots pots, which allowed reporters to walk around the DNC and related events in Chicago to attempt to detect whether the devices connected to cell-site simulators.

The Rayhunter software works by detecting three key indicators based on a review of academic literature about how cell-site simulators work. First, it checks if the network you're connected to tries to force a downgrade to 2G, which has less security than a 4G or 5G connection. Second, it detects if the network asks your device for an IMSI number. Finally, the software checks if the network requests a "null cipher," a technical term for asking your phone not to use encryption between the phone and the tower.

According to CSS documentation obtained through public records requests, some CSS allow users to connect via Bluetooth or Wi-Fi. So alongside Ray Hunter, WIRED used two rooted Android phones running an app called Wigle, which logs the GPS coordinates of Bluetooth, mobile, and Wi-Fi signals that the phone encounters. This setup enabled us to collect and store data on observed Wi-Fi and Bluetooth activity. Neither phone connected to any Wi-Fi or cellular network, nor did they upload any data to the cloud. We analyzed the data locally.

WIRED focused on identifying MAC addresses, which are unique identifiers assigned to network devices, and OUIs (organizationally unique identifiers), which are usually the first three bytes of a MAC address. We looked for any OUIs of known CSS manufacturers like Harris, KeyW, Jacobs, and Digital Receiver Technology.

One of our first stops in Chicago was at Union Park, where a coalition of political and community organizations had planned a march to call for an end of US aid to Israel.

On Monday afternoon, a smaller-than-expected but still massive crowd of thousands of protesters prepared to march toward the DNC to protest Israel’s deadly siege of Gaza. Hundreds of Chicago police on bicycles lined the approved route, ready to respond. Farther down the planned route, Secret Service agents and other DHS officers observed the demonstration. The march started off peacefully, but by 4:30 pm local time, tensions escalated.

A small group of protesters breached the first of two security fences around the United Center. As some tore down sections of the fence, others climbed over and faced off with law enforcement standing behind the second barrier. Police began photographing the protesters tearing down the barricades, and a CPD helicopter circled as low as 650 feet, according to publicly available flight data WIRED reviewed at the time. CBS later reported 13 arrests from the first day of the convention.

While Rayhunter didn’t pick up any suspicious cellular infrastructure, our other equipment detected three new cell towers that hadn’t been there the day before. According to Quintin, because Rayhunter did not detect any suspicious behaviors, these towers were likely “cell on wheels,” aka COWs, temporary cell towers that companies roll out to provide extra cellular coverage during large events.

Leaving the protest, our Android detected a Wi-Fi network named Skydio X10-c9z2 with a hardware identifier associated with Skydio, a California-based company that sells drones to law enforcement. Skydio equipment has been used as part of Drone as First Responder programs around the country for years. According to marketing material, the Skydio X10 is equipped with multiple high-resolution cameras, including thermal imaging, powerful zoom capabilities, and onboard AI. It’s unclear which agency the drone belongs to.

CPD did not respond to WIRED’s questions about the Skydio drone.

It wasn’t just American law enforcement we suspected may deploy cell-site simulators. In 2019, the FBI alleged that Israel had placed one near the White House—a claim Israel has denied. Similarly, in 2016, protesters opposing the Dakota Access Pipeline suspected that a private security firm, TigerSwan, had used one against them.

On Tuesday of the DNC, an unpermitted protest organized by a self-described militant anti-imperialist group called Behind Enemy Lines was scheduled to take place outside the Israeli Consulate at the Accenture Tower, located two miles east of the United Center. Hours before the planned demonstration, police had already saturated the area. CPD officers on bicycles lined both sides of Madison Street in front of the building’s entrance, while the surrounding plaza served as a staging area for additional officers, who mingled with Secret Service and other DHS personnel.

Data collected by our fanny pack detected a Skydio drone near the Israeli consulate matching the hardware identifiers we identified the previous day. WIRED detected no cell-site simulators near the Israeli consulate.

By 7 pm, approximately 200 protesters had gathered outside the consulate. After a few speeches, tensions escalated as some protesters attempted to continue marching, leading to confrontations with the officers. Outnumbered by both police and journalists, more than 50 people were arrested, including three reporters.

WIRED could not determine the exact number of officers deployed at the protest, and CPD has yet to respond to our request for comment. However, our analysis of Bluetooth signals collected from the Android devices detected hardware identifiers associated with Axon, formerly Taser International, from as many as 720 different devices. Axon develops technology for law enforcement, including Tasers, body cameras, evidence management systems, and other software. The signals we observed were most likely from body-worn cameras used by officers during the demonstration.

The trackability of Axon’s body cameras is a known vulnerability. Last year at the Defcon hacker conference, Alan “Nullagent” Meekins and Roger “RekcahDam” Hicks, cofounders of the Bluetooth tracking platform RFParty, demonstrated that their platform could decipher signals emitted by body cameras, allowing them to detect the presence and approximate position of police officers.

In an email, Axon spokesperson Victoria Keough said that some Axon products have wireless features that enable real-time monitoring of officers during patrols and critical incidents. “While BLE \[ Bluetooth Low Energy \] and other wireless communications can be susceptible to monitoring from other nearby devices, the benefits of BLE in ensuring incidents are captured with maximum visibility are crucial to public safety,” she wrote. Keough added that the current generation body-worn cameras offer the ability to be in “airplane mode” for specific tactical situations.

WIRED’s wireless survey appears to confirm Meekins and Hicks’ findings. Over the course of six days at the DNC, we detected signals from as many as 2,568 different Axon devices. Mapping these signals reveals information about where we encountered police and how they were deployed. For instance, the day after the incident at the Israeli consulate, we returned to the park where protesters had broken through barricades on Monday. Ahead of another planned protest, we found officers blocking entry to the park, designated a “free speech zone” by the city. On a map, a chain of closely clustered circles shows how tightly officers on bikes had formed a perimeter around the side of the park facing the expected protest route.

CPD did not respond to WIRED’s request for comment.

WIRED is not publishing the data collected for this story, partially because of how law enforcement could be able to use that data to identify devices at protests. “This is a known issue within the cybersecurity community,” Quintin of the EFF says. “I think police are starting to get wise to the fact that this is a technique they can use to find people. I wouldn’t be surprised if Bluetooth and wireless tracking is the next big wave of police technology.”

A company called Latent Wireless may be a pioneer in Wi-Fi signal tracking for law enforcement. Founded in 2019 by David Schwindt, a former police officer, Jeff Bromberger, and Peter Scott, both computer scientists, the company developed a Wi-Fi dongle that connects to patrol car computers. This device passively scans and analyzes metadata from Wi-Fi signals encountered by the car and matches detected MAC addresses against a list of stolen electronics or devices linked to criminals or missing persons. If a match is found, the system alerts officers, who can then use a directional antenna to locate the signal’s source.

In one instance that Schwindt and Bromberger shared with WIRED, local police used software from Latent Wireless to locate a suspect in an office building knowing only the MAC address of the employee’s device. In another case, a robber connected to a Wi-Fi network at a local coffee shop before committing a crime. Police identified the MAC address of his device through the coffee shop’s router logs and eventually tracked him down by detecting the signal from that device as they drove around.

Schwindt and Bromberger emphasize that privacy is a priority for the Latent Wireless. They avoid bulk data collection, do not attempt to decrypt traffic, and do not store the locations of observed MAC addresses unless they’re on the hot list.

On Wednesday evening, hundreds of protesters gathered for another march toward the United Center. Thirty minutes after the speakers began addressing the crowd, the thumping of a CPD helicopter's rotors overhead interrupted them. The aircraft, a Bell 206L-4 LongRanger IV or a similar model, circled low—at 500 feet, according to flight data. Its tail number, N911YY, was clearly visible. Something appeared to protrude from a window.

Among the demonstrators, a man in a DHS vest weaved through the crowd, eyes scanning as he spoke into his phone. Curious about what the helicopter might be up to, I asked a freelance photographer, Wali Khan, to try to capture an image with his telephoto lens of whatever was sticking out of the door. Unfortunately, the helicopter was too far away to get a clear picture.

The helicopter circled for about half an hour. Despite my repeated attempts, the Chicago Police Department has yet to respond to my request for records regarding the helicopter’s mission that evening. What is clear, however, is the impact it had on those below. The hovering presence interrupted speeches, causing more than one protester I spoke with to wonder whether they were being singled out. Some people thought the officer was sticking a rifle out the window, while others assumed it was a camera.

None of WIRED’s devices picked up the hidden connections of cell-site simulators that day, or throughout the entire trip, but there were times like this when the surveillance was impossible to miss. “If what comes out of this is that activists spend less time worrying about protecting themselves from IMSI catchers and more time protecting themselves from drones, cameras, and things we know are being used,” Quintin says, “that’s a good outcome.”

_Additional reporting by Makena Kelly_

We Hunted Hidden Police Signals at the DNC

" Hello pervert"  sextortion mails keep adding new features to their email to increase credibility and urge victims to pay

After using passwords obtained from one of the countless breaches as a lure to trick victims into paying, the “Hello pervert” sextortion scammers have recently introduced two new pressure tactics: Name-dropping the infamous Pegasus spyware and adding pictures of your home environment.

They do this to add credibility to the false claims that the scammers have been watching your online behavior and caught you red-handed during activities that you would like to keep private amongst your friends and family.

The email usually starts with “Hello pervert” and then goes on to claim that the target has been watching pornographic content. The scammers often claim to have footage of what you were watching and what you were doing while watching.

To stop the sender from spreading the incriminating footage, the target will have to pay the scammer, or else they will send it to everyone in their email contacts list.

More recently, scammers have started increasing their threats by mentioning a powerful spyware called “Pegasus.” Several versions of these scam emails have included the following text:

> Have you heard of Pegasus? This is a spyware program that installs on computers and smartphones and allows hackers to monitor the activity of device owners. It provides access to your webcam, messengers, emails, call records, etc. It works well on Android, iOS, and Windows.

Though Pegasus is indeed a powerfully invasive spyware tool, the threat of its use, as included in these scam emails, is entirely empty. This is because Pegasus has never been observed outside of a surveillance campaign carried out, specifically, by governments. Time and time again, Pegasus has been used by oppressive government regimes to spy on political dissidents, human rights activists, and watchdog journalists. There is essentially no proof that such a closely-guarded spyware has ended up in the hands of everyday scammers.

But the pressure tactics don’t end with Pegasus, as many of these emails include an old (or active) password that a scam target has used in the past. Here, this isn’t some act of advanced hacking. Instead, it is likely that the scammers bought your password from other cybercriminals that obtained them during one of the countless data breaches that hit company after company every week.

When scammers have access to such data, it may also include your physical address. With that knowledge, scammers have increased their threats by simply adding a photograph of your personal neighborhood by looking it up online. For most places in inhabited areas, you can grab such pictures from Google Maps or similar apps.

A Reddit user demonstrated this by finding that such a scammer used an old PO box address. But it’s true that this adds a convincing argument to the claim that the sender has been spying on you.  

As an extra threat the email may include something like:

> “Or is visiting \[your physical address\] a more convenient way to contact if you don’t take action. Nice location btw.”

Implying that they know where you live and threatening to stop by and create a scene.

**How to recognize “Hello pervert” emails**

Once you know what’s going on it’s easy to recognize these emails. Remember that not all of the below characteristics have to be included in these emails, but all of them are red flags in their own right.

*   They often look as if they came from one of your own email addresses.
*   The scammer accuses you of inappropriate behavior and claims to have footage of that behavior.
*   In the email the scammer claims to have used Pegasus or some Trojan to spy on you through your own computer.
*   The scammer says they know “your password.”
*   You are urged to pay up quickly or the so-called footage will be spread to all your contacts. Often you’re only allowed one day to pay.
*   The actual message often arrives as an image or a pdf attachment. Scammers do this to bypass phishing filters.

**How to react to “Hello pervert” emails**

First and foremost, never reply to emails of this kind. It may tell the sender that someone is reading the emails sent to that address and they will repeatedly try new and other methods to defraud you.

*   If the email included a password, make sure you are not using it any more and if you are, change it as soon as possible.
*   If you are having trouble organizing your password, have a look at a password manager.
*   Don’t let yourself get rushed into action or decisions. Scammers rely on the fact that you will not take the time to think this through and subsequently make mistakes.
*   Do not open unsolicited attachments. Especially when the sender address is suspicious or even your own.
*   For your ease of mind, turn of your webcam or buy a webcam cover so you can cover it when you’re not using the webcam.

If you want to find out what personal data of yours has been exposed online, you can use our free Digital Footprint scan. Fill in the email address you’re curious about (it’s best to submit the one you most frequently use) and we’ll send you a free report.

**We don’t just report on threats – we help safeguard your entire digital identit**y

Cybersecurity risks should never spread beyond a headline. Protect your—and your family’s—personal information by using identity protection.

 “Hello pervert” sextortion scam includes new threat of Pegasus—and a picture of your home 

### Summary

`gix-path` executes `git` to find the path of a configuration file that belongs to the `git` installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote.

### Details

In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest [scope](https://git-scm.com/docs/git-config#SCOPES):

https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L91

https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L112

While the configuration variable of highest scope is not usually in the local scope, there are practical situations where this occurs:

- A configuration file truly associated with the installation is not present on all systems and can occasionally be empty. Likewise, there may be no variables in the global scope.
- Configuration files associated with those higher scopes may be deliberately skipped by setting the `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` environment variables to `/dev/null` (or to `NUL` on Windows). This prevents `gix-path` from finding the path of configuration files for those scopes, while not preventing downstream components such as the function in `gix-config` from reporting a local path as being associated with the installation.
- The `GIT_CONFIG_NOSYSTEM` environment variable can be used to disable configuration associated with the installation. (`GIT_CONFIG_NOSYSTEM=1` is more powerful than `GIT_CONFIG_SYSTEM=/dev/null` on systems where an additional "unknown" scope is associated with the installation, as occurs on macOS with Apple Git.) This will cause the local scope to be the highest nonempty scope under even more situations, though in practice it is less dangerous because most, though possibly not all, downstream components would disregard the value.

A user may use either or both of the latter two techniques to turn off an undesired configuration or to create a more replicable environment. Such a user would expect that this results in a more controlled configuration.

Often, when located inside one repository, a user performs operations on that repository or that are not specific to any repository. In such use, local configuration is typically desired or at least acceptable, and mistaking it as coming from another scope is not typically harmful.

However, sometimes a user is in one repository and operates on another repository. A major case where this occurs is cloning one repository while located in another. This can be done in an ad-hoc fashion, including when cloning the repository outside of the one we are inside. It may also potentially be automated by an application for purposes such as submodule handling. Two kinds of problems are anticipated:

- A less secure configuration may be set for a specific repository where it is judged acceptable, even though it would not be wanted for other repositories, such as to enable a protocol or set up debugging.
- More likely, a configuration that supplies secrets for use in one repository's remote can be used to send those secrets to another repository's remote.

### PoC

In this example, we send mock `Authorization: Basic ...` credentials meant for one repository's remote to another remote, by running `gix` while inside the first repository to clone the second repository.

These instructions are written for a Unix shell, but they will work in other shells, including in PowerShell on Windows if the method of setting environment variables is adapted and `/dev/null` is replaced with `NUL`. This procedure is likely to demonstrate the problem on all systems *except* macOS. This is due to the high-scoped "unknown" configuration that usually accompanies Apple Git, and reflects that gix-path is in practice much less vulnerable on macOS (though still potentially vulnerable).

1. Install [`dummyhttp`](https://crates.io/crates/dummyhttp) to serve as a local HTTP server for the demonstration.

2. Obtain a build of `gitoxide` with the `max` feature set enabled. While this vulnerability affects other builds, this example requires `max` for `http.extraHeader` support.

   Running `cargo install gitoxide` will install such a build though it may build against a patched version of `gix-path`. Cloning the repository (12251eb052df30105538fa831e641eea557f13d8 and earlier are affected) and building with `cargo build` or `cargo install --path .` are also sufficient. In contrast, installing from published binaries with `binstall` or `quickinstall` does not provide the `max` feature, as of this writing.

3. Run: `dummyhttp -i 127.0.0.1 -c 403 -v`

4. In a separate terminal, create a new local repository and set up a mock remote and `http.extraHeader` configuration:

   ```sh
   git init myrepo
   cd myrepo
   git remote add origin http://127.0.0.1:8080/mygit.git
   git config --local http.extraHeader 'Authorization: Basic abcde'
   ```

5. Make sure the testing setup is working by running `gix fetch` in the repository and checking that it fails in the expected way. In the terminal where that is run, a message should be shown indicating an HTTP 403 error. The more interesting output is in the terminal where `dummyhttp` is running, which should look like this:

   ```text
   2024-30-30 03:30:16 127.0.0.1:55689 GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
   ┌─Incoming request
   │ GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
   │ Accept: */*
   │ Authorization: Basic abcde
   │ Git-Protocol: version=2
   │ Host: 127.0.0.1:8080
   │ User-Agent: git/oxide-0.42.2
   ┌─Outgoing response
   │ HTTP/1.1 403 Forbidden
   │ Content-Length: 9
   │ Content-Type: text/plain; charset=utf-8
   │ Date: Fri, 30 Aug 2024 03:30:16 -0400
   ```

   Some details may differ, especially dates and times. But `Authorization: Basic abcde` should be shown.

6. Now, in the terminal where you ran `gix fetch`, try cloning a separate repository:

   ```sh
   gix clone http://127.0.0.1:8080/other.git
   ```

   Check the output appended in the terminal where `dummyhttp` is running. This is to observe that `Authorization: Basic abcde` was rightly *not* sent.

   Alternatively, if it *does* appear, then your system may be in one of the uncommon configurations that is vulnerable without further action.

7. Now rerun that command, but with a modified environment, to cause `gix-path` to wrongly treat configuration from the local scope as being associated with the `git` installation:

   ```sh
   env GIT_CONFIG_SYSTEM=/dev/null GIT_CONFIG_GLOBAL=/dev/null gix clone http://127.0.0.1:8080/other.git
   ```

   Check the output appended in the terminal where `dummyhttp` is running. Observe that `Authorization: Basic abcde` was wrongly sent.

While this procedure uses the same remote host for both repositories, this is not a required element. If the second repository had a different, untrusted host, the extra header would still be sent.

### Impact

It is believed to be very difficult to exploit this vulnerability deliberately, due to the need either to anticipate a situation in which higher-scoped configuration variables would be absent, or to arrange for this to happen. Although any operating system may be affected, users running Apple Git on macOS are much less likely to be affected.

In the example shown above, more secure general practices would avoid it: using a credential manager, or even using `http.<url>.extraHeader` with as specific a `<url>` as possible, rather than the more general `http.extraHeader`. Many scenarios are analogous: if each repository's configuration is as secure as possible for how the repository is used, and secrets are stored securely and separately, then the circumstances under which an unacceptably unsecure configuration is used, or under which a leak of credentials would occur, become unlikely.

**Summary**

gix-path executes git to find the path of a configuration file that belongs to the git installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote.

**Details**

In gix_path::env, the underlying implementation of the installation_config and installation_config_prefix functions calls git config -l --show-origin and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest scope:

https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L91

https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L112

While the configuration variable of highest scope is not usually in the local scope, there are practical situations where this occurs:

*   A configuration file truly associated with the installation is not present on all systems and can occasionally be empty. Likewise, there may be no variables in the global scope.
*   Configuration files associated with those higher scopes may be deliberately skipped by setting the GIT_CONFIG_SYSTEM and GIT_CONFIG_GLOBAL environment variables to /dev/null (or to NUL on Windows). This prevents gix-path from finding the path of configuration files for those scopes, while not preventing downstream components such as the function in gix-config from reporting a local path as being associated with the installation.
*   The GIT_CONFIG_NOSYSTEM environment variable can be used to disable configuration associated with the installation. (GIT_CONFIG_NOSYSTEM=1 is more powerful than GIT_CONFIG_SYSTEM=/dev/null on systems where an additional "unknown" scope is associated with the installation, as occurs on macOS with Apple Git.) This will cause the local scope to be the highest nonempty scope under even more situations, though in practice it is less dangerous because most, though possibly not all, downstream components would disregard the value.

A user may use either or both of the latter two techniques to turn off an undesired configuration or to create a more replicable environment. Such a user would expect that this results in a more controlled configuration.

Often, when located inside one repository, a user performs operations on that repository or that are not specific to any repository. In such use, local configuration is typically desired or at least acceptable, and mistaking it as coming from another scope is not typically harmful.

However, sometimes a user is in one repository and operates on another repository. A major case where this occurs is cloning one repository while located in another. This can be done in an ad-hoc fashion, including when cloning the repository outside of the one we are inside. It may also potentially be automated by an application for purposes such as submodule handling. Two kinds of problems are anticipated:

*   A less secure configuration may be set for a specific repository where it is judged acceptable, even though it would not be wanted for other repositories, such as to enable a protocol or set up debugging.
*   More likely, a configuration that supplies secrets for use in one repository's remote can be used to send those secrets to another repository's remote.

**PoC**

In this example, we send mock Authorization: Basic ... credentials meant for one repository's remote to another remote, by running gix while inside the first repository to clone the second repository.

These instructions are written for a Unix shell, but they will work in other shells, including in PowerShell on Windows if the method of setting environment variables is adapted and /dev/null is replaced with NUL. This procedure is likely to demonstrate the problem on all systems _except_ macOS. This is due to the high-scoped "unknown" configuration that usually accompanies Apple Git, and reflects that gix-path is in practice much less vulnerable on macOS (though still potentially vulnerable).

1.  Install dummyhttp to serve as a local HTTP server for the demonstration.
    
2.  Obtain a build of gitoxide with the max feature set enabled. While this vulnerability affects other builds, this example requires max for http.extraHeader support.
    
    Running cargo install gitoxide will install such a build though it may build against a patched version of gix-path. Cloning the repository (12251eb052df30105538fa831e641eea557f13d8 and earlier are affected) and building with cargo build or cargo install --path . are also sufficient. In contrast, installing from published binaries with binstall or quickinstall does not provide the max feature, as of this writing.
    
3.  Run: dummyhttp -i 127.0.0.1 -c 403 -v
    
4.  In a separate terminal, create a new local repository and set up a mock remote and http.extraHeader configuration:
    
    git init myrepo
    cd myrepo
    git remote add origin http://127.0.0.1:8080/mygit.git
    git config --local http.extraHeader 'Authorization: Basic abcde'
    
5.  Make sure the testing setup is working by running gix fetch in the repository and checking that it fails in the expected way. In the terminal where that is run, a message should be shown indicating an HTTP 403 error. The more interesting output is in the terminal where dummyhttp is running, which should look like this:
    
        2024-30-30 03:30:16 127.0.0.1:55689 GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
        ┌─Incoming request
        │ GET /myrepo.git/info/refs?service=git-upload-pack HTTP/1.1
        │ Accept: */*
        │ Authorization: Basic abcde
        │ Git-Protocol: version=2
        │ Host: 127.0.0.1:8080
        │ User-Agent: git/oxide-0.42.2
        ┌─Outgoing response
        │ HTTP/1.1 403 Forbidden
        │ Content-Length: 9
        │ Content-Type: text/plain; charset=utf-8
        │ Date: Fri, 30 Aug 2024 03:30:16 -0400
        
    
    Some details may differ, especially dates and times. But Authorization: Basic abcde should be shown.
    
6.  Now, in the terminal where you ran gix fetch, try cloning a separate repository:
    
    gix clone http://127.0.0.1:8080/other.git
    
    Check the output appended in the terminal where dummyhttp is running. This is to observe that Authorization: Basic abcde was rightly _not_ sent.
    
    Alternatively, if it _does_ appear, then your system may be in one of the uncommon configurations that is vulnerable without further action.
    
7.  Now rerun that command, but with a modified environment, to cause gix-path to wrongly treat configuration from the local scope as being associated with the git installation:
    
    env GIT\_CONFIG\_SYSTEM=/dev/null GIT\_CONFIG\_GLOBAL=/dev/null gix clone http://127.0.0.1:8080/other.git
    
    Check the output appended in the terminal where dummyhttp is running. Observe that Authorization: Basic abcde was wrongly sent.
    

While this procedure uses the same remote host for both repositories, this is not a required element. If the second repository had a different, untrusted host, the extra header would still be sent.

**Impact**

It is believed to be very difficult to exploit this vulnerability deliberately, due to the need either to anticipate a situation in which higher-scoped configuration variables would be absent, or to arrange for this to happen. Although any operating system may be affected, users running Apple Git on macOS are much less likely to be affected.

In the example shown above, more secure general practices would avoid it: using a credential manager, or even using http.<url>.extraHeader with as specific a <url> as possible, rather than the more general http.extraHeader. Many scenarios are analogous: if each repository's configuration is as secure as possible for how the repository is used, and secrets are stored securely and separately, then the circumstances under which an unacceptably unsecure configuration is used, or under which a leak of credentials would occur, become unlikely.

**References**

*   GHSA-v26r-4c9c-h3j6
*   https://nvd.nist.gov/vuln/detail/CVE-2024-45305
*   https://git-scm.com/docs/git-config#SCOPES
*   https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L112
*   https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L91
*   https://rustsec.org/advisories/RUSTSEC-2024-0367.html

GHSA-v26r-4c9c-h3j6: gix-path uses local config across repos when it is the highest scope

Taskhub version 2.8.8 suffers from an ignored default credential vulnerability.

**Taskhub 2.8.8 Insecure Settings**

Posted Sep 3, 2024

Authored by indoushka

Taskhub version 2.8.8 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | 2c385d7b29ff2d1f0cadb673bff0447f2a27c839cc502710002b3eab58740544

Download | Favorite | View

**Taskhub 2.8.8 Insecure Settings**

    =============================================================================================================================================| # Title     : Taskhub v2.8.8 Insecure Settings Vulnerability                                                                              || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://codecanyon.net/item/taskhub-project-management-finance-crm-tool/25685874                                            |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin@gmail.com & pass = 12345678[+] https://www/127.0.0.1/tasks.octalfoxcom/auth/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,625)
*   Arbitrary (17,028)
*   BBS (2,859)
*   Bypass (1,898)
*   CGI (1,047)
*   Code Execution (7,868)
*   Conference (692)
*   Cracker (844)
*   CSRF (3,420)
*   DoS (25,190)
*   Encryption (2,389)
*   Exploit (54,101)
*   File Inclusion (4,271)
*   File Upload (1,007)
*   Firewall (822)
*   Info Disclosure (2,911)
*   Intrusion Detection (916)
*   Java (3,155)
*   JavaScript (907)
*   Kernel (7,252)
*   Local (14,836)
*   Magazine (587)
*   Overflow (13,205)
*   Perl (1,435)
*   PHP (5,253)
*   Proof of Concept (2,399)
*   Protocol (3,745)
*   Python (1,652)
*   Remote (31,810)
*   Root (3,668)
*   Rootkit (529)
*   Ruby (640)
*   Scanner (1,657)
*   Security Tool (8,035)
*   Shell (3,295)
*   Shellcode (1,219)
*   Sniffer (904)
*   Spoof (2,291)
*   SQL Injection (16,693)
*   TCP (2,462)
*   Trojan (690)
*   UDP (919)
*   Virus (671)
*   Vulnerability (33,048)
*   Web (10,128)
*   Whitepaper (3,783)
*   x86 (969)
*   XSS (18,278)
*   Other

**File Archives**

*   September 2024
*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,104)
*   BSD (378)
*   CentOS (61)
*   Cisco (1,954)
*   Debian (7,114)
*   Fedora (1,693)
*   FreeBSD (1,247)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (387)
*   iPhone (108)
*   IRIX (220)
*   Juniper (71)
*   Linux (51,006)
*   Mac OS X (696)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,685)
*   Slackware (941)
*   Solaris (1,614)
*   SUSE (1,444)
*   Ubuntu (9,797)
*   UNIX (9,443)
*   UnixWare (187)
*   Windows (6,757)
*   Other

Taskhub 2.8.8 Insecure Settings

Red Hat Security Advisory 2024-6211-03 - Red Hat OpenShift Service Mesh Containers for 2.6.1. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_6211.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: Red Hat OpenShift Service Mesh Containers for 2.6.1 security updateAdvisory ID:        RHSA-2024:6211-03Product:            Red Hat OpenShift Service MeshAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:6211Issue date:         2024-09-03Revision:           03CVE Names:          CVE-2024-4067====================================================================Summary: Red Hat OpenShift Service Mesh Containers for 2.6.1Red Hat Product Security has rated this update as having a security impact ofImportant. A Common Vulnerability Scoring System (CVSS) base score, which gives adetailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.Description:Red Hat OpenShift Service Mesh is Red Hat's distribution of the Istio service mesh project, tailored for installation into an OpenShift Container Platform installation.Security Fix(es):* axios: Server-Side Request Forgery (CVE-2024-39338)* express: cause malformed URLs to be evaluated (CVE-2024-29041)* micromatch: vulnerable to Regular Expression Denial of Service (CVE-2024-4067)* braces: fails to limit the number of characters it can handle (CVE-2024-4068)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-4067References:https://access.redhat.com/security/updates/classification/#importanthttps://issues.redhat.com/browse/OSSM-6857https://issues.redhat.com/browse/OSSM-8006

Red Hat Security Advisory 2024-6211-03

Red Hat Security Advisory 2024-6210-03 - Red Hat OpenShift Service Mesh Containers for 2.5.4.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_6210.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Low: Red Hat OpenShift Service Mesh Containers for 2.5.4 security updateAdvisory ID:        RHSA-2024:6210-03Product:            Red Hat OpenShift Service MeshAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:6210Issue date:         2024-09-03Revision:           03CVE Names:          CVE-2024-39338====================================================================Summary: Red Hat OpenShift Service Mesh Containers for 2.5.4 Red Hat Product Security has rated this update as having a security impact ofLow. A Common Vulnerability Scoring System (CVSS) base score, which gives adetailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.Description:Red Hat OpenShift Service Mesh is Red Hat's distribution of the Istio service mesh project, tailored for installation into an OpenShift Container Platform installation.Security Fix(es):* axios: Server-Side Request Forgery (CVE-2024-39338)* elliptic: nodejs/elliptic: From NVD collector (CVE-2024-42459)* ECDSA signature malleability due to missing checks (CVE-2024-42460)* elliptic: nodejs/elliptic: From NVD collector (CVE-2024-42461)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-39338References:https://access.redhat.com/security/updates/classification/#lowhttps://issues.redhat.com/browse/OSSM-6766

Red Hat Security Advisory 2024-6210-03

Red Hat Security Advisory 2024-6209-03 - Red Hat OpenShift Service Mesh Containers for 2.4.10.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_6209.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Moderate: Red Hat OpenShift Service Mesh Containers for 2.4.10 security updateAdvisory ID:        RHSA-2024:6209-03Product:            Red Hat OpenShift Service MeshAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:6209Issue date:         2024-09-03Revision:           03CVE Names:          CVE-2024-28180====================================================================Summary: Red Hat OpenShift Service Mesh Containers for 2.4.10Red Hat Product Security has rated this update as having a security impact ofModerate. A Common Vulnerability Scoring System (CVSS) base score, which gives adetailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.Description:Red Hat OpenShift Service Mesh is Red Hat's distribution of the Istio service mesh project, tailored for installation into an OpenShift Container Platform installation.Security Fix(es):* axios: Server-Side Request Forgery (CVE-2024-39338)* elliptic: nodejs/elliptic: From NVD collector (CVE-2024-42459)* ECDSA signature malleability due to missing checks (CVE-2024-42460)* ECDSA implementation malleability due to BER-enconded signatures being allowed (CVE-2024-42461)* jose-go: improper handling of highly compressed data (CVE-2024-28180)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-28180References:https://access.redhat.com/security/updates/classification/#moderate

Tag

#ios