Cisco just dropped a patch for a maximum-severity vulnerability that allows attackers to change the password of any user, including admins.

Tracked as CVE-2024-20419, the bug carries a maximum 10/10 CVSS 3.1 rating and affects the authentication system of Cisco Smart Software Manager (SSM) On-Prem.

Cisco hasn’t disclosed too many details about this, which is more than understandable given the nature of the vulnerability. However we know that an unauthenticated remote attacker can exploit this to change passwords. It’s hardly ideal, and should be patched as soon as possible.

Digging into the severity assessment, the attack complexity was deemed “low”: no privileges or user interaction would be required to pull it off, and the impact on the product’s integrity, availability, and confidentiality is all designated “high.”

“This vulnerability is due to improper implementation of the password-change process,” Cisco’s advisory reads, providing the last few details about the vulnerability.

“An attacker could exploit this vulnerability by sending crafted HTTP requests to an affected device. A successful exploit could allow an attacker to access the web UI or API with the privileges of the compromised user.”

There are no workarounds for this vulnerability, so get those patches applied if you’re in the business of keeping your passwords safe and secure. Fortunately, there are no signs of this being exploited in the wild yet, but now the cat’s out of the bag it likely won’t be long before that changes.

CVE-2024-20419 affects both SSM On-Prem and SSM Satellite. They’re different names for the same product, only the latter refers to versions before release 7.0.

[…]

Source: Critical Cisco bug allows crims to change admin passwords • The Register

A troubling report from the Belgian consumer protection group Testaankoop: several models of Velop Pro routers from Linksys were found to be sending WiFi configuration data out to a remote server during the setup process. That would be bad enough, but not only are these routers reporting private information to the mothership, they are doing it in clear text for anyone to listen in on.

Testaankoop says that while testing out the Pro WiFi 6E and Pro 7 versions of Velop routers, they discovered that unencrypted packets were being sent to a server hosted by Amazon Web Services (AWS). In these packets, they discovered not only the SSID of the user’s wireless network, but the encryption key necessary to join it. There were also various tokens included that could be used to identify network and user.

While the report doesn’t go into too much detail, it seems this information is being sent as part of the configuration process when using the official Linksys mobile application. If you want to avoid having your information bounced around the Internet, you can still use the router’s built-in web configuration menus from a browser on the local network — just like in the good old days.

The real kicker here is the response from Linksys, or more accurately, the lack thereof. Testaankoop says they notified them of their discovery back in November of 2023, and got no response. There’s even been firmware updates for the affected routers since then, but the issue is still unresolved.

Testaankoop ends the review by strongly recommending users avoid these particular models of Linksys Velop routers, which given the facts, sounds like solid advice to us. They also express their disappointment in how the brand, a fixture in the consumer router space for decades, has handled the situation. If you ask us, things started going downhill once they stopped running Linux on their hardware.

Source: Linksys Velop Routers Caught Sending WiFi Creds In The Clear | Hackaday

A now-patched vulnerability in Ollama – a popular open source project for running LLMs – can lead to remote code execution, according to flaw finders who warned that upwards of 1,000 vulnerable instances remain exposed to the internet.

Wiz Research disclosed the flaw, tracked as CVE-2024-37032 and dubbed Probllama, on May 5 and its maintainers fixed the issue in version 0.1.34 that was released via GitHub a day later.

Ollama is useful for performing inference with compatible neural networks – such as Meta’s Llama family, hence the name; Microsoft’s Phi clan; and models from Mistral – and it can be used on the command line or via a REST API. It has hundreds of thousands of monthly pulls on Docker Hub.

In a report published today, the Wiz bug hunting team’s Sagi Tzadik said the vulnerability is due to insufficient validation on the server side of that REST API provided by Ollama. An attacker could exploit the flaw by sending a specially crafted HTTP request to the Ollama API server — and in Docker installations, at least, the API server is publicly exposed.

The Ollama server provides multiple API endpoints that perform core functions. This includes the API endpoint /api/pull that lets users download models from the Ollama registry as well as private registries. As the researchers found, the process to trigger the download of a model was exploitable, allowing miscreants to potentially compromise the environment hosting a vulnerable Ollama server.

