CVE-2016-10229 – zdalne wykonanie kodu na kernelach< 4.5

Jeden z poważniejszych błędów w jądrze Linuxa został nazwany: CVE-2016-10229 i pozwala on niestety wykonać zdalnie kod z uprawnieniami root poprzez wysyłkę odpowiedniego pakietu UDP:

„udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSG_PEEK flag.”

Podatność dotyczy jąder < 4.5, aczkolwiek kernele Redhat/Centos nie są podatne, a Debian twierdzi, że zostało to załatane w najnowszych kernelach i ma to związek z wykrytym w grudniu błędem oraz jego poprawkami na koniec stycznia.

Lista podatnych kerneli znajduje się na stronie SecurityFocus i zalecana jest szybka aktualizacja serwerów oraz komputerów ich wykorzystujących.

Podatnych jest niestety też sporo urządzeń mobilnych opartych na systemie Android i według strony są to następujące modele: Nexus 5X, Nexus 6, Nexus 6P, Pixel, Pixel XL, Pixel C, Android One, Nexus Player.

Logowanie aktywności w SFTP

SFTP to na pewno wygodniejsza i bezpieczniejsza usługa od FTP, aczkolwiek w standardzie nie zawiera logowania aktywności. Widzimy tylko w logach systemowych, że ktoś się logował, ale już nie wiemy co robił. Bezpieczeństwo serwerów przekładamy ponad wszystko inne więc warto jest uruchomić logowanie wszelkiej aktywności w podsystemie SFTP. Możemy to prosto zrobić w każdym systemie Linux jeżeli mamy pakiet OpenSSH w wersji co najmniej 4.4.

Dokonujemy tego przez edycje dwóch plików i na przykładzie Debiana wygląda to tak:

Pierwszy:/etc/ssh/sshd_config

gdzie podmieniamy:

Subsystem sftp /usr/lib/openssh/sftp-server

na:

Subsystem sftp /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO

Drugi: /etc/rsyslog.conf

gdzie dodajemy np. na końcu pliku linie:

local5.* /var/log/sftpd.log

Następnie wystarczy przeładować usługi i mamy uruchomione logowanie do pliku /var/log/sftpd.log – tu warto też dodać ten plik do rotacji logów by za bardzo nie urósł 😉

CVE-2016-5195 – Dirty Cow – Poważne zagrożenie dla serwerów Linux

W sieci dość spore zamieszanie wywołała poważna luka bezpieczeństwa o nazwie „Dirty Cow” – „Brudna Krowa” której przypisano numerek CVE-2016-5195. Więcej informacji na dedykowanej stronie: https://dirtycow.ninja/

W olbrzymim skrócie:

Zagraża ona wszystkim serwerom Linux zainstalowanym w ostatnich latach. Pozwala na podniesienie uprawnień które może spowodować spore problemy bezpieczeństwa w różnych instalacjach serwerowych. Najgorszym jest to, że w internecie został opublikowany exploit wykorzystujący dziurę. Błąd jest co prawda lokalny więc atakujący musi mieć dostęp do systemu, aczkolwiek potencjalnie można wykonać kod exploita przez np. dziurę w serwisie www co mocno zwiększa zagrożenie.

Nie ma innego sposobu niż nałożenie łaty na jądro systemowe czy wykonanie jego aktualizacji. W przypadku tego błędu nie pomaga nawet popularne Grsecurity.

Zachęcamy więc wszystkich do szybkich aktualizacji swoich swoich serwerów i zabezpieczenia przed tą podatnością na atak.

 

W przypadku problemów lub chęci zabezpieczenia swoich serwerów zapraszamy do kontaktu: https://netfs.pl/kontakt

 

ps. pamiętajmy, że po aktualizacji musimy przeładować system, jeżeli nie korzystamy z pakietu Kernel Care.

Fatal BUG Imagemagick – zdalne wykonanie kodu – FIX

logo-medium       Dwa dni temu pojawił się dość niemiły błąd w Imagemagick ( CVE-2016–3714 ) pozwalający na wykonanie dowolnego kodu w systemie przez prosty upload obrazka, a raczej spreparowanego pliku na stronę WWW.

Pojawiły się dość szybko publicznie exploity i nawet sytuacja została opisana pod wdzięczną nazwą „Imagetragick”.

