Hacking Linux – Hoe kom je binnen in het veilige Linux?

Niet zo lang geleden kwamen veel bedrijven in de problemen door ransomeware, dat overal servers geïnfecteerd had. De geïnfecteerde servers draaiden vooral Windows en Linux bleef redelijk in de luwte. Naar aanleiding van dit ransomware-incident vragen veel beheerders zich echter af hoe veilig Linux nu eigenlijk is. Dit artikel geeft een overzicht van een aantal mogelijke zwakke plekken en wat je daartegen kunt doen. 

 

Door de manier waarop Linux ontworpen is, is het van nature behoorlijk veilig. Dit is voor een groot deel te herleiden tot het gebruik van de execute permissie. Zonder de execute permissie kan geen enkel programma automatisch uitgevoerd worden. De beheerder van de betreffende computer zal eerst als bewuste actie de execute permissie op een script of programmabestand toe moeten passen, voordat een programma uitgevoerd wordt. Bij het aanmaken van een bestand op een systeem zal dat bestand nooit automatisch uitvoerbaar gemaakt worden. Vanwege de manier waarop Linux omgaat met de execute permissie, krijgen virussen op Linux ook weinig kans. Er zijn dan ook eigenlijk geen bekende virussen, noch zijn er virusscanners, die veel meer scannen dan in- en uitgaande mail wanneer Linux gebruikt wordt als mailserver. 

Een tweede kernelement is het gebruik van het root gebruikersaccount. De gebruiker root is de almachtige systeembeheerder waarvoor geen enkele beperking geldt. Alle andere gebruikers kunnen alleen bestanden aanmaken in hun eigen home directory of in /tmp. Dat betekent dat de schade, die een gebruiker bewust of onbewust uit kan voeren, meestal impact heeft op een beperkte omgeving. 

Een ander belangrijk onderdeel van de beveiliging van Linux is Mandatory Access Control (MAC). Er zijn twee belangrijke systemen voor MAC: SELinux en AppArmor. Beide systemen hebben als doel om ervoor te zorgen dat alleen acties, die specifiek zijn toegestaan, uitgevoerd mogen worden. Hiervoor wordt gewerkt met profielen, die aan toepassingen gekoppeld worden. In deze profielen wordt op system call niveau bepaald wat is toegestaan en alles wat niet in zo’n profiel gedefinieerd is, wordt geblokkeerd. 

 

Hacken onmogelijk? 

Tot zover lijkt het alsof het Linux besturingssysteem zijn zaakjes goed voor elkaar heeft en het niet mogelijk is om in te breken. Schijn bedriegt! Er zijn een aantal significante problemen, die ervoor kunnen zorgen dat een verkeerd beheerde Linux-machine de deur wijd open heeft staan voor ongeoorloofde activiteit. In het vervolg van dit artikel zullen we de volgende zaken verder uitwerken:

 

•Aanval op het root wachtwoord;

•Installatie van onbetrouwbare software;

•Uitvoeren van instabiele of onbetrouwbare scripts;

•Brute-force attacks op SSH;

•Zero-day exploits.

 

De gebruiker root

De grootste zwakke plek op Linux is de gebruiker root. Bij het ontwerp van het Linux besturingssysteem werd onderscheid gemaakt tussen geprivilegieerde gebruikers en niet-geprivilegieerde gebruikers. Een niet-geprivilegieerde gebruiker is een gebruiker, die toegang heeft tot beperkte onderdelen van het besturingssysteem. De gebruiker root is de geprivilegieerde gebruiker, waarvoor geen enkele beperking geldt. Je zou kunnen zeggen dat de root gebruiker onbeperkt toegang heeft tot de Linux kernel. Als een aanvaller een root shell kan openen, is hij dus binnen. 

Het spreekt voor zich dat je de root gebruiker voorziet van een zeer sterk en moeilijk wachtwoord. Daarnaast zorg je er als Linux-gebruiker voor om nooit in te loggen als root, want dan wordt elk proces dat je start, gestart met root privileges. Het zwakke punt blijft echter dat de gebruiker root bestaat en dat het onder bepaalde omstandigheden mogelijk is om in te loggen als root. De enige beperkende factor is dat je hiervoor wel consoletoegang moet hebben tot het Linux systeem, terwijl het aan het opstarten is. Op een modern Linux-systeem geeft de volgende procedure vrijwel altijd toegang tot een root shell zonder dat een wachtwoord ingevoerd hoeft te worden. 

 

