Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - _Jenda

Stran: 1 ... 61 62 [63] 64 65 ... 100
931
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 22:06:06 »
Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene :)
A v čem je teda přesně problém když tohle někdo udělá? Samozřejmě nepředpokládám (i když podle úrovně dotazů…) že by měl autor globální klíče.

932
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 21:53:13 »
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.
Jako že útočníka nenapadne, že by na konci mohlo být CRC a nevyzkouší všechny polynomy až mu nějaký vyjde? A to ani když zařízení fyzicky dostane, vytáhne z něj firmware a disassembluje ho? https://en.wikipedia.org/wiki/Security_through_obscurity

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 ;D
Tomu se říká replay a taky jsem o něm mluvil… Buď můžeš použít sekvenční čísla, nebo na začátku vždycky proběhne handshake, do kterého oba konce vloží nějakou náhodu.

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).
Ano, tohle jsme tu přesně potřebovali. Až na to, že a) tohle jsou úplně jiné případy (kdy se snažíš zabránit v úniku dat ze zařízení, které má útočník fyzicky v ruce; my řešíme síťovou bezpečnost), b) je úplně jiný level „Jenda udělá MITM na deset řádků Pythonu“ a „jó, teoreticky by někdo mohl cracknout AES!“.

I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.
To předpokládám, že v jeho use-case nevadí (e.g. pokud se útočník dostal fyzicky k zařízení, může si už dělat co chce).

933
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 20:34:18 »
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.

934
Odkladiště / Re:Hledání zajímavého obsahu na Internetu
« kdy: 04. 02. 2021, 20:15:58 »
IRC kanál #brmlab na freenode a již zmíněné https://news.ycombinator.com/

935
Distribuce / Re:Po aktualizaci na Debian Buster nefunguje síť
« kdy: 04. 02. 2021, 20:14:35 »
opravdu nechapu, proc pri timeoutu neni moznost hotkey "S - skip timeout na vlastni nebezpeci"
+1, mně většinou dojde trpělivost a v konfiguraci všechny timeouty snížím, ale pak jsem zase narazil na problém, že velký FS na rotačním disku, který nebyl korektně odpojen, trvalo dlouho připojit (přehrával se žurnál atd.), nestihlo se to do toho timeoutu a celé to vybuchlo.

936
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 20:09:30 »
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.

937
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 20:01:51 »
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.

938
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 19:10:20 »
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?

939
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 15:00:36 »
Protokol je jasně daný
No a kde teda je popsaný?

Přesný popis není důležitý, protože ten útočník rozklíčuje kompletně jen velice težce. Zkusím večer vygenerovat zničující zprávu a ta se pro celý proces může použít, protože bezpečně to zbortí.
No minimálně by se nám hodilo vědět jak funguje ta autentizace, nebo alespoň co autentizace je (to by šlo asi i uhodnout kdyby se těch zpráv nasniffovalo víc, bude to něco na začátku co vypadá náhodně). Samozřejmě se neptám na formát payloadu, to je mi fuk a nezajímá mě.

940
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:42:02 »
Protokol je jasně daný
No a kde teda je popsaný?

941
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:34:01 »
No úplně na koleně to být nemělo. Chtěl jsem použít https://github.com/kokke/tiny-AES-c a ten algoritmus CTR s AES-256. Můj návrh byl ten, že bude pevně daný klíč, který budou znát jen client a server. Pro každé zašifrování se vygeneruje inicializační vektor a ten se pošle spolu s daty (nešifrovaně). Pokud to správně chápu a bude pro každou šifru jiný vektor, který bude generován s co největší náhodností je to neprůstřelné.
Nepopsal jsi jak pak proběhne to samotné ověření (a jak je dále zajištěna integrita dat). A pro začátek u CTR můžu flipovat jednotlivé bity ciphertextu a tím se flipují bity na stejné pozici v plaintextu.

Je to celé naprd, protože znám systém za statisíce a stovky zařízení, které jsou takto blbě navržena a už roky běží (né mojí vinou). Změnit šifrování na TLS není už realizovatelné.
A ten Tiny AES běží přímo na tom zařízení? Pokud to zvládne ještě SHA-2, tak se tam dá udělat AES + HMAC a to bude podstatně lepší. Ale musí to dělat někdo ví co dělá, ne někdo kdo neví jak se dělá MITM. Jinak tohle se normálně řeší tak, že nakoupíš nějaké malé routříky na kterých běží OpenWRT, nastavíš na tom OpenVPN (nebo jinou VPN, wireguard, ...) a dáš to před to zařízení. Samozřejmě ne vždy to jde provést (cena, prostor, spotřeba). Jako bonus získáš přístup na to zařízení i když je za NATem atd.

