Ernst & Young ekspozon një bazë të dhënash 4 TB në internet, çfarë shkoi keq?

0

Një gabim në sistemin cloud ka bërë që një sasi e madhe të dhënash, që i përkasin njërës prej firmave më të mëdha të shërbimeve profesionale në botë, të bëhet publike. Sipas disa studiuesve të pavarur të sigurisë kibernetike, një skedar rezervë (backup) i SQL Server, me madhësi 4 terabajt, që i përkiste Ernst & Young (EY), ishte i aksesueshëm publikisht në internet përmes shërbimit Microsoft Azure Storage.

Edhe pse nuk duket se është përfshirë në ndonjë sulm kibernetik, incidenti tregon se edhe organizatat më të mëdha e më të sofistikuara mund të bien pre e gabimeve të thjeshta të konfigurimit, në një kohë kur përdorimi i shpejtë i teknologjisë cloud është bërë normë.

Problemi u zbulua nga kompania holandeze e sigurisë Neo Security, gjatë një skanimi rutinë të rrjeteve dhe aseteve cloud.

Neo Security nuk shkarkoi përmbajtjen e plotë të skedarit (gjë që do të kishte pasoja ligjore), por arriti të marrë rreth 1,000 byte të mjaftueshme për të verifikuar se bëhej fjalë për një backup të pakriptuar të SQL Server.

Më pas, studiuesit nisën një proces gjurmimi për të identifikuar pronarin e të dhënave të ekspozuara. Metadata fillestare e ruajtjes nuk tregonte se kujt i përkiste, por kërkime të mëtejshme, si dokumente bashkimi (të përkthyera nga një gjuhë e Europës Jugore Qendrore) dhe një kërkim DNS SOA (Start of Authority) që tregonte për domenin “ey.com”, i çuan ata në përfundimin se skedari i përkiste EY.

Përmasat dhe rreziqet

Një skedar backup prej 4 terabajtësh nuk është thjesht i madh, ai mund të jetë katastrofik nëse ekspozohet. Madhësia e tij sugjeron një bazë të dhënash të konsiderueshme që mund të përmbajë:

  • struktura të tabelave,
  • të dhëna përdoruesish,
  • kredenciale hyrjeje,
  • “token”-e autentikimi,
  • kode të llogarive të shërbimeve,
  • madje edhe sekrete API-sh ose sesione të ruajtura në cache.

Studiuesit paralajmëruan se një ekspozim i tillë është i ngjashëm me “lënien e planit të ndërtesës dhe çelësave të kasafortës mbi tavolinë, me një shënim që thotë ‘falas për këdo që e do’.”

Platformat e skanimit cloud, të përdorura nga sulmues ose “bote” automatike, mund të zbulojnë hapësira të tilla publike brenda minutash. Sipas Neo Security dhe mediave që raportuan për rastin, pyetja kryesore nuk është “nëse dikush e gjeti skedarin”, por “sa veta e gjetën”.

EY deklaroi se skedari i përkiste një njësie që ishte blerë nga dega e saj në Itali, dhe se asnjë e dhënë klientësh, personale apo konfidenciale e EY Global nuk ishte prekur.

Megjithatë, incidenti ngriti dy çështje urgjente:

  1. Edhe organizatat më të mëdha dhe me buxhete të mëdha IT mund të gabojnë në konfigurimin e ruajtjes në cloud, duke ekspozuar të dhëna shumë të ndjeshme.
  2. Në epokën e cloud, ku të dhënat lëvizin shpejt dhe lejet janë të ndërlikuara, monitorimi i vazhdueshëm dhe skanimi automatik për konfigurime të gabuara janë bërë domosdoshmëri, jo luks.

Çfarë shkoi keq?

Zinxhiri i plotë i ngjarjeve nuk është bërë publik, por burime të shumta tregojnë një gabim klasik: gjatë një procesi migrimi ose ruajtjeje të të dhënave nga serverët lokalë në cloud, një “container” ose “bucket” u vendos gabimisht si publik, në vend që të ishte privat.

Një shembull tipik: një administrator eksporton bazën e të dhënave (krijon një skedar .BAK), e ngarkon në një “blob” në cloud për ta përdorur më vonë dhe harron të ndryshojë listën e kontrollit të aksesit (ACL) për të kufizuar qasjen publike.

Platformat moderne cloud theksojnë thjeshtësinë dhe shpejtësinë: zgjedh bazën e të dhënave, përcakton destinacionin, planifikon eksportin, por nën sipërfaqe, mungojnë masat mbrojtëse kundër gabimeve të tilla.
Një klikim i gabuar, një emër “bucket”-i i shkruar keq, dhe papritur të dhënat private mund të qëndrojnë në hapësirë publike.
Ky rast tregon sa e lehtë është të rrjedhin terabajtë të dhënash ndjeshme për shkak të një gabimi njerëzor.

Skedari i ekspozuar qëndroi aty derisa Neo Security e zbuloi me skanimin e saj; kohëzgjatja e ekspozimit ende nuk është verifikuar në mënyrë të pavarur.

