🦗 🐠 🍑 Puedo convertirme en Apple, y tú también 🚳 📠 👨🏾‍💼

Divulgación pública del código de Apple que firma vulnerabilidad de terceros

A diferencia de algunos trabajos anteriores, esta vulnerabilidad no requiere derechos de administrador, no requiere un código JIT o corrupción de memoria para omitir la verificación de firma de código. Todo lo que necesita es un archivo Fat / Universal formateado correctamente, y la verificación de la firma del código mostrará un resultado válido.

Resumen

Encontrado un desvío utilizado por la API de terceros para firmar el código le permite presentar cualquier código firmado por Apple.
Todos los proveedores y proyectos de código abierto conocidos son notificados (ver la lista a continuación). Los parches están disponibles para ellos.
Existe la posibilidad de que el problema afecte a otros programas de terceros que utilizan las API de firma de código oficial de Apple.
Los desarrolladores son responsables del uso adecuado de la API de firma de código. Existen herramientas de demostración de piratería (PoC) para las pruebas.
Se aplica solo a macOS y versiones anteriores de OSX.

Vendedores afectados

VirusTotal - CVE-2018-10408
Google - Santa, molcodesignchecker - CVE-2018-10405
Facebook - OSQuery - CVE-2018-6336
Desarrollo objetivo - LittleSnitch - CVE-2018-10470
F-Secure - xFence (también LittleFlocker) CVE-2018-10403
Objective-See - WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (y otros) - CVE-2018-10404
Yelp - OSXCollector - CVE-2018-10406
Negro de carbón - Respuesta Cb - CVE-2018-10407

La importancia de la firma de código y cómo funciona en macOS / iOS

La firma de código es una construcción de seguridad que utiliza una infraestructura de clave pública (PKI) para firmar digitalmente código compilado o incluso scripts para garantizar que sea confiable y que el código sea auténtico. En Windows, puede firmar criptográficamente casi cualquier cosa: desde binarios .NET hasta scripts de PowerShell. En macOS / iOS, la firma de código se refiere principalmente a binarios de Mach-O y paquetes de aplicaciones para permitir que solo se ejecute código de confianza en la memoria.

Los antivirus, los sistemas de seguridad y la respuesta a incidentes, así como las herramientas forenses analizan las firmas para identificar códigos confiables entre los que no son confiables. La verificación de firma acelera el análisis. Varias herramientas utilizan información de firma de código para implementar medidas de seguridad: estas son listas blancas, antivirus, respuesta a incidentes y sistemas de búsqueda de amenazas. Poner en peligro la firma del código en uno de los sistemas operativos más populares significa socavar la construcción de seguridad básica, de la que dependen muchas operaciones de seguridad de la información de rutina.

Ya se encontraron problemas en la firma del código ( 1 , 2 , 3 , 4 , 5 ). A diferencia de algunos trabajos anteriores, esta vulnerabilidad no requiere derechos de administrador, no requiere un código JIT o corrupción de memoria para omitir la verificación de firma de código. Todo lo que necesita es un archivo Fat / Universal formateado correctamente, y la verificación de la firma del código mostrará un resultado válido.

Detalles de vulnerabilidad

La esencia de la vulnerabilidad es que el cargador Mach-O y la API de firma de código no se utilizan para verificar las firmas de código de forma incorrecta. Esta diferencia puede explotarse utilizando un binario Universal / Fat especialmente diseñado.

¿Qué es un archivo Fat / Universal?

Fat / Universal es un formato binario que contiene varios archivos Mach-O (archivo ejecutable, dyld o paquete), cada uno de los cuales está orientado a una arquitectura de CPU específica (por ejemplo, i386, x86_64 o PPC).

Prerrequisitos

El primer Mach-O en el archivo Fat / Universal debe estar firmado por Apple, puede ser un archivo i386, x86_64 o incluso un PPC.
Un código binario malicioso o extraño autofirmado debe compilarse bajo i386 para macOS x86_64.
El CPU_TYPE en el encabezado Fat del binario de Apple debe establecerse en un tipo de procesador no válido o un tipo que no sea nativo del conjunto de chips del host.

