[Cyber Cultura] A Web que queremos

Aproveitando o lançamento da última versão do Firefox, o pessoal da Mozilla lançou uma campanha bem bonitinha em favor da liberdade e privacidade na Internet, batizada de "The Web We Want".

O hotsite da campanha tém um gráfico com estatísticas sobre o que as pessoas em todo o mundo preferem para a Internet:

• Garantia da Privacidade
• Crie oportunidades
• Esteja disponível para todos
• Promova a liberdade
• Inspire a aprendizagem
• Esteja sob controle do usuário

Não é de espantar que, em todo o mundo, a garantia de privacidade foi a opção mais votada pela maioria do pessoal (cerca de 1/3 dos votantes).

[Segurança] Target: a invasão foi identificada... e ignorada.

A recente agitação com o surgimento do bug do Heartbleed e a aprovação do Marco Civil tiraram a minha atenção do caso do roubo de dados da Target. Mas, de qualquer forma, eu já tinha pensado em escrever um artigo comentando um fato bem curioso: as ferramentas de segurança detectaram e alarmaram o ataque na Target, mas a equipe de segurança deles ignorou os alertas! E o resto é história...

Segundo descrito na reportagem sobre este assunto, a solução de antivírus corporativo e uma ferramenta específica usada pela Target detectaram o ataque, mas foram ignoradas pelas equipes de segurança que deveriam ter atuado para evitar o incidente.

O primeiro ponto interessante é que 6 meses antes do ataque, a Target começou a instalar uma ferramenta de detecção de malwares da FireEye, que custou 1.6 milhões de dólares (caraca!!!). Além disso, a Target possui duas equipes de segurança: uma em Bangalore (India) e outra em Minneapolis. Quando a equipe de Bangalore nota algo suspeito, o centro de operações de segurança da Target em Minneapolis deve ser notificado. Pela localização geográfica dessas equipes, dá para supor que o time de Bangalore deve ser um pessoal de SOC para monitoração mais mão na massa em regime de 24x7, enquanto o time americano em Minneapolis deve ser um mini SOC com os gestores, um time de resposta a incidente e provavelmente uma equipe para suporte de 2o ou 3o níveis.

Analisando os logs das ferramentas, a Target percebeu que no dia 30 de novembro de 2013 os hackers fizeram o upload do malware para exfiltração dos dados de cartão de crédito roubados. Isto permitiu que os dados roubados fossem enviados para servidores provisórios espalhados nos EUA e depois para computadores na Rússia. Mas, neste momento, o software da FireEye identificou o upload do malware e gerou alertas. Estes alertas se repetiram no dia 02 de dezembro, quando os hackers instalaram uma outra versão do malware. A ferramenta da FireEye indicou a presença de um malware desconhecido e, inclusive, os endereços dos servidores para onde os dados foram enviados. Pior ainda: a Target tinha desabilitada uma opção para excluir automaticamente o malware quando ele fosse detectado. Até mesmo o sistema de antivírus que a Target usava, o Symantec Endpoint Protection, tinha identificado o comportamento suspeito por vários dias.

O problema é que a tal ferramenta da FireEye enviou os alertas para o time de segurança em Bangalore, que, por sua vez, avisaram a equipe de segurança em Minneapolis. E então...

Nada aconteceu... O time de segurança em Minneapolis não fez nada.

Se estes alertas tivessem sido tratados por alguma das duas equipes de segurança, eles poderiam ter agido cedo o suficiente para evitar que os dados fossem enviados para fora da Target. E todo o incidente poderia ter sido evitado.

No fundo, esta história mostra que não adianta apenas investir em ferramentas de detecção de ataques. Mesmo porque hoje em dia existem dezenas delas que podem gerar milhares de alertas, além dos alertas do Firewall, IPS, anti-vírus, DLP, sistema operacional, etc, etc. Essa salada toda acaba sobrecarregando a equipe de segurança a ponto dela ignorar a maioria dos alertas que recebe. Provavelmente a grande maioria destes alertas não representariam um risco grave e os alertas importantes acabam perdidos em um mar de ruído. Um alerta de vírus sendo atualizado em sua rede jamais deveria passar desapercebido.

