Cisco IOS XR Software Health Check Open Port Vulnerability

MediumAdvisory ID:cisco-sa-iosxr-redis-ABJyE5xK
First Published:2022 May 20 16:00 GMT
Version 1.0:Final
Workarounds:Yes
Cisco Bug IDs:CSCwb82689
CVSS Score:Base 6.5
CVE-2022-20821CWE-200 Download CVRFEmail

Summary

  • A vulnerability in the health check RPM of Cisco IOS XR Software could allow an unauthenticated, remote attacker to access the Redis instance that is running within the NOSi container.This vulnerability exists because the health check RPM opens TCP port 6379 by default upon activation. An attacker could exploit this vulnerability by connecting to the Redis instance on the open port. A successful exploit could allow the attacker to write to the Redis in-memory database, write arbitrary files to the container filesystem, and retrieve information about the Redis database. Given the configuration of the sandboxed container that the Redis instance runs in, a remote attacker would be unable to execute remote code or abuse the integrity of the Cisco IOS XR Software host system.Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.This advisory is available at the following link:
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-redis-ABJyE5xK

Affected Products

  • Vulnerable ProductsAt the time of publication, this vulnerability affected Cisco 8000 Series Routers if they were running a vulnerable release of Cisco IOS XR Software and had the health check RPM installed and active.For information about which Cisco software releases were vulnerable at the time of publication, see the Fixed Software section of this advisory. See the Details section in the bug ID(s) at the top of this advisory for the most complete and current information.Determine the Device ConfigurationTo determine if the device is in a vulnerable state, issue the run docker ps CLI command. If the output returns a docker container with the name NOSi, as shown in the following example, the device is considered vulnerable:RP/0/RP0/CPU0:8000#run docker ps Wed May 18 04:54:52.502 UTC CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 54307e434f29 nosi:latest “docker-entrypoint.s…” 9 seconds ago Up 8 seconds NOSi RP/0/RP0/CPU0:8000#Products Confirmed Not VulnerableOnly products listed in the Vulnerable Products section of this advisory are known to be affected by this vulnerability.

Workarounds

  • There are workarounds that address this vulnerability:Option 1: This is the preferred method. Disable health check and explicitly disable the use cases.To effectively disable health check, enter the following commands exactly as shown:RP/0/RP0/CPU0:8000(config)#no healthcheck enable
    RP/0/RP0/CPU0:8000(config)#healthcheck use-case asic-reset disable
    RP/0/RP0/CPU0:8000(config)#healthcheck use-case packet-drop disable
    RP/0/RP0/CPU0:8000(config)#commit
    RP/0/RP0/CPU0:8000#Then remove the health check RPM from the device:RP/0/RP0/CPU0:8000#install package remove xr-healthcheck
    Wed May 18 05:00:08.060 UTCInstall remove operation 5.2.2 has started
    Install operation will continue in the background
    RP/0/RP0/CPU0:8000#
    RP/0/RP0/CPU0:8000#install apply restart
    Wed May 18 05:01:08.842 UTC
    Install apply operation 5.2 has started
    Install operation will continue in the background
    RP/0/RP0/CPU0:8000#Option 2: Use an Infrastructure Access Control List (iACLs) to block port 6379.To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure access control lists (iACLs) to perform policy enforcement of traffic sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. For the maximum protection of infrastructure devices, deployed iACLs should be applied in the ingress direction on all interfaces to which an IP address has been configured. An iACL workaround cannot provide complete protection against this vulnerability when the attack originates from a trusted source address.The iACL policy denies unauthorized Redis communications packets on TCP port 6379 that are sent to affected devices. In the following example, 192.168.60.0/24 is the IP address space that is used by the affected devices. Care should be taken to allow required traffic for routing and administrative access before denying all unauthorized traffic. Whenever possible, infrastructure address space should be distinct from the address space used for user and services segments. Using this addressing methodology will assist with the construction and deployment of iACLs. ipv4 access-list Infrastructure-ACL-Policy ! !– The following vulnerability-specific access control entries !– (ACEs) can drop Redis Database communication packets ! deny tcp any 192.168.60.0 0.0.0.255 eq 6379 ! !– Explicit deny ACE for traffic sent to addresses configured !– within the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !– Permit or deny all other Layer 3 and Layer 4 traffic in !– accordance with existing security policies and configurations ! !– Apply iACL to interfaces in the ingress direction
    ! interface GigabitEthernet0/0 ipv4 access-group Infrastructure-ACL-Policy in

    For additional information about iACLs, see Protecting Your Core: Infrastructure Protection Access Control Lists.While these workarounds have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.

Fixed Software

  • When considering software upgrades, customers are advised to regularly consult the advisories for Cisco products, which are available from the Cisco Security Advisories page, to determine exposure and a complete upgrade solution.In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.Fixed ReleasesAt the time of publication, the release information in the following table(s) was accurate. See the Details section in the bug ID(s) at the top of this advisory for the most complete and current information.Cisco IOS XR ReleaseFirst Fixed Release7.2 and earlierNot affected7.3.15, 7.3.16, 7.3.1, and 7.3.2Not affected7.3.37.3.417.4Not affected7.5.1Not affected7.5.2Not affected7.6Not affected1. An SMU is also planned for 7.3.3.The Cisco Product Security Incident Response Team (PSIRT) validates only the affected and fixed release information that is documented in this advisory.

Exploitation and Public Announcements

  • In May 2022, the Cisco PSIRT became aware of attempted exploitation of this vulnerability in the wild. Cisco strongly recommends that customers apply suitable workaround or upgrade to a fixed software release to remediate this vulnerability.

Source

  • This vulnerability was found during the resolution of a Cisco TAC support case.

URL

Revision History

  • VersionDescriptionSectionStatusDate1.0Initial public release.-Final2022-MAY-20

    Source :
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-redis-ABJyE5xK

