Adicionada ofuscação do timing de teclas ao ssh(1)

 (undeadly.org)
3 pontos por GN⁺ 2023-08-30 | 1 comentários | Compartilhar no WhatsApp
  • Damien Miller fez commit de um recurso de ofuscação para ocultar as informações de tempo entre pressionamentos de tecla no cliente ssh(1)
  • Em tráfego interativo com poucos dados enviados, ele usa transmissão em intervalos fixos, com intervalo padrão de 20 ms
  • Após a última tecla real digitada, envia entradas falsas de chaff por um tempo aleatório para embaralhar ainda mais o padrão de timing
  • O comportamento é controlado pela nova palavra-chave ObscureKeystrokeTiming em ssh_config
  • A implementação usa novas extensões PING/PONG da camada de transporte do SSH, e depois pode chegar a outros sistemas por meio do openssh-portable

Ocultação do timing de digitação no cliente ssh(1)

  • Damien Miller fez commit de suporte à ofuscação do timing de teclas em ssh(1)
  • Esse recurso tenta enviar o tráfego interativo com pouco volume de dados em intervalos fixos, para ocultar o intervalo de tempo entre as teclas digitadas
    • O intervalo padrão de transmissão é de 20 ms
    • Após a última tecla real, ele transmite entradas falsas de chaff por um tempo aleatório
  • A operação é controlada pela nova palavra-chave ObscureKeystrokeTiming em ssh_config

