Beyond Stack Smashing : Recent Advances in Exploiting Buffer Overruns
Artigo de Jonathan Pincus e Brandon Baker publicado em IEEE Computer Society 1540-7993/4
Neste artigo são descritas três modos de exploits para buffer overrun, também conhecidos como Buffer Overflow : arc injection, pointer subterfuge, e heap smashing.
O método tradicional de exploração de buffer overrunns é através de stack smashing, que ocorre através da modificação do endereço de retorno salvo no stack (região da memória empregada para armazenamento de parâmetros, variáveis locais e endereços de retorno), que aponta para o código do atacante que reside num buffer stack do sistema atacado.
Hackers criaram formas de explorar buffer overruns. A técnica Heap smaching permite exploração de buffer overruns na área da memória alocada dinamicamente.
Explorando Buffer Overruns
Um buffer overrun ocorre quando uma aplicação tenta ler ou escrever além do endereçamento de um array declarado na área de buffer da memória. O Buffer overrun ocasiona exceções em linguagens como Pascal, Ada, Java, porém linguagens como C e C++ não realizam nenhum tipo de checagem.
Stack Smashing
É uma técnica descrita em detalhes pelos hackers AlephOne e DillDog, na qual troca-se o controle de fluxo de dados para executar o código criado pelo atacante. A técnica se vale do fato de que a maioria dos compiladores C armazenam o endereço de retorno salvo na mesma pilha usada para as variáveis locais.
Arc Injection
Nesta técnica o atacante fornece dados a uma aplicação, tendo como retorno o efeito desejado e com o objetivo de modificar o endereço de retorno. Em geral o endereço de retorno passa a apontar para algum local que contenha alguma função específica.
Pointer Subterfuge
Pointer Subterfuge utiliza-se da alteração de valores de ponteiros. Algumas variações são: funtion-pointer clobbering, data-pointer modification, exception-handler hijcking e virtual pointer smashing.
Heap Smashing
Heap Smashing explora implementações em memória dinâmicas alocadas por violação em algumas invariantes assumidas.
Conclusão
O desenvolvimento de software seguro vem se tornando cada vez mais necessário, onde é de grande importância o conhecimento das vulnerabilidades de linguagens como C, C++, de forma a estudar os ataques que possam ocorrem nestes ambientes. Esforços devem ser empregados para minimizar as vulnerabilidades encontradas nestes ambientes, de modo a diminuir cada vez mais a chance de erros de programação.
terça-feira, 6 de julho de 2010
Resumo do artigo "Reflections on Trusting Trust" de Ken Thompson
Reflections on Trusting Trust
Neste artigo, Ken Thompson, um dos criadores do UNIX, relata que é possível modificar os compiladores de modo a comprometer a segurança daqueles que o utilizam, introduzindo código malicioso. Ele implantou um trojan horse (cavalo de tróia) no compilador C para o programa de login do Unix. Uma vez instalado em um computador, este compilador habilitaria um acesso ao sistema como qualquer usuário. Por ter sido compilado junto ao sistema operacional, este cavalo de tróia não é detectado no código fonte, sendo que só pode ser descoberto se for inspecionado o código binário. Neste caso foi empregada uma técnica de ataque chamada de dupla compilação diversa (DDC).
No caso da linguagem de programação C, o compilador C é escrito em C, e segundo o autor, problemas surgem quando compiladores são escritos na sua própria linguagem. Thompson demonstra que não se pode confiar em compiladores que não têm procedência, pois a maioria dos programas de código aberto possuem relativa segurança.
Assim recomenda-se verificar a procedência e a integridade de compiladores, principalmente de onde não se tenha acesso ao código fonte, sendo importante acreditar em toda a infra-estrutura de compilação, pois os mesmos podem ter códigos maleficamente implementados e podem ser ativados quando um determinado padrão for encontrado em um código-fonte.
Neste artigo, Ken Thompson, um dos criadores do UNIX, relata que é possível modificar os compiladores de modo a comprometer a segurança daqueles que o utilizam, introduzindo código malicioso. Ele implantou um trojan horse (cavalo de tróia) no compilador C para o programa de login do Unix. Uma vez instalado em um computador, este compilador habilitaria um acesso ao sistema como qualquer usuário. Por ter sido compilado junto ao sistema operacional, este cavalo de tróia não é detectado no código fonte, sendo que só pode ser descoberto se for inspecionado o código binário. Neste caso foi empregada uma técnica de ataque chamada de dupla compilação diversa (DDC).
No caso da linguagem de programação C, o compilador C é escrito em C, e segundo o autor, problemas surgem quando compiladores são escritos na sua própria linguagem. Thompson demonstra que não se pode confiar em compiladores que não têm procedência, pois a maioria dos programas de código aberto possuem relativa segurança.
Assim recomenda-se verificar a procedência e a integridade de compiladores, principalmente de onde não se tenha acesso ao código fonte, sendo importante acreditar em toda a infra-estrutura de compilação, pois os mesmos podem ter códigos maleficamente implementados e podem ser ativados quando um determinado padrão for encontrado em um código-fonte.
quarta-feira, 5 de maio de 2010
Novidades sobre Cloud Computing
Em 27/04/2010, a Cloud Security Alliance (CSA) disponibilizou um material chamado "Cloud Controls Matrix V1", uma matriz que auxilia os gestores a identificar e mapear os riscos de segurança relacionados a Cloud Computing. Para cada um dos 98 controles sugeridos, a matriz indica se ele se aplica ao fornecedor de serviços ("service provider") ou ao cliente, e relaciona este controle às principais regulamentações existentes (COBIT, HIPAA, ISO/IEC 27002-2005, NIST SP800-53 e o PCI DSS).
terça-feira, 4 de maio de 2010
Criptografia com o uso de curvas elípticas