Sin pasar los correspondientes SecRequirementRef y SecCSFlags , la interfaz del programa API de firma de código ( SecCodeCheckValidity ) verificará el primer binario en el archivo Fat / Universal para el origen de la firma (por ejemplo, Apple) y verificará la autenticidad de la firma. Luego, la API verificará todos los otros archivos binarios en el archivo Fat / Universal para verificar el cumplimiento de los Identificadores de equipo y la autenticidad de la firma, pero sin verificar la raíz de confianza de la autoridad de certificación . La razón por la cual el código malicioso o el código "sin firmar" debe ser i386 es porque la API de firma de código está configurada de manera predeterminada para verificar la firma del código para la arquitectura de CPU nativa (x86_64).

Una de las razones por las cuales el código autofirmado pasa la prueba con éxito es porque incluso en los binarios principales de Apple, el campo TeamIdentifier está configurado para not set . La siguiente ilustración muestra el binario Mach-O válido, firmado por Apple (python.x64), junto al Mach-O autofirmado (ncat.i386). Ambos tienen `TeamIdentifier = no establecido`.

Por ejemplo, firmé el binario usando la ID del desarrollador e intenté en lipo combinarlo con el binario de Apple en un archivo Fat / Universal. Este tipo de firma de código falla.

Mi PoC inicial es ncat (de nmap), que llamé ncat.frankenstein. Aquí, el archivo Fat resultante contiene el binario python x86_64 firmado por Apple y el binario autofirmado (adhoc) ncat i386. Un binario codesign -s - target_mach-o_or_fat_binary se crea fácilmente con codesign -s - target_mach-o_or_fat_binary . Así es como se ve en MachOView:

Si ejecuta este archivo, se iniciará python x86_64:

Y la firma del código se está verificando:

¿Cómo ejecuté el binario autofirmado ncat?

Esto se realiza configurando un tipo CPU_Type no válido o una CPU no nativa (por ejemplo, PPC). Luego, el cargador Mach-O omite el binario Mach-O con una firma válida y ejecuta código malicioso (no firmado por Apple):

Luego se ejecuta ncat.frankenstein, y el resultado de la validación será valid :

Publicamos ncat.frankenstein y otros cuatro ejemplos para que los desarrolladores puedan verificar las vulnerabilidades en sus productos.

Recomendaciones

En la línea de comando

Depende de cómo verifique el código firmado. Si usa el signo de código, entonces probablemente esté familiarizado con los siguientes comandos:

codesign –dvvvv - volcado de la autoridad de certificación y TeamIdentifier (ID del desarrollador)
codesign –vv : verificación estricta de todas las arquitecturas

Pero para verificar correctamente este tipo de abuso, debe agregar el requisito de certificado de anclaje con los siguientes comandos :

codesign -vv -R='anchor apple' ./some_application_or_mach-o # para el código firmado por Apple
codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # para el código firmado por Apple y Apple

Tal comando mostrará un error al verificar el código con la firma de otra persona:

Puede usar el comando spctl , pero requiere un análisis cuidadoso de la salida del comando. Por ejemplo, el binario Mach-O con la firma de Apple (/ bin / ls) y Safari devuelve lo siguiente:

Y aquí está el resultado de una aplicación firmada por Apple:

Tenga en cuenta la línea "(el código es válido pero no parece ser una aplicación)" para / bin / ls, que no pasa la prueba. A modo de comparación, aquí está el resultado del archivo Fat / Universal ncat.frankenstein:

El archivo ncat.frankenstein Fat / Universal no muestra que el código sea válido. Por lo tanto, no puedo recomendar spctl para verificar manualmente los binarios fuera de línea de Mach-O. Simplemente use el signo de código con las banderas apropiadas.

Para desarrolladores

Por lo general, los desarrolladores comprueban los binarios Mach-O o Fat / Universal usando las API SecStaticCodeCheckValidityWithErrors () o SecStaticCodeCheckValidity () con los siguientes indicadores:

