Pular para o conteúdo principal

“Pense como um Hacker”


PARTE 1
Se você é engenheiro ou desenvolvedor encarregado de criar sistemas embarcados (ou software, dispositivos, redes, etc.), uma de suas maiores prioridades é - ou deveria ser - identificar e minimizar possíveis vulnerabilidades de segurança de dados. Para atingir efetivamente esse objetivo você precisa entender como os sistemas são hackeados e, finalmente, entender como “pensar como um hacker”.

Hackear é sobre explorar vulnerabilidades. Podem ser falhas de design, controles de acesso fracos, configurações incorretas ou muitos outros problemas. Este artigo mostra a mente de um hacker. Como você verá, o processo e a mentalidade deles em encontrar e explorar vulnerabilidades são muito diferentes de como os engenheiros abordam o desenvolvimento do sistema.

O que acontece dentro da mente de um hacker? É um lugar divertido, caótico e extremamente volátil, então traga café (muito) e vamos mergulhar.

Mentalidade Hacker: baseada em uma missão


A diferença mais marcante entre hackers e engenheiros é como eles enfrentam um desafio. Engenheiros (e cientistas) são sistemáticos. Os problemas são primeiro definidos e analisados, um plano (ou hipótese) é formulado e a hipótese é testada. Os resultados são então analisados, quanto aos sucessos e fracassos, e as conclusões são extraídas.

Este é o método científico. Ele serviu bem a humanidade por centenas de anos. Hacking subverte esse processo. Primeiro, não há plano, mas sim uma missão. Planos para um hacker são soltos e flexíveis. Lembre-se, um hacker não está construindo algo que deve passar no teste do tempo. Em vez disso, eles estão invadindo. Eles não precisam satisfazer um gerente ou CEO; eles só precisam completar uma missão.

Onde os engenheiros são sistemáticos, os hackers são pragmáticos e a “reação em cadeia” conduzida em sua metodologia. Existem semelhanças, mas a principal diferença é que os hackers vão, a qualquer custo, cumprir sua missão. Além disso, eles podem descartar resultados que não os ajudam, em vez de ter que explicá-lo aos outros.

Às vezes, isso é descrito como lista vs pensamento de caminho:
  • Cientistas e engenheiros trabalham contra listas de tarefas e devem reportar resultados.
  • Hackers seguem caminhos. Eles continuarão seguindo um caminho até que eles não avancem em sua missão.

Resumindo, os engenheiros pretendem ser minuciosos; os hackers pretendem ser eficazes. Estas podem parecer nuances menores, mas quando colocadas em ação, essas nuances têm implicações significativas.

Padrão Comum: A Cadeia de Morte


Quando um hacker está invadindo um ambiente ou sistema, ele geralmente segue um padrão comum, chamado de cadeia de abate. À medida que o hacker avança através de sistemas e redes, eles buscam níveis mais altos de acesso e autoridade dentro do ambiente (Figura 1). Eventualmente, quando eles têm acesso suficiente, podem roubar os dados que desejam e/ou plantar códigos maliciosos.

hacker
Figura 1: Se você conseguir capturar hackers no início da cadeia de mortes, poderá impedir a ocorrência de um hack.

Os hackers geralmente moram dentro de um ambiente por um longo período: de 100 a 140 dias em média. O Target foi hackeado em 2013, por exemplo, e levou mais de 100 dias para os hackers executarem totalmente o hack. Se você conseguir capturar hackers no início da cadeia de mortes, poderá impedir que um ataque aconteça.

É importante notar que a maioria dos hackers são automatizados e utilizam bots. Embora possamos descrever essas etapas no contexto de uma pessoa real estar realizando, os bots são o que realmente fazem todo o trabalho real.

Pensamento Hacker


Os hackers olham as coisas de maneira diferente. Em particular, eles:
  • Observam o óbvio;
  • Imaginam o pior;
  • Exploram todos os pontos de acesso possíveis;
  • Amam todos tipos de dados;
  • Entendem que os humanos são o elo fraco;
  • Adoram informações obscuras;
  • Encontram e exploram backdoors;
  • Exploraram a indiferença de terceiros;
  • Buscam credenciais;
  • Aproveitam do seu lixo.

Observe o óbvio


É fácil deixar passar uma fraqueza enquanto você está profundamente concentrado em um desenvolvimento. Afaste-se do desenvolvimento para fazer algumas perguntas básicas sobre o seu trabalho. Use a avaliação “Five Whys Deep”:
  • Por que seu produto faz isso?
  • Por que isso é necessário?
  • Por que você projetou dessa maneira?
  • Por que isso é bom?
  • Por que não fazer diferente?