942
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:11:58 »
protokol zdokumentovany byt nemusi, pokud mam k dispozici klienta i server, abych si mohl cist sitovou komunikaci, tak to je lehke.
„Lehké“ je relativní, samozřejmě je možné že ten protokol bude jednoduchý a udělat to bude na pět minut, ale taky tam může být něco nezjevného a reverzování bude chvíli trvat. A protože cílem je hodnotit bezpečnost protokolu, tak je blbost pálit čas na implementaci a řešení toho proč to nefunguje. Navíc s tímhle rozpočtem, a když to vynásobíš odhadem že se to celé podaří (jak technicky, tak že uživatel hazardrok nezdrhne bez zaplacení, případně si nevymyslí ze své neznalosti nějaký pseudodůvod proč se tvůj útok nepočítá, a taky že tě tu někdo nepředběhne - jak vidíme tak už jsme dva co to jako chtějí implementovat) tak 50% tak to celé musíš stihnout za několik málo hodin aby to bylo rentabilní. Jinak z toho co popsal mi přijde že to bude deset řádků Pythonu (necháš projít ten úvodní handshake a pak už si komunikaci upravuješ jak je libo) a tak bych do toho šel :), ale necháme se překvapit.

943
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 13:42:16 »
Autorizaci klienta chci teď po novu řešit pomocí AES a předpokládám, že SERVER i CLIENT při navazování spojení pozná zda je to fejk nebo ne. Pro mě je největší otázkou co se bude po tom co je spojení navázané.

Z tohoto mi přijde, že se snažíš implementovat si protokol pro šifrování a autentizaci „na koleně“, což vzhledem k tomu, jak se ptáš na základy typu únos TCP spojení a MITM, nedopadne dobře. Kdybys použil nějaký normální standardní protokol (třeba TLS) nebo o tom něco věděl (no offense), tak bys to samozřejmě udělal tak, že je šifrovaná a podepisovaná celá komunikace. I ten AES a spol. k tomu lze samozřejmě použít - buď si vybereš mód, který je autentizovaný by default (AEAD, například GCM), nebo do komunikace vkládáš HMAC podpisy zašifrovaných bloků. Dále se bojím, že to naprogramuješ tak, že bude možný replay útok, nebo tam nasekáš chyby typu neautentizovaný CBC nebo counter mód, takže útočník bude moct přehazovat jednotlivé bity ve zprávě, transplantovat bloky atd.

Jediné co mě napadá je že existuje hackerský TCP server, který má stejnou IP adresu jako můj a tak se client připojí k němu. Jak by to ale mohl dokázat, když jsou všichni z jiného města? V rámci jedné budovy client-hacker možná, ale jiná síť...
Tak jednak řešení, které funguje jen proti útočníkům z jiného města, ale nikoli proti útočníkům ze stejného města, je dost k ničemu. A jednak: v rámci sítě (ARP spoofing) a po cestě u ISP (jeho děravá infrastruktura; když jsem sám ISP - různé veřejné wifi) na obou stranách. Dále třeba zmíněný DNS poisoning. A pak byly i nějaké další způsoby, co zneužívaly různé implementační problémy se sekvenčními čísly atd., ale ty jsem nikdy podrobně nezkoumal a bylo složitější je provést.

No pokud bys o to měl skutečně zájem, o víkendu si nějakej pronajmu a rozjedu na něm ten systém. A myslím to naprosto seriózně, protože mě opravdu zajímá jestli to lze takto jednoduše. Jsem přesvědčen, že to nedokážeš. Máš nějakej tip na poskytovatele nějakých virtuálních serverů, který by byl vhodný?
Když sem dáš dokumentaci protokolu (rozhodně to za 5kKč nikdo nebude reverzovat) a ukázkovou implementaci klienta (abychom to nemuseli implementovat), tak se ti na to možná podívám.

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.
Opět, řešení, která se spoléhají na tyhle věci, jsou rozbitá.