Estas banderas deben garantizar que todo el código cargado en la memoria en el archivo Mach-O o Fat / Universal esté firmado criptográficamente. Sin embargo, estas API no proporcionan una validación adecuada de forma predeterminada, por lo que los desarrolladores externos deben aislar cada arquitectura en el archivo Fat / Universal y verificar que las identidades coincidan y sean criptográficamente robustas.

La mejor manera de probar cada arquitectura anidada en el archivo Fat / Universal es primero llamar a SecRequirementCreateWithString con el requisito "anchor apple", luego SecStaticCodeCheckValidity con kSecCSDefaultFlags | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks con referencia al requisito; como se muestra en el código fuente parcheado de WhatsYourSign .

Al pasar la "manzana ancla" a la función SecRequirmentCreateWithString, esta llamada funciona de manera similar al codesign -vv -R='anchor apple' , que requiere la cadena de confianza Firma de software de Apple para todos los archivos binarios anidados en el archivo Fat / Universal. Además, al pasar las banderas y el requisito de SecStaticCodeCheckValidity, todas las arquitecturas se verifican para este requisito y se aplican las verificaciones de revocación.

Manifestaciones

La herramienta de codesign de Apple y la necesidad de usar la bandera -R .

LittleSnitch: la comprobación del archivo Fat / Universal en el disco no funciona, pero LittleSnitch verifica correctamente el proceso en la memoria.

LittleFlocker: F-Secure compró LittleFlocker, y ahora se llama xFence.

F-Secure xFence (anteriormente LittleFlocker)

Objetivo-Ver herramientas

Taskexplorer

WhatsYourSign

Facebook OSquery es el resultado de muestras de malware y / bin / ls como un ejemplo válido.

Emisión de Google Santa: Fileinfo muestra que ncat.frankenstein está en la lista blanca:

Denegar la ejecución de ncat (sin firmar) y el permiso de ejecución de ncat.frankenstein:

Registro de Santa.log que muestra eventos del ejemplo anterior:

Respuesta de negro de carbón

VirusTotal: ejemplo de bash_ppc_adhoc antes de instalar el parche en VirusTotal:

Fechas de divulgación

22/02/2018: Se envió un informe y PoC a Apple para evitar los sistemas de seguridad de terceros.

01/03/2018: Apple respondió que los desarrolladores externos deberían usar kSecCSCheckAllArchitectures y kSecCSStrictValidate con la API SecStaticCodeCheckValidity, y la documentación del desarrollador se actualizará en consecuencia.

06/03/2018: se envió un informe y un PoC a Apple para omitir las banderas y verificar estrictamente la codesign .

16/03/2018: información adicional enviada a Apple.

20/03/2018: Apple dijo que no veía esto como un problema de seguridad que debería abordarse directamente.

29/03/2018: Apple declaró que la documentación podría actualizarse, pero "los [...] desarrolladores externos deberían hacer un trabajo adicional para verificar que todas las identidades en el binario universal sean iguales si quieren presentar un resultado significativo".

02/04/2018: primer contacto con CERT / CC y posterior colaboración para aclarar el alcance y el impacto de la vulnerabilidad.

09/04/2018: todos los desarrolladores externos conocidos afectados por la vulnerabilidad son notificados en coordinación con CERT / CC.

18/04/2018: el último contacto con CERT / CC con una recomendación de que divulgar información públicamente en un blog es mejor para notificar a otros desarrolladores externos que utilizan la API de firma de código de Apple de forma privada.

05/06/2018: contacto final con los desarrolladores antes de la publicación.

06/12/2018: divulgación de información.

En conclusión

Gracias a todos los desarrolladores externos por su arduo trabajo y profesionalismo para resolver este problema. Las vulnerabilidades de firma de código son errores especialmente desmoralizantes, especialmente para las empresas que intentan proporcionar una seguridad mejor que la predeterminada en el sistema operativo.

GMO GlobalSign Russia ACTION para suscriptores de Habr

Puede obtener información adicional comunicándose con el gerente de GlobalSign por teléfono: +7 (499) 678 2210, o complete el formulario en el sitio web, indicando el código de promoción CS002HBFR.

Puedo convertirme en Apple, y tú también