Search This Blog

Showing posts with label Google. Show all posts

SaaS App Vanity URLs Can Be Spoofed for Phishing & Social Engineering

 

Researchers warn that vanity links made by businesses to add their brand to well-known cloud services could become a handy vector for phishing attacks and a technique to deceive users. Cloud services that don't check whether subdomains have been modified may allow URLs that appear to be from "varonis.box.com" or "apple.zoom.us," according to a Varonis advisory released on Wednesday. 

In the instance of Box.com, this could result in a malicious document; in the case of Zoom, it could result in a data-gathering webinar unrelated to the stated brand. The issue arises when a cloud service permits the usage of a vanity subdomain but does not validate it or use it to provide services. More than six months ago, Varonis warned Box.com and Zoom of the problem, as well as Google, whose URLs to Google Docs might be spoofed. 

The issues are essentially fixed, according to the company. According to Or Emanuel, director of research and security at Varonis, the vulnerability is likely to occur for other providers. "We think it is more than just those three SaaS services," he says, adding that attackers can also use the predictability of the subdomains to select potential victims. "Because of the vanity URLs, it makes it very easy for threat actors to scan all the subdomains of all the big Fortune companies with different cloud providers." 

Attackers use well-known companies to hide dangerous code and phishing sites, which allows them to dupe victims into trusting false e-mail messages and website links. In 2019, for example, three-quarters of businesses learned that the lookalike domain had been created by a third party using a top-level domain other than.COM. Varonis' research takes a different approach to the problem. 

Rather than looking at top-level domains, the company's researchers looked into ways to abuse the subdomains that many cloud service providers allow their customers to use. "Not only do vanity URLs feel more professional, but they also provide a sense of security for end-users," Varonis stated in the advisory. "Most people are likelier to trust a link at varonis.box.com than a generic app.box.com link. However, if someone can spoof that subdomain, then trusting the vanity URL can backfire."

When a customer is permitted to utilise their brand as a subdomain, such as varonis.zoom.us, a software-as-a-service (SaaS) application is vulnerable to the attack since the subdomain is no longer validated when the link is provided to a third party, such as participants in a conference call or webinar. In the case of Zoom's service, attackers may design a webinar that asks registrants a series of social engineering-friendly questions, rebrand the webinar as a well-known organisation, and then modify the resulting URL to the targeted URL. 

The original domain — for example, attacker.zoom.us — might be changed to varonis.zoom.us without affecting the link's functioning. A well-branded page might trick a victim into providing personal information, especially if the subdomain indicates that the host is a well-known organisation. In the case of Box.com, a link like app.box.com/f/abcd1234 may be modified to varonis.app.box.com/f/abcd1234 to make it look like an official form gathering information while actually sending it to the attacker.  

"The more interesting attacks from a data protection standpoint are when you have forms for registration or file-sharing requests," Emanuel says. "When the threat actor controls these pages, they can ask for any information they want, and it seems totally legit. It's really hard to determine that it's not a page that the company owns." 

This type of social engineering is beneficial in phishing assaults, as well as persuading people to click on links or download suspicious files. According to the FBI's annual Internet Crime Complaint Center (IC3) report, losses from cybercrime, including phishing attacks, reached approximately $7 billion in 2021. According to Emanuel, cloud providers should verify that any URL change is confirmed by the link's encoding. 

According to Varonis, both Box.com and Google have fixed the issues, albeit the errors still present for Google Forms and Google Docs when using the "Publish to the web" function. When the subdomain is changed, Zoom will notify users. Furthermore, users should be wary of links, particularly if the connected page requires too much information or leads to further links or files. 

"We recommend educating your coworkers about the risk associated with clicking on such links and especially submitting PII and other sensitive information via forms, even if they appear to be hosted by your company’s sanctioned SaaS accounts," Varonis stated in the advisory.

Google SMTP Relay Service Exploited for Sending Phishing Emails

 

Phishers are exploiting a vulnerability in Google's SMTP relay service to send malicious emails that imitate well-known brands. Threat actors use this service to mimic other Gmail tenants, according to Avanan researcher Jeremy Fuchs. Since April 2022, they've noticed a massive rise in these SMTP relay service exploit attacks in the wild. 

Organizations utilise Google's SMTP relay service to send out promotional messages to a large number of consumers without the risk of their mail server being blacklisted. 

Fuchs explained, “Many organizations offer this service. Gmail does as well, with the ability to route outgoing non-Gmail messages through Google. However, these relay services have a flaw. Within Gmail, any Gmail tenant can use it to spoof any other Gmail tenant. That means that a hacker can use the service to easily spoof legitimate brands and send out phishing and malware campaigns. When the security service sees avanan.com coming into the inbox, and it’s a real IP address from Gmail’s IP, it starts to look more legitimate.” 

As Gmail's SMTP relay servers are usually trusted, email security solutions are circumvented, and recipients see a legitimate-looking email address in the "From:" field. Users will only know something is wrong if they inspect the message headers. 

This brand impersonation method will only work if the impersonated corporation/brand company hasn't enabled its DMARC reject policy, according to Fuchs. A DNS-based authentication standard is known as DMARC. It protects enterprises from impersonation threats by preventing malicious, spoof emails from reaching their intended recipients. 

Using tools like MXToolbox, any phisher — indeed, anyone who uses the internet – may verify whether the DMARC reject policy has been enabled for a certain domain. Trello and Venmo, for example, haven't, according to Fuchs, while Netflix has. 

On April 23rd, 2022, Fuchs claims to have warned Google about how phishers were using their SMTP relay service. “Google noted that it will display indicators showing the discrepancy between the two senders, to aid the user and downstream security systems,” he told Help Net Security. 

