Nueva vulnerabilidad de día cero en Apple iOS permite hackear el sandbox fácilmente y robar datos entre aplicaciones

Como sabemos, los productos de Apple suelen ser más costosos que sus contrapartes de otras compañías. Expertos en auditoría de sistemas de información aseguran que esto se debe a su especial énfasis en la privacidad e integridad de sus productos y a la seguridad en Apple Store, considerada la fuente más segura para la descarga de aplicaciones para el sistema iOS. 

Aunque se cree que la prueba de seguridad de Apple es la más difícil de todas las otras plataformas disponibles, hoy nos hemos encontrado con un investigador que ha estado jugando con esta seguridad durante casi tres años y Apple ahora puede identificar y corregir sus errores en el sistema iOS 13.5. Aún así, algunos no pueden creer esto, pero sí, esta es la realidad de cómo un investigador de seguridad ha estado usando este error durante casi tres años para su propio beneficios. Los errores no son más que las verificaciones de integridad que realiza Apple para permitir a los desarrolladores obtener sus aplicaciones en Apple Store.

Hay algunas funciones o recursos que están restringidos solo a los usuarios root y las aplicaciones de terceros no pueden usarlos. No obstante, expertos en auditoría de sistemas de información mencionan que este error está permitiendo que un desarrollador pueda escalar algunos permisos que solo se conservan para el usuario root, y no para las otras aplicaciones. Veamos en detalle qué es exactamente el error.

Análisis detallado

Imagine que es un desarrollador y quiere publicar su aplicación en App Store. Lo primero que debe hacer es verificar las reglas y regulaciones requeridas por Apple para publicar su aplicación, por lo que necesita todos sus archivos de configuración y firmas de código en el archivo plist (un archivo que almacena datos en formato serializado). Apple utiliza este formato en su configuración de macOS y básicamente encontrará dos tipos de archivos plist:

  • Bplist (un formato binario que los humanos no pueden leer y es más rápido que cualquier otro archivo plist)
  • Archivo Plist en formato XML o JSON

Si tomamos en consideración el formato del archivo plist en XML (Lenguaje de marcado extensible):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>OS Build Version</key>
    <string>19D76</string>
    <key>IOConsoleLocked</key>
    <false/>
    <!-- abc -->
    <key>IOConsoleUsers</key>
    <array>
        <dict>
            <key>kCGSSessionUserIDKey</key>
            <integer>501</integer>
            <key>kCGSessionLongUserNameKey</key>
            <string>Siguza</string>
        </dict>
    </array>
    <!-- def -->
    <key>IORegistryPlanes</key>
    <dict>
        <key>IODeviceTree</key>
        <string>IODeviceTree</string>
        <key>IOService</key>
        <string>IOService</string>
    </dict>
</dict>
</plist>

Estos archivos plist también se pueden usar para almacenar derechos, mencionan los especialistas en auditoría de sistemas de información, que son los permisos del usuario para acceder a un recurso en particular en el entorno. Aunque en un entorno UNIX, un usuario normal no puede tener acceso a los recursos del usuario raíz, pero aquí los sistemas operativos Apple (iOS o MAC OS) aunque los sistemas operativos UNIX tienen algunas relajaciones y usan los derechos para permitir que el usuario dé acceso a un tarea particular o un recurso.

Cada aplicación que se desarrolla tiene su propio binario. Un desarrollador necesita una extensión llamada AppleMobileFileIntegrity (o “AMFI”) para ejecutar el binario en el sistema y para esto, necesita validar su identidad que el núcleo conoce o estas comprobaciones pueden validarse a través del certificado firmado por el verificado autoridad.

Ahora viene el panorama general, ¿quién será esa autoridad verificada que firma el certificado para la aplicación de desarrolladores? Esa autoridad puede ser la propia Apple Store para la cual la aplicación del desarrollador debe pasar alguna prueba de seguridad difícil y es seguro que si hay algún contenido malicioso, se bloqueará de inmediato. Entonces, si un hacker está tratando de pasar por esto, se confirma que no podrá pasar la prueba y es posible que no logre sus motivos.

La otra forma es que el desarrollador autofirma el certificado que es válido durante 7 días y necesita otro parámetro de verificación de seguridad, es decir, el perfil de aprovisionamiento para verificar la identidad del desarrollador y decidir cuánto privilegio debe otorgarse a ese binario. Xcode (IDE de Apple) o, a veces, un software de terceros lo busca por usted. Es algo así como una garantía o testimonio de una tercera persona de que usted es legal. Después de que, de alguna manera, el desarrollador se las arregla para dar un perfil provisional para demostrar su identidad, la aplicación puede ejecutar su binario y, si hay algún demonio en lugar del desarrollador, puede otorgar cualquier derecho en su binario para hacer alguna tarea malvada

Pero, de manera predeterminada, Apple mantiene las aplicaciones de terceros en una zona de contención y permite muy poco acceso a los recursos del sistema. Entonces, ¿cómo puede un atacante ejecutar los derechos? Según expertos en auditoría de sistemas de información, Apple tiene cuatro analizadores (un software que convierte el texto de entrada a formato estructural para que la máquina lo procese):

  • OSUnserializeXML en el kernel
  • IOCFUnserialize en IOKitUser
  • CFPropertyListCreateWithData en CoreFoundation
  • xpc_create_from_plist en libxpc (fuente cerrada)

Todos estos analizadores pueden analizar los derechos, pero todos tienen diferentes resultados. Lo que significa que, considere que programó dos calculadoras diferentes, en la primera dice que solo 2 + 2 = 4 y en la segunda dice que solo 1 + 3 = 4. Entonces, si consulta la primera calculadora, dígame que si 1 + 3 = 4, dará la salida no, mientras que la segunda calculadora dirá sí. Entonces, todos estos analizadores diferentes tienen una sintaxis diferente. Por lo tanto, un atacante puede engañar fácilmente al analizador que realmente utiliza el kernel mientras puede ejecutar a través de otros analizadores y, al igual que en realidad, el sistema escuchará a los analizadores de la mayoría de los tres e ignorará al otro. Entonces, al tener acceso a casi todos los recursos, un atacante puede inyectar algo de carga o generar código, generar un shell o cualquiera de literalmente miles de otras cosas.

Conclusión

Este fue solo un día cero que fue descubierto hace tres años por un investigador de seguridad y ahora está arreglado en iOS 13.5 aunque es una versión beta, esperamos que la compañía lance pronto su versión estable. No es necesario subestimar la seguridad de Apple, ya que no se trata solo de un script que ejecuta cualquier script kiddie y pasará por alto su seguridad. Estos errores deben ser realmente apreciados cuando se descubren y la empresa debe responder a ellos tan pronto como sea posible.

Para mayores informes sobre vulnerabilidades, exploits, variantes de malware y riesgos de seguridad informática puede ingresar al sitio web del Instituto Internacional de Seguridad Cibernética (IICS), al igual que a las plataformas oficiales de las compañías tecnológicas.