Publicznie dostępny plik (4TB) z backupem bazy danych firmy EY

Jeden z badaczy Neo Security zauważył dziwnie wyglądającą odpowiedź HTTP na żądanie typu HEAD. Tego typu żądanie pozwala uzyskać podstawowe informacje o danym zasobie bez pobierania go. W tym przypadku serwer zwrócił odpowiedź z nagłówkiem Content-Length wskazującym, że plik ma 4 terabajty.

TLDR:

– Badacz z Neo Security odkrył publicznie dostępny plik BAK o wielkości 4 TB w Azure Blob Storage.

– Takie pliki zawierają pełne kopie baz danych SQL – w tym potencjalnie identyfikatory sesji i inne dane aplikacji.

– Po identyfikacji właściciela – firmy EY, zajmującej się doradztwem finansowym i audytami – badacz zgłosił incydent i plik przestał być dostępny.

– Publiczny dostęp do takich danych stwarza ogromne ryzyko – plik mógł być pobrany przez wiele nieupoważnionych podmiotów.

– Przypadek EY pokazuje, że nawet duże firmy mogą popełnić krytyczne (i trywialne) błędy w zabezpieczeniach.

Zasób ten był publicznie dostępny w ramach usługi Azure Blob Storage (to taki trochę Ażurowy 😉 odpowiednik S3 od Amazona).

Mowa o pliku BAK, czyli kopii zapasowej serwera Microsoft SQL (odpowiadającego za bazy danych). Zawiera wszystko: strukturę baz oraz – co najważniejsze – ich tabele wraz z przechowywanymi danymi.

W tym wszelkie zapisane klucze API, identyfikatory sesji, tokeny uwierzytelniające. Wszystko, co przechowuje aplikacja.

Historia zna już przypadki publicznie dostępnych plików (np. te z Wojewódzkiego Inspektoratu Ochrony Środowiska). Ale nie słyszeliśmy jeszcze o udostępnionej w ten sposób kopii bazy z 4 TB danych. Na etapie znalezienia pliku badacz z Neo nie wiedział jeszcze, do kogo on należy. Próbując ustalić właściciela bucketa, w którym plik był przechowywany, natknął się na adres serwera DNS działającego w domenie ey[.]com. 

Domena ta należy do firmy EY (dawniej Ernst & Young), czyli międzynarodowego koncernu zajmującego się doradztwem finansowym i audytami. Badacz nie pobrał jednak całej bazy danych, bo wykraczałoby to znacznie poza ramy etycznego hackingu. Postanowił pobrać pierwsze 1000 bajtów, aby przekonać się, czy faktycznie doszło do naruszenia. Plik mógłby przecież być zaszyfrowany, przez co nie można byłoby odczytać jego zawartości.

Tak jednak nie było. Plik nie był zaszyfrowany i faktycznie zawierał kopię bazy danych. Przez nieokreślony bliżej czas był publicznie dostępny.

Badacz założył, że plik mógł zostać wielokrotnie pobrany – mając na względzie istnienie narzędzi skanujących – to nie pytanie, czy ktoś znalazł plik, tylko ile osób go znalazło. Zaczął więc szukać kontaktu do działu security, programu Bug Bounty lub innego odpowiedniego miejsca. Nic takiego jednak nie znalazł.

Wszedł więc na LinkedIn i zaczął wysyłać wiadomości do przypadkowych osób związanych z firmą – prosząc o kontakt do działu bezpieczeństwa. Po 15 próbach znalazł kogoś, kto zrozumiał sytuację i połączył go z zespołem CSIRT.

Od tego momentu wszystko przebiegło profesjonalnie. Otrzymał potwierdzenie, że firma zajmuje się tematem. Tydzień później problem został zdiagnozowany i całkowicie usunięty. Reakcja firmy była wzorcowa – bez grożenia pozwami, bez ignorowania i bez komunikatów w stylu to nie bug, to feature. Po prostu naprawili zgłoszony błąd.

Mniej pozytywny jest fakt, że jeśli firma EY (ze swoim zespołem bezpieczeństwa, certyfikatami ISO, budżetem na poziomie Wielkiej Czwórki, podlegająca regulacjom) może mieć publicznie dostępną w Internecie kopię zapasową serwera SQL o wielkości 4 TB, to o ilu podobnych plikach nie wiemy?

Badacze z Neo Security przywołali przy tej okazji przypadek sprzed kilku lat, gdy analizowali atak ransomware na jedną z firm. Okazało się, że atakujący uzyskali dostęp do firmowych systemów właśnie przez dostępny publicznie plik BAK. Był on upubliczniony przez 5 minut.

Okazało się, że jeden z pracowników miał problem z migracją bazy danych. Żeby nie kombinować z konfiguracją firewalla i VPN, postanowił na chwilę włączyć publiczny dostęp do pliku, na którym pracował. Wszystko zadziałało i po chwili ograniczył dostęp. Chwila ta okazała się jednak wystarczającym czasem dla atakujących.

Dzięki zautomatyzowanym skanerom byli oni w stanie znaleźć plik i pobrać go, przez co poznali kolejne dane dostępowe – to z kolei pozwoliło już na uzyskanie dostępu do infrastruktury, a skutkiem był atak ransomware. Jak widać niezależnie od zaawansowanych zabezpieczeń danej usługi, zwykła nieuwaga czy drobne odstępstwo od procedur może stać się powodem wycieku danych i najsłabszym ogniwem w nawet najlepiej zabezpieczonej organizacji.

Źródła:

• neosecurity.nl
• www.techradar.com

~Tymoteusz Jóźwiak