He also points out that any SMTP relay could be vulnerable to this type of assault. The DMARC protocol, which Google recommends, is the overarching solution to this well-known security issue. However, until that becomes the norm, recipients should verify the headers of unsolicited email messages and avoid opening attachments or clicking on links in those messages if they can't tell whether they're harmful. 

“We have built-in protections to stop this type of attack. This research speaks to why we recommend users across the ecosystem use the Domain-based Message Authentication, Reporting & Conformance (DMARC) protocol. Doing so will defend against this attack method, which is a well-known industry issue,” a Google spokesperson told Help Net Security.

Google's Safety Section Will Show What Android Apps Do With the User Data

Earlier this week, Google rolled out a new Data Safety section for Android apps on Play Store to mention the type of data that is collected and given to third parties. It is the users' right to know why their data is collected and if the developer shares user data with a third party. 

Besides this, users should know how application developers are protecting user data when an app is downloaded. The transparency measure, built in accordance with Apple's Privacy Nutrition Labels, was first announced by Google last year in May 2021. 

The Data safety section will show up against all app listings on the digital storefront, presenting a unified view of what kind of data is getting collected, why it's being collected, and how it'll be used, also mentioning what data is shared with the third parties. Moreover, the labels may also show an app's security practices, for instance, data encryption in transit and if the user can ask for the data to be deleted. 

Additionally, it will validate these practices against security standards like Mobile Application Security Verification Standard (MASVS). The feature will probably be rolled out for all users, app developers can expect a deadline of 20 July 2022 to finalize the work and update the users if there is any change in the apps' functionality or data handling practices. 

Data safety may face similar concerns that Apple did, as the system is built entirely on an honor system, which needs app developers, to be honest, and clear about what they'll do with the data, avoiding listing it as inaccurate labels. 

Since then, Apple said that the company will audit labels for authenticity, and make sure that these labels are dependable and don't give the users fake assurance about security. 

"Google, last year, had said that it intends to institute a mechanism in place that requires developers to furnish accurate information and that it will mandate them to fix misrepresentations should it identify instances of policy violations," reports The Hacker News.

VirusTotal Reveals Claims of Critical Flaws in Google’s Antivirus Service

 

There have been questions raised regarding the credibility of research that claims to reveal a severe vulnerability in VirusTotal, a Google-owned antivirus comparison and threat intel service. 

VirusTotal (VT) is a service that enables security researchers, system administrators, and others to evaluate suspicious files, domains, IP addresses, and URLs using an aggregated service that includes close to 70 antivirus vendors and scan engines. The security community, including, but not limited to, the vendors who maintain the scanning engines used by VT, receives samples provided through the service automatically. 

 In a blog post published on Tuesday, Israel-based cybersecurity education platform provider Cysource claims researchers were able to “execute commands remotely within [the] VirusTotal platform and gain access to its various scans capabilities”. 

A doctored DJVU file with a malicious payload added to the file's metadata is used in the attack. To accomplish remote code execution (RCE) and a remote shell, this payload exploits the CVE-2021-22204 vulnerability in Exiftool, a metadata analysis tool.

In April 2021, Cysource researchers presented their findings to Google's VRP, which were addressed a month later. VirusTotal claims that instead of providing a way to weaponize VirusTotal, Cysource has only demonstrated a way to exploit an unpatched third-party antivirus toolset. 

Bernardo Quintero, VirusTotal's founder, stated the code executions are occurring on third-party scanning systems that take and analyse samples obtained from VT, rather than VirusTotal itself, in a response to the findings released as a thread on Twitter. 

 “None [of the] reported machine was from VT and the ‘researchers’ knew it,” Quintero added.

Google Researchers: 'Zero-Day’ Hacks Hit Record in 2021

 

Following a year marked by high-profile ransomware assaults and supply-chain hacks, Google researchers have uncovered another alarming cyber milepost for 2021: a record number of "zero-day" exploits. A zero-day exploit is a previously undisclosed flaw that gives software developers exactly 0 days to fix it. As a result, the technology in question is extremely lucrative to hackers - and a disaster for cyber-security experts. 

According to a report released Tuesday (April 19) by Google's Project Zero, a team of specialist bug hunters, hackers attacked a total of 58 zero-day defects affecting key software suppliers in 2021. In 2020, there were 25 flaws, compared to 21 in 2019. Since Project Zero began tracking zero-days in 2014, this is the largest number of zero-days ever recorded. 

Ms Maddie Stone, a security researcher at Project Zero, stated in a blog post about the findings that the trend could be attributed to an enhancement in identification from companies like Microsoft, Apple, and Google, who now publicly report their findings around zero-day concerns, rather than a spike in hacks. 

Hackers have utilized the attack approach in recent years to install powerful spyware on smartphones, which has then been used to spy on journalists, lawmakers, human rights activists, and others. Last year, suspected Chinese state-sponsored hackers used such vulnerabilities to compromise Microsoft Exchange servers. 

Ms Stone of Google stated that the data contained some surprises. Despite the recent attention on spyware abuse, cyber-security researchers are still unable to find zero-day vulnerabilities that allow hackers to exploit systems. 

She wrote, "We know that messaging applications like WhatsApp, Signal, Telegram, etc are targets of interest to attackers and yet there's only one messaging app, in this case, iMessage, zero-day found this past year." 

Since 2014, the team has discovered two such flaws, one in WhatsApp in 2019 and the other in iMessage in 2021. According to Ms Stone, the majority of individuals on the planet are not at risk of being targeted by a zero-day attack. 

Nonetheless, she believes that such attacks have a widespread influence. "These zero-days tend to have an outsized impact on society so we need to continue doing whatever we can to make it harder for attackers to be successful."

Google Strengthens Android Security With a New Set of Dev Policy Updates

 

