Hacker: "Pense como um Hacker" - Parte 1 - Embarcados
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 do Hacker: 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.
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.
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 você projetou dessa maneira?
O objetivo deste exercício é identificar as fraquezas óbvias. Um hacker vai notá-las muito mais rápido do que você pensa.
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 por um hacker
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 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.
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.
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 More. Traduzido por Equipe Embarcados.