Configure uma conta de usuário "endurecida" que um invasor teria dificuldade em abusar

Question

Suponha que você tenha uma máquina Windows Server executando vários serviços confidenciais. Suponha que um desses serviços seja bastante simples, mantendo uma pequena quantidade de informações em um arquivo de texto, mas como resultado de estar mal codificado, possui uma vulnerabilidade de execução de código arbitrária (desconhecida).

É possível configurar uma conta de usuário para esse serviço de forma que, se um hacker explorasse essa vulnerabilidade com êxito, o maior dano que poderia fazer seria ler / gravar esse arquivo de texto, atrapalhar esse serviço específico e possivelmente listar os arquivos fora de C: \ Windows, mas nada mais?

Uma tentativa ingênua de fazer isso imediatamente se depara com um problema: qualquer um em "Usuários" pode gravar em C: \ Arquivos de Programas e remover "Usuários" da ACL desse diretório resulta em um erro de permissão, fazendo com que eu me pergunte se é uma péssima ideia.

Ou o jogo já está perdido se o invasor puder executar código arbitrário, independentemente de qual conta de usuário é usada? Eu sempre pensei que os descendentes do Windows NT tornassem possível conter isso, mas agora que eu tentei, não tenho mais tanta certeza.

    

Answer 1

Por padrão, os usuários podem não gravar em C:\Program Files . Eles têm Leitura, Listar Conteúdo da Pasta e Ler & Executar. Se esse não é o seu caso, alguém ou alguma coisa modificou essas permissões.

Um usuário limitado pode ler grande parte do sistema de arquivos, mas só pode gravar em locais aos quais tenha acesso explicitamente, como seu perfil de usuário.

Se você conceder Modify somente para aquele arquivo de texto, a única coisa que a conta poderá gravar no sistema de arquivos é esse arquivo, mais coisas em seu diretório de perfil (Meus Documentos, etc ) que não deve ter consequências.

Se você tiver o grupo de usuários interno com permissões de modificação em todo o seu sistema de arquivos, isso não é padrão. Fora da caixa, contas de usuários limitadas podem causar muito pouco dano.

Por si só, um bug de execução de código arbitrário não é especialmente inofensivo se a conta de serviço que está executando seu processo tiver um privilégio limitado. O problema é que há tantas escaladas de privilégios que, quando você pode executar arbitrariamente código, pode simplesmente executar algo que permitirá que você saia do seu nível de privilégio. Por si só, a execução de código arbitrário não é um grande problema, mas no mundo real é quase sempre acompanhada de uma exploração de escalonamento de privilégios. Então, sim, eu ficaria preocupado.

    

Answer 2

Algumas respostas bastante interessantes aqui.

Tomando uma postura empírica, com vários testes de pós-penetração "coisas para consertar listas" no meu currículo, eu diria que a Microsoft fez um ótimo trabalho nos últimos anos de fornecer as ferramentas e opções para proteger um servidor muito bem .

É claro, a MS ainda fuzz seu código, e eles e a comunidade continuam a encontrar exploits de escalada de execução / privilégio remoto, mas eu tenho que dizer, o patch deles é on-the-ball comparado a alguns outros fornecedores (SonicWall , Tivoli e Oracle vêm à mente).

Minhas recomendações seriam:

• Verifique se o Controle de Conta de Usuário (UAC) está ativado
• Garantir que a Prevenção de Execução de Dados (DEP) esteja ativada
• Usar contas de serviço gerenciado (Windows 7 ou Windows Server 2008 R2 e superior)
• Comece com os privilégios mínimos absolutos e adicione apenas mais se for absolutamente necessário. Quero dizer sistema de arquivos privs e atribuição de direitos de usuário (diretiva de segurança local ou diretiva de grupo)
• Use o Process Monitor da Microsoft para diagnosticar problemas de privilégio (ao experimentar ^^^)
• Verifique se o servidor está com patch (patches de segurança, pelo menos, via WSUS)
• Se você tiver um software de terceiros instalado, mantenha esse patch também.
• Desinstale o Java. A menos que você realmente precise disso. Corrigi-lo Em seguida, corrija-o novamente porque o patch que você aplicou não corrigiu a falha que a Oracle disse que faria. Desculpe, a Oracle arruinou o Sun Java!
• Mantenha o software de sistemas do seu fornecedor de hardware atualizado (BIOS, drivers de dispositivo, etc.)
• Use a auditoria do Windows para monitorar a atividade de sua nova conta brilhante.
• Encaminhe eventos em algum lugar central.
• Examine diariamente os eventos encaminhados ou, pelo menos, configure os acionadores para alertar quando necessário.
• Habilite o Firewall do Windows (é uma pena, mas muitas pessoas o desligam)
• Certifique-se de que o backup do seu servidor seja feito, por isso, se o pior acontecer, você terá seus dados.
• Desenvolva um plano para o que você faria se o pior acontecesse.
• Não permita que seu servidor acesse a Internet. Mais uma vez, não consigo acreditar no número de data centers em que já estive, onde há acesso HTTP (S) aberto à Internet para todos os servidores. Algumas pessoas precisam ser levadas para conversar.

