Názory k článku Postřehy z bezpečnosti: pomsta ztraceného telefonu

Tým zjistil, že pomocí jednoduchého rádiového zařízení mohou vyslat jedinečný kód, který odemkne Apple Pay v telefonu. Následně potom může proběhnout platba i v případě, že je iPhone uvnitř tašky uživatele.
Podle toho, co mají na githubu, jsem to pochopil trochu jinak.
U karty ve Wallet musí být povolen express transit a musí to být Visa, souhlas.
Vlastní zneužití ale probíhá tak, že u platebního terminálu je emulátor karty, který požadavek na platbu opatří příznakem express transit.
Tento požadavek pak přes internet druhá část, emulátor terminálu, předá iPhonu (teoreticky v té tašce).
iPhone platbu zamítne a emulátor terminálu to předá zpátky emulátoru karty, který zamítnutí změní na schválení a předá skutečnému terminálu.
Chyba to je, a zřejmě hodně blbá - proč to nefunguje s MasterCard?
Je to někde mezi Apple a Visa (a proto taky se to tak dlouho řeší/neřeší).
Ale možnost moc snadná není: když uvážím, jak blízko musím dát telefon k terminálu při platbě a ty další prerekvizity... Dva komplicové, dobré načasování, oběť musí splňovat podmínky.

"Čína prohlásila transakce prováděné pomocí kryptoměn za ilegální." Tak to je vlastně dobře ne? Vzhledem k tomu jakou ekologickou stopu má těžba a hlavně jaké problémy to dělá v dostupnosti GPU. Třeba začnou Číňáci rozprodávat farmy :)

To uz robia od juna :-) A je to jedno z mala rozhodnuti ktore kvitujem.

Jako že se konečně nasytí trh vyžhavenými kartami před smrtí?

Koukám že doménu autodiscover.cz už si někdo zaregistroval, náhodou ve stejný den kdy to na bleepingcomputer psali :-)

Hlavně že se pořád řeší hashování hesel v databázi na serveru, ale odesílání hesla v otevřeném tvaru z klienta je považováno za normální. Pak to takhle dopadá.

double hashing, kedy jeden prebehne ešte na strane klienta a druhý na strane servera znie zaujímavo, ale nemalo by byť toto riešené už pomocou HTTPS/SSL, akurát iným spôsobom, ale vlastne že nejde to heslo v surovom tvare cez sieť?

4. 10. 2021, 12:16 editováno autorem komentáře

HTTPS/SSL je něco jiného, to zajišťuje šifrovaný kanál. Ale jinak ano, tohle by mělo být přímo součástí HTTP standardu – heslo by měl hashovat rovnou prohlížeč a měl by zaručovat, že s heslem se pracuje jen v bezpečné části prohlížeče a ven (do skriptů, do HTTP požadavků apod.) se dostane jedině zahashované heslo.

A čemu přesně tohle hashování v prohlížeči bude bránit? Když se útočník dostane k tomu zahashovanému heslu, tak ho prostě na ten server pošle v tom zahashovaném tvaru. Vůbec nemusí rekonstruovat předlohu v té bezpečné části prohlížeče.
Jaká situace by musela nastat, aby útočníkovi co má přístup k těm prohlížečem zahashovaným heslům byla k něčemu užitečná i ta nezahashovaná?
I kdyby prohlížeč ta hesla hashoval na požádání s dodanou solí, tak je nabořený komunikační kanál a útočník může solit podle svých chutí.

> I kdyby prohlížeč ta hesla hashoval na požádání s dodanou solí, tak je nabořený komunikační kanál a útočník může solit podle svých chutí.

Navyse v tomto pripade by musel mat server heslo ulozene v plaintexte, aby si vedel dany hash overit.

Hashování v prohlížeči nemusí být tak triviální, jak si představujete. Součástí hashe může být výzva serveru, takže pokud se útočník dostane k obsahu komunikace, bude mu to k ničemu, protože získaný hash nebude moci použít k ničemu. Představte si schéma hash(výzva serveru + tělo požadavku + hash(identifikace serveru + login + heslo)). Server má uložené jen hash(identifikace serveru + login + heslo). Údaje, které zná server, nelze použít pro přihlášení k jinému systému. Údaje, které putují po síti, lze použít nanejvýš pro zopakování stejného požadavku (pokud si server nebude pamatovat použité výzvy).

