Como proteger servidores de um ataque de solicitação cgi-bin / php POST

Question

Recebemos uma solicitação POST em nosso servidor com o seguinte:

%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%F%69%6E%70%75%74+%2D%6E

Usando o decodificador de URL, isso se traduz em:

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n

Parece ser semelhante a solicitações de URL estranho via Nginx no Ubuntu 14.04, o que o usuário malicioso está tentando fazer? . Em que cenário a solicitação funcionaria? Vejo nos logs que enviamos um 404, mas quero ter certeza de que não temos nenhuma outra caixa que possa ser vulnerável a ele.

    

Answer 1

Muitos anos atrás, as pessoas usavam o PHP como um script CGI (nem mesmo o FastCGI, ele ainda não existia!) em parte para que pudessem trocar o Apache de seu MPM prefork de baixo desempenho para o novo e de maior desempenho. trabalhador MPM. (E o nginx ainda era desconhecido, foi há muito tempo atrás.) Se um servidor foi configurado para executar o PHP como um script CGI, você poderia chamar o interpretador PHP diretamente em /cgi-bin/php .

O PHP tecnicamente ainda pode ser instalado como CGI, mas acabou não sendo tão eficiente quanto as pessoas esperavam, assim o FastCGI foi inventado. Todos os sites PHP atuais de alto desempenho usam FastCGI / FPM, geralmente com nginx ou às vezes com o evento MPM do Apache. FastCGI / FPM não são vulneráveis a isso, pois não permitem que o PHP seja chamado diretamente através de /cgi-bin .

Se o seu servidor não for uma pilha antiga de PHP rodando como CGI, então você não precisa se preocupar com esta requisição.

    

Answer 2

O problema geral é a injeção de comando . Facilitado por antigas configurações CGI inseguras permitindo a direção de execução do php, embora um servidor web moderno que enviou um 404 não seja vulnerável a isso especificamente.

Você o impede removendo o CGI onde ele não é necessário, bloqueando o servidor web com permissões de arquivo e talvez o SELinux, e protegendo seus aplicativos da web. O Projeto de Teste de Projetos de Segurança de Aplicativos da Web Abertos tem alguns conselhos gerais.

    

Answer 3

Atacantes maliciosos, ou pentesters que desejam obter uma parte do seu bounty de bug irão testar o seu site em busca de erros comuns cometidos ao escrever aplicações web.

Existem algumas maneiras de proteger seus aplicativos Web contra um ataque bem-sucedido:

• treinar seus desenvolvedores da web a usar boas práticas de segurança, como sempre OWASP é um bom ponto de partida: link
• coloque seus aplicativos por trás de um Firewall de Aplicativos da Web. (WAF) um WAF verificará todas as solicitações de recebimento e simplesmente descartará aquelas que parecem não estar funcionando bem. Uma solução em nuvem fácil de usar é o link , mas há muitos outros por aí, seja em nuvem, pode instalar em seu datacenter de software que você pode executar em seus servidores (pense em palo alto, fortigate, checkpoint, watchguard)
• Permita que um testador de caneta investigue sua infra-estrutura (regularmente), se você fornecer documentação e informações sobre seus sistemas, eles poderão realizar esses testes menos cegos do que um invasor aleatório na Internet, provavelmente encontrarão os problemas mais rapidamente então um atacante aleatório e você pode consertá-los. Se você quiser fazer isso sozinho, novamente, o OWASP é um ótimo recurso: link

Nenhuma dessas opções tem garantia de 100% e eu recomendaria fazer todas elas.

    

Answer 4

Remediation

Sanitization

The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + ,

Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + ,

Permissions

The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view.

link

Instale também o modsecurity no Nginx com as regras do comodo.

link