Taula de continguts[Amaga][Espectacle]
Log4Shell, una vulnerabilitat d'Internet, ha afectat recentment milions de màquines. Log4j, una peça de programari obscura però gairebé omnipresent, ho provoca.
Log4j s'utilitza per registrar totes les accions que es produeixen darrere de les escenes en una varietat de sistemes informàtics.
Es basa en una biblioteca de registre de codi obert que utilitzen empreses i fins i tot organitzacions governamentals a la majoria d'aplicacions.
Com que és un dels pitjors forats de seguretat cibernètica que s'han descobert mai, és fonamental protegir els vostres sistemes d'aquesta vulnerabilitat. Però com?
Explorem detalladament la vulnerabilitat de Log4j i totes les solucions possibles per solucionar-hi.
Què és Log4j?
Log4j és un de codi obert marc de registre que permet als desenvolupadors de programari registrar diferents dades dins de les seves aplicacions. És un component del projecte Apache Logging Services, que està executat per Apache Software Foundation.
Centenars de llocs web i aplicacions utilitzen Log4j per realitzar operacions crítiques, com ara registrar dades per a la depuració i altres usos.
Quan introduïu o feu clic a un enllaç en línia deficient i obteniu un avís d'error 404, aquest és un exemple freqüent de Log4j a la feina. El servidor web que executa el domini de l'enllaç web al qual heu intentat accedir us informa que no existeix aquesta pàgina web. També registra l'esdeveniment a Log4j per als administradors del sistema del servidor.
Al llarg dels programes de programari, s'utilitzen senyals de diagnòstic similars. Al joc en línia Minecraft, per exemple, el servidor utilitza Log4j per registrar activitats com ara la memòria RAM total utilitzada i les instruccions d'usuari enviades a la consola.
Com es produeix la vulnerabilitat?
Les cerques són una nova característica introduïda a Log4j 2.0, que ajuda a incorporar informació addicional a les entrades de registre. Una d'aquestes cerques és la cerca JNDI (Java Naming and Directory Interface), que és una API de Java per comunicar-se amb un servei de directori.
Amb aquest enfocament, els ID d'usuari interns es poden assignar a noms d'usuari reals. Aquesta consulta exposa la vulnerabilitat RCE recentment descoberta, ja que un dels tipus de dades subministrats pel servidor LDAP és un URI que apunta a una classe Java, que després es carrega a la memòria i la executa la instància Log4j.
A causa d'una debilitat en la validació d'entrada de la biblioteca Log4j, és possible injectar un servidor LDAP arbitrari des d'una font no fiable. Com que els desenvolupadors assumeixen que les dades enviades als registres es tractaran com a text sense format, no es duu a terme cap validació d'entrada addicional i entra en els registres entrades perilloses de l'usuari.
Una declaració de registre pot semblar així:
Un usuari maliciós ara inseriria una cerca JNDI que faci referència a un servidor LDAP canalla en un paràmetre d'URL. La cerca JNDI seria la següent:
Aleshores, la biblioteca Log4j parla amb aquest servidor LDAP a attacker.com per obtenir informació del directori, inclosos els valors per a Java Factory i Java Codebase.
Aquests dos valors inclouen la classe Java de l'atacant, que després es carrega a la memòria i la executa la instància Log4j, completant l'execució del codi.
Qui està en risc?
La vulnerabilitat Log4j és increïblement àmplia i afecta les aplicacions empresarials, els dispositius incrustats i els seus subsistemes. Les aplicacions afectades inclouen Cisco Webex, Minecraft i FileZilla FTP.
Tanmateix, aquesta no és de cap manera una llista sencera. El defecte fins i tot afecta la missió helicoïdal Ingenuity Mars 2020, que utilitza Apache Log4j per a la gravació d'esdeveniments.
La comunitat de seguretat ha compilat un llista de sistemes vulnerables. És fonamental tenir en compte que aquestes llistes s'actualitzen contínuament, de manera que si un programa o sistema determinat no apareix, no assumeixis que no es veu afectat.
L'exposició a aquesta vulnerabilitat és força probable, encara que sigui específica pila de tecnologia no aplica Java, els executius de seguretat haurien d'esperar que ho facin els sistemes de proveïdors crítics, els proveïdors de SaaS, els proveïdors d'allotjament en núvol i els proveïdors de servidors web.
Com comprovar la vulnerabilitat Log4j?
El primer pas és determinar si ja s'ha produït una agressió. Podeu fer-ho comprovant els registres del sistema per trobar fragments de càrrega útil RCE.
Si una cerca de termes com "jndi", "ldap" o "$::" produeix algun registre, els investigadors de seguretat haurien d'explorar més per veure si es tracta d'un atac legítim o simplement d'empremtes digitals.
Es van descobrir molts assalts en estat salvatge que no van lliurar cap càrrega útil perjudicial. No obstant això, van ser realitzats per experts en seguretat per determinar quantes aplicacions eren vulnerables a aquest atac.
El següent pas és utilitzar la biblioteca Log4j per identificar tots els projectes. Si s'utilitzen versions entre 2.0-beta9 i 2.14.1, el projecte pot ser susceptible.
Donada la dificultat de determinar on existeix aquesta vulnerabilitat, pot ser preferible suposar que el projecte és susceptible i que l'actualització de la biblioteca és el millor curs d'acció per eliminar el perill d'execució de codi.
El projecte no és vulnerable si la versió utilitzada és inferior a la 2.0-beta 9, tot i que la biblioteca Log4j encara s'hauria d'actualitzar perquè les versions del rang 1.x són antigues i ja no reben actualitzacions.
Tant si es descobreix un projecte susceptible, s'aconsella que es comprovi per veure si alguna informació registrada mitjançant Log4j conté informació que l'usuari pot canviar. Els URL, els paràmetres de sol·licitud, les capçaleres i les galetes són exemples d'aquestes dades. Si es registra un d'ells, el projecte està en perill.
Aquest coneixement us pot ajudar a aprofundir més en els registres del sistema i a determinar si la vostra aplicació web ja ha estat atacada.
Hi ha eines en línia gratuïtes que poden detectar si una aplicació web és vulnerable. Un d'aquests programes és Log4Shell caçadora. És de codi obert i està disponible a GitHub.
Si es descobreix una àrea de codi vulnerable a l'aplicació en línia, la càrrega útil proporcionada per l'eina revelada es pot utilitzar per injectar-la a l'aplicació web. L'eina de prova revelaria les connexions fetes entre la vostra aplicació web i el seu servidor LDAP si s'aprofités la vulnerabilitat.
Solucions per solucionar la vulnerabilitat de Log4j
El primer pas és actualitzar Log4j, que podeu fer utilitzant els gestors de paquets normals o descarregant-lo directament des d'aquest pàgina.
També és possible disminuir l'explotabilitat de la vulnerabilitat establint la variable d'entorn FORMAT MSG NO LOOKUPS a true. Aquesta contramesura, però, només és aplicable a les versions de Log4j superiors o iguals a 2.10.
Considerem ara opcions alternatives.
1. Solucions alternatives per a la versió 4 de Log2.17.0j
Definitivament, es recomana utilitzar la versió 4 de Log2.15.0j per protegir-se contra Log4Shell, però, si això no és possible, hi ha altres solucions disponibles.
Versions 2.7.0 i posteriors de Log4j: És factible protegir contra qualsevol atac canviant el format dels esdeveniments que s'han de registrar mitjançant la sintaxi percent m nolookups per a les dades subministrades per l'usuari. Aquesta actualització requereix editar el fitxer de configuració de Log4j per generar una nova versió del programa. En conseqüència, abans de desplegar aquesta nova versió s'han de repetir les etapes de validació tècnica i funcional.
Log4j versions 2.10.0 i posteriors: També és possible protegir-se de qualsevol atac establint el paràmetre de configuració log4j2.formatMsgNoLookups a true, per exemple, quan s'inicia la màquina virtual Java amb l'opció -Dlog4j2. formatMsgNoLookups = true, una altra opció és eliminar la classe JndiLookup de l'argument classpath, que eliminarà el vector d'atac principal (els investigadors no descarten la possibilitat d'un altre vector d'atac).
Amazon Web Services ofereix un hotpatch que "s'ha d'utilitzar sota el vostre propi risc". S'han publicat altres "tècniques", com ara Logout4Shell, que "utilitza aquesta vulnerabilitat contra si mateixa". L'expert en seguretat qüestiona la legalitat d'aquest moviment, que implica "piratejar una màquina per arreglar-la".
2. El problema s'ha resolt a Log4j v2.17.0.
Per a versions superiors a 2.10: Log4j2.formatMsgNoLookups s'ha de definir com a true.
Per a les versions 2.0 a 2.10.0: executeu l'ordre següent per eliminar la classe LDAP de Log4j.
Log4j2.formatMsgNoLookups s'ha de definir com a true a la configuració del sistema.
Mitigació en JVM
La mitigació amb paràmetres de JVM ja no és una opció. Altres mètodes de mitigació continuen tenint èxit. Actualitzeu a la versió 4 de Log2.17.0j si és possible. Hi ha una guia de migració disponible per a Log4j v1.
Si no és possible una actualització, assegureu-vos que els components del costat del client i del servidor tinguin la propietat del sistema -Dlog4j2.formatMsgNoLookups = true.
Tingueu en compte que Log4j v1 ha arribat al final de la seva vida útil (EOL) i ja no rebrà correccions d'errors. Altres vectors RCE també són susceptibles a Log4j v1. Per tant, us recomanem que actualitzeu a Log4j 2.17.0 tan aviat com sigui possible.
3. Mesures de mitigació
Els exploits actuals no poden funcionar fins i tot si Log4j és susceptible en alguns casos, com ara si la màquina amfitriona executa una versió de Java superior a 6u212, 7u202, 8u192 o 11.0.2.
Això es deu a una millor protecció contra la càrrega de classe remota de la interfície de directoris i noms de Java (JNDI) en les versions actuals, que és necessària perquè l'atac funcioni.
A més, amb les versions de Log4j superiors a la 2.10, el problema es pot evitar establint el valor del sistema formatMsgNoLookups com a true, proporcionant l'argument JVM -Dlog4j2.formatMsgNoLookups = true o suprimint la classe JndiLookup de la ruta de classe.
Mentrestant, fins que es solucionin les instàncies vulnerables, la vulnerabilitat es pot solucionar mitjançant les tècniques següents:
- Estableix la propietat del sistema log4j2.formatMsgNoLookups a true per a >=2.10.
- Estableix l'opció d'entorn LOG4J FORMAT MSG NO LOOKUPS a true per a >=2.10.
- Elimineu JndiLookup.class del classpath per a 2.0-beta9 a 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Una pràctica recomanada és limitar el trànsit de sortida a Internet només als ports adequats.
Tot i que la majoria dels atacs en el camp es lliuren a través d'HTTP, la vulnerabilitat es pot explotar mitjançant qualsevol protocol que registre les dades d'entrada de l'usuari mitjançant Log4j.
Tanmateix, actualitzar a log4j 2.17.0 és el millor remei perquè algú pot descobrir un enfocament addicional al problema. A més, molts editors i fabricants han anunciat millores als seus serveis o aplicacions.
4. Pedaç de vulnerabilitat de Log4Shell
Log4j és omnipresent, sobretot ara que s'està explotant la vulnerabilitat. En resum, tot el que heu de fer és incloure els caràcters següents als registres inspeccionats per Log4j.
I això baixarà i executarà el fitxer Java situat al final de l'URL. És tan directe com dramàtic.
Com sabeu, és fonamental actualitzar log4j a la versió >= 2.17.0 per solucionar aquesta vulnerabilitat de Log4Shell (CVE-2021-44228).
Si això no és possible:
Per a les aplicacions que utilitzen la biblioteca Log4j versions 2.10.0 i posteriors, també és possible protegir contra qualsevol atac establint el paràmetre de configuració log4j2.formatMsgNoLookups a true, per exemple, mentre s'inicia la màquina virtual Java amb -Dlog4j2.formatMsgNoLookups = true opció.
Una altra opció és eliminar la classe JndiLookup de l'argument classpath, que eliminarà el vector d'atac primari (els investigadors no descarten l'existència d'un altre vector d'atac).
Nota
Les organitzacions que dubten o no volen fer ajustos als sistemes susceptibles (o que només volen instal·lar garanties addicionals) haurien de pensar en:
- Assegureu-vos que tot el trànsit s'encamina a través d'un iSensor/WAF/IPS. Això pot evitar que l'assalt tingui accés al sistema.
- Limitació de la quantitat de trànsit que pot arribar al sistema susceptible Si el sistema no necessita estar connectat a Internet, restringeix l'accés només a IPS i rangs essencials i fiables.
- Reducció del trànsit de sortida autoritzat de l'amfitrió. Com que aquest atac opera connectant-se a un servidor canalla, totes les adreces IP i ports superfluos haurien de ser bloquejats en un tallafoc.
- Si el servei ja no és necessari, s'hauria de desactivar fins que estigui a punt una solució.
Conclusió
Els defectes de Log4j van sorprendre la nostra comunitat i ens van recordar a tots com depenem del programari de codi obert.
Log4j és únic. No és un sistema operatiu, ni és un navegador, ni és un programari. Més aviat, és el que els programadors anomenen una biblioteca, un paquet o un mòdul de codi. Només té un propòsit, és a dir, mantenir un registre del que passa en un servidor.
Les persones que escriuen codi prefereixen concentrar-se en allò que fa que el seu programari sigui diferent. No els interessa reinventar la roda. Com a resultat, es basen en una gran quantitat de biblioteques de codi existents, com ara Log4j.
El mòdul Log4j deriva d'Apache, el programari de servidor web més utilitzat. És per això que es pot descobrir en milions de servidors. Per tant, augmenta les amenaces a la seguretat.
Espero que les solucions anteriors us ajudin a mantenir els vostres dispositius segurs.
Estigueu atents a HashDork per obtenir informació més útil del món de la tecnologia.
Deixa un comentari