RenatoMartini.Net

Category: openssl

2014: a Falha Heartbleed

A conhecida falha Heartbleed, detectada em abril na suite OpenSSL, uma suite « open source » utilizada por um grande número de sites no mundo, assim como plataformas e hardware criptográficos, seis novas vulnerabilidades foram atualizadas em abril e maio por um especialista do Japão, e publicadas 5 junho pela Fundação OpenSSL.

Segundo a Fundação, o bug é um tipo de « man in the middle », ou seja, que abre uma conexão entre dois pontos encriptados graças a uma ferramenta OpenSSL e pode assim permitir a uma pessoa interceptar uma troca de dados entre os pontos da conexão. Um cenário arriscado mais comum é o uso de uma rede pública onde uma das pontas se mostra vulnerável, e basta apenas que uma delas seja desvelada. Tal falha era ainda menos perigosa que o bug Heartbleed tornado público em abril, até então presente na biblioteca OpenSSL, ainda que nenhum código para explorar esta falha tenha sido apresentado imediatamente1. O bug consiste em toda sua singeleza no mecanismo TLS Heartbeat que é construído para preservar conexões vivas ainda que nenhum dado seja efetivamente trocado. As Heartbeat messages enviadas numa rede contém dados aleatórios e um tamanho de payload. A outra ponta da rede deve responder espelhando exatamente com os mesmos dados.

Em pseudo-código a estrutura de dados assim se apresenta (note-se ainda o tamanho de 2-byte do payload):

  1. struct {
  2. HeartbeatMessageType type;
  3. uint16 payload_length;
  4. opaque payload[HeartbeatMessage.payload_length];
  5. opaque padding[padding_length];
  6. } HeartbeatMessage;

A expressão heartbeat, « batida de coração », representa este desejo manter viva a conexão na rede, por assim dizer, como na sequência de várias « batidas » que nos mantém vivos. A batida transforma-se, desgraçadamente, em hemorragia, heartbleed, porque a falta de verificação do correto perímetro (o atacante) pode desvelar uma determinada quantidade de memória (64K) armazenada entre cliente & servidor. Ali podem estar, cookies, senhas e tantas outras informações sensíveis. Resumidamente, NSFOCUS Secutity Labs: « the OpenSSL TLS Heartbeat Extension protocol implements blind trust from the length of payload in the communicating field. Lacking correct perimeter checks, this protocol may allow disclosure of data amounts up to 64K memory to any connected clients or server and with this, sensitive information contained in that memory data can also be exposed. This Heatbeat defect can be exploited to access sensitive user data stored in millions of servers or by clients—data such as licenses, cookies, and user passwords. An attacker may even eavesdrop on communications using acquired secret keys, and thereby steal data from service providers by impersonating the service providers and users ». O bug foi introduzido originalmente nesta inserção na plataforma GIT do projeto OpenSSL.

Em especial, podemos ver aqui:

2427                 /* Allocate memory for the response, size is 1 bytes

2428                  * message type, plus 2 bytes payload length, plus

2429                  * payload, plus padding

2430                  */

2431                 buffer = OPENSSL_malloc(1 + 2 + payload + padding);

2432                 bp = buffer;

2433                 

2434                 /* Enter response type, length and copy payload */

2435                 *bp++ = TLS1_HB_RESPONSE;

2436                 s2n(payload, bp);

2437                 memcpy(bp, pl, payload);

2438                 

2439                 r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding); 

O dados gerados maliciosamente contém um payload, que incorretamente o software confia cegamente sem as devidas verificações. O OpenSSL assim procede a resposta com o buffer, copiando os dados presentes no ponteiro « pl »:


memcpy(bp, pl, payload);

