Haga clic y arrastre en las ondas sonoras de abajo para saltar a cualquier punto. Tú también puedes escuchar directamente en Soundcloud.

DOUG.  Estafas en Twitter, martes de parches y delincuentes que piratean a delincuentes.

Todo eso y más en el podcast Naked Security.

[MÓDEM MUSICAL]

Bienvenidos al podcast, todos.

soy doug

Él es Paul Ducklin.

Pablo, ¿cómo estás hoy?

PATO.  Muy bien, Doug.

No tuvimos el eclipse lunar aquí en Inglaterra, pero pude vislumbrar brevemente la luna llena *llena* a través de un pequeño espacio en las nubes que emergió como el único agujero en toda la capa de nubes en el momento en que salí para ¡echar un vistazo!

Pero no teníamos esa luna anaranjada como la que tenían ustedes en Massachusetts.

DOUG.  Comencemos el espectáculo con Esta semana en la historia de la tecnología… esto se remonta a mucho tiempo atrás.

Esta semana, el 08 de noviembre de 1895, el profesor de física alemán Wilhelm Röntgen se topó con una forma de radiación aún no descubierta que lo llevó a referirse a dicha radiación simplemente como "X".

Como en la radiografía.

¿Qué tal eso… el descubrimiento accidental de los rayos X?

PATO.  Bastante sorprendente.

Recuerdo que mi mamá me decía: en los años 1950 (debe haber sido lo mismo en los Estados Unidos), aparentemente, en las zapaterías…

DOUG.  [SABE LO QUE VIENE] ¡Sí! [RISAS]

PATO.  La gente llevaría a sus hijos… te pararías en esta máquina, te pondrías los zapatos y en lugar de simplemente decir: “Camina, ¿te quedan apretados? ¿Pellizcan?”, te paraste en una máquina de rayos X, que básicamente te bañó con radiación de rayos X y tomó una foto en vivo y dijiste: “Oh, sí, son del tamaño correcto”.

DOUG.  Sí, tiempos más simples. Un poco peligroso, pero...

PATO.  ¿UN POCO PELIGROSO?

¿Te imaginas a la gente que trabajaba en las zapaterías?

Deben haber estado bañándose en rayos X todo el tiempo.

DOUG.  Absolutamente... bueno, estamos un poco más seguros hoy.

Y hablando de seguridad, el primer martes del mes es el Patch Tuesday de Microsoft.

So que aprendimos este martes de parches aquí en noviembre de 2022?

Intercambio de 0 días fijos (por fin), ¡más 4 nuevos parches de martes de 0 días!

PATO.  Bueno, lo más emocionante, Doug, es que técnicamente el martes de parches no arregló uno, ni dos, ni tres... sino *cuatro* días cero.

Pero en realidad, los parches que podría obtener para los productos de Microsoft el martes corrigieron *seis* días cero.

Recuerde esos días cero de Exchange que notoriamente no fueron parcheados el último martes de parches: CVE-2002-41040 y CVE-2022-41082, lo que se conoció como ProxyNotShell?

S3 Ep102.5: Errores de intercambio "ProxyNotShell": habla un experto [Audio + Texto]

Bueno, eso se solucionó, pero esencialmente en una "línea lateral" separada del martes de parches: el SU de Exchange de noviembre de 2022, o Actualización de software, que solo dice:

Las actualizaciones de software de Exchange de noviembre de 2022 contienen correcciones para las vulnerabilidades de día cero informadas públicamente el 29 de septiembre de 2022.

Todo lo que tiene que hacer es actualizar Exchange.

Vaya, gracias Microsoft... ¡Creo que sabíamos que eso era lo que íbamos a tener que hacer cuando finalmente salieran los parches!

Por lo tanto, * están * fuera y hay dos días cero fijos, pero no son nuevos, y técnicamente no están en la parte "Patch Tuesday".

Allí, tenemos otros cuatro días cero fijos.

Y si crees en priorizar los parches, obviamente esos son los que quieres tratar primero, porque alguien ya sabe cómo hacer cosas malas con ellos.

Estos van desde un desvío de seguridad hasta dos elevaciones de privilegios y una ejecución remota de código.

Pero hay más de 60 parches en total, y si observa la lista general de productos y componentes de Windows afectados, hay una lista enorme, como de costumbre, que incluye todos los componentes/productos de Windows de los que ha oído hablar, y muchos de los que probablemente no haya oído hablar.

Microsoft corrige 62 vulnerabilidades, incluidas Kerberos, Mark of the Web y Exchange... más o menos

