sexta-feira, 28 de fevereiro de 2014

Segurança x Confiança: Problemas causados por bugs em softwares

Você confia nos programas que você utiliza? Você toparia uma cirurgia remotamente, com seu médico a km de distância utilizando os recursos da telemedicina? Você confia que os automóveis mais modernos disponíveis te levarão de um ponto a outro do globo terrestre sem que você encoste no volante?  Você confia que as empresas nas quais você armazena seus dados estão fazendo tudo para manuseá-los/preservá-los com segurança e que o acesso às suas informações é restrito? Você confia que os softwares que você utiliza são testados exaustivamente a procura de brechas que possam resultar num incidente de segurança? Se você respondeu que sim a todas as perguntas anteriores, parabéns! Eu queria ser você, mas simplesmente não consigo.

A confiança nos dispositivos computacionais e eletrônicos, na minha opinião, nunca estiveram tão em baixa, seja em software ou hardware (o que por um lado, ajuda a manter aquecido o mercado de segurança da informação). Já é um mantra do pessoal de segurança em TI que "100% de Segurança não existe", mas devemos nos acostumar também ao fato de que "Código de programa bem escrito, 100% bug free", também é lenda urbana. Todo programa tem suas vulnerabilidades e o fato de você não as encontrar, ou mesmo os especialistas de segurança não as encontrarem, não significa que seu programa esteja livre de erros, significa apenas que os erros não foram encontrados! Ele pode permanecer anos invisível no seu ambiente até que alguém o descubra e, sendo pessimista, o explore (e sob esse ponto de vista é bem melhor saber sobre a falha e corrigi-la do que simplesmente não saber da sua existência).

Claro que alguns erros tem proporções ínfimas, e não são motivo de tanta preocupação. Uma aplicação que executa uma função inválida e trava o seu computador, trará muito menos dor de cabeça do que um foguete espacial que se desintegrou ao receber uma informação errônea (e veremos esse caso adiante). E com esse pensamento, procurei na Internet alguns casos que mostram que um código vulnerável (ou um programa mau escrito, como queira), é um dos principais problemas que temos na segurança da informação. Aponte um programa que não tem falhas. Pense sobre os programas e sistemas operacionais que você utiliza; agora vá no Google e digite "Falha de segurança no [coloque aqui o programa que você pensou]". Conseguiu encontrar algum que não retornasse nenhum resultado? Note que nem todos esses casos citados abaixo estão relacionados à segurança da informação, mas servem para exemplificar o quão difícil é projetar e implementar códigos livres de bugs. Veremos casos de agências espaciais internacionais como a NASA que possuem recursos de sobra e um forte incentivo para certificar-se da qualidade de seus programas e mesmo assim falharam e apresentaram bugs que custaram alguns milhões (em casos de outras empresas, algumas vidas). 

E por falar em "bug", pesquisando na Internet, você encontrará diversas "lendas" dizendo que o termo "bug" surgiu em 1945 quando Grace Murray Hopper (uma das pioneiras na programação do famoso Harvard Mark I e II e responsável por popularizar a ideia de linguagens de programação independentes do hardware, levando ao desenvolvimento do COBOL - COmmon Business Oriented Language), documentou o primeiro bug da informática. Segundo essa lenda, no dia  9 de setembro de 1945 seu grupo de trabalho encontrava-se na sala do Mark II tentando identificar porquê o computador não funcionava adequadamente. Após uma inspeção minuciosa, encontraram no "Painel F" uma mariposa entre os contatos de um dos relés do computador. No caderno de registros, Grace registrou o incidente como "First actual case of bug being found" (encontrado o primeiro caso de bug) e "anexou" junto da inscrição a famigerada mariposa ;o) associando pela primeira vez o termo "bug" a um erro num sistema computacional. A partir de então, quando os computadores apresentam falhas, é normal usar o termo bug para referenciar tais falhas (vindo daí também o termo "debug").

 Grace Murray Cooper                      Harvard Mark II

 

Na verdade, conforme o site ComputerWorld, o termo bug surgiu bem antes mas ainda assim é uma lenda que vale a pena ser mantida, em função dos serviços prestados pela sra. Cooper. Segundo o site, dois argumentos invalidam a origem do termo conforme o relato de 1945:

1 - O Harvard Mark II entrou em operação no verão de 1947, dois anos após a data atribuída para essa história e;

2 - não se usa um termo como "Encontrado o primeiro caso de bug" se a expressão "bug" não for de uso comum, ou seja, rotineira no ambiente em que foi utilizada. Esse tipo de comentário não faria sentido a não ser como uma mensagem bem humorada para um erro.

Engenheiros e cientistas já falavam sobre bugs, um século antes do incidente da "mariposa no relé", incluindo Thomas Edison, inventor de diversos dispositivos (entre eles a lâmpada elétrica incandescente), que em 1878, numa carta enviada a Theodore Puskas escreveu: "Bugs - como essas pequenas falhas e dificuldades são chamadas - aparecem e meses de observações, estudos e trabalhos intensos são necessários antes do sucesso ou fracasso comercial ser atingido com precisão". Estudiosos inclusive "rastrearam" a palavra bug a um termo que fazia referência a um monstro, uma palavra que sobreviveu em termos obscuros como "bugaboo" (bicho-papão) e "bugbear" (pesadelo) e de forma mascarada na palavra "boogeyman" (bicho-papão).

Independente de onde/quando o termo tenha sido utilizado pela primeira vez, vejamos alguns casos onde um "simples errinho de programação", causou danos significativos. Veja que nem todos os casos são de programas mau escritos, alguns envolvem falta de testes, erros diversos ou uso incorreto, mas sou da opinião que fundamentalmente, os softwares deveriam estar preparados para o uso incorreto. 
(clique nos links abaixo das imagens para ser direcionado até a página de origem da foto)

