https://www.michalspacek.cz/exporty/clanky/newsletterMichal Špaček: Články se značkou „newsletter“2017-08-21T10:00:00+02:00Michal Špačekhttps://www.michalspacek.cz/ctvrte-cislo-newsletteru-2017-21-33-tyden2017-08-21T10:00:00+02:002017-08-21T10:00:00+02:00<p>Čtvrté (a poslední) číslo newsletteru převážně o bezpečnosti,
bezpečném vývoji převážně webových aplikací a bezpečnosti převážně
uživatelů je konečně tu.</p>Čtvrté číslo newsletteru (2017, 22.-33. týden)<h2 id="tls-ssl-https">TLS, SSL, HTTPS</h2>
<p id="symantec-terminy">Skoro již tradičně začneme certifikační autoritou
<strong>Symantec</strong>. Ta se v posledních letech potýká s <a
href="https://wiki.mozilla.org/CA:Symantec_Issues">mnoha problémy</a>, mj.
vystavila několik desítek tisíc falešných certifikátů, kvůli kterým jí
výrobci prohlížečů přestávají důvěřovat. Předběžně se proto
dohodla s Googlem, že od 8. srpna budou certifikáty vydávat nezávislé
certifikační autority. V <a
href="https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal">reakci
na tuto předběžnou</a> dohodu Symantec tvrdil, že po diskuzích
s potenciálními partnery nelze termín stihnout, partneři Symantecu by prý
neměli dostatek času na posílení infrastruktury, která by tak nemusela
zvládnout nápor nových žadatelů. Symantec je podle měření firmy Netcraft
největším vydavatelem OV (Organization Validation) a EV (Extended Validation)
certifikátů a ověření žadatelů o tyto certifikáty nelze vždy
automatizovat jako v případě běžnějších DV (Domain Validation)
certifikátů, které vystavuje například autorita Let's Encrypt.
<strong>Finální situace</strong> je tedy taková, že aktivity certifikační
autority Symantec <strong><a
href="https://www.digicert.com/news/digicert-to-acquire-symantec-website-security-business/">převezme</a>
od 1. prosince 2017 autorita DigiCert</strong>. <strong>Existujících
certifikátů vydaných před 1. červnem 2016 se <a
href="https://www.thesslstore.com/blog/symantec-certificates-august-8/">změny
dotknou až od dubna 2018</a></strong> ve stabilní verzi Chrome, v Canary od
ledna 2018, do té doby bude Chrome certifikátům důvěřovat. Certifikátů
<strong>vydaných po 1. červnu 2016 se změny dotknou až v říjnu
2018</strong>. Mozilla ve svém prohlížeči Firefox <a
href="https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Oaeqtddo_Cw/lN-Pp6h1AAAJ">udělá
změny v podobný čas</a>, plusmínus pár týdnů podle plánu vydání
nových verzí. Je dobré připomenout, že Symantec má i další značky
certifikátů (GeoTrust, Thawte, RapidSSL) a týká se to všech</p>
<p id="firefox-ocsp"><strong>Testovací verze Firefoxu</strong> označovaná
jako <em>Nightly</em> má <strong><a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1366100">pokusně
vypnutou</a> kontrolu</strong> platnosti „základních“ DV (Domain
Validated) certifikátů pomocí protokolu <strong>OCSP</strong> (Online
Certificate Status Protocol). Prohlížeč může po obdržení certifikátu
poslat dotaz na <abbr title="Online Certificate Status Protocol">OCSP</abbr>
servery aby zjistil, jestli certifikát nebyl <em>revokován</em> (zrušen). To
může zdržovat načtení stránky, podle Mozilly skoro 9 % úspěšných
<abbr title="Online Certificate Status Protocol">OCSP</abbr> trvá déle než
1 vteřinu. Například <a
href="https://www.michalspacek.cz/druhe-cislo-newsletteru-2017-20-tyden#vypadek-letsencrypt">výpadek
<abbr title="Online Certificate Status Protocol">OCSP</abbr> serverů
certifikační autority Let's Encrypt</a> minulý měsíc způsobil problémy
některým návštěvníkům stránek, které certifikáty od Let's Encrypt
používají, a tato změna ve Firefoxu by tomu měla předejít. Pokud se po
změně načítání výrazně zrychlí, tak bude kontrola vypnutá ve všech
verzích Firefoxu. Chrome takové <em>online</em> kontroly neprovádí již
několik let. Místo posílání požadavků by se měla používat technika
zvaná <em>OCSP Stapling</em>. Ta spočívá v připojení <abbr
title="Online Certificate Status Protocol">OCSP</abbr> odpovědi rovnou
k počátečnímu navázání šifrovaného spojení mezi serverem a
prohlížečem, jenže implementace <em>OCSP Staplingu</em> v serverech Apache
i nginx je <a
href="https://www.michalspacek.cz/druhe-cislo-newsletteru-2017-20-tyden#ocsp-stapling">bohužel
chybná</a>.</p>
<p id="wikipedia-cenzura">HTTPS <a
href="https://www.michalspacek.cz/potrebujete-mit-web-na-https">je dobro</a>.
A taky chrání před cenzurou. <strong>Po přechodu Wikipedie na
HTTPS</strong> v červnu 2015 se <a
href="https://motherboard.vice.com/en_us/article/wikipedias-switch-to-https-has-successfully-fought-government-censorship"><strong>snížil
počet cenzurování</strong></a> této „otevřené“ encyklopedie.
Nepřející vlády sice pořád mohou cenzurovat celou Wikipedii, zkoumání
provozu odhalí doménu nebo IP adresu, na kterou se uživatel připojuje, ale
takové zablokování se většinou setká s velkou nevolí a je to
„vidět“. Jednotlivé stránky zablokovat nejdou.</p>
<p id="wosign-startcom">Certifikační autority <strong>WoSign a
StartCom</strong> mají, podobně jako Symantec, za sebou také <a
href="https://wiki.mozilla.org/CA:WoSign_Issues">pěknou řádku problémů</a>.
Autorita WoSign vydávala certifikáty s do minulosti posunutým začátkem
platnosti, certifikáty s duplicitními sériovými čísly a také
nezveřejnila nákup certifikační autority StartCom. <strong>Chrome
61</strong> (aktuální je verze 60) <strong>těmto certifikačním autoritám
<a
href="https://groups.google.com/a/chromium.org/d/msg/net-dev/FKXe-76GO8Y/Ka8K5lj9AgAJ">přestane
úplně důvěřovat</a></strong> a žádné jimi vydané certifikáty nebudou
platné. StartCom je známá svými certifikáty zdarma, které pro nekomerční
účely poskytovala ještě před vznikem certifikační autority
Let's Encrypt. Společnost StartCom v červenci <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1311832#c12">vydala
zprávu</a>, že prošla auditem, změnila majitele (nyní je vlastníkem
StartComu čínská firma Qihoo 360, která v roce 2016 koupila prohlížeč
Opera), a že znovu Mozillu požádala o přidání na seznam důvěryhodných
certifikačních autorit.</p>
<p id="caddy-detekce-mitm">Nedávný výzkum <a
href="https://www.michalspacek.cz/prvni-cislo-newsletteru-2017-19-tyden#inspekce-https"><strong>inspekce
HTTPS</strong></a>, tedy sledování zašifrovaného provozu, ukázal, že
webový server může „inspekci provozu“ detekovat podle charakteristiky
HTTPS spojení, která je pro každý prohlížeč a skenovací software jiná.
Webový server <strong>Caddy</strong> <a
href="https://caddyserver.com/docs/mitm-detection"><strong>detekci inspekce
implementoval</strong></a>, takže provozovatel webu si může logovat, kolik
návštěvníků je inspekcí <em>postiženo</em>, případně může rovnou
uživateli ukázat, že jeho načítání stránek není tak bezpečné, jak na
první pohled vypadá.</p>
<h2 id="prohlizece">Prohlížeče</h2>
<p id="chrome-certifikat">V aktuální verzi Chrome 60 je zpátky
<strong>zkratka pro zobrazení informací o certifikátu</strong>. Stačí
kliknout na ikonku zámečku v řádku s adresou a hned se dozvíte, jestli je
certifikát validní, nebo ne. Když nad „odkazem“ <em>Valid</em> chvilku
necháte myš, tak se zobrazí i informace o autoritě, která certifikát
vystavila. Zkratku je potřeba nejdříve zapnout, to provedete na speciální
adrese <code>chrome://flags/#show-cert-link</code>, po novém spuštění
prohlížeče už ji budete moci využít. V budoucnu by zkratka měla být
standardně zapnutá, vývojáři Chrome prý čekají na nějaké úpravy
panelu, který se po kliknutí na zámek objeví. Informace o certifikátu
naleznete také v Developer Tools (ty zobrazíte např. stiskem F12),
v záložce Security je na to tlačítko.</p>
<p id="chrome-reklamy"><strong>Chrome</strong> začne počátkem příštího
roku <a
href="https://blog.chromium.org/2017/06/improving-advertising-on-web.html"><strong>blokovat
<em>nepřijatelné</em> reklamy</strong></a>. To jsou ty, které nebudou
splňovat <a href="https://www.betterads.org/standards/">standard <em>Better
Ads</em></a>, tedy např. reklamy, které začnou automaticky přehrávat
nějaký zvuk nebo reklamy v pop-up oknech. Celkem bude blokovat 4 typy
nepřijatelných reklam pro desktop a 8 typů pro mobilní zařízení. Už jen
dodám, že Google je zakládajícím <a
href="https://www.betterads.org/members/">členem koalice</a>, která standard
definovala a dalšími členy jsou mj. Facebook, Interactive Advertising Bureau
(IAB) a GroupM.</p>
<h2 id="uniky-dat">Úniky dat</h2>
<p id="zomato-stejne-heslo">Firma <strong>Zomato</strong> (působí
i v Čechách) nedávno <a
href="https://www.michalspacek.cz/druhe-cislo-newsletteru-2017-20-tyden#unik-zomato">oznámila</a>,
že si někdo odnesl <strong>17 milionů uživatelských účtů</strong>, teď
už <a
href="http://blog.zomato.com/post/160986258541/security-update-what-really-happened-and-what">víme,
jak k tomu došlo</a>. V roce 2015 byla zveřejněna data z úniku ze
služby 000Webhost, na které měl účet i vývojář Zomata. Ze služby
unikla i hesla v čitelné podobě a ten vývojář <strong>používal to
samé heslo i na GitHubu</strong>. Někdo tak získal přístup ke zdrojovým
kódům Zomata, našel v nich chybu, kterou zneužil pro získání přístupu
do databáze. Firmy by se o své vývojáře (a tím i o svoji budoucnost)
měly starat trochu víc, třeba by jim mohly <a
href="https://www.michalspacek.cz/spravce-hesel-jako-firemni-benefit">pořídit
správce hesel</a>.</p>
<p id="onelogin-unik">Správci hesel mají určitá rizika, ale ta jsou pořád
menší, než když někdo používá jedno heslo na více místech. Často jsou
terčem útoků, ale při dobrém návrhu to zas tak moc nevadí. Ze správce
hesel <strong>OneLogin</strong> <a
href="https://www.onelogin.com/blog/may-31-2017-security-incident"><strong>unikla
data</strong> na konci května</a> a útočník prý <strong>data může
i dešifrovat</strong>, dostal se tedy i k šifrovacím klíčům,
<em>eh</em>, což o moc dobrém návrhu nesvědčí. OneLogin možná budete
znát, před rokem <a
href="http://blog.portadi.com/onelogin-acquired-portadi/">spolknul českou firmu
Portadi</a>. Dat zákazníků Portadi se to <a
href="https://twitter.com/soukup_tom/status/872824122744623105">prý
netýká</a>.</p>
<h2 id="sbohem-a-satecek">Sbohem a šáteček</h2>
<p id="posledni"><em>Děje se toho fakt dost, co?</em> Nepíše se mi to lehce,
a trvalo to, než jsem to ze sebe dostal, ale tohle je <strong>poslední
newsletter</strong> v této podobě. Ani jsem ho nestihl pojmenovat a už jsem
ho <em>zabil</em>. Nezbývá mi tolik času, abych každou událost, novinku a
změnu v prohlížeči detailně popisoval tak, jak bych v newsletteru chtěl,
mrzí mě to. Aktuální novinky a události místo toho najdete u <a
href="https://twitter.com/spazef0rze">mě na Twitteru</a> a/nebo <a
href="https://www.facebook.com/spaze">na Facebooku</a>. S radostí si tedy
můžete vyhodit RSS newsletteru z čtečky (protože <em>Inbox Zero</em>,
že), ale přidejte si místo toho <a
href="https://www.michalspacek.cz/exporty/clanky">RSS pro všechny články</a>,
mám „rozdělaných“ pár <em>pěkných</em> článků. Moc děkuji za
dosavadní přízeň i pochopení.</p>
<h2 id="kam-dal">Kam dál</h2>
<p id="kam-dal">Newsletter <a
href="https://www.feistyduck.com/bulletproof-tls-newsletter/">týkající se
TLS/SSL/HTTPS</a> vydává Feisty Duck, knižní vydavatelství, které má na
svědomí třeba <a
href="https://www.feistyduck.com/books/bulletproof-ssl-and-tls/">Bulletproof SSL
and TLS</a> – „živou“, neustále aktualizovanou knihu o… no, však
víte. Na Rootu najdete <a
href="https://www.root.cz/serialy/postrehy-z-bezpecnosti/">seriál Postřehy
z bezpečnosti</a> a v Hospodářských novinách <a
href="https://ihned.cz/?m=authors&article%5baut_id%5d=16308890&person%5bid%5d=16308890">vychází
Bezpečnostní svodky Michala Altaira Valáška</a>. Plánované změny
v prohlížečích tweetuje <a href="https://twitter.com/intenttoship">účet
Intent To Ship</a>.</p>https://www.michalspacek.cz/treti-cislo-newsletteru-2017-21-tyden2017-05-29T10:00:00+02:002017-05-29T10:00:00+02:00<p>Třetí číslo newsletteru převážně o bezpečnosti, bezpečném vývoji
převážně webových aplikací a bezpečnosti uživatelů.</p>Třetí číslo newsletteru (2017, 21. týden)<p>Tady je přehled toho, co mě minulý týden zaujalo.</p>
<p>Pokud chcete newsletter dostávat pravidelně, tak využijte <a
href="https://www.michalspacek.cz/exporty/clanky">export všech článků</a>
nebo <a href="https://www.michalspacek.cz/exporty/clanky/newsletter">jenom
newsletterů</a> ve formátu <em>Atom</em>.</p>
<h2 id="tls-ssl-https">TLS, SSL, HTTPS</h2>
<p id="stack-overflow-https"><strong>Stack Overflow</strong>, známý web, na
kterém můžete položit otázku ohledně programování a při troše
štěstí dostanete i odpověď, <strong>přešel na šifrované spojení
HTTPS</strong>. Šéf architekt a vývojář Nick Craver při té
příležitosti vydal <a
href="https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/">pěkně
dlouhý dokument</a>, ve kterém přechod popisuje. Ve Stack Overflow začali
o zavedení HTTPS <a
href="https://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/">přemýšlet
v roce 2013</a>, samotné „zapnutí“ jim <a
href="https://meta.stackexchange.com/questions/292058/network-wide-https-its-time">trvalo
2 měsíce</a>. Zajímavě se vypořádali s <em>Mixed Contentem</em>, tedy
s obsahem načteným po nezabezpečeném HTTP do stránky načtené pomocí
HTTPS. Prohlížeče totiž takový obsah nespustí (pokud se jedná o
„aktivní“ <em>mixed content</em>, tedy JavaScript), nebo hlásí varování
(pro „pasivní“ obrázky). Do otázek i odpovědí na Stack Overflow
<strong>lze obrázky vkládat</strong>, ale teď už <a
href="https://meta.stackexchange.com/questions/291947/roadmap-to-https-serving-and-uploading-https-images-only">jen
když jejich <strong>adresa začíná na <code>https://</code></strong></a>.
Primárním důvodem pro přechod prý byla rychlost, kterou HTTPS (a <a
href="https://www.michalspacek.cz/prednasky/http2-develcz">HTTP/2</a>)
přineslo. Samotné zabezpečení přenosů dat by prý za tolik práce
nestálo. <em>„Prodávejte“ rychlost v podání HTTP/2, ne bezpečnost
v podobě HTTPS, o tu nikdo vlastně moc nestojí.</em></p>
<p id="nasa-https">Na šifrovaný <strong>protokol HTTPS přešel</strong>
i <em>Národní úřad pro letectví a kosmonautiku</em>, zkráceně
<strong>NASA</strong>. Americkým vládním agenturám v podobných věcech
pomáhá <a href="https://18f.gsa.gov/">„servisní kancelář“ 18F</a>,
která na svém blogu <a
href="https://18f.gsa.gov/2017/05/25/from-launch-to-landing-how-nasa-took-control-of-its-https-mission/">zveřejnila
článek o přechodu</a>. NASA má přes 3000 veřejně přístupných webů a
služeb, na přechodu <em>makalo</em> přes sto lidí a že to nebylo
jednoduché dokazuje i v době psaní článku neplatný certifikát na <a
href="https://nasa.gov">https://nasa.gov</a> (bez <em>www</em>), který vypršel
28. května ve 2 ráno našeho času. Mimochodem, 77 % z celkem
1045 amerických federálních agentur podporuje HTTPS. Ukazuje to <a
href="https://pulse.cio.gov/https/domains/">dashboard</a>, který provozuje
<em>jednotka</em> 18F.</p>
<h2 id="prohlizece">Prohlížeče</h2>
<p id="electrolysis"><a
href="https://wiki.mozilla.org/Electrolysis"><strong>Electrolysis</strong></a>
(„e10s“, <em>e-deset-písmenek-s</em>) je projekt Mozilly, jak
z <strong>Firefoxu</strong> udělat Chrome. A taky Internet Explorer. Tyto
prohlížeče totiž vykreslují stránky <strong>pomocí více
procesů</strong>, což přináší větší stabilitu (nepadá celý
prohlížeč, ale jen jeden <em>tab</em>) a bezpečnost (jednotlivé procesy si
nemohou lézt do zelí), ale Firefox nic takového neměl. <strong>Od verze
54</strong> (aktuální je 53) by Electrolysis, tedy Firefox s více procesy <a
href="https://mail.mozilla.org/pipermail/firefox-dev/2017-May/005451.html">mělo
používat <strong>80 % uživatelů</strong></a>, kteří splní podmínky
<em>žádné rozšíření</em> a <em>prohlížeč bez speciálních nástrojů
pro nevidomé apod.</em> „Víceprocesový“ Firefox naštěstí <a
href="http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/">zabírá
jen o 10–20 % více paměti</a> než „jednoprocesový“ Firefox, takže
časem by <em>Electrolysis</em> měli používat všichni uživatelé a kromě
větší stability by to neměli ani postřehnout.</p>
<div id="csp-report-to">
<p><a
href="https://www.michalspacek.cz/prednasky/xss-php-csp-etc-omg-wtf-bbq-phplive"><strong>Content
Security Policy</strong></a> (CSP) spočívá v tom, že server pomocí HTTP
hlavičky <code>Content-Security-Policy</code> řekne prohlížeči, které
zdroje (např. JavaScript, obrázky a další) a odkud může do aktuálně
zobrazované stránky načítat. Když prohlížeč do stránky bude chtít
načíst například nepovolený JavaScript, tak na vývojářem uvedenou adresu
<strong>může poslat report</strong> a vývojář tak může <em>nějak</em>
reagovat. Adresa pro zasílání reportů se uvádí v direktivě
<code>report-uri</code>. Když se na jedná stránce poruší politika
několikrát, tak prohlížeč pošle tolik reportů, kolikrát k porušení
došlo, což není moc šetrné. Řeší to <strong><a
href="https://www.chromestatus.com/features/5826576096690176">nová
direktiva</a> <code>report-to</code></strong>, její hodnotou je název
<em>skupiny</em>, na níž se mají všechna hlášení posílat dohromady.
Podporovány budou obě direktivy <code>report-uri</code> i
<code>report-to</code>, alespoň po nějakou přechodnou dobu. „Nová“
hlavička CSP pak může vypadat například takto:</p>
<pre><code>Content-Security-Policy: script-src 'self'; report-to default</code></pre>
<p><em>Skupina</em> <code>default</code> se definuje pomocí <a
href="https://www.w3.org/TR/reporting/">nové HTTP hlavičky
<code>Report-To</code></a> a může být použita i pro další vlastnosti
prohlížeče, které umí posílat reporty.</p>
</div>
<div id="csp-embedded-enforcement">
<p>Ve <strong>Chrome</strong> by se měla <a
href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/DdzeM55D87Y/kwMlfu-DBgAJ">objevit
implementace <strong>Content Security Policy: Embedded Enforcement</strong></a>.
Ta <a href="https://w3c.github.io/webappsec-csp/embedded/">rozšiřuje <abbr
title="Content Security Policy">CSP</abbr></a> o možnost <strong>povolit
zdroje i stránce vkládané do <code>iframe</code></strong>. Takové stránky
často vývojář nemá pod kontrolou, jedná se například o reklamní
systémy nebo různé trackovací skripty, ale i jim by bylo vhodné zdroje
omezit. To půjde pomocí nového atributu <code>csp</code>,
například takto:</p>
<pre
class="html"><code><iframe src="..." csp="default-src povolena.cdn.com; object-src 'none'"></code></pre>
<p>Stránka natažená do <em>ajfrejmu</em> tak bude moci z
<code>povolena.cdn.com</code> načítat obrázky, JavaScript, CSS a další
(<code>default-src povolena.cdn.com</code>), až na plug-iny (Java, Flash) –
ty prohlížeč do stránky ve <em>frejmu</em> nenačte vůbec
(<code>object-src 'none'</code>). Stránky se nejdřív musí „domluvit“:
prohlížeč obsah atributu <code>csp</code> odešle v hlavičce
<code>Sec-Required-CSP</code> a stránka ve <em>frejmu</em> tu hlavičku
zpracuje a pokud bude v pořádku, tak server musí odpovědět hlavičkou
<code>Allow-CSP-From</code>, jejíž hodnotou bude <em>origin</em>
(protokol://doména:port) stránky, do které se <em>ajfrejm</em> vkládá,
jako jakési vyjádření souhlasu. Když prohlížeči hlavička
<code>Allow-CSP-From</code> nedorazí, tak iframe nezobrazí. Existuje ještě
druhá, <a
href="https://w3c.github.io/webappsec-csp/embedded/#implicit-opt-in">podstatně
komplikovanější možnost</a>: iframe pošle prohlížeči hlavičku
<code>Content-Security-Policy</code> jako obvykle a prohlížeč porovná,
jestli takto nastavená politika je „silnější“ než ta v atributu
<code>csp</code>, pokud ano, tak se iframe načte. <em>CSP: Embedded
Enforcement</em> pro Chrome je <a
href="https://www.chromestatus.com/features/5750241810710528">zatím ve
vývoji</a>.</p>
</div>
<h2 id="hesla">Hesla</h2>
<p id="1password-travel-mode">Správce hesel <strong>1Password</strong> (jeho
online verze) má <a
href="https://blog.agilebits.com/2017/05/18/introducing-travel-mode-protect-your-data-when-crossing-borders/">novou
vlastnost nazvanou <strong>Travel Mode</strong></a>. Ta funguje následovně:
před cestou do zahraničí se <strong>přihlásíte na webu</strong>,
označíte některá hesla jako <em><strong>bezpečná pro
cestování</strong></em>, zapnete <em>Travel Mode</em> a 1Password všechna
neoznačená hesla <strong>odstraní</strong> z vašich zařízení. Jakmile
jste bezpečně v cílové destinaci, tak se zase přihlásíte na webu, Travel
Mode vypnete a hned zas máte k dispozici všechna hesla. <em>Travel Mode</em>
se hodí třeba pro cesty s firemními zařízeními, dá se tak minimalizovat
riziko úniku přihlašovacích údajů. Během přestupů na letištích
většinou nemusíte mít přístup k důležitým firemní serverům a riziko,
že vám někdo na letišti <em>prohledá</em> počítač nebo telefon je
poměrně vysoké. Společnost Basecamp má hezkou <a
href="https://github.com/basecamp/handbook">příručku pro zaměstnance</a>, ve
které je cestování s daty <a
href="https://github.com/basecamp/handbook/blob/master/international-travel-guide.md#company-security-at-the-border">věnována
celá kapitola</a>. Tedy vlastně cestování <em>bez dat</em>, že.</p>
<p id="soutez-hesla">Pokud vás baví vymýšlet hesla (s vědomím, že
taková hesla <em>nejsou nejvíc nejbezpečnější</em>), tak přesně pro vás
Per Thorsheim, organizátor konference Passwords, připravil
<strong>soutěž</strong>, ve které <a
href="https://www.peerlyst.com/posts/a-passphrase-challenge-part-two-per-thorsheim-1">máte
vymyslet <strong>co nejkratší heslo</strong></a>, resp. větu
(<em>passphrase</em>). Ta má mít <strong>minimálně 4 slova</strong>, musí
obsahovat všechna písmena ze zvolené abecedy a má dávat smysl. Pangram
„Příliš žluťoučký kůň úpěl ďábelské ódy“ by sice smysl
dával, ale neobsahuje všechna písmena.</p>
<p id="samsung-skener-duhovky">Každou chvíli přijde nějaká jakože
převratná technologie, která se hesla snaží zabít. Zatím se to nepovedlo
nikomu a ničemu, ale aspoň je sranda. Telefon <strong>Samsung Galaxy
S8</strong> má dokonce <strong>skener duhovky</strong>. Ten jde <a
href="https://www.ccc.de/en/updates/2017/iriden">obejít nasměrováním
telefonu na <strong>obrázek duhovky</strong></a>, který byl vytištěn na
tiskárně od stejného výrobce. Trik spočívá v použití kontaktní
čočky, která obrázek správně „zakřiví“. Otisky prstů a podobné
ověřování bude vždy méně bezpečné než hesla, ale zase je to
pohodlnější a tak to někteří lidé budou spíš používat.</p>
<h2 id="chyby-a-zranitelnosti">Chyby a zranitelnosti</h2>
<p id="twitter-publikovani"><strong>Změnou parametrů</strong>
<code>owner_id</code> a <code>user_id</code> v rozhraní pro <strong>správu
reklam na Twitteru</strong> <a
href="http://kedrisec.com/twitter-publish-by-any-user/">šlo
<strong>tweetovat</strong> jako jakýkoliv jiný uživatel</a>. Bylo předtím
nutné uživateli tweetnout obrázek, aby se „stal“ jeho majitelem.</p>
<p id="titulky-spusteni-kodu"><strong>Přehrávače</strong> VLC, Kodi, Popcorn
Time a Stremio <a
href="http://blog.checkpoint.com/2017/05/23/hacked-in-translation/">obsahovaly
<strong>chyby při zpracování titulků</strong></a>, jejichž zneužitím mohl
útočník na počítači oběti <strong>spustit vlastní zákeřný
kód</strong>. Problémy byly odhaleny ručním procházením zdrojových kódů
nebo využitím automatizovaných „zkoušečů všeho možnýho“, jako
např. AFL (American Fuzzy Lop), a jen ve VLC byly nahlášeny a opraveny
4 chyby (CVE-2017–8310, CVE-2017–8311, CVE-2017–8312, CVE-2017–8313).
Detaily by mohly být známé již tento týden, nálezci <a
href="https://www.syscan360.org/en/speakers/#issue-17oh">budou o chybách
přednášet</a> na konferenci SyScan360. Prý existuje přes 25 různých
formátů titulků, některé dokonce používají HTML formátování a
obrázky, takže na problém je zaděláno.</p>
<p id="imagemagick-yahoo">Víte, co má taky spoustu <em>divných</em>
formátů? Správně, obrázky. Na změnu velikosti a vytváření náhledů se
často používá knihovna <strong>ImageMagick</strong>, což je taky
<em>povedenej kousek software</em>. Minulý rok v ní bylo <a
href="https://imagetragick.com/">nalezeno několik chyb</a>, jedna z nich
umožňovala útočníkovi spustit zákeřný kód třeba jen nahráním
<em>správného</em> obrázku do služby, která dělá náhled. Tento rok
legrace pokračuje. Chris Evans nalezl chybu, která <a
href="https://scarybeastsecurity.blogspot.cz/2017/05/bleed-continues-18-byte-file-14k-bounty.html">umožňovala
<strong>číst paměť</strong> serverů Yahoo</a>, stačilo si poslat e-mail
s 18 bajtovou přílohou. Obrázek v doručeném e-mailu obsahoval kousky
cizích fotek. Yahoo <em>zapomnělo</em> aktualizovat ImageMagick a tak šlo
zneužít i další, již dva roky opravenou chybu, která <a
href="https://scarybeastsecurity.blogspot.cz/2017/05/bleed-more-powerful-dumping-yahoo.html">dovolovala
z paměti získávat textové řetězce</a>. Yahoo problém vyřešilo úplně
skvěle: přestali ImageMagick používat úplně.</p>
<h2 id="nove-verze-a-vlastnosti">Nové verze a vlastnosti</h2>
<p id="wordpress-exploit-kit">WPXF, <a
href="http://pentestit.com/wpxf-wordpress-exploit-framework/"><strong>WordPress
Exploit Framework</strong></a>, slouží k <strong>testování webů</strong>,
které používají redakční systém WordPress. WPXF obsahuje zhruba stovku
modulů, které <strong>umí zneužít známých chyb</strong>
v <em>děravých</em> pluginech, ale můžete si dopsat vlastní podle
potřeby. Framework je podobně jako nástroj WPScan napsán v jazyce Ruby, ale
WPScan jen očmuchává web a zjišťuje použité verze WordPressu i doplňků
a výsledky poté porovnává s databází známých chyb.</p>
<h2 id="akce">Akce</h2>
<p id="it17">20. a 21. června se koná další ročník <strong>konference <a
href="https://www.nic.cz/it17/">Internet a Technologie</a></strong>, kterou
pořádá sdružení CZ.NIC, správce české národní domény, ve spolupráci
s Fakultou elektrotechnickou ČVUT. Velká část konference se <strong>věnuje
bezpečnosti</strong>, namátkou vybírám několik zajímavých přednášek:
Tomáš Hála z Active24 bude vyprávět o závislostech provozovatelů webů
(na certifikačních autoritách), Michal Špaček poradí, jak <em>vytunit</em>
HTTPS servery podle hodnocení SSL Labs a já přidám přednášku
o <em>hackování</em> účtů a lidí jen podle fotek na Facebooku. Vstupné
je 300 Kč, pro studenty 90% sleva.</p>
<h2 id="legislativa">Legislativa</h2>
<p id="gdpr-uoou">Za rok začne platit <em><strong>Obecné nařízení
o ochraně osobních údajů</strong></em> (GDPR), které nahradí zákon č.
101/2000 Sb., o ochraně osobních údajů. Pro snazší pochopení a orientaci
v nařízení vydal Úřad pro ochranu osobních údajů <a
href="https://www.uoou.cz/vismo/dokumenty2.asp?id_org=200144&id=23790"><strong>Soubor
otázek a odpovědí</strong></a> a <a
href="https://www.uoou.cz/vismo/dokumenty2.asp?id_org=200144&id=23799"><strong>Desatero
omylů o GDPR</strong></a>. Věděli jste například, že <abbr
title="General Data Protection Regulation">GDPR</abbr>, podobně jako HTTPS,
nezabezpečí váš web?</p>
<p id="gdpr-troy-hun"><em>Obecnému nařízení o ochraně osobních
údajů</em>, česky <strong><abbr
title="General Data Protection Regulation">GDPR</abbr></strong>, se <a
href="https://www.troyhunt.com/free-course-the-gdpr-attack-plan/">věnuje
i Australan Troy Hunt</a>. O GDPR natočil hodinu a čtvrt dlouhé
<strong>video</strong>, které je po registraci dostupné zdarma. Australan a
<em>evropské nařízení</em>? Jo, tohle <strong>GDPR se totiž netýká jen
evropských firem</strong>.</p>https://www.michalspacek.cz/druhe-cislo-newsletteru-2017-20-tyden2017-05-22T10:00:00+02:002017-05-27T19:53:14+02:00<p>Druhé číslo newsletteru převážně o bezpečnosti, bezpečném vývoji
převážně webových aplikací a bezpečnosti uživatelů.</p>Druhé číslo newsletteru (2017, 20. týden)<h3>Aktualizace článku</h3><ul><li><em><strong>27.5.</strong> Popis výpadku Let's Encrypt odkazuje na oficiální post-mortem, ne na <a
href="https://news.ycombinator.com/item?id=14375728">komentář na
Hacker News</a></em></li><li><em><strong>23.5.</strong> Michele Orru' na akci OWASPu bohužel nedorazí</em></li><li><em><strong>22.5.</strong> Přidán odkaz na exploit na Joomlu</em></li></ul><p>Minulý týden světem bezpečnosti stále hýbal ransomware
<em>WannaCry(pt)</em>, který lehce zastínil i další zajímavé události.
Tady je přehled toho, co mě zaujalo.</p>
<p>Pokud chcete newsletter dostávat pravidelně, tak využijte <a
href="https://www.michalspacek.cz/exporty/clanky">export všech článků</a>
nebo <a href="https://www.michalspacek.cz/exporty/clanky/newsletter">jenom
newsletterů</a> ve formátu <em>Atom</em>.</p>
<h2 id="tls-ssl-https">TLS, SSL, HTTPS</h2>
<p id="symantec-google">Certifikační autorita <strong>Symantec</strong>,
která v minulosti vystavila <a
href="https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29">minimálně
30 tisíc</a> falešných certifikátů, <a
href="https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ"><strong>se
předběžně dohodla s Googlem</strong></a>. Ten <a
href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ">původně
navrhoval</a> zkrátit platnost certifikátů od Symantecu na maximálně
9 měsíců a u tzv. EV certifikátů nezobrazovat příznak <em>Extended
Validation</em> (tedy název firmy). Dohoda říká, že od 8. srpna budou
certifikáty Symantecu <strong>vystavovány jednou nebo více nezávislými
certifikačními autoritami</strong> („Managed CAs“), které budou moci
vystavovat i <abbr title="Extended Validation">EV</abbr> certifikáty. Tyto
„Managed CAs“ mohou být křížově podepsány Symantecem tak, aby se
využily stávající kořenové certifikáty v prohlížečích.
<strong>Certifikáty vydané Symantecem po 1. červnu 2016 budou fungovat
i nadále</strong>. Ty starší by od Chrome 65 (datum vydání 18. ledna
2018) neměly být platné. Nezávislé certifikační autority budou muset od
1. února 2018 také ověřovat žádosti o certifikáty, do té doby mohou
použít informace Symantecu. Ten musí <strong>vytvořit úplně novou
certifikační autoritu</strong>, která bude muset být znovu přidána do
úložišť důvěryhodných certifikátů.</p>
<p id="https-phishing">Firefox i Chrome od ledna zobrazují varování na
stránce načtené pomocí nezabezpečeného HTTP pokud je na ní políčko pro
zadání hesla. To samozřejmě negativně ovlivnilo i falešné stránky
loudící od uživatelů jejich přihlašovací údaje a tak <a
href="https://news.netcraft.com/archives/2017/05/17/phishing-sites-react-promptly-to-new-browser-changes.html"><strong>počet
phishingových stránek na HTTPS stoupl třikrát</strong></a>. Certifikáty
jsou dnes zdarma dostupné pro každého (např. od certifikační autority
Let's Encrypt), tedy i pro podvodníky. Mohlo to být ale i tím, že
phishingové stránky jsou často hostované na hacknutých webech, které na
HTTPS přešly. V každém případě <strong>doporučení že bezpečný web
poznáte podle HTTPS a zámečku již dlouho neplatí</strong>.</p>
<p id="uzivatele-varovani">Počet uživatelů, kteří <strong>ignorují
varování Chrome</strong> o chybě při připojení na HTTPS servery <a
href="https://twitter.com/__apf__/status/865304554425810944"><strong>klesl na
33 %</strong> (Windows) a 17 % na Androidu</a>. V roce 2013 to bylo 70 %.
To kdybyste potřebovali nějaká čísla do prezentací. Kdybyste sháněli
i nějaká data nebo roky, tak je najdete v <a
href="https://www.feistyduck.com/ssl-tls-and-pki-history/"><strong>přehledu
historie SSL/TLS</strong></a>. Mohlo by vás překvapit, že protokol
<strong>SSL 3 je z roku 1995</strong> a TLS 1.2 z roku 2008.</p>
<p id="ocsp">Certifikační autorita <strong>Let's Encrypt</strong> měla
v pátek <a
href="https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/591ed0da457ea42d38001796">několikahodinový
<strong>výpadek OCSP</strong></a> (Online Certificate Status Protocol)
serverů. Ty slouží k ověření platnosti certifikátů, prohlížeč na ně
může po obdržení certifikátu poslat dotaz aby zjistil, jestli certifikát
nebyl <em>revokován</em> (zrušen). Browsery to většinou nedělají, protože
to zdržuje načtení stránky, místo toho se používá technika zvaná
<em>OCSP Stapling</em>. Spočívá v připojení („přicvaknutí“) <abbr
title="Online Certificate Status Protocol">OCSP</abbr> odpovědi rovnou
k počátečnímu navázání šifrovaného spojení mezi prohlížečem a
serverem, takže browser má informaci hned a nemusí nikam nic posílat.</p>
<p id="ocsp-stapling">Jenže <strong>implementace <em>OCSP Staplingu</em>
v serveru Apache je chybná</strong>. Pokud Apache obdrží chybu při dotazu
na <abbr title="Online Certificate Status Protocol">OCSP</abbr> server, tak tou
chybou <a
href="https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html">nahradí
stále platnou předchozí odpověď</a>, ačkoliv by nemusel a neměl.
<strong>Nginx</strong> začne „přicvakávat“ OCSP odpověď až když ji
získá, takže v klidu <strong>pošle první odpověď bez <em>OCSP</em>
statusu</strong>. To se dá řešit stahováním odpovědi mimo nginx a tomu pak
říct, že ji má hledat v souboru, na který ukazuje direktiva
<code>ssl_stapling_file</code>, ale ta <a
href="https://trac.nginx.org/nginx/ticket/990">nepodporuje více
certifikátů</a> pro jeden web. Více různých certifikátů se používá pro
<a
href="https://www.ssllabs.com/ssltest/analyze.html?d=michalspacek.cz">duální
nasazení</a> RSA („běžných“) a ECDSA certifikátů (ty používají tzv.
eliptické křivky).</p>
<p id="vypadek-letsencrypt"><strong>Výpadek Let's Encrypt</strong> <a
href="https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922">popsal
šéf Josh Aas</a>. Ve zkratce: pro <abbr
title="Online Certificate Status Protocol">OCSP</abbr> požadavky se používá
kódování Base64, ve kterém se mohou vyskytnout dvě lomítka za sebou.
V Let's Encrypt upravili webové servery tak, aby ze dvou lomítek nedělaly
jen jedno, což je sice standardní chování, ale pro <abbr
title="Online Certificate Status Protocol">OCSP</abbr> nevhodné. Jenže
některé prohlížeče posílají na <abbr
title="Online Certificate Status Protocol">OCSP</abbr> servery Let's Encrypt
požadavek se dvěma lomítky mezi doménou a Base64 daty
(<code>http://ocsp.int-x3.letsencrypt.org//<base64></code>), což po
„opravě“ znamenalo, že <strong>Base64 data nešla dekódovat</strong> a
servery <strong>vracely chybu</strong>. Ta se nekešovala na <abbr
title="Content Delivery Network">CDN</abbr> a tak skoro všechny požadavky šly
až na servery Let's Encryptu, ty nápor nezvládly a celá infrastruktura
Let's Encrypt se položila. Nešly ani vystavovat certifikáty a problémy
hlásili i <strong>uživatelé webového serveru Caddy</strong>. Ten nemohl
při startu kontaktovat Let's Encrypt pro vystavení nového certifikátu a tak
se nespustil. Autor již <a
href="https://caddyserver.com/blog/certificate-management-policies">vydal novou
verzi</a>, která se spustí i když nejde vystavit nový certifikát za
předpokladu, že starý expiruje za více než 7 dní.</p>
<h2 id="prohlizece">Prohlížeče</h2>
<p id="eme-https">Mozilla <a
href="https://groups.google.com/forum/#!msg/mozilla.dev.platform/sa_2q8oEKgE/nLF5_t1EAwAJ">plánuje
z <strong>Firefoxu odstranit podporu pro <em>Encrypted Media Extensions</em>
(EME) na nešifrovaném HTTP</strong></a> a nadále pro <abbr
title="Encrypted Media Extensions">EME</abbr> vyžadovat HTTPS. Chrome to samé
udělal v aktuální verzi 58, Mozilla to chce stihnout <strong>do konce
roku</strong>. <em>Encrypted Media Extensions</em> dovoluje používat
zašifrovaný obsah ve videu v HTML5, využívá toho například společnost
Netflix, která se zabývá mj. distribucí video obsahu po Internetu.</p>
<p id="hlavicka-xcto"><strong>Safari</strong> od verze 30 (aktuálně jako
<em>Technology Preview</em>) <a
href="https://webkit.org/blog/7614/release-notes-for-safari-technology-preview-30/">podporuje</a>
<strong>bezpečnostní hlavičku
<code>X-Content-Type-Options: nosniff</code></strong>. Tu by ze serveru do
prohlížeče měly posílat všechny aplikace a hlavně ty, do kterých
uživatelé mohou nahrávat své soubory. Některé <a
href="https://www.michalspacek.cz/prednasky/http-hlavicky-subresource-integrity-apod-phplive/x-content-type-options">prohlížeče
totiž <em>očmuchávají</em> obsah dat</a> a když se jim zdá, že
<em>to</em> vypadá třeba jako JavaScript, tak <em>to</em> začnou za
JavaScript považovat. A to i přesto, že <em>to</em> byl původně
obyčejný textový soubor, který do prohlížeče dorazil s typem
<code>text/plain</code>. Útočník by tak mohl například pomocí nahraného
textového souboru spustit útok <a
href="https://www.michalspacek.cz/prednasky/xss-php-csp-etc-omg-wtf-bbq-phplive/xss"><abbr
title="Cross-Site Scripting">XSS</abbr></a> a získat obsah cookies uživatele.
Hlavička <code>X-Content-Type-Options: nosniff</code> takové
<strong>„očmuchávání“ vypíná</strong>. Jestli hlavičku posíláte si
můžete zkontrolovat na <a
href="https://securityheaders.io/">securityheaders.io</a>. V Safari
Technology Preview 30 je nově také <strong>Subresource Integrity
(SRI)</strong>, tedy ochrana proti modifikaci souborů např. na <abbr
title="Content Delivery Network">CDN</abbr>. <abbr
title="Subresource Integrity">SRI</abbr> jsem detailněji popisoval <a
href="https://www.michalspacek.cz/prvni-cislo-newsletteru-2017-19-tyden">minule</a>.</p>
<h2 id="chyby-a-zranitelnosti">Chyby a zranitelnosti</h2>
<p id="joomla-sql-injection">Populární nástroj pro správu obsahu (<abbr
title="Content Management System">CMS</abbr>) <strong>Joomla! verze
3.7</strong> <a
href="https://blog.sucuri.net/2017/05/sql-injection-vulnerability-joomla-3-7.html">obsahuje
jednoduše zneužitelnou chybu <strong>SQL Injection</strong></a> v komponentě
<code>com_fields</code>. Chyba byla opravena ve verzi 3.7.1. SQL Injection
mizerům umožní získat data z tabulek v databázi, ke kterým běžně
nemají přístup, například uživatelská jména a hesla. Útok SQL Injection
a ochranu proti němu si ukazujeme i na školení <a
href="https://www.michalspacek.cz/skoleni/bezpecnost-php-aplikaci">Bezpečnosti
webových aplikací</a>
<small>(nejbližší termín: termín zatím nevypsán)</small>. <strong>Aktualizace
22.5.</strong>: objevil se <a
href="https://github.com/XiphosResearch/exploits/tree/master/Joomblah">kód,
který chybu umí zneužít</a>.</p>
<p id="uber-reset-hesla">Hacker s přezdívkou Procode701 nahlásil
<strong>Uberu</strong> před sedmi měsíci chybu, která umožňovala
<strong>unést účet jakémukoliv uživateli</strong> pomocí chyby v resetu
zapomenutého hesla. Taková obnova by měla probíhat tak, že zadáte
e-mailovou adresu, aplikace na ni pošle náhodně vygenerovaný a unikátní
odkaz, vy na něj kliknete a můžete nastavit nové heslo. Uber ovšem <a
href="http://securityaffairs.co/wordpress/59210/hacking/uber-improper-authentication.html">náhodně
vygenerovaný identifikátor zaslal zpátky i do prohlížeče uživatele</a>.
Útočník tak mohl zadat e-mailovou adresu jakéhokoliv zákazníka Uberu a
z odpovědi serveru si zjistit i vygenerovaný identifikátor. Ten pak ručně
mohl přidat do odkazu, načíst danou stránku a heslo k zadané adrese
nastavit ve svém prohlížeči.</p>
<p id="wordpress-bug-bounty"><strong>WordPress má <a
href="https://wordpress.org/news/2017/05/wordpress-now-on-hackerone/">bug bounty
program</a></strong>. Když v něm naleznete nějakou bezpečnostní chybu,
můžete ji nahlásit a získat finanční odměnu. Platí to i pro projekty
BuddyPress, bbPress, GlotPress a WP-CLI a do programu odměn jsou zahrnuty
hlášení bezpečnostních chyb na následujících doménách:
<code>wordpress.org</code>, <code>bbpress.org</code>, <code>wordcamp.org</code>,
<code>buddypress.org</code>, <code>glotpress.org</code>,
<code>api.wordpress.org</code>. Detaily <a
href="https://hackerone.com/wordpress">najdete na platformě HackerOne</a>, na
které WordPress svůj bug bounty program provozuje.</p>
<h2 id="nove-verze-a-vlastnosti">Nové verze a vlastnosti</h2>
<p id="fb-messenger-e2e"><em>End-to-End</em> šifrování zajistí, že
k vašim zprávám nemá přístup ani provozovatel serverů, přes které se
posílají. Takové šifrování používá například WhatsApp, který je
postaven na Signal Protocolu. Šifrování <strong><em>End-to-End</em>
používá i Facebook Messenger</strong> pro tzv. <a
href="https://www.facebook.com/help/messenger-app/1084673321594605/"><em>Secret
Conversations</em></a>, které jsou dostupné pro Android a iOS. Ty Facebook
spustil <a
href="https://newsroom.fb.com/news/2016/07/messenger-starts-testing-end-to-end-encryption-with-secret-conversations/">již
loni v létě</a>, ale až teď mají uživatelé <strong>možnost používat
více zařízení</strong>, což znamená, že zprávy můžete dostávat
zároveň na mobil i na tablet. Podobně to umí i komunikátor <a
href="https://whispersystems.org/">Signal</a>, podle kterého se jmenuje onen
protokol, ale má navíc i <a
href="https://whispersystems.org/blog/signal-desktop/">klienta pro Chrome</a>,
který můžete ovládat všemi deseti i na počítači.</p>
<p id="php-encryption">Nejlepší™ šifrovací knihovna pro PHP
<strong><code>defuse/php-encryption</code> má <a
href="https://github.com/defuse/php-encryption/releases/tag/v2.1.0">novou verzi
2.1.0</a></strong>. Ta usnadňuje načítání šifrovacích klíčů ze
souborů, ignoruje odřádkování (a další „bílé znaky“) na konci
souborů s klíči. Pokud v PHP šifrujete data, měli byste používat tuto
knihovnu, autoři se vyznají v kryptografii a snaží se knihovnu vytvářet
tak, aby bylo těžké ji použít špatně.</p>
<p id="tink">Novou <strong>knihovnu pro šifrování v Javě a C++</strong>
s využitím cloudových úložišť šifrovacích klíčů vytvořila parta
kryptologů a vývojářů z Google. <a
href="https://github.com/google/tink">Jmenuje se <strong>Tink</strong></a>,
zatím není dokončená a nemá žádný <em>release</em>, ale vypadá
nadějně právě díky podpoře úložišť jako např. Amazon KMS. V budoucnu
by knihovna měla podporovat i Go, Python a JavaScript. Asi by se slušelo
zopakovat, že šifrovací knihovny byste si nikdy <strong>neměli psát
sami</strong>, je totiž velmi jednoduché navrhnout algoritmy, které vy sami
nedokážete prolomit. Ale to neznamená, že to nedokáže ani váš soused
na síti.</p>
<p id="ssh-mitm">Když se vám při přihlašování na vzdálený <abbr
title="Secure Shell">SSH</abbr> server objeví hláška, že se změnil klíč,
pátrate po důvodu? Naprostá většina uživatelů nejspíš ne. Toho právě
využívá <a href="https://github.com/jtesta/ssh-mitm"><strong>SSH
MITM</strong></a>, <em>patch</em> pro OpenSSH, který z něj udělá
<strong>proxy server</strong> umožňující <strong>zachytávat procházející
provoz</strong>, včetně hesel. SSH MITM se hodí jako nástroj pro testování
nejen ostražitosti uživatelů při přístupu na vzdálené servery.</p>
<h2 id="uniky-dat">Úniky dat</h2>
<p id="unik-bell">Kanadská telekomunikační společnost <strong>Bell</strong>
přiznala, že někdo <a
href="http://www.ibtimes.co.uk/canadian-telecom-bell-admits-hackers-stole-more-1-9m-active-email-addresses-1621883">získal
<strong>1,9 milionu uživatelských účtů</strong> z jejich databáze</a>
(ve skutečnosti <a href="https://haveibeenpwned.com/PwnedWebsites#Bell2017">to
bylo 2,2 milionu</a>). Data byla volně ke stažení na Internetu, útočníci
vyhrožují uvolněním dalších dat, pokud Bell nebude „spolupracovat“
(asi překlep, chtěli spíš napsat „platit“). Podobný incident se
odehrál počátkem roku 2014, tenkrát někdo <a
href="http://globalnews.ca/news/1123488/bell-canada-hacked-small-business-customer-usernames-passwords-breached/">získal
zhruba 21 tisíc uživatelských účtů ze systémů dodavatele Bellu</a>.</p>
<p id="unik-dafont">Skoro <strong>700 tisíc účtů</strong> a hesel
hashovaných pomocí MD5 <a
href="http://www.zdnet.com/article/font-sharing-site-dafont-hacked-thousands-of-accounts-stolen/">získal
útočník ze serveru na sdílení fontů <strong>DaFont</strong></a>. Využil
k tomu zranitelnost <em>SQL Injection</em>, která mizerovi umožňuje upravit
dotazy zasílané do databáze a získat tak data, která běžně nejsou
zobrazována. Data uniklá z DaFont i ze společnosti Bell jsou již nahrána
do služby <a href="https://haveibeenpwned.com/">Have I Been Pwned</a>, tam
můžete zjistit, jestli v úniku nebyl i váš e-mail a případně si nechat
<a href="https://haveibeenpwned.com/NotifyMe">zasílat notifikace</a> nebo
prohledávat <a href="https://haveibeenpwned.com/DomainSearch">celou vaší
doménu</a>. Hashovací algoritmus MD5 je pro ukládání hesel zcela nevhodný,
dovoluje útočníkům generovat miliardy hashů za vteřinu a porovnávat je
s těmi, které získali z databáze a tím tak získat hesla uživatelů,
kteří je často používají i třeba pro přístup k e-mailovým
schránkám.</p>
<p id="unik-seznamka"><strong>120000 hashovaných hesel</strong> ze seznamky
<strong>PureMatrimony</strong> <a
href="http://www.ibtimes.co.uk/purematrimony-data-leak-muslim-dating-site-users-data-exposed-120000-passwords-found-online-1622517">uniklo
ze systémů dodavatele</a>. Data byla volně ke stažení, hesla byla
hashována opět pomocí nevhodného algoritmu MD5, <em>překvapení!</em></p>
<p id="unik-docusign">Společnost <strong>DocuSign</strong> vytvářející
software pro elektronické podepisování potvrdila, že kdosi <a
href="https://trust.docusign.com/en-us/personal-safeguards/">získal
<strong>seznam e-mailových adres</strong> uživatelů</a>, kteří u DocuSignu
měli účet. Seznam byl následně použit k rozesílání phishingu a
zavirovaných příloh. Pokud vám kdykoliv dorazí nějaký wordovský soubor,
který po vás bude chtít z nějakého důvodu povolit makra ve Wordu, tak to
nedělejte, i kdyby vám slibovali hory+doly. Pravděpodobně je to nějaký
zákeřný soubor, který vám pak zaviruje počítač.</p>
<p id="unik-combo"><strong>Volně přístupná MongoDB</strong> databáze
obsahovala (a nejspíš stále obsahuje) přes <strong>560 milionů
uživatelských účtů a hesel</strong>, z toho necelých 250 milionů
unikátních. Jenže to je jen „kombo“ – kompilace z předchozích
úniků dat, podobně jako seznamy nazvané „Anti Public“ a
„Exploit.in“. Troy Hunt, provozovatel <a
href="https://haveibeenpwned.com/">Have I Been Pwned</a>, zjistil, že
naprostá většina (98 %) účtů již v Have I Been Pwned je, takže tento
nový seznam <a
href="https://twitter.com/troyhunt/status/864575837265207296">importovat
nebude</a>.</p>
<p id="unik-zomato">Společnost <strong>Zomato</strong>, vytváří aplikaci pro
hledání restaurací, v létě 2014 koupila českou službu Lunchtime.cz
i slovenskou Obedovat.sk. Ve čtvrtek Zomato <a
href="https://motherboard.vice.com/en_us/article/restaurant-app-zomato-says-your-stolen-password-is-fine-but-is-it">oznámila,
že si někdo odnesl <strong>17 milionů uživatelských účtů</strong></a>
včetně hesel, která byla hashována zcela nevhodnou a příliš rychlou
funkcí MD5, <em>překvapení?</em> K heslu byla přidána kryptografická sůl
(<em>salt</em>), ačkoliv mluvit o dvou znacích jako o „soli“ není
správné. <em>Salt</em> musí být unikátní pro každého uživatele a heslo,
aby si útočník nemohl nastavit například <em>Password123</em> a pouhým
pohledem do databáze nemohl zjistit, kdo má stejné heslo jako on. Dva
hexadecimální znaky mohou obsahovat pouze 256 kombinací, což je pro miliony
uživatelů naprosto nedostačující. V <a
href="http://blog.zomato.com/post/160791675411/security-notice">prohlášení
firmy</a> stojí, že berou bezpečnost <em>velmi vážně</em> a já začínám
mít pocit, že když firma tohle musí prohlašovat, tak že to není tak
úplně pravda. Útočník prý chybu objevil před rokem, nahlásil ji, ale
firma report zcela ignorovala. Zomato se začalo o incident zajímat až ve
chvíli, kdy hacker začal data prodávat. Ten nakonec nabídku <a
href="https://venturebeat.com/2017/05/19/zomata-agrees-to-hackers-demand-will-launch-bug-bounty-program-in-exchange-for-stolen-data-deletion/">smazal
výměnou za příslib</a>, že firma spustí „dospělý“ bug bounty
program, ve kterém bude nahlášené chyby finančně odměňovat.</p>
<h2 id="soukromi">Soukromí</h2>
<p id="twitter-podminky"><strong>Twitter</strong> mění <a
href="https://twitter.com/privacy">zásady ochrany osobních údajů</a>, nové
budou platit od 18. června. Zároveň spustil nové <a
href="https://twitter.com/personalization"><strong>nastavení
personalizace</strong></a> a rozšířil <a
href="https://twitter.com/settings/your_twitter_data">nastavení vašich
údajů</a>. Podívejte se, co všechno o vás Twitter ví a co všechno
můžete vypnout. Pro některé bude překvapením, že Twitter na Androidu <a
href="https://support.twitter.com/articles/20172069">zjišťuje vaše
nainstalované aplikace</a> a používá to pro personalizaci obsahu, který
vám nabízí, ale nebojte, i to lze vypnout. Když už v tom budete,
podívejte se do <a href="https://twitter.com/settings/safety">nastavení</a>,
jestli nemáte nevědomky zapnuté třeba sdílení polohy. Patřičnou péči
věnujte i <a href="https://twitter.com/settings/applications">seznamu
aplikací</a>, které mají přístup k vašemu účtu a ty neznámé nebo
nepoužívané odstraňte. Nebo smažte rovnou všechno, když aplikace bude
potřebovat přístup, tak vás o něj požádá. Často se totiž stává, že
aplikaci někdo <em>hekne</em> nebo její autor dostane nabídku, kterou
nemůže odmítnout, a pak za vás tweetuje třeba spam.</p>
<h2 id="akce">Akce</h2>
<p id="locked-shields">V estonském Tallinnu proběhlo před pár týdny
<strong>mezinárodní cvičení</strong> věnující se kybernetické
bezpečnosti nazvané <strong><em>Locked Shields</em></strong>. Od roku 2010 ho
organizuje NATO a letos ho český tým vyhrál, gratuluju! Jak takové
cvičení probíhá <a
href="https://blog.nic.cz/2017/05/19/zazitky-z-locked-shields-2017/">popisují
Radka Nepejchalová a Martin Kunc</a>: Radka měla na starosti e-shop, na
kterém protivník úspěšně zneužil chybu SQL Injection, Martin pečoval o
(nebo <em>patchoval</em>?) DNS a VPN servery.</p>
<p id="owaspcz">V úterý 30. května pořádá česká větev sdružení
<strong><abbr
title="Open Web Application Security Project">OWASP</abbr></strong> v Praze <a
href="https://www.eventbrite.com/e/owasp-czech-chapter-meeting-registration-33997427220">další
<strong>setkání nejen o webové bezpečnosti</strong></a>. Vstup (a pizza)
zdarma, registrace nutná. Mluvit se bude o JavaScriptu, mobilních
aplikacích, WordPressu a Internet Exploreru, těším se! <del>Pozvání
přijal například Michele Orru', hlavní vývojář frameworku
<strong>BeEF</strong>, který tak <a
href="https://www.michalspacek.cz/prednasky/xss-php-csp-etc-omg-wtf-bbq-phplive/beef">rád
používám ve svých přednáškách</a></del> <strong>Aktualizace
23.5.</strong>: Michele Orru' bohužel nedorazí.</p>https://www.michalspacek.cz/prvni-cislo-newsletteru-2017-19-tyden2017-05-15T10:00:00+02:002017-08-01T00:32:44+02:00<p>První číslo newsletteru převážně o bezpečnosti, bezpečném vývoji
převážně webových aplikací a bezpečnosti uživatelů.</p>První číslo newsletteru (2017, 19. týden)<h3>Aktualizace článku</h3><ul><li><em><strong>1.8.</strong> Chrome 60 již kontroluje <em>origin</em> všech <em>frames</em> pokud
přijde hlavička <code>X-Frame-Options: SAMEORIGIN</code></em></li><li><em><strong>16.5.</strong> Přidána informace o <code>rel="noreferrer"</code> k
<code>rel="noopener"</code></em></li></ul><p>Wow, takové ohlasy na nulté číslo newsletteru jsem nečekal. Všem moc
děkuju za přečtení a připomínky, toto první číslo je díky nim lehce
bohatší na informace i kontext. Dejte mi prosím vědět, jestli je to
takhle lepší.</p>
<p>Pokud chcete newsletter dostávat pravidelně, tak jsem přidal <a
href="https://www.michalspacek.cz/exporty/clanky">export všech článků</a>
nebo <a href="https://www.michalspacek.cz/exporty/clanky/newsletter">jenom
newsletterů</a> ve formátu <em>Atom</em>. Zasílání e-mailem přijde ještě
o něco později.</p>
<p>Pohodlně se usaďte, první číslo newsletteru se stále pracovním názvem
<em>čtu Twitter, aby vy už jste nemuseli</em> je tu.</p>
<h2 id="tls-ssl-https">TLS, SSL, HTTPS</h2>
<p id="symantec-opera"><strong>Opera Software</strong> se <a
href="https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B201-225%5D">vyjádřila
k situaci</a> s certifikační autoritou <strong>Symantec</strong>, která
v minulých letech vydala <a
href="https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29">minimálně
30 tisíc falešných certifikátů</a>. Opera by nejraději viděla celou
novou infrastrukturu pro vydávání certifikátů, ale nejspíš prostě
udělá to, co udělá Google. Ať už to bude cokoliv.</p>
<p id="edge-sha1-certifikaty"><strong>Microsoft Edge</strong> a <strong>Internet
Explorer 11</strong> <a
href="https://technet.microsoft.com/library/security/4010323">blokují od
9. května weby</a>, které mají <strong>SHA-1 certifikáty</strong> (platí
to i pro <em>intermediate</em> certifikační autority) a prohlížeče místo
toho zobrazují chybovou hlášku informující o špatném certifikátu. Tato
změna se dotkne jen certifikátů, jejichž kořenový certifikát je
v Microsoft Trusted Root Programu, ačkoliv přejít na bezpečnější
SHA-2 by měli všichni.</p>
<p id="inspekce-https">Tým složený z lidí z několika univerzit,
z Mozilly, Google a Cloudflare se podíval na <strong>zoubek „inspekci HTTPS
provozu“</strong> (<em>HTTPS Interception</em>), tedy sledování
zašifrovaného provozu pro účely skenování antivirem nebo blokování
nevhodného obsahu. Jejich <a
href="https://www.elie.net/publication/the-security-impact-of-https-interception">výzkum
ukazuje</a>, že webový server může „inspekci provozu“ detekovat podle
charakteristiky HTTPS spojení, která je pro každý prohlížeč a skenovací
software jiná. Analýzu prováděli na několika populárních e-commerce
webech, na serverech, ze kterých si stahuje aktualizace Firefox a na síti
Cloudflare. Ve všech případech zjistili, že <strong>„inspekce HTTP
provozu“ je 4–11 %</strong>, tedy o řád vyšší, než se doposud
předpokládalo. Zkoumáním populárních antivirů a firemních proxy serverů
zjistili, že <strong>skoro všechny programy snižují zabezpečení
spojení</strong>, některé dokonce ani správně neověřovaly certifikáty.
Zjišťováním použitých TLS/SSL klientů podle charakteristik spojení se
v roce 2015 <a
href="https://is.muni.cz/repo/1299983/https_client_identification-paper.pdf">zabýval
i tým z Masarykovy univerzity v Brně</a>.</p>
<p id="overovani-certifikatu-ios"><strong>76 oblíbených (a spousta těch
méně oblíbených) aplikací</strong> pro iOS <strong>neověřuje správně
certifikáty</strong>, čímž umožní <strong>zákeřným Wi-Fi</strong>
sítím a jejich provozovatelům dostat se například k přihlašovacím
údajům podvržením falešného certifikátu. <a
href="https://medium.com/@chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f">Seznam
27 z nich byl zveřejněn</a>, některé ale stále na opravu čekají. Tento
problém musí vyřešit vývojáři aplikací, App Transport Security (ATS) to
za ně neudělá. ATS zajistí „jen“ to, že aplikace bude komunikovat po
HTTPS s použitím dostatečně silných šifer.</p>
<h2 id="prohlizece">Prohlížeče</h2>
<p id="mozilla-bug-bounty"><strong>Mozilla</strong> znovu <a
href="https://blog.mozilla.org/security/2017/05/11/relaunching-web-bug-bounty-program/">spustila
<strong><em>web bug bounty program</em></strong></a>. Za nalezení chyb na
vybraných webech a jejich nahlášení můžete získat odměnu až $5000 za
spuštění kódu (<abbr title="Remote Code Execution">RCE</abbr>) na
kritických serverech.</p>
<p id="edge-sop">Prohlížeč <strong>Edge</strong> obsahuje zatím neopravené
chyby, které <a
href="https://www.brokenbrowser.com/sop-bypass-uxss-stealing-credentials-pretty-fast/">umožňují
<strong>obcházet Same-Origin Policy</strong></a> a získávat tak cookies a
v případě používání vestavěného správce hesel i přihlašovací
údaje. <a href="https://tools.ietf.org/html/rfc6454">Same-Origin Policy</a>
(SOP) má zajistit, že JavaScript z jednoho <em>originu</em> nebude mít
přístup ke stránce a datům na jiném <em>originu</em>, přičemž
<em>origin</em> je definován jako kombinace protokolu, jména serveru (domény)
a portu.</p>
<p id="chrome-teletexstring">V <strong>Chrome 59</strong> (vyjde v červnu) se
políčka <code>TeletexString</code> v certifikátech nakonec budou <a
href="https://bugs.chromium.org/p/chromium/issues/detail?id=717905#c14">zobrazovat
se znakovou sadou <em>Latin-1</em></a>, takže certifikáty s takovými
políčky na macOS <strong>budou nadále fungovat</strong>.
<code>TeletexString</code> je jeden ze způsobů, jak v certifikátu uvést
např. název firmy pokud obsahuje diakritiku. <a
href="https://www.michalspacek.cz/nulte-cislo-newsletteru-2017-18-tyden">Minule</a>
jsem psal, že takové certifikáty měly v Chrome 59 na macOS zobrazovat
chyby <code>ERR_SSL_SERVER_CERT_BAD_FORMAT</code> nebo
<code>ERR_BAD_SSL_CLIENT_AUTH_CERT</code>.</p>
<p id="service-workers-chromium">O <strong>bezpečnosti <em>Service
Workers</em></strong> v Chromiu se dozvíte v <a
href="https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq/service-worker-security-faq">Service
Worker Security <strong>FAQ</strong></a>. <em>Service Workers</em> jsou skripty,
které běží na pozadí, bez zobrazené stránky, a používají se na
synchronizaci nebo notifikace, tedy na věci, na které by jinak byla potřeba
nativní aplikace. Jsou zamýšleny jako vylepšená náhrada <em>Application
Cache</em>.</p>
<p id="izolace-extenzi-chrome">Od <strong>Chrome 56</strong> běží webové
iframy (např. reklamy) v extenzích (třeba na stránce s nastavením
rozšíření) <strong>v odděleném procesu</strong>. <a
href="https://blog.chromium.org/2017/05/improving-extension-security-with-out.html">Nemají
tak přístup k API pro rozšíření</a> i kdyby se jim podařilo zneužít
nějakou chybu. Zvýšilo se tím zabezpečení prohlížeče, taková API
totiž mohou přistupovat k věcem, ke kterým se běžná stránka nedostane,
např. k historii.</p>
<p id="hlavicka-xfo">Bezpečnostní HTTP <strong>hlavička
<code>X-Frame-Options</code></strong> se používá k omezení vložení
stránky do <em>frames</em>, čímž se znemožní útok <a
href="https://www.michalspacek.cz/prednasky/http-hlavicky-subresource-integrity-apod-phplive/clickjacking">Clickjacking</a>.
<strong>Varianta <code>X-Frame-Options: SAMEORIGIN</code></strong> povolí
vložit stránku do <em>frame</em> pokud je na stejném <em>originu</em>
(protokol, doména, port), ale <strong>kontroluje jen nejvyšší
<em>frame</em></strong>, tedy stránku zobrazenou v adresním řádku. Takže
stránku s <code>X-Frame-Options: SAMEORIGIN</code> je možné vložit do
<em>frame</em> na jiném <em>originu</em>, pokud ten <em>frame</em> je vložen
do stejného <em>originu</em> jako stránka posílající
<code>X-Frame-Options: SAMEORIGIN</code>, čímž se zamýšlená ochrana lehce
vytrácí. Schematicky to vypadá takto: <code>example.com</code> →
<code>útočník.cz</code> →
<code>example.com + X-Frame-Options: SAMEORIGIN</code>. Chrome už jednou
kontrolu <em>originu</em> změnil na všechny <em>frames</em>, ale museli tu
změnu vrátit zpět. Teď to <a
href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/fsDaKFqvU20/6swtcHVrAQAJ">chtějí
změnit znovu</a>. <strong>Aktualizace 1.8.</strong>: změna byla <a
href="https://www.chromestatus.com/feature/4678102647046144">provedena</a>
v Chrome 60.</p>
<div id="webkit-sri">
<p>Do <strong>WebKitu</strong> <a
href="https://bugs.webkit.org/show_bug.cgi?id=148363">byla přidána podpora
<strong>Subresource Integrity</strong> (SRI)</a>. WebKit je jádro prohlížeče
Safari a všech prohlížečů na iOS a Subresource Integrity hlídá, jestli se
nezměnil obsah nějakého zdroje staženého například z <abbr
title="Content Delivery Network">CDN</abbr>, tedy jestli někdo <em>cédéenku
nehacknul</em>, tak jak se to <a
href="https://www.maxcdn.com/blog/bootstrapcdn-security-post-mortem/">stalo
v roce 2013 frameworku Bootstrap</a>. Ten byste do stránky měli vkládat
pomocí značky <code>script</code> takhle nějak:</p>
<pre
class="html"><code><script
src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"
integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa"
crossorigin="anonymous"
></script></code></pre>
<p>Hodnotu atributu <code>integrity</code> se dozvíte od vývojáře knihovny.
Prohlížeč po stažení kódu spočítá jeho hash a pokud nesedí s hashem
v atributu <code>integrity</code>, tak se stažený soubor ignoruje. Víc
o <abbr title="Subresource Integrity">SRI</abbr> v mé přednášce <a
href="https://www.michalspacek.cz/prednasky/http-hlavicky-subresource-integrity-apod-phplive/sri">nejen
o bezpečnostních HTTP hlavičkách</a>.</p>
</div>
<h2 id="hesla">Hesla</h2>
<p id="teplomer-hesla"><strong>„Teploměry“ ukazující sílu hesla</strong>
(„password strength meters“) při jeho zadávání jsou často k ničemu.
Stačí jim, že heslo má 8 znaků, minimálně jedno velké, jedno malé,
jedno číslo a hned si myslí, že heslo je <em>supersilné</em> i přesto,
že je vcelku předvídatelné. <a
href="https://www.cs.cmu.edu/news/new-meter-will-change-how-users-create-passwords">Tenhle
teploměr ne</a>, navíc vám pomocí rad typu „nedávejte číslice jen na
konec“ <strong>navrhne jak heslo vylepšit</strong>, <a
href="https://cups.cs.cmu.edu/meter/">však to zkuste</a>. Za zmínku také
stojí <a
href="https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html">zxcvbn</a>
od Dropboxu.</p>
<p id="analyza-antipublic"><strong>Analýza 562 milionů hesel</strong> ze
seznamu nazývaného <strong>„Anti Public“</strong> <a
href="https://duo.com/blog/a-security-analysis-of-over-500-million-usernames-and-passwords">přinesla
tyto výsledky</a>: nejvíc účtů na doméně <code>yahoo.com</code>
(41,71 %), nejčastější délka hesla 9 znaků (27 %),
10 nejčastějších hesel: <code>123456</code>, <code>123456789</code>,
<code>abc123</code>, <code>password</code>, <code>password1</code>,
<code>12345678</code>, <code>111111</code>, <code>1234567</code>,
<code>12345</code>, <code>1234567890</code>. Vcelku nic
překvapivého, že.</p>
<h2 id="chyby-a-zranitelnosti">Chyby a zranitelnosti</h2>
<p id="icloud-keychain-sync"><strong>iCloud Keychain Sync</strong>, nástroj od
Apple pro bezpečné sdílení hesel mezi zařízeními, obsahoval chybu, která
útočníkovi <a
href="https://medium.com/@longtermsec/bypassing-otr-signature-verification-to-steal-icloud-keychain-secrets-9e92ab55b605">umožňovala
<strong>získat uživatelská data</strong></a> i přesto, že data jsou
šifrovaná <em>end-to-end</em> a šifrovací klíče jsou specifické pro
každé zařízení. Zneužití nebylo jednoduché, potřeboval by k tomu
např. přístup k serverům Apple nebo uživatelské heslo k iCloud účtu
bez 2FA. Chyba byla opravena v iOS 10.3.</p>
<p id="defender-spusteni-kodu">Natalie Silvanovich a Tavis Ormandy z Google
Project Zero našli chybu v jádru <strong>Windows Defenderu</strong>, což je
antivir dodávaný s Windows. <a
href="https://bugs.chromium.org/p/project-zero/issues/detail?id=1252&desc=5">Ta
umožňovala <strong>vzdáleně spustit kód</strong></a> např.
<strong>navštívením zákeřné stránky</strong>. Tím se do cache
prohlížeče (obecně na disk) uložil soubor s JavaScriptem, který chtěl
antivir prozkoumat, čímž kód dodaný útočníkem spustil. Microsoft <a
href="https://technet.microsoft.com/en-us/library/security/4022344">chybu
bleskově opravil</a>, uživatelé nemusí dělat nic, Defender se
aktualizuje sám.</p>
<p id="hp-stisky-klaves"><strong>HP</strong> <em>zapomnělo</em> ve svých audio
ovladačích (které vytvořila společnost Conexant) kousek kódu, který
<strong>zaznamenává stisky všech kláves</strong> a <a
href="https://www.modzero.ch/modlog/archives/2017/05/11/en_keylogger_in_hewlett-packard_audio_driver/index.html">zapisuje
je do souboru</a> přístupného všem uživatelům na počítači. Takže když
uživatel vyplňoval na nějakém webu své heslo, tak ho měl hezky
<em>zálohované</em>. Záloha to nebyla moc dobrá, při dalším
přihlášení do Windows se vymazala. V <a
href="https://twitter.com/__ths__/status/863324677019770880">novější verzi
ovladače „keylogger“ zůstal</a>, ale je potřeba ho nejdříve zapnout
v registrech, eh.</p>
<p id="vanilla-forums-spusteni-kodu">Software pro provozování diskuzních fór
<strong>Vanilla Forums</strong> až do verze 2.3.0 včetně <a
href="https://exploitbox.io/vuln/Vanilla-Forums-Exploit-RCE-0day-Remote-Code-Exec-CVE-2016-10033.html">používá
starou verzi knihovny PHPMailer</a>, čehož lze v kombinaci s <a
href="https://exploitbox.io/vuln/Vanilla-Forums-Exploit-Host-Header-Injection-CVE-2016-10073-0day.html">možností
upravit hlavičku <code>Host</code></a> využít ke <strong>vzdálenému
spuštění kódu</strong>. Oba problémy byly nahlášeny v prosinci 2016, ale
výrobce na opravu <em>zapomněl</em> a náhodou si <em>vzpomněl</em> až po
jejich zveřejnění. Pokud Vanilla Forums používáte, tak nezapomeňte
aktualizovat na <a
href="https://open.vanillaforums.com/discussion/33498/critical-security-release-vanilla-2-3-1">nově
vydanou verzi 2.3.1</a>.</p>
<p id="ipb-xss"><strong>Invision Power Board</strong>, další nástroj pro
provozování fór, obsahuje ve verzi 4.1.19.2 <a
href="http://zeroday.insecurity.zone/exploits/ipb_owned.txt">několik chyb
<strong>Cross-Site Scripting</strong></a> (XSS). Útočník může na fórum
například nahrát vlastní SVG soubor, ve kterém může být JavaScript
(<code><svg xmlns="http://www.w3.org/2000/svg" onload="alert('XSS❤SVG');"/></code>),
který potom prohlížeč spustí. V extrémním případě by těchto chyb
šlo využít až k nahrání útočníkovo PHP souboru na server a tím
<strong>spuštění jím dodaného kódu</strong>. Výrobce prý na opravu také
několik měsíců <em>zapomněl</em>, <a
href="https://invisionpower.com/release-notes/41194-r63/">opravu
<em>nějakých</em> XSS zmiňuje u verze 4.1.19.4</a>, ale detaily
neuvádí.</p>
<p id="travisci-tokeny"><strong>Travis CI</strong>, nástroj pro <em>Continuous
Integration</em>, <a
href="https://blog.travis-ci.com/2017-05-08-security-advisory">omylem
<strong>zobrazoval ve výstupech OAuth tokeny</strong></a>, které se
používají pro přístup ke GitHubu, například pro nahrávání souborů na
GitHub během <em>buildu</em>. Výstupy (česky logy) pro Travis CI
obsluhující open-source projekty jsou veřejně dostupné pokud je uživatel
nesmaže. GitHub dotyčné tokeny (bylo jich 2833) zneplatnil a majitelům dá
vědět. Problém se netýkal jenom GitHubu, Travis CI problém oznámil
i dalším službám.</p>
<p id="joomla-oprava-chyby"><strong>Nová verze</strong> publikačního
nástroje <strong>Joomla</strong> vyjde ve středu 17. května přibližně
v 16h našeho času. Verze 3.7.1 bude obsahovat <a
href="https://www.joomla.org/announcements/release-news/5704-important-security-announcement-pre-release-371.html"><strong>opravu
blíže nespecifikované kritické bezpečnostní chyby</strong></a>. Pokud
Joomlu používáte, na středeční odpoledne si asi raději nic jiného
neplánujte. Do několika hodin po zveřejnění zranitelnosti se běžně
vytvoří automatizované nástroje, které velmi rychle hledají
nezáplatované servery a chyby zneužívají.</p>
<h2 id="uniky-dat">Úniky dat</h2>
<p id="unik-edmodo">Z platformy pro podporu výuky na základních a
středních školách <strong>Edmodo</strong> někdo <a
href="https://motherboard.vice.com/en_us/article/hacker-steals-millions-of-user-account-details-from-education-platform-edmodo">získal
<strong>77 milionů uživatelských účtů a hashovaných hesel</strong></a>.
Databáze se prodává na „černém trhu“ za 1088 amerických dolarů.
Hesla byla hashována pomocí doporučovaného algoritmu <em>bcrypt</em>, takže
rychle půjde <em>cracknout</em> jen jednoduchá hesla typu <em>password</em>
apod. <a
href="https://pulse.michalspacek.cz/passwords/storages/site/www.edmodo.com">Edmodo
jsem přidal na svůj seznam firem</a>, které (třeba i nedobrovolně)
zveřejnily způsob ukládání hesel.</p>
<h2 id="utoky">Útoky</h2>
<p id="malware-proton"><strong>Malware Proton</strong> krade z macOS mj.
i data ze správce hesel <strong>1Password</strong>. Pokud jste si stáhli
populární program pro práci s video soubory HandBrake mezi 2. a
6. květnem, tak se <a
href="https://arstechnica.com/security/2017/05/mac-users-installing-popular-dvd-ripper-get-nasty-backdoor-instead/">porovnáním
SHA-1 hashe přesvědčte, že jste nestáhli modifikovaný program</a>. Někdo
totiž napadl server <em>download.handbrake.fr</em> a instalační program
HandBrake vyměnil za něco nepěkného.</p>
<p id="unos-dns"><strong>Unést</strong> se dá dneska snad všechno, třeba
i takový <strong>DNS server</strong>. Ten pak může domény převádět na
<em>nesprávné</em> IP adresy, čehož se dá využít k phishingu, distribuci
malware nebo cenzuře. <strong>Jak moc se po světě <a
href="https://recdnsfp.github.io/">unáší DNS server Google</a></strong> se
pomocí <em>DNS Fingerprintingu</em> rozhodli zjistit na DNS Hackathonu
v Amsterdamu. <strong>V ČR bylo uneseno 7 z 241 dotazů</strong>, čímž
jsme si vysloužili krásné 19. místo.</p>
<p id="zaplaty-xp">Chvilku poté co zmrzlo peklo <a
href="https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/">vydal
<strong>Microsoft</strong> záplaty pro Windows XP</a> (a další již
nepodporované operační systémy) řešící <strong>možnost vzdáleného
spuštění kódu pomocí protokolu SMB</strong>. Ten se ve Windows používá
pro sdílení souborů mezi počítači, přičemž pro podporované systémy
<strong>záplata existuje <a
href="https://technet.microsoft.com/en-us/library/security/ms17-010.aspx">již
od půlky března</a></strong>. Této chyby využívá <a
href="https://www.troyhunt.com/everything-you-need-to-know-about-the-wannacrypt-ransomware/">malware
resp. <em>ransomware</em> označovaný jako WannaCrypt</a> (někdy také
příznačně jako WannaCry), který zašifruje data na disku a požaduje
výkupné pro dešifrování. Na <a
href="https://gist.github.com/rain-1/989428fa5504f378b993ee6efbc0b168#infections">seznamu
obětí</a> figurují nemocnice, banky, továrny, parkovací automaty a další.
Šíření této varianty viru zpomalil chlapík s přezdívkou
<em>MalwareTech</em>, <a
href="https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html">ten
si všiml, že po infekci se malware snaží poslat požadavek</a> na doménu
<code>iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com</code>, která ale
<strong>nebyla registrovaná. Tak ji koupil</strong> a až později zjistil, že
fungovala jako hlavní vypínač – když malware dostal odpověď na <a
href="https://blog.didierstevens.com/2017/05/13/quickpost-wcry-killswitch-check-is-not-proxy-aware/">přímo
poslaný požadavek</a> (tzn. ne přes proxy), tak se dál nešířil. Již se
objevují <a
href="https://blog.comae.io/wannacry-new-variants-detected-b8908fefea7e">nové
varianty s jinými doménami</a>. Ať už podnikáte v čemkoliv, nezapomeňte
si domény registrovat včas.</p>
<h2 id="matka-moudrosti">Matka moudrosti</h2>
<p id="rel-noopener">Pokud z vaší stránky otvíráte <strong>odkazy do
nového okna pomocí <code>target="_blank"</code></strong>, tak k nim <a
href="https://developers.google.com/web/tools/lighthouse/audits/noopener">přidejte</a>
<code>rel="noopener"</code>. To zajistí, že stránky v Chrome budou mít
oddělené procesy a nová stránka nebude mít přístup k vlastnosti
<code>window.opener.location</code>, pomocí které může tu vaši
<strong>přesměrovat jinam, třeba na nějaký phishing</strong>, aniž by si
toho návštěvníci všimli. <strong>Aktualizace 16.5.</strong>: stejnou
funkčnost dosáhnete použitím <code>rel="noreferrer"</code>, z historických
důvodů se chová stejně, navíc neposílá ani <em>Referrer</em>.</p>
<h2 id="akce">Akce</h2>
<p id="dox-tyden-bezpecnosti">V centru současného umění <strong>DOX
v Praze</strong> se v týdnu od 15. května koná <a
href="http://www.dox.cz/cs/doprovodne-akce/tyden-datove-bezpecnosti"><strong>Týden
datové bezpečnosti</strong></a>. Jde o přednášky, komentované prohlídky
a workshopy k výstavě <em>Big Bang Data</em>, jsou většinou večer a
v rámci středeční panelové diskuze „Ukaž svá data!“ od 19h budu
<em>vaše data</em> ukazovat i já.</p>https://www.michalspacek.cz/nulte-cislo-newsletteru-2017-18-tyden2017-05-08T00:00:00+02:002017-05-11T00:00:00+02:00<p>Začal jsem sbírat odkazy a témata na newsletter. Tady je jeho
nulté číslo.</p>Nulté číslo newsletteru (2017, 18. týden)<h3>Aktualizace článku</h3><ul><li><em><strong>11.5.</strong> Nová adresa návrhu Mozilly na řešení situace s CA Symantec</em></li><li><em><strong>10.5.</strong> Lupa.cz již vypla podporu šifry RC4</em></li><li><em><strong>9.5.</strong> V Chrome 59 se pole <code>TeletexString</code> v certifikátech bude brát
jako <em>Latin-1</em></em></li></ul><p>Před týdnem mě napadlo začít psát newsletter. Začal jsem si
poznamenávat odkazy a čekal co z toho vyleze s tím, že zbytek vymyslím
potom, však to znáte. Zatím tedy nevím, jestli to vydávat měsíčně nebo
každý týden, ale podle odpovědí na <a
href="https://twitter.com/spazef0rze/status/861197976588484608">dotaz na
Twitteru</a> to vypadá spíš na každý týden. Do týdenních zpráv se dají
zařadit i celkem aktuální věci, třeba pozvánky na nějaké konference, na
druhou stranu, pokud byste se o nějakém problému dozvěděli za měsíc, tak
už může být třeba pozdě. Z týdenních se ale dá vždy zkompletovat
archív po měsících, takže možná přijde i kouzelník. A když už tu
bude, tak by mi mohl pomoci s RSS i posíláním e-mailem, chci rozhodně
nabídnout obojí.</p>
<p>Takže tady je nulté číslo newsletteru o tom, co mě zajímá.
Převážně o bezpečnosti, bezpečném vývoji nejen webových aplikací a
bezpečnosti uživatelů. Pracovně tomu říkám <em>čtu Twitter, aby vy už
jste nemuseli</em>.</p>
<p>Dejte mi prosím vědět, jestli byste to četli a jestli je týdenní
frekvence snesitelná. Jo, tenhle týden se toho urodilo dost, uvidíme kolik
toho bude v dalším nultém číslu.</p>
<p>Tak jdem na to, zprávy z týdne začínajícího Svátkem práce právě
začínají…</p>
<h2 id="tls-ssl-https">TLS, SSL, HTTPS</h2>
<p id="symantec-mozilla"><strong>Mozilla</strong> zveřejnila svůj <a
href="https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit">návrh
na řešení situace s certifikační autoritou <strong>Symantec</strong></a>.
Ta ztrácí důvěru výrobců prohlížečů, během minulých let se jí
totiž <a
href="https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29">podařilo
vydat minimálně 30 tisíc falešných certifikátů</a>. Dokument má
10 stran, ve zkratce: Mozilla navrhuje, aby CA provozoval někdo jiný, pokud
Symantec nebude souhlasit, tak chce snížit maximální platnost nových
i existujících certifikátů na 13 měsíců. Ale nevidí důvod
k zobrazování EV certifikátů jakožto „normálních“ certifikátů. Jen
pro úplnost, <a
href="https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ">návrh
Googlu z března</a> je o něco tvrdší.</p>
<p id="linkedin-brotli"><strong>LinkedIn</strong> shrnul zrychlování
načítání webu <a
href="https://engineering.linkedin.com/blog/2017/05/boosting-site-speed-using-brotli-compression">pomocí
kompresního algoritmu <strong>Brotli</strong></a>, ten je dostupný pouze
pro HTTPS.</p>
<p id="bezpecnost-tls13-0rtt"><em>Zero Round Trip Time Resumption (0-RTT)</em>
v <strong>TLS 1.3</strong> zrychluje načítání stránek skoro na úroveň
nešifrovaného webu, ale umožňuje provádět „Replay Attack“. Existuje
<em>workaround</em>, viz <a
href="https://github.com/tlswg/tls13-spec/issues/1001">Security review of TLS
1.3 0-RTT</a>, kde se také píše, že <em>TLS1.3 0-RTT is insecure by
default</em>. Cloudflare experimentálně <a
href="https://blog.cloudflare.com/introducing-0-rtt/">povolil TLS 1.3 0-RTT
v březnu</a>, ale kvůli tomuto jen pro <code>GET</code> požadavky bez
parametrů v URL.</p>
<p id="openssl-tls13"><strong>TLS 1.3</strong> se objeví
v <strong>OpenSSL</strong> ve verzi 1.1.1, v <a
href="https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/">Using TLS1.3 With
OpenSSL</a> se dozvíte další detaily o implementaci.</p>
<p id="lupa-https"><a href="https://www.lupa.cz/"><strong>Lupa.cz</strong></a>
konečně přešla na <strong>HTTPS</strong>. <del>Ještě by mohli <a
href="https://www.ssllabs.com/ssltest/analyze.html?d=www.lupa.cz&s=91.213.160.123">vypnout
podporu již ne zcela bezpečné šifry RC4</a>.</del> <strong>Aktualizace
10.5.</strong>: už ji vypli.</p>
<h2 id="prohlizece">Prohlížeče</h2>
<p id="chrome-not-secure"><strong>Chrome</strong> bude <a
href="https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html">od
verze 62 zobrazovat HTTP weby jako <strong>Not Secure</strong></a>, pokud si je
načtete v <em>Incognito</em> režimu nebo pokud do stránky na HTTP začnete
vyplňovat nějaké údaje. Verze 62 by měla vyjít v říjnu 2017.</p>
<p id="chrome-certifikat">V <strong>Chrome</strong> Canary je od verze
60.0.3088 zpátky <a
href="https://textslashplain.com/2017/05/02/inspecting-certificates-in-chrome/">zkratka
pro zobrazení <strong>informací o certifikátu</strong></a>, navíc
s šikovným <em>tooltipem</em>, který rovnou prozradí certifikační
autoritu. Snad to bude brzy i ve <em>stable</em> verzi, do té doby najdete
informace v <em>Developer tools</em> v záložce „Security“.</p>
<p id="chrome-64bit">Pokud používáte 32-bitový <strong>Chrome</strong> a
máte 64-bitový operační systém a víc jak 4 GB operační paměti, tak se
vám při automatické aktualizaci prohlížeče <a
href="https://chromereleases.googleblog.com/2017/05/stable-channel-update-for-desktop.html">nainstaluje
<strong>64-bitová verze</strong></a>.</p>
<p id="chrome-blokovani-pozadavku">V <strong>Chrome</strong> je od verze
59 možnost <a
href="https://developers.google.com/web/updates/2017/04/devtools-release-notes#block-requests"><strong>blokovat
požadavky</strong> v <em>Developer tools</em></a>. To se hodí třeba pro
testování webu v prohlížečích s blokováním reklam apod.</p>
<p id="hotmail-certifikat"><strong>Hotmail</strong> má na doméně <a
href="https://hotmail.com">https://hotmail.com</a> <strong>špatný
certifikát</strong>. Chrome takovou situaci vyřeší automagickým přidáním
<code>www</code>, ale zkuste si <a
href="https://hotmail.com">https://hotmail.com</a> načíst ve Firefoxu. Více
o podobné funkčnosti se dozvíte od Erica Lawrence v jeho <a
href="https://textslashplain.com/2017/03/01/the-trouble-with-magic/">blog postu
o magii</a>, v části „End-User Magic“.</p>
<p id="podpora-webcrypto"><strong>Web Crypto API</strong> dovoluje JavaScriptu
používat kryptografické operace, jeho <a
href="https://gist.github.com/rmhrisk/88afc747e33bc662cc9b90c3ed5bf479"><strong>podporu
v prohlížečích</strong> zmapoval Ryan Hurst</a>.</p>
<p id="chrome-teletexstring"><strong>Aktualizace 9.5.</strong>: v Chrome 59 se
<code>TeletexString</code> bude <a
href="https://bugs.chromium.org/p/chromium/issues/detail?id=717905#c14">brát
jako <em>Latin-1</em></a> a certifikáty <strong>budou dále fungovat</strong>
i na macOS. <del>Pokud máte v serverovém nebo klientském certifikátu
<strong>diakritiku</strong> (obecně jakékoliv „ne-ASCII“ znaky)
v políčku <code>TeletexString</code>, tak vám <a
href="https://textslashplain.com/2017/05/03/chrome-59-on-mac-and-teletexstring-fields/">v <strong>Chrome
59 na macOS přestane fungovat</strong></a> a místo toho uvidíte chybu
<code>ERR_SSL_SERVER_CERT_BAD_FORMAT</code> nebo
<code>ERR_BAD_SSL_CLIENT_AUTH_CERT</code>. Jestli takový certifikát máte
zjistíte např. pomocí tohoto <a
href="https://lapo.it/asn1js/">ASN.1 dekodéru</a>, hledejte řetězec
<code>TeletexString</code>.</del></p>
<h2 id="hardware">Hardware</h2>
<p id="cactus-hid"><a
href="https://blog.aprbrother.com/product/cactus-whid"><strong>Cactus
WHID</strong></a>, <em>Wi-Fi <abbr title="Human interface device">HID</abbr>
Injector</em>, „fleška“, co vypadá jako „fleška“, ale <strong>není
to „fleška“</strong>. Umí například simulovat klávesnici, má Wi-Fi a
vypadá to na dobrou legraci. Mám trochu jednodušší <a
href="https://hakshop.com/products/usb-rubber-ducky-deluxe">Rubber Ducky</a>,
programovatelnou „klávesnici ve flešce“, takže až mě někde potkáte,
tak vám to rád ukážu, hehe.</p>
<h2 id="chyby-a-zranitelnosti">Chyby a zranitelnosti</h2>
<p id="wordpress-spusteni-kodu">Ve <strong>WordPressu 4.6</strong> jde díky
chybě v PHPMaileru <a
href="https://exploitbox.io/vuln/WordPress-Exploit-4-6-RCE-CODE-EXEC-CVE-2016-10033.html"><strong>vzdáleně
spustit kód</strong></a>. Chyba už byla opravena v lednu tohoto roku, takže
pokud pravidelně a automaticky aktualizujete, tak se vás netýká.</p>
<p id="wordpress-reset-hesla"><strong>Všechny verze WordPressu</strong>
(včetně aktuální 4.7.4) obsahují poměrně těžko zneužitelnou chybu,
díky které by šlo <a
href="https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html"><strong>získat
odkaz na reset hesla</strong></a>. Spočívá ve změně hlavičky
<code>Host</code>, jejíž hodnota se promítne do
<code>$_SERVER['SERVER_NAME']</code> a pak i do e-mailové hlavičky
<code>From</code>. Mohlo by se stát, že po odmítnutí zprávy cílovým
poštovním serverem bude e-mail s odkazem na nastavení nového hesla zaslán
zpět na adresu uvedenou ve <code>From</code>, což je hodnota dodaná
útočníkem.</p>
<p id="intel-amt">Webový interface, který je součástí procesorů od Intelu,
resp. <strong>Intel <abbr
title="Active Management Technology">AMT</abbr></strong> <a
href="https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution-bug-that-lurked-in-cpus-for-10-years/">má
od roku 2011 boží chybu</a>. Pro přihlášení používá metodu HTTP Digest
a <strong>pro přihlášení uživatele <em>admin</em> stačí poslat prázdný
<em>digest</em></strong>. Připomnělo mi to PayPal, kdy k obejití 2FA
stačilo z formuláře <a
href="https://henryhoggard.co.uk/blog/Paypal-2FA-Bypass">odebrat políčka pro
zadání odpovědí na bezpečnostní otázky</a>. Výrobci hardware <a
href="https://www.ssh.com/vulnerability/intel-amt/">již plánují opravy</a>,
do té doby AMT vypněte, pokud ho používáte.</p>
<h2 id="nove-verze-a-vlastnosti">Nové verze a vlastnosti</h2>
<p id="phpass">Nová verze <strong>knihovny pro hashování hesel
v PHP</strong> <a
href="http://www.openwall.com/lists/announce/2017/05/07/1">phpass 0.5 podporuje
PHP 7</a>. Pokud ji doposud nepoužíváte, tak ani
<strong>nezačínejte</strong>, nativní PHP funkce <code>password_hash()</code>
a <code>password_verify()</code> jsou vhodnější. Tyto funkce jsou dostupné
až od PHP 5.5, ale některé projekty musí podporovat i starší verze PHP.
Pro ně je tato knihovna, používá ji například i WordPress, ačkoliv <a
href="https://www.michalspacek.cz/prednasky/jak-zlepsit-zabezpeceni-ctvrtiny-celeho-webu-wordcamp/ukladani-hesel">ne
úplně nejlépe</a>.</p>
<p id="signal-posilani-souboru">Šifrovaný komunikátor <strong>Signal</strong>
umožnil <a
href="https://twitter.com/whispersystems/status/859125874901135360"><strong>posílání
jakýchkoliv souborů</strong></a>.</p>
<p id="android-o-webview">V další velké verzi <strong>Androidu</strong>
(Android O) poběží <a
href="https://android-developers.googleblog.com/2017/03/first-preview-of-android-o.html"><strong>WebView
v sandboxu</strong></a>.</p>
<h2 id="uniky-dat">Úniky dat</h2>
<p id="antipublic-exploitin">Troy Hunt nahrál do <a
href="https://haveibeenpwned.com/"><strong>Have I been pwned?</strong></a> <a
href="https://www.troyhunt.com/password-reuse-credential-stuffing-and-another-1-billion-records-in-have-i-been-pwned/">data
ze seznamů nazvaných <em>antipublic</em> a <em>Exploit.in</em></a>. Oba
<strong>seznamy už vznikly před nějakou dobou</strong> a <strong>obsahují
data z různých služeb i předchozích úniků</strong>. Pokud se v nich
najdete a chtěli byste znát i heslo, které je v seznamech uvedeno, tak si
budete ta data muset stáhnout a podívat se. Hesla jsou v nich uvedená
v čitelné podobě.</p>
<h2 id="utoky">Útoky</h2>
<p id="ss7">Němečtí mizerové využívají chyby protokolu SS7 k <a
href="https://arstechnica.com/security/2017/05/thieves-drain-2fa-protected-bank-accounts-by-abusing-ss7-routing-protocol/"><strong>získávání
kódů ze SMS</strong> a následnému luxování bankovních účtů</a>. SMS
pro účely 2FA je nevhodná, o dalších důvodech jsem psal v článku <a
href="https://www.michalspacek.cz/kam-zmizel-druhy-faktor-ze-sms-zprav">Kam
zmizel druhý faktor ze SMS zpráv</a>. Jen tak mezi námi, SMS je nevhodná
skoro na všechno, pro posílání zpráv použijte raději třeba výše
zmíněný Signal.</p>
<p id="oauth-phishing">Objevil se <em>OAuth phishing</em>, tedy
<strong>zákeřná aplikace</strong>, která požaduje <strong>přístup
k vašemu Google účtu, ale nechce přímo heslo</strong>. Tato se jmenovala
„Google Docs“ a <a
href="https://www.theverge.com/2017/5/3/15534768/google-docs-phishing-attack-share-this-document-with-you-spam">chtěla
přístup k e-mailu a ke kontaktům</a>. Aplikace, kterým jste dali přístup
si zkontrolujte a pročistěte, odkaz na seznam povolených aplikací pro <a
href="https://myaccount.google.com/permissions">Google</a>, <a
href="https://www.facebook.com/settings?tab=applications">Facebook</a> a <a
href="https://twitter.com/settings/applications">Twitter</a>.</p>
<h2 id="soukromi">Soukromí</h2>
<p id="ultrazvuk-android"><strong>234 aplikací pro Android</strong> neustále
poslouchá a čeká na <strong>ultrazvukový signál</strong>, aby <a
href="http://christian.wressnegger.info/content/projects/sidechannels/2017-eurosp.pdf">mohlo
uživatele za nějakým účelem <strong>sledovat</strong></a>.</p>
<h2 id="sbohem-a-satecek">Sbohem a šáteček</h2>
<p id="openssh-ssh1"><strong>OpenSSH</strong> bude umět už jen SSHv2, <a
href="http://undeadly.org/cgi?action=article&sid=20170501005206">podpora
zastaralého protokolu <strong>SSHv1 byla odstraněna</strong></a>. Mohlo by se
to dotknout některých starších síťových zařízení.</p>
<p id="silex13">Mikroframework Silex 1.3 <a
href="https://github.com/silexphp/Silex/commit/004f924fda9faabe2988c52453fa9e294a2a9a7c">už
není dále vyvíjen</a>, přejděte na verzi 2.</p>