Google has announced several important policy changes for Android app developers that will improve the security of users, Google Play, and the apps available through the service. 
These new developer requirements will be in effect from May 11th through November 1st, 2022, allowing developers plenty of time to adjust. The following are the most important policy changes related to cybersecurity and fraud that will be implemented: 
  • New API level target requirements.
  • Banning of loan apps whose Annual Percentage Rate (APR) is 36% or higher.
  • Prohibiting the abuse of the Accessibility API.
  • New policy changes for the permission to install packages from external sources.
All newly released/published apps must target an Android API level released within one year of the most recent major Android version release starting November 1, 2022. Those who do not comply with this criterion will have their apps banned from the Play Store, Android's official app store. 

Existing apps that do not target an API level within two years of the most recent major Android version will be eliminated from the Play Store and become undiscoverable. This change is intended to compel app developers to follow the tougher API regulations that underpin newer Android releases, such as better permission management and revoking, notification anti-hijacking, data privacy enhancements, phishing detection, splash screen limits, and other features. 

According to Google's blog article on the new policy: "users with the latest devices or those who are fully caught up on Android updates expect to realize the full potential of all the privacy and security protections Android has to offer." 

App developers who require extra time to migrate to more recent API levels can request a six-month extension, albeit this is not guaranteed. Many outdated apps will be forced to adopt better secure methods as a result of this policy change. 

Accessibility API abuse

The Accessibility API for Android enables developers to design apps that are accessible to people with disabilities, enabling the creation of new ways to operate the device using its applications. However, malware frequently exploits this capability to do actions on an Android smartphone without the user's permission or knowledge. As noted below, Google's new policies further restrict how this policy can be applied: 
  • Change user settings without their permission or prevent the ability for users to disable or uninstall any app or service unless authorized by a parent or guardian through a parental control app or by authorized administrators through enterprise management software; 
  • Workaround Android built-in privacy controls and notifications; or
  • Change or leverage the user interface deceptively or otherwise violates Google Play Developer Policies.
Google has also released a policy change that tightens the "REQUEST INSTALL PACKAGES" permission. Many malicious software publishers hide package-fetching technology that downloads malicious modules after installation to have their submission accepted on the Play Store. Users interpret these activities as "request to update" or "download new content," and they either authorise the action when presented with the corresponding prompt or don't notice because it occurs in the background. 

Google aims to narrow this loophole by imposing new permission requirements, bringing light to an area that was previously unregulated. Apps that use this permission must now only fetch digitally signed packages, and self-updates, code modifications, or bundling of APKs in the asset file will still require the user's authorization. For all apps using API level 25 (Android 7.1) or higher, the new REQUEST INSTALL PACKAGES policies will enter into force on July 11th, 2022.

JupyterLab Web Notebooks Targeted by Unique Python-Based Ransomware

 

The first-ever Python-based ransomware virus specifically tailored to target vulnerable Jupyter notebooks has been revealed by researchers. It is a web-based immersive computing platform which allows editing and running programs via a browser. Python isn't widely used for malware development, instead, notably, thieves prefer languages like Go, DLang, Nim, and Rust. Nonetheless, this isn't the first time Python has been used in a ransomware attack. Sophos disclosed Python ransomware, particularly targeting VMware ESXi systems in October 2021. 

Jupyter Notebook is a web-based data visualization platform that is open source. In data science, computers, machine learning, and modular software are used to model data. Over 40 programming languages are supported by the project, which is used by Microsoft, IBM, and Google, as well as other universities. According to Assaf Morag, a data analyst at Aqua Security, "the attackers got early access via misconfigured environments, then executed a ransomware script it encrypts every file on a particular path on the server and eliminates itself after execution to disguise the operation." 

The Python ransomware is aimed at those who have unintentionally made one's systems susceptible. To watch the malware's activities, the researchers set up a honeypot with an exposed Jupyter notebook application. The ransomware operator logged in to the server, opened a terminal, downloaded a set of malicious tools, including encryptors, and then manually generated a Python script. While the assault came to a halt before completing the mission, Team Nautilus was able to gather enough data to mimic the remainder of the attack in a lab setting. The encryptor would replicate and encrypt files, then remove any unencrypted data before deleting itself. 

"There are over 11,000 servers with Jupyter Notebooks which are internet-facing," Aqua researcher Assaf Morag stated. "Users can execute a brute force attack and perhaps obtain access to some of them — one would be amazed how easy it can be to predict these passwords." We believe the attack either timed out on the honeypot or the ransomware is still being evaluated before being used in real-world attacks." Unlike other conventional ransomware-as-a-service (RaaS) schemes, Aqua Security described the attack as "simple and straightforward," adding since no ransom note was displayed on the process, raising the possibility the threat actor was experimenting with the modus operandi or the honeypot scheduled out before it could be completed. 

Regardless, the researchers believe it is ransomware rather than a wiper weapon based on what they have. "Wipers typically exfiltrate data and delete it or simply wipe it," Morag continued. "We haven't observed any attempts to move the data outside the server, and the data wasn't just erased, it was encrypted with a password," says the researcher. This is even additional evidence this is a ransomware attack instead of a wiper."

Although evidence discovered during the incident study leads to a Russian actor, citing similarities with prior crypto mining assaults focused on Jupyter notebooks, the attacker's identity remains unknown.

V8 Type Confusion Vulnerability Hits Google Chrome & Microsoft Edge Browser

 

Following the discovery of a V8 vulnerability in Chrome and Edge that has been exploited in the wild, ZDNet recommends that users running Windows, macOS, or Linux update their Chrome builds to version 99.0.4844.84, as an out-of-band security update was recently released by Google to address the issue. 