1962 - Sonda Mariner
Em 28 de julho de 1962 um bug no software da sonda Mariner I (cujo destino era Vênus), desviou seu percurso de voo logo após o lançamento, fazendo com que o controle da missão destruísse o foguete cerca de 5 minutos após a decolagem enquanto ele sobrevoava o oceano Atlântico. A investigação do acidente determinou que o problema estava numa fórmula escrita a lápis que foi imprecisamente inserida no computador de cálculo (o programador se esqueceu de inserir uma "/", e sem ela o software tratava variações normais de velocidade como se fosse um problema grave, gerando falhas e enviando o foguete para fora de curso). O custo da falha foi de 18,5 milhões de dólares.


1978 - Coliseu Hartford
Uma falha no desenvolvimento do programa utilizado para projetar o Coliseu Hartford em Connecticut, EUA, (que não previa o peso acumulado da neve), causou o desabamento do telhado da arena durante uma tempestade de neve que teve duração de 10 dias. Apesar de uma partida ter sido disputada no coliseu apenas 6 horas antes do ocorrido, não houve feridos; ainda assim, o prejuízo foi de 70 milhões de dólares.

Coliseu Hartford  


1982 - Explosão no Gasoduto Transiberiano
Considerada a maior explosão não nuclear registrada até hoje, a explosão desse gasoduto teve origem num erro de programação. As informações dão conta que o governo soviético adquiriu um sistema canadense para controlar o gasoduto Transiberiano, com o objetivo estratégico de roubar ou obter de maneira sigilosa informações sensíveis sobre a tecnologia americana. Quando a CIA (agência de inteligência central americana) tomou conhecimento da compra, infiltraram um bug no sistema que a princípio deveria passar pela inspeção soviética porém ocasionar má operação, além de permitir aos americanos manipular remotamente todo o tipo de máquinas e tecnologia. Mas em 1982 quando o bug foi ativado as coisas saíram completamente diferentes do esperado, provocando a gigantesca explosão. Felizmente, como aconteceu numa área remota, não houve vítimas.


1983 - A "quase" 3º Guerra Mundial
Uma falha no sistema de alerta da União Soviética indicou, em 1983, que 5 mísseis balísticos intercontinentais haviam sido lançados pelos Estados Unidos. Detalhe: exatamente um período em que essas nações estavam na chamada Guerra Fria!!!! O então tenente-coronel Stanislav Yevgrafovich Petrov estava como um oficial de serviço no dia 26 de setembro 1983 no Serpukhov-15, um poderoso bunker em Moscou, de onde controlava-se o sistema de alerta antecipado de mísseis americanos. Ao invés de informar seus superiores, Stanislav (contra o protocolo militar estabelecido), preferiu esperar os primeiros impactos de solo para só então tomar as contra medidas que fossem necessárias. Felizmente foi uma falha do sistema soviético que, diga-se de passagem, jamais havia falhado. Os sensores dos satélites de alerta tinha experimentado uma situação estranha, que fez a luz solar refletida por nuvens em elevadas altitudes, parecerem disparos de misseis, ativando a rede de alarme. História completa aqui.


1985 - Therac-25
O Therac-25 era um acelerador linear utilizado para o tratamento de tumores na década de 80, produzido pela Atomic Energy Canada Limited - AECL. Ele emitia radiação de alta energia sobre células cancerígenas sem causar dano ao tecido circundante. Devido a uma falha de programação (um bug sutil chamado "race condition"), um técnico configurou acidentalmente o Therac-25 para emitir 100 vezes mais a energia do que o necessário (o feixe de elétrons seria como um fogo de alta potência). Como consequência, 6 pessoas morreram em função das altas doses de radiação recebidas e várias dezenas também sofreram os efeitos, inclusive os próprios funcionários. O software não reconhecia quando doses exageradas eram aplicadas, fazendo com que alguns pacientes morressem pouco depois da exposição. Este caso tornou-se um ícone para os estudantes de informática na saúde e engenharia de software.

  A estrutura do Therac-25                                  THERAC-25

 

1988 - O worm de Morris
O primeiro worm de Internet, também chamado de Morris Worm, foi criado por Robert Morris Jr. e apenas na tarde do dia 2 de novembro de 1988, infectou entre 2.000 e 6.000 computadores em menos de um dia (o que correspondia a 10% da Internet na época). Morris que é filho do na época cientista chefe do Centro Nacional de Segurança Computacional dos EUA, foi o primeiro a ser condenado pela lei de Abuso e Fraude de Computadores, mas pagou multa de US$ 10 mil e prestou serviços comunitários. O worm de Morris fazia um buffer overflow no daemon finger do Unix que possuía uma falha no código

 O código do worm de Morris                      Robert Morris

1990 - Pane nas linhas da AT&T
No dia 15 de janeiro de 1990 uma única linha de código numa atualização de software implementada para acelerar chamadas causou uma pane com efeito cascata na gigante da telefonia americana AT&T. Este bug no software que controlava os equipamentos de telefonia de longa distância, fez com que a unidade de comutação com erro, informasse as unidades vizinhas que estava com problemas. Infelizmente, a unidade de comutação vizinha também travava ao receber essa mensagem (não sem antes passar a mensagem adiante), gerando um efeito em cascata. Cerca de 9 horas e 75 milhões de ligações perdidas depois, o problema foi resolvido.
                                     

