Leandro Fróes

Você já utilizou algum programa que precisasse de argumentos em linha de comando para executar alguma ação em específico? Algum programa como: ping, wget, curl, valgrind, etc? Estes são só alguns dos milhares de programas que exigem no mínimo um argumento para serem executados (sem falar de suas opções adicionais). Com isto em mente, o programador Zack Akil criou em seu blog um tutorial simples e muito rico sobre como criar um programa de linha de comando em Python, utilizando um módulo nativo chamado argparse. A intenção de ensinar como programas de linha de comando funcionam através da criação de um. ? A ideia do argparse é simples: parsear argumentos passados via linha de comando para um script e executar uma ação de acordo. Mesmo sendo uma tarefa aparentemente simples, ler a documentação ou entender como de fato fazer isto de forma correta pode ser difícil para iniciantes. Até mesmo para quem já programa pode ser uma tarefa difícil, tendo em vista que nem todos utilizam a linha de comando no seu dia a dia. Neste ponto, o tutorial do Zack ajuda muito! O módulo pode ser utilizado tanto no Python 2 quanto no 3, basta incluí-lo em seu script. O tutorial dá uma introdução extremamente interessante, mas as possibilidades de uso são enormes, não se limite à ele!!! ?

Recentemente a equipe de desenvolvimento do Chromium relatou em seu blog que está mudando a maneira como avalia a segurança de páginas HTTP e HTTPS. Trata-se dos avisos de site "Seguro" ou "Inseguro" que o navegador emite quando um usuário acessa um site, como na imagem a seguir: Várias vezes nos deparamos com o um cadeado verde como este da imagem acima, indicando que um site utiliza HTTPS e é "seguro". Ou com um aviso em vermelho, indicando que não é seguro já que o certificado SSL pode ser inválido, o que significa que o usuário pode ser vítima de um ataque do tipo man-in-the-middle. Ainda há os sites que utilizam HTTP puro, caso em que o Chrome os rotula de "Não seguros", como no exemplo abaixo: Outros navegadores possuem abordagens similares, o que pode gerar confusão usuários. ? O relato diz que a partir da versão 69 do Google Chrome não haverá mais cadeado verde indicando segurança, tendo em vista que a utilização de HTTPS não é mais algo diferenciado, mas sim essencial, com a imagem abaixo ilustra: Fonte: Chromium Blog Os sites HTTP continuam marcados como "Não seguros" e para a versão 70, o plano é enfatizar o risco com um aviso em vermelho quando houver entrada de dados no site (via HTTP POST por exemplo), similar ao aviso atual de certificado inválido: Fonte: badssl.com E você, acha que HTTPS é um requisito mínimo? Um diferencial? Nosso canal Papo Binário tem um vídeo que aborda esta velha discussão. Confere lá! ?

Dois meses atrás o pesquisador de nick landave descobriu uma vulnerabilidade no compactador 7-zip. Dentre todos os compactadores o 7-zip é um dos mais complexos, não só por sua leveza e portabilidade, mas também pelo fato de entender como descompactar vários outros formatos, tais como gzip, rar, zip etc. Como diria tio Ben: “Com grandes poderes vem grandes responsabilidades”. O código do 7-Zip é baseado principalmente em uma versão recente do UnRAR. Especialmente as partes de alto nível do código foram fortemente modificadas e com elas uma falha, devido à fragilidade do código. A falha se resume a um membro de uma estrutura (uma classe para ser mais exato) inicializado de forma indevida, ou seja, sem a devida verificação quanto aos dados inicializados. Esta falta de verificação assume que as coisas vão sempre acontecer de um jeito e, se não acontecerem, iniciará uma área não utilizada de memória, possibilitando corrupção de memória, RCE e por ai vai. A CVE (Common Vulnerabilities and Exposures) registrada foi a CVE-2018-10115 e, após a 7-Zip lançar a correção, landave publicou em seu blog não só sobre a falha, mas também como ele a encontrou, como ela pode ser explorada e como corrigi-la. Um verdadeiro trabalho de pesquisa, não é mesmo?

