OUTDOOR FÓRUM

Je to obryně Stáňa. ... Měli byste spolu malé obříky.

Zacínám být nato (asi) starý / opotřebený - neska od rána chaos kolem termínů velké zakázky, co fčíl dokončujeme, do toho změny ve dvou nabídkách (ve formátu EU = ca 50 stránek každá), fčíl půlhodinový telefonát s kolegou / známým v UK a.... sem hotový, mám dost, zhasínám, zamykám, du dom (za chvíli).

Korporace...

Mame novy hardware, je pro nej potreba rychle napsat firmware, posilame ti ho.
Za tyden: hw jsem dostal, ale nefunguje.
Aha, je tam opacne jedna soucastka, je to potreba predelat. Posleme ti nove predelane a ty nam posli zpatky ty puvodni.

Ping-pong mezi Taiwanem a Prahou, vsak o co jde Jesteze o tom nevi Greta

Něco je dramaticky špatně.... právě sem dokončil jednání s (novým) zákazníkem a.... když už získáme nového zákazníka, tak je to vždycky: daleko, jazyková bariera, nesmyslné obchodní a platební podmínky, arogantní nadřazenost velké firmy nad mou malou atd. Tady u toho to vypadá že: je zblízka, není tam bariéra, nemá nesmyslné požadavky a chová se způsobně/normálně. Něco je špatně, hodně špatně.

mike píše:na to ani nepotrebujes teorii her... Slusna prasarna. Jsou takove obchodni podminky vubec platne? Ale to je vlastne jedno, s evidentnima podvratakama smlouvy uzavirat nechces a soudit se taky ne.

It gets even better! Po očku jsem se na to díval a v dražbě samotné nikdo nepřihodil ani vyvolávačku 9M, až kdosi pár sekund před koncem (časový limit se pak vždycky natáhne na 5 minut, takže to je jedno). Kolik tam bylo lidí není na daném portálu vidět (na jiných to jde). Předpokládal jsem, že šlo o příhoz prodávajícího, aby někoho vyprovokoval anebo aby nebyl hned vidět, že to propadlo. Nu počkal jsem pár dní a zavolal maníkovi, jak to vypadá - a jestli by paní majitelka nechtěla jednat. Prý chtěla, neboť se to neprodalo (...) - ale cena by se měla pohybovat okolo té "odhadní", stanovené na 12,5M. Paní to prý za 9 ani 10 rozhodně neprodá. Na můj dotaz, co by se tedy stalo, kdyby to někdo vzal za tu vyvolávačku, mi bylo odpovězeno, že "takto dobrovolné dražby nefungují" - v tu chvíli jsem pochopil plnou funkci příhozů prodávajícího - buď dožene kupujícího tam, kde ho chce mít, anebo prohlásí dražbu za neplatnou.

Kdyby to nebylo na tak pěkném místě, ani bych to už dál nesledoval, ale takhle jsem to chtěl dořešit tak, abych neměl výčitky, že to třeba nějak šlo a já se na to vybodl. Jenže když jsem se tam byl podívat s kamarádem architektem*, tak po čtvrt hodině prohlídky řekl, že mu to stačí - a za plotem pronesl jediné slovo: "buldozer". A 20M teda fakt nemám

* časová osa je trochu zjednodušená, telefonátů apod. bylo více, a mezi tím i prohlídka

karaya1 píše:"takto dobrovolné dražby nefungují" - v tu chvíli jsem pochopil plnou funkci příhozů prodávajícího - buď dožene kupujícího tam, kde ho chce mít, anebo prohlásí dražbu za neplatnou.

Mne to teda nedava moc smysl. Na co si hrajou? Nejake psychologicke efekty? Nejak jim to nefunguje

Kazdopadne plati, co jsem psal, od takovych dal. Udelal jsem si tuhle zkusenost uz v 90. letech, nastesti nebyla moc draha, ale tahlo se to roky a prusvih hrozil docela realne. Kdyz si nekdo dava nestandardni podminky, tak pryc od nej. Bez ohledu na to, jestli potencialni problem vidis nebo ne, vsechny moznosti te nenapadnou.

