LinuxPorady.pl gotowe rozwiązania, lifehacki, patenty dotyczące Linuksa

Objawia się ona następującymi zmianami:

1. wgrywane są nowe pliki:

-rw-r--r-- 1 user user   743 lis 21 09:09 accesson.php
-rw-r--r-- 1 user user 10443 lis 21 09:09 content-post.php
-rw-r--r-- 1 user user  4821 lis 21 09:09 dump.php
-rw-r--r-- 1 user user   299 lis 21 09:09 opn-post.php
-rw-r--r-- 1 user user 29527 lis 21 09:09 search.php
-rw-r--r-- 1 user user 24882 lis 21 09:09 wp-post.php

-rw-r--r-- 1 user user 743 lis 21 09:09 accesson.php

-rw-r--r-- 1 user user 10443 lis 21 09:09 content-post.php

-rw-r--r-- 1 user user 4821 lis 21 09:09 dump.php

-rw-r--r-- 1 user user 299 lis 21 09:09 opn-post.php

-rw-r--r-- 1 user user 29527 lis 21 09:09 search.php

-rw-r--r-- 1 user user 24882 lis 21 09:09 wp-post.php

2. usuwane są pliki blokujące:

np. plik

/assets/.htaccess

1	/assets/.htaccess

o treści:

<Files "\.(php|tpl)$">
   Order allow,deny
   Deny from all
</Files>

Order allow,deny

Deny from all

</Files>

3. cel ataku

Przejęcie kontroli nad serwerem www i wysyłka SPAM

4. leczenie

a) usunięcie w/w plików php

b) przywrócenie w/w pliku blokującego

c) aktualizacja snippetów:

ajaxSearch
ditto

1 2	ajaxSearch ditto

c) Modyfikacja kodu PHP w pliku:

/assets/snippets/ajaxSearch/classes/ajaxSearchResults.class.inc.php

1	/assets/snippets/ajaxSearch/classes/ajaxSearchResults.class.inc.php

Zakomentowanie linii 727. Tzn zamiana:

                        if (substr($filterArray[1], 0, 5) != "@EVAL") {
                            $this->_filterValue = $filterArray[1];
                        } else {
                            $this->_filterValue = eval(substr($filterArray[1], 5));
                        }

if (substr($filterArray[1], 0, 5) != "@EVAL") {

$this->_filterValue = $filterArray[1];

} else {

$this->_filterValue = eval(substr($filterArray[1], 5));

}

Na:

                        if (substr($filterArray[1], 0, 5) != "@EVAL") {
                            $this->_filterValue = $filterArray[1];
                        } else {
                            // $this->_filterValue = eval(substr($filterArray[1], 5));
                        }

if (substr($filterArray[1], 0, 5) != "@EVAL") {

$this->_filterValue = $filterArray[1];

} else {

// $this->_filterValue = eval(substr($filterArray[1], 5));

}

Oczywiście scenariusz wykonywania naprawy może być inny. Przedstawiamy naszą propozycję na oczyszczenie instalacji WP z infekcji przy pomocy komend Linuksa. Na upartego wystarczy nam do tego sama konsola Linux. Np. przy pomocy serwera VPS.

Przeraża Cię ta procedura ? 🙂 Skorzystaj z pomocy specjalisty !

Usuwanie wirusów ze stron www

1. Porównanie wersji z kopii bezpieczeństwa z aktualną wersją plików

Jeśli dysponujemy kopią bezpieczeństwa najlepiej jest dodać ją do repozytorium SVN celem prześledzenia zmian w plikach.

a) Tworzymy repozytorium SVN oraz kopię roboczą:

cd ~
mkdir repozytoria
cd repozytoria
svnadmin create backup-wordpress
cd ~
mkdir workspace
cd workspace
svn co file:///home/user/repozytoria/backup-wordpress wordpress-infekcja

cd ~

mkdir repozytoria

cd repozytoria

svnadmin create backup-wordpress

cd ~

mkdir workspace

cd workspace

svn co file:///home/user/repozytoria/backup-wordpress wordpress-infekcja

(gdzie user – nazwa Twojego użytkownika)

b) Wgrywamy następnie do folderu

~/workspace/wordpress-infekcja