É importante lembrar que não existe um o / s, aplicativo ou rede completamente seguro. É tudo sobre camadas de prevenção e identificar quando as coisas parecem diferentes. Não seja vendido em Detecção de Intrusão, a menos que, é claro, você a) seja suscetível a discursos de vendas sensacionalistas, b) tenha muito tempo livre em suas mãos e c) tenha bastante dinheiro sobrando.

Finalmente, os "ataques" mais desonestos nos dias de hoje não são sobre interrupção; muito pelo contrário. O foco (e financiamento!) Mudou para a exfiltração de dados.

    

Answer 3

No mundo do Linux, usaríamos o SELinux ou outro mecanismo de controle de acesso obrigatório para atenuar esse tipo de ameaça.

O Windows não tem nada tão robusto, mas desde o Vista / 2008 ele tem um mecanismo de integridade básico que você pode usar. (Embora isso tenha uma curva de aprendizado bastante alta e explicá-la totalmente exigiria mais tempo do que é permitido aqui.)

Acho que sua melhor atenuação de curto prazo seria isolar o serviço em uma máquina virtual.

    

Answer 4

Se "executar código arbitrário" significa que o processo pode criar diretórios, pode ser possível que eles criem diretórios no diretório atual, no diretório de perfil de usuário da conta de serviço, na raiz da unidade C: \ ou simplesmente pesquisem para um diretório onde possa criar diretórios.

A última vez que verifiquei, o Windows normalmente conferiu a permissão para criar diretórios na raiz de C :. Você pode não ver isso no gui porque você precisaria visualizar a página de propriedades Advanced ou usar o ICACLS para obter uma lista completa de permissões.

Mesmo que a permissão de diretório C: \ tenha sido endurecida, é trivial pesquisar todos os diretórios em C: \ e testar um em que as permissões permitam que a conta de serviço crie diretórios. As chances são de que haja um.

Se a exploração do processo puder criar diretórios em algum lugar em C :, então é bastante simples desabilitar o sistema criando milhões ou bilhões de diretórios / subdiretórios vazios.

Os diretórios vazios são zero bytes, portanto, não estão sujeitos a cotas. Esses diretórios também são armazenados diretamente na MFT (devido ao seu tamanho pequeno), portanto, mesmo que o processo possa ser interrompido e os diretórios excluídos, a MFT é efetivamente descartada - tão grande e / ou fragmentada que o sistema pode precisar ser restaurado. de backup.

    

Answer 5

Use DEP para todos os processos. Vai parar a maioria, mas há muitos exploits que podem derrotar a DEP de qualquer maneira.

    

Answer 6

Prevenir o abuso tem que ser feito a partir do zero - não adianta fazê-lo para uma conta em um servidor inseguro com uma grande superfície de ataque

Então,

1) Verifique se o servidor está corrigido.

2) Você pode usar o SCW (Security Config Wizard) para proteger o servidor. Ele fará um trabalho mais rápido e melhor do que a maioria dos administradores fará.

Ele permite que você desfaça as alterações feitas, mas só desfará uma etapa. Então, se você executá-lo, bloquear coisas e, em seguida, executá-lo novamente (ou seja, se você perdeu alguma coisa) e então você percebe que algo está quebrado, se quebrou que durante o primeiro bloqueio para baixo, você não pode facilmente desfazê-lo (tem que fazê-lo manualmente)

Então, depois de executá-lo e aplicá-lo, testar a funcionalidade completamente .

3) Então , verifique se você está usando contas que não são administradores, usuários avançados, etc. e que eles têm apenas permissões NTFS para fazer o mínimo do que precisam fazer - nada mais.

4) Você também pode usar a política de segurança local (ou política de domínio, se o servidor for um membro do domínio) para bloquear outros aspectos da GUI.

    

Answer 7

Você certamente pode tentar criar um usuário seguro semelhante àqueles que vêm com janelas que não podem ser conectadas, e só têm acesso a determinados arquivos na máquina. O problema é que uma exploração de escalonamento de privilégios poderia funcionar nesse usuário, dependendo da situação.

Com o linux nós chroot processos jail e serviços como este como parte de uma estratégia de mitigação de segurança. Eu não sou um cara do Windows, mas como você faria isso no Windows?

Uma coisa que você pode fazer para colocar o serviço em um sandbox é executá-lo em uma VM. O Virtualbox é a minha escolha, já que você pode instalá-lo na mesma caixa se quiser e começar com o servidor, mesmo sem cabeça, quase executado apenas como um serviço. É grátis também. É muito difícil para uma exploração escapar da sua VM. A desvantagem dessa abordagem é que você executaria outra instância inteira do Windows, que precisaria ser mantida atualizada e consumiria recursos.

Outra coisa que funcionaria é usar um programa sandbox dedicado, como sandboxie , que pode proteger qualquer processo para dificultar a fuga se fica comprometido.