VMware Releases Patches for New Vulnerabilities Affecting Multiple Products

VMware has issued patches to contain two security flaws impacting Workspace ONE Access, Identity Manager, and vRealize Automation that could be exploited to backdoor enterprise networks.

The first of the two flaws, tracked as CVE-2022-22972 (CVSS score: 9.8), concerns an authentication bypass that could enable an actor with network access to the UI to gain administrative access without prior authentication.

CVE-2022-22973 (CVSS score: 7.8), the other bug, is a case of local privilege escalation that could enable an attacker with local access to elevate privileges to the “root” user on vulnerable virtual appliances.

“It is extremely important that you quickly take steps to patch or mitigate these issues in on-premises deployments,” VMware said.

The disclosure follows a warning from the U.S. Cybersecurity and Infrastructure Agency (CISA) that advanced persistent threat (APT) groups are exploiting CVE-2022-22954 and CVE-2022-22960 — two other VMware flaws that were fixed early last month — separately and in combination.

“An unauthenticated actor with network access to the web interface leveraged CVE-2022-22954 to execute an arbitrary shell command as a VMware user,” it said. “The actor then exploited CVE-2022-22960 to escalate the user’s privileges to root. With root access, the actor could wipe logs, escalate permissions, and move laterally to other systems.”

On top of that, the cybersecurity authority noted that threat actors have deployed post-exploitation tools such as the Dingo J-spy web shell in at least three different organizations.

IT security company Barracuda Networks, in an independent report, said it has observed consistent probing attempts in the wild for CVE-2022-22954 and CVE-2022-22960 soon after the shortcomings became public knowledge on April 6.

More than three-fourths of the attacker IPs, about 76%, are said to have originated from the U.S., followed by the U.K. (6%), Russia (6%), Australia (5%), India (2%), Denmark (1%), and France (1%).

Some of the exploitation attempts recorded by the company involve botnet operators, with the threat actors leveraging the flaws to deploy variants of the Mirai distributed denial-of-service (DDoS) malware.

The issues have also prompted CISA to issue an emergency directive urging federal civilian executive branch (FCEB) agencies to apply the updates by 5 p.m. EDT on May 23 or disconnect the devices from their networks.

“CISA expects threat actors to quickly develop a capability to exploit these newly released vulnerabilities in the same impacted VMware products,” the agency said.

The patches arrive a little over a month after the company rolled out an update to resolve a critical security flaw in its Cloud Director product (CVE-2022-22966) that could be weaponized to launch remote code execution attacks.

CISA warns of active exploitation of F5 BIG-IP CVE-2022-1388

It’s not just VMware that’s under fire. The agency has also released a follow-up advisory with regards to the active exploitation of CVE-2022-1388 (CVSS score: 9.8), a recently disclosed remote code execution flaw affecting BIG-IP devices.

CISA said it expects to “see widespread exploitation of unpatched F5 BIG-IP devices (mostly with publicly exposed management ports or self IPs) in both government and private sector networks.”

Source :
https://thehackernews.com/2022/05/vmware-releases-patches-for-new.html

Millions of Attacks Target Tatsu Builder Plugin

The Wordfence Threat Intelligence team has been tracking a large-scale attack against a Remote Code Execution vulnerability in Tatsu Builder, which is tracked by CVE-2021-25094 and was publicly disclosed on March 24, 2022 by an independent security researcher. The issue is present in vulnerable versions of both the free and premium Tatsu Builder plugin. Tatsu Builder is a proprietary plugin that is not listed on the WordPress.org repository, so reliable installation counts are not available, but we estimate that the plugin has between 20,000 and 50,000 installations. Tatsu sent an urgent email notification to all of their customers on April 7th advising them to update, but we estimate that at least a quarter of remaining installations are still vulnerable.

All Wordfence users with the Wordfence Web Application Firewall active, including Wordfence free customers, are protected against attackers trying to exploit this vulnerability.

We began seeing attacks on May 10, 2022. The attacks are ongoing with the volume ramping up to a peak of 5.9 million attacks against 1.4 million sites on May 14, 2022. The attack volume has declined but the attacks are still ongoing at the time of publication.

The following is a graph showing the total volume of attacks targeting the vulnerability in Tatsu Builder.

Graph showing attack volume against CVE-2021-25094

While the following is a graph showing the total number of sites being targeted by attackers trying to exploit the vulnerability in Tatsu Builder.


Description: Unauthenticated Remote Code Execution
Affected Plugin: Tatsu Builder
Plugin Slug: tatsu
Plugin Developer: BrandExponents
Affected Versions: < 3.3.13
CVE ID:CVE-2021-25094
CVSS Score: 8.1 (High)
CVSS Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Researcher/s: Vincent Michel (darkpills)
Fully Patched Version: 3.3.13

Indicators of Attack

Most of the attacks we have seen are probing attacks to determine the presence of a vulnerable plugin. These may appear in your logs with the following query string:

/wp-admin/admin-ajax.php?action=add_custom_font

The vast majority of attacks are the work of just a few IP addresses.

The top 3 attacking IPs have each attacked over 1 million sites:

148.251.183.254
176.9.117.218
217.160.145.62

An additional 15 IPs have each attacked over 100,000 sites:

65.108.104.19
62.197.136.102
51.38.41.15
31.210.20.170
31.210.20.101
85.202.169.175
85.202.169.71
85.202.169.86
85.202.169.36
85.202.169.83
85.202.169.92
194.233.87.7
2.56.56.203
85.202.169.129
135.181.0.188

Indicators of Compromise

The most common payload we’ve seen is a dropper used to place additional malware located in a randomly-named subfolder of wp-content/uploads/typehub/custom/ such as wp-content/uploads/typehub/custom/vjxfvzcd.

