Știri
Știri din categoria Securitate cibernetică

Google leagă cookie-urile de sesiune de dispozitiv în Chrome, reducând riscul de furt de conturi: potrivit techradar.com, Chrome 146 pentru Windows introduce „Device Bound Session Credentials” (DBSC), o funcție care face mult mai dificilă folosirea cookie-urilor de sesiune furate în atacuri cu malware de tip infostealer.
DBSC „leagă” criptografic sesiunea de autentificare de dispozitivul fizic folosit la logare, prin module de securitate susținute de hardware (de exemplu, Trusted Platform Module pe Windows). Practic, browserul generează o pereche de chei publică/privată care nu poate fi exportată de pe mașină, iar serverul emite cookie-uri de sesiune cu durată scurtă doar dacă Chrome poate dovedi că deține cheia privată asociată.
Miza este reducerea furtului de sesiuni, o metodă prin care atacatorii pot ocoli autentificarea cu mai mulți factori (MFA). Cookie-urile de sesiune sunt create după autentificare, iar dacă sunt exfiltrate, pot permite accesul la conturi fără a mai trece prin MFA. Google susține că, în modelul DBSC, chiar dacă un atacator reușește să fure cookie-urile, acestea „expiră rapid” și devin inutile, deoarece cheia privată necesară nu poate fi sustrasă.
Dincolo de schimbarea din browser, funcția cere și adaptări pe partea de server. Conform descrierii, site-urile pot trece la „sesiuni securizate” prin adăugarea unor puncte dedicate (endpoints) de înregistrare și reîmprospătare în backend, păstrând compatibilitatea cu interfața existentă. Chrome se ocupă de criptografie și rotația cookie-urilor, iar aplicația web continuă să folosească cookie-uri standard pentru acces, ca până acum.
Funcția este disponibilă acum în Chrome 146 pe Windows. Varianta pentru macOS este așteptată „în săptămânile următoare”. Google mai spune că o versiune timpurie a protocolului a fost lansată în 2025 și că, pentru sesiunile protejate de DBSC, a observat o „reducere semnificativă” a furtului de sesiuni, fără a oferi însă cifre în materialul citat.
În context, techradar.com amintește că infostealerele folosite frecvent pentru furtul de date includ familii precum Lumma, Vidar, StealC și AMOS, capabile să extragă nu doar cookie-uri, ci și parole stocate, date din portofele cripto și conținutul clipboard-ului.
Recomandate