1	~/workspace/wordpress-infekcja

Pliki z kopii bezpieczeństwa.

Duże pliki binarne (mp3, mp4, jpg, png, zip, tar) nie są potrzebne do synchronizacji. Najlepiej je usunąć aby przyśpieszyć sobie pracę.

Znajdujemy takie pliki (o wielkości powyżej 500kb)

find . -type f -size +500k

1	find . -type f -size +500k

i je usuwamy:

rm /sciezka/do/pliku

1	rm /sciezka/do/pliku

Czytaj jak kopiować i wklejać tekst w konsoli Linux.

Jeśli plik jest to niezbędny plik .js albo .php – zostawiamy go.

Dodajemy wszystkie pliki do kontroli wersji i komitujemy:

svn status | grep "^\?" | sed -e 's/? *//' | sed -e 's/ /\\ /g' | xargs svn add
svn ci -m 'wgranie plików z kopii bezpieczeństwa (lub inny dowolny komentarz)'

1 2	svn status \| grep "^\?" \| sed -e 's/? *//' \| sed -e 's/ /\\ /g' \| xargs svn add svn ci -m 'wgranie plików z kopii bezpieczeństwa (lub inny dowolny komentarz)'

c) Pobieramy pliki z zainfekowanej strony do osobnego folderu (tutaj utworzony poniżej folder: wordpress-infekcja), który uprzednio tworzymy:

cd ~
mkdir pliki-stron
cd ~/pliki-stron
mkdir wordpress-infekcja
cd wordpress-infekcja

cd ~

mkdir pliki-stron

cd ~/pliki-stron

mkdir wordpress-infekcja

cd wordpress-infekcja

d) Gdy już pliki zostaną pobrane dokonujemy synchronizacji:

rsync -r -t --progress --delete -s --exclude '.svn' ~/pliki-stron/wordpress-infekcja ~/workspace/

1	rsync -r -t --progress --delete -s --exclude '.svn' ~/pliki-stron/wordpress-infekcja ~/workspace/

Nastepnie przeglądamy listę zmian w plikach:

cd ~/workspace/wordpress-infekcja
svn st

1 2	cd ~/workspace/wordpress-infekcja svn st

Listę dostępnych statusów odnośnie zmienionych plików znaleźć można tutaj : https://linuxporady.pl/lista-statusow-svn-subversion-eng/

Wykonane zmiany w plikach możemy sprawdzić poprzez komendę:

svn diff /sciezka/do/pliku

1	svn diff /sciezka/do/pliku

Jednak bardziej pomocne mogą okazać się programy typu Eclipse lub Netbeans z odp. wtyczkami SVN.

Następnie:

Usuwamy złośliwe pliki:

rm /sciezka/do/pliku

1	rm /sciezka/do/pliku

Leczymy złośliwie zmienione pliki

svn revert /sciezka/do/pliku

1	svn revert /sciezka/do/pliku

Przywracamy niezbędne dla działania systemu pliki usunięte (symbol „!” po komendzie svn st) przez hakera:

svn revert /sciezka/do/pliku

1	svn revert /sciezka/do/pliku

Po skrupulatnym wykonaniu powyższych czynności nowo powstałe pliki dodajemy do repozytorium:

svn status | grep "^\?" | sed -e 's/? *//' | sed -e 's/ /\\ /g' | xargs svn add

1	svn status \| grep "^\?" \| sed -e 's/? *//' \| sed -e 's/ /\\ /g' \| xargs svn add

Usunięte – wykluczamy z repozytorium:

svn status | grep "^\?" | sed -e 's/? *//' | sed -e 's/ /\\ /g' | xargs rm -R

1	svn status \| grep "^\?" \| sed -e 's/? *//' \| sed -e 's/ /\\ /g' \| xargs rm -R

Całość zmian komitujemy:

svn ci -m 'Nowa kopia robocza (lub inny dowolny komentarz)'

1	svn ci -m 'Nowa kopia robocza (lub inny dowolny komentarz)'

2. Znalezienie rozmaitych podejrzanych wystąpień w plikach

Każde takie odkrycie badamy z osobna pod kątem czy jest to istotnie zawartość skryptu WP albo modułu, czy fragment złośliwego kodu.