The dropper is typically named .sp3ctra_XO.php and has an MD5 hash of 3708363c5b7bf582f8477b1c82c8cbf8.

Note the dot at the beginning as this indicates a hidden file, which is necessary to exploit the vulnerability as it takes advantage of a race condition.

This file is detected by the Wordfence scanner.

What Should I Do?

All Wordfence users with the Wordfence Web Application Firewall active, including Wordfence free customers, are protected against this vulnerability. Nonetheless, if you use the Tatsu Builder plugin, we strongly recommend updating to the latest version available, which is 3.3.13 at the time of this writing. Please note that version 3.3.12 contained a partial patch but did not fully address all issues.

If you know anyone using the Tatsu Builder plugin on their site, we urge you to forward this article to them as this is a large-scale attack and any vulnerable sites that are not updated and not using some form of a Web Application Firewall are at risk of complete site takeover.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

Source :
https://www.wordfence.com/blog/2022/05/millions-of-attacks-target-tatsu-builder-plugin/

Europe Agrees to Adopt New NIS2 Directive Aimed at Hardening Cybersecurity

The European Parliament announced a “provisional agreement” aimed at improving cybersecurity and resilience of both public and private sector entities in the European Union.

The revised directive, called “NIS2” (short for network and information systems), is expected to replace the existing legislation on cybersecurity that was established in July 2016.

The revamp sets ground rules, requiring companies in energy, transport, financial markets, health, and digital infrastructure sectors to adhere to risk management measures and reporting obligations.

Among the provisions in the new legislation are flagging cybersecurity incidents to authorities within 24 hours, patching software vulnerabilities, and readying risk management measures to secure networks, failing which can incur monetary penalties.

“The directive will formally establish the European Cyber Crises Liaison Organization Network, EU-CyCLONe, which will support the coordinated management of large-scale cybersecurity incidents,” the Council of the European Union said in a statement last week.

The development closely follows the European Commission’s plans to “detect, report, block, and remove” child sexual abuse images and videos from online service providers, including messaging apps, prompting concerns that it may undermine end-to-end encryption (E2EE) protections.

The draft version of NIS2 explicitly spells out that the use of E2EE “should be reconciled with the Member States’ powers to ensure the protection of their essential security interests and public security, and to permit the investigation, detection and prosecution of criminal offenses in compliance with Union law.”

It also stressed that “Solutions for lawful access to information in end-to-end encrypted communications should maintain the effectiveness of encryption in protecting privacy and security of communications, while providing an effective response to crime.”

That said, the directive will not apply to organizations in verticals such as defense, national security, public security, law enforcement, judiciary, parliaments, and central banks.

As part of the proposed agreement, the European Union member states are mandated to incorporate the provisions into their national law within a period of 21 months from when the directive goes into force.

“The number, magnitude, sophistication, frequency and impact of cybersecurity incidents are increasing, and present a major threat to the functioning of network and information systems,” the Council noted in the draft.

“Cybersecurity preparedness and effectiveness are therefore now more essential than ever to the proper functioning of the internal market.”

Source :
https://thehackernews.com/2022/05/europe-agrees-to-adopt-new-nis2.html

SonicWall Releases Patches for New Flaws Affecting SSLVPN SMA1000 Devices

SonicWall has published an advisory warning of a trio of security flaws in its Secure Mobile Access (SMA) 1000 appliances, including a high-severity authentication bypass vulnerability.

The weaknesses in question impact SMA 6200, 6210, 7200, 7210, 8000v running firmware versions 12.4.0 and 12.4.1. The list of vulnerabilities is below –

  • CVE-2022-22282 (CVSS score: 8.2) – Unauthenticated Access Control Bypass
  • CVE-2022-1702 (CVSS score: 6.1) – URL redirection to an untrusted site (open redirection)
  • CVE-2022-1701 (CVSS score: 5.7) – Use of a shared and hard-coded cryptographic key

Successful exploitation of the aforementioned bugs could allow an attacker to unauthorized access to internal resources and even redirect potential victims to malicious websites.

Tom Wyatt of the Mimecast Offensive Security Team has been credited with discovering and reporting the vulnerabilities.

SonicWall noted that the flaws do not affect SMA 1000 series running versions earlier than 12.4.0, SMA 100 series, Central Management Servers (CMS), and remote access clients.

SonicWall

Although there is no evidence that these vulnerabilities are being exploited in the wild, it’s recommended that users apply the fixes in the light of the fact that SonicWall appliances have presented an attractive bullseye in the past for ransomware attacks.

“There are no temporary mitigations,” the network security company said. “SonicWall urges impacted customers to implement applicable patches as soon as possible.”

Source :
https://thehackernews.com/2022/05/sonicwall-releases-patches-for-new.html

Enjoy the Speed and Safety of TLS 1.3 Support

SonicWall NGFWs offer full TLS 1.3 support — ensuring your network can handle the latest encryption protocols.

The best products tend to stick around for a while. In the first two years that the Ford Mustang was manufactured, 1965 and 1966, roughly 1.3 million cars rolled off assembly lines in Dearborn, Mich.; Metuchen, N.J.; and Milpitas, Calif. Of those, a remarkable 350,000 are still on the road today — and with proper care, still getting from Point A to Point B just as well as they did during the Johnson Administration.

But aesthetics aside, does that make them a good choice for a daily driver today? In a crash test with any modern vehicle (or a race with any of today’s Mustangs), the first-generation Mustang would be completely overwhelmed. Safety features we take for granted, such as airbags, lane-keep assist, blind spot detection and anti-lock brakes, are absent. These cars might do fine for the occasional Sunday spin around town. But would you put your family in one?

