Vojtěch Pavlík: Meltdownem to neskončilo. L1TF, POP SS, TLBleed a další
Současné procesory intenzivně využívají takzvané spekulativní vykonávání. Tím se lépe využívají zdroje v procesoru, který je schopen při vykonávání jedné instrukce připravovat další krok. Problémem jsou skoky, protože není možné jednoduše zjistit další instrukci.
Procesor k tomu má jakési „orákulum“, které se podle předchozích výsledků skoků stačí odhadnout, kam bude kód pokračovat. Pokud se trefí, má práci hotovou ve chvíli, kdy je potřeba. Pokud se netrefí, práce se zahodí. Není to na škodu, protože nás to nic nestojí. Vždycky se to predikcí může jen zlepšit.
Moderní procesory jsou schopny predikovat až 300 instrukcí napřed a systém učení se stále zlepšuje, aby byl odhad co možná nejpřesnější.
Dalším způsobem, jakým se zrychluje práce procesoru, je keš. Keš v procesoru je velmi drahá, i nejnovější procesory mají L1 keš o velikosti 32 KB.
Kromě samotných dat je potřeba mít uloženou také informaci o tom, co v paměti je a dá se použít pro zrychlení práce.
Už na začátku letošního roku se objevil útok Spectre v1, který tyto principy zneužívá. Nejprve vytvoříme smyčku, která naučí prediktor, že se vždycky skáče na začátek smyčky.
Zároveň zaplníme keš vlastním smetím, abychom z ní vymazali veškerá data linuxového jádra. Poté zavoláme jadernou funkci a snažíme se přečíst z paměti informaci, kterou by nám jádro za normálních okolností nikdy nedalo. V rámci spekulativního vykonávání se obsah paměti načte, ale poté procesor zjistí, že celá spekulace byla chybná a všechny stopy zahladí.
Ovšem načtená paměť je v keši a ta funguje nezávisle, proto si pak útočník může změřit, jak dlouho mu trvá načtení dané stránky a podle toho zjistí, zda je v keši.
Tímto postranním kanálem si pak může postupně přečíst celou paměť. V jádře ale musí být vhodná funkce, kterou je možné takto zneužít.
Proto vývojáři provedli statickou analýzu kódu a všechny zneužitelné funkce upravili tak, aby byly bezpečné. To jsme všechno udělali, ztratili jsme nějaký výkon, ale všechno je v pořádku.
Ovšem existuje řada dalších cest, jak skryté mechanismy procesoru zneužít.
Procesor například implementuje další predikční jednotku, která sleduje návraty z funkcí. Když někam skočíme, musíme také vědět, kam se vrátit.
Uvnitř procesoru se pak udržuje rychlý zásobník skoků, ve kterém je uloženo šestnáct posledních adres pro návrat z nejnovějších skoků. Vytvoříme funkci, která rekurzivně zavolá šestnáctkrát sama sebe a pak vyskočí pomocí GOTO.
Tím jsme zaplnili zásobník daty o skocích, ze kterých se už nikdy nevrátíme.
Poté jádro spustí další proces, který se stane obětí a při prvním RET se spekulativně skočí na námi připravenou adresu. Tohle ale není tak nebezpečné, protože si nemůžeme přesně vybrat index a zajistit, kam přesně se pak skočí. Dá se to vylepšit, ale už to není tak účinné.
Oprava probíhá tak, že se tabulka RSB vyprázdní před každým skokem do jádra. Opět nás to stojí výkon, jako všechno.
Další zajímavý útok zneužívá líné přepínání jednotky pro práci s plovoucí čárkou (FPU). V dobách procesorů 386 totiž existoval samostatný matematický koprocesor 387, který byl k hlavnímu CPU připojen pomocí relativně pomalé sběrnice. Přenášet neustále stav všech registrů touto sběrnicí by bylo velmi pomalé.
Většina procesů ovšem s plovoucí řadovou čárkou nepracuje, takže není potřeba koprocesor do akce zapojovat. Existuje tedy flag, který při použití koprocesoru vyvolá výjimku a procesor pak ví, že při přepnutí kontextu je potřeba stav koprocesoru uložit. Data tedy přenášíme jen v případě, že koprocesor někdo používal, to přineslo obrovské zrychlení.
Při spekulativním vykonávání se tento bit opět nekontroluje, takže jsme schopni si přečíst obsahy registrů jiných procesů. To není tak nebezpečné, ale pokud v registrech budou například prvočísla, už nám to pomůže dostat se k privátnímu klíči.
Oprava se provádí tak, že jádro při každém přepnutí procesů uloží stav koprocesoru. Naštěstí to Intel už dnes umí velmi rychle, takže nás to už nestojí tak velký výkon.
Používají se k tomu moderní instrukce FXSAVE a FXRSTOR.
Jeden z nových útoků využívá také velmi staré instrukce pro přepínání zásobníků, při jejichž použití jsou zakázána přerušení. Útočník si nejprve zapne krokování kódu a poté uprostřed přepínání zásobníků zavolá syscall a skočí do jádra.
To se opět dá na úrovni jádra ošetřit, zjistíme, jestli k přerušení došlo s uživatelského prostoru a ošetříme to. Procesor je ale tak složitý, že některé kombinace instrukcí prostě nečekáte a dokáže vás překvapit instrukce z roku 1981.
Další útok zneužívá takzvaného hyper-threadingu, který dokáže lépe využít některé části procesoru. Vytváří dvě virtuální jádra, která ale sdílejí některé části skutečného procesoru, včetně L1 keše. Útok na tento systém představil Percival už v roce 2005, ale šlo o poměrně komplikovanou věc, která nebyla příliš dobře využitelná.
Procesor kvůli rychlé práci s virtuální pamětí používá takzvanou TLB (Transaction Lookaside Buffer), což je tabulka pro rychlé vyhledávání adres ve fyzické paměti. Nedávno byl oznámen útok TLBleed, který vylepšuje Percivalův útok a zneužívá sdílenou TLB k odhadování toho, co běží na vedlejším jádře.
Útok je ještě slabší, protože je v praxi neproveditelný. Proto jsme se na jeho řešení vykašlali, jako všichni.
Když procesor přepíná tabulky virtuálních paměti, stojí ho to poměrně dost času. Proto byl vymyšlen takzvaný supervisor bit, který určuje, zda do dané stránky může běžný proces.
Umožňuje to namapovat paměť jádra do paměti procesu a znepřístupnit ji. Když pak proces volá funkce jádra, nemusí se přepínat kontexty a šetříme výkon. To je dobrý nápad, ale pak se ukázalo, že ve spekulativním režimu se bit nekontroluje.
Tím vznikl útok Meltdown, který je notoricky známý.
Existuje však ještě další bit, který ukazuje, zda je daná paměťová stránka ve fyzické paměti nebo je odswapovaná. Útok L1TF (Foreshadow) staví opět na tom, že se daný bit při spekulaci nekontroluje, takže je při útoku možné načítat cizí paměťové stránky. Problém je to zejména ve virtuálním prostředí, protože procesor nekontroluje, ve kterém virtuálním prostředí se právě nachází. Můžeme v jednom virtuálním stroji měnit nastavení tabulek a vyčítat postupně obsah L1 keše virtuálu, který běžel před námi. Tam je obvykle mnoho důležitých dat.
Oprava spočívá v tom, že se při přepnutí virtuálních strojů pokaždé tabulky vyprázdní. To nás stojí mnoho času, ale je možné hypervizor optimalizovat tak, aby prováděl co nejméně přepnutí.
Problém nastává ve chvíli, kdy virtuální stroje běží na dvou virtuálních jádrech v rámci hyper-threadingu. Hypervizor pak nemá možnost tyto sdílené tabulky čistit, nemá kdy.
Jeden virtuál pak může neomezeně sledovat druhý stroj, protože sdílejí L1 keše. Hostitel s tím bohužel nedokáže nic udělat, jedinou možností je opravdu vypnout HT, což znamená u moderních procesorů propad o 20 až 50 % výkonu.
Bolí to zejména cloudové poskytovatele, kteří musí kvůli tomuto problému zdvojnásobit kapacitu.
Tomáš Chvátal: budoucnost distribuce software v Linuxu
Všechny linuxové distribuce využívají nějaký způsob balíčkování, ale dělají to i další systémy: Android, iOS, dokonce i Windows 10. Další možností je používání moderních programovacích jazyků, které mají vlastní balíčkovací systémy.
Příkladem je CPAN (Perl), PyPi (Python), Cabal (Haskell), npm (JavaScript) a další. Nechrání vás ale před problémy měnících se verzí, což za vás distribuce vyřeší.
Tvůrci balíčků v distribucích musí vyřešit testování, kompilovat různé části software dohromady, vybrat závislosti, zajistit poinstalační konfiguraci a nakonec se starat o aktualizaci toho všeho. Z pohledu uživatele jde o archiv souborů, které se vám nainstalují na disk. Uživatele zajímá jen to, že se něco rozbalí na disk a bude to fungovat.
Zajímat by ho ale zároveň mělo, že balíček je aktuální, je digitálně podepsaný, poskytuje úvodní konfiguraci a umí migrovat mezi verzemi. Když budete aktualizovat několik let starý systém na nový, mělo by se to s trochou dobré vůle podařit.
S balíčkováním začala distribuce Slackware, která ale vytvořila monolitickou instalaci, jednotlivé soubory se pak rozdělily do archivů a ty se distribuovaly uživatelům. Jakákoliv chyba v systému ovlivnila všechny balíky a uživatele. Zároveň chyběla jakákoliv podpora závislostí.
Velkým krokem vpřed byl balíčkovací systém RPM, který sice také tvoří především sada souborů k instalaci, ale konečně bylo možné přidat také metadata.
RPM obsahuje také standardní způsob, jak balíček popsat a vytvořit. Přináší to ale nový problém, protože umí sice závislosti zapsat, ale už se o ně neumí starat.
Potřebujeme tedy správu repozitářů a nástroje pro automatické stahování a instalaci balíčků. Zároveň bylo možné konečně kompilovat mimo běžící systém v nějakém specializovaném prostředí.
Instalátor měl ale problém v tom, že jeho práce byla poměrně pomalá, trvalo i několik minut, než dokázal vyřešit závislosti a balíčky nainstalovat. Proto jsme se rozhodli to celé přepsat a vytvořili jsme libsolv a zypper.
Knihovna libsolv je dnes používaná na všech distribucích používajících RPM. Zrychlilo se to tak, že se celý výpočet provede za několik sekund.
Dalším krokem bylo napsání openSUSE Build Service, kde si každý uživatel může vytvořit svůj účet a sestavit si balíčky pro svou distribuci. Jednotliví uživatelé jsou pak odděleni ve virtuálních strojích. Dnes obsahuje přes 56 tisíc projektů, skoro půl milionů balíčků a 85 tisíc repozitářů.
Celá farma se skládá z 1200 velmi rychlých serverů s alespoň osmi procesorovými jádry.
Kromě samotného balení software je potřeba zajistit také testování všech balíčků. Proto vznikl nástroj openQA, který dokáže automatizovaně instalovat a testovat software, simulovat uživatele a vrátit výsledky. Výrazně to zrychluje práci, protože například před vydáním bezpečnostní opravy je potřeba provést hodně testů.
To je minulost a současnost balíčkování, dále se přednáška věnovala budoucnosti.
V případě RPM nejsou v plánu příliš velké změny, ale čekají nás například booleanovské závislosti, zrychlení vnitřních procesů či vylepšení linteru. Bohužel tyhle věci se prosazují velmi pomalu, máme to napsané, ale pro nasazení musíme počkat, až to budou podporovat i starší verze distribucí.
Linuxovým světem se dnes šíří vlna nových balíčkovacích systémů, které dokáží vytvářet jednotné balíčky pro všechny distribuce a tím připravit stabilní prostředí napříč systémy. Ty dokáží dodat nejnovější software do starých distribucí, snaží se řešit problémy se závislostmi na balíčcích v systému nebo umožnit instalaci více různých verzí daného software. Nejrozšířenějšími projekty v tomto směru jsou Flatpak, Snap a Appimage.
Flatpak je vyvíjen v rámci projektu Freedesktop.org, dokáže sdílet knihovny mezi flatpaky a nabízí sandboxing. K dispozici je i prověřený repozitář FlatHub, na které jsou k dispozici zkontrolované balíčky.
Proti tomu Snap vyvíjí Canonical a využívá snapshoty v souborovém systému squashfs. Aplikace nedokáží sdílet soubory, takže si balíček musí nést všechny knihovny, které chce využívat.
Appimage připojuje obraz aplikace pomocí FUSE – jeden soubor obsahuje jednu aplikaci. Nenabízí ale sandboxing.
Samotná myšlenka celého principu takového balení je sice dobrá, ale přináší nové problémy. Bezpečnost například najednou závisí na někom jiném a tvůrce distribuce nemůže ovlivnit, že jsou všechny distribuované aplikace bez bezpečnostních děr. To dokáže dobře zajistit Google a Apple, ale malý projekt většinou nemá možnost dělat dostatečně dobrý code review.
Distribuce také velmi často chrání uživatele před šílenými změnami, které tvůrci rádi zavádějí. Balíček systemd má například ve SLES 12 asi 2500 patchů. Dodáváme něco docela jiného než je v upstreamu.
Technicky vzato jsou tyto nové balíčky vlastně kontejnery, které jsou velmi vhodné pro rychlé nasazení nového software. Při testování je například možné velmi rychle startovat nová testovací prostředí, která jsou od sebe navíc velmi dobře izolovaná. Je tak možné provozovat například starý systém, který je bezpečně uzavřený ve svém kontejneru a v případě úspěšného útoku není ohrožen zbytek infrastruktury.
Kontejnery mají ale zase nevýhody v tom, že je potřeba opravovat bezpečnostní chyby na mnoha místech a musíte věřit, že je správci opravují. Když navíc aktualizuji, musím předělat všechny image, aby chyba nebyla v žádném z nich. Ve výchozím stavu není tahle věc nebezpečná, jde jen o to, jak to lidé používají.
Petr Stehlík: pokročilé bootloadery pro AVR
AVR je jméno rodiny 8bitových mikrokontrolerů, které se nacházejí například v deskách Arduino Uno. Pořád to jsou procesory na mnoho účelů nejlepší a nejjednodušší. Prakticky nic nepotřebují, stačí přivést napájení a fungují.
Standardně se programování provádí přes ISP (ICSP) pomocí šestipinového konektoru, k tomu je ale potřeba specializovaný programátor. Existuje i vysokonapěťové paralelní programování, kterým je možné opravit větší problémy způsobené špatným programování. Třetí možností je použití sériový port s pomocí bootloaderu.
V procesoru jsou pojistky (fuses), které nastavují parametry mikrokontroleru. Tím můžete nastavit, jak se celý procesor chová. Programování se provádí pomocí utility avrdude.
K programování je možné použít i druhé Arduino, které může sloužit jako programátor jiného Arduina.
Bootloader je nainstalován na konci standardní 32KB paměti. Pokud správně nastavíte pojistky, Arduino neskočí na začátek paměti, ale až do míst, kde je bootloader. Původní bootloadery měly 2KB, ale pak přišel člověk, který napsal Optiboot a ten se vejde do 512 bytů.
Standardní bootloader umí jen přijmout program a zapsat ho do paměti, můžete po něm ale chtít podstatně více věcí, proto vznikly alternativní bootloadery.
Můžete s nimi například zapisovat do Flash stejně jako do EEPROM. Běžný program nemůže do Flash paměti z bezpečnostních důvodů zapisovat, ale existuje trik, kterým je to možné zařídit.
Aplikace pak skáče do bootloaderu, v jehož oblasti je možné do Flash zapisovat. Tím se obejde kontrolní mechanismus, což může být pro někoho velmi zajímavá věc.
Velmi zajímavým bootloaderem je One Way Loader (OWL). Podívejte se na to, je to úplný programátorský masterpiece.
Dokáže například pracovat se zašifrovaným firmwarem a dokáže to navíc po jednom jediném datovém drátu. One Way znamená komunikaci jen jedním směrem, vůbec není implementován zpětný kanál.
Data je možné dovnitř nasypat mnoha různými zařízeními: RS232, RS485, ale i přes zvuk, světlo nebo magnetizmus. Nový firmware můžete zablikat na fotorezistor pomocí LEDky. Je to úžasné pro malá zařízení, do kterých se nevejdou šestipinové konektory.
Při nasazení OWL se nejprve vygeneruje zavaděč, vypálí se do paměti procesoru a nastaví se interní pojistky. Poté se zapíše firmware, který může být i šifrovaný. To se hodí pro ochranu vašeho zařízení, které pak například zloděj nemůže přečíst. Pokud máte v programu například heslo do bezdrátové sítě, není možné ho z paměti získat.
Tomáš Hála: SMTP bezpečně aneb nezapomněli jsme na poštu?
Podle žebříčku Alexa už přes 50 % z milionu největších webů přesměrovává na HTTPS. Hendikep je zatím vidět u malých webů, tam obvykle šifrování lidé nemají potřebu řešit.
V případě pošty je situace hodně jiná, protože v komunikačním řetězci je výrazně více stran. Odesílatel, DNS server, odesílací server, přijímací MX server a pak samotný příjemce.
Řešením by mohlo být používat PGP, klade ale nároky na odesílatele i příjemce. Je tu s námi mnoho let, ale reálně ho používáme jen v konkrétních situacích.
Co ale můžeme jako správci systémů udělat pro běžné uživatele, kteří infrastruktuře nerozumí a spoléhají se na provozovatele e-mailové schránky, že vše nastaví bezpečně?
Pro bezpečnější předávání pošty mezi servery je možné využít protokol TLSA (DANE), který vynutí šifrování SMTP a kontrolu certifikátu. Udělal jsem vlastní statistiku a jen asi 13 % serverů nepodporuje TLS, ale jen asi 1 % validuje TLSA.
Zatímco u webu se v případě problémů s certifikátem objeví uživateli informační hláška, v případě poštovního řetězce se už uživatel nemá možnost se nic takového dozvědět.
K útokům na provoz ovšem v praxi dochází, ať už na úrovni místních poskytovatelů nebo pomocí BGP hijackingu, kdy jsou uneseny celé IP rozsahy serverů.
Protokol TLSA umožňuje efektivní obranu tím, že se do DNS zóny podepsané DNSSEC zveřejní otisk certifikátu. To jednak předává bezpečnou cestou informace o certifikátu, ale zároveň se tím zveřejňuje informace, že server vyžaduje povinné šifrování tímto správným certifikátem. V Česku je už více než polovina domén zabezpečena pomocí DNSSEC, takže by mělo být poměrně snadné TLSA implementovat.
Pro kontrolu TLSA stačí jen DNSSEC validující resolver a zapnout správné volby v SMTP serveru. To je vlastně všechno, je to velmi snadné.
Analogickým protokolem k TLSA je webový HSTS, který také zapíná povinné šifrování důvěryhodným certifikátem. Pokud dojde k chybě, k serveru se nepřipojíte a musíte počkat, až to správce opraví.
Pavel Šnajdr: vpsFree.cz: vyvíjíme vlastní hardware
vpsFree.cz je otevřená organizace a staví na otevřeném software. Dostali jsme se k tomu, že si začínáme vyvíjet vlastní hardware. Vytváříme svobodný software, ale jak mu můžeme věřit, když nemůžeme věřit hardware?
Dodavatelé hardware dnes nedokáží dodat dostatečně otevřený hardware, o kterém víme, co dělá. Do otevřeného hardware musíme stejně nacpat uzavřený firmware, který je vyvíjen pod tlakem a s nedostatečnou kontrolou kvality.
Navíc do hardware je možné dát cílený backdoor a bez detailní dokumentace není možné zkontrolovat, že je vše v pořádku. Začali jsme vytvářet vlastní softwarovou platformu vpsAdminOS a máme kontrolu nad softwarem, chceme mít i kontrolu nad hardwarem.
Navrhnout si vlastní server je obrovský úkol. Cílem je vytvořit hardware, na kterém bude možné hostovat i citlivá data.
Dlouhodobým cílem je mít kompletně otevřený hardware, což není možné udělat rychle. V rozumně dlouhé době jsme schopni zvládnout alespoň částečně otevřený hardware.
Některé součástí zatím budou muset zůstat s uzavřenou částí s binárními bloby. Jde ale o to otevřít alespoň základní debatu.
V rámci projektu by měly vzniknout malé servery, které je možné naskládat do datacentra a použít je v produkci. Jsou potřeba velká procesorová jádra od ARM, která mají mnoho výkonu i na intepretované jazyky používané na serverech. Zbytek desky včetně ethernetu bude implementován pomocí Lattice FPGA s otevřeným designem. Kreslit se to bude v KiCADu, což bude docela sranda.
Konkrétně budou použity procesory NXP LS1046A se čtyřmi jádry Cortex A72 a FPGA Lattice ECP5–5G. Deska bude obsahovat 8 GB RAM na procesoru a hodně síťových rozhraní.
Projekt by měl už v příští rok mít první prototypy, k prvnímu konkrétnímu cíli by se měl dostat během roku 2020. Pokud rozumíte vývoji hardware, přidejte se k nám a pomozte. Potřebujeme otevřený hardware co nejdříve.
Kontakt můžete zanechat na vpsfree.cz/hw. Doufáme, že nejsme jediní, kdo chce otevřený hardware. Nedokážeme to vyvíjet úplně sami, musí to být jednoznačně komunitní snaha.
Michal Špaček: vyhledávejte na netu jako MacGyver
Co by dělal MacGyver, kdyby mu unikla data? Navštívil by web Have I been Pwned, který provozuje Troy Hunt. Jedná se o databázi, do které jsou přidávána hesla z úniků dat. Jde ale jen o veřejně známé úniky. Počítejte vždy s tím, že vaše data unikla.
Je možné si nechat posílat notifikace o nových únicích, které se vás týkají. Stejně tak umí služba po ověření hlídat celé domény.
Hesla se do databáze dostávají například ze služeb, do kterých je možné vložit libovolný textový obsah a odkazovat na něj. Je to místo, kam se jednoduše vloží libovolná informace, včetně databáze hesel.
Například Pastebin má vyhledávací pole, kam stačí zapsat například „.cz“ a velmi rychle najdete spoustu hesel. Některá z nich budou určitě stále funkční.
Nechtěná data se ale na internet dostávají například omylem. Já jsem například otevřel web Souldeeprecordings.com a našel jsem dump celé jejich databáze.
Je možné to ale dělat i cíleně pomocí vyhledávače, kam stačí vložit „Index of“ a najdete spoustu zajímavých věcí. Je možné, že tam budou nějaká zajímavá data.
Uživatelé velmi často používají heslo „heslo“, takže do vyhledávače lze vložit jeho haš a vyhledat stránky, kde se řetězec vyskytuje. V Google můžete zadat také například typ souboru a s filetype:sql nebo txt se dozvíte spoustu dalších podrobností. Tyhle seznamy už jsou v Have I been pwned, ale určitě některá hesla budou pořád fungovat.
Některé certifikační autority mají problémy se zabezpečením a občas vystavují certifikáty neoprávněně. Dokud neexistovalo Certificate Transparency, vládl v této oblasti naprostý chaos. Kdokoliv mohl vystavovat certifikát pro jakoukoliv doménu.
Certificate Transparency zavádí logy, které obsahují všechny vydané a podepsané certifikáty. Dává nám to tedy vhled do toho, co autority vystavují.
Zároveň může prohlížeč ověřit, že byl použitý certifikát v logu zveřejněn.
Logy je ovšem možné také průběžně sledovat a nechat domény v nových certifikátech skenovat na bezpečnostní chyby. Často to bývají nové weby, které ještě bývají špatně zabezpečené. Třeba nový WordPress ještě bez hesla a podobně.
Také se zde dají najít staré weby, o které se už nikdo nestará, ale stáje ještě běží. Stejně jako testovací weby. Správci si například myslí, že o tom webu nikdo neví. Ale jakmile na něj byl vystaven certifikát, už je možné ho najít.
Podle Špačka by proto i phishingové weby měly mít HTTPS. Pokud si pořídí certifikát, dozvíme se o tom a můžeme zasáhnout. Měli bychom tedy chtít mít všechny weby na HTTPS.
Různé služby umožňují automaticky monitorovat nově přidávané certifikáty a sledovat problémové domény.
Dalším problémem je skenování internetu, pomocí nástroje masscan je možné celý IPv4 prostor projít za pět minut. Co ale s IPv6?
Přestože je IPv6 prostor obrovský, je možné živé adresy objevovat například pomocí NTP. Pokud používáte IPv6, váš počítač se ptá na synchronizaci času a podle toho je možné na serveru objevovat živé stroje.
Ty je pak možné automaticky skenovat. Ať máte IPv4 nebo IPv6, budete skenováni. Nebuďte z toho vyplašení, skeny jsou a budou.
Ke získávání dalších informací je možné použít vyhledávač Shodan.io, který dělá skeny internetu a ukládá je do své databáze. Pomocí něj lze například najít otevřené web kamery zadáním řetězce „Yawcam“. Stejně tak je možné hledat obrázky, kde snadno objevíte například vzdálené plochy počítačů nebo záběry z dalších webkamer.
Špaček přímo na přednášce našel dálkové ovládání solárních elektráren nebo web kameru zabírající aktivní RSA token.
Pokud provozujete vlastní aplikaci nebo web a chcete, aby vám lidé podobné chyby hlásili, udělejte jim to co nejjednodušší. Kam hlásit chyby? Klasická podpora asi nechce vědět o úniku dat. Jak najít správné lidi?
Můžete to usnadnit tím, že vytvoříte soubor security.txt a do něj vložíte kontaktní informace.