Origens
A Criptografia de Curvas Elípticas (ECC) utiliza uma variação da criptografia assimétrica, baseada na matemática das curvas elípticas. Seus criadores argumentam que a ECC pode ser mais rápida e usar chaves mais curtas do que os métodos antigos como RSA, e proporcionando ao mesmo tempo um nível de segurança equivalente. Seu uso foi proposto por Neal Koblitz e Victor Miller em 1985.
Existem algumas versões de criptografia de curvas elípticas. Tais versões, com pequenas variações em seus algoritmos, se baseiam na dificuldade de resolução do problema do logaritmo discreto para o grupo de uma curva elíptica sobre alguns grupos finitos.
Funcionamento
Em matemática, as curvas elípticas são definidas por equações de grau três.
As equações são utilizadas para provar o último teorema de Fermat sendo empregadas com frequência em criptografia.
As curvas elípticas são "regulares", o que significa que não têm "cúspides" nem auto-intersecções, e se pode definir uma operação binária para o conjunto de seus pontos de uma maneira geométrica natural, o que faz deste conjunto um grupo abeliano.
Dada uma curva elíptica E, e um grupo G(q), consideramos o grupo abeliano de pontos racionais E(q) na forma (x, y), onde x e y pertencem a G(q), e onde a operação de grupo + se define nesta curva. Define-se então uma segunda operação "*" Z×E(q) → E(q): se P é algum ponto em E(q), então definimos 2*P = P + P, 3*P = 2*P + P = P + P + P, e assim por diante. Note-se que dados os inteiros j e k, j*(k*P) = (j*k)*P = k*(j*P). O problema do logaritmo discreto de uma curva elíptica (PLDCE) é, determinar o inteiro k, dados os pontos P e Q, quando k*P = Q.
Vantagens
O algoritmo ECC tem sido reconhecida como o mais forte para um dado comprimento de chave, com utilização provável em conexões de rede que tenham requisitos muito limitados de largura de banda.
O NIST e o grupo X9 da ANSI estabeleceram requisitos mínimos de tamanho de chave: 1024 bits para RSA e DSA e 160 bits para ECC, correspondentes a um bloco simétrico de de 80 bits. O NIST publicou uma lista de curvas elípticas recomendadas de 5 tamanhos distintos de chave: 80, 112, 128, 192 e 256 bits. Em geral o algoritmo ECC sobre um grupo binário requer uma chave assimétrica com o dobro de tamanho do que aquele correspondente a uma chave simétrica.
A Carga Computacional mede a eficiência com que os algoritmos podem implementar as transformações com as chaves públicas e privadas (sistema em operação). As melhores implementações de cada um dos sistemas ("state-of-the-art implementations") indicam que o ECC é executado aproximadamente 10 vezes mais rápido que o RSA ou DSA.
O Tamanho de Banda corresponde a quantos bits (a mais) temos que transmitir após criptografar ou assinar uma mensagem, em relação a mensagem original. O ECC se destaca exclusivamente nos casos em que são processadas mensagens pequenas . Visualizando os sistemas de criptografia com chave pública como ferramenta de troca de chave (utiliza transformação de mensagens pequenas), essa vantagem do ECC torna-se ainda mais significativa.
Desvantagens
Desvantagens da utilização da Criptografia por Curvas Elípticas:
a) Tamanho da chave - sistemas criptográficos sobre chaves ainda mais pequenas;
b) ECC é matematicamente sub-utilizado em relação ao RSA e ao SDL;
links de referência:
Neal Koblitz, "Elliptic curve cryptosystems", Mathematics of Computation 48, 1987, pp203–209.
http://twiki.di.uminho.pt/twiki/pub/Education/Criptografia/CriptografiaMestrados/ECC_report_ibraim.pdf
http://www.lockabit.coppe.ufrj.br/downloads/academicos/ECCMono.pdf
http://pt.wikipedia.org/wiki/Curva_el%C3%ADptica
http://pt.wikipedia.org/wiki/Criptografia_de_Curvas_El%C3%ADpticas
Assinar:
Postagens (Atom)