Vivemos em um mundo onde quase todos os tipos de autenticação digital são baseados em senhas, método já considerado inseguro por vários especialistas. Tendo isto em mente, a Microsoft investiu num projeto que já está em testes nas últimas versões do Windows onde o usuário autentica no sistema sem o uso de senhas. No fim do ano passado, a Microsoft relatou as diversas desvantagens de se utilizar senhas, dentre elas: a quebra de senhas fáceis (cracking), difícil memorização, necessidade de troca constante e complexidade exigida. No artigo em que anuncia novas funcionalidades nesta direção, Suzanne Choney, storytelling da empresa, nos conta que a solução para o problema das senhas, segundo a Microsoft, é: você. ? Dentre as funcionalidades recém lançadas com o Windows 10 há a autenticação por reconhecimento facial utilizando o Windows Hello, seja para logar no computador ou para acessar algum aplicativo. Vale a pena assistir o vídeo abaixo para entender como o Windows Hello funciona: Outra funcionalidade bem interessante é a autenticação pelo smartphone utilizando biometria ou PIN através de um recurso chamado Microsoft Authenticator App. Estes e outros recursos estarão disponíveis para qualquer usuário (podendo utilizar também 2FA) sem precisar de senhas convencionais. A Microsoft deixou claro que irá utilizar as vantagens providas pelas senhas e eliminará as desvantagens, tendo como principal objetivo o compromisso com o usuário final e com a segurança. Será que finalmente veremos o fim das senhas? ?

No dia 25/04 a Google anunciou grandes atualizações em relação ao novo Gmail e sua segurança, integração com seus serviços em Cloud e funcionalidades de sua I.A. Uma funcionalidade bem interessante é o novo Confidential Mode. Resumindo a funcionalidade permite você a colocar data de expiração para seus emails e até anular mensagens já enviadas. Como você pode exigir autenticação adicional via mensagem de texto para visualizar um e-mail, também é possível proteger os dados, mesmo que a conta de e-mail de um destinatário tenha sido invadida enquanto a mensagem está ativa. Alguns recursos foram melhorados, como a verificação se um email é ou não malicioso e o fato de poder ver os anexos enviados por um email sem ter que abri-lo: Infelizmente nem todas estas funcionalidades estão disponíveis para todos os usuários, mas as que estão disponíveis podem ser encontradas no novo gmail. Para isto, basta ir do lado direito em cima e trocar para a nova versão (e retorne para a antiga quando quiser): Todas as funcionalidades estão disponíveis apenas para aqueles que pagam pelo G Suite, mas quem sabe mais pra frente não estejam disponíveis para todos, não é mesmo?

No dia 26 de fevereiro o usuário de nick Sai Lay publicou em seu Twitter um cheat sheet sobre segmentação de memória para o Linux : Afinal, o que é um cheat sheet? Basicamente um “guia rápido”, uma “folha de consulta” para possíveis dúvidas que você possa ter sobre o assunto abordado. Este tipo de guia pode abordar diversos assuntos, desde comandos/scripts específicos para pentest até definições rápidas sobre registradores e alinhamento de memória (que é o nosso caso). A quantidade de informações disponíveis em um cheat sheet é enorme, mas não há sentido em ter tanta informação se não entendermos de fato o que é aquilo. Tendo em vista isto detalharemos um pouco mais um ponto em específico deste guia, deixando o resto para a sua curiosidade Que tal darmos uma breve olhada em uma seção? Considere o código abaixo: #include <stdio.h> int main(void){ printf("Isto eh um teste\n"); return 0; } Se utilizarmos o comando readelf --sections test veremos que a seção .data(seção de dados inicializados), por exemplo, tem apenas 16 bytes (em hexa): ... [22] .got PROGBITS 0000000000200fd8 00000fd8 0000000000000028 0000000000000008 WA 0 0 8 [23] .got.plt PROGBITS 0000000000201000 00001000 0000000000000020 0000000000000008 WA 0 0 8 [24] .data PROGBITS 0000000000201020 00001020 0000000000000010 0000000000000000 WA 0 0 8 [25] .bss NOBITS 0000000000201030 00001030 0000000000000008 0000000000000000 WA 0 0 1 … Podemos verificar o que tem nestes bytes com objdump -d -j .data test: test: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... Mas e se nosso código fosse da seguinte forma: #include <stdio.h> int a = 10; int main(void){ printf("Isto eh um teste\n"); return 0; } Note que o tamanho da seção aumentou em 4 bytes, que “coinscidentemente” é o tamanho de uma variável do tipo inteiro na arquitetura onde os testes foram feitos : ... [23] .got.plt PROGBITS 0000000000201000 00001000 0000000000000020 0000000000000008 WA 0 0 8 [24] .data PROGBITS 0000000000201020 00001020 0000000000000014 0000000000000000 WA 0 0 8 [25] .bss NOBITS 0000000000201034 00001034 0000000000000004 0000000000000000 WA 0 0 1 [26] .comment PROGBITS 0000000000000000 00001034 … Se olharmos o que há na seção veremos o seguinte resultado: test: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... 0000000000201030 <a>: 201030: 0a 00 00 00 .... Agora temos um valor de 4 bytes disponível para nossa variável a que possui o valor 0a em hexa (ou seja, 10 como declarado anteriormente). Caso a variável fosse, por exemplo, long long a = 10 o resultado seria: est: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... 0000000000201030 <a>: 201030: 0a 00 00 00 00 00 00 00 .....… 8 bytes disponíveis, exatamente o valor que sizeof(long long) representa nesta arquitetura. Não ficou satisfeito ainda? Você também pode olhar as seções com o gdb(GNU Debugger) utilizando o comando maintenance info sections: ... [22] 0x00201000->0x00201020 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTE---Type <return> to continue, or q <return> to quit--- NTS [23] 0x00201020->0x00201038 at 0x00001020: .data ALLOC LOAD DATA HAS_CONTENTS [24] 0x00201038->0x00201040 at 0x00001038: .bss ALLOC [25] 0x00000000->0x0000001c at 0x00001038: .comment READONLY HAS_CONTENTS ... É extremamente interessante ir a fundo em cheat sheets como este, mais interessante ainda é montar um você mesmo, seja para uso particular ou para disponibilizar para todos. Espera, não entendeu direito os comandos, ordenação dos bytes ou algo desta notícia? Que tal assistir ao curso do CERO? A última aula fala justamente sobre o formato ELF (executáveis Linux) e sua especificação. Agora que sua curiosidade foi instigada, que tal aplicar seus conhecimentos sobre arquitetura de computadores e mostrar pra gente?

