Zákaz používání mobilních telefonů a dalších elektronických komunikačních zařízení ve školách, jehož uzákonění navrhli jako poslanci premiér Andrej Babiš (ANO) a ministr školství Robert Plaga (za ANO), dnes podle očekávání vláda podpořila. Novinářům to oznámil Babiš, podle Plagy byla podpora kabinetu jednomyslná. Účinnost předkladatelé navrhují od 1. září 2027. Podle opoziční ODS je plošný zákaz líbivé populistické opatření namířené proti digitální gramotnosti dětí.
Vládní CERT upozorňuje (𝕏) na zranitelnost ve WordPress Core: CVE-2026-63030 s přezdívkou wp2shell. Zranitelnost typu vzdálené spuštění kódu (RCE) bez nutnosti autentizace umožňuje útočníkovi spouštět libovolný kód prostřednictvím endpointu WordPress REST API Batch. Ke zneužití není vyžadován platný uživatelský účet ani interakce uživatele. Úspěšné zneužití může vést ke kompletnímu kompromitování webové stránky a souvisejících dat. Zranitelnost postihuje verze WordPress 6.9.0 až 6.9.4 a 7.0.0 až 7.0.1.
Evropská komise (EK) vyměřila čínskému internetovému prodejci AliExpress pokutu 550 milionů eur (13,3 miliardy korun) za porušení povinností vyplývajících z nařízení o digitálních službách (DSA). Platforma podle EK řádně neposuzovala a neomezovala rizika související s prodejem nelegálních, nebezpečných nebo padělaných výrobků na svém internetovém tržišti. Komise zároveň firmě nařídila přijmout nápravná opatření. Podle AliExpressu je pokuta nepřiměřená.
Ruffle, tj. open source emulátor Flash Playeru napsaný v Rustu, byl vydán ve verzi 0.4.0. Ke stažení je také na Flathubu. Přímo ve webovém prohlížeči lze vyzkoušet online dema nebo vlastní swf soubory.
HollowByte je zranitelnost typu Denial of Service (DoS) v kryptografické knihovně OpenSSL. Útočník může odesíláním škodlivého payloadu o velikosti pouhých 11 bajtů zaplnit paměť serveru. OpenSSL před ověřením dat vyhradí nepřiměřený blok paměti (až 131 KB). Server pak čeká na data, která nepřišla. Zranitelnost je opravena ve verzích OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 a 3.0.21.
Ve španělské A Coruñě probíhá GUADEC 2026, tj. letošní konference vývojářů a uživatelů desktopového prostředí GNOME. Videozáznamy přednášek jsou k dispozici na YouTube.
Společnost Collabora ve spolupráci s Valve vyvíjí Holo Core, tj. port Arch Linuxu pro ARM64 procesory (AArch64), který bude pohánět VR headset Steam Frame. Pro testování Arch Linuxu pro AArch64 jsou k dispozici binární balíčky, zdrojové kódy i kontejner pro Docker nebo Podman.
Mikroprocesor Zilog Z80 byl oficiálně uveden na trh před 50 lety, tj. v červenci 1976. Výroba mikroprocesoru skončila v roce 2024.
Výzkumníci ze společnosti ESET objevili 11 zapomenutých UEFI shim zavaděčů, které byly podepsány společností Microsoft, a které umožňují útočníkům obejít ochranu UEFI Secure Boot na většině zařízení. Microsoft je zneplatnil (přidal jejich hash do databáze dbx) v rámci aktualizace Patch Tuesday dne 9. června 2026. Uživatelé Linuxu mohou databází aktualizovat pomocí LVFS. Ověřit zneplatnění zavaděčů lze pomocí skriptu uefi-dbx-audit. Jedná se o CVE-2026-8863 a CVE-2026-10797.
pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
nonssl-mitm. Nový. Lepší. Nyní ještě krémovější. Navržený gynekoložkou. Bez odklikávání certifikátů.
Útok jsem pracovně nazval nonssl-mitm, protože se v podstatě jedná o (dočasné?) vyřazení SSL. Pokud jsem pouze znovuobjevil Ameriku, omlouvám se
. Pokud je to něco úplně nového, nazývám zde popsané skutečnosti Jendovým útokem
(něco jako je Kaminského útok).
Zde popsané principy, otvory, perforace a deflorace jsou vymeditovány pouze teoreticky a zkoušel jsem je pouze doma. Není mým údělem vykrádat přihlašovací údaje k účtům, nýbrž pouze ukázat, zda a jak to jde. Nenesu zodpovědnost za využití, použití, zneužití, vyvezení, dovezení či provezení zde popsaných praktik. Zkoušíte na vlastní risiko.
Mnoho bankovních i nebankovních (freemaily, komunitní portály :-P, datové tamty, no, jak se to jmenuje...) institucí používá nějaký způsob šifrovaného spojení, řekněme, že HTTPS. Mnohé z nich (freemaily, komunitní portály :-P) ho používají z výkonnostních důvodů pouze pro přihlášení. Podívejme se, jak vypadá takový přihlašovací formulář na jednom takovém náhodně vybraném portále.
<form action="https://www.abclinuxu.cz/Profile;jsessionid=gztm0pfw2jpa" method="POST"> <input type="text" name="LOGIN"> <input type="password" name="PASSWORD"> <input type="submit" name="finish" value="Přihlásit"> </form>
(redakčně kráceno)
Tento formulář ke klientovi doputoval po nezabezpečeném HTTP. A teď si představte, že mezi klientem a Stickfishím serverem sedím útočník, který odpověď serveru modifikuji. Asi takto:
<form action="http://www.abclinuxu.cz/Profile;jsessionid=gztm0pfw2jpa" method="POST"> <input type="text" name="LOGIN"> <input type="password" name="PASSWORD"> <input type="submit" name="finish" value="Přihlásit"> </form>
Data z tohoto formuláře budou odeslána nezabezpečeným spojením. Přejete si pokračovat? [Ano] [Ne] [ ] Zobrazit příště toto varování
Na rovinu - když se vám toto zobrazilo poprvé, třeba před dvěma lety, na libovolné stránce, určitě jste to odklikli. A určitě jste poprosili prohlížeč, aby vás už příště neotravoval. Nebo toto varování snad máte zapnuté? Hlasujte v anketě.
Takže uživatel vyplní heslo a nic zlého netuše odešle a vy ve svém Wiresharkovi paket zachytíte.
Banky obvykle pošlou dopis končící
V prvním případě se posílá HTTP 302 nebo HTTP 200 s metou refresh v hlavičce na https variantu. Ano, i tyto požadavky můžeme cestou modifikovat.
Například tolik oblíbené datové schránky, o kterých ještě bude řeč dále, (sken dopisu) mají na http://datoveschranky.info/ odkaz na https://www.mojedatovaschranka.cz/. Tož, z odkazu na stránce datoveschranky.info se omylem cestou ztratí "s"...
Většina webů (asi všechny kromě některých freemailů a AbcLinuxu :-P) nemá HTTP variantu. Každý požadavek oběti na port 80 serveru tedy musíme vždy chytit, zašifrovat, poslat na server přes HTTPS, odpověď rozšifrovat a poslat zpátky oběti přes HTTP. Oběť si tedy prostě normálně kliká po rozhraní své schránky a v adrese vidí http://. Ale kolik BFU se dívá do adressbaru.
Technickou realizaci tohoto jsem neřešil (jsem teoretik!), ale osobně bych si spustil lighttpd a pomocí modulu rewrite nasměroval všechny požadavky na jeden bashový skript. Ten by si mohl vypreparovat požadavek, pomocí wgetu ho poslat přes https serveru a staženou odpověď by vrátil webserveru k odeslání zpátky klientovi. Ale to už se blížíme k technickému zpracování...
Zase na druhou stranu, ve většině případů nám stačí podvrhnout přihlašovací stránku, takže si u nás na serveru vytvoříme prostě její kopii a action toho formuláře necháme směřovat na původní adresu.
Příklad útoku popíšu na datových schránkách. Ano, už zase rýpu. Víte, díky datovým schránkám jsem začal tuto bezpečnostní problematiku studovat. Alespoň k něčemu jsou dobré 
Jak si sednete mezi klienta a server neřeším. Buď máte router po cestě, nebo použijete třeba arpspoof.
Vždycky jsem si myslel, že se to jmenuje transparentní proxy, ale dokumentace Privoxy mě přesvědčila o opaku. Jo, takže budeme používat Privoxy, protože s ní prostě umím.
Prvně nařídíme Privoxy, aby reagovala s požadavky, které vedou skrz ni.
accept-intercepted-requests 1
Potom budeme chtít, aby poslouchala na všech rozhraních na portu 80
listen-address :80
Dále vložíme potřebné filter a action soubory. Já jsem je nechal pojmenované user.*, protože v Debianu je to tak default. Ale jak se rozhodnete, to je na vás.
filterfile user.filter actionsfile user.action
Nyní nadefinujeme potřebný filtr. Můžete si o tom přečíst článek tady na ABC. Svůj filtr jsem pojmenoval nonssl-mitm. Přiznám se, že jsem dost prasil - místo, abych podrobně sledoval cestu "skutečného" požadavku (jsou tam asi tři různá přesměrování), jsem to rovnou natvrdo nasměroval na login.mojedatovaschranka.cz.
FILTER: nonssl-mitm s/href="https:\/\/www.mojedatovaschranka.cz\/portal\/ISDS\/"/href="http:\/\/login.mojedatovaschranka.cz\/"/ig
Zapneme filtr pro doménu datoveschranky.info
{+filter{nonssl-mitm}}
datoveschranky.info
A nakonec nastavíme forward subdomén mojedatovaschranka.cz na náš servřík. Já používám LigHTTPd a poslouchá mi na localhostu na portu 8111.
forward .mojedatovaschranka.cz localhost:8111
Do documentrootu svého webservříku jsem umístil věrnou kopii přihlašovacího formuláře k datové schránce. Action jsem mu nechal na skutečnou adresu https://login.mojedatovaschranka.cz/nidp/idff/sso?sid=4 a zkusil jsem se "přihlásit". Povedlo se.
Co si případný útočník umístí do této falešné přihlašovací stránky, to nechám na něm. Znovu připomínám, že zneužití cizí datové schránky je trestné.
Příprava takovéhoto útoku je složitější, ale na rozdíl od "obyčejného" podvrhování certifikátu se uživateli nezobrazí ani upozornění o špatném certifikátu. Nepomůže mu ani, když si nainstaluje a ověří certifikát PostSigna.
Řešení? Nebuďte líní a zadávejte do svého prohlížeče celou adresu, včetně https://. Nevěřte tomu, že když zadáte jenom mojedatovaschranka.cz a prohlížeč vám před to doplní http://, přesměruje vás to na https:// variantu. A když už, tak si alespoň zkontrolujte, jestli vás to přesměrovalo a zobrazte si detaily certifikátu.
Pokud jsem někde udělal chybu či jsem něco napsal nejasně, neváhejte využít komentářů.
Před domem teď zastavilo několik aut s černými skly a vylézají z nich nějací zakuklenci.
Tiskni
Sdílej:
.
. Nejlepší by bylo, kdyby prohlížeč kromě „už nikdy nevarovat“ měl ještě možnost „už nikdy nevarovat pro tuto doménu“.
V tomhle si nedělej žádné iluze, např. náš studijní systém trpí podobnou chybou – přijdeš na úvodní stránku, ta je nešifrovaná, klikneš na „Přihlásit se“ a to tě hodí na stránku s HTTPS basic autentizací (tzn. generické okno webového prohlížeče) a tam už zadáváš heslo – obávám se, že většina uživatelů by jméno a heslo vyplnila, i kdyby útočník-uprostřed upravil titulní stránku, aby odkaz vedl na nešifrovanou podvodnou stránku. Když jsem upozorňoval autory toho systému, že by bylo lepší, kdyby se šifrování započalo o stránku dříve, než uživatel posílá heslo, případně se použila formulářová autentizace (místo basic), přišlo jim to moc práce.
Ona ta integrita bez identifikace druhé strany nemá moc smysl – pak máš jen jistotu, že s někým komunikuješ a nikdo není mezi vámi, kdo by tu komunikaci narušoval, ale už nevíš, jestli ten někdo je skutečný server, kam se chceš připojit nebo útočník.
Něco mezi HTTP a HTTPS může být, když hesla hashuješ na straně klienta. Ovšem je to jen ochrana proti odposlechnutí (např. po nechráněném wifi), ale ne proti pozměnění (MIM), protože když může někdo pozměňit ty stránky, tak vypne hashování, uživatel nic nepozná (za HTML zdroják se nedívá) a heslo se odešle v čistém tvaru. Případně to jde zkombinovat s HTTPS a mít to jako druhou úroveň zabezpečení (někdo např. podvrhne certifikáty, odposlouchává a nakonec zjistí, že odposlechl jen náhodné hashe hesel).
Příprava takovéhoto útoku je složitější
Kdybys tam vrazil jako proxy třeba takový nginx, tak je to přepisování snadné (https → http).
it's very beautiful and encouraging song!
Down with Exxon Mobil,Total,Chevron,BP and
Royal Dutch Shell!!!
Russia i Gazprom,ypa!

Je to podobné sslsniff-u. Jenom sslsniff navíc umí podvrhovat falešné SSL certifikáty, které ale projdou ověřením SSL certificate chain. Má na to několik metod: