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

DOUG. Se capturó el código de la compañía criptográfica, se vulneró el juego de pago por 2FA de Twitter y GoDaddy.

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

[MÓDEM MUSICAL]

Bienvenidos al podcast, todos.

Soy Doug Aamoth; el es paul patito

Y es el episodio 123, Paul.

¡Lo hicimos!

---

PATO. ¡Lo hicimos!

¡Súper, Doug!

Me gustó tu aliteración al principio…

---

DOUG. Gracias por eso.

Y tienes un poema más adelante, esperaremos con gran expectación por eso.

---

PATO. Me encanta cuando los llamas poemas, Doug, aunque en realidad son tonterías.

Pero llamémoslo un poema...

---

DOUG. Sí, llamémoslo un poema.

---

PATO. Las dos líneas… [RISAS]

---

DOUG. Exacto, eso es todo lo que necesitas.

Mientras rime.

Comencemos con nuestro Historia de la tecnología segmento.

Esta semana, el 19 de febrero de 1971, se emitió lo que se cree que es la primera orden judicial en los EE. UU. para registrar un dispositivo de almacenamiento informático.

La evidencia de robo de secretos comerciales condujo a la búsqueda de tarjetas perforadas de computadora, hojas impresas de computadora y banco de memoria de computadora y otros dispositivos de almacenamiento de datos impresos magnéticamente con el programa de computadora patentado.

El programa en cuestión, un programa de trazado remoto, fue valorado en $15,000 y finalmente se determinó que un ex empleado que aún tenía acceso al sistema había llamado y usurpado el código, Paul.

---

PATO. Me sorprendió cuando vi eso, Doug, dado que recientemente hablamos en el podcast sobre intrusiones y robos de código en muchos casos.

¿Qué era… LastPass? ¿Ve papi? ¿Reddit? ¿GitHub?

Realmente es un caso de plus ça change, plus c'est la même eligió¿no es así?

Incluso reconocieron, en aquel entonces, que sería prudente realizar la búsqueda (al menos en el espacio de la oficina) por la noche, cuando sabían que los sistemas estarían funcionando pero que el sospechoso probablemente no estaría allí.

Y la orden en realidad establece que "los expertos nos han hecho saber que el almacenamiento de la computadora se puede borrar en minutos".

---

DOUG. Sí, es un caso fascinante.

Este tipo que se fue y trabajó para una compañía diferente, todavía tenía acceso a la compañía anterior, y marcó en el sistema, y ​​luego, accidentalmente, al parecer, imprimió tarjetas perforadas en su antigua compañía mientras estaba imprimiendo el código en papel en su nueva empresa.

Y la gente de la antigua empresa decía: "¿Qué está pasando aquí?"

Y luego eso fue lo que condujo a la orden y finalmente al arresto.

---

PATO. Y la otra cosa que noté, leyendo la orden judicial, que el policía pudo poner allí...

… es que había encontrado un testigo en la antigua empresa que confirmó que este tipo que se había mudado a la nueva empresa había dejado escapar, o se jactaba, de que todavía podía entrar.

¡Así que tiene todas las características de un truco contemporáneo, Doug!

[A] el intruso cometió un error garrafal que provocó que se detectara el ataque, [B] no cubrió sus huellas lo suficientemente bien, y [C] se había estado jactando de sus habilidades de haxxor de antemano. [RISAS]

Como usted dice, eso finalmente condujo a una condena, ¿no es así, por robo de secretos comerciales?

Ah, y la otra cosa, por supuesto, que la empresa víctima no hizo es...

…se olvidaron de cerrar el acceso al ex-personal el día que se fueron.

Lo cual sigue siendo un error que las empresas cometen hoy, lamentablemente.

---

DOUG. Sí.

Aparte de las tarjetas perforadas, esta podría ser una historia moderna.

---

PATO. ¡Sí!

---

DOUG. Bueno, llevemos las cosas a la modernidad y hablemos de GoDaddy.

ha sido golpeado con el malware, y algunos de los sitios de los clientes han sido envenenado.

Esto sucedió en diciembre de 2022.

No salieron y dijeron en diciembre: "Oye, esto está pasando".

GoDaddy admite: los ladrones nos atacan con malware y sitios web de clientes envenenados

---

