0 
0 Embora novos ataques pareçam surgir mais rapidamente do que as tendências do TikTok, alguns garantem ação antes mesmo de terem a chance de surgir. Este é o caso de um ataque que chamaremos de Evil-Colon, que opera de forma semelhante aos agora extintos ataques Poison-NULL-Byte. Embora os ataques Poison-NULL-Byte agora estejam obsoletos, eles podem ter pavimentado o caminho para novos ataques semelhantes que podem causar estragos em seu código se não forem tratados adequadamente.
Caso em questão: Ao realizar uma auditoria de código-fonte, me deparei com uma situação em que o Evil-Colon pode ser usado para superar o processo de sanitização do caminho. Nesse caso, descobri uma abordagem excepcionalmente interessante para atacar vulnerabilidades de manipulação de caminho em aplicativos implantados em sistemas operacionais Windows. Como esse é um problema específico do Windows, o método de ataque Evil-Colon provavelmente funcionaria em aplicativos implantados em qualquer servidor Windows.
Como funciona o Mal-Colon
Vamos cavar um pouco mais fundo em como isso poderia acontecer. Imagine que há um aplicativo implantado em um sistema Windows que recebe entrada do usuário, não filtra caracteres de dois pontos e cria um arquivo em um sistema de arquivos usando essa entrada do usuário. Nesse cenário, é possível omitir dados adicionais de “higienização” que são colocados no final do nome do arquivo.
Aqui está um exemplo do pequeno código-fonte do aplicativo Java “WriteFile.jsp”:
A primeira parte deste script criará novos arquivos no diretório c:\testing\webdata\ , mas com a sanitização, o aplicativo anexará a extensão “.txt” a todos os arquivos recém-criados. O que pode ser feito aqui é passar um caractere de dois pontos (“:”) no final do nome do arquivo de entrada do usuário, e a extensão “.txt” será criada como um Alternate Data Stream.
Então, o que será criado no sistema de arquivos é um arquivo com uma extensão de arquivo arbitrária.
Se você passar um argumento para o script, ficaria assim:
http://localhost:8080/examples/WriteFile.jsp?
nome do arquivo=evil.jsp:&data=TEST_31337
Após isso, será criado o arquivo evil.jsp no diretório c:\testing\webdata, sem a extensão “.txt”, mas com a extensão “.jsp” pois foi utilizado dois pontos no final do nome do arquivo e ele “strips” off” o resto da string do nome do arquivo em Alternate Data Stream.
Agora, se houver a possibilidade de manipular de alguma forma os arquivos criados anteriormente no fluxo de trabalho do aplicativo, essa situação pode levar a sérios problemas de segurança.
Se você observar o código-fonte do aplicativo Java, verá que o usuário ou agente mal-intencionado é capaz de modificar arquivos existentes posteriormente no código, o que efetivamente permitirá que eles modifiquem o conteúdo do arquivo “.jsp” para o que quiserem. É importante observar que essa segunda parte do comportamento do aplicativo não é uma vulnerabilidade em si, mas uma situação na qual um ataque Evil-Colon é totalmente explorável.
Veja como fica:
Se você se aprofundar e examinar o conteúdo do evil.jsp no sistema de arquivos, verá que ele contém uma string “EVIL_CONTENT”. Esta demonstração é apenas um exemplo, mas no mundo real também pode ser um script JSP webshell, permitindo que atores mal-intencionados obtenham execução remota de código (RCE) em um aplicativo/servidor vulnerável.
Implicações de um ataque Evil-Colon
O que tudo isso significa? Em poucas palavras, é possível explorar aplicativos que executam operações baseadas em caminho com entrada do usuário de várias maneiras. Eventualmente, isso pode levar a ataques muito mais sérios.
Para pintar uma imagem de um problema grave, tome o caso da entrada do usuário. Quando a entrada do usuário é aproveitada na construção do caminho do arquivo, os dados desse arquivo podem ser alterados posteriormente por alguns fluxos de código adicionais. Um cenário como esse pode resultar em situações perigosas, que podem incluir contornar a lógica de uploads de arquivos para tipos de arquivos específicos, bem como várias injeções de dados arbitrárias, entre outros problemas.
Como se preparar para ataques Evil-Colon
Embora nunca seja possível impedir totalmente um novo ataque, os desenvolvedores podem e devem estar preparados. Primeiro, lembre-se de que essa classe de vulnerabilidades deve ser priorizada caso a caso, por aplicativo. Não é uma abordagem única para mitigação e remediação. No entanto, existem medidas que os desenvolvedores podem tomar para ajudar a reduzir as chances de tais vulnerabilidades.
No caso do Evil-Colon, o invasor provavelmente tentaria todos os fluxos de código, o que poderia levar à criação de caminho com entrada do usuário que geraria nomes de arquivo arbitrários e poderia ser posteriormente explorado para ações perigosas e maliciosas.
Para se defender contra isso, é fundamental eliminar os caracteres de dois pontos de qualquer possível operação de caminho usando filtros ou operações simples de verificação/substituição de string.
Em seguida, determine o impacto que um byte de dois pontos pode ter em várias situações. Também é fundamental implementar auditorias de código em processos de CI/CD, bem como em aplicativos.
As equipes de segurança devem analisar proativamente e proteger o código-fonte do aplicativo o mais rápido possível, de maneira shift-left. Testar cedo e com frequência inevitavelmente reduzirá o número de problemas e horas gastas tentando remediar mais tarde, depois que algo deu errado.
FONTE: HELPNET SECURITY