Concerning the V8 Vulnerability:

There isn't much information available about this recently discovered vulnerability, as Google stated that it will wait for the bulk of users to update their browsers before acting. As per Google, “Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third-party library that other projects similarly depend on, but haven’t yet fixed.” 

What is known is that the bug in question has been assigned CVE-2022-1096, which is a zero-day "type confusion in V8" bug and was reported on March 23, 2022, by an "anonymous" researcher. V8 is a JavaScript engine that is completely free and open-source. The Chromium Project created it for Google Chrome and Chromium web browsers. 

Lars Bak is the person who came up with the idea for the project. It's worth noting that the first version of Firefox was released in 2008, almost simultaneously with the initial version of Chrome. Because the V8 vulnerability affected Edge as well, Microsoft Office issued a statement on the subject, stating that the issue had been resolved in Edge version 99.0.1150.55. 

Microsoft’s notice reads, “The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information.”

Google Authenticator Codes for Android is Targeted by Nefarious Escobar Banking Trojan

 


'Escobar' virus has resurfaced in the form of a novel threat, this time targeting Google Authenticator MFA codes. 

The spyware, which goes by the package name com.escobar.pablo is the latest Aberebot version which was discovered by researchers from Cyble, a security research firm, who combed through a cybercrime-related forum. Virtual view, phishing overlays, screen captures, text-message captures, and even multi-factor authentication capture are all included in the feature set. 

All of these characteristics are utilized in conjunction with a scheme to steal a user's financial data. This malware even tries to pass itself off as McAfee antivirus software, with the McAfee logo as its icon. It is not uncommon for malware to disguise itself as a security software; in fact, it was recently reported that the malware was installed straight inside of a completely functional 2-factor authentication app. 

The malicious author is leasing the beta version of the malware to a maximum of five customers for $3,000 per month, with threat actors getting three days to test the bot for free. After development, the threat actor intends to raise the malware's price to $5,000. 

Even if the overlay injections are curtailed in some way, the malware has various other capabilities to make it effective against any Android version. In the most recent version, the authors increased the number of aimed banks and financial organizations to 190 entities from 18 countries. 

The malware asks a total of 25 rights, 15 of which are employed nefariously. To name a few, accessibility, audio recording, read SMS, read/write storage, acquiring account lists, disabling keylock, making calls, and accessing precise device locations. Everything the virus captures, including SMS call records, key logs, notifications, and Google Authenticator codes, is sent to the C2 server. 

It is too soon to gauge the popularity of the new Escobar malware among cybercriminals, especially given its exorbitant price. Nonetheless, it has grown in strength to the point that it can now lure a wider audience. 

In general, avoiding the installation of APKs outside of Google Play, utilizing a mobile security application, and ensuring the Google Play Protect is enabled on your device will reduce, the chances of being infected with Android trojans.

Android's March 2022 Security Updates Patch 39 Vulnerabilities

 

This week Google has announced the release of security patches for 39 vulnerabilities for the March 2022 security update for Android devices. The most sensitive vulnerability is CVE-2021-39708 which gives a remotely exploitable elevation of privilege to malicious actors. This issue was found in the System component. 

“The most severe of these issues is a critical security vulnerability in the System component that could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation,” Google notes in its advisory. 

The first set of measures arrives on devices as the 2022-03-01 security patch level and addresses CVE-2021-39708 with 17 other bugs. 

According to the data, 10 security issues have been resolved in the System component in which nine issues were elevation of privilege and one was information disclosure vulnerability. Also, six vulnerabilities were resolved in Framework in which four were elevation of privilege and two denials of service bugs. Further, one security measure was patched in Android runtime (elevation of privilege) and the last was in Media Framework (information disclosure). 

Additionally, On Google Pixel devices, the March 2022 Android security measures also have resolved 21 flaws as part of the 2022-03-05 security patch level. Later addresses all of these vulnerabilities along with 41 other security flaws that hit Kernel components (13 flaws), Pixel (26), Qualcomm components (1), and Qualcomm closed-source components (1). 

The March 2022 security measures with patch level 2022-03-05 are released for the Pixel 3a series, Pixel 4 series, Pixel 4a series, Pixel 5, Pixel 5a, however, the Pixel 6 series update is delayed (again). Additionally, the Pixel-specific new measures introduced additional vulnerabilities in the Pixel software, kernel, and both open and closed-source Qualcomm components, the details of which have been given below. 

Global: Pixel 3a: SP2A.220305.012 Pixel 3a (XL): SP2A.220305.012 Pixel 4: SP2A.220305.012 Pixel 4 (XL): SP2A.220305.012 Pixel 4a: SP2A.220305.012 Pixel 4a (5G): SP2A.220305.012 Pixel 5: SP2A.220305.012 Pixel 5a (5G): SP2A.220305.012 Pixel 6: Waiting Pixel 6 Pro: delayed.

 'Dirty Pipe' Kernel Bug Enables Root Patched via Linux Distros

 

Dirty Pipe is a Linux local privilege escalation problem that has been found and publicly released, together with proof-of-concept vulnerability. The 'Dirty Pipe' vulnerability was responsibly disclosed by security researcher Max Kellermann, who indicated it impacts Linux Kernel 5.8 and later versions, as well as Android devices. 

CVE-2022-0847 is a weakness in the Linux kernel which was introduced in version 5.8 and resolved in versions 5.16.11, 5.15.25, and 5.10.102.

Kellerman discovered the flaw while investigating a bug that was causing one of his customer's web server access records to be corrupted. The vulnerability, according to Kellerman, is similar to the Dirty COW vulnerability (CVE-2016-5195), which was addressed in 2016.