Em 2015 foi criado o projeto Kaitai Struct. Mantido até hoje o projeto engloba toda uma estrutura para trabalhar com a ideia de parsing de arquivos, tanto em disco quanto em memória. O segredo disto é a linguagem descritiva criada pelo projeto. O Kaitai utiliza um arquivo de texto com extensão .ksy para definir um formato. Este arquivo, após ser compilado pelo seu próprio compilador (ksc) gera um código em qualquer uma das linguagens aceitas para parsear o formato(CPP/STL, C#, Graphviz, Java, JavaScript, Perl, PHP, Python, Ruby e JSON). Ficou confuso? Aqui está um exemplo de um arquivo nesta linguagem descritiva: meta: id: microsoft_pe title: Microsoft PE (Portable Executable) file format application: Microsoft Windows endian: le ks-version: 0.7 doc-ref: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx seq: - id: mz1 type: mz_placeholder - id: mz2 size: mz1.header_size - 0x40 - id: pe_signature contents: ["PE", 0, 0] - id: coff_hdr type: coff_header - id: optional_hdr type: optional_header size: coff_hdr.size_of_optional_header - id: sections repeat: expr repeat-expr: coff_hdr.number_of_sections type: section enums: pe_format: 0x107: rom_image 0x10b: pe32 0x20b: pe32_plus types: mz_placeholder: seq: - id: magic contents: "MZ" … Neste exemplo o arquivo está descrevendo os campos do formato PE (executáveis Windows). Alguns campos foram omitidos pois a especificação do formato PE é grande. Todos estes campos e suas definições podem ser encontrados na documentação oficial. Segue a definição de alguns campos: id: usado para identificação. doc-ref: usado para indicar a documentação do formato endian: usado para indicar o endianess (ordem dos bytes. Little-Endian no exemplo). seq: usado para indicar uma sequência de atributos e a ordem que serão lidos ou escritos. Sem mais delongas vamos ao que interessa, a prática. O exemplo abaixo usa a versão web do projeto: Para analisar um arquivo PE (que é o nosso exemplo) primeiro devemos ir no lado esquerdo onde há vários tipos de formatos em ksy, selecionar a pasta kaitai.oi/formats/executables e clicar duas vezes em microsoft_pe.ksy: Logo de cara podemos ver o arquivo .ksy, mas ainda não fizemos o parser. Para de fato conseguir analisar o nosso binário precisamos carregá-lo e isto é feito no botão abaixo de “Local Storage” (lugar este onde ficam os arquivos que carregamos). Há três botões, o primeiro cria um arquivo .ksy, o segundo carrega um arquivo seu para análise e o terceiro baixa um arquivo do repositório do KS: Aqui carreguei o Putty.exe (um binário PE) e olha só o resultado: uma árvore ao meio com todos os campos parseados e o dump do arquivo em disco à direita. Se clicarmos duas vezes em algum campo , como, por exemplo, ImageBase, podemos ver sua localização exata no arquivo, no dump: Legal, não é mesmo? Mais legal ainda é o fato dele gerar o código fonte usado para o parser e isso na linguagem que você escolher dentre das suportadas. No caso, escolhi C++: Aqui foram apresentadas apenas algumas funcionalidades deste projeto, mas fica claro o quanto isso é útil tanto para análises quanto para estudos de diversos formatos: executáveis, logs, cabeçalhos de protocolos e até mesmo arquivos .pcap. O Kaitai Struct também funciona em linha de comando em: Linux, Windows e macOS. Caso queira você também pode baixar o código direto do repositório do projeto e trabalhar como quiser, seja para engenharia reversa ou para aprender como programar um parser.

No final de 2015 o programador Mahdi Safsafi decidiu listar todas as instruções da Intel e da AMD e colocar num repositório no github vários conjuntos de instruções, incluindo SSE5 e 3DNow! Estas estão listadas em formato XML. Segundo o autor a ideia principal é justamente essa, ter um repositório com uma lista de fácil parsing, ou seja, simples de ser lida por um script ou programa. A documentação é extremamente simples e de fácil entendimento. Foram usadas algumas notações da própria Intel para indicar, por exemplo, se uma instrução suporta certo modo de operação. Exemplo: V - Supported. I - Not supported. N.E- Indicates an instruction syntax is not encodable in 64-bit mode (it may represent part of a sequence of valid instructions in other modes). Pode ser que essa notícia soe um pouco estranha pra você, que pode se perguntar: Qual seria a utilidade de uma lista parseável de instruções? Um exemplo onde esta lista pode ser útil é num script que pode analisar estes dados e ti prover informações da propria documentação em um piscar de olhos. Para exemplificar isto fiz um código em Python que simplesmente abre o arquivo XML, lê seus campos e imprime seus valores na tela de uma forma -organizada-. Veja: import xml.etree.ElementTree as x tree = x.parse('AZ.xml') root = tree.getroot() for child in root.iter('ins'): attr1 = child.attrib.get('x32m', None) attr2 = child.attrib.get('x64m', None) opc = child.attrib.get('openc', None) m = child.find('mnem').text arg = child.find('args').text dsc = child.find('dscrp').text print '32 bits Mode: ' + format(attr1) print '64 bits Mode: ' + format(attr2) print 'Mnemonic: ' + format(m) print 'Args: ' + format (arg) print 'Openc: ' + format(opc) print 'Description: ' + format(dsc) print '----------------------------' A saída ficaria mais ou menos assim: ... 32 bits Mode:V 64 bits Mode:RVM Mnemonic:VPSRLD Args:ymm1,ymm2,xmm3/m128 Openc:None Description:Shift doublewords in ymm2 right by amount specified in xmm3/m128 while shifting in 0s. ---------------------------- 32 bits Mode:V 64 bits Mode:VMI Mnemonic:VPSRLD Args:ymm1,ymm2,imm8 Openc:None Description:Shift doublewords in ymm2 right by imm8 while shifting in 0s. ---------------------------- 32 bits Mode:V 64 bits Mode:RVM Mnemonic:VPSRLQ Args:ymm1,ymm2,xmm3/m128 Openc:None Description:Shift quadwords in ymm2 right by amount specified in xmm3/m128 while shifting in 0s. ---------------------------- 32 bits Mode:V 64 bits Mode:VMI Mnemonic:VPSRLQ Args:ymm1,ymm2,imm8 Openc:None Description:Shift quadwords in ymm2 right by imm8 while shifting in 0s. ---------------------------- 32 bits Mode:V 64 bits Mode:V Mnemonic:PSUBB Args:mm,mm/m64 Openc:None Description:Subtract packed byte integers in mm/m64 from packed byte integers in mm. ---------------------------- 32 bits Mode:V 64 bits Mode:V Mnemonic:PSUBB Args:xmm1,xmm2/m128 Openc:None Description:Subtract packed byte integers in xmm2/m128 from packed byte integers in xmm1. ---------------------------- 32 bits Mode:V 64 bits Mode:V Mnemonic:PSUBW Args:mm,mm/m64 Openc:None Description:Subtract packed word integers in mm/m64 from packed word integers in mm. ---------------------------- ... Isso me lembrou uma ferramenta escrita pelo Fernando chamada bashacks(mais especificamente a função bh_asminfo), onde a ideia é a mesma. Infelizmente o projeto que contém esta lista foi descontinuado agora no fim de 2017, mas o autor já foi rápido e iniciou um novo chamado opcodesDB, que pelo visto suporta JSON. Já pensou no tanto de coisas que poderíamos fazer com estes bancos de dados parseáveis?