segunda-feira, 21 de abril de 2014

__name__ == '__main__'

Para os iniciantes em Python, com certeza já se deparou e ficou curioso o que quer dizer __name__ == '__main__' no final do script, right?
Irei explicar isso na prática... Vamos começar fazendo um simples script (utilizo o Python 3, porque é foda e mais tarde explicarei o porquê).

Abra aí o seu shell e escreva:
cd desktop && mkdir popo && cd popo && echo print (__name__) > slayerowner.py


Agora note que foi criado um simples script .py no diretório popo.
Beleza temos um script, já sabemos que podemos usar ele como programa (executando na linha de comando) ou módulo (fazendo a importação), Executando ele na linha de comando, olhe o que nos dar em retorno..

Assim que executa o script, simplesmente executa e sai normalmente, o que não tem nada de errado.
Se importarmos esse print __name__ para o interpreter, vai imprimir o nome do arquivo.


O __main__ é algo que todo script python quando é executado na linha de comando recebe. Logo então __name__ == '__main__' serve para averiguar se o script está sendo executado na linha de comando ou sendo importado. Agora você se pergunta: "Isso serve pra que cara? 0_o".
Pense em um script com algumas funções no começo dele sendo declarada e logo no meio/final estão usando-os para receber os valores como quisera.


#!/usr/bin/env python

def int(x):
 return x - 9
def float(x):
 return x**5/2
 
print (int(4))
print (float(20))


resultado:
-5
1600000.0

Então aí você pensa: "Mas eu não queria esses valores, quero utilizar as funções na qual está disponível no script". É nessa hora que editamos o script para:

#!/usr/bin/env python

def int(x):
 return x - 9
def float(x):
 return x**5/2

if __name__ == '__main__':
 print (int(4))
 print (float(20))

Nesse estado o resultado da execução vai ser diferente se o __name__ for igual à __main__, ou seja se for executado em linha de comando ou usado como módulo.

segunda-feira, 14 de abril de 2014

Resenha sobre o HeartBleed.

Pois bem, acho que todos já ouviram falar desta tal vulnerabilidade assombrando muitos webadmins e outros responsáveis por segurança na qual utiliza o famoso projeto OpenSSL. Depois dessa enorme repercussão em todo o mundo. Tantos Vulnerability Researcher propuseram de descreverem seu ponto de vista, críticas e comentar sobre a tal falha em seus grandes blogs e Vlogs, como: SecurityAttack, BrasilPentest, 100Security, The Hackers News, Garage4Hackers, Anchisesbr, UnknownSec, Security Affairs, Eli the Computer Guy, NerdAlert, Fierce Outlaws e entre muitos outros quem compartilharam excelentes conteúdos. Enfim, tive a ideia de fazer uma resenha explicando o que compreendo e tenho acompanhado até então, em apenas 1 postagem. Vejamos...

O que é SSL/TLS e como funciona?
O antecessor de TLS, Secure Sockets Layer (SSL = Camada de Sockets Segura). Um protocolo responsável por criptografar dados mantendo então uma segurança de seus dados durante a transferência.
A comunicação entre o cliente e o servidor funciona de uma maneira nada complexo. Sendo o primeiro passo seria a ação daquele que estabelece a conexão TCP, Three-Way Handshake[1]. Então quando o Cliente envia algum pacote (Client: Hello World) para o servidor, o mesmo confirma o recebimento enviando um ACK (é um recibo de recebimento) para o cliente e envia outro pacote (Server: Hello World). Para confirmação, o Cliente também envia o ACK, assim o Servidor envia ao Cliente uma parte pública do certificado digital (Server: x509 certificate > formato padrão para certificados digitais, utilizado no SSL), mantendo consigo a parte privada. O Cliente manda o recibo de confirmação novamente para o Servidor (Client: ACK), então começa o compartilhamento de chaves entre os dois.
Note que o Cliente já obteve sua parte do certificado digital, onde a partir daí ele consegue informações que ele pode usar, dependendo de qual cifra foi estabelecida para o uso entre eles, logo entra em outra fase onde usam um conceito de algoritmos assimétricos para realizar o Shared Key Exchange (Troca de Chave Compartilhada), o que é necessário para fazer o resto da negociação, Encrypted Handshake Message. Nada mais é do que uma amostra de uma mensagem criptografada, para assegurar que as trocas de chaves foram estabelecidas corretamente, para que os dois conseguem ler as mensagens criptografadas. Contudo o tráfego assegurado por SSL acontece logo à seguir, no Application Data, a parte da comunicação segura dos dados, ou seja, as outras ações ocorridas até então é apenas para negociar o protocolo SSL.
Ficando assim[2]:
1 - Three-Way HandShake (SYN, SYN ACK, ACK)
2 - Client Message Package
3 - Server ACK Package
4 - Server Message Package
5 - Client Message Package
6 - Server: x509 Certificate
7 - Client ACK
8 - Shared Key Exchange
9 - Encrypted Handshake Message
10 - Application Data