W chwili dodawania wpisu nie było dostępnej poprawki, a jedynie sposób na częściowe wyjście z opresji. Co zrobić by zabezpieczyć się przed wydaniem stosownych poprawek ? To dość proste wystarczy dodać do pliku policy.xml kilka linijek. Standardowo znajduje się on pod ścieżką: /etc/ImageMagick/policy.xml

<policymap>
<policy domain=”coder” rights=”none” pattern=”EPHEMERAL” />
<policy domain=”coder” rights=”none” pattern=”URL” />
<policy domain=”coder” rights=”none” pattern=”HTTPS” />
<policy domain=”coder” rights=”none” pattern=”MVG” />
<policy domain=”coder” rights=”none” pattern=”MSL” />
</policymap>

Czy działa poprawnie możemy sprawdzić wykonując polecenie:

[email protected]:~# convert -list policy

Path: [built-in] Policy: Undefined
rights: None

Path: /etc/ImageMagick/policy.xml
Policy: Coder
rights: None
pattern: EPHEMERAL
Policy: Coder
rights: None
pattern: HTTPS
Policy: Coder
rights: None
pattern: URL
Policy: Coder
rights: None
pattern: MVG
Policy: Coder
rights: None
pattern: MSL

enjoy 😉

 

Nginx – proste zabezpieczenie WordPress

Nginx – proste zabezpieczenie WordPress

 

zabezpieczenie wordpressPopulary skrypt blogowy jest jednym z najczęściej atakowanych w sieci, w poniższym wpisie pokażemy jak można wykonać proste zabezpieczenie WordPress. Całość polegać będzie na dodaniu do konfiguracji Virtualhosta kilku wpisów blokujących niebezpieczne zapytania:

  1. Blokada wszystkiego z kropką z przodu np. .htaccess
location ~ /\. {
 deny all;
 }

2. Blokada wykonywania skryptów PHP w katalogach:

location ~* ^/wp-content/.*.(php|phps)$ {
 deny all;
}
     location ~* ^/wp-includes/.*\.(php|phps)$ {
      internal;
     }

3. Blokada odczytu różnych rozszerzeń plików ( tu można dostosować  pod własne wymagania ):

location ~* ^/wp-content/.*.(txt|md|exe|sql|sh|pl|py|zip|rar|gz|tar.gz)$ {
 deny all;
 }

4. Blokada dostępu do logowania, możemy ją zrobić na dwa sposoby, dodatkowa autoryzacja na podstawie IP lub hasła. Do każdego z wpisów musimy dodać konfiguracje fastcgi wymaganą do uruchomienia PHP, tą możemy skopiować z głównego location i może ona wyglądać tak:

Autoryzacja IP:

location ~ ^/(wp-admin|wp-login\.php) {
 location ~ \.php$ {
 try_files $uri =404;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass 127.0.0.1:9001;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 allow IP1;
 allow IP2;
 deny all;
 }

Autoryzacja hasłem:

location ~ ^/(wp-admin|wp-login\.php) {
 location ~ \.php$ {
 try_files $uri =404;
 include /etc/nginx/fastcgi_params;
 fastcgi_pass 127.0.0.1:9001;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 auth_basic "Login";
 auth_basic_user_file /etc/nginx/.htpasswd;
}

Oczywiście składania pliku .htpasswd jest taka sama jak dla Apache i możemy ją wygenerować samemu lub programem pochodzącym z Apache:  htpasswd ( dla Debian: apt-get install apache2-utils dla Centos: yum install httpd-tools ).

Blokadę możemy rozszerzyć o plik xmlrpc.php który jest często wykorzystywany w Atakach. Wystarczy wtedy zmienić zawartość zmiennej location na:

location ~ ^/(wp-admin|wp-login|xmlrpc\.php) {

 

Dodatkowymi zabezpieczeniami może być wyłączenie niebezpiecznych funkcji w PHP oraz aktywacją open_basedir ( w przypadku środowisk bez chroot’owanch kont ).

Zabezpieczenie WordPress może odbyć się również w bardziej profesjonalny sposób z wykorzystaniem rozwiązań WAF ( Web Application Firewall ) dla Nginx mamy do dyspozycji mod_security mod_security oraz Naxsi.

W przypadku problemów z bezpieczeństwem aplikacji internetowych i chęcią ich zabezpieczenia za pomocą m.in. mechanizmów WAF, zapraszamy do kontaktu: https://netfs.pl/kontakt