Automatycznie znaleziska są składowane w pliku „zmiany”, który za każdą komendą jest nadpisywany.

a) znalezienie plików które nie mają rozszerzenia PHP a mają znacznik php:

find -not -iname "*.php" -type f -exec grep -q '<?php' {} \; -print > zmiany

1	find -not -iname "*.php" -type f -exec grep -q '<?php' {} \; -print > zmiany

b) wystąpienia wieloelementowej tablicy _Global:

find -type f -exec grep -q '\$GLOBAL\S\[$GLOBALS' {} \; -print > zmiany

1	find -type f -exec grep -q '\$GLOBAL\S\[$GLOBALS' {} \; -print > zmiany

c) znalezienie wystąpień tłumionego include. Używamy kilku wariantów wyszukiwania:

find -type f -exec grep -q '@include "' {} \; -print > zmiany

find -type f -exec grep -q '\@include\ \"' {} \; -print > zmiany

find -type f -exec grep -q '@include "' {} \; -print > zmiany

find -type f -exec grep -q '\@include\ \"' {} \; -print > zmiany

d) znalezienie wystąpień hexowego wpisywania znaków w PHP:

find -type f -iname "*.php" -exec grep -q 'chr\(109\)' {} \; -print > zmiany

1	find -type f -iname "*.php" -exec grep -q 'chr$109$' {} \; -print > zmiany

tu zamiast 109 możemy użyć innych cyfr

e) znalezienie podejrzanych operacji na zmiennej tablicowej _FILE i funkcji haszującej:

find -type f -iname "*.php" -exec grep -q '\$_FILES\[base64_decode' {} \; -print > zmiany

find -type f -iname "*.php" -exec grep -q 'gzinflate\(' {} \; -print > zmiany

find -type f -iname "*.php" -exec grep -q '\$_FILES\[base64_decode' {} \; -print > zmiany

find -type f -iname "*.php" -exec grep -q 'gzinflate\(' {} \; -print > zmiany

f) komendy wyodrębniające podejrzane pod kątem exploitów pliki PHP:

grep '((eval.*(base64_decode|gzinflate|\$_))|\$[0O]{4,}|FilesMan|JGF1dGhfc|IIIl|die\(PHP_OS|posix_getpwuid|Array\(base64_decode|document\.write\("\\u00|sh(3(ll|11)))' . -lroE --include=*.php* > mozliwe_exploity.txt

1	grep '((eval.(base64_decode\|gzinflate\|\$_))\|\$[0O]{4,}\|FilesMan\|JGF1dGhfc\|IIIl\|die\(PHP_OS\|posix_getpwuid\|Array\(base64_decode\|document\.write\("\\u00\|sh(3(ll\|11)))' . -lroE --include=.php* > mozliwe_exploity.txt

cd .
sploitpattern='r0nin|m0rtix|upl0ad|r57shell|cFaTaLisTiCz_Fx|Tukulesto|99shell|shellbot|phpshell|void.ru|phpremoteview|directmail|bash_history|.ru/|brute *force|multiviews|cwings|vandal|bitchx|eggdrop|guardservices|psybnc|dalnet|undernet|vulnscan|spymeta|raslan58|Webshell'
 
find . -name "*.php" -print0 | xargs -0 egrep -il "$sploitpattern" | sort > mozliwe_exploity.txt

cd .

find . -name "*.php" -print0 | xargs -0 egrep -il "$sploitpattern" | sort > mozliwe_exploity.txt

grep '((eval.*(base64_decode|gzinflate|\$_))|\$[0O]{4,}|FilesMan|GLOBALS.*exit|JGF1dGhfc|IIIl|die\(PHP_OS|posix_getpwuid|Array\(base64_decode|document\.write\("\\u00|sh(3(ll|11)))' . -lroE --include=*.php*

1	grep '((eval.(base64_decode\|gzinflate\|\$_))\|\$[0O]{4,}\|FilesMan\|GLOBALS.exit\|JGF1dGhfc\|IIIl\|die\(PHP_OS\|posix_getpwuid\|Array\(base64_decode\|document\.write\("\\u00\|sh(3(ll\|11)))' . -lroE --include=.php

