Segundo Fred Cohen, no artigo “20 Tips on Software Security”, projetar e executar sistemas de software seguros podem ser complexos, contudo, o autor descreve 20 dicas para auxiliar os desenvolvedores de softwares a construir sistemas mais seguros. Esta 20 dicas são divididas em 05 partes.

Segue abaixo um paralelo entre o artigo de Cohen e O CLASP (Comprehensive, Lightweight Application Security Process) que é um documento que descreve as melhores práticas de devenvolvimento de softwares seguros. O CLASP mantém uma lista de 104 tipos de vulnerabilidades submetidos dentro de 05 categorias.

Parte 3 – Use medidas razoáveis e prudentes:

10 - Do an independent protection audit before release

Se o produto possui características de segurança, deve-se testar todas as funcionalidades para evitar desgastes futuros. Tenha alguém no projeto que conheça de testes voltados para segurança.

11 - Use good change control in your software update process

O emprego de um controle de mudanças no processo de atualização de um software evita embaraços com clientes. Descrito pelo CLASP como erros de lógica, falta de parâmetros em procedimentos.

12 - Provide a secure manufacturing and distribution mechanism

Prover um mecanismo de produção e distribuição seguros. É importante adotar estratégias de segurança para que o sistema não chegue ao mercado com algum tipo de vírus embutido. Classificado pelo CLASP como erros ambientais.

13 - Track who does what and attribute faults to root causes

Erros são cometidos por todos, e a maioria dos erros são similares num ambiente. Deve-se encontrar a origem dos problemas e adotar maneiras de eliminá-los. Identifique quem faz o que no projeto. Categorizado pelo CLASP como erros gerais de lógica, falta de parâmetros .

Parte 4 – Forneça um processo de beta-teste que ajude a encontrar  falhas:

14 - Internal beta-testing should seek out flaws relentlessly

Um beta teste interno deve procurar falhas no sistema. Mantenha uma equipe interna que saída sobre teste de segurança. O custo de reparar erros relacionados à segurança é maior após o software ser liberado para uso. Classificado pelo CLASP como erros gerais de lógica.

15 - Get some monkeys on your keyboards

Erros no software podem ser descobertos com entrada de dados incorretos, o que pode resultar numa falha a ser explorada pelo atacante. Classificado pelo CLASP como erros gerais de lógica.

16 - Build a repeatable testing capability

Contruir uma capacidade de repetição nos testes. A repetibilidade e a automação do processo de teste do software são a chaves principal para o sucesso e a eficiência.

17 - Get an outside community with an interest in finding and fixing holes

Se você não pode testar o software sozinho, procure uma comunidade externa que o auxilie.

Parte 5 – Apenas porque você não seja perfeito não significa que você não tentou.

18 - Don't throw up your hands - work the issues

Mesmo que você não consiga resolver um problema da melhor maneira, você deve fazer o bastante de forma suficiente para garantir uma base de segurança.

19 - Use constant quality improvement to enhance your security

Faça uso de uma constante melhoria de qualidade no produto para realçar a segurança.

20 - People that complain about 'defensive programming' don't belong

Pessoas que se queixam sobre programação defensiva não fazem parte do ambiente de programação profissional. Muitas vezes programas dependem de outros programas e programadores também dependem de outros programadores.

Este artigo descreve três famílias de exploits para buffer overrun, também conhecidos como Buffer Overflow : arc injection, pointer subterfuge, e heap smashing. Sistemas desenvolvidos com baixa segurança são a causa principal das vulnerabilidades por parte destes novos tipos de ataques.

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.

Na década passada, porém, hackers criaram várias formas de explorar buffer overruns. A técnica Heap smaching permite exploração de buffer overruns na área da memória alocada dinamicamente, o oposto à pilha. O exploit Apacha/Open_SSL Slapper worm utiliza a técnica heap smashing para explorar uma vulnerabilidade no Servidor OpenSSL.

Explorando Buffer Overruns