A bug in the kernel's pipe handling code allows a user program to rewrite the information of the page cache, which ultimately makes its way into the file system, thanks to a refactoring error. It is identical to Dirty COW, but it is relatively easier to use. 

While using Linux, check for and install security updates from the distro. Wait for Google (and maybe your maker and/or carrier) to send you an update if you're using Android; because it runs a kernel older than 5.8, the current version of Android for the Google Pixel 6 and the Samsung Galaxy S22 is currently in jeopardy. 

Kellerman revealed a proof-of-concept (PoC) vulnerability as part of the Dirty Pipe disclosure which essentially allows users to inject their own content into sensitive read-only files, removing limitations or modifying settings to provide wider access than they would normally have. 

However, security researcher BLASTY disclosed an improved vulnerability today which makes gaining root privileges easier by altering the /usr/bin/su command to dump a root shell at /tmp/sh and then invoking the script. 

Starting on February 20th, 2022, the vulnerability was responsibly revealed to several Linux maintainers, including the Linux kernel security team and the Android Security Team. Despite the fact that the defect has been resolved in Linux kernels 5.16.11, 5.15.25, and 5.10.102, numerous servers continue to use outdated kernels, making the release of this vulnerability a major concern for server admins. 

Furthermore, due to the ease with which these vulnerabilities may be used to acquire root access, it will only be a matter of time before threat actors start exploiting the vulnerability in upcoming attacks. The malware had previously used the comparable Dirty COW vulnerability, which was more difficult to attack.  

This flaw is particularly concerning for web hosting companies that provide Linux shell access, as well as colleges that frequently provide shell access to multi-user Linux systems. It has been a difficult year for Linux, with a slew of high-profile privilege-escalation flaws exposed.

Google WAF Circumvented Via Oversized POST Requests

 

It is possible to circumvent Google's cloud-based defences due to security flaws in the default protection offered by the company's web application firewall (WAF). 

Researchers from security firm Kloudle discovered that by sending a POST request larger than 8KB, they were able to get beyond the web app firewalls on both Google Cloud Platform (GCP) and Amazon Web Services (AWS). 

“The default behaviour of Cloud Armor, in this case, can allow malicious requests to bypass Cloud Armor and directly reach an underlying application,” according to Kloudle. 

"This is similar to the well-documented 8 KB limitation of the AWS web application firewall, however, in the case of Cloud Armor, the limitation is not as widely known and is not presented to customers as prominently as the limitation in AWS.” 

Even if an underlying application is still susceptible, WAFs are designed to guard against web-based attacks like SQL Injection and cross-site scripting. If a targeted endpoint accepts HTTP POST requests "in a manner that could trigger an underlying vulnerability," bypassing this safeguard would bring a potential attacker one step closer to attacking a web-hosted application. 

Kloudle explains in a technical blog post,“This issue can be exploited by crafting an HTTP POST request with a body size exceeding the 8KB size limitation of Cloud Armor, where the payload appears after the 8192th byte/character in the request body." 

Google's Cloud Armor WAF comes with a collection of predefined firewall rules based on the OWASP ModSecurity Core Rule Set, which is open source. The possible attack vector can be blocked by setting a custom Cloud Armor rule to block HTTP requests with request bodies larger than 8192 bytes - a general rule that can be customised to accommodate defined exceptions. 

Even though AWS' WAF has similar issues, Kloudle faulted GCP for neglecting to notify customers about the problem. According to the researchers, other cloud-based WAFs have comparable drawbacks. 

Kloudle told The Daily Swig: “This is part of ongoing work… so far, we have seen request body limitations with Cloudflare, Azure, and Akamai as well. Some have 8KB and others extend to 128KB.” 

In response to questions from The Daily Swig, a Google spokesperson stated that the 8KB restriction is stated in the company's documentation. Kloudle's representative expressed concern over security and functionality. 

The representative explained, “Perimeter security software is hard. I suspect in this case 8KB limit allows them to reliably process other WAF rules. They could be doing more for developer awareness, including adding that rule by default with the option to disable in case someone wants to. As per the shared security responsibility model they put the onus on the end-user to use the service securely.”  

Kloudle's representative expressed sympathy for the security and functionality trade-offs that cloud providers must make but suggested to The Daily Swig that cloud providers could do more to educate consumers about the issue.

Google Announces Privacy Sandbox on Android to Restrict Sharing of User Data

 

Google announced on Wednesday that it will extend its Privacy Sandbox activities to Android in an effort to broaden its privacy-focused, but less disruptive, advertising technologies beyond the desktop web. To that aim, Google stated it will work on solutions that prohibit cross-app tracking, similar to Apple's App Tracking Transparency (ATT) framework, essentially restricting the exchange of user data with third parties as well as removing identifiers like advertising IDs from mobile devices. 

Anthony Chavez, vice president of product management for Android security and privacy, stated, "The Privacy Sandbox on Android builds on our existing efforts on the web, providing a clear path forward to improve user privacy without putting access to free content and services at risk." 

Google's Privacy Sandbox, which was announced in 2019, is a collection of technologies that will phase out third-party cookies and limit covert monitoring, such as fingerprinting, by reducing the number of information sites that can access to keep track of users online behavior. 

The Alphabet Inc. company, which makes the majority of its revenue from advertising, says it can safeguard phone users' data while still providing marketers and app developers with new technology to deliver targeted promotions and measure outcomes. According to Anthony Chavez, vice president of product management for Android Security & Privacy, the proposed tools for the Android mobile operating system would limit the app makers' ability to share a person's information with third parties and prohibit data monitoring across several apps. Google stated the tools would be available in beta by the end of 2022, followed by "scaled testing" in 2023. Chavez said in an interview that the best path forward is an approach “that improves user privacy and a healthy mobile app ecosystem. We need to build new technologies that provide user privacy by default while supporting these key advertising capabilities." 

