PDA

Zobacz pełną wersję : Wysyłanie spamu i mod_security



wargulek
07-09-2017, 18:21
Witam przy wyłączonym mod security co jakiś czas powstaje skrypt na koncie w różnych miejscach wysyłający spam. Następnie włącza się automatycznie zabezpieczenie serwera i powstaje blokada na wysyłkę maili. Włączenie mod_security powoduje pewien hamulec jednak wtedy nie działają komentarze na stronie. W logach jest coś takiego (ip wykomentowano):

2017-09-07 15:28:43.324 [NOTICE] [xxx.xxx.xx.xxx:53961:HTTP2-15] mod_security rule [Id '211540'] triggered!
[Thu Sep 7 15:28:43 2017] [error] [client [xxx.xxx.xx.xxx] ModSecurity: Access denied with code 406, [Rule: 'ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_N AMES|XML:/*|!ARGS:/body/|!ARGS:/content/|!ARGS:customized|!ARGS:/description/|!ARGS:/message/|!ARGS:/password/|!ARGS:Post|!ARGS:desc|!ARGS:text|!REQUEST_COOKIES :/__utm/|!REQUEST_COOKIES:/_pk_ref/|!ARGS:sql_query' '(?i:\b(?:t(?:able_name\b|extpos[^a-zA-Z0-9_]{1,}\()|(?:a(?:ll_objects|tt(?:rel|typ)id)|column_ (?:id|name)|mb_users|object_(?:id|(?:nam|typ)e)|pg _(?:attribute|class)|rownum|s(?:ubstr(?:ing){0,1}| ys(?:c(?:at|o(?:lumn|nstraint)s)|dba|ibm|(?:filegr oup|object|(?:process|tabl)e)s))|user_(?:group|pas sword|(?:ind_column|tab(?:_column|le)|user|(?:cons train|objec)t)s)|xtype[^a-zA-Z0-9_]{1,}\bchar)\b)|(?:\b(?:(?:instr|locate)[^a-zA-Z0-9_]{1,}\(|(?:attnotnull|c(?:harindex|onstraint_type)| m(?:sys(?:column|object|relationship|(?:ac|queri)e )s|ysql\.(db|user))|s(?:elect\b.{0,40}\b(?:ascii|s ubstring|users{0,1})|ys\.(?:all_tables|tab|user_(? :c(?:atalog|onstraints)|(?:object|t(?:ab(?:_column |le)|rigger)|view)s)))|waitfor\b[^a-zA-Z0-9_]{0,}?\bdelay)\b)|@@spid\b))'] [id "211540"] [msg "COMODO WAF: Blind SQL Injection Attack"]
2017-09-07 15:28:43.324 [NOTICE] [[xxx.xxx.xx.xxx:53961:HTTP2-15] Content len: 99, Request line: 'POST /component/jcomments/ HTTP/1.1' Ustawienie SecRuleRemoveById 211540 w htaccess daje efekt jak na początku przy wyłączonym mod_security, więc problem jest to co w logu.
Co to jest i jak się ustrzec, dziura w jcomments? Zainstalowana najnowsza dostępna wersja tego dodatku 3.0.5
Blokada na ip pomoże rozwiązać problem tylko częściowo.

adam.lachut
08-09-2017, 00:12
Wg mnie:

- masz jakąś lukę w zabezpieczeniach podatną na (Blind) SQL Injection
- i/lub jakiś skrypt (np. jakiś php shell) z którym komunikacja wyzwala regułę 'Blind SQL Injection Attack' w mod_security

i to jest główny problem, który ograniczyłeś dzięki zastosowaniu dodatkowej ochrony w postaci mod_security

Nie sądzę żeby luką był Jcomments (chyba że został już zmodyfikowany) - po prostu nie działa poprawnie przy włączonym mod_security, problem jest znany i jak dotąd nie znalazłem innego rozwiązania niż wyłączenie mod_security.

Myślę że powinieneś zacząć od upewnienia się że nie masz infekcji i zabezpieczenia J!2.5 (patche EOL, jakieś utwardzanie) w takim stopniu, żeby mod_security nie był niezbędny.

A.

wargulek
08-09-2017, 09:01
Na razie zblokowałem ip w htaccess, ale obawiam się, że to nie wystarczy. Hosting przeskanował konto pod kątem wirusów i nic nie znalazł. Zna ktoś może coś w php aby przeskanować pliki strony lokalnie jeszcze. Upgradeowałem wszystko (joomle, dodatki) co się dało do najnowszych wersji, które ze sobą współpracują. Oczywiście nie są to najnowsze bo nie wszystkie są aktualizowane. Jcomments to bodajże najnowsza wersja 2014 rok :-) Można rozwinąć jeszcze myśl o patche EOL i utwardzanie - z czym to się je?

adam.lachut
08-09-2017, 09:37
Blokada IP w .htaccess na pewno nie wystarczy.

Brak trafień skanera na serwerze nie wyklucza infekcji (nie przesądzam że konto zostało zainfekowane - nie sprawdzałem :) - próbujemy zgadywać na podstawie opisu sytuacji).

Lokalnie możesz np. porównać pliki z Twojej instalacji z oryginalnymi wersjami i przejrzeć dodatkowe moduły i szablon. Jeśli i masz dostęp do SSH możesz np. wyszukać ostatnio zmienione (polecenie find, ale z przełącznikiem ctime zamiast mtime).

Skorzystanie z myJoomla (jeden skan jest za darmo) może pomóc, ale nie na każdym serwerze zadziała poprawnie. Możesz spróbować z Gravity od WordFence (darmowy).

Patche EOL: https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions

Utwardzanie: ilu administratorów, tyle odpowiedzi, więc to raczej sugestie i pewnie część z nich to trochę zaklinanie rzeczywistości :) ale część na pewno poprawi odporność. Zacząłbym od zabezpieczenia admina hasłem .htaccess/.htpasswd, poza tym na przykład: zmiana haseł (superuser, baza), prefiksu w bazie, nazwy użytkownika 'admin' jeśli istnieje, sprawdzenie uprawnień do plików i folderów, zablokowanie dostępu do bazy z zewnętrznych IP, wyłączenie wildcard. Może jakiś prosty firewall (typu darmowy jHackGuard) albo instalacja AdminTools. Może uda się zmigrować do 3.6.5/3.7.x.

Niestety na końcu i tak się może okazać że coś przeoczyłeś, że masz zainfekowany inny serwis na tym koncie, że ktoś do crona podpiął jakiegoś exploita, że nie zmieniłeś skompromitowanego hasła do konta ftp i tak dalej, i tak dalej...

Skoro wiedziałeś jak wyłączyć w .htaccess regułę mod_security, na pewno warto spróbować!

A.