PATO. Sí, parecía un poco tarde, aunque se podría decir: “más vale tarde que nunca”.

Y no tanto para entrar en acción por GoDaddy, sino al menos para explicar algo de la complejidad de investigar esto...

… parece que el malware que se implantó hace tres meses fue diseñado para desencadenar cambios intermitentes en el comportamiento de los servidores web alojados de los clientes.

Así que no fue como si los delincuentes entraran, cambiaran todos los sitios web, hicieran una gran cantidad de cambios que aparecerían en los registros de auditoría, saldrían y luego intentarían obtener ganancias.

Es un poco más como lo que vemos en el caso de la publicidad maliciosa, que es cuando envenenas una de las redes publicitarias en las que se basa un sitio web, por parte del contenido que a veces produce.

Eso significa que, de vez en cuando, alguien se ve afectado por malware cuando visita el sitio.

Pero cuando los investigadores vuelven a echar un vistazo, les resulta muy difícil reproducir el comportamiento.

[A] no sucede todo el tiempo, y [B] puede variar, dependiendo de quién eres, de dónde vienes, qué navegador estás usando…

…o incluso, por supuesto, si los delincuentes reconocen que usted es probablemente un investigador de malware.

Así que acepto que fue complicado para GoDaddy, pero como usted dice, podría haber sido bueno si le hubieran hecho saber a la gente en diciembre que había habido esta "redirección intermitente" de sus sitios web.

---

DOUG. Sí, dicen que el "malware redirigió intermitentemente sitios web de clientes aleatorios a sitios maliciosos", lo cual es difícil de rastrear si es aleatorio.

Pero esto no fue una especie de ataque realmente avanzado.

Estaban redirigiendo los sitios de los clientes a otros sitios donde los delincuentes estaban ganando dinero con eso...

---

PATO. [CÍNICO] No quiero estar en desacuerdo contigo, Doug, pero según GoDaddy, esto puede ser parte de una campaña de varios años de un "actor de amenazas sofisticado".

---

DOUG. [MOCK ASOMBRADO] ¿Sofisticado?

---

PATO. Así que la palabra S se dejó caer allí de nuevo.

Todo lo que espero es que, dado que no hay mucho sobre lo que podamos aconsejar a las personas ahora porque no tenemos indicadores de compromiso, y ni siquiera sabemos si, en este punto, GoDaddy ha podido llegar a lo que las personas podrían ir a buscar a ver si les pasaba esto…

…esperemos que cuando su investigación, que le hayan dicho a la SEC (Comisión de Bolsa y Valores) todavía la estén llevando a cabo); Esperemos que cuando eso termine, haya un poco más de información y que no tarde otros tres meses.

Dado no solo que los redireccionamientos ocurrieron hace tres meses, sino también que parece que esto puede deberse esencialmente a una pandilla cibernética que ha estado jugando dentro de su red durante hasta tres años.

---

DOUG. Creo que digo esto todas las semanas, pero “estaremos atentos a eso”.

Muy bien, más cambios en marcha en Twitter.

Si desea usar la autenticación de dos factores, puede usar mensajes de texto, puede usar una aplicación de autenticación en su teléfono o puede usar un token de hardware como Yubikey.

Twitter ha decidido CHARGE para mensajes de texto 2FA, diciendo que no es seguro.

Pero como también sabemos, cuesta mucho enviar mensajes de texto a teléfonos de todo el mundo para autenticar a los usuarios que inician sesión, Paul.

Twitter les dice a los usuarios: paguen si quieren seguir usando 2FA inseguro

---

PATO. Sí, estaba un poco confundido por esto.

El informe, razonablemente, dice: "Hemos decidido, esencialmente, que la 2FA basada en mensajes de texto y SMS simplemente no es lo suficientemente segura"...

…por lo que hemos hablado antes: intercambio de SIM.

Ahí es donde los ladrones entran en una tienda de teléfonos móviles y persuaden a un empleado de la tienda para que les dé una nueva SIM, pero con su número.

Entonces, el intercambio de SIM es un problema real, y es lo que hizo que el gobierno de los EE. UU., a través del NIST (el Instituto Nacional de Estándares y Tecnología), dijera: "Ya no vamos a admitir esto para los inicios de sesión basados ​​en el gobierno, simplemente porque no sentimos que tengamos suficiente control sobre la emisión de tarjetas SIM”.

