abril 17, 2014

[Segurança] The Day Our Privacy Died

Vídeo muito divertido para celebrarmos a falta de privacidade na era pós-Snowden, provavelmente divulgado no The eMetrics Summit, SF 2014:




Segue a letra:
Long, long time ago
I can still remember how the Internet used to make me smile.
And I knew if I had my chance
I could overcome the rants
Crybabies whining their data was compiled

But Julien Assaunge made me shiver
With every WikiLeak he delivered.
Bad news on my modem
And then came Edward Snowden.

I don't remember if I cried
When we learned of NSA Inside
Open source and greed collide
The day our privacy died.

And we were singing
Bye-bye anonymity lie
Trusted Facebook with my data but Mark Zuck was not shy
He sold it to the bidders cause the bidders were high
And Amazon knows everything that I buy
Amazon knows everything that I buy

Hey do you Like the things I love.
And do you have faith in Cloud above.
If Hype Cycle tells you so?
Now do you believe that it's just you two
In a conversation twixt her and you.
The walls have ears and you know that Google does too.

Google knows that you're in love with him.
Cause you Instagramed him in the gym.
You both tweeted out the news
As if you had nothing to lose.

I was a lonely teenage gaming nerd.
Hacking a rip off of Angry Birds
Until their lawyers overheard
The day our privacy died.

And we were singing bye-bye communication blue sky
I tried Twitter as transmitter but the ads were bone dry
Baffling noise drowned the signal's bull's eye
And opt-in's just a new way to spy
Opt-in's just a new way to spy

Now for 10 years we were clicking wild.
Thinking no one would want to track this child.
But that's only how it used to be.
When the ad men sang for the biggest brands
They had 'em eating out of their hands
And the Mad Men said tracking's for you and me.

Oh, and while the brands were placing bets
The hackers stole their data sets.
The firewalls were burned
No data was returned.

And while Bill Gates read a book on Jobs
Merchants prayed to data gods
Our cries were turned to sniffling sobs
The day our privacy died

And we were singin' Hi, Hi to the new FBI
I'm just frozen by my modem cause my modem's a spy
And government boys are hanging off my wi-fi
Singin' there's no place left you can hide.
There's just place left you can hide

I met a girl who warned of laws
Of nation's rules causing data withdrawals
But merchants smiled and turned away.

I went down to the sacred store
The iBeacon followed me through the door
And the man there said that prying was the only way

And in the streets, the tweeters scowled
The Tumblrs cried, SnapChatters growled
But not a word was spoken
Resistance all was broken

And the three ideas I admire the most
Opinions, views and the thoughtful post
They caught the last train for the coast
The day our privacy died

We were singin' bye-bye, info we want to hide
Our data's been translated to the money supply
Our phones are tracking us wherever we fly
This science seems to be misapplied.

[Segurança] Presidência do capítulo brasileiro da Cloud Security Alliance

Estou assumindo a posição de novo presidente do capítulo brasileiro da Cloud Security Alliance (CSABR), em substituição ao presidente anterior, o Paulo Pagliusi, que assumiu o cargo de vice-presidente.

Antes de mais nada, preciso agradecer ao trabalho e ao interesse incansável de todos os participantes da CSABR, que nos fez chegar até aonde estamos. Em particular, temos que reconhecer a dedicação dos presidentes anteriores: o Leonardo Goldim, que teve a coragem de trazer a CSA para o Brasil, e fomos o segundo capítulo em todo o mundo! Em seguida vieram o André Serralheiro que deu um novo ritmo ao capítulo e o dedicado Paulo Pagliusi, que trouxe grande experiência e visão. Para mim foi um prazer trabalhar com todos eles.

Por isso, assumir a presidência do capítulo é, acima de tudo, uma grande honra e uma grande responsabilidade. E espero contribuir para uma trajetória de sucesso crescente da CSABR. Nós ainda estamos muito longe de onde gostaríamos, mas ao mesmo tempo caminhamos muito considerando os poucos recursos que temos.

