TCP bezpečnost

[Ondrej Nemecek]

IMHO tady nikdo nebude jen tak něco hackovat, protože to může být ilegální a proč by to někdo dělal?

Ale hacknout to určitě jde a může se to stát i mimochodem. Takže by se to mělo řešit jaksi projektově v rámci kompetencí.

Že nebudete ani první ani poslední, komu se to přihodilo, je vidět například z osudu zdravotnických zařízení.

[Reklama]

[Filip Jirsák]

Díky uživateli Filip Jirsák za komentář. Tomuto asi rozumím, ale jaká je reálná šance, že to někdo dokáže? Myslím tím, jestli toto dokáže 9 z deseti hackerů, který se o to pokusí, protože to je tak strašně jednoduché nebo to dokáže 1 z tisíce, protože má zrovna přístup k nějaké páteřní síti a ví co má hledat. Já mám např. přístup jak ke klientovy tak k serveru a vím jak celej princip pracuje. Znamená to tedy, že mi stačí jen udělat kroky 1..2...3, zmačknout enter a data, která systém poškodí jsou odeslaná?

Schopnosti na to má velká spousta lidí. Jediné reálné omezení je motivace. Pokud napadením útočník nic nezíská, budou to nejspíš zkoušet jenom tací, kteří si prostě jen něco chtějí zkusit. Buď si dokázat, že to zvládnou, nebo se na tom něco naučit. A pak je samozřejmě otázka, zda narazí zrovna na vaše zařízení.

Úplně něco jiného ale je, pokud tím může útočník něco získat. Nebo vám způsobit škodu a tím pádem vás vydírat („zaplaťte, nebo vám způsobím tuhle škodu“). Může vám tím útočník způsobit škodu 5000 Kč? No, pak se asi nikdo nebude obtěžovat. Může tím poškodit zařízení, pokazit pověst firmy, zmařit třeba investice v řádech statisíců nebo milionů? Pak už výhružka „pošlete mi 100 000 Kč v bitcoinech, nebo několik vašich zařízení vypnu“ dává smysl a za tu částku už se někomu vyplatí se tomu věnovat.

Pokud máte přístup ke klientovi a serveru, odeslat data samozřejmě můžete. V drtivé většině případů byste to mohl udělat i tehdy, pokud byste měl přístup jen k routeru některé z těch sítí. Kdybyste měl přístup jen do některé z těch sítí (ne přímo na router), bylo by to jen o něco složitější.

Nevím, co je to za zařízení a co si tam můžete dovolit implementovat. Pokud je to nějaký hardware, na kterém běží linux (nebo něco o něco menšího), moc bych se s tím nepáral a použil bych HTTPS. Pokud trváte na tom, že ta data musí být veřejná a chcete zabezpečit jenom důvěryhodnost příkazů ze serveru, pak je podepisujte. Ideálně podpisem založeným na asymetrické šifře – zařízení budou mít veřejný klíč, server bude podepisovat privátním. Pokud můžete zařízením důvěřovat, že z nich nikdo nevydoluje citlivé informace, můžete podepisovat i jenom hashem. Pošlete ze serveru zprávu, ke zprávě připojíte tajné heslo a to celé zahashujete – a ten hash pošlete na konci zprávy. Klient bude znát stejné tajné heslo a s přijatou zprávou provede to samé. Když mu vyjde stejný hash, ví, že to posílal oprávněný server.

[Jose D]

jak se vyvarovat chyb. Jedna rada byla:

Znovu a znovu vynalézejte kolo.

Napadá mě otázka čemu pak věřit.

"Why shouldn't we create our own security schemes?" - https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit

Koncept jsem ti výše napsal. MITM. - https://www.greycampus.com/opencampus/ethical-hacking/network-or-tcp-session-hijacking

Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit

Tohle se dodává jako služba, akorát rýpat se v custom aplikaci něco stojí - ať se dostaneš do kontextu, testování vlastních řešení je v té "premium": https://csirt.cz/cs/penetracni-testovani/