O objetivo deste exercício é identificar as fraquezas óbvias. Um hacker vai notá-las muito mais rápido do que você pensa.

Imagine o pior


Qual é o pior cenário possível? Qual a probabilidade disso acontecer? Os hackers não possuem uma bússola moral. Eles não sentirão compaixão por você quando sua rede ou aplicativos estiverem lutando para se recuperar de um desastre. Como tal, você precisa fazer planos para lidar com esses piores cenários.

No entanto, tenha cuidado para não se enredar nos chamados “cenários zumbis” - isto é, desastres que surgem devido a uma sequência ridícula de eventos sem resposta. A maioria dos filmes de zumbis é baseada nessa premissa.

Explore cada potencial de pontos de acesso


Você deve saber de todas as formas possíveis que qualquer pessoa ou qualquer coisa pode acessar seu sistema. Um hacker muitas vezes, tentará todas elas. Você pode pensar que sua interface Bluetooth é super segura, mas existem dezenas de maneiras de explorar especificamente o Bluetooth que podem torná-las completamente inseguras. Certifique-se de testar agressivamente todas as interfaces, independentemente de quão obscuro você tenha feito isso.

Ame todos os dados


Os hackers adoram dados e alguns tipos mais do que outros. O armazenamento de dados também é uma das maneiras pelas quais os hackers ganham persistência em um ambiente. Você deve analisar os dados do seu sistema:
  • Como os dados são armazenados?
  • Como isso é transmitido?
  • Quem pode acessar os dados?
  • Como esse acesso é monitorado, gerenciado e controlado?
  • Como o acesso é registrado? Para onde vão esses dados?

Entenda que os seres humanos são o elo fraco


Os hackers entendem que os humanos são o elo fraco na segurança de dados. Não apenas somos inconsistentes e não confiáveis, mas somos extremamente suscetíveis à manipulação. Se o seu sistema envolve seres humanos em qualquer nível (o que acontece), então ele tem pontos fracos.

Todos os problemas de segurança da informação geralmente se resumem a fraquezas humanas. Quer desconfiguremos ou codifiquemos mal os aplicativos, os humanos produzem o elo mais fraco. Suponha que os usuários cometam erros, e muitos deles, então dê atenção especial aos pontos de contato humanos.

Ame Informações Técnicas Obscuras


Os hackers adoram informações técnicas obscuras e descobrem um documento aleatório que você colocou no Pastebin anos atrás para usar os dados desse documento no seu sistema. Isso faz parte da diversão de invadir novos sistemas.

Seja cauteloso sobre quais tipos de dados técnicos você libera para o público. Suponha que os hackers vão pegá-lo e analisá-lo. Se você tiver um produto que está sendo desenvolvido em um ambiente aberto, seja mais diligente ao projetar componentes e recursos de maneira segura.

Encontre e explore suas backdoors


Muitos hackers tiveram seu primeiro gostinho de hackear do filme Wargames nos anos 80. Há uma ótima cena no meio do filme em que um cientista da computação repreende seu colega nerd por pensar em backdoors para sistemas de computador como segredos: Senhor Cabeça de batata! Portas traseiras não são segredos!

Suas palavras são tão verdadeiras hoje como eram então. Backdoors em aplicativos ou dispositivos são comuns e os hackers irão procurá-las. É uma das técnicas mais antigas e confiáveis ​​para invadir um sistema. Funcionou em Wargames, e ainda funciona hoje.

Explore a indiferença de terceiros


Embora você possa se preocupar profundamente com a segurança do seu sistema, seus fornecedores ou parceiros têm o mesmo nível de preocupação? Os hackers geralmente segmentam componentes de terceiros porque podem atacar um amplo conjunto de alvos com uma única técnica. Heartbleed foi um exemplo perfeito do perigo de componentes inseguros de terceiros. Heartbleed foi uma falha na implementação do OpenSSL. O OpenSSL está dentro de milhões de produtos. Isso significa que uma vulnerabilidade deixou milhões (provavelmente bilhões) de dispositivos vulneráveis ​​a ataques.

Se você integrar um componente de terceiros em seu sistema, você herdará todos os pontos fracos desse componente. Embora o produto possa pertencer a outra pessoa, você será responsável por sua segurança.

Busque credenciais


As contas de usuários legítimas são basicamente o que os hackers querem. Depois de terem credenciais, os hackers podem escalar seus privilégios e, em seguida, percorrer o sistema. Além disso, o uso de credenciais legítimas geralmente não gera alarmes.

