Artigos

sysblog

Autenticação multi-factor para o dia a dia

Cada vez é mais a informação localizada em sistemas fora do nosso controlo direto. Lojas online, serviços de correio eletrónico, redes sociais, plataformas de gaming e serviços de homebanking são apenas alguns exemplos em que a nossa informação está protegida apenas por um nome de utilizador e uma password. Este artigo refere de que modo podemos implementar uma camada adicional de segurança – a autenticação multifator – no processo de login de modo a proteger melhor a nossa informação, sem custos acrescidos.

A autenticação multifator baseia-se na premissa de que quanto mais mecanismos de autenticação forem utilizados mais fielmente conseguiremos identificar um determinado sujeito e, deste modo, assegurar que os serviços prestados são-no ao sujeito correto e apenas a este. Existem 3 mecanismos que podem ser utilizados para autenticar um sujeito:

  • Algo que este tem – um objeto na posse do sujeito, como um cartão;
  • Algo que este sabe – informação na posse do sujeito, como um PIN ou uma password;
  • Algo que este é – uma característica intrínseca do sujeito, como uma impressão digital ou a sua retina.

Por exemplo, em Portugal, um dos meios de pagamento e transações mais utilizados e de forma totalmente ubíqua é o cartão multibanco que utiliza autenticação multifator com algo que temos – o cartão – e algo que sabemos – o PIN. Sem um ou o outro não será possível realizar transações na rede o que traz uma camada de segurança e confiança adicional a todo o sistema. Embora exista uma perceção de maior fiabilidade pela utilização de sistemas biométricos (p.ex.: leitura de impressão digital ou de retina) estes por si só não asseguram autenticação multifator porque apenas validam um fator – aquilo que somos. Teriam que estar associados a outro mecanismo (p.ex.: um PIN ou cartão) para assegurar a componente multifator.

Em resumo, quanto mais fatores forem utilizados mais garantias existem sobre a identidade do sujeito. Deste modo a autenticação multifator também pode – e deve – ser implementada pelos utilizadores para protegerem o acesso aos seus dados na Internet, seja numa utilização doméstica ou empresarial.

Várias entidades na Internet disponibilizam já autenticação multifator através de um código gerado por uma aplicação num smartphone ou através de um SMS enviado para o telefone. Existem várias aplicações disponíveis para diversas plataformas nas stores correspondentes – iTunes, Google Play ou Microsoft Store, para citar alguns exemplos. Entre as mais usadas contam-se o Google Authenticator, o Authy ou o Azure Authenticator. A utilização destas aplicações e mesmo a receção de SMS habitualmente não acarretam custos para o utilizador, o que na prática significa um aumento da segurança das contas apenas com o custo de mais uns segundos no processo de autenticação.

Alguns exemplos com sites mais conhecidos:

  • Amazon –  a retalhista disponibiliza esta possibilidade mas é necessário ativá-la em Amazon.com ficando depois disponível no acesso aos vários sites regionais (Amazon.co.uk, Amazon.es, etc.). Procure a opção em Your Account -> Settings -> Change Account Settings -> Advanced Security Settings.
  • Apple – A marca da maçã tem vindo a disponibilizar, a partir deste Outono, uma camada adicional de segurança para o ID Apple com um código apresentado automaticamente num dispositivo fidedigno com o iOS 9 ou o OS X El Capitan ou enviado por SMS para um número de telefone em que confia.
  • DropBox – O site de armazenamento de ficheiros permite configurar a autenticação de dois fatores acedendo ao perfil e habilitando essa funcionalidade.
  • Evernote – O conhecido serviço de anotações também disponibiliza autenticação de dois fatores através da utilização de app. Basta configurar as opções de login na secção de segurança.
  • Facebook – A rede social permite o acesso ao site com códigos gerados através da própria app (instalada num smartphone), outra app das já indicadas ou através da receção de SMS. Basta ir à secção Aprovação de acesso nas Definições de Segurança e configurar de acordo com as opções.
  • Google – Basta ativar a Verificação em dois passos acedendo às configurações de segurança e seleccionar como principal forma de receção de códigos a opção Google Authenticator ou outra das disponíveis, como a utilização de SMS. Desta forma é possível proteger o acesso a todos os serviços e informação que dependem de um login no Google como o correio eletrónico, o acesso às fotos no Picasa ou aos ficheiros armazenados via Google Drive.
  • LastPass – O popular gestor de passwords permite reforçar a segurança no acesso às configurações, contas e passwords no seu “cofre” na nuvem através de vários mecanismos. Basta aceder a Definições de conta -> Opções multifator e selecionar e configurar a opção desejada entre as várias disponibilizadas. Utilizadores do serviço gratuito podem escolher entre a utilização de uma app de geração de códigos, a impressão de uma matriz de números ou o envio de mensagens para o telemóvel, de acordo com outros serviços que já utilizem. Para os utilizadores do serviço Premium existem outras opções, incluindo a utilização de biometria.
  • LinkedIn –  a rede social orientada aos profissionais permite aos seus utilizadores a possibilidade de receber um SMS sempre que faça um login. Esta opção é acedida através da opção Configurações e privacidade -> Conta -> Gerenciar configurações de segurança.
  • Microsoft – A proteção adicional de uma conta associada a serviços fornecidos pela Microsoft é tão importante como uma conta associada a serviços do Google pela diversidade de informação e serviços a que se tem acesso, tais como correio eletrónico, Xbox Live, Office 365 entre outros. Para contas Microsoft Live é possível configurar a autenticação multifator acedendo às Definições de Segurança e configurando o modo desejado na seção Verificação em dois passos. No caso de utilização dos serviços empresariais solicite ao seu Administrador de sistemas a ativação da autenticação multifator para acesso à informação e serviços na nuvem.
  • Paypal – O bem conhecido site de gestão de pagamentos online também já disponibiliza aos seus utilizadores realizarem login com um segundo nível de segurança por SMS. Para ativar esta possibilidade basta aceder a Perfil – As minhas definições -> Chave de segurança.
  • Twitter – A rede social de micromensagens também adotou a autenticação multifator por SMS. Para proceder à sua ativação é necessário ativar a opção de verificação de pedidos de acesso através de Configurações -> Segurança e Privacidade.
  • Zoho – o sistema de correio eletrónico também permite a autenticação multifator sendo, desta lista, o único que sugere automaticamente a sua adoção. De qualquer modo basta aceder a Minha conta -> Autenticação de duas camadas. Depois basta selecionar de que modo se processará o multifator – usando uma app ou através de SMS.