1991 - Falha de mísseis Patriot acaba em desastre
No dia 25 de fevereiro de 1991, durante a primeira Guerra do Golfo, o sistema americano dos mísseis Patriot falhou ao interceptar um míssil vindo do Iraque que atingiu uma base americana em Dhahran na Arábia Saudita, matando 28 soldados e ferindo outros 110. Um erro de arredondamento no cálculo e consequentemente na medição do tempo, ocasionou um deslocamento na posição da região de procura do radar da ordem de 687 metros o que conduziu à não detecção do míssil Scud iraquiano (segundo esse site, o erro grosseiro ocorreu em função de terem se passado 100 horas sem que o sistema fosse reiniciado). Mais informações técnicas explanando o exato problema do erro de arredondamento aqui.
          Resultado da explosão



                                                           

1992 - Acidente do Raptor F-22 
Em abril de 1992 um avião Raptor F-22 caiu ao pousar na Base Aérea Edwards na Califórnia. Após investigação, descobriu-se que a causa do acidente foi um erro no software de controle de voo que falhou ao impedir uma oscilação induzida pelo piloto.

 O piloto David Cooley                                Raptor F-22

1993 - Falha da divisão de números de ponto flutuante nos processadores Pentium
Em 1993 um problema com os então novíssimos microprocessadores Pentium da Intel (que vieram para substituir os 486), trouxeram enorme prejuízo à empresa. O divisor da unidade de ponto flutuante do Pentium tinha uma tabela de divisão insuficiente, faltando cerca de 5.000 entradas, o que resultava num erro de arredondamento. Por exemplo, ao dividir 4195835,0 por 3145727,0 o resultado apresentado pelo microprocessador era 1,33374 ao invés de 1,33382, um erro de 0.006%. Ainda que esse tipo de falha afetasse poucos usuários, a Intel assumiu o erro mas inicialmente se propôs a trocar apenas os processadores de quem conseguisse provar que usava o computador para cálculos matemáticos que exigissem precisão absoluta. A resposta das centenas de milhares de consumidores que haviam pago mais de $600 pelo processador foi dura (ahhh se isso acontecesse com os fabricantes de software) e a Intel viu-se substituindo os processadores de todos os clientes que o solicitaram, arcando com um prejuízo de $450.000.000,00.

1994 - Calculadora do Windows 3.x
Um erro na calculadora que acompanhava as versões de Windows 3.x fazia com que a subtração de 2.1 de 2.11 resultasse no valor "0.00" ao invés de "0.01".

1994 - Acidente com um Chinook no Mull of Kintyre
No dia 02 de junho de 1994 um helicóptero Chinook da Força Aérea Real Britânica caiu no Mull of Kintyre (região montanhosa situada no ponto mais extremo ao sudoeste da Península Kintyre na Escócia onde se localiza um farol histórico, imortalizada numa canção de Paul McCartney nos anos 70). O acidente que matou 29 pessoas (25 passageiros e 4 tripulantes) teve inicialmente sua causa atribuída a erro humano. Após uma investigação porém, foram descobertas evidências suficientes de que o acidente tenha sido causado por um bug no software do computador de controle do motor da aeronave.

                                      Imagem ilustrativa de um Chinook

                                                               

                                     
1995/1996 - Ping da morte
O ping da morte era um ataque de DoS (Denial of Service ou Negação de Serviço) a um computador, que explorava uma má implementação do protocolo TCP/IP nos sistemas operacionais. O ping da morte enviava um pacote mal formado com um tamanho de pacote absurdamente elevado e com uma frequência muito alta. Esse tipo de ataque afetava uma grande variedade de sistemas como Unix, Linux, Mac, Windows, impressoras, roteadores e etc. Em sistemas Windows, o ataque geralmente resultava na famosa "Tela azul da morte". Entre 1997 e 1998 a grande maioria dos sistemas foi corrigido. 



1996 - Explosão do Foguete Ariane
Em 4 de junho de 1996 a estação espacial europeia lançou o foguete Ariane-5 contendo 4 satélites para estudar como o campo magnético da Terra interage com os ventos solares. O foguete desintegrou-se 40 segundos após o seu lançamento. O problema aconteceu quando o computador de orientação tentou converter a velocidade do foguete expressa com 64-bits para um formato de 16-bits. O número era muito grande para ser armazenado por uma variável de 16-bits e acabou ocasionando um overflow. Quando o sistema de orientação desligou, o controle foi passado para uma unidade redundante idêntica que também veio a falhar por rodar o mesmo algoritmo. Nesse caso existem 2 situações cruciais para serem analisadas sobre a ótica da segurança:

1 - Os cientistas que desenvolveram o Ariane-5, reutilizaram parte do código do Ariane-4. A função errônea fazia parte de um requisito do Ariane-4 que não fazia parte da especificação do Ariane-5.

2 - Os resultados fornecidos pelo segmento de código que resultaram no erro eram relevantes apenas antes da decolagem. Após a decolagem esta função não servia para nada.

O prejuízo foi de $500.000.000,00.



1997 - USS Yorktown
 Um membro da tripulação de um cruzador de mísseis guiados USS Yorktown inseriu por engano um valor "0" num determinado dado que resultou numa "divisão por 0" causando um buffer overflow. O erro teve um efeito em cascata derrubando toda a rede de 16 computadores e eventualmente desligando o sistema de propulsão do navio. O navio permaneceu por quase 3 horas inoperante na água (ou como eles chamam: "dead in the water"), simplesmente porque um programa não validava os dados de entrada. Ainda segundo os engenheiros: "Usar Windows NT ao invés de Unix num ambiente tão crítico foi uma bola fora" e que a decisão de usar Windows NT ao invés de Unix no programa foi uma decisão política equivocada e não uma decisão técnica. Reportagem aqui.