944
Sítě / Re:Vypočítání počtu wifi
« kdy: 03. 02. 2021, 11:21:15 »
https://www.3ds.com/products-services/simulia/products/cst-studio-suite/  ;D

ne, sorry, tohle je fakt dost těžký problém a bez detailních informací (zdi…) to nemáš šanci udělat.

945
EKG mě až překvapilo jak je jednoduché - postavil jsem to tento víkend za odpoledne jako katalogové zapojení ADS1292R a pomocí opotřebovaných elektrod z vodivé gumy (tj. úplně špatných, protože se polarizují, správně tam má být stříbrný drátek v gelu o správném složení a tak; na druhou stranu gumové elektrody stojí pár korun a dají se používat nekonečně dlouho) a nestíněného kabelu (tj. příšerné rušení ze sítě) jsem na sobě, bez jakéhokoli setupu, jen tak v sedě na židli u počítače a podle umístění elektrod co jsem natipoval, naměřil tohle:



což mě naprosto šokovalo, protože jsem nečekal, že s touto kvalitou a cenou tam bude něco vidět. Data to blije přes SPI do Pythonového skriptu běžícího na Raspberry Pi - bez problému si to tak můžeš připojit třeba přes wifi do Grafany :D. Spočítání tepové frekvence pak je aplikace nějakého derivačního/IIR/peak detect filtru.

Bohužel se mi nepovedlo rozchodit monitoring dechu, který to má taky umět, buď to dělám blbě, nebo na to jsou potřeba ty lepší elektrody a některé součástky (ty jsem objednal, ale ještě nepřišly). Celé zařízení má výrobní cenu asi 350 Kč (bez Raspberry; přičemž k jednomu Raspberry jich může být připojeno několik - nevím kolik, je to čistě o propustnosti sběrnice), všechny součástky jsou na JLC a sami ti to osadí a dokonce mají 114 kusů in stock. Raspberry můžeš napájet z galvanicky odděleného 12V/5V rozvodu, nebo si do toho EKG dáš optický izolátor (což to tak prodraží tak na 500 Kč celkem), nebo se spokojíš s tím, že směrem k pacientovi je ochranný odpor. Pokud by byl zájem, tak rád budu spolupracovat - na výrobě takového monitoru EKG, integraci, rozchození toho snímání respirace :) a tak, pokud je to v Praze tak i IRL, ale zase se nechci nechat někde na JIPce nakazit, tak on-site servis leda až bude očkování (ehm).

Dále jsem si na Ali koupil MAX30102 oxymetr za 60 Kč, už je v ČR, za chvíli si s ním pohraju a napíšu sem jak to chodí. Bojím se, že to bude horší než to zázračné EKG, protože to neměří prosvícením, ale odrazem, a to bylo vždycky strašně na prd. Kamarád koupil to stejné s originálním kolíčkem na prst a bluetooth, ale ještě mu to nepřišlo (je to ale pokročile na cestě), posílám mu odkaz na tuto diskuzi, jestli sem pak napíše.

Dále mám problém že nevím jak oxymetr otestovat - nevím jestli když zadržím dech, tak si dokážu způsobit znatelné snížení saturace. Podtlakovou komoru ani inertní plyny na lidi v práci nemáme :).

Ten kamarád říkal, že existuje standard pro oxymetry, a že by ho to teoreticky mohlo splňovat. Pak by to šlo přijímat pomocí BTLE donglu přes USB do počítače. Další možnost je zjistit, že uvnitř je normální MCU a ten odkazovaný MAX a flashnout na to vlastní FW. Další možnost je odsniffovat protokol s originálním příslušenstvím, nejspíš u takto levného zařízení nebude moc složitý, a napsat na to alternativního klienta. Ultimátní prasárna je grabovat obrazovku originální aplikace.

Dále se dělají hrudní pásy s Bluetooth nebo ANT+, to se taky dá připojovat do počítače (používají to cyklisti na trenažérech, které jim pak podle toho nastavují zátěž, simulují konkrétní dráhu, dělají takto závody přes internet a tak), ale vůbec nevím jak snadno se to programuje.

(nevěřím že se oxymetr píše s měkkým i, je to oxygen, že jo!)

Stran: 1 ... 61 62 [63] 64 65 ... 100