O mercado de Cloud Computing continua em franco crescimento, mesmo após os escândalos de espionagem que surgiram no ano passado e a crescente preocupação com a privacidade (algo muito válido, diga-se de passagem). O mercado de segurança para Cloud Compiting também está crescendo e amadurecendo, as vezes por conta de novas regulamentações, de novas tecnologias ou mesmo por causa de novos incidentes, que servem de lição para os profissionais da área. Afinal, trabalhar com segurança da informação é um desafio constante!

Nosso papel, como profissionais de segurança, é garantir como usuários e empresas podem adotar as novas tecnologias com os devidos controles e salvaguardas.

[Segurança] Bug do Heartbleed e o que realmente pode ser acessado

Muito já tem sido dito e discutido sobre os perigos do bug do Heartbleed, em especial sobre o risco das empresas terem informações roubadas. Há relatos de acesso a chaves criptográficas, e facilmente se especula na imprensa que muita coisa pode ser roubada por ciber criminosos, incluindo certificados digitais, nomes de usuários, senhas, mensagens de instant message, emails e documentos ou comunicações de empresas (como diz o próprio site sobre o bug).

A verdade é que somente informações acessadas através do OpenSSL podem ser roubadas pelo atacnate, se ele tiver sorte. Ou seja, somente o que a vítima acessar via SSL (por exemplo, páginas ou documentos que visualize ou faça o download via https) no momento em que o atacante explora o bug.

Isto acontece porque o bug do Heartbleed faz com que o servidor OpenSSL responda requisições do protocolo Heartbeat com trechos de memória de tamanho indicado pelo atacante, que pode ser de 1 até 64KB. Ou seja, o protocolo de Heartbeat do TLS foi desenvolvido para que o cliente e o servidor fiquem mandando dados entre eles para manter a conexão ativa: um lado manda a requisição de heartbeat, com uma string qualquer, e o outro lado manda, como resposta, a mesma string de volta. Segundo a RFC, o payload (resposta) é formado pelo conteúdo do request ("the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest").

Desta forma, o solicitante envia uma quantidade de dados (chamada de "payload", e que deve ser devolvida) e informa qual é o tamanho desse conjunto de dados, mas informa um número maior do que o tamanho real, até no máximo 64*1024. Por exemplo, ele envia a mensagem "teste" e, em vez de dizer que o tamanho é 5, diz que são 65.535 caracteres. Assim, por causa do bug, o OpenSSL não verifica o tamanho real, acredita no que foi informado e, ao tentar devolver a mensagem original ("teste", neste exemplo), ele extrai blocos de memória do servidor e devolve isso tudo. O OpenSSL usa o memcpy (que é inseguro) para jogar um bando de dados de memória como a resposta do heartbeat. E, nessa hora ele poderia acessar outras áreas de memória do processo, dependendo de como o servidor está alocando a memória.



Assim, a cada vez que explora o bug, o atacante recebe de presente um bloco de memória de, no máximo, 64 KB (64 Kbytesque corresponde a 65.535 caracteres). Logo, o atacante pode ficar rodando o seu script que explora o bug e, assim, vai extrair centenas ou milhares de blocos de memória  até não aguentar mais (fácil, já tem script para fazer isso). Em seguida ele tem que juntar todos esses blocos de memória e caçar as informações que deseja no meio disso tudo.

É importante notar que o atacante terá acesso somente a área da memória heap do processo OpenSSL. Ele não vai ter acesso a memória de todo o servidor !!! Isto porque não tem como o leak de memória do OpenSSL dar acesso a memória de outros processos. Isso não está claro em nenhum lugar, mas nos sistemas operacionais modernos cada processo tem sua área de memória virtual. Antigamente todos os processos compartilhavam a mesma visão da memória, mas isso não acontece mais. Somente vulnerabilidades no kernel do S.O. permitem acessar áreas de outros processos.