When a product forms the boundary between something precious and grave disaster, you want that product to be as safe as possible. This also holds true for another Milpitas innovation: SonicWall firewalls. To know whether your current choice is still the right choice, it helps to look at what innovations have occurred since then, and whether they were incremental improvements or giant leaps forward. In the case of TLS 1.3 encryption support, it’s unquestionably the latter.

TLS 1.3 is the latest version of transport layer security, which offers reliable encryption for digital communications over the internet. And as with the Mustang before it, modern innovations have led to sizeable leaps in two areas: safety and performance.

TLS 1.3: Safety First

Since the original SSL technology was introduced in 1994, each new version has worked to solve the problems of the previous versions while also maintaining compatibility with those versions. But, unfortunately, maintaining backward compatibility meant leaving in many unnecessary or vulnerable ciphers.

These legacy ciphers made the encryption susceptible to attack, offering attackers a vector through which to circumvent newer security advances in favor of older and weaker protection. A few of the ciphers that persisted up through TLS 1.2 were so weak that they allow an attacker to decrypt the data’s contents without having the key.

TLS 1.3 represents a fundamental shift in this philosophy. Due to a sharp increase in attacks, such as Lucky13, BEAST, POODLE, Logjam and FREAK, which depend on such vulnerabilities for transmission, the Internet Engineering Task Force (IETF) opted to remove these ciphers altogether — and the resulting TLS 1.3 is vastly more secure because of it.

It’s also more private. In previous versions, including 1.2, digital signatures weren’t used to ensure a handshake’s integrity — they only protected the part of the handshake after the cipher-suite negotiation, allowing attackers to manipulate the negotiation and access the entire conversation.

In TLS 1.3, the entire handshake is encrypted, and only the sender and the recipient can decrypt the traffic. This not only makes it virtually impossible for outsiders to eavesdrop on client/server communications and much harder for attackers to launch man-in-the-middle attacks, it also protects existing communications even if future communications are compromised.

TLS 1.3: Safety Fast

With TLS 1.3, the handshake process isn’t just more secure — it’s faster, too. The four-step handshake required with TLS 1.2 necessitated two round-trip exchanges between systems, introducing latency and taking up bandwidth and power.

These slowdowns especially affected the growing class of Internet of Things (IoT) devices, which have trouble handling connections requiring lots of bandwidth or power, but also tend to need encryption most due to weak onboard security.

However, with just a single key exchange and significantly fewer supported ciphers, TLS 1.3 uses considerably less bandwidth. And because it requires just one round trip to complete the handshake, it’s significantly faster. TLS 1.3’s zero round trip time (0-RTT) feature is even quicker: On subsequent visits, it offers a latency time equal to that of unencrypted HTTP.

Is Your Firewall Up to the Task?

Experts estimate that 80-90% of all network traffic today is encrypted. But many legacy firewalls lack the capability or processing power to detect, inspect and mitigate cyberattacks sent via HTTPs traffic at all, let alone using TLS 1.3 — making this a highly successful avenue for hackers to deploy and execute malware.

According to the 2022 SonicWall Cyber Threat Report, from 2020 to 2021, malware sent over HTTPS rose a staggering 167%. All told, SonicWall recorded 10.1 million encrypted attacks in 2021 — almost as many as in 2018, 2019 and 2020 combined.

https://e.infogram.com/e3c6d4f2-5828-4326-8c3d-b5bb992a1321?parent_url=https%3A%2F%2Fblog.sonicwall.com%2Fen-us%2F2022%2F05%2Fenjoy-the-speed-and-safety-of-tls-1-3-support%2F&src=embed#async_embed

With an average of 7% of customers seeing an encrypted attack in a given month, the odds your organization will be targeted by an attack this year are enormous. But if your firewall cannot inspect encrypted traffic — and increasingly, if it cannot inspect TLS 1.3 — you’ll never know it until it’s too late.

SonicWall Supports TLS 1.3 Encryption

SonicWall Gen 7 firewalls bring a lot to the table: They combine higher port density and greater threat throughput with comprehensive malware analysis, unmatched simplicity and industry-leading performance. But among the biggest game-changers in Gen 7 (and its predecessors capable of running SonicOS Gen 6.5) is its support for TLS 1.3 encryption.

SonicWall NGFWs with SonicOS Gen 6.5 and later offer full TLS inspection, decrypting data, checking it for potential threats, and then re-encrypting it for secure transmission — all while ensuring you retain optimal performance and comprehensive visibility.

After all, as in the case of the classic Mustang, there’s no blind spot detection for firewalls that can’t handle today’s encrypted traffic — and these legacy solutions are easily outclassed when going head-to-head. Don’t let yesterday’s firewalls leave unprotected gaps in your network: Upgrade to SonicWall Gen 7 today.

Source :
https://blog.sonicwall.com/en-us/2022/05/enjoy-the-speed-and-safety-of-tls-1-3-support/

Anti-Ransomware Day: What Can We Do to Prevent the Next WannaCry?

This Anti-Ransomware Day, SonicWall looks at how cybersecurity has changed since WannaCry — and what we can do to ensure we never see such a widespread, devastating and preventable attack again.

On May 12, 2017, attackers identified a vulnerability in a Windows device somewhere in Europe — and in the process, set off an attack that would ultimately impact roughly 200,000 victims and over 300,000 endpoints across 150 countries. The devastation wrought by WannaCry caused financial losses of roughly $4 billion before the strain was halted by an unlikely hero just hours later. But perhaps most devastating of all was that it was completely preventable.

To help raise awareness about ransomware strains like WannaCry and the steps needed to combat them, INTERPOL in 2020 teamed up with cybersecurity firm Kaspersky to declare May 12 Anti-Ransomware Day. By taking a few important steps, organizations can help stop the next major ransomware attack, averting the potential for downtime, reputational damage, fines and more.