karaya1 píše:za plotem pronesl jediné slovo: "buldozer". A 20M teda fakt nemám

To ses tam nebyl podivat predem, nez jsi uvazoval o te drazbe?

todle vypadá na zcela neregulovanou soukromou dražbu podle vlastních kovbojských pravidel

existuje institut veřejné dražb, má to svoji vlastní úpravu (zákon o veřejných dražbách) a kromě nedobrovolných dražeb (ty jsou mnohem častější) tam jsou upraveny i dobrovolné

pokud by někdo fakt měl zájem to transparentně prodat v dražbě, není důvod, aby nešel cestou dobrovolné, upravené, dražby - akorát bude muset splnit nějaká pravidla

Lipon píše:akorát bude muset splnit nějaká pravidla

Coz bude ten duvod

V korporaci se pri snaze dostat se do mnoha vlastnich systemu/webovych stranek se vzdy zobrazilo "zabezpecovaci okno" - vybralo se, jestli se chci overit PINem na kartu nebo jsou dve jine moznosti pro pripad problemu s kartou. Zadal se PIN a slo se.

Ted "securitaci" vymysleli vylepseni zabezpeceni. Kdyz se chci nekam dostat, najdrive automaticky vyskoci okna na zadani PINu ke karte. Zadam - a objevi se to puvodni zabezpecovaci okno, kde si mohu znovu zvolit, ze se overim kartou a PINem . Vyberu - zadam znovu PIN a jsem tam.

Stale premyslim, jaky to ma smysl... (krome mozne premie nejakemu tymu, ktery toto navrhl a zrealizoval)

Někdo si špatně vyložil význam multi ve výrazu Multi-Factor Authentication?

Podobne se mi jeste nedavno choval MS Autheticator. Nejdriv to chtelo PIN, pak jsem dal approve a chtelo to znovu ten samy PIN Puvodne stacil jeden, ale pak to "vylepsili". Ted to nastesti vylepsili doopravdy a chce to otisk prstu. Jednou. To je na telefonu nejpohodlnejsi zpusob.

Stěžuju si na ofiko distributora, dodavatele, či co to je přesně. Adidas, maj pod palcem i distribuce dalších značek.
Poslali mi vadný pár obuvi. Komunikace ok, musel jsem do copy centra vytisknout štítek a balík zanést na poštu. Že mi to vymění. Prdlajs. Poslali mi zpět to, co jsem jim poslal. Nebo že by měli 2 páry s na chlup stejným defektem /křivá podrážka/? Asi těžko. Levá bota sedí jak prdel na hrnec, pravá je křivá.
Tudíž znova do copy centra a na poštu
Už ale dostanu peníze zpět. Bez keců.
Jenže jinde ty boty nemaj. Že bych objednal jinej pár, zatímco tento vadnej bude na cestě? Nevím, na druhou stranu se mi do toho nechce, na pikaču vracení a evidentně zaměstnanci mající to na starosti mě měli na salámu a poslali křivý boty zpět jako "vyměněno"
Jediný důvod, proč Adidas není na black listu je ta komunikace, sice byla taková, mírně řečeno všelijaká, ale s ničím nedělali problémy.

Ja mel jednou Adidas AX2. Po kratsi dobe jsem zjistil, proc mi je neprijemne kousek pod kotnikem na jedne bote - byla tam cast vyztuze, nejaky "drat", ktery byl v ponekud jine pozici, nez by mel. Tj. ne spatny kus dratu, ale blbe vlozene do zbyle casti boty. Pred koupi jsem zkousel dve velikosti, toto jsem tehdy citil pouze u jedne. Kolega si par tydnu prede mnou koupil stejne boty o cislo vetsi - ten to tam mel taky dobre. Zasel jsem do prodejne, kde jsem si boty koupil, mezitim uz dostali ze skladu dalsi par te "me" velikosti - bylo to to same, jako na mych. Jeste jsem si to overil v dalsi prodejne, uplne jiny obchod - v te velikosti to same. Druha bota u vsech naprosto OK.