É preciso investir no tratamento destes alertas e no correto escalonamento e priorização dos incidentes. E, além disso, a equipe de segurança tem que estar apta a identificar reais problemas e agir rapidamente. e, mesmo assim, corremos o risco de não ver um malware personalizado roubando dados em nossa rede :(

[Cyber Cultura] O Marco Civil é nosso !!!

Hoje, 23/04, a presidenta Dilma sancionou o Marco Civil da Internet (PLC 21/2014) durante o evento Net Mundial, exatamente um dia após ele ser aprovado as pressas pelo Senado. Assim, o Marco Civil se transformou na Lei nº 12.965, de 23 de Abril de 2014.

O Marco Civil surgiu em 2009 como uma forma de oposição ao projeto de leis de ciber crime do Senador Azeredo, e foi criado através da iniciativa popular: o projeto foi redigido coletivamente através de um esforço coordenado pelo Ministério da Justiça, que lançou um site para que a sociedade pudesse enviar contribuições, sugestões e críticas ao texto do Marco Civil. Em 2011 o projeto de lei foi enviado ao Congresso.

Muitas críticas e elogios já foram feitos ao Marco Civil nesse meio tempo. Uma das principais, que ouvi de advogados especializados no assunto, é que a maioria dos artigos são desnecessários, pois apenas reafirmam e repetem leis ou práticas já existentes. Por exemplo, o parágrafo XIII do artigo 7 diz algo estupidamente óbvio e já praticado no mercado: "aplicação das normas de proteção e defesa do consumidor nas relações de consumo realizadas na internet" (caracolas, até eu que sou analfabeto legislativo sei que o código de defesa do consumidor se aplica as relações de consumo !!!).

Desde o começo o Marco Civil apresentou uma visão de oposição a tentativas de regulamentação e legislação da Internet. O principal argumento foi na linha de que deveríamos definir os direitos dos usuários antes de criminalizar o uso da rede. Desta forma, o projeto incluiu alguns temas bem polêmicos:

• A proteção a privacidade e aos dados pessoais dos internautas: diversos artigos abordam este tema, incluindo a obrigação de remover os dados após encerrar seu acesso ao serviço;
• As responsabilidade dos Provedores de Internet, ou melhor, a não responsabilização dos provedores pelo conteúdo. Também define como deve ser o processo de retirada de conteúdo online que seja ofensivo ou ilegal;
• A guarda de logs de acesso, incluindo prazos, controles e direitos dos usuários quanto a monitoração e guarda de logs. O texto aprovado diz que os provedores de acesso devem manter seus logs por apenas 1 ano e os provedores de aplicação devem manter logs por 6 meses (não permitindo a terceirização da guarda dos logs dos provedores de acesso). Pior ainda, ele dá a entender que os provedores somente podem fornecer os logs de acesso a justiça mediante consentimento formal do usuário final (ou seja, será que o ciber criminoso pode optar por negar que o provedor guarde seus logs de acesso e os forneça para a Polícia!?);
• A neutralidade da rede: princípio de que todos os tipos de acesso, pacotes e conexões devem ser tratados igualmente pelos provedores de acesso. Nesse sentido, o maior argumento é que os provedores podem querer cobrar por pacotes de serviço diferenciados (ex: plano para quem acessa e-mail, plano para quem acessa vídeos, etc) ou restringir acessos a serviços específicos (como, por exemplo, download de conteúdos). Embora recentemente isto começou a acontecer nos EUA (com provedores locais limitando acesso ao Netflix), até hoje nunca houve nenhuma restrição de acesso criada pelos provedores Brasileiros, mesmo sem haver regulamentação que os inpedisse de fazê-lo.

Depois dos escândalos de espionagem da RSA, frutos das denúncias do Edward Snowden, o governo brasileiro também tentou incluir algumas cláusulas que abordassem este assunto, que incluía uma proposta esdrúxula de obrigar empresas de Internet a ter uma cópia de seus sites no Brasil, para que os dados dos usuários brasileiros ficassem em território nacional.

De acordo com o site do Senado, o texto final do Marco Civil está disponível aqui (e a versão escaneada aqui). O texto final pode ser visto no site da Presidência da República. Segue abaixo uma transcrição parcial do texto final do Marco Civil, com destaque aos artigos que considero mais relevantes.

CAPÍTULO II

DOS DIREITOS E GARANTIAS DOS USUÁRIOS

Art. 7º O acesso à internet é essencial ao exercício da cidadania, e ao usuário são assegurados os seguintes direitos:
I – inviolabilidade da intimidade e da vida privada, sua proteção e indenização pelo dano material ou moral decorrente de sua violação;
II – inviolabilidade e sigilo do fluxo de suas comunicações pela internet, salvo por ordem judicial, na forma da lei;
III – inviolabilidade e sigilo de suas comunicações privadas armazenadas, salvo por ordem judicial;
IV – não suspensão da conexão à internet, salvo por débito diretamente decorrente de sua utilização;
V – manutenção da qualidade contratada da conexão à internet;
VI – informações claras e completas constantes dos contratos de prestação de serviços, com detalhamento sobre o regime de proteção aos registros de conexão e aos registros de acesso a aplicações de internet, bem como sobre práticas de gerenciamento da rede que possam afetar sua qualidade;
VII – não fornecimento a terceiros de seus dados pessoais, inclusive registros de conexão, e de acesso a aplicações de internet, salvo mediante consentimento livre, expresso e informado ou nas hipóteses previstas em lei;
VIII – informações claras e completas sobre coleta, uso, armazenamento, tratamento e proteção de seus dados pessoais, que somente poderão ser utilizados para finalidades que:
a) justifiquem sua coleta;
b) não sejam vedadas pela legislação; e
c) estejam especificadas nos contratos de prestação de serviços ou em termos de uso de aplicações de internet;
IX – consentimento expresso sobre coleta, uso, armazenamento e tratamento de dados pessoais, que deverá ocorrer de forma destacada das demais cláusulas contratuais;
X – exclusão definitiva dos dados pessoais que tiver fornecido a determinada aplicação de internet, a seu requerimento, ao término da relação entre as partes, ressalvadas as hipóteses de guarda obrigatória de registros previstas nesta Lei;
XI – publicidade e clareza de eventuais políticas de uso dos provedores de conexão à internet e de aplicações de internet;
(...)

