Czasem nie potrzeba skomplikowanego ataku, żeby doprowadzić do katastrofy w firmie. Wystarczy zwykły ludzki błąd, zwykła nieuwaga. Tak było w przypadku niedawno ujawnionego incydentu, który opisali badacze z NeoSecurity, którzy podczas rutynowego skanowania natknęli się na backup SQL Servera o rozmiarze aż 4 TB, który był publicznie dostępny w sieci.
I nie był to plik przypadkowej firmy. Z analiz wynikało, że dane należały do Ernst & Young (EY), globalnego giganta audytu i doradztwa biznesowego.
Jak do tego doszło?
Zespół NeoSecurity prowadził standardowe badania ekspozycji zasobów w internecie – skanowanie serwerów, testowanie odpowiedzi HTTP, analiza nagłówków. W jednym z przypadków serwer odpowiedział komunikatem „200 OK”, ale uwagę badaczy przykuł nagłówek Content-Length, wskazujący na plik o wielkości około 4 terabajtów.
Po sprawdzeniu nazwy pliku okazało się, że kończy się on rozszerzeniem .bak, czyli typowym dla kopii zapasowych baz danych Microsoft SQL Server. Badacz jednoznacznie potwierdził, że to prawdziwy plik backupu, niezaszyfrowany i dostępny bez żadnych ograniczeń.
Kolejnym krokiem była analiza DNS, z której jasno wynikało, że zasób należy do infrastruktury EY.
Po dalszej analizie badacz potwierdził, że to nie był fałszywy trop. Plik faktycznie był kopią zapasową, a co najgorsze – nie był w żaden sposób zabezpieczony. Ani hasła, ani szyfrowania. Nic.
4 TB ryzyka
Choć badacz nie pobrał całego pliku i choć nie ma dowodów, że ktoś pobrał cały plik (co przy 4 TB byłoby dość trudne), to sam fakt, że był on dostępny publicznie, to już ogromny problem.
Backup SQL Servera to nie jest przypadkowa paczka danych – to kompletne odwzorowanie systemu: tabele, procedury, dane użytkowników, loginy, tokeny, a często także hasła.
Jak słusznie zauważyli eksperci NeoSecurity, taki plik to gotowy prezent dla każdego atakującego zawierający pełen obraz tego, co dzieje się w środku firmy.
EY reaguje, ale niesmak pozostaje
Po zgłoszeniu sprawy przez badacza, plik szybko został usunięty z publicznego dostępu. EY przyznało, że analizuje incydent i wdrożyło dodatkowe środki bezpieczeństwa, by uniknąć podobnych sytuacji w przyszłości.
Mimo to sprawa wywołała spore poruszenie w branży, bo pokazuje coś, o czym wiele firm woli nie mówić głośno, że nawet najwięksi mogą popełnić proste błędy konfiguracyjne.
Dlaczego takie rzeczy się zdarzają?
Chmura daje ogromne możliwości, ale też bywa zdradliwa. Wystarczy jedno nieopatrzne kliknięcie przy ustawieniu uprawnień i zasób, który miał być prywatny, staje się widoczny dla całego świata.
Jak podkreślili badacze z NeoSecurity, ich systemy regularnie znajdują podobne przypadki – od zapomnianych bucketów po testowe środowiska z prawdziwymi danymi. I choć EY to potężna korporacja, takie błędy nie są wyjątkiem, tylko codziennością.
Czego możemy się z tego nauczyć?
- Nie zakładaj, że chmura zrobi wszystko za ciebie.
- Backup to nie śmietnik. Traktuj każdy backup jak dane produkcyjne – zaszyfruj, ogranicz dostęp, monitoruj.
- Automatyzuj skanowanie powierzchni ataku – narzędzia ASM (Attack Surface Management) pomagają wychwycić takie przypadki, zanim zrobią to inni.
- Przygotuj procedurę zgłaszania incydentów – badacz, który znalazł ten plik, miał problem z dotarciem do odpowiednich osób w EY.
Wnioski
Patrząc na to z perspektywy praktyka, trudno nie zgodzić się z wnioskami badaczy.
To nie był atak, nie była luka „zero-day” a czysto ludzki błąd, który mógł kosztować firmę fortunę.
Wielu administratorów nadal ufa, że skoro coś działa i jest w chmurze, to jest „w porządku”. Tymczasem bezpieczeństwo zaczyna się od świadomości – od prostego pytania: czy na pewno wiem, co jest w mojej infrastrukturze?
Incydent z EY pokazuje, że nawet najwięksi mogą się potknąć. Nie ma znaczenia, czy jesteś startupem, czy globalnym graczem – wystarczy chwila nieuwagi, by Twoje dane znalazły się na widoku.
pełna analiza: https://www.neosecurity.nl/blog/ey-data-leak-4tb-sql-server-backup