Google is aiming to strike a balance between the financial needs of developers and marketers and the expanding demands of privacy-conscious consumers and regulators. The company is gathering feedback on the proposal, similar to how its Privacy Sandbox effort is gradually building a new online browsing privacy standard. Google's initial idea was met with derision from UK authorities and lawmakers, but the corporation has subsequently proposed serving adverts based on themes a web user is interested in that are erased and replaced every three weeks. 

Meta Platforms Inc., the parent company of Facebook, has been at odds with Apple over the company's App Monitoring Transparency tool, which allows iPhone users to turn off tracking across all of their apps. According to executives, Google's YouTube has taken a minor financial hit as a result of the technology. In other words, it makes it more difficult for marketers to verify whether their iPhone advertising was effective. 

According to Chavez, the Android Privacy Sandbox would enable tailored advertising based on recent "topics" of interest, and enable attribution reporting, which will tell marketers if their ad was effective.

Due to Security Reasons, Chrome will Limit Access to Private Networks

 

Google has announced that its Chrome browser will soon ban websites from querying and interacting with devices and servers inside local private networks, due to security concerns and past abuse from malware. 

The transition will occur as a result of the deployment of a new W3C specification known as Private Network Access (PNA), which will be released in the first half of the year. The new PNA specification introduces a feature to the Chrome browser that allows websites to request permission from computers on local networks before creating a connection.

“Chrome will start sending a CORS preflight request ahead of any private network request for a subresource, which asks for explicit permission from the target server. This preflight request will carry a new header, Access-Control-Request-Private-Network: true, and the response to it must carry a corresponding header, Access-Control-Allow-Private-Network: true,” as perEiji Kitamura and Titouan Rigoudy, Google. 

Internet websites will be prohibited from connecting if local hardware such as servers or routers fails to respond. One of the most important security features incorporated into Chrome in recent years is the new PNA specification. 

Cybercriminals have known since the early 2010s that they can utilize browsers as a "proxy" to relay connections to a company's internal network. For example, malicious code on a website could attempt to reach an IP address such as 192.168.0.1, which is the standard address for most router administrative panels and is only reachable from a local network. 

When users visit a fraudulent site like this, their browser can issue an automatic request to their network without their permission, transmitting malicious code that can evade router authentication and change router settings. 

