image

Beveiligingslek in Linux-schijfversleuteling ontdekt

dinsdag 15 november 2016, 11:01 door Redactie, 31 reacties

Er is een beveiligingslek in de schijfversleuteling van Linux-systemen ontdekt waardoor een aanvaller door het inhouden van de entertoets voor 70 seconden roottoegang kan krijgen, zo heeft de Spaanse beveiligingsonderzoeker Hector Marco aangetoond.

Het probleem is aanwezig in Cryptsetup, dat samen met Linux Unified Key Setup-on-disk-format (LUKS) wordt gebruikt voor het versleutelen van Linux-systemen. Het scriptbestand dat voor het opstartproces verantwoordelijk is en de gebruiker om zijn encryptiewachtwoord vraagt blijkt een fout in de wachtwoordcontrole te hebben. Als de gebruiker het maximale aantal toegestane inlogpogingen heeft gehad zal het opstartproces gewoon worden uitgevoerd, ook al is het juiste encryptiewachtwoord niet opgegeven.

Het echte probleem is volgens de onderzoeker de verwerking van hardwarefouten door Cryptsetup. In dit geval weet het script niet wat de oorzaak van de fout is en geeft de gebruiker een rootshell. Het inhouden van de entertoets voor 70 seconden is in dit geval voldoende. Volgens Marcro is de systeempartitie in dit geval nog steeds versleuteld en is voor zover bekend niet mogelijk te ontsleutelen. Het kan echter zijn dat andere partities niet zijn versleuteld.

Verder kan de aanvaller via de kwetsbaarheid zijn rechten op het systeem verhogen, toegang tot alle schijven krijgen en die naar een extern apparaat kopiëren om later proberen die te ontsleutelen of een denial of service te veroorzaken door alle informatie op de schijven te verwijderen. Daarnaast is het mogelijk om de kwetsbaarheid ook uit te buiten op systemen waar een aanvaller geen fysieke toegang toe heeft. Het gaat dan om cloudomgevingen. Volgens de onderzoeker is het probleem waarschijnlijk geïntroduceerd bij het toevoegen van nieuwe features. "Het is algemeen bekend dat complexiteit de grootste vijand van security is", merkt hij op.

Reacties (31)
15-11-2016, 12:07 door Anoniem
Misleidende titel: de versleuteling is niet aangetast. Het enige dat gebeurt is dat zonder geldige passphrase het startup script toch doorgaat, maar wel zonder dat de schijf is ontsleuteld.
15-11-2016, 12:20 door ph-cofi - Bijgewerkt: 15-11-2016, 12:20
This vulnerability allows to obtain a root initramfs shell on affected systems.
Lijkt me ernstig niet de bedoeling dat een gebruiker zonder rechten met de elleboog op de ENTER-key alsnog een shell aangeboden krijgt.
Zo'n programmeerfout duidt op gebrek aan reviewing, eerder dan door toevoegen van complexiteit?
Ter compensatie: de open code stelt de onderzoekers in staat de fout zelf op te zoeken, dat snel herstel ten goede kan komen.
15-11-2016, 12:34 door Anoniem
Als dit betekent dat er een rootkit kan worden geplaatst die actief wordt de volgende keer dat de legitieme gebruiker opstart en wel het juiste wachtwoord c.q. passphrase ingeeft heb je wel een probleempje toch?


My two cents...
15-11-2016, 13:13 door Anoniem
<quote>Als dit betekent dat er een rootkit kan worden geplaatst die actief wordt de volgende keer dat de legitieme gebruiker opstart en wel het juiste wachtwoord c.q. passphrase ingeeft heb je wel een probleempje toch?</quote>

Als een aanvaller fysieke toegang heeft - zoals in dit geval - dan kan die altijd al de boot-code aanpassen. De genoemde bug is niet meer dan dat, een bug. Sop en Kool.
15-11-2016, 13:49 door Anoniem
Door Anoniem: Als dit betekent dat er een rootkit kan worden geplaatst die actief wordt de volgende keer dat de legitieme gebruiker opstart en wel het juiste wachtwoord c.q. passphrase ingeeft heb je wel een probleempje toch?

