.htacess e arquivos aleatórios hackeados

Question

Recentemente, em um dos servidores de meus clientes executando o apache e o php, notei um monte de arquivos aleatórios que foram colocados em todas as pastas do site. Eles são nomeados com números aleatórios, como 205492.php.

Existem também arquivos .htaccess que foram colocados junto com esses arquivos numerados aleatoriamente. Meu host me diz que é o script de upload do cliente em php, mas o proprietário / grupo dos arquivos está definido como httpd. Eu acho que isso significa que é o daemon apache que colocou os arquivos aqui. O tempo de criação desses arquivos está definido para o mesmo timestamp.

Existem muitas funções CURL e base64_encode em todo o arquivo php aleatório. Eu notei que a pessoa que construiu o site dos meus clientes tinha chmod para 777 na pasta inteira. Desde então mudei para 755 pensando que poderia ter sido o problema.

Eu estou querendo saber se alguém já ouviu falar de algo assim antes e se alguém tem alguma sugestão. Muito obrigado pelo seu tempo.

    

Answer 1

Não apenas os programadores PHP ruins ou medianos, muitas vezes bons, esquecem os objetivos de segurança.

Embora não seja esculpido em pedra, sites de hackers podem ser feitos caminho mais difíceis com a introdução de algumas regras

• segmentação de código / dados / arquivo de trabalho e aplicação de permissão
  
• código: um diretório onde você guarda seus arquivos executáveis: este diretório TEM que ser acessível, mas NÃO DEVE ser gravável pelo usuário executando o apache (www-data ou httpd em sistemas diferentes) (mecanismo php_admin_flag ativado)
   
• data: lugar do css, imagens e arquivo estático que vem com a página: este diretório NÃO DEVE ser gravável ou executável pelo Apache (mecanismo php_admin_flag desativado)
   
• um diretório para arquivos carregáveis pelo usuário, arquivos temporários e assim por diante: este diretório pode ser gravável, mas NÃO DEVE ser executado pelo Apache (mecanismo php_admin_flag desativado)
  
• desabilitando arquivos .htaccess: um terço de uma vez, os 'hacks' do site são apenas sobre reescrever arquivos .htaccess, então é como um escalonamento de privilégios. Também acelera o Apache se ele não precisar verificar se algum arquivo .htaccess está residindo em _qualquer_ nível do caminho que está sendo atendido.  
 
• introduzindo restrições não-obstétricas no PHP, como  
  • desativando funções não utilizadas (sistema, exec no início),
    
  • introduzindo open_basedir (estritamente declarando diretórios onde o exec do PHP não é permitido)
    
  • Mecanismo php_admin_flag desativado no diretório / e permitindo somente diretórios específicos (ou melhor, arquivos específicos)
    
  • display_errors estritamente OFF
    
  • com o virtualhosting em muitos sites, está se tornando útil se você introduzir um wrapper do sendmail, a fim de marcar cada letra de saída, facilitando a localização do virtualhost que inunda o sistema com spam
   
• e, claro, evitando erros comuns, como incluir uma variável GET / POST

Um simples wrapper do sendmail:

#!/bin/sh
umask 077
TEMP=/tmp
CHROOT=${1:-unspecified}

trap "rm -f msg.$$ ; exit 1" 0 1 2 3 15

rm -f msg.$$ || exit 1;
cat | formail -f -I "X-subsystem-sent: \"$CHROOT\"" >$TEMP/trapmail.$$

exec <$TEMP/trapmail.$$ || exit 1
rm -f $TEMP/trapmail.$$ # safe, we hold the file descriptor

exec /usr/sbin/sendmail -t -i 
exit 1

    

Answer 2

Há um exploit em um dos arquivos / bibliotecas que o site está usando. A exploração permite que os arquivos sejam enviados para o servidor e, parece, colocados em locais arbitrários. Como o PHP é executado como o mesmo usuário que o apache está executando, todos os arquivos enviados serão de propriedade desse usuário. Em segundo lugar, porque a raiz do documento foi chmoded para o 777, ele permite que qualquer usuário do sistema grave arquivos / pastas nesse caminho.

Alterar o nível de permissões, chmod 755 como você fez, ajudará a resolver isso, mas eu recomendaria olhar seus registros / código e eliminar a exploração ou possível exploração.

    

Answer 3

Eu tive uma situação semelhante com um dos meus sites. Eu usei os logs do servidor e os logs do CMS baseados em PHP para identificar o endereço IP.

Usando o arquivo .htaccess, adicionei a seguinte linha (que bloqueia o ponto de acesso em branco)

#Blacklist
RewriteCond %{REMOTE_ADDR} (?:123.123.123.123) [NC]

Substituir o número acima pelo IP (ou bloquear todo o intervalo, se for de um país suspeito), foi o que fiz. Fiz o trabalho. Esta é apenas uma solução possível. Espero que ajude!