Ir para conteúdo

  • Notícias

    Mostrar todas categorias
    • Leandro Fróes
      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 primeiro de Abril de 2018 a Cloudflare, respeitada empresa fornecedora de serviços para quem mantém servidores na Internet, lançou um novo servidor DNS público acessível mundialmente, o 1.1.1.1 e isso tem dado o que falar.
      Desempenho
      Na lista do DNSPerf o servidor já consta em primeiro lugar, desde seu lançamento. Claro que ainda é cedo para dizer pois o número de usuários deve aumentar nos próximos dias, o que deve exigir cada vez mais da infraestrutura deste novo servidor DNS.
      O pesquisador Nykolas Z publicou alguns testes, que apontaram diferentes resultados dependendo da região de origem das requisições DNS.  Da única cidade brasileira testada, São Paulo, o tempo de resposta do 1.1.1.1 foi de apenas 2.71 milissegundos, aproximadamente 75% mais rápido que o segundo colocado no teste. Veja os resultados:
      CloudFlare 2.71 ms CleanBrowsing 12.00 ms Google_DNS (o famoso 8.8.8.8) 29.71 ms Norton_DNS 114.71 ms Quad9 114.71 ms Comodo_DNS 129.85 ms OpenDNS 213.14 ms Yandex_DNS 238.14 ms No Brasil os usuários utilizam por padrão o servidor DNS fornecido por seus provedores (NET Virtua, Oi Velox, Speedy, BRT Telecom, etc), que são hospedados tem território nacional e, em teoria, deveriam fornecer uma resposta mais rápida. No entanto, não foi o que encontrei nos meus testes com o DNS da NET 181.213.132.2, que se mostrou quase 5 vezes mais lento que o novo 1.1.1.1 da Cloudflare, como mostra a imagem abaixo:

      Claro que o meu teste foi muito simples, mas o repeti várias vezes com domínios diferentes e os resultados foram similares. Se você é cliente de outro provedor, faz o teste e comenta aqui o que achou.
      Configuração
      Já bateu a vontade de configurá-lo no seu ambiente? Calma, vamos analisar as opções: se você utiliza um modem ADSL ou à cabo, pode querer configurar diretamente lá. Neste caso você vai precisar buscar no manual do seu modem a configuração normalmente chamada de WAN (Wide Area Network) e fixar os seguintes endereços DNS (se houver os campos abaixo):
      Servidor DNS primário (IPv4): 1.1.1.1
      Servidor DNS secundário (IPv4): 1.0.0.1
      Servidor DNS primário (IPv6): 2606:4700:4700::1111
      Servidor DNS secundário (IPv6): 2606:4700:4700::1001
      Você também pode configurar o DNS do Google por exemplo (8.8.8.8) para ser o secundário. Assim, se houver algum problema com a infraestrutura do 1.1.1.1, você tem uma redundância de um servidor de outra empresa completamente diferente. Fica a seu critério.
      Pode ser que você encontre um desafio na configuração do modem. No meu caso aqui com um modem vagabundo da HUMAX fornecido pela NET eu só consigo fixar o DNS se fixar também o IP da rede WAN, o que naturalmente não posso fazer, já que meu plano não contempla um IP fixo. 

      Infelizmente fiquei sem opção e tive que configurar o DNS em todos os meus dispositivos manualmente (as instruções variam para cada sistema operacional mas você está convidado a pedir ajuda em nosso fórum se precisar).
      Segurança
      DNS em si nunca foi seguro, mas o 1.1.1.1 oferece duas opções para encriptar as consultas e respostas: DNS sobre HTTPS ou sobre TLS, apesar de poucos clientes suportarem tais recursos por enquanto. Quanto à privacidade, a Cloudflare garante que as consultas DNS nunca são registradas e os outros logs do servidor são excluídos a cada 24 horas. Num blogpost sobre o assunto, o fundador e CEO da Cloudflare Matthew Prince disse inclusive que contratou a KPMG, uma das maiores empresas de auditoria do mundo, para auditar os servidores afim de garantir que nenhuma informação fica registrada em seus servidores.
      O 1.1.1.1 protege contra sites maliciosos?
      Não. Diferentemente de servidores DNS como o OpenDNS (208.67.222.222 e 208.67.220.220) ou o Norton ConnectSafe, que oferece até modalidades de bloqueio que incluem pornografia, o 1.1.1.1 da Cloudflare não faz nenhum tipo de bloqueio, assim como o famoso 8.8.8.8 do Google.
      Recomendação
      Minha recomendação varia de acordo com o tipo de usuário.
      Para técnicos e analistas que precisam acessar sites maliciosos, recomendo testar o 1.1.1.1.
      Para usuários finais, recomendo escolher entre OpenDNS ou Norton ConnectSafe. Não são tão rápidos quando o 1.1.1.1, mas oferecem um nível básico de proteção contra ameaças.
      Para administradores de rede, uma solução interessante é o projeto brasileiro CleanDNS, que dá maior controle do que bloquear para os usuários, oferece cache e tudo mais.
      Não recomendo a ninguém utilizar os DNS nativos das operadoras. Além de lentos em sua maioria, há casos de comprometimento que levaram clientes a acessarem sites maliciosos. Todo cuidado é pouco! 
    • O famoso site alemão de crakmes (programas feitos especialmente para treinarmos engenharia reversa) saiu do ar há algum tempo. Alguns arquivos foram salvos e um espelho foi criado em crackmes.cf, mas não satisfeito, s4r criou o crackmes.one com a mesma ideia. O site já reúne aproximadamente 50 crackmes novos além de milhares importados do crackmes.de. Há crackmes escritos em várias linguagens como Java, C++, Delphi e VB. É diversão garantida.
       
      Vale lembrar que oferecemos aqui gratuitamente, bancado por nossos apoiadores, o CERO (Curso de Engenharia Reversa Online) totalmente do zero, que pode te ajudar caso você seja iniciante em engenharia reversa e em crackmes. Boa sorte e happy hacking!
    • Uma engenheira de software de Reykjavík, na Islândia, não curtiu muito quando o Twitter encerrou o suporte ao app oficial para macOS. O limite de caracteres dos posts na plataforma foi dobrado, de 140 para 280 caracteres em Setembro do ano passado, mas o app para macOS não recebeu essa atualização. Foi então que Alva fez engenharia reversa no aplicativo do Twitter e simplesmente mudou o limite imposto pelo software de 140 caracteres para 240. Como a plataforma já aceitava os tweets maiores, ela só precisava contornar este limite no software mesmo. O patch foi feito com um disassembler chamado Hopper, que Alva diz ser seu preferido para disassemblar binários escritos em Objective C, a linguagem padrão para aplicativos Apple. Mais detalhes você encontra no blogpost dela, em Inglês: Reclaim your abandonware.
      Nós aqui do Mente Binária ficamos muito felizes de ver a engenharia reversa sendo utilizada com fins criativos. Parabéns, Alva! 
×
×
  • Criar Novo...