Press Shift+F10 to bypass Bitlocker

Security researcher Sami Laiho discovered this simple method of bypassing BitLocker, wherein an attacker can open a command-line interface with System privileges just by holding SHIFT+F10 while a Windows 10 PC is installing a new OS build.

http://blog.win-fu.com/2016/11/every-windows-10-in-place-upgrade-is.html
http://thehackernews.com/2016/11/windows-bitlocker-bypass.html

Hozzászólások

Ezen a hibán most jót röhögtem :D

Pár hete itt népek a Grub2 hasonló szintű "törését" is kimagyarázták, hogy nincs azzal semmi baj, szerintem akkor itt is ugorhatunk. (Nem.)
Ehhez ráadásul meg kell várni egy OS frissítést, amiből következik, hogy a probléma elhárítható azzal, hogy kikapcsoljuk az automatikus frissítést. (Bár azt meg mintha mostanában nem lehetne. FIXME)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Eg es fold. A grubos dolognal nem fersz hozza a jelszo nelkul a diszk tartalmahoz, itt meg igen.

Egyebkent nemreg vetette fel egy hupos kollega, hogy hogy a picsaba indult ujra a gepe, ha be volt allitva bitlocker. Kiderult, hogy az upgrade idejere "kikapcsolja" a titkositast. Akkor ment a nyafi, hogy hat mit erdekel teged az, hogy a kulcsod(bol kepzett valami) elmentesre kerul a tudtod nelkul, jo az ugy. Hat latjuk milyen jo...

Jol ertem, hogy az a "hiba", hogy frissites kozben nincs titkositva a rendszer?

Nem az volt valamelyik másik fórumtéma, hogy Win10 bekapcsolja a gépet, hogy frissítsen, és ezt nem lehet letiltani, és irgum-burgum, mert a hátizsákbab megfő a laptop, meg miegymás.

Ilyen esetekben a titkosítás nem tudom, hogy játszik. Nem is indul el a gép? (akkor a másik fórumot ha valaki megkeresné, be lehetne írni, hogy itt a megoldás). Vagy bekapcsol, de nem tud bebootolni, mert titkosított a lemez? Vagy bekapcsol, a titkosítást a frissítés az eltárolt jelszóval simán kikapcsolja, és megy minden simán?

Pár hónapja nekem is volt ilyen: Win10 telepítés után ejszaka egyszer csak elkezdett zúgni a gép, egyből rányomtam a sleep gombra, de pár percen belül megint feléledt, ekkor már inkább ráhagytam. Ezután inkább kikapcsoltam a windows update-et és inkább havonta 1x kézzel rányomok.

(A gép 1000 éves Core2duo, sima desktop alaplappal.)

Ezeket kell kikapcsolni:
http://www.howtogeek.com/wp-content/uploads/2016/10/wpw_17.png
http://www.howtogeek.com/wp-content/uploads/2016/11/wpw_y.png

Ha fizikailag hozzáférhet egy támadó a géphez, akkor már eleve megette a biztonságot a fene. Linux esetén sem véd ez ellen a LUKS lemez titkosítás. Mivel a /boot titkosítatlan, elhelyezhet rá a támadó egy módosított (például keyloggeres) kernel image-et, és onnantól a későbbi bootolások során kompromittálható a rendszer.

Celzott tamadas ellen ugyse ved, sima lopas/rablas ellen meg igy is joval tobb mint a semmi. (igyekeznek minel hamarabb megszabadulni az "arutol").

Persze, ez egy problema amit javitani illene, de azert nem kell tobbet belelatni mint ami.
--

"You can hide a semi truck in 300 lines of code"

Az sem jelent teljes védelmet. A támadó célja mindig az, hogy a kititkosítás előtt tudjon lefutni valamilyen saját kódja. Ha ez a háttértárolón (merevlemez, SSD, stb.) van, akkor be kell tudnia ékelődni a kititkosító kód lefutása elé (például az MBR-be, de ezt a SecureBoot erősen megnehezíti). Így lényegtelenné válik, hogy a /boot titkosított-e, vagy sem.

Nem állítottam, hogy létezne teljes védelem, csupán a fenti, pontatlan állításod cáfoltam abban a formában, ahogy ott áll. (Egyébként szerintem kielégítően biztonságos pl. a Gentoo által támogatott mód: a teljes lemez titkosított, a bootloader egy, a POST után kézzel begépelendő passphrase-zel fér csak hozzá a /boot-hoz, az így betöltött initrd pedig egy - csak ekkor elérhető - külső eszközről olvassa be a kulcsot, amivel kinyitja a rootfs-t.)
------------------------
{0} ok boto
boto ?

Ha ellopják a (kikapcsolt) laptopom, fel tudják oldani a bitlockert? Nem, ugye? Akkor nincs itt semmi látnivaló, kérem oszoljanak. (Persze lehet, hogy az NSA megoldja így is...)

Na jó, az tényleg gáz, hogy szó nélkül kikapcsolgatja a bitlockert, de remélhetőleg rájönnek, hogy ez faszság, és megoldják, hogy ne történjen ilyen többé.

--

Sajnos nem ilyen egyszerű: ez egy klasszikus használhatóság <--> biztonság dilemma és annak is elég kellemetlen.

Ha ellopják a kikapcsolt laptopod, elég a logon képernyőn egy wifire csatlakozni és várni, amíg az OS upgrade-eli magát. Ez a mostani kiadási tempó mellett kb. 9 havonta megtörténik, normál frissítésként. Ha eközben valami távmenedzsmenttel nem tudod legyalulni a laptopot, az adataidhoz hozzá fognak férni e módon... (és nem kell hozzá 5 dolláros csavarkulcs.)

Viszont ha az OS frissítés nem oldja fel a Bitlockert, hanem felhasználói beavatkozáshoz köti és figyelmeztet, hogy ne hagyd magára a géped, amíg az OS települ, akkor lőttek az automatikusan éjjel, érdemi munkából való kiesés nélkül upgrade-elő OS-nek.

Üdv,
Marci

Kikapcsolt, bitlockerrel védett laptopról hogy jutnak el logon képernyőig? A használhatóságot nem értem, ha én bitlockert állítok be, az a normál, hogy minden induláskor kulcsot írok be.

Lockolt állapotban mondjuk ez tényleg gond, ideális esetben lockolt képernyő mögött el kellene dobni a memóriából a titkosított kulcsokat és semminek nem kéne futnia. (Vagy a rendszer partíción éppen mehet bármi, csak a felhasználói adatokat kell lezárni.)

--

"Kikapcsolt, bitlockerrel védett laptopról hogy jutnak el logon képernyőig? A használhatóságot nem értem, ha én bitlockert állítok be, az a normál, hogy minden induláskor kulcsot írok be."

Úgy, hogy ha UEFI környezetben, Secure Boot-tal védve és TPM kulcstárolással dolgozol, a Windows - ha a firmware-t és az OS-t megbízhatónak detektálja, (és ezt az opciót konfigurálod) el fog indulni és eljut a logon screen-ig, feloldva a Bitlockert. Ha aztán a jelszót nem tudod jól megadni, lezár a Bitlocker.
Szóval, nem kell minden induláshoz kulcsot beírni, mégis működik.

https://technet.microsoft.com/en-us/library/dn632176(v=ws.11).aspx

Üdv,
Marci