“Cybercrime and cybersecurity may seem like a complex issue that is difficult to understand unless you are an expert in the field — this is not the case. INTERPOL’s campaign aims to demystify these cyberthreats and offer simple, concrete steps which everybody can take to protect themselves,” INTERPOL’s Director of Cybercrime Craig Jones said.

What’s Changed Since WannaCry?

In the years since the infamous attack, ransomware has continued to grow. In 2021, SonicWall Capture Labs threat researchers recorded 623.3 million ransomware attempts on customers globally. This represents an increase of 105% from 2020’s total and a staggering 232% since 2019.

And while ransomware was a hot topic worldwide due to attacks such as WannaCry and NotPetya, which would begin its own savage trek across the globe just six weeks later, ransomware volume in 2017 was less than a third of what it was in 2021.

Weakened, but Still Wreaking Havoc

While variants such as Ryuk, SamSam and Cerber made up 62% of the ransomware attacks recorded by SonicWall in 2021, WannaCry lives on — and in surprising numbers. By now, five years on, the number of vulnerable Windows systems should be virtually zero. A patch for the EternalBlue vulnerability exploited by WannaCry was released two months prior to the attack, and Microsoft later took the unusual step of also releasing patches for Windows systems that were old and no longer supported.

But in 2020, SonicWall observed 233,000 instances of WannaCry, and in 2021, 100,000 hits were observed — indicating that there are still vulnerable Windows systems in the wild that need to be patched.

We Can Worry … Or Get to Work

What made WannaCry so successful was that many organizations at the time took a set-it-and-forget-it approach to IT, leaving vulnerable hundreds of thousands of endpoints that could otherwise have been patched prior to the attack. But while patching is a crucial part of any cybersecurity strategy, it can’t work alone — there are still a number of other steps organizations need to take to bolster their odds against the next big ransomware attack.

  • Update: Whenever possible, enable automatic updates on applications and devices on your network — both for operating systems and for any other apps in your ecosystem.
  • Upgrade: The older an operating system gets, the more malware and other threats are created to target them. Retire any software or hardware that is obsolete or no longer supported by the vendor.
  • Duplicate: All important data should be backed up to a place inaccessible by attackers. Having adequate and up-to-date backups on hand significantly eases recovery in the event of a ransomware attack.
  • Educate: A staggering 91% of all cyberattacks start with someone opening a phishing email. Teach employees to be wary any time they receive an email, particularly one with an attachment or link.
  • Safeguard: By taking the above steps, most attacks can be prevented, but not all. They’re called “best practices” and not “universal practices” for a reason: If any are allowed to lapse — or new methods are found to circumvent them — organizations will need a strong last line of defense. An advanced, multi-layer platform that includes endpoint security, next-gen firewall services, email security and secure mobile access can work to eliminate blind spots and eradicate both known and unknown threats.

“In the past two years, we have seen how cybercriminals have become bolder in using ransomware. Organizations targeted by such attacks are not limited to corporations and governmental organizations — ransomware operators are ready to hit essentially any business regardless of size,” Jones said. “To fight them, we need to educate ourselves on how they work and fight them as one. Anti-Ransomware Day is a good opportunity to highlight this need and remind the public of how important it is to adopt effective security practices.”

Source :
https://blog.sonicwall.com/en-us/2022/05/anti-ransomware-day-what-can-we-do-to-prevent-the-next-wannacry/

Examining Emerging Backdoors

Next up in our “This didn’t quite make it into the 2021 Threat Report, but is still really cool” series: New backdoors!

Backdoors are a crucial component of a website infection. They allow the attackers ongoing access to the compromised environment and provide them a “foot in the door” to execute their payload. We see many different types of backdoors with varying functionality.

When our malware research team is provided with a new backdoor they need to write what’s called a “signature” to ensure that we detect and remove it in future security scans. Signatures need names, and over the years we’ve developed something of a taxonomy naming system for all of the different malware that we come across.

In this article we’re going to explore all the different categories of signatures for newly-discovered backdoors throughout the year 2021.

How do Backdoors Work?

HTTP requests to websites typically fall into one of the following categories:

  • POST – sending data to a website
  • GET – requesting data from a website
  • COOKIE – data (such as session data) saved from a website
  • REQUEST – a conjunction of all/any of the three

We see all sorts of different backdoors while cleaning up compromised websites. Sometimes they use one of these types of requests, or a combination of multiple different types.

We’ve broken all newly generated signatures from 2021 down for further analysis into the following categories:

A graph showing the distribution of new backdoor signatures generated in 2021.

Uploaders

By far the most common type of backdoor found in 2021 was an uploader: That is, a PHP script that allows the attackers to upload any file that they want. These malicious files allow anyone with the correct URL path, parameters and (occasionally) access credentials to upload whichever files they want to the web server. Typically, bad actors use these backdoors to upload a webshell, spam directory, dropper, or other type of file giving them full control over the environment.

To avoid detection, attackers are always tweaking their malware by using new methods of obfuscation or concealing backdoors within legitimate-looking images, core files, plugins, or even themes — this can make malicious file uploaders difficult to detect during a casual site review.

Once an attacker has identified a vulnerable environment that they can get a foothold in, planting the uploader is often the next step. After that they have enough access to upload more complicated access points such as a webshell.

Of course there are legitimate uploader scripts, as many websites require functionality to allow users to upload photos or other content to the website. To mitigate risk, secure uploader scripts contain strict rules on how they are able to behave:

  • Only certain file types/extensions are allowed (usually image, or document files)
  • May require authorisation cookies to be set
  • May place files in a restricted directory with PHP execution disabled
  • May disable direct access and instead need to be called by the existing CMS structure

Malicious uploaders, on the other hand, have no such restrictions as they are designed to upload malicious files and PHP scripts.

A malicious uploader script

WebShells