CAPÍTULO III

DA PROVISÃO DE CONEXÃO E DE APLICAÇÕES DE INTERNET

Seção I

Da Neutralidade de Rede

Art. 9º O responsável pela transmissão, comutação ou roteamento tem o dever de tratar de forma isonômica quaisquer pacotes de dados, sem distinção por conteúdo, origem e destino, serviço, terminal ou aplicação.
§ 1º A discriminação ou degradação do tráfego será regulamentada nos termos das atribuições privativas do Presidente da República previstas no inciso IV do art. 84 da Constituição Federal, para a fiel execução desta Lei, ouvidos o Comitê Gestor da Internet e a Agência Nacional de Telecomunicações, e somente poderá decorrer de:
I – requisitos técnicos indispensáveis à prestação adequada dos serviços e aplicações; e
II – priorização de serviços de emergência.
§ 2º Na hipótese de discriminação ou degradação do tráfego prevista no § 1º, o responsável mencionado no caput deve:
I – abster-se de causar dano aos usuários, na forma do art. 927 da Lei nº 10.406, de 10 de janeiro de 2002 – Código Civil;
II – agir com proporcionalidade, transparência e isonomia;
III – informar previamente de modo transparente, claro e suficientemente descritivo aos seus usuários sobre as práticas de gerenciamento e mitigação de tráfego adotadas, inclusive as relacionadas à segurança da rede; e
IV – oferecer serviços em condições comerciais não discriminatórias e abster-se de praticar condutas anticoncorrenciais.
§ 3º Na provisão de conexão à internet, onerosa ou gratuita, bem como na transmissão, comutação ou roteamento, é vedado bloquear, monitorar, filtrar ou analisar o conteúdo dos pacotes de dados, respeitado o disposto neste artigo.

Seção II

Da Proteção aos Registros, aos Dados Pessoais e às Comunicações Privadas

