6 votes

Comment identifier l'application/processus qui re-monte les partitions R/W, crée des fichiers et modifie les permissions des fichiers ?

J'ai un appareil enraciné, avec des droits de superutilisateur accordés à quelques applications auxquelles je fais confiance. J'ai souvent trouvé mon /system o /vendor partition montée en lecture/écriture, et certains fichiers chmod ed à 0777 . De même, des répertoires/fichiers aux noms aléatoires sont créés/supprimés (ex. /sdcard/.a03Degpoif ), .nomedia sont créés à l'intérieur de ceux-ci pour cacher leur contenu à la galerie, etc.

logcat / dmesg ne contient aucune trace de tout cela en arrière-plan. Cela ne se produit pas périodiquement mais de façon désordonnée, la connectivité internet n'est pas non plus une condition. J'ai essayé de désactiver/désinstaller des applications, de rechercher des processus suspects en cours d'exécution, mais je n'ai pas pu identifier le ou les coupables.

Y a-t-il un moyen de savoir qui fait ça ?

5voto

Irfan Latif Points 16863

Nota _: La solution suivante nécessite un appareil enraciné. Le noyau doit être construit avec AUDIT_WATCH de préférence AUDIT_TREE ._

La seule bonne chose que Google ait faite, c'est de choisir le noyau Linux, flexible et configurable, pour Android, et de ne pas opter pour quelque chose comme un système d'exploitation à base d'ADN. Noyau endommagé et essayer de tout gérer depuis l'espace utilisateur, y compris faire tourner un noyau Linux ( 1 ) .

Le noyau de Linux Système d'audit permet d'enregistrer tous les appels système ou les modifications du système de fichiers effectués par un processus. Dans notre cas, nous avons besoin d'identifier le(s) processus qui écrivent dans le fichier /sdcard o /system et faire des appels syscals mount y chmod .

Les distributions Linux disposent d'un service auditd qui communique avec le noyau pour obtenir des informations sur les événements liés à la sécurité. Sur Android, nous avons déjà logd pas aussi configurable que auditd mais suffisant pour une surveillance de base. logd couvre principalement les fonctionnalités de son homologue de bureau syslogd mais aussi klogd et partiellement auditd pour obtenir les journaux du sous-système SELinux du noyau.

Nous pouvons ajouter quelques règles supplémentaires en utilisant auditctl pour signaler également les événements qui nous intéressent. Vous pouvez utiliser auditctl à partir d'un environnement Linux minimal sur votre appareil Android, ou compilez le binaire à partir du code source (doit être construit avec --avec le bras / --avec-aarch64 quelle que soit l'architecture de vos appareils), ou en obtenir un pré-compilé ici .

Créez maintenant des fichiers de règles dans /etc ou où vous le souhaitez :

# /etc/audit-start.rules

# enable auditing, won't work in PID namespace
# won't work if permanently disabled with kernel parameter "audit=0"
-e 1

# delete previous rules (though there are none on Android)
-D

# increase the buffers to avoid failure
# no. of event to be queued, waiting for logd to read them
-b 10000

# disable rate limit (msgs/sec) to avoid failure
-r 0

# this determines how long to wait in burst of events
--backlog_wait_time 0

# set failure mode to dmesg
-f 1

# define filesystem rules, whatever file/directory you want to watch
-w /system -p wa -k FILESYSTEM_AUDIT

# define syscall rules, see all syscalls with 'ausyscall --dump' or
# here: github.com/linux-audit/audit-userspace/blob/master/lib/aarch64_table.h
-a always,exit -S fchmod -S fchmodat -k CHMOD_AUDIT
-a always,exit -S mount -k MOUNT_AUDIT

# /etc/audit-stop.rules

# clear on exit, restore Android default values
-e 0
-D
-b 64
-r 5
--backlog_wait_time 18000

Appliquer les règles :

~# auditctl -R /etc/audit-start.rules

Maintenant, faites des changements ; montez /system R/W, écrire/supprimer quelque chose à cet endroit et changer les permissions du fichier.

En fonction de logd vous pouvez obtenir audit journal dans un ou plusieurs journaux différents ( 2 ) y compris events tampon ( 3 ) de logcat y main tampon ( 4 ) :

~# logcat -d -b events,main | grep _AUDIT

Ou dans le noyau printk tampon ( 5 ) y logact 's kernel tampon ( 6 ) :

~# dmesg | grep _AUDIT
~# logcat -d -b kernel | grep _AUDIT

audit(0.0:16122): arch=c00000b7 syscall=40 success=yes exit=0 a0=7fcec5db38 a1=7fcec5db3f a2=0 a3=8021 items=1 ppid=761 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="busybox" exe="/data/data/com.mixplorer/files/busybox/busybox" subj=u:r:magisk:s0 key="MOUNT_AUDIT"
audit(0.0:16126): arch=c00000b7 syscall=53 success=yes exit=0 a0=ffffff9c a1=7b839180c0 a2=81a4 a3=0 items=1 ppid=11687 auid=4294967295 uid=10135 gid=10135 euid=10135 suid=10135 fsuid=10135 egid=10135 sgid=10135 fsgid=10135 tty=(none) ses=4294967295 comm="Thread-7" exe="/system/bin/app_process64" subj=u:r:untrusted_app:s0:c135,c256,c512,c768 key="CHMOD_AUDIT"
audit(0.0:16141): arch=c00000b7 syscall=35 success=yes exit=0 a0=ffffff9c a1=7bc22a3c40 a2=0 a3=7bdfbd3098 items=2 ppid=11687 auid=4294967295 uid=10135 gid=10135 euid=10135 suid=10135 fsuid=10135 egid=10135 sgid=10135 fsgid=10135 tty=(none) ses=4294967295 comm="pool-2-thread-1" exe="/system/bin/app_process64" subj=u:r:untrusted_app:s0:c135,c256,c512,c768 key="FILESYSTEM_AUDIT"

La première ligne montre qu'un processus s'exécutant en tant que Root avec le contexte SELinux de Magisk a fait un syscall 40 ( mount ) et la commande montre qu'il s'agit de l'application MiXplorer (juste à titre d'exemple, je l'ai fait moi-même). La deuxième ligne indique que l'application s'exécute avec l'UID 10135 tiene chmod de quelque chose.
La troisième ligne montre la même application (en faisant le syscall 35 ) a supprimé quelque chose dans /system partition.

Il s'agit d'un cas d'utilisation simple. Des règles plus récursives peuvent être définies pour traiter des situations complexes, en interprétant également d'autres champs du journal, comme expliqué ci-dessous ici .

Pour effacer les règles :

~# auditctl -R /etc/audit-stop.rules

NOTE :

  • Pour les cas simples où l'objectif est juste d'être notifié de certains changements dans le système de fichiers (et non de tracer l'auteur), inotify peut être utilisé à la place comme expliqué dans cette réponse .
  • Afin de marquer tous les processus qui s'exécutent avant le début de l'audit comme auditables par le noyau, passez la commande audit=1 paramètre de démarrage au noyau, soit en éditant cmdline en boot.img ou utiliser fastboot -c option.
  • Pour enregistrer le journal d'audit dans un fichier, exécutez logcat en arrière-plan :

    logcat -s auditd -b events -f /data/media/0/auditd.log &

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X