Reagimi dhe pasojat

Sipas raportimeve, Neo Security u përpoq të kontaktonte EY në disa mënyra, përfshirë përmes LinkedIn, përpara se të arrinte të lidhej me ekipin e reagimit ndaj incidenteve të EY. Procesi i kontaktimit thuhet se mori rreth 15 përpjekje përmes LinkedIn.

Në deklaratën publike të EY thuhet se ekspozimi kishte ndodhur disa muaj më parë dhe se është zgjidhur tashmë. Ata theksuan gjithashtu se rasti ishte i kufizuar vetëm në një entitet të blerë nga EY Italia, dhe nuk kishte lidhje me sistemet globale të EY.

Ekspertët e sigurisë, megjithatë, theksojnë se edhe nëse organizata pretendon se të dhënat e klientëve nuk janë prekur, fakti që një skedar i tillë ka qenë publikisht i arritshëm për një periudhë të panjohur, krijon rrezik, pasi bote automatike ose hakerë mund ta kenë shkarkuar tashmë.

Pasojat më të gjera

Ky incident i konfigurimit të gabuar në cloud tregon një rrezik sistemik më të gjerë në infrastrukturën moderne të IT-së:

  • Shkalla dhe shpejtësia: Organizatat po zhvendosin sasi të mëdha të dhënash në cloud me ritme të shpejta dhe sa më shpejt. Kjo rrit mundësinë e gabimeve njerëzore.
  • Probleme vizibiliteti: Shumë kompani nuk kanë kontroll të plotë se çfarë është ekspozuar dhe ku.
  • Automatizimi në favor të sulmuesve: Mjetet e automatizuara të skanimit që përdorin sulmuesit janë më të shpejta se auditimet manuale që bëjnë mbrojtësit.
  • Rreziku i nënvlerësimit: Deklaratat e korporatave se “asnjë e dhënë nuk u prek” shpesh bazohen në analiza të brendshme, por nëse një pasuri është publike, duhet të supozohet komprometimi, dhe pastaj të provohet e kundërta.
  • “Zero Trust” nuk mjafton pa vetëdije për asetet: Edhe nëse ke një arkitekturë sigurie shumë të fortë, nëse lë një kopje të plotë të bazës së të dhënave pa mbrojtje, çdo kufi sigurie humbet kuptimin.

Për organizatat që përdorin teknologjinë cloud (Azure, AWS, Google Cloud, etj.), ky rast tregon nevojën për:

  1. Mbajtjen e një inventari të vazhdueshëm të aseteve – çdo “bucket”, “blob”, “container”, “snapshot” dhe “backup” duhet të jetë i dokumentuar.
  2. Zbatimin e mjeteve automatike për zbulimin e ekspozimeve – që simulojnë veprimet e sulmuesve, jo vetëm auditimet e brendshme.
  3. Vendosjen e politikës “default-deny” – çdo skedar backup duhet të jetë privat, përveç rasteve kur është domosdoshmërisht publik.
  4. Zbatimin e parimit të “privilegjit minimal” dhe enkriptimit në pushim (encryption-at-rest) – në mënyrë që edhe nëse ndodh ekspozimi, të dhënat të jenë të padobishme për palët e jashtme.
  5. Mbajtjen e regjistrave të pandryshueshëm (immutable logs) dhe fshirja ose arkivimi – çdo backup më i vjetër se një periudhë e caktuar duhet të fshihet ose të arkivohet.
  6. Përfshirjen e skenarëve të gabimeve në cloud në testet e reagimit ndaj incidenteve – jo vetëm për sulmet kibernetike, por edhe për gabime njerëzore.
  7. Krijimin e kanaleve të qarta për raportimin e dobësive nga studiues të jashtëm, që çështje të tilla të raportohen dhe të zgjidhen shpejt.

Fakti që një skedar i vjetër backup (.BAK) u la i hapur në internet mund të duket i parëndësishëm në një epokë ku dominon frika nga sulmet zero-day apo aktorët shtetërorë, por ky rast tregon se rreziqet e vjetra mbeten po aq të fuqishme.
Backup-i prej 4 terabajtësh i lënë nga EY ishte praktikisht “një derë kasaforte e lënë hapur”, që kushdo mund ta gjente.

Në garën e cloud computing për shpejtësi dhe shkallë, kontrolli, qeverisja dhe vigjilenca e vazhdueshme janë të panegociueshme.
Për EY dhe të tjerët, pyetja nuk është më “si të mbrohemi nga sulmuesit?”, por “si të kuptojmë çfarë kemi ekspozuar tashmë?”

Nëse një kompani si EY, një nga katër të mëdhatë në botë, mund të bëjë një gabim të tillë, atëherë një problem i tillë mund t’I ndodhë kujtdo. / Neo Security, LinkedIn

 

The post Ernst & Young ekspozon një bazë të dhënash 4 TB në internet, çfarë shkoi keq? appeared first on Revista Monitor.

PËRGJIGJU

Please enter your comment!
Please enter your name here

3 × three =