Ataque a Uber – Como se proteger

[tiagotoledo]

Ataque a Uber – Como se proteger

https://tiagobigode.com.br/ataque-a-ube ... -proteger/

Quando pensamos em proteger o usuário, temos que tratar esse tema com a proteção em camadas. Para empresas de grande porte não vejo nenhum motivo do porquê não adicionar essas camadas de segurança em minha humilde opinião fecal.

No caso recente da UBER, pelas informações que vi, teve duas fases. Atacante-01 comprometeu dispositivo e teve acesso a credencial do usuário, atacante colocou a credencial à venda na darkweb. Atacante-02 comprou essa credencial e realizou ataque.


FASE 1
Não é claro ou eu não encontrei informações sobre como o atacante-01 conseguiu comprometer o dispositivo e obteve a credencial. Pensei em alguns cenários:

1.0 – Pode ser ter sido através de e-mail, aquelas campanhas que o atacante envia (phishing) para um mundo de gente, pode ter sido algo direcionado onde o atacante escolhe grupo de usuários e dispara o e-mail (spear-phishing) ou realmente ser direcionado a uma pessoa em específica (whaling).

1.1 – Temos a opção de o atacante tentar roubar a pessoa e ter acesso físico ao equipamento.

1.2 – Ou como já vimos em um seriado, onde o atacante espalha pendrive próximo ao alvo (no caminho do trabalho/casa, metro, carro, forja algum brinde, engenharia social, etc) e torce para usuário achar e usar. Ou quando usuário está em um lugar público e se distrai e o atacante coloca algum pendrive na máquina e infecta o dispositivo.

1.3 – Usuário navegando e clicou onde não devia. 1.4 – Usando algum software/jogo crackeado.

1.5 – Insider. Que pode ser uma pessoa insatisfeita ou chantagem/suborno ou se o próprio usuário vendeu a credencial.

1.6 – Conectar em rede pública (hotéis, vizinho, condomínio, etc).

Pensando em como o atacante poderia obter credencial pensei nesses os cenários, caso tenha mais informações sobre o ataque ou queria compartilhar seu ponto de vista comente aqui ou enviei e-mail/zap.

FASE 2
Atacante-02 comprou a credencial na darkweb e iniciou o ataque.

2.0 – Pelas informações que vi, o atacante-02 tentou acessar a VPN com a credencial, mas o MFA impediu o acesso. Era uma credencial com poucos privilégios, mas permitia acesso à rede. Próximo foi passo foi executar mfa-flooding. Não ficou claro se o usuário aprovou em algum momento ou atacante-02 ligou/mensagem/e-mail para usuário falando que é da equipe de TI/Suporte e pediu para usuário aprovar.

2.1 – Autenticação realizada com sucesso, o atacante-02 tem acesso a rede e com isso começou a vasculhar a rede e encontraram um compartilhamento de rede (esse usuário não deveria ter acesso) com scripts usados para automação. E no script tinha credenciais chumbadas (hard-coded) quer permitia acesso a solução de PAM.


2.2 – Com acesso ao PAM atacante-02 escalou privilégio e teve acesso a diversas ferramentas.

Diante desse cenário, podemos analisar e ver em como podemos proteger o usuário e consequentemente o negócio. Uns dias atrás Bruno Tarasco fez uma dinâmica diante desse cenário onde ele propôs que pensássemos em como a CyberArk poderia ajudar a diminuir a chance de sucesso do ataque. No evento foi pensado somente nas soluções CyberArk, aqui irei sugerir diversas outras soluções/camadas.

Irei separar o artigo em dois, o primeiro (esse), irei simplesmente apontar as soluções baseado na cadeia de ataque. E no outro artigo irei detalhar em como as soluções podem ajudar. Clique aqui para acessar.

—————————————————————————-
No item 1.0: campanhas de conscientização e ferramenta para testar/avaliar/educar o usuário. Inclusive terceiros.

No item 1.1: criptografar dispositivo e ter MFA no login;

No item 1.2: bloquear USB e criar processo para usuários que realmente precisar usar;

No item 1.3: filtro de conteúdo com RBI e CDR;

No item 1.4: NG-AV com EDR;

No item 1.5: Situação complexa. Trabalhar com zero-trust e privilégio mínimo, ter auditoria nos acessos, honeytokens, DLP, acessos condicionais (horário, MFA, ter linha-base) e workflow em aplicações sensíveis. Acesso a VPN é bem sensível (não deveria ser usado) e caso for usar permitir que somente dispositivo confiável conecte. Isso vale para as aplicações SaaS também, só pode acessar através de dispositivo confiável.

No item 1.6: campanhas de conscientização e ferramenta para testar/avaliar/educar o usuário. Inclusive terceiros;

No item 2.0: Usar QR-code como fator de MFA; Não vi informação com relação a horário e dia semana então aplicar o acesso condicional poderia impedir o ataque ou acesso baseado no risco. Permitir somente dispositivos conhecidos e confiáveis conectar na VPN impediria o ataque

No item 2.1: Não usar VPN, podemos usar o ZTNA dependendo da situação. Por que a credencial chumbada no script tem acesso a outras credenciais?! Temos que aplicar o privilégio mínimo e nunca confiar sempre verificar. Para essa situação temos a solução de Credencial Provider da CyberArk para tornar seguro os scripts de automação.

—————————————————————————-
Executar a solução de DNA (Discovery and Audit) da CyberArk vai ser essencial para avaliar o ambiente. E o mais legal é uma ferramenta sem custo nenhum.

E temos outra solução da CyberArk, CEM (Cloud Entitlements Manager), que vai nos ajudar na visibilidade de permissões em acesso na nuvem. De todas as identidades existentes, vamos ter visibilidade das permissões que os usuários têm e quais eles realmente usam. Trabalhando sempre com o privilégio mínimo é uma solução multi-cloud, que é muito comum hoje em dia termos recursos na AWS, GCP e Azure.

Tem um outro artigo que entra em mais detalhes nas proteções: Proteção em camadas – Endpoint – Identidade

Palavras chaves: ataque a uber, MFA, cadeia de ataque, proteção endpoint, proteção em camadas, proteção em profundidade, QR-code, conscientização, ZTNA, DNA, CEM, identidade

ataque a uber, cadeia de ataque, CEM, conscientização, DNA, identidade, mfa, proteção em camadas, proteção em profundidade, proteção endpoint, QR-code, ztna