Art. 10. A guarda e a disponibilização dos registros de conexão e de acesso a aplicações de internet de que trata esta Lei, bem como de dados pessoais e do conteúdo de comunicações privadas, devem atender à preservação da intimidade, da vida privada, da honra e da imagem das partes direta ou indiretamente envolvidas.
§ 1º O provedor responsável pela guarda somente será obrigado a disponibilizar os registros mencionados no caput, de forma autônoma ou associados a dados pessoais ou a outras informações que possam contribuir para a identificação do usuário ou do terminal, mediante ordem judicial, na forma do disposto na Seção IV deste Capítulo, respeitado o disposto no art. 7º.
§ 2º O conteúdo das comunicações privadas somente poderá ser disponibilizado mediante ordem judicial, nas hipóteses e na forma que a lei estabelecer, respeitado o disposto nos incisos II e III do art. 7º.
§ 3º O disposto no caput não impede o acesso aos dados cadastrais que informem qualificação pessoal, filiação e endereço, na forma da lei, pelas autoridades administrativas que detenham competência legal para a sua requisição.
§ 4º As medidas e os procedimentos de segurança e de sigilo devem ser informados pelo responsável pela provisão de serviços de forma clara e atender a padrões definidos em regulamento, respeitado seu direito de confidencialidade quanto a segredos empresariais.
Art. 11. Em qualquer operação de coleta, armazenamento, guarda e tratamento de registros, de dados pessoais ou de comunicações por provedores de conexão e de aplicações de internet em que pelo menos um desses atos ocorra em território nacional, deverão ser obrigatoriamente respeitados a legislação brasileira e os direitos à privacidade, à proteção dos dados pessoais e ao sigilo das comunicações privadas e dos registros.
§ 1º O disposto no caput aplica-se aos dados coletados em território nacional e ao conteúdo das comunicações, desde que pelo menos um dos terminais esteja localizado no Brasil.
§ 2º O disposto no caput aplica-se mesmo que as atividades sejam realizadas por pessoa jurídica sediada no exterior, desde que oferte serviço ao público brasileiro ou pelo menos uma integrante do mesmo grupo econômico possua estabelecimento no Brasil.
§ 3º Os provedores de conexão e de aplicações de internet deverão prestar, na forma da regulamentação, informações que permitam a verificação quanto ao cumprimento da legislação brasileira referente à coleta, à guarda, ao armazenamento ou ao tratamento de dados, bem como quanto ao respeito à privacidade e ao sigilo de comunicações.
§ 4º Decreto regulamentará o procedimento para apuração de infrações ao disposto neste artigo.
(...)

Subseção I

Da Guarda de Registros de Conexão

Art. 13. Na provisão de conexão à internet, cabe ao administrador de sistema autônomo respectivo o dever de manter os registros de conexão, sob sigilo, em ambiente controlado e de segurança, pelo prazo de 1 (um) ano, nos termos do regulamento.
§ 1º A responsabilidade pela manutenção dos registros de conexão não poderá ser transferida a terceiros.
§ 2º A autoridade policial ou administrativa ou o Ministério Público poderá requerer cautelarmente que os registros de conexão sejam guardados por prazo superior ao previsto no caput.
§ 3º Na hipótese do § 2º, a autoridade requerente terá o prazo de 60 (sessenta) dias, contados a partir do requerimento, para ingressar com o pedido de autorização judicial de acesso aos registros previstos no caput.
§ 4º O provedor responsável pela guarda dos registros deverá manter sigilo em relação ao requerimento previsto no § 2º, que perderá sua eficácia caso o pedido de autorização judicial seja indeferido ou não tenha sido protocolado no prazo previsto no § 3º.
§ 5º Em qualquer hipótese, a disponibilização ao requerente dos registros de que trata este artigo deverá ser precedida de autorização judicial, conforme disposto na Seção IV deste Capítulo.
§ 6º Na aplicação de sanções pelo descumprimento ao disposto neste artigo, serão considerados a natureza e a gravidade da infração, os danos dela resultantes, eventual vantagem auferida pelo infrator, as circunstâncias agravantes, os antecedentes do infrator e a reincidência.

Subseção II

Da Guarda de Registros de Acesso a Aplicações de Internet na Provisão de Conexão

Art. 14. Na provisão de conexão, onerosa ou gratuita, é vedado guardar os registros de acesso a aplicações de internet.

Subseção III

Da Guarda de Registros de Acesso a Aplicações de Internet na Provisão de Aplicações

Art. 15. O provedor de aplicações de internet constituído na forma de pessoa jurídica e que exerça essa atividade de forma organizada, profissionalmente e com fins econômicos deverá manter os respectivos registros de acesso a aplicações de internet, sob sigilo, em ambiente controlado e de segurança, pelo prazo de 6 (seis) meses, nos termos do regulamento.
§ 1º Ordem judicial poderá obrigar, por tempo certo, os provedores de aplicações de internet que não estão sujeitos ao disposto no caput a guardarem registros de acesso a aplicações de internet, desde que se trate de registros relativos a fatos específicos em período determinado.
§ 2º A autoridade policial ou administrativa ou o Ministério Público poderão requerer cautelarmente a qualquer provedor de aplicações de internet que os registros de acesso a aplicações de internet sejam guardados, inclusive por prazo superior ao previsto no caput, observado o disposto nos §§ 3º e 4º do art. 13.
§ 3º Em qualquer hipótese, a disponibilização ao requerente dos registros de que trata este artigo deverá ser precedida de autorização judicial, conforme disposto na Seção IV deste Capítulo.
§ 4º Na aplicação de sanções pelo descumprimento ao disposto neste artigo, serão considerados a natureza e a gravidade da infração, os danos dela resultantes, eventual vantagem auferida pelo infrator, as circunstâncias agravantes, os antecedentes do infrator e a reincidência.
Art. 16. Na provisão de aplicações de internet, onerosa ou gratuita, é vedada a guarda:
I – dos registros de acesso a outras aplicações de internet sem que o titular dos dados tenha consentido previamente, respeitado o disposto no art. 7º; ou
II – de dados pessoais que sejam excessivos em relação à finalidade para a qual foi dado consentimento pelo seu titular.
Art. 17. Ressalvadas as hipóteses previstas nesta Lei, a opção por não guardar os registros de acesso a aplicações de internet não implica responsabilidade sobre danos decorrentes do uso desses serviços por terceiros.

