- 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_.
5 comentarios
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.
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...
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...
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...?
Resumen con IA del hilo de HN