ale tohle je přece už pár let starý problém, který je známý, myslím, že se řešil i tady na rootu už několikrát. Úprava konfiguračního souboru a vypnutí ExportNoKey vede k možnosti získat hesla, je ale potřeba přístup k samotném počítači a účtu, pod kterým keepass běží. Stejná zranitelnost je přece i s třeba ssh-agentem či cokoliv, co je uložené lokálně.
Stejně tak lze získat i hesla z 1password nebo jiných, pokud jsou v paměti cachovaná (tj. nezadávám heslo při každém vyplnění hesla do formuláře), lokální proces si je s určitou snahou může získat.
Trochu mi to připadá, že si někdo nahání body hlášením CVE.
3. 2. 2023, 12:49 editováno autorem komentáře
Hesla vyhradne lokalne. Nikto nepotrebuje vediet moje heslo, privatny ssh kluc etc. Ak ma nahodou zrazi autobus, tak su efektivnejsie a cistejsie cesty ako moj ucet deaktivovat a pridelit prava niekomu inemu. Ak ich predsa len z nejakeho fakt inak neriesitelneho dovodu treba synchronizovat tak existuju bezpecnejsie cesty ako nazdielat db s heslami na sambu...
dw: No a jaký je rozdíl v tom, zda jsou ta hesla uložená lokálně nebo vzdáleně, vzhledem k tomu, že za ně zodpovídáte a chcete mít kontrolu nad tím, jak se s nimi zachází? Mne napadá jediný rozdíl – na lokálním počítači máte lokálního uživatele a spouštíte pod ním veškeré programy, takže je to mnohem nebezpečnější, než na vzdáleném serveru, ke kterému přistupujete jenom pomocí síťového protokolu.
Doufám, že víte o tom, že hesla na vzdáleném serveru mohou být uložena šifrovaně a mohou se šifrovat a dešifrovat lokálně u vás, takže server se nikdy to samotné heslo nedozví. A dělá to tak každý aspoň trochu příčetný správce hesel.
Z mojich skusenosti je to vo firmach a korporatoch riesene vsade inak. Zalezi akych maju shopnych adminov a security team.
To ze su api, ku ktorym je len jedno heslo a ani to nejde zmenit si uvedomujem, tam patri proxy, teda ak nechcem zbytocne premyslat o tom kolko byvalich zamestnancov a ich znamich to heslo ma.
A k tomu ci by zamestnavatel mal vediet heslo ktorym potvrdzujem moju identitu: ziadny zamestnavatel ho nema pravo vediet, moze maximalne nastavit pre hesla politiku ako maju vyzerat.
Je to důležité, jestli jde o textový soubor? Protože když změníte binárku, k heslům, která zadají přihlašující se uživatelé, se dostanete.
Když můžete přepsat konfigurační soubor KeePassu, pravděpodobně budete moci přepsat i takové soubory, které způsobí, že si uživatel místo „opraveného“ KeePassu spustí KeePass, který tu současnou „zranitelnost“ stále má.
Je to taková zranitelnost když máte na dveřích vedle bezpečnostního zámku i obyčejnou FABku, nenechávejte ten klíč k FABce v zámku, ale aspoň ho schovejte pod rohožku. (Následovat bude obvyklý argument „třeba toho zloděje, který si poradí s bezpečnostním zámkem, nenapadne podívat se pod rohožku ale klíče v zámku by si všiml“.)
> Je to důležité, jestli jde o textový soubor? Protože když změníte binárku, k heslům, která zadají přihlašující se uživatelé, se dostanete.
Stačí i textový soubor, například v /etc/pam.d si můžete pověsit vlastní handler (shellový skript), který heslo dostane a může zalogovat.
Taky by mě zajímal ten způsob útoku. Musel bych mít velmi specificky soubory KeePass na síťovém disku, ale ne ostatní věci, protože jinak by mi mohli mnohem jednodušeji přidat libovolný kód do .bashrc, libovolné rozšíření do .mozilla atd.
aké heslá linuxu? Lokálne heslá pre prihlásenie do toho linuxu? Na to presa stačia hashe, ale na prihlásenie do systémov tretej strany je potrebné mať uložené heslá tak, aby sa dali získať ako text. Ak má niekto prístup k disku, môže si tam hodiť napr. keylogger a odchytiť si aj heslo k zašifrovaným súborom
> z tohoto důvodu právě keepass korporátně neopužíváme a je zakázaný
Z jakého důvodu? Věděli jste o chybě ze zprávičky předem?
> používají se jen síťové/webové uložiště
IMHO ten útok na tohle právě spočívá v tom, že máte profil KeePassu na síťovém úložišti, a to ho zákeřně pozmění - ale když máte přímo webového správce hesel, tak je situace v tomto případě ještě horší, ne?
keepass dovoluje exportovat všechna hesla v cleartextu jakémukoliv oprávněnému uživateli, nedá se tam auditovat, kdo kdy přistupoval k heslů a v případě útoků chybí indície dopředu při získáváních hesel, útočník může díky tomu získat poměrně značnou část přístupů do infrastruktury. Nebavím se vůbec o osobních heslech, ale o správě pro velké organizace.
Ano, tuhle vlastnost znám/známe dlouho, vždyť je to dokumentovaná funkce, vůbec to jako zranitelnost nepovažuji. Stejný problém logicky má třeba pass, gpg nebo i lastpass/1password (bylo u nich možné upravit lokální aplikaci a nechat jí hesla někam uložit, v prohlížeči se sice konzistence pluginu ověřuje, ale pokud někdo používal desktop aplikaci, tam se konzistence neověřovala, informace stará 2 roky, dnes nevím).
Dnes je v kurzu hesla co nejméně zobrazovat uživatelům, nedovolit jejich hromadný export, vytvářet krátká dočasná hesla pro přístupy. Jako webové myslím třeba v podobně cyberku, síťové třeba v podobě luna hsm.
Měl jsem více rozvést kontext, v kterém to myslím.
S většinou těch výhrad ke KeePassu se dá souhlasit. Ale připadá vám jako dobrý nápad používat jako klienta pro password manager aplikaci, která má za rok 2022 celkem 303 bezpečnostních zranitelností? Ano, mluvím o Chromu. K tomu je dobré započíst zranitelnosti webových serverů a vlastních serverových aplikací. Například v roce 2022 dopadl celkem špatně LastPass, když měl dva závažné bezpečnostní incidenty během třech měsíců. Je webový password manager vůbec lepší nápad, než post-it lísteček na monitoru?
Nezáleží na počtu zranitelností, ale i na jejich charakteru. Navíc spousta těch hesel (dnes to bude většina i u spousty IT správců) se stejně používá v prohlížeči, takže prohlížeč se to heslo tak jako tak dozví.
V dnešní době se bráníme v drtivé většině případů proti remote útokům, takže z tohoto pohledu je lísteček na monitoru hodně bezpečné řešení. Má to dvě nevýhody – tolik lístečků, kolik máte hesel, by se vám na monitor nejspíš nevešlo, navíc jejich hledání a hlavně opisování hesel by bylo dost nepohodlné. A pak to má ještě jednu reálnější nevýhodu – správce hesel má chránit před lidskou chybou, že heslo zadáte někam, kam nemáte. Tedy proti phishingu. Tedy je potřeba, aby správce hesel identifikoval, kam chcete heslo vložit, našel správný záznam a heslo sám vložil. U webů to funguje dobře, pokud máte doplněk v prohlížeči, protože weby jsou jednoznačně identifikované svou doménou. Při zadávání do aplikací už to takhle nefunguje, správce hesel obvykle neumí zkontrolovat, o jakou aplikaci se jedná, a vložit do ní správné přihlašovací údaje.
Na prvním místě ty post-it notes. Ty znamenají, že přístup k heslům má doslova každý, kdo jde kolem počítače. Uklízečky, ostraha objektu, údržba, kolegové, kontraktoři... Navíc spousta meetingů dnes bývá online, a tam hrozí riziko, že se díky kameře k heslům dostane i kdokoliv, kdo je na online meetingu.
Teď k těm password managerům používaným z browseru. Jako sorry, ale kdyby měl lokální password manager stovky bezpečnostních děr ročně, tak by vás asi ani ve snu nenapadlo mu svěřit hesla. U webového password manageru ale z nějakého důvodu nevidíte problém. Podotýkám, že jde o scénář, kdy se browser a/nebo serverová aplikace může dostat ke všem heslům, ke kterým máme přístup. Za mě je to velmi rizikové.
Pokud jde o zadání správného hesla na správné místo, tak k tomu není nutný doplněk browseru. A věřit s hesly bezpečnosti browseru a/nebo doplňků je podle mě jako pracovat na cirkulárce se zavřenýma očima.
Ty lístečky na monitoru samozřejmě nebyl návod, že to tak má někdo dělat. Jenom připomenutí, že reálné nebezpečí je dnes někde úplně jinde.
K bezpečnostním dírám v prohlížeči už jsem vám vysvětloval, že nejde o jejich počet, ale o to, co ta která bezpečnostní chyba znamená. Když v bance dojde k bezpečnostní incidentu, že se zahradník škrábne o trn rostliny, také kvůli tomu nebudete hned vybírat peníze z účtu.
Stejně tak jsem psal, že když používáte webové aplikace, stejně se prohlížeč to heslo dozví, takže mu stejně musíte důvěřovat.
Pokud zadání hesla na správné místo necháte na kontrole člověka, můžete na něm nechat i to, aby si heslo zapamatoval, a nepotřebujete žádného správce hesel. Akorát hodně štěstí při hledání takového supermana.
No pokud má někdo konfigurační soubor aplikace na sdíleném disku, tak si nic jiného nezaslouží.
Pokud ho má na lokálním počítači, tak je to už úplně jedno - pokud to tam dokáže útočník modifikovat, pak tam může nahrávat i vlastní spustitelné soubory a podobně, takže víceméně až na nějakou komplikaci s lokálními právy na té stanici se dostane i k tomu obsahu RAM...
Jednak je princip chyby snad zřejmý z textu zprávičky. Jednak to, co píšete, není tak docela pravda. Pokud útočník může přepisovat soubory uživatele, s vysokou pravděpodobností dokáže uživateli podstrčit i svůj vlastní upravený KeePassXC, do kterého může tuto funkcionalitu implementovat. Zkrátka když na Linuxu všechny aplikace běží pod právy uživatele, je v případě kompromitace uživatelského účtu napadnutelná prakticky každá aplikace.