Cazul unui inginer Google acuzat că a folosit date interne pentru pariuri pe Polymarket ridică miza de reglementare pentru piețele de predicție , printr-o aplicare „în stil bursier” a conceptului de tranzacționare pe informații privilegiate asupra unor contracte de tip derivat, potrivit The Next Web . Procurorii federali din Southern District of New York (SDNY) l-au pus sub acuzare pe Michele Spagnuolo , un inginer Google de securitate a informațiilor, în vârstă de 36 de ani, stabilit în Elveția. Acesta ar fi folosit un instrument intern Google pentru a accesa date nepublice despre tendințele de căutare și ar fi pariat 2,7 milioane de dolari (aprox. 12,2 milioane lei) pe Polymarket, obținând un profit de 1,2 milioane de dolari (aprox. 5,4 milioane lei) din contractele „Google Year-in-Search” pentru 2025. De ce contează: „insider trading” aplicat pe o piață reglementată ca derivat Miza principală a dosarului este cadrul legal folosit de autorități. Polymarket operează cu „contracte de eveniment” (pariuri pe rezultate), care sunt reglementate de Commodity Futures Trading Commission (CFTC) ca derivate, nu de Securities and Exchange Commission (SEC) ca valori mobiliare. În mod tradițional, răspunderea pentru tranzacționare pe informații privilegiate a fost mai ușor de încadrat în regimul piețelor de capital. În acest caz, procurorii ar fi ocolit această limitare folosind legea privind frauda pe mărfuri (commodities fraud), care vizează manipularea și conduita frauduloasă pe orice piață aflată sub supravegherea CFTC. Publicația notează că dosarul SDNY, susținut de o investigație FBI, este cea mai concretă aplicare publică de până acum a unei logici de tip „insider trading” la tranzacții pe o piață de predicție. Cum ar fi funcționat schema, potrivit acuzării Polymarket a rulat la finalul lui 2025 o piață privind cine va conduce clasamentul Google „Year-in-Search”, recapitularea anuală a celor mai căutați termeni și persoane. Procurorii susțin că Spagnuolo ar fi: accesat date interne, nepublice, despre trendurile de căutare; plasat 25 de pariuri printr-un cont numit „AlphaRaccoon”; mizat aproape 1 milion de dolari (aprox. 4,5 milioane lei) că Bianca Censori nu va termina pe primul loc și peste 600.000 de dolari (aprox. 2,7 milioane lei) că Papa Leo XIV nu va termina pe primul loc; luat o poziție „semnificativă” pe artistul D4vd să termine pe primul loc, la o probabilitate aproape de zero, conform prețului din piață. D4vd a câștigat după ce Google a anunțat rezultatele pe 4 decembrie 2025, iar contul „AlphaRaccoon” ar fi încasat profitul. Ulterior, Spagnuolo ar fi eliminat numele „AlphaRaccoon” de pe cont și ar fi mutat câștigurile din portofelul cripto asociat. Capete de acuzare și anchete paralele Spagnuolo este acuzat de fraudă pe mărfuri, fraudă prin mijloace electronice (wire fraud) și spălare de bani. În paralel, CFTC a deschis un caz civil. Este al doilea dosar penal federal legat de tranzacționarea pe Polymarket și primul în care informația folosită ar proveni din interiorul unei mari platforme din Silicon Valley, potrivit articolului. Presiune în creștere asupra piețelor de predicție Dosarul apare într-un context de intensificare a presiunii de reglementare asupra Polymarket și a platformei Kalshi. Publicația menționează că: Comisia de Supraveghere a Camerei Reprezentanților din SUA (House Oversight), condusă de James Comer, a deschis o investigație privind folosirea de informații nepublice de către clienți ai Polymarket și Kalshi; Spania a blocat ambele platforme invocând motive legate de licența de jocuri de noroc; India a blocat formal Polymarket pe 21 mai. Într-un caz anterior, un militar american a fost acuzat că a folosit informații interne pentru a paria pe rezultate politice din Venezuela, obținând aproximativ 400.000 de dolari (aprox. 1,8 milioane lei). Ce urmează Spagnuolo a fost arestat în Elveția și, potrivit informațiilor citate, cooperează cu procesul de extrădare. Google nu a comentat dacă intenționează să inițieze o acțiune civilă împotriva fostului angajat. Pentru Polymarket, întrebarea comercială deschisă este dacă argumentul că „dinamica de preț” rezistă unui număr mic de participanți informați va rămâne credibil în fața unei urmăriri penale de acest tip. Articolul notează că piața „Year-in-Search” ar fi fost suficient de mică încât o poziție de 2,7 milioane de dolari să fie vizibilă în registrul de ordine, iar echipa de supraveghere a platformei nu a explicat public de ce nu ar fi semnalat-o înainte de rezultatele din decembrie 2025. [...]

Atacatorii folosesc deja AI ca să găsească breșe „zero-day” care pot ocoli inclusiv autentificarea în doi pași , iar asta mută presiunea operațională pe companii: controalele clasice și scanările automate nu mai sunt suficiente pentru a prinde vulnerabilități de logică, greu de observat în testele standard, potrivit Mediafax , care citează Euronews și un raport al Google Threat Intelligence Group . Google spune că a identificat pentru prima dată un atac în care inteligența artificială a fost folosită pentru a descoperi și exploata o vulnerabilitate „zero-day ” – o breșă necunoscută inclusiv dezvoltatorilor și pentru care nu există încă o soluție de protecție. Compania afirmă că a detectat atacul înainte să fie lansat la scară largă și a avertizat discret compania afectată. De ce contează pentru companii: 2FA poate fi ocolită, iar „scanarea” nu mai ajunge Ținta a fost un sistem popular de administrare web, iar vulnerabilitatea identificată cu ajutorul AI ar fi permis ocolirea autentificării în doi pași (2FA), una dintre măsurile considerate esențiale în protecția conturilor. În raportul citat se arată că „actorul criminal intenționa să folosească vulnerabilitatea într-un atac masiv”. Miza operațională este că astfel de breșe nu arată ca erorile „clasice” de programare. Specialiștii citați explică faptul că era vorba de o contradicție logică ascunsă în structura codului: instrumentele tradiționale caută, de regulă, erori evidente sau probleme de memorie, în timp ce AI poate analiza logica sistemelor și poate identifica excepții sau reguli contradictorii pe care oamenii și programele standard le pot rata. Raportul compară situația cu „un seif bancar” care are o încuietoare funcțională, dar se deschide pentru cineva care știe o excepție secretă introdusă accidental. AI „industrializează” atacurile: de la căutarea de breșe la phishing personalizat Google avertizează că grupări asociate cu China și Coreea de Nord folosesc deja AI pentru a căuta vulnerabilități la scară industrială, inclusiv prin trimiterea a mii de solicitări automate pentru analizarea vulnerabilităților software și construirea rapidă de instrumente de atac. În paralel, grupări asociate cu Rusia ar dezvolta malware care se rescrie singur pentru a evita detectarea de către programele antivirus. Raportul mai indică o schimbare și în phishing: în locul mesajelor generice trimise în masă, atacatorii folosesc AI pentru a analiza organigrame, a identifica angajați-cheie și a crea mesaje credibile și personalizate, mai greu de depistat chiar și de utilizatori cu experiență. „Combatant activ”, nu doar instrument: cum răspunde Google Una dintre concluziile raportului este că AI nu mai funcționează doar ca instrument de analiză, ci ca participant direct în lanțul ofensiv. „LLM-ul nu mai este doar un consilier pasiv, ci un participant activ în lanțul ofensiv”, avertizează Google. Compania spune că folosește, la rândul ei, AI pentru a detecta și repara vulnerabilități mai rapid decât ar putea-o face echipele umane, însă avertizează că avantajul tehnologic dintre atacatori și apărători devine tot mai fragil. [...]

