Podsumowanie:

Wersje Log4j wcześniejsze niż 2.15.0 są narażone na lukę umożliwiającą zdalne wykonanie kodu głównie za pośrednictwem parsera LDAP JNDI. Zgodnie z przewodnikiem bezpieczeństwa tego projektu z fundacji Apache wersje Log4j <= 2.14.1 posiadają funkcje JNDI używane w konfiguracji, komunikatach logów i parametrach nie są chronione przed punktami końcowymi, które atakujący może wstrzyknąć i np. za pomocą protokołu LDAP (lub innego) pobrać i wykonać dowolny kod z zdalnego zasobu. Serwer z podatną wersją Log4j, do którego atakujący może wysyłać kontrolowane przez siebie komunikaty logów np. frazy wyszukiwania lub wartości nagłówków HTTP może wykonać dowolny kod pobrany z zewnętrznych serwerów LDAP. Wystarczy logować dane wejściowe lub meta dane użytkownika:
[ 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ść… ]

Ooprócz zewnętrznych serwisów, wpisów DNS, certyfikatów dla domen – istnieje jeszcze jeden zasób identyfikujący wspólne cechy: domen (firm) i webaplikacji – jest to ulubiona ikonka (ang. favicon.ico). Bardzo dużo firm posiada unikalne loga, które są pomniejszane do ikonek i wyświetlane przy pasku adresu / zakładkach przeglądarki. Zazwyczaj możemy znaleźć je pod adresem: http://domena/favicon.ico chyba, że odpowiednimi tagami HTML wskażemy przeglądarce inną lokalizację. Bardzo wiele z tych ikonek jest unikalnych dla wybranych domen (firm) oraz webaplikacji. Dzięki tej zależności możemy przeszukiwać internet w celu namierzania różnych zasobów powiązanych z daną ikonką.
[ czytaj całość… ]

W

raz z użyciem w systemie Ubuntu 14.04 LTS jądra z dystrybucji 16.04, czyli Xenial (4.4.0) do obsługi procesorów z rodziny Intel (Sandy Bridge lub nowsze) używany jest sterownik intel_pstate. Na temat jego pracy istnieje wiele opracowań. Czasami wypada lepiej, a czasami gorzej. Wszystko zależy od bardzo wielu czynników np. konfiguracji sprzętu, wykorzystanego oprogramowania, charakterystyki obciążania maszyn zadaniami itd. Dlatego przed nadzieją na szybki zysk wydajności, jak zawsze należy wykonać testy na swoim środowisku zamiast ślepo ufać obcym opracowaniom. Na przykład dla serwerów ElasticSearch oraz PrestoDB bardziej opłacalnym wariantem okazało się trzymanie procesora na stałej częstotliwości (intel_pstate=disable) niż pozwalanie mu na wchodzenie na niższe wartości (zarówno wariant powersafe, jak i performance). Przełożyło się to na zmniejszenie czasów odpowiedzi (obrazek #1 – Elastic) oraz spadek obciążenia maszyn (obrazek #2 – Presto).

Więcej informacji: Intel CPUs: P-state, C-state, Turbo Boost, CPU frequency, Why does the CPU frequency fluctuate when using the performance governor?

C

o się może złego dziać, jeśli czasy połączeń i odpowiedzi pomiędzy daemonami lub aplikacjami umieszczonymi na różnych serwerach losowo wahają się dochodząc nawet do wartości sekund? W dodatku liczba pakietów opuszczających serwer na wyjściu jest zauważalnie większa niż otrzymuje on do przetworzenia na wejściu. Wykluczając problemy wydajnościowe dotyczące utylizacji zasobów serwera, do którego się łączymy – pozostaje tylko jedno – sieć.
[ czytaj całość… ]

P

ierwszym korkiem w każdej ocenie bezpieczeństwa aplikacji mobilnych w Androidzie jest posiadanie pliku .APK, który reprezentuje aktualną wersję aplikacji mobilnej. W większości przypadków to klient (firma, osoba prywatna) jest odpowiedzialna za dostarczenie nam tego pliku – szczególnie w sytuacji, gdy aktualna wersja aplikacji nie jest publicznie dostępna. Chyba, że chcemy lub zlecono nam ocenę czarnej skrzynki (ang. black box) to wówczas w naszym interesie jest pozyskanie takiego pliku. Poniżej znajduje się prosty przykład, jak z publicznie dostępnej aplikacji wyciągnąć developerskie i testowe adresy, które przez zaniedbanie mogły zostać pozostawione w kodzie takiej aplikacji.
[ czytaj całość… ]

P

akiety zawierające serwer Tomcat (w wersji 6, 7, 8) dostępne w oficjalnych repozytoriach systemów Linux opartych o dystrybucje Debian (wliczając w to Ubuntu) dostarczały podatny skrypt init pozwalający osobom atakującym, które przeniknęły do systemu na konto użytkownika tomcat (na przykład wcześniej eksplorując podatność zdalnego wykonania kodu w hostowanej aplikacji java) na podniesienie uprawnień do użytkownika root i w pełni skompromitować atakowany system. Autor luki powiadomił Debian Security Team i zostały wydane już odpowiednie aktualizacje bezpieczeństwa.

Jeśli pozostajemy w obszarze serwera tomcat warto również zapoznać się z możliwością odczytywania źródłowego kodu za pomocą tego serwera wykorzystując znaki kodowane procentowo.

Więcej informacji: Szczegóły ataku oraz exploit wykorzystujący podatność

J

ava jest popularnym językiem programowania. Dwie główne sprawy tej popularności to bezpieczeństwo oraz dostępność bibliotek i komponentów w jej dużym ekosystemie. Odkąd większość aplikacji Javy robi użytek z tego ekosystemu, a wykorzystywane biblioteki posiadają zależności w innych bibliotekach – zapewnienie integralności bezpieczeństwa takich aplikacji staje dość trudne. Niektóre badania wyjawiły poważną skalę tego problemu. W przedstawionej prezentacji przyjrzano się 1261 wersji z 31 różnych bibliotek, które zostały pobrane z Centralnego Repozytorium Mavena. Jedną z strategii, która taką integralność jest w stanie zapewnić na przyzwoitym poziomie jest wymuszenie przeskanowania listy zależnych bibliotek budowanej aplikacji w bazie danych znanych podatności i zagrożeń – CVE.
[ czytaj całość… ]

S

tandardowo w systemie Ubuntu 12.04.2 LTS jest zainstalowany Tomcat7 w wersji 7.0.26. Niestety jednym z ogólnych problemów serwera Tomcat jest rotowanie pliku catalina.out, który czasami (w zależności od poziomu logowania) potrafi zajmować po kilka gigabajtów – a użycie narzędzia logrotate z opcją copytruncate na tak dużym pliku potrafi spowodować, że zanim logrotate dokona skopiowania i wyczyszczenia pliku – inny proces trzymający otwarty plik dokona zapisu, a miejsce nie zostanie wcale zwolnione.
[ czytaj całość… ]

F

aktem jest, że lekceważenie polityki bezpieczeństwa przez pracowników będzie wzrastać dopóki będzie ona sztywna i trudna do zaadaptowania przez zwykłych zjadaczy chleba. Włączenie kwestii bezpieczeństwa do rozmów, opracowanie zasady dopuszczalnych działań, omówienie postępowania z poufnymi informacjami – już nie wystarczy.
[ czytaj całość… ]