Vzdálené odemykání LUKS partitiony a bezpečnostní rizika

[Darkhunter]

Ahoj,
pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.
Otevíráme ho, pokud zákazník zapne raspberry a autorizuje se na našem serveru.
Chtěl bych odemykat tu partition vzdáleně stylem:

Kód [Vybrat] Rozbalit


echo "heslo" | ssh root@IP  "cryptsetup open /dev/mmcblk0p3 cryptopt"
ssh root@IP "mount -t ext4 /dev/mapper/cryptopt /opt"

Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.
Pak bych se chtěl zeptat, jestli takhle zadané passphrase heslo se odesílá zašifrované a jestli ho nemůže vesměs nikdo ukrást. (To by ani nemělo jít, protože všechno tohle probíhá ve VPN.)

[Reklama]

[JardaP .]

Rikate, ze mate VPN a jeste skrz to tlacite ssh a ptate se, jestli heslo jde sifrovane? To je ale blba otazka, ze jo.

Ovsem na druhe strane vam heslo vyleze ven v cleartextu a pokud vam nekdo treba misto prikazu cryptsetup podstrci skript, ktery zaloguje heslo a dale zavola ten spravy cryptsetup, tak vam heslo slohne a vy se o tom nedozvite. A pokud ma nekdo vyzicky pristup k RPi, tak nevim, co by mu v tom zabranilo, kdyz ude chtit.

[Darkhunter]

Já se ptal ohledně toho šifrování na přijímací straně...
No a dá se to nějak zabezpečit lépe? No já počítám s tím, že stát se to asi může, ale zákzaníci nejsou počítačově moc zruční...Navíc ten cryptsetup heslo se pošle jen, když je správně detekované ID desky a spousty dalších věcí. Já bych potřeboval, aby se ty příkazy vzdálené vůbec nikam nelogovaly...

[JardaP .]

Tak ja logovani prikazu pres ssh nikdy nesledoval, pokud vim, tak v logu je leda to, ze se nekdo prihlasil pres ssh nebo ze bylo blbe heslo/user a spojeni bylo odmitnuto. Nicmene co vam brani vzit jedno takove RPI, pustit si ho doma a pak si prohrabnout logy?

[Darkhunter]

No já to právě nikde nenašel a jestli žádné takové logy nejsou, tak by zjišťování, jak se ta partition odemyká a všechno kolo, mělo být o dost složitější.

[Reklama]

[Tuxik]

Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje. Heslo je šifrovaný dvakrát, jednou po VPN server VPNkou a podruhé SSHčkem až do cíle, takže o to bych se nebál. Příkaz jako takový se nikam nezaloguje, pokud se o to sám nebudeš snažit (není to tak jednoduché, ssh jako takové to neumí), největším problémem potom zůstává přístup k aplikaci a co ta aplikace umožní.

Pokud ti na tom opravdu moc záleží a stojí ti to za to, nech si udělat od někoho schopného penetrační testy - v tomto případě je zásadní to "nech si udělat", protože i kdyby jsi byl schopný si je udělat sám (což dle dotazu asi není tvůj případ), stejně budeš příliš ovlivněnej tím, co o svém řešení víš  a co si o něm myslíš.

[emil]

Ahoj,
pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.
Otevíráme ho, pokud zákazník zapne raspberry a autorizuje se na našem serveru.
Chtěl bych odemykat tu partition vzdáleně stylem:

Kód [Vybrat] Rozbalit


echo "heslo" | ssh root@IP  "cryptsetup open /dev/mmcblk0p3 cryptopt"
ssh root@IP "mount -t ext4 /dev/mapper/cryptopt /opt"

Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.
Pak bych se chtěl zeptat, jestli takhle zadané passphrase heslo se odesílá zašifrované a jestli ho nemůže vesměs nikdo ukrást. (To by ani nemělo jít, protože všechno tohle probíhá ve VPN.)

- Pokud ma zakaznik nad tim RPI plnou kontrolu celou dobu (vcetne casu odemykani LUKS), tak na to asi reseni neexistuje.

- Pokud zakaznik po autorizaci (mimo to RPI) ceka na odemceni LUKS a pak ziska pristup k RPI, je to resitelne:
  - zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem => tim zamezite podvrzeni skriptu nebo binarky
  - heslo (ale lepe odemykaci klic) se posle trubkou pres to SSH a odemce LUKS
  - system se preda zakaznikovi
  - po ukonceni uzivani zakaznikem, zkontrolujete fs na modifikace systemu (zajima vas vlastne diff distribuce pred a po)
  - zkontrolujete LUKS jestli nema nove klice
  - zavrete/zamcete LUKS

Riziko co mne napada:
  - pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)

[Mirek Prýmek]

Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje.

Přesně tak, tímhle je potřeba začít, ne dumáním nad logováním ssh.

  - zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem => tim zamezite podvrzeni skriptu nebo binarky

Nedovedu si teď úplně představit, jak to udělat dobře na nedůvěryhodném systému. Když budu dělat sha checksumy, jak zjístím, že samotná binárka sha256sum není modifikovaná? Ok, můžu si tam přes ssh nakopírovat svoji binárku, jak zjistím, že není jádro modifikováno tak, že mi pro checksum předhotí správné binárky, ale jinak použije kompromitované?

