Category: security

The vulnerability impacts four Small Business RV Series models, namely the RV110W Wireless-N VPN Firewall, the RV130 VPN Router, the RV130W Wireless-N Multifunction VPN Router, and the RV215W Wireless-N VPN Router. This vulnerability only affects devices with the web-based remote management interface enabled on WAN connections. […] Cisco states that they will not be releasing a security update to address CVE-2022-20825 as the devices are no longer supported. Furthermore, there are no mitigations available other than to turn off remote management on the WAN interface, which should be done regardless for better overall security. Users are advised to apply the configuration changes until they migrate to Cisco Small Business RV132W, RV160, or RV160W Routers, which the vendor actively supports.

“Upon gaining an initial foothold into a telecommunications organization or network service provider, PRC state-sponsored cyber actors have identified critical users and infrastructure including systems critical to maintaining the security of authentication, authorization, and accounting,” the advisory explains. The attackers then stole credentials to access underlying SQL databases and used SQL commands to dump user and admin credentials from critical Remote Authentication Dial-In User Service (RADIUS) servers.

“Armed with valid accounts and credentials from the compromised RADIUS server and the router configurations, the cyber actors returned to the network and used their access and knowledge to successfully authenticate and execute router commands to surreptitiously route, capture, and exfiltrate traffic out of the network to actor-controlled infrastructure,” the federal agencies added. The three federal agencies said the following common vulnerabilities and exposures (CVEs) are the network device CVEs most frequently exploited by Chinese-backed state hackers since 2020. “The PRC has been exploiting specific techniques and common vulnerabilities since 2020 to use to their advantage in cyber campaigns,” the NSA added. Organizations can protect their networks by applying security patches as soon as possible, disabling unnecessary ports and protocols to shrink their attack surface, and replacing end-of-life network infrastructure that no longer receives security patches.

The agencies “also recommend networks to block lateral movement attempts and enabling robust logging and internet-exposed services to detect attack attempts as soon as possible,” adds BleepingComputer.

Over the next few months, multiple BMC vendors issued patches and advisories that told customers why patching the vulnerability was critical. Now, researchers from security firm Eclypsium reported a disturbing finding: for reasons that remain unanswered, a widely used BMC from data center solutions provider Quanta Cloud Technology, better known as QCT, remained unpatched against the vulnerability as recently as last month. As if QCT’s inaction wasn’t enough, the company’s current posture also remains baffling. After Eclypsium privately reported its findings to QCT, the solutions company responded that it had finally fixed the vulnerability. But rather than publish an advisory and make a patch public — as just about every company does when fixing a critical vulnerability — it told Eclypsium it was providing updates privately on a customer-by-customer basis. As this post was about to go live, “CVE-2019-6260,” the industry’s designation to track the vulnerability, didn’t appear on QCT’s website. […] “[T]hese types of attacks have remained possible on BMCs that were using firmware QCT provided as recently as last month,” writes Ars’ Dan Goodin in closing. “QCT’s decision not to publish a patched version of its firmware or even an advisory, coupled with the radio silence with reporters asking legitimate questions, should be a red flag. Data centers or data center customers working with this company’s BMCs should verify their firmware’s integrity or contact QCT’s support team for more information.”

Two of the vulnerabilities — tracked as CVE-2021-3971 and CVE-2021-3972 — reside in UEFI firmware drivers intended for use only during the manufacturing process of Lenovo consumer notebooks. Lenovo engineers inadvertently included the drivers in the production BIOS images without being properly deactivated. Hackers can exploit these buggy drivers to disable protections, including UEFI secure boot, BIOS control register bits, and protected range register, which are baked into the serial peripheral interface (SPI) and designed to prevent unauthorized changes to the firmware it runs. After discovering and analyzing the vulnerabilities, researchers from security firm ESET found a third vulnerability, CVE-2021-3970. It allows hackers to run malicious firmware when a machine is put into system management mode, a high-privilege operating mode typically used by hardware manufacturers for low-level system management. “All three of the Lenovo vulnerabilities discovered by ESET require local access, meaning that the attacker must already have control over the vulnerable machine with unfettered privileges,” notes Ars Technica’s Dan Goodin. “The bar for that kind of access is high and would likely require exploiting one or more critical other vulnerabilities elsewhere that would already put a user at considerable risk.”

Still, it’s worth looking to see if you have an affected model and, if so, patch your computer as soon as possible.

We do not believe the attacker obtained these tokens via a compromise of GitHub or its systems, because the tokens in question are not stored by GitHub in their original, usable formats. Following immediate investigation, we disclosed our findings to Heroku and Travis-CI on April 13 and 14…