Un atac de tip „supply chain” pe GitHub poate ajunge rapid la utilizatori prin pachete npm , după ce o campanie numită Megalodon a infectat peste 5.500 de depozite cu commit-uri malițioase, potrivit TechRadar . Miza operațională pentru companii este expunerea secretelor din fluxurile CI/CD (integrare și livrare continuă), care pot deschide acces la infrastructură cloud și la medii de producție. Cum funcționează atacul și de ce e greu de prins Cercetătorii SafeDep descriu Megalodon ca o campanie „inspirată” de TeamPCP , care pornește de la un commit malițios trimis de un actor ce se prezintă drept un „build-bot” (un cont care mimează un robot de build ce face modificări automate). Dacă un maintainer acceptă commit-ul, codul introduce un infostealer (malware care fură date) și începe să se propage către alte depozite „în stil vierme”, adică prin replicare automată. Ținta principală sunt secretele din pipeline-urile DevOps, adică acele chei și tokenuri care permit automatizărilor să acceseze servicii critice. Ce date sunt vizate: chei cloud, acces SSH și configurații DevOps În observațiile SafeDep, Megalodon a urmărit să colecteze, între altele: chei secrete AWS și tokenuri de acces Google Cloud; credențiale de tip „instance role” din AWS, Google Cloud și Azure; chei private SSH; configurații Docker și Kubernetes; tokenuri Vault și credențiale Terraform. Pentru organizații, compromiterea acestor date poate însemna acces neautorizat la resurse cloud, modificări în infrastructură și risc de extindere laterală în rețea. De la maintaineri la utilizatori: riscul de propagare prin npm În etapa inițială, expuși sunt în primul rând maintainerii de pe GitHub. Riscul se extinde însă către utilizatori dacă proiectele compromise sunt publicate mai departe în npm (registrul de pachete folosit frecvent în ecosistemul JavaScript), deoarece pachetele pot ajunge în aplicații ale terților. SafeDep oferă exemplul Tiledesk, unde versiunile 2.18.6 (19 mai) până la 2.18.12 (21 mai) „conțin backdoor-ul”, iar publicarea s-a făcut din aceeași cont npm ca și versiunea curată 2.18.5, fără ca atacatorul să fi preluat contul npm. Concluzia cercetătorilor: depozitul GitHub a fost compromis, iar maintainerul a publicat din sursa „otrăvită” fără să își dea seama. „Atacatorul nu a atins niciodată contul npm. Au compromis depozitul GitHub, iar maintainerul a publicat din sursa infectată fără să realizeze.” Context: copycat după TeamPCP și listă de repo-uri compromise TechRadar notează că Megalodon pare a fi un actor separat, de tip „copycat”, nu neapărat parte din inițiativa TeamPCP menționată de The Register, care a scris despre o „competiție” de atacuri asupra lanțului de aprovizionare (supply chain) pe Breach Forums. Lista completă a depozitelor compromise este publicată de SafeDep în raportul său (linkul indicat în articol). [...]

