B

ardzo wiele osób zawsze zadaje sobie pytanie: Jak mój adres e-mail znalazł się w bazie spam? Odpowiedź może być prosta: Sam(a) go przekazał(a)eś. Tak. Np. za pomocą portalu LinkedIn. Jak możemy przeczytać na stronie jest to “największa sieć specjalistów, licząca ponad 467 milionów użytkowników w 200 krajach i terytoriach na całym świecie“. Pytanie ilu z tych użytkowników jest pacynkami ze skarpetek do wyciągania danych?
[ czytaj całość… ]

A

taki typu directory traversal oraz Local File Inclusion bywają często widywane w aplikacjach internetowych. Obydwa te błędy mogą zostać wykorzystane do odczytu dowolnych plików na serwerze. Najczęściej pokazywanym przykładem jest możliwość przeczytania pliku /etc/passwd:
[ czytaj całość… ]

P

ozostańmy jeszcze przy shodanie. Tym razem po to, aby przyjrzeć mu się z punktu widzenia pewnych mechanizmów, środowiska rozproszonego i – bardziej niebezpiecznego. Kilka dni temu, pojawiła się wiadomość, że DC/OS stał się dostępny w chmurze obliczeniowej Azure. W praktyce oznacza to, że uruchamiając X maszyn wirtualnych w tej usłudze, będziemy w stanie spiąć je w jeden klaster, oferujący wspólne zasoby obliczeniowe, pamięciowe i dyskowe. Zyskamy także możliwość dowolnego dzielenia tych zasobów, wedle naszych potrzeb i rodzajów aplikacji, które będziemy chcieli uruchomić.
[ czytaj całość… ]

Z

nowu IofT dał popalić Internetowi. Jak powstrzymać te wszystkie urządzenia przed przejęciem? Hmm… najlepiej je zamknąć przed zewnętrznym dostępem. Ale jak? Co łączy wszystkie te urządzenia? Może protokół? Ale jaki? HTTP. No tak, ale nie wstrzykniemy nim przecież uwierzytelnienia. To musi być coś uniwersalnego… No tak! UPnP. Spójrzmy ile mniej więcej jest wystawionych interfejsów tego protokołu. Według shodana prawie 14 milionów (dokładnie: 13,968,198). To już daje jakieś pole do popisu. Zacznijmy od routerów.
[ czytaj całość… ]

W

świecie HTTP istnieje wiele nagłówków. Niektóre z nich starają się nas chronić inne – wręcz przeciwnie. Poszczególne urządzenia równoważenia obciążenia, serwery www oraz aplikacje webowe ujawniają informacje odnośnie swoich wersji. Czasami dochodzi również do ujawnienia informacji o wewnętrznych sieciach przed którymi się one znajdują. Poniżej zamieszczam kilka przykładów takich wycieków.
[ czytaj całość… ]

S

pójrzmy na poniższy nagłówek HTTP przechodzący przez urządzenie BIG-IP firmy F5 Networks zawierający ciasteczko powodujące przywiązanie klienta do jednego serwera z backendu:

HTTP/1.1 403 Forbidden
Date: Mon, 17 Oct 2016 07:56:53 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: BIGipServerCRM-entryhttps_WAF-Pool=872768522.15168.0000; path=/
Transfer-Encoding: chunked

Zamieńmy liczbę 872768522 na wartość heksadecymalną: 3405640A, rozbijmy ją od tyłu na bloki i ponownie wróćmy do wartości decymalnych:

0A = 10
64 = 100
05 = 5
34 = 52

Hmm… czyżby właście wyciekła informacja o wewnętrznym adresie serwera 10.100.5.52? Zróbmy analogiczną konwersję z liczbą 15168 (3B40), która pewnie oznacza port do komunikacji:

403B = 16443

Finalnie otrzymujemy: 10.100.5.52:16443. Dość ciekawą informacją jest fakt, że samo F5 Networks ujawnia, jak zaszyfrować i rozszyfrować takie dość nieprzemyślane ciasteczko.

Więcej informacji: Overview of BIG-IP persistence cookie encoding

P

o pierwsze ten artykuł nie ma nic wspólnego z współczesnymi technikami hackingu jak obejście ASLR, eksploracją ROP, zdalnym 0day lub łańcuchem 14 różnych błędów, aby złamać Chrome. Nic z tych rzeczy. Omówimy jednak jedną technikę hackingu starej szkoły Uniksa, która działa nawet w dzisiejszych czasach. Technikę, o której (ku mojemu zdziwieniu) wiele osób związanych z bezpieczeństwem nigdy nie słyszało. Prawdopodobnie dlatego, że nikt wcześniej tak naprawdę o niej nie mówił. Dlatego postanowiłem opisać ten temat bo jest on dla mnie osobiście całkiem zabawny, aby przekonać się, co można zrobić za pomocą prostych sztuczek zatrucia wildcardów w Uniksie. Więc w dalszej części możnemy spodziewać się zbioru schludnych hacków na ten temat. Jeśli zastanawiasz się, jak podstawowe narzędzia Uniksa, jak “tar” lub “chown” mogą doprowadzić do kompromitacji systemu – czytaj dalej.
[ czytaj całość… ]

W

2015 roku, dane 13 milionów użytkowników programu MacKeeper wyciekły, z powodu przechowywania ich w otwartej bazie MongoDB. Wówczas, sam autor wyszukiwarki shodan.io przeprowadził badanie i wykrył, że publicznie dostępnych jest około 600 TB danych. Po publikacji wyników badania w lipcu ubiegłego roku, już w grudniu okazało się, że ilość publicznie dostępnych baz NoSQL wzrosła o 5 tysięcy, a ilość danych osiągnęła wolumen 685 TB. Świat devopsów, zamiast wyciągnąć z zaistniałej sytuacji, jeszcze bardziej pogrążył się w koszmarze nieautoryzowanego dostępu do danych.
[ czytaj całość… ]

W

iele serwerów WWW posiada katalogi, których zawartość jest ukierunkowana na konkretne pliki. Oznacza to, że dany /katalog/ nie posiada standardowych plików typu index serwujących treść (lub posiada je puste) oraz nie pozwala na wyświetlenie zawartości całego katalogu często zwracając komunikat o kodzie 403. Mimo to pozwala na dostęp do bezpośrednich zasobów np. /katalog/install.exe. Analogicznie odnieść możemy się do katalogów, w których wdrażane są aplikacje. Są one (powinny być) ograniczane dostępem do konkretnych zasobów. Niestety bardzo często razem z kodem różnych aplikacji lub błędnym działaniem ludzkim przedostają się różnego rodzaju meta informacje, odsłaniające słabe strony tych rozwiązań.
[ czytaj całość… ]

T

infoleak jest prostym skryptem napisanym w języku Python, który pozwala na uzyskanie takich informacji o użytkowniku Twittera, jak:

• podstawowe informacje: nazwę, zdjęcie, lokacje, śledzących itp.,
• urządzenia oraz systemy operacyjne,
• aplikacje oraz używane inne media społecznościowe,
• odwiedzane miejsca oraz dane geolokalizacyjne,
• analizę hashtagów, wspomnień i wiele innych…

Oczywiście informacje te uzależnione są od ustawień konta, jakie wybrał dany użytkownik Twitter’a. Przejdźmy do procesu instalacji i przykładowego użycia skryptu.
[ czytaj całość… ]