În ultimele zile pe net s-a vorbit mult despre vulnerabilitatea Log4j în care au fost descoperiți diverși vectori de atac și au fost filtrate și diverse exploit-uri funcționale pentru a exploata vulnerabilitatea.
Seriozitatea problemei este că acesta este un cadru popular pentru organizarea registrului în aplicații Java., care permite executarea unui cod arbitrar atunci când o valoare formatată special este scrisă în registry în formatul „{jndi: URL}”. Atacul poate fi efectuat asupra aplicațiilor Java care înregistrează valorile obținute din surse externe, de exemplu prin afișarea valorilor problematice în mesajele de eroare.
Și asta un atacator face o solicitare HTTP pe un sistem țintă, care generează un jurnal folosind Log4j 2 Care folosește JNDI pentru a face o cerere către site-ul controlat de atacator. Vulnerabilitatea face ca procesul exploatat să ajungă la site și să execute sarcina utilă. În multe atacuri observate, parametrul care aparține atacatorului este un sistem de înregistrare DNS, menit să înregistreze o solicitare pe site pentru identificarea sistemelor vulnerabile.
După cum a spus deja colegul nostru Isaac:
Această vulnerabilitate a Log4j permite exploatarea unei validări de intrare incorecte către LDAP, permițând executarea codului de la distanță (RCE) și compromiterea serverului (confidențialitate, integritatea datelor și disponibilitatea sistemului). În plus, problema sau importanța acestei vulnerabilități constă în numărul de aplicații și servere care o folosesc, inclusiv software de afaceri și servicii cloud precum Apple iCloud, Steam sau jocuri video populare precum Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash și un lung etc.
Vorbind despre această chestiune, recent a lansat Apache Software Foundation prin o postare un rezumat al proiectelor care abordează o vulnerabilitate critică în Log4j 2 care permite rularea unui cod arbitrar pe server.
Sunt afectate următoarele proiecte Apache: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl și Calcite Avatica. Vulnerabilitatea a afectat și produsele GitHub, inclusiv GitHub.com, GitHub Enterprise Cloud și GitHub Enterprise Server.
În ultimele zile s-a înregistrat o creștere semnificativă a activităţii legate de exploatarea vulnerabilităţii. De exemplu, Check Point a înregistrat aproximativ 100 de încercări de exploatare pe minut pe serverele sale fictive apogeul său, iar Sophos a anunțat descoperirea unei noi rețele botnet de exploatare a criptomonedei, formată din sisteme cu o vulnerabilitate nepatchată în Log4j 2.
În ceea ce privește informațiile care au fost publicate despre problemă:
- Vulnerabilitatea a fost confirmată în multe imagini oficiale Docker, inclusiv couchbase, elasticsearch, flink, solr, imagini de furtună etc.
- Vulnerabilitatea este prezentă în produsul MongoDB Atlas Search.
- Problema apare într-o varietate de produse Cisco, inclusiv Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Raportare avansată de securitate web, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks etc.
- Problema este prezentă în IBM WebSphere Application Server și în următoarele produse Red Hat: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse și AMQ Streams.
- Problemă confirmată în Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Multe produse de la Oracle, vmWare, Broadcom și Amazon sunt, de asemenea, afectate.
Proiecte Apache care nu sunt afectate de vulnerabilitatea Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper și CloudStack.
Utilizatorii pachetelor problematice sunt sfătuiți să instaleze de urgență actualizările lansate pentru ei, actualizați separat versiunea Log4j 2 sau setați parametrul Log4j2.formatMsgNoLookups la true (de exemplu, adăugând cheia „-DLog4j2.formatMsgNoLookup = True” la pornire).
Pentru a bloca sistemul este vulnerabil la care nu există acces direct, s-a sugerat exploatarea vaccinului Logout4Shell, care, prin comiterea unui atac, expune setarea Java „log4j2.formatMsgNoLookups = true”, „com.sun.jndi”. .rmi.obiect. trustURLCodebase = fals „și” com.sun.jndi.cosnaming.object.trustURLCodebase = fals „pentru a bloca alte manifestări ale vulnerabilității pe sistemele necontrolate.