Meta a închis o breșă operațională în suportul Instagram după ce atacatori au reușit să convingă agentul de asistență bazat pe inteligență artificială să inițieze resetări de parolă fără verificări de identitate, potrivit TechRadar . Incidentul arată riscul de a delega către sisteme automate procese sensibile, precum recuperarea conturilor. Atacul a fost unul de inginerie socială : infractorii au purtat o conversație cu chatbotul MetaAI și l-au determinat să trimită coduri de resetare a parolei pentru conturi care nu le aparțineau, fără să ceară verificare de identitate. Cercetătorii care au făcut public cazul au atras atenția că astfel de sarcini, dacă sunt automatizate, pot deveni puncte de intrare în compromiterea conturilor. De ce contează: conturi „premium” pot fi monetizate rapid Țintele au fost conturi Instagram cu nume scurte („short-handle”), considerate valoroase deoarece au, de regulă, audiențe foarte mari și pot fi revândute pe piața neagră. Conform cercetătorilor ZachXBT și Dark Web Informer, atacatorii au obținut coduri de resetare pentru conturile altor persoane. Două conturi, și , ar fi fost listate la vânzare pe canale de Telegram pentru „peste 1 milion, cumulat”, potrivit Cybersecurity News (citat de TechRadar ). Cercetătorii au urmărit apariția listărilor în mai multe comunități de hacking de pe Telegram. Ce a făcut Meta și ce spune compania Meta a remediat problema „vinerea trecută seara”, conform articolului. Compania a transmis ulterior: „Am remediat o problemă care permitea unei părți externe să solicite e-mailuri de resetare a parolei pentru unii utilizatori Instagram. Nu a existat nicio breșă a sistemelor noastre și conturile Instagram ale oamenilor rămân sigure.” Publicația notează și un aspect important pentru utilizatori: în acest caz, atacul a vizat fluxul de suport al platformei, nu utilizatorii direct, astfel că opțiunile de prevenție la nivel individual au fost limitate. Implicații pentru companii: automatizarea suportului trebuie „îngrădită” pe procese critice Cazul evidențiază o vulnerabilitate de proces: dacă un agent automat poate declanșa resetări de parolă fără controale robuste, atacatorii pot transforma conversația cu un bot într-o cale de preluare a conturilor. Pentru organizații, lecția este că automatizarea în suport trebuie însoțită de verificări stricte pentru operațiuni cu impact mare (recuperare cont, schimbare e-mail, resetare parolă), tocmai pentru a reduce suprafața de atac la inginerie socială. [...]

Microsoft a remediat o pană care a blocat configurarea MFA și accesul la My Sign-Ins , un incident cu impact operațional direct pentru organizațiile care se bazează pe autentificarea cu mai mulți factori pentru accesul utilizatorilor, potrivit BleepingComputer . Problema a afectat utilizatori care nu au putut seta MFA sau accesa site-ul mysignins.microsoft.com , iar în centrul de administrare Microsoft incidentul a fost urmărit sub codul MO1329260 . Conform actualizărilor din admin center, cei afectați au întâlnit erori „504 Gateway Timeout” la accesarea serviciului. Ce s-a întâmplat și cum a reacționat Microsoft Microsoft a confirmat incidentul în jurul orei 5:00 AM ET (12:00, ora României) și l-a încadrat ca „incident în desfășurare”, etichetă folosită pentru probleme critice cu impact vizibil asupra utilizatorilor. Pentru limitarea efectelor, compania a trecut inițial pe „infrastructură alternativă” considerată sănătoasă și a început monitorizarea telemetriei (indicatori tehnici ai funcționării serviciului) pentru a urmări revenirea completă. În paralel, Microsoft a indicat că analizează măsuri suplimentare, inclusiv optimizarea modului în care sunt procesate cererile către serviciu, pe fondul persistenței unor rate ridicate de erori. Cauza indicată: schimbare de configurare a cache-ului și suprasolicitare la failover Într-o actualizare din 1 iunie, ora 08:41 EDT (15:41, ora României), Microsoft a transmis că a restabilit accesul la My Sign-Ins și a pus incidentul pe seama unei schimbări recente de configurare a cache-ului (mecanism de stocare temporară pentru accelerarea răspunsurilor), care a necesitat un failover (comutare pe infrastructură de rezervă). „Am identificat că o schimbare recentă de configurare a cache-ului a necesitat un failover.” În timpul failover-ului, serviciul a înregistrat utilizare ridicată de CPU și memorie, pe fondul unui vârf de trafic din Europa, ceea ce a împiedicat MySignIn să proceseze volumul de solicitări. Microsoft spune că a revenit asupra acțiunilor de atenuare și a readus traficul pe infrastructura inițială. Ce rămâne neclar Compania nu a precizat ce regiuni au fost afectate, menționând doar contextul unui vârf de trafic din UE în perioada failover-ului. Pentru organizații, incidentul evidențiază un risc operațional: indisponibilitatea temporară a fluxurilor de înrolare MFA și a accesului la pagina My Sign-Ins poate întârzia onboarding-ul utilizatorilor și poate complica gestionarea accesului în intervalul afectat. [...]