O advisory minúsculo do OpenSSL só cita "reveal up to 64k of memory", enquanto o site do Heartbleed.com (que está mais para fazer FUD do que para dar detalhes técnicos de qualquer coisa) não fala em nenhum momento qual área de memória pode ser acessada pelo bug (ele só fala que "The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software." Ou seja, ele fala que afeta a "memória do sistema"). A página do CVE também não diz muitos detalhes, apenas fala que "allows remote attackers to obtain sensitive information from process memory" (isto é, acessa a área de memória do processo) e nem o Bruce Schneier ajudou muito: "Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory." Ou seja, pela grande maioria do que se lê por aí, não dá para ter certeza de como o bug afeta os sistemas vulneráveis.

E afinal das contas, o que o atacante pode conseguir?
  • Os dados da sua sessão SSL ativa, que estavam sendo tratados em memória: Se, por azar, você estava logado na hora que o hacker roubou os blocos de memória do servidor e, naquele momento, os dados da sua sessão estavam sendo tratados em memória, aí o atacante pode ter conseguido roubar seus dados que estavam sendo criptografados naquele momento. Basicamente, são os conteúdos das páginas que você estava navegando: dados de usuário e senha se você acessou a página de login naquele momento, ou o cookie de sessão. No pior caso o atacante teve a sorte de capturar o bloco de memória referente a conexão aonde o usuário fez o login e ele roubou a senha. Ou você estava acessando seu GMail ou o webmail da empresa e o atacante leu um trecho de 64K do seu e-mail.
  • Se ele tiver muita sorte, o hacker conseguiu roubar blocos de memória que tinham a chave privada de criptografia: aí ele consegue levantar um servidor falso com o certificado digital igual ao seu ou, se ele tiver cópia de todo o tráfego, ele consegue descriptografar tudo. Mas, para isso, ele vai ter que interceptar todo o tráfego de rede do servidor (deve fazer isso online ou ter uma cópia dos pacotes de rede em um arquivo). Mais cedo ou mais tarde a chave privada vai vazar, mesmo por que o TLS no lado do servidor precisa da chave privada em memória para fazer o handshake do TLS. E aí nessa hora a chave pode vazar.
  • O atacante conseguiu roubar blocos de memória que tinham a chave de criptografia de sessão de alguma sessão SSL. Aí, além de ter que capturar o tráfego para conseguir decifrar algo, a chave de sessão é uma chave simétrica que vale só para um acesso específico. Isso é muito menos calamitoso do que o caso anterior.

Resumindo o que foi dito acima, o atacante pode ter a sorte de capturar os dados criptografados através da sua sessão SSL. O mais arriscado são os nomes de usuário e senhas e, eventualmente, as chaves privadas associadas ao certificado digital do servidor. Mas o maior problema relacionado ao roubo do certificado não é alguém usar isso para decriptografar os seus dados: o maior risco é usarem estas chaves privadas para criarem certificados digitais para sites fraudulentos, e assim, atacar usuários com mensagens de phishing. Dá para fazer uma bela festa com isso...

abril 13, 2014

[Segurança] O bug do Heartbleed for Dummies

O Adriano Cansian divulgou recentemente um texto que explica de uma forma bem simples e objetiva o que é o bug do Heartbleed e qual é o impacto dele. Para quem não o conhece, o Adriano é um profissional muito experiente e respeitado na área de segurança, professor da UNESP de São José do Rio Preto e coordenador de um grupo de pesquisas de segurança UNESP chamado ACME! Cybersecurity Research Labs.

Eu recebi o texto abaixo através de uma lista de discussão e acredito que ele merece ser compartilhado. Parabéns ao Adriano pela iniciativa :)

Observação: só para evitar mal entendidos, o título "for Dummies" deste post é porque o texto é bem simples e voltado para leigos. Não é minha intenção dar nenhuma conotação negativa.

* O QUE É O HEARTBLEED

