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

W

celu zrozumienia jak powstają zawieszone rekordy DNS (ang. dangling DNS records) należy posiadać podstawową widzę na temat działania usługi DNS, która tłumaczy przyjazne dla użytkowników nazwy domen, takie jak nfsec.pl (łatwe do zapamiętania i rozpoznania) na numeryczne adresy IP. Adresy IP dla każdej domeny są przechowywane na autorytatywnych serwerach DNS, które można porównać do książek telefonicznych w internecie. Po wpisaniu adresu strony internetowej w przeglądarce, przeglądarka na początku łączy się z rekurencyjnym serwerem DNS i zadaje pytanie: “Jaki jest adres IP nfsec.pl?”. Rekursywny serwer DNS wysyła zapytanie do serwera autorytatywnego w celu uzyskania odpowiedzi (oczywiście to trochę bardziej skomplikowane).
[ czytaj całość… ]

J

akiś czas temu Inti De Ceukelarie odkrył lukę pozwalającą na przeprowadzenie ataku na przestrzeń nazw w postaci adresów e-mail. Wykorzystanie tego błędu pozwala na uzyskanie dostępu do wewnętrznych systemów, mediów społecznościowych lub wewnętrznej komunikacji atakowanej firmy. Ze względu na skalę błąd nadal jest aktualny dla wielu firm, a w swej prostocie jest bardzo prosty do wykonania.
[ czytaj całość… ]

M

ulticast DNS (mDNS, DNS w trybie rozsyłania grupowego) został stworzony w celu wykonywania operacji DNS w sieciach lokalnych pozbawionych konwencjonalnego serwera DNS działającego w trybie transmisji jednostkowej – unicast. Jako usługa typu zero-config wymaga niewielkiej lub nie wymaga żadnej konfiguracji, aby korzystać z połączenia pomiędzy uczestnikami w sieci. Protokół ten działa, nawet gdy nie ma żadnej infrastruktury lub jest ona w stanie awarii – wymaga jedynie współpracy pomiędzy innymi użytkownikami w sieci.
[ czytaj całość… ]

I

nternet przyzwyczaja nas do wielu nowych rzeczy. To, co jest w nim opublikowane przyjmujemy czasem za pewnik, a porady za sprawdzone i uzasadnione. Niestety nie zawsze tak jest. Jeśli spojrzymy na niektóre, zalecane metody instalacji lub konfiguracji oprogramowania to aż trudno uwierzyć, że nikt nie pomyślał na ile różnych sposobów można je wykorzystać. Sprawdźmy dokąd może zaprowadzić nas na przykład polecenie:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

[ czytaj całość… ]

D

o pliku net/ipv4/tcp_input.c w jądrze Linuksa od wersji 3.6 wprowadzono patch mający na celu poprawienie odporności stosu TCP przed atakiem Blind In-Window. Niestety spowodował on zupełnie odwrotne działanie i w rzeczywistości ułatwia przechwytywanie sesji TCP poprzez wyciek informacji bocznym kanałem. Podatne są wszystkie systemy Linux z zakresu 3.6 – 4.7 (do przeprowadzenia ataku wystarczy, że tylko jedna strona w komunikacji klient – serwer jest podatna). Jak twierdzą autorzy będący m.in. członkami Cyber Security Group Uniwersytetu w Kalifornii atak zajmuje od 40 do 60 sekund i posiada od 88% do 97% skuteczności. Pierwsza prezentacja odkrycia odbyła się w maju 2016 roku na konferencji GeekPwn, a w ciągu dwóch dni na konferencji Usenix Security Symposium zostaną przedstawione pełne wyniki badań. Na YouTube dostępy jest film prezentujący przeprowadzenie ataku z wstrzyknięciem treści w trwającą sesję TCP. Tymczasowym rozwiązaniem do czasu pojawienia się oficjalnych poprawek jest podniesienie limitu ilości wysyłanych segmentów ACK służących do kwestionowania pakietów SYN z niezgodnymi numerami sekwencyjnymi.

sysctl -w net.ipv4.tcp_challenge_ack_limit=999999999

Warto wspomnieć, że pierwszy tego rodzaju atak przeprowadził Kevin Mitnick.

Więcej informacji: Fixing an Internet Security Threat, CVE-2016-5696