Um buffer overrun ocorre quando uma aplicação tenta ler ou escrever além do array determinado 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 que foi descrita em detalhes na década de 90 pelos hackers AlephOne e DillDog, na qual consiste de duas etapas : trocar o controle de fluxo de dados para executar o código criado pelo atacante. A técnica confia no 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

Esta técnica ocorre quando o atacante fornece dados a uma aplicação, tendo como retorno o efeito desejado, ou seja, também tem o objetivo de modificar o endereço de retorno. Geralmente faz com que aponte para algum local que contenha alguma função específica.

Pointer Subterfuge

Pointer Subterfuge é uma técnica de exploração que utiliza da alteração de valores de ponteiros. Pode-se citar pelo menos quatro variantes de Pointer Subterfuge : funtion-pointer clobbering, data-pointer modification, exception-handler hijcking e virtual pointer smashing.

Heap Smashing

Até recentemente, especialistas acreditavam que somente pilhas de buffers eram vulneráveis a ataques do tipo exploits. Porém, vários exploits do tipo Pointer Subterfuge desafiaram esta suposição, sendo que foi desenvolvido um ataque específico para memória Heap que deste então ficou conhecido como Heap Smashing.

Heap Smashing explora implementações em memória dinâmicas alocadas por violação em algumas invariantes assumidas.

Conclusão

É importante que desenvolvedores de sistemas tenham conhecimento das vulnerabilidades de linguagens como C, C++, de forma a estudar os ataques que possam ocorrem nestes ambientes. Os esforços devem ser empregados para abrandar as vulnerabilidades encontradas nestes ambientes, como observar o processo inteiro da programação do software para evitar erros de programação.

O artigo descreve a técnica SQL Injection, que explora vulnerabilidades em aplicações Web desenvolvidas sem segurança, e mostra técnicas de segurança para proteção desta vulnerabilidade.

SQL Injection uma vulnerabilidade que envolve os Banco de Dados relacionais, onde os hackers injetam comandos SQL não autorizados, induzindo outra consulta ao Banco. Esta vulnerabilidade ocorre por falha do desenvolvedor que utiliza qualquer linguagem Server-side (PHP, Coldfusion, ASP, etc.), onde o programador cria códigos de acesso ao Banco de Dados sem se importar com eventuais explorações. Uma das formas de se evitar é que sempre sejam validados os dados enviados pelo usuário.

O artigo, escrito por Kevin Spett, relata as seguintes técnicas de SQL Injection :

Bypass de autorização

Uso do comando Select

Uso do comando Inset

Uso de store procedure no SQL Server

O autor recomenda duas soluções contra ataques de SQL Injection :

Data Sanitization : Os dados fornecidos pelo cliente devem estar limpos de caracteres especiais ou strings que possam ser utilizadas de maneira maliciosa, sendo que deve ser feito por todas as aplicações, e não apenas por aquelas que usam queries SQL.

Códigos seguros SQL para aplicações WEB :  Existem algumas pequenas regras específicas para SQL Injection. Em primeiro lucar, limite o tamanho das entradas dos usuários, até mesmo para os dados numéricos. Em seguida, limite os direitos de acesso do usuário ao Banco de Dados. Não permita que o usuário tenha direito de acesso a todas as store procedures do sistema se o usuário tem necessidade de partes dos dados do sistema.

Conclusão

Pensar desenvolvimento de sistemas seguros deve fazer parte da rotina de programação. As possibilidades  de ataque e roubo de informações através da técnica de SQL Injection são várias e os desenvolvedores, na maioria das vezes não conhecem este tipo de vulnerabilidade.

Este artigo faz referência aos projetos e análise de sistemas de software seguros de acordo com requisitos de sistemas sob a forma de casos de uso e casos de mau uso, que são empregados na engenharia de software para descrever os requisitos funcionais de um sistema. Devido às crescentes ameaças  de segurança no software, é comum que os problemas de segurança estejam presentes em todos os estágios do desenvolvimento do software. O emprego da técnica de casos de uso e de mau uso têm como propósito melhorar a rastreabilidadea dos problemas de segurança no projeto de desenvolvimento de um software, onde os autores demonstram a técnica no estudo de caso de um software em um ambiente hospitalar.