Heartbleed é o nome que foi dado a um problema no sistema OpenSSL. O OpenSSL se trata de uma biblioteca de softwares que é usada pela maioria dos sites para garantir a sua comunicação utilizando um sistema de segurança chamado "SSL". Ele fornece  o "S" de "security"  nos endereços da Internet que começam com HTTPS, ou se você preferir, é ele o responsável pelo ícone de cadeado na barra de endereços do seu navegador enquanto você navega na web.

Normalmente, quando navegando em um site usando SSL, você pode confiar que a informação que você envia para o site só pode ser vista pelo próprio site. Isso mantém seguras as sua informações privadas, tais como cartões de crédito, nomes de usuário e senhas.

A exploração da falha Heartbleed permite que atacantes contornem as proteções fornecidas pelo SSL. Isso significa que todas as informações que você enviou para um site que teve versões vulneráveis do OpenSSL podem já estarem nas mãos dos bandidos. A exploração desta vulnerabilidade é silenciosa e não deixa nenhuma pista ou registro do acontecido. Não é possível determinar se você foi ou não afetado.

Os sites mais importantes já corrigiram a falha, entretanto as suas e as minhas informações pessoais e, principalmente, nossas senhas, podem ter vazado para as mãos de pessoas má intencionadas. Insisto: não é possível determinar se você foi ou não afetado.

* ATUALIZE SUAS SENHAS

Há uma boa chance que você tenha utilizado sites vulneráveis. A reação impensada a esta notícia é mudar todas as suas senhas imediatamente. Mas, ainda que eu esteja realmente recomendando que você mude suas senhas, é importante entender que nem todos os sites já foram atualizados, para proteger contra essa vulnerabilidade.

O melhor conselho que tenho, no momento, é que você  mude suas senhas dos sites mais importantes de imediato, incluindo seu e-mail, suas contas bancárias, suas redes sociais, e outros alvos de alto valor para você. Isto irá fornecer, insisto, no momento, a sua melhor defesa contra os ataques anteriores.

Depois de algumas semanas os sites terão sido atualizados com novos certificados SSL, e seremos capazes de confiar novamente no SSL. Então, neste ponto, você deverá mudar todas as suas senhas novamente, por precaução.

* COMO ESCOLHER UMA SENHA SEGURA

Pense numa frase que seja fácil de memorizar e que contenha números. Depois pegue as primeiras letras e números da frase, com letras maiúsculas e minúsculas, forme a senha com eles, e comece ou termine com um símbolo. Exemplo:

Minha mãe Olivia tinha 25 anos quando casou
Senha: %MmOt25aqc%

Eu tenho 13 albuns do Pink Floyd!!
Senha: =Et13adPF!!

Estas são senhas seguras, difíceis de serem quebradas ou adivinhadas. Qualquer coisa diferente disso é fácil de ser quebrada.

* DEDIQUE ALGUM TEMPO A ISSO, COM SERIEDADE

O Heartbleed é uma questão realmente muito séria para a Internet e para sua segurança. Trata-se de uma grave ameaça à infra-estrutura crítica da Internet. Então você deve dedicar algum tempo para atualizar suas senhas. Eu não estaria lhe dizendo isso se a questão não fosse realmente grave.

Idealmente você deve mudar todas as suas senhas, mas, no mínimo, por favor atualize aquelas dos sites mais importantes. Senhas novas, fortes e únicas são sua melhor defesa contra Heartbleed.

* COMPARTILHE O CONHECIMENTO

Por favor, compartilhe notícias de Heartbleed com seus amigos e família. Basta encaminhar este e-mail. Este será um grande primeiro passo para ajudá-los a saber que este é um problema muito, muito, sério. Nos últimos dias nossa equipe de analistas dedicou muito tempo para alertar pessoas, empresas e instituições e também para ajudar sanar o problema, compartilhando e informando sobre a sua gravidade.

Espero que você também seja capaz de transformar esta crise numa oportunidade para o bem, assim como estamos fazendo.

