Artigos

sysblog

2014, o ano que mudou a forma como encaramos o tema da privacidade dos dados?

Parte I


 

2014, o ano que mudou a forma como encaramos o tema da privacidade dos dados?

por Artur D’Assumpção (adassumpcao@sysvalue.com), 17 de Dezembro de 2014

O ano de 2014 será certamente recordado como um dos mais difíceis até à data no que diz respeito à segurança da informação e quebra de privacidade.

Este foi um ano complicado, de onde se destacam diversas falhas de segurança gravíssimas (possivelmente das mais severas registadas até à data) com enorme impacto na segurança das organizações em geral, que obrigou a uma resposta global e urgente às falhas identificadas, sem exceção. – http://www.incapsula.com/blog/2014-mega-vulnerabilities.html

Com igual destaque, verificou-se também um anormal número de ataques a organizações de elevado perfil, que viram roubados e publicados na Internet milhões de registos de dados pessoais, informação de negócio confidencial/sensível e até mesmo propriedade intelectual, resultando em elevados prejuízos financeiros e reputacionais, não só para as organizações em causa, mas também para os seus clientes. – http://www.zdnet.com/pictures/2014-in-security-the-biggest-hacks-leaks-and-data-breaches/

Por fim, testemunhou-se ainda uma exposição mediática ímpar acerca destes casos, que foi certamente uma agravante para os impactos que se viriam a registar.

As estatísticas são alarmantes…