Jediný způsob, jak to udělat fakt dobře, o kterým vím, je TPM, který RasPi nemá.

  - system se preda zakaznikovi

Btw, nebylo ani řečeno, co tohle přesně znamená. Zákazník má to RasPi v ruce? Má k němu ssh přístup? Na roota nebo uživatele? Má přístup jenom přes nějakou aplikaci? Je ta aplikace nějak auditovaná?

Riziko co mne napada:
  - pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)

No já hlavně úplně nechápu, jaký smysl by mělo LUKS otevřít a dá k němu uživateli plný přístup. Tak si celý obsah zkopíruje a dál klíč nepotřebuje... ...a jsme zpátky u toho, že se musí začít sepsáním toho, co proti komu chráním a jaké má potenciální útočník v ruce prostředky.

[Lol Phirae]

Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje.

Přesně tak, tímhle je potřeba začít, ne dumáním nad logováním ssh.

+1. A není to tak dlouho, co tady někdo sáhodlouze hloubal nad stejnou pitomostí (znásilnění LUKSu jako DRM). A ne a ne a nenechal si vysvětlit, že to k tomu není určeno.

[Filip Jirsák]

  - zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem

Což ale bude kontrolovat na zařízení, které má pod kontrolou zákazník - takže samozřejmě může předstírat, že soubory modifikované nejsou, i když budou.

Chtěl bych se zeptat, zda-li se někam vzdálené příkazy logují a kam.

V normálním nastavení sshd neloguje vstup ani výstup, který přes něj prochází. sshd jen spustí shell a vstup mu předává a přebírá od něj výstup.

jestli takhle zadané passphrase heslo se odesílá zašifrované

Ano, po výměně klíčů je už celá SSH komunikace šifrovaná.

jestli ho nemůže vesměs nikdo ukrást.

Může. Vymění sshd za svůj, vymění cryptsetup za svůj, vymění celé RPi za své...

pronajímám zákazníkům rpi stroje, kde máme náš program v pythonu, který máme na luks encrypted partition.

Nebylo by lepší věnovat energii na zlepšování toho programu, než se pokoušet o nemožné? Pokud je ten váš program takový zázrak, stejně se k němu někdo dostane.

[Darkhunter]

Takže. Zákazník nemá do raspi přístup. Má ho sice u sebe, ale žádného uživatele na raspi nemá.
Na raspi poběží restapi pro mobilní appku, z které bude zákazník přistupovat.
Samozřejmě při otvírání LUKSu čekuju i IDčko základní desky a další parametry, aby nebylo možné to zkoušet odemykat z jiného raspi.
Tohle řešení mi zatím nezabralo ani hodinu a moc do toho investovat nechci. Nějaký expert se tam vždycky nějak dostane. Mně jde o to, aby se tam nedostalo 99% lidí. Většina toho našeho kódu se stejně vydá jako opensource, ale pak je tam databáze atd a to bych chtěl mít zabezpečené pořádně.

[RDa]

Jestli mate sifrovane data na hardware ktery sam o sobe bezpecny neni, tak zadna extra SW vrstva vam ochranu neprida. Staci vytahnout SD kartu z RPi, pozmenit par skryptu a maji vse co se snazite chranit. A bude to trvat rozhodne mene casu, nez do toho sami investujete.

Jestli chcete chranit data nebo sve algoritmy - dejte je k sobe na server a pristup jen pres API.

Jste milionty clovek co nechape, ze takto veci chranit nejde. A ochrana ve stylu "pokryt 99% uzivatelu" neni ochrana! Je to jenom promarneny cas a jine zdroje, ktere jste mohli investovat lepe.

[Mirek Prýmek]

Nějaký expert se tam vždycky nějak dostane.  [...] a to bych chtěl mít zabezpečené pořádně.

Není to náhodou v rozporu?!

Zákazník nemá do raspi přístup. Má ho sice u sebe, ale žádného uživatele na raspi nemá.

Čili nejen že do raspi přístup má, ale efektivně má root přístup ke všemu před rozkódováním LUKSu. Může upravit libovolnou binárku, včetně ssh a jádra. Ergo žádné dobré řešení neexistuje.

[Darkhunter]

Dobře, v tom máte pravdu, ale já to nemůžu dát k sobě na server, protože potřebuju, aby jim to fungovalo i bez internetu... :/
Tak já už nevím...Leda ten python překompilovat nějak.

[Filip Jirsák]

Tak já už nevím...Leda ten python překompilovat nějak.

A nebo se na to schovávání vykašlat. Protože je to stejně k ničemu. Opravdu si myslíte, že je ta vaše implementace takový zázrak? Že to někdo jiný nedokáže napodobit i tehdy, když zdrojáky vůbec neuvidí, a bude zkoumat jenom to, jak se aplikace chová navenek z pohledu uživatele? Pokud ta vaše aplikace bude tak úžasná, že se bude masově krást, budete mít stejně tolik platících zákazníků, že vám to bude jedno.