O cliente up.time para Windows é vulnerável a uma sequência de ataque e formato, bem como um estouro de buffer, e pode permitir que usuários não autenticados venha executar certos comandos.
Para a versão 6.0 e 7.2, um invasor não autenticado na rede pode enviar ou o "% n" ou "% s” formato de parâmetros que fará o aplicativo falhar. Buffer de cópia sem verificar tamanho da entrada o ('Classic Buffer Overflow ') também é permitido.
Para a versão 7.4, um invasor não autenticado na rede enviando comandos com uma entrada que é maior do que 1024 bytes irá travar o aplicativo. Execução remota de código é provável, mas atualmente não comprovada. Para as versões 7.6 e anteriores, o invasor não autenticado na rede podem enviar comandos internos para a porta que o agente está usando o up.time. Estes comandos não são autenticados e, portanto, o atacante pode aprender informações, como a versão do up.time em execução, detalhes sobre o sistema operacional subjacente correndo up.time, detalhes sobre outros processos em execução no sistema, e log de eventos do sistema de informação.
Um usuário remoto não autenticado pode ser capaz de realizar uma negação de serviço em up.time, ou obter informações do sistema para uso futuro. Pode também ser possível executar códigos.
Idera lançou up.time versão 7.6, que aborda CVE-2015-2894 e CVE-2015-2895. Usuários afetados são encorajados a atualizar o mais rápido possível. A questão restante, CVE-2015-2896, vai ser totalmente resolvido em uma versão futura, mas podem ser mitigados com as seguintes ações.
Verifique a configuração de acordo com Idera, os usuários afetados também podem usar as seguintes configurações para mitigar esses problemas:
1. Definir para que todos os agentes executem em modo de somente leitura por padrão.
2. Para utilizar scripts personalizados ou ações de recuperação de gatilho, você precisa definir uma senha no agente, ou adicionar comandos ao arquivo uptmpasswd para o agente linux.
3. Agentes de comunicação pode ser criptografado com SSL usando vários Tunneling SSL / Proxy Utilities (OpenSSL, etc). KB artigos abordam os detalhes para a implementação com Stunnel em várias plataformas.
4. Agentes de execução sob xinet.d também pode ser fixada no nível de serviço ao restringir conexões de entrada para aceitar apenas conexões a partir da Estação de Monitoramento, ou limitar o número total de conexões, etc.
5. Desativar Comandos Agent se você não usar os comando através do console do agente ou da edição de conf / agent_commands.txt.
Nenhum comentário :
Postar um comentário
Deixe seu comentário ou sugestões de postagem.