Embora você possa não conseguir proteger as credenciais do usuário o tempo todo (pois elas estão nas mãos de humanos), você ainda pode impedir que essas credenciais sejam usadas de maneira maliciosa. Isso começa com a implementação de direitos de privilégios mínimos, ou seja, os usuários nunca devem ter mais acesso do que precisam. Além disso, você deve testar agressivamente os sistemas contra ataques de escalonamento de privilégios.

Recolha o seu lixo


Seu sistema é parte de um todo maior? Poderia cegar uma parte do sistema e deixar outras partes abertas para ataque? Que tal alimentar seus dados falsos do sistema? Foi assim que o malware Stuxnet funcionou. Alimentava informações falsas a sistemas de controle industrial e os sobrecarregava. Se um hacker quiser roubar dados de você, ou interromper as operações, pode ser tão fácil quanto sobrecarregar seu sistema com muito tráfego de rede.

Ataques de negação de serviço são difíceis de serem interrompidos. Ao projetar seu sistema, você deve considerar como ele poderia ser potencialmente sobrecarregado e criar mecanismos para parar ou ignorar quantidades esmagadoras de informações. Além disso, é importante sempre validar que os dados enviados ao seu sistema são provenientes de uma fonte confiável.

Conclusão


Como engenheiro de projeto, identificar e minimizar possíveis vulnerabilidades de segurança de dados são os principais objetivos. Os hackers abordam seu trabalho de maneira muito diferente dos engenheiros; em vez de adotar uma abordagem sistemática, eles preferem uma abordagem de cadeia de eliminações em que procuram, de forma incremental e persistente, vulnerabilidades a serem exploradas.

“Pensar como um hacker” exige que você analise os sistemas projetados de maneira diferente. Parte disso significa entender os aspectos técnicos das vulnerabilidades e soluções; no entanto, uma parte maior requer observar o óbvio, entender os erros humanos e a indiferença, e entender o que os hackers buscam e as pistas que eles usam.

Artigo escrito originalmente por Andrew Plato para Mouser Electronics: “Think Like a Hacker” Part 1: Mindset, Kill Chain, and MoreTraduzido por Equipe Embarcados.
PARTE 2

No artigo “Pense como um Hacker” Parte 1, exploramos a mente de um hacker, a abordagem de cadeia de morte, pistas e vulnerabilidades que ele usa para explorar sistemas. Na parte 2, veremos as medidas tangíveis que você pode adotar para melhorar seus processos de desenvolvimento e, ao mesmo tempo, minimizar os riscos nos sistemas criados por você. No final deste artigo, você será desafiado a:
  • Realize uma avaliação de risco;
  • Integre a segurança ao seu ciclo de vida de desenvolvimento;
  • Teste de forma agressiva;
  • Escolha agilidade em vez de força;
  • Mantenha sempre limpo;
  • Coloque na nuvem.

Realize uma avaliação de risco


Uma avaliação de risco abrangente de todo o seu ambiente, incluindo práticas de desenvolvimento, é o primeiro passo. Os documentos do NIST 800-53 descrevem uma abordagem de avaliação de risco que você pode usar. Se o NIST for muito esotérico, você poderá tentar várias abordagens do setor. Na Anitian, usamos nossa abordagem RiskNow®, que mescla entrevistas com avaliações técnicas.

Em geral, use uma avaliação de risco para orientar seus esforços de segurança. A intenção é se concentrar nas áreas de seu(s) sistema(s) que apresentam mais ameaças ou maiores riscos.

Integre a segurança em seu ciclo de vida de desenvolvimento


Você não pode esperar para proteger um sistema, uma vez que é projetado ou construído. Em vez disso, a segurança deve ser integrada em todas as dimensões do ciclo de vida do desenvolvimento. Para conseguir isso, você deve:
  • Separe os ambientes de desenvolvimento, teste e produção.
  • Crie e siga um processo formal de controle de mudanças.
  • Armazene o código em um repositório seguro, sem acesso compartilhado.
  • Use autenticação multi-fator para todo o acesso ao código de desenvolvimento ou projetos.
  • Realize revisões de código (ou testes de segurança) de qualquer componente de terceiros em seu sistema.
  • Exija que todos os desenvolvedores participem de seminários anuais de treinamento em segurança.
  • Use padrões de codificação seguros, como MISRA C.

Teste de forma agressiva


Um dos itens mais importantes ao integrar ao seu desenvolvimento é o teste de segurança. Teste em todas as fases:
  • Fase de design: conduza revisões de segurança de sua arquitetura e componentes de terceiros.
  • Fase de desenvolvimento: Varredura de código para vulnerabilidades à medida que é registrada.
  • Fase de teste: Realize testes de penetração ao vivo de sistemas implantados.
  • Produção: ativamente hackear sistemas em um ambiente ao vivo.