g) znalezienie wystąpień includowanego kodu który jest zazwyczaj widoczny w ukrytych (zaczynających się od kropki) plikach PHP udających ikony (rozszerzenie .ico)

find -type f -exec grep -q 'basename\/\*' {} \; -print > zmiany

1	find -type f -exec grep -q 'basename\/\*' {} \; -print > zmiany

h) znalezienie podejrzanych skrytów o 8-literowej nazwie plików

W niektórych infekcjach – haker umieszcza na serwerze w losowych miejscach pliki o losowej nazwie (to istotne – nazwy są generowane automatycznie i nie mają sensu – to po prostu 8-literowy ciąg znaków). Zazwyczaj są one 8-literowe. Najlepiej wylistować wszystkie takie pliki i znaleźć takie podejrzane wystąpienia:

find . \( -name "????????.php" \)

1	find . $ -name "????????.php" $

Dla przykładu plik o nazwie typu:

vecqmdgn.php
gtyxodmt.php

1 2	vecqmdgn.php gtyxodmt.php

może wymagać wglądu – czy rzeczywiście jest częścią webserwisu. Jeśli nie i posiada podejrzany kod. Należy go skasować.

Oczywiście 8-literowy ciąg to nie standard. Jeśli pojawia się dużo plików np. 6-literowych należy odp. zmienić kryteria wyszukiwania.

i) znajdowanie zainfekowanych plików JavaScript wykonujących przekierowanie – brak możliwości zalogowania się do admina albo oglądania strony

więcej na ten temat: https://blog.sucuri.net/2019/11/vulnerable-versions-of-adminer-as-a-universal-infection-vector.html )

find -type f -name "*.js" -exec grep -q 'document.currentScript.parentNode.insertBefore(s, document.currentScript);' {} \; -print

1	find -type f -name "*.js" -exec grep -q 'document.currentScript.parentNode.insertBefore(s, document.currentScript);' {} \; -print

Oczywiście ta lista możliwych podejrzanych zmian w plikach nie jest wyczerpująca.

Wszystkie ew. zmiany w plikach musimy zakomitować, aby mieć pewność że dysponujemy aktualną i oczyszczoną kopią roboczą:

svn ci -m 'Nowa kopia robocza (lub inny dowolny komentarz)'

1	svn ci -m 'Nowa kopia robocza (lub inny dowolny komentarz)'

j) Wyszukanie plików PHP w folderze ze zdjęciami i próba znalezienia złośliwych skryptów.

Jeśli na serwerze mamy folder ze zdjeciami (np. systemy PrestaShop: /img) a w nim niezliczoną liczbę plików PHP tym prostym zapytniem posortujemy pliki wg rozmiarów i zapiszemy wynik do pliku tekstowego:

find . -type f -name "*.php" -exec du -h {} \; | sort -h > pliki-php.txt

1	find . -type f -name "*.php" -exec du -h {} \; \| sort -h > pliki-php.txt

W ten sposób plik PHP ze stosunkowo dużym rozmiarem (kilka-kilkanaście kb wielkości) może być potencjalnym plikiem z którego może być przeprowadzony atak.

Dla przykładu, jeśli posiadamy folder ze zdjęciami i w każdym podfolderze jest plik zaślepkowy index.php kierujący do glownej, mozemy łatwo sprwadzic czy któryś z nich nie jest podejrzanie duży i np. w nim znajduje się exploit.

k) znalezienie plików, które były edytowane w przeciągu ostatniego tygodnia:

find . -type f -name '*.php' -mtime -7

1	find . -type f -name '*.php' -mtime -7

Oczywiście zamieniająć cyfrę 7 na np. 14 – wylistujemy pliki z przed 2 tyg. itd.

Analogicznie możemy znaleźć tak pliki ZIP w których czasem hakerzy umieszczają archiwum do wypakowania:

find . -type f -iname '*.zip' -mtime -7

1	find . -type f -iname '*.zip' -mtime -7

flaga iname nie zwraca uwagi na wielkość liter 😛

3. Aktualizacja i weryfikacja modułów

Należy zaktualizować możliwe najwięcej komponentów w WP. Zatem:

jądro WordPress
motywy
wtyczki