Segundo o Data Breach Report (Dezembro de 2014) publicado pelo Identity Theft Resource Center (http://www.idtheftcenter.org/images/breach/DataBreachReports_2014.pdf), 2014 foi um ano que viu agravado de forma significativa, tanto o número de quebras de segurança que levaram à perda de privacidade de informação de natureza pessoal (PI), bem como o volume de registos perdidos para estes ataques. *Este estudo apenas contempla o universo de organizações que comunicam estes dados ao ITRC.  foto1

Embora se tenha observado um acréscimo preocupante de quebras de segurança e perda de informação em todas as categorias analisadas, é a categoria de Business que mais sofreu, com um total de 64,7 milhões de registos perdidos, perfazendo 79% do total de registos perdidos durante 2014.

Na tabela abaixo é possível verificar qual foi a média de registos perdidos por cada quebra de segurança registada:

foto2

É de salientar que o volume elevado de registos perdidos pelas organizações da categoria Business e Government/Military, por cada quebra de segurança registada, são nomeadamente 10x e 3x superiores às restantes categorias. Estes valores revelam que um ataque a estas organizações resulta geralmente num maior impacto.

Destaca-se ainda o aumento significativo (42%) de ataques a organizações da categoria Medical/Healthcare com um impacto preocupante no que toca à divulgação de dados pessoais sensíveis de natureza médica (PHI – Personal Health Information). Prevê-se que estes casos se agravem em 2015. – http://www.modernhealthcare.com/article/20141201/BLOG/312019996/coming-in-2015-even-more-healthcare-data-breaches

Enquanto o estudo do ITRC apenas abrange as quebras de segurança que resultaram concretamente na perda de informação de natureza pessoal (PI), já o Breach Level Index (http://www.breachlevelindex.com/) registou só no 3º Trimestre de 2014 um volume de quebras de segurança record, tendo sido perdidos ou roubados cerca de 183 milhões de registos de natureza diversa (ex.: dados pessoais, informação pessoal/empresarial, dados privados/confidenciais, propriedade intelectual, dados financeiros/bancários, contas de serviço, etc.). – http://www.breachlevelindex.com/img/Breach-Level-Index-Infographic-Q32014.jpg

É curioso verificar que, segundo o relatório produzido pelo Breach Level Index para o 3º Trimestre, apenas 1% dos casos registados afirmaram usar mecanismos de confidencialidade/cifra forte dos dados armazenados e/ou sistemas de gestão de chaves privadas e autenticação forte. Nestes casos as “quebras de segurança” registadas resultaram na perda de dados inúteis para os atacantes. – http://www.breachlevelindex.com/pdf/Breach-Level-Index-Report-Q32014.pdf

Será a estratégia atual a mais adequada? O que se pode esperar no futuro…

O alarmante número de incidentes de quebra de segurança e consequente perda de privacidade da informação, bem como a perspetiva futura de agravamento deste cenário, tem colocado em discussão se a estratégia atual será a mais adequada.

Algumas previsões para 2015:

Até à data a estratégia de segurança da informação adotada pelas organizações tem-se centrado na segurança perimetral (e rede). Esta abordagem foca-se na implementação de meios e processos que dificultem os ataques à infraestrutura que se encontra exposta ao público, numa tentativa de os conter à entrada, e evitar que estes se propaguem aos sistemas internos (mais críticos), conduzindo assim à perda de informação. No entanto, uma vez comprometida esta primeira linha de defesa, a realidade é que são poucas as medidas implementadas que evitem este desfecho.

As estatísticas mostram que definitivamente a estratégia não está a resultar.

Por este motivo, a discussão atual prende-se com o facto de que na realidade as quebras de segurança são inevitáveis e que embora a segurança perimetral continue a ser decisiva na proteção da infraestrutura e ativos da organização, os esforços devem reposicionar-se na proteção da própria informação.

“Move from breach avoidance to breach acceptance”

Esta abordagem permite reconcentrar os esforços na proteção da informação, investindo em mecanismos de segurança e adotando best-practices que assegurem a sua privacidade e confidencialidade, mesmo considerando o pior cenário em que o seu acesso seja totalmente comprometido. – http://www.rsaconference.com/writable/presentations/file_upload/spo-w10-evolving-from-breach-prevention-to-breach-acceptance-to-securing-the-breach.pdf

Embora não exista uma solução ideal, parte da futura estratégia de uma organização para proteção da informação passará certamente pela implementação de 3 iniciativas fundamentais:

  1. Cifrar toda a informação sensível, esteja esta armazenada de forma fixa ou em trânsito (dispositivos móveis);
  2. Armazenar e gerir de forma segura as chaves criptográficas;
  3. Implementar mecanismos fortes de autenticação de utilizadores e controlo de acesso à informação;

foto3

Ao promover estas iniciativas na infraestrutura IT, uma organização estará efetivamente a preparar-se para uma eventual quebra de segurança, ao mesmo tempo evitando que se torne vítima desta, salvaguardando preventivamente a segurança dos dados. – http://www2.safenet-inc.com/securethebreach/downloads/secure_the_breach_manifesto.pdf

Parte II


 

As vulnerabilidades que marcaram 2014

De entre as várias vulnerabilidades que assolaram 2014, há 4 que merecem especial destaque, tanto pela sua severidade, universo de sistemas afetados, risco e impacto, são elas: – Heartbleed, Shellshock, POODLE e BadUSB. – http://www.incapsula.com/blog/2014-mega-vulnerabilities.html

Heartbleed

foto4

O Heartbleed (http://heartbleed.com/) foi sem dúvida a mais grave vulnerabilidade de 2014. Esta consiste numa vulnerabilidade descoberta na famosa biblioteca criptográfica OpenSSL (https://www.openssl.org/), permitindo a obtenção de dados protegidos residentes em memória (ex.: credenciais de acesso, chaves privadas e certificados, etc.) durante o processo normal de funcionamento do protocolo SSL/TLS.

– O protocolo SSL/TLS consiste numa camada de segurança adicional que permite dotar as comunicações de dados de segurança e privacidade, recorrendo para tal a mecanismos criptográficos.

Esta vulnerabilidade expõe, entre outros dados, credenciais de autenticação e certificados digitais, comprometendo toda a segurança no acesso (autenticação e confidencialidade) a serviços e sistemas. – Detalhes técnicos da vulnerabilidade em http://www.theregister.co.uk/2014/04/09/heartbleed_explained/)

foto5

A gravidade desta vulnerabilidade prende-se com a facilidade de exploração e com o facto de que a implementação do protocolo SSL/TLS pela biblioteca OpenSSL, ser a mais adotada de entre os variados protocolos seguros existentes hoje em dia na Internet. Alguns protocolos populares afetados são: – HTTPS, Wi-Fi 802.11, VPN SSL e muitos outros que recorram a esta implementação.

Muitos gigantes da Internet foram um alvo em massa da exploração desta vulnerabilidade, afetando e comprometendo milhões de acessos por todo o mundo.

foto6

Embora muita da atenção se tenha focado nas grandes organizações, é com um elevado grau de certeza que se pode afirmar que foram poucas as organizações a escapar a esta vulnerabilidade, bem como ao seu impacto. – http://securityaffairs.co/wordpress/23878/intelligence/statistics-impact-heartbleed.html

Shellshock

foto7

O Shellschock é uma vulnerabilidade que permite explorar uma falha de validação (parsing) de argumentos na aplicação BASH (processador de comandos/command shell http://en.wikipedia.org/wiki/Bash_(Unix_shell)) presente nos sistemas operativos Unix, Linux e OS X.  Esta vulnerabilidade permite a manipulação de variáveis de ambiente e execução de comandos arbitrários no sistema. – Detalhes técnicos da vulnerabilidade em http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

Sendo a BASH uma componente subjacente a grande parte das aplicações que correm no sistema operativo, por intermédio destas torna-se possível a injeção de comandos arbitrários e a sua consequente execução no sistema pela BASH. Um exemplo prático da gravidade desta vulnerabilidade é o facto de ser possível explorá-la através do Apache (o servidor HTTP mais popular na internet), permitindo a execução remota de comandos arbitrários no sistema. Existem muitos outros exemplos, como por exemplo aplicações Web.

O Shellshock é uma vulnerabilidade cuja severidade e impacto se equipara ao Heartbleed, sendo que em certas situações pode até ser considerada mais gravosa, já que não requer nenhum tipo de autenticação para ser explorada e permite a execução remota de comandos arbitrários (o que não acontece com Heartbleed) – http://www.darkreading.com/shellshock-bash-bug-impacts-basically-everything-exploits-appear-in-wild/d/d-id/1316064. Uma ligeira maior complexidade na exploração da vulnerabilidade é o único fator que talvez permita ao Heartbleed manter o pódio.

POODLE

foto8

A vulnerabilidade POODLE tira partido das versões atuais do protocolo SSL/TLS manterem a retro compatibilidade com a versão 3 do SSL. Esta versão legacy, já com cerca de 18 anos de existência, é conhecida pelas falhas criptográficas existentes que permitem atacar a cifra e violar a confidencialidade dos dados. – http://arstechnica.com/security/2014/10/ssl-broken-again-in-poodle-attack/

Através da manipulação da negociação do protocolo SSL/TLS implementada em alguns web browsers é possível, com um ataque do tipo man-in-the-middle (http://en.wikipedia.org/wiki/Man-in-the-middle_attack), forçar o uso da versão 3 do protocolo, expondo a segurança da comunicação à já conhecida fragilidade da cifra. Atacando a cifra nas comunicações HTTPS, torna-se assim possível o acesso em claro a Cookies “seguros” ou outros tokens de autenticação, permitindo o ataque de roubo de sessão/session hijack a aplicações web. – Detalhes técnicos da vulnerabilidade https://www.openssl.org/~bodo/ssl-poodle.pdf

Esta vulnerabilidade não é tão grave (quando comparada ao Heartbleed e Shellshock) devido a um vetor de ataque que requer uma maior complexidade por parte do atacante, bem como ao facto do universo de browsers/servidores web vulneráveis ser menor. No entanto, para aqueles vulneráveis o impacto de um ataque pode ser bastante elevado.

BadUSB

O BadUSB representa uma recente família de ataques com potencial devastador para a segurança da informação. Esta baseia-se numa falha descoberta na arquitetura do hardware dos dispositivos USB e que afeta todos os dispositivos fabricados até á data, sem exceção. – http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/

Esta vulnerabilidade explora uma fragilidade na arquitetura do hardware USB que permite reprogramar o micro-controlador USB. É assim possível injetar código malicioso no firmware e transformar qualquer dispositivo USB num dispositivo malicioso, que é infetado e infecta o sistema das vítimas de forma totalmente encoberta. – https://srlabs.de/badusb/ e https://srlabs.de/blog/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf

A gravidade desta vulnerabilidade prende-se com a exploração de um novo vetor de ataque e infeção extremamente simples e eficaz, o seu potencial devastador, a quantidade de dispositivos vulneráveis existentes que podem ser alvo e portadores do código malicioso, e pelo simples facto de não haver qualquer solução à data para o problema.

Os ataques que marcaram 2014

Como referido, o ano de 2014 foi realmente ímpar no que diz respeito à quantidade de organizações de elevado perfil que foram alvo de ataques com um impacto sem precedentes, tendo milhões de dados pessoais/privados entre outras informações confidenciais sido perdidos ou roubados. – http://breachlevelindex.com/.

foto9

http://www.breachlevelindex.com/img/Breach-Level-Index-Infographic-Q32014.jpg

Embora  não seja possível elencar neste artigo todos os casos mais graves (são mesmo muitos), escolhemos alguns que, devido à dimensão/impacto do ataque, o perfil da entidade/organização atacada e ao elevado volume e natureza dos dados perdidos merecem especial destaque.

Mais informações de outros ataques mediáticos em:

Sony Pictures Entertainment (Novembro/Dezembro 2014)

A Sony Pictures Entertainment representa o mais recente ataque a uma organização de alto perfil que ainda está a chocar a comunidade e a gerar muita controvérsia. – http://www.huffingtonpost.com/creditsesamecom/why-the-sony-hack-could-be-a-game-changer_b_6335082.html

A totalidade dos contornos ainda está por apurar, mas todos os dias conhecem-se novos factos e já é possível prever um impacto financeiro e reputacional sem precedentes.

Do que se sabe a respeito do ataque (http://www.independent.co.uk/arts-entertainment/films/news/sony-hack-timeline-whats-happened–and-who-has-it-affected-so-far-9931385.html), o nível de intrusão é tão grave que consegue colocar a organização numa situação bastante complicada.

Segundo o FBI, o Malware usado para invadir a rede da Sony é tão sofisticado que não seria detetado por 90% das soluções anti-malware no mercado. – http://variety.com/2014/biz/news/fbi-official-malware-in-sony-attack-would-have-gotten-past-90-of-cybersecurity-defenses-1201376529/

Os prejuízos conhecidos até à data vão desde:

  • Mais de 100TB de informação interna, confidencial e sensível roubada, e que tem vindo a ser publicada aos poucos na Internet;
  • Publicados filmes e guiões de filmes que ainda não foram lançados no mercado;
  • Publicados e-mails que comprometem altos funcionários da Sony nas relações com colaboradores, atores e mesmo representantes do governo dos EUA (ex: Barack Obama);
  • Mais de 32 mil emails do CEO da Sony com dados confidenciais foram publicados (ex.: registos financeiros, receitas, estratégias de negócio, etc.)
  • Informação pessoal e confidencial dos colaboradores revelada (ex: salários, contratos, identificação pessoal, registos médicos, etc.);
  • Ameaças aos colaboradores e à família (revelar informação comprometedora).
  • Milhares de acessos e passwords publicados
  • Comprometidos Certificados Digitais da SONY que já permitiram aos atacantes assinar digitalmente Malware que é identificado pela Microsoft, como sendo de confiança.
  • E mais…

Este caso e novos desenvolvimentos podem ser acompanhados aqui:

http://deadline.com/2014/12/sony-hack-timeline-any-pascal-the-interview-north-korea-1201325501/

 

JPMorgan Chase (Agosto 2014)

O ataque ao JPMorgan Chase fica para história como um dos maiores ataques a uma instituição bancária, onde mais de 83 milhões de contas pessoais/negócio (banca online), e informação pessoal foram roubados, e ainda hoje se sentem as repercussões. http://dealbook.nytimes.com/2014/10/02/jpmorgan-discovers-further-cyber-security-issues/?_php=true&_type=blogs&_r=1

 

Ebay (Maio de 2014)

O ataque à infraestrutura do Ebay foi o maior que esta registou até à data, comprometendo bases de dados e conduzindo à perda de mais de 145 milhões de contas de utilizador e respetivos dados pessoais, informação tal que expõe os utilizadores a potenciais situações de fraude e roubo de identidade.

Segundo as análises forenses o ataque inicial partiu do comprometimento das contas de 3 funcionários do Ebay. A partir destes acessos foi possível posteriormente comprometer as bases de dados principais de utilizadores que continham toda a informação armazenada em claro (não cifrada). – http://www.reuters.com/article/2014/05/23/us-ebay-cybercrime-idUSBREA4M0PH20140523

iCloud (Agosto 2014)

O ataque ao iCloud é um exemplo prático de um ataque com uma expressão bastante reduzida (apenas umas centenas de utilizadores do serviço foram afetados) e que obteve uma grande cobertura mediática a nível mundial devido aos perfil público dos utilizadores lesados, causando danos reputacionais elevados à Apple, em particular ao serviço iCloud.

Este ataque ficou conhecido por “Celebrity Nude Hack” e afetou várias personalidades da vida publica norte americana (na sua maioria atrizes de Hollywood e vários artistas da indústria musical) que viram as suas vidas privadas expostas com a publicação de várias fotografias íntimas. – http://www.theverge.com/2014/9/1/6092089/nude-celebrity-hack

Suspeita-se que este ataque foi possível através de uma vulnerabilidade do iCloud (Find My iPhone App) que permitiu um ataque de brute-force (http://en.wikipedia.org/wiki/Brute-force_attack) ao serviço do iCloud. Esta vulnerabilidade associada ao uso de passwords fracas por parte dos utilizadores, permitiu o acesso a backups integrais do iPhone e à recuperação de fotografias íntimas que até já teriam sido apagadas dos iPhones dos próprios autores, e que apenas se encontravam armazenadas no iCloud. – http://time.com/3247717/jennifer-lawrence-hacked-icloud-leaked/

 

Target e Home Depot (Início de 2014 e Setembro de 2014)

Os ataques aos gigantes do retalho Target e Home Depot representam dos maiores até à data a empresas do sector do retalho, conduzindo à perda em massa, respetivamente, de 40 e 56 milhões de dados de cartões de crédito. Entre estes encontram-se também os dados pessoais dos seus donos – http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic-hack-of-credit-card-data e http://www.businessweek.com/articles/2014-09-18/home-depot-hacked-wide-open

 

Autor: Artur D’Assumpção @ SysValue

heartbleed_cupid

Heartbleed, Cupid and Wireless

Since my presentation on cupid has gotten quite a bit of attention, I feel it’s necessary to provide a bit more context about this issue and what it is exactly. I’ve received some questions and I’ll try to post all the answers here.

 

What is cupid?

cupid is the name I gave to two source patches that can be applied to the programs “hostapd” and “wpa_supplicant” on Linux. These patches modify the programs behavior to exploit the heartbleed flaw on TLS connections that happen on certain types of password protected wireless networks.

hostapd is a program that sets up a configurable Access Point on Linux, so it is possible to create almost any kind of Wireless Network configuration and let clients connect to it.

wpa_supplicant is a program used to connect to wireless networks on Linux and also on Android.

Interesting side note: both hostapd and wpa_supplicant were written by the same author and share a lot of code, so the patches are very similar.

 

How does the attack work?

This is basically the same attack as heartbleed, based on a malicious heartbeat packet. Like the original attack which happens on regular TLS connections over TCP, both clients and servers can be exploited and memory can be read off processes on both ends of the connection.

The difference in this scenario is that the TLS connection is being made over EAP, which is an authentication framework/mechanism used in Wireless networks. It’s also used in other situations, including wired networks that use 802.1x Network Authentication and peer to peer connections.

EAP is just a framework used on several authentication mechanisms. The ones that are interesting in this context are: EAP-PEAP, EAP-TLS and EAP-TTLS, which are the ones that use TLS.

To exploit vulnerable clients, hostapd (with the cupid patch) can be used to setup an “evil” network such that, when the vulnerable client tries to connect and requests a TLS connection, hostapd will send malicious heartbeat requests, triggering the vulnerability.

To exploit vulnerable servers we can use wpa_supplicant with the cupid patch. We request a connection to a vulnerable network and then send a heartbeat request right after the TLS connection is made.

I saw a misconception on a lot of sources regarding heartbeat and it is a common question that I get: It’s not necessary to fully establish a TLS connection to perform the heartbleed attack. No actual keys or certificates need to be exchanged.

I have found it to be possible to send and receive heartbeat responses right after a “Client Hello” message (before certificates are presented or session keys are exchanged).

 

Do I need to provide a valid user/password to exploit this vulnerability?

In short, no. The vulnerability is triggered before a valid password needs to be presented. Sometimes in order to exploit a vulnerable server you must present a valid username (not password), as the specific EAP mechanism may request a valid username/realm to redirect the user to the proper authentication server.  But this can be easily sniffed off the air when a regular user tries to connect.

 

How to spot vulnerable systems:

You basically use cupid to trigger the vulnerability and look for a behaviour consistent with heartbleed on a packet sniffer.

The following image shows wpa_supplicant_cupid exploiting a vulnerable network:

heartbleed_cupid_img1

 

First we provide a username (EAP Identity), then we will create a TLS connection over EAP to authenticate (using EAP-PEAP). Note that cupid sends heartbeat requests right after “Client Hello”, there’s no need to perform the full TLS handshake. Up to 64kb of memory can be read for each heartbeat request.

 

The second image shows hostapd_cupid exploiting a vulnerable client in the same fashion:

heartbleed_cupid_img2

 

Note that, in this case, we didn’t even send a “Server Hello” message. The vulnerable client requested a TLS connection, sent a “Client Hello”, and we proceeded to send an heartbeat request. The client is happy to respond, leaking up to 64kb of process memory.

 

What is present on the memory that can be read?

Not enough testing was made to go into such detail, so we can only speculate. Most of the memory is zeroed out, but cursory inspection found interesting stuff on both vulnerable clients and servers. I can speculate that most likely the private key of the certificate used on the TLS connection is in memory. What can also be in memory is the user credentials used for authenticating the connection.

 

What software is affected?

Note that I’ve done very limited testing on this. I have confirmed however that on Ubuntu, if you are using a vulnerable version of OpenSSL the default installations of wpa_supplicant, hostapd, and freeradius can be exploited.

Android 4.1.0 and 4.1.1 use a vulnerable version OpenSSL. Also, all versions of Android use wpa_supplicant to connect to wireless networks, so I have to assume that these are probably vulnerable.

Regarding vulnerable clients:

If you have an Android device running 4.1.0 or 4.1.1 you should avoid connecting to unknown wireless networks unless you upgrade your ROM.

If you have a Linux system/device you’re using to connect to wireless networks you should make sure to upgrade your OpenSSL libraries, so if you followed heartbleed mitigation recommendations you should be fine.

 

Regarding vulnerable servers:

If you have an home router you are probably safe from this specific attack vector. This is because most home routers use a single key for Wireless Security (a pre-shared key), and do not use EAP authentication mechanisms.

 

If you have a corporate wireless solution on your company you should look at this problem, since most of the managed wireless solutions use EAP based authentication mechanisms. And some companies use OpenSSL. You should look at having your equipment tested or contacting your vendor and ask for more information.

You should also look at this issue if you have any type of EAP authentication mechanism on your corporate network. Note that 802.1x Network Access Controlled wired networks might also suffer from this problem.

You can contact us at SysValue if you need assistance on testing your corporate network regarding this issue.

 

Conclusion:

I hope this comprehensively addresses all the questions you have about cupid. I’ve put the source code online so that you can test more networks and devices. Please let me know of the results of your testing so I can update this post with the types of devices and configurations that are affected / not affect by this issue.

 

References:

Article written by Luis Grangeia