O

skracarkach adresów URL (ang. shorturls) mówiliśmy nie raz, nie dwa. Ogólnie rzecz biorąc ich używanie ich jako przekierowanie prowadzące do wrażliwych danych wiążę się z dużym ryzykiem. Oprócz tego, że tego typu adresy są łamane w celu odgadywania i katalogowania obiektów do których prowadzą to jeszcze posiadają inną wadę – mogą zostać przejęte. Gdy użytkownik tworzy krótki link w danej skracarce, zazwyczaj wygląda on tak: “skrót.pl/“, po którym następuje losowy ciąg cyfr i liter stworzony przez usługę np. 2TeiuwH, co daje nam: https://skrót.pl/2TeiuwH. Jednak w wielu tego typu serwisach użytkownicy mogą również dostosowywać tylną część, która pojawia się po ukośniku (“/”). Jeśli taki niestandardowy, ostatni człon adresu URL (2TeiuwH) jest już gdzieś używany, serwis informuje użytkownika, że dana fraza jest już zajęta i musi wybrać inną. Jednak mogą zdarzyć się błędy związane z weryfikacją ulotnych danych takich skracarek. Na przykład ze względu na niechęć wyczerpania się możliwych kombinacji adresów URL o określonej długości – serwisy mogą umożliwiać użytkownikom tworzenie niestandardowych części tych adresów, które były już wcześniej używane – ale oryginalny link lub konto odpowiedzialne za jego stworzenie w danym serwisie zostało usunięte lub dezaktywowane. Wówczas dochodzi do reużycia lub rotacji właściciela tego samego adresu URL, który może tym razem kierować w inne miejsce niż pierwotnie to robił oryginał. Jak możemy się domyślić – w zależności gdzie historycznie został użyty i opublikowany skrócony adres URL: czy to na profilu społecznościowym kogoś ważnego / popularnego, czy to w bardzo poczytnym serwisie / artykule – jego przejęcie i przekierowanie w szkodliwe miejsce może mieć negatywne konsekwencje zarówno dla autora wpisu, jak i czytelnika.

Atakujący tak banalną metodą może doprowadzić np. do uwiarygodnienia szkodliwej strony, która będzie wyłudzała dane uwierzytelniające lub środki finansowe tworząc ją w taki sposób, aby wpisywała się w kontekst w jakim został użyty skrócony adres URL. To samo może tyczyć się już docelowych adresów URL, do których prowadzą skrócone adresy URL. Jeśli skrócony adres jest nadal aktywny, ale docelowa domena już wygasła i jest wolna – może zostać ona ponownie zarejestrowana i zmanipulowana do serwowania szkodliwej treści lub bycia kolejnym przekierowaniem do takowej.

Więcej informacji: Crypto scammers hacked Trump’s tweets via a bug

curl -s https://nfsec.pl | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*" | sort -u

Więcej informacji: SpiderFoot

D

zisiaj Pinaki zwrócił uwagę na sposób generowania adresów URL zawartych w phishingu wymierzonego w obywateli Ukrainy, który jako przynęty używał możliwość uzyskania wiz poprzez internet. Linki posiadające poniższy format były przekazywane za pomocą różnych wiadomości e-mail oraz czatach:

https://evisa.mfa.gov.ua:login@%6E%66%73%65%63%2E%70%6C

Szybki rzut oka na ten link nawet płynnie korzystającego z internetu użytkownika może go przekonać, że prowadzi on do portalu logowania serwisu evisa.mfa.gov.ua. Ale tak niestety nie jest. Kliknięcie linku w przeglądarce zaprowadzi nas do domeny: https://nfsec.pl. Dlaczego? Spójrzmy jak wygląda format adresu URL (zgodnie z definicją w RFC 1808, sekcja 2.1):

<schemat>://<nazwa_użytkownika>:<hasło>@<host>:<port>

Jest to dość dobrze znana technika w phishingu, w której domena jest zakodowana szesnastkowo. Jeśli rozłożymy ten format na czynniki pierwsze to otrzymamy:

• https:// – protokół / schemat
• evisa.mfa.gov.ua – nazwa użytkownika
• login – hasło
• nfsec.pl – docelowa strona internetowa (zakodowana szesnastkowo – to na nią zostaniemy przekierowani)

Dowód koncepcji: https://evisa.mfa.gov.ua:login@%6E%66%73%65%63%2E%70%6C

Najeżdżając kursorem na powyższy link możemy zaobserwować prawdziwy adres URL wyświetlany w lewym dolnym rogu. Zawsze należy pamiętać o tej czynności przed kliknięciem w link.

Więcej informacji: What does netloc mean?, Phishing attempts on Ukraine,

J

eśli interesuje nas stworzenie w naszej sieci firmowej usługi do skracania adresów lub wklejania i udostępniania kawałków teksu – aby nasi użytkownicy nie korzystali z zewnętrznych serwisów i tym samym doprowadzali do wycieków wrażliwych informacji – możemy zainteresować się dwoma projektami. Pierwszy z nich to skracarka anoni.sh, który nie loguje żadnych interakcji użytkownika (tylko anonimowa analityka za pomocą znaczników czasu umożliwiająca śledzenie ogólnego wykorzystania) oraz umożliwia ustawienie własnego (czytaj: odpowiednio długiego i skomplikowanego) klucza. Jego kod dostępny jest na serwisie github, co umożliwia nam własną instalację. Drugim jest minimalistyczny projekt wzorowany na wklejarce pastebin o otwartym kodzie źródłowym, w którym serwer nie posiada wiedzy o wklejanych danych (dane są szyfrowane i deszyfrowane w przeglądarce przy użyciu 256-bitowego AES GCM). Ponadto mamy możliwość ustawienia czasowej retencji, hasła oraz możliwości zniszczenia zawartości od razu po przeczytaniu.

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ść… ]

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ść… ]