Mi columna en Invertia de esta semana se titula «Vulnerabilidades de software: ¿el cuento de nunca acabar?» (pdf), y habla de la naturaleza del desarrollo de software y de por qué el descubrimiento de problemas tan graves como el reciente Log4Shell, que afecta a prácticamente la totalidad de sistemas, no solo no debe sorprendernos ni hacernos despotricar contra nada ni nadie, sino simplemente llevarnos a desarrollar habilidades para la resolución rápida de los eventuales problemas que pueda generar.
Como muy bien afirmó hace años el bueno de Marc Andreessen, «el software se está comiendo el mundo«. Cada vez más cosas de las que hacemos regularmente en nuestro día a día están de una u otra manera basadas en software, en código ejecutable, en el que, con cierta periodicidad y a modo de cuento de nunca acabar, aparecen vulnerabilidades que, en muchos casos, comprometen su seguridad y ofrecen oportunidades a delincuentes de toda ralea para todo tipo de maldades.
El problema fundamental de Log4Shell es que afecta a un módulo de software, un generador de mensajes de registro o logging framework en Java denominado Log4j, creado por la Apache Software Foundation y posteriormente implementado en multitud de lenguajes, que resulta ser extremadamente popular y utilizado en todas partes. Lo que un módulo de este tipo hace es, básicamente, registrar la actividad de las transacciones en tiempo de ejecución, y permitir posteriormente al desarrollador filtrarlas en función de su criticidad.
¿Por qué está este software en todas partes? Muy simple: porque lo que hace, lo hace razonablemente bien, y porque una de las reglas básicas del desarrollo de software es no tratar nunca de reinventar la rueda. Esto, que en muchas ocasiones genera sistemas con dependencias de todo tipo que se apoyan en componentes que nadie se ha preocupado de tocar en años, lleva a que algunos definan Log4Shell como «la vulnerabilidad más importante y más crítica de la última década, y posiblemente la más grande en la historia de la informática moderna«, no solo porque afecta a infinidad de sistemas y dispositivos, sino porque el desarrollador de Alibaba que se encontró con la vulnerabilidad decidió, además, publicarla en Twitter.
Esto ha generado una auténtica pesadilla de seguridad, porque además de tener una presencia generalizada, la velocidad con la que ciberdelincuentes de toda condición se han puesto a explotar la vulnerabilidad ha sido prácticamente sin precedentes. Hablamos de responsables de sistemas en todo el mundo que, desde que el pasado jueves 9 se publicó ese tweet posteriormente eliminado, se han pasado horas y horas buscando una forma de arreglar el problema, localizando un parche para ello, e instalándolo en todas partes.
¿Qué pasa si no instalas la actualización que corrige la vulnerabilidad? Simplemente, que lo único que tiene que hacer un potencial atacante es lograr enviar un mensaje para que el módulo de logging del sistema lo registre, y que ese mensaje contenga, por ejemplo, instrucciones para acceder a un sitio gestionado por el atacante, donde el sistema hará y ejecutará lo que le digan, sea robar datos, ejecutar programas para minar criptomonedas, o lo que sea. Esto supone prácticamente poder acceder sin esfuerzo a prácticamente cualquier sistema, y sin necesidad de ninguna contraseña.
¿Debemos llevarnos las manos a la cabeza por un problema de este tipo? No, en absoluto. Este tipo de problemas son habituales en el software, lo han sido siempre y lo van a seguir siendo, seguramente hasta que el software dejen de hacerlo seres humanos – y posiblemente después, también. No hay más forma de evitarlo que intentar que, siguiendo la conocida ley de Linus, sean cuantos más mejor los ojos que puedan examinar el software, porque «dado un número suficientemente elevado de ojos, todos los errores se vuelven obvios». Siempre es mejor que este tipo de errores aparezcan en un módulo de software de código abierto, entorno en el que cualquiera puede detectarlos y corregirlos rápidamente, que el que surjan en un código propietario que solo una empresa, en función de sus intereses y de su estimación de la criticidad del problema, puede corregir.
Pero lo realmente importante no es la vulnerabilidad en sí, sino que todos los afectados sean capaces de ponerse las pilas y corregir rápidamente el potencial problema. Para ello, es preciso no solo que estén bien informados y se enteren con la premura necesaria, sino además, que tengan todos sus sistemas convenientemente registrados, inventariados y con todas sus dependencias correctamente documentadas, para poder plantearse corregir el problema rápidamente y en todos los sitios en los que se encuentre.
Eso, y no otra cosa, es lo que distingue a las compañías que actúan con responsabilidad de las que no lo hacen. A partir de ahora, nos encontraremos de todo: desde compañías que no dan oportunidad a ningún delincuente porque aplicaron los correspondientes parches quedándose a trabajar durante el fin de semana del 9 y el 10 de diciembre, inmediatamente tras la publicación de la vulnerabilidad, hasta otras que no se enteren o no tengan a bien hacer nada durante meses o años, y que únicamente estarán esperando a que el delincuente de turno estime que tiene algo que ganar por el hecho de entrar en sus sistemas sin ningún tipo de esfuerzo, como Pedro por su casa.
El software se está comiendo el mundo, sí. Pero el software tiene sus certezas, y es que de vez en cuando, aparece alguna vulnerabilidad que hay que corregir. En lugar de despotricar contra la naturaleza del software, que es la que es dede hace mucho tiempo, despotriquemos contra aquellos que no la entienden y que no toman las medidas adecuadas para controlar los problemas a tiempo.
This article is also available in English on my Medium page, «Software is problematic by nature, we just have to learn how to protect ourselves«
En lugar de despotricar contra la naturaleza del software, que es la que es desde hace mucho tiempo, despotriquemos contra aquellos que no la entienden y que no toman las medidas adecuadas para controlar los problemas a tiempo.
«¿¡Nadie paga a los mantenedores de Log4j2 !? Hay una página entera en la Guía del Comité de Gestión de Proyectos de la Apache Foundation sobre las responsabilidades de los desarrolladores… ¿Y NADIE LES ESTÁ PAGANDO? […] ¿Qué estamos haciendo, gente? […] El open source necesita madurar muchísimo» (Filippo Sottile).
«Medio Internet es vulnerable porque estamos confiando en un proyecto open source de un tío que tiene dos trabajos, uno de ellos no remunerado. Por supuesto que [el proyecto] tiene problemas, ¿cómo no los iba a tener? Lo está haciendo lo mejor que puede. ¿Por qué somos tan reticentes a pagar el tiempo de los desarrolladores de dependencias críticas?» (Ada Worcester).
y la mejor…
«El proyecto Apache Log4j está siendo mantenido por tres personas que ofrecen voluntariamente su tiempo libre. Por favor, no sea un idiota con ellos, porque compañías multimillonarias están usando su herramienta sin siquiera molestarse en donarles 1.000 dólares» (Catalin Cimpanu).
Despues me entretendre con mas… pero como colaborador en varios proyectos open, me entra diarrea…
https://www.macworld.com/article/559108/icloud-patch-log4shell-exploit.html
Apple ha tardado menos en parchear su Cloud de esta vulnerabilidad que lo que hizo con la vulnerabilidad de NSO (publicado en 2016 y hasta el 23 de Noviembre no hubo una solución)
Igual no fueron tan malos en la comunidad:
November 26: The CVE ID for the vulnerability is reserved.
December 1: The first known exploit of the vulnerability detected in the wild.
December 10: The CVE ID is published and a patch is released.
December 11: At 14:24 CET, ESET’s Network Attack Protection module received a detection update to cover this vulnerability.
December 13: Log4j version 2.16.0 released after the fix in version 2.15.0 was found to be incomplete and still put some systems at risk.
Creo que cuando se habla de un artículo «técnico» se debería tirar también de enlaces igualmente técnicos… The Guardian o The SimpsonFilibuster, no creo que sean las mejores fuentes… suelen tender al amarillismo… un poco como este artículo de hoy (esto es crítica constructiva, no ataque, no empecemos)
Me sorprende me no se mencione que los mas afectados son las “grandes” (Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter…) y no, no afecta a multitud de lenguajes, solo a servidores con librería Apache y Java.
La solución en realidad es bastante sencilla (casi desde el primer momento estuve al tanto), una simple búsqueda me ha ofrecido cientos de resultados sobre como atacar la vulnerabilidad… entre ellas, la de los propios desarrolladores que tardaron menos y nada… (en Github)
Pero para mí, lo importante, el grueso del asunto, es lo ya mencionado en mi comentario anterior…
Como coño puede ser posible, que todas “esas grandes”, estén empleando software de código abierto, que algunos logran/logramos, mantener a duras penas y no se ve ninguna implicación por su parte, sea con donativos, con recursos, y porque no, con creación de departamentos dedicados a ellos (y por supuesto, remunerados)…???
El artículo, apunta a una “culpabilidad” por parte de los administradores de sistemas, y estoy de acuerdo… antes de implementar una medida, tienes que verificarla y probarla… pero en algunos casos, eso sería tanto como “hacértela tú mismo”.
Si estas tirando, de un recurso “gratuito” (y volvemos a confundir “libre” con “gratis”), que menos, que apoyar las iniciativas, mas aun, cuando tus sistemas, los utilizan en beneficio propio…
El “ataque” (de momento, vulnerabilidad”), ha sido importante? SI, rotundo. Pone en jaque a toda la puñetera internete… y vamos a oir hablar de ello en los próximos días/semanas/meses… todo dependerá de la celeridad de los admins en poner remedio…
…pero de ahí, a repartir las culpas entre el populacho (los admins) creo que hay un trecho importante… como lo hay, entre los múltiples ataques que han estado recibiendo los tres que mantienen el proyecto… igual después de ello, deciden dedicarse a unas birras con los amigos y familia, y que le den a la internete…
Estoy a medias de acuerdo. Es decir una empresa utiliza un SW de código abierto mantenido por la comunidad en las condiciones que limita su licencia. Al igual que podemos hacerlo los particulares.
Otra cuestión es que un servicio comercial no le exhime de ninguna responsabilidad frente a sus usuarios su uso. Para que lo entiendan los no informáticos
a) Supongamos que yo voy al bosque a por setas, y hago setas picking
b) Y tengo esas cestas en mi casa Suiza en un valle del cantón de los Grisones para el que quiera que coja unas cuantas. Y digo claramente que se use bajo responsabilidad de cada uno. Ya que no soy micólogo profesional.
c) Viene el Sr. Manzana y se coge unas cuantas para su Restaurante
d) Sus clientes se cogen un pedal del 15 con las setas alucinógenas
¿Soy yo culpable que tengo un Disclaimer bien gordo?
Si el profesional que gana pasta no conoce las setas ¿soy yo culpable por recolectarlas?
Pues según la ley aqui en España tendré una Responsabilidad Civil por las setas, por el SW no sé. Por eso cuando las setas se pasan de fecha en Carrefour las tiran a la basura, luego tu como indigente, ya verás si las coges o no… ¿es el Sr Manzana un indigente? no lo parece…
Y gracias a la comunidad por hacer el esfuerzo del código abierto, que en general suele funcionar bastante mejor que muchos privativos.
Ya… tu ejemplo me vale, en parte…
No es cuestión de Disclaimers… sino de “aprovechamiento del trabajo ajeno” y no dar ni una sola palmadita en la espalda…
He hervido con este tema, como me ha pasado en ocasiones similares, porque de repente, todo se va al traste y cuando empieza lo que yo llamo: “la búsqueda implacable de culpables…” nos toca la china… y nadie, nadie, nadie, se pregunta “pero esta gente cobraba?”, “recibía alguna ayuda aunque fuera en infraestructura…? a eso me refiero… la mayoría se piensa que eso del “open”, es un “ven y sírvete tu mismo, que yo limpio las cacas…”
Y no se dan cuenta del esfuerzo “desinteresado” que suele haber detrás…
Por aquello de «una imagen vale más que mil palabras», una viñeta de Randall Munroe
Jajaja, gracias, Antonio, ya la tenía enlazada en la entrada, fue de lo primero en lo que pensé! ;-)
OFFTOPIC
Hablando de cuñados y el BITCOIN
https://www.elladodelmal.com/2021/12/si-estas-navidades-tu-cunado-te-dice.html
Yo cada semana, gano la loteria primitiva con mi metodo infalible…
porque como siempre me olvido de ir a echarla, gano 1€ a la semana… que mejor inversion… XDDD
Si estas navidades tu cuñado te dice que se está forrando con BitCoins dile que revise a ver si no está siendo estafado
¿Cómo era? ¿Ah, si? :
Informarse mínimamente y un poco de sentido común. Ya sé que es mucho pedir para algunos.
El final de Chema es de 5 estrellas:
Espera, que esto es mas divertido… XDDD
Durante unas horas mucha gente fue millonaria: un error disparó el precio de las criptomonedas en Coinbase
Y lo que vuelve a ser genial es la solución adoptada al final del link
«se vieron obligados a reiniciar los servidores»
BOTONAZO !!!
Y estos subiendo en bolsa ahora mismo. TLC
Seguimos con Offtopic???? XDDD
Una clave robada, 45.000 dólares de factura en AWS: una estafa rocambolesca para minar 1.000 euros en Monero
A ver, estoy tratando de darle algún sentido al post, pero no es así como ha sucedido.
No es vulnerabilidad debida a la debilidad del código, sino al contrario, es código abierto de una elevada calidad y auditado por la Apache Foundation, que utilizan multinacionales de todo calibre, precisamente, porque es una pieza de software bien testada y conocida.
(El CDN Cloudflare, por ejemplo, que es una infraestructura que usan millones de páginas web)
Ningún código está libre de ser objeto de una vulnerabilidad, ya sea en su implementación o por un uso malicioso del mismo, en este caso es una librería de traza en tiempo de ejecución para Java, que examina y mantiene un registro durante la ejecución de las aplicaciones en este lenguaje.
Hacía mucho tiempo que no veía una shell aprovechando los permisos y paso de argumentos en un .log, pero es una vulnerabilidad muy común en sistemas .nix. Y de Java, qué vamos a decir sobre su depuración que no se haya dicho mil veces.
La vulnerabilidad una vez publicada (CVE-2021-44228) ha sido corregida de inmediato, en menos de 24h, por sus desarrolladores, por lo que no hay apenas lugar a ningún tipo de incidente ni 0-day.
A pesar de ser una alerta crítica por su clasificación, no ha tenido nada que ver con las chapuzas con el ramsonware al estilo de Telefónica-Movistar.
Creo que un montón de medios de comunicación se han agarrado a su clasificación de importancia CVE para crear una noticia sensacionalista, sin tener ni idea de lo que estaban escribiendo.
La resolución ha sido inmediata. No es código abandonado, ni mucho menos. La dificultad consiste en las numerosas dependencias a parchear en todos los servidores de aplicaciones que se basan en ese código.
.
Catalin Cimpanu @campuscodi – Cybersecurity news reporter
Vulnerability notes: Log4Shell
–
Disclaimer
Programo desde los 11-12 años, no solo soy «informático de letras», y Java es un asco.
Justamente, es lo que venía a decir en mi segundo comentario… ni había que tirarse de los pelos, y la solución vino más rápida de lo que el “amarillismo” de las noticias nos querían apuntar… aunque eso sí, mis quejas siguen siendo las mismas, la falta de apoyo…
Disclaimer
No sé lo que entiendes por “Un informático de letras” …
Aprendí a programar en Ensamblador y Forth en un Rockwell AIM-65 (MOS 6502) con 14/15 años (lo usabamos para control numerico). Dos mas tarde, me hice mis propios prototipos: Zilog Z80 y Signetics 2650 (de aquellas aún estaba en Electrónica Industrial), tengo 56 (y reconozco que ahora, no seria capaz de repetirlo. Abandone electronica al irme a la mili). Si algo he aprendido en estos años, es que por muy dinosaurio que seas, siempre habrá alguien mejor… aunque sea un “friki con o sin título”, como apunta el iluminado más abajo…
Y si, Java apesta…
Completamente de acuerdo ¿Aún hay programadores que «usan»Java … ?
Os cuento, tengo un jar de un programa opensource que uso poco, de vez en cuando, y siempre pasa lo mismo que cuando lo voy a utilizar el JRE se ha actualizado, y considera que el JAR que tengo en mi DD es un peligro potencial. Y la solución que da Oracle es que el SW tiene que estar firmado… como no me da la gana entrar en sus tripas (tengo cosas más divertidas que hacer) para firmarlo o que yo como usuario entre en el centro de control de java, le baje los niveles de seguridad y poder ejecutarlo. Es parecido a lo que pasa con Office te pasan un excel que no es tuyo, y tu decides que te abres en canal o no…
Pues desde la JRE release 8u20 no puedes elegir riesgo alto en el centro de seguridad, por narices el JAR (ejecutable) tiene que estar firmado… conclusión de Oracle pensar por el usuario…
Conclusión: desinstalo el JRE y pongo una release anterior para poder ejecutar mi programa JAR de vez en cuando. Y si tengo un JRE no seguro, pero lo suficiente para mi ya que apenas lo uso…
Y updates desactivados…
Que pena de Java desde que SUN fue comprada
Un poco OffTopic… Esto te va a gustar… XDDD
Memory Map Land
… luego nos encontramos con que en la UEFA no son capaces ni de hacer un cuadrante de equipos en un folio, hacen mal un sorteo de Champions League retransmitido en directo a medio munto, y le echan la culpa al «software de un proveedor externo». Las que paga el pobre e inocente software salvando el culo a auténticos errores humanos…
«que todos los afectados sean capaces de ponerse las pilas y corregir rápidamente el potencial problema.»
«despotriquemos contra aquellos que no la entienden y que no toman las medidas adecuadas para controlar los problemas a tiempo.» (EDans).
Me lleva apensar en los psiquiatras que, desconociendo la esencia (desconocida en si) del cerebro, se dedican a meter sus manos en la mente del individuo (sea lo que eso sea), para manipular, más o menos animadamente, su software, como si fueran entendidos en la materia.
Hay mucho friki, con o sin título, que se cree algo casi divino manejando los entresijos de un algoritmo, cuando tiene problemas serios de manejo interior, en sus propios circuitos neuronales.
Nada nuevo bajo el sol, como se suele decir, ya Roma (antigua) nos enseña ejemplos de tamaños tarados. Cada nuevo emperador se creía mejor que el anterior. Y al final, el imperio hizo cataplún, sin que el «lobo bárbaro» tuviera que soplar demasiado fuerte.
¿Acaso en los valles de silicona se llora/suda menos que en los valles de lágrimas?
Siempre encuadrado en el «ethical hacking», reconozco que me fascinan los hackers capaces de encontrar estas vulnerabilidades.
Y más aún si se ganan la vida encontrándolas, reportándolas a las compañias de software y recibiendo recompensas por ello («Bounty hackers», creo que se llaman).
Hay algún libro/artículo/reportaje específico sobre estos «Bounty hackers» y como consiguen encontrar dicha vulnerabilidades?
Obviamente supongo que no hay un único método a seguir, pero quizás si que sigan algunas reglas sistemáticas básicas para encontrar vulnerabilidades en diferentes paquetes de software.
Alguna sugerencia?
Gracias de antemano!
Libros:
https://0xword.com/es/buscar?tag=hacking
PD: son los que cita siempre Chema Alonso
Muchas gracias, Carlos!
Un abrazo.
Chipi
Y si quieres herramientas, la distro kali de linux. en alguna de ellas pones chipi hot arroba gmail, ya me entiendes, y te dice hasta la marca de café que gastas en 5 minutos
:-))
Si es honrado, nunca jamas un informática dirá que sus software está libre de errores, Lo mas que puede decir, es que ha pasado con éxito una serie de pruebas.
El error del año 2000, se venía arrastrando a lo largo del siglo XX desde que se comenzo a utilizar par gestión el ordenador por los años 40 y sólo nos dimos cuenta de que ordenar por fechas era imposible con solo años de dos dígitos, cerca del año 2000.
Periódicamente aparecerán errores que haran fallar a cualquier programa y algunos manejan temas de importancia crítica, el último problema conocido de este tipo , es el de los Boing 747 Max
OFFTOPIC (o no) XDDD
El autor del manifiesto aprovecha entonces para cagarse en los algoritmos, en los trackers, en Zuckerberg, en los motores de búsqueda y en la Web 3.0 que se nos viene encima, incluyendo Meta y el metaverso, las blockchains y en Sanpitopato ya puestos. Se ha quedado agusto, vamos.
La Web está jodida. Y ya no hay nada que podamos hacer por ella. Un manifiesto