NVIDIA mută securitatea „zero trust” în stocare pentru AI agențial, cu politici aplicate direct în cip , mizând pe detecție la rulare „de până la 1.000x” mai rapidă și pe aplicarea regulilor de acces la viteze de până la 800 Gb/s, potrivit NVIDIA News . Miza operațională este reducerea riscului ca agenții AI — care citesc, scriu și partajează date fără supraveghere umană directă — să devină o nouă suprafață de atac în companii, în special prin acces neautorizat la fișiere și „memorie de context”. Anunțul vizează NVIDIA Vera BlueField-4 STX , o extensie a arhitecturii accelerate de stocare a companiei, care aduce un „stack” (pachet) unificat de securitate NVIDIA DOCA și îl aplică „în siliciu” pe NVIDIA BlueField-4. Practic, interacțiunile dintre agenți, date și memoria de context pot fi inspectate și guvernate „inline” (pe flux), în calea de date a infrastructurii AI, cu obiectivul de a impune politici continuu, fără a încetini operațiunile. „AI-ul agențial transformă datele întreprinderii într-un sistem viu, în timp real — iar acel sistem trebuie protejat acolo unde datele se mișcă, unde contextul este stocat și unde agenții acționează”, a declarat Jensen Huang , fondator și CEO al NVIDIA. Ce se schimbă în practică: securitate în stratul de stocare, nu doar la aplicație NVIDIA argumentează că, pe măsură ce companiile trec de la chatboți la agenți autonomi care „raționează, recuperează și acționează” pe date interne, stocarea devine un punct de control în timp real. În acest context, Vera BlueField-4 STX ar urma să reducă expunerile generate de accesul continuu la date și de partajarea automată de informații. Conform materialului, NVIDIA DOCA permite: detecție a amenințărilor la rulare „de până la 1.000x” mai rapidă decât soluțiile existente „agentless runtime” (fără agent instalat pe sistemele monitorizate); aplicarea politicilor de acces la rețea și fișiere la viteze de până la 800 Gb/s. Componentele DOCA anunțate pentru Vera BlueField-4 STX Capabilitățile de securitate menționate includ biblioteci și microservicii DOCA aduse în stratul de stocare pentru AI: NVIDIA DOCA Vault (microservicii): pentru a se asigura că doar sarcinile de lucru AI autorizate pot accesa fișierele potrivite, cu permisiunile potrivite. NVIDIA DOCA Argus : vizibilitate asupra comportamentului agenților și activității sarcinilor de lucru AI. NVIDIA DOCA Flow : izolare a traficului de rețea și protecția datelor sensibile în medii AI multi-tenant (cu mai mulți clienți/echipe pe aceeași infrastructură). NVIDIA susține că politicile pot fi aplicate direct în cip, în timp ce datele continuă să circule la „vitezele” cerute de infrastructurile de tip „AI factory”. Ecosistem: securitate, stocare și integratori Publicația listează parteneri care integrează soluții de securitate enterprise cu Vera BlueField-4 STX, între care Akamai, Armis (ServiceNow), Check Point, Cisco, CrowdStrike, EQTY, F5, Fortinet, Palo Alto Networks, TrendAI, Xage Security și Zscaler (fără a detalia nivelul sau calendarul fiecărei integrări). Pe zona de stocare și sisteme, sunt menționați furnizori precum Cloudian, DDN, Dell Technologies, Hitachi Vantara, HPE, IBM, MinIO, NetApp, Nutanix, VAST Data și WEKA, precum și producători (AIC, ASUS, Foxconn, Gigabyte, QCT, Supermicro, Wistron, Wiwynn). La nivel de implementare, NVIDIA indică și implicarea unor integratori globali precum Accenture, Deloitte și Worldwide Technology. Disponibilitate Platformele bazate pe STX sunt „așteptate” să fie disponibile de la parteneri în a doua jumătate a lui 2026, conform anunțului. Materialul nu oferă detalii despre prețuri, configurații sau condiții comerciale. [...]