myslím to tak, že se mi dost těžko věří tomu, že něco lze, když jsem to ještě neviděl a to i přes to, že na internetu se to píše.

huh.

[_Jenda]

No žádná autentizace tam teď v podstatě není, ale možná si jen nerozumíme :-)

Aha, tak o čem se bavíme? Jestli dokážeme v TCP spojení, které přes nás jde, nahradit jedny ASCII znaky za jiné ASCII znaky (a přepočítat CRC)? Na to je všude na netu návodů hromada, ale jestli chceš, tak to za těch 5kKč klidně naprogramuju .

Můj návrh s autentizací pomocí AES jen tento (má za cíl autorizovat mezi sebou obě strany jen při navazování spojení)...a nemění komunikační protokol
1. jen obě strany už od začátku znají šifrovací klíč
2. server vygeneruje náhodný vektor, který použije k inicializaci šifry a zašifruje nějaký text (třeba náhodný nebo "5*9=")

Zbytečně složité, stačí do zařízení poslat zašifrovaný text a zařízení ho pošle rozšifrovaný (nebo naopak, ale ono je to v CTR módu vlastně jedno).

Teda, ehm: doufám že ten CTR mód inicializuješ vždycky správně a negeneruješ omylem pokaždé stejný keystream, že ne?!? Pak by šly ty challenge navzájem vyXORovat a jsi více či méně v řiti (podle konkrétních detailů protokolu)

Tím se zajistí, že klient i server si musí rozumět a můžou spolu komunikovat.

No dobře, tím server ověřil, že komunikuje se správným klientem. Jak je tohle ale navázáno na celý zbytek komunikace? Co se stane, pokud v tento okamžik do komunikace vstoupí útočník?

Je to mnohem horší, což osobně vidím jako velkej průser.