Je moet dan wel een (onversleutelde) locatie vinden waar je een dergelijke kit kunt plaatsen en waar vandaan die dan ook opgestart wordt.

Peter
15-11-2016, 14:31 door Anoniem
Wat een paniek.. Wanneer je fysiek toegang hebt tot het systeem is het toch eenvoudig zat om bij de unencrypted filesystems te komen. Daar heb je geen 70 seconden enter voor nodig.
15-11-2016, 14:33 door Anoniem
Door Anoniem:
Door Anoniem: Als dit betekent dat er een rootkit kan worden geplaatst die actief wordt de volgende keer dat de legitieme gebruiker opstart en wel het juiste wachtwoord c.q. passphrase ingeeft heb je wel een probleempje toch?

Je moet dan wel een (onversleutelde) locatie vinden waar je een dergelijke kit kunt plaatsen en waar vandaan die dan ook opgestart wordt.

Peter
Dat lijkt me niet echt een issue als je een root-shell hebt.
15-11-2016, 15:03 door Anoniem
Booten met een USB stick en je hebt toegang tot alle onversleutelde systemen.

Hoeveel systemen hebben:

* BIOS passwd +
* USB disabled +
* Grub passwd +
* LUKS+Cyptsetup

Maar staan jou wel fysieke toegang toe?

Neemt niet weg dat het gewoon niet moet kunnen en dit snel gefixed moet en gaat worden.
15-11-2016, 15:34 door Anoniem
Door Anoniem: Wat een paniek.. Wanneer je fysiek toegang hebt tot het systeem is het toch eenvoudig zat om bij de unencrypted filesystems te komen. Daar heb je geen 70 seconden enter voor nodig.

Als je fysiek toegang hebt kun je ook een hardware keylogger plaatsen. Maar dat is het punt niet. Het punt is dat je bijvoorbeeld een USB Rubber ducky kunt gebruiken om deze aanval, zelfs onder camera toezicht, te kunnen uitvoeren.

Het open maken van servers gaat vallen terwijl deze aanval op een veel subtielere wijze kan plaatsvinden.


My two cents....
15-11-2016, 15:45 door [Account Verwijderd]
[Verwijderd]
15-11-2016, 16:02 door [Account Verwijderd] - Bijgewerkt: 15-11-2016, 16:03
[Verwijderd]
15-11-2016, 18:02 door Anoniem
Door ph-cofi:de open code stelt de onderzoekers in staat de fout zelf op te zoeken, dat snel herstel ten goede kan komen.
Aan de andere kant, hoe lang zit de fout er al in? En hoeveel hebben de fout al gevonden? Overheden vinden dit juist prachtig.

Door Anoniem:
Als een aanvaller fysieke toegang heeft - zoals in dit geval - dan kan die altijd al de boot-code aanpassen. De genoemde bug is niet meer dan dat, een bug. Sop en Kool.
En daarom is volgens mij juist secure boot uitgevonden?
15-11-2016, 19:17 door Anoniem
Je komt in de busybox shell en vandaar uit kan je b.v. /boot mounten en een aangepaste kernel installeren. Dus ja een ernstige zaak. Reden temeer om zoveel mogelijk te zorgen dat er geen externe devices (b.v. via USB) beschikbaar zijn.

Aan de andere kant, als je fysieke toegang heb kan je ook de HDD/SSD eruit slopen, in een ander systeem zetten en dan /boot mounten en een andere kernel installeren.
15-11-2016, 22:49 door Anoniem
Tja of gewoon init=/bin/bash instellen bij grub voordat het systeem start, scheelt 70 enters ;)
16-11-2016, 06:55 door Anoniem
Wat als je nu een kopie van je /boot op je encrypted filesysteem zou hebben en dat meteen na het mounten van je encrypted fs een compare gedaan wordt of /boot = /encrypted-boot.