Entonces, como siempre: No se demore / Hágalo hoy¡Douglas!

DOUG.  Muy bueno.

Hablemos ahora de un retraso bastante...

Tienes una historia muy interesante sobre el Mercado de drogas de la Ruta de la Seda, y un recordatorio de que los delincuentes que roban a los delincuentes siguen siendo un delito, aunque hayan pasado unos diez años hasta que te atrapen por ello.

Hacker del mercado de drogas de Silk Road se declara culpable y se enfrenta a 20 años en prisión

PATO.  Sí, incluso las personas que son bastante nuevas en la seguridad cibernética o en Internet probablemente habrán oído hablar de "Silk Road", quizás el primer mercado de la web oscura bien conocido, grande, generalizado y ampliamente utilizado donde básicamente todo vale.

Entonces, todo eso se incendió en 2013.

Porque el fundador, originalmente conocido sólo como El temible pirata Roberts, pero finalmente se reveló como Ross Ulbricht… su poca seguridad operativa fue suficiente para atarle las actividades.

El fundador de Silk Road, Ross Ulbricht, condenado a cadena perpetua sin libertad condicional

No solo su seguridad operativa no era muy buena, parece que a fines de 2012, tuvieron (¿puedes creerlo, Doug?) un error en el procesamiento de pagos con criptomonedas...

DOUG.  [JADEOS EN FALSO HORROR]

PATO.  …del tipo que hemos visto repetido muchas veces desde entonces, que no hizo la contabilidad de doble entrada adecuada, donde para cada débito, hay un crédito correspondiente y viceversa.

Y este atacante descubrió que, si ingresa algo de dinero en su cuenta y luego lo paga muy rápidamente a otras cuentas, en realidad podría pagar cinco veces (o incluso más) los mismos bitcoins antes de que el sistema se dé cuenta de que el primer débito se había ido. mediante.

Así que básicamente podrías poner algo de dinero y luego simplemente retirarlo una y otra y otra vez, y obtener un alijo más grande...

… y luego podría volver a lo que podría llamar un “bucle de ordeño de criptomonedas”.

Y se estima... los investigadores no estaban seguros, que él comenzó con entre 200 y 2000 bitcoins propios (si los compró o los extrajo, no lo sabemos), y muy, muy rápidamente los convirtió en, espéralo, Doug: ¡50,0000 bitcoins!

DOUG.  ¡Wow!

PATO.  Más de 50,000 bitcoins, así como así.

Y luego, obviamente pensando que alguien se iba a dar cuenta, se dio a la fuga mientras iba adelante con 50,000 bitcoins...

…cada uno vale la increíble cantidad de $12, en comparación con fracciones de centavo solo unos años antes. [RISAS]

Así que se fue con $600,000, así como así, Doug.

[PAUSA DRAMÁTICA]

Nueve años después…

[LA RISA]

…casi *exactamente* nueve años después, cuando lo arrestaron y allanaron su casa bajo una orden judicial, los policías buscaron y encontraron una pila de mantas en su armario, debajo de las cuales se escondía una lata de palomitas de maíz.

Extraño lugar para guardar tus palomitas de maíz.

Dentro de la cual había una especie de billetera fría computarizada.

¡Dentro de los cuales había una gran proporción de dichos bitcoins!

