El documento enlazado especifica un formato de intercambio de datos basado en XML. Describe cómo empaquetar todos los datos (incluido el fingerprint.codex.xml) en 3. (U) Estructura de directorios .
Los datos CODEX completos, incluidos los archivos xml individuales (por ejemplo, fingerprint.codex) o los metadatos de los datos recuperados (como correos electrónicos o capturas de pantalla) no deben generarse en el host de destino:
Generación de estos met formatos NO DEBE tener lugar en el objetivo. En su lugar, las herramientas DEBEN devolver al usuario los detalles detalles necesarios para que se pueda producir un archivo o estructura Codex a partir del formato personalizado específico de la herramienta, controlado por el usuario, potencialmente no conectado a Internet. Una vez más, las herramientas no DEBEN almacenar datos en en formato Codex ni generar ningún formato Codex personalizado en el objetivo.
Objetivo aquí significa: un host monitorizado/atacado. Usuario aquí probablemente significa: un evaluador/procesador de datos de la agencia o de uno de sus contratistas.
Como consecuencia, el archivo fingerprint.codex.xml ni siquiera existe en el host de destino, sino que se genera en otro lugar a partir de los datos transmitidos.
Según el documento ( 4.4 (U//FOUO) Formato XML de huellas dactilares ) una huella digital de MacOS consiste simplemente en el UUID en minúsculas md5 del sistema root. Todas las demás claves, excepto usertag están relacionados con los sistemas operativos Windows o Linux.
El UUID se puede recuperar introduciendo:
diskutil info / | grep "Volume UUID" | tr '[:upper:]' '[:lower:]' | awk '{print $3}'
y su hash md5 con:
md5 -s $(diskutil info / | grep "Volume UUID" | tr '[:upper:]' '[:lower:]' | awk '{print $3}')
El archivo de huellas dactilares completo tendría este aspecto para un Mac (aquí un ejemplo de MacOS VM):
<codex version=”1”>
<fingerprint target=”machine” type=”os” version=”1”>
<uid>“db78ec1b99a4e71fabbc0e23888baf64</uid>
<rootfsid>d15d6f4e-d213-373d-893e-f975126cb767</rootfsid>
<usertag>NONE</usertag>
</fingerprint>
<fingerprint target=”machine” type=”hardware” version=”1”>
</fingerprint>
<timestamp>2017-03-24 07:11:00.000000Z</timestamp>
</codex>
En estas circunstancias, el archivo de huellas dactilares no puede "corromperse" o "falsificarse" en su host, simplemente se genera y almacena en otro lugar.
Por supuesto, puede invalidar la huella digital actual relacionada con su Mac borrando su volumen de arranque e instalando un nuevo sistema - esto generará un nuevo UUID de volumen (o rootfsid).
No sé si la agencia tiene una herramienta o un método para vincular una nueva huella dactilar (y los datos CODEX relacionados) creada tras una "segunda visita amistosa"/vigilancia/ataque a la antigua huella dactilar (y los datos CODEX relacionados) de su volumen Root ahora sobrescrito. Probablemente lo haya hecho.
Y para responder a sus preguntas de alguna manera:
- No puede detectar si el archivo de huellas dactilares está dañado porque probablemente no tenga acceso a las instalaciones de almacenamiento de datos de la CIA
- No puede falsificar el archivo de huellas dactilares porque probablemente no tenga acceso a las instalaciones de almacenamiento de datos de la CIA y ¿cómo podría un malware dejar de funcionar en el arranque por un archivo de huellas dactilares remoto?
- Puede utilizar cualquier algoritmo hash más o menos "seguro" para calcular el uid en el archivo de huellas dactilares. Aunque por definición es md5.
1 votos
Calificado como poco claro: Sus preguntas contienen tres preguntas diferentes y no está claro cómo cada una de ellas está relacionada con el hardware o el software de Apple.