Escolha agilidade em vez de força


Você nunca construirá um muro alto o suficiente para parar todos os hackers, então se concentre em tornar seus sistemas mais ágeis do que difíceis. Se o seu sistema sofreu ataque:
  • Com que rapidez você pode atualizá-lo?
  • Como você saberia que estava sendo atacado?
  • Quais seriam as repercussões de um ataque?
  • Quem lidaria com um ataque?
  • O que aconteceria se a sua criptografia (se você usá-la) fosse quebrada?
  • Existem outras tecnologias, como firewalls, que poderiam mitigar um ataque?

Mantenha sempre limpo


Para transformar fraquezas potenciais em pontos fortes, siga os seguintes passos:
  • Valide os dados sempre que aceitá-los ou enviá-los.
  • Não permita acesso desnecessário - restringindo todo o acesso apenas ao que é absolutamente essencial.
  • Impeça que aplicativos não confiáveis ​​sejam executados.
  • Limite rigorosamente todo o acesso remoto.
  • Criptografar todos os dados: em repouso e em trânsito.
  • Realize uma verificação de integridade na inicialização.
  • Evite segredos do sistema e divida os componentes do sistema.
  • Remova os recursos de depuração (se possível).
  • Por que o produto faz isso? Se não houver uma boa razão para um recurso, elimine-o.

Coloque na nuvem


Há uma razão para que 97% das empresas tenham parte ou toda a sua infraestrutura na nuvem. A nuvem permite agilidade, flexibilidade e maior segurança. Use a nuvem para reunir logs, enviar atualizações ou publicar APIs.

No entanto, o maior benefício da nuvem é a automação. Você pode construir ambientes inteiros como código e destruí-los e recriá-los por capricho. Isso permite a infraestrutura descartável - isto é, sistemas que podem ser destruídos e recriados a partir de boas imagens conhecidas. Automatizar essa destruição e recriação tem enormes benefícios de segurança. É impossível para um hacker estabelecer persistência em um ambiente se o ambiente desaparecer toda semana. Infraestrutura descartável é um estado final ideal para qualquer sistema complexo.

Conclusão


Pensar como um hacker exige que você olhe para os sistemas projetados de maneira diferente, incluindo observar o óbvio, entender o erro humano e a indiferença, e entender o que um hacker procura e as pistas que ele usa. Os engenheiros de projeto podem e devem tomar medidas para melhorar os processos de desenvolvimento e minimizar os riscos no projeto de sistemas. Realizar avaliações de risco, integrar segurança ao processo de desenvolvimento, testar, desenvolver infraestrutura descartável automatizada e usar a nuvem são etapas fundamentais que aperfeiçoarão seus processos de desenvolvimento e minimizarão os riscos nos sistemas projetados.

Artigo escrito originalmente por Andrew Plato para Mouser Electronics: "Think Like a Hacker" Part 2: Building Secure Systems.

Traduzido por Equipe Embarcados.

Comentários

Postagens mais visitadas deste blog

Dica de configuração do CURA usando PLA

Essas são as configurações que eu fiz em minha impressora ANET A8 para imprimir no PLA.

Criei 2 perfis, um com média qualidade (0,2mm) e outro com alta qualidade (0,1mm).

Média Qualidade



 Alta Qualidade

No filme o Livro de Eli, o personagem principal é cego?

Acho que o filme vale a pena, não só pela excelente fotografia, mas por alguns outros pontos. Eli pode ser cego sim. Ainda vou assistir mais uma vez o filme para confirmar, mas alguns detalhes são importantes para serem notados:
1) Cegos geralmente usam óculos de sol, portanto o fato de todo mundo usar, esconde um pouco o fato de ele usar.
2) Nem todos os cegos tem olhos do mesmo jeito. Se ele não for completamente cego, ele é o suficiente para ter que aprender Braile
3) Ele não olha para o sol e sim o sente em sua face.
4) Ele não encherga que a bateria de seu iPod está acabando? pq fica batendo nele?
5) Vai para o escuro lutar com os primeiros bandidos. Uma tremenda vantagem para quem é cego. Técnica muito usada pelo super-herói Demolidor.
6) Só atira qdo ouve de onde vem o tiro. Se ninguém atirar ele não revida.
7) Ele mata um passaro pelo som. É forçado ele acertar tudo, mas isso é para deixar a gente confuso.
Pois bem, só assisti uma vez, mas vou confirmar isso tudo na segunda. Acho qu…

Suporte para Notebook com tubos de PVC

Fonte: http://tecnicolinux.blogspot.com.br