Takze klidne muze byt, ze minimalne jedna "varka" mohla byt udelana spatne - nekde nekdo neco blbe nastavil, vystupni kontrola to nezjistila (ten muj problem se nezjisti, kym se boty neobujou a jeste i chvili nosi), tudiz uplne vsechny boty maji stejnou vadu.
Z Tveho popisu tezko rict, jestli "Tva" zavada mohla byt zpusobena nejakym nastavenim pri vyrobe (krive nastavena forma, atd.) nebo je to evidentne kusova zalezitost. Kdybys to overil a zjistil ze to maji i nekde jinde, obavam se, ze bys musel potom hledat vyslovene jinou vyrobnou serii.

NTB, uz jsem videl - ale ne u Adidasu -, ze napr. pri nejake vyprodejove akce byly vsechny boty daneho modelu a velikosti (te velikosti meli hafo, jinych jen sem-tam ojedinely par) se stejne spatnou podrazkou. Tam to vyslovene vypadalo, jako by do formy neco vrazilo a udelalo tam prohluben, resp. hlubsi ryhu. Mozna to vetsine lidi nemuselo vadit, ale pokud chodil nekdo jistym zpusobem, tak najednou pri ohnuti se musel "propadnout o 2-3 milimetry.

Jinde koupit nejdou. Počkám na další sérii... Je mi jasný, že to může být chyba celý řady třeba 100ks, ale že by o tom nevěděli? Nebo o tom ví, ale chtěj to i tak prodat? To je fuk, každopádně tut na nějakej čas útrum..

Etheric píše:Levá bota sedí jak prdel na hrnec, pravá je křivá.

Mám to u všech svých bot LaS stejně, levá sedí a pata se v ní nehýbe/netlačí do strany, na pravé ta pata nesedí a tlačí se dovnitř/dostrany. Není to ale botama, ale mou patou resp. kotníkem doyebaným při úrazu na silvestra 1987. Neměls taky nějaký úraz na noze?

Jde o křivou podrážku, což je znát i z položení na stůl, oproti tý levý. Křivá bota, nic víc, nic míň.
Objednal jsem 2 verze, s a bez gtx. Identická bota, rozdíl v membráně. Na těch bez membrány podrážka křivá neni

Etheric píše:Poslali mi zpět to, co jsem jim poslal. Nebo že by měli 2 páry s na chlup stejným defektem /křivá podrážka/?

Klidne. Viz treba jak jsem psal o VJ Sport botach, prisla pulka vadnych a to dost podobne. Tam na to prisli uz v prodejne a posilali je zpatky. Tady zrejme popadli druhou krabici a nijak nezkoumali, co v ni je. Prijde mi to podstatne pravdepodobnejsi, nez ze by ti poslali znovu ty same. Nenapada mne duvod, proc by to delali, leda kdyby se nekdo spletl.

Priste si tam nekde udelej nenapadnou znacku a budes mit jistotu

Po nekolika letech jsem potreboval vterinove lepidlo a ne gel, ktery pouzivam normalne. Samozrejme nova tuba, vsechny stare vyschly. Otvira se tak, ze se spicka dotahne a prorazi plisek na tube. Tupy tlak, ktery chce samozrejme silu a dopadlo to podle ocekavani, ac jsem si daval bacha. Aspon jsem prsty nedal k sobe, takze je nemam slepene, jen na nich mam tenky povlak lepidla. Ktery debil tohle vymyslel? Pritom by to stacilo uplne normalne prorazit hrotem, jak to maji treba zubni pasty...

Nas Security Team uz uplne spadl na hlavu... Nebo nekdo chce vervomoci zbavit korporaci jedne ze zivotne dulezitych aplikaci.

Ted prisel od nich mail, kde popisuji, ze udelali "dukladnou analyzu teto aplikace jako Black boxu"... A "nasli" nejakych 9 nebo 10 zavaznych bezpecnostnich chyb.

Typu:
- Muze se utocnik prihlasit do aplikace pouze s "hashem" hesla bez znalosti samotneho hesla. Predpokladem je, ze se dostane k tomu hashu. (Co uz nepisou - ta tabulka je ulozena zasifrovana pod heslem admina dane aplikace. Navic se utocnik musi dostat na server, kam maji pristup jenom domenovi admini a nas lokalni admin, co pouzivame pro aplikac, tj. potreba druheho hesla.)