Seção III

Da Responsabilidade por Danos Decorrentes de Conteúdo Gerado por Terceiros

Art. 18. O provedor de conexão à internet não será responsabilizado civilmente por danos decorrentes de conteúdo gerado por terceiros.
Art. 19. Com o intuito de assegurar a liberdade de expressão e impedir a censura, o provedor de aplicações de internet somente poderá ser responsabilizado civilmente por danos decorrentes de conteúdo gerado por terceiros se, após ordem judicial específica, não tomar as providências para, no âmbito e nos limites técnicos do seu serviço e dentro do prazo assinalado, tornar indisponível o conteúdo apontado como infringente, ressalvadas as disposições legais em contrário.
§ 1º A ordem judicial de que trata o caput deverá conter, sob pena de nulidade, identificação clara e específica do conteúdo apontado como infringente, que permita a localização inequívoca do material.
§ 2º A aplicação do disposto neste artigo para infrações a direitos de autor ou a direitos conexos depende de previsão legal específica, que deverá respeitar a liberdade de expressão e demais garantias previstas no art. 5º da Constituição Federal.
(...)
Art. 20. Sempre que tiver informações de contato do usuário diretamente responsável pelo conteúdo a que se refere o art. 19, caberá ao provedor de aplicações de internet comunicar-lhe os motivos e informações relativos à indisponibilização de conteúdo, com informações que permitam o contraditório e a ampla defesa em juízo, salvo expressa previsão legal ou expressa determinação judicial fundamentada em contrário.
(...)
Art. 21. O provedor de aplicações de internet que disponibilize conteúdo gerado por terceiros será responsabilizado subsidiariamente pela violação da intimidade decorrente da divulgação, sem autorização de seus participantes, de imagens, de vídeos ou de outros materiais contendo cenas de nudez ou de atos sexuais de caráter privado quando, após o recebimento de notificação pelo participante ou seu representante legal, deixar de promover, de forma diligente, no âmbito e nos limites técnicos do seu serviço, a indisponibilização desse conteúdo.
(...)

CAPÍTULO IV

DA ATUAÇÃO DO PODER PÚBLICO

Art. 24. Constituem diretrizes para a atuação da União, dos Estados, do Distrito Federal e dos Municípios no desenvolvimento da internet no Brasil:
(...)
V – adoção preferencial de tecnologias, padrões e formatos abertos e livres;
VI – publicidade e disseminação de dados e informações públicos, de forma aberta e estruturada;
(...)
VIII – desenvolvimento de ações e programas de capacitação para uso da internet;
(...)

Para tentar manter este post relativamente curto, eu nem me dei ao trabalho de copiar o Marco Civil na íntegra, e fiz questão de pular os capítulos I, IV (suprimido aqui em grande parte) e V. Em minha opinião, o Capítulo I contém um monte de obviedades e os dois últimos capítulos (IV e V - das disposições finais) contém muito blá-blá-blá juidiquês e uma boa dose de politicagem relacinada a inclusão digital.

Nota: post atualizado em 24/4 com as referências para o texto final do Marco civil, transformado em Lei, conforme consta no site da Presidência da República.

[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 Kbytes, que 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...

[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.

[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 !!!

[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?

• O pessoal do OpenSSL publicou um pequeno Advisory que indica quais são as versões vulneráveis: 1.0.1 e 1.0.2-beta, incluindo todas as versões até 1.0.1f e 1.0.2-beta1.
• Para corrigir o problema, deve-se fazer o upgrade para a versão 1.0.1g ou recompilar o seu OpenSSL com a opção -DOPENSSL_NO_HEARTBEATS
• Teste se a sua versão do OpenSSL é vulnerável
• O site do Heartbleed tem muita informação sobre o bug em formato de uma longa FAQ
• O Sandro Suffert publicou uma lista com vários detalhes e dicas

Pequeno update (24/4): a N-Stalker lançou uma ferramenta gratuita para testar se o servidor está vulnerável ao bug do Heartbleed.

[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.