Qué es un IOC
Cuando hay ataque, en sus distintas etapas, se van generando acciones y artefactos, que deberían quedar registradas en algún lado y que son detectables.
Por ejemplo, te envían un link malicioso, para que te descargues un archivo, que al ejecutarse accede a una url para bajar componentes adicionales, exfiltrar información o recibir órdenes. Además, se escribe en el disco como persistencia y agrega una clave en el registro para reiniciarse cuando el sistema lo haga, ¿qué tenemos?
- Una url maliciosa
- Un archivo malicioso
- Más archivos maliciosos
- Más urls
- Claves en el registro
Si vos ves este ataque, podés tomar nota de identificadores de cada una de estas piezas y luego, ante cada intento de acceder a urls comparar con las maliciosas, al bajar, escribir o leer un archivo hacerlo con los maliciosos y revisar el registro buscando claves.... maliciosas.
El caso particular del archivo no es muy práctico tomarlo como referencia pues puede ser grande, lo mejor es calcularle un hash y guardar ese Indicator Of Compromise.
Pequeña pieza de recomendación
Lamentablemente, incluso entre la gente técnica, la falta de conocimiento detallado hace que se cometan errores de concepto, por ejemplo el que paso a reportar, pues lo he visto varias veces con varias personas.
Ponele que tenés dos herramientas que entienden IOCs, el DNS y el proxy saliente.
Te llega este IOC, ¿dónde lo ponés?
https://3984274.aws.com
Muy bien, en cualquiera o ambos.
¿Y este?
https://3984274.aws.com/api/service/34
Si tuvieras la tentación de decir lo mismo, antes mirá este:
https://www.afip.gob.ar/api/service/34
Hay personas que han dicho:
"Pongamos en ambos"
Hay dos problemas, el de seguridad y el conceptual técnico.
El de seguridad es que si para bloquear
https://www.afip.gob.ar/api/service/34
ponés "www.afip.gob.ar" en el DNS, generás una denegación de servicio a todo afip sólo por una ruta comprometida. Podría ser válido, razonando "si tiene esa ruta comprometida, puede estar todo el resto, no interactuemos en absoluto con afip hasta que corrijan", ok, es una decisión.
En la conversación de esa decisión es cuando detecté el problema conceptual técnico:
El DNS no entiende ni "https://" ni "/api/service/34"
La única manera de bloquear sin "daños colaterales" es en el proxy.
Sigamos....
Qué es MD5
Hashing es una operación que se hace sobre un dato y devuelve un hash, que es un número largo y en teoría cambia ante cualquier modificación sobre el dato. Si calculás un hash de un dato, modificás un bit, recalculás, te da otro hash.
Por alguna falta de visión, pues esto de los IOCs es relativamente reciente, se utilizan como IOCs de archivos hashes MD5, que se diseñó en 1991 y ya desde 1993 se le han hallado problemas criptográficos que en el mejor de los casos, parecería que ya desde 2010 se considera deprecado.
Digo falta de visión pues si buscamos en wikipedia IOC, el artículo nace en 2013, como que ya existían varios SHA para ese entonces, pero seguro que lo de los IOC con MD5 entraron de la mano de gente de seguridad no técnica y programadores sin conocimientos de seguridad que buscaban ahorrar espacio y tiempo de ejecución.
Ojo, siempre es fácil señalar los errores del pasado desde el futuro, pero bueno.
La colisión "accidental"
Una colisión de hash es cuando dos datos distintos dan el mismo hash. Las colisiones son esperables pues la variedad de datos es infinita y los hashes son números, en el caso de MD5 entre 0 y 2 a la 128, que aunque es un número grande, claramente es muy muy muy inferior a infinito.
Se podría argumentar que dada la baja probabilidad de colisión y la ventaja del ahorro de espacio y tiempo de ejecución no importa, aunque ya tenemos al menos un caso conocido.
Dice este reporte que no sé de dónde saqué, pero se parece a la situación habitual de malware, en este caso Trojan.Win64.CoinMiner, un minero:
https://itsafety.net/report/20200515-65ade21dc82c01972891285581d85866-servermanager-exe_process-partofthreat
Trojan.Win64.CoinMiner |
Fijate que dice que la mayor parte de los antivirus no lo detecta, ¿por qué será?
Dice Microsoft, que respecto a windows debe tener una cierta autoridad
https://learn.microsoft.com/en-us/windows-server/administration/server-manager/server-manager
Microsoft |
Puede ser que estemos hablando de distintas piezas, pero si buscás en virustotal ese hash (65ade21dc82c01972891285581d85866), te trae
VirusTotal |
De paso observá que el hash que te muestra es un SHA256, correcto.
No tengo las ganas de buscar cada versión legítima del archivo hasta encontrar el que coincide con esa firma, para demostrar fehacientemente el punto pues su demostración pasa por otro lado.
La colisión a propósito
Desde hace años en mis charlas muestro este ejemplo:
angel devil |
Vemos que dos programas generan distinto output, miden lo mismo, tienen la misma longitud pero son distintos, con sha256 eso no pasa.
sha256 |
La verdad verdad, no sé bien de dónde lo saqué, tampoco importa muchísimo pues se trata de criptoarqueología y no hay nadie que discuta que MD5 no sirve.
Es un programa en C con un buffer. En ese buffer hay un valor, se compila y al ejecutar se comprueba que sea ese valor. En este caso se ejecuta angel().
Luego, con fastcoll y longEgg se manipula ese buffer en la copia de angel llamada devil hasta que da el mismo hash MD5. Al ejecutar y fallar la comprobación, se ejecuta devil().
int main() {
if (strcmp(dummya, dummyb) != 0) {
return angel();
} else {
return devil();
}
}
Lo que importa, es que probablemente se puedan tomar dos programas de la misma longitud, manipular una parte y hacerles concidir los hashes, con lo cual para cada ejecutable legítimo del sistema
Digo probablemente pues como script kiddie todo esto parece fácil, pero no lo he comprobado.
Me pregunto por qué no se hace y apuesto a que no vale la pena, es demasiado fácil contrarestar, leyendo el archivo de atrás para adelante para el MD5 o tomando otro SHA cualquiera basta para detectar correctamente, salvo en las herramientas más precarias, para decirles de alguna manera....
lectura invertida |
Para qué puede servir MD5
MD5 es útil en situaciones sin adversarios. Por ejemplo, tenés dos archivos del mismo tamaño y no sabés si son iguales. Si están en la misma máquina corrés cmp y listo, te lo dice. Pero si están en distintas máquinas, tendrías que copiar uno a la otra o montar en una una carpeta de otra.... mucho trabajo. El MD5 de cada archivo te puede confirmar si son distintos, no tanto que sean iguales, pero ya dije, sin adversarios.
Me ha servido para hacer unas pruebas con FPGA, tal cual relato en un montón de entradas....
Y por supuesto sirve para demostrar lo inseguro que es.
No hay comentarios:
Publicar un comentario