“What we found is that when pulling a model from a private registry (by querying the http://[victim]:11434/api/pull API endpoint), it is possible to supply a malicious manifest file that contains a path traversal payload in the digest field,” Tzadik explained.

An attacker could then use that payload to corrupt files on the system, achieve arbitrary file read, and ultimately remote code execution (RCE) to hijack that system.

“This issue is extremely severe in Docker installations, as the server runs with root privileges and listens on 0.0.0.0 by default – which enables remote exploitation of this vulnerability,” Tzadik emphasized.

And despite a patched version of the project being available for over a month, the Wiz kids found that, as of June 10, there were more than 1,000 of vulnerable Ollama server instances still exposed to the internet. In light of this, there’s a couple things anyone using Ollama should do to protect their AI applications.

First, which should go without saying, update instances to version 0.1.34 or newer. Also, as Ollama doesn’t inherently support authentication, do not expose installations to the internet unless using some sort of authentication, such as a reverse-proxy. Even better, don’t allow the internet to reach the server at all, put it behind firewalls, and only allow authorized internal applications and their users to access it.

“The critical issue is not just the vulnerabilities themselves but the inherent lack of authentication support in these new tools,” Tzadik noted, referring to previous RCEs in other tools used to deploy LLMs including TorchServe and Ray Anyscale.

Plus, he added, even those these tools are new and often written in modern safety-first programming languages, “classic vulnerabilities such as path traversal remain an issue.” ®

Source: Patch now: ‘Easy-to-exploit’ RCE in open source Ollama

Apple and the satellite-based broadband service Starlink each recently took steps to address new research into the potential security and privacy implications of how their services geo-locate devices. Researchers from the University of Maryland say they relied on publicly available data from Apple to track the location of billions of devices globally — including non-Apple devices like Starlink systems — and found they could use this data to monitor the destruction of Gaza, as well as the movements and in many cases identities of Russian and Ukrainian troops.

At issue is the way that Apple collects and publicly shares information about the precise location of all Wi-Fi access points seen by its devices. Apple collects this location data to give Apple devices a crowdsourced, low-power alternative to constantly requesting global positioning system (GPS) coordinates.

Both Apple and Google operate their own Wi-Fi-based Positioning Systems (WPS) that obtain certain hardware identifiers from all wireless access points that come within range of their mobile devices. Both record the Media Access Control (MAC) address that a Wi-FI access point uses, known as a Basic Service Set Identifier or BSSID.

Periodically, Apple and Google mobile devices will forward their locations — by querying GPS and/or by using cellular towers as landmarks — along with any nearby BSSIDs. This combination of data allows Apple and Google devices to figure out where they are within a few feet or meters, and it’s what allows your mobile phone to continue displaying your planned route even when the device can’t get a fix on GPS.

[…]

In essence, Google’s WPS computes the user’s location and shares it with the device. Apple’s WPS gives its devices a large enough amount of data about the location of known access points in the area that the devices can do that estimation on their own.

That’s according to two researchers at the University of Maryland, who theorized they could use the verbosity of Apple’s API to map the movement of individual devices into and out of virtually any defined area of the world. The UMD pair said they spent a month early in their research continuously querying the API, asking it for the location of more than a billion BSSIDs generated at random.

They learned that while only about three million of those randomly generated BSSIDs were known to Apple’s Wi-Fi geolocation API, Apple also returned an additional 488 million BSSID locations already stored in its WPS from other lookups.

[…]

Plotting the locations returned by Apple’s WPS between November 2022 and November 2023, Levin and Rye saw they had a near global view of the locations tied to more than two billion Wi-Fi access points. The map showed geolocated access points in nearly every corner of the globe, apart from almost the entirety of China, vast stretches of desert wilderness in central Australia and Africa, and deep in the rainforests of South America.

A “heatmap” of BSSIDs the UMD team said they discovered by guessing randomly at BSSIDs.

The researchers said that by zeroing in on or “geofencing” other smaller regions indexed by Apple’s location API, they could monitor how Wi-Fi access points moved over time. Why might that be a big deal? They found that by geofencing active conflict zones in Ukraine, they were able to determine the location and movement of Starlink devices used by both Ukrainian and Russian forces.

The reason they were able to do that is that each Starlink terminal — the dish and associated hardware that allows a Starlink customer to receive Internet service from a constellation of orbiting Starlink satellites — includes its own Wi-Fi access point, whose location is going to be automatically indexed by any nearby Apple devices that have location services enabled.

A heatmap of Starlink routers in Ukraine. Image: UMD.

The University of Maryland team geo-fenced various conflict zones in Ukraine, and identified at least 3,722 Starlink terminals geolocated in Ukraine.

“We find what appear to be personal devices being brought by military personnel into war zones, exposing pre-deployment sites and military positions,” the researchers wrote. “Our results also show individuals who have left Ukraine to a wide range of countries, validating public reports of where Ukrainian refugees have resettled.”

[…]

The researchers also focused their geofencing on the Israel-Hamas war in Gaza, and were able to track the migration and disappearance of devices throughout the Gaza Strip as Israeli forces cut power to the country and bombing campaigns knocked out key infrastructure.

“As time progressed, the number of Gazan BSSIDs that are geolocatable continued to decline,” they wrote. “By the end of the month, only 28% of the original BSSIDs were still found in the Apple WPS.”

In late March 2024, Apple quietly updated its website to note that anyone can opt out of having the location of their wireless access points collected and shared by Apple — by appending “_nomap” to the end of the Wi-Fi access point’s name (SSID). Adding “_nomap” to your Wi-Fi network name also blocks Google from indexing its location.

[…]

Rye said Apple’s response addressed the most depressing aspect of their research: That there was previously no way for anyone to opt out of this data collection.

“You may not have Apple products, but if you have an access point and someone near you owns an Apple device, your BSSID will be in [Apple’s] database,” he said. “What’s important to note here is that every access point is being tracked, without opting in, whether they run an Apple device or not. Only after we disclosed this to Apple have they added the ability for people to opt out.”

The researchers said they hope Apple will consider additional safeguards, such as proactive ways to limit abuses of its location API.

[…]

“We observe routers move between cities and countries, potentially representing their owner’s relocation or a business transaction between an old and new owner,” they wrote. “While there is not necessarily a 1-to-1 relationship between Wi-Fi routers and users, home routers typically only have several. If these users are vulnerable populations, such as those fleeing intimate partner violence or a stalker, their router simply being online can disclose their new location.”

The researchers said Wi-Fi access points that can be created using a mobile device’s built-in cellular modem do not create a location privacy risk for their users because mobile phone hotspots will choose a random BSSID when activated.

[…]

For example, they discovered that certain commonly used travel routers compound the potential privacy risks.

“Because travel routers are frequently used on campers or boats, we see a significant number of them move between campgrounds, RV parks, and marinas,” the UMD duo wrote. “They are used by vacationers who move between residential dwellings and hotels. We have evidence of their use by military members as they deploy from their homes and bases to war zones.”

A copy of the UMD research is available here (PDF).

Source: Why Your Wi-Fi Router Doubles as an Apple AirTag – Krebs on Security

An unknown financially motivated crime crew has swiped a “significant volume of records” from Snowflake customers’ databases using stolen credentials, according to Mandiant.

“To date, Mandiant and Snowflake have notified approximately 165 potentially exposed organizations,” the Google-owned threat hunters wrote on Monday, and noted they track the perps as “UNC5537.”

The crew behind the Snowflake intrusions may have ties to Scattered Spider, aka UNC3944 – the notorious gang behind the mid-2023 Las Vegas casino breaches.

“Mandiant is investigating the possibility that a member of UNC5537 collaborated with UNC3944 on at least one past intrusion in the past six months, but we don’t have enough data to confidently link UNC5537 to a broader group at this time,” senior threat analyst Austin Larsen told The Register.

Mandiant – one of the incident response firms hired by Snowflake to help investigate its recent security incident – also noted that there’s no evidence a breach of Snowflake’s own enterprise environment was to blame for its customers’ breaches.

“Instead, every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials,” the Google-owned threat hunters confirmed.

The earliest detected attack against a Snowflake customer instance happened on April 14. Upon investigating that breach, Mandiant says it determined that UNC5537 used legitimate credentials – previously stolen using infostealer malware – to break into the victim’s Snowflake environment and exfiltrate data. The victim did not have multi-factor authentication turned on.

About a month later, after uncovering “multiple” Snowflake customer compromises, Mandiant contacted the cloud biz and the two began notifying affected organizations. By May 24 the criminals had begun selling the stolen data online, and on May 30 Snowflake issued its statement about the incidents.

After gaining initial access – which we’re told occurred through the Snowflake native web-based user interface or a command-line-interface running on Windows Server 2002 – the criminals used a horribly named utility, “rapeflake,” which Mandiant has instead chosen to track as “FROSTBITE.”

UNC5537 has used both .NET and Java versions of this tool to perform reconnaissance against targeted Snowflake customers, allowing the gang to identify users, their roles, and IP addresses.

The crew also sometimes uses DBeaver Ultimate – a publicly available database management utility – to query Snowflake instances.

Several of the initial compromises occurred on contractor systems that were being used for both work and personal activities.

“These devices, often used to access the systems of multiple organizations, present a significant risk,” Mandiant researchers wrote. “If compromised by infostealer malware, a single contractor’s laptop can facilitate threat actor access across multiple organizations, often with IT and administrator-level privileges.”

All of the successful intrusions had three things in common, according to Mandiant. First, the victims didn’t use MFA.

Second, the attackers used valid credentials, “hundreds” of which were stolen thanks to infostealer infections – some as far back as 2020. Common variants used included VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER. But even in these years-old thefts, the credentials had not been updated or rotated.

Almost 80 percent of the customer accounts accessed by UNC5537 had prior credential exposure, we’re told.

Finally, the compromised accounts did not have network allow-lists in place. So if you are a Snowflake customer, it’s time to get a little smarter.

Source: Over 165 Snowflake customers didn’t use MFA, says Mandiant • The Register

Oddly enough, they don’t mention the Ticketmaster 560m+ account hack confirmed in what seems to be a spree hitting Snowflake customers considering the size of the hack! Also, oddly enough, when you Google Snowflake, you get the corporate page, some wikipedia entries, but not very much about the hack. Considering the size and breadth of the problem, this is surprising. But perhaps not, considering it’s a part of Google.

Hackers working for the Chinese government gained access to more than 20,000 VPN appliances sold by Fortinet using a critical vulnerability that the company failed to disclose for two weeks after fixing it, Netherlands government officials said.

The vulnerability, tracked as CVE-2022-42475, is a heap-based buffer overflow that allows hackers to remotely execute malicious code. It carries a severity rating of 9.8 out of 10. A maker of network security software, Fortinet silently fixed the vulnerability on November 28, 2022, but failed to mention the threat until December 12 of that year, when the company said it became aware of an “instance where this vulnerability was exploited in the wild.” On January 11, 2023—more than six weeks after the vulnerability was fixed—Fortinet warned a threat actor was exploiting it to infect government and government-related organizations with advanced custom-made malware.

Enter CoatHanger

The Netherlands officials first reported in February that Chinese state hackers had exploited CVE-2022-42475 to install an advanced and stealthy backdoor tracked as CoatHanger on Fortigate appliances inside the Dutch Ministry of Defense. Once installed, the never-before-seen malware, specifically designed for the underlying FortiOS operating system, was able to permanently reside on devices even when rebooted or receiving a firmware update. CoatHanger could also escape traditional detection measures, the officials warned. The damage resulting from the breach was limited, however, because infections were contained inside a segment reserved for non-classified uses.

On Monday, officials with the Military Intelligence and Security Service (MIVD) and the General Intelligence and Security Service in the Netherlands said that to date, Chinese state hackers have used the critical vulnerability to infect more than 20,000 FortiGate VPN appliances sold by Fortinet. Targets include dozens of Western government agencies, international organizations, and companies within the defense industry.

“Since then, the MIVD has conducted further investigation and has shown that the Chinese cyber espionage campaign appears to be much more extensive than previously known,” Netherlands officials with the National Cyber Security Center wrote. “The NCSC therefore calls for extra attention to this campaign and the abuse of vulnerabilities in edge devices.”

Monday’s report said that exploitation of the vulnerability started two months before Fortinet first disclosed it and that 14,000 servers were backdoored during this zero-day period. The officials warned that the Chinese threat group likely still has access to many victims because CoatHanger is so hard to detect and remove.

[…]

Fortinet’s failure to timely disclose is particularly acute given the severity of the vulnerability. Disclosures are crucial because they help users prioritize the installation of patches. When a new version fixes minor bugs, many organizations often wait to install it. When it fixes a vulnerability with a 9.8 severity rating, they’re much more likely to expedite the update process. Given the vulnerability was being exploited even before Fortinet fixed it, the disclosure likely wouldn’t have prevented all of the infections, but it stands to reason it could have stopped some.

Fortinet officials have never explained why they didn’t disclose the critical vulnerability when it was fixed. They have also declined to disclose what the company policy is for the disclosure of security vulnerabilities. Company representatives didn’t immediately respond to an email seeking comment for this post.

Source: China state hackers infected 20,000 Fortinet VPNs, Dutch spy service says | Ars Technica

Between 27 and 29 May 2024 Operation Endgame, coordinated from Europol’s headquarters, targeted droppers including, IcedID, SystemBC, Pikabot, Smokeloader, Bumblebee and Trickbot. The actions focused on disrupting criminal services through arresting High Value Targets, taking down the criminal infrastructures and freezing illegal proceeds. This approach had a global impact on the dropper ecosystem. The malware, whose infrastructure was taken down during the action days, facilitated attacks with ransomware and other malicious software. Following the action days, eight fugitives linked to these criminal activities, wanted by Germany, will be added to Europe’s Most Wanted list on 30 May 2024. The individuals are wanted for their involvement in serious cybercrime activities.

This is the largest ever operation against botnets, which play a major role in the deployment of ransomware. The operation, initiated and led by France, Germany and the Netherlands was also supported by Eurojust and involved Denmark, the United Kingdom and the United States. In addition, Armenia, Bulgaria, Lithuania, Portugal, Romania, Switzerland and Ukraine also supported the operation with different actions, such as arrests, interviewing suspects, searches, and seizures or takedowns of servers and domains. The operation was also supported by a number of private partners at national and international level including Bitdefender, Cryptolaemus, Sekoia, Shadowserver, Team Cymru, Prodaft, Proofpoint, NFIR, Computest, Northwave, Fox-IT, HaveIBeenPwned, Spamhaus and DIVD.

The coordinated actions led to:

• 4 arrests (1 in Armenia and 3 in Ukraine)
• 16 location searches (1 in Armenia, 1 in the Netherlands, 3 in Portugal and 11 in Ukraine)
• Over 100 servers taken down or disrupted in Bulgaria, Canada, Germany, Lithuania, the Netherlands, Romania, Switzerland, the United Kingdom, the United States and Ukraine
• Over 2 000 domains under the control of law enforcement

Furthermore, it has been discovered through the investigations so far that one of the main suspects has earned at least EUR 69 million in cryptocurrency by renting out criminal infrastructure sites to deploy ransomware.

[…]

Operation Endgame does not end today. New actions will be announced on the website Operation Endgame. In addition, suspects involved in these and other botnets, who have not yet been arrested, will be directly called to account for their actions. Suspects and witnesses will find information on how to reach out via this website.

Command post at Europol to coordinate the operational actions

Europol facilitated the information exchange and provided analytical, crypto-tracing and forensic support to the investigation. To support the coordination of the operation, Europol organised more than 50 coordination calls with all the countries as well as an operational sprint at its headquarters.

Over 20 law enforcement officers from Denmark, France, Germany and the United States supported the coordination of the operational actions from the command post at Europol and hundreds of other officers from the different countries involved in the actions. In addition, a virtual command post allowed real-time coordination between the Armenian, French, Portuguese and Ukrainian officers deployed on the spot during the field activities.

The command post at Europol facilitated the exchange of intelligence on seized servers, suspects and the transfer of seized data. Local command posts were also set up in Germany, the Netherlands, Portugal, the United States and Ukraine. Eurojust supported the action by setting up a coordination centre at its headquarters to facilitate the judicial cooperation between all authorities involved. Eurojust also assisted with the execution of European Arrest Warrants and European Investigation Orders.

[…]

Source: Largest ever operation against botnets hits dropper malware ecosystem | Europol

Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.

TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address. The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android. They also said their attack technique may have been possible since 2002 and may already have been discovered and used in the wild since then.

Reading, dropping, or modifying VPN traffic

The effect of TunnelVision is “the victim’s traffic is now decloaked and being routed through the attacker directly,” a video demonstration explained. “The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the Internet.”

The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network. A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself. Researchers from Leviathan Security explained:

Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway. When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.

We use DHCP option 121 to set a route on the VPN user’s routing table. The route we set is arbitrary and we can also set multiple routes if needed. By pushing routes that are more specific than a /0 CIDR range that most VPNs use, we can make routing rules that have a higher priority than the routes for the virtual interface the VPN creates. We can set multiple /1 routes to recreate the 0.0.0.0/0 all traffic rule set by most VPNs.

Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.

We now have traffic being transmitted outside the VPN’s encrypted tunnel. This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121. It’s also possible for people who can connect to the network as an unprivileged user to perform the attack by setting up their own rogue DHCP server.

The attack allows some or all traffic to be routed through the unencrypted tunnel. In either case, the VPN application will report that all data is being sent through the protected connection. Any traffic that’s diverted away from this tunnel will not be encrypted by the VPN and the Internet IP address viewable by the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN app.

Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.

The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.

Source: Novel attack against virtually all VPN apps neuters their entire purpose | Ars Technica

[…] The email your manager received and forwarded to you was something completely innocent, such as a potential customer asking a few questions. All that email was supposed to achieve was being forwarded to you. However, the moment the email appeared in your inbox, it changed. The innocent pretext disappeared and the real phishing email became visible. A phishing email you had to trust because you knew the sender and they even confirmed that they had forwarded it to you.

This attack is possible because most email clients allow CSS to be used to style HTML emails. When an email is forwarded, the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.

An attacker can use this to include elements in the email that appear or disappear depending on the context in which the email is viewed. Because they are usually invisible, only appear in certain circumstances, and can be used for all sorts of mischief, I’ll refer to these elements as kobold letters, after the elusive sprites of mythology.

This affects all types of email clients and webmailers that support HTML email. So pretty much all of them. For the moment, however, I’ll focus on selected clients to demonstrate the problem, and leave it to others (or future me) to extend the principle to other clients.

[…]

Exploiting this in Thunderbird is fairly straightforward. Thunderbird wraps emails in <div class="moz-text-html" lang="x-unicode"></div> and leaves them otherwise unchanged, making it a good example to demonstrate the principle. When forwarding an email, the quoted email will be enclosed in another <div></div>, moving it down one level in the DOM.

Taking this into account leads to the following proof of concept:

<!DOCTYPE html>
<html>

<head>
    <style>
        .kobold-letter {
            display: none;
        }

        .moz-text-html>div>.kobold-letter {
            display: block !important;
        }
    </style>
</head>

<body>
    <p>This text is always visible.</p>
    <p class="kobold-letter">This text will only appear after forwarding.</p>
</body>

</html>

The email contains two paragraphs, one that has no styling and should always be visible, and one that is hidden with display: none;. This is how it looks when the email is displayed in Thunderbird:

As expected, only the paragraph “This text is always visible.” is shown. However, when we forward the email, the second paragraph becomes suddenly visible. Albeit only to the new recipient – the original recipient who forwarded the email remains unaware.

Because we know exactly where each element will be in the DOM relative to .moz-text-html, and because we control the CSS, we can easily hide and show any part of the email, changing the content completely. If we style the kobold letter as an overlay, we can not only affect the forwarded email, but also (for example) replace any comments your manager might have had on the original mail, opening up even more opportunities for phishing.

[…]

Source: Kobold letters – Lutra Security

[…] Open Web Advocacy (OWA), a group that supports open web standards and fair competition, said in a post on Tuesday that representatives “recently met with both the [EU’s] Digital Markets Act team and the UK’s Market Investigation Reference into Cloud Gaming and Browsers team to discuss how tech giants are subverting users’ choice of default browser via in-app browsers and the harm this causes.”

OWA argues that in-app browsers, without notice or consent, “ignore your choice of default browser and instead automatically and silently replace your default browser with their own in-app browser.”

The group’s goal isn’t to ban the technology, which has legitimate uses. Rather it’s to prevent in-app browsers from being used to thwart competition and flout user choice.

In-app browsers are like standalone web browsers without the interface – they rely on the native app for the interface. They can be embedded in native platform apps to load and render web content within the app, instead of outside the app in the designated default browser.

[…]

The problem with in-app browsers is that they play by a different set of rules from standalone browsers. As noted by OWA in its 62-page submission [PDF] to regulators:

• They override the user’s choice of default browser
• They raise tangible security and privacy harms
• They stop the user from using their ad-blockers and tracker blockers
• Their default browsers privacy and security settings are not shared
• They are typically missing web features
• They typically have many unique bugs and issues
• The user’s session state is not shared so they are booted out of websites they have logged into in their default browser
• They provide little benefit to users
• They create significant work and often break third-party websites
• They don’t compete as browsers
• They confuse users and today function as dark patterns

Since around 2016, software engineers involved in web application development started voicing concerns about in-app browsers at some of the companies using them. But it wasn’t until around 2019 when Google engineer Thomas Steiner published a blog post about Facebook’s use of in-app browsers in its iOS and Android apps that the privacy and choice impact of in-app browsers began to register with a wider audience.

Steiner observed: “WebViews can also be used for effectively conducting intended man-in-the-middle attacks, since the IAB [in-app browser] developer can arbitrarily inject JavaScript code and also intercept network traffic.” He added: “Most of the time, this feature is used for good.”

[…]

In August 2022, developer Felix Krause published a blog post titled “Instagram and Facebook can track anything you do on any website in their in-app browser.” A week later, he expanded his analysis of in-app browsers to note how TikTok’s iOS app injects JavaScript to subscribe to “every keystroke (text inputs) happening on third party websites rendered inside the TikTok app”

[…]

Even assuming one accepts Meta’s and TikTok’s claims that they’ve not misused the extraordinary access granted by in-app browsers – a difficult ask in light of allegations raised in ongoing Meta litigation – the issue remains that companies implementing in-app browsers may be overriding the choices of users regarding their browser and whatever extensions they have installed.

However, Meta does provide a way to opt out of having its in-app browser open links clicked in its Facebook and Instagram apps.

[…]

As for the Competition and Markets Authority (CMA), the UK watchdog appears to be willing to consider allowing developer choice to supersede user choice, or at least that was the case two years ago. In its 2022 response to the CMA’s Interim Report, Google observed [PDF] that the competition agency itself had conceded that in an Android native app, the choice of browser belongs to the app developer rather than to Google.

“The Interim Report raises concerns about in-app browsers overriding users’ chosen default browsers,” Google said in its response. “However, as the CMA rightly notes, the decision on whether a native app launches an in-app browser, and if so, which browser, lies with the respective app developer, not Google. Having control over whether or not an in-app browser is launched allows app developers to customize their user interfaces, which can in turn improve the experience for users. There is therefore, to some extent, a trade-off between offering developers choice and offering end users choice.”

Source: In-app browsers still a privacy, security, and choice issue • The Register

However, in-app browsers are a horrible security breach and the choice should belong to the user – not Google, not an app developer.