Pasa todos los días. El sistema operativo te permite usar cierta funcionalidad a través de una API (interfaz de programación de aplicaciones) para realizar una tarea... Pero la usas mal y la acabas liando. Lo cierto es que a veces no ayuda la documentación, ya que algunas escriben lo justo para que entiendas el ejemplo que viene incluido. Hay días que incluso te ves echando un vistazo rápido al código fuente de la librería (si es que es de código abierto), a ver cómo cierta función maneja un argumento en particular. Y es que algo que parece tan sencillo como decir si un ejecutable está firmado por Apple o no se puede complicar...
Y en este caso se ha complicado. Múltiples programas de terceros, realizados por empresas con nombres tan sonados como Facebook, Google o F-Secure, no hacen un uso correcto de la API que proporciona macOS para comprobar código firmado. Básicamente permite que un atacante introduzca código no firmado en un ejecutable firmado, sin que suenen las alarmas y haciendo que se ejecute el código no firmado en lugar del firmado. ¿Cómo es posible esto?
En primer lugar, tenemos que tener en cuenta que macOS todavía permite ejecutar código no firmado (tiempo al tiempo), con lo que como mucho, lo que nos llevamos a día de hoy es una advertencia (y eso si lo ejecutas desde la interfaz gráfica y no desde consola). Por tanto, la ejecución puede darse igualmente. El problema viene cuando herramientas de seguridad (software antivirus, herramientas forenses...) utilizan la firma de los ejecutables para marcarlos como confiables y no procesarlos... Que si no realizas esta verificación exhaustivamente, se te puede colar uno que al ejecutarse, termine corriendo código no firmado.
Concretamente, para que esto pase debe crearse un ejecutable con ciertas características que no detallamos por no pasarnos de técnicos. Aunque sí detallamos las más importantes, siendo la que más que debe ser un ejecutable Fat (también llamado Universal), que es un contenedor de múltiples ejecutables. Este formato se pensó originalmente para contener el mismo código pero compilado para distintas arquitecturas (PowerPC, i386, y x86_64).
 |
| Ejecutable Fat en el que se aprecian dos ejecutables de distintas arquitecturas. Extraído de okta.com. |
Sabiendo esto, ya podemos empezar a entender cómo se construye este ejecutable malicioso. Lo primero es empaquetar en un ejecutable Fat un ejecutable original firmado por Apple junto con el ejecutable malicioso que pretendemos terminar ejecutando. Este último debe tener ciertas características por sí mismo y compartir alguna que otra con el ejecutable de Apple, pero no las detallamos por ser triviales de cumplir.
El problema está en que un ejecutable así construido pasa la verificación más sencilla proporcionada por la API del sistema operativo y usada por programas de terceros. Esto se debe a que exceptuando el primer ejecutable contenido, no se verifica la entidad certificadora raíz de los ejecutables. Esto permite que el segundo ejecutable sea autofirmado (cosa que se puede hacer sin problema), y el ejecutable Fat se siga considerando firmado por Apple en su totalidad.
Por último, y para que la parte responsable del sistema operativo de cargar los ejecutables en memoria no cargue el primer ejecutable (que es lo natural siempre y cuando la arquitectura sea compatible), se usa un pequeño truco: malformar a propósito la cabecera del primer ejecutable que indica la arquitectura, para que el cargador del sistema operativo vea un valor no válido y salte a ejecutar el segundo ejecutable malicioso.
Todas las empresas detrás de las herramientas afectadas conocidas lo han reconocido y corregido, y se ha asignado un CVE por cada herramienta.
Más información:
I can be Apple, and so can you
https://www.okta.com/security-blog/2018/06/issues-around-third-party-apple-code-signing-checks/
https://www.okta.com/security-blog/2018/06/issues-around-third-party-apple-code-signing-checks/
