Știri
Știri din categoria Securitate cibernetică
Android va începe să închidă automat apelurile care se dau drept bănci, o schimbare cu impact direct asupra fraudelor telefonice, potrivit Android Police. Măsura vizează în special apelurile în care escrocii „clonează” (spoof) numărul sau numele unei instituții financiare pentru a părea legitimi.
Noua funcție urmărește să reducă pierderile generate de escrocherii care se prezintă ca fiind din partea băncilor. Publicația notează că această metodă de fraudă a devenit frecventă și că, la nivel global, escrocii ajung să fure aproape 1 miliard de dolari pe an (aprox. 4,6 miliarde lei) prin astfel de scheme.
Mecanismul descris are două componente:
Protecția nu este „infailibilă”: utilizatorul trebuie să aibă instalată aplicația băncii respective pentru ca verificarea să funcționeze.
Google spune că funcția va fi disponibilă pe dispozitive cu Android 11 și versiuni mai noi și va începe să fie distribuită „în următoarele săptămâni”. La lansare, suportul este menționat pentru Revolut, Itaú și Nubank, iar extinderea către alte aplicații bancare ar urma să vină în cursul anului următor.
În același anunț, Google a prezentat și alte măsuri de securitate pentru Android, inclusiv controale suplimentare pentru situațiile de furt (de exemplu, opțiuni mai stricte în „Mark as Lost” din Find Hub) și monitorizare „dinamică” a comportamentului aplicațiilor pentru a semnala posibile tentative de furt de date, cu opțiunea de dezinstalare.
Recomandate
Un atac coordonat de inteligența artificială a scos la iveală o vulnerabilitate „zero-day ” în software-ul Google , ridicând miza operațională pentru companii: apărarea nu mai înseamnă doar patch-uri rapide, ci și capacitatea de a detecta exploatări pe care nici dezvoltatorii nu le cunosc, potrivit Mediafax . Atacul a fost respins, însă cazul evidențiază riscul ca IA să accelereze descoperirea și exploatarea breșelor. Publicația notează, citând Futurism, că atacul a folosit inteligența artificială pentru a identifica o eroare majoră în software-ul Google despre care dezvoltatorii nu aveau cunoștință. Reprezentanții companiei nu au precizat cine s-a aflat în spatele atacului. De ce contează: „zero-day” găsite cu IA pot depăși apărarea standard Google a indicat că atacatorii au identificat o „vulnerabilitate zero-day” – adică o eroare dintr-un software necunoscută până atunci celor care îl dezvoltă. În astfel de situații, apărătorii nu au, de regulă, soluții pregătite din timp, iar fereastra de risc poate fi critică. În cazul descris, vulnerabilitatea ar fi permis ocolirea autentificării cu doi factori pe un „instrument popular de administrare a sistemului, open-source, bazat pe web”. Instrumentul nu este numit în material. Potrivit informațiilor citate, accesul ar fi fost posibil dacă atacatorii ar fi avut numele de utilizator și parola unei persoane. Impact operațional: autentificarea cu doi factori nu mai e suficientă, singură Materialul subliniază că autentificarea cu doi factori este „ultima linie de apărare semnificativă” pentru majoritatea utilizatorilor, în condițiile în care parolele sunt adesea slabe. În acest context, o metodă de ocolire a autentificării cu doi factori ar fi putut avea „un efect catastrofal”, conform sursei. Experții citați au descris cazul drept primul exemplu de vulnerabilitate zero-day exploatată de hackeri cu ajutorul inteligenței artificiale și îl văd ca un semnal despre ce ar putea urma, pe fondul dezvoltării accelerate a produselor bazate pe IA. [...]
Google își extinde apărarea anti-fraudă cu filtre bazate pe inteligență artificială și schimb de date între companii și autorități , mizând pe blocarea la scară mare a tentativelor de înșelăciune înainte să ajungă la utilizatori, potrivit Google Blog . Mesajul vine în contextul în care compania descrie atât măsuri tehnice integrate în produse (Gmail, Chrome, Search, Android), cât și colaborări cu instituții publice și inițiative educaționale. În centrul strategiei este folosirea inteligenței artificiale ca „primă linie” de apărare, cu rezultate prezentate ca volum și rată de blocare: Google spune că oprește peste 99,9% din spam, phishing și programe malițioase înainte să ajungă în Gmail și că blochează aproape 15 miliarde de e-mailuri nedorite pe zi. În Chrome, compania afirmă că anticipează și blochează în timp real site-uri periculoase, iar în Search filtrează „sute de milioane” de pagini de tip spam zilnic, pentru a menține rezultatele „99% fără spam”. Filtrare la scară mare în publicitate și detecție pe dispozitiv Pe zona de publicitate, Google indică faptul că în 2025 sistemele sale au identificat peste 99% dintre reclamele care încălcau politicile înainte să fie văzute de utilizatori și că a blocat sau eliminat peste 8,3 miliarde de reclame, dintre care 602 milioane asociate cu escrocherii. Tot pe linia protecțiilor automate, compania menționează „Scam Detection” în aplicația Phone by Google, unde inteligența artificială rulează pe dispozitiv și alertează utilizatorii în timp real atunci când detectează tipare conversaționale specifice escrocilor. Instrumente pentru utilizatori: verificare rapidă și semnale în timp real Google pune accent și pe instrumente prin care utilizatorii își pot întări securitatea conturilor și pot verifica suspiciuni „în momentul în care apar”: Security Checkup , pentru consolidarea setărilor de securitate ale contului, inclusiv activarea „Passkeys” (chei de acces) și verificarea în doi pași (2-Step Verification); Circle to Search pe Android, care permite selectarea unui mesaj suspect pentru o evaluare bazată pe inteligență artificială și recomandări; alternativ, aceeași verificare se poate face prin captură de ecran și Google Lens . Educație și finanțare: program interactiv și ținte de acoperire Pe componenta de prevenție, Google descrie inițiativa „Be Scam Ready”, un program interactiv, de tip joc, care simulează în siguranță scenarii de fraudă. Compania susține că abordarea „învățare prin practică” are rezultate mai bune decât campaniile tradiționale de conștientizare. Programul este disponibil în engleză, portugheză, thailandeză și chineză tradițională și ar urma să fie lansat în mai multe limbi „mai târziu în acest an”, inclusiv franceză, spaniolă și arabă. În plus, Google reamintește un angajament de 5 milioane de dolari (aprox. 23 milioane lei) prin Google.org, anunțat la summitul de anul trecut, pentru combaterea escrocheriilor în Europa și Orientul Mijlociu. Beneficiarii menționați, Internet Society (ISOC) și Oxford Information Labs (OXIL), derulează programe de instruire „la firul ierbii”, cu obiectivul de a proteja peste 7 milioane de persoane vulnerabile și de a echipa mii de lucrători din prima linie cu instrumente de „reziliență” la fraude. Schimb de date și acțiuni împotriva rețelelor: GSE, poliție și litigii Pentru a opri fraudele care operează pe mai multe platforme și în mai multe țări, Google indică rolul Global Signal Exchange (GSE), descris ca un „clearinghouse” global pentru date despre amenințări. Platforma ar stoca peste 1,2 miliarde de „semnale”, iar Google, ca partener fondator, atât consumă, cât și furnizează informații, în timp ce modelele sale de inteligență artificială analizează semnalele pentru a identifica tipare care pot sprijini investigații și acțiuni de aplicare a legii. Pe partea de intervenție, compania spune că lucrează cu agenții de aplicare a legii, inclusiv cu National Crime Agency (NCA) din Marea Britanie, și că, pe baza semnalelor partajate prin GSE, echipele sale au identificat și perturbat o rețea de fraudă din Africa de Vest. Google mai menționează că este semnatar al „Industry Accord Against Online Scams and Fraud” și că a inițiat acțiuni legale împotriva unor operațiuni, inclusiv „Lighthouse” (o rețea de tip „phishing-as-a-service”, adică furnizare de infrastructură pentru atacuri de tip phishing) și operatorii botnetului BadBox. În ansamblu, mesajul companiei este că lupta anti-fraudă se mută tot mai mult în zona de automatizare prin inteligență artificială și cooperare interinstituțională, cu efect direct asupra modului în care sunt filtrate e-mailurile, reclamele și accesul la site-uri, dar și asupra instrumentelor de verificare pe care utilizatorii le au la îndemână. [...]
„Vibe coding” împinge în sus riscul de breșe și scurgeri de date în aplicațiile construite cu ajutorul inteligenței artificiale, pe fondul unei adoptări rapide a acestui mod de lucru, potrivit Android Headlines , care citează concluziile unui studiu. „Vibe coding” descrie, în esență, dezvoltarea de software în care utilizatorul se bazează puternic pe modele de inteligență artificială pentru a genera cod, pe baza unor instrucțiuni în limbaj natural, fără a mai trece prin același nivel de proiectare și verificare tehnică specific programării clasice. Miza pentru companii este operațională: viteza de livrare crește, dar crește și probabilitatea ca în produs să ajungă vulnerabilități. De ce contează pentru companii: viteză mai mare, control mai slab Din perspectivă de securitate cibernetică , riscul major semnalat este că aplicațiile și componentele generate „pe repede înainte” pot include erori de implementare sau configurații greșite care rămân nedetectate până când sunt exploatate. În practică, asta poate însemna: expunerea neintenționată a datelor (de exemplu, prin setări greșite sau acces neautorizat); introducerea de vulnerabilități în codul aplicației, care pot fi folosite pentru atacuri; dificultăți mai mari de auditare și întreținere, dacă echipele nu înțeleg în detaliu codul generat. Materialul indică faptul că fenomenul este alimentat de popularitatea în creștere a „vibe coding”, iar studiul citat leagă această tendință de o creștere a vulnerabilităților de securitate. Ce urmează: presiune pe procesele interne de securitate În termeni operaționali, concluzia implicită este că organizațiile care folosesc astfel de instrumente vor avea nevoie de controale mai stricte înainte de lansare (testare, revizuire de cod, politici de utilizare a AI în dezvoltare). Android Headlines nu oferă, în fragmentul disponibil, detalii despre metodologia studiului sau despre indicatori cantitativi, astfel că amploarea exactă a creșterii nu poate fi evaluată din informațiile furnizate. [...]
Google împinge autentificarea fără parolă și recuperarea contului ca măsuri „de bază” pentru reducerea riscului de compromitere, într-un set de cinci instrumente pe care utilizatorii le pot activa în contul Google, potrivit Google Blog . Mesajul central: securizarea accesului nu mai depinde doar de „o parolă bună”, ci de metode mai greu de interceptat sau reutilizat și de opțiuni de recuperare care limitează blocarea definitivă a contului. Lista vine în contextul Zilei Mondiale a Parolei și vizează, în principal, scăderea expunerii la atacuri bazate pe parole (ghicire, reutilizare, furt) și creșterea rezilienței contului atunci când utilizatorul își pierde dispozitivul sau datele de autentificare. Ce se schimbă operațional pentru utilizatori: autentificare cu „passkeys” și verificare în doi pași Primul instrument recomandat este folosirea „passkeys” (chei de acces) pentru conturile Google. Google descrie passkeys ca o metodă „mai ușoară și mai sigură” decât parolele și chiar decât unele metode tradiționale de autentificare multifactor, precum codurile de unică folosință. Autentificarea se face prin blocarea ecranului dispozitivului (amprentă, recunoaștere facială sau PIN), iar Google susține că datele biometrice rămân pe dispozitiv și nu sunt partajate cu compania. Al doilea pas este activarea 2-Step Verification (verificare în doi pași, 2SV) ca măsură suplimentară, inclusiv atunci când utilizatorul folosește passkeys. Argumentul din material: dacă cineva încearcă să se dea drept utilizator și pretinde că a pierdut passkey-ul, 2SV adaugă un strat de protecție multifactor. Recuperarea contului și reducerea „suprafeței” de parole Google recomandă și configurarea „Recovery Contacts” (contacte de recuperare) pentru situații precum pierderea telefonului. Utilizatorul poate desemna persoane de încredere care să ajute la confirmarea identității în caz de blocare a accesului. Publicația precizează două limite importante: pot fi setate până la 10 contacte, iar acestea nu primesc acces la cont sau la informațiile personale. Pentru autentificarea în aplicații și site-uri terțe, compania promovează „Sign in with Google” (Conectare cu Google), ca alternativă la crearea de conturi noi cu utilizator și parolă. Rațiunea invocată este reducerea numărului de parole stocate în diverse servicii, ceea ce poate limita expunerea dacă o altă platformă are un incident de securitate; utilizatorul poate revizui și revoca accesul aplicațiilor oricând. A cincea recomandare este folosirea Google Password Manager pentru generarea, salvarea și administrarea parolelor și passkeys pentru alte conturi, cu stocare și sincronizare între dispozitive și completare automată la autentificare. Cele cinci instrumente, pe scurt Passkeys pentru Contul Google (autentificare cu blocarea ecranului dispozitivului) 2-Step Verification (2SV) ca strat suplimentar de protecție Recovery Contacts (până la 10 contacte de recuperare) „Sign in with Google” pentru aplicații și site-uri terțe Google Password Manager pentru parole și passkeys, cu sincronizare între dispozitive Google nu oferă în material date cantitative despre adopție sau eficiență (de exemplu, scăderi măsurate ale compromiterilor), dar poziționează aceste setări ca actualizări rapide care pot crește securitatea autentificării și șansele de recuperare a accesului pe termen lung. [...]
Atacul ransomware asupra Foxconn riscă să expună proiecte și infrastructură ale altor giganți tech, chiar dacă Apple pare neafectată , potrivit AppleInsider . Gruparea Nitrogen susține că a furat peste 8 TB de date (peste 11 milioane de fișiere), iar eșantionul analizat indică documente sensibile legate de proiecte AMD, Google și Intel. Ce s-a întâmplat și ce date ar fi fost luate Foxconn a confirmat că unitatea sa din Mount Pleasant, Wisconsin , a fost afectată de un atac în mai 2026. Nitrogen afirmă că a extras un volum mare de date, incluzând „instrucțiuni confidențiale, proiecte și desene” asociate mai multor companii și inițiative. AppleInsider precizează că nu a publicat linkuri către fișierele presupus furate, dar a analizat setul de mostre pus la dispoziție de atacatori pentru a estima amploarea incidentului. Din eșantion ar reieși, între altele: documente financiare legate de unitatea Foxconn din Houston, Texas; documentație tehnică despre senzori de temperatură, circuite integrate, layout-uri de plăci și alte elemente de inginerie; documente de tip „topologie de rețea” (hărți ale infrastructurii) pentru proiecte AMD, Intel și Google, inclusiv fișiere despre procesoare de server, socket-uri și componente conexe. Publicația notează că setul de mostre pare să fie dominat de materiale ale echipei de inginerie electrică a Foxconn. De ce contează economic și operațional: riscul se mută spre infrastructură și clienți non-Apple Deși titlul incidentului gravitează în jurul lanțului de aprovizionare Apple, miza imediată pare să fie expunerea de informații care pot afecta operațional alte proiecte și clienți ai Foxconn. Analistul Mark Henderson susține că „specificațiile de topologie pentru Google și Intel sunt adevărata problemă”, descriindu-le drept „hărți arhitecturale ale infrastructurii active”, care ar putea fi folosite pentru identificarea vulnerabilităților în centre de date. Separat, atacul ar fi avut și efecte directe în fabrică. Conform publicației locale TMJ4, unitatea din Mount Pleasant a avut o întrerupere de rețea la începutul lunii mai 2026, iar producția ar fi fost întreruptă aproximativ o săptămână, după care a fost reluată. The Cybersec Guru relatează că problemele ar fi început pe 1 mai, cu oprirea Wi‑Fi la 7:00 (ora de Est) și perturbări ale infrastructurii principale până la 11:00 (ora de Est), iar activitatea ar fi rămas afectată până pe 12 mai 2026. „Ni s-a spus să ne oprim computerele și să nu ne mai logăm în niciun caz. Terminalele de pontaj erau moarte. Completam foi de pontaj pe hârtie doar ca să ne urmărim orele.” De ce Apple pare mai puțin expusă în acest caz AppleInsider arată că nu este clar dacă există fișiere legate direct de proiecte Apple existente sau viitoare. Un motiv invocat: unitatea Foxconn din Mount Pleasant produce în principal televizoare și servere de date, nu dispozitive Apple. Pe baza eșantionului analizat, publicația spune că nu pare ca Nitrogen să fi obținut scheme Apple, documentație a echipelor Foxconn implicate în dezvoltarea produselor Apple sau date de control al calității Apple. Totuși, articolul subliniază o limitare importantă: prezența unor documente legate de unitatea din Houston sugerează că atacatorii ar fi putut obține date și din alte locații, nu doar din Wisconsin, inclusiv prin e-mail sau servere de partajare de fișiere. Cine este Nitrogen și ce particularitate are atacul Nitrogen ar fi activă din 2023, cu posibile legături cu ecosistemul BlackHat/ALPHV, și folosește un model de „dublă extorcare” (criptează datele și amenință ulterior cu publicarea lor). În același timp, potrivit Coveware, instrumentul de criptare ESXi folosit de Nitrogen ar avea un defect critic: în timpul criptării, cheia publică a fișierelor se corupe, ceea ce ar face imposibilă decriptarea chiar și dacă se plătește răscumpărarea. Ce urmează Amploarea completă a incidentului rămâne neclară, în condițiile în care volumul revendicat este foarte mare, iar informațiile disponibile provin parțial din mostre publicate de atacatori. Pe datele analizate până acum, AppleInsider apreciază că este puțin probabil ca designurile produselor Apple să apară ca urmare a acestui atac, însă riscul de expunere pentru proiecte și infrastructuri ale altor companii rămâne o problemă majoră. [...]
O campanie de tip supply-chain care a compromis pachete populare din ecosistemele npm și PyPI poate expune credențiale de GitHub, cloud și CI/CD , ceea ce ridică riscul de acces neautorizat în infrastructura de dezvoltare și, implicit, de propagare a codului malițios prin actualizări legitime, potrivit Tom's Hardware . Microsoft Threat Intelligence a transmis într-o postare pe X că investighează compromiterea pachetului PyPI „mistralai”, după ce atacatori ar fi injectat cod malițios care se executa automat la import și descărca un payload secundar deghizat ca „transformers.pyz”, lansând malware pe sisteme Linux. Conform Microsoft, versiunea compromisă ar fi „mistralai” 2.4.6, cu cod inserat în „mistralai/client/ init .py”, care descărca un fișier într-un director temporar și îl executa în fundal. Ce pachete sunt vizate și de ce contează operațional Incidentul apare pe fondul unei „valuri” de compromiteri în lanțul de aprovizionare software (supply-chain), care afectează atât npm (JavaScript), cât și PyPI (Python). Firma de securitate Aikido a avertizat că versiuni malițioase asociate ecosistemului TanStack ar fi fost compromise în două valuri distincte, începând în jurul orei 19:20 UTC (22:20, ora României). Printre pachetele menționate se numără: „@tanstack/react-router” „@tanstack/history” „@tanstack/router-core” Aceste componente sunt descrise ca fiind descărcate „zeci de milioane de ori pe săptămână”, ceea ce amplifică riscul de răspândire rapidă în aplicații și medii de producție. Aikido a mai spus că și mai multe pachete npm ale SDK-ului Mistral ar fi fost compromise în cadrul aceleiași campanii „ Mini Shai-Hulud ”, inclusiv: „@mistralai/mistralai” „@mistralai/mistralai-azure” „@mistralai/mistralai-gcp” În acest context, compania a recomandat dezvoltatorilor să rotească imediat (să înlocuiască) credențiale precum tokenuri GitHub, credențiale npm, chei API de cloud și secrete CI/CD, dacă au instalat pachetele afectate. Miza: credențiale furate din mediile de dezvoltare, nu atacuri la utilizatorul final Deși Microsoft nu a atribuit public compromiterea din PyPI campaniei „Mini Shai-Hulud”, materialul notează că incidentele au trăsături comune: cod malițios introdus în pachete de încredere, descărcare în etape a payload-urilor, furt de credențiale și execuție automată la instalare sau import. Riscul major este unul operațional: mediile moderne de dezvoltare și automatizare (workstation-uri de dezvoltatori, „CI runners” – mașini care rulează automat testele și livrările) conțin frecvent credențiale cu valoare ridicată, precum tokenuri de acces la GitHub, chei de implementare în cloud, credențiale SSH, tokenuri de publicare în npm și acces la sisteme CI/CD. Compromiterea lor poate oferi atacatorilor o cale de a publica actualizări malițioase prin canale legitime, cu efect de cascadă în ecosisteme întregi. Ce măsuri recomandă Microsoft Microsoft a recomandat organizațiilor, între altele, să izoleze gazdele Linux afectate, să blocheze conexiunile către adresa IP malițioasă menționată în analiză, să caute indicatori precum „/tmp/transformers.pyz”, „pgmonitor.py” și „pgsql-monitor.service” și să rotească imediat credențialele potențial expuse. Investigațiile sunt în desfășurare, iar articolul avertizează că ar putea apărea și alte pachete afectate pe măsură ce furnizorii și comunitatea audită infrastructura de publicare și credențialele compromise. [...]