Zou dat de zaak veiliger maken, immers als je iets aanpast aan /boot zal dat gedetecteerd worden.
16-11-2016, 08:09 door karma4
Door Anoniem: Booten met een USB stick en je hebt toegang tot alle onversleutelde systemen.

Hoeveel systemen hebben:

* BIOS passwd +
* USB disabled +
* Grub passwd +
* LUKS+Cyptsetup

Maar staan jou wel fysieke toegang toe?

Neemt niet weg dat het gewoon niet moet kunnen en dit snel gefixed moet en gaat worden.
Die heten desktops ofwel werkstations tegenwoordig ook smartphones . Verander de technische namen is in die van ms google apple alternatieven.... Zie de humor dat het weinig uitmaakt om welk os het gaat.
16-11-2016, 09:05 door [Account Verwijderd] - Bijgewerkt: 16-11-2016, 09:08
[Verwijderd]
16-11-2016, 09:26 door Anoniem
Door Rinjani:
Door karma4:
Door Anoniem: Booten met een USB stick en je hebt toegang tot alle onversleutelde systemen.

Hoeveel systemen hebben:

* BIOS passwd +
* USB disabled +
* Grub passwd +
* LUKS+Cyptsetup

Maar staan jou wel fysieke toegang toe?

Neemt niet weg dat het gewoon niet moet kunnen en dit snel gefixed moet en gaat worden.
Die heten desktops ofwel werkstations tegenwoordig ook smartphones . Verander de technische namen is in die van ms google apple alternatieven.... Zie de humor dat het weinig uitmaakt om welk os het gaat.

Goed... Ik dacht "nu ben ik de onzin ook meer dan zat, ik ga het gewoon uitproberen".

Even mijn Linux installatie rebooten dus. Euh... Hoe ging dat ook alweer, dat rebooten? ;-)

Na mijn BIOS wachtwoord krijg ik de prompt voor het wachtwoord voor mijn versleutelde /home partitie. Enter toets vasthouden met de stopwatch erbij voor die 70 seconden. Wat blijkt: al na een paar seconden word ik eruit gegooid want maximaal aantal retries overschreden (waarschijnlijk drie).

Het hele probleem blijkt dus niet te bestaan (op mijn openSUSE Tumbleweed Linux in ieder geval niet en die gebruikt Dracut ook nog). Ik weet niet waar dit soort onzinverhalen vandaan komt (misschien dat die beveiligingsonderzoekers net zo lang zoeken totdat ze die ene zwakke Linux distro hebben gevonden waar een probleem in zit) maar het is (alweer) een storm in een glas water!

Heb je uberhaupt wel het artikel van die onderzoeker gelezen? Gezien je reactie niet. Misschien moet je dat eens doen.
Link: http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
16-11-2016, 09:56 door Anoniem
Leuk om te zien hoe de Linux fanclub meteen de boel weet te bagatelliseren. Typisch. Het grote probleem is dat het niet eerder is opgemerkt. Het vliegertje dat er duizenden zo niet miljoenen naar de code kijken en dus alle fouten er zo uit halen, gaat wederom niet op.
16-11-2016, 10:01 door [Account Verwijderd]
[Verwijderd]
16-11-2016, 10:08 door [Account Verwijderd]
[Verwijderd]
16-11-2016, 11:30 door Anoniem
Door Rinjani:
Door Anoniem: Leuk om te zien hoe de Linux fanclub meteen de boel weet te bagatelliseren. Typisch. Het grote probleem is dat het niet eerder is opgemerkt. Het vliegertje dat er duizenden zo niet miljoenen naar de code kijken en dus alle fouten er zo uit halen, gaat wederom niet op.

Het is een non-issue.