1999 - Destruição das sondas Mars Polar Lander e Mars Climate Orbiter
No dia 3 de dezembro de 1999 a sonda Mars Polar Lander estava se preparando para pousar quando houve um desligamento prematuro do motor antes que ele tocasse o solo. Quando o aterrizador se encontrava a 40 metros da superfície, suas pernas de pouso se abriram e o balanço causado no aterrizador pode ter gerado sinais espúrios nos sensores, levando o computador a considerar que já havia pousado e procedendo o desligamento do motor de descida (situação que não havia sido prevista pelos desenvolvedores). Os cientistas acreditam que a sonda espatifou-se no solo de Marte a uma velocidade de 22 metros/segundo.  O custo da missão excedeu os U$120.000.000,00.

Já a Mars Climate Orbiter foi uma sonda lançada pela NASA no dia 11 de dezembro de 1998 e que chegou a Marte em 23 de setembro de 1999. A nave espacial deveria efetuar sua inserção na órbita de Marte a uma altitude de 140 km a 150 km da superfície, mas devido a um erro de cálculo essa manobra ocorreu a 57 km da superfície causando a destruição da nave (devido a sua fricção com a atmosfera de Marte). O erro aconteceu devido a equipe em Terra ter utilizado o sistema imperial (polegadas e libras) para calcular os parâmetros da manobra de inserção enquanto os sistemas na nave utilizavam apenas o sistema métrico (metros e Newtons).

 Mars Polar Lander                       Mars Climate Orbiter


1999 - Problemas na emissão de passaportes britânicos
No verão de 1999 a agência de passaportes no Reino Unido implementou um novo sistema da Siemens para controlar a emissão de passaportes. Ao mesmo tempo, uma mudança na lei exigia que todos os menores de 16 anos viajando ao exterior deveriam emitir passaporte (o que resultou numa procura enorme para emissão de novos passaportes). Porém o novo sistema não havia sido testado de forma adequada, bem como seus funcionários não haviam recebido o treinamento necessário. Como resultado, meio milhão de cidadãos britânicos não conseguiu emitir seus passaportes e o custo da imperícia foi em torno de  £12.6 milhões.

Imagem ilustrativa de passaportes britânicos


1999 - Bug do milênio
O bug do milênio consistia no fato de uma boa parcela dos softwares gerenciar datas com apenas 2 dígitos (fazendo com que "1998" fosse referenciado como "98", ficando subentendido que na frente desses haveriam os dígitos "19"). O problema aconteceria quando, no ano "2000", os softwares considerariam o ano "00" como "1900", causando diversos problemas como boletos de cobrança sendo emitidos com cem anos de atraso, por exemplo. Embora nenhuma falha significativa tenha ocorrido, as empresas correram para atualizar seus sistemas numa espécie de pânico coletivo. É possível que um problema similar aconteça em 2038 (o problema do ano 2038). Os sistemas Unix calculam o tempo em segundos desde 01 de Janeiro de 1970 e armazenam este número como um inteiro de 32 bits signed (que considera o sinal). O valor máximo possível com essa representação é 231, ou seja, 2.147.483.647 segundos, valor que será atingido as 03:14:07 do dia 19 de Janeiro de 2038.

2000 - Vítimas de um Tratamento de Câncer no Panamá
Em novembro de 2000, no Instituto Oncológico Nacional na cidade do Panamá, numa série de acidentes e falhas dos engenheiros da Multidata Systems International calcularam erroneamente a dosagem de radiação que os pacientes deveriam receber durante uma terapia de radiologia. A falha estava no software de controle da máquina de raios software RTP/2 (vers. 2.11, 1991), que provocou a morte de 8 pacientes e fez com que outros 20 recebessem sobredosagens que poderiam causar graves danos a sua saúde.


2004 -  Falha em atualização gera prejuízo para governo Britânico
Uma falha no sistema para distribuição de bolsas assistenciais originados por dois softwares da  Electronic Data Systems (EDS), gerou enormes prejuízos ao governo Inglês. Ao longo de 2004 os dois sistemas da EDS (o Child Tax Credit e o Working Tax Credits) repassaram cerca de 27 bilhões de dólares a 5,7 milhões de famílias, mas praticamente um terço delas recebeu pagamentos extras no ano, em virtude das falhas (o prejuízo superou £1 bilhão e resultou na renúncia do chefe da CSA - Child Support Agency, Doug Smith). Um memorando interno da EDS vazou para a mídia onde a empresa admitia que o sistema da CSA foi "mal projetado, mal testado e mal implementado".

2005 - Perda do satélite europeu CryoSat-1
No dia 8 de outubro de 2005, o satélite CryoSat-1 da agência espacial europeia  foi perdido durante uma falha no seu lançamento. A falha aconteceu porque não havia um comando para desligamento do segundo estágio do motor do foguete no sistema de controle de voo do seu foguete Rokot. Isto impediu que o segundo estágio se separasse do Briz-KM e o foguete foi impedido de alcançar a órbita.

 

2005 - Sistema de proteção contra cópia da SONY
Em outubro de 2005 a Sony produziu um esquema de proteção contra cópias denominado SONY DRM rootkit (XCP) que instalava um rootkit nos computadores com Windows XP. A intenção era esconder o mecanismo de proteção para ser mais difícil de burlar, mas infelizmente esse rootkit abria uma brecha de segurança que permitia a instalação de cavalos de Tróia por terceiros nos computadores de quem executasse o CD.




2006 - Vulnerabilidade do OpenSSL
Na tentativa de resolver um problema, um mantenedor do Debian fez uma atualização do OpenSSL e quebrou o gerador de números aleatórios nesse processo. Trecho do alerta do CAIS disponível aqui: "Devido a uma modificação introduzida pelo Debian no pacote OpenSSL original, existe uma vulnerabilidade na geração de números aleatórios, o que faz com que essas aplicações gerem sempre um número limitado e pequeno de chaves criptográficas. Com isso um atacante de posse de uma lista dessas chaves pode realizar ataques de força bruta contra as aplicações e conseguir acesso ao conteúdo criptografado."
 

