Linux-rootkit udnytter stjålne SSH-nøgler

US-CERT advarer om flere angreb mod Linux-systemer, hvor stjålne SSH-nøgler bliver brugt til at installere et rootkit på systemet.

Den amerikanske offentlige it-sikkerhedsinstitution US-CERT har udsendt en advarsel om, at der er registreret flere angreb, hvor Linux-systemer er blevet inficeret med et rootkit, som åbner en bagdør til systemet.

Infektionen sker angiveligt ved hjælp af stjålne SSH-nøgler til fjernadgang til systemet.

Ifølge sikkerhedsorganisationen SANS Internet Storm Center kan der være tale om angreb, der er relaterede til den sikkerhedsbrist, som tidligere i år blev opdaget i en algoritme i Debian GNU/Linux.

Sårbarheden betød, at det var væsentligt lettere at gætte en nøgle, fordi tilfældighedsgeneratoren i algoritmen ikke fungerede.

US-CERT anbefaler, at man kontrollerer, hvilke Linux-systemer der benytter SSH-nøgler uden samtidig at være beskyttet af en adgangskode. Det vil typisk være applikationer, som kommunikerer via SSH.

Benytter man adgangskoder sammen med SSH-nøgler vil risikoen være mindre, da det nuværende angreb udelukkende sker ved hjælp af nøglerne og derfor ikke fungerer mod kombinationen af kodeord og nøgle.

US-CERT angiver ligeledes, hvordan man kan opdage rootkittet ved at biblioteket /etc/khubd.p2 ikke bliver vist med kommandoen ls, men kan tilgås med cd-kommandoen.

Kommentarer (17)

Christian Nobel

US-CERT angiver ligeledes, hvordan man kan opdage rootkittet ved at biblioteket /etc/khubd.p2 ikke bliver vist med kommandoen ls, men kan tilgås med cd-kommandoen.

Der er vel tale om et skjult bibliotek, så det er da ikke nødvendigt at lave cd, men bare benytte ls -a.

/Christian

Ove Andersen

Rootkittet skal vel installeres som root - altså en almindelig bruger kan da ikke installere et rootkit, med mindre der er noget helt galt?

Og en linux administrator med lidt sikkerhed i mente ved jo, at man ikke tillader root adgang via SSH.

Så for at installere rootkittet skal der logges ind via SSH og derefter opnås root adgang?

For at teste mod rootkit bruger jeg selv chkrootkit og rkhunter på min Debian server og laptop..

Ove Andersen

Helt korrekt, men det er da temmeligt besværligt først at skal knække en usikker SSH nøgle for derefter at skal til at rode et system igennem efter en root sårbarhed.

SSH breaket er temmeligt sikkert nemt at automatisere, mens det andet er mere besværligt..

Christian Nobel

Nej, der er tale om en version af ls der er patchet til ikke at vise kataloger der hedder khubd.p2.

Hvordan fremkommer at ls er patchet, er det rootkittet der har sørget for det?

Og så en anden lille generel sikkerhedsbetragtning, undlad selvfølgelig at benytte port 22 til ssh adgang udefra.

/Christian

Peter Makholm

Hvordan fremkommer at ls er patchet, er det rootkittet der har sørget for det?

Ja, at installere sin egen version af ls er en ret primitiv, men normal, måde at rootkits holder sig skjulte.

Thomas Ammitzbøll-bach

Det er et gammelt flamewar-emne, og det er fordi, der er ulemper ved begge dele.

I en supersikker server, der er det slet ikke muligt at logge ind som root ved andet end konsollen. Man ikke lave su, sudo el.lign. Der er ingen kommandoer, der kører suid, og enhver forbindelse fra uprivilegerede brugere til root.

Men sådan er virkeligheden bare ikke. Enhver systemadministrator nægter at sidde i et serverrum mere end en halv time af gangen. Så kravet er der jo om, at man skal kunne komme fra en uprivilegerede konto til root.

Argumentet for, at man ikke må kunne logge ind gennem SSH direkte som root, er følgende: Alle ved, at root login hedder "root", så det har vi. Nu skal vi bare gætte password. Hvis man først skal logge ind som "ole" med Oles password, og man derefter kan bruge su til at blive root, så er der tre ting man skal vide: Oles loginnavn, Oles password og roots password.

Fint nok, men er det mere sikkert? Lidt... loginnavn og password er multiplikativt forbundne, sådan at man ikke kan vide, om man har valgt et eksistende loginnavn, hvis man ikke også har det rigtige password. Har man det, skal man additivt gætte root-password for at få root-adgang. Men i det regnestykke skal man huske, at der er flere uprivilegerede konti, som summerer reciprokt. Det forbedrer altså kvaliteten af sikkerheden, men kun additivt. (Sagt på en anden måde: Det svarer til at øge sikkerheden til en garage ved at sætte to hængelåse på porten i stedet for en.)

Desværre bliver sikkerhed lavere, hvis man bruger sudo. Hvis man skal logge ind som "ole" og Oles password er ringere end root-password, og blot derefter kan få root-adgang med sudo, så er sikkerheden blevet dårligere end hvis der kun var adgang til root-kontoen fra SSH med root-password.