abril 11, 2014

[Segurança] Como o bug do Heartbleed funciona

Até o momento apareceram duas ótimas referências que explicam tecnicamente como o bug do Heartbleed funciona.

O primeiro é um artigo no blog existential type crisis, aonde o autor destrinchou o que aconteceu e o que foi corrigido no código do arquivo ssl/d1_both.c, um dos dois lugares no OpenSSL em que foi feita a correção. Este arquivo contém a função que processa o heartbeat do SSL. Ele aponta exatamente em que lugar no código o desenvolvedor esqueceu de verificar o tamanho do payload para evitar que o tamanho da resposta fosse maior do que o payload (e, assim, iria invadir uma área adjacente de memória na hora de copiar o payload que o servidor recebeu para enviá-lo na resposta).

A segunda ótima explicação, fácil de entender, foi criada pelo pessoal do XKCD.


Simplesmente brilhante !!!

abril 09, 2014

[Segurança] Heartbleed: o bug que faz o SSL sangrar...

De repente chegaram dezenas de mensagens nas listas de discussão, Twitter e até mesmo no Facebook sobre isso...


No dia 07/Abril foi divulgado um bug muito sério no OpenSSL, batizado de Heartbleed (CVE-2014-0160), que é causado por uma falha de implementação no TLS que permite ao atacante obter dados da memória do servidor.

Explorando essa vulnerabilidade, um atacante consegue obter vários blocos aleatórios da memória do servidor SSL, de 64 KB de tamanho cada, e assim remontar esses blocos de dados e ter acesso aos dados que estõa sendo tratados pelo servidor, tais como os dados criptografados na navegação do usuário (mensagens, senhas, etc) e até mesmo as próprias chaves de criptografia utilizadas pelo servidor.

O Bruce Schneier (pausa para babação de ovo) considerou o bug do Heartbleed como uma vulnerabilidade catastrófica ("de 0 a 10, merece 11").

Mas não é para menos, pois essa vulnerabilidade na biblioteca criptográfica do OpenSSL afeta milhões de servidores web em todo o mundo, uma vez que o OpenSSL é utilizado nos servidores Apache e nginx, dois dos softwares mais populares para servidores web: os dois juntos representam cerca de 66% dos sites ativos na Internet. Além disso, o OpenSSL é usado para proteger servidores de e-mail, é usado em redes privadas virtuais (SSL VPNs), e até mesmo em dispositivos de rede e diversos outros softwares. Segundo estimativas da Netcraft, 17,5% dos servidores SSL em todo o mundo estão vulneráveis ao bug, representando cerca de meio milhão de sites.



Oh! E agora, quem poderá nos defender?

abril 04, 2014

[Cyber Cultura] Table Top Day

O Will Wheaton (que, adimito, eu só sei quem é porque assisto o Bing Bang Theory) tem um projeto muito legal chamado TableTop: um site e diversos vídeos no YouTube aonde ele explica como jogar vários jogos de tabuleiro.

Os vídeos são super bem feitos, engraçados, educativos e ensinam como jogar vários jogos de tabuleiro, do tradicional e bem conhecido Catan e o Munchkin a vários outros como o Forbidden Island (que temos no Garoa e é bem divertido de jogar).

Neste sábado, dia 05 de abril, será o Table Top Day, um evento em vários lugares do mundo para as pessoas jogarem jogos de tabuleiro.


março 31, 2014

[Cyber Cultura] Edward Snowden no TED

O Edward Snowden deu uma palestra recentemete no TED, chamada "Here's how we take back the Internet" (também disponível no YouTube).

Filmada na conferência TED 2014 em 18 de Março deste ano, a palestra durou aproximadamente 35 minutos (sim, ela é longa comparada com o que costumamos ver nos vídeos do TED). O interessante é que ele deu a palestra através de tele-presença, utilizando um robozinho com uma tela aonde podemos ver o seu rosto, e através do qual ele também podia ver a platéia.