Webshells are a classic type of malware that have been used by attackers for many years. They are administrative dashboards that give the attacker full access to the files and often provide a large amount of information about the hosting environment including operating system, PHP settings, web server configurations, file management, and SQL connections.

The classic FilesMan shell continues to be very popular with attackers. In 2021 we generated 20 new signatures related to new filesman variants alone, not including hack tools which grab filesman shells from remote servers.

Interestingly, a lot of malicious web shells provide far superior functionality than a lot of file managers provided by web hosting providers.

A malicious web shell backdoor

Misc RCE

Sometimes remote code execution backdoors are a little more complicated, or just rely on more basic/generic $_REQUEST calls. This is a PHP global array that contains the content of GETPOST and COOKIE inputs. The content of these variables could be anything and the attacker can fill them — e.g. with the payload — which is then processed. Sometimes the entire payload code is stored there and only very simple code snippets are injected into legitimate files. Such a snippet only loads and executes the content of these variables.

Other times, RCE backdoors make use of multiple different functions and request types.

A remote code execution backdoor

Generic

Not falling into any particular category are our collection of “generic” backdoors. They tend to use a mixture of different functions and methods to maintain backdoor access to the environment. Some are heavily obfuscated and others are mostly in plain text, but what unites them is that they don’t rely on any one technique to backdoor the environment in which they reside.

A generic, malicious backdoor

FILE_GET_CONTENTS

The PHP function file_get_contents fetches a local file or remote file. As far as backdoors are concerned, attackers misuse this function to grab malicious files located on other websites or servers and add it to the victim’s website. This allows them to host the actual malicious content elsewhere, while maintaining all of the same functionality on the victim environment.

Here we have a very simple backdoor using file_get_contents to grab a backdoor from a malicious server. The actual address is obfuscated through use of a URL shortening service:

A backdoor which uses file_get_contents

The footprint of this malware is very small as the payload resides elsewhere, but the functionality is potentially huge.

Remote Code Execution Backdoors

Not to be confused with remote code execution vulnerabilities, these backdoors are crafted to take whatever command is issued to it by the attacker and execute it in the victim’s environment. These PHP backdoors are often more complex than uploaders and allow the attackers more leeway in terms of how they can interact with the victim website.

If a request is sent that matches the parameters of the backdoor it will execute whichever command the attacker instructs so long as it doesn’t get blocked by any security software or firewall running within the environment.

A remote code execution backdoor

Here’s another example of a quite well hidden RCE backdoor in a Magento environment:

A well-hidden RCE backdoor in a Magento environment

Attackers make heavy use of the eval function which executes the command in the victim environment.

FILE_PUT_CONTENTS

These backdoors utilise the PHP function file_put_contents which will write the instructed content to a file on the victim environment.

Here is an example of such a backdoor lodged in a WordPress configuration file wp-config.php:

A backdoor which uses file_put_contents

This backdoor writes the specified malicious content into the file structure of the victim website given the correct parameters in the attacker’s request, allowing them to infect other files on the server with the content of their choice.

cURL

The curl() function facilitates the transmission of data. It can be used maliciously to download remote code which can be executed or directly displayed. This way, malware authors are able to create a small backdoor that only has this curl functionality implemented while the payload itself can be downloaded from a remote source.

It has many uses, and as such can be misused in many ways by attackers. We have seen it used frequently in credit card skimmers to transmit sensitive details to exfiltration destinations. It can also be used in RCE backdoors:

A backdoor which uses CURL

Since the attackers have crafted a backdoor to (mis)use curl, and they control the parameters under which it will function, in this way they are able to send or receive malicious traffic to and from the website, depending on how the backdoor is designed.

Authentication Bypass

These types of backdoors are most often seen in WordPress environments. They are small PHP scripts which allow the attacker to automatically log in to the administrator panel without needing to provide any password.

As long as they include the database configuration file in the script then they are able to set the necessary cookies for authorization, as seen in this example here:

A backdoor which bypasses normal authentication

The existence of such backdoors presents a case that additional authentication requirements should be employed within website environments. Protecting your admin panel with our firewall’s protected page feature is a great way to do this.

If you’re not a user of our firewall there are a lot of other ways that your admin panel can be protected.

Basic RCE via POST

Backdoors that take input through POST requests are quite common and many of the backdoor types that we’ve seen contain such functionality. Some of them, however, are quite small and rely exclusively on POST requests.

The example below shows one such backdoor, coupled with basic password protection to ensure that the backdoor is not used by anybody that does not have access to the password.

A basic remote code execution backdoor which uses POST

Fake Plugins

Another tactic that we’ve seen attackers use is the use of fake plugins. This is frequently used as a payload to deliver spam and malware, since WordPress will load the components present in the ./wp-content/plugins directory.

We’ve also seen attackers use these plugins as backdoors to maintain access to compromised environments.

A fake plugin in a WordPress environment

Since admin panel compromises are a very common attack vector, the usage of fake/malicious backdoor plugins is quite popular with attackers.

System Shell Backdoors

Attackers have also written malware that interacts with the hosting environment itself and will attempt to run shell commands via PHP scripts in the environment. This is not always possible, depending on the security settings of the environment, but here’s an example of one such backdoor:

A system shell backdoor

If system() is disabled in the environment then these will not work, so the functionality of such backdoors will be limited by the security settings in the host.

COOKIE Based Backdoors

Some malware creators use COOKIES as a storage for various data. These can be decryption keys  used to decode an otherwise inaccessible payload, or even the entire malicious payload itself.

A cookie based backdoor

CREATE_FUNCTION

The create_function() is often used by malware instead of (or in conjunction with) the eval() function to hide the execution of the malicious code. The payload is encapsulated inside the crafted custom function, often with an obfuscated name to make the functionality less clear.