No tak si na to najměte konzultanta. Já se klidně hlásím, když mě trochu postalkuješ tak najdeš že mám za sebou pár projektů podle kterých bych toho měl být schopen (a už jsem vám poradil to OpenWRT . Jenom se bojím, že mě nedokážete zaplatit, když s tím zjevně zápasíte několik let a za tu dobu jste nedokázali sehnat programátora co by tomu rozuměl.

Nějakej osvědčenej typ na model se kterým se každej naučí?

Tohle je běh na dlouhou trať, pokud chceš rozumět těm principům za tím, tak budeš muset nastudovat aplikovanou kryptografii (začal bych tady: https://cryptopals.com/) a sítě (začal bych tady http://www.earchiv.cz/l225/index.php3 a tady http://www.earchiv.cz/l226/index.php3). Pokud chceš hotové bezpečné řešení, tak nějakou existující knihovnu implementující široce známý standard (např. TLS). Pokud to tvůj embedded systém neumí a potřebuješ si napsat něco vlastního, tak to opravdu bez porozumění výše uvedeným zdrojům nedáš.

Jestli ses ptal na model routeru, tak bych doporučil tyhle levné bílé mikrotiky - https://www.alza.cz/mikrotik-rb750r2-d2646618.htm (existuje jich víc, RB750, RB952… pro tebe jsou všechny ekvivalentní) a do toho flashnout OpenWRT. Pokud je 900 Kč za Mikrotik moc, tak bych zkusil na AliExpressu GL-MT300N-V2, který stojí polovinu, ale je to „neznačkové“ řešení.

Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit a ukázat mi to v reálném provozu.

Já teď nevím co teda jako máme ukázat že prolomíme. Jde o to editování spojení které přes nás jde, příp. jsme ho na sebe přesměrovali třeba pomocí ARP spoof? Jako sorry, ale to je snad síťařské „101“, ne?

[hazardrok]

Těch věcí co si můžu spolehlivě dovolit moc není. Resp. implementovat nějaký kód, který šifruje není problém, ale implementovat celou knihovnu TLS, aby to ověřovalo obě strany už je problém. A ověřit obě strany potřebuji, protože server musí věřit klientovy, aby mu posílal platné hodnoty z měření a klient musí věřit, že mu server posílá správnou konfiguraci. Proto jsem se také začal zabývat šifrováním, ale zatím jen při navazování spojení. Po posledních komentářích chápu, že to není reálné a je potřeba k tomu přistoupit líp.
Používat asynchronní šifru se mi zdálo složitější než synchronní (jen dojem za posledních pár dní co se tím zabývám) hlavně z pohledu výpočtu. Proto jsem se pokusil implementovat ten AES-256 s CTR, protože se tam používá stejný algoritmus k šifrování i dešifrování což by mi ušetřilo dost paměti. Nejsem ale schopen posoudit zda to někdo prolomí a jak říkáte, proč by to také dělal. Na druhou stranu rád bych tomu co to dělá rozumněl a chtěl bych, aby to bylo přinejmenším nesnadné prolomit. Podepisování hashem se mi líbí...

Můžete se tedy pokusit odpovědět na tyto otázky, nemusí to být složité odpovědi...
1. Je lepší použít synchronní šifru nebo asynchronní (je nějaká jednoduchá na implementaci)?
2. Pokud použiju synchronní např. zmíněný AES metodou CRT a budu každou zprávu šifrovat pomocí náhodného vektoru, který budu předávat v každé zprávě bude to spolehlivé? Pokud nebude, existuje nějaká jiná synchronní šifra, kterou můžu napsat v céčku s minimální zdroji která bude spolehlivá?

Osobně jsem k té asynchronní šifře docela skeptickej, protože se mi nelíbí ten privátní a veřejnej klíč. Také moc nechápu jak se dají pomocí veřejného klíče získat data zašifrovaná privátním, ale to je asi jen detail, kterej snad někdy pochopím. Je mi jasné, že v moderním světě se to takto dělá a všichni to přijímají ale na rovinu... v tomto vlákně je vidět jakási píle něco udělat líp, ale když si firma vezme 1,5mil Kč za vývoj SW paskvilu, za rok řekne sorry, ale my už to dělat nebudem a nic se jim neděje je to smutné. Na druhou stranu jsem nedavno byl u jednoho chlapíka v domě za 50mil+ a tam nedostanete ani kafe. U nás dostane kafe a sušenku i kominík co udělá nerezovej komín na krb do domu kde neni hromosvod :-D Všechno není tedy jen o penězích...

Takže pokud tu ještě někdo má sílu se tím zabývat, zapomeňte na mikrotik a jiný názory o TSL, protože to mi nepomůže a spíš mi poraďte jakou šifru mám použít. Klidně udělám ještě jednu obálku nad celou komunikací, která bude celá zašifrovaná, ale jak to nepůjde napsat do 512b ramky je to špatný.

[Reklama]

[hazardrok]

Teda, ehm: doufám že ten CTR mód inicializuješ vždycky správně a negeneruješ omylem pokaždé stejný keystream, že ne?!? Pak by šly ty challenge navzájem vyXORovat a jsi více či méně v řiti (podle konkrétních detailů protokolu)

No v podmínkách je (pokud jsem je správně pochopil), že nesmím dvě různé zprávy zašifrovat stejným klíčem a stejným inicializačním vektorem. Inicializační vektor chápu jako absolutně náhodné číslo. Pokud tedy každou zprávu zašifruju stejným klíčem, ale pokaždé jiným vektorem, který si budu náhodně generovat a posílat ho veřejně vedle zašifrovaných dat logicky bych si myslel, že podmínky šifrování jsou splněny. A data jsou šifrovaná bezpečným způsobem. Dokážeš mi tento můj závěr vyvrátit? Klidně pošlu i ten kód, kterým to testuju.

Kdybych tady teď neseděl a nesnažil se o socializaci na této síti měl jsem na plánu doma testovat to šifrování a hledat bezpečnostní chyby. Např se mi moc líbí toto: https://cs.wikipedia.org/wiki/Provozn%C3%AD_re%C5%BEim_blokov%C3%BDch_%C5%A1ifer
Chtěl jsem si vyzkoušet jak by vypadal můj zašifrovaný tučňák :-)

[_Jenda]

Je to symetrická a asymetrická, ne synchronní a asynchronní 

Asymetrické šifrování je složité implementovat a na omezeném hardwaru je složité ho počítat. Pro tvůj případ si vystačíš se symetrickým. Budeš potřebovat blokovou šifru (AES) a hash (SHA-256 a z toho odvozený HMAC). Oboje se do malého prostoru snad vejde.

2. Pokud použiju synchronní např. zmíněný AES metodou CRT a budu každou zprávu šifrovat pomocí náhodného vektoru, který budu předávat v každé zprávě bude to spolehlivé? Pokud nebude, existuje nějaká jiná synchronní šifra, kterou můžu napsat v céčku s minimální zdroji která bude spolehlivá?

Nebude, a problém je v tom counter módu. Jak už jsem psal a jako hardwarář by sis měl hned uvědomit, tak když to dělá XOR s keystreamem, tak můžu pomocí XORování těch šifrovaných dat ta data pod tím libovolně měnit. To nemusí být nutně na závadu, i když bych osobně raději použil mód CBC (který ale tímto problémem částečně trpí taky, a na tom Matasano je na tohle cvičení), pokud tuto změnu dat zjistíš. A k tomu právě potřebuješ ten HMAC. Takže na konec zprávy přilepíš její HMAC (pozor, používá se schéma encrypt-then-MAC, tj. HMAC spočítáš ze zašifrované zprávy) a tím to máš ověřeno. Pak ještě chceš mít nějaké počítadlo nebo náhodnou challenge aby nešly dělat replay útoky a pak bych tomu řešení už docela věřil.

Také moc nechápu jak se dají pomocí veřejného klíče získat data zašifrovaná privátním, ale to je asi jen detail, kterej snad někdy pochopím.

Upřímně já to taky chápu na úrovni „algrebra magic“ [mává rukama]. A jinak implementovat RSA from scratch je o držku, protože tam jsou věci jako padding, správná volba exponentu a tak. U ECC je to podobně příšerné, různé handlování nevalidních bodů na křivce a tak. Proto bych se tomu snažil co nejvíc vyhnout a používal bych symetrické řešení.

Inicializační vektor chápu jako absolutně náhodné číslo. Pokud tedy každou zprávu zašifruju stejným klíčem, ale pokaždé jiným vektorem, který si budu náhodně generovat a posílat ho veřejně vedle zašifrovaných dat logicky bych si myslel, že podmínky šifrování jsou splněny.

Ano, to je v pořádku.

[_Jenda]

Ještě jsem si vzpomněl na tohle http://mj.ucw.cz/vyuka/2021/kry/, „díky“ koronaviru tam jsou záznamy přednášek pro vzdálené studium. Nekoukal jsem na to, ale možná to bude vyžadovat trochu matfyz-level matematiky, a nevím, jak to bude srozumitelné bez toho.

[Filip Jirsák]

Používat asynchronní šifru se mi zdálo složitější než synchronní (jen dojem za posledních pár dní co se tím zabývám) hlavně z pohledu výpočtu.

Předpokládám, že myslíte symetrické a asymetrické šifrování.

Další věc – šifrování zajišťuje to, aby nikdo cizí data neviděl, ale nezajišťuje, že je nemůže měnit (integritu dat). Pokud někdo přepíše zašifrovaná data, na výstupu (po rozšifrování) asi dostanete nesmysly, ale nemáte to jak zjistit, že to někdo změnil.

Takže co potřebujete zajistit – utajení dat, jejich nezměnitelnost, nebo obojí?

1. Je lepší použít synchronní šifru nebo asynchronní (je nějaká jednoduchá na implementaci)?

Záleží jak na co :-) Symetrické šifrování používá na obou stranách stejný klíč, takže musíte věřit oběma stranám (a musíte být schopen klíč na obě strany bezpečně dopravit). U asymetrické šifry se šifruje veřejným klíčem a dešifruje privátním. Asymetrické šifry jsou podstatně pomalejší, než symetrické – takže pokud je potřeba šifrovat větší množství dat (třeba ve spojení), vytvoří se na začátku klíč, který se vymění pomocí asymetrického šifrování, a dál už se šifruje symetricky s pomocí toho klíče.