- Utocnik muze spustit z podaplikace libovolny prikaz Perlu. Predpokladem je, ze se prihlasi do aplikace, k cemu muze pouzit hash hesla. (Co se nepise, viz vyse - musi pristup pres dve hesla. Kdyz se ale uz dostane na server, tak si muze spustit jakykoliv prikaz Perlu primo z operaku, nemusi si tam spoustet tu aplikace, neto jeste podaplikaci .)

Atd...

Nejlepsi na tom je, ze tuto aplikace ve velkem pouzivaji armady, bezpecnostni slozky (vcetne tajnych a bezpecnostnich sluzeb), korporaty, kde "je bezpecnost na prvnim miste (opravdu, ne jenom deklarovane!), atd., kde se pred nasazovanim i v prubehu pouzivani delaji mnohem dukladnejsi bezpecnostni proverky.

Mne teda oboji prijde jako security problem a mozna i pruser. Ze to pouzivaji nekde jinde a ze jim to proslo je nepodstatne. V tehle oblasti se nehraje na autority, ale na realitu. Bud tam problem je nebo neni a ze ho predtim nenaslo tisic auditu vubec nic neznamena. Mame pripady, kdy cely svet dlouha leta neco v pohode pouzival a pak tam nekdo nasel a zneuzil opravdovy pruser (priklad: heartbleed bug). Situace je naprosto asymetricka, je to podobne, jako u vedeckych hypotez. Priklad: na zaklade pozorovani si udelas hypotezu, ze vsechny labute jsou bile. Miliony pozorovani bilych labuti hypotezu potvrzuji, ale nedokazuji. Jedine pozorovani cerne labute ji vyvrati.

Co se hashe tyce, tak neni moc podstatne, jak bezpecne je ulozeny. Ve spravne udelanem systemu muze byt i verejny a utocnikovi to neni nic platne. Prave proto, ze hash sam o sobe nesmi stacit, je jen na potvrzeni, ze uzivatel se prihlasuje spravnym zpusobem tj. zna heslo a pripadne dalsi veci. Z toho se vygeneruje hash a ten se porovna s ulozenym. Coz neni to same, jako pouzit primo hash. Je to mj. i prevence proti zneuziti adminy, kdyby pouzili primo hash, tak veskera cinnost bude vypadat, jako bys ji delal primo ty. Pripadne muze byt admin vydiran, pouzito proti nemu socialni inzenyrstvi atd.

Udelat spravne bezpecnost neni nic jednoducheho a prvoplanove pristupy zdaleka nestaci. Mozna ti k tomu neco napise karaya1, je to jeho job.

No, hlavně teda nechápu, proč ta hesla hashujete, když se pak jde přihlásit tím hashem, to je pak úplně zbytečný. Jestli ti to nepřijde jako problém, tak ti asi uniká podstata, jak by to mělo všechno fungovat. Kdyby na tohle security team neupozornil, tak by to nebyl úplně security tým, že jo.

Jinak hash se dneska generuje z hesla + dalšího řetězce (sůl - salt), aby se předešlo nějakým slovníkovým útokům.

Uplne ne, hash jako uzivatel nezadas, musel by sis na to napsat programek, ktery se primo pripoji k tomu serveru a preda hash spravnym protokolem, coz nemusi byt uplne snadne. Ale v principu mas samozrejme pravdu, z hlediska security to vyjde nastejno. I v tom, ze apukovi unika podstata, ale to neni nic neobvykleho

Na druhou stranu, veci maji svuj vyvoj, pred 25 - 30 lety by mne tenhle pristup uplne neprekvapil, tehdy fungovaly i podstatne jednodussi utoky. I ten salt se pridal az pozdeji prave v reakci na slovnikove utoky.

apuka píše:- Muze se utocnik prihlasit do aplikace pouze s "hashem" hesla bez znalosti samotneho hesla. Predpokladem je, ze se dostane k tomu hashu.