Extensão do protocolo SSH e caminho de distribuição

  • A implementação usa duas novas mensagens da camada de transporte adicionadas ao protocolo SSH
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • Essas mensagens usam o espaço de numeração de local extensions e são anunciadas com a mensagem "ping@openssh.com" ext-info e a versão em string "0"
  • A mudança é apresentada como um exemplo de “security by trickery” e como mais um motivo para aguardar o próximo lançamento do OpenBSD
  • Outros sistemas provavelmente verão esse recurso em breve por meio do openssh-portable

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-30
Opiniões do Hacker News

  • O timing das teclas digitadas é uma preocupação em I/O de terminal desde os anos 1980, e mesmo naquela época já era algo levado em conta em ambientes iniciais de criptografia, como stelnet ou Kerberos
    A maioria dos apps de terminal usa I/O com buffer para entrada de senhas, e isso ainda é um recurso de segurança importante
    Nesse modo, nada é enviado para o outro lado até o usuário pressionar Enter, então, com padding, fica difícil para um ataque man-in-the-middle inferir até mesmo o tamanho da senha
    Por um tempo, apps que recebiam senhas em modo sem buffer para mostrar um * a cada tecla digitada eram alvos fáceis
    Visualmente é elegante e dá feedback, mas vaza justamente a velocidade de digitação, que é o que mais deveria ser ocultado na entrada de senha
    Eu gostaria que a entrada de senhas continuasse usando I/O com buffer, e acho essa abordagem melhor a ponto de ser difícil para o SSH acompanhar, mesmo com ofuscação
    Ainda assim, é bom que o SSH tenha adicionado esse recurso, e ele ajuda a proteger coisas que não podem ser colocadas em buffer, como entrada no shell ou em editores

    • O método usado hoje, de exibir um número fixo de asteriscos independentemente do tamanho da senha, é bastante confuso para o usuário
      A pessoa pode pensar “o tamanho está errado, então deve estar incorreta” e tentar digitar manualmente a senha “certa”, anulando a vantagem de uma senha salva
      No passado, acho que havia métodos que mostravam um hash visual, como um hash de 2 dígitos e um smiley, mas isso pode até ajudar ataques de alguém olhando por cima do ombro
    • Nos anos 1990, com um add-on de IA baseado em Visual Basic, bastavam alguns minutos de digitação para identificar quem estava usando o teclado apenas pelo padrão de digitação, o que tornava o processo de login praticamente inútil
      Hoje isso também poderia ser aplicado a logins em telas sensíveis ao toque, associando pressão do dedo, área de contato e formato ao usuário
      Se incluir swipes e movimentos do mouse no contexto de um sistema operacional desktop, também seriam possíveis apps de segurança capazes de bloquear o sistema quando alguém que não é o dono do dispositivo ou da conta estiver usando
      No mínimo, daria para registrar o momento em que meu/minha parceiro(a) fuçou no meu celular
    • Autenticação SSH baseada em senha é algo que praticamente nunca deveria ser usado
    • Fico curioso se existe algum cliente SSH que faça buffer da entrada linha por linha
      Ou seja, que não envie o que foi digitado até pressionar Enter ou um botão de envio
      Na época em que eu jogava muito MUD, usava clientes Telnet assim, mas nunca vi isso em clientes SSH desde então
      Parece uma defesa razoável contra vazamento de timing de teclas no SSH e, em alguns cenários de uso, talvez seja melhor do que o atraso de 20 ms mencionado no artigo
      Pensando melhor, porém, seria mais ideal que ele também enviasse quando Tab fosse pressionado, para o autocompletar do shell no Linux
    • Se “a maioria dos apps de terminal usa I/O com buffer para entrada de senhas”, fico me perguntando se a existência deste patch significa que o OpenSSH não se comporta assim

  • Isso me lembra Bridge profissional
    Eles separam as equipes com uma parede e passam as cartas simultaneamente por uma abertura, para impedir comunicação por timing
    https://youtube.com/watch?v=RVZLNRmO3vo

    • Mesmo assim, trapaceiam por meio das telas
      https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
      https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
      https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
      E esses são só os casos que conhecemos
      Uma vez usei Bridge de verdade em uma entrevista
      No Bridge existe uma regra de Ética Ativa segundo a qual, se seu parceiro lhe dá uma dica por meios que não sejam os lances, você deve obrigatoriamente escolher a direção oposta sempre que isso for logicamente possível
      Em uma entrevista de debugging, o entrevistador estava tentando me levar de forma óbvia demais à resposta, então parei para verificar tudo que me vinha à cabeça antes de fazer o que ele dizia
      Depois da entrevista, expliquei por que fiz isso e disse que, se precisassem de mais explicações, procurassem por Ética Ativa
      E fui aprovado
    • Se as pessoas simplesmente tiverem que executar um autômato predefinido, como máquinas de estado humanas, e forem penalizadas ao se desviar, então é melhor decidir o vencedor no cara ou coroa e pular o jogo
      Isso é parecido com dizer que o catcher não deveria poder sinalizar para o pitcher
      Transferência de informação é uma habilidade humana que acrescenta uma dimensão ao jogo, e deveriam deixar vencer quem faz isso melhor
    • Do ponto de vista de red team, há irregularidades humanas demais aqui que poderiam ser exploradas
      Não parece muito difícil transmitir algo como 1 ou 2 bits de informação
    • Bridge é um jogo realmente estranho
      A comunicação secreta com o parceiro é o ponto central, mas essa comunicação não pode ser secreta
      É muito peculiar, como se a regra fosse que você pode se comunicar, mas não deve se comunicar
    • Ainda parece haver possibilidade de transmitir informação
      Por exemplo, dar um empurrãozinho ou empurrar lentamente uma mesinha através da barreira para indicar algo
      A pessoa no canto superior direito do vídeo passou assim na primeira e na segunda vez

  • Há um texto de 2008 apresentando um artigo de 2001 sobre esse tipo de ataque de timing: https://lwn.net/Articles/298833/
    O artigo citado é “Timing analysis of keystrokes and timing attacks on SSH” e analisa como as informações de timing das teclas vazam informações sobre a sequência de teclas digitada
    Uma análise mais detalhada diz que, para cada par de teclas digitadas, vaza cerca de 1 bit de informação sobre o conteúdo, e que, como a entropia de senhas fica em torno de 4 a 8 bits por caractere, essa informação pode ser bastante significativa
    Eu achava que isso tinha sido corrigido há muito tempo, e pensava que uma correção havia entrado por volta de 2012, então é bem surpreendente que ainda não tenha sido resolvido

  • Talvez algum dia seja necessário usar pacotes preenchidos previamente com dados aleatórios para ocultar as teclas digitadas
    Não é exatamente esteganografia, mas chega bem perto, e também parece que poderia ser usado para tornar a análise de tráfego mais difícil ou até impossível

    • A NSA e outros usam métodos assim há décadas
      Se for uma linha dedicada, não é tão difícil manter a linha sempre totalmente criptografada no uso máximo e só sobrepor dados reais quando necessário
    • Esse método também permite esteganografia
      Há pesquisas em que um modelo de linguagem reescreve um texto de cobertura inofensivo, mas substitui a distribuição de probabilidade usada na amostragem de palavras por uma distorção de entropia mínima derivada de uma chave
      No lado receptor, usando o mesmo modelo e a mesma chave, é possível decodificar o texto de cobertura de volta para o texto cifrado, e isso também se aplica a imagens
      https://openreview.net/forum?id=HQ67mj5rJdR
    • Isso lembra transmissões de números
      Números são transmitidos continuamente para o mundo todo, e só ganham significado quando aqueles números têm significado para alguém
      Fazem isso mesmo sabendo muito bem que agências de inteligência do mundo inteiro estão ouvindo
    • Alguns protocolos de mensagens funcionam assim
    • O tráfego SSH é criptografado, então, para um observador, os pacotes já parecem dados aleatórios

  • Isso me faz pensar em emuladores de terminal modernos, como o Warp no macOS
    Por exemplo, fico curioso se eles recebem toda a entrada localmente e depois a enviam ao host remoto em um bloco só
    Fazer isso poderia quebrar alguma entrada em modo raw executada no host remoto, mas talvez desse para detectar essa situação e alternar para um fluxo bruto de teclas
    [1]: https://warp.dev

    • Em geral, quando você se conecta via SSH, a conexão em si está sempre em modo raw, e o host remoto trata o pty da forma usual
      O pty remoto pode estar em modo por linha ou em modo raw
      Terminais com integração especial com o shell normalmente exigem que essa integração também esteja instalada no host remoto, e alguns lidam com isso de forma bastante transparente
      É por isso que o mosh pode se comportar melhor do que SSH puro em conexões com latência maior
      Porém, esse recurso não deve se aplicar ao mosh
    • É difícil imaginar que um app que se vende como “IA para o terminal” seja mais seguro e privado do que ferramentas Unix padrão
      Recursos de segurança específicos, como defesa contra ataques de timing, podem ser melhor implementados por uma ferramenta nova e talvez nem existam em ferramentas padrão antigas
      Mas é muito mais provável que outros recursos de segurança estejam ausentes na ferramenta nova, e adicionar “IA” aumenta muito a superfície de ataque
      Sinceramente, também é difícil acreditar nas alegações de privacidade do Warp
      Hoje em dia, ferramentas de processamento de linguagem natural quase sempre tendem a soluções em nuvem, e nesse caso a possibilidade de privacidade cai quase imediatamente para perto de zero
    • Se algo foi projetado para receber dados em uma determinada taxa de baud, a entrada enviada em um bloco só não acabaria entrando no fluxo nessa mesma taxa?

  • Fico curioso sobre qual ameaça isso mitiga

    • Um espião não consegue ver o conteúdo das teclas digitadas, mas antes conseguia ver quando cada tecla era transmitida
      Se ele conhecer o padrão de digitação do alvo, pode usar esses dados para reconstruir o conteúdo
      É possível coletar esse padrão fazendo o alvo digitar em um site controlado por mim em um navegador com JavaScript habilitado, ou gravando o som da digitação
      Recentemente, alguns streamers online também sofreram ataques em que senhas foram roubadas com modelos de IA treinados no som de teclados
    • Se me lembro bem, havia um artigo por volta de 2005 que correlacionava tempos de pacotes em sessões SSH criptografadas com estatísticas coletadas de digitadores humanos para descobrir o que havia sido digitado
      Este recurso parece adicionar ruído para impedir isso
    • A preocupação original com a vulnerabilidade era o uso do algoritmo de Viterbi
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      Com a adição de aprendizado de máquina, a precisão da decodificação por áudio melhorou bastante, então é melhor usar um teclado silencioso em locais fisicamente inseguros
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • Basicamente, dá para analisar a velocidade de digitação e fazer algumas inferências
      Por exemplo, como usuários normalmente digitam senhas mais rápido do que outros textos, é possível estimar o tamanho da senha observando a quantidade de teclas enviadas de uma vez em operações como sudo
    • Recentemente houve pesquisas usando timing de teclas e deep learning para identificar usuários como uma impressão digital, e este artigo usa isso para autenticação: https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      O caso de uso do artigo em si não é uma ameaça de segurança, mas pode ser interpretado como vazamento de informação

  • Fico curioso sobre quanta latência isso adiciona
    Em especial, latência imprevisível é um dos maiores fatores de estresse no trabalho de desenvolvimento de software

    • Está dito diretamente no texto
      Quando apenas pequenas quantidades de dados são transmitidas, o tráfego interativo é enviado em intervalos fixos, e o padrão é 20 ms
    • A discussão acima sobre latência parece se referir à latência na experiência do usuário, isto é, o atraso entre pressionar uma tecla e ver o resultado
      [1]
      Ferramentas como o Mosh ajudam bastante a reduzir a latência percebida
      O Mosh exibe a tecla do usuário assim que ela é registrada localmente, em uma cor esmaecida para indicar que a ida e volta ainda não terminou
      Foi assim da última vez que vi; talvez fosse sublinhado
      Quando a ida e volta termina, o caractere é exibido normalmente
      [1] Se o maior fator de estresse no desenvolvimento de software for a latência das teclas, isso soa como bastante sorte
      [2]: https://mosh.org
    • Essa latência não é previsível por design?

  • Link do commit real: https://github.com/openssh/openssh-portable/commit/7603ba712...

  • Parece que alguns detectam shells hands-on-keyboard na rede medindo o timing dos pacotes; fico curioso para saber o quanto essa mudança vai atrapalhar esse tipo de detecção

    • Espero que esse tipo de abordagem siga o mesmo caminho de outras tentativas corporativas de quebrar criptografia ou inserir backdoors em nome da “segurança”
      Acho uma forma realmente errada de abordar segurança
      Seria bom saber se um script de automação está fazendo login em um equipamento, mas um projeto melhor poderia tornar essa informação irrelevante
    • Quais seriam os casos de uso não maliciosos para isso?