Antiga vulnerabilidade UPnP de uma nova maneira

Tudo o que é novo é um velho bem esquecido (ou melhor, um velho muito esquecido). Obviamente, é correto monitorar novas vulnerabilidades, mas você não deve esquecer as antigas. Especialmente quando o fabricante se permite “esquecê-las”. Alguém deve se lembrar. Caso contrário, pisaremos no mesmo rake repetidamente.

O artigo se concentrará em um antigo, mas, como se viu, nunca perdeu sua relevância até hoje, buraco UPnP.



PS: Não ligarei para o provedor, ele não é culpado disso, mas, por outro lado, há uma clara supervisão das políticas de segurança que, juntamente com a arquitetura da rede, possibilitaram explorar essa vulnerabilidade. Como sempre, as estrelas convergem. O provedor instalou roteadores em sua rede para clientes com os chips necessários e o conectou com um endereço IP externo. Sim, a maioria das portas foi filtrada, mas, por algum motivo, não 52869.

PPS Todos os eventos ocorreram no final de 2018. Heróis são fictícios, e coincidências com personalidades reais são aleatórias.


A primeira menção à vulnerabilidade foi em 2014: tyk
Tentativas de contato com o fabricante não tiveram muito sucesso e a vulnerabilidade foi publicada. A única recomendação de contração foi:

"... restringindo a interação com o serviço ... Somente clientes e servidores que têm um relacionamento processual legal ... devem poder se comunicar com ele."

Existe uma falha no serviço SOAP miniigd. O problema está processando solicitações de NewInternalClient devido à incapacidade de limpar os dados do usuário antes de fazer uma chamada do sistema. Um invasor pode usar esta vulnerabilidade para executar código com privilégios de root.

I.e. Em todos os roteadores com UPnP versão 1.0, você pode executar código remoto arbitrário.
Sem autorização. Da raiz. Ótimo, certo?

Qualquer um pode encontrar um plug-in pronto para metasplit no github, cujo desempenho foi testado pelas cadeiras queimadas de nossos engenheiros de serviço.
Foi inesperado e nada divertido.

Uma breve cronologia dos eventos daquele dia:

14:00 No suporte técnico, os assinantes começam a receber chamadas para a Internet com mau funcionamento.

• Sintomas no lado do cliente: "funciona devagar, após uma reinicialização, funciona bem por um tempo e depois lentamente".
• Sintomas por parte do equipamento: um pequeno aumento no tráfego e nas cargas da CPU foram baixados para a carga que o cliente gera.

Aplicativos únicos são registrados para verificar a linha quanto a administradores ou a partida do instalador. Não há modelo comum para ação. Nada está claro.

15:00 O número de solicitações começa a exceder a temperatura média no hospital e as solicitações individuais começam a esculpir as solicitações para mais com o tipo de "Acidente". Os aplicativos são enviados aos administradores seniores para verificar os segmentos de rede.

15:20 Os administradores fecham colisões em massa, porque Não há problemas na rede, todas as solicitações de clientes de diferentes pontos de conexão são únicas. (Por exemplo: o switch está cheio de assinantes ativos, mas não funciona bem para um). Nesse momento, os apelos caem e tudo se acalma. Alguém presta atenção (finalmente) que todos os pedidos de trabalho ruim estavam com o mesmo modelo de roteador, todos juntos fingem que está tudo bem.

15:30 Novamente o afluxo de pedidos dos assinantes, novamente o registro de um acidente em massa e a transferência para os administradores. Nesse momento, fica claro que algo está realmente errado e algo precisa ser feito (quem trabalhou com o serviço ao cliente entenderá o quanto às vezes é difícil fazer isso. Os clientes sempre mentem e, às vezes, a primeira linha está para aumentar ainda mais a tarefa) .

15:35 O engenheiro de serviço recebe uma solicitação de um problema com o serviço ao cliente. Obtém uma lista de todos os clientes, seu tipo de conexão e modelo de dispositivo. E então um pouco de mágica começa.