A autenticação multifator também se aplica nos casos em que o login num site ou serviço está integrado com um já existente. Por exemplo sites como o Coursera ou o EDX, ambos plataformas de cursos online, permitem autenticação com contas do Facebook ou do Google. Se a opção de autenticação multifator estiver já ativada também se aplicará ao fazer login nestas plataformas.

Nos serviços prestados em Portugal a autenticação multifator ainda não é algo comum na utilização de serviços via Internet, mas temos esperança que isto mude. Alguns serviços da Administração Pública, como o acesso ao Portal das Finanças, já permitem a utilização do Cartão do Cidadão + PIN, mas nem sempre é possível dispor de leitores de cartões ao passo que na banca online é comum a utilização de um segundo mecanismo de autenticação (SMS ou cartão matriz), mas apenas na realização de operações e não como mecanismo de proteção no login ao serviço.

Enquanto não se torna a norma aqui fica uma listagem de serviços na Internet que suportam autenticação com dois fatores, entre os quais estão alguns já bem conhecidos. Esta listagem contempla serviços de backup na nuvem, banca online, moeda virtual, jogos e correio eletrónico entre outras categorias.

Autor: Jorge Pinto @ SysValue

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 ([email protected]), 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

sysblog

Windows Management Instrumentation (WMI)

O que é o WMI?

O WMI é a implementação Microsoft do Web-Based Enterprise Management (WBEM),  uma iniciativa da indústria para o desenvolvimento de uma tecnologia padrão para receber ou gerir métricas num ambiente corporativo. Recorrendo ao Information Model (CIM), padrão da indústria para a representação de sistemas, aplicações, redes, dispositivos e outros componentes, o WMI permite o uso de scripts em linguagem VBScript e Windows PowerShell para a obtenção de dados e a realização de operações em sistemas.

O WMI consegue assim fornecer aos utilizadores informações sobre o estado dos sistemas das máquinas locais ou remotos, bem como realizar ações como a definição de configurações de segurança, definição e alteração de propriedades do sistema, configuração e alteração de permissões para utilizadores e grupos de segurança.

Arquitetura do WMI

O WMI fornece uma interface uniforme a todas as aplicações locais e remotas para a obtenção e gestão de métricas de um computador ou de uma rede. Este interface permite que as aplicações cliente do WMI e scripts não necessitem de ligar-se a uma variedade de interfaces de programação do sistema operativo (APIs).

O diagrama seguinte mostra a relação entre a infra-estrutura WMI e os fornecedores WMI e objetos de gestão, e também mostra a relação entre a infra-estrutura WMI e os consumidores do WMI.

wmi

Como se pode usar o WMI?

Por norma, muitas aplicações de monitorização de serviços exigem a criação na AD de um utilizador com privilégios de administração para a realização das suas funções. Porém, tal configura um enorme risco para a segurança do sistema em todos os vectores (confidencialidade, integridade e disponibilidade).

Os próximos passos demostram como é que possível a criação de um utilizador sem privilégios de administração e a ativação do WMI nas máquinas pretendidas.

O exemplo usado assume que o sistema operativo é Windows Server 2012 R2.

Pré-requisitos

  • Todos os procedimentos que se seguem necessitam de ser executadas com privilégios de administração nos sistemas operativos das máquinas envolvidas;
  • Poderá ser necessária a alteração de políticas de firewalling em equipamentos ativos de rede onde vigorem políticas ativas de restrição de tráfego (ver secção 3).

Procedimentos

Todos os procedimentos descritos nas secções seguintes deverão ser efetuados em todos os dispositivos onde se deseja autorizar a execução de WMI queries remotamente.

Na existência de um domain controller e na necessidade de autorizar a execução de WMI queries para qualquer entidade pertencente a um determinado domínio, os procedimentos seguintes deverão ser efetuados apenas no domain controller, à exceção da secção 5.1 que deverá, neste caso, ser ignorada.

  1. Services

Confirmar se os serviços associados DCOM e WMI estão a iniciar automaticamente (Automatic).

Esta validação deverá ser feita através do seguinte caminho:

                Server Manager -> Tools -> Services

                Alterar o tipo de arranque dos serviços seguintes de Manual para Automatic:

  • DCOM Server Process Launcher
  • WMI Performance Adapter

                No caso de os serviços se encontrarem Stopped, terão que ser iniciados manualmente.

  1. Firewall Windows

Permitir na firewall do Windows o trafego para os serviços DCOM e WMI, executando as instruções seguintes na command-line:

  • Clique em Start, clique em Run, digite exe e clique em OK.
  • Executar as instruções seguintes:
    • netsh advfirewall firewall set rule group=”windows management instrumentation ()” new enable=yes
  • netsh advfirewall firewall set rule group=”remote administration” new enable=yes

 

  1. Configuração de dispositivos ativos de rede

Na existência de dispositivos ativos de rede com políticas ativas de restrição de tráfego, deverão ser efetuados os procedimentos descritos numa das seguintes opções:

3.1. Atribuição dinâmica

  • Permitir trafego para DCOM port (135/tcp/udp)
  • Permitir a Range (TCP e UDP) 1025 a 5000 no caso do sistema operativo da máquina de destino ser Windows 2000, Windows XP ou Windows 2003.
  • Permitir a Range (TCP e UDP) 49152 a 65535 no caso do sistema operativo da máquina de destino ser Windows Vista ou superior.

3.2. Atribuição de porta fixa

  • Permitir trafego para DCOM port (135/tcp/udp).
  • Permitir o trafego para a porta 12345/tcp/udp.
  • Forçar uma porta (eg, 12345/tcp) para comunicações WMI em cada máquina windows:

C:\> winmgmt -standalonehost
C:\> net stop “Windows Management Instrumentation”
C:\> net start “Windows Management Instrumentation”
C:\> netsh firewall add portopening TCP 12345 WMIFixedPort

  1. Utilizador

Criar um novo utilizador com as características seguintes:

  • Aceder a Server Manger -> Tools -> Computer Management;
  • Na janela Computer Management expandir Local Users and Groups, clicar com o botão direito na pasta Users e escolher a opção New User;
  • Depois de criar o utilizador ele tem de pertencer aos seguintes grupos:
    • Distributed COM Users
    • Performace Log Users
  1. Configuração de políticas para o novo utilizador

A configuração de políticas para o novo utilizador poderá ser efetuada em três contextos distintos: apenas na Máquina Local (5.1) ou para todo o Domínio (5.2), sendo neste ultimo caso necessário efetuar as definições nos Controladores de Domínio.

5.1. Definição de políticas apenas para a Máquina Local

  • Clique em Start, clique em Run, digite msc e clique em OK.
  • Selecionar Security Settings expandir, Local Policies expandir e selecionar User Rights Assignment.
  • Associar as seguintes políticas ao utilizador criado:
    • Act as part of the operating system;
    • Log on as a batch job;
    • Log on as a service;
    • Replace a process level token.

5.2. Definição de políticas para todo o Domínio

  • Clique em Start, clique em Run, digite msc e clique em OK.
  • Selecionar Security Settings expandir, Local Policies expander e selecionar User Rights Assignment.
  • Depois é necessário acrescentar o utilizador que criamos nas seguintes políticas:
    • Act as part of the operating system;
    • Log on as a batch job;
    • Log on as a service;
    • Replace a process level token.
  1. Permissões de WMI namespaces (Root e CIMV2)

Existem dois namespaces para os quais terão de ser dadas permissões ao novo utilizador a fim de permitir pedidos WMI: Root (5.1) e CIMV2 (5.2).

6.1. Configuração de permissões para o Namespace Root

  • Clique em Start, clique em Run, digite msc e clique em OK.
  • Clique com o botão direito no WMI Control e clique na opção Properties.
  • Navegar até ao separador Security, selecionar Root e carregar no botão Security.
  • Acrescentar o utilizador que criamos e dar as seguintes permissões:
    • Execute Methods
    • Full Write (opcional)
    • Partial Write (opcional)
    • Provider Write (opcional)
    • Enable Account
    • Remote Enable
    • Read Security
    • Edit Security (opcional)

6.2. Configuração de permissões para o Namespace CIMV2

  • Clique em Start, clique em Run, digite msc e clique em OK.
  • Clique com o botão direito no WMI Control e clique na opção Properties.
  • Navegar até ao separador Security, selecionar Root, abrir a árvore, selecionar CIMV2 e carregar no botão Security.
  • Acrescentar o utilizador que criamos e dar as seguintes permissões:
    • Execute Methods
    • Full Write (opcional)
    • Partial Write (opcional)
    • Provider Write (opcional)
    • Enable Account
    • Remote Enable
    • Read Security
    • Edit Security (opcional)

  1. Permissões no DCOM

7.1. Verificar a configuração do DCOM:

  • Execute no Run o comando DCOMcnfg
  • Clique em Component Services.
  • Expandir
  • Carregar com o botão direito em My Computer e selecione Properties.
  • Certifique-se que está ativo o Enable Distributed COM no computador.
  • Clique na tab Com Security.
  • Clique no botão Edit Limits localizado abaixo do Launch and Activation Permissions.
  • Na caixa Launch Permissions certificar-se que a conta de utilizador ou grupo está na listado de Groups or user names.
  • Na caixa Launch Permissions selecione a conta de utilizador ou grupo na lista de Group or user names e selecionar Remote Launch e Remote Activation e clique OK.