Twitter, benditos sean sus corazones (Reddit lo hizo hace cinco años), dijo que no es lo suficientemente seguro.

Pero si compras una insignia azul de Twitter, lo que imaginas implica que eres un usuario más serio o que quieres ser reconocido como un jugador importante...

…puedes seguir usando la forma insegura de hacerlo.

Lo cual suena un poco raro.

Así lo resumí en el citado poema, o coplas, de la siguiente manera:

 El uso de textos es inseguro para hacer 2FA. Así que si quieres seguir así, vas a tener que pagar.

---

DOUG. ¡Bravo!

---

PATO. Yo no sigo eso.

Seguramente si es tan inseguro que es peligroso para la mayoría de nosotros, incluso para los usuarios menores cuyas cuentas quizás no sean tan valiosas para los delincuentes...

... seguramente las mismas personas a las que al menos se les debería disuadir de seguir usando 2FA basado en SMS serían los poseedores de la insignia azul.

Pero al parecer no…

---

DOUG. Bien, tenemos algunos consejos aquí, y básicamente se reduce a: Ya sea que pague o no por Twitter Blue, debe considerar alejarse de la 2FA basada en texto.

Utilice una aplicación 2FA en su lugar.

---

PATO. No estoy tan clamorosamente en contra de la 2FA basada en SMS como parece estarlo la mayoría de la gente de ciberseguridad.

Me gusta bastante su sencillez.

Me gusta el hecho de que no requiere un secreto compartido que podría ser filtrado por el otro extremo.

Pero soy consciente del riesgo de intercambio de SIM.

Y mi opinión es que, si Twitter realmente piensa que su ecosistema está mejor sin la 2FA basada en SMS para la gran mayoría de las personas, entonces realmente debería estar trabajando para sacar a *todos* de la 2FA...

…especialmente incluyendo a los suscriptores de Twitter Blue, sin tratarlos como una excepción.

Esa es mi opinión.

Entonces, ya sea que vaya a pagar por Twitter Blue o no, ya sea que ya pague por él o no, le sugiero que se mude de todos modos, si es que el riesgo es tan grande como lo pretende Twitter.

---

DOUG. Y solo porque esté utilizando 2FA basado en aplicaciones en lugar de 2FA basado en SMS, eso no significa que esté protegido contra ataques de phishing.

---

PATO. Eso es correcto.

Es importante recordar que la mejor defensa que puede obtener a través de 2FA contra los ataques de phishing (donde va a un sitio clonado y dice: "Ahora ingrese su nombre de usuario, su contraseña y su código 2FA") es cuando usa un hardware autenticador basado en token... como, como dijiste, un Yubikey, que tienes que ir y comprar por separado.

La idea es que esa autenticación no solo imprima un código que luego ingrese obedientemente en su computadora portátil, donde podría enviarse a los delincuentes de todos modos.

Por lo tanto, si no está utilizando la autenticación basada en clave de hardware, ya sea que obtenga ese código mágico de seis dígitos a través de un SMS o si lo busca en la pantalla de su teléfono desde una aplicación...

…si todo lo que va a hacer es escribirlo en su computadora portátil y potencialmente ponerlo en un sitio de phishing, entonces ni el 2FA basado en aplicaciones ni el basado en SMS tiene ninguna ventaja particular sobre el otro.

---

DOUG. Muy bien, estén seguros ahí afuera, gente.

Y nuestra última historia del día es Coinbase.

Otro día, otro intercambio de criptomonedas se violó.

Esta vez, por algunos buenos anticuados ingeniería social, ¿Pablo?

Coinbase violada por ingenieros sociales, datos de empleados robados

---

PATO. Sí.

¿Adivina qué vino en el informe, Doug?

Te doy una pista: “Veo, con mi ojito, algo que empieza por S”.

---

DOUG. [IRÓNICO] ¡Dios mío!

¿Fue este otro ataque sofisticado?

---

PATO. Claro que lo era... aparentemente, Douglas.

---

DOUG. [MOCK SORPRENDIDO] ¡Oh, Dios mío!

---