Apesar do tom quase sempre bombástico da mídia não-especializada (por exemplo: Falha 'Heartbleed' é uma catástrofe2, , e mesmo naquela que trata do tema tecnologia, tais vulnerabilidade e falhas são sempre passíveis de serem encontradas, não há engenharia e implementação perfeita -, seja no mundo open source seja no de softwares não abertos. Encontrado o bug, seja qual for, tão logo possa, deve o o responsável pela infraestrutura aplicar as devidas correções e atualizações.

Enfim, não foi o armagedom, todos continuamos usando a Rede, aproveitando seus recursos, fazendo negócios, política, interação em redes sociais, até que uma próxima falha seja encontrada.


Referências:
1. http://www.lemonde.fr/economie/article/2014/06/06/apres-heartbleed-une-nouvelle-faille-de-securite-dans-openssl_4433841_3234.html
2. http://www.heartbleed.com.br/
3. http://www.nsfocus.com/2014/SecurityView_0417/169.html

 
Revisão v. 1.9a
 
  1. Alguns scripts logo apareceram para que se testassem a vulnerabilidade Heartbleed, o mais conhecido foi o ssltest.py, que pode ser visto aqui []
  2. http://g1.globo.com/tecnologia/blog/seguranca-digital/post/falha-heartbleed-e-uma-catastrofe.html []

O módulo FIPS do OpenSSL versão 2.0

A suite OpenSSL, que dispensa apresentações, possui um importante módulo para aqueles que desejam suportar em sua aplicação, ou hardware, o padrão FIPS 140-21. O chamado "FIPS Object Module" versão 2.0 suporta também todo o conjunto de algoritmos criptográficos conhecidos como "Suite B" criados pela NSA norte-americana, que também podem ser usados exclusivamente com estas extensões.

A Suite B requer um nivel de segurança de 128-bit e note-se que impossibilita o use do TLS lesser abaixo da versão 1.22, pois as versões anteriores usavam ainda a solução MD5-SHA1, sabidamente já obsoletos, como função pseudo-randômica.

O modo FIPS é iniciado pela chamada de função FIPS_mode_set().

  1. int FIPS_mode_set(int ONOFF);

Com FIPS_mode_set(0) ele abandonará o modo FIPS, e retorna 1 se com êxito. Já com o valor diferente de zero ele entrará no modo FIPS. O valor "2" está reservado para restringir as operações aos algoritmos da Suite B. Diferentemente da documentação que está disponível no Wiki do projeto OpenSSL, o Manual do Módulo FIPS documenta o uso de outra função para restringir à Suite B: "An argument of FIPS_SUITEB(2) will restrict the available algorithms to those
allowed by the Suite B specification
".

Exemplo de uma chamada direta da função:

  1. #ifdef OPENSSL_FIPS
  2. if(options.no_fips <= 0)
  3. {
  4. if(!FIPS_mode_set(1))
  5. {
  6. ERR_load_crypto_strings();
  7. ERR_print_errors_fp(stderr);
  8. exit(1);
  9. }
  10. else
  11. fprintf(stderr,"*** IN FIPS MODE ***\n");
  12. }
  13. #endif

Um tema importante para aqueles que ainda querem adotar a padronzação ECC feita pela NSA é o das patentes. O item 6.5 "ECC and the NSA Sublicense" é portanto leitura obrigatória para o desenvolvedor.

Why are there two versions of the OpenSSL FIPS Object Module 2.0? At least some implementations of Elliptic Curve Cryptography (ECC) are perceived to be encumbered in the United States by a complex set of patents. Concern about the possible risks of patent infringement have been a significant disincentive to more widespread use of ECC. In order to counter such concerns for the ECC necessary to implement the Suite B algorithms, the NSA established a process for sub-licensing the patents for that subset of ECC (see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). The OSF has obtained such a sublicense (http://opensslfoundation.com/testing/docs/NSA-PLA.pdf). However, that sublicense only covers the specific patents presumed relevant to the prime curve ECC used for Suite B. It does not cover other possible types of ECC such as binary curves which are implemented in OpenSSL. Judging the risks of a patent infringement lawsuit is difficult, and not only because the patents themselves are usually incomprehensible to the software developer. The mere threat of a patent lawsuit can be crippling to even a medium sided enterprise, regardless of the legitimacy of the accusation of infringement. It is the considered opinion of the OpenSSL team that the implementation of ECC in OpenSSL, both primary and binary curve, does not infringe any patents 46 However, some potential users are still concerned about the risk of patent litigation, understandably so given the extent to which such litigation has been used as an offensive commercial tactic in recent years. For the OpenSSL software such users can use built-time options to omit specific algorithms of concern from the resulting binary code.

FIPS140 Files Here you can find a number of FIPS140 related files including the user guide and test vectors. Bytes Timestamp Filename ________ ____________________ ____________________________ 1707577 Sep 29 14:15:31 2013 UserGuide-2.0.pdf 464520 May 20 20:40:51 2013 SecurityPolicy-2.0.pdf 223576 Jun 28 15:42:31 2012 UserGuide.pdf 925694 Jun 27 02:45:21 2012 UserGuide-1.2.pdf 82787660 Feb 3 19:45:56 2012 fips-2.0-tv.tar.gz 399521 May 12 14:55:47 2011 SecurityPolicy-1.2.3.pdf 5628 May 10 12:52:17 2011 incore2 645167 Dec 8 20:19:25 2010 SecurityPolicy-1.2.2.pdf 1936 Jan 12 23:34:27 2010 incore.gz 860211 Nov 20 16:26:39 2009 SecurityPolicy-1.2.pdf 429420 Feb 10 19:28:55 2008 SecurityPolicy-1.1.2.pdf 681420 Dec 13 21:11:03 2007 UserGuide-1.1.1.pdf 8947798 Oct 10 23:21:37 2007 testvectors-linux-2007-10-10.tar.gz 9112982 Oct 10 00:56:58 2007 testvectors-XP-2007-10-09.zip 1395381 Feb 6 22:03:20 2007 SecurityPolicy-1.1.1.pdf 5700115 Jul 19 13:30:25 2005 rsp.SuSE.2005-07-01.tar.gz 5699128 Jul 19 13:30:17 2005 rsp.SuSE.2005-06-30.tar.gz 5660011 Jul 19 13:30:03 2005 rsp.HP-UX.2005-07-01.tar.gz 4249118 Jun 10 12:26:55 2005 testvectors.SuSE.tar.gz 4149860 Jun 10 12:26:43 2005 testvectors.HP-UX.tar.gz

 
Revisão v. 1.0
 
  1. Obviamente que a compilação do módulo em questão não gerará de forma imediata uma como que aceitação do padrão NIST, como o próprio OpenSSL avisa: "OpenSSL has been configured to generate a fipscanister.o object module. That compiled module is NOT FIPS 140-2 validated or suitable for use in satisfying a requirement for the use of FIPS 140-2 validated cryptography UNLESS the requirements of the Security Policy are followed exactly (see http://openssl.org/docs/fips/ or http://csrc.nist.gov/cryptval/)." []
  2. Consultar: http://tools.ietf.org/html/rfc5246: "The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256." []

Vazamento de senhas do Fisco canadense

O Estadão recentemente tratou do vazamento de informações no Fisco do Canadá, Dados da receita canadense são roubados através do Heartbleed, diz a nota. Heartbleed é (ou foi, considerando-se que já esta corrigido num fixbug) um bug que pode ser qualificado de grave, pois compromete a chave privada de um servidor, o que a rigor permitiria a o acesso aos dados guardados em servidores sem a posse de nenhum acesso privilegiado.

O vazamento de senhas do Fisco canadense se deu pelo fato do acesso irregular do seu site, possibilitar a invasão do armazenamento onde se encontram o "login/senha" de seus usuários.

Não se trata do apocalipse digital1, como por vezes pode parecer na mídia não especializada, mostra apenas que geralmente falhas de segurança estão na implementação da tecnologia e não necessariamente no protocolo em si. O SSL/TLS ainda servirá por longo tempo a infraestrutura da informação.

Dados da receita canadense são roubados através do Heartbleed Novecentos canadenses tiveram dados roubados a partir de falha de segurança nos bancos de dados da receita do país Por Agências 900 canadenses tiveram seus dados privados roubados da receita federal do país. FOTO: Reprodução OTTAWA – A receita federal do Canadá divulgou nesta segunda-feira,14, que dados privados de cerca de 900 pessoas foram roubados de seus sistemas como resultado de vulnerabilidades causadas pela falha “Heartbleed”. A falha permitiu o roubo de dados de seguro social e possivelmente outros dados, informou a Agência de Receita do Canadá (CRA). “Lamentavelmente, a CRA foi notificada por agências de segurança do Canadá sobre uma invasão aos dados dos contribuintes ocorrida durante um período de seis horas”, disse a CRA em comunicado. A CRA fechou o acesso a seus serviços online na última quarta-feira por causa da falha, presente em uma tecnologia de codificação largamente utilizada na Web e que representa um dos mais sérios problemas de segurança eletrônica descobertos nos últimos anos. / REUTERS

 
Revisão v. 1.0
 
  1. Mais informação pode ser consultada no site http://heartbleed.com/, de forma sucinta e objetiva. []

Copyright © 2017 RenatoMartini.Net

Theme by Anders NorenUp ↑