K

ontynuując naszą serię Necronomicon zajmiemy się dzisiaj publicznymi wiaderkami danych, które są umieszczone w chmurze. Bardzo wiele firm i prywatnych osób nadal przeprowadza adopcję chmury publicznej, której flagową usługą jest możliwość taniego przechowywania plików różnej maści. Mimo wielu badań, opracowań i raportów niewielu z tych adeptów zdaje sobie sprawę, że gdy tylko zdecydują się na ustawienie (świadomie lub nie) publicznego dostępu do dowolnego wiaderka (ang. bucket) istnieje duże prawdopodobieństwo, że ich nazwy zostaną odgadnięte, a dane zindeksowane oraz wystawione innym użytkownikom do łatwego przeszukiwania i pobierania. 24 września 2023 roku wyszukiwarka GrayHatWarfare przyznała, że jej baza danych zawiera 416.712 różnych wiaderek danych, 316.00 z S3, 6800.000 z DigitalOcean, 44000 z Google oraz 49.900 otwartych kontenerów z Azure, co daje łącznie 10,4 miliarda publicznie dostępnych plików. Patrząc z perspektywy bezpieczeństwa te wszystkie publiczne magazyny danych zawierają wiele szalonych rzeczy: pliki PST (które można zaimportować do programu Outlook, jako kompletne skrzynki e-mail); paszporty (których zapisywanie jest nielegalne w kilku krajach); certyfikaty urodzin; numery ubezpieczenia społecznego z USA; recepty oraz dane medyczne; rachunki i dane klientów; polisy ubezpieczeniowe; klucze licencyjne; dane dostępowe; klucze dostępowe; tokeny; certyfikaty TLS; pliki konfiguracyjne do narzędzi: WinSCP, FileZilla, Sublime, Menedżery haseł, VPN, Gitlab; Pliki konfiguracyjne PHP…
[ czytaj całość… ]

I

nernet to wodospad cieknących danych. W mojej pierwszej serii Necronomicon ( część I oraz II) mogliśmy się o tym przekonać na przykładzie skracarek adresów URL. Dzisiaj zajmiemy się serwisami oferującymi miejsce na repozytoria kodu. Ale od początku. Jakieś dziesięć lat temu powstał ruch DevOps – przechodząc przez różne etapy rozwoju dołączono do niego kolejny człon – DevSecOps. Upraszczając: jest to ruch, który osadza w cykl życia oprogramowania procesy bezpieczeństwa. Jego braki lub luki proceduralne są częstym i w dużej mierze niedocenianym wektorem zagrożeń dla wielu firm i organizacji.
[ czytaj całość… ]

W

poprzedniej części zebraliśmy i przygotowaliśmy do wstępnej obróbki zbiór danych pochodzący z skracarek URL. W tej części zajmiemy się jego umieszczeniem w silniku wyszukiwania, który umożliwi nam bardzo szybkie pozyskiwanie interesujących nas informacji. Jak wcześniej wspomnieliśmy na naszej maszynie wirtualnej uruchomiony jest system Ubuntu 18.04 LTS. Sama maszyna ma 2 CPU / 4 GB RAM oraz 100 GB dysku z czego 57 GB jest już zajęte przez ściągnięte, skompresowane dane. W tej części artykułu interesuje nas stworzenie następnego przepływu danych:

[/data/archive/*/*/*.txt] --> [logstash] --> [elasticsearch] --> [kibana]

[ czytaj całość… ]

S

erwisy oferujące skracanie adresów URL są do dzisiaj powszechnie stosowane. Pozwalają one utworzyć wygodny, krótki adres URL, który służy jako przekierowanie do długich i złożonych adresów. Skrócony adres URL może na przykład wyglądać tak: https://bit.ly/2TeiuwH. Po kliknięciu w niego nastąpi natychmiastowe przekierowanie do adresu URL bit.ly zapisanego za magiczną wartością 2TeiuwH (jeśli kliknąłeś w poprzedni link bez sprawdzenia dokąd prowadzi – dziękuje za zaufanie). Problem w tym, że “skróty” te można “złamać” poprzez ataki brute force. Dlatego używając tego typu serwisów nigdy nie powinniśmy w nich ukrywać linków do poufnych informacji. Zespół URLTeam z serwisu archiveteam.org – postawił sobie za cel badanie i odkrywanie tajemnic, jakie kryją się w tych magicznych wartościach.
[ czytaj całość… ]