This function is then called somewhere else within the code, and thus the payload is evaluated. Backdoors have been found to abuse this to place their payload back on the infected website after it was removed.

A backdoor which creates a malicious function in the victim environment

RCE via GET

Backdoors have also been seen using GET requests for input, rather than POST requests. In the example below we can see that the backdoor will execute the malicious payload if a GET request contains a certain string.

A remote code execution backdoor which uses GET

This allows the attackers to restrict the usage of the backdoor to only those who know the exact parameters to specify in the malicious GET request to the website. If the correct parameters are given then the backdoor will execute its intended function.

Database Management Backdoors

Most often attackers will misuse tools such as Adminer to insert malicious content into the victim website’s database, but occasionally we have seen them craft their own database management tools. This allows them to insert admin users into the website as well as inject malicious JavaScript into the website content to redirect users to spam or scam websites or steal credit card information from eCommerce environments.

A database management backdoor

Conclusion & Mitigation Steps

Backdoors play a crucial role for the attackers in a huge number of website compromises. Once the attackers are able to gain a foothold into an environment their goal is to escalate the level of access they have as much as possible. Certain vulnerabilities will provide them access only to certain directories. For example, a subdirectory of the wp-content/uploads area of the file structure.

Often the first thing they will do is place a malicious uploader or webshell into the environment, giving them full control over the rest of the website files. Once that is established they are able to deliver a payload of their choosing.

If default configurations are in place in a standard WordPress/cPanel/WHM configuration a single compromised admin user on a single website can cause the entire environment to be infected. Attackers can move laterally throughout the environment by the use of symlinks even if the file permissions/ownership are configured correctly.

Malicious actors are writing new code daily to try to evade existing security detections. As security analysts and researchers it’s our job to stay on top of the most recent threats and ensure that our tools and monitoring detect it all.

Throughout the year 2021 we added hundreds of new signatures for newly discovered backdoors. I expect we’ll also be adding hundreds more this year.

If you’d like us to help you monitor and secure your website from backdoors and other threats you can sign up for our platform-agnostic website security services.

Source :
https://blog.sucuri.net/2022/05/examining-emerging-backdoors.html

Massive WordPress JavaScript Injection Campaign Redirects to Ads 

Our remediation and research teams regularly find malicious redirects on client sites. These infections automatically redirect site visitors to third-party websites with malicious resources, scam pages, or commercial websites with the intention of generating illegitimate traffic.

As outlined in our latest hacked website report, we’ve been tracking a long-lasting campaign responsible for injecting malicious scripts into compromised WordPress websites. This campaign leverages known vulnerabilities in WordPress themes and plugins and has impacted an enormous number of websites over the year — for example, according to PublicWWW, the April wave for this campaign was responsible for nearly 6,000 infected websites alone.

Since these PublicWWW results only show detections for simple script injections, we can assume that the scope is significantly larger.

Investigating Obfuscated JavaScript in WordPress Sites

We recently investigated a number of WordPress websites complaining about unwanted redirects. Interestingly enough, they were found to be related to a new wave of this massive campaign and were sending website visitors through a series of website redirects to serve them unwanted ads.

The websites all shared a common issue — malicious JavaScript had been injected within their website’s files and the database, including legitimate core WordPress files such as:

  • ./wp-includes/js/jquery/jquery.min.js
  • ./wp-includes/js/jquery/jquery-migrate.min.js

