Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 46, views: 31.781 •
Submitter: ieperlingetje

Aan de Metasploit-hackerstoolkit is een module toegevoegd die het mogelijk maakt om via een exploit in het sudo-commando toegang te krijgen tot een beheerdersaccount. De bug in sudo is onder andere aanwezig in diverse versies van OS X en in Linux-distributies.

HackerVia het sudo-commando worden privileges bepaald op de command line in een shellomgeving. Zo kan bijvoorbeeld een normale gebruiker opdrachten uitvoeren die normaliter alleen met een rootaccount mogelijk zijn.

De bug in sudo is al in maart van dit jaar bekend maar nog steeds niet gedicht op een aantal besturingssystemen. Door middel van de exploit kan de systeemklok worden teruggezet op 1 januari 1970, ook bekend als epoch. Vervolgens kan de aanvaller toegang krijgen tot het systeem zonder dat er om een wachtwoord gevraagd zal worden.

Volgens Rapid7, de ontwikkelaar van de Metasploit-hackerstoolkit, bevatten onder andere OS X vanaf Lion 10.7 tot en met Mountain Lion 10.8.4 de sudo-kwetsbaarheid. Ook diverse Linux-distributies zouden nog een kwetsbare versie van sudo aanbieden. Aan Metasploit is inmiddels een module toegevoegd die het mogelijk maakt om via een exploit toegang te krijgen tot een sessie met rootrechten, zo meldt Threatpost. Voorwaarde is wel dat de gebruiker eerder het sudo-commando heeft gebruikt en tot de admingroep behoort. Bovendien werkt de aanvalsmethode niet op afstand als het gebruikersaccount niet bekend is; fysieke toegang tot het doelwit is noodzakelijk.

Reacties (46)

Iemand enig idee waarom fysieke toegang noodzakelijk is? Zit er een verschil tussen een SSH-sessie en achter het toetsenbord zitten?
Waarschijnlijk omdat je een sessie van de user nodig hebt die op dat moment ingelogt is, gokje hoor.

EDIT
Tweakers heeft het eea niet goed overnomen zo te zien:
In addition to the previously mentioned conditions, they of course must have physical or remote access on top of admin access to the machine, making execution of the bug even less likely.
Het werkt dus ook over SSH.

[Reactie gewijzigd door sfranken op 8 september 2013 16:09]

Jep, maar je kan niet gebruiken als je zelf de sessie opzet. De aanvallende gebruiker moet dat al gedaan hebben, vandaar fysiek toegang. Zie ook:
Voorwaarde is wel dat de gebruiker eerder het sudo-commando heeft gebruikt en tot de admingroep behoort.
Hier maak ik even uit dat ze 'misbruik' maken van de standaard sudo timeout voor wachtwoord vragen. Die is 5 minuten, maar is aan te passen. Ik verwacht daarom dat op systemen waar deze default is verandert naar 0 (altijd vragen) het geen effect zal hebben.
Nee hoor, als ik een bekende username van system X heb kan ik via SSH kijken of het systeem kwetsbaar is maak ik uit het artikel van Rapid7 op
Puntje, ik heb remote-mogelijkheid verduidelijkt. Account (username) moet bekend zijn en deze moet eerder fysiek op het doelwit zijn aangemaakt.
Klopt, dit soort bugs worden vaak aangeduid met "privilege escalation": een reguliere gebruiker kan zich naar admin verheffen, maar je moet wel eerst een basisprivilege hebben.
De exploit is op zich niet een technisch hoogstandje trouwens. Op het moment dat je sudo hebt gebruikt, zal dit een minuut of 5 "geldig" blijven. Door de klok terug te zetten is die 5 minuten counter blijkbaar van de leg, met als gevolg dat die timeout niet meer voordoet. De eisen waarin dit werkt zijn (1) toegang tot een machine als user waarbij (2) deze user in de sudo'ers lijst staat, (3) sudo al sudo heeft gebruikt in die specifieke sessie en (4) de timeout-functie aanstaat ipv vragen om een password elke keer dat je sudo gebruikt. Puntje 2 is op veel machines ongebruikelijk, en 3 zal in de praktijk remote niet voorkomen, tenzij de user naast je zit, een ssh sessie is gestart en vergeet z'n scherm te locken en/of uit te loggen als hij koffie haalt.

[Reactie gewijzigd door RSpliet op 8 september 2013 16:28]

