Hoy noté que Adobe Desktop Services está monitoreando constantemente / etc / passwd.

¿Sería el punto? Las contraseñas no se almacenan en / etc / passwd, entonces, ¿por qué una aplicación supervisaría / etc / passwd? ¿Qué información podrían estar tratando de monitorear?

Adobe Desktop Service no estaba mirando su / etc / passwd. La biblioteca del sistema de Apple era.

La biblioteca del sistema de Apple quería saber su nombre de usuario para poder encontrar su directorio de inicio. Luego decidió que la mejor manera de averiguar su nombre de usuario era buscarlo /etc/passwd. Adobe Desktop Service solo quería saber la ruta de acceso a su directorio de inicio y ¿(correctamente) lo usó? el marco de CoreFoundation para eso. Es por eso que la llamada aparece bajo el proceso de Adobe.

Detalles

En su captura de pantalla, la entrada de la persona que llama dice algo así _fsi_get_user. Este es el símbolo de una subrutina privada en una de las bibliotecas del sistema macOS libsystem_info.dylib, ubicada en /usr/lib/system.

El código fuente público de la _fsi_get_userfunción revela la siguiente lógica:

if (geteuid() == 0)
{
  // […]
}
else
{
  f = fopen(_PATH_PASSWD, "r");
  _fsi_get_validation(si, VALIDATION_PASSWD, _PATH_PASSWD, f, &va, &vb);
  fmt = 1;
}

Mirando el código descompilado en libsystem_info.dylib(por ejemplo, usando Hopper Disassembler) confirma que ese _PATH_PASSWDes realmente el nombre del archivo /etc/passwd. (El código fuente más abajo file_module.ctambién explica por qué hay una llamada a fstatinmediatamente después de fopen: la implementación de _fsi_get_validation? Hace eso para averiguar el último tiempo de modificación de su /etc/passwd).

En otras palabras: Adobe no estaba mirando su archivo passwd; La biblioteca del sistema de Apple era.

Conectando los puntos

Hay muchas pilas de llamadas posibles que pueden conectar el código de Adobe Desktop Service a la _fsi_get_userfunción. ¿Un poco de análisis estático sugiere lo más plausible? candidato sería NSHomeDirectory, una clase de utilidad en Foundation.framework.

Mirando el binario de Adobe Desktop Service revela que efectivamente llama [NSHomeDirectory UTF8String]:

*100032ac4   call   imp___stubs__NSHomeDirectory
*100032ac9   mov    rsi, qword [0x10008a178]  ; "UTF8String"
*100032ad0   mov    rdi, rax
*100032ad3   call   qword [_objc_msgSend_100088350]

La implementación de Apple NSHomeDirectorynos llevará a /etc/passwdbastante rápido. Mi suposición educada sobre la cadena más probable de llamadas a funciones sería:

Adobe Desktop Service → [NSHomeDirectory UTF8String](en Foundation.framework) → NSHomeDirectoryForUser→ CFCopyHomeDirectoryURLForUser(en CoreFoundation.framework) → _CFCopyHomeDirURLForUser→ getpwuid(en libsystem_info.dylib, reexportado a través de libSystem.B.dylib) → si_user_byuid(aquí es donde Apple decide en tiempo de ejecución qué fuente va a utilizar. Por ejemplo, si su ID de usuario está entre 1 y 499 , /etc/passwdse le consultará en lugar de Servicios de directorio. ) → file_user_byuid→ _fsi_get_user.

Para estar más seguro, analicé el servicio binario de escritorio de Adobe y, como era de esperar, no contiene ninguna referencia única /etc/passwd. (Sin embargo, no he comprobado si Adobe Desktop Service hace o no otras cosas sospechosas).

Todo el análisis hubiera sido un poco más fácil si hubiera hecho clic en una de las entradas antes de crear la captura de pantalla. Su aplicación habría mostrado el seguimiento de pila relevante en la esquina inferior derecha (son las líneas donde dice Seguimiento de pila ). Pero bueno, me divertí mucho descubriéndolo, ¡y aprendí mucho de esa manera!

Verificación

Para confirmar que mi análisis es correcto, es posible que desee hacer clic en una de las /etc/passwdentradas en su aplicación de instrumentos y encontrar los términos NSHomeDirectoryy file_user_byuiden algún lugar del seguimiento de la pila.

De la información en su captura de pantalla, el programa no está tratando de "monitorear" el contenido del archivo. En su lugar, solicita repetidamente los metadatos sobre el archivo (es decir, si el archivo existe, qué tan grande es, cuándo se creó, etc.).

Solo Adobe puede decirle por qué codificaron su programa de la manera en que lo hicieron.

Sin embargo, tenga en cuenta que hay múltiples explicaciones lógicas de por qué hicieron lo que hicieron, eso no implica actividades de "espionaje" o "nefastas".

Por ejemplo, este programa de daemon en particular (es decir, el servicio en segundo plano) puede verificar constantemente la existencia de / etc / password para determinar que (a) no está protegido y (b) no está despojado de sus permisos, por lo que está prohibido Examina ese archivo.