Slo-Tech - V francoskih trgovinah so se danes spopadli s hekerskim napadom na njihove hladilnike, zaradi česar so morali zavreči hrano, ki se je nedopustno segrela. Doslej so za francosko tiskovno agencijo verige E. Leclerc, Intermarche in Cooperative U potrdile, da so bile žrtve napada. Po besedah predstavnikov Cooperative U podobnega napada v preteklosti ne beležijo, predvsem ne tako ciljanega.
Prizadetih je bilo več sto trgovin, v katerih naj bi se hladilniki segreli vse do 50 °C. Hekerji so poleg spremembe termostatov izklopili tudi sisteme za opozarjanje na porast temperature, zato so bili hladilniki več ur pregreti. Po nepotrjenih informacijah so izkoristili ranljivosti v programski opremi za krmiljenje in sprožili programe za odtaljevanje.
Danfoss je potrdil, da so bili prizadeti njihovi starejši sistemi AK-SM800 in AK-SC355 ter neposodobljeni AK-SM800A. Na internetu je dostopnih približno tri tisoč naprav s to programsko opremo, med temi polovica v Franciji.
Lani so v teh napravah odkrili več ranljivosti (CVE-2025-41450, VE-2025-41451, VE-2025-41452), ki so bile sicer odpravljene, veliko lastnikov hladilnikov ni namestilo posodobitev. Trenutno kaže, da so hekerji pridobili dostop do nezakrpanih sistemov. Strokovnjaki so že avgusta opozarjali, kako jih je mogoče izkoristiti v praksi.
Varnostni šef bo to konkretno plačal. Razen seveda, če ne gre za kritično infrastrukturo. Verjetno pa zavarovalnica ne bo imela veliko dela z iskanjem razloga, zakaj ji ne bi bilo treba plačati. Bomo videli, kako je to izvedeno...
Smešno je,
da po skoraj petih letih še vedno rusophrenik nisi sposoben opredeliti,
pod kakšnimi pogoji zmagujemo v Ukljani.
veliko lastnikov hladilnikov ni namestilo posodobitev.
15 let nazaj smo se zgražali takim stavkom,
danes pa: Prav ti je!!
Pravilneje bi bilo, da so bili prizadeti nadzorni sistemi hladilnikov.
Kakšno pamet rabiš pri hladilniku? Podvojeno tipalo za nadzor temperature in javljanje, kadar je izven območja, meritev porabe, daljinski vklop/izklop luči, predvidevam, da imajo tile trgovinski še defrost funkcijo za hitro odtalitev in čiščenje, in vse skupaj gre na centralni nadzorni sistem, da ne rabiš vzdrževalca na objektu.
So torej napadli vsak hladilnik posebej ali centralni nadzorni sistem?
Kaj bo naslednjič? Množični vklop pirolize v pečicah?
Modeli so že sposobni, ampak mu moraš to povedati.
Torej mora programer samo zalaufat deep research o vseh zadnjih varnostnih tveganjih povezanih s projektom in dobrimi praksami, in mu rečt naj iz tega sestavi prompt za agenta, ki potem to tudi upošteva skozi celoten proces developmenta. :)
Potem imaš pa še drugega agenta, ki ti tedensko zalaufa deep research, nove ugotovitve primerja z codebase in naredi report, če je kje kakšno varnostno tveganje. Zadevo po potrebi updejtaš oz. dovoliš agentu da naredi to sam.
Ga ni človeka, ki bi po peš poti naredil projekt bolj secure. Razen če ta človek načrtno išče nove, neugotovljene luknje.
10 let nazaj stranka na internetni oblak vendorja priključi diskovno polje: "kaj jamraš, to vsi tko delajo... ful je benefitov"
10 let nazaj stranka na internetni oblak vendorja priključi UPS server sobe, niti po kitajsko se ne da dopovedati, kakšna tveganja to predstavlja. Prepirati sem se moral, da so vsaj tega dali v svoj segment.
No, enkrat pa tehnični dolg nespametnih odločitev priraca za tabo...
Sicer osebno se ne bi na to zanašal in bi zadevo pred produkcijo preveril, ampak zadnji modeli že dolgo ne delajo takih osnovnih napak.
Napak? Odvisno, kaj mu naročiš. "Daj geslo na spletno stran".
Sem ga vprašal -> če ti naročim: "Daj geslo na spletno stran", kako si ti to razlagaš?
Razumel bi kot: »Zakleni dostop do spletne strani, da lahko njeno vsebino vidi samo nekdo, ki pozna geslo.« Privzeto bi predpostavil eno skupno geslo za celotno stran, brez posameznih uporabniških računov. Z varnostnega vidika bi to pomenilo: - Preverjanje na strežniku: zaščiteno vsebino pošlje šele po uspešnem preverjanju gesla. - Zaščito vseh poti do vsebine: tudi neposrednih povezav do podstrani, zaščitenih datotek in podatkovnih vmesnikov. - Geslo zunaj javne kode: obiskovalec ga ne more prebrati v izvorni kodi ali JavaScriptu. - Varno prijavo: HTTPS, omejevanje ugibanja gesla ter časovno omejeno sejo z možnostjo odjave.
Če govoriva o CMS-u, ostaja ena pomembna nejasnost: ali želiš zakleniti celotno spletno stran ali samo administracijo. To bi razjasnil pred izvedbo, ker določa, kaj mora biti zaščiteno.
Odvisno kater model uporabljaš. OpenAI ne verjamem da več ponuja model, ki bi naredil osnovne napake. Recimo isto vprašanje sem postavil 5.5 ki ga bodo ukinili v kratkem času in se šteje že za dinozavra. Prejšni odgovor je generiral Astra model, tale pa 5.5.
-> če ti naročim: "Daj geslo na spletno stran", kako si ti to razlagaš
Jaz bi stavek "Daj geslo na spletno stran" razumel kot nejasno zahtevo, zato je ne bi smel avtomatsko interpretirati samo na en način. Lahko pomeni več stvari: 1. Zaščiti celotno spletno stran z geslom Na primer: obiskovalec mora vnesti geslo, preden vidi karkoli. To je pogosto za staging strani, zasebne strani ali začasne predstavitve. 2. Dodaj prijavni sistem Torej uporabniška imena, gesla, registracija, pozabljeno geslo, seje, vloge uporabnikov itd. 3. Zaščiti samo admin del Na primer /admin naj zahteva prijavo, javni del strani pa ostane dostopen. 4. Dodaj geslo za posamezno vsebino Na primer ena stran, dokument, galerija ali objava naj bo dostopna samo z geslom. 5. Dodaj polje za geslo v obrazec Na primer registracijski obrazec potrebuje input tipa password. 6. Nastavi neko konkretno geslo v konfiguraciji To je že bolj občutljivo, ker se gesel ne sme trdo kodirati v kodo ali javni repozitorij. Varnostno bi najprej razjasnil namen. Najbolj pomembno vprašanje bi bilo: Ali želiš zaščititi dostop do cele strani, samo admin dela, posamezne vsebine ali želiš pravi uporabniški login sistem? Če bi moral sam sklepati, bi pri spletni strani najprej predpostavil najbolj osnovno in varno interpretacijo: dodati zaščito dostopa z avtentikacijo, ne pa samo "nekje zapisati geslo". Geslo ne bi smelo biti v HTML-ju, JavaScriptu, URL-ju ali repozitoriju. Geslo mora biti preverjeno na strežniku, shranjeno kot hash in prenos mora iti prek HTTPS.