Maar heb je niet voor het aanpassen van de tijd ook al root-rechten nodig?
Ja, dat bedacht ik net ook al. Je kan de tijd niet aanpassen zonder eerst root-rechten te hebben. Dus de bug werkt wel, maar alleen als je al root-rechten hebt, wat een beetje een paradox is.

Het idee is dat je een sudo-timeout kan bevriezen, maar niks houdt je tegen om 'sudo su' te doen, of 'sudo bash' ofzo. Dus op het moment dat je deze bug kan exploiteren kan je ook al gewoon een root-shell starten.

Dit is natuurlijk een nieuwe bug die je automatisch kan exploiten, maar de voorwaarden maken het zo dat je zonder deze exploit ook al root-rechten had op het moment dat je de bug kan exploiteren, wat het een beetje moot maakt.
Je kan de tijd niet aanpassen zonder eerst root-rechten te hebben.
Nonsens natuurlijk, dit kan vanuit de desktop-omgeving. Niet de hwclock, die is afgeschremd, maar op Ubuntu kan ik zo de kernel-klok 'grafisch' veranderen (in Unity), en als ik daarna in de terminal 'date' type, zie ik netjes de veranderde tijd.

Daarom denk ik ook het verhaal over 'lokale' toegang die nodig is, en volgens mij dat 'sfranken' hierboven ernaast zit: Om via de desktop de klok aan te passen, zal je toegang tot de desktop moeten hebben, en 'remote' desktop staat meestal standaard uit.

Als ik op m'n Ubuntu-bak hier via de terminal de date probeer te veranderen, krijg ik echter het volgende:
user@host:~$ date -s 10:10
date: cannot set date: Operation not permitted
Sun Sep 8 10:10:00 CEST 2013
Hieruit conlcudeer ik dat een lokale user wel de tijd kan veranderen via de desktop maar niet via de terminal.

Met andere woorden, hoe wil je in SSH de datum gaan veranderen als je date niet mag draaien, en zonder admin-rechten?
Klopt gewoon helemaal wat je zegt. Uit het bug report dat SED hieronder linkt:
A user who has sudo access and is able to control the local clock (common in desktop environments) can run a command via sudo without authenticating as long as they have previously authenticated themselves at least once by running "sudo -k" and then setting the clock to the epoch (1970-01-01 01:00:00).
Op basis van dit nieuwsbericht lijkt het erop dat sudo de timeout altijd bewaart, ook als je een jaar geleden voor het laatst sudo hebt gebruikt. Door de klok terug te zetten naar 1970 is die timeout nog altijd geldig. Dus je moet kunnen inloggen als een gebruiker die ooit eerder sudo heeft gebruikt. Als je dat kan, ken je waarschijnlijk het wachtwoord ook al, dus in dat opzicht is het niet een heel nuttige exploit.
Maar er zwerven standaard een hele hoop configuraties rond (onder Ubuntu standaard) waarin in /etc/sudoers 'rootpw' uit staat.

Daarmee kan een 'lokale' gebruiker die in een groep hoort die sudo mag draaien commando's als root uitvoeren. Het kan ook zo ingesteld zijn dat een bepaalde gebruiker alle commando's als root uit mag voeren, sudo is zeer flexibel.

Diegene heeft dan standaard 5 minuten de tijd om 'sudo visudo' te draaien en snel zichzelf alle rechten te geven.

Overigens staat er een fout in het artkikel: De gebruiker hoeft niet per se bij de groep 'admin' te horen, ook dit is gespecificeerd in /etc/sudoers.

De volgende regel staat bijv. standaard op een Ubuntu-bak in /etc/sudores:
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
Die regel zorgt ervoor dat gebruikers uit de adin-groep met SUDO op alle genoemde bakken alle commando's als root uit mogen voeren.

Op bijv. OpenBSD maar ook Gentoo Linux is dit niet de groep 'admin', maar 'wheel'.

[Reactie gewijzigd door kidde op 8 september 2013 22:28]

Je moet bij een ingelogde shell kunnen, en dan wel eentje die nog in de sudo timeout periode zit, om de exploit te kunnen uitvoeren. Met andere woorden: je moet toegang hebben tot een root-sessie. En die kan je niet echt 'stelen' op afstand...
Als iemand fysieke toegang heeft tot je server heb je veel meer andere problemen dan dit, dan gaat een gaatje dichten in een progje ook niet veel helpen...
Het gaat niet over servers, het gaat over het veranderen van de kernel-klok via een desktop-environment.