15:40 O engenheiro executa a lista de clientes através de todos os diagnósticos, cada roteador foi verificado de acordo com todas as métricas padrão e ... nada foi encontrado. Um roteador é como um roteador. Sim, a CPU aumentou, mas os indicadores não são críticos, mas derrama tráfego em algum lugar, o que significa que funciona.

Sim, o serviço UPnP está girando na porta 52869. Sim, ainda há um monte de portas abertas, abertas significa que elas são necessárias (lógica de ferro), e sempre giravam e não havia problemas (mais um argumento da lógica de ferro). O ssh direto para esse modelo de roteador não é possível (francamente, é possível, mas dentro das políticas da empresa e da empresa, foi altamente desencorajado que essa caminhada nos dispositivos clientes). Tudo se levantou novamente.

16:00 Só agora descobrimos que existem alguns problemas. O engenheiro de serviço se reporta ao seu supervisor, e o supervisor faz um telefonema para nós sobre suas suposições sobre a porta 52869 e pede ajuda.

16:05 Então tudo aconteceu muito rapidamente. O mesmo modelo de roteador está incluído no suporte de teste, o endereço IP é retirado do cliente com problema e pendurado no teste. O wireshark está ligado. Isso é para capturar solicitações para o dispositivo.

Para capturar solicitações do roteador (naquele momento, o esquema geral de como a interação ainda era desconhecida), o cliente é isolado no segmento de teste e todo o seu tráfego é espelhado na máquina de teste mais próxima onde outro wireshark é gerado.

Esperamos mais, olhamos para a tela.

Hacks já foram capturados dessa maneira - com bastante eficiência e, portanto, decidiram não mudar de hábito.

16:10 Enquanto o wireshark sussurra, no Google há uma vulnerabilidade CVE-2014-8361 sobre a qual é relatada aos engenheiros. O engenheiro, sem ouvir, toma uma decisão (e, em princípio, lógica) - o filtro dessa porta na fronteira. Mal disse o que fez.


16:25 Dizem-nos que toda a merda de refazer Misha não funcionou. E nós já sabíamos que isso não funcionaria. Naquele momento, eles já haviam batido no roteador de teste, levantado o inverso e entrado em outra porta e começaram a usá-lo para a porta DDOS-a até 1900 (!) Usando outra vulnerabilidade. Senhor, que lata de lixo com vazamento


O mais interessante é que as regras de firewall no dispositivo foram alteradas e o nmap agora não mostra portas abertas do lado de fora. Somente em um despejo de tráfego foi possível detectar solicitações nessas portas. I.e. um invasor após hackers bloqueou o acesso ao restante. Não é uma abordagem de alta tecnologia, mas é bravo mesmo assim.

16:30 Uma conferência se reúne com as perguntas "quem é o culpado e o que fazer". As portas 1900 e 52869 foram deixadas proibidas e estão sendo feitas tentativas para corrigir algo em dispositivos invadidos. Reiniciar - não ajudou, a idéia de reflash foi imediatamente rejeitada. Sim, existe uma funcionalidade, foi possível reorganizar remotamente o software via TR069 com um botão em todos os dispositivos. Mas desde o dispositivo não foi a primeira atualização, mas o número de clientes foi grande - uma certa porcentagem de dispositivos em tijolos criaria problemas.

16:40 Para resumir: os dispositivos foram invadidos, participe de um mínimo de ddos ​​e transmita algo em algum lugar do canal criptografado. (Tudo em portas diferentes ). Não é possível entrar, o fornecedor recusou o acesso total via ssh ao dispositivo e ver o que era impossível chegar lá. O console é protegido por senha.

Em algum lugar mais perto das 17:00, foi decidido costurar o dispositivo como o caminho mais rápido. Depois de piscar e reiniciar, tudo voltou ao normal.

Em vez de totais

Infelizmente, não conseguimos resolver completamente este problema.

Por "decidir", quero dizer obter informações completas sobre hackers e atualizar nossas políticas para combater isso no futuro. Sim, nem todas as tarefas são resolvidas com sucesso e como gostaríamos. Isso é normal. Embora ofensivo.

Se é bom procurar no shodan,
você pode encontrar algo
para experimentos:
de um jeito ou de outro
mas eu não te disse isso.