A raíz de las filtraciones hechas por Wikileaks sobre las constantes intrusiones de la CIA en diversos tipos de tecnologías por muchos años, opino, como algunas personas, que no hay absolutamente nada ilegal en los contenidos hasta ahora, (los cuales, debo aclarar, no he revisado en detalle, por lo que mi opinión puede pecar de incompleta); y, por cierto, algunos de los documentos, me parece, son algo viejos. Aun así, las acciones llevadas a cabo por la CIA implícitas en Vault 7, son exactamente lo que yo esperaría que una agencia de inteligencia hiciera en internet. Ni más ni menos.

De todo lo que he revisado acerca de la filtración, me gustaría resaltar en este artículo, unas bellas best-practices sobre programación de malware, cortesía de la CIA, las cuales igualmente son aplicables para obtener un enfoque de privacy-by-design hacia el desarrollo de software, especialmente para aquellos que no están acostumbrados a utilizarlas regularmente en sus productos. Parecen tener muy buena pinta a pesar de tener un claro enfoque hacia el lado del black hat. Veamos algunas:

Generales

  • Ofuscar o cifrar todo tipo de string o datos de configuración relacionados directamente con la funcionalidad del software. Se debe tener especial consideración en deshacer la ofuscación únicamente en el momento que la información es utilizada en memoria. Cuando un valor ha dejado de ser utilizado debe ser removido bajo cualquier circunstancia.

o Explicación: Los strings o cualquier tipo de dato es muy útil para los analistas de malware o para efectuar ingeniería inversa, por lo que hay que eliminarlos.

  • No descifrar (o quitar la ofuscación de) los strings o los datos utilizados inmediatamente tras la ejecución de la herramienta en el objetivo.

o Explicación: Incrementa la dificultad para encontrar datos sensitivos o volver impreciso el análisis dinámico automatizado de los binarios.

  • Remover datos sensitivos (llaves de cifrado, arreglos de datos, shellcode, módulos, etc.) de la memoria, cuando estos dejen de ser necesarios en texto plano. Nunca confíes en que el sistema operativo ejecute, por si mismo, este wipe-out al terminar la ejecución de la herramienta.

o Explicación: Aumenta la dificultad de una posible revisión forense.

  • Quitar cualquier ruta, debugging output o nombres de los desarrolladores en el producto final.

o Explicación: Aumenta la dificultad de cualquier análisis de la herramienta o el uso de ingeniería inversa.

  • No invocar directamente funciones que no son consistentes con la función de la herramienta, especialmente si se desea pasar como usurpación de otra (ej. WriteProcessMemory, VirtualAlloc, CreateRemoteThread son muy sospechosas para un binario que se supone sería el reemplazo de una aplicación como NotePad).

o Explicación: Minimiza las posibilidades de investigar más a fondo el binario malicioso e incrementar la dificultad de un análisis estático.

  • No generar crashdumps, coredumps, pantallas azules u otros pop-ups en caso de que el programa falle.

o Explicación: Evitar las sospechas del usuario o del sysadmin, y mitiga las opciones de una posible ‘respuesta a incidentes’.

  • No ejecutar acciones que causen que la computadora del objetivo se congele o produzca problemas de operación inesperados.

o Explicación: Evita que la atención del usuario se centre en investigar este comportamiento y pueda identificar un posible malware dentro del sistema.

  • Se debe poner máximo esfuerzo en minimizar el tamaño del binario (o binarios) que serán inyectados en el objetivo, (sin el uso de empaquetadores, o compresores). Un archivo de tamaño ideal debe rondar alrededor de los 150 KB máximo.

o Explicación: Acorta el tiempo de ejecutar las funcionalidades y sobre todo el tiempo en cargar todo nuestro código malicioso en el objetivo.

  • Proveer los medios necesarios para una desinstalación completa de hooks, funciones, ‘injected threads’, llaves de registro, servicios, procesos, etc.

o Explicación: Evita que datos sensitivos o no deseados queden deambulando en el objetivo.

  • No dejar estampa de fecha/hora en los binarios que puedan correlacionar una zona horaria en específico.

o Explicación: Evita la investigación de un lugar específico en una zona horaria específica, de acuerdo a sus posibles horas de trabajo.

  • Utilizar siempre un método de ‘borrado seguro’ a la hora de remover cualquier clase de dato de nuestro programa. (La definición de borrado seguro es variable dependiendo del sistema objetivo, pero al menos una función de wipe-out de 0’s debe ser ejecutada).

o Explicación: Aumenta la dificultad en algún posible análisis forense.

Networking

  • Utilizar cifrado end-to-end para cualquier tipo de comunicación. Nunca utilizar protocolos que violen este principio ‘punto a punto’.

o Explicación: Evitar cualquier clase de sniffeo o análisis de protocolos.

  • No confiar únicamente en SSL o TLS para proteger las comunicaciones.

o Explicación: Numerosas vulnerabilidades han sido descubiertas en estos protocolos que podrían comprometer el payload.

  • Utilizar protocolos bajo estándares en todo momento. Cualquier payload cifrado debe viajar tunneleado en otro protocolo bien conocido (ejemplo: HTTPS)

o Explicación: Protocolos propietarios o ‘customizados’ pueden levantar sospechas de los analistas de red o prender las alarmas de cualquier IDS.

  • Modificar aspectos como jitter o tamaño de los paquetes en la comunicación. No manejar tamaños fijos que puedan ser predecibles.

o Explicación: Aumenta la dificultad en correlacionar todo tipo de actividad sospechosa en la red.

  • Tirar toda clase de conexión una vez terminada cualquier operación relacionada con la ejecución del malware.

o Explicación: Incrementa la dificultad de una posible respuesta a incidentes.

PSP/AV

  • No asumir que las versiones ‘freemium’ de antivirus o en general de cualquier producto de seguridad, poseen las mismas funcionalidades que los productos completos. Probar con todas las variantes del producto que estén disponibles, no importando que provengan del mismo vendedor.

o Explicación: Asegurar el bypass de nuestro binario en caso de encontrarse con diversas barreras de defensa.

  • Testear con productos “live” o con ‘online sandboxing’. Esto puede ser igualmente arriesgado, y se debe tener consideración especial cuando se efectúe esta prueba con malware incompleto-completo. Muchos de estos productos online, además de realizar el análisis, suben el ‘sample’ del código malicioso de manera automática a sus sensores, actualizando sus firmas y provocando que lo que llevemos desarrollado hasta ahora (o el malware entero) quede inutilizable.

o Explicación: Testear todos los posibles escenarios con productos live o locales para asegurar penetración y persistencia.

Para finalizar este post sobre ‘best practices’ en el desarrollo de malware, solamente quiero mencionar una frase que leí por ahí, en algún foro de seguridad TI creo, la cual me parece viene a colación hablando de este tema tan ‘indecente’ de los códigos maliciosos:

Una de las razones por las cuales la sociedad no se ha autodestruido es que muchas de las personas poseedoras de gran intelecto y habilidades no se especializan en ser unos criminales. Si en algún momento esto se volviera viable (y atractivo) para ellos, estaríamos condenados…