Aangezien we het hier niet over Windows hebben, kunnen we er volgens mij toch vanuit gaan dat Linux/BSD/OS X servers beveiligd zijn voor het laten verzetten van de tijd via een desktop-environment.

Verder draaien die servers hopelijk ntpd, en afhankelijk van hoe ntpd is ingestelt, gaat die als het goed is nogal hard miauwen als de kernel-clock in een keer 43 jaar afwijkt van andere internet-klokken. Maar ja, dat laatste zou u zelf een keer moeten uitproberen natuurlijk, hangt ook van de polling-tijd van ntpd af.
Niet een heel relevante bug. Als je admin access hebt, ben je sowieso al in je hack geslaagd of ben je sowieso al een vertrouwde gebruiker.
Dat is niet helemaal waar, het sudo commando kan je per user limiteren tot slechts bepaalde zaken waarbij root nog altijd een veel grotere impact kan uitoefenen als dit met zo'n gelimiteerde account bereikt kan worden.
Ook diverse Linux-distributies zouden nog een kwetsbare versie van sudo aanbieden.
Misschien ook zo liev om even aan te geven welke distro's te zijn en wat je er tegen kan doen (waar evt. een update beschikbaar is of dat je van source moet compileren)?

Vervolgens ga ik ook maar het originele artikel lezen want dit is misschien ook niet onbelangrijk om aan het artikel toe te voegen ..
Miller previously reported that Sudo 1.8.6p7 and 1.7.10p7 fixed the bug and made it so future versions would ignore the epoch time stamp, in a Seclists post in February but this module appears to circumvent that.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775
sudo 1.6.0 through 1.7.10p6 and sudo 1.8.0 through 1.8.6p6 allows local users or physically-proximate attackers to bypass intended time restrictions and retain privileges without re-authenticating by setting the system clock and sudo user timestamp to the epoch.
Oa. Debian, Slackware, Opensuse en Ubuntu zijn of waren kwetsbaar ;)

[Reactie gewijzigd door Ventieldopje op 8 september 2013 16:35]

Het artikel wat je noemt geeft links naar de Security Advisories van die 3 distro's, waarin staat dat die distro's het probleem hebben aangepakt (al een hele tijd geleden).

Alle distro's die sudo meeleveren hebben er iets mee moeten doen, en de distro's die sinds maart geen nieuwe versie uitgebracht hebben, of gebruikers die nog niet geŁpdatet hebben zijn kwetsbaar.
Vraag me af of dit ook werkt op BSD. Daar heb je nog te doen met de wheelgroup.
Had het al gelezen op een blog voor TenFour Fox (Firefox voor oude PPC Macs). Daarin staat ook een oplossing om dit gat te dichten.

Vertaald:
Hoe op te lossen? Nou, je kan een nieuw sudo bouwen en installeren, maar hier is een beter idee: dwing sudo om altijd je wachtwoord te vragen, dat is sowieso veiliger. Typ in de Terminal sudo visudo, geef je wachtwoord, en voeg de volgende regel toe aan het configuratiebestand:: Defaults timestamp_timeout=0

Sla het bestand op en verlaat de editor. Test het met achereenvolgende sudu bash commando's. Je zou nu elke keer gevraagd moeten worden om het wachtwoord. Nu maakt het niet meer uit waar de klok op staat, je zal altijd om een wachtwoord gevraagd worden. Getest op [Mac OSX] 10.4 en 10.6; Ik zie geen reden waarom het niet zou werken op 10.5, 10.7 of 10.8. Voor gebruikers van 10.3 of ouder, als sudo -V zegt dat het versie 1.6 is of nieuwer, dan ben je ook kwetsbaar. Dit zou opgelost kunnen worden in een toekomstige 10.6 update, maar echt, dit is gewoon een veiliger manier dan om een tool te gebruiken dat gevaarlijk kan zijn als het niet goed is ingesteld.
Mogelijk werkt de methode voor Mac OSX ook voor Linux. Bij Mac OSX 10.5 werkt het in elk geval want die heb ik en ik heb die wijziging toegepast (Max OSX 10.5 Power PC versie).

[Reactie gewijzigd door pe1dnn op 8 september 2013 16:38]

En dan bij updates een dag lang je wachtwoord intikken?
Nee, bij updates kan je gewoon 'sudo apt-get upgrade' doen, en dan worden alle updates in die ene sessie gewoon geinstalleerd. Of je doet 'sudo su'. Of 'sudo bash'. Of 'gksu/kdesu [packagemanagergui]'