PATO. Como creo que hemos hablado antes en el podcast, y como puede ver escrito en los comentarios de Naked Security, "'Sofisticado' generalmente se traduce como 'mejor que nosotros'".

No mejor que todos, simplemente mejor que nosotros.

Porque, como señalamos en el video del podcast de la semana pasada, nadie quiere ser visto como la persona que cayó en un ataque poco sofisticado.

Pero como también mencionamos, y como explicaste muy claramente en el podcast de la semana pasada, a veces los ataques poco sofisticados funcionan...

…porque parecen tan monótonos y normales que no hacen sonar las alarmas de que podría ocurrir algo más diabólico.

Lo bueno que hizo Coinbase es que proporcionó lo que podría llamarse algunos indicadores de compromiso, o lo que se conoce como TTP (herramientas, técnicas y procedimientos) que los delincuentes siguieron en este ataque.

Solo para que pueda aprender de las cosas malas que les sucedieron, dónde entraron los ladrones y aparentemente echaron un vistazo y obtuvieron un código fuente, pero con suerte nada más que eso.

En primer lugar: phishing basado en SMS.

Recibe un mensaje de texto y tiene un enlace en el mensaje de texto y, por supuesto, si hace clic en él en su teléfono móvil, entonces es más fácil para los delincuentes disfrazar que está en un sitio falso porque la barra de direcciones no está tan claro, etcétera, etcétera.

Parecía que ese bit falló porque necesitaban un código de autenticación de dos factores que de alguna manera los delincuentes no pudieron obtener.

Ahora, no sabemos…

… ¿olvidaron preguntar porque no se dieron cuenta?

¿El empleado que recibió el phishing finalmente se dio cuenta de que “esto es sospechoso. Ingresaré mi contraseña, pero no ingresaré el código”.

¿O estaban usando tokens de hardware, donde la captura 2FA simplemente no funcionó?

No lo sabemos... pero esa parte no funcionó.

Ahora, desafortunadamente, parece que ese empleado no llamó y le dijo al equipo de seguridad: “Oye, me acaba de pasar algo raro. Creo que alguien estaba tratando de ingresar a mi cuenta”.

Entonces, los ladrones siguieron con una llamada telefónica.

Llamaron a esta persona (tenían algunos datos de contacto para ellos), y de esa manera obtuvieron información de ellos.

El tercer indicador fue que estaban tratando desesperadamente de que esta persona instalara un programa de acceso remoto al decirlo.

---

DOUG. [GEMIDO]

---

PATO. Y, aparentemente, los programas sugeridos fueron AnyDesk e ISL Online.

Parece que la razón por la que probaron ambos es que la persona debe haberse resistido y al final no instaló ninguno de ellos.

Por cierto, *no hagas eso*… es una muy, muy mala idea.

Una herramienta de acceso remoto básicamente lo hace caer de su silla frente a su computadora y pantalla, y deja caer al atacante allí mismo, "desde la distancia".

Mueven su ratón; se mueve en su pantalla.

Escriben en su teclado; es lo mismo que si estuviera escribiendo en su teclado mientras está conectado.

Y luego, el último indicador que tenían en todo esto es, presumiblemente, alguien que intenta ser de gran ayuda: “Oh, bueno, necesito investigar algo en su navegador. ¿Podría instalar este complemento del navegador?”

Whoa!

¡Las alarmas deberían sonar allí!

En este caso, el complemento que querían es un complemento perfectamente legítimo para Chrome, creo, llamado "Editar esta cookie".

Y está destinado a ser una forma en la que puede ingresar y ver las cookies del sitio web y el almacenamiento del sitio web, y eliminar las que no desea.

Entonces, si dice: "Oh, no me di cuenta de que todavía estaba conectado a Facebook, Twitter, YouTube, lo que sea, quiero eliminar esa cookie", eso evitará que su navegador se vuelva a conectar automáticamente.

Por lo tanto, es una buena manera de realizar un seguimiento de cómo los sitios web lo siguen.

Pero, por supuesto, está diseñado para que tú, el usuario legítimo del navegador, básicamente puedas espiar lo que hacen los sitios web para tratar de espiarte.

Pero si un *ladrón* puede hacer que instales eso, cuando no sabes muy bien de qué se trata, y luego pueden hacer que abras ese complemento, pueden echar un vistazo a tu pantalla (y tomar una captura de pantalla si tienen una herramienta de acceso remoto) de cosas como tokens de acceso para sitios web.

