S

erwis zajmujący się między innymi gromadzeniem informacji o podatnościach pakietów czołowych dystrybucji Linuksa (Debian, Ubuntu, Oracle Linux, Fedora, CentOS, RedHat) udostępnił możliwość darmowego sprawdzania, czy w naszym systemie nie są obecne wersje oprogramowania, które zawiera błędy bezpieczeństwa. Autorzy serwisu napisali już Proof Of Concept agenta w języku Python. Istnieje też ręczna możliwość sprawdzenia pakietów poprzez formularz na stronie.

darkstar@darkstar:~$ git clone https://github.com/videns/vulners-scanner
Cloning into 'vulners-scanner'...
remote: Counting objects: 49, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 49 (delta 9), reused 0 (delta 0), pack-reused 30
Unpacking objects: 100% (49/49), done.
Checking connectivity... done.
darkstar@darkstar:~$ cd vulners-scanner/
darkstar@darkstar:~/vulners-scanner$ python3 linuxScanner.py

             _
__   ___   _| |_ __   ___ _ __ ___
\ \ / / | | | | '_ \ / _ \ '__/ __|
 \ V /| |_| | | | | |  __/ |  \__ \
  \_/  \__,_|_|_| |_|\___|_|  |___/

==========================================
Host info - Host machine
OS Name - ubuntu, OS Version - 16.04
Total found packages: 448
No vulnerabilities found

Więcej informacji: Linux Vulnerability Audit in Vulners

W nawiązaniu do poprzednich dwóch edycji oraz odpowiadając na pytanie: Jakie jeszcze przykładowe programy umożliwiają ucieczkę z sudo? – Możemy przyjrzeć się następującym przypadkom:
[ czytaj całość… ]

T

a krótka instrukcja poruszy temat skonfigurowania serwera httpd apache (2.4) w środowisku chroot() pod katalogiem /chroot. Na początek w systemie należy zainstalować takie pakiety jak: apache2 oraz libapache2-mod-php. Pierwszy z dwóch zapewni nam oprogramowanie httpd samo w sobie podczas, gdy libapache2-mod-php wsparcie dla interpretera PHP w wersji 7.0.8:
[ czytaj całość… ]

M

onit jest małym, ale potężnym narzędziem, które potrafi zarządzać monitoringiem i kondycją systemu. Potrafi przeprowadzać zautomatyzowane czynności utrzymaniowe, naprawcze i zaradcze w sytuacjach wystąpienia różnych błędów. Nie tylko umie czuwać nad poprawnym działaniem procesów, ale również zgłaszać incydenty oraz podejmować różne akcje (np. poprzez skrypty). Poniżej zamieszczam prosty przykład, jak wykorzystać tego daemona do monitorowania logowań przez SSH i wysyłania powiadomień przez e-mail.
[ 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

R

ekonesans DNS jest główną częścią etapu zbierania informacji w testach penetracyjnych. Można to porównać do wykonywania mapy infrastruktury danego serwisu. Większość organizacji nie monitoruje ruchu DNS, szczególnie nieudanych zapytań i prób pobrania całej strefy – dlatego wyciśnięcie jak największej ilości informacji z tego źródła często nie wpływa na alarmy w systemach bezpieczeństwa i nie wzbudza podejrzeń. W Internecie istnieje wiele dostępnych narzędzi, które mogą skutecznie wykonywać tego typu operacje, ale my skupimy się tylko na kilku i w dodatku tylko na tych napisanych w języku Python, ponieważ bardzo łatwo jest stworzyć dla nich wirtualne środowisko i zainstalować zależności, aby zadziałały od kopnięcia.
[ czytaj całość… ]

N

ajnowsza wersja Linuksa otrzymała nową funkcję bezpieczeństwa o nazwie “LoadPin”, która została przeniesiona z systemu Chrome OS i umożliwia wprowadzenie ograniczeń odnośnie nośników i lokalizacji, z których mogą być ładowane moduły i firmware jądra. Innymi słowy LoadPin jest nowym mini Modułem Bezpieczeństwa Linuksa (ang. Linux Security Module – LSM, który przechwytuje skonsolidowany zaczep LSM wywołania kernel_file_read, aby nasz system ładował wszystkie dodatki (moduły, firmware, obrazy kexec, polityki bezpieczeństwa) pochodzące z jednego zaufanego systemu plików. Poprzez zaufany system plików rozumie się tutaj taki, który jest umieszczony na urządzeniu tylko tylko-do-odczytu (np. CDROM lub dm-verity [wbudowany w Androidowe jądro od czasów wersji 4.4]). Niweluje to konieczność podpisywania każdego ładowanego pliku z osobna, ponieważ pierwszy plik ładowany przez interfejs odczytu plików jądra jest “przypinany” do systemu plików użytego do załadowania, a wszystkie pliki pochodzące z poza niego są odrzucane. Włączeniem lub wyłączeniem funkcji możemy sterować poprzez opcję SECURITY_LOADPIN_ENABLED w jądrze lub parametrem loadpin.enabled=1/0 przy starcie systemu.

Więcej informacji: The LoadPin security module

Nigdy, przenigdy nie ładujemy sesji screen / tmux na użytkowniku, który później w tej samej sesji odpala polecenie sudo / su i zostawia zawieszoną sesję (Ctrl + A + D) z uprawnieniami użytkownika root. Po przejęciu takiego konta – uzyskanie kontroli nad całym systemem ogranicza się wtedy do polecenia: screen -r. Scenariusz zawsze powinien być następujący: logowanie na zwykłego użytkownika ›› sudo su ›› screen ›› zawieszenie sesji i wylogowanie się z root.

W

większości przypadków systemy Linuksowe dobrze radzą sobie z obsługą pamięci. Istnieje zawsze ryzyko, że niektóre programy wymkną się spod kontroli i przydzielą sobie więcej pamięci niż jest normalnie możliwe i wejdą w strefę pliku wymiany. W takich sytuacjach można zaobserwować znaczne spowolnienie systemu (chyba, że używamy dysków SSD dla swap), a sprawdzenie dostępnej pamięci będzie prawdopodobnie pierwszą rzeczą jakiej należy się przyjrzeć.
[ czytaj całość… ]

P

oważna podatność została wykryta, a raczej powróciła po 15 latach (pierwsze błędy tego typu zostały odkryte i naprawione w bibliotece Perla w marcu oraz Curla w kwietniu 2001 roku). Głównie dotyka aplikacje oraz serwery działające z interfejsami CGI lub podobnymi. Wszystko sprowadza się do prostego konfliktu w nazwach zmiennych. Według RFC 3875 aplikacja CGI pobiera wartość nagłówka HTTP o nazwie Proxy (który może zostać wysłany w dowolnym żądaniu użytkownika) i zapisuje ją pod zmienną środowiskową HTTP_PROXY. Problem w tym, że ta zmienna środowiskowa jest używana do konfiguracji serwera proxy przy łączeniu się aplikacji i serwerów WWW z Internetem.
[ czytaj całość… ]