Știri
Știri din categoria Securitate cibernetică
Google își întărește apărarea împotriva recenziilor false și a editărilor suspecte pe Google Maps, într-o mișcare cu impact direct asupra reputației și operațiunilor comercianților care depind de vizibilitatea din platformă, potrivit Google. Compania spune că noile protecții vizează atât oprirea „scam”-urilor (înșelătorii) legate de recenzii, cât și blocarea mai rapidă a modificărilor neconforme ale profilurilor de business, înainte ca acestea să devină publice.
În spatele acestor schimbări este presiunea volumelor: comunitatea a publicat peste 1 miliard de recenzii și a propus 80 de milioane de actualizări (program, date de contact și altele) doar în 2025, ceea ce face ca abuzurile să aibă efecte rapide și la scară mare asupra companiilor listate.
Prima direcție este oprirea fraudelor din zona recenziilor înainte să producă pagube. Google afirmă că și-a îmbunătățit sistemele pentru a identifica mai repede tipare noi de abuz, inclusiv tentative de a cere bani în schimbul eliminării unor recenzii false de o stea. Când detectează un val brusc de recenzii de tip spam, compania spune că poate interveni printr-un set de acțiuni operaționale:
Aceste protecții „se implementează la nivel global în următoarele săptămâni”, potrivit companiei.
A doua măsură ține de editările propuse pentru locații și denumiri. Google spune că folosește acum modelele Gemini pentru a „prinde” mai rapid editările nefolositoare și pentru a bloca sugestiile care încalcă politicile înainte să fie publicate, inclusiv cele care introduc comentarii sociale sau politice cu nuanțe locale. Implementarea este „în derulare” la nivel global pe Android, iOS și desktop.
A treia schimbare vizează controlul pe care îl au proprietarii asupra propriilor profiluri. Începând din această lună, Google anunță alerte proactive prin e-mail pentru proprietarii verificați și activi, astfel încât aceștia să poată revizui editările importante ale Business Profile înainte ca ele să apară public.
Pentru afacerile locale, recenziile și informațiile din Google Maps influențează direct decizia de cumpărare și fluxul de clienți. Măsurile descrise de Google mută o parte din „lupta” cu abuzurile mai devreme în lanț (blocare înainte de publicare) și adaugă un mecanism de control pentru proprietari (alerte prin e-mail), ceea ce poate reduce timpul și costurile administrative asociate cu corectarea informațiilor sau cu gestionarea crizelor de reputație generate de recenzii false.
Google leagă noile măsuri de rezultatele din 2025, când spune că:
Compania susține că investițiile continue în aceste sisteme ar trebui să le permită proprietarilor să se concentreze pe clienți, cu riscuri mai mici ca reputația lor din Maps să fie afectată de abuzuri.
Recomandate
Google va condiționa reclamele financiare din SUA și Canada de o verificare suplimentară a autorizării , într-o mișcare care ridică pragul de conformare pentru bănci și alți furnizori legitimi, dar urmărește să reducă impersonarea de brand și fraudele din publicitate, potrivit Google Blog . Măsura extinde programul „ Financial Services Verification ” (verificare pentru servicii financiare) în două piețe nord-americane, pe baza unui mecanism existent de verificare a identității advertiserilor. Google spune că, în SUA și Canada, peste 97% dintre reclamele văzute pe Google provin deja de la advertiseri cu identitatea verificată. Ce se schimbă pentru advertiserii din servicii financiare Pe lângă verificarea identității, noul strat de control introduce o verificare specializată a acreditărilor: advertiserii vor trebui să demonstreze că sunt autorizați de autorități de reglementare relevante sau de registre recunoscute înainte de a putea rula anumite reclame financiare. Obiectivul declarat este să limiteze: impersonarea unor instituții financiare (brand impersonation); accesul actorilor rău intenționați la utilizatori prin reclame. Google indică faptul că programul, în forma sa actuală, protejează aproximativ 2 miliarde de utilizatori de internet în 42 de țări, fiind „cel mai amplu program de acest tip”. Implementare etapizată și rolul registrelor bancare Google afirmă că va adapta implementarea în funcție de particularitățile fiecărei țări, invocând diferențe de reglementare și o introducere în etape („phased implementation”). În SUA, compania spune că lucrează cu American Bankers Association pentru a folosi registrul dedicat al acesteia, astfel încât băncile autorizate să fie verificate înainte ca reclamele să poată rula. În Canada, Google menționează colaborarea cu Canadian Bankers Association în pregătirea lansării. Calendar: țintă de lansare la începutul lui 2027 Google indică un „planned rollout” la începutul lui 2027. Înainte de lansare, compania promite informații specifice pe țări pentru advertiseri, inclusiv: registre acceptate, acreditări necesare, instrucțiuni de înrolare (onboarding). După deschiderea verificării, advertiserii vor fi notificați dacă și când trebuie să parcurgă procesul, iar ghidajul ar urma să fie oferit înainte de începerea aplicării (enforcement) politicii. Context: automatizare și colaborare anti-fraudă Google leagă verificarea „upfront” de sistemele sale de siguranță, menționând că în 2025 Gemini a ajutat la identificarea a peste 99% dintre reclamele care încălcau politicile, înainte ca acestea să fie difuzate. Inițiativa este prezentată și ca parte a unor eforturi mai largi de schimb de informații între tehnologie, finanțe și autorități, inclusiv prin Global Signal Exchange. [...]
Google Play Services ar asocia automat numărul de telefon cu toate conturile Google autentificate pe același dispozitiv, fără notificare , ceea ce poate crea o legătură directă între identități pe care utilizatorii încearcă să le țină separate (personal, serviciu, cont „anonim”), potrivit Android Police . Informația pornește de la o sesizare a unui utilizator pe Reddit, preluată de publicație, potrivit căreia Google Play Services ar „verifica” numerele de telefon de pe telefon și le-ar atașa tuturor conturilor Google conectate pe acel dispozitiv ( Android Police notează că subiectul a fost semnalat și „via Android Authority”). Publicația subliniază că nu ar exista un avertisment sau o solicitare explicită de acord. Miza nu este neapărat că datele „se amestecă” între conturi, ci că același identificator (numărul de telefon) devine comun mai multor conturi. Chiar dacă utilizatorul nu vede conținutul unui cont în altul, această asociere poate funcționa ca un „fir” care leagă conturile între ele și de persoana reală din spatele lor — exact opusul separării pe care o urmăresc mulți utilizatori când folosesc mai multe conturi pe același telefon. Ce poți face dacă vrei să reduci asocierea dintre conturi Android Police descrie câțiva pași care ar putea limita sau corecta situația, deși menționează că procesul „ia ceva timp”: Dezactivarea sincronizării/validării automate a numărului de telefon : în aplicația Setări → Google → Toate serviciile → zona Confidențialitate și securitate → opțiunea Verificarea numărului de telefon (denumirile pot varia ușor în funcție de versiunea Android). Verificarea numerelor salvate în cont : în contul Google → secțiunea Informații personale → Telefon , unde pot apărea numere stocate ce pot fi șterse. Repetarea verificărilor pentru fiecare cont Google folosit pe telefon, dacă obiectivul este separarea lor. Context: semnalări inclusiv pe GrapheneOS Autorul notează că utilizatorul de pe Reddit ar fi întâlnit același comportament și pe un dispozitiv cu GrapheneOS (un sistem orientat spre confidențialitate). Publicația tratează situația ca pe un exemplu de practică „deloc surprinzătoare” în ecosistemul marilor platforme, dar accentul rămâne pe consecința practică: utilizatorii care folosesc mai multe conturi pentru separare ar putea descoperi că acestea sunt totuși conectate prin numărul de telefon. Android Police recomandă, în esență, ca cei interesați să verifice rapid ce numere sunt asociate conturilor lor și să ajusteze setările dacă nu doresc această legare automată. [...]
Pentagonul își extinde capabilitățile de „război în umbră” în zona cibernetică , după ce a înființat în secret, în aprilie, o structură dedicată sabotajului tehnologic și perturbării proiectelor din străinătate, potrivit Antena 3 , care citează Politico. Miza, conform materialului, este accelerarea operațiunilor „agresive” în afara SUA, inclusiv potențiale atacuri cibernetice, într-un cadru despre care sursa notează că a fost ținut departe de supravegherea publică. Noua entitate se numește „ Biroul de Sprijin Tehnologic ” (Technology Support Office – TSO) și, până acum, nu a fost menționată public nici de secretarul Apărării, Pete Hegseth, nici de alți oficiali de rang înalt. Informațiile despre TSO ar fi greu de găsit pe site-urile Pentagonului, iar agenția apare doar în câteva documente ale Departamentului Apărării. Ce ar face TSO și de ce contează operațional Potrivit articolului, TSO ar fi fost creat pentru a intensifica activități clandestine care vizează sabotarea sau perturbarea proiectelor tehnologice externe considerate amenințări la adresa superiorității militare a SUA. În această logică, agenția ar urma să acopere o plajă mai largă de acțiuni, de la zona cibernetică până la operațiuni de dezinformare și perturbarea lanțurilor logistice. Publicația menționează că TSO nu ar avea autoritatea legală de a desfășura direct operațiuni clandestine, însă ar colabora cu ofițeri superiori militari și de informații pentru a dezvolta instrumente și strategii care să limiteze accesul adversarilor la tehnologii critice de apărare sau să le submineze „de la distanță”. Cum ar fi fost construită agenția și cine a coordonat înființarea Politico afirmă că a discutat, sub anonimat, cu 12 foști și actuali oficiali americani din securitatea națională, inclusiv persoane implicate în înființarea agenției sau care au lucrat îndeaproape cu aceasta. Conform relatării, inițiativa ar fi fost condusă de secretarul adjunct al Apărării, Steve Feinberg , iar un alt oficial implicat ar fi Tom Rakusan, fost agent CIA și consilier principal al lui Feinberg la Pentagon. TSO ar fi rezultat în mare parte din reorganizarea a două departamente secrete care derulau eforturi similare, la scară mai mică, încă din 2023. Instrumente, ținte și buget estimat TSO ar fi format din ingineri, operatori speciali și ofițeri de informații, iar activitatea ar include: dezvoltarea de instrumente și sisteme de hacking personalizate; planificarea de operațiuni de înșelăciune și diversiune; inducerea în eroare a adversarilor pentru a-i determina să instaleze componente concepute de TSO în platforme-cheie și programe ale sistemelor de armament străine. Un fost oficial al serviciului de informații al Pentagonului a estimat pentru Politico un buget de cel puțin 1,5 miliarde de dolari (aprox. 6,9 miliarde lei) pentru TSO. Întrebările de supraveghere și reacția Casei Albe În material sunt menționate și temeri că administrația Trump ar fi evitat deliberat să vorbească public despre TSO pentru a limita supravegherea unor programe care ar putea afecta civili sau ar putea tensiona relațiile cu state cu care SUA nu sunt în război, precum China. Un fost oficial de rang înalt din Pentagon, citat sub anonimat, a ridicat explicit problema controlului și a responsabilității: „Întrebările sunt: Cine aprobă și controlează (o astfel de agenție), cine supraveghează (activitățile sale), cine este informat, pentru ca cetățenii americani să aibă încredere că ceea ce faci tu este în conformitate cu valorile noastre.” Casa Albă, potrivit articolului, a refuzat să comenteze existența agenției și nu a răspuns unei cereri de comentariu privind subiectul. [...]
Exploatarea activă a două vulnerabilități critice din PHP crește riscul de compromitere a NAS-urilor expuse la internet , iar pentru o parte dintre producători nu există încă remedieri complete, potrivit AppleInsider . Miza este operațională: NAS-urile sunt folosite frecvent ca depozit principal pentru fișiere și copii de siguranță, iar un atac reușit poate duce la acces neautorizat și executare de cod de la distanță. Vulnerabilitățile, denumite „PHP2Shell” și urmărite ca CVE-2026-109618 și CVE-2026-109619, pot permite atacatorilor să ruleze cod pe servere afectate fără autentificare. Echipa PHP a publicat actualizări de securitate pe 21 octombrie pentru versiunile 8.2–8.5, însă urgența este amplificată de faptul că Amazon a detectat o tentativă de exploatare pe 17 octombrie, înainte de divulgarea publică. Cine are patch-uri și cine încă lucrează la remedieri Synology a publicat pachete PHP actualizate care adresează problemele. În avizul său de securitate, compania indică drept afectate versiunile PHP 7.3–8.4 și menționează, între altele, Mail Station și Synology Calendar. Actualizările pentru PHP 8.2 și PHP 8.4 sunt disponibile prin Package Center și arhiva de descărcări, însă producătorul recomandă verificarea stării fiecărui pachet afectat, nu presupunerea că totul a fost remediat. Synology face și o distincție importantă pentru administrare: pachetele PHP instalate separat nu sunt același lucru cu componentele PHP integrate în DiskStation Manager, iar compania susține că PHP-ul „încorporat” nu este expus la suprafețe de atac externe, ceea ce ar face exploatarea prin acel component „puțin probabilă”. QNAP a confirmat o plajă mai largă de produse afectate într-un aviz din 22 octombrie, inclusiv QTS 5.2.11 și versiuni anterioare, QTS 6.1.0, mai multe versiuni de QuTS hero și QuTScloud, plus aplicații precum Note Station 3. Compania spune că lucrează la remedieri, dar nu a indicat un termen de livrare. QNAP afirmă că nu are rapoarte de atacuri care să-i vizeze produsele, deși există documentare privind încercări de exploatare a serverelor PHP vulnerabile. Până la apariția patch-urilor, QNAP recomandă reducerea expunerii directe la internet prin: dezactivarea redirecționărilor de porturi neesențiale; dezactivarea UPnP (configurarea automată a porturilor în router); dezactivarea serviciilor de acces la distanță care nu sunt necesare; folosirea unei conexiuni VPN și restricționarea accesului de administrare la rețele de încredere. Publicația notează și că dezactivarea serverului web integrat poate reduce expunerea dacă nu este necesar, dar QNAP avertizează că această măsură nu protejează interfața de administrare a NAS-ului; rămân necesare restricțiile de rețea cât timp software-ul afectat nu este actualizat. Producători unde situația rămâne neclară Pentru TerraMaster , AppleInsider menționează o discuție pe Reddit în care compania a recunoscut problema după ce un utilizator a raportat PHP 7.4.33 în interfața de administrare a unui model F2-425. Într-un răspuns din 22 octombrie, TerraMaster a spus că investighează și testează și lucrează la o soluție, însă nu există încă un patch, iar publicația precizează că nu a confirmat independent dacă acea configurație este exploatabilă. În cazul Ugreen , AppleInsider spune că nu a putut confirma dacă există o actualizare de securitate PHP2Shell pentru UGOS Pro; politica de raportare a vulnerabilităților descrie procesul, dar nu stabilește dacă software-ul NAS este afectat. Pentru Asustor , publicația afirmă că nu a putut confirma existența unui patch PHP2Shell sau o listă definitivă de dispozitive afectate; compania are o pagină de avize de securitate, iar statusul vulnerabilității este indicat ca „în desfășurare”. Riscul operațional ignorat frecvent: containerele Docker Un NAS „la zi” ca sistem de operare poate rula în continuare PHP vulnerabil în aplicații din containere Docker. Acestea pot include propriile instalări PHP, care nu sunt actualizate automat odată cu firmware-ul sau pachetele producătorului. Recomandarea este ca utilizatorii care rulează servicii bazate pe PHP în Docker să verifice imaginile de container pentru versiuni afectate și să instaleze imagini actualizate când devin disponibile; în practică, actualizarea presupune de regulă recrearea containerului pentru a rula software-ul remediat. QNAP avertizează explicit că instalările PHP din Container Station și aplicațiile terțe nu sunt acoperite de actualizările sistemului de operare. Ce urmează și unde e riscul cel mai mare Cea mai mare problemă pe termen lung, potrivit AppleInsider, este la NAS-urile vechi, ieșite din suport , care nu mai primesc actualizări de securitate și pot rămâne vulnerabile pe termen nedefinit. În acest caz, recomandarea este să nu fie expuse la internet interfața de administrare sau alte servicii, chiar dacă dispozitivul poate rămâne util pentru stocare locală. Pentru acces de la distanță, publicația indică folosirea unui VPN în locul expunerii porturilor de administrare și verificarea jurnalelor pentru activitate suspectă, deoarece actualizările nu „repară” un compromis deja produs. [...]
Cloudflare își mută managementul vulnerabilităților spre „apărare la marginea rețelei” (edge) cu ajutorul modelelor OpenAI , într-un serviciu aflat în acces timpuriu care promite să lege direct descoperirea unei probleme în cod de semnalele din producție și de măsuri concrete de reducere a expunerii, potrivit OpenAI . Miza operațională este reducerea timpului pierdut de echipele de securitate în trierea alertelor și accelerarea trecerii de la „am găsit o vulnerabilitate” la „am aplicat o protecție”. Ce lansează Cloudflare și cum funcționează Serviciul se numește „ Vulnerability Discovery and Remediation ” și este oferit în regim de early access prin Cloudflare Managed Defense. Conform descrierii, Cloudflare combină modele OpenAI accesate prin Daybreak cu propria rețea globală și cu „context de amenințări” (threat context) pentru a investiga cod și a evalua potențiale vulnerabilități. Diferența pe care o urmărește Cloudflare este conectarea unei vulnerabilități din cod cu realitatea din producție: dacă ruta afectată este activă, dacă primește trafic suspect și dacă există deja controale de securitate care o protejează. Aceste semnale ar trebui să ajute la prioritizarea investigațiilor. În fluxul descris, serviciul: analizează cod „autorizat de client” pentru a identifica vulnerabilități potențiale și a verifica dovezile din spatele fiecărei constatări; pregătește propuneri de patch-uri (corecții în cod) și, unde este cazul, reguli personalizate de Web Application Firewall (WAF – filtru de securitate pentru aplicații web) pentru a reduce expunerea până la aplicarea unui fix; rulează verificări automate pe propuneri, iar echipa Cloudflare le revizuiește înainte de a le trimite clienților, care păstrează controlul asupra modificărilor implementate. De ce contează pentru companii: triere mai rapidă și protecții temporare OpenAI notează că echipele de securitate se confruntă cu un flux constant de informații despre vulnerabilități și alerte, iar trierea manuală consumă timp și capacitate. Abordarea Cloudflare încearcă să reducă această presiune prin: mai mult „context” din trafic și semnale de securitate, pentru a decide ce merită investigat primul; măsuri de protecție la nivel de edge (de exemplu, reguli WAF) care pot limita expunerea înainte ca echipele de dezvoltare să finalizeze corecțiile. În esență, produsul este poziționat ca o punte între descoperirea vulnerabilităților și apărarea efectivă, cu pași intermediari „gata de evaluat” de client. Rolul Codex în ingineria Cloudflare și un reper de cost În paralel, Codex este folosit pe scară largă în organizația de inginerie a Cloudflare pentru creșterea productivității și îmbunătățirea calității codului, potrivit lui Mark Anderson, President of Revenue, Cloudflare. Acesta susține că „100%” dintre dezvoltatorii companiei folosesc Codex. Anderson oferă și un exemplu concret: o echipă de patru dezvoltatori ar fi refăcut un produs în trei zile, ar fi făcut rollout și testare, cu un cost de 1.100 dolari (aprox. 5.000 lei) pe tokeni, estimând că altfel ar fi fost nevoie de luni de lucru și „poate de 10 ori mai mulți dezvoltatori”. „Frumusețea automatizării pe care o oferă Daybreak și Codex este că poți atribui mașinilor munca de rutină, astfel încât oamenii să-și exercite judecata asupra celor mai importante decizii de inginerie și securitate.” Ce urmează Materialul indică faptul că „Vulnerability Discovery and Remediation” este în acces timpuriu, fără a detalia calendarul unei disponibilități generale sau condițiile comerciale. Direcția este însă explicită: integrarea modelelor AI în procesele de inginerie și securitate, astfel încât analiza codului, semnalele din producție și acțiunile propuse (protecții și patch-uri) să fie legate într-un flux unic, în care clientul decide ce implementează. [...]
Închiderea preventivă a unor platforme publice din Europa arată cât de rapid poate AI să transforme vulnerabilități vechi în risc operațional imediat , forțând instituții și organizații să oprească servicii online până la aplicarea actualizărilor, potrivit Mediafax . Măsurile au fost luate după identificarea, cu ajutorul instrumentelor bazate pe inteligență artificială, a două vulnerabilități critice în PHP, limbaj de programare folosit pe scară largă pentru site-uri și aplicații web. Experții avertizează că atacatorii încearcă deja să exploateze problemele, iar impactul s-a văzut în întreruperi care au atins inclusiv spitale și servicii publice. Ce servicii au fost oprite și unde s-au văzut efectele În Olanda, autoritățile au suspendat preventiv accesul la mai multe platforme, inclusiv Overheid.nl (portalul serviciilor guvernamentale) și MijnOverheid.nl (comunicarea dintre cetățeni și administrație). Au fost menționate ca afectate și organizații precum Portul Rotterdam, federația națională de fotbal, partide politice și spitale. În alte state, reacția a fost similară: Franța a închis temporar site-urile prefecturilor până la actualizări, Finlanda a suspendat servicii online guvernamentale, iar Germania a dezactivat mai multe site-uri federale. Belgia (Ministerul de Externe) și Cehia au raportat măsuri comparabile. În afara administrației publice, Fundația Wikimedia a anunțat suspendarea preventivă a unor sisteme până la instalarea remedierilor, iar Internet Archive a fost indisponibil temporar. Autoritățile au precizat că oprirea preventivă nu înseamnă automat că site-urile au fost compromise. De ce contează: vulnerabilități vechi, risc nou accelerat de AI Problemele au fost identificate independent de cercetători ai companiilor Calif și Wiz, care au folosit instrumente bazate pe inteligență artificială, inclusiv modele dezvoltate de Google și OpenAI. Potrivit Wiz, vulnerabilitățile existau în codul PHP de mai bine de un deceniu, dar ar fi fost foarte greu de exploatat prin metode tradiționale. Cele două vulnerabilități, evaluate la 9,2 din 10 ca gravitate, pot permite executarea de cod malițios de la distanță, fără autentificare, pe serverele vulnerabile. Cloudflare a raportat apariția unor tentative de atac, iar Amazon a anunțat că a detectat o încercare de exploatare încă din 17 octombrie, înainte de dezvăluirea publică. Ce urmează: actualizări disponibile, dar fereastra de risc rămâne Dezvoltatorii PHP au publicat miercuri remedierile și au recomandat instalarea imediată. CERT-EU (echipa de răspuns la incidente cibernetice a instituțiilor UE) recomandă suspendarea temporară a sistemelor vulnerabile atunci când actualizarea nu poate fi aplicată rapid. Potrivit companiei Censys, aproximativ 1,5 milioane dintre cele 2,6 milioane de servere identificate ca utilizând PHP raportau versiuni pentru care nu exista o remediere disponibilă. În acest context, specialiștii avertizează că publicarea detaliilor tehnice și folosirea AI pot accelera dezvoltarea atacurilor împotriva serverelor care rămân neactualizate. [...]