Tohle je určitě problém, někdy se tomu říká Pass the hash. Chápu, že silné jednosměrné funkce odolné proti paralelizaci "sežerou" spoustu výkonu serveru a je snaha přesunout počítání hashů na klienty (pokud to vůbec je tento případ ), ale tím se pak stane původní hash novým heslem. Vždycky je nutné na serveru to ještě jednou přehashovat, teď už klidně nějakou rychlou funkcí.
Je jedno, že je složité se dostat k hashům hesel (to by ostatně mělo být samozřejmé), tohle v dobrém systému být nesmí. Navíc není třeba ani nějaká složitá změna, aby to bylo v pohodě.

apuka píše:- Utocnik muze spustit z podaplikace libovolny prikaz Perlu.

To by se mi taky nelíbilo - předpokládám, že to není feature, ale bug. Pak tam cítím něco jako špatnou validaci vstupu a to je vždycky problém, nehledě na to, jak těžké je vyrobit exploit*.

Zajímal by mě ten zbytek - a taky když našli tohle jako black box, co by našli jako white box s přístupem ke zdrojákům

Obecněji: práce pentesterů je přesně toto, najít díry a potenciální hrozby. Nicméně to neznamená, že se daná aplikace musí okamžitě vypnout. Pracuješ s nějakým rizikem a k tomu máš k dispozici různé strategie. Můžeš ho ignorovat (a dopadnout jako Equifax), můžeš ho minimalizovat (pofixuješ chyby v aplikaci, resp. donutíš vendora, aby to udělal), můžeš ho přenést (třeba na pojišťovnu - to jsou teď ty "zábavné" soudní spory o to, kdo bude platit milionová výkupné ransomware gangům), můžeš nastavit další kontroly (to je váš případ - aplikace běží na serveru přístupném jen adminům atd.)... Když kontroluješ čistě aplikaci, hledáš díry v ní. Je možné, že způsob nasazení a další kontroly okolo riziko zneužití děr snižuje natolik, že bude akceptováno. Ale v principu je report správný a správně.


Pozn*. nedávno jsem četl fascinující rozbor Pegasusu - to je ten zero-click exploit na iOS. Šlo o to, že Apple měl chybu v parsování PDF souborů v iMessage, která umožňovala namapovat novou paměť, zapisovat do ní instrukce a ty pak spouštět. Jenže aby bylo co spouštět, museli si útočníci v dané části paměti instrukce vyrobit - začli od hradel a z nich přímo v paměti vyrobili "něco jako javascript", zapsali instrukce v něm a spustili.

Ja jsem puvodne nechtel jit do vetsich podrobnosti, ale alespon trochu bude treba.

Je mi naprosto jasne, ze obe chyby jsou za beznych okolnosti problem. Ale tady je to prece jen neco jineho.

Nize uvedene plati pro oba spomenute problemy:

1) Bezi to na servru, kam se muze dostat (pres Remote Desktop Connection) pouze "nas" administrator a lidi z DC. Nikdo jiny, tam uz jsou potom jen asi 3 lokalni ne-admin uzivatele, ktere na RDC nemaji pravo, jsou to specialni "vlastni" uzivatele pro nejake mensi aplikace s minimalnimi pravy. Aplikace bezi pod nasim administratorem.
2) Server je odriznuty od internetu a siti vubec, krome pevne definovaneho jedineho (nestandardniho) portu a to jenom z nekolika jinych konkretnich servru, odkud se tam posilaji pozadavky na zpracovani (na ty servry se zase na OS nedostane jen tak nekdo, i my jako admini mame obcas problem). Ty chyby nasli pri spousteni aplikace/podaplikace pres browser z daneho servru jako localhost:xxxx. Ten port je ale zvenku zakazany a aplikaci pres jiny port nespusti.
Plus je umozneny prenos tiskovych souboru pres standardni LPR port. Pres ten taky nic u nas nespusti a ten aplikace nesleduje.
3) Do te aplikace se jako admin muze hlasit jediny konkretni uzivatel, vsichni ostatni mohou mit jen read-only prava. Tj. ziskanim hashu se sice dostanes k precteni nastaveni, ale nic vic, zmeny tam neudela. Navic tato aplikace neloguje prihlasovani ani provedene zmeny, takze kdyz uz se dokaze prihlasit jako admin, aby dostal hashe hesel, tak je to zbytecna prace. Plus viz dalsi body.
4) Vsechna nastaveni jsou delane jeste klasickym Unix pristupem, vse je v textovych konfiguracnich souborech - nezaheslovanych, nesifrovanych. Tj. kdokoliv, kdo se dokaze na server prihlasit, ma jednoduchou moznost si ty konfiguracni soubory nejenom cist, ale taky menit - bez toho, aby se musel "pretvarovat", ze to delal pod jinym uzivatelem. Bude to vzdy pod stejnym adminem.
5) Existuji v systemu i "volne pristupne", heslem nechranene aplikace, pres ktere se da i mimo OS level dostat ke vsem informacim jako v te kritizovane aplikaci. Dokonce se nektere z nich daji i nastavovat. Zase predpokladem je, ze se clovek dostane na server pod nasim adminem.
6) Heslo na RDC pristup i na toho admina aplikace na server jsou sdilene, protoze se o nej vzdy starala nejaka skupina lidi (podpora 24/7). Tento princip byl schvalen security oddelenim...

