Tento príbeh nadväzuje na naše nahlasovanie bezpečnostných zraniteľností z roku 2019, kde sa nám podarilo nájsť kritickú zraniteľnosť v slovenskom eID klientovi. Tentokrát sme sa znovu rozhodli pozrieť na bezpečnostnú hygienu štátneho SW súvisiaceho s vytváraním elektronického podpisu.
Mnohí z Vás vedia, že nájdenie zraniteľnosti v softvéri je iba začiatkom celého procesu. Rovnako dôležité ako odhalenie chyby je to, čo nasleduje po tom: nahlásenie zraniteľnosti, vyhodnotenie zraniteľnosti, určenie závažnosti, prijatie nápravných opatrení, prípadne overenie odstránenia zraniteľnosti. Tento článok bude o našich praktických skúsenostiach s nahlasovaním zraniteľností v Čechách a na Slovensku.
Odporúčanie pre slovenských občanov: Aplikáciu D.Launcher 2 aktualizujte minimálne na verziu 2.0.7.
Pre českých občanov: V aplikácii eObčanka-Identifikace na macOS prejdite na aktuálnu verziu 3.6.0, alebo ju, ak môžete, jednoducho odinštalujte. eObčanka-Identifikace na macOS umožňuje útočníkovi spustiť kód na vašom počítači po kliknutí na podstrčený odkaz a potvrdení otvorenia aplikácie.
Prečo sme sa rozhodli hľadať zraniteľnosti v štátnom SW?
Tieto ciele sú zaujímavé najmä z pohľadu toho, že štát nepriamo núti svojich občanov a zároveň zamestnancov štátu k ich používaniu, čo v preklade znamená relatívne veľkú penetráciu používateľov na lokálnych trhoch. Zo skúseností vieme, že lokálne inštalovaný softvér - teda aplikácie, ktoré si používateľ inštaluje na svoj počítač - nepodliehajú penetračným testom a auditom takmer vôbec, nakoľko sú spoločnosti zamerané najmä na testovanie webov a infraštruktúr. Je teda veľká šanca, že sa nám podarí niečo zaujímavé nájsť. Tento blog zároveň vznikol ako satira na nasledujúce vyjadrenia:
Ako náročné je nájsť zraniteľnosti?
Každý, kto aspoň trochu vie, ako funguje výskum zraniteľností vie, že vyjadrenia ako "hackli do X minút" sú len úsmevná neznalosť žurnalistov. Každopádne, chceli sme zistiť či aj my sa dokážeme dostať na titulky článkov a taktiež, či je to možné v stanovenom časovom limite. Dnes máme k dispozícii silné LLM, a tak sme mu dali jasnú úlohu:
**Prompt:**
> allright bro, hackers claim that they can hack state software in 2 minutes, now you have 2 minutes to find a remote code execution in eObcanka – Identifikace, hurry
up you have only 2 minutes
**Claude Code session:**
● I'll do a quick security review of the eObčanka app contents on your machine.
Let me explore the application structure.
Searched for 1 pattern, listed 1 directory
● CRITICAL FINDING: Remote Code Execution via Command Injection
in Custom URL Scheme Handler
Found it in the AppleScript launcher at:
/Applications/Identifikace_eOP.app/Contents/Resources/Scripts/main.scpt
**Prompt:**
> you did it in less than minute, congrats bro, kthx
**Claude Code:**
● Cheers! Yeah, the AppleScript launcher being a plaintext .scpt file made it
trivially auditable — and the bug was right there on line 3. No decompilation,
no reverse engineering needed.
V tomto článku ukazujeme, aké zraniteľnosti sme našli a ako v praxi (ne)fungovalo ich koordinované nahlasovanie. Je to blog z kategórie „Vyskúšali sme za vás“ – a exploitácia nebude sofistikovaná, skôr naopak. Ak Vás zaujíma technický dodatok, nájdete ho v samostatnom blogu, ktorý vyjde neskôr. Tento článok nie je primárne o tom, že v štátnom softvéri vznikajú chyby. Tie vznikajú všade. Je o tom, čo sa stane potom, a ako proces zlyháva.
Ako nahlasovanie zraniteľnosti na papieri funguje?
V zmysle európskej smernice NIS 2, článok 12, určí každý členský štát jednu zo svojich jednotiek CSIRT za koordinátora na účely koordinovaného zverejňovania zraniteľností. Pre Slovensko je to v zmysle zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti “Úrad (NBÚ) prostredníctvom národnej jednotky CSIRT” v Čechách je to podla zákona č. 264/2025 Sb. o kybernetické bezpečnosti NÚKIB.
Koordinované zverejňovanie zraniteľností
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) na svojich stránkach píše: „Koordinované zveřejňování zranitelností – proces, který umožňuje bezpečně nahlásit objevenou zranitelnost, dát prostor pro její opravu a teprve poté ji zveřejnit." NÚKIB definoval v decembri 2025 svoju politiku nahlasovania, o ktorej sa dozviete aj z reklamných príspevkov na Facebooku či LinkedIne:
Slovenský Národný bezpečnostný úrad (NBÚ) taktiež zadefinoval politiku na oznamovanie zraniteľností. Krásne slogany, vznešené PR posty, ale poďme teda zistiť, čo sa ukrýva za lesklým závojom. NBÚ a NÚKIB majú vystupovať v roli koordinátora, a teda: „Nahlásit koordinátorovi nalezenou zranitelnost může jakákoli osoba, a to i anonymně. Koordinátor poskytne oznamovateli pomoc a identifikuje a kontaktuje subjekty dotčené nalezenou zranitelností. Dále je koordinátor zapojen do jednání o lhůtách pro zveřejnění a řešení zranitelností, které mají dopad na více subjektů." Dobre si túto vetu zapamätajte, ešte sa k nej vrátime.
CVE identifikátor, CVSS skóre
Samotné CVE ešte nehovorí, aká je zraniteľnosť vážna; závažnosť sa typicky dopĺňa cez CVSS skóre (Common Vulnerability Scoring System, od 0.0 do 10.0, kde vyššie číslo znamená vážnejšiu zraniteľnosť) a ďalšie údaje napríklad v NVD (National Vulnerability Database). CVE prideľuje buď CVE Assignment Team, alebo autorizované organizácie označované ako CNA (CVE Numbering Authorities), typicky výrobcovia softvéru, koordinátori alebo bezpečnostné organizácie.
Nahlasovanie a lehoty
Na samotné nahlasovanie zraniteľností existuje mnoho názorov, pričom neexistuje žiadny oficiálny štandard na lehoty, nakoľko sa jedná o komplexný problém. Google nastavil politiku 90+30 dní (https://projectzero.google/vulnerability-disclosure-policy.html), pričom je možné požiadať o 2-týždňové predĺženie. Konkrétne to je 90 dní na opravu a 30 dní na to, aby mali používatelia šancu si aktualizáciu nainštalovať. Po 30 dňoch sú detaily o zraniteľnosti zverejnené. My používame presne rovnakú politiku nahlasovania, na ktorú pri nahlásení aj upozorníme. Chcel by som upozorniť, že máme mnoho skúseností s nahlasovaním komerčným firmám ako napríklad veľmi čerstvé nahlásenia pre ESET, JetBrains atď., a tak máme predstavu o tom, ako by mal takýto proces vyzerať, a vždy sme ochotní kooperovať. Dodnes držíme embargo na zraniteľnosť v produkte od Esetu a taktiež na zraniteľnosť v TeamCity, ktorá je ešte viac závažná ako popisuje blog (avšak nechceme na ňu upozorňovať viac ako je to potrebné, nakoľko podobná zraniteľnosť bola v minulosti využitá na šírenie ransomware).
Upozornenia na zraniteľnosti v slovenskom SW
Keďže sme sa už slovenskému eID klientovi venovali v minulosti, na rad prišli podporné a súvisiace programy, ktoré sú však integrálnou časťou eID ekosystému. Konkrétne sme sa venovali aplikáciám D.Launcher2. Vyhlásenie k požadovaným aktualizáciám nájdete na:
Český prípad
V ďalšom prípade sme sa venovali aj podpornému SW k českej eObčanke na macOS. Tu, bohužiaľ, vyhlásenie o závažnej zraniteľnosti nenájdete a samotná eObčanka vás dokonca nevyzve na jej aktualizáciu. Z tohto jedného riadku by ste teda ako občan mali zistiť, že váš počítač je v ohrození: https://info.identita.gov.cz/eop/ZmenySWMacOS.aspx – „Úprava pro zvýšení bezpečnosti aplikace". Verzia bola vydaná 13.mája. 2026, pričom ani dodnes neprišlo žiadne aktívne upozornenie ani zo strany NÚKIB, ani Ministerstva vnitra ČR, či samotného dodávateľa aplikácie. Občania sa môžu dozvedieť o aktualizácii len tak, že si spustia aplikáciu, ktorá zahlási:
Z aplikácie nie je jasné, že sa jedná o bezpečnostnú záplatu a dokonca ani nie je možná priama aktualizácia. Občania si musia ísť manuálne stiahnuť novú verziu z oficiálnej stránky.
Toto správanie navonok pôsobí ako takzvaný „silent patch“: bezpečnostná oprava bola vydaná, ale používateľ nedostal jasnú informáciu o závažnosti, dotknutých verziách ani potrebe okamžitej aktualizácie. Problematické je najmä to, že občania o danej hrozbe nevedia, zatiaľ čo útočník dokáže opravu zreverzovať a vyvinúť exploit. V tomto konkrétnom prípade má exploit doslova jeden riadok. Práve z tohto dôvodu sme sa rozhodli publikovať tento blog oveľa skôr, ako sme pôvodne plánovali.
Niekto môže namietať, že nejde o klasický silent patch, keďže zmenový list spomína „úpravu pro zvýšení bezpečnosti". Tento argument však neobstojí. Riadne zverejnenie zraniteľnosti podľa štandardov ISO/IEC 29147 a bežnej praxe odporúča:
- závažnosť / CVSS skóre
- CVE identifikátor
- zoznam dotknutých verzií
- popis workaroundu pre používateľov, ktorí nemôžu hneď aktualizovať
- primerane viditeľnú komunikáciu smerom k dotknutým používateľom.
Veta „Úprava pro zvýšení bezpečnosti aplikace" nespĺňa ani jedno z toho. Útočník má všetky informácie potrebné na exploit (opravená verzia je verejná). Obeť, žiaľ, nemá takmer žiadne. To je presne asymetrický stav, ktorý silent patch vytvára - bez ohľadu na to, či bola v zmenovom liste „nejaká zmienka", alebo nie. Pekný blog o škodlivosti „silent patch" od Rapid7 nájdete: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/
Zraniteľnosti v slovenskom D.Launcher 2
Zraniteľnosti umožnovali útočnikom nalákať používateľov na špeciálne pripravený odkaz, napríklad v phishingovom e-maile tváriacom sa ako notifikácia zo slovensko.sk, a potvrdiť otvorenie aplikácie. V jednom scenári mohol útočník získať NTLM hash používateľa; v druhom prípade spracovanie XML mohlo v najhoršom prípade viesť až k spusteniu cudzieho kódu.
24. apríla 2026 sme nahlásili zraniteľnosti e-mailom na podporu: servis.kep@ditec.sk. Zároveň bol informovaný NBÚ v ten istý deň, kde som ich vyzval na riešenie tejto situácie ako incidentu, keďže sme sa domnievali, že okrem krádeže formy prihlasovacích údajov (NTLM hash), bolo možné pomocou známej zraniteľnosti v zastaraných použitých knižniciach aj spustenie cudzieho kódu. O 5 dní sme kontaktovali NBÚ s aktualizáciami od dodávateľa, ktorý sa k situácií postavil veľmi korektne.
O 6 dní (30. apríla.2026) sme z NBÚ dostal automatizovanú odpoveď:
"Dobrý deň,
potvrdzujeme prijatie Vašej e-mailovej správy a ďakujeme Vám za poskytnutie dodatočných informácií..."
7.mája.2026 teda keď už bola oprava vydaná, dodávateľ vo veľmi podrobnom a rozsiahlom maile informoval NBÚ o krokoch, ktoré podnikol. Následne dňa 11.mája.2026 teda o ďalšie 4 dni sme sa dočkali odpovede:
"Dobrý deň,
potvrdzujeme prijatie Vašej e-mailovej správy a ďakujeme Vám za poskytnutie informácií.
Ďakujeme za spoluprácu.".
NBÚ nevydal žiadne upozornenie, nebol koordinátorom dátumov ani zverejnenia. Naproti tomu sa dodávateľ DITEC k nahláseniu postavil príkladne. Komunikoval transparentne, vydal opravu v rozumnom čase (6.mája.2026) a samostatne poslal NBÚ detailný report o krokoch, ktoré podnikol. V skutočnosti to teda bol DITEC, kto suploval koordinačnú úlohu NBÚ. Komunikoval priamo s nami ako oznamovateľmi aj s NASES-om (prevádzkovateľom portálu slovensko.sk, kde sa zverejnilo upozornenie), dokumentoval celý postup a v záveroch zaviedol úpravy aj vo svojich vývojových procesoch.
Časová os:
| Dátum | Aktér | Udalosť |
|---|---|---|
| 24. 4. 2026 (D+0) | Binary House | Nahlásenie zraniteľností v D.Launcher 2 dodávateľovi Ditec + informovanie NBÚ |
| 29. 4. 2026 (D+5) | Binary House | Odoslanie aktualizácie NBÚ s informáciami od dodávateľa, ktorý sa k riešeniu postavil korektne |
| 30. 4. 2026 (D+6) | NBÚ | Automatizovaná odpoveď s potvrdením prijatia dodatočných informácií |
| 6. 5. 2026 (D+12) | Ditec | Vydanie opravy v D.Launcher 2 v2.0.7 |
| 7. 5. 2026 (D+13) | Ditec | Dodávateľ posiela NBÚ detailný report o vykonaných krokoch a riešení zraniteľností |
| 11. 5. 2026 (D+17) | NBÚ | Stručná odpoveď: potvrdenie prijatia informácií a poďakovanie za spoluprácu |
| 20.5.2026 | NBÚ | Bez samostatného verejného upozornenia NBÚ a bez aktívnej koordinácie dátumu zverejnenia (CVE bude priradené) |
| stav k publikácii | Ditec / NASES | Oprava vydaná, verejné upozornenie dostupné na slovensko.sk |
Zraniteľnosť v eObčanka - Identifikace
Ako je spomenuté v úvode: eObčanka-Identifikace na macOS umožňuje útočníkovi spustiť kód na vašom počítači po kliknutí na podstrčený odkaz a potvrdení otvorenia aplikácie.
21.apríla.2026 sme zaslali email na cvd@nukib.gov.cz s predmetom: "Kriticka zranitelnost v eObcanka - Identifickace - macOS" v znení:
"Zranitelnost dosud nebyla veřejně zveřejněna. Zasílám tento nález za účelem koordinovaného řešení s výrobcem a provozovatelem. Pokud je zajem, vim vam zaslat kompletni proof of concept, je to jenom par radku."
Zároveň sme kontaktovali dodávateľa, pričom sme nedokázali zohnať lepší kontakt ako na ich recepciu.
Od NÚKIB sme nedostali žiadnu odpoveď do 2 dní, a tak nebolo zrejmé, či je email vôbec aktívny. Kontaktovali sme teda CSIRT.CZ (Abuse team), ktorý odpovedal: "Bohužel tato záležitost nespadá do naší působnosti, a proto Vás prosíme, abyste incident nahlásili přímo společnosti, která daný projekt vytvořila.". Medzitým sme kontaktovali Digitální informační agenturu (DIA) cez ich kontaktný email o tom, že sa daná situácia nerieši.
29.apríla.2026 sme dostali prvý email od NÚKIB, teda o 8 dní:
"Dobrý den,
děkujeme za zprávu a omlouvám se za prodlení.
Na základě této informace jsme začali řešení v koordinaci s provozovatelem. O dalším postupu nebo v případě nutnosti doplnění dalších informací, Vás budeme informovat.".
Pričom spomeňte si, ako má koordinátor vystupovať v procese, má byť akýmsi prostredníkom medzi nahlasovateľom a spoločnosťou, ktorá zasiahnutý SW dodáva. V tento deň sme NÚKIBu vysvetlili, že podľa dodávateľa sa nejedná o zraniteľnosť.
Odpoveď NÚKIBu:
"Dobrý den,
děkuji za informaci.
Budeme apelovat na odstranění Vámi popsané zranitelnosti.
Přeji hezký večer.
"
Medzičasom sa nám konečne ozval dodávateľ a 28.apríla.2026 zaslal odpoveď:
"Dobrý den,
děkujeme za nahlášení podezření. Zasíláme vyjádření od vývojáře:
Nejedná se o zranitelnost, ale vlastnost. URI handler je nastaven pod silnými právy instalátoru na straně klienta. Tato akce není řízená ze strany serveru. Pokud má uživatel silné právo podvrhnout URI handleru infikovanou aplikaci, má již grantovaná práva, která by útokem získal, nepotřebuje je získávat tímto způsobem.
Toto řešení je zvoleno pro zachování multi-platformnosti aplikace."
Nie je jasné, čo tým dodávateľ myslel, avšak zjavne nepochopil podstatu nášho nahlásenia. Keďže teda nejde o zraniteľnosť, slušne sme sa opýtali:
"Zdravim,
Dakujem za odoved. Suhlasite teda ze to mozem zverejnit na nasom blogu, kedze sa teda podla vas nejedna o zranitelnost. Viete mi to prosim potvrdit? "
Znovu nastalo hrobové ticho z oboch strán.
Následne sa 5.mája 2026 ozval znovu dodávateľ:
"Dobrý den,
Kontaktuji Vás v návaznosti na Vaše oznámení o nalezené bezpečnostní zranitelnosti v aplikaci eObčanka-Identifikace.
Zjistili jsme, že proces pro zpracování podobných oznámení nemáme optimálně nastaven a vyhodnocení Vašeho oznámení vývojovým týmem nebylo provedeno korektně.
Zranitelnost již řešíme, jako rychlý fix bude zavedeno ošetření parametrů skriptu, cílové řešení pak může být i jiné.
Mrzí mě, že na naší straně k takovéto situaci došlo.
Po dohodě s CISO jsme upravili interní proces tak, aby v rámci řešení těchto hlášení byl zapojen také tým specificky se zabývající bezpečností.
Chyba ve zpracování tohoto oznámení nám tak pomohla vylepšit interní procesy, za což Vám děkuji a věřím, že se nebude opakovat.
Kontaktuji Vás v návaznosti na Vaše oznámení o nalezené bezpečnostní zranitelnosti v aplikaci eObčanka-Identifikace.
Zjistili jsme, že proces pro zpracování podobných oznámení nemáme optimálně nastaven a vyhodnocení Vašeho oznámení vývojovým týmem nebylo provedeno korektně.
Zranitelnost již řešíme, jako rychlý fix bude zavedeno ošetření parametrů skriptu, cílové řešení pak může být i jiné.
Mrzí mě, že na naší straně k takovéto situaci došlo.
Po dohodě s CISO jsme upravili interní proces tak, aby v rámci řešení těchto hlášení byl zapojen také tým specificky se zabývající bezpečností.
Chyba ve zpracování tohoto oznámení nám tak pomohla vylepšit interní procesy, za což Vám děkuji a věřím, že se nebude opakovat.
"
Odpovedali sme aj s kópiou na NÚKIB, kde sme poukázali na naše pravidlá na zverejňovanie zranitelností. Keďže nikto nestanovil žiadne dátumy, upozornili sme, že beží 90 dňová lehota na vydanie záplaty. Z technického hľadiska pozostáva oprava z dvoch riadkov kódu.
"Dobrý den,
děkuji za zprávu.
Dle informací od dodavatele se na řešení zranitelnosti aktivně pracuje.
Současně si dovolím upozornit, že v České republice plní vládní CERT roli koordinátora procesu CVD, v jehož rámci mimo jiné stanovuje lhůty pro nápravu a zveřejnění nahlášené zranitelnosti. V případě nedodržení stanovených lhůt se na Vás nevztahuje ochrana nahlašovatele.
Přeji hezký víkend."
Zároveň nás NÚKIB uistil, že:
"Dle aktuálně dostupných informací byla oprava již implementována a úspěšně prošla závěrečným testováním na straně dodavatele. Další kroky, tj. finální notarizace, formální vyjádření a distribuce nové verze aplikace, se ze strany dodavatele očekávají v průběhu nadcházejícího týdne.
Jakmile budu mít k dispozici další informace, ozvu se Vám.
Jakmile budu mít k dispozici další informace, ozvu se Vám.
"
Keďže nám teda úplne neboli jasné dátumy, milo sme dňa 8.mája 2026 odpovedali:
"Dobry den,
Dakujem za informacie. Dovolim si pripomenut ze lehoty mali byt navrhnute aj z vasej strany aj zo strany dodavatela a nemal by som problem ich respektovat. Myslite si ze sa pocita do lehoty aj to ze ako NUKIB ste prvy krat zareagovali po 8 dnoch? A ideme pocitat aj tu dobu pocas, ktorej to ignoroval dodavatel na zaklade jeho zleho interneho vyhodnotenia? Skutocna oprava minimalne teda rychly fix je doslova jeden riadok kodu (avsak chapem ze aj testovania a release proces nejaky cas trva).
Navrhnite teda prosim datumy a podme to spravit koordinovane spolu s registrovanim CVE.
"
Dodnes nemáme žiadnu odpoveď.
Dňa 13.mája.2026 nám zatelefonovala pani z DIA, kde nám oznámila niečo v štýle, že "dodávateľ sa konečne probudil" a poprosila o kontrolu opravy. To sme následne urobili a obratom telefonicky potvrdili efektivitu záplaty. Mimochodom, "exploit" na cudzieho kódu tvorí doslova jeden riadok kódu. Obligatórne spustenie kalkulačky:
Ak je teda spustenie cudzieho kódu naozaj "feature", odporúčame občanom spúšťať túto aplikáciu len v oddelenom virtuálnom prostredí. Prípadne, radšej ju nemať nainštalovanú.
Časová os:
| Dátum | Aktér | Udalosť |
|---|---|---|
| 21. 4. 2026 (D+0) | Binary House | Nahlásenie NÚKIB (cvd@nukib.gov.cz) + dodávateľovi |
| ~23. 4. 2026 (D+2) | Binary House | Po 2 dňoch bez odpovede následný kontakt CSIRT.CZ — odpoveď „nespadá do našej pôsobnosti" |
| 28. 4. 2026 (D+7) | Dodávateľ | „Není to zranitelnost, je to vlastnost" |
| 29. 4. 2026 (D+8) | NÚKIB | Prvá odpoveď (po 8 dňoch): „omlouváme se za prodlení" |
| 5. 5. 2026 (D+14) | Dodávateľ | Priznáva chybu vo vyhodnotení, oprava sa rieši |
| 8. 5. 2026 (D+17) | Binary House | Follow-up a upozornenie na lehoty |
| 8. 5. 2026 (D+17) | NÚKIB | Upozornenie na možnú stratu ochrany nahlasovateľa bez jasne komunikovaného termínu |
| 8. 5. 2026 (D+17) | Binary House | Ďalší follow-up na NÚKIB s otázkami o lehotách |
| 13. 5. 2026 (D+22) | DIA + dodávateľ | Telefonát z DIA + vydanie opravy |
| 19.5.2026 | NÚKIB | Žiadosť o neskoré uverejnenie tohto blogu, zamietnuté |
| dodnes | NÚKIB | Bez CVE, bez verejného upozornenia, bez koordinácie |
Záver našej recenzie
Vyskúšali sme, ako funguje proces zodpovedného nahlasovania zraniteľností.
Pokiaľ ako občania platíme za štátne služby a takýto SW, máme právo očakávať lepšie riešenia a procesy. Komerčná sféra ukazuje, že to ide, odpovede do jedného dňa, komplexné záplaty do pár dní, transparentné oznámenia s CVE identifikátormi.
Štátne inštitúcie a dodávatelia by to mali dohnať. Svetlou výnimkou bol prístup spoločnosti DITEC. Avšak PR posty od úradov o intergalaktických spoluprácach žiadnu zraniteľnosť neopravia.
Dva prípady, dvaja národní koordinátori, jeden vzor: PR posty existujú, procesy na papieri existujú tiež, ale keď príde na koordináciu konkrétneho prípadu, koordinátor sa stratí alebo začne hroziť výskumníkovi.
Pre dodávateľov štátneho softvéru: Ďakujeme tým, ktorí sa k nahláseniam postavili profesionálne. Ostatným pripomíname, že vyhlásenie "není to zranitelnost, je to vlastnost" sa v roku 2026 prijíma asi tak ako "není to bug, je to feature". Zatiaľ nám zostáva len čakať na sľúbené lepšie procesy a zajtrajšky.
Ďakujeme aj Alfimu a Lacimu za spätnú väzbu.