2. Pokud použiju synchronní např. zmíněný AES metodou CRT a budu každou zprávu šifrovat pomocí náhodného vektoru, který budu předávat v každé zprávě bude to spolehlivé? Pokud nebude, existuje nějaká jiná synchronní šifra, kterou můžu napsat v céčku s minimální zdroji která bude spolehlivá?

Viz výše. Úvodní výměna klíče se obvykle řeší asymetrickou šifrou. Případně pokud je komunikace déle trvající, klíče se v průběhu ještě obměňují.

Osobně jsem k té asynchronní šifře docela skeptickej, protože se mi nelíbí ten privátní a veřejnej klíč. Také moc nechápu jak se dají pomocí veřejného klíče získat data zašifrovaná privátním, ale to je asi jen detail, kterej snad někdy pochopím.

To, že je veřejný a privátní klíč, je naopak obrovská výhoda. Šifrovat pak může kdokoli (šifrovací klíč je veřejný). A je to opačně, než jste napsal – šifruje se veřejným, dešifruje privátním. Opačné pořadí se používá pro podepisování (podepisuje se privátním, podpis ověřuje veřejným).

Takže pokud tu ještě někdo má sílu se tím zabývat, zapomeňte na mikrotik a jiný názory o TSL, protože to mi nepomůže a spíš mi poraďte jakou šifru mám použít. Klidně udělám ještě jednu obálku nad celou komunikací, která bude celá zašifrovaná, ale jak to nepůjde napsat do 512b ramky je to špatný.

