Radoslav Bodó, Jakub Urbanec: (Ne)bezpečnost 2023
Jeden z největších zaznamenaných úniků dat proběhl v ICMR Indian Council of Medical Research, který se zabývá například očkováním. Uniklo celkem 815 milionů záznamů, což je neuvěřitelně obrovské číslo. V Evropě by to byla data všech obyvatel.
Společnosti 23andMe uniklo sice na pohled „jen“ 9 milionů účtů, což není tolik, ale jde zase o citlivá data, protože tato společnost provádí testování DNA.
Aby se dokázala celá společnost proti podobným útokům bránit, vznikla ICRI – International Counter Ransomware Initiative. Česká republika se připojila k prohlášení proti platbám výkupného při ransomwarových útocích.
Úniky velmi souvisejí s bezpečností systémů a uživatelů, kteří ty systémy používají.
Dříve jsme považovali procesory za neomylný hardware, který není možné napadnout a když v něm spustíme program desetkrát, dostaneme stejný výsledek. Procesory se ale stávaly čím dál chytřejšími a složitějšími, až se začaly objevovat neočekávané věci.
Od roku 2018 se pravidelně nacházejí bezpečnostní chyby v procesorech.
Do procesoru postupně přibyly například keše a možnost vykonávat instrukce mimo pořadí. Procesory předpočítávají před větvením obě možné cesty, takže jsou připravené v době, kdy k nim program dorazí.
To má ale postranní efekty zejména v keších, což umožňuje útočníkovi přistupovat do paměti, která mu nepatří. Proces se může dívat do paměti operačního systému nebo do paměti jiného procesu.
V současné době jsou hitem postranní kanály ve vnitřních keších, které se používají pro zpracování komplexních instrukcí. Ty jsou dnes implementovány jako software, takže procesor postupně vykonává jednotlivé mikroinstrukce.
Moderní procesory například dovolují zpracovat velké matice dat a výsledek uchovávat v interní paměti, která ale může zůstat částečně naplněná, i když je celý tento komplexní proces zastaven. Je to uvedeno dokonce v dokumentaci.
Chyba Downfall tak umožňuje z této vnitřní paměti vyčíst data jiného procesu, který například počítá šifrovací klíče.
Chyby se objevují nejen v procesorech Intel, ale problémy má i AMD. Útok Zenbleed například staví na tom, že interní registry jsou implementovány ve sdílené paměti, která se průběžně používá k různým účelům. Problém je, že kvůli optimalizaci se paměť nemaže, ale označuje se jako uvolněná. V případě spekulativního vykonávání kódu se ovšem může stav vrátit o krok zpátky. Útočník pak připraví takový stav, kdy se mu podaří získat data z dočasně uvolněné části registru.
V paměti totiž zůstanou data jiného procesu, ke kterým se může útočící proces dostat.
Podobné chyby se nevyhýbají ani procesorům od Apple, ať už verzím A v iPhonech nebo verzím M v Macboocích. Spectre měřil časování zpracování dat, abychom poznali, zda jsou data v keši nebo ne.
Současné operační systémy ale uživatelským procesům nabízejí jen velmi hrubé časovače, což na podobná měření nestačí. Musely se tedy vymyslet nové způsoby, jak zjistit, zda jsou data v keši.
Používají se tedy dvě vlákna, která sdílejí proměnnou. Jedno z nich plní data do keše a měří dobu běhu toho druhého, které spekulativně data z keše čte. Podle rychlosti poznáme, jestli jsou data v keši nebo ne.
Je to složitější, trvá to dlouho, ale i Apple s tím má problém. Potíže se ovšem na jeho platformách týkají jen prohlížeče Safari, ostatní prohlížeče jsou proti chybě chráněny.
Problémy se vyskytují také v různé elektronice, například nizozemská organizace Midnight Blue analyzovala různá zařízení používající komunikační standard TETRA. Část standardu je otevřená, ale zejména šifrovací část je tajná a přestože se tyhle přístroje se vyrábějí už dvacet let, dlouho žádné podrobnosti neunikly.
Jedním ze zařízení je Motorola MTM5400, které se skládá ze dvou částí: procesoru ARM a DSP. Se softwarovou částí je možné komunikovat pomocí AT příkazů, v jejichž zpracování byly nalezeny klasické chyby.
Obě části mezi sebou komunikují vlastním protokolem a software má přímý přístup do paměti DSP. Nemá ovšem přístup ke kódu, který šifrování zajišťuje. Může jen nahrát vlastní data a může si je nechat zašifrovat nebo dešifrovat.
Ukázalo se ale, že DSP je implementován jako jiné procesory a opět bylo možné zneužít postranní kanály a pomocí chybné implementaci keše vyčíst kód. Ten pak bylo možné podrobit analýze.
Ukázalo se, že celý ekosystém obsahuje velmi mnoho zajímavých chyb.
Jednotlivé stanice si například vyměňují náhodná data pro vytvoření šifrovacího klíče. Je možné oběma stranám podvrhnout takové hodnoty, že je pak používána známá hodnota klíče.
Pro generování symetrického klíče se navíc používá zkrácená podoba klíče, takže místo 80 bitů se nakonec používá jen 32 bitů a takové šifrování je možné snadno prolomit.
V SSH byl nedávno objeven útok nazvaný Terrapin, který umožňuje snížit zabezpečení a přejít z bezpečných klíčů na přihlašování pomocí hesla. Na heslo už se dá útočit, nebo pomocí sledování komunikace odhadovat jeho délku nebo jiné vlastnosti.
V systému se glibc stará o mnoho záležitostí, včetně interakce s jádrem a například spouštění nových procesů. Je to taková máma.
Aby bylo možné nastavení knihovny ovládat, existuje proměnná GLIB_TUNABLES, v jejímž zpracování byla objevena chyba, která umožnila přepsat část paměti a navýšit uživatelská oprávnění.
Nedokonalost byla objevena také v systémovém linkeru, který nahrává kód z disku do virtuálního paměťového prostoru procesu. Ten kontroluje, jestli nemá být načten kód ze souborového systému, který je označen jako noexec.
Z takového souborového systému by nemělo být možné spustit žádný kód. Bylo ovšem zjištěno, že je možné vytvořit upravenou binárku, která pomocí relokací vytvoří spustitelný kód o délce až 256 bajtů, což stačí ke spoustě akcí. Tímhle dokážete utéct z klece, která je vytvořená například uvnitř kontejneru.
Petr Adamec: Budování lokální sítě – utrpením k 802.1×
CESNET před časem stěhoval kanceláře do nové lokality a bylo potřeba postavit novou lokální síť. To pro nás byla šance udělat všechno znovu a pořádně.
Taková změna umožňuje napravit nevědomé i vědomé a trpěné nedostatky. Chtěli jsme do věcí zavést řád.
Pomocí při budování sítě byly i nové směrnice, které stanoviny pravidla pro používání sítě.
Hlavním cílem pro správce bylo snížit si množství práce. Abychom rutinně nedělali věci, které se dají dělat rychle a lépe.
V plánu bylo zavést také 802.1×, který se doposud v lokální síti nepoužíval. To umožnilo také zjednodušit konfiguraci přepínačů, která by měla být jednotná a neměnná.
V síti bylo potřeba také podporovat dual-stack, aby byly protokoly IPv4 a IPv6 naprosto rovnocenné. Přístup zvenčí k uživatelským počítačům je umožněn pouze po VPN.
V síti se používají přepínače Catalyst 9300, asi dvacet Wi-Fi AP Cisco, o DHCP se stará Kea a pro VPN se používá eduVPN.
Při nasazení ověřování pomocí 802.1× bylo potřeba rozhodnout, kdo a jak bude ověřován. Je možné se přihlašovat jménem a heslem, ale to při restartu RADIUS serveru zobrazí na Windows přihlašovací dialog a systém se už sám nikdy nepřipojí. Rozhodli jsme se ověřovat pouze zařízení a pouze certifikátem.
Windows v doméně mají vlastní certifikáty a ostatní uživatelé mají k dispozici portál pro generování certifikátů s delší platností. Každé zařízení by mělo mít podle směrnic vygenerovaný vlastní certifikát.
Pro monitoring lokální sítě byl nasazen nástroj Netdisco, který už umí monitorovat i 802.1× a sousedy v IPv6. Objevili jsme jen problémy se synchronizací času, kdy některá zařízení ve flow posílala data s posunutými časovými značkami.
Selže-li z nějakého důvodu autentizace, dostane se počítač do nouzové VLAN, kde je spuštěný captive portál. Uživatel má k dispozici rozcestník s nejdůležitějšími informacemi a formulářem pro generování autentizačních certifikátů.
Michal Růžička: Projekt Secrets
Organizace se obvykle potřebuje vypořádat se sdílením různých tajemství jako jsou hesla, šifrovací klíče, autentizační tokeny, klíče k API a podobně. Zajímá nás to samozřejmě i v kontextu zákonných regulací, takže to řešíte pravděpodobně ve svých organizacích taky.
V plánu bylo pokrýt celý životní cyklus takového tajemství: od generování, přes bezpečné uložení, změnu a užívání, až po bezpečnou destrukci. Uživatelé obvykle recyklují hesla, protože je neumí udržet v hlavě a ne vždy používají správce hesel.
Zároveň je nutné mít možnost vybraná tajemství sdílet mezi správci společné infrastruktury.
Existují nejrůznější klíčenky nebo univerzální správci hesel, což jsou ale často řešení určená pro jednoho uživatele a sama o sobě neumožňují nějak tajemství sdílet. Potřebovali jsme také řešení integrované s institucionálními a infrastrukturními systémy.
Příjemné by také bylo, kdyby některý spravovaný stroj mohl na vybraná tajemství sám dosáhnout. S tím souvisí i automatizace důležitých procesů. Chceme mít možnost automaticky vytvořit například klíč pro API a po nějaké době ho automaticky zase zrušit.
Celé řešení by mělo být také monitorovatelné a auditovatelné. Na místě jsou také obavy ze spolehlivosti a dostupnosti, protože pokud tento důležitý nástroj nepoběží, budeme mít omezenou možnost jeho opravy.
Musí tedy existovat záložní přístup ke kritickým prvkům, které dovolí obnovit funkci systému pro uložení tajemství.
Různé týmy uvnitř organizace dříve používaly také různé typy řešení, někde se používal jeden z mnoha softwarových správců hesel, jinde drželi přihlašovací údaje v hlavě. Po analýze dostupných řešení a jejich vlastností se ukázalo, že žádný z nástrojů nedokáže uspokojit všechny požadavky. Nejlépe dopadl systém HashiCorp Vault. Vyhodnotili jsme ho jako řešení, které chceme nasadit.
HashiCorp nabízí placenou variantu, která ale pro 200 uživatelů vyšla i s akademickou slevou na 2 miliony korun ročně. Museli jsme se tedy dívat výhradně na open-source verzi a vypořádat se s jejími omezeními.
Systém byl nainstalován na dva oddělené clustery: VMware a OpenStack.
Byly identifikovány nejběžnější scénáře použití: sdílení tajemství v rámci týmu, přístup přes SSH, tajemství pro GitLab CI/CD a použití pro RDP na Windows. Uživatelské testování ukázalo, že HashiCorp Vault není příliš intuitivní pro sdílení mezi fyzickými osobami.
Byl tedy nasazen nástroj Passbolt, který zjednodušuje použití Vaultu v týmech.
Společnost HashiCorp přelicencovala své produkty, včetně Vaultu. Vznikla sice svobodná odnož OpenBao, ale zvyšuje to nejistotu při nasazování takového nástroje. Nemusí to nutně znamenat problémy do budoucna, ale nepřidá vám to na klidu.
Milan Čermák: Využití JupyterLab pro interaktivní analýzu nejen kyberbezpečnostních dat
Při analýze incidentů v síti je potřeba posbírat mnoho různých informací, často z velmi různorodých systémů. Problém bývá detekován v SIEM, podrobnosti o serveru jsou v databázi zařízení, incident se potvrdí v tocích a aplikační data jsou v lozích jednotlivých serverů. Byli jsme z toho nešťastní, protože i analýza malého incidentu nám zabere spoustu času, protože je potřeba otevírat spoustu nástrojů.
V datové analytice se typicky používá Jupyter Notebook, což je prostředí, které umožňuje psát analytický kód typicky v Pythonu, dokumentovatelný v Markdownu. Nad tím existuje Jupyter Lab, který dovoluje spouštět a spravovat jednotlivé Notebooky a případně také Jupyter Hub, který nabízí pohodlné uživatelské rozhraní.
Použití Pythonu umožňuje rychlý vývoj metod pro zpracování heterogenních dat a jejich korelaci. Většina databází, služeb a nástrojů má dostupný modul pro Python, nebo umožňuje dotazování skrz API.
Při správném naprogramování je možné provést celou analýzu na jedno kliknutí a nechat ji běžet i několik dní.
Teoreticky tedy máme k dispozici nástroj řešící většinu analytických problémů, ale pokulhává u něj uživatelská přívětivost. Jedním řešením je rozšíření Widgets, které umožňují do projektu přidávat různé grafické prvky, které dovolují proces konfigurovat bez zásahu do kódu.
Dalším pomocníkem je rozšíření Voilà, které umožňuje spustit Jupyter Notebook a zobrazit pouze jeho výstup. Pak už jsme ve stavu, kdy to pro nás začíná být funkční, jsme schopni vše připravit pro správce a analytiky a ti mají k dispozici jen uživatelské prostředí.
Pro jednotlivé služby je pak možné vytvořit patřičné konektory, přičemž uživateli stačí vyplnit autentizační údaje v konfiguračním souboru.
Typický Notebook pak obsahuje vše, co potřebuje analytik při řešené incidentu. Vše je řízeno přes jednoduché vstupy a tlačítka spouštějící akci. Každý krok lze také vysvětlit a zdokumentovat.
Celá analýza je pak proveditelná v jednom prostředí a v rámci jednoho uživatelského rozhraní.
Petr Adamec: Zabezpečení lokální sítě pomocí RTBH
RTBH znamená Remotely Triggered Black Hole a jde o bezpečnostní mechanismus, který se používá k ochraně před distribuovanými útoky. Principem je změnit next-hop a poslat provoz do rozhraní, které veškerý provoz zahazuje.
Princip popisuje RFC 5635.
Požadavkem bylo automaticky zahazovat nežádoucí provoz, ale zároveň propouštět některé konkrétní služby. Chtěli jsme i možnost ručního blacklistu a hierarchických práv, aby si někteří správci mohli chránit určitou část rozsahu.
Uživatelé sami jsou také někdy zdrojem útoků, takže bylo třeba i chránit odchozí směr.
Na hranici sítě je možné použít různé detektory provozu jako fail2ban, FastNetMon, FTAS a prakticky cokoliv dalšího. Komunikují přes API s ExaFS, který je přes exaBGP schopen poslat na routery požadavek na zahození provozu.
Uživatelé pak mají k dispozici webové rozhraní ExaFS a mohou sledovat stav blokací. Pokud mají navíc práva k určitým rozsahům, mohou stanovovat filtrační pravidla.
ExaFS nabízí také API a je možné ho napojit například na systém FTAS. Ten generuje přehledy o událostech v síti a výsledkem je okamžité blokování IP adres, které překračují nastavená pravidla. Další možností je napojení na fail2ban, kdy je možné blokovat provoz v celé síti podle neúspěšných přístupů ke službám.
Tomáš Košňar: Ať nás stroje brání samy
Když v síti přibývá detekčních nástrojů, přibývá zároveň i oznámení o incidentech a s tím přibývá také ruční práce. V určitou chvíli jsme zjistili, že 400 mailů za dopoledne nezvládneme.
Zároveň přibývá konzumentů, s nástroji už nepracují jen síťaři, ale například také bezpečnostní analytici, kteří se také musejí podílet na celém procesu ochrany.
V síti CESNET jsou nasazeny už zmíněné nástroje FTAS a ExaFS. Na hranici sítě se sleduje provoz z vnějších sítí a detekují se například volumetrické útoky, typická agresivní schémata a podobně. Musíme se chovat kompromisně, protože některé typy provozu například z CDN nám nesmějí spustit filtraci.
Pokud je detekován útok, nasadí se opatření podle charakteru anomálie. Je možné nasadit RTBH, BGP FlowSpec nebo přeposlání na externí čističku. Pokud to nestačí a vrací se nám příliš mnoho nechtěného provozu, můžeme nasadit kombinaci různých opatření.
Dalším řešením je komunitní ochrana, kdy je možné oddělit vybranou část uživatelů do samostatné části sítě. Je to vlastně síť v síti a je možné aplikovat opatření na celou tuto oblast na hranici VRF.
Lze tu snadno nasadit RTBH, protože pak platí pro celou společnou síť a data jsou sbírána přímo na hranici této virtuální sítě.
Z perspektivy uživatele jde o podpůrný nástroj, který obvykle pracuje na síťové vrstvě, s malými odbočkami na transportní vrstvu. Na phishing to tedy z principu nefunguje.
Řešení se také snaží útokům předcházet, bránit hledání prostupností, mapování prostoru a podobně. Cílem není detekovat útoky, ale chránit síť a udržet ji v provozu.
Michal Strnad: Co nabízí nové objektové úložiště a co to znamená pro vaše data?
Data jsou alfa a omega všeho a bezpečnostní mechanismy jsou stavěny tak, aby data chránily. CESNET provozuje celou řadu diskových a objektových úložišť. Základem jsou disková pole typu RAID, která jsou odolná proti výpadkům jednotlivých disků.
Dalším používaným úložištěm je pásková jednotka, která má vysokou kapacitu a při dodržení správných podmínek také dobrou skladovatelnost. Nevýhodou je sekvenčnost a omezený počet mechanik, o které se uživatelé přetahují.
Oba přístupy je možné spojit do HSM, tedy Hierarchical Storaege Management. Ten je pro uživatele transparentní a sám podle migrační politiky přenáší data mezi páskami a diskovými poli. Uživatel si musí někdy na data počkat, takže mu může dojít trpělivost.
CESNET provozuje také objektová úložiště, která staví na velkém množstvím serverů s mnoha disky a rychlou sítí. Cluster sám udržuje minimální počet nastavených replik.
Obvykle se udržují tři kopie a celé řešení je odolné proti výpadku serveru, racku nebo dokonce celého datacentra.
Objektové úložiště má plochou strukturu a udržuje spoustu metadat pro vyhledávání, organizaci a správu obsahu. Adresáře tam jsou, protože je uživatelé chtějí, ale jsou emulované.
Výhodou takového úložiště je, že je dobře rozšiřitelné a škálovatelné.
CESNET používá technologii Ceph, přičemž každý cluster má desítky serverů a v nich tisíc až dva tisíce šifrovaných disků. Šifrování umožňuje disky reklamovat bez obav o data. Každý server má síťové připojení o kapacitě 4×10 Gbps nebo 2×25 Gbps. U některých instalací už uvažujeme o stogigabitových kartách. Každý jednotlivý server nabízí kapacitu úložiště 300 až 750 TB.
Mnoho hardware znamená také velkou úmrtnost. Je potřeba detailně monitorovat a hodně lidí se musí o zařízení starat.
Problematické jsou například zombie disky, které pracují pomalu a ovlivňují práci celého clusteru. Čteme obvykle z mnoha disků najednou a nemůžeme čekat na pomalejší z nich.
Objektové úložiště má proti HSM obrovské čtecí a zapisovací rychlostí. Hodí se lépe pro živější data a horké archivy.
Proti páskám se tu neustále kontroluje stav dat, takže se přijde na každý špatně zapsaný bit.
Například pro databázový provoz je objektová databáze nevhodná, protože aplikace čeká na replikaci na všechny disky a až pak dostane oznámení o uložení dat. Pokud tedy ukládáte malé objekty, budou latence poměrně nepříjemné.
Konzistence je ale hlavní prioritou těchto úložišť.
Martin Šebela: Phishingator – rok poté
Phishingator je webová aplikace pro automatické rozesílání cvičných phishingových zpráv. Uživatel si vytvoří podobu e-mailové zprávy a podvodné stránky a rozešle zprávy uživatelům.
Hodí se to pro vzdělávání uživatelů, kteří se chovají jinak, když jim nečekaně přijde podvodná zpráva. Nástroj byl představen před rokem právě na konferenci BSS.
Během roku byl nástroj předveden 35 organizacím jako jsou vysoké školy, výzkumné ústavy, úřady, nemocnice a třeba i soudy. Nasadili jsme devět instancí a další jsou v procesu nasazování.
Během toho vyšly další verze Phishingatoru s novými funkcionalitami.
Při ostrém nasazení se začalo stávat, že některé cvičné podvodné stránky se brzy objevily na blacklistech. Stávalo se to zejména u podvodných stránek s přihlášením do Office365.
Takové stránky jsou velmi rychle zablokovány, zajímavé je, že i tak někteří uživatelé přes varování projdou a vyplní platné heslo.
Proto autoři implementovali obranu proti blokaci, kterou používají i skuteční útočníci. Nejdřív se ověřuje, jestli návštěvník není z PhishTanku nebo se nehlásí jako Googlebot. Opravdu to funguje.
V kombinaci s různými cookies a přesměrováním se zatím daří blokacím předcházet.
Postupně přibývají nové funkce jako nové metody ověřování přihlašovacích údajů, personalizace šablony podvodné stránky a ignorování robotických návštěv. Například Outlook365 nám někdy podvodné odkazy sám otevíral a uživatel pak měl v Phishingatoru záznam o návštěvě, přestože na odkaz neklikl.
Plánuje se řada dalších vylepšení jako podpora HTML zpráv, nové proměnné v obsahu e-mailu, podpora multiskupin a graf zobrazující průběh kampaně. Postupně přijímáme další podněty a podle nich chceme zavádět nové funkce.
Dan Studený: To nej z agendy CESNET-CERTS
Běžným případem při řešení bezpečnostních incidentů jsou testovací servery, které nikdo neaktualizuje nebo stále zapomenuté běží, ačkoliv by měly být vypnuté. Častým úkazem jsou staré systémy, na kterých běží staré aplikace, které nemá kdo přepsat.
Někdy se o systémy také starají externí firmy, které bývají nepružné v servisních zásazích.
Samostatnou třídou zařízení jsou hloupá zařízení jako kamery, tiskárny a podobné přístroje, které by neměly být vidět z internetu, ale jsou. Jednou nám klimatizační jednotka provedla DoS útok do internetu. Zlá klimatizace!
Častým zdrojem problémů bývá lehkomyslnost, kdy se po reinstalaci nespustily orchestrační skripty nastavující zabezpečení. Setkali jsme se se sítí, která měla ACL správně napsané na IPv4, ale na IPv6 vůbec žádná pravidla nebyla.
Podobně záložní linky bývají méně zabezpečené než ty hlavní.
Zvláštní kategorií jsou také natované sítě, které nesbírají žádná data o uživatelích. Často chybí jakékoliv logování a nesbírá se ani flow.
Podobně také sítě určené pro hosty často pustí do sítě kohokoliv a provoz nebývá monitorován. Jednu ze sítí navštívil někdo s malwarem, kdo otrávil DNS keš a ostatní uživatelé pak byli přesměrováni na phishingové stránky.
Při řešení incidentů jsou překážkou také nefunkční bezpečnostní kontakty a špatná vnitřní komunikace v některých organizacích. Někdy najdeme zranitelné či útočící zařízení, které má neznámého správce nebo řešení trvá měsíc i déle.
Správci by neměli brát zranitelnosti na lehkou váhu, měli by číst poštu a oznámení o problémech a měli si nastavit pravidla součinnosti s dalšími správci.
Radoslav Bodó: Sner4
Slow Network Recon Service je nástroj pro proaktivní monitoring sítě, který průběžně skenuje přidělené adresní rozsahy. Je to něco jako Shodan, který běží uvnitř vaší sítě.
Na základě fingerprintingu je možné provádět sběr informací o službách, které v síti běží.
Martin Krajči: Služba Situational awareness
Služba má na komunitní bázi poskytovat informace o závažnosti a opravách nových zranitelností. Správci každodenně sledují nové zranitelností, na základě informací o síti pak vybírají zranitelnosti dle typu produktů a provádí jejich prioritizaci. Vytváříme stručné zprávy o těchto zranitelnostech, které posíláme správcům sítí.
Na začátku se vyskytují ty nejpodstatnější informace o zranitelnosti, verze balíčků s aplikovanými opravami a poté další podrobnosti.
Služba běží zhruba rok a postupně se upravuje formát zpráv na základě informací od odběratelů. Plánuje se také zasílání zpráv pomocí RSS a v plánu je zobrazovat je také na webu. Doteď jsme reporty vytvářeli manuálně, ale přecházíme na automatický systém Taranis-NS.
Aleš Padrta: Ze zákulisí The Catch
Každoročně v říjnu probíhá vzdělávací soutěž, která se jmenuje The Catch. Je určena odborné veřejnosti, ale nejen jí.
Každá soutěž je tématicky propojena a obsahuje zajímavosti z praxe či předchozích ročníků.
Hlavní web soutěže se zadáním běží na jiném serveru než server pro soubory ke stažení. Úlohy jsou dostupné za VPN a jedna z úloh po vás chce nakonfigurovat si OpenVPN.
Uživatelé tak dostanou vlastní IP adresu uvnitř sítě a nemohou být například odpojeni místním poskytovatelem sítě kvůli podezřelým aktivitám ve veřejném internetu.
Každá úloha má určitě své řešení, je zkoušena autorem, nezávislým kolegou a automatizovaným skriptem. Postup řešení je logický, i když se vám bez potřebných znalostí může zdát, že vám logický nepřipadá.
Každá úloha je s automatizací řešitelná v rámci minut. Pokud vám skript běží už třetí den, neděláte to dobře.
Autoři sledují úspěšnost řešení jednotlivých úloh a snaží se odhalit nejrůznější chyby z nepochopení. Často nejde o chybějící technické znalosti, ale o nedostatky v obecných znalostech. Nečekali jsme třeba, že někdo neví, že křížek na mapě s pokladem znamená cíl a ne start. Musíme se bavit s mladšími lidmi, kteří často vědí jiné věci, než víme my.
Pavel Valach: Passkeys se blíží…
Passkeys vznikly mimo jiné proto, abychom se vyhnuli nepříjemné situaci, kdy omylem někde zveřejníme své heslo. Nejde vlastně o nový způsob přihlašování, jen o použití asymetrické kryptografie na webových službách. Server zná pouze váš veřejný klíč a tajemství se na server nikdy nepřenáší.
Jde o řešení, které je velmi odolné proti phishingu. Pokud nebude objevena nějaká vážná bezpečnostní chyba, je prakticky nemožné, aby vás útočník zavedl na podvodnou stránku.
Dobrá zpráva je, že většina prohlížečů a operačních systémů už tento způsob přihlašování podporuje.
Přihlašovat se je možné například pomocí hardwarového tokenu jako YubiKey. Tajemství je napevno uloženo v zařízení a nemá se odtud jak dostat.
Většina uživatelů ale dnes používá takzvaný Multi-device FIDO credential, kdy se klíče generují v různých zařízeních a tajemství je pak možné synchronizovat. Pro přihlášení napříč zařízeními je možné například využít QR kód.
Passkeys se postupně šíří i do akademické sféry, například FEL ČVUT nebo MUNI už na implementaci pracují. Řada organizací používá vícefaktorovou autentizací pomocí YubiKey.
Pro uživatele je tento způsob přihlašování velmi pohodlný, protože není potřeba si pamatovat žádná hesla.
Andrej Tomči: Detekce secrets ve verzovaném kódu
Ve verzovaném kódu se nám často objevují čitelná tajemství jako hesla, tokeny a certifikáty. To pak umožňuje komukoliv s přístupem k repozitáři tyto informace zneužít.
Součástí problému je i to, že dostat už zveřejněná data z historie Gitu není snadné.
Při návrhu řešení je potřeba brát v potaz i míru rizika, pravděpodobnost zneužití a případné dopady. Je třeba vývojáře naučit, jak správně pracovat s citlivými údaji a jak předcházet incidentům.
Je třeba správně využít nástroje jako HashiCorp Vault nebo pass.
Je také možné proaktivně sledovat výskyt takových tajemství v repozitáři. Na začátku stačí naivně použít vyhledávání a zkoušet různé řetězce souvisejícími s hesly, soukromými klíči a podobně.
Lepší je ale dělat to systematicky a celý proces automatizovat například pomocí Gitleaks nebo TruffleHog.
Jan Kolouch: hSOC
V roce 2019 proběhl útok na benešovskou nemocnici a sešli se chytří pánové, kteří se rozhodli vytvořit kyberochranku pro nemocnice. Poté přišla celá řada dalších útoků. Máte pocit, že se něco změnilo a bezpečnosti jsou bezpečnější?
CESNET se snaží se situací pomoci, protože mimo jiné připojuje právě nemocnice a jiná zařízení z oblasti zdravotnictví. V současné době je připojeno 61 zdravotnických zařízení, z nichž 15 je zapojených v oddělené síti hsoc-vrf se specifickými pravidly.
Iniciativa hSOC (Hospital SOC) poskytuje bezpečnější připojení do systémů státu a vytváří metodiky.
Podstatná je kooperace, koordinace a možnost zapojit se do komunity. Musím říct, že zástupci současného ministerstva se snaží.
Řešením je budovat kapacity a nečekat, že vám někdo pomůže. Našim cílem je použít principy a metodiky, které jsou ověřené.
Pavel Valach: HAAS aneb sdílejte data
Honeypoty umožňují zachytávat nezvané hosty na umístěnou návnadu na strategické pozici v síti. Návnadou bývají různé služby, na které se může připojit někdo zvenčí. Snažíme se v podstatě o sběr dat, která nám pak slouží k ochraně sítě.
CESNET připravuje vlastní honeypot nazvaný Hugo, který zatím běží v testovacím režimu.
Každé připojení k takovému honeypotu je událostí, ale je potřeba shodnotit, jak k ní došlo. Připojil se někdo omylem? Našel přihlašovací údaje v nějakém úniku?
Výsledkem může být spousta informací od zdrojových IP adres přes přihlašovací údaje až po konkrétní použité příkazy.
Organizace připojené do sítě CESNET se budou moci snadno zapojit do sběru dat, která se pak mohou sbíhat v systému Warden. Bude stačit si stáhnout obraz virtuálního stroje, přidělit mu nějaké IP adresy a spustit ho.
Po registraci do Wardenu už pak honeypot může běžet a sbírat data.
Jako implementace honeypotu se zatím používají Cowrie emulující příkazovou řádku a Dionaea emulující různé služby. Umí i pasivní fingerprinting útočníkova systému.
Oba nástroje umožňují nahrávat celou komunikaci, nad kterou je možné provádět další výzkum.
(Autorem fotografií je Petr Krčmář.)