A técnica de análise arquitetural baseada em casos de mau-uso, para identificar as vulnerabilidades que as fontes de ameaças podem utilizar para realizar ataques ao sistema, consiste nos seguintes passos :

1. Usuários e comportamentos

As seguintes ações devem ser executadas neste passo :

a)       Identificar os usuários que utilizarão o sistema, através de informação passadas pelos responsáveis do projeto;

b)       Entrevistar os usuários para descobrir as funções que os mesmos utilizarão no sistema;

c)       Identificar os usuários que farão acesso a funções relacionadas ã segurança do sistema a ser desenvolvido.

2. Identificar os casos de uso e casos de mau uso

As seguintes ações devem ser executadas neste passo :

d)       Identificação dos atores, usos do sistema e criação dos cenários do ambiente;

e)       Desenvolver diagramas de casos de uso e casos de mau uso, como forma de mitigar as ameaças ao sistema

3. Proposta de arquitetura e de avaliação

Os componentes candidatos de uma arquitetura são obtidos a partir das tarefas empregando os diagramas de mau uso. As tarefas de sobreposição são consolidadadas numa única tarefa que cobre as ações de outras tarefas. A partir da lista das tarefas, identificar as tarefas diretas (nenhuma mudança necessária aos componentes envolvidos) ou indiretas (mudanças necessárias aos componentes). Para os componentes indiretos deve ser listada as mudanças necessárias. Após a classificação dos componentes, desenhar um diagrama exibindo estes componentes. Repita estas etapas para cada proposta arquitetônica.

4. Selecionar a arquitetura mais apropriada

Para selecionar a melhor arquitetura, são analisados todos os aspectos positivos de cada proposta e ajustados os componentes e suas interações em um modelo compreensível. É então criado um desenho arquitetônico para mostras os componentes e suas interações. Nesta etapa  é importante fornecer um apoio racional para as alterações que foram feitas.

Neste artigo, Ken Thompson, um dos criadores do UNIX, relata que é possível modificar os compiladores (ferramentas que transformam códigos escritos em alguma linguagem de programação em linguagem de máquina). 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. Este cavalo de tróia não é detectado o código fonte, sendo que só pode ser descoberto se for inspecionado o código binário. A técnica de ataque empregada é chamada de dupla compilação diversa (DDC), onde o código fonte é recompilado duas vezes.

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.

É recomendável verificar a procedência e a integridade de compiladores, 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.

Referências :

Artigo: Reflections on Trusting Trust, Ken Thompson

http://www.dwheeler.com/trusting-trust/

A utilização de Criptografia com Curvas Elípticas foi proposta em 1985, pelos matemáticos Neal Koblitz e Victor Miller, como uma nova forma para sistemas criptográficos de chave pública. Eles se basearam nos algorítmos de chaves públicas já existentes, como o algoritmo de Diffie e Hellman, fazendo uso das curvas elípticas. Portanto, os sistemas criptográficos que fazem de curvas elípticas se baseiam em modificações de outros sistemas, com o diferencial de proverem sistemas criptográficos assimétricos mais seguros e com chaves menores, resolvendo um grande problema dos algoritmos de chave pública, que se refere ao grande tamanho de suas chaves. Koblitz e Miller desenvolveram uma forma de utilizar o grupo de pontos de uma curva elíptica sobre um corpo finito para implementar griptografia de chave pública.

As equações cúbicas para curvas elípticas têm a seguinte forma :

y² + a1xy + a3y = x³ + a2x² + a4x + a5,

As variáveis x e y situam-se no plano. Na verdade, x e y podem ser complexos, reais, inteiros, base polinomial, base canônica ou qualquer outro tipo de elemento de corpo

A base para a segurança dos sistemas criptográficos baseados em curvas elípticas, chamados de ECC (Elliptic Curve Cryptosystem), é a suposta intratabilidade do problema do logaritmo discreto no grupo de pontos de uma curva elíptica, que pode ser resumido da seguinte forma: data uma curva elíptica E definida sobre um corpo finito, um ponto P da curva de ordem n, e um ponto Q, determine o inteiro  k, 0 £ k £ n-1, tal que Q = kP.  Matemáticos no mundo inteiro se dedicam ao estudo dos logaritmos discretos de curvas elípticas, e nenhuma fraqueza foi descoberta.