1.Zorg ervoor dat de doelwitmachine opnieuw opgestart wordt. Zodra je de GRUB2 boot prompt ziet, druk je op e om de editor te openen (zie afbeelding 1).

2.Eenmaal in de editor zoek je de regel op, die begint met linux16. Voeg aan het eind van deze regel de tekst rd.break in. 

3.Gebruik nu de toetscombinatie Ctrl-X. Het Linux-systeem zal nu opstarten, waarbij alleen maar een kernel geladen wordt en het initramfs. Dit initramfs is een minimaal besturingssysteem van waaruit je toegang hebt tot je volledige harde schijf, zonder dat je een root wachtwoord in hoeft te voeren. 

4.Na het opstarten wordt nu een root shell weergegeven. Je bent er dan echter nog niet. Als je het wachtwoord wilt resetten, dien je eerst de volledige toegang tot het root filesystem op de schijf te herstellen. Hiervoor zijn nog een paar commando’s nodig. Tik eerst mount om uit te vinden op welke directory je root filesystem gemount is. In het onderstaande voorbeeld gaan we uit van CentOS, waar het root bestandssysteem op /sysroot gemount wordt. 

5.Type nu: 

mount -o bind /dev /sysroot/dev 

Dit zorgt ervoor dat alle device files beschikbaar zijn.

6.Gebruik nu onderstaande listing, zodat ook de belangrijke kernel interface /proc beschikbaar komt op het tijdelijke root mountpunt.

mount -t proc proc /sysroot/proc 

7.Als deze essentiële bestandssystemen gemount zijn, type je chroot /sysroot om het tijdelijke mountpunt van het root filesystem om te zetten naar de / directory. Dit betekent dat wanneer je tools gebruikt, die toegang nodig hebben tot de / directory op de schijf, het nu allemaal doen. Je kunt nu passwd gebruiken om het root wachtwoord in te stellen. 

8.Tot slot: als je op een distributie werkt waar SELinux aan staat, moet je ervoor zorgen dat het hele bestandssysteem opnieuw voorzien wordt van SELinux context labels. Dit doe je met de opdracht touch /.autorelabel. 

9.Type nu reboot om opnieuw op te starten en in te loggen met je eigen root wachtwoord. Veel plezier met de onbeperkte toegang tot het betreffende systeem!

 

Tegenmaatregelen

Wellicht vraag je je af of het nu echt zo eenvoudig is. Als je geen tegenmaatregelen getroffen hebt: ja. Gelukkig zijn er een aantal maatregelen, die je als eigenaar van een Linux-systeem kunt nemen om het te beschermen tegen deze zwakke plek:

•Zorg dat je Linux-systeem niet fysiek bereikbaar is. Een fysiek bereikbaar systeem kan gehackt worden. 

•Voorzie GRUB van een wachtwoord om toegang te krijgen tot de boot prompt. 

•Als GRUB voorzien is van een wachtwoord, kan je altijd nog inbreken op de server door op te starten van een boot image, zoals een DVD of USB-stick. Dat zet je uit door in de BIOS van het systeem de interne harde schijf als eerste in de boot volgorde te definiëren.

•Voorzie tot slot je BIOS (EFI) van een wachtwoord en zet de Linux-machine achter slot en grendel. Met al deze maatregelen heb je het vrijwel onmogelijk gemaakt om ongeoorloofd het root-wachtwoord te resetten. 

 

Rootkits en software packages

Je hebt eerder kunnen lezen dat er op Linux geen virussen zijn. Sommige mensen zeggen dat dat ook niet hoeft, want op Linux zijn er software packages. Om software te kunnen installeren, moet je met root permissies software packages installeren. Er zijn echter maar heel weinig mensen, die voordat ze dat doen, het package inspecteren om te kijken of het niet toevallig kwaadaardige code (zoals root kits) bevat. 

Wellicht ben je ook al eens in de situatie geweest waar je op zoek was naar een driver of een programma voor je Linux-machine. Een poging te installeren met apt, zypper, dnf of yum leverde niets op, maar gelukkig kwam je ergens op het internet een package tegen met een veelbelovende beschrijving. Het probleem echter met packages van internet is dat je geen idee hebt wat je precies installeert. 