Viz výše – co přesně potřebujete zajistit? Aby data nikdo neviděl, aby je nemohl změnit, nebo obojí? Je to stejné v obou směrech komunikace nebo v každém směru jiné?

[_Jenda]

Pro tvůj případ si vystačíš se symetrickým. Budeš potřebovat blokovou šifru (AES) a hash (SHA-256 a z toho odvozený HMAC). Oboje se do malého prostoru snad vejde.

A kdyby se nevešlo, tak hash se dá použít jako šifra v counter mode (jednoduše hashuješ klíč + zvyšující se počítadlo a to generuje keystream), a naopak bloková šifra se dá použít jako hash (detaily jsem zapomněl). Ale je to další věc, ve které se dají nasekat chyby, takže to radši nedělej.

[hazardrok]

Je to symetrická a asymetrická, ne synchronní a asynchronní

Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory

[Filip Jirsák]

Je to symetrická a asymetrická, ne synchronní a asynchronní

Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory

:-) Je to pojmenované podle těch klíčů. Symetrická má na obou stranách stejný klíč, je to tedy symetrické, strany nelze rozlišit. Asymetrická používá veřejný a privátní klíč, proto je to asymetrické – strany se liší.

[hazardrok]

Další věc – šifrování zajišťuje to, aby nikdo cizí data neviděl, ale nezajišťuje, že je nemůže měnit (integritu dat). Pokud někdo přepíše zašifrovaná data, na výstupu (po rozšifrování) asi dostanete nesmysly, ale nemáte to jak zjistit, že to někdo změnil.

Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.

Takže co potřebujete zajistit – utajení dat, jejich nezměnitelnost, nebo obojí?

Popravde receno utajit je nepotrebuju, ale nesmi byt zmeneny. Jak nad tim ale premejslim tak moc nedokazu pochopit co se bude dit, kdyz utocnik zachyti dva zasifrovane ramce. Jeden bude znamenat napr. odemkni dvere a druhy zamkni dvere. Pokud jsou to platne ramce a utocnik je bude stridave odesilat, tak je zarizeni musi preci nutne vyhodnotit jako spravne. Nenapada me mechanismus jak by se dalo zajistit aby to zarizeni odmitlo pozadavek. Mozna mi stale neco unika...nebylo by to naposled

[Filip Jirsák]

Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.

