Sekurak - piszemy o bezpieczeństwie

W tekście opisany jest kolejny XSS w aplikacji Google Colaboratory. Pokazuje, w jaki nieoczekiwany sposób może zachowywać się biblioteka JS – i może wprowadzić nam w aplikację nieoczekiwanego XSS-a przez… ciasteczka!

Dane o pracownikach, ciekawe informacji z sieci społecznościowych, przeglądanie ksiąg wieczystych, rejestrów pojazdów, Darkweb, przeszukiwanie danych usuniętych (np. z Google) –  to tylko kilka tematów, które omawiamy na naszym szkoleniu OSINT (Open-source intelligence).

When testing infrastructure security, we often face the task of testing the security of the SSH server. One of the basic tests is to check the resistance to brute-force attacks. When performing such a type of attacks, knowledge of correct user names significantly increases the probability of success.

Podczas testów bezpieczeństwa infrastruktury często stajemy przed zadaniem przetestowania bezpieczeństwa serwera SSH. Jednym z podstawowych testów jest sprawdzenie odporności na ataki brute-force. W atakach tego typu znajomość poprawnych nazw użytkowników w znacznym stopniu zwiększa prawdopodobieństwo sukcesu – zamiast sprawdzać wszystkie możliwe kombinacje potencjalnych nazw użytkowników i haseł, sprawdzamy poprawność haseł tylko dla istniejących użytkowników.

Zagadnienie rozszerzania możliwości skanera Nmap dzięki NSE było na łamach Sekuraka poruszane już wielokrotnie. Dzisiaj przyjrzymy się bliżej skryptom z kategorii brute, które służą do łamania haseł metodą słownikową.

Pierwsza części serii poruszała temat wykorzystania wyszukiwarek internetowych jako źródła informacji we wstępnej fazie rekonesansu. Druga część również będzie traktować o wyszukiwarkach, ale takich, które zostały stworzone do testów bezpieczeństwa.

W artykule opisany jest błąd bezpieczeństwa, który znalazłem na początku czerwca 2018 w aplikacji desktopowej Google Hangouts Chat. Jest przykładem na to, jak aplikacje napisane w Electronie mogą sprawić, by pewnie mniej istotne podatności (jak np. open redirect) stały się nagle poważnymi błędami w aplikacjach.

TLDR: zhackowany router w oddziale -> dostęp do sieci LAN -> atak na system zarządzania przelewami -> zlecenie lewych przelewów -> wypłata pieniędzy z bankomatów. Game Over.

Tak przynajmniej donosi wiele światowych mediów. Jednym z punktów zaczepienia było zebranie danych CCTV z lotnisk (i zapewne innych miejsc)

Podstawą testów bezpieczeństwa aplikacji webowej czy infrastruktury jest rekonesans, a więc zebranie wszystkich subdomen, adresów IP i innych ogólnodostępnych informacji. Jednym z najprostszych narzędzi, które możemy do tego wykorzystać jest wyszukiwarka Google.

Czy w każdej sytuacji możemy ufać logom serwera WWW? Czy istnieje sposób by obejść logowanie zapytań i nie pozostawić śladu wykonania złośliwego kodu?

Niemal w każdym telefonie mamy możliwość zablokowania kogoś, kto okazał się sprzedającym nam super garnki, ubezpieczenia, tańszy prąd czy nową super ofertę abonamentu GSM. Co jednak w przypadku gdybyśmy nie chcieli widzieć tego typu połączeń z numerów, które widzimy na oczy pierwszy raz?

Według relacji, wyglądało to mniej więcej tak: w środku dnia podjeżdża na stację konwoj 10 dużych samochodów, tankują do oporu. Dla obsługi jest to trochę podejrzane, prawda?

Na pewno nie raz widzieliście ostrzeżenie po kliknięciu na plik pobrany z Internetu (niezaufany), Microsoft też często ostrzega przed uruchomieniem linku / kodu zawartego w MS Office.  Nowe wersje MS Office wprowadzają też parę dodatkowych metod ochrony, np. uniemożliwienie uruchamiania nowych podprocesów (choćby cmd).

W ostatnim czasie zbiegły się ze sobą dwa wydarzenia, mające ze sobą jeden szczegół – czyli ukryte znaki dodawane na wydrukach przez drukarki – a mające na celu zidentyfikowanie urządzenia, które zostało wykorzystane do wydruku.