Tj. shrnuto - ve vseobecnosti ty vycitane problemy nejsou OK, ale v teto konkretni situaci (a to je situace, jak cela ta aplikace ma definovane, ze ma byt system, na kterem bezi) vytykane problemy nijak nedotykaji bezpecnosti dat ani samotne aplikace. Pokud neco by bylo na vytknuti kvuli bezpecnosti, tak by to mohl byt bod 6, ktery je jediny realne nebezpecny - ale ten jim nevadi.
Abych tak rekl, je to priklad ze mas neco na svem izolovanem, do site nepripojenem PC, kde mas pouze sveho jedineho uzivatele. Mas tam sice bezpecnostni diry, ktere by utocnik zvenci mohl zneuzit, ale k tomu se potrebuje dostat na Tvuj PC a to jen tak, ze si k nemu sedne a prihlasi. Tj. kdyz prekona "veskere zabezpeceni".

Navic je tady jeste jedna ne uplne zanedbatelna vec:
7) cely ten system bezi tak ja je ted minimalne 7 let, spise nekter servry od r. 2012, jine od 2005-2007 ale na nich doslo casem k upgradu na stejnou verzi jako bezi od 2012. Tj. alespon 10 let nikomu nevadilo.

Ono to jeste nejsou vsechny detaily vyse napsane, jsou i dalsi zalezitosti, ktere brani zneuziti zvenci - ale nebrani, kdyz se nekdo na server prihlasi.

karaya1 píše:Vždycky je nutné na serveru to ještě jednou přehashovat, teď už klidně nějakou rychlou funkcí.

Tohle ti přece nijak nepomůže, ne? Když ti klient předá hash, tak když ho přehashuješ, ničemu to nepomůže.

Hafi píše:Tohle ti přece nijak nepomůže, ne? Když ti klient předá hash, tak když ho přehashuješ, ničemu to nepomůže.

Útočníkovi pak ale nestačí hash, co máš uložený v DB, musí nalézt kolizi. Pokud dešifruje komunikaci klient-server a odchytí hash, tak to nepomůže (pokud to není nějaký challenge-response protokol).

apuka píše:Je mi naprosto jasne, ze obe chyby jsou za beznych okolnosti problem. Ale tady je to prece jen neco jineho.

V roce 2011 se taky stalo něco, co se stát nikdy nemělo - Číňani ukradli z RSA seedy do jejich HW tokenů. Systém, kde byly uloženy, byl taky superizolovaný až na jeden jediný API endpoint dostupný z jednoho jediného místa pod jedním jediným uživatelem.
Jo, v RSA udělali chyby (nemonitorovali onen endpoint na počet požadavků, ostatně celkově by ta architektura šla udělat tak, aby tam ten endpoint ani nebyl), ale třeba si taky mysleli, že "tady to je přece jen něco jiného". A aniž bych srovnával důležitost/cennost RSA a vaší korporace (ani nevím, která to je ), tak přístup "je to složitě dostupné i pro nás, tak co teprve pro útočníka" není ideální.
Ale to už je na hodnocení rizik a ISO 27001 - a od toho je radno se držet co nejdál