2007 - Excel informando valor incorreto
A Microsoft lançou uma correção para o Microsoft Excel 2007 que corrige um erro onde era apresentado o número 100.000 como resultado de cálculos que deveriam resultar em 65.535 ou 65.536.




2007 - Atualização do jogo Espacial EVE online trava computadores
Uma atualização lançada para o jogo RPG Espacial EVE online que deveria melhorar desempenho gráfico, causou o travamento de computadores com Windows XP. Isto porque os desenvolvedores atualizavam o arquivo "boot.ini" no computador do usuário (mesmo nome do arquivo que possui parâmetros de inicialização do Windows XP). O primeiro reinicio de sistema após  a atualização travava o computador.
 Microsoft Corp. corrigiu uma falha no software Excel 2007 que apresentava valores incorretos para cálculos envolvendo alguns números, informou a empresa nesta quarta-feira (10/10). A companhia ainda informou que vai incluir a correção no Windows Update, o quando antes.
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf
A Microsoft Corp. corrigiu uma falha no software Excel 2007 que apresentava valores incorretos para cálculos envolvendo alguns números, informou a empresa nesta quarta-feira (10/10). A companhia ainda informou que vai incluir a correção no Windows Update, o quando antes.
O bug, que a Microsoft reconheceu há duas semanas, mostra o número 100.000 como o resultado de cálculos que deveriam resultar em 65.535 ou em 65.536. O erro, segundo a Microsoft, não está nos cálculos do Excel, mas no código que carrega os valores resultantes e os formata antes de exibi-los em uma célula da planilha eletrônica. Somente a mais nova versão do programa, o Excel 2007, e seu equivalente online, o SharePoint 2007, contém esse bug.
As correções para a falha e a documentação no banco de dados de suporte da Microsoft, foram publicadas no site de downloads da companhia, com links disponíveis no blog do Excel. O downaloda para o Excel 2007 possui substanciais 32,5 Megabytes (MB).
"Estamos no processo de adicionar esta correção ao Microsoft Update para que ela seja atualizada automaticamente a usuários rodando o Excel 2007 ou o Excel Services 2007", informou David Gainer, gerente de projetos do programa, no blog da equipe.
A correção não está entre as correções liberadas no boletim mensal de atualizações anunciado ontem (09/10) pela Microsoft.
- See more at: http://idgnow.com.br/seguranca/2007/10/10/idgnoticia.2007-10-10.9822776538/#sthash.3uYGZqTy.dpuf


2010 - Erros em terminais do Bank of Queensland na Austrália
Um erro no código do terminal  pagador do Bank of Queensland, na Austrália, deixou diversos dispositivos inoperantes por uma semana. Aparentemente o problema aconteceu devido a uma rotina incorreta na conversão de um número hexadecimal. Quando o dispositivo devia assinalar 2010 ele pulava 6 anos até 2016, fazendo com que os terminais recusassem os cartões dos clientes por estarem expirados. 

E veja que não foram citadas aqui, falhas de segurança, apenas casos de falhas de programas que ganharam notoriedade em função dos seus efeitos desastrosos.


A infeliz realidade é que erros de software como esses estão em todo lugar mas têm pouca repercussão caso seus efeitos não sejam tão devastadores. Se a planilha eletrônica travar enquanto você está alterando informações dos seus gastos pessoais ninguém morrerá por isso e, convenhamos, se os usuários não reclamarem do problema, certamente a fabricante não terá motivação para corrigi-lo se isso não resultar num ganho financeiro. Mas a partir do momento que softwares cada vez mais complexos começam a invadir sistemas críticos (sistemas para evitar acidentes em veículos automotivos, decolagem e aterrissagem de aeronaves, plantas de controle nuclear, etc) é possível que vejamos mais falhas como essas acontecendo. Diariamente a imprensa especializada divulga casos de crackers que invadem sistemas devido as suas falhas de segurança (boa parte em função de códigos vulneráveis)  mas nossa passividade em cobrar softwares de maior qualidade dos fabricantes, não são lá motivadores para que eles se empenhem mais nessa tarefa (apenas para registro, nos casos de falha de segurança também é preciso computar os casos de má implementação ou uso). 

Vemos que as empresas deixam muito a desejar quando o assunto é teste dos seus produtos. Por um lado é até compreensível pois ninguém conseguirá testar todas as possibilidades com todas as variáveis que o mundo real oferece. Um problema que foi encontrado utilizando o software num determinado ambiente pode não acontecer em outro de característica similar, pois uma variável diferente, mesmo que ínfima, pode estar envolvida e desencadear toda uma gama diferente de resultados. O problema começa quando uma empresa sabe que o software possui determinadas vulnerabilidades e o comercializa assim mesmo. Como saber quais programas são esses? Como confiar nesse tipo de programa? 