En als je het over Mac OS X hebt, GUI security wordt via het subsysteem (ja, nu komt het) "Security" geregeld. En dat heeft weer niks met sudo te maken, authenticatie en authorisatie gaat dan namelijk helemaal niet met sudo.
Waarom? Je hoeft om prvileges toegekend te krijgen normaal gesproken slechts 1x je wachtwoord in te tikken en vervolgens kan de software al je updates installeren.
Op RedHat bijvoorbeeld zou "sudo yum -y update" al je pakketten updaten, maar slechts eenmalig om je wachtwoord vragen.
Veiligheid of gemak, je kan ze niet beide hebben ;)
En wat is het nut om de systeemklok naar 1 januari 1970 te zetten? Als je dat doet heb je nergens meer een wachtwoord voor nodig??
Vanaf het moment dat de gebruiker voor het laatste 'sudo' uitvoerde, kan hij dit standaard 5 minuten lang zonder wachtworod doen.

Met andere woorden, als je weet dat de gebruiker voor het laaste 3 januari 2010 10:10 sudo gebruikte, kan je ook de klok op die tijd terugzetten en 5 minuten je gang gaan. Maar meestal weet je niet wanneer de gebruiker voor het laatste sudo gebruikte!

Dus, je voert 'sudo -k' uit voor die gebruiker, en zijn timestamp wordt gereset (en niet verwijderd zoals bij eerdere versies van sudo!) naar 1 januari 1970 0:00.

Dan zet je de klok terug naar die tijd, en voila: sudo denkt dat die gebruiker het laatst 1 januari 1970 0:00 sudo gebruikt heeft, sudo denkt dat het 1 januari 1970 0:00 is (een paar seconden later misschien?) en de gebruiker kan 5 minuten lang sudo zonder paswoord gebruiken.
Wat zou je er tegen kunnen doen, om dit te beveiligen? Alle rechten van de root aanpassen?.
Allemaal leuk en aardig dat een 'exploit suite' deze 6 maanden gelede gepatchte exploit heeft toegevoegd. Als je gewoon je systeem up-to-date hebt dan is er niet aan de hand. Ik gebruik Ubuntu en deze exploit is eind februari al gepatcht
Precies, ik gebruik ubuntu 13.04. Als je alles update en bijhoud is er niks aan de hand.
Ook de Long Term zal de update al wel ontvangen hebben. 13.04 is toch niet LTS?
13.04 is geen LTS idd. Ik denk dat 12.04 LTS ook wel de update zou hebben ja.
Jep, even gekeken op een productie server en inderdaad het is gepatcht
Veel servers worden vergeten en blijven draaien, dat zijn de doelwitten
Ah oke. Daar heb je wel gelijk in idd.
Afgaande op de complexe voorwaarden waaraan voldaan moet zijn om deze kwetsbaarheid uit te buiten lijkt het me niet de grote "verbetering" voor metasploit. Zelfs eerder een wanhoopspoging om Apple en Linuxsystemen aan te vallen.
Iets met storm en glas water.....


in theorie is het een groot gevaar, maar gezien wat er voor nodig is om het echt te gebruiken, zal het praktisch gezien zo goed als nooit gebruikt worden. Ik mag hopen dat mensen die achter echt kritische *nix systemen zitten zich bewust zijn van de mogelijkheid dat een fysiek iemand zoiets zou kunnen proberen in de 5 minuten dat hij wegloopt van zijn terminal en voorzorgsmaatregelen nemen.
ctr alt L. lock screen :). weg probleem.
Voorwaarde is wel dat de gebruiker eerder het sudo-commando heeft gebruikt en tot de admingroep behoort. Bovendien werkt de aanvalsmethode niet op afstand als het gebruikersaccount niet bekend is; fysieke toegang tot het doelwit is noodzakelijk.
En daarmee is dit gelijk oninteressant nieuws geworden.
Niet helemaal waar, het werkt dus wel degelijk remote... Er staat "ALS het gebruikersaccout niet bekend is DAN is fysieke toegang noodzakelijk".

Als iemand dus een bash account weet te kraken met ook maar enige toegang, dan kan de hacker vervolgens het hele systeem verkrachten via deze bug... Dat is behoorlijk gevaarlijk.
Dat het risico klein is, betekent niet dat het geen probleem is dat gepatched dient te worden... Met zo'n instelling op alle zaken zouden operating systems bizar kwetsbaar zijn.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Google Laptops Apple Games Politiek en recht Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013