O HeartBleed, é uma vulnerabilidade extrema ocorrida no openSSL.
"Essa fraqueza permite roubos de informações protegidas, dentro de suas condições normais, pela criptografia SSL/TLS, usada pra proteger a Internet. SSL/TLS fornece comunicação de segurança e privacidade por toda Internet tais como web, email, mensagem instantânea (IM) e alguns VPNs 
 O Bug Heartbleed permite qualquer um da Internet, ler a memória do sistema protegida pela versão vulnerável do OpenSSL. Que compromete as chaves secretas usadas para identificar os fornecedores de serviços e para criptografar o tráfego, os nomes e senhas de usuários e o conteúdo atual. Permite os atacantes espionar as comunicações, roubar informações diretamente dos serviços e os usuários e para representar usuários e serviços" - [3]
Interpretando bem o texto, sabemos que não é apenas uma página web que possa estar vulnerável, entre tanto qualquer outro aplicativo, até mesmo os App para mobiles também podem estar correndo um grande riscos, é isso mesmo produção? Sim, Slayer! Fora inúmeros websites e empresas, tais como: Facebook, Google, Yahoo, Cisco, FIFA, DropBox e etc. Temos fontes de outros acontecimentos peculiares em relação à isso. Por exemplo:

1- No Canada, hackers exploraram 'confirmados' 900 cidadãos e um X número não confirmados de empresas. O 'Canada Revenue Agency' (CRA) foi notificado pelo Governo de maliciosa violação dos dados contribuintes que ocorreram ao longo do período de 6 horas.[4]

2- Google afirma que Mobiles e Tables com seu sistema operacional também estão em risco, porém com a correção já criada, ainda precisam fazer algo para dispositivos que não podem executar versões superiores do OS[5], Nisso também incluia o BlackBerry (BBM), o famoso aplicativo para sistemas Android e iOS.[6]

3- Um dos líderes entre jogos de tiro/ação 'Call of Duty: Black Ops II' e outro jogo MMORPG também da Steam 'South Park: The Stick of Truth', tiveram o título editado para a seguinte frase: 'Valve please reset all partner logins because heartbleed' (Valve, favor resetar todos os logins de parceiros por causa do Heartbleed). Próprios usuários procuraram algumas soluções relacionados à Ubsoft e Obsidian da Steam e mudaram o título em esperança de uma rápida correção vinda da Valve. Enquanto a Ubsoft e a Obsidian não comentaram nada sofre o problema, a Valve avisou que o problema já foi corrigido e sugestão para alteração de senha e reiniciar o Steam Guard, como prevenção.

NSA, o pai da humildade e disciplina, não querendo ficar de fora (lógico né), afirma ter explorado esta vulnerabilidade nos últimos 2 anos. (True or False?)
Whatever, o c0der Alemão quem cometeu o erro, Robin Seggelmann, disse que "infelizmente", o bug que apresentou a falha passou por ele e por um revisor quando foi introduzido para o protocolo de criptografia OpenSSL fonte aberta há mais de dois anos.

"Eu estava trabalhando para melhorar o OpenSSL e apresentado inúmeras correções de bugs e adicionado novas funcionalidades...
 [...] Em um dos novos recursos, infelizmente, eu perdi a validação de uma variável que contém um comprimento." - disse Seggelmann
 Depois ele apresentou o código, para o revisor que aparentemente também não notou a falta validação,
"Então o erro fez o seu caminho do ramo de desenvolvimento para a versão lançada." 
Os registros mostram que revisor foi o Stephen Henson. Seggelmann disse que o erro que ele apresentou foi "trivial", mas reconheceu que seu impacto foi "grave".