Vandaar dat er een CVE nummer enzo aan gehangen word, omdat jij het een non-issue vind. :')
16-11-2016, 11:50 door Anoniem
Door ph-cofi:
This vulnerability allows to obtain a root initramfs shell on affected systems.
Lijkt me ernstig niet de bedoeling dat een gebruiker zonder rechten met de elleboog op de ENTER-key alsnog een shell aangeboden krijgt.
Zo'n programmeerfout duidt op gebrek aan reviewing, eerder dan door toevoegen van complexiteit?
Ter compensatie: de open code stelt de onderzoekers in staat de fout zelf op te zoeken, dat snel herstel ten goede kan komen.

Misschien kan ik zonder elleboog ook opstarten van USB disk, etc...
(BIOS beperkingen zijn makkelijk te omzeilen.)
16-11-2016, 12:23 door [Account Verwijderd]
[Verwijderd]
16-11-2016, 13:32 door Anoniem
Door Anoniem: Leuk om te zien hoe de Linux fanclub meteen de boel weet te bagatelliseren. Typisch. Het grote probleem is dat het niet eerder is opgemerkt. Het vliegertje dat er duizenden zo niet miljoenen naar de code kijken en dus alle fouten er zo uit halen, gaat wederom niet op.

Ik zou het nu niet bepaald bagatelliseren, maar een beetje plaatsen.

Het is inderdaad een belangrijk security issue dat je zo makkelijk een rootshell kan krijgen op een systeem, maar het feit dat het een vrij obscure bug is waarbij er aan zoveel randvoorwaarden voldaan moet worden om het te kunnen exploiten, lijkt mij op 2 dingen te wijzen:

1: Dat, omwille van de vele nodige randvoorwaarden, het opensouce model waarbij vele mensen naar de code kunnen kijken best wel werkt, want het is geen triviaal te vinden issue.

2: Dat, omwille van sommige van deze randvoorwaarden, het issue niet zo belangrijk is. Als het issue wel als kritisch beschouwd wordt, dan is het aanwezig zijn van dergelijke nodig randvoorwaarden op z'n minst al even kritisch.
16-11-2016, 14:51 door [Account Verwijderd]
Het is geen issue in de schijf-versleuteling.

physical access == root access, dat weten we al sinds de eerste computer.

Pure clickbait, wat een kolder sensatie verhaal.
17-11-2016, 00:04 door Anoniem
Door NedFox: Het is geen issue in de schijf-versleuteling.

physical access == root access, dat weten we al sinds de eerste computer.

Pure clickbait, wat een kolder sensatie verhaal.

physical access != root access
Voor medewerkers die hun pwd wareen vergeten, een brute-force attack gedaan.
Na twee weken (en miljoenen pogingen) nog steeds geen suc6
Verhaal gaat dus niet altijd op.
17-11-2016, 11:04 door Anoniem
Door Anoniem:
Door NedFox: Het is geen issue in de schijf-versleuteling.

physical access == root access, dat weten we al sinds de eerste computer.

Pure clickbait, wat een kolder sensatie verhaal.

physical access != root access
Voor medewerkers die hun pwd wareen vergeten, een brute-force attack gedaan.
Na twee weken (en miljoenen pogingen) nog steeds geen suc6
Verhaal gaat dus niet altijd op.

root access != data access
17-11-2016, 12:33 door [Account Verwijderd]
[Verwijderd]
17-11-2016, 15:53 door Anoniem
Reacie op hierboven: Met alleen versleuteling van de home gegevens ben je er echt niet, daar een persoon met toegang (fysiek of via priv esc etc) toegang heeft tot de programmatuur die de verleuteling regelt.
On topic, razendsnel fixen dit.
Toch, bij fysieke toegang, of evt via mistige wolkenservers toegang is de encryptiesoftware al te manipuleren als door een evil maid.
18-11-2016, 12:39 door [Account Verwijderd] - Bijgewerkt: 18-11-2016, 12:46
[Verwijderd]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.