A confiança se torna um problema mais crítico ainda por que as falhas que são utilizadas para quebrar a segurança, geralmente não afetam a performance do produto. Falhas que afetam a performance de um software ou de um dispositivo são rapidamente notadas e demandam correções urgentes. Porém uma falha de segurança pode permanecer num produto durante anos e não ser descoberta (o que não impede que ela seja explorada por alguém que já a tenha encontrado) e por isso são deixadas pra segundo plano, mesmo que seus efeitos sejam devastadores. Este é um desafio muito grande e que torna a segurança mais difícil (e importante) do que a confiança. Quem "confia", sente-se "seguro", certo? Confiança é você acreditar que, quando o controle anticolisão do veículo falhar, ele voltará a funcionar como um veículo antigo lhe devolvendo o controle, e não que ele se espatife na próxima árvore que encontrar no caminho a 200 km/h. Se você não se sente seguro, dificilmente ativará essa funcionalidade do veículo, pois não há confiança. Confiança é você acreditar que se por algum motivo o braço mecânico do robô que está fazendo sua cirurgia falhar, ele será tranquilamente removido por um elemento humano, antes que decida brincar de jogo da velha com algum órgão interno seu. Mas como confiar nesses sistemas com tantos casos de dispositivos que negligenciaram a segurança no passado e que continuam negligenciando ainda hoje? Com códigos tão mal escritos? Sabendo que tratam-se de softwares extremamente complexos que rodam em rede? Como vamos esperar que aplicações melhores sejam desenvolvidas, se nos acostumamos com pior, se nos acostumamos a reiniciar o computador quando algo dá errado e está tudo bem?

Conforme Bruce Schneier na sua apresentação para a Black Hat uma das soluções para os problemas de segurança passa por fazer códigos mais simples, pois quanto mais complexo for o código do programa, mais falhas ele terá. A fórmula na verdade é bem simples: 
  • Mais complexidade -> Mais código -> Mais erros
  • Mais erros -> mais vulnerabilidades de segurança (conhecidas ou não)
Mas o que estamos vendo vai justamente na contramão desse processo. Os códigos estão cada vez mais complexos e cheios de funcionalidades (algumas bem inúteis ou que nunca serão utilizadas) e a responsabilização dos fabricantes cada vez mais ignorada. Afinal, todo software possui erros, certo? Enquanto os fabricantes dos produtos não forem chamados às suas responsabilidades com mais rigor, não criarem códigos mais simples e com testes mais exaustivos, creio que continuaremos vivendo essa assincronia entre confiança e segurança, pois estamos confiando cada vez mais em softwares e a sensação de segurança é cada vez menor.

Você confia? E se sente seguro? Novamente, queria ser como você. Afinal, "Errar é humano, mas para estragar tudo mesmo é preciso um computador" - Paul Ehrlich (Biologista americano). E lendo essa frase, o pensamento que me vêm a cabeça é: "E não é que é verdade?" ;o)

Fontes de pesquisa sobre bugs históricos:

t+

Cristiano
"A grandeza não consiste em receber honras, mas em merecê-las." - Aristóteles

terça-feira, 25 de fevereiro de 2014

CUPP.py: veja por que você não deve usar senhas fracas

Senhas, senhas e mais senhas. Já parou para se perguntar quantas senhas você têm para gerenciar? Senha de bancos, senhas de sistemas na empresa, senhas de serviços on-line. Meu software gerenciador de senhas, possui armazenado até a data de hoje (fevereiro/2014), 232 senhas de diferentes serviços. Simplesmente impossível de lembrar e gerenciar tudo isso, sem o auxílio de um gerenciador, mas afinal, é pra isso que existem os gerenciadores de senhas, certo? Para que nós não precisemos ficar decorando senhas ou anotando-as em locais inseguros. Lembre-se que o processo da segurança tem disso: a segurança diminui a facilidade de uso. É chato ter de gerenciar diferentes senhas? É, claro que é; trabalhoso inclusive. Quem me dera ter, por exemplo, uma única senha universal que desse acesso a todos os meus serviços. Bastaria eu me lembrar dessa senha única para poder logar nos meus 232 serviços distintos. Porém se alguém descobrisse essa senha, também teria acesso a todos as minhas aplicações e creio que a essa altura você já tenha entendido o equívoco que é utilizar a mesma senha para serviços diferentes, certo?.

Conforme o criptólogo e especialista em segurança Bruce Schneier, o conceito de senhas é baseado num oxímoro. A ideia é ter uma palavra randômica fácil de lembrar para  servir de autenticação. Infelizmente, se é fácil de lembrar, como “Cristiano” por exemplo, então não deve ser algo randômico. Se for randômico, como “TRsdj-dsi18*”, então certamente não é muito fácil de lembrar. Um conceito muito interessante que Schneier aborda no seu livro "Secrets & Lies" (que em breve colocarei na seção Livros deste blog), é justamente sobre autenticação; o quanto nós, seres humanos, somos especialistas nesse processo, afinal, autenticamos pessoas e coisas diversas vezes por dia. Fazemos isso desde pequenos, nosso cérebro é treinado para isso, somos experts. Se virmos uma pessoa das nossas relações na rua, usando barba, óculos escuros e chapéu, ainda assim somos capazes de reconhecê-la facilmente (motivo pelo qual super-heróis usam máscara e todos os amigos do Superman são perfeitos idiotas ;o)). Ao atender o telefone, é bem possível que no próprio alô já reconheçamos quem está do outro lado da linha desde que, obviamente, seja uma pessoa do nosso convívio.

Agora perceba que todo esse nosso poder de autenticar pessoas que viemos desenvolvendo desde o nosso nascimento é transferido para o computador através da simples combinação: "usuário x senha". Não é suficiente. Quando se entra num sistema com as informações de login, estão acontecendo dois processos distintos. O primeiro é o de identificação, ou seja, você diz ao computador quem você é através do seu nome de usuário. O segundo processo é o da autenticação propriamente dita, ou seja, você prova para o computador que você realmente é quem diz ser ao informar sua senha. Você consegue notar a fragilidade dessa lógica? Uma senha é algo que o usuário sabe e isso pode ser transmitido à qualquer outra pessoa. Se o usuário for desleixado o suficiente, essa informação pode ser inclusive roubada. O fato de alguém ter se logado num sistema especificando um usuário e uma senha, não significa necessariamente que aquela pessoa tinha permissão de uso ao sistema e sim que sabia de credenciais corretas, mas esse papo de autenticação ficará para outro post pois têm bastante pano pra manga, nesse post vamos manter o foco nas senhas. ;o)

