Știri
Știri din categoria Securitate cibernetică
Google mută o componentă critică a modemului Pixel 10 pe Rust, reducând riscul de atacuri „din memorie” – o schimbare cu impact operațional direct asupra securității, pe care restul producătorilor Android ar avea motive să o copieze, potrivit BGR.
Modemul este una dintre cele mai sensibile piese dintr-un telefon: rulează cod complex (în cazul firmware-ului de modem Pixel, „zeci de megabytes” de cod executabil scris în C și C++), iar aceste limbaje cresc probabilitatea apariției erorilor de gestionare a memoriei. Astfel de probleme pot duce la vulnerabilități critice, inclusiv atacuri de tip „buffer overflow” (depășirea limitelor unui buffer, care poate permite executarea de cod nedorit).
În aprilie 2026, Google a explicat pe Google’s Security Blog că a întărit măsurile proactive de securitate pe Pixel 10 prin integrarea „unui parser DNS (Domain Name System) scris în Rust, sigur din perspectiva memoriei, în firmware-ul modemului”. Ideea centrală: folosirea Rust pentru parserul DNS din baseband (componenta care gestionează comunicațiile celulare) reduce clasa de vulnerabilități legate de memorie și, implicit, scade semnificativ riscurile de securitate în modem.
Un detaliu important subliniat în material este că modemul are, practic, propriul „sistem de operare”, iar protecțiile din sistemul principal al telefonului nu sunt suficiente pentru a-l apăra în toate scenariile. Google spune că a observat un interes în creștere pentru modemurile celulare atât din partea atacatorilor, cât și a cercetătorilor, iar faptul că acestea pot fi exploatate de la distanță ridică miza pentru întreaga piață Android.
BGR amintește și un exemplu intern relevant: Project Zero (echipa Google de cercetare în securitate) a reușit la un moment dat să obțină execuție de cod de la distanță pe modemuri Pixel prin internet, ceea ce indică nivelul de expunere al acestei suprafețe de atac.
Google începuse deja să abordeze vulnerabilitățile de tip „memory-safety” în firmware-ul modemului prin corecții aplicate începând cu Pixel 9 (2024), însă Pixel 10 duce abordarea mai departe prin înlocuirea unei componente concrete cu una scrisă în Rust.
Mișcarea se înscrie într-o strategie mai amplă: Google a anunțat în 2021 suport pentru Rust în dezvoltarea Android, ca alternativă la C și C++. Compania descrie direcția drept o abordare de „Safe Coding”, adică înlocuirea treptată a limbajelor considerate „nesigure din perspectiva memoriei” cu opțiuni „memory-safe”, precum Rust.
Într-o actualizare din 2025, publicată tot pe Google’s Security Blog, compania a susținut că strategia a redus ponderea vulnerabilităților de tip memory-safety sub 20% din total, „pentru prima dată”, și că a accelerat livrarea de cod prin reducerea timpului de revizuire.
Materialul notează că vulnerabilitățile legate de memorie sunt printre cele mai exploatate și pot fi folosite inclusiv pentru spionaj. În acest context, BGR amintește că National Security Agency a emis în 2022 un ghid care recomandă folosirea limbajelor „memory-safe” acolo unde este posibil, pentru a limita astfel de riscuri; documentul este disponibil pe site-ul National Security Agency.
Separat, publicația menționează și un exemplu din tabăra Apple: compania ar fi introdus o funcție numită „Memory Integrity Enforcement” pe iPhone 17 și iPhone Air, într-un efort de a reduce riscurile asociate spyware-ului, conform unui alt articol BGR: Apple stepped up its security game with the iPhone 17 series and iPhone Air.
Din informațiile prezentate, schimbarea de pe Pixel 10 este un exemplu de „întărire” a unei zone istorice de risc (baseband/modem) printr-o intervenție țintită: înlocuirea unei componente expuse (parserul DNS) cu una scrisă într-un limbaj proiectat să prevină erori de memorie. Dacă abordarea se generalizează, impactul ar putea fi o scădere a vulnerabilităților critice exploatabile de la distanță în ecosistemul Android, însă BGR nu indică un calendar sau angajamente similare din partea altor producători.
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ă. [...]
Un atac de tip DDoS a provocat probabil întreruperi de internet în Coreea de Nord , blocând timp de circa 32 de ore accesul la zeci de site-uri oficiale, potrivit informațiilor publicate de HotNews , care citează o analiză a companiei americane de monitorizare a rețelelor Kentik . Analiza Kentik indică mai multe valuri de trafic care au venit simultan din două țări și au coincis cu momentul în care site-urile nord-coreene au început să cadă. Doug Madory, director de analiză a internetului la Kentik, a declarat pentru Reuters că vârfurile de trafic au început marți, în jurul orei 11:00 (ora locală), și că „este cu siguranță un atac DDoS (Distributed Denial-of-Service)”, adică o supraîncărcare intenționată a serverelor printr-un volum foarte mare de cereri. Totuși, datele analizate nu indică identitatea autorilor, iar Kentik a evaluat doar o parte din traficul direcționat către Coreea de Nord, ceea ce limitează concluziile privind originea exactă și amploarea atacului. Ce a fost afectat Întreruperile au vizat peste 40 de site-uri oficiale care folosesc domeniul național „.kp”, inclusiv paginile Ministerului Afacerilor Externe și ale agenției de presă de stat KCNA, potrivit presei sud-coreene citate în material. Ipoteze alternative și ce nu pare să fie cauza Presa sud-coreeană a menționat și o posibilă explicație non-cibernetică: experți în securitate au indicat că o alimentare instabilă cu energie electrică ar fi putut contribui la problemele de funcționare. În același timp, căderile din Coreea de Nord „nu par” să fie legate de problemele globale apărute ulterior în săptămână, generate de dezvăluirea unor vulnerabilități în limbajul de programare PHP, potrivit informațiilor din analiză. Context: nu este un incident izolat Rețeaua de internet a Coreei de Nord, strict controlată, a mai fost paralizată și în trecut. Un exemplu menționat este finalul anului 2014, când țara a avut o întrerupere completă de câteva ore, pe fondul tensiunilor legate de o comedie a Sony Pictures despre asasinarea fictivă a liderului Kim Jong Un. [...]
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ă. [...]
