Evitar a execução do script de shell pelo Apache

Question

Eu encontrei alguns scripts de shell que foram executados pelo apache depois de serem enviados para um diretório de plugins do Wordpress (plugin é respeitável).

top -c

25821 www-data  20   0 99108 1268  996 S  779  0.1 105:27.72 ../mine.32 --url=http://vibehacks.net/ --userpass=HI:FRIEND

ps -aufx | grep mine.32

www-data 25819  0.0  0.0   2236   540 ?        S    22:01   0:00  |   \_ sh -c nohup ../mine.64 --url=http://vibehacks.net/ --userpass=HI:FRIEND >./mine.log 2>&1; nohup ../mine.32 --url=http://vibehacks.net/ --userpass=HI:FRIEND >./mine.log 2>&1
www-data 25821  490  0.1  99108  1268 ?        Sl   22:01 120:14  |       \_ ../mine.32 --url=http://vibehacks.net/ --userpass=HI:FRIEND

    

Answer 1

Suponho que, embora você não tenha dito, você foi hackeado e está procurando maneiras de evitar que isso aconteça novamente.

Eu não acho que você pode controlar o tipo de arquivo que o apache irá executar desta maneira, se você tiver seus manipuladores configurados de tal forma que eles vejam tudo em um diretório para ser um CGI. Se você alterar seus manipuladores para que apenas arquivos com um determinado tipo de extensão sejam interpretados como executáveis CGI, o invasor poderá apenas alterar o nome do arquivo. O Linux interpretará qualquer executável praticamente da mesma maneira, desde que ele tenha um cabeçalho ELF ou um shebang no topo, ou seja, de outro modo executável, não importa realmente o que é chamado (e o apache não precisa se importar ou). Portanto, evitar que o apache execute scripts de shell não é feito facilmente (não acho que seja realmente possível). Além disso, o problema real era que um invasor era capaz de colocar arquivos arbitrários em locais confiáveis em sua caixa.

O que eu sugiro que você faça é determinar como isso aconteceu. Com os plugins do wordpress, isso pode ser de algumas maneiras. Por exemplo, certamente poderia ter sido carregado usando uma conta FTP roubada ou uma conta SSH. Ele também pode ter sido enviado por meio de um rootkit (é por isso que eu reconstruo qualquer caixa que tenha sido estourada). No entanto, como é no wordpress, o cenário mais provável é muito mais bobo.

Quando o wordpress pode atualizar a si mesmo e seus plug-ins e instalar conteúdo usando sua interface da web, você se abre para essa possibilidade. Se alguém tiver acesso a uma conta do wordpress privilegiada, ou falsificar um servidor do qual esse conteúdo possa ser baixado, ou apenas adicionar sua carga útil a um plug-in e aguardar sua atualização, você será o proprietário. Embora o wordpress pareça gostar desse recurso, eu e todo mundo que conheço no campo de infosec recomendo strongmente que ele seja desativado; O apache nunca deve ter acesso de gravação à sua própria webroot, e isso é especialmente verdadeiro para locais CGI.

    

Answer 2

Se você encontrou o arquivo / scripts no "diretório do plugin do Wordpress", você deve verificar nos logs de ftp ou do sistema que o endereço IP e qual autenticação de usuário foi carregada,

Em seguida, altere a senha desse usuário e desative esses scripts. Você pode desabilitá-los, alterando as permissões 000 e ownship root.