ESCUCHA AHORA
Haga clic y arrastre en las ondas sonoras de abajo para saltar a cualquier punto. Tú también puedes escuchar directamente en Soundcloud.
Con Doug Aamoth y Paul Ducklin. Música de introducción y salida de Edith Mudge.
Puedes escucharnos en SoundCloud, Podcasts de Apple, Podcasts de Google, Spotify, Stitcher y en cualquier lugar donde se encuentren buenos podcasts. O simplemente suelta el URL de nuestro feed RSS en tu cazador de vainas favorito.
LEER LA TRANSCRIPCIÓN
DOUG AAMOTH. JavaScript, NetUSB, Log4Shell, FTC...
Todo eso y más: es el podcast Naked Security.
[MÓDEM MUSICAL]
Bienvenidos al podcast, todos.
Yo soy paul; el es doug...
PABLO PATO. [RISA] Creo que cometiste un verdadero error, ¿no?
DOUG. Yo si.
PATO. En realidad no era una broma.
DOUG. *Soy* Doug... Estoy en piloto automático, como siempre, durante el primer minuto del espectáculo.
PATO. Bueno, vamos a estar hablando de muchos errores de software... es fácil cometer ese tipo de error.
DOUG. Tenemos mucho de qué hablar, así que vamos a entrar en materia.
Hoy tenemos algo así como una ronda relámpago; un montón de historias para cubrir.
Y como saben, nos gusta comenzar el espectáculo con una Fun Fact: si eres supersticioso sobre el viernes trece, no estás solo a menos que vivas en Grecia, España o Italia.
Grecia y España consideran el martes XNUMX como el día más desafortunado; Los italianos desconfían del viernes diecisiete; y Paul, como sabes, uniremos esto de nuevo en el Esta semana en la historia de la tecnología segmento más adelante en el programa.
PATO. ¡Triskaidecafobia!
DOUG. Lo he visto escrito en algunos lugares, y me alegro de que lo hayas dicho en voz alta porque es casi imposible de leer si no lo has escuchado antes...
PATO. Τρισκαίδεκα… es solo la palabra griega antigua para trece, con la palabra miedo.
Entonces, en realidad, ese es el miedo a los trece, en lugar de necesariamente solo el viernes trece, pero van juntos.
DOUG. Un día en el que suceden cosas espeluznantes y extrañas.
Y hablando de espeluznante y extraño, ¡la historia de este "desarrollador de JavaScript" es salvaje!
PATO. No sé si da miedo, pero sí, es raro. Quizás un poco triste.
DOUG. Entonces, ¿qué pasó aquí?
PATO. Bueno, fue lo que podría llamarse un ataque a la cadena de suministro, donde las personas absorben código escrito en JavaScript en sus proyectos, desde NPM o GitHub, o donde sea que lo obtengan, desde un módulo de código abierto que consumen muchos proyectos diferentes, emitidos bajo la licencia MIT Open Source.
Por lo tanto, puede usarlo libremente, siempre que no reclame que es suyo; incluso puede usarlo en código comercial.
Y el desarrollador de dos de estos proyectos, faker.js y colors.js, de repente decidió que ya había tenido suficiente.
Había dado algunos indicios, hace un par de años, de que estaba un poco cansado de hacer todo este trabajo y que no le pagaran...
…como la famosa caricatura de XKCD, Doug.
DOUG. [RISAS]
PATO. “Todo está respaldado por este pequeño y delgado pilar del programa, mantenido incansablemente por una persona al azar en Nebraska desde 2003” – *esa* caricatura de XKCD.
DOUG. Sí.
PATO. Este tipo obviamente decidió: "Bueno, ya tuve suficiente".
Entonces, para faker.js, básicamente desconectó todo: eliminó todo el código fuente.
Creó, por así decirlo, una versión final del proyecto que no tiene código fuente; tiene el comentario “Endgame”; y simplemente dice en el LÉAME, "¿Qué le pasó a Aaron Schwartz?"
Fue el famoso hacktivista que, lamentablemente, se suicidó después de ser arrestado por tomar una gran cantidad de archivos: documentos académicos que, en su opinión, no deberían estar detrás de un cortafuegos, pero la ley consideró lo contrario.
Así que eso es lo que hizo con este faker.js
Y aunque es un nombre extraño para el programa, en realidad fue algo muy útil porque crea datos falsos para ti.
Hablaste de eso en un podcast reciente, ¿verdad, Doug?
Sobre la importancia de no utilizar datos reales para no meterse en problemas de privacidad.
Bueno, desconectó ese, así que si actualizaste a la última versión, todo desapareció.
No tienes que actualizar, legalmente puedes seguir usando el anterior, pero está claro que ha decidido que es hora de salir de Dodge City.
Pero con colors.js... lamentablemente, adoptó un enfoque menos comprensible, ya que emitió una nueva versión que incluía un bucle infinito, básicamente haciendo que imprimiera basura de aspecto extraño cuando lo ejecutabas, en lugar de simplemente permitirte agregar colores a la salida de su consola.
Ya sabes cómo a la gente le gustan los colores para resaltar palabras como ERROR, ADVERTENCIA, lo que sea.
Pero si aceptara esta actualización automáticamente, como parte de lo que podría llamar su cadena de suministro, de repente su programa sufriría una Denegación de servicio porque entraría en este bucle que se ejecutaba desde un valor inicial de 666...
DOUG. [RISAS]
PATO. …hasta, pero sin incluir, el valor de JavaScript Infinity.
Este ciclo imprime "prueba, prueba, prueba, prueba, prueba" con una gran cantidad de basura agregada.
Podrías decir que no fue algo muy agradable de hacer, pero no tenías que aceptar la nueva versión, y el código estaba allí para que lo vieras: no estaba oculto de ninguna manera.
Es de código abierto, puedes ir y revisarlo.
De todos modos, algunas personas se vieron afectadas y tuvieron que volver a la versión anterior, y esto inició toda una cadena de comentarios en su cuenta de GitHub.
Creo que ha sido bloqueado de su cuenta de GitHub, tal vez comprensiblemente, pero hay cientos de comentarios allí.
Algunas personas dicen: "Sí, estoy contigo, hermano"; Entiendo de dónde vienes”, y otras personas diciendo: “¿Sabes qué? Probablemente un paso demasiado lejos.
DOUG. Piense en cuántos paquetes de software comerciales se basan en cosas como esta...
PATO. Casi dices Log4j allí, Doug.
DOUG. [RISAS] Hablemos de eso un poco más tarde.
PATO. Bueno, me pregunto si el momento de esto quizás no fue precipitado por el alboroto sobre Log4j>
¿Quizás eso fue lo que provocó a este tipo?
Porque tengo entendido que intentó comercializar el kit de herramientas faker.js, que es muy útil; un cuerpo de código bastante sustancial que podría crear datos realistas de todo tipo.
Intentó comercializarlo y crear servicios en línea que las personas que quisieran pudieran pagarle, pero parece que eso no funcionó para él, por lo que no era realmente sostenible.
Así que desconectó ese.
Pero desafortunadamente, envenenó el pozo en el otro proyecto, y ahí es donde estamos.
DOUG. Supongo que esto resurge la cuestión de la idea de un Lista de materiales del software, o una lista de ingredientes, por así decirlo, para consumidores o personas que van a comprar su software...
…para que puedan ver cuántos componentes de código abierto tiene o de dónde proviene todo.
PATO. Sí, tal vez ese es el lado positivo de esto.
Log4j no resolvió el problema subyacente: esa función se agregó a Log4j, ¿qué, en 2013?
Y nadie lo notó hasta ahora, y luego, cuando lo hicieron, "Oh, Dios mío, ¿cómo te atreves?"
Bueno, introdujiste el código en tu software hace años y años sin darte cuenta de que tenía este problema, y no pagaste por él; tal vez sea un poco exagerado sugerir que fue culpa de alguien más que de usted, porque lo atraparon.
Así que tal vez el lado positivo sea que, aunque se podría decir que fue algo un poco infantil, tal vez nos ayude a todos a aceptar, como usted dice, una Lista de materiales del software – “ingredientes enumerados”.
Tal vez sea una buena idea.
DOUG. Muy bien, mucha buena discusión allí.
esa historia se llama El desarrollador de JavaScript destruye sus propios proyectos en la "lección" de la cadena de suministro en nakedsecurity.sophos.com
Así que puedes acercarte a leer y opinar.
Y ahora vamos a hablar de NetUSB.
Recuerdo la emoción de conectar mi impresora directamente al enrutador de mi casa a través de USB, hace muchos años y decir: “¡Guau, lo logramos! ¡La tecnología finalmente ha alcanzado su ápice!”
PATO. NetUSB es un producto cuya licencia puede obtener de una empresa de Taiwán llamada Kcodes.
Afirman en su material de marketing que más del 20% de los dispositivos de red en todo el mundo tienen código Kcodes integrado en ellos ahora, por lo que parece que han tenido bastante éxito.
Y NetUSB es, por así decirlo, un virtualizador USB genérico.
Por lo tanto, no se trata solo de que pueda conectar un disco duro centralizado o NAS, o una impresora, como lo hizo.
NetUSB puede manejar otras cosas como sintonizadores de TV, dispositivos de audio, todo tipo de cosas, de forma centralizada.
Entonces, hay una especie de cable USB virtual que se ejecuta en su red, entre su computadora y (desafortunadamente) un controlador de kernel especial en su enrutador...
…un controlador que resultó tener un error que, en teoría, podría haber permitido que casi cualquier persona se hiciera cargo de su enrutador.
Oh querido.
DOUG. Oh querido, de hecho.
PATO. Entonces, ese error fue encontrado por un investigador llamado Max van Amerongen en Sentinel One.
Aparentemente, estaba buscando participar en la competencia de piratería informática Pwn2Own IoT para 2021.
Vio que Netgear tenía un dispositivo en la lista, por lo que pensó: “Oh, he mirado esos dispositivos antes; Déjame ver."
Descubrió que había un controlador de kernel que escuchaba en el puerto TCP 20005... ese número parece ser arbitrario, por lo que no es un indicador confiable de que tiene este problema, pero podría ser un punto de partida si sabe cómo escanear puertos. .
Y Max pensó: “Oye, ¿lista de controladores del kernel en todas las interfaces de red: localhost, LAN y WAN? Si hay una vulnerabilidad allí, podría ser remotamente explotable. Ahí es donde voy a empezar a centrarme”.
Y entonces investigó el código allí.
Como se puede imaginar, algo como NetUSB: tendrá muchas funciones diferentes que admitirá.
Si piensas en HTTP, bueno, tiene docenas de comandos: GET, POST, HEAD, OPTION... pero algo como NetUSB, con docenas de tipos diferentes de dispositivos, con docenas de funciones diferentes, probablemente admita cientos de comandos diferentes.
Y descubrió que el comando 0x805F, creo que es arbitrario, 32863...
Ese comando, cuando procesó los datos que se le iban a enviar, tenía un pequeño error desagradable, Douglas, relacionado con el número 17.
Básicamente, el error es así.
Cuando desee ejecutar este comando, el comando tiene algo que ver con un mensaje; No sé qué hace el comando, porque en realidad es el preprocesamiento lo que causa el problema, no el comando en sí...
…lo primero que hace el controlador del kernel es decir, “OK, voy a necesitar algunos datos de usted. Dime cuántos datos vas a enviar”, y acepta un valor de cuatro bytes. (Puedes ver a dónde va esto...)
Entonces asigna esa cantidad de memoria.
Ahora, eso suena mal porque no hace una verificación de longitud.
¿Qué pasa si la persona dice: "Oh, quiero asignar tres gigas de RAM?" [LA RISA]
Bueno, imagina, en el enrutador doméstico promedio, simplemente no va a funcionar, y fallará con gracia.
El problema es que si dices "Quiero 4 GB menos un byte", en otras palabras FFFFFFFF en hexadecimal.
Luego, en lugar de intentar asignar tantos bytes, lo que claramente no funcionará porque un enrutador de 32 bits no tendrá 4 GB de RAM a su disposición...
… lo que haría el código, diría: “Bueno, voy a asignar tanta memoria como quieras en caso de que necesites tanta, incluso si no la usas. Y necesito 17 bytes adicionales para mi propio uso temporal”.
Por lo tanto, asignaría un entero positivo sin signo muy, muy grande *más 17 bytes* de memoria.
Esto daría la vuelta al estilo del millennial bug o del cuentakilómetros de un coche.
Entonces, un atacante podría decir: "Quiero que me asigne 4GB-1 bytes de RAM, y eso significará que puedo enviarle mensajes de cualquier tamaño hasta esa cantidad en el futuro".
Pero el núcleo asignaría un búfer de solo 16 bytes, debido al desbordamiento de enteros.
Luego, el kernel diría: "Bien, envíame tus datos", y tú los envías tanto como quieras...
Por supuesto, si luego le envía más de 16 bytes, que es accidentalmente todo lo que asignó, ¡tiene un desbordamiento de búfer dentro del núcleo!
Gracias por venir; juego terminado.
DOUG. Bien, ¡parece que tenemos que esperar una actualización de firmware!
PATO. Bueno, la buena noticia es que esto fue divulgado responsablemente.
La razón por la que solo se escribió sobre este año, a pesar de que el trabajo se realizó a mediados de 2021, es que esto se reveló de manera responsable a la empresa que fabrica el producto NetUSB, y luego a todos los proveedores que podrían otorgar licencias para sus productos. productos
Entonces, todos sabían que existía este error y que necesitaban solucionarlo.
Por lo tanto, se reveló responsablemente y los parches están disponibles.
El único problema es: ¿cómo encuentras si eres vulnerable?
Como mencioné anteriormente, podría intentar usar un programa como Nmap o algo así, un escáner de puertos y ver si tiene el puerto 20005 abierto en su enrutador, lo que sería una buena pista de que podría tener esto, porque así es como el investigador lo encontró en primer lugar.
Pero, por supuesto, eso es solo un síntoma: si tiene ese puerto abierto o cerrado, no significa que tenga o no el error.
Por lo tanto, si tiene un enrutador compatible con esta función NetUSB, que le permite conectar no solo impresoras sino casi cualquier dispositivo USB de forma centralizada, vaya al sitio web del proveedor del enrutador y verifique si hay una actualización.
DOUG. Bien, tenemos otros consejos que pueden ayudarnos a mitigar ese tipo de malversación en el futuro.
PATO. Sí, el otro consejo que pusimos en el artículo no fue para los usuarios de enrutadores domésticos que podrían estar en riesgo, donde realmente todo lo que podemos decir es: “Parche temprano, parche a menudo; verifique si hay un parche disponible”.
Ponemos algunos consejos para los programadores: tres cosas rápidas.
En primer lugar, no escuche en todas las interfaces de red de forma predeterminada, a menos que realmente lo necesite.
En segundo lugar, siempre verifique los resultados de la aritmética de enteros, especialmente cuando se relaciona con la asignación de memoria.
Y el tercer consejo es verificar el subdesbordamiento de enteros, así como el desbordamiento de enteros.
Si te imaginas correr el odómetro de un auto de la vieja escuela al revés, el número antes de 000000 es 999999, no -1, porque los odómetros de los autos no pueden hacer números negativos.
No piense: "Seguramente habrá 17 bytes libres", porque es posible que no haya...
…usted se lo debe a sus usuarios para comprobar.
DOUG. DE ACUERDO.
El articulo es: Los enrutadores domésticos con soporte NetUSB podrían tener un agujero crítico en el kernel, en www.sophos.com
Ahora es el momento de Esta semana en la historia de la tecnología!
Hablamos sobre el viernes trece antes en el programa...
PATO. Tengo una idea de adónde va esto, y creo que se relacionará con virus informáticos, Doug. [LA RISA]
Esa es mi sospecha…
DOUG. ¿Como supiste? [LA RISA]
Esta semana, el viernes 13 de enero de 1989, el virus Friday the Thirteenth infectó computadoras en toda Gran Bretaña.
Este no fue el primer virus del viernes trece, y puede o no haber sido una variante del llamado virus de Jerusalén anterior, que era un virus bomba de relojería que iba a estallar a partir del viernes trece de mayo. 1988, que fue el viernes trece más reciente antes de enero de 1989.
Ambos virus ralentizaban las máquinas, pero dejaban en paz a COMMAND.COM.
Y Paul, tienes un gran color sobre todo esto porque lo viviste. "Tú estabas allí, hombre".
PATO. ¡Cómo se repite la historia!
Muchas lecciones de esos días podemos retomarlas en estos días, pero la de COMMAND.COM es bastante interesante.
De memoria, uno de los primeros virus que infectaron archivos en el mundo de DOS (creo que puede haber sido el virus Lehigh de los EE. UU.) era muy obvio, porque cuando infectó el archivo COMMAND.COM, solo había unas pocas variantes de COMMAND.COM, y algunas personas habían memorizado el tamaño de ese archivo.
Entonces, rápidamente se corrió la voz: “Oye, este asunto de los virus es trivial de tratar. Todo lo que tienes que hacer es observar el tamaño de COMMAND.COM y, si cambia, ¡tienes un virus!”.
Y la inferencia que se invitó a la gente a hacer fue: si *no* cambia, *no* tienes* un virus.
Entonces, ¿qué comenzaron a hacer los creadores de virus casi de inmediato?
DOUG. [RISAS]
PATO. Infectaron todos los archivos *excepto* COMMAND.COM, porque ese era en el que todos se estaban enfocando.
Pero sí muestra que esta era una era diferente... cuando podías nombrar un virus como una *ciudad* entera, asumiendo que había tan pocos virus que ¿cuál es la probabilidad de que alguna vez fuera otro del mismo lugar?
DOUG. Sí, los tiempos cambian, y no siempre para mejor.
Hablando de cambios en los tiempos, parece que Honda está teniendo su propio pequeño momento Y2K o, sin darse cuenta, construyó algo que funciona como una máquina del tiempo.
PATO. Me encanta tu trabajo allí, Doug, es una muy buena transición.
DOUG. Gracias!
PATO.Sabía lo que vendría después, y no lo predije.
Sí, la máquina del tiempo de Honda.
Definitivamente es volver al pasado, ¿no es así? No Regreso al futuro.
Aparentemente, los propietarios de autos Honda de cierta edad, no nuevos, ni viejos tampoco; los autos tienen que tener aparentemente alrededor de una década de antigüedad...
…el día de Año Nuevo de 2022, cuando la gente encendía sus autos, después de un rato el reloj se atrasaba alrededor de la medianoche del 01 de enero de 2002.
Y no debería decir esto, porque es algo cruel de hacer, pero voy a decir que si no puedes recordar 2002...
DOUG. Ay, no, no, noooooooooooo….
PATO. ¿Se me permite hacerlo?
DOUG. ¡No!
PATO. Digamos que había una canción en las listas con letras que decían: "La la la, la la la la-la, la la la la-la la la-la", de la diminuta estrella pop australiana Kylie Minogue: así es como muy atrás hemos ido.
Y nadie sabía muy bien por qué.
La mejor conjetura hasta ahora parece ser que se relaciona con lo que se conoce como giro de GPS, de la misma manera que el error Millennium fue causado por personas que decían: “¿Sabes qué? Solo vamos a inferir 19 y usaremos dos dígitos para el año”.
Bueno, por supuesto, el GPS se inventó en la década de 1970 y el ancho de banda de estos satélites lejanos es muy, muy limitado.
Y pensaron, bueno, lo que haremos es correr en intervalos de 1024 semanas en lugar de años.
Entonces, hay un "número de semana" y solo hay 10 bits disponibles para el número de semana.
Entonces, cada 1024 semanas, los dispositivos GPS de la vieja escuela vuelven a lo que podría llamarse el Día Cero.
Yo los llamo “kiloweekaries”,” y esos kilowwekaries van desde 1980 hasta 1999; 1999 a 2019; y 2019 a 2039.
Ahora, hubo un infame reinicio de kilosemana el 06 de abril de 2019, donde las personas con receptores GPS antiguos se preguntaban: "¿Volverán a 1999?"
Algunos lo hicieron, otros no.
Pero, por supuesto, al igual que el Millenium Bug, no tiene que ser golpeado por esto *solo en el período exacto de reinversión*.
Como recordarán, con el error Millennium, lo que hizo una gran cantidad de software fue asumir cualquier cosa antes de 50 en realidad se refería al próximo milenio.
Por lo tanto, 50 significa 1950, pero 49 significa 2049, por lo que todavía tiene un error de Millennium, pero lo cambia un poco.
DOUG. ¡Deja que las generaciones futuras se encarguen de ello!
PATO. Absolutamente.
Por supuesto, puede hacer eso con el giro del GPS, y eso es lo que hace una gran cantidad de software.
¿Cómo sabes qué fecha de inicio usar? Bueno, la forma obvia de hacerlo es usar la hora, la fecha o el año en el que compila el software que se está ejecutando actualmente en el dispositivo GPS, porque eso nunca puede retroceder.
Entonces, puede hacer una comparación que diga: "No espero que este software entre en juego antes de, digamos, 2003. Entonces, si alguna vez veo un año anterior a 2003, simplemente asumiré que estoy fuera de rango."
Y lo que estás haciendo es virar algunos días, semanas, meses, años desde el comienzo de un período GPS de 1024 semanas, aproximadamente 20 años; 19 años, siete meses y medio….
… básicamente estás tomando algunos días y los cambias al final del período kilosemanal actual.
Y la sugerencia es que eso pudo haber sido lo que atrapó a Honda aquí.
La razón por la que supongo que ese es el caso es que un lector de The Register, que es una publicación de TI popular en el Reino Unido, comentó allí que tenía un Honda CR-V que se vio afectado por esto, y cada vez que enciende su automóvil , el tiempo retrocede hasta el 01 de enero de 2002, como si el reloj no supiera qué hacer.
Entonces, está eligiendo el inicio del año como predeterminado. (Pero luego, por supuesto, debido a que el reloj es alimentado por GPS, no puede configurarlo manualmente).
En este caso, parece como si supiera cuál es la hora correcta, pero no sabe qué año es, por lo que calcula: "Comenzaré a medianoche, más o menos, más o menos". sea cual sea la zona horaria en la que creo que estás”.
Aparentemente, este tipo descubrió que su GPS pensó que era mayo de 2002, hace casi exactamente 1024 semanas, lo que le hizo pensar que esto huele a volcado de GPS.
DOUG. Interesante.
PATO. Y esa es la mejor conjetura que se me ocurrió sobre cómo sucedió esto: que es causado por algo como el error Millennium, pero relacionado con una limitación que se incorporó al GPS, comprensiblemente, en la década de 1970, porque cada bit cuenta cuando usted tiene que conseguirlo de forma fiable a través del espacio.
Entonces, ¿quién sabe qué pasó, Doug?
Pero es una indicación para cualquier programador de que, cuando estás escribiendo código hoy, y piensas: "¿Cuál es la probabilidad de que el código que estoy generando hoy todavía esté en uso en 2042?"...
…la respuesta es *probablemente* no, pero muy *posiblemente* podría serlo.
DOUG. ¡Nunca sabes!
PATO. Y por lo tanto, las decisiones que tomes hoy realmente podrían afectar a las personas en el futuro.
DOUG. “Por favor, piensa en los niños”, ¿sabes a lo que me refiero?
PATO. ¡Exactamente!
Como demostró el error del milenio; como lo demuestran errores como este: 20 años es mucho tiempo, pero también bastante poco tiempo, cuando se trata de la longevidad del software de computadora.
DOUG. Absolutamente.
Muy bien, esa es una historia fascinante. Tenemos algunos buenos comentarios, así que ven y lee todo al respecto: Autos Honda en flashback a 2002: "No puedo sacarte de mi cabeza".
Y ahora tengo ese gusano del oído….
PATO. ¡Tu lo dijiste! No creo que en realidad usé esas palabras.
Solo dije, [CANTA, DESVANECIENDO GRADUALMENTE] “La la la, la la la la-la/La la la, la la…”
DOUG. No nos gusta decepcionar aquí, pero lamentablemente no tenemos ningún error de Apple...
PATO. [ANSIO] ¡Me he desparasitado!
DOUG. ¿Te has engañado a ti mismo?
No tenemos una historia de errores de Apple esta semana, pero sí que no podemos ofrecer una historia de Log4Shell.
Tal vez esa sea nuestra nueva historia de la burbuja de Apple: tenemos un par de ellas.
PATO. Espero que Log4j me quite esa canción de la cabeza porque realmente me he engañado a mí mismo, Doug, y realmente no puedo quejarme, ¿verdad?
DOUG. ¡No señor!
PATO. Aaaargh.
Muy bien, no es exactamente Log4j de nuevo, pero es un recordatorio importante.
Como saben por el podcast de la semana pasada, hablamos sobre cómo el sector público de EE. UU. decretó: “La noche antes de Navidad: deberás terminar esto para entonces. No lo dejes. Hazlo hoy. No va a desaparecer por sí solo”.
Bueno, venga el Año Nuevo; Viene la Comisión Federal de Comercio: la FTC es básicamente la organización de derechos del consumidor de los EE. UU., y ha presentado un pequeño recordatorio bastante contundente y cuadrado para las empresas que operan en las jurisdicciones de los EE. UU.
Incluso si es víctima de un delito cibernético, si hubiera podido evitarlo aplicando un parche y fuera razonable esperar que lo hubiera hecho, también podría ser responsable.
Fueron bastante contundentes en lo que dijeron, y la advertencia incluye estas palabras, Doug: “La FTC tiene la intención de utilizar toda su autoridad legal para perseguir a las empresas que no toman medidas razonables para proteger los datos de los consumidores de la exposición como resultado de Log4j o vulnerabilidades conocidas similares en el futuro”.
DOUG. Whoa!
PATO. ¡No es solo que Naked Security diga: "Parche temprano, parche a menudo"!
Es la FTC recordándote que la simpatía solo llega hasta cierto punto, y que puedes ser víctima y autor de un delito cibernético por la misma razón, es decir, no haber parcheado.
Deja entrar a los ladrones, y lo lamentaremos.
Pero si permite que los ladrones entren donde se esperaba razonablemente que los mantuvieras alejados, tomando las precauciones que francamente todos los demás tomaron, entonces tal vez tengas que cargar con la lata para algo de eso.
DOUG. Bien, entonces cuando dicen "Log4j o vulnerabilidades similares conocidas en el futuro", no mucho después de eso, tuvimos una vulnerabilidad similar con este error H2.
PATO. Sí, sorprendentemente similar a Log4Shell.
Y, de hecho, lo encontraron investigadores que buscaban en el código Java tipos de programación similares que condujeron a la vulnerabilidad Log4Shell en primer lugar.
Este error, CVE-2021-42392, fue descubierto por una empresa de gestión de la cadena de suministro llamada JFrog.
Decidieron, "Oye, vamos a revisar todo el código Java que podría contener un uso similar de esta cosa JNDI" - esto Interfaz de nombres y directorios de Java que resultó ser abusable en el error Log4j.
Y si recuerdas JNDI, eso es lo que realmente dices: “Oye, quiero que busques estos datos. Oh, no tengo los datos, pero te enviaré una URL para algunos datos; de hecho, te enviaré una URL para un programa: ejecuta el programa y mira lo que te dice”.
JFrog, supongo, se preguntaba cuántos otros programas tienen partes de su código donde esta funcionalidad de búsqueda de nombre JNDI podría usarse y quizás sobreutilizarse.
Desafortunadamente, rápidamente encontraron uno en un popular motor de base de datos Java SQL llamado H2.
Ahora, tengo que ser honesto, Doug, no había oído hablar de H2 antes.
DOUG. No yo tampoco.
PATO. He oído hablar de MySQL, PostgreSQL, SQLite, todo el material de la base de datos No-SQL.
Pero nunca había oído hablar de H2 por la misma razón por la que nunca había oído hablar de Log4j: todo su reclamo de fama era que era algo que era lo suficientemente compacto como para que, a diferencia de, digamos, MySQL o Microsoft SQL, donde ejecutas un servidor y conéctese a él. Oye, puedes absorberlo en tu aplicación, tener H2 como parte de tu aplicación.
DOUG. ¡Genial!
PATO. Es otra de esas cosas en las que las aplicaciones que podrías haber instalado podrían haber incluido esto, al igual que las aplicaciones de Java podrían haber incluido Log4j.
La mala noticia es que el error funciona casi exactamente de la misma manera que la vulnerabilidad de Log4Shell: obtienes esta cosa de JNDI y, en lugar de simplemente hacer una búsqueda local, dices: “Oye, ¿sabes qué? Para la búsqueda, aquí hay una URL; vaya y obtenga este archivo de clase Java y ejecútelo”.
Así que es la misma secuencia de eventos que lleva a la explotabilidad.
Esa es la mala noticia.
La buena noticia es que, por lo que puedo decir, la única forma realista en que un atacante podría explotar esto es si pudiera ingresar y modificar el archivo de configuración para este componente H2 en una de las computadoras en su red.
En otras palabras, es más una elevación de privilegios o un truco de movimiento lateral que una ejecución remota de código.
Porque, aunque podría usarlo para la ejecución remota de código si el agujero estuviera abierto, tendría que obtener acceso local para abrir todo el acceso remoto, si sabe a lo que me refiero.
DOUG. Sí.
PATO. En otras palabras, tienes que entrar en la red para poder entrar en la red.
Sin embargo, es algo que desea parchear, porque es una característica que estaba allí por error, al igual que el problema de Log4Shell.
Entonces, sigue siendo un error con los parches; simplemente no es la catástrofe potencial de ejecución remota de código que vimos con Log4Shell.
DOUG. Bien, tenemos algunos consejos.
Si sabe que tiene una aplicación que ejecuta el motor de base de datos H2, puede actualizar a la versión 2.0.206; o si no está seguro, puede buscar instancias del código H2 en su red.
PATO. Sí, eso es un poco como el problema de Log4j, ¿no?
Cuando la gente se detuvo a pensar en ello, se dieron cuenta de que en realidad no sabían cuántas aplicaciones tenían que estaban en Java para empezar; y luego no sabían cuántos de ellos habían incluido Log4j.
Cuando fueron a buscar, encontraron: "Dios mío, hay muchas más aplicaciones Java de las que pensábamos, y muchas de ellas tenían Log4j".
Lo mismo con este H2: podría estar en un acto de aplicación sin que te des cuenta.
DOUG. Ahí está de nuevo la Lista de materiales: ¡necesitamos esa Lista de materiales!
PATO. ¡Exactamente!
Entonces, como hiciste con Log4j, donde estabas buscando log4j DASH lo que sea...
…aquí puede buscar archivos llamados h2 DASH STAR DOT jar, eso es Java Archive.
Cuando aparezcan esos archivos, si tiene alguno, probablemente aparecerá algo como h2 DASH dos DOT cero DOT algún número u otro DOT jar.
Y como dijiste, Doug, lo que estás buscando es 2.0.206 o posterior.
DOUG. OK, salten a ello, todo el mundo!
Eso es llamado Agujero de seguridad similar a Log4Shell encontrado en el popular motor de base de datos Java SQL H2, en nakedsecurity.sophos.com.
PATO. Y no nos creas que tienes que saltar hacia él. ¡Tómalo de la FTC!
DOUG. ¡Sí, en serio! [RISAS]
PATO. No quiero decir que estén amenazando a la gente, pero están diciendo: "Importa".
DOUG. Están "instando encarecidamente".
Y puede leer más sobre eso en nakedsecurity.sophos.com: La FTC amenaza con emprender acciones legales por Log4j sin parches y otras vulnerabilidades.
Y a medida que completamos el espectáculo, es hora de que ¡Oh! ¡No! de la semana.
El usuario de Reddit LordDragon24Aug965, escribe...
PATO. Ese es el nombre completo?
DOUG. Ese es el nombre completo, sí.
PATO. Hazlo de nuevo, no lo entendí todo...
DOUG. Señor Dragón24 de agosto de 1965…
PATO. [SARCÁSTICO] Ese no sería su cumpleaños, ¿verdad?
DOUG. Puede ser, porque comienza diciendo: “En los viejos tiempos…” [RISAS]
Yo era el único técnico de soporte telefónico para una de las omnipresentes casas de clones de PC que solía anunciarse en las revistas de informática.
Habíamos vendido 200 computadoras a una compañía de software y la primera fue directamente a un vicepresidente de la compañía para que la probara mientras construíamos el resto del pedido.
El representante de ventas vino a mí lleno de pánico y me dijo que la máquina, que había probado antes de salir de la tienda, no encendía.
Llamé al vicepresidente que dijo que no había luces en la máquina.
Les pedí que miraran la parte de atrás y vieran si el ventilador de la fuente de alimentación, el único ventilador en esos días, estaba girando.
Me dijo que esperara, que tenía que encender la luz.
¿No lo sabrías?
Lo había enchufado a un tomacorriente con interruptor.
Y Paul, me interesa saber si esto tiene sentido para ti...
Termina diciendo: "El representante de ventas me compró el almuerzo para ahorrar su comisión".
¿Tienes un concepto de "toma de corriente conmutada" en tu cuello del bosque?
PATO. De hecho, creo que en todas las jurisdicciones que he vivido en mi vida…
…No me he encontrado con el fenómeno de una toma de corriente *sin interruptor*.
DOUG. ¡Ah, así es, sí!
PATO. Por razones de seguridad, ¿por qué no tener un interruptor para poder apagarlo?
Es particularmente relevante en el Reino Unido, donde usamos redes de anillo: si una salida está activa, todas están activas.
Así que tenemos puntos de venta que, según tengo entendido, están cambiados por ley.
Lo extraño que tenemos, en dos de los países en los que he vivido, tienen la regulación, no creo que la tengas en los EE. UU., que no se permiten interruptores de luz dentro del baño.
DOUG. Interesante.
PATO. Tiene que tener un interruptor de luz normal fuera del baño o, más comúnmente en el Reino Unido, tiene un interruptor de tiro donde el interruptor está en el techo y es operado por una cuerda que no conduce electricidad.
Pero no está permitido un interruptor, o un tomacorriente, en un baño.
DOUG. ¡Interesante!
Bueno, aprendí mucho hoy, así que gracias por iluminarme sobre esto y todas las otras cosas de las que hablamos.
Y si tienes un ¡Oh! ¡No! te gustaría enviar, nos encantaría leerlo en el podcast.
Puede enviar un correo electrónico a tips@sophos.com; puedes comentar cualquiera de nuestros artículos; o puede contactarnos en social@NakedSecurity.
Ese es nuestro programa de hoy, muchas gracias por escuchar.
Para Paul Ducklin, soy Doug Aamoth y les recuerdo, hasta la próxima, que...
AMBAS COSAS. ¡Mantente seguro!
[MÓDEM MUSICAL]