Musimy się także zastanowić czy wszystkie zainstalowane wtyczki są niezbędne do funkcjonowania strony. Niepotrzebne lub podejrzane komponenty należy usunąć.

Po dokonaniu aktualizacji należy uwzględnić zmiany w kopii bezpieczeństwa w SVN. Powtarzamy tutaj proces z pkt. 1 tego artykułu.

4. Ustawienie prawidłowych uprawnień na plikach i folderach.

Następnie całość plików powinna być wgrana przez FTP na serwer docelowy uprzednio po usunięciu zawartości:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

1 2	find . -type f -exec chmod 644 {} \; find . -type d -exec chmod 755 {} \;

5. Zmiana haseł powiązanych ze stroną

a) Zmiana wszystkich dostępów FTP (skomplikowane hasło).

Najlepiej jest usunąć wszystkie konta FTP zostawiając tylko jedno, które ma trudne i unikalne hasło.

b) Zmiana wszystkich dostępów CMS.

W dziale użytkownicy w WP należy dokonać przeglądu którzy administratorzy są potrzebni, a którzy nie.

c) Zmiana hasła do bazy danych (skomplikowane, unikalne hasło)

Następnie należy je wprowadzić w pliku

wp-config.php

1	wp-config.php

w katalogu głównym

6. Asekuracyjnie. Porównajmy naszą zaktualizowaną wersję strony opartej o WordPress z bazową wersją tego CMS.

Analogicznie jak w pkt. 1:

Upewniamy się, że mamy aktualną wersję kopii roboczej opartej o kopię bezpieczeństwa z SVN:

~/workspace/wordpress-infekcja
svn st
svn up

~/workspace/wordpress-infekcja

svn st

svn up

Do osobnego folderu wgrywamy aktualną wersję CMS WordPress ze strony: https://pl.wordpress.org/

Tworzymy go w folderze pliki-stron:

cd ~/pliki-stron
mkdir wordpress-base/wordpress-infekcja  -p

1 2	cd ~/pliki-stron mkdir wordpress-base/wordpress-infekcja -p

Następnie synchronizujemy pliki z naszą kopią bezpieczeństwa sprawdzamy zmiany:

rsync -r -t --progress --delete -s --exclude '.svn' ~/pliki-stron/wordpress-base/wordpress-infekcja ~/workspace/
svn st

1 2	rsync -r -t --progress --delete -s --exclude '.svn' ~/pliki-stron/wordpress-base/wordpress-infekcja ~/workspace/ svn st

Większość wtyczek, motywów itp. będzie usunięta (symbol wykrzyknika). Zapewne nie zawierają się one w podstawowej wersji CMS. Najbardziej kluczowe mogą być podejrzane zmiany w plikach jądra CMS, albo usunięcie plików, które mają łudząco podobną nazwę do składowych plików CMS. Należy przeglądnąć ich zawartość.

7. Dodatkowe zabezpieczenia

Blokowanie wywołań plików php i ukrytych plików php.

W folderze:

wp-content/uploads

1	wp-content/uploads

Umieść plik o nazwie:

.htaccess

.htaccess

I zawartości:

<FilesMatch "\.(php|ico)$">
   Order allow,deny
   Deny from all
</FilesMatch>

Order allow,deny

Deny from all

</FilesMatch>

Dodatkowo, zgodnie z informacjami zawartymi na stronie: https://perishablepress.com/protect-post-requests/ możemy zupełnie uniemożliwić requesty POST. Czyli jeśli nasza strona nie posiada formularza kontaktowego itp. możemy dodać taką regułę do .htaccess. Jednak uwaga – może to uniemożliwić logowanie do CMS. W takim wypadku na czas logowania należy ją zakomentować:

# deny all POST requests
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} POST
	RewriteRule .* - [F,L]
</IfModule>

# deny all POST requests

RewriteCond %{REQUEST_METHOD} POST

RewriteRule .* - [F,L]

</IfModule>

Widok zakomentowanej reguły:

# deny all POST requests
#<IfModule mod_rewrite.c>
#	RewriteCond %{REQUEST_METHOD} POST
#	RewriteRule .* - [F,L]
#</IfModule>

# deny all POST requests