O que é OpenSSL e qual versão são afetadas?
É um software open source que facilita a comunicação dentre Protocolo SSL.
[7]
A implementação do OpenSSL estão presentes em servidores rodando Apache e Nginx. Infelizmente, permanece de Apache, o servidor web dominante hoje com mais de metade dos sites ativos da internet executando nele e nginx tem sobre outro 14%[8]
De fato, o bug Heartbleed surgiu em Dezembro de 2011[9], afetando a versão 1.0.1, na qual foi lançada em Março de 2012 atráves do 1.0.1f (6 Jan, 2014).
E se você rodar uma versão beta do OpenSSL 1.0.2, também estará vulnerável, ou seja, se você estive fazendo "a coisa certa" e manter suas versões até à data, está vulnerável. Acha mesmo que mantendo seu servidor atualizado estará fora de questão? Adotando a questão... Realmente teria ele esperado mais do que dois anos?

É somente sites sobre Apache e nginx que são afetados?
Não são todos os servidores web quem são dependentes de OpenSSL, por exemplo o IIS, utiliza Schannel da Microsoft, na qual não é encontrado o Bug. Isso quer dizer que uma grande parte não é vulnerável, e não que nenhuma seja, pois pode haver OpenSSL dentro da fazenda de servidores.

Quem encontrou e por que torná-la pública?
A primeira evidência pública do bug apareceu como um Conselho Consultivo OpenSSL em 7 de abril e adverte para "A falta dos limites check-in na manipulação da extensão TLS heartbeat". O bug foi descoberto e relatado por Neel Mehta da Google segurança e, simplesmente, afirma as versões impactadas e recomenda a atualização OpenSSL ou se isso não for viável, recompilá-lo e desabilitar os heartbeat.

O que é Heartbeat?
Vamos primeiro entender a característica que esse bug fez sua maneira. O bug que existe na implementação do OpenSSL a extensão do Heartbeat, uma característica descrita pelo IETF[10]

A extensão de Heartbeat fornece um novo protocolo para TLS/DTLS permitindo o uso da funcionalidade keep-alive sem executar uma renegociação e uma base para a descoberta do caminho MTU (PMTU) para DTLS.

 Quando eles ainda estão lá, õ heartbeat mantém o contexto entre os peers alive, portanto, a nomenclatura "keep-alive". No contexto de SSL, a negociação inicial entre o cliente e o servidor tem uma sobrecarga de comunicação que o heartbeat ajuda a evitar a repetição, estabelecendo-se o ponto é "alive". Sem o heartbeat, a única maneira de fazer isso é pela renegociação, que, em termos relativos, é caro.

Como o risco é explorado? E como isso foi corrigido?
Há abundâncias de provas de conceitos por toda internet, o que já não é tanta novidade assim, porém um exemplo que recentemente eu à tinha visto, é o exemplo de Rahul Sasi do Garage4Hackers, explicando o script vulnerável,  a correção quem ele tem desenvolvido para o teste do bug.[11]

Como sabe se um site é vulnerável?
A maneira mais fácil de testar isso remotamente é saltar para a página de teste Heartbleed criada por Filippo Valsorda. Um site vulnerável parecido com este:

[Imagem retirada do Blog: ClickSSL]

 OpenSource não é seguro, então porque demorariam 2 anos para encontrarem a falha?
Em termos, pode-se dizer que softwares OpenSource, sim é seguro. Pois assim a comunidade poderá analisar e identificar os erros mais cedo. OpenSSL project no GitHub tem mais de 10.000 confirmações abrangendo 21 colaboradores e 25 filiais todo 57MB de código-fonte. Não é grande, mas há o suficiente lá dentro e o bug é bastante obscuro em retrospectiva que passou despercebido até agora.


Referências:
[1] http://andreysmith.wordpress.com/2011/01/02/three-way-handshake/
[2] https://tools.ietf.org/html/rfc5246
[3] http://heartbleed.com/
[4] http://www.cra-arc.gc.ca/gncy/sttmnt2-eng.html
[5] http://googleonlinesecurity.blogspot.co.uk/2014/04/google-services-updated-to-address.html
[6] http://btsc.webapps.blackberry.com/btsc/viewdocument.do;jsessionid=5893087B0890E66745D0A2187EBB2FF1?externalId=KB35882
[7] http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html
[8] http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html
[9] http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1
[10] https://tools.ietf.org/html/rfc6520
[11] http://www.garage4hackers.com/entry.php?b=2551