Nesta palestra, o Snowden comenta o impacto suas revelações, suas motivações, e também detalha algumas das principais informações que ele tornou público sobre a estrutura de espionagem e inteligência criada pela NSA.

Dois dias depois, o diretor da NSA Richard Ledgett deu sua resposta a palestra do Snowden, no próprio TED, aonde apresentou a visão da NSA sobre o Snowden e suas revelações.

março 30, 2014

[Segurança] Gráfico de Ataques da Kaspersky

Através do blog do Coruja de TI, fiquei sabendo que a Kaspersky lançou o site chamado Cyber Warfare Real Time Map que mostra uma animação muito bem feita ilustrando os ciber ataques em tempo real pelo mundo. O mapa usa dados coletados pelas soluções de segurança da Kaspersky para ilustrar diversos ataques que acontecem em todo o mundo, indicando o tipo de ataque, origem e destino.

O resultado é um mapa interativo, dinâmico, visualmente muito bonito e chamativo.







Entretanto, vale a pena notar que os dados são bem superficiais: há pouca informação sobre os tipos de ataques, e nenhum detalhe: o site apenas mostra os totais de ataques por países.

Também vale mencionar que, embora o título do site e do gráfico indique que se tratem de ataques relacionados a guerra cibernética ("cyber warfare"), não há nenhuma informação que comprove isso. A menos que você acredite que realmente aconteçam tantos ataques relacionados a guerras cibernéticas diariamente (o que eu duvido, e muito), me parece que na verdade este gráfico mostra qualquer tipo de ataque, ou seja, incluindo principalmente ataques comuns do dia-a-dia, como infecção de vírus e simples scans de rede.

Ou seja: o gráfico é bem legal, mas tem pouca utilidade prática e o título desmerece o trabalho por ser inadequado e exagerado (algo que costumamos chamar de FUD).

[Cyber Cultura] Visite o Datacenter do Google

Há algum tempo atrás o Google criou um passeio virtual em um dos seus datacenters através do Streetview, o datacenter de Lenoir, na Carolina do Norte.

A "tour" é meio limitada, não dá para ir na maioria dos lugares, exceto em um trajeto bem específico. Para quem já conhece algum grande datacenter por dentro (isto é, um DC grande e organizado, pois nem todos os que existem por aí merecem uma visita), não há muitas novidades aparentes em termos de infra-estrutura. O que me chamou mais a atenção foram algumas "cortinas" entre alguns conjuntos de rack, que eu acredito que sejam utilizadas para fazer um isolamento do ar nos corredores de rack por onde circulam ar quente (pois neles estão direcionadas as saídas de ventilação dos servidores e equipamentos). Também é interessante passear pela área externa da sala de servidores, aonde ficam os escritórios, e ver várias coisinhas que você nunca veria em um datacenter brasileiro, como um bar, mesas de ping-pong, sofás, uma sala com geladeiras com refrigerantes e sucos, etc.

Fora os aspectos técnicos, é um passeio virtual divertido, com alguns detalhes interessantes, tais como...

  • Um Stormtrooper vigiando os racks, acompanhado por um mini R2-D2:




  • Não é possível navegar nesta sala, mas deu para descobrir que ela tem, nada mais nada menos, 90 conjuntos de racks:



  • Um boneco gigante do Android dentro de um cercado de racks, em uma ante-sala do datacenter, aonde ficam as unidades de fitas de backup de dados:



  • Uma mesa de pebolim (também conhecido como "totó") no escritório:



  • Meu Deus... o que é isso?



  • Em um dos quadros de aviso, há um documento com o título "Información sobre Compensación Laboral", mas não dá para ler o texto do aviso :(


Também é interessante dar uma olhada no vídeo sobre este datacenter. Notem que no vídeo os detalhes engraçadinhos ainda estão lá, mas passam quase desapercebidos.


Creative Commons License
Disclaimer: The views expressed on this blog are my own and do not necessarily reflect the views of my employee.