Certa vez, invadi um dos servidores de telegrama. Não que isso fosse algo interessante, e as próprias vulnerabilidades são padrão. O fato de os telegramas se relacionarem com a segurança e por que, ao longo dos anos, ninguém explorou vulnerabilidades é bastante surpreendente. Mas quem não faz nada não está enganado!
Em maio de 2017, o
kyprizel chamou a atenção para o fato de que a área de trabalho de telegrama pode fazer upload de arquivos ZIP no servidor
tdesktop.com . Como se viu mais tarde, não apenas o ZIP, mas por dentro há informações sobre a falha do aplicativo, para que o desenvolvedor possa estudar sob quais circunstâncias a falha ocorreu. Além disso, o desenvolvedor obtém acesso a eles através da interface da web, a julgar pelo formulário de autenticação. Eu adicionei o anfitrião às notas e esqueci com segurança.
Lembrei-me dele depois de cerca de um ano, quando os próximos estudos foram discutidos em um bate-papo. Naquele momento, o arquivo raiz era error_log, no qual, como você deve ter adivinhado, erros foram gravados. No mínimo, havia caminhos de arquivo completos, mas, além disso, o erro favorito é "Você tem um erro na sintaxe do SQL". Mas somos todos preguiçosos e, em geral, na tentativa de não participar, tudo permanece como está.
Mais um ano se passou, fui convidado a falar na conferência
#PartyHack em Kazan. E quando você não tem o material para falar, olha as anotações. O que temos lá? Anfitrião suspeito em Telegram.
Como o servidor usava PHP, como evidenciado por crash.php, decidi examinar um pouco os arquivos com essa extensão, e me deparei com info.php, onde estavam os conteúdos da função phpinfo (). A primeira coisa que notei foi usar o servidor da web Apache. Como assim? O telegrama inteiro é nginx, e aqui está o Apache! E quem usa o apache em 2019?
O que vem à mente quando você ouve o Apache? Lembro-me imediatamente do mod_status, que é construído com ele por padrão. Este módulo gera uma página com o estado atual do servidor, sobre recursos do sistema, solicitações do servidor e a velocidade de seu processamento. Na maioria das vezes, o caminho para isso é / server-status, raramente apenas / status. Para entender o quão popular é esse erro administrativo, lembre-se de que ele ficou no site apache.org por muitos anos
Por muitos anos eu coleciono caminhos para arquivos e diretórios potencialmente perigosos no projeto fuzz.txt , então o status do servidor estava lá naturalmente.Em geral, é digno de nota no status do servidor que também mostra os endereços IP dos clientes que enviam solicitações ao servidor. Porém, nesse caso, todas as solicitações eram de 127.0.0.1 para o domínio virtual preston-desktop.com. O Nginx na frente apenas procurou todas as solicitações no apache local, portanto não houve divulgação de informações do usuário. No entanto, valeu a pena colocar o status do servidor para monitorar, aqui está um
pequeno script feito no joelho que coloca linhas exclusivas no banco de dados sqlite. Por um curto período de tempo, muitos links exclusivos foram coletados, mas basicamente eram solicitações de atualizações (indicando a versão) e quase não havia downloads. Depois de um tempo eu vi o administrador.
Apesar de termos um comprimento de linha limitado, é possível ver nos logs que o administrador ocasionalmente baixa os logs de queda para análises adicionais, e os parâmetros engraçados __login e __token são passados para lá. E os pedidos POST na captura de tela são meus.
Olhando a fonte, você pode perceber dois métodos interessantes.
O primeiro é o
query_report , que possui opções adicionais de apiid, versão, dmp e plataforma. Ele retorna se mais logs são necessários sobre a falha do aplicativo ou se a versão já está atualizada e erros são conhecidos. O mecanismo foi criado para não exagerar, mas corrigir apenas o real.
O segundo é o próprio
relatório . Já sem parâmetros adicionais. Se uma palavra retornou à solicitação anterior que indica a necessidade de enviar um despejo, o arquivo é enviado.
Lá, você pode ver que os dados são enviados usando várias partes, onde o nome do arquivo é report.telegramcrash e seu aplicativo do tipo Conteúdo / fluxo de octetos.
Assim, você pode tentar fazer upload de seus próprios arquivos e testar as vulnerabilidades associadas à descompactação de ZIP e outras partes de upload.
Além disso, tentaria enviar uma carga diferente para encontrar pelo menos algum tipo de vulnerabilidade, se não fosse um truque. Se substituirmos os nomes de parâmetros conhecidos de outra solicitação, cujos valores válidos foram obtidos do status do servidor, no método de relatório, podemos tentar usar um ataque secreto de todos os hackers da web.
Utilizando a potência do megazord (aspas simples) no parâmetro plataforma, foi possível observar o comportamento anômalo do recurso.
Há aspas - um erro, sem aspas - está tudo bem. Para verificar a validade, você pode escrever alguma expressão lógica, por exemplo platform = mac 'AND' a '=' a. A resposta é Concluído, como no upload bem-sucedido de arquivos.
Bem, não admira que eles tenham inventado a automação, por isso estou dissociando o sqlmap, que já ficou empoeirado pela inação. Antecipando perguntas - tudo o mais estava bem configurado, o usuário no DBMS não é privilegiado.
Enviado para security@telegram.org, pouco depois recebi a cobiçada carta sobre o prêmio de US $ 30.000.
Brincadeirinha, US $ 2000 para sqli e US $ 500 para phpinfo e status do servidor, o que também é bom. E os lobos estão seguros e as ovelhas estão cheias, ou vice-versa.
Não hackeei usuários (sua correspondência é segura), não pude desenvolver ainda mais o ataque, um servidor com despejos de usuários aleatórios (ou seja, despejos de desastre sem informações sobre o identificador em telegrama, telefone, mensagens e bate-papos) é um valor duvidoso. Em teoria, seria possível bombear falhas, estudá-las e explorá-las. Depois de aprender como os telegramas são descartados, você pode descartá-los da vítima e, em seguida, estudar tudo o que pode extrair dos registros de queda, se puderem ser baixados através desta injeção.
Original único.