Esas cookies que se configuran porque inició sesión esta mañana, y la cookie le permitirá permanecer conectado durante todo el día, o toda la semana, a veces incluso un mes completo, para que no tenga que iniciar sesión una y otra vez. .

Si el ladrón se apodera de uno de esos, entonces cualquier nombre de usuario, contraseña y autenticación de dos factores que tenga se descarta.

Y parece que Coinbase estaba haciendo algún tipo de XDR (respuesta de detección extendida).

Al menos, afirmaron que alguien en su equipo de seguridad notó que había un inicio de sesión para un usuario legítimo que llegó a través de una VPN (en otras palabras, disfrazando su fuente) que normalmente no esperarían.

“Eso podría ser correcto, pero parece un poco inusual. Profundicemos un poco más”.

Y finalmente pudieron localizar al empleado que se había enamorado de los ladrones *mientras estaban siendo objeto de phishing, mientras estaban siendo manipulados socialmente*.

El equipo de Coinbase convenció al usuario: “Oye, mira, *somos* los buenos, ellos son los malos. Rompe todo contacto, y si intentan devolverte la llamada, *no los escuches más*”.

Y parece que eso realmente funcionó.

¡Así que un poco de intervención es muy útil!

---

DOUG. Muy bien, buenas noticias, un final feliz.

Se llevaron un poco de información de los empleados, pero podría haber sido mucho, mucho peor, ¿suena?

---

PATO. Creo que tienes razón, Doug.

Podría haber sido mucho peor.

Por ejemplo, si obtuvieron muchos tokens de acceso, podrían haber robado más código fuente; podrían haberse apoderado de cosas como claves de firma de códigos; podrían haber tenido acceso a cosas que estaban más allá de la red de desarrollo, tal vez incluso a los datos de la cuenta del cliente.

No lo hicieron, y eso es bueno.

---

DOUG. Muy bien, bueno, escuchemos a uno de nuestros lectores sobre esta historia.

Richard, lector de Naked Security, escribe:

La búsqueda regular y activa de indicios de que alguien no está tramando nada bueno en su red no convence a la alta gerencia de que su trabajo es necesario, necesario o importante.

Esperar las detecciones de ciberseguridad tradicionales es tangible, medible y justificable.

¿Qué dices, Pablo?

---

PATO. Es ese antiguo problema de que si tomas precauciones que son lo suficientemente buenas (o mejores que lo suficientemente buenas, y lo hacen muy, muy bien)...

… comienza a socavar los argumentos que usó para aplicar esas precauciones en primer lugar.

"¿Peligro? ¿Qué peligro? Nadie se ha caído por este precipicio en diez años. ¡Después de todo, nunca necesitábamos la cerca!”

Sé que es un gran problema cuando la gente dice: "Oh, sucedió X, luego sucedió Y, entonces X debe haber causado Y".

Pero es igualmente peligroso decir: "Oye, hicimos X porque pensamos que evitaría que Y. Y dejó de suceder, así que tal vez no necesitábamos X después de todo, tal vez todo eso sea una pista falsa".

---

DOUG. Quiero decir, creo que XDR y MDR... se están volviendo más populares.

El viejo "una onza de prevención vale una libra de cura"... que podría estar ganando terreno y ascendiendo a los niveles más altos de la corporación.

¡Así que esperamos seguir peleando esa buena batalla!

---

PATO. Creo que tienes razón, Doug.

Y creo que también podría argumentar que también puede haber presiones regulatorias que hacen que las empresas estén menos dispuestas a decir: “¿Sabes qué? ¿Por qué no nos limitamos a esperar y ver? Y si tenemos una pequeña brecha que no tenemos que contarle a nadie, tal vez nos salgamos con la nuestra”.

Creo que la gente se está dando cuenta de que "es mucho mejor estar a la vanguardia y no meterse en problemas con el regulador si algo sale mal, que asumir riesgos innecesarios para nuestro propio negocio y el de nuestros clientes".

Eso es lo que espero, de todos modos!

---

DOUG. Ciertamente.

Y muchas gracias, Richard, por enviar eso.

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!

[MÓDEM MUSICAL]