These types of attacks aren't simply theoretical; they've happened previously, as evidenced by the examples provided here and here. Other local systems, such as internal servers, domain controllers, firewalls, or even locally-hosted apps (through the http://localhost domain or other locally-defined domains), could be targeted by variations of these internet-to-local network attacks. Google aims to prevent such automated attacks by incorporating the PNA specification into Chrome and its permission negotiation system. 

According to Google, PNA was included in Chrome 96, which was published in November 2021, but complete support will be available in two parts this year, with Chrome 98 (early March) and Chrome 101 (late May).

Doxy.me is Resolving a Data Leak that Exposed Patient Information to Facebook and Google

 

Doxy.me, a telehealth platform, is correcting an issue that allowed three third-party firms to obtain the names of some patients' providers. After examining the platform, privacy researcher Zach Edwards discovered that the company, which self-reports as having 30% of the growing US telemedicine market and is currently used by over 1 million providers worldwide, appeared to be sharing IP addresses and unique device identification numbers with Google, Facebook, and the marketing software company HubSpot. 

When patients clicked on a link to the platform's "virtual waiting room" service, which connects patients with medical professionals, the sensitive user data became available. According to Edwards, Doxy.me appears to have attempted to remove the doctor name from URLs given to third parties, but the three companies used particular technical loopholes to obtain the complete URL, which included the doctor names. There was no breach of patient health information.

Working with third parties like Google and Facebook to maximize data analytics and marketing poses dangers that are distinct from encrypting patient sessions or requiring strong passwords for Doxy.me. Regulators and lawmakers have shown a desire to address the privacy concerns raised by telehealth apps. In September, the Federal Trade Commission issued guidelines that would punish health applications for failing to tell consumers about the sharing of personal information without their permission. 

“As soon as you start sharing data, networks, there are some things that are out of your control and much of the responsibility here is on the ad networks themselves,” said Rykov, of the Mozilla Foundation. “They operate like a black box, we don’t really know what their algorithm is doing and what they’re capable of.” 

The problem raises broader concerns about data security in the telehealth industry. Google and Facebook use metadata gathered from throughout the web to categorize people into "audiences." Companies employ metadata collected across websites to construct audience groups, sometimes known as "lookalike" or "similar" audiences, to assist advertising customers target audiences they are attempting to reach. A marketing customer can then utilize this technique to increase the size of its own audience list. 

Such data sharing puts users in danger of being inadvertently grouped with other patients by Google and Facebook's advertising platforms, potentially providing sensitive information about a patient's condition to the companies' algorithms. Advertisers could therefore target individuals with adverts that were personalised to their specific medical issues.

Due to a Vulnerability in the TLD Registrar's Website, Attackers May Have Modified the Nameservers

 

Due to a vulnerability in the TLD registrar's website, attackers may have changed the name-servers of any domain under Tonga's country code top-level domain (ccTLD), according to security researchers. With approximately 513 million results from a Google search for '.to' pages, the weakness provided potential miscreants with a plethora of potential targets for a variety of large-scale attacks. The Tonga Network Information Center (Tonic) was "extremely quick" in resolving the bug in under 24 hours after online security firm Palisade exposed the issue, following a pen test, on October 8, 2021, according to a Palisade blog post. 

Sam Curry and other Palisade researchers uncovered an SQL injection vulnerability on the registrant website, which could be used to gain plaintext DNS master passwords for.to domains. Once signed in, they may modify the DNS settings for these domains and redirect traffic to their own website. According to Curry, the attacker might then steal cookies and local browser storage and therefore access victim sessions, among other assaults. 

An attacker may send crafted accounts if they gained control of google.to, an official Google domain for redirects and OAuth authorization processes. OAuth is a popular authorization mechanism that allows websites and web applications to request limited access to another application's user account. Importantly, OAuth enables the user to authorize this access without revealing their login credentials to the requesting application. This implies that instead of handing over complete control of their account to a third party, users can fine-tune which data they want to disclose. 

The fundamental OAuth protocol is extensively used to integrate third-party functionality that requires access to certain data from a user's account. For example, an application may utilise OAuth to request access to your email contacts list in order to recommend individuals to connect with. The same approach, however, is also used to enable third-party authentication services, allowing users to log in with an account they have with another website. 

As with .io, .to domains are extensively used to generate short links that are used to reset user passwords, for affiliate marketing, and to drive users to company resources. Curry argued that link shortening services used by Amazon (amzn.to), Uber (ubr.to), and Verizon (vz.to) may have been misused by altering the '.to' pages to which these giant brands' tweets connected for their millions of Twitter followers. 

Curry speculated that attackers "could likely steal a very big amount of money" from customers of tether.to, the official platform for purchasing Tether stable coin - even if they "only owned this domain for a short period of time." However, Eric Gullichsen, administrator of the.to ccTLD, stated that “various security and monitoring and throttling systems we already had in place would have defeated many of the exploits used during the pen test, had the security researchers’ IP addresses not been whitelisted to enable their testing.”

Google: Cryptocurrency Miners are Targeting Compromised Cloud Accounts

 

Google has warned that cryptocurrency miners are using hacked Google Cloud accounts for computationally intensive mining.

Details were disclosed by Google's cybersecurity team in a study published on Wednesday. The "Threat Horizons" study seeks to give intelligence that will assist firms in keeping their cloud systems safe. 

Google wrote in an executive summary of the report, “Malicious actors were observed performing cryptocurrency mining within compromised Cloud instances.” 

Cryptocurrency mining is a for-profit industry that frequently necessitates enormous quantities of computational power, which Google Cloud users may purchase. Google Cloud is a cloud-based storage technology that allows consumers to store data and files off-site. 

As per Google, 86 per cent of the 50 newly hacked Google Cloud accounts were used to mine cryptocurrencies. Bitcoin mining software was downloaded in the majority of cases within 22 seconds of the account being hacked. Around 10% of the affected accounts were also used to perform scans of other publicly available resources on the internet in order to locate susceptible systems, while the remaining 8% were utilised to attack new targets. 

According to Google, malicious actors were able to get access to Google Cloud accounts by exploiting inadequate consumer security procedures. Almost half of the compromised accounts were the result of criminals acquiring access to an internet-facing Cloud account that had either no password or had been hacked. 

As a result, these Google Cloud accounts were vulnerable to being scanned and brute-forced. A quarter of the compromised accounts were the result of flaws in third-party software installed by the owner. Bitcoin, the world's most popular cryptocurrency, has been criticized for consuming excessive amounts of energy. Bitcoin mining consumes more energy than several countries. When authorities investigated a suspected cannabis farm in May, they discovered it was actually an illegal bitcoin mine. 

“The cloud threat landscape in 2021 was more complex than just rogue cryptocurrency miners, of course,” wrote Bob Mechler, director of the office of the chief information security officer at Google Cloud, and Seth Rosenblatt, security editor at Google Cloud, in a blog post. 

They also stated that Google researchers discovered a phishing attack by the Russian group APT28/Fancy Bear at the end of September and that Google stopped the attack. Google researchers also discovered a North Korean government-backed threat organisation that impersonated Samsung recruiters in order to deliver harmful attachments to the staff at various South Korean anti-malware protection firms, they noted.

Hackers Exploit macOS Zero-Day Vulnerability: Google Warns

 

Google's Threat Analysis Group (TAG) determined that cybercriminals targeting visitors to Hong Kong websites potentially have been exploiting a previously unreported zero-day issue in macOS to record keystrokes and screen captures. Apple patched the problem, known as CVE-2021-30869, in September, around a month after Google researchers identified it. Apple indicated that it was made aware of claims that a bug vulnerability was in the wild and that a malicious program might utilize it to run arbitrary code with kernel privileges. 

Google has also disclosed further details, stating that this was a "watering hole" assault, in which attackers choose websites to hack based on the characteristics of usual users. The cyberattacks were aimed at Mac and iPhone users. 

"A malicious application may be able to execute arbitrary code with kernel privileges. Apple is aware of reports that an exploit for this issue exists in the wild," Apple said, crediting Google TAG researchers with reporting of the flaw. 

The watering hole exploited an unpatched XNU privilege escalation vulnerability in macOS Catalina at the time, resulting in the installation of a backdoor. 

"The websites leveraged for the attacks contained two iframes which served exploits from an attacker-controlled server -- one for iOS and the other for macOS," said Erye Hernandez of Google TAG. 

"We believe this threat actor to be a well-resourced group, likely state-backed, with access to their own software engineering team based on the quality of the payload code," he added. 

The criminals used the earlier revealed XNU flaw, CVE-2020-27932, and an associated exploit to build an escalation of privilege problem that granted them root privileges on a targeted Mac. And once attackers got root privileges, they downloaded a payload that operated silently in the backdrop on affected Macs. According to Google TAG, the malware's architecture signals a well-resourced attacker. 

"The payload seems to be a product of extensive software engineering. It uses a publish-subscribe model via a Data Distribution Service (DDS) framework for communicating with the C2. It also has several components, some of which appear to be configured as modules," notes Hernandez. 

The backdoor had the typical suspicious characteristics of malware designed to spy on a victim, such as device fingerprinting, screengrabs, the capacity to upload and download data, and the ability to implement terminal instructions. In addition, the spyware can record audio and track keystrokes. Google did not reveal the websites that were targeted but did mention that they included a "media outlet and a prominent pro-democracy labor and political group" relating to Hong Kong news.

This New Tool Helps in Detecting Vulnerable Chrome Extensions

 

The researchers from CISPA Helmholtz Center for Information Security in Germany have built tools to assist in identifying Chrome extensions that are vulnerable to exploitation by malicious web pages and other extensions. 

Google revealed plans to revamp its browser extension platform in 2018 in order to make it more safe. Chrome extensions had vast rights under its prior platform regulations, known as Manifest v2, which could be easily abused. Many crooks have taken use of these powers. Google, for example, eliminated over 500 harmful extensions in February 2020. That was a month after Google barred new extensions from its Chrome Web Store in order to combat payment fraud. 

Along with its attempts to tidy up the Chrome Web Store, Google has been working on Manifest v3, a redesigned set of extension APIs that offer less features, at the cost of content blocking and privacy tools, but with reduced security and privacy risks. In January 2021, Google began accepting Manifest v3 extensions for evaluation. However, its most recent extensions are not without flaws, and earlier Manifest v2 extensions still continue to circulate.

CISPA Helmholtz boffins Aurore Fass, Dolière Francis Somé, Michael Backes, and Ben Stock took it upon themselves to create a tool termed DoubleX to assist in coping with the problem. They highlight their research in the paper termed "DoubleX: Statically Detecting Vulnerable Data Flows in Browser Extensions at Scale," which is published in the Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, which will be held next week in South Korea. 

They stated that malicious extensions are only a small part of the extensions that cause security and privacy issues. Furthermore, benign extensions may include vulnerable code that may be abused by other extensions installed by the user. DoubleX is on the lookout for extensions that aren't harmful but can be exploited. 

DoubleX is a open-source static analyzer that detects potentially dangerous data flows. In other words, it doesn't simply hunt for malicious extensions; it also looks for exploitable data pathways. 

 How might these flaws be exploited?

According to the researchers, the presence of an eval function indicates that an attacker might possibly exploit the permissions of the vulnerable extension. When DoubleX was fed a considerable number of Chrome apps, it did discover some issues, but they were comparatively less. 

The paper stated, "We analyzed 154,484 Chrome extensions, 278 of which we flagged as having externally controllable data flows or exfiltrating sensitive user information. For those, we could verify that 89 per cent of the data flows can be influenced by an attacker, which highlights DoubleX precision." 

"In addition, we detected 184 extensions (with 209 vulnerabilities) that are exploitable under our threat model, leading to, e.g., arbitrary code execution in any website." 

Around 2.4 million to 2.9 million people are affected by these 184 extensions, with 172 vulnerable to a web attacker and 12 vulnerable through another unprivileged extension. The researchers claim they duly notified their results to developers if they could discover contact information, and to Google in other cases, from October 2020 to May 2021. According to them, 45 of the 48 vulnerable extensions discovered were still available in the Chrome Web Store as of July 2021. 

The paper stated, "Of those, 13 have been updated since our disclosure, but only five have been fixed (300k+ users, 50k+ users, 3k+ users, 2k+ users, and 35 users)."

Netlab 360 Research: namesilo's Parking Pages And Google's Custom Pages Are Abused to Spread Malware

 

Netlab 360 has discovered a suspicious GoELFsample, which is a downloader used mostly to propagate mining malware. The fascinating thing is that their team discovered it while they were spreading the sample and settings using namesilo's Parking page and Google's user-defined page. This appears to be just another effort to obscure the control channel to escape being tracked, monitored, and blocked by the malicious attacker, and it has most likely served them effectively. 

Tencent's security team also revealed an identical sample, however, the study of the spread isn't entirely accurate. The information shown on the website is commonly assumed to be handled by the domain parking provider during the domain parking time (Domain Parking), as well as the actual owner of the domain cannot edit the content of the page. Therefore in this scenario, the domain parking service allows the domain owner to personalize the parking page. The attacker used this, as well as the bespoke sites are given by Google, to distribute the virus. 

This would have two significant advantages: on one hand, the intruder incurs few bandwidth and server costs for the allocation of malicious programs; on the other hand, because the bots 'talk' to the domain parking provider and Google, the control traffic completely merges in, making it extremely difficult to supervise and block. According to Netlab's DNSMon/DTA monitoring data, this new tendency has indeed been escalating in recent months. 

The mining aspect isn't especially fascinating, but researchers did observe that the DNS resolution of www.hellomeyou.cyou has traditionally been CNAME to a parking domain parking.namesilo.com. Parking domains are often registered but never active. 

By logging into namesilo's user service interface, researchers discovered that its ParkingPage has user-definable material, that allows hacker groups to abuse it. Multiple historical screenshots of the site in their DNSMon system revealed that the page's title was indeed a harmful sample link and the page's description was xmrig configuration. 

Simultaneously, there is also the abuse of GitHub and Google links in the description, which additional investigation reveals is also a component of the virus dissemination route. Among these is a base64 encoded xmrig mining program on Google's custom website. 

Netlab 360 notes that: “In this case, it is different. This particular case uses the ‘user-customize’ parking page directly for its control channel. Hackers do not need to have their own machines and IPs, they just use the parked pages provided by the domain registrar, as well as the custom pages of google(see the following snapshot) to help spreading their malware. By doing this, the malicious actor totally goes under the radar because all the control channel traffic uses these totally legit ‘public facilities’.”