La activa campaña de Corea del Norte dirigida a investigadores de seguridad

• El Grupo de Análisis de Amenazas (TAG) de Google confirmó recientemente que hubo ataques dirigidos a investigadores de seguridad y que en ellos se explotó una vulnerabilidad de día cero.
  • La vulnerabilidad de día cero fue reportada al proveedor correspondiente y el parche está en proceso.
• Los atacantes norcoreanos entablaron conversaciones activas con sus objetivos a través de redes sociales como Twitter y construyeron una relación.
  • De hecho, conversaron durante meses con un investigador de seguridad sobre temas de interés mutuo y fueron ganando su confianza.
  • Después, se pasaron a una app de mensajería cifrada y enviaron un archivo malicioso que incluía al menos una vulnerabilidad de día cero en un paquete de software popular.
• Cuando la explotación tenía éxito, el shellcode verificaba si se trataba de una máquina virtual y enviaba diversa información al servidor del atacante; esto estaba implementado de forma similar a métodos vistos antes en ataques norcoreanos que explotaban vulnerabilidades.
• Además de los ataques dirigidos mediante vulnerabilidades de día cero, también desarrollaron una herramienta de código abierto para ingeniería inversa y la publicaron en Github.
  • Este programa se publicó por primera vez el 30 de septiembre de 2022 y luego se desarrolló activamente, con varias actualizaciones.
  • Sin embargo, la herramienta incluía una puerta trasera que podía descargar y ejecutar código arbitrario desde el servidor del atacante.
  • TAG recomienda revisar el sistema si se usó esta herramienta y, de ser necesario, reinstalar el sistema operativo.
• Todos los sitios web y dominios maliciosos identificados fueron añadidos a Safe Browsing de Google, y se enviaron alertas de ataques respaldados por gobiernos a las cuentas de Google que podrían haberse visto afectadas.
  • Además, se divulgaron todos los dominios, archivos y cuentas maliciosos, como dbgsymbol, blgbeach y @Paul091_.

[kuroneko]

• Hilo de HN

Los ataques dirigidos dan miedo, pero creo que hay que tener todavía más cuidado con la parte en la que metieron código malicioso en un proyecto open source.

Al parecer, el código fuente de esa herramienta era normal, pero los archivos incluidos en el GitHub Release contenían código malicioso.
Dicen que incluso tenía más de 200 estrellas en GitHub...

De repente están saliendo varias noticias de seguridad seguidas. Parece que todos tendremos que prestar más atención a la seguridad.

[sixmen]

Aun así, pensaba que al menos el código fuente se podría verificar, pero nunca se me ocurrió que sería distinto al Release. La seguridad nunca se acaba...

[kunggom]

Parece que esto también es una especie de ataque a la cadena de suministro.
Justo hace 1 mes, en el caso de Go 1.21.0, que se lanzó entonces, publicaron en el blog que por primera vez los resultados de compilación de su toolchain eran completamente reproducibles. Los dos primeros párrafos de ese texto dicen lo siguiente.

Perfectly Reproducible, Verified Go Toolchains

Una de las principales ventajas del software de código abierto es que cualquiera puede leer el código fuente e inspeccionar su funcionamiento. Pero la mayor parte del software, incluso el de código abierto, se descarga en forma de binarios compilados, por lo que es mucho más difícil de inspeccionar. Si un atacante quiere llevar a cabo un ataque a la cadena de suministro contra un proyecto de código abierto, la forma menos visible es reemplazar los binarios distribuidos sin modificar el código fuente.

La mejor manera de defenderse de este tipo de ataque es hacer que las compilaciones del software de código abierto sean reproducibles; es decir, que una compilación que parte del mismo código fuente genere exactamente la misma salida cada vez que se ejecute. Así, cualquiera puede compilar y volver a compilar a partir del código fuente real, y verificar que el binario reconstruido sea idéntico bit a bit al binario publicado, para confirmar que no haya cambios ocultos en el binario distribuido. Este enfoque demuestra que el binario no contiene puertas traseras ni otras modificaciones que no estén en el código fuente, sin necesidad de desensamblarlo ni mirar su interior. Como cualquiera puede verificar el binario, grupos independientes pueden detectar y reportar con facilidad ataques a la cadena de suministro. (Traducción de DeepL)

Me preguntaba por qué había que preocuparse por algo así, y resulta que este tipo de ataques ya se venían realizando en secreto desde hace cerca de 1 año. Ah, qué peligroso está el mundo...

[kuroneko]

Yo también tiendo a confiar un poco más cuando viene junto con código en GitHub... tendré que tener cuidado.
¿Al final no queda de otra más que revisar siempre el código y hacer el build uno mismo...?

[kuroneko]

Resumen con IA del hilo de HN

• 0xDEAFBEAD: propone a GitHub agregar un banner de advertencia para repositorios que contengan malware como esta herramienta.
• zb3: recuerda que no se debe confiar ciegamente en el código de GitHub solo porque el autor parezca confiable.
• nneonneo: cree que es posible que el malware esté en la versión binaria y no en el código fuente en sí, ya que el código se ve limpio, pero los binarios podrían tener una puerta trasera.
• bowmessage: señala una sospechosa función de actualización automática que puede descargar malware desde un dominio controlado por el atacante.
• gregsadetsky: descubre que el repositorio espejo de la herramienta sigue funcionando y explica cómo funciona el proceso de actualización para permitir la infección.
• codetrotter: proporcionó un archivo del repositorio original antes de que fuera eliminado.
• dantillberg: describe el código de actualización automática que descarga y ejecuta archivos desde una URL.
• bdowling: al principio malinterpretó el problema, pero luego aclaró que el problema era la URL de actualización controlada por el atacante.
• saagarjha: cree que el zero-day estaba en la capacidad del software de ejecutar código del atacante mediante la función de actualización.
• rightbyte: cuestiona si realmente hay pruebas suficientes para asegurar que fue obra de Corea del Norte.