En el momento en que lo arrestaron, los bitcoins costaban algo más de $ 65,535 (o 2¹⁶-1 cada uno.

Habían subido más de mil veces en el ínterin.

Entonces, en ese momento, ¡fue la mayor redada de criptomonedas de la historia!

Nueve años más tarde, aparentemente incapaz de deshacerse de sus ganancias mal habidas, tal vez con miedo de que incluso si intentara meterlas en un vaso, todos los dedos señalarían hacia él...

… ¡ha tenido todos estos bitcoins por valor de $ 3 mil millones que han estado en una lata de palomitas de maíz durante nueve años!

DOUG.  Dios mío.

PATO.  Entonces, después de haber estado sentado en este tesoro aterrador durante todos esos años, preguntándose si lo iban a atrapar, ahora se pregunta: "¿Cuánto tiempo estaré en prisión?"

¿Y la pena máxima por el cargo que enfrenta?

20 años, Doug.

DOUG.  Otra historia interesante que sucede ahora mismo. Si has estado en Twitter últimamente, sabrás que hay mucha actividad. para decirlo diplomáticamente…

PATO.  [PERSONICACIÓN DE BOB DYLAN DE CALIDAD BAJA A MEDIA] Bueno, los tiempos están cambiando.

DOUG.  …incluyendo en un momento la idea de cobrar $20 por un cheque azul verificado, que, por supuesto, casi de inmediato provocó algunas estafas.

Estafas por correo electrónico con la insignia azul de Twitter: ¡no se deje engañar por ellas!

PATO.  Es solo un recordatorio, Doug, de que cada vez que hay algo que ha atraído mucho interés, los ladrones seguramente lo seguirán.

Y la premisa de esto era: “Oye, ¿por qué no llegar temprano? Si ya tienes una marca azul, ¿adivina qué? No tendrá que pagar los $19.99 al mes si se registra previamente. Dejaremos que te lo quedes.

Sabemos que esa no fue la idea de Elon Musk, como dijo, pero es el tipo de cosas que hacen muchas empresas, ¿no?

Muchas empresas te darán algún tipo de beneficio si te quedas con el servicio.

Así que no es del todo increíble.

Como dices… ¿qué le diste?

B-menos, ¿verdad?

DOUG.  Le doy al correo electrónico inicial una B-menos... quizás te engañen si lo lees rápidamente, pero hay algunos problemas de gramática; las cosas no se sienten bien.

Y luego, una vez que haga clic, le daría a las páginas de destino C-menos.

Eso se vuelve aún más difícil.

PATO.  ¿Eso es en algún lugar entre el 5/10 y el 6/10?

DOUG.  Sí, digamos eso.

¡Y tenemos algunos consejos, de modo que incluso si se trata de una estafa A-plus, no importará porque podrá frustrarla de todos modos!

Comenzando con mi favorito personal: Utiliza un administrador de contraseñas.

Un administrador de contraseñas resuelve muchos problemas cuando se trata de estafas.

PATO.  Lo hace.

Un administrador de contraseñas no tiene ninguna inteligencia similar a la humana que pueda ser engañada por el hecho de que la imagen bonita es correcta, el logotipo es perfecto o el formulario web está exactamente en la posición correcta en la pantalla con exactamente la misma fuente. , para que lo reconozcas.

Todo lo que sabe es: "Nunca antes había oído hablar de este sitio".

DOUG.  Y por supuesto, activa 2FA si puedes.

Siempre agregue un segundo factor de autenticación, si es posible.

PATO.  Por supuesto, eso no necesariamente te protege de ti mismo.

Si va a un sitio falso y ha decidido: "Oye, es perfecto en píxeles, debe ser el verdadero negocio", y está decidido a iniciar sesión, y ya ha ingresado su nombre de usuario y su contraseña, y luego te pide que pases por el proceso 2FA...

…es muy probable que hagas eso.

Sin embargo, te da ese poco de tiempo para hacer el “Stop. Pensar. Conectar." cosa, y dígase a sí mismo: "Espera, ¿qué estoy haciendo aquí?"

Entonces, en cierto modo, el pequeño retraso que presenta 2FA puede ser no solo una pequeña molestia, sino también una forma de mejorar su flujo de trabajo de seguridad cibernética... un poco más en serio.

Así que no veo cuál es el inconveniente, de verdad.

DOUG.  Y, por supuesto, otra estrategia que es difícil de seguir para muchas personas, pero que es muy efectiva, es evite los enlaces de inicio de sesión y los botones de acción en el correo electrónico.

Entonces, si recibe un correo electrónico, no solo haga clic en el botón ... vaya al sitio mismo y podrá saber rápidamente si ese correo electrónico era legítimo o no.

PATO.  Básicamente, si no puede confiar totalmente en la correspondencia inicial, entonces no puede confiar en ningún detalle que contenga, ya sea el enlace en el que va a hacer clic, el número de teléfono al que va a llamar, la dirección de correo electrónico que Los contactaré en la cuenta de Instagram a la que enviará mensajes directos, sea lo que sea.

No use lo que está en el correo electrónico... encuentre su propio camino allí, y evitará muchas estafas de este tipo.

DOUG.  Y finalmente, por último pero no menos importante... esto debería ser de sentido común, pero no lo es: Nunca le preguntes al remitente de un mensaje incierto si es legítimo.

No respondas y digas: "Oye, ¿eres realmente Twitter?".

PATO.  Sí, tienes toda la razón.

Debido a mi consejo anterior, "No confíe en la información del correo electrónico", como no llamar a su número de teléfono... algunas personas se sienten tentadas a decir: "Bueno, llamaré al número de teléfono y veré si realmente son ellos [IRÓNICO] Porque, obviamente, si la cocinera responde, van a dar sus nombres reales”.

DOUG.  Como siempre decimos: En caso de duda/No lo des.

Y esta es una buena historia de advertencia, la próxima historia: cuando los escaneos de seguridad, que son herramientas de seguridad legítimas, revelar más de lo que deberían, ¿Qué pasa entonces?

Herramientas de escaneo de URL públicas: cuando la seguridad conduce a la inseguridad

PATO.  Este es un investigador muy conocido con el nombre de Fabian Bräunlein en Alemania... lo hemos presentado un par de veces antes.

Ha vuelto con un informe detallado titulado urlscan.ioAnuncio SOAR de SOAR: herramientas de seguridad habladoras que filtran datos privados.

Y en este caso, es urlscan.io, un sitio web que puede usar de forma gratuita (o como un servicio pago) donde puede enviar una URL, un nombre de dominio, un número de IP, o lo que sea, y puede buscar, "¿Qué sabe la comunidad ¿sobre esto?"

Y revelará la URL completa sobre la que preguntaron otras personas.

Y esto no son solo cosas que las personas copian y pegan de su propia elección.

A veces, su correo electrónico, por ejemplo, puede estar pasando por una herramienta de filtrado de terceros que extrae URL, llama a casa para urlscan.io, hace la búsqueda, obtiene el resultado y lo usa para decidir si enviar el mensaje como basura, bloquearlo como spam o pasarlo.

Y eso significa que a veces, si la URL incluye datos secretos o semisecretos, información de identificación personal, entonces otras personas que por casualidad buscaron el nombre de dominio correcto dentro de un período corto después verían todas las URL que se buscaron, incluyendo cosas que pueden estar en la URL.

ya sabes, como blahblah?username=doug&passwordresetcode= seguido de una cadena larga de caracteres hexadecimales, y así sucesivamente.

Y Bräunlein ideó una lista fascinante del tipo de URL, en particular las que pueden aparecer en los correos electrónicos, que pueden enviarse de manera rutinaria a un tercero para filtrar y luego indexarse ​​para realizar búsquedas.

El tipo de correos electrónicos que pensó que eran definitivamente explotables incluían, pero no se limitaban a: enlaces de creación de cuentas; Enlaces de entrega de regalos de Amazon; claves API; Solicitudes de firma de DocuSign; transferencias de archivos de Dropbox; seguimiento del paquete; restablecimientos de contraseña; facturas de PayPal; uso compartido de documentos de Google Drive; Invitaciones de SharePoint; y enlaces para darse de baja del boletín.

No señalar con el dedo a SharePoint, Google Drive, PayPal, etc.

Esos fueron solo ejemplos de URL que encontró y que eran potencialmente explotables de esta manera.

DOUG.  Tenemos algunos consejos al final de ese artículo, que se reducen a: lea el informe de Bräunlein; leer urlscan.ioentrada de blog de; haga una revisión del código por su cuenta; si tiene un código que realiza búsquedas de seguridad en línea; aprender qué funciones de privacidad existen para los envíos en línea; y, lo que es más importante, aprenda a informar datos no autorizados a un servicio en línea si los ve.

Me di cuenta de que hay tres... ¿una especie de quintillas?

Mini-poemas muy creativos al final de este artículo…

PATO.  [MOCK HORROR] ¡No, no son quintillas! Los limericks tienen una estructura de cinco líneas muy formal...

DOUG.  [RISA] Lo siento mucho. ¡Eso es cierto!

PATO.  ... tanto para la métrica como para la rima.

¡Muy estructurado, Doug!

DOUG.  Lo siento mucho, muy cierto. [RISAS]

PATO.  Esto es solo una tontería. [LA RISA]

Una vez más: En caso de duda/No lo des.

Y si estás recopilando datos: Si no debería estar dentro/tíralo directamente a la papelera.

Y si está escribiendo código que llama a API públicas que podrían revelar datos de clientes: Nunca hagas llorar a tus usuarios/Por cómo llamas a la API.

DOUG.  [RISAS] ¡Eso es nuevo para mí, y me gusta mucho!

Y por último, pero ciertamente no menos importante en nuestra lista aquí, hemos estado hablando semana tras semana sobre este error de seguridad de OpenSSL.

La gran pregunta ahora es, “Como puedes saber ¿Qué necesita arreglo?”

La historia de la actualización de seguridad de OpenSSL: ¿cómo puede saber qué necesita reparación?

PATO.  De hecho, Doug, ¿cómo sabemos qué versión de OpenSSL tenemos?

Y obviamente, en Linux, simplemente abre un símbolo del sistema y escribe openssl version, y te dice la versión que tienes.

Pero OpenSSL es una biblioteca de programación y no existe una regla que diga que el software no puede tener su propia versión.

Su distribución puede usar OpenSSL 3.0 y, sin embargo, hay una aplicación que dice: “Oh, no, no hemos actualizado a la nueva versión. Preferimos OpenSSL 1.1.1, porque todavía es compatible y, en caso de que no lo tenga, traemos nuestra propia versión”.

Y entonces, desafortunadamente, al igual que en ese infame caso de Log4Shell, ¿tuviste que ir a buscar a los tres? 12? 154? quién sabe cuántos lugares en su red donde podría tener un programa Log4J desactualizado.

Lo mismo para OpenSSL.

En teoría, las herramientas XDR o EDR podrían decírselo, pero algunas no lo admitirán y muchas lo desaconsejarán: en realidad, ejecute el programa para averiguar qué versión es.

Porque, después de todo, si es el buggy o el incorrecto, y realmente tienes que ejecutar el programa para que reporte su propia versión...

…eso se siente como poner el carro delante del caballo, ¿no?

Así que publicamos un artículo para esos casos especiales en los que realmente desea cargar la DLL, o la biblioteca compartida, y realmente desea llamarla propia. TellMeThyVersion() código de programa

En otras palabras, usted confía en el programa lo suficiente como para cargarlo en la memoria, ejecutarlo y ejecutar algún componente del mismo.

Le mostramos cómo hacerlo para que pueda estar absolutamente seguro de que cualquier archivo OpenSSL periférico que tenga en su red esté actualizado.

Porque aunque esto fue degradado de CRÍTICO a ALTO, ¡sigue siendo un error que necesita y desea corregir!

DOUG.  Sobre el tema de la gravedad de este error, tenemos un interesante pregunta del lector de seguridad Naked Svet, quien escribe, en parte:

¿Cómo es que un bug que es enormemente complejo para su explotación, y que sólo puede ser utilizado para ataques de denegación de servicio, sigue siendo clasificado como ALTO?

PATO.  Sí, creo que dijo algo sobre "Oh, ¿el equipo de OpenSL no ha oído hablar de CVSS?", que es un estándar del gobierno de los EE. filtrado automáticamente por secuencias de comandos.

Entonces, si tiene un puntaje CVSS bajo (que es el Sistema de puntuación de vulnerabilidad común), ¿por qué la gente se emociona al respecto?

¿Por qué debería ser ALTO?

Entonces mi respuesta fue: "¿Por qué *no* debería ser ALTO?"

Es un error en un motor criptográfico; podría fallar un programa, digamos, que está tratando de obtener una actualización... por lo que fallará una y otra vez, lo cual es un poco más que una simple denegación de servicio, porque en realidad le impide hacer su seguridad correctamente.

Hay un elemento de derivación de seguridad.

Y creo que la otra parte de la respuesta es, cuando se trata de vulnerabilidades que se convierten en exploits: "¡Nunca digas nunca!"

Cuando tiene algo como un desbordamiento de búfer de pila, donde puede manipular otras variables en la pila, posiblemente incluidas las direcciones de memoria, siempre existe la posibilidad de que alguien pueda descubrir un exploit viable.

Y el problema, Doug, es que una vez que lo han descubierto, no importa lo complicado que haya sido descubrirlo...

…una vez que sabes cómo explotarlo, *cualquiera* puede hacerlo, porque puedes venderles el código para hacerlo.

Creo que sabes lo que voy a decir: "No es que me sienta muy fuerte al respecto".

[LA RISA]

Es, una vez más, uno de esos "malditos si lo hacen, malditos si no lo hacen".

DOUG.  Muy bien, muchas gracias, Svet, por escribir ese comentario y enviarlo.

Si tiene una historia interesante, un comentario o una pregunta que le gustaría enviar, nos encantaría leerlo en el podcast.

Puede enviar un correo electrónico a tips@sophos.com, puede comentar cualquiera de nuestros artículos o puede contactarnos en las redes sociales: @nakedsecurity.

Ese es nuestro programa de hoy; muchas gracias por escuchar

Para Paul Ducklin, soy Doug Aamoth, les recuerdo hasta la próxima para...

AMBAS COSAS.  ¡Mantente seguro!