hashovanie na klientovi neriesi, nic. Docieli sa tym iba to, ze namiesto lobovolneho retazca posiela iny, vzdy s rovnakych znakov a vzdy konkretnej dlzky. Bezpecnosti to nijak nepomohlo.

Ako clovek co sa v IT uz nejaky cas pohybuje viem, ze hashovanie hesla s challnege na serveri bolo (asi aj stale je) sucastou HTTP specifikacie- nejaky derivat HTTP Basic autorizacie. No ta sa nikde neujala.

Pardon, malo to byt na klientovi - https://en.wikipedia.org/wiki/Digest_access_authentication

Je hezké, že nejprve napíšete, že to nic neřeší, a pak dáte odkaz na stařičké řešení, které uvedený problém řeší. A od té doby samozřejmě doba pokročila a máme modernější autentizační schémata, třeba SCRAM (pro HTTP definováno už od roku 2016).

V otevřeném tvaru by to bylo nebezpečné, od toho tu máme TLS.

Bylo by to bezpečné i v otevřeném tvaru. Ale to je jedno, o to tady nejde. Jde o to, že máme tisící první důkaz toho, že neplatí předpoklad „klient vždy komunikuje se správným serverem a server je vždy naprosto bezpečný a bezchybný“.

Vážně považujete posílání hesel v otevřeném tvaru po síti za bezpečné? To budete ve výrazné menšině, protože většina bude považovat možnost odposlechnutí síťového provozu za znepokojivou.

K tomu aby platil předpoklad "klient vždy komunikuje se správným serverem" existuje TLS které to při správné implementaci zajistí. Je to postup jak se použitím existujícího standardu vyhnout nutnosti komplikovat spousty protokolů na aplikační úrovni.

No a předpoklad "server je vždy naprosto bezpečný a bezchybný" je jen marný výkřik, na tom se živí spousta IT pracovníků a stejně to nemá stoprocentní řešení.

Vážně považujete posílání hesel v otevřeném tvaru po síti za bezpečné?
Myslím, že když si přečtete můj první komentář v diskusi, kde kritizuji posílání hesel v otevřeném tvaru šifrovaným kanálem, po jednoduché úvaze dojdete k tomu, že posílání hesel v otevřeném tvaru nešifrovaným kanálem nebudu hodnotit o nic lépe.

K tomu aby platil předpoklad "klient vždy komunikuje se správným serverem" existuje TLS které to při správné implementaci zajistí.
Tak si přečtěte kapitolku „Závažný bug v Microsoft Exchange Autodiscover funkci vyzrazuje uživatelská hesla“ v článku, pod kterým diskutujete. A zjistíte, že nezajistí.

Odkaz na zdroj u BloodyStealeru vyhodi 404 Error. Je ten link spravny? Pripadne jsem nasel link na strankach kaspersky : https://www.kaspersky.com/about/press-releases/2021_bloodystealer-new-advanced-stealer-targets-accounts-of-popular-online-gaming-platforms

4. 10. 2021, 21:43 editováno autorem komentáře

Microsoft Exchange Autodiscover - nezkoušel jste to někdo náhodou? Mně se to tedy s Outlookem nepodařilo, žádný dotaz přímo na autodiscover.TLD se nekonal. Podle článku na https://practical365.com/hot-air-and-publicity-for-purported-autodiscover-security-flaw/ nejsem sám a připadá mi, že v něm obsažená kritika zveřejněného nálezu je oprávněná.

Kdyby na tom nic nebylo, asi by Microsoft neskoupil desítky autodiscover.* domén.

Něco na tom asi bude, jen jsem si myslel, že to bude jednodušší nasimulovat. Zkoušel jsem Outlook 365 (16.0.14326) a Outlook 2019 (16.0.10378), bez úspěchu. Uživatel zřejmě musí zadat adresu v nějakém speciálním patvaru. Koukám, že autoři nálezu v posledních dnech doplnili do článku podrobnosti, včetně seznamu detekovaných verzí klientů (ty výše zmíněné jsem tam nenašel).

6. 10. 2021, 22:59 editováno autorem komentáře

Ono to vypadá, že to nebude problém Outlooku pro Windows, ale hlavně knihoven či softwaru třetích stran. Tj. někdo implementoval poštovního klienta, chtěl tam také implementovat funkci autodiscover, ale iniciativně prochází všechny domény z e-mailové adresy až po kořenovou doménu.