Ako sme „hackli“ eKasu: podvádzať na daniach nikdy nebolo jednoduchšie -

1 Like

Ja som tusil, ze take nieco tam bude schovane. Len som to nevedel najst.

Presne, ako monopol na ŠPZ. Kritériá pre konštrukciu CHDÚ sú pomerne presne špecifikované finančnou správou, priestor na kreativitu pri tvorbe riešenia sa tým výrazne zmenšuje. Akýkoľvek výrobca pokladníc, ktorý chce použiť vlastnú hardvérovú variantu CHDÚ, okrem tej technicky a konštrukčne nedotiahnutej od spoločnosti CHDU, s.r.o., vďaka tejto prihláške certifikát nezíska.

Aby mohla pokladňa predávať iba online je nereálne. Vieš si predstaviť ako vyháňajú ľudí z TESCA a naplnené košíky tam musia nechať, lebo im vypadlo internetové spojenie? VRP funguje iba online, ale ta sa používa iba v malých prevádzkach. Tie počas nefunkčnosti VRP môžu predávať na paragony. A štát je spokojný s tým, že im verí, že tie pragony dodatočne zaevidujú. Pri ORP (to je eKasa s CHDÚ) taku doveru nemá a preto je tam CHDU, ktoré by malo zabezpeciť offline predaj.

To asi nemala byt reakcia na mna. Ja viem, ze cisto online je pre masove pripady nevhodne.

1 Like

Dakujem. Aj som mal rozpisany prispevok na tuto temu (eticki hackeri), aj som ho nakoniec zahodil, aby nebol brany ako nenavistny (tzv hate). Potesili ste ma, ze nie som sam kto si to uvedomil.

1 Like

Toto je dokument, ktory je v celom vlakne najpodstatnejsi a nedostalo sa mu este dost pozornosti.

Ak to spravne citam tak, su dve moznosti:

  1. bud CHDU a PPEKK je jeden zaliaty kus (a bude to mat asi uplne ine zranitelnosti)
  2. alebo je to odpojene od seba, malo to byt sifrovane (moc by to nepomohlo) a tymto sa zaoberala Nethemba.

Mohli by sme rozobrat aj tu 1.

1 Like

Alebo este konkretnejsie:

image

Bod 2. mi nedava vobec zmysel.

Ahoj,

ako faktor fyzickej bezpecnosti (ze musis rozbit material v ktorom je to
zaliate fyzicky, teplom, alebo chemicky) robi utok na CHDU neprakticky,
lebo je to vela roboty a hrozi riziko poskodenia CHDU.

Ostava potom len utok na klienta (PPEKK) so vsetkymi vektormi. Napr. sa
ti podari ako vyrobcovi zacertifikovat “binarny obraz” PPEKK ktory
loaduje libku ktoru nepotrebuje a potom mu ju z OS podhodis.

Obidve skupiny vektorov su ale u uroven zlozitosti vyssie, ako to co
popisala Nethemba (odpojit a pripojit bez nasledkov lebo vynimka z
pravidiel).

Pri cenach ekasy je lahsie kupit ekasu s udelenou vynimkou na externe
ulozisko od CHDU.

Keby v specke nebola podmienka nesifrovat data na CHDU a zaroven by bola
bez vynimky vyzadovana podmienka sifrovat komunikaciu na fyzicky
oddelene CHDU, tak by to cele vyzeralo daleko menej zle.

r.

1 Like

Ano, to vyzera akoby sa niekto snazil v specke pokryt scenar kde mas k
pocitacu pripojene nieco ako fiskalny modul ktory sa neda bez porusenia
plomby odstranit.

Pravdepodobne (cista spekulacia) to bude zapracovana pripomienka
vyrobcov legacy registracnych pokladnic.

1 Like

Napr. tato argumentacia FS je podla mna trochu poslabsia, nepredpokladam, ze pokladnice maju neustale monitorovane bezpecne pripojenie na FS, ale proste posielaju requesty. Cize

  1. Poslem legit blocek, FS zaeviduje, vytlacim. vsetko legalne.
  2. Stlacim gombik, request na FS nejaky firewall/proxy proste zahodi, CHDU ide cez emulator, vytlacim fiktivny blocek. Stlacim gombik. Na doklady sa zabudlo.
  3. FS nevidi absolutne nic o ziadnom offline rezime. Pokracujem dalej.

Ak je tam nejake novum, preco nie. Ale ak ide iba o zmontovanie vseobecne znamych komponentov a funkcionalit aby to nieco konkretneho robilo, potom je tvoja otazka na mieste.

ano, to by slo.

Zavisi, aky protokol zaviedol FS. Ci musi PPEKK hlasit do FS, ze naposledy neuspesne odoslalo nejaky blocek a ze bola nejaku dobu v offline rezime.
Ak sa ale PPEKK spolieha na udaje v CHDU, tak potom nemusi nikto nikdy zistit, ze bola v offline.

Ten bod 2 nie je v pripade tychto pokladnic splneny. Sice CHDU od CHDU je odchytavac tlace, ale zjavne nevie CHDU ako samostatny funkcny celok nebol schopny zabezpecit ulozenie vsetkych tlacovych vystupov, lebo nema kontrolu nad komunikaciu z PPEKK.
A nesplna ani bod 4.

Malo by to patrit do bodu 3, lebo komunikacia prebieha cez komunikacne linky v pocitaci, kde moze byt MITM.
Mne to pride, ze budu musiet nakoniec zrusit tu certifikaciu a opravit vsetky pokladnice a nanovo spravit certifikaciu.

1 Like

Bolo by fajn zistit, ze ktore z tychto este idu cez ktory bod. https://www.podnikajte.sk/dane/pokladnice-ekasa

Konkretne rozhodnutia o certifikacii som nenasiel.

Pravdepodobne najaktualnejsi zoznam rozhodnuti je:

https://www.financnasprava.sk/_img/pfsedit/Dokumenty_PFS/Podnikatelia/eKasa/2019/2019.10.15_dat_uloz.pdf

Zaujimavy zvysok je na:

https://www.google.com/search?q=filetype:pdf+site:https://www.financnasprava.sk/_img/pfsedit/Dokumenty_PFS/Podnikatelia/eKasa/2019/

r.

Mňa by skôr zaujímalo, že prečo je v aplikácií “Over doklad”, vytvorenej za účelom overovania dokladov evidovaných v systéme e-kasa pomocou naskenovania QR kódu vytlačeného na doklade, uvedený rok 2015. :smiley:

Ten výrobca je Ing. Štefan Genšor z Námestova, stojaci za (už teraz bývalým) fiškálnym modulom FisBox. Je uvedený ako autor prihláseného úžitkového vzoru na CHDU:

Inak ešte tu je jedna zaujímavá (pod)kauza - firma VAROS TRADE z BB doteraz nezískala certifikáciu na ich CHDÚ riešenie, vraj na nich niekto podal anonym, že tam majú skrytý backdoor. Riešia to cez súdnych znalcov, lebo vraj FS nevie toto tvrdenie potvrdiť ani vyvrátiť (ako teda vedia vôbec certifikovať ostatné CHDÚ?). Iní zas tvrdia, že niekomu vyhovovalo, ak VAROS ako 3. najväčší výrobca na Slovensku nezíska certifikáciu. Problémy s certifikáciou mal aj 2. najväčší výrobca (firma BOWA z BA), dostali ju až tesne pred 1.7., teda pôvodným termínom zavedenia eKasy.

Navyše certifikáty pre všetky eKasa pokladne sú vydávané certifikačou autoritou z Česka (První certifikační autorita, a.s., https://www.ica.cz/)…

2 Likes