#<IfModule mod_rewrite.c>

# RewriteCond %{REQUEST_METHOD} POST

# RewriteRule .* - [F,L]

#</IfModule>

8. Sprawdzenie podejrzanych użytkowników bazie danych.

Niekiedy hakerzy przejmują kontrolę nad systemem CMS i za jego pośrednictwem dokonują swoich działań.

Aby się upewnić, że w CMS nie ma takiego backdoora zaloguj się do bazy danych przez program PhpMyAdmin. Dane do zalogowania znajdziesz w pliku:

wp-config.php

1	wp-config.php

następnie zaznacz tabelę:

wp_users

wp_users

Jeśli w jej obrębie znajdują się podejrzane konta użytkowników

a) Usuń je – notując ich numery ID

b) Wywołaj komendę:

DELETE FROM `wp_usermeta` WHERE `user_id` = 2

1	DELETE FROM `wp_usermeta` WHERE `user_id` = 2

Gdzie 2 – to zanotowany numer ID.

c) zmień hasło do bazy danych i zaktualizuj je w pliku php:

wp-config.php

1	wp-config.php

Możesz też wywołać poniższą komendę w SQL (np. w phpmyadmin):

SELECT * FROM `wp_usermeta` WHERE `meta_key` = 'wp_capabilities' AND `meta_value` LIKE "%administrator%"

1	SELECT * FROM `wp_usermeta` WHERE `meta_key` = 'wp_capabilities' AND `meta_value` LIKE "%administrator%"

Wskaże ona ID użytkowników w randze admina. Jeśli haker założył dodatkowe konta z takimi użtkownikami – przegladnij je i wykasuj podejrzane konta.

9. Sprawdzenie sytuacji po paru dniach

Należy następnie sprawdzić sytuację na witrynie po paru dniach / tygodniach. Najlepiej dla szybkości pobrać jedynie pliki narażone na atak. Następnie prześledzić ich zmiany przez SVN na identycznej zasadzie jak w pkt. 1 albo 6 niniejszego artykułu:

find -iregex '.*\.\(ico\|php\)$' > pliki
tar -czvf pliki.tar.gz -T pliki

1 2	find -iregex '.*\.$ico\\|php$$' > pliki tar -czvf pliki.tar.gz -T pliki

Ewentualnie jak bazujemy na hostingu opartym o Direct Admin dodajmy takie komenty do crona:

find ~/domains -iregex '.*\.\(ico\|php\)$' > ~/domains/pliki
tar -czvf ~/domains/pliki.tar.gz -T ~/domains/pliki

1 2	find ~/domains -iregex '.*\.$ico\\|php$$' > ~/domains/pliki tar -czvf ~/domains/pliki.tar.gz -T ~/domains/pliki

10. Dodanie do CRON polecenia automatycznie usuwającego plik o określonej nazwie

Jeśli plik z exploitem pojawia się zawsze pod specyficzną nazwą np. jest to plik php:

SHELLcmd.php

1	SHELLcmd.php

I nie ma na serwerze innego pliku pod tą nazwą. Można po prostu dodatkowo zabezpieczyć się poprzez dodania do CRON automatycznego znalezienia tego pliku i unięcia.

Komenda:

find -name "SHELLcmd.php" | xargs rm

1	find -name "SHELLcmd.php" \| xargs rm

CRON ustawiamy aby uruchamiał się co 1 minutę. Np. w Direct Admin wpisujemy w polu minuta:

*/1

*/1

11. Popularne dziury w innych systemach CMS.

Jeśli na Twoim serwerze są inne popularne skrypty CMS jak np. Joomla albo PrestaShop przepatrz te strony pod kątem zagrożeń. Dla Joomla wykonaj aktualizację do najnowszej wersji + porównanie plików z plikami z demo tej samej wersji. Dla PrestaShop – podobnie.

Dość popularną dziurą w PrestaShop ostatnimi czasy (szczególnie dla wersji 1.6.x) była często wykorzystywana podatność w module: jmsslider

Więcej informacji znajdziesz tutaj: https://www.joommasters.com/index.php/blog/tutorials-and-case-studies/how-to-fix-security-bug-of-slider-security-breach-of-theme.html