Looking across the entire GitHub platform, we have high confidence that compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps. Our analysis of other behavior by the threat actor suggests that the actors may be mining the downloaded private repository contents, to which the stolen OAuth token had access, for secrets that could be used to pivot into other infrastructure.

We are sharing this today as we believe the attacks may be ongoing and action is required for customers to protect themselves.

The initial detection related to this campaign occurred on April 12 when GitHub Security identified unauthorized access to our npm production infrastructure using a compromised AWS API key. Based on subsequent analysis, we believe this API key was obtained by the attacker when they downloaded a set of private npm repositories using a stolen OAuth token from one of the two affected third-party OAuth applications described above. Upon discovering the broader theft of third-party OAuth tokens not stored by GitHub or npm on the evening of April 13, we immediately took action to protect GitHub and npm by revoking tokens associated with GitHub and npm’s internal use of these compromised applications.

We believe that the two impacts to npm are unauthorized access to, and downloading of, the private repositories in the npm organization on GitHub.com and potential access to the npm packages as they exist in AWS S3 storage.

At this point, we assess that the attacker did not modify any packages or gain access to any user account data or credentials. We are still working to understand whether the attacker viewed or downloaded private packages.

npm uses completely separate infrastructure from GitHub.com; GitHub was not affected in this original attack. Though investigation continues, we have found no evidence that other GitHub-owned private repos were cloned by the attacker using stolen third-party OAuth tokens.

Once GitHub identified stolen third-party OAuth tokens affecting GitHub users, GitHub took immediate steps to respond and protect users. GitHub contacted Heroku and Travis-CI to request that they initiate their own security investigations, revoke all OAuth user tokens associated with the affected applications, and begin work to notify their own users…. GitHub is currently working to identify and notify all of the known-affected victim users and organizations that we discovered through our analysis across GitHub.com. These customers will receive a notification email from GitHub with additional details and next steps to assist in their own response within the next 72 hours.
If you do not receive a notification, you and/or your organization have not been identified as affected.

You should, however, periodically review what OAuth applications you’ve authorized or are authorized to access your organization and prune anything that’s no longer needed.
You can also review your organization audit logs and user account security logs for unexpected or anomalous activity….

The security and trustworthiness of GitHub, npm, and the broader developer ecosystem is our highest priority. Our investigation is ongoing, and we will update this blog, and our communications with affected customers, as we learn more.

While the method is convincing, it has a few weaknesses that should give savvy visitors a foolproof way to detect that something is amiss. Genuine OAuth or payment windows are in fact separate browser instances that are distinct from the primary page. That means a user can resize them and move them anywhere on the monitor, including outside the primary window. BitB windows, by contrast, aren’t a separate browser instance at all. Instead, they’re images rendered by custom HTML and CSS and contained in the primary window. That means the fake pages can’t be resized, fully maximized or dragged outside the primary window. All users should protect their accounts with two-factor authentication. One other thing more experienced users can do is right click on the popup page and choose “inspect.” If the window is a BitB spawn, its URL will be hardcoded into the HTML.

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It’s listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, “This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat.” So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn’t available yet in all distribution releases.

While analyzing the PE header of a malware sample discovered on the network of an undisclosed Ukrainian organization, it was also discovered that the malware was deployed in attacks the same day it was compiled. “CaddyWiper does not share any significant code similarity with HermeticWiper, IsaacWiper, or any other malware known to us. The sample we analyzed was not digitally signed,” ESET added. “Similarly to HermeticWiper deployments, we observed CaddyWiper being deployed via GPO, indicating the attackers had prior control of the target’s network beforehand.”

BleepingComputer found that the VuxnerChat.exe download [VirusTotal] actually installs the “Trillian” messaging app and then downloads further malware onto the computer after Trillian finishes installing. As this type of campaign looked similar to other campaigns that have pushed remote access and password-stealing trojans in the past, BleepingComputer reached out to cybersecurity firm Cluster25 who has previously helped BleepingComputer diagnose similar malware attacks in the past. Cluster25 researchers explain in a report coordinated with BleepingComputer that the Vuxner[.]com is hosted behind Cloudflare, however they could still determine hosting server’s actual address at 86.104.15[.]123.

The researchers state that the Vuxner Chat program is being used as a decoy for installing a remote desktop software known as RuRAT, which is used as a remote access trojan. Once a user installs the Vuxner Trillian client and exits the installer, it will download and execute a Setup.exe executable [VirusTotal] from https://vuxner[.]com/setup.exe. When done, the victim will be left with a C:swrbldin folder filled with a variety of batch files, VBS scripts, and other files used to install RuRAT on the device. Cluster25 told BleepingComputer that the threat actors are using this attack to gain initial access to a device and then take control over the host. Once they control the host, they can search for credentials and sensitive data or use the device as a launchpad to spread laterally in a network.