Por mais insuficiente que seja a combinação usuário/senha os usuários sempre darão um jeitinho de piorar a situação: se você os deixar escolher uma senha sem qualquer critério, eles automaticamente escolherão uma senha fraca, como “internacional” ou “gremio”. Se você os forçar a escolher uma senha forte com letras maiúsculas, minúsculas, números e símbolos, eles irão anotar num papel e esconder embaixo do teclado. Se você os pedir para alterar, eles alterarão para a mesma senha que usavam no mês passado. Junte-se isso ao fato de usarem a mesma senha para diversos serviços diferentes e está feito o cenário do caos da segurança digital. Afinal, se até o Comando Aéreo Estratégico dos EUA mantiveram por 20 anos os códigos de lançamento dos mísseis nucleares como "00000000", o que impediria o usuário mediano de usar senhas fracas? Ah sim, "senhas fracas". Se você utiliza computadores há algum tempo, certamente já ouviu falar que não deve criar "senhas fracas" certo, mas o que isso quer dizer? Sem querer reinventar a roda, senhas fracas podem ser definidas como:

- Nome dos pais;
- nome de filhos;
- nome de amigos; 
- sobrenomes;
- datas de aniversário;
- números de telefone;
- números de documentos (RG, CPF, etc);
- placas de automóveis;
- nomes de agremiações esportivas;
- nome de animais de estimação;
- conjuntos musicais;
- artistas preferidos;
- nome da empresa onde trabalha;
- palavras contidas em dicionários (de qualquer idioma, mesmo que de trás pra frente) e etc;

Veja que esses são apenas alguns exemplos, essa lista não se encerra aqui. Para facilitar ainda mais o entendimento, vejamos um exemplo prático do porque não se deve utilizar esse tipo de senha. Para isso, utilizaremos a ferramenta CUPP.py disponível no Backtrack para criar uma lista de senhas, também conhecida como "wordlist". Essa lista de senhas poderá ser utilizada com qualquer ferramentas de quebra de senhas por ataque de dicionário. O CUPP (Common User Passwords Profiler) é a mesma ferramenta que utilizamos no post sobre quebra de redes sem fio WPA/WPA2 e foi desenvolvida por Muris Kurgas. Essa é sua telinha inicial:


Imagine que temos um usuário chamado João que, ao ser solicitado para criar uma senha, definiu-a com o apelido do seu filho junto da sua data de nascimento: "pedrinho2011". Como nosso usuário sabe que essa não é uma senha forte e já ouviu falar que uma gama maior de caracteres deve ser utilizada para compor suas senhas, ele decidiu trocar algumas letras por números, para dificultar o trabalho de um possível invasor. Sua senha então ficou: "P3dr1nh02011" (João alterou o "e" por "3", o "i" por "1" e o "o" por "0"). João então testou a referida senha no site "How Secure is My Password", e teve a confirmação de que essa era uma senha forte, afinal, um computador Desktop normal levaria em torno de 25.000 anos para quebrá-la.


Porém esse cálculo é feito considerando-se o método de força bruta. Num ataque de dicionário, uma wordlist será utilizada para tentar quebrar a senha do João, ou seja, tudo dependerá da qualidade da wordlist do atacante. O CUPP.py nos permitirá criar uma wordlist personalizada, sempre levando em consideração que nosso usuário foi tolo o suficiente para utilizar informações pessoais para compor uma senha. Nesse caso, estamos supondo também que o atacante pode ser uma pessoa próxima a João ou mesmo que tenha descoberto diversos dados pessoais através de currículos coletados na Internet, redes sociais ou mesmo através de engenharia social.

Ao rodar o Cupp com o parâmetro "-i", o programa executará no modo interativo, solicitando as informações do alvo para o atacante. Veja na imagem abaixo que foram solicitados o nome do alvo, seu sobrenome, apelido e data de nascimento, informações sobre o cônjuge do alvo, informações sobre o filho do alvo, nome do animal de estimação e nome da empresa onde trabalha.


Além disso, foi questionado se era necessário adicionar palavras específicas sobre a vítima. No exemplo, considerei que João é um gremista fanático e adicionei palavras como "gremio", "futebol", "zeroberto" e "barcos". O programa questiona se é necessário inserir caracteres especiais, ao qual eu confirmei. O programa questiona se é necessário adicionar números randômicos ao final das palavras, o que eu também confirmei. Por último, o programa questiona se deve ser utilizado o modo "Leet", ou seja, substituir letras por números ("leet" vira "1337", por exemplo), o que eu também confirmei. O resultado, é uma wordlist com 483.422 senhas sugeridas pelo programa. Entre elas, veja a senha que ele sugere abaixo:


Se este arquivo fosse utilizado como wordlist num ataque de dicionário contra o usuário João, certamente sua senha seria quebrada. Então novamente, caso ainda não tenha ficado claro o suficiente: NÃO UTILIZE ESSE TIPO DE SENHA!!!! NÃO COMPONHA SENHAS USANDO INFORMAÇÕES PESSOAIS. São extremamente fáceis de serem quebradas e existem ferramentas específicas para isso.

É importante notar que o CUPP possui um arquivo de configuração no seu diretório corrente, chamado cupp.cfg. Nele, é possível configurar os caracteres utilizados na opção "leet". Você pode por exemplo, definir que a letra "a" deve ser substituída por "4" ou por "@" ou mesmo por ambas, como mostra a figura abaixo:


Também é possível configurar quais caracteres especiais devem ser utilizados, comprimento mínimo e máximo que devem ser utilizados para compor as senhas, entre outras opções que merecem atenção.