Nu er der jo i SSH facilitet til, at man ikke skal bruge passwords men kan anvende kryptografiske nøgler. Artiklen handler om stjålne nøgler, men den er ikke så klar på, hvor de stjålne nøgler er taget fra. Hvis der er tale om brudte nøgler på grund af fejlen i Debian, så er løsningen jo først og fremmest at få genererede nogle nye nøgler i en fart.

Fordelen ved nøglerne er, at man kan give andre folk root-adgang (konsulenter etc.) uden at de skal kende root-password. Hvis en ekstern person genererer en nøgle og denne nøgle tilføjes roots authorized_keys af en systemadministrator, så har man ikke root-passwords ud i det fri.

Hvis man har mange servere, og der laves automatisering af opgaver, der indvolverer flere maskiner, så er man nødt til at have root-adgang, der ikke baserer sig på passwords. Alternativet er, at en administrator logger ind på hver maskine, bliver root og derefter starter rutinen op.

I praksis ser jeg også en række andre ting i det virkelige liv: Jo flere krumspring man skal i gennem for at få en root-shell, desto mere tilbøjelige er folk til at gå fra en desktop med et gabende shell-vindue.

Det bedste, man kan gøre, er at forhindre SSH-adgang fra andre IP-adresser end dem, der eksplicit skal have adgang. Det er bare et par linier i et iptables-script

Thomas

Christian Nobel

Ja, at installere sin egen version af ls er en ret primitiv, men normal, måde at rootkits holder sig skjulte

Tak, så giver det mere mening, og længe leve forummet for at bidrage med den forståelse man ikke får fra artiklerne.

/Christian

Sune Rentow

Når man er i gang med iptables så kan man tilføje følgende:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Det vil maksimalt tillade tre nye forbindelser fra en bruger hvert minut. På den måde bliver det svært at teste store mængder passwords, men normale brugere kan logge på normalt uden diverese krumspring.

Jarnis Bertelsen

Det vil maksimalt tillade tre nye forbindelser fra en bruger hvert minut. På den måde bliver det svært at teste store mængder passwords, men normale brugere kan logge på normalt uden diverese krumspring.

Det gør dig naturligvis sårbar for DoS angreb. Du skal kunne acceptere at blive lukket ude af din server, hvis en hacker havde besluttet sig for at bryde koden. Jeg tror ikke det ville være et problem for de fleste, og det vil nok ske meget sjældent, men man skal nok lige overveje det, hvis det er meget kritisk at man altid har adgang til maskinen. En simpel løsning kunne være, kun at tillade 3 forsøg fra den samme ip adresse. Desværre vil det nok betyde, at man er sårbar for et distribueret angreb fra fx et botnet. Jeg er sikker på at der findes masser af bedre løsninger, hvis man tænker lidt over det.

Martin Larsen

Jeg bruger programmet denyhosts til automatisk at udelukke gentagne forsøg på at få adgang: http://denyhosts.sourceforge.net

Det nytter selvfølgelig ikke noget hvis indtrængeren har en stjålen nøgle, men det er så ikke nødvendigvis en usikkerhed ved systemet selv. Lidt ligesom at bilens startspærrer ikke hjælper et hak hvis tyven har din nøgle.

Peter Mogensen

Den primære fordel ved at skifte port er nok at det er nemmere at ikke at skulle se efter mistænkelige ting i loggen, hvis den ikke er fyldt med robotter, der forsøger at logge ind som "mysql" og lign. via SSH.

Selve sikkerheden er vist begrænset. Hvis man endelig vil skjule sin SSH-port, så skal man nok kigge på fwknop og single-packet-authorization.

Peter Jensen

Jeg har også flyttet mine ssh porte og det er ren dovenskab (gider ikke lave et firewallscript der udelukker bestemte ipnumre), før var der altid en eller anden knold der brugte min båndbrede på at bryde ind, og da jeg kun bruger nøglefiler og de vist endnu ikke er hugget fra mig, spildte de deres tid, så for nu ikke at spilde andres tid, flyttede jeg porte og vupti siden har jeg ikke set en eneste der brugte deres oppetid på at forsøge at besøge mig, men ja det er rigtigt der er ingen sikkerhedsforbedringer i portskift, blot viser praktisk erfaring at man slipper for forsøg på besøg.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

CERT 70-480 Programming in HTML5 with JavaScript and CSS3

Hvornår: 2015-10-09 Hvor: Storkøbenhavn Pris: kr. 4950.00

Project 2010 Videregående

Hvornår: 2015-11-26 Hvor: Østjylland Pris: kr. 3500.00

Managing Office 365 Identities and Requirements [20346]

Hvornår: 2015-10-26 Hvor: Østjylland Pris: kr. 19500.00

MCP 10748 kursus: Deploying System Center 2012 Configuration Manager

Hvornår: 2015-11-16 Hvor: Storkøbenhavn Pris: kr. 11250.00

ILOGIC SEMINAR - WORKSHOP

Hvornår: 2015-09-25 Hvor: Østjylland Pris: kr. Gratis