To je dost odvážné tvrzení :-) CRC je příliš krátké na to, aby někoho určitě zastavilo. Útočník akorát nepošle změněná data hned na první pokus, ale bude muset vystřílet těch pokusů víc.

Popravde receno utajit je nepotrebuju, ale nesmi byt zmeneny.

Pokud to opravdu stačí, stačí ta data podepisovat. Buď klasicky asymetrickými klíči, nebo pokud můžete klientům věřit, pak stačí použít ten hash (data + sdílený klíč). Inspirovat se můžete třeba u JSON Web Token, jakým způsobem je to podepisováno.

Jak nad tim ale premejslim tak moc nedokazu pochopit co se bude dit, kdyz utocnik zachyti dva zasifrovane ramce. Jeden bude znamenat napr. odemkni dvere a druhy zamkni dvere. Pokud jsou to platne ramce a utocnik je bude stridave odesilat, tak je zarizeni musi preci nutne vyhodnotit jako spravne. Nenapada me mechanismus jak by se dalo zajistit aby to zarizeni odmitlo pozadavek. Mozna mi stale neco unika...nebylo by to naposled

To je zase jiná věc – obrana proti replay attack. Tam je potřeba vyřešit, aby každý požadavek musel být jiný. Například můžete na obou stranách držet sekvenční číslo – server zvýší číslo o jedničku a pošle požadavek. Klient si ověří, že sekvenční číslo požadavku je nižší, než poslední známé číslo – pokud ano, požadavek je platný a provede se, a čítač se posune na nejnovější číslo. Kdyby útočník vzal data a poslal je znovu, klient bude vědět, že tohle sekvenční číslo už vylo použité dříve a že je to opakování požadavku. Díky tomu, že to celé máte v TCP/IP spojení, nemusíte řešit, že by požadavky přišly v jiném pořadí. Ještě bude potřeba dořešit přetočení sekvence – buď ji nadimenzovat tak, aby se nikdy nepřetočila (např. pokud zařízení fyzicky zvládne provést cca 1000 příkazů a pak už bude tak opotřebované, že přestane fungovat, je sekvence s prostorem 4 miliardy hodnot dostatečná rezerva). Případně se dají sekvenční čísla počítat jen v rámci jednoho TCP/IP spojení, pak ale zase musíte řešit, jak zabránit tomu, aby útočník nezopakoval celé dřívější spojení (nebo jeho začátek). Pomůže třeba pokud má ten klient přesný čas (pak může být součástí přenášených dat, klient ho ověří – pokud by někdo data zopakoval, buď nebude sedět čas, nebo opakování přijde velice rychle za sebou – předpokládám, že pokud přijdou třeba během vteřiny dva příkazy na zavření ničemu to nevadí).

Akorát to trochu vypadá, že tu znovu vymýšlíme TLS. A to není zrovna jednoduché – i experti v tom dělají chyby, takže dnes už máme 6. verzi. Chápu, že bude problém použít hotovou knihovnu, implementovat celé TLS na zelné louce je hodně náročné – ale tohle vyzobávání dílčích částí, které vám budou stačit a které bude snadné implementovat, určitě povede k tomu, že na něco zapomeneme. Další věc je, jakou úroveň spolehlivosti potřebujete. TLS věří i banky a vlády, vám možná stačí nižší spolehlivost, takže by pak nemuselo tolik vadit, že tam budou nějaké menší díry, které bude relativně náročné zneužít.

[RDa]

Bezpecny protokol ani zarizeni neexistuje - sebevic se budete snazit, vzdy existuje vice ci mene slozita cesta, jak jakoukoliv ochranu ktera je obalkou zakladni funkcionality obejit (viz CD, copy protection, hry, sw a pod). I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

Zminilo se tady, co je to vubec za aplikaci, co potrebuje vyresit nejakou ochranu? Protoze urcity bezpecnostni kompromis lze najit na te aplikacni urovni, a realna aplikace by spis mela umet identifikovat narusitele a ochranu pak zalozit na ponekud vyssi urovni (je to srovnatelny se spamem - neco nezachytite, neco zbytecne zahodite.. dokonalost neexistuje).