Re: [Brmlab] GnuPG best practices + tips
On 05/22/18 02:32, Pavel Ruzicka wrote: > Co mi u efail neni uplne jasne (ale mozna jen proto ze jsem nad tim > dostatecne dlouho nepremyslel) zda jde do odchoziho HTTP pozadavku > zakomponovat vysledek neceho co se behem renderovani HTML mailu spustilo > na strane klienta (ne jen obsah puvodni zpravy). Napr. v Thunderbird se > afaik Javascript pochazejici ze zpravy nespusti. Mozna pres nejaka ta > "zverstva" s CSS ktera se provedou driv nez se email klient pokusi > stahnout ten obrazek. Co som cital z toho paperu a rozlicnych PoC na twitteri apod., tak javascript neni mozne pouzit (tj. nevidel som, ze by sa to niekomu podarilo, ale tiez to 100% neviem vylucit, email klienti su strasne zloziti, si myslim, ze tam chyb moze byt viac). Co som videl, tak pouzili CSS background, /, niekde tusim na githube som videl zoznam tagov, ktore to triggeruju, ale teraz to neviem najst. Ale bolo ich celkom dost (radovo cca 50+). Ale javascript som medzi nimi nevidel. Dalsia vec, co limituje ten utok, ze prakticky ma URL nejaky limit, takze to odreze zaciatok spravy. OM ___ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
Re: [Brmlab] GnuPG best practices + tips
Velke plus za tenhle email. more of this. ad efail: vypnuti renderovani HTML je v teto souvislosti doporucovane, bohuzel mi to prijde hodne neprakticke. Zaznamenal jsem i doporuceni na kompartmentalizaci (ne jako reseni, ale zmirneni) pripadne firewall ve stylu Little/OpenSnitch, bez detailni analyzy kazdeho odchoziho pozadavku si ale myslim, ze i ja bych takovou komunikaci odklikl jako potrebnou, takze to stezi jde povazovat za reseni. Osobne teda nepodepisuju pokud k tomu neni opravdu duvod abych mohl cokoli poprit :) Ale ano, AEAD je asi spravna cesta. Prestoze je pro mne email porad nejpouzivanejsim prostredkem komunikace a organizace, doufejme ze zemre ve prospech nastroje bez techto neduhu. Web-of-trust mi porad prijde vic v pohode nez PKI :) Co mi u efail neni uplne jasne (ale mozna jen proto ze jsem nad tim dostatecne dlouho nepremyslel) zda jde do odchoziho HTTP pozadavku zakomponovat vysledek neceho co se behem renderovani HTML mailu spustilo na strane klienta (ne jen obsah puvodni zpravy). Napr. v Thunderbird se afaik Javascript pochazejici ze zpravy nespusti. Mozna pres nejaka ta "zverstva" s CSS ktera se provedou driv nez se email klient pokusi stahnout ten obrazek. ruza On 05/21/2018 11:54 PM, Ondrej Mikle wrote: > Zdar, > > k tomuto prispevku ma viedlo to, ze par clenov brmlabu pouziva GnuPG > (typicky s enigmailom) a ze ked zmenim pocitac, tak mam problem najst > verejne kluce, pokial si ich nevyexportujem z keyringu na nejakom inom > kompe. > > 1. Majte kluc najditelny, idealne vygooglitelny podla mailu a potom > podla fingerprintu > > 2. Na to sa hodi mat kluc publikovany napr. na user stranke brmlab wiki, > vlastnu VPS, alebo keybase.io. Kluc sa da publikovat na PGP keyserver > cez 'gpg --send-keys', potom to umoznuje ludom kluc importovat cez 'gpg > --recv-keys'. Mat fingerprint na separatnej stranke umoznuje mat iny > kanal, jak overit fingerprint. > > Velmi dobry napad je mat na tej stranke https, takze to nikto nemoze > jednoducho vymenit. V pripade vlastnej VPS/vlastnej domeny je dobre, ked > si clovek moze overit cez whois, komu to patri. > > Web-of-trust je failed concept, nefunguje to v praxi. > > PGP keyservers (tych asi 6 hlavnych) si medzi sebou synchronizuju kluce, > takze prakticky by malo byt jedno, z ktoreho tahate tie kluce (inak je > na to parameter --keyserver). > > Keybase.io umoznuje cloveku pouzit niekolko kanalov na publikaciu kluca > (github, twitter, vlastny web, atd.) > > V skutocnosti jeden z najtazsich problemov public key encryption je > distribuovanie tych klucov spolahlivo. > > 3. Bez tych postupov vyssie to nuti ludi random akceptovat kluce (lebo > ich nevedia "aspon +/- spolahlivo najst"), ktore niekde najdu a bolo uz > par pripadov, ze pre "vysoko profilovych ludi" (napr. developerov Tor > Project) niekto zverejnil svoje fake kluce. Dolezite je pri hladani > pouzit a/alebo skontrolovat fingerprint, pretoze to kratke 32-bitove ID > ide bruteforcovat. Sice to chvilu trva, a pre bezneho clena brmlabu by > sa na to nikto neobtazoval, ale ide to. > > 4. Ked uz sifrujete, podpisujte. Pointa je, ze ziskat public key a > zasifrovat nan dokaze kazdy. Preto vsetky dnes moderne schemy su tzv. > AEAD (=authenticated encryption) > > PGP/GnuPG je spravene tak, ze dokym sa sprava nerozsifruje prijemcom, > tak sa neda zistit, kto ju podpisal. Viz nizsie o formatovani PGP sprav. > > 5. Niektore tieto vlastnosti mozem demonstrovat na ukazani, jak su > formovane PGP spravy (RFC 4880). Napr viz v prilohe dump sifrovanej > spravy, ktora bola podpisana, ale kvoli sifrovaniu neni videt jej podpis. > > Da sa na to pouzit 'gpg --list-packets' alebo 'pgpdump -ilmp > message.asc' (pgpdump je separatna utilita, nie priamo sucastou GnuPG). > > Keby bol zaujem, mozem o tom spravit talk, jak to interne je implementovane. > > 5a. GnuPG by default nechava vidiet, na ktore kluce bola sprava > sifrovana. Da sa to vypnut cez '--hidden-recipient' (vsetky tieto veci > sa daju by default zapnut v configu ~/.gnupg/gpg.conf). Pokial ID kluca > prijemcu neni urcene, GPG vyskusa vsetky private keys. > > Na druhej strane ma tento option dost obmedzene prakticke pouzitie, > pretoze ten, kto vam sleduje emaily, vidi odosielatela a prijemcu. > > 6. Nepouzivajte outdated schemy ako DSA a El-Gamal. Minimalna dlzka RSA > kluca 2048 bit. > > 7. Co sa tyka tej poslednej zranitelnosti "E-fail" (efail.de), tak trik > spociva v tom, ze je to "decrypting oracle". Niekto vam posle vas > zasifrovany email a mail klienti nemaju dostatocne dobre filtrovanie na > remote contect - tj. napr Thunderbird a dalsie sice filtruju remote > images, ale ked pouzijete nejke zverstva s CSS, tak tam utocnik namiesa > tu spravu tak, ze tam da link napr. ako CSS backgroud > "https://attackes.picus/bullshit/; + zasifrovanu spravu a email klient > na to spravi request. Klient spravu rozsifruje a posle request, ked cast > URL je ta desifrovana sprava. > > Nevedel som zatial na 100% zistit, ci nejak staci
[Brmlab] GnuPG best practices + tips
Zdar, k tomuto prispevku ma viedlo to, ze par clenov brmlabu pouziva GnuPG (typicky s enigmailom) a ze ked zmenim pocitac, tak mam problem najst verejne kluce, pokial si ich nevyexportujem z keyringu na nejakom inom kompe. 1. Majte kluc najditelny, idealne vygooglitelny podla mailu a potom podla fingerprintu 2. Na to sa hodi mat kluc publikovany napr. na user stranke brmlab wiki, vlastnu VPS, alebo keybase.io. Kluc sa da publikovat na PGP keyserver cez 'gpg --send-keys', potom to umoznuje ludom kluc importovat cez 'gpg --recv-keys'. Mat fingerprint na separatnej stranke umoznuje mat iny kanal, jak overit fingerprint. Velmi dobry napad je mat na tej stranke https, takze to nikto nemoze jednoducho vymenit. V pripade vlastnej VPS/vlastnej domeny je dobre, ked si clovek moze overit cez whois, komu to patri. Web-of-trust je failed concept, nefunguje to v praxi. PGP keyservers (tych asi 6 hlavnych) si medzi sebou synchronizuju kluce, takze prakticky by malo byt jedno, z ktoreho tahate tie kluce (inak je na to parameter --keyserver). Keybase.io umoznuje cloveku pouzit niekolko kanalov na publikaciu kluca (github, twitter, vlastny web, atd.) V skutocnosti jeden z najtazsich problemov public key encryption je distribuovanie tych klucov spolahlivo. 3. Bez tych postupov vyssie to nuti ludi random akceptovat kluce (lebo ich nevedia "aspon +/- spolahlivo najst"), ktore niekde najdu a bolo uz par pripadov, ze pre "vysoko profilovych ludi" (napr. developerov Tor Project) niekto zverejnil svoje fake kluce. Dolezite je pri hladani pouzit a/alebo skontrolovat fingerprint, pretoze to kratke 32-bitove ID ide bruteforcovat. Sice to chvilu trva, a pre bezneho clena brmlabu by sa na to nikto neobtazoval, ale ide to. 4. Ked uz sifrujete, podpisujte. Pointa je, ze ziskat public key a zasifrovat nan dokaze kazdy. Preto vsetky dnes moderne schemy su tzv. AEAD (=authenticated encryption) PGP/GnuPG je spravene tak, ze dokym sa sprava nerozsifruje prijemcom, tak sa neda zistit, kto ju podpisal. Viz nizsie o formatovani PGP sprav. 5. Niektore tieto vlastnosti mozem demonstrovat na ukazani, jak su formovane PGP spravy (RFC 4880). Napr viz v prilohe dump sifrovanej spravy, ktora bola podpisana, ale kvoli sifrovaniu neni videt jej podpis. Da sa na to pouzit 'gpg --list-packets' alebo 'pgpdump -ilmp message.asc' (pgpdump je separatna utilita, nie priamo sucastou GnuPG). Keby bol zaujem, mozem o tom spravit talk, jak to interne je implementovane. 5a. GnuPG by default nechava vidiet, na ktore kluce bola sprava sifrovana. Da sa to vypnut cez '--hidden-recipient' (vsetky tieto veci sa daju by default zapnut v configu ~/.gnupg/gpg.conf). Pokial ID kluca prijemcu neni urcene, GPG vyskusa vsetky private keys. Na druhej strane ma tento option dost obmedzene prakticke pouzitie, pretoze ten, kto vam sleduje emaily, vidi odosielatela a prijemcu. 6. Nepouzivajte outdated schemy ako DSA a El-Gamal. Minimalna dlzka RSA kluca 2048 bit. 7. Co sa tyka tej poslednej zranitelnosti "E-fail" (efail.de), tak trik spociva v tom, ze je to "decrypting oracle". Niekto vam posle vas zasifrovany email a mail klienti nemaju dostatocne dobre filtrovanie na remote contect - tj. napr Thunderbird a dalsie sice filtruju remote images, ale ked pouzijete nejke zverstva s CSS, tak tam utocnik namiesa tu spravu tak, ze tam da link napr. ako CSS backgroud "https://attackes.picus/bullshit/; + zasifrovanu spravu a email klient na to spravi request. Klient spravu rozsifruje a posle request, ked cast URL je ta desifrovana sprava. Nevedel som zatial na 100% zistit, ci nejak staci vypnut renderovanie html mailov, zatial sa to riesi. Problem je v tom, ze ti ludia nezverejnuju PoC, takze sa blbo testuje, co vlastne problem je a co ne. 7a. Na ten "decrypting oracle vulnerability" zda sa je potreba aspon v niektorych pripadoch, aby sprava mala chybu v overovani integrity (sa to vola MDC), ktory je ale zapnuty be default, takze triggernutie tej chyby neni zas tak jednoduche. OM OM Old: Public-Key Encrypted Session Key Packet(tag 1)(526 bytes) New version(3) Key ID - 0x Pub alg - ElGamal Encrypt-Only(pub 16) ElGamal g^k mod p(2047 bits) - 5a 17 72 63 fd a0 6e 5b 75 77 02 f8 7e e7 6d 8c 83 b9 41 6f 2c 55 05 2c b5 a7 93 4b 09 39 ff 6f 4b 62 b7 c6 30 d7 32 0b 02 fb 88 3b 9a 50 b2 f7 8f f2 b0 a3 02 f5 f5 ad 28 1e 59 b4 a5 10 5b bc 09 fc d1 f3 8b f3 49 33 9d 50 30 30 f8 d2 13 d0 53 c9 34 5f b4 c8 a2 47 0a c7 fb b4 37 19 d6 f3 9a 49 f2 de 29 4b 59 54 29 12 ec 66 56 ea d0 34 ff 57 40 01 e1 62 6f 1a 45 3e 3f 39 c7 45 0c 50 b5 b9 55 fb c0 30 0e c4 a7 ca 4a ad d5 13 ed a1 af 9d fa 93 bf cd 14 08 c1 e9 5a 3b ce 91 cf 6a a7 c6 a0 e5 de df b6 10 67 95 aa 57 41 c3 fc ad 0e d5 46 cc 38 70 50 5d 7a 59 6d 24 0c 73 38 c9 87 46 28 bb 4b a8 81 74 ab fd 2a ce d8 e0 5e 61 e1 2f 7b 45 66 73 01 04 56 c4 5e 2b 3d 8a be 99 61 60 04 9a f1 a5 a2 65 a7 e4 6c ed 05 26 21 5c a5 65 69 a5 e4 3c d3 52 52 06 32 5e 6e 61 a0 ff ElGamal m