7.2. Configuração do DCOM no remote access:

  • Execute no Run o comando DCOMcnfg
  • Clique em Component Services.
  • Expandir
  • Carregar com o botão direito em My Computer e selecione Properties.
  • Clique na tab Com Security.
  • Clique no botão Edit Limits, localizado abaixo de Access Permissions.
  • No Access Permissions selecionar ANONYMOUS LOGON na lista Groups or user names.
  • Na coluna Allow debaixo de Permissions for User selecionar Remote Access e clique OK.

 

Autor: Nuno Barros @ SysValue
sysblog

Network Packet Brokers (NPB)

Ao longo dos últimos anos, um dos requisitos operacionais que tem ganho mais importância é a visibilidade das aplicações e da infraestrutura que as suporta. Esta visibilidade é essencial para que as equipas de segurança estejam atentas ao tráfego malicioso e para que as equipas de operações possam alterar o seu comportamento de reactivo para proactivo.

Tem havido um aumento considerável de tecnologias para recolher e analisar pacotes de rede, para monitorização de aplicações, monitorização de segurança, monitorização de rede, e outros. No entanto existem vários desafios para obter visibilidade, tais como, escalabilidade, virtualização, flexibilidade e acesso.

A solução tem que ser escalável de forma a suportar o aumento de velocidade dos acessos e consequentemente o aumento do volume de pacotes de rede. Terá que suportar o aumento da infraestrutura, nomeadamente o aumento de localizações geográficas e novos sistemas. Terá que ser flexível para suportar as novas tecnologias para visibilidade e análise de tráfego.

Para responder a estes desafios apareceu no mercado uma nova categoria de equipamentos que permitem uma nova abordagem para a manipulação de pacotes, os Network Packet Brokers (NPB). Os NPBs permitem otimizar o acesso e a visibilidade de tráfego para monitorização, segurança, ferramentas de aceleração, etc. As capacidades do NPS incluem:

  • Agregação de tráfego monitorizado a partir de múltiplos links
  • Filtragem de tráfego para aliviar as ferramentas de monitorização
  • Balanceamento de carga através de um conjunto de sistemas
  • Regeneração de tráfego para múltiplos sistemas

NPB

As soluções de segurança que permitem uma implementação in-line, tais como, o IPS (Intrusion Prevention Systems) e o DLP (Data Loss Prevention) já existem há alguns anos mas tem havido algumas preocupações devido a questões de fiabilidade e performance em colocar estes equipamentos em modo in-line, onde são capazes de intersetar e bloquear o tráfego. Os NPBs permitem balancear o tráfego através de várias soluções de segurança melhorando a fiabilidade e a performance em caso de falha ou degradação de alguma appliance. Desta forma os inconvenientes em colocar as soluções de segurança, como o IPS e o DLP, em modo in-line deixam de existir, permitindo um aumento de segurança.

Os NPBs têm a capacidade de aplicar filtros de modo a restringir o tráfego interessante a monitorizar, por exemplo, restringir o envio de tráfego VoIP para um sistema que faça análise de tráfego VoIP.

O NPB permite aplicar filtros com base nos seguintes parâmetros:

  • MAC address (source, destination)
  • IP address (source, destination, range)
  • UDP, TCP, and ICMP (port, range)
  • VLAN
  • IP service type

Capacidades do NPB:

  • Full traffic aggregation
  • Traffic regeneration
  • Packet ordering
  • Packet de-duplication
  • Packet fragment reassembly
  • Conditional packet slicing/masking
  • Power-loss traffic-flow policies
  • Link state mirroring
  • Protocol stripping
  • Reboot accelerated failover
  • Health-check packets
  • Selected traffic aggregation
  • Hardware-based packet filtering
  • Session-aware load balancing
  • High data-burst buffering
  • Deep packet inspection
  • Time- and port-stamping

Os NPBs têm capacidade para processar, consolidar e filtrar o tráfego de forma a minimizar o investimento na infraestrutura de rede. Esta capacidade ajuda as empresas a resolver os desafios de monitorização de rede permitindo que as organizações utilizem ferramentas de segurança e monitorização de forma mais eficiente, centralizem os sistemas de monitorização e segurança, e permite partilhar o tráfego e sistemas entre grupos. A escalabilidade e a fácil utilização dos NPBs não só ajudam a baixar o CAPEX e OPEX, mas também permitem às organizações uma melhor gestão e eficiência da rede num ambiente dinâmico e desafiante.

Autor: Gonçalo Rey @ 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

sysblog

Análise de malware em resposta a incidentes de segurança (3/3) – Análise de malware

Este é o terceiro e último de uma série de 3 posts sobre análise de malware e o seu papel na resposta a incidentes de segurança. Depois da identificação dos ficheiros descrita no post anterior, neste artigo é apresentada sumariamente a metodologia que poderá ser seguida para a análise do malware, mais concretamente do seu comportamento e capacidades.

