1

4 marca 2025 roku po raz kolejny mogliśmy przekonać się jak łatwo można przeprowadzić atak na łańcuch dostaw (ang. supply chain attack). Wystarczy uderzyć w kruchość ludzkiej weryfikacji w danym projekcie, którego popularność jest na tyle duża (lub specyficzna), aby spowodować dość duże spustoszenie, problemy i zaangażowanie dużej ilości ludzi do naprawy przepuszczonego błędu. Ale od początku. Dzisiejszy model rozwoju oprogramowania opiera się na używaniu popularnych platform typu Github, czy Gitlab itp. Oczywiście ma to swoje plusy dodatnie oraz plusy ujemne – szczególnie, gdy tego typu platformy mają swoje problemy bezpieczeństwa, które dziedziczymy razem z ich adopcją. W dodatku oferują funkcjonalności, które są najczęściej uzupełnianie przez zewnętrzne (często lepsze) rozwiązania. Takim przykładem są klocki, z których budowane są przepływy zadań / pracy (ang. workflows). Oferują one zautomatyzowane procesy uruchamiające jedno lub więcej zadań do obsługi cyklu życia oprogramowania. W przypadku GitHub są definiowane przez pliki YAML zaewidencjonowane w repozytorium projektu i zostają uruchomione automatycznie przez konkretne zdarzenie w repozytorium (np. dodanie pliku, zmianę wersji itd.). Mogą być też wyzwalane ręcznie, a także według zdefiniowanego harmonogramu czasowego (ala cron).
[ czytaj całość… ]

B

adacze z SEC Consult, a dokładniej Timo Longin – znany ze swoich ataków na protokół DNS opisał informację o nowej technice ataku o nazwie SMTP Smuggling, która może umożliwiać wysyłanie fałszywych wiadomości e-mail z pominięciem mechanizmów uwierzytelniania. Technika ta wykorzystuje protokół SMTP (ang, Simple Mail Transfer Protocol), w którym atakujący może wykorzystać różnice w sposobie, w jaki wychodzące i przychodzące serwery SMTP interpretują sekwencję wskazującą koniec danych w wiadomości e-mail. Co ciekawe bardzo podobną technikę o nazwie MX Injection opisał Vicente Aquilera Diaz w 2006 roku. Mimo, że jest to znany, długotrwały i dobrze udokumentowany problem, kilka powszechnie używanych serwisów i serwerów świadczących usługi e-mail okazało się podatnych na przeprowadzenie tego ataku.
[ czytaj całość… ]

N

a początku warto poruszyć temat Python2. Jeśli nadal jest on używany w naszym środowisku (nie)produkcyjnym, należy zdać sobie sprawę, że ataki na łańcuch dostaw z wykorzystaniem tej wersji obejmują już więcej niż tylko podatny interpreter, ale także pakiety innych firm w PyPI (ang. Python Package Index). Dlatego jeśli wykorzystujemy jeszcze drugą wersję w: procesie kompilacji; posiadamy narzędzia i usługi automatyzacji testów; skrypty wbudowane w strukturę CI/CD (ang. Continuous Integration / Continuous Delivery); interfejsy wiersza poleceń lub infrastrukturę wdrożeniową – musimy pogodzić się z świadomością, że jest to tykająca bomba z rosnącą liczbą luk.
[ czytaj całość… ]

A

rgon2 jest algorytmem, który wygrał w 2015 roku Konkurs Haszowania Haseł (ang. Password Hashing Competition). Jest wskazywany jako następca bcrypt i scrypt oraz zalecany przez OWASP (ang. The Open Web Application Security Project) do zabezpieczania haseł. Zaletą tego algorytmu są jego różne warianty (aktualnie posiada on trzy: Argon2i, Argon2d i Argon2id), które zawierają mechanizmy utrudniające ataki typu brute force oraz side channel. Ma prostą konstrukcję mającą na celu uzyskanie najwyższego współczynnika wypełnienia pamięci i efektywnego wykorzystania wielu jednostek obliczeniowych.
[ 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ść… ]

K

iedy wpisujemy URL w pasku adresu nasz komputer wysyła zapytanie DNS do właściwego serwera DNS i otrzymuje odpowiedni adres IP, który służy do osiągnięcia łączności z docelowym systemem. Protokoły takie, jak SSL/TLS, HTTPS zapewniają szyfrowanie komunikacji pomiędzy serwerem, a klientem po fakcie rozwiązania nazwy domeny. A, co jeśli atakujący przejmie komunikację pomiędzy serwerem DNS i jego klientem podczas procesu rozwiązywania domeny? Przekieruje ruch do spreparowanego serwera w celu kradzieży danych lub przeprowadzenia ataku DoS? W tym celu został opracowany mechanizm bezpieczeństwa pod postacią ciasteczka DNS.
[ czytaj całość… ]

W

drugiej połowie 2000 r. w środowiskach związanych z bezpieczeństwem systemów informatycznych zawrzało. Odkryto całkiem nową klasę nadużyć. Okazało się, że mnóstwo programów, między innymi tak znane aplikacje jak wu-ftpd, Apache i PHP3 czy screen, ma poważne dziury. A wszystko przez ciągi formatujące.
[ czytaj całość… ]