Juist omdat je software packages op Linux installeert met root permissies, is het belangrijk dat je zeker bent van je zaak. Daar is een vrij eenvoudige oplossing voor: gebruik alleen de repositories, die door je distributie beschikbaar gesteld worden. De kans dat hier iets mis mee gaat, is bijzonder klein. Hoe verder je bij de betrouwbare software vandaan gaat, die door jouw Linux-distributie beschikbaar gesteld wordt, hoe groter het risico. Dat geldt al voor min of meer betrouwbaar lijkende externe partijen, maar het geldt helemaal voor packages, die je zelf op internet gevonden hebt. Mocht je toch software downloaden van internet en dit moeten installeren, dan is het zeer verstandig om te analyseren wat je precies gaat doen. Als het om rpm packages gaat, gebruik je hiervoor de opdracht rpm -qp –scripts op een package dat je van internet gedownload hebt, maar voordat je het installeert. 

 

Scripts

Wellicht het grootste probleem dat je tegen komt op Linux, zijn onbetrouwbare of gewoon slecht geschreven scripts. Heel veel toepassingen en met name webservers maken in ruime mate gebruik van scripts. Deze scripts kunnen bijvoorbeeld inbegrepen zijn in webpagina’s en ervoor zorgen dat taken geautomatiseerd uitgevoerd worden bij selectie van een specifieke functie. Dit probleem heb ik live mee mogen maken op een server waar meerdere Apache virtual hosts draaiden voor een aantal websites, die door verschillende mensen onderhouden werden. Het gevolg was een wildgroei aan PHP, Python en Perl scripts, waarbij één van de scripts een optie had om vanuit het script een shell te openen. 

In dit geval werd de schade nog enigszins beperkt, omdat de betreffende Apache-server gebruik maakte van een specifiek account, dat voor deze service aangemaakt was. In dit account was het echter wel mogelijk om een shell te openen, met het gevolg dat een hacker vanuit het script talloze scripts had weggeschreven in de /var/tmp/- directory. Deze scripts waren gezamenlijk bezig om een distributed denial of service attack uit te voeren op een aantal vooraanstaande websites.

Uiteraard had het nooit voor mogen komen om met het httpd account een shell te openen. Dit probleem is eenvoudig te voorkomen door in plaats van /bin/bash een programma als /sbin/nologin of /bin/false als shell te specificeren (en gelukkig doet ook bijna elke moderne Linux-distributie dat voor service-accounts). Het ontnemen van een login shell voor service-accounts biedt echter geen alomvattende oplossing voor securityproblemen, die mogelijkerwijs op kunnen treden. Een systeem voor Mandatory Access Control, zoals SELinux doet dat wel. 

Op een systeem waar SELinux of AppArmor aan staat, worden alleen handelingen toegestaan waarvoor specifiek een regel is aangemaakt in de policy. Dat betekent dat een Apache proces bijvoorbeeld bestanden kan lezen in de Apache DocumentRoot of scripts uit kan voeren vanuit de standaard directory voor scripts. Een handeling daarentegen, die niet specifiek is toegestaan, zal tegengehouden worden. Een voorbeeld hiervan is een script dat bestanden wil aanmaken in /var/tmp/- en deze vervolgens uit wil voeren. Helaas zijn er nog steeds heel veel beheerders die SELinux direct uitzetten, omdat ze er niet goed mee overweg kunnen. 

 

SSH Brute Force

Een volgende populaire kandidaat voor een succesvolle hack op Linux is SSH. Secure Shell is een handige service, die het beheerders mogelijk maakt om van afstand in te loggen op Linux. Tegelijkertijd zet je met SSH echter een service aan, die het voor iedereen mogelijk maakt in te loggen op Linux. Zeker als sshd op de standaardpoort 22 draait en je systeem rechtstreeks aan het internet verbonden is. Uit meerdere tests blijkt dat een dergelijk systeem binnen een kwartier gevonden is en de eerste SSH brute force attack te verduren krijgt. 