Atualmente, três tipos de sistemas de criptografia com chave pública são considerados seguros e eficientes, classificados de acordo com o problema matemático em que eles se baseiam :

1. Sistemas de fatoração de inteiros (Integer Factorization Systems - IFS), baseados no problema de fatoração de inteiros (Integer Factorization Problem - IFP)
2. Sistemas de logaritmo discreto (Discrete Logarithm System - DLS), baseados no problema do logaritmo discreto (Discrete Logarithm Problem - DLP)
3. Sistemas de curva elíptica (Elliptic Curve Discrete Logarithm System - ECDLS), baseados no problema do logaritmo discreto em curvas elípticas (Elliptic Curve Discrete Logarithm Problem - ECDLP).

Referências :

Gabriel Belingueres. Introducción A Los Criptosistemas de Curva Elíptica. Em http://www.publispain.com/supertutoriales/matematica/criptografia/cursos/2/curva.pdf

JURISIC, A.; MENEZES, A. J. Elliptic Curves and Cryptography. (Ontario: Certicom White Paper em http://www.certicom.ca/ecc/weccrypt.htm, 1997

http://www.smartsec.com.br/curvaselipticas.html

http://www.ccet.unimontes.br/arquivos/monografias/261.pdf

O GSM (Global System Mobile) é o sistema de telefonia móvel padrão na Europa, sendo o mais utilizado em todo o mundo. Foi o primeiro sistema a oferecer serviços de segurança, como autenticação, sigilo e distribuição de chaves de sessão.

A tecnologia GSM combina os sistemas TDMA, FDMA e FDD, ou seja, usa simultaneamente o múltiplo acesso (MA) por divisão e freqüência das portadoras (FDMA), o múltiplo acesso por divisão de tempo (TDMA) de cada portadora e usa uma faixa de freqüência para cada sentio de transmissão (FDD = Freqüency Division Duplex).

As informações referentes à assinatura e identificação  do usuário não estão embutidas no aparelho celular, e sim no chip destacável denominado SIM card (

Subscriber Identity Module), onde está contida a chave secreta, conhecida somente pelo chip e pela identidade HLR (Home Location Register), que contêm toda informação sobre o assinante.

Na tecnologia GSM, após a autenticação do usuário, estabelece-se uma chave Kc conhecida por ambas as partes (BTS e MS) com a qual as mensagens transmitidas e recebidas são cifradas por um algoritmo de stream cipher – que, ao contrário dos block ciphers, encriptam cada caractere (usualmente cada bit) de uma seqüência – chamado A5.

O GSM faz uso do sistema de criptografia de chave simétrica, e utiliza como processo de autenticação um mecanismo de desafio-resposta. Para garantir a segurança na comunicação, a tecnologia GSM faz uso de três algoritmos de segurança (A3, A5 e A8), sendo o A3 empregado para gerar o desafio-resposta, o A5 para cifrar e decifrar as mensagens e o A8 para gerar a chave de sessão.

O algoritmo A5 possui duas versões : o A5/1, versão mais forte, utilizada nos EUA e Europa Ocidental; o A5/2, versão mais fraca e exportável utilizada nos outros países.

A versão A5/1 possui uma chave de 64  bits, porém faz uso efetivo de 54 bits. O A5/1 realiza a cifragem das mensagens baseado em três LFSRs (Linear Feedback Shift Register) controlados por clock, sendo que os comprimentos dos registros são 19, 22 e 23. O resultado de saída é um XOR dos três registros LFSRs.

Ataques ao protocolo A5

Os ataques praticados à tecnologia GSM ocorrem sobre as vulnerabilidades encontradas no algoritmo A5/1. Basicamente, dois tipos de ataques acontecem sobre o A5/1 :  : known ciphertext attack ou known plaintext attack .

No ataque do tipo known ciphertext attack, o atacante possui somente o texto cifrado e necessita obter o texto claro ou a chave simétrica para decifrar a mensagem.  As etapas para a execução do ataque são : Dada uma seqüência de frame counters Fn {0,1}22 e uma seqüência de pares de frames cifrados Cn {0,1}114 x {0,1}114, um ataque ao A5/1 tem como objetivo  descobrir informações sobre o texto claro Pn {0,1}114 x {0,1}114 ou sobre a chave de sessão Kc.

De posse destes dados, um ataque de força bruta faz uma busca no espaço de todas as chaves Kc {0,1}64 possíveis criando um conjunto de seqüências pseudo-randômicas Xn {0,1}114 x {0,1}114 para cada frame e computando os pares de texto claro Pn para cada par Cn.

Para a concretização deste ataque é necessária a utilização de um algoritmo de reconhecimento de texto claro eficiente. A dificuldade de implementar tal  algoritmo limita a possibilidade prática do ataque de força bruta. Contudo, se a seqüência computada de Pn’s formar um texto claro válido, a chave Kc candidata foi encontrada.

O ataque do tipo known plaintext attack, supõe-se que o atacante possua uma parte do texto cifrado e o texto claro, tentando, então, obter a chave utilizada para cifrar a mensagem. É importante salientar que cada segundo de conversação contêm aproximadamente 28 frames, sendo que os telefones GSM enviam um novo frame a cada 4.6 milissegundos.

Os ataques do tipo  known plaintext attack criam a partir de um conjunto de frames de texto cifrado e seus textos claros correspondentes, um conjunto de streams de bits de saída (bit strings y(t)|288 t=101) para o A5/1, e posteriormente, tenta-se computar o estado do A5/1 antes do embaralhamento do frame counter. Neste ataque as seguintes etapas são executadas :

1. Determinar a partir de um conjunto de streams de bit de saída o estado interno do

A5/1 para alguns ciclos t > 100.

2. Inverter o A5/1 para determinar um conjunto de estados iniciais possíveis.

3. Inverter o embaralhamento do frame counter para determinar o estado do A5/1 após o embaralhamento da chave de sessão.

O estado obtido no ultimo passo pode ser utilizado para gerar um stream de bits para qualquer frame counter desejado e então realizar ciframento e deciframento da chave de sessão.

Referências :

http://packetstormsecurity.nl/crypt/cryptanalysis/a51-pi.htm

http://www.tml.tkk.fi/Opinnot/Tik-110.501/2000/papers/tarkkala.pdf

http://cryptome.org/a51-bsw.htm

http://www.teleco.com.br/tutoriais/tutorialroubocel/pagina_2.asp

A criptografia é uma área da ciência que utiliza técnicas matemáticas para a cifragem de mensagens, tornando-as secretas. A criptografia surgiu praticamente com a escrita, pois desde a época dos egípcios, técnicas de cifragem de mensagens eram utilizadas para transmitir de forma segura as mensagens. A criptografia foi largamente utilizada para fins militares durante a Segunda Guerra Mundial.

A partir de 1926, os alemães utilizaram a máquina Enigma para gerar mensagens cifradas. Esta máquina era uma variação da máquina comercial do Enigma. Os códigos gerados pelo Enigma mudavan constantemente, o que resultou num trabalho intenso dos poloneses para decifrar as mensagens alemãs. Em 1932 os poloneses conseguiram quebrar os códigos gerados pelo Enigma através de duas máquinas que projetaram. Dentre os criptoanalistas poloneses que decifraram os código do Enigma, destacou-se o matemático Marian Adam Rejewski, que detectou as primeiras falhas no Enigma, construindo assim as primeiras bombas, que permitiam decifrar, por tentativa e erro, as mensagens geradas na máquina Enigma.

O serviço de inteligência da Polônia forneceu todo conhecimento adquirido aos seus aliados (Inglaterra e França), que refiram as bombas. Os ingleses então criaram o centro de inteligência em Betchley Park, próximo a Londres,  com o objetivo de quebrar as mensagens cifradas pelos alemães. Um dos matemáticos ingleses que se destacaram em Betchley Park foi Alan Turing. Um dos seus trabalhos foi a construção da máquina teórica de Turing, que, de acordo com um sistema formal, pudesse realizar operações computacionais. Sob sua liderança, foi projetado o computador Colossus, que tinha como missão quebrar os códigos das mensagens alemãs geradas pela máquina Enigma. Os códigos gerados pelo Enigma mudavam constantemente, obrigando o Colossus trabalhasse rápido para decifrar as mensagens

Em 1940, os alemães desenvolveram a máquina de criptografar Lorenz Schlussel-zusatz, utilizada pelo alto comando alemão. Os ingleses, a partir de 1944, desenvolveram a máquina Colossus I e II, que tinha capacidade de decifras mensagens alemãs codificadas. Até recentemente, poucas informações fora liberadas sobre estas máquinas.

No fim da guerra, Churchill temeu um novo inimigo, os russos, e ordenou que tudo fosse destruído em Betchley Park, com exceção das duas máquinas Colossus. Estas foram desmontadas nos anos 60.

Neste artigo pode-se observar que através de um trabalho intenso e organizado é possível realizar a quebra de mensagens cifradas, o que compromete toda a segurança do envio de informações.

Bibliografia

http://www.enigmahistory.org/enigma.html

PLIMMER, Beryl. Machines Invented for WW II Code Breaking. pp. 37-40. Vol 30 Nº 4 SIGCSE Bulletin. December 1998.

A reportagem refere-se a uma série de ataques cibernéticos do tipo DOS (Denial of Service), que começaram em abril de 2007 e interrompeu o serviço de vários sites em toda a Estônia.

A reportagem relata que o ataque pode ter acontecido pelo fato do governo da Estônia ter removido uma estátua de um soldado da 2ª. Guerra, o que gerou uma revolta por parte estonianos de ascendência russa. Houve especulações de que o ataque havia partido do governo russo, porém o governo da Estônia não tinha provas que os ataques partiram da Rússia.

Os atacantes utilizaram uma grande rede de bots, para ampliar o impacto do ataque, com o objetivo de enviar uma enxurrada de pacotes a todos os roteadores da rede, causando a interrupção dos serviços.

O ataque do tipo Denial of Service (negação de serviço) utiliza uma técnica de ataque que visa a indisponibilidade através da sobrecarga de solicitações de serviço (flood) e não a invasão do alvo. Algumas características deste tipo de ataque :

      Gera grande tráfego de dados (Redes ou Host)

      Causa uma parada de serviço (temporário)

      Difícil detecção e solução 

Lições aprendidas :

1. Esta reportagem nos faz concluir que cada vez mais estamos dependentes da tecnologia, em especial a Internet, e qualquer indisponibilidade deste serviço trará inúmeros problemas para toda a população.
2. Também podemos afirmar que existem milhares de vulnerabilidades nas tecnologias, em especial ao protocolo TCP-IP, que é o padrão da Internet, e cada vez mais sistemas são construídos sem a preocupação com a segurança.
3. Os ataques podem partir de qualquer ponto do mundo, sendo de difícil detecção e solução. Normalmente não são criados planos de contingência para dar continuidade nas operações interrompidas por estes ataques.
    

Segue abaixo uma pequena lista de sites com diversas iformações sobre Tecnologia :

www.infoexame.com.br

www.olhardigital.com.br

www.timaster.com.br

www.infnet.com.br

www.apinfo.com.br

www.informationweek.com.br

www.itmidia.com.br

www.clubedohadware.com.br

www.laercio.com.br

www.baboo.com.br

Quer uma vaga aqui?, Rosa Sposito, edição de outubro de 2007 - Descubra que tipo de profissional as dez melhores empresas para se trabalhar em TI procuram. [...]

Após 7 dias, cabo rompido deixa Índia sem web, Felipe Zmoginski, do Plantão INFO - SÃO PAULO - A ruptura de três cabos submarinos que ligam a Europa ao Oriente Médio e Ásia deixou a Índia quase sem internet. [...]

Boa Noite, Pessoal...

Estas são minhas primeiras linhas neste novo meio de comunicação. Espero que gostem.