Teksty

Pierwsza część artykułu dotyczyła zakresu planowania bezpieczeństwa informacji ze szczególnym uwzględnieniem roli najwyższego kierownictwa w tym procesie oraz obowiązków i uprawnień pracowników. W tej części zagłębimy się w tematykę aktywów, kontrolowania dostępu do nich i ich zabezpieczania.

Prowadzenie jakiegokolwiek biznesu wiąże się z przetwarzaniem informacji. Im większa organizacja (czyli np. firma, urząd lub szpital), tym więcej informacji, a więc większe ryzyko, że jeśli nie zapewnimy odpowiedniego poziomu bezpieczeństwa przetwarzanych danych, mogą one zostać ujawnione przypadkowo (poprzez niewiedzę lub lekkomyślność personelu albo przez podatności w infrastrukturze) lub celowo. Prędzej czy później brak zapewnienia ochrony informacji zemści się na nas (czy to finansowo, czy wizerunkowo).

Wpis opisuje jak udało się obejść mechanizm uwierzytelniania w aplikacji opartej o NodeJS w jednym z prywatnych programów bug bounty. Zaprezentowano metodologię stosowaną w przypadku podobnych sytuacji, która bardzo często pozwala na znalezienie luki (bądź luk) w aplikacjach z pozoru wyglądających na takie, które nie zawierają żadnej funkcjonalności do “złamania”.

Trzecia część serii o rekonesansie infrastruktury IT. Poznajemy takie narzędzia jak crt.sh, VirusTotal czy RiskIQ.

Budując naszą obronę przed tego typu atakami, powinniśmy przede wszystkim poznać i, co najważniejsze (a jednocześnie najtrudniejsze), nauczyć się kilku podstawowych technik wpływu na zachowanie drugiego człowieka, aby w momencie kiedy zostaniemy zaatakowani zauważyć ten fakt i zdążyć się przed nim obronić.

Systemy Web Application Firewall (WAF) stały się integralną częścią infrastruktury znakomitej większości wykorzystywanych komercyjnie aplikacji internetowych. Pomysł na zbliżone podejście do problemu niebezpiecznych danych wejściowych, jak w przypadku niechcianych pakietów sieciowych, okazał się skuteczną ochroną przed typowymi klasami błędów trapiących aplikacje webowe.

WebAssembly (WASM) jest odpowiedzią na rosnące zapotrzebowanie użytkowników (i deweloperów oczywiście) na bogate, funkcjonalnie i szybkie aplikacje webowe. Problemem w takich scenariuszach wykorzystania jest najczęściej wydajność całego środowiska, a do tej pory nie udało się w pełni poprawić wszystkich bolączek JavaScript.

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!

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.

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.

W artykule opisany jest błąd CVE-2018-6148, naprawiony w Chrome 67 w wersji z dnia 6 czerwca 2018. Błąd ten pozwalał na dodawanie dowolnych nagłówków zapytania HTTP w zapytaniach cross-domenowych. Oznaczało to, że dowolna strona webowa mogła ustawić treść takich nagłówków jak np. X-CSRF-Token, Referer, User-Agent, Host czy Cookie. Inne strony webowe, z kolei, przyjmują za pewnik, że nikt nie może w przeglądarce sobie sam tych nagłówków ustawiać – co może prowadzić do problemów bezpieczeństwa.