In een SSH brute force attack probeert de aanvaller toegang te krijgen door geautomatiseerd voor de hand liggende gebruikersnamen en vaakgebruikte wachtwoorden uit te proberen om in te loggen. Als de aanvaller dit maar lang genoeg kan proberen, zal dit uiteindelijk ook wel een keer lukken. 

De mogelijkheid om toegang te krijgen via SSH is echter vrij eenvoudig tegen te houden door de SSH-service zelf te voorzien van een aantal niet-standaard parameters. Om te beginnen is het aan te raden om geen SSH-services aan te bieden op de standaardpoort 22. Geautomatiseerde scripts scannen doorgaans namelijk alleen op die poort. Vervolgens is het een goed idee om gebruik te maken van de optie AllowUsers, waarmee je aangeeft welke gebruikers via SSH in mogen loggen en toegang ontzegt aan alle andere gebruikers. Daarnaast kun je overwegen SSH-logins door middel van wachtwoorden uit te zetten en alleen toegang te verlenen aan gebruikers, die gebruikmaken van een SSH public/private key paar. Met deze maatregelen zorg je ervoor dat SSH nagenoeg onneembaar wordt. 

 

Zero-day exploits

Tot slot is er nog een categorie zwakheden in Linux (en elk ander besturingssysteem) dat aandacht behoeft: de zero-day exploit. Dit zijn zwakheden in software die nog niet algemeen bekend zijn en dus nog ontdekt moeten worden. Omdat dit type nog niet bekend is, is het lastig je ertegen te wapenen. Toch zijn er maatregelen die je kunt nemen. 

Om te beginnen, is het noodzakelijk om regelmatig patches en updates te installeren. Wellicht is de onbekende exploit bij jouw distributie allang gevonden en staat de oplossing gewoon klaar in de vorm van een patch. De dagen van “If it ain’t broke, don’t fix it” liggen ver achter ons en elk modern computersysteem dat aan internet verbonden is, behoort met regelmaat voorzien te worden van de allerlaatste patches. 

Wil je echt bovenop de feiten zitten en op de hoogte blijven van nieuwe problemen, zelfs voordat er patches voor zijn uitgebracht? Dan is het de moeite waard om de website http://cve.mitre.org in de gaten te houden. Hier worden namelijk alle beveiligingsproblemen gepubliceerd op het moment dat ze bekend zijn.Dit stelt je in staat om meteen maatregelen te nemen als de problemen op jouw omgeving van toepassing zijn. 

Daarnaast kun je onbekende problemen in zekere mate tegenhouden door gebruik te maken van Mandatory Access Control. Zoals eerder besproken, houd je hiermee handelingen tegen, die een toepassing niet zou horen te doen en dat beperkt het risico dat zero-day exploits schade aanrichten aanzienlijk. 

 

Conclusie

Zoals elk besturingssysteem heeft Linux een aantal zwakke plekken. Daarnaast biedt Linux echter ook alles wat nodig is om jouw systeem tegen die zwakke plekken te beschermen. Als je de risico’s dat jouw Linux-systeem gehackt wordt tot een minimum wilt beperken, volstaat het om een paar maatregelen te nemen. 

Om te beginnen zou elk Linux-systeem gebruik moeten maken van SELinux of AppArmor. Hiermee voorkom je dat toepassingen handelingen uit kunnen voeren, die ze niet uit zouden moeten kunnen voeren. Denk daarbij aan het script in de webserver dat een shell wil openen, maar ook aan onbekende gevaren, die bestaan door een zero-day exploit. Dit dient gecombineerd te worden met een consequente updatestrategie. Als je niet regelmatig zelf wilt bekijken welke nieuwe exploits gepubliceerd zijn, zorg je er toch vrij eenvoudig voor dat de jou onbekende problemen voorkomen worden door updates te installeren. 

Een derde maatregel die behoorlijk efficiënt is, is sshd services aan te bieden op een niet-standaard poort, zodat dictionary attacks weinig kans maken. Combineer dat met de AllowUsers parameter in sshd_config en zorg ervoor dat inloggen op afstand alleen is toegestaan door één account met een ongebruikelijke naam. Tot slot, als het mogelijk is de server fysiek te beveiligen door hem in een afgesloten ruimte te zetten, houd je daarmee ook alle pogingen tegen om het root wachtwoord ongeoorloofd te veranderen, met als resultaat een Linux-systeem die bijna niet te hacken is.