Once the website had been compromised, attackers had attempted to automatically infect any .js files with jQuery in the names. They injected code that begins with “/* trackmyposs*/eval(String.fromCharCode…”

However, it was clear that the attackers had taken some measures to evade detection and had obfuscated their malicious JavaScript with CharCode, as seen below.

Malicious JavaScript injection obfuscated with CharCode
Malicious JavaScript injection obfuscated with CharCode

Once deobfuscated, the true behavior of the injection emerged.

Deobfuscated malicious JavaScript redirects site visitors on page load
Deobfuscated malicious JavaScript redirects site visitors on page load

This JavaScript was appended under the current script or under the head of the page where it was fired on every page load, redirecting site visitors to the attacker’s destination.

Malicious Chain of Redirects

To accomplish these redirects, the malicious injection creates a new script element with the legendarytable[.]com domain as the source.

The code from the legendarytable[.]com domain then calls to a second external domain — local[.]drakefollow[.]com — which calls from links[.]drakefollow[.]com, redirecting the site visitor to one of many different domains including:

  • bluestringline[.]com
  • browntouchmysky[.]com
  • redstringline[.]com
  • whitetouchmysky[.]com
  • gregoryfavorite[.]space
  • gregoryfavorite[.]top
  • pushnow[.]net/

At this point, it’s a free for all. Domains at the end of the redirect chain may be used to load advertisements, phishing pages, malware, or even more redirects.

From a site visitor’s perspective, they’ll simply see the following malware page before landing on the final destination.

Malicious redirect landing page
Malicious redirect landing page

This page tricks unsuspecting users into subscribing to push notifications from the malicious site. If they click on the fake CAPTCHA, they’ll be opted in to receive unwanted ads even when the site isn’t open — and ads will look like they come from the operating system, not from a browser.

These sneaky push notification opt-in maneuvers also happen to be one of the most common ways attackers display “tech support” scams, which inform users that their computer is infected or slow and they should call a toll-free number to fix the problem.

Detecting Malicious JavaScript via SiteCheck

Client-side redirects are initiated by the site visitors’ browser once the infected web page has been loaded. Since this particular infection is found client-side, remote website scanners like SiteCheck can help scan a website and identify this malware.

Here’s an example of a SiteCheck results page for this specific campaign.

SiteCheck results for malicious Javascript injection
SiteCheck results for malicious Javascript injection

At the time of writing, PublicWWW has reported 322 websites impacted by this new wave for the malicious drakefollow[.]com domain. Considering that this count doesn’t include obfuscated malware or sites that have not yet been scanned by PublicWWW, the actual number of impacted websites is likely much higher.

Conclusion & Mitigation Steps

Our team has seen an influx in complaints for this specific wave of the massive campaign targeting WordPress sites beginning May 9th, 2022, which has impacted hundreds of websites already at the time of writing.

It has been found that attackers are targeting multiple vulnerabilities in WordPress plugins and themes to compromise the website and inject their malicious scripts. We expect the hackers will continue registering new domains for this ongoing campaign as soon as existing ones become blacklisted.

If you believe that your website has been infected with malicious JavaScript or you have found unwanted redirects to spam or ads on your site, you can use our free remote website scanner to detect the malware.

Website owners who have identified malware on their website can leverage the instructions found in our hacked WordPress cleanup guide  — and, as always, we’re happy to help clean up an infection if you need a hand.

Source :
https://blog.sucuri.net/2022/05/massive-wordpress-javascript-injection-campaign-redirects-to-ads.html

ShieldPRO 15.0 Upgrade Guide

ShieldPRO 15.0 for WordPress is a major release. 
We’ve taken steps to improve the Shield Security Dashboard navigation menu and the Overview section UI making it much easier to secure your WordPress site by quickly identifying areas of improvement. Also, the original WordPress Admin Dashboard widget was pretty basic, so we’ve completely revamped it with some of your latest site activity. This guide outlines what have been added/removed, changed, or improved and what fixes we’ve made.

Firstly, we’re going to explain what major changes are made and which options you’d need to review.

New Added Features

For 15.0 release we added

  • Block Username Fishing option

This feature is now a Bot Signal which is recorded in the Activity Log and triggers offenses. 

You can use this option to block the ability to discover WordPress usernames based on author IDs. When enabled, any URL requests containing “author=” will be killed.

This option is accessible from within WP Lockdown module > Obscurity:

The new Security Rules Engine is the new foundation of how Shield will handle security for nearly all WordPress requests. It’s accessible from within the main navigation menu > Tools section.

This article outlines what brought this about, what the Rules Engine is and does, and how it will inform future development and our approach to WordPress Security.

Changes

Change 1: All-New Security Overview page

We’ve broken up the plugin into 7 key areas and gathered configuration options and conditions of the site under each one. We give each component a weighted score and calculate an overall percentage. 

You can see your score within each area and click “Analysis” to get a clear breakdown of what constitutes that score.

Example, Site Scanning area:

Change 2: All-New Dashboard WidgetSimilar to the Security Overview we offer some visibility to the workings of the Shield plugin right on the WordPress Dashboard, using the built-in widget area.Currently it shows your

  • security overview progress
  • recently blocked IPs
  • recent offending IPs
  • recent user sessions
  • jump links to key plugin areas

Change 3: New Template-Based Block Pages

When triggering the Shield defenses, Shield now provides a much more visitor-friendly block page that outlines exactly what’s happened. It’ll provide details of why the block occurred and what the visitor can do about it. Please see below examples of the new blocking pages.

General IP Blocking Page (non-logged in users)

General IP Blocking Page (logged in users)

Firewall Blocking Page

Username Fishing Blocking Page

Change 4: Audit Trail (now renamed to Activity Log) and Traffic Log: Direct access to the IP analysis

In the previous plugin release, when you click an IP address from within Audit Trail or Traffic Log, you were directed to the IP Analysis page in a separate tab.

Now, you can analyse IP directly from within Audit Trail (Activity Log) Traffic Log. Please see below examples.

From Within Audit Trail (Activity Log)

From Within Traffic Log

Change 5: Option Removed: Legacy Comment SPAM Detection

We’ve completely removed the older, less reliable comment spam detection using Javascript and CAPTCHAs. Please use the newer AntiBot Detection EngineChange 6: Option Removed: Auto-Filter Scan ResultsShield will now filter unnecessary scan results automatically.

This option can now be adjusted using a WP filter. Change 7: Deprecated: Options For CAPTCHA and GASP Bot Checking On WordPress Login FormsThe options to use CAPTCHA and/or GASP Bot Checking for WordPress Login SPAM has been deprecated. These options are replaced with the AntiBot Detection Engine and will be completely removed in a future release. 

Change 8: Audit Trail Renamed to Activity Log

Improvements

For 15.0 release we’ve made the following improvements

  • Improved Plugin Navigation
    This release brings further enhancements in this area – the new dynamic page loading and smoother navigation.
  • Improved Visitor IP Source Detection
    We’ve built a Javascript utility which will determine your best visitor IP source. This should, hopefully, solve this problem of everyone going forward, even if your host is badly configured (there are many such hosts!).
  • Massive Performance Optimisations
    As part of our new approach to security with the Security Rules Engine, we’ve taken the opportunity to rip out legacy code and optimise many other areas. We’ve eliminated unnecessary MySQL queries and redesigned core components to be more efficient with how they store data.
  • New Filters: Adjust scanner notices about plugin/theme update/active status
    You can now use filters to adjust whether Shield warns about inactive plugins/themes or those with updates. 
  • A New WP Filter To Add Custom Shield Template Directory
    If you’re looking to adjust some of our page templates, such as the block pages, you can now provide custom templates more easily using the new filter. 
  • Option Removed: XML-RPC bypass option, under the General settings:


    This option can now be adjusted using a WP filter. 

Fixes

For 15.0 release, we’ve made the following fixes

  • 15.0 release
    • Broken password reset links in some cases when using hidden login page
    • Help ensure forward compatibility for sites with newer TWIG libraries also installed
    • Fix for some scan results browsing errors

For more information on Shield 15.0 release, read this blog article here.

Source :
https://help.getshieldsecurity.com/article/461-shieldpro-15-0-upgrade-guide

Exit mobile version