Vsak mne slo prave o to, ze zrovna v tomto pripade, kdyby se mely vyhodnotit skutecne bezpecnostni hrozby, tak jsou tam jine s radove vetsim vyznamem - napr. ty sdilene ucty, navic uz mimo korporaci (bo externi support), kam na to nikdo nevidi (ale je to ve financnim zajmu firmy, alespon si to zatim vedeni tak mysli

Druhou veci je, ze pres ten server se dela konverze a tisk dokumentu, pricemz ty realne citlivemse zpracovavaji nekde jinde jinym zpusobem. Takze - za mne - by cena za pripadne ziskani nejakych dat byla v pomeru k jejich uzitecnosti ponekud mala. A to neberu do uvahy, ze kdyz uz se nekdo dostane na server, nemusi vymyslet zadne slozitosti a jednoduse si dane data ziska jako soubory OS.
Stejne tak, pokud by chtel zaskodnicit znemoznenim pouzivani, tak to taky udela naprosto jednoduse. Navic dokumentace k danemu systemu je verejne dostupna, vcetne tech dulezitych nastaveni.

karaya1 píše:Chápu, že silné jednosměrné funkce odolné proti paralelizaci "sežerou" spoustu výkonu serveru a je snaha přesunout počítání hashů na klienty (pokud to vůbec je tento případ )

O tom silne pochybuju Aby se neco takoveho vubec muselo resit, tak bys tam musel mit nevim kolik (tisice?) prihlaseni za sekundu. Spis to vypada na nejaky zastaraly system a design chybu z dob, kdy se na to jeste moc nehledelo.

Jinak nevim jak ostatni, ale ja uz jsem se v apukove popisu ztratil a cele mi to nedava smysl. Coz mne neprekvapuje, jestli nekdo dokaze cokoliv zamlzit spoustou nepodstatnych detailu a dovedne se vyhnout postate problemu, tak je to on Spis bych ale veril tem, co ty testy zadali a delali, asi k tomu byl nejaky duvod.

mike píše:jestli nekdo dokaze cokoliv zamlzit spoustou nepodstatnych detailu a dovedne se vyhnout postate problemu

Hm, zase je reco kvuli recem.... Kde mas tady nejaky "nepodstatny detail" a "vyhnuti se podstate problemu"???

Ale nedivim se TI, ze se ztracis - ono jsou totiz nektere systemy pomerne slozite (ja jsem zdaleka nepopsal plne zpusob funkcnosti ) a pospletane. Ty delas jinou praci, ktera je - z tohoto hlediska - pomerne jednoducha, ja se musim venovat spolupraci systemu, kde je ta spolupraca casto hodne zamotana a jde pres mnoho IT oblasti, samozrejme se soucinnosti vice technicky uzce specializovanych tymu.

Abys mohl byt trochu vice v obraze, tak specialne pro Tebe napisu jeste jednou "podstatu problemu" - Secu team otestoval izolovany server na problemy s moznym vzdalenym spoustenim kodu a pristupem, ktere mohou byt silne nebezpecne. Jenze tady ten vzdaleny pristup je zablokovany a vsechno testovane se da udelat pouze lokalne primo ze servru - na to "zapomeli". No a kdyz uz se "nejak" dostanes na ten server primo, tak muzes udelat vse, co tim vzdalenym "hacknutim" pohodlne bez sloziteho vymysleni.

apuka píše:Kde mas tady nejaky "nepodstatny detail" a "vyhnuti se podstate problemu"???

Na to bych musel ocitovat cely tvuj dlouhy prispevek, ale to tady nedelame

apuka píše:Secu team otestoval izolovany server na problemy s moznym vzdalenym spoustenim kodu a pristupem, ktere mohou byt silne nebezpecne. Jenze tady ten vzdaleny pristup je zablokovany...

A proto vyse pises o pristupu pres remote desktop

No, tohle nema cenu, precti si odkazy, co ti daval karaya1 vyse a neres veci, kterym nerozumis