Portanto permanece o alerta: evite criar senhas fracas e, se você utiliza informações pessoais nesse processo, saiba que essa também pode ser considerada uma senha fraca. Como criar senhas fortes? Dê uma olhadinha aqui.
Para finalizar, outra informação importante que devemos atentar refere-se ao ato de anotar senhas em papel, e aqui, diversos especialistas de segurança da informação poderão tirar-lhe a vida se souberem que você adota essa prática (inclusive eu iria, até pouco tempo atrás ;o)). O mesmo Schneier, defende que a situação ideal, seria transformar o processo de autenticação única num processo de autenticação dupla. A autenticação única, com usuário e senha a qual estamos acostumados, baseia-se em algo que o usuário sabe. Se o usuário escrever parte da senha num papel ele estará transformando algo que ele sabe (a senha), em algo que ele tem (a folha de papel). Note que o efeito é o mesmo do que ter um cartão bancário onde, para retirar dinheiro você precisa informar a senha (algo que você sabe) e passar o cartão magnético (algo que você tem).  É claro que, para essa lógica funcionar, a parte da senha anotada no papel deve ser grande e aleatória o suficiente para tornar essa senha segura. Na próxima vez que o usuário logar, estará usando uma autenticação dupla, especificando algo que ele sabe e utilizando algo que ele tem guardado na carteira.

Suponha por exemplo que vamos utilizar a senha criada nesse exemplo: (Meu vizinho João, 87, gosta bastante de limonada. = MvJ,87,gbdl.). A essa senha, vou adicionar caracteres aleatórios: "@Mg7F-097DsLp-12". Alteraria então minha senha do Twitter (apenas um exemplo de serviço) para: "MvJ,87,gbdl.@Mg7F-097DsLp-12", sendo que "MvJ,87,gbdl." é a parte que eu sei e "@Mg7F-097DsLp-12" é a parte que levo anotada na carteira. Segundo o "How Secure is My Password", são necessários 252 undecilhões de anos para quebrar essa senha (me arrisco a dizer que ela é segura ;o)):


Note que mesmo com essa técnica, alguns problemas de segurança permanecem, pois não adianta fazer todo esse processo, se você "emprestar" algo que você sabe (senha) e algo que você tem (o papel com a informação aleatória) para outras pessoas logarem por você (mais ou menos o que você faz quando está com preguiça e dá seu cartão do banco e senha para outras pessoas comprarem coisas por você na padaria, tsc tsc tsc). Ainda assim, é possível tornar esse processo bem mais seguro. Esse é certamente um bom sistema pessoal de autenticação, desde que a segunda parte da senha esteja guardada com segurança. Mesmo que alguém consiga visualizar a informação escrita no papel, terá apenas um pedaço da senha. Como alternativa eu recomendaria o uso de programas como o KeePass, que podem ser instalados tanto no PC quanto em smartphones. Ao invés de guardar essa informação na carteira, você pode guardá-la com criptografia num programa no seu smartphone. Ainda assim, muito interessante a ideia de levar parte da senha na carteira. Afinal, que outro lugar melhor para guardar essa informação do que no mesmo local onde você guarda seu dinheiro, sua identificação, seus cartões de crédito e etc? Grande Schneier.

P.S.: esse post demonstra apenas um tipo de ataque à senhas dos usuários. Existem diversas outras maneiras de se chegar ao mesmo ponto e esse post nem de longe pretende esgotar o assunto.

t+

Cristiano
"A grandeza não consiste em receber honras, mas em merecê-las." - Aristóteles 

quinta-feira, 20 de fevereiro de 2014

Palestra no La Salle Esteio

Aconteceu no dia 19/02/2014 no La Salle Esteio uma série de 4 palestras sobre "Cyberbullying" e "Segurança na Internet" com os alunos da instituição. A proposta era fazer na volta às aulas, uma aula inaugural onde os alunos pudessem ser alertados sobre os diversos aspectos e problemas causados pelo cyberbullying e instruí-los quanto a alguns cuidados necessários para utilizar a internet com segurança. 


 

Tive a oportunidade de trabalhar com diversas turmas desde a 5º série até o ensino médio e confesso que fiquei muito feliz e satisfeito com o resultado. As turmas em geral, mesmo os pequenos de 12, 13 anos, foram muito participativos, me deixaram muito a vontade e propiciaram um ambiente muito bacana para que pudéssemos discutir o assunto.

Com os mais pequenos, foram discutidas as características do cyberbullying, o que difere o bullying do cyberbullying, estratégias para tentar prevenir e/ou combater esse problema, maneiras de fazer uma denúncia, casos que podem ser enquadrados como crimes, a responsabilidade dos pais e etc. Discutimos também sobre "celebridades", que passaram por esse problema na sua juventude mas que conseguiram superar essas adversidades. 


É fundamental salientar para eles a importância de criarmos uma ambiente sinérgico entre escola, famílias e comunidade para acabarmos com essa prática que tem atingido tantos dos nossos jovens hoje em dia.


 Já com os maiores, o assunto foi especificamente segurança na Internet e como evitar a superexposição a qual, infelizmente, já estamos nos acostumando. Discutimos assuntos como a origem militar da Internet, porque nos preocuparmos com segurança, engenharia social, hoaxes (boatos), superexposição, e para onde as novas tecnologias estão nos levando no que diz respeito à segurança.

Agradeço novamente a escola pela oportunidade de conversar com essa galerinha e fico muito feliz que tenha conseguido levar informações importantes para que possam discutir com seus pais, amigos e familiares. 


t+

Cristiano
"A grandeza não consiste em receber honras, mas em merecê-las." - Aristóteles

Related Posts Plugin for WordPress, Blogger...