A análise de malware tem dois grandes objectivos. A identificação do tipo de ameaça e dos seus objectivos e a recolha de informação que permita uma resposta eficiente, bloqueando o ataque e controlando os danos já sofridos. Por exemplo, indicadores que permitam detectar a presença do malware num sistema, indicadores que permitam detectar actividade do malware na rede e  tácticas de remoção do malware e de resposta ao incidente que deverão ser aplicadas.

Esta análise pode ser efectuada com níveis de profundidade que vão desde uma análise automatizada com recurso a sandboxes à engenharia reversa e análise pormenorizada do código Assembly, pelo que é necessário algum pragmatismo na selecção da metodologia para que seja identificado o máximo de informação sem que se perca demasiado tempo com detalhes de pouca utilidade prática.

A forma mais eficiente de fazer a análise e um bom primeiro passo de análise é o recurso a malware sandboxes que permitem executar o malware num ambiente controlado, monitorizando as suas acções e produzindo um relatório de forma automatizada.

Estas ferramentas permitem tirar conclusões rápidas sobre as capacidades e o funcionamento do malware. No entanto, têm diversas limitações (e.g. Detecção por parte do malware, utilização de criptografia, condições específicas de execução do malware) e muitas vezes não oferecem a flexibilidade necessária para chegar às conclusões pretendidas.

Assim, após análise inicial em sandbox, quando a informação produzida não é suficiente, é realizada uma análise estática manual dos ficheiros. Esta análise consiste na análise dos binários do malware, de forma a inferir sobre o seu comportamento. Para o fazer são realizadas operações tais como a identificação de strings presentes no ficheiro ou a análise das bibliotecas importadas. Este processo nem sempre é directo, uma vez que o malware recorre muitas vezes a técnicas que impedem a análise dos binários, sendo por isso necessário algum pré-processamento para unpacking dos binários antes da análise.

Em seguida, é normalmente realizada uma análise dinâmica, que consiste na execução do malware num ambiente controlado e especialmente preparado para o efeito. Este tipo de análise vai para além da análise efectuada por sandboxes automatizadas, já que é possível a simulação de comportamentos do utilizador mais completos para levar o malware a realizar operações adicionais e a configuração do sistema para a análise específica do malware em questão. Por exemplo, poderá ser fornecido ao malware informação que este está programado para roubar tais como credenciais ou documentos e analisar o seu comportamento nessas situações.

Por fim, quando as metodologias de análise simples não são suficientes para a obtenção da informação pretendida, poderá ser necessária a realização de engenharia reversa do malware com recurso a disassemblers e debuggers de forma a compreender a fundo o comportamento do malware. Este é um procedimento moroso e que exige conhecimentos muito especializados, pelo que na grande maioria dos casos não é levado a cabo.

Uma vez finalizada a análise, deverá ter sido gerada diversa informação util, tal como:

  • Modo de infecção (e.g. Emails ou sites visitados);
  • Vulnerabilidades exploradas para a infecção;
  • Indicadores de infecção para a pesquisa de hosts infectados;
  • Indicadores de rede para pesquisa de hosts infectados através da análise de tráfego de rede e criação de regras IDS;
  • Medidas a tomar para parar de imediato a comunicação com os servidores de comando e controlo;
  • Amostras de malware para envio a fabricantes de antivírus;
  • Informação útil sobre a ameaça, para programas de awareness e comunicação de tentativas de fraude a clientes e colaboradores;

Esta informação poderá então ser utilizada para uma resposta adequada e eficiente ao incidente, recuperando o controlo dos sistemas e tendo a capacidade de responder às questões sobre qual o incidente e o seu impacto real.

Autor: Tiago Pereira @ SysValue

sysblog

Comprehensive Monitoring as a Service (CMaaS)

CMaaS, em tradução livre Monitorização Abrangente como Serviço, é um conceito recente e inovador a entrar no mundo das soluções de monitorização.

cmaas

Inserido no contexto dos XaaS um termo colectivo com uma série de significados – incluindo “X como um serviço”, “qualquer coisa como serviço” ou “tudo como serviço” – que se referem a um crescente número de serviços prestados através da Internet em vez de fornecidos localmente.

CMaaS é um caso particular de um SaaS – Software as a Service (software como serviço) herdando assim todas as vantagens que advêm de fornecer um software desta forma.

O CMaaS é uma ferramenta de monitorização cujo objetivo principal é o de informar os seus utilizadores sobre o estado e o desempenho de todos os seus serviços, aplicações e infra-estruturas, independentemente das respectivas localizações geográficas, arquiteturas e plataformas tecnológicas.

Como qualquer SaaS, o CMaaS oferece os seus serviços através de um aplicativo central, baseado na web, alojado pelo fornecedor do serviço de monitorização, sem os custos diretos e indirectos da infraestrutura para o cliente.

O termo Abrangente (do inglês comprehensive) realça a capacidade desta filosofia de monitorizar tudo o que for necessario. Apresentando-se assim como uma solução para praticamente todo o tipo de situações de monitorização: desde a monitorização dos sistemas de produção numa indústria, até o seguimento dos parâmetros ambientais numa casa de habitação, passando por uma PME que necessite de monitorizar os seus servidores e aplicações, entre outros cenários.

O principal benefício da monitorização como um serviço é a facilidade de configuração e manutenção. Em geral, para se iniciar o processo de monitorização num sistema deste tipo, basta a criação on-line de uma conta junto de um dos fornecedores deste tipo de soluções, e garantir que a infra-estrutura está pronta a ser monitorizada (geralmente algo bastante simples bastando que os serviços sejam acessíveis pelos sistemas de monitorização) e pode-se começar a monitorizar imediatamente. O funcionamento e manutenção do CMaaS é garantido pelo fornecedor do serviço.

Dos muitos benefícios desta abordagem destacam-se:

  • Fácil de configurar, ainda mais fácil de manter – Como dito anteriormente, para iniciar a monitorização, o utilizador não tem que instalar os tradicionalmente complexos  sistemas, nem de manter servidores aplicacionais, bases de dados e outros equipamentos referentes à ferramenta de monitorização, ao contrário do que acontece numa solução local (on-premise).

  • Evolução rápida do produto – Os sistemas CMaasS são atualizados centralmente, sem problemas logísticos e de forma transparente para os utilizadores da solução.

  • Aplicações distribuídas são facilmente monitorizadas – Através deste tipo de soluções, uma aplicação distribuida por múltiplos servidores e/ou geografias é muito mais fácil de monitorizar, não necessitando de agentes nem de instalação de software especifico.

  • Perfeito para nuvens públicas – Porque o sistema de monitorização deve ser independente do sistema cloud que está a servir a aplicação em si  e porque não faz sentido pagar pelo alojamento na cloud de mais um sistema de monitorização.

  • Acessibilidade Global – Acesso ao sistema de monitorização de qualquer lugar e a partir de qualquer dispositivo.

Como não existem soluções perfeitas, há alguns aspetos a considerar na comparação entre uma solução local (on premise) e uma solução CMaaS:

  • Segurança dos dados resultantes da monitorização – Como a logística do serviço está do lado dos fornecedores do CMaaS, os dados resultados da monitorização não estão sobre o controlo direto do cliente.

  • Segurança das aplicações e infraestruturas – Os pontos de entrada para a infraestrutura a monitorizar podem ser explorados como vetores de intrusão. Para mitigar este risco, a instalação de componentes de monitorização locais (dentro da infraestrutura) pode ser uma solução.

  • Fiabilidade do sistema de monitoramento – No fim do dia é tudo uma questão de confiança. Há que confiar nos fornecedores do serviço de monitorização a vários níveis: disponibilidade da monitorização (24/7) / segurança de dados do cliente / competência.

  • Os dados em tempo real – Este é provavelmente o “calcanhar de Aquiles” dos CMaaS. Se os requisitos de monitorização envolvem a avaliação do estado dos serviços em tempo real (e não com o habitual atraso que muitas das soluções CMaaS apresentam) o CMaaS pode não ser a solução mais adequada.

  • Desempenho da solução de monitorização – A configuração das taxas de recolha de dados de performance em soluções CMaaS normalmente não estão disponíveis ou não têm possibilidade de baixa resolução.

  • Personalização da solução de monitorização – Qualquer solução CMaaS, por melhor que seja e por maior variedade de possibilidades de configuração e personalização que apresente, não poderá competir com uma solução desenvolvida à medida das necessidades do cliente.

Em Conclusão, A Monitorização Abrangente como Serviço é uma solução atraente para muitas empresas e situações especialmente em sistemas baseados em nuvem e empresas que não queiram ou não possam suportar os custos de uma solução local.

 
 
 
Bibliografia:

Autor: Tiago Pombeiro @SysValue

logotipo_POR_Lisboa_100pxlogotipo_QREN_100px
logotipo_UE_Feder_100px

Vulnerabilidade crítica em implementações SSL/TLS – Vulnerabilidade Heartbleed

Foi tornada pública ontem (7 de Abril) uma vulnerabilidade crítica na implementação da biblioteca open source OpenSSL, conhecida como Heartbleed attack. Esta vulnerabilidade permite a leitura de blocos de memória do processo em questão o que pode levar ao comprometimento de informação sensível tal como:

  • Chaves privadas de certificados SSL;
  • Credenciais (passwords) de utilizadores;
  • Outras chaves criptográficas

As seguintes versões do OpenSSL estão vulneráveis:

  • OpenSSL 1.0.1 a 1.0.1f – (inclusivé) estão vulneráveis
  • OpenSSL 1.0.1g – NÃO ESTÁ vulnerável
  • OpenSSL 1.0.0 branch – NÃO ESTÁ vulnerável
  • OpenSSL 0.9.8 branch – NÃO ESTÁ vulnerável

A maioria das implementações baseadas em OpenSSL (p. ex. VPN’s SSL) que suportem TLS 1.2 com a extensão “heartbeat” deverão ser afetadas.

Aconselhamos todos os clientes com sites que utilizem SSL/TLS a fazerem o despiste da vulnerabilidade. Este despiste pode ser realizado através do Qualys SSL Labs:

Em alternativa existe um script em Python que tem sido utilizado pela equipa da SysValue para testes internos e pode ser utilizada (sem garantias dadas sobre o funcionamento do mesmo):

Este ataque tem afetado grande percentagem da Internet, tendo sido já reportado, p. ex. o comprometimento de credenciais de utilizadores do site Yahoo, entre outros.

Para mais informações pode ser consultado o seguinte site (em desenvolvimento):

Para informação sobre o desenvolvimento deste ataque pode ser seguida a hashtag #heartbleed no Twitter.

Artigo por: Luis Grangeia

Malware

Cada vez mais os problemas relacionados com malware afetam tanto particulares como empresas. Há alguns anos atrás, os tipos mais comuns de malware eram os vírus e os worms, para os quais existiam ferramentas baseadas em assinaturas (antivírus) com uma boa eficácia. No entanto, esse cenário tem vindo a alterar-se, sendo cada vez mais comuns outros tipos de malware: no passado recente tivemos eventos como a operação Aurora (http://en.wikipedia.org/wiki/Operation_Aurora), Zeus 
(http://en.wikipedia.org/wiki/Zeus_(Trojan_horse), e outros mais ou menos significativos e com maior ou menor exposição. Em cada um destes casos, o modus operandis era distinto pelo que o combate não pode passar por ações individualizadas de prevenção de uma determinada vulnerabilidade (explorada por uma dessas instâncias), mas por uma ação mais abrangente e estruturada com o intuito de proteger a informação mais valiosa das empresas (tipicamente o alvo destes ataques).
A dificuldade está na implementação dessas medidas protetoras (que podem passar pela implementação de ferramentas ou estratégias) dado que o grau de efetividade contra o malwareavançado (APT – Advanced Persistent Threat) dificilmente é de 100%. Adicionalmente, a adoção massiva e crescente da chamada “social media”, tanto pelas empresas como pelos particulares, torna esta tendência como um canal para a fácil distribuição do malware e de difícil controlo.
Os gráficos seguintes ilustram os principais vetores de entrada do malware:
Blog malware web
Blog malware tre
.
Para os negócios que realizam transações na web, como por exemplo sites de comércio online ou os sites de homebankingmalware como o trojan Zeus, que se posiciona no browser do cliente e intersecta todos os pedidos (MITB – Man-in-the-Browser), são especialmente preocupantes. Neste caso, não podemos confiar em nada que é enviado pelo browser do cliente, nem mesmo com a utilização de cifra SSL, não sendo possível para as aplicações detetar este tipo de ameaças dado que todo o código no cliente (client-side) pode ser manipulado pelo malware. Existem, no entanto, algumas proteções adicionais que podem ser aplicadas para minimizar a sua efetividade:
  • Implementação de dois níveis de autenticação/autorização, recorrendo a um dispositivo distinto do que origina a transação (e assumindo que a probabilidade de infeção simultânea dos dois dispositivos é baixa);
  • Implementação de medidas no lado das aplicações (server-side fraud detection) para determinar comportamentos anómalos, por exemplo, por variação dos montantes típicos ou das operações comuns.
Este tipo de transações é um alvo sempre apetecível para estas ameaças, que variam e assumem diversas formas explorando inúmeras vulnerabilidades. Como referido, uma das variantes explora as vulnerabilidades dos seus clientes (client-side vulnerabilities) que visa não diretamente a organização, mas os seus utilizadores, tirando partidos de sistemas menos protegidos e não tão educados quanto ao risco de determinados comportamentos. Continuam, no entanto, a existir ataques dirigidos às próprias organizações, que recorrem a soluções como o IPS (Intrusion Prevention Systems) ou o WAF (Web Application Firewalls), tipicamente inline, para o controlo e proteção contra essas ameaças. Nalguns casos, o volume de trafego que tem que ser processado por essas ferramentas limita-as na sua análise, pelo que soluções que fazem essa análise em modo offline, podem ser muito mais detalhadas e minuciosas cobrindo assim um espectro maior de ameaças, estando, naturalmente, limitadas na sua capacidade de prevenir o primeiro ataque, mas tendo a capacidade de gerar alertas para estas ameaças. Cabe depois à organização implementar um plano de ação para o tratamento destes alertas e análise do impacto da sua execução.
A Gartner lançou em finais de 2013 um relatório (http://www.gartner.com/newsroom/id/2595015), no qual caracteriza em cinco o tipo de medidas que pode ser implementada por uma organização para garantir a proteção contra este tipo de ameaças:
 
  • Network Traffic Analysis: A análise do trafego de rede permite definir uma baseline, sendo os comportamentos anómalos analisados e classificados. Implica algum tunningda solução para minimizar os falsos positivos resultantes desta abordagem.
  • Network Forensics: Tipicamente garantem a captura total do trafego de rede e permitem reconstruir e simular num ambiente controlado o impacto de determinado trafego observado. Tem requisitos elevados de storage que aumentam com períodos de retenção elevados.
  • Payload Analysis: Associados a técnicas de sandbox local ou na cloud, para deteção do malware. Estas soluções têm uma visibilidade limitada do impacto do malware nosendpoints, sendo muitas vezes complementada com outras técnicas.
  • Endpoint Behaviour Analysis: Baseado na ideia do isolamento da execução das aplicações nos endpoints, ou na monitorização do comportamento e dos recursos acedidos pela sua execução. Implica a instalação de um agente no endpoint com as implicações que essa instalação acarreta na gestão e manutenção desse agente.
  • Endpoint Forensics: Conjunto de ferramentas que garante às equipas de análise de incidentes de segurança (incident response teams), a automatização do processo de resposta a incidentes.
Blog malware flux
Cada vez mais este tipo de soluções são um requisito nas mais variadas organizações. A recomendação da gartner é a da aplicação conjunta de pelo menos dois tipos de medidas das acima mencionadas, complementando as vantagens para cada um dos segmentos (linhas) com diferentes horizontes temporais (p.ex. colmatar as dificuldades de uma análise do payload com uma análise forense dos endpoints – tipo 3 e tipo 5). Como referido, a estratégia não deverá ser contra uma determinada ameaça ou variante, mas de uma forma global contra este tipo de ameaças através de um plano de ação bem definido, que passa não apenas pela implementação de políticas ou ferramentas por forma a criar ambientes mais seguros e menos suscetíveis às várias ameaças, mas dos próprios utilizadores que muitas vezes são o elo mais fraco desta cadeia.
Autor: Rui Branco @ SysValue

Bibligrafia:

http://tinyurl.com/qe562at

Sources: November 2013 Osterman Research Survey on Email, Web and Social Mdeia Security; 2013 Trustwave Global Security Report; The Global Malware Problem: Complanency Can Be Costl, Osterman Research.

 

Sobre Wearables e Bluetooth Smart

Em Janeiro o CES2014 em Las Vegas deu o mote para o ano de 2014, indicando que será certamente um ano de grande aposta em dispositivos “wearable”. Houve vários produtos a ser anunciados nesta área tais como “smartwatches”, dispositivos de “fitness tracking”, entre outros.

Existe também suspeita generalizada de que já em 2014 a Apple e a Google anunciarão os seus smartwatches, pelo que as expectativas relativamente a esta tecnologia são elevadas.

Devemos então tentar adivinhar as aplicações que estes dispositivos poderão ter, em particular no domínio da segurança. O facto de serem um segundo dispositivo inteligente (para além do “smartphone”) que andará connosco para qualquer lado pode permitir aplicações interessantes, como por exemplo servir como segundo factor de autenticação: A Nymi é uma pulseira que recolhe dados biométricos relacionados com o batimento cardíaco do utilizador e utiliza os mesmos como segundo factor perante um smartphone ou qualquer outro dispositivo que comunique directamente com a pulseira.

 

Um ponto comum a todos estes dispositivos é a utilização de Bluetooth Smart (também conhecido como Bluetooth Low Energy), um protocolo introduzido em conjunto com a especificação da norma Bluetooth 4.0. Este protocolo é inteiramente novo e distinto do Bluetooth clássico, partilhando apenas a frequência e determinadas características que tornam fácil implementar ambos os protocolos no mesmo dispositivo/rádio.

 

São estas as principais características diferenciadoras:

  • Cerca de 95% maior eficiência energética face ao Bluetooth clássico;
  • Menor latência no setup de ligações (6ms ao contrário dos cerca de 100ms no Bluetooth classico);
  • Funciona em modo ponto a ponto ou em modo estrela (um “master” para vários “slaves”) — não é possível ter um slave a transmitir para dois masters;
  • Tem menor largura de banda face ao Bluetooth clássico (não estando prevista a capacidade de transmissão de voz/áudio).
  • Suporta encriptação forte (AES-CCM 128), no entanto os mecanismos de troca de chaves têm falhas (ver abaixo).

Pelo facto de aparecer associado ao Bluetooth (que é suportado pela esmagadora maioria dos smartphones), assim como por suportar um maior raio de alcance face à tecnologia Near Field Communication (NFC) permitindo maior conveniência/usabilidade, e também pela sua eficiência energética, todos estes factores tornam o protocolo extremamente promissor e candidato a adoção em massa, na área dos wearables e não só:

A maior simplicidade do Bluetooth Smart do ponto de vista das camadas física e lógica do protocolo facilita o estudo dos seus mecanismos de segurança. É significativamente mais fácil fazer análise passiva do protocolo através de network sniffing, uma vez que os mecanismos de “frequency hopping” e “pairing” são mais simples do que os do Bluetooth clássico.

Um dispositivo particularmente útil para testar a segurança do Bluetooth Smart é o Ubertooth One, desenvolvido especificamente para testar Bluetooth / Bluetooth Smart.

Blog ubertooth one

Na SysValue temos um Ubertooth One e estamos particularmente interessados na investigação de:

  • Eventuais vulnerabilidades em comunicações mais sensíveis, p. ex. transmissão de notificações de emails recebidos entre um smartphone e um smartwatch, ou entre uma fechadura física e uma chave Bluetooth;
  • Aplicações de proximidade: P. ex. a capacidade de bloquear/desbloquear um smartphone ou PC com base na proximidade de uma pulseira/relógio Bluetooth;
  • Vulnerabilidades na stack Bluetooth que possam permitir a execução de código em dispositivos vulneráveis;
  • Possibilidade de tracking de pessoas com base em dispositivos Bluetooth e todas as implicações que tal tenha do ponto de vista da privacidade.

Para concluir deixo o link para uma apresentação recente do Mike Ryan da iSEC Partners, que tem investigado a segurança do Bluetooth Smart onde é feita uma exposição do protocolo e demonstradas vulnerabilidades nos mecanismos de pairing (troca de chaves) especificados no protocolo.

Autor: Luis Grangeia @ SysValue