I denna första delen om blandade säkerhetstips för Linux, kommer vi gå igenom varför det är så viktigt att hålla koll på program med SetUID-biten satt.

Vi kommer inte att gå igenom själva intrånget här. Det finns mängder av olika sätt att ta sig in på ett system. Alltifrån dåligt kodade PHP-script på webbservern, till säkerhetshål i någon tjänst som körs på maskinen. Eller via en användare som har använt ett svagt lösenord. Eller vi en gammal kärnmodul. Istället kommer vi fokusera på hur man upptäcker ett intrång, och täpper till systemet igen.

SetUID 0 / SetGID 0

När ett intrång har skett är inkräktarens första mål att se till att han behåller sina root-rättigheter. Han eller hon kommer förutsätta att intrånget upptäcks, och att du som systemadministratör då kommer patcha systemet så att han inte kan nyttja säkerhetshålet igen.

För att inkräktaren ska ha möjlighet att bli root igen – han vill ju inte vara en vanlig användare – brukar han placera en rad setuid(0)-program på systemet. Dessa program exekverar ett vanligt skal på systemet, men som root-användaren. På så sätt har inkräktaren återigen root-rättigheter.

Ett sådant program kan i sin enklaste form se ut som nedanstående C-kod.

#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    setuid(0);
    setgid(0);
    execl("/bin/bash", "bash", NULL);
    return 0;
}

Om vi kompilerar detta programmet, sätter ägaren till root, och därefter sätter SetUID- och SetGID-biten, kommer vilken användare som helst som kör programmet att få ett root-skal.

För att inkräktaren ska lyckas sätta ägaren till root, och sätta SetUID- och SetGID-bitarna, krävs att han någon gång under intrånget haft root-rättigheter.

$> gcc myshell.c -o myshell
$> su
Password:
#> chown root:root myshell
#> chmod 6755 myshell
#> exit

Nu har inkräktaren förberett sitt root-skal och kan komma åt alla filer på hela systemet som en vanlig användare.

$> ls -l hemlisar.txt
-r-------- 1 root root 26 sep 17 03:08 hemlisar.txt

$> cat hemlisar.txt
cat: hemlisar.txt: Permission denied

$> ./myshell
#> cat hemlisar.txt
Kära dagbok...

Så enkelt är det alltså för en inkräktare att skapa sitt egna root-skal. Det är därför viktigt att du har koll på vilka SetUID- och SetGID-program som finns på ditt Linuxsystem.

Det finns under normala omständigheter en rad program i Linux som kräver just dessa bitar för att fungera. Bland annat passwd-kommandot kräver SetUID, annars hade inte användarna kunnat ändra sina egna lösenord – de har ju inte rättigheter att ändra vare sig /etc/passwd eller /etc/shadow.

SetUID och SetGID är således rättighetsbitar som gör att vem som helst på systemet kan exekvera programmet som filens ägare eller grupp. SetUID står för set user ID och SetGID står för set group ID. Ägs filen av root, kommer den också att exekveras som root, även om den körs av en vanlig användare.

Hitta program med dessa bitar

Det bästa är att skapa en lista över alla normala program som behöver SetUID-biten och spara listan utanför servern, exempelvis på ett skrivskyddad minneskort. Om du misstänker att ett intrång skett jämför du din säkra lista mot de nuvarande programmen som har SetUID.

För att hitta SetUID- och SetGID-program kan vi använda kommandot find.

#> find / -user root \( -perm -4000 -o -perm 2000 \)
/bin/umount
/bin/fusermount
/bin/mount
/bin/su
/bin/ntfs-3g
/sbin/mount.nfs
/opt/google/chrome/chrome-sandbox
/home/jake/myshell
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/newgrp
/usr/bin/pkexec
/usr/bin/gpasswd
/usr/bin/chfn
/usr/bin/chsh
/usr/sbin/pppd
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/xorg/Xorg.wrap
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/policykit-1/polkit-agent-helper-1

Här ser vi inkräktarens root-skal i listan, /home/jake/myshell. För att maskera sitt root-skal brukar dock en inkräktare placera sitt root-skal i /bin-katalogen och döpa den till något finurligt, t.ex. mount2 eller liknande. Allt för att hindra upptäckt.

Hitta skillnader med diff

Låt oss anta att du har en lista över alla SetUID- och SetGID-program som du skapade när systemet var nyinstallerat. För att jämföra och upptäcka eventuella nya program med dessa bitar satta kan du använda diff. Observera att du måste ha skapat de båda listorna med samma argument till find för att undvika så kallade false positives.

#> find / -user root \( -perm -4000 -o -perm 2000 \) > ny-lista.txt
#> diff saker-lista.txt ny-lista.txt
7a8
> /home/jake/myshell

Här ser vi att /home/jake/myshell är ett nytt program som inte fanns med i den säkra listan över SetUID-program. Alltså är detta något som du som systemadministratör bör undersöka och radera från systemet.

Att radera alla sådana nya SetUID-program är ett första steg för att rensa upp efter ett intrång. Se bara upp så att du inte raderar riktiga systemprogram som faktiskt ska ha dessa bitar satta!

Tänk på att detta bara är ett av många steg för att rensa upp efter ett intrång. Det är aldrig säkert att man hittar alla bakdörrar, root-skal och root-kit efter ett intrång. Man brukar därför utgå från att man aldrig igen kan lita på ett system som haft ett intrång…