ANAIS. Editor Clovis Torres Fernandes. Realização Instituto Tecnológico de Aeronáutica Divisão de Ciência da Computação

Transcrição

1 Simpósio Sobre Segurança em Informática São José dos Campos SP 24 a 26 de outubro de 2000 ANAIS Editor Clovis Torres Fernandes Realização Instituto Tecnológico de Aeronáutica Divisão de Ciência da Computação e Centro de Computação da Aeronáutica - CCA/SJ i

2 Catalogação na fonte pela Biblioteca Central do ITA/CTA W612a Simpósio Segurança em Informática (2000: São José dos Campos) Anais do simpósio segurança em informática / Clovis Torres Fernandes (editor). São José dos Campos: CTA/ITA/IEC, p. 1. Computação: Segurança congressos. I. Fernandes, Clovis Torres (editor) II. Título CDU 681.3(042.3) Capa Studio Designer Tel.: (0xx12) Editoração Eletrônica Marcos Antonio dos Santos (IEC/ITA) Para cópias adicionais destes anais, favor enviar pedido à secretaria do evento: Divisão de Ciência da Computação/ITA A/C Fabiane A. S. Lazzarini Praça Mal. Do Ar Eduardo Gomes, 50 Vila das Acácias São José dos Campos SP Tel.: Fax: ii

3 APRESENTAÇÃO O SSI Simpósio Segurança em Informática, sob a organização da Divisão de Ciência da Computação do ITA e do Centro de Computação da Aeronáutica - CCA/SJ, tem como objetivo principal divulgar e discutir os diversos aspectos relacionados com Segurança em Informática. Através da sua realização pretende-se reunir anualmente os principais expoentes das áreas acadêmica, militar, técnica e empresarial, colocando-os em contato com os possíveis interessados, a saber, professores, pesquisadores, alunos de pósgraduação, graduação e profissionais da área. O SSI 2000 consta das seguintes atividades: 3 Sessões Técnicas para apresentação dos artigos técnico-científicos selecionados, 12 Palestras Técnicas de convidados de universidades, 12 Palestras Técnicas de convidados de empresas, uma Mesa-Redonda, cujo tema é Segurança em Informática no Comércio Eletrônico, e 3 Microcursos, a saber, MC01 - Crime na Internet: Conhecendo e Observando o Inimigo, MC02 - Criptografia de Chave Pública: Algoritmo RSA e sua Implementação, MC03 - As Dez Maiores Ameaças à Segurança da Internet, MC04 - Segurança do CORBA e MC05 - Política de Segurança Versus Práticas de Segurança na Nova E-ra. Realizou-se uma divulgação em nível nacional da chamada de trabalhos que poderiam estar escritos em português, espanhol ou inglês. O resultado foi a submissão de 34 artigos, vindos de diversas instituições do país. Aproveito para agradecer a todos os que submeteram trabalhos ao SSI O processo de revisão foi às cegas, onde cada trabalho teve no mínimo três avaliações distintas. Foram aceitos 17 artigos, com um índice de aceitação de artigo (número_de_aceitos/número_de_submetidos) de 50%. Dos artigos aceitos, um subcomitê do Comitê de Programa promoveu a escolha do Melhor Artigo SSI Agradeço aos membros do Comitê de Programa e revisores ad-hoc pelo duro trabalho de avaliação e comentários dos trabalhos submetidos. Em especial, agradeço ao Prof. Dr. Adriano Mauro Cansian - UNESP, pela coordenação firme e segura do trabalho de revisão dos artigos submetidos. Agradeço à FAPESP pelo patrocínio oferecido e a todas as empresas que colaboraram de modo a tornar possível a realização do SSI Um especial agradecimento aos palestrantes, aos participantes da mesa-redonda e aos instrutores dos microcursos, pelo pronto atendimento em comparecer e preparar suas apresentações no evento, e a todos os estudantes, professores, pesquisadores e profissionais de empresa que se motivaram a comparecer e enriquecer o evento. Um especial agradecimento à Prefeitura de São José dos Campos que colaborou com o evento. Estendo os agradecimentos ao apoio decisivo da Divisão de Ciência da Computação, Direção Administrativa e Reitoria do ITA, bem como ao Centro de Computação da Aeronáutica - CCA/SJ. Em especial, agradeço e reconheço o valioso esforço e dedicação dos membros da Comissão Organizadora do SSI 2000 e da equipe de suporte e funcionários envolvidos. São José dos Campos, 24 outubro de 2000 Clovis Torres Fernandes Coordenador Geral iii

4 COMITÊ DE PROGRAMA Adriano Mauro Cansian - UNESP [Coordenador] Alessandro Anzaloni ITA/IEE Bernardo Gonçalves Riso UFSC Carlos Becker Westphall UFSC Celso Massaki Hirata ITA/IEC Clovis Torres Fernandes ITA/IEC Edgar Toshiro Yano ITA/IEC Edson dos Santos Moreira USP/ICMC Jamil Salem Barbar UFU João Batista Camargo Junior USP João Bosco Mangueira Sobral UFSC Luiz A. Vieira Dias UNIVAP Luiz Eduardo Buzato UNICAMP Nei Yoshihiro Soma ITA/IEC Paulo Lício de Geus UNICAMP Paulo Roberto Guardieiro UFU Pedro Vazquez UNICAMP Pedro Frosi Rosa UFU Ricardo Felipe Custodio UFSC Selma Shin Shimizu Melnikoff POLI/USP Sérgio Takeo Kofuji USP Raul Fernando Weber II/UFRGS Taisy Silva Webe II/UFRG COMISSÃO ORGANIZADORA Clovis Torres Fernandes - ITA/IEC [Coordenador Geral] Fabiane Lazzarini ITA/IEC Iara Braz Neves ITA/IEC Jaqueline de Carvalho ITA/IEC Jony Santellano ITA/IEC Júlia Nonoyama ITA/IEC Marcos Antonio dos Santos ITA/IEC Maria Conceição Osório de Almeida CCA-SJ Mônica Gonçalves de Mendonça ITA/IEC Nei Yoshihiro Soma ITA/IEC Rogério Gonçalves Paulo CCA-SJ iv

5 SUMÁRIO ADMINISTRATION TECHNIQUES FOR IMPLEMENTING SECURITY ON LARGE WINDOWS NT NETWORKS..01 Alessandro Augusto, Célio Guimarães e Paulo Lício de Geus - UNICAMP A HUFFMAN-BASED TEXT ENCRYPTION ALGORITHM..11 Ruy Luiz Milidiú, Cláudio Gomes de Mello e José Rodrigues Fernandes - PUC/Rio ALGORITMOS INTELIGENTES PARA BUSCA DE PADRÕES NA DETECÇÃO DE INTRUSÃO...19 Daniel Rodrigus Ambrosio, Mauro César Bernardes, Stenio Firmino Pereira Filho e Edson dos Santos Moreira - ICMC - USP/São Carlos ANÁLISE DE SEGURANÇA DO ACESSO REMOTO VPN...29 Emilio Tissato Nakamura e Paulo Lício de Geus - UNICAMP AVALIAÇÃO DA SEGURANÇA DA URNA ELETRÔNICA BRASILEIRA...39 Amilcar Brunazo Filho - TD Tecnologia Digital Ltda AVALIAÇÃO DE AÇÕES COOPERATIVAS NA ANÁLISE DA SEGURANÇA DO SISTEMA DE TELEDESTRUIÇÃO DE UM VEÍCULO DE SONDAGEM Carlos Lahoz, Martha Abdala - IAE/CTA Rogério de Lemos University of Kent/UK Carlos Moura - IAE/CTA ESPECIFICAÇÃO FORMAL PARA O PROJETO E A ANÁLISE DE PROTOCOLOS CRIPTOGRÁFICOS...59 Clóvis Freire Júnior - CCA/Brasília Luiz Antônio da Frota Mattos - ICE/UnB FALSIFICAÇÃO DE ENDEREÇOS IP: UM PERIGO QUE RONDA OS SERVIÇOS DE RESOLUÇÃO DE NOMES NA INTERNET...69 Cláudio de Castro Monteiro e Vagner José Sacramento - ULBRA/Palmas FILTRAGEM COM ESTADOS DE SERVIÇOS BASEADOS EM RPC NO KERNEL DO LINUX...79 Marcelo Barbosa Lima e Paulo Lício de Geus - UNICAMP PERSPECTIVAS PARA O ESQUEMA DE AUTENTICAÇÃO DO SISTEMA OPERACIONAL UNIX...89 José Roberto B. Gimenez - CEPPE/UNG - Univ. Guarulhos PROGRAMAS SEGUROS: VULNERABILIDADES COMUNS E CUIDADOS NO DESENVOLVIMENTO...95 Felipe Massia Pereira e Paulo Lício de Geus - UNICAMP v

6 SELECTION OF CHANNELS FROM A TREE-STRUCTURED FILTER BANK FOR SPEAKER IDENTIFICATION André Gustavo Adami - Oregon Graduate Institute/USA TÉCNICAS DE SCAN EM REDES USANDO OS RECURSOS DA PILHA TCP/IP Antônio Pires de Castro Júnior e Nelson Luis S. Fonseca - UNICAMP TEIAS DE CONFIANÇA Paulo André Sant'Anna Perez e Paulo Lício de Geus - UNICAMP UM ESTUDO SOBRE ASPECTOS DA SEGURANÇA EM BANCO DE DADOS Dirson Santos de Campos e Luiz Antônio da Frota Mattos - ICE/UnB UM MECANISMO PARA DISTRIBUIÇÃO SEGURA DE VÍDEO MPEG Cíntia Borges Margie, Graça Bressan e Wilson Vicente Ruggiero - POLI/USP UM MÉTODO PRÁTICO PARA AVALIAÇÃO INICIAL DE VULNERABILIDADES DE SEGURANÇA EM SISTEMAS DE BANCO DE DADOS CORPORATIVOS Clovis Torres Fernandes, Daniel dos Santos Nascimento e Álvaro Augusto Neto - ITA/IEC Alberto Bastos - Modulo Security Solutions S/A vi

7 ADMINISTRATION TECHNIQUES FOR IMPLEMENTING SECURITY ON LARGE WINDOWS NT NETWORKS Alessandro Augusto Instituto de Computação IC - UNICAMP Campinas - SP alessandro.augusto@ic.unicamp.br Célio Guimarães Instituto de Computação IC - UNICAMP Campinas - SP celio@ic.unicamp.br Paulo Lício de Geus Instituto de Computação IC - UNICAMP Campinas - SP paulo@ic.unicamp.br ABSTRACT The process to secure a Windows NT computer can be easy if the administrator knows which configurations and security settings he needs to do. But, even when the administrators knows the changes that needs to be done on a single NT computer, the process to apply the same configuration in an environment with hundreds of NT-based computers can be really frustrating. Most solutions to this problem require some expensive tool such as Systems Management Server (SMS). But there are many companies and institutions that cannot purchase this kind of tool or the SMS's licenses. In this case, the solutions presented until now don t solve the problem of administering NT and applying security to a NT network. This paper describes some highly recommended security procedures and propose three solutions to solve the difficulty to apply security or to upgrade NT-based computer networks without any extra tool. 1 INTRODUCTION During the last years it is unquestionable the advantages that institutions had with the increase in the use of computers, with the interconnection of these computers in networks and with the sharing of resources. Even so, it is also unquestionable that the institutions need to be prepared before migrating to this new "digital territory". Thus, there have been a lot of discussion on system administration and security, especially in UNIX operating systems, but little aspect deals with Windows NT operating system. Among the operating systems with wide prominence and use in several environments, Windows NT gets the attention with its growing use and its user-friendly interface. In spite of easiness to use the system, comparing Windows NT with other UNIX systems, NT can be considered "lacking" in the subject of network administration, especially when the topic is applying security on a NT network. In institutions that have a considerable group of interconnected computers through a network based on Windows NT, it always existed difficulties when the administrators need to do apply some security configurations on each network computer. These difficulties generate high monetary costs to maintain a group of system administrators in service. Windows NT s environments have a reputation to be a system requiring hands-on administration, that is, it needs a manual by-hand work [5]. It is necessary the administrator's physical presence in each machine every time it needs to do some modification or configuration. It can be concluded that the associated costs would increase as the amount of networked computers gets bigger. Remote software installation and configuration is another problem in this kind of environment. A large portion of configuring security on NT is modifying some Registry values. As the administrator begins to look at configuring values keys on the Registry and to read the papers about NT security, he starts to think that it is almost impossible to administer NT-based computer networks without some expensive administrative tool such as SMS (Systems Management Server) and without a large number of system administrators available [7]. For a practical example, the usual software installation methods on NT requires the administrator to sit in front of an individual machine, answer some questions interactively, wait some minutes for the software to load and maybe reboot the machine. This approach doesn t scale to hundreds of NT machines. With this example, the administrator can't imagine the problem that he will face when he starts to configure security. He knows what he needs to modify on the Registry, but how does he do all this modifications without sitting in front of each computer? The goal of this work is to define a good level of security for NT computers and also, to create techniques and propose solutions, where the system administrator is able to configure the security and have it automatically distribute to each machine of a given type. But there are some restrictions about these techniques, one of the restrictions is that the administrators cannot copy the whole Registry and paste it on another computer. Fortunately, there are ways to by-pass most of these problems. As a result, the solutions presented here solve this problem of applying security on NT

8 network and also, techniques to facilitate any software installation, software upgrading and also any other kind of communication between the workstations and the server without expensive tools such as SMS. For another example, if the administrator needs to know the exact time that each network computer was turned on, he can create a batch script that logs the time and use this script with one of the proposed solutions to send these logs to the administrator. The techniques presented in this paper can be considered a good solution for institutions that don t want to spend money with this kind of problem. With these techniques, system administrators can deploy up to 100 PC s per hour depending on which technique he chooses and also, it depends on the size of the package that is being installed. These techniques will increase a lot the deploy ratio and turn much more easily the administration process. This paper is structured as follows: after a brief introduction on section 1, it describes the Windows NT operating system on section 2. After that, it describes the Registry and the problem on how to administer the NT network, respectively on sections 3 and 4. Section 5 presents some security recommendations. Section 6 proposes and explains the solutions to administer the NT networks. Section 7 shows a practical example with its solution of how can the administrator applies some security configurations to a NT environment. The paper finishes with the conclusion and the references used by it. 2 WINDOWS NT Since its initial release in 1993, the operating system Windows NT 1 appeared as an outstanding operating system with multiple purposes. Projected to integrate a client-server network, Windows NT is divided in two products: Windows NT Workstation and Windows NT Server [8]. Combining an application server with a file system and a print system, it was created to be easy to use and to manage. Besides that, it is much more reliable and stable than the previous versions of the systems Windows 9.x and Windows 3.x. The client is known as Windows NT Workstation. The default system already brings applications to execute in the network such as ftp clients, electronic mail, telnet, etc. In the same way, NT Server default system brings some different applications, for example a web server, IIS 2. In Windows NT, all configurations are stored centrally in only one database denominated 1 New Technology 2 Internet Information Server Registry, which is one of the most important topics about this system, especially when talking about security [6]. 3 REGISTRY Registry is a central and organized database that contains all the information about hardware and software configuration. In previous versions of Windows, configuration files with extension.ini and.sys executed the functions exercised by the current Registry. The problem of these configuration files was the restriction with relationship to its maximum size to be of 64 Kb. Beyond that problem, any user could easily edit some configuration file and could cause damage on the system [6]. Inside the Registry is stored all information about user s account, user s groups, and information about all hardware and software installed in the computer. To modify the Registry values, it is necessary to have writing permission, because each of its items has access permission. Every change in the Registry affects the configuration of the machine directly. Developed with a hierarchical structure, the Registry can be compared with a country, which it is divided in states, which is divided in cities, in neighborhoods and so on. 4 THE PROBLEM One of the hardest tasks that system administrators have with NT environment is to configure the security of its network and to install or upgrade software. Some people don t agree with this, they say it s much easier to install an application under Windows NT than under UNIX. On NT, the administrator just need to put the CD or the floppy in the drive, maybe click setup (if autorun is not configured automatically), answer some Installshield questions and wait for it goes to work [5]. These people would expect that UNIX software management would be much harder, since there is no installshield there. The argument that NT is easier to administer due to its graphic interface (GUI-based) it is questionable. Besides being questionable because other operating systems also possess graphic interface, it is also doubtful the argument that the graphic interface is simpler than command line interface (CLI-based). Generally, GUI-based tools are easier to install but harder to automate and extend [5]. However, the fact that software installation under NT is easier than UNIX can be considered

9 true for an isolated NT machine. Managing a large environment is entirely different. Command-line tools are easier for any system administrator to use when managing a large environment. The difficulty found in Windows NT administration occurs when the environment, which is the amount of networked workstations, is larger than 1. The difficulty and the time spend in the administration is directly proportional to the amount of computers. The larger is the amount of computers in the environment, more complex and delayed will be its administration. Another item that hinders the administration of Windows NT networks, is the fact of having a heterogeneous network, that is, when there are computers with different hardware profiles. In spite of the same security configuration in two different machines add or modify the same keys and fields in the Registry, it is impossible to copy the Registry of the first computer and paste into another NT computer where it was not configured yet. The impossibility is because of the remaining keys, which contains hardware and software configurations specific to each computer. The two main problems here are: (1) what changes and security settings should the administrator do to make a NT computer secure? (2) How to apply these settings to the whole NT network computers without having to sit in front of each machine? How to administer a Windows NT network and its security in some easy way, also with a cheap solution and fast results, considering the amount of computers present in the network is larger than 1? How to perform the needed modifications in all the network machines with a small effort and in the least possible time? How to automate the tasks of software installation or upgrading to the remaining network machines? The solutions for these questions are describe in the next sections. 5 SECURITY SETTINGS RECOMMENDED Windows NT provides a rich set of security features, however, the default configuration is highly relaxed. This is because the operating system is sold as a shrink-wrapped product with an assumption that an average customer may not want to worry about a highly restrained but secure system on their desktop. This assumption has changed over the years as Windows NT gains popularity largely because of its security features [12]. This section describes the most important security recommendation settings. It will follow some recommendations of a Windows NT C2 configuration 3 [13]. A particular installation s requirements can differ significantly from another. Therefore, it is necessary to evaluate the environment and requirements before implementing a security configuration. Windows NT allows the administrator to establish a full range of security levels, from no security at all to the C2 level of security. These levels are arbitrary, and the administrator will probably want to create his own level by blending characteristics of the levels presented in this section. One reason to not have maximum security level at all times is that the limits the administrator sets on access to computer resources make it a little harder for people to work with the protected resources. And if the security is too tight, users will try to circumvent security in order to get work done [12]. The first step in establishing security is to make an accurate assessment of the needs. Then choose the elements of security that the administrator wants, and implement them. The following subsections describe some recommendations to apply security configuration on Windows NT. 5.1 Operating System and Service Pack Installation The first step to start armoring the NT system is the operating system (OS) installation. Install it on a NTFS file system. With NTFS, the administrator can assign a variety of protections to files and directories, specifying which groups or individual accounts can access these resources in which ways. During the OS installation, select only the services that will run and the protocols that will be needed. The fewer services running, the fewer exploits or security issues the system will have [12]. Following the installation, install the latest service pack (current service pack 6a). Staying current with the latest exploits is critical for a secure system. Once the administrator finishes the OS and the service pack installation, he can start to configure the system. All unnecessary devices and services 3 The Department of Defense Trusted Computer System Evaluation Criteria (DoD-TCSEC), better known as the Orange Book, provides standardized methods for determining the security level of a particular system [2]. The Orange Book s security levels are grouped by divisions and classes. Division C, also known as Discretionary Protection, contains two classifications, C1 and C2, with C2 providing greater security than C1 by enforcing more granular access of control policies, auditing all security related events, and better resource isolation. For a complete description of how the Windows NT satisfies each requirement of the Criteria, see [11].

10 must be disabled. The services that should be enabled depend on the user needs. 5.2 OS/2 and Posix Subsystems OS/2 and Posix are subsystems designed to run with other system but not specifically with Windows NT and that may not be able to take full advantage of all Windows NT features (such as memory management). Most of the administrators don t need these subsystems, so it can be disabled. To remove OS/2 and POSIX subsystems, the administrator needs to delete the \winnt\system32\os2 directory and make the following Registry configurations [13]: Hive Key Action Hive Table 1- removing Posix and OS/2 subsystems. Key Value Name Action Hive Key Value Name Action Hive Key Action 5.3 ShutDown Button HKEY_LOCAL_MACHINE\ SOFTWARE \Microsoft\OS/2 Subsystem for NT Delete all sub keys HKEY_LOCAL_MACHINE\ SYSTEM \CurrentControlSet\Control\Session Manager\Environment Os2LibPath Delete HKEY_LOCAL_MACHINE\ SYSTEM \CurrentControlSet\Control\Session Manager\SubSystems Optional Delete values HKEY_LOCAL_MACHINE\ SYSTEM \CurrentControlSet\Control\Session Manager\SubSystems Delete entries for Posix and OS/2 Normally, any user can shut down a computer running NT without logging on by choosing Shutdown in the Logon dialog box. This is appropriate where users can access the computer s operational switches; otherwise, they might tend to turn off the computer s power or reset it without properly shutting down. However, the administrator can remove this feature requiring users to log on before shutting down the computer [12]. The configuration to remove the shutdown button from logon dialog box is on table 2. Hive Key Value Name Table 2- remove shutdown button from dialog box. HKEY_LOCAL_MACHINE\ SOFTWARE \Microsoft\Windows NT\ CurrentVersion\Winlogon ShutdownWithoutLogon Action Set the value Files and Directories Among the files and directories to be protected are those that make up the operating system software itself. The standard set of permissions on file system and directories provide a reasonable degree of security without interfering with the computer s usability. For a high-level security installation, however, the administrator might want to additionally set directory permissions to all subdirectories and existing files. To protect the files and directories, the administrator needs to use the ACL editor in Windows NT Explorer to change access on the system drive (by default "C:\") to grant full control to Administrators and SYSTEM, and grant read permission to Everyone. In [12] and [13] it gives the following recommendations: Directory C:\ \WINNT \WINNT\ REPAIR \TEMP \WINNT\ Profiles\ <user> \WINNT\ Profiles\ administrator Table 3 - protecting files and directories. 5.5 Protecting the Registry Permissions Administrators: Full Control SYSTEM: Full Control Everyone: Read Administrators: Full Control SYSTEM: Full Control Everyone: Read CREATOR OWNER: Full Control Permit only Administrators: Full Control CREATOR OWNER: Full Control User: Full Control Remove Everyone In addition to the considerations for standard security, the administrator of a high-security installation might want to set protections on certain keys in the registry. By default, protections are set on the various components of the registry that allow work to be done while providing standardlevel security. For high-level security, the administrator can assign rights to specific registry keys, but this should be done with caution, because programs

11 that the users require to do their jobs often need to access certain keys on the users behalf. Normally, the keys in the registry are changed indirectly, through the administrative tools such as the control panel. The registry can also be altered directly with any registry editor. Open regedt32.exe and grant full control to Administrators and SYSTEM and read access to Everyone for the followings Registry subkeys [13]: - HKEY_LOCAL_MACHINE\Software : locks the system in terms of who can install software. - HKEY_LOCAL_MACHINE\Hardware - HKEY_LOCAL_MACHINE\System - HKEY_USERS\.Default 5.6 Restricting Remote Access to the Registry The default permissions do not restrict which users can have remote access to the registry. Only administrators should have remote access to the registry. To restrict network access to it, select the hive HKEY_LOCAL_MACHINE\System, the key CurrentControlSet\Control\SecurePipeServers and the value name winreg and set the Administrators permission to full control, and make sure no other users or groups are listed [1]. Table 4 shows this configuration. Table 4 - restricting remote access to the registry. To allow only the administrator to control which users can access a computer from its network interface and what information is shared over the network interface set read permission for Everyone and all untrusted users on the value of table 6 [13]. Hive Key Value Name Action 5.9 Cache Logon Table 6- shares. HKEY_LOCAL_MACHINE\ SYSTEM \CurrentControlSet\Services\ LanmanServer Share Everyone and all untrusted users: Read The default configuration of Windows NT caches the last logon credentials for a user who logged on interactively to a system [1]. Even though the credential cache is well protected, administrators may want to disable the cache. This results in a somewhat longer logon time, but prevents malicious users from tapping logon information from short-term memory. Table 7 shows how to disable caching. Table 7 - disabling cache logon. Hive Key Value Name Action HKEY_LOCAL_MACHINE\ SYSTEM \CurrentControlSet\Control\ SecurePipeServer Winreg Administrators: Full Control Hive Key Value Name HKEY_LOCAL_MACHINE\ SOFTWARE \Microsoft\Windows NT\ CurrentVersion\Winlogon CachedLogonCount Action Set the value Trojan Horses Restrict untrusted users ability to plant Trojan horse programs on the system. Trojan horses can take advantage of the Run utility if is unguarded [16]. There are some trojan horses that are written to execute during an Uninstall operation. To restrict the ability of users to plant trojan horses programs, set the values of table 5. Table 5 - protecting from trojan horses Hiding the Last User Name By default, Windows NT places the user name of the last user to log on the computer in the user name text box of the logon dialog box. This makes it more convenient for the most frequent user to log on. To help keep user names secret, the administrator can prevent Windows NT from displaying the user name from the last log on [15]. To prevent it, the administrator needs to set the values of table 8. Hive Key Value Name Action 5.8 Share HKEY_LOCAL_MACHINE\ SOFTWARE \Microsoft\Windows\CurrentVersion Run, RunOnce, Uninstall, AEDebug Everyone and all untrusted users: Read Hive Key Value Name Table 8 - hiding the last user name. HKEY_LOCAL_MACHINE\ SOFTWARE \Microsoft\Windows NT\ CurrentVersion\Winlogon DontDisplayLastUserName

12 Action Set the value Fpnwclnt.dll There is a security issue that may occur due to the way Windows NT handles the file \winnt\system32\fpnwclnt.dll. This file is a dynamic link library that let files and prints services for a netware and directory service manager for netware perform password synchronization with Novell netware servers. If there is no Novell netware servers on the NT network, this file should be removed [14] User Rights and More Security Configurations We described above, a few recommendations to set a Windows NT at C2 security level. There is a lot more security configurations that can be changed. There are several user rights that the administrators should be aware of and possibly audit. This permissions can be simple changed using the Microsoft Manager Console (MMC). MMC integrates the set of administrative components. Together, these services provide a model of system administration and coherent delegation that reduces the time of administration. MMC hosts the programs, called snap-ins, that administrators use to manage their servers. MMC allows administrators to configure account police, local polices, event log, restricted groups, system services, registry and file system. The security template snap-in is a stand-alone Microsoft Management Console (MMC) snap-in that allows the creation of a text-based template file that contains security settings for all security areas. 6 PROPOSED ADMINISTRATIVES SOLUTIONS The main problem present before was accomplished: the changes and security settings that the administrator should do to have a NT computer more secure than the default installation. Now the problem is how to apply these settings to the whole NT networked computers without having to sit in front of each machine and configuring one by one. To solve this problem, this paper proposes 3 techniques that will help the administrator. In order to decide on which technique would be easier to use, the system administrator needs to evaluate and consider as many options as possible. The procedure for any of these techniques has basically two steps: 1. create a package that will be installed or applied 2. choose the technique to apply the package created For a better understanding, the term "change" is standardized in this paper as being the task or the modifications that the administrator wants to do in his network computers. This change can be for example a simple modification in the standard wallpaper, or a new software installation, or to restrict the permission to read the Registry or any other alteration. Also the term "model machine" defines the computer where the change was accomplished for the first time. This model machine can be any of the present computers in the network and it will be considered a reference during the whole process. The package will be created in this model machine. "Target system" or "target machine" are the terms used to define the network computers where the changes accomplished in the model machine will be applied, that means, the computers where the package created will be installed. Next section will detail the process to create the package. 6.1 Packaging The heart of a successful automated installation is the first step, which is called packaging. As the name says, packaging is the process to create a file, which contains all the changes that the administrator wants to apply in the network [4]. The packaging process is similar to the clone process. With the impossibility of copying the whole model machine Registry to the target machines, the goal of packaging is to create a system exactly equal, that is, to clone the model machine, including in the clone system all the configurations and security policy of the model machine, all them with the installed software and configured, besides considering each system as being a different machine in the network. The initial idea of the clone process is to discover what changed in the NT system of the model machine after any change and to create a package that just contains the modifications that happened after the administrator execute its change. It will be detailed better in the section After creating the package, it needs to be applied in the target machines with some of the techniques that will be explained below. When someone change any property in NT or when someone installs a new software or hardware, new files and new keys are added and modified in the Registry of that system. The clone process seeks to discover which were those modifications. After discovering the modifications that were done

13 in the model machine, it creates the package that will be applied in the target machines. To discover the alterations happened in the model machine, it is necessary some application that does a "sweeping" of the file system and the Registry, to discover what changed in the system after the administrator s modification, and as result, create the package. In this paper the application used to sweep the system and to generate the package is called sysdiff.exe Sysdiff.exe Sysdiff.exe 4 is a practical example of a tool that helps to clone NT systems. With this tool it is possible to discover all the new files that were added or modified in the file system and all the keys and values that were inserted or modified in the Registry. The application Sysdiff.exe doesn t install the operating system, it just discovers the modifications happened in the model machine, it generates a package contends those changes and it creates an installation for that package. To run correctly, there are some requirements that need to be done for sysdiff.exe: - It is necessary to define a "model machine", which is a reference computer, where the changes will be accomplished firstly. This model machine should run the same operating system of the target machines, where the package will be applied. - It is also necessary to define a distribution point. A shared folder (share), where should be stored the application Sysdiff.exe and the package created. It is necessary that the target machines have access to this share. The clone process should be fast enough, otherwise it can be unviable. Depending on the number of networked workstations, the clone process can delay more than the accomplishment of the same task in all the target machines Options of the application Sysdiff.exe Sysdiff.exe possesses the following parameters: Option /Snap Table 9 - Options of sysdiff.exe. Command Line Sysdiff /snap snapshot_file With this option, the application takes a snapshot of the current system configuration. The parameter snapshot_file is already the name of the file in which the photo of the current configurations will be recorded. 4 Sysdiff.exe is a Microsoft tool, distributed on the Resource Kit CD-ROM. It can also be downloaded from the Web. Option /Diff Command Line Sysdiff /diff snapshot_file package This option generates the distribution package. That package is a file containing the differences found among the first snapshot of the system, with the configuration of the system registered immediately after the changes are accomplished. The new parameter included in this option is the name of the package that will be created. This is the same package that will be applied to the target machines. Option /Apply Command Line Sysdiff /apply package This option is used to apply the package generated by the option /diff in the target system, that means, in the machine that is executing the application Sysdiff.exe. Option /Dump Command Line Sysdiff /dump package dump_file This option allows to create a report containing the modifications accomplished by a certain package. The parameter dump_file is the name of the file that will contain the changes applied by the package Creating the package - step by step After defining the necessary requirements for Sysdiff.exe, described in the section 6.1.1, the steps to create the package are: 1. in the model machine, install the application Sysdiff.exe. 2. execute the application Sysdiff.exe with the option /snap to take a snapshot of the model machine before any change. This photo will contain all the configuration of the current NT system. This step should be done before the administrator configure any security setting. 3. Soon after, the administrator should accomplish the change wanted in the machine, e.g. accomplishes the security recommendations presented on section After accomplishing the configurations, execute the application Sysdiff.exe again with the option /diff. The objective of this step is to find the differences happened in the model machine and to create an installation package for the target machines. To create the package, Sysdiff.exe receives as entrance the snapshot took before the changes (step 2) and it supplies as result the generated package, which contains all the changes that were done on that machine by the administrator. 5. The last step is to leave the application Sysdiff.exe and the generated package in the share distribution folder (share).

14 With that, the process of creating the package is concluded. This stage is necessary to use with any of the techniques that this paper presents. Section 6.2 presents the first one, which uses a login account. The other one, uses NT Services and will be present in section 6.3. And the last technique, presented in section 6.4 uses the schedule service. 6.2 Solution 1: Using a special account This technique is considered the easiest for networks where the physical location of each computer is close to each other. The goal of this technique is simple: it discovers the entrances that were added in the Registry of the model machine, creates a package and apply it on the target machines using a batch script. To discover the modifications done in the model machine, it uses the process described in the section to create the package. This technique consists of: 1. Create an installation package for the changes that the administrator wants to do and leave it on a share drive (section 6.1.3). 2. Create a batch script (.bat), that connects the current machine to the above share and apply that package to this computer, the computer that is executing the batch (described on table 10). 3. Create a new user account login with administrator s rights and configure this account to execute the script from the last step (step 2) when the system administrator logon in. 4. On each target machine, the administrator should logon in using the user account created on step 3. The goal of the batch script (from step 2) is to apply the package on every network machine. Suppose that the administrator already created the package, leave it on a share drive and created the new user account login. After this, the administrator needs to go to each computer, and logon in this new account. Then, the account will execute the script, which will: (1) connect the current computer to the share drive (2) execute the sysdiff.exe application with the option to apply the package (sysdiff /apply) (3) logout the account With these steps, any modification on the first machine will create a new package. So the process to install or customize anything on the network can be really easy. The system administrator just needs to go to each network computer and logon in this new account. 6.3 Solution 2: NT services This technique uses the concept of NT services. It came up for the system administrator that cannot be present on each network computer every time he needs to install a new package or do any other modification. It is a good solution for companies and institutions that have a large environment, where the network computers stay far away from each other. The solution is similar to the first one, but in this technique, the system administrator will need to go to each computer only one time, to configure the service, and not all the time that he wants to apply a new package. Installing a new service, NT is capable to selfupgrade when the machine is booted, without any user interaction. The only requirement in this technique is to turn on the machine, so the system starts the service automatically and upgrades itself [12]. Among the benefits offered with the installation of the new service, there are: - Possibility to automate tasks without needing administrator's interaction - When applications are executed as being services, the applications are not concluded in the moment that an user makes the logout of the machine. The service will execute even if the user logout the system. - If the application that is executed as service is a client-server application, this application can respond commands all the time, even when there is no user logged in the machine. The second solution proposed by this paper consists of the following steps: 1. Create an installation package for these changes and leave it on a share drive (section 6.1.3). 2. Create a new batch file (.bat) different from the first technique. The batch file here should connect the current machine to the share drive where the package is, and compare if it needs to apply that package or not. Maybe that package has already been applied to the current computer. 3. Create a new NT service on each network computer and configure the service to be the batch file from step 2 and to startup automatically when the computer turns on [10]. In this technique, the administrator needs to create a batch file which will compare the packages from the share with the packages already applied on the current computer that is running the service. With these steps, the system administrator needs to configure each computer only the first time, when he creates the new service. This service will run automatically when the computer turns on. So, every morning, when any user starts his work, he turns the computer on, and doesn t even know that the system is automatically self-upgrading.

15 6.4 Solution 3: Schedule Service The third technique described in this paper is very similar to the second solution. It was deployed for the system administrator that can t be present on each computer during the upgrading. This solution requires that the system administrator goes to each network computer one time and configure the NT s schedule service to startup automatically. With this configuration, this service will always be startup when the computer turns on. The schedule service allows the system administrator to schedule, remotely or locally, any task at some specific time. Also known as the AT command, the schedule service is used to schedule tasks to run automatically at a present time. The third proposed solution consists of: 1. Configure each network computer to start the schedule service automatically. This step is done just one time. The next time that the administrator applies different packages, this step can be ignored. 2. Create an installation package for the changes and leave the package on a share drive (section 6.1.3). 3. Create a batch file similar to the first technique (special account) which will connect the current computer to the share drive and apply the package on the current computer (table 10 shows the script). 4. Schedule the batch file created above to run at a specific time. There are options to schedule it to run several times, every day, every week, so it can be handled by the system administrator choices. In [5], the authors say they were unsure with the schedule service because of security aspects. With the right configuration, schedule service is secure because only the administrator can schedule tasks to execute. 2. Before he makes any change, he executes sysdiff.exe with the option /snap to take the first snapshot of the machine. 3. After take the snapshot, the administrator starts to configure the security and the installation of the software. The paper won't get in details about what security setting the administrators is changing, but he can follow the recommendations described on section 5 of this paper and apply it here. The administrator installs the software in this step too. 4. When its done, the administrator executes the sysdiff.exe with the option /diff to create the package. 5. Now he needs to create a share drive (folder) and put the package created and the sysdiff.exe there. 6. The administrator needs to choose one of the techniques. In this case, lets suppose that the administrator choosed the first technique, the special account technique (section 6.2). The reason is because this solution is easier for network where the computers are close to each other s. 7. The next step is to create the batch script that connects the current computer to the share drive, and execute the sysdiff.exe with the option /apply (table 10). 8. After that, the administrator needs to create a new user account, with administrator's rights that will execute the script created on the last step. 9. To finish the process and to apply the package, the administrator needs to go to each workstation and logon in the special account that he created on step 8. An example of a batch script is presented on table 10. Table 10 - Batch Script. 7 PRACTICAL EXAMPLE For a practical example, suppose a NT-based network, with one server and 10 workstations. Also, suppose that the workstations are located at the same room and the server is in a different place, where the users don't have physical access. The administrator wants to configure the security of each workstation and also wants to install a new software. The steps to automate this tasks are: 1. The administrator selects one of the workstations and installs the sysdiff.exe application.

16 @REM Script to automate and install Packages are created with the Applying the connect the current computer to the use g: Change the Apply the /apply Return to Disconnect from the share use g: off 8 CONCLUSIONS Automating NT tasks without administrative tools such as SMS can be by-passed using some techniques. The difficulty found to deploy these solutions was that all the previously published papers, explain how it could be done assuming that SMS was installed. After learning about NT application issues, Registry, and trying out various options, we suggest some security settings and propose 3 solutions to apply this settings on every kind of NT-based environment, either when the amount of computers is small and the computers are close to each other, or in large environments and large networks where there is one system administrator that can t be in front of each network computer. 9 REFERENCES [1] CERT. Windows NT Configuration Guidelines. April, Url: [2] DoD Departament of Defanse Standard. Department of Defanse Trusted Computer System Evaluation Criteria. December, Url: [3] EVARD, Rémy & LESLIE, Robert. Soft: A Software Environment Abstraction Mechanism. In: USENIX LISA VIII Conference Proceedings, [4] FULMER, Robert & LEVINE, Alex. AutoInstall for NT: Complete NT Installation Over the Network. In: Proceedings of the Large Installation System Administration of Windows NT Conference, USENIX LISA, Seattle, Washington, USA, [5] GOMBERG, Michail & EVARD, Rémy & STACEY, Craig. A Comparison of Large- Scale Software Installation Methods on NT and UNIX. In: Proceedings of the Large Installation System Administration of Windows NT Conference, USENIX LISA, Seattle, Washington, USA, [6] KIRCH, John. Troubleshooting and Configuring the Windows 95/NT Registry. Macmillan Computer Publishing, [7] LUERKENS, Cameron D. & COLE, John & LEGG, Danielle. Software Distribution to PC Clients in an Enterprise Network. In: Proceedings of the Large Installation System Administration of Windows NT Conference, USENIX LISA, Seattle, Washington, USA, [8] Microsoft Windows NT Workstation 4.0 Resource Kit. Microsoft Corporation, Microsoft Press, [9] SPITZNER, Lance. Armoring NT. Url: [10] Srvany.exe. Running applications as services. Microsoft Press. [11] TCSEC Final Evaluation Reports. TTAP-CSC-FER-99/001. Microsoft Corporation, Windows NT Workstation and Windows NT Server, Version 4.0. Url: /TTAP-CSC-FER pdf [12] Windows NT Server - Server Operating System. Securing Windows NT Installation. Microsoft Corporation, Microsoft Press White Paper. [13] Windows NT C2 Configuration Checklist. Url: [14] Windows Knowledge Base. Article ID: Q Security Issues that may occur due to the way Windows NT handles FPNWCLNT.DLL [15] Windows Knowledge Base. Article ID: Hiding the last logged on username in the logon dialog. [16] Windows Knowledge Base. Article ID: Resetting Default Access Controls on Selected Registry Keys [17] Windows Knowledge Base. Article ID: How to protect Windows NT Desktops in public areas

17 A HUFFMAN-BASED TEXT ENCRYPTION ALGORITHM Ruy Luiz Milidiú Departamento de Informática Pontifícia Universidade Católica (PUC-Rio) Claudio Gomes de Mello Departamento de Engenharia de Sistemas (DE/9) Instituto Militar de Engenharia (IME) José Rodrigues Fernandes Faculdade de Informática Universidade Católica de Petrópolis (UCP) Abstract. Huffman coding achieves compression by assigning shorter codes to the most used symbols and longer codes to the rare ones. This paper describes two cipher procedures added to Huffman coding to provide encryption besides its compression feature. We use multiple substitution to disguise symbols with fake codes and a stream cipher to encrypt these codes. The proposed scheme is simple and fast. It generates encrypted documents with enough confusion and diffusion. 1 Introduction In order to maintain a secure communication between remote points it is necessary to guarantee the integrity and confidentiality of both incoming and outcoming information. The communication cost is related to the volume of exchanged information. Hence, information compression is essential. Besides that, one must also guarantee that sniffers can not be able to decipher in transit messages. To protect data against statistical analysis, Shannon [Shan49] suggested that the language redundancy should be reduced before encryption. We use the well-known Huffman codes to achieve this. Huffman codes have optimal average number of bits per character, among prefix-free codes. Besides that, Rivest et al [Rive96] tried to cryptanalyse a file that has been Huffman coded (and not encrypted) and find that it was surprisingly difficult. First, let us introduce some concepts. Let P be the set of possible plaintexts, and S={s 1, s 2,, s n } the plaintext alphabet of X, X P such that X=x 1 x 2 where x i S. Let n be the number of symbols in S. If p i is the probability of s i to appear in the plaintext X we have the Entropy of X, defined by H(X) = - SUM i (p i ). log p i, as the average number of bits to represent each symbol s i S. Moreover, we say that H(X) leads to Zero Redundancy, that is, has the exact number of necessary bits to represent S. The encoding produced by Huffman s algorithm is prefix-free, and satisfies [Stin95]: H(X) l(huffman) < H(X)+1, where l is the weighted average length. Here, we propose two cryptosystems based on Huffman coding. Sometimes an alphabet provides multiple substitutions for a letter. Thus, a symbol x i of a plaintext X instead of always being replaced by a codeword c, will be replaced by any codeword of a set (c 1, c 2,...). These alternates used in the multiple substitution are called homophones [Simm91]. Günther et al [Gunt88] introduced a coding technique using homophones such that their encoding tables generates a stream of symbols which all have the same frequency. Then, Massey et al [Mass89] proposed a scheme, based on Günter s homophonic substitution, to generate homophones by decomposing the probability of each symbol in a sum of negative powers of 2, generating new symbols. Our first cipher is a multiple substitution procedure. We substitute each Huffman coded symbol by a string of fake codes followed by the symbol itself. It is a

18 steganographic technique, that is, to disguise the symbol by mixing it with other fake ones. (right child) shown in figure 1 is created for these symbols. Each symbol has an identification bit (ID bit) that marks it as real (bit 0) or fake (bit 1). Our second procedure is a stream cipher. It encodes the ID bit of each symbol by operating a XOR (exclusive-or) with a given secret-key. s The result is an encrypted Huffman coding and decoding that can be used in communication or in gigabytes sized document collections as proposed in [Moff94]. 0 1 s 3 s 4 s 2 In section 2, the Huffman coding, decoding and properties are introduced. In section 3, we describe our multiple substitution and stream cipher used to modify Huffman codes to add the encryption feature. In section 4, we relate some experiments using our implementation to compress and encrypt some documents. Finally, in section 5, we conclude our work. 2 Huffman Codes Suppose that a plaintext has a set of n different symbols S = {s 1,...,s n }, n>1, and that the frequency of each symbol in the plaintext is known. So, a code for each symbol is required in order to compress the plaintext, limited by prefix-free codes. Prefix-free codes means that no codeword is the first part (prefix) of another codeword. When decoding, it is easy to recognize in the decoding process the end of a codeword without reading the next codeword. That is, the code searched is that of a prefix-free binary tree, where each symbol is located at one tree s leaf. A walk through the tree assigns the codeword of a symbol when you reach a leaf. Huffman codes were introduced by David Huffman [Huff52] in This coding scheme compresses texts by assigning shorter codes to the most used symbols and longer codes to the rare ones. Now, let us illustrate the approach of Huffman s algorithm. Suppose the following plaintext with 25 symbols: s 2 s 3 s 2 s 1 s 2 s 1 s 4 s 3 s 1 s 2 s 1 s 3 s 1 s 4 s 1 s 4 s 1 s 2 s 1 s 2 s 1 s 1 s 1 s 2 s 1 The frequencies of each symbol are calculated and a prefix-free tree labeled with 0 (left child) or 1 Figure 1 - prefix-free tree Then, a walk in the tree through the leaves generates the codetable of figure 2. Symbol Frequency Codeword s s s s Figure 2 - Codetable The plaintext is encoded with 44 bits as follows: In a standard text coding, we would have 8 bits per symbol, and hence 200 bits for the above plaintext. With the codetable of figure 2, we achieve only 44 bits. This is due to the fact that the most frequent symbols in the plaintext have the smallest codeword lengths. Huffman decoding is almost immediate. With the Huffman codes assigned to each symbol, we go parsing the bits of the encoded text and walking through the Huffman tree. Guided by the labeled branches assigned with the bit, we traverse the coding tree until reaching a leaf. At this leaf, we find the encoded symbol. A Huffman tree is an optimal tree, but we also have several other optimal trees. Some of them are easily obtained by exchanging the places of symbols s i at the same level of the tree. This can be used to hide code information. Wayner [Wayn88] proposed two methods for assigning a key to a tree. First, suppose we have a Huffman tree with N leaves. It is well known that for a strict binary tree with N leaves we have: 1. N-1 internal nodes; 2. The depth H of the tree satisfies: upperbound(log N) H N-1.

19 Therefore, Wayner proposed that we can have a set of optimal Huffman trees by operating an XOR between each N-1 branches of the tree with a control key with size N-1. Or we can assign one bit of a key for each level of the tree. The size of the key can be too short in this case, O(log N). Milidiú et al [Mili97] show that one can efficiently implement prefix-free codes with length restriction, obtaining also very effective codes with little loss of compression. These two procedures lead to cipher procedures. 3 Encrypted Huffman Here, we propose two cryptosystems to add encryption properties to Huffman codes. A Cryptosystem is a five-tuple (P, C, K, E, D), where the following conditions are satisfied: 1. P is a finite set of possible plaintexts; 2. C is a finite set of possible ciphertexts; 3. K, the keyspace, is a finite set of possible keys; 4. For each k in K, there is an encryption rule e k E and a corresponding decryption rule d k D. Each e k : P=>C and d k : C=>P are functions such that d k (e k (X)) = X for every plaintext X in P. 3.1 Multiple Substitution Our first procedure is a multiple substitution cipher. We insert null symbols in the cipher text. A null symbol means nothing, and their inclusion is only to avoid easy decoding of the text by unauthorized people. This null symbol η, that we call a fake symbol, is inserted in the ciphertext with multiple codes, also called homophones. We use a set = {δ 1, δ 2,, δ m } of fake symbols generated to disguise the output ot the effective null symbol. Next, we describe the method. Our Multiple Substitution is a cryptosystem (P, C, K, L, F, E, D) where we additionally define: 1. L as a finite set of possible fake codes representing the fake symbol η. So, we have L a subset of C and S + = S U {η}, where S + is the alphabet of symbols plus the null symbol; 2. F = (f 1, f 2, ) as the fake code generator. For i >= 1, f i : P=>P i-1 x L. a. Codebook construction The set of fake codes are indeed homophonic codes of η. This homophones can be generated according to several alternatives such as: Alternative 1: After collecting the plaintext alphabet S={s 1, s 2,, s n } with their frequency values, create other m symbols that we define as to be fake symbols δ j with j in [1,m] that are homophones of η. Generate random frequencies to each δ j symbol and then construct the Huffman tree with S and {δ 1, δ 2,..., δ m } symbols together in the same tree; Alternative 2: Create m symbols δ j with j in [1,m] with the frequency values equal to the first m symbols of S in the Huffman tree. Then, construct a second fake Huffman tree; Alternative 3: After constructing the Huffman tree with the S symbols, assume that the first m symbol s codes represent the m fake codes too. In both alternatives 2 and 3 we need an extra identification bit (ID bit) to indicate when the symbol code is real (bit 0) or fake (bit 1). We call α the fake tree generation rate. It is a parameter that controls the expansion rate, say 30% for example, of fake symbols in the coding tree. With this rate we can configure the number of distinct fake symbols created as m = α * n as shown in figure 3 that illustrates alternative Figure 3 Fake tree construction rate generates a new fake Huffman tree We use indeed alternative 3 due to its savings of memory space and small time to construct a Huffman tree with more symbols (alternative 1) or a second tree (alternative 2). α

20 So, α is the symmetric key that defines the number of distinct fake symbols used as shown in figure 3. b. Coding With the m fake codes defined, we use a function to generate a string of fake codes for each symbol x i of X=x 1 x 2. Let L i be the string of codes generated for x i ; Codes of L i are a string of m i homophones of η, that is, the fake codes of δ j with j in [1,m] followed by the x i symbol itself. So, L i = (δ 1, δ 2,..., δ mi, x i ) as shown in figure 4. The δ j codes are randomly chose from the m fake codes. Sequential selection could be used if desired. So, we have a Geometrical Distribution of generating m i fake codes plus the effective symbols defined by the following expression: P[m i + 1] = β (mi+1)-1. (1- β) = β mi. (1- β) The decoding procedure is very simple, as shown below: 1. If the codeword read is a S symbol, then d k (s=x i ) = x i ; 2. Else d k (s=t j ) = η and the null symbol is skipped. By generating fake symbols we insert new characters in the encoded text in order to flatten the overall distribution of the symbols of a given language. c. Diffusion x i f i δ 1 δ 2 δ 3.. x i L i Figure 4 Generation of homophones of η followed by the effective symbol Finally, let β be a fake symbol generation rate, that is, the probability of generating a fake code at each round before outputting the effective code. So, the coding procedure is the following pseudocode: 1. Choose a random number p, p in [0,1] 2. If p<β then e Rs (x i )=δ j return to 1 3. Else e Rs (x i )=x i i is increased by 1 4. If i n then return to 1 5. End. The parameter β is used to set the number of fake symbols generated between real symbol outputs. It is used to balance diffusion and text expansion. A well-known cipher attack is statistical analysis. In any language some characters are used more than others. Hence, an attack could be done by counting the frequencies of each symbol in a ciphertext and trying to assign each one to characters in the language that have the same distribution frequencies that the ones found in the ciphertext. With fake codes generation, we achieve some diffusion in the distribution of frequency of codes. Then, counting the frequencies of codes can lead to wrong assignments to symbols. It s obvious that a great disadvantage of this scheme is text expansion. But it has great benefits too: diffusion of distribution frequencies and the lack of correlation between symbols in the language. Both features lead to a more difficult statistical analysis. d. Text Expansion To estimate the text expansion of multiple substitution we observe that: (i) The average number of output ciphers generated is the average of a Geometrical Distribution, that is, 1/(1-β); (ii) One additional bit per character due to the ID bit is needed. Since we have H(X) l(huffman) < H(X)+1, it leads to H(X) + 2. The text expansion can be estimated by the average number of characters generated times the average number of bits. So, the average number of bits B per character is:

21 B [1/(1-β)]. ( H(X) + 2 ) For example, using β=0.30 and assuming that we have H(X)=4.19 for monogram parsing, and an average H L =1.25 for the entropy of english language we get: 1/(1-β) = 1/(1-0.30) = 1.43, that is, 43% of text expansion due to fake codes. B (4.19+2) = 8.85 B L 1.43 (1.25+2) = 4.65 So, we should still achieve compression using word parsing in our encrypted Huffman if compared to standard ASCII representation (8 bits per character). 3.2 Stream Cipher Suppose that someone has the encoded text, the Huffman codetable and the number of fake codes defined by β. Then, decoding is immediate. Therefore, a secret-key is necessary to add confusion to the process. The secret-key we use is fully scalable. It can have any length we desire: 48 bits, 128 bits, 256 bits, etc. So, we introduce a second procedure, a stream cipher. A Stream cipher is a cryptosystem (P, C, K, L, F, E, D) where we additionally define: 1. L as a finite set called the keystream alphabet; 2. F=(f 1, f 2, ) as the keystream generator. For i >= 1, f i : K x P i-1 => L. a. Keystream Let k K and X=x 1 x 2. The stream cipher procedure is defined as: (i) Z=z 1 z 2 is the keystream. We have a function f i that generates z i from k: z i = f i (k, x 1, x 2,, x i-1 ); (ii) z i is used to cipher x i such that y i = e zi (x i ); We have a new z i key for each x i that comes in, and this z i key is generated from the past z 1, y 1, z 2, y 2,, z i-1, y i-1. Our method consists of a single constant function such that z i = f(k,i). If k < X, that is, the size of the key is less than the size of the plaintext, we have two alternatives to generate the keystream: Alternative 1: Cyclic keystream generation - when the key k ends up we return back to the beginning and so on. Then, we have the key bit defined by z i = f(k, i) = k i mod φ, where φ= k ; Alternative 2: Random keystream generator - function f generates bit-streams using key k as a seed. We assume alternative 1 as illustrated in figure 5.This way, we maintain Huffman s coding synchronism properties. Alternative 2 is not used since it causes dependency with past. keystream k ID-bit XOR codeword Figure 5 XOR between the i-th bit of the key k and the ID bit of the codeword b. Coding We define coding and decoding procedures as - XOR (exclusive-or) operations between the z i bit and all the bits of the codeword. This is equivalent of exchanging places of a symbol in the Huffman tree: y i = e k (x i ) = (z i xor x i,1, z i xor x i,2,, z i xor x i, xi ) x i = d k (x i ) = (z i xor y i,1, z i xor y i,2,, z i xor y i, yi ) However, we use indeed a simpler procedure defined by a XOR between the z i bit and only the first bit of the codeword. This is equivalent of only disguising the ID bit: y i = e k (x i ) = (z i xor h 1, x i,2,, x i, xi ) x i = d k (x i ) = (z i xor h 1, y i,2,, y i, yi ) Where h 1 and h 1 are the ID bits of x i and y i.

22 c. Confusion With this XOR operation we add hideness to our method. It is simple and has low processor cost. The secret-key can have any length and any kind of trial-and-error attacking would be so much time consuming that makes the analysis unfeasible. In this scheme, we have indeed a composite key that contains α and the keytream seed k as shown in figure 6. α K Figure 6 Composed key With this secret key included in the process, we have an encryption system to use in insecure communication channels. d. Text Expansion The stream cipher does not cause any additional text expansion. 4 Experiments In table 1, we list some results with a C++ implementation of our encrypted Huffman coding and decoding. We use the Brazilian Constitution and the Gutenberg Project collection. We use α = 0.30, monogram parsing and all sizes are expressed in bytes. We first measure the storage space required to compress the documents collection using standard Huffman coding. Then, we use the encrypted Huffman and measure the difference between the new space required to the encryption features, that is, the extra-space needed. Observe that text expansion is very close to its expected value. Moreover, the relative additional time to introduce encryption to the compression process is about 5%. Brazilian Constitution Gutenberg Project Plaintext size Encoded text size (Huffman) Ciphertext size Expansion over 19% 34% plaintext Expansion over encoded text 104% 130% 5 Conclusions Table 1 Extra-space results Usually, one make serial procedures to compress and then encrypt a file. In this work, we proposed simple modifications in Huffman codes to add encryption to its compression feature. It results in a fast and low computational power consumption that provides enough confusion and diffusion to the ciphertext. That follows from both its theoretical and practical properties. The diffusion and confusion are also controlled parameters. The β factor controls the rate of generating fake codes. With β we can set the ciphertext expansion due to null symbol insertion, what is directly associated with the security of the file. While the size of the key k is associated with the security of the confusion feature. References [Gunt88] Gunter, C.G An Universal Algorithm for Homophonic Coding. in Advances in Cryptology Eurocrypt-88, LNCS, vol [Huff52] Huffman, D A Method for the Construction of Maximum of Minimum Redundancy Codes. Proc. IRE, [Mass89] Massey, J.L., Kuhn, Y.J.B., Jendal, H.N An Information-Theoretic Treatment of Homophonic Substitution. in Advances in Cryptology Eurocrypt-89, LNCS, vol [Mili97] Milidiú, R.L., Laber, E.S Improved Bounds on the Inefficient of Length-Restricted Prefix Codes.

23 [Moff94] Moffat, A., Witten, I.I., Bell, Timothy C Managing Gigabytes: Compressing and Indexing Documents and Images. Van Nostrand Reinhold. [Rive96] Rivest, Ronald L., Mohtashemi, M., Gillman, David W On Breaking a Huffman Code. IEEE Transactions on Information Theory, vol. 42, no. 3. [Shan49] Shannon, C Communication Theory of Secrecy Systems. Bell Syst. Tech., vol. 28, no. 4, pp [Simm91] Simmons, G Contemporary Cryptology The Science of Information Integrity. IEEE Press. [Stin95] Stinson, D.R Cryptography: Theory and Practice, CRC Press [Wayn88] Wayner, P A Redundancy Reducing Cipher, Cryptologia,

24

25 ALGORITMOS INTELIGENTES PARA BUSCA DE PADRÕES NA DETECÇÃO DE INTRUSÃO Daniel Rodrigues Ambrósio, Stênio Firmino Pereira Filho, Edson dos Santos Moreira Departamento. de Ciências da Computação e Estatística Instituto de Ciências Matemáticas e de Computação ICMC-USP São Carlos - SP {daniel,stenio,edson@icmc.sc.usp.br Mauro Cesar Bernardes Instituto de Engenharia e Ciências Exatas Universidade de Alfenas UNIFENAS Alfenas - MG mauro@icmc.sc.usp.br RESUMO Este trabalho apresenta.uma discussão sobre a tecnologia de Inteligência Computacional mais indicada para ser usada no reconhecimento de padrões na Detecção de Intrusão. As Redes Neurais, as Redes Bayesianas e os Algoritmos Genéticos são alguns dos candidatos. As vulnerabilidades dos sistemas computacionais surgem e disseminam-se rapidamente, impondo a necessidade do aumento do nível de adaptação das ferramentas de segurança. Os Sistemas de Detecção de Intrusão baseados em inteligência computacional vêm para facilitar o trabalho do administrador, fornecendo informações relevantes para ajudá-lo no processo de tomada de decisão. ABSTRACT This work presents a discussion about which Computer Intelligence technology fits better on pattern recognition systems for Intrusion Detection. Neural Networks, Bayesian Nets and Genetic Algorithms are some candidates. The computational vulnerabilities appear and spread very fast, so there is a need increase the level of adaptability of the security tools. Intrusion Detection Systems based on Computer Intelligence ease the work of the system administrator, offering relevant information to help in his/her decisionmaking process. 1 INTRODUÇÃO Como o número de usuários que dependem da segurança computacional passou de apenas algumas organizações que lidam com dados secretos para todo o mundo conectado à Internet, as necessidades de segurança computacional mudaram radicalmente. No mundo atual de redes internacionais e comércio eletrônico, todo sistema computacional é um alvo potencial. Raramente passa-se um mês em que não surjam notícias na mídia de uma grande empresa ou organização que tenha tido seus sistemas invadidos. Apesar dos riscos, o interesse em redes de computadores, Internet e Comércio Eletrônico nunca foi maior. O número de computadores ligados à Internet tem aproximadamente dobrado a cada ano por aproximadamente uma década. Por todas as indicações, é provável que esse crescimento continue por alguns anos. Com esse crescente interesse, é natural que a preocupação com a proteção da informação também cresça. Porém não existe nenhum sistema que possa ser considerado o estado da arte em matéria de proteção e ainda, que forneça um elevado grau de segurança enquanto permite uma certa flexibilidade e liberdade no uso dos recursos computacionais. Existem fatores que tornam muito difícil impedir que atacantes eventualmente tenham acesso a um sistema. A maioria dos computadores possui algum tipo de furo de segurança que permite a atacantes externos (ou ainda legítimos) terem acesso a informações confidenciais. Mesmo um sistema supostamente seguro pode ser vulnerável a usuários internos abusando de seus privilégios ou ser comprometido por práticas impróprias. Em vista disto, uma vez que um ataque pode ser considerado inevitável, existe uma óbvia necessidade por mecanismos que possam detectar atacantes tentando penetrar no sistema ou usuários legítimos fazendo mal uso de seus privilégios. A abordagem a ser usada para garantir um bom nível de segurança a um site é o uso de várias tecnologias e ferramentas que sejam capazes de trabalhar integradas. Uma das ferramentas mais usadas hoje em dia é o firewall, responsável por fazer o isolamento da rede interna. Mas o firewall não é uma ferramenta completa, uma vez que ele não consegue trabalhar no lado interndo da rede. Ele também não é capaz de barrar uma tentativa de intrusão ou de abuso de privilégio para as quais não tenha sido previamente programado. Surge então a necessidade de um sistema capaz de trabalhar no lado interno da rede e que tenha um caráter adaptativo, ou seja, que consiga aprender novos padrões de ações que caracterizem um ataque. É desejável também que essa ferramenta, uma vez que ela tem a capacidade de detectar ações maliciosas, seja capaz de tomar algumas decisões de prevenção ou de remediamento da situação baseado no conhecimento dado a ela. Uma ferramenta candidata seria um Sistema de Detecção de Intrusão (SDI) que faça uso de algum algoritmo de inteligência computacional capaz de

26 lhe conferir a capacidade de aprender quando está sendo feita a tentativa de um ataque ou quando ele já está em andamento, de reagir a ele. Esse trabalho visa então, analisar as opções existentes hoje na área de Inteligência Computacional que possam ser aplicadas a esse cenário e que confiram à ferramenta a ser desenvolvida, as características já mencionadas e também outras desejáveis, como rapidez tanto na detecção quanto na tomada de decisão e detecção do maior número possível de intrusões entre outras. A seção 2 introduz o conceito de Sistemas de Detecção de Intrusão e apresenta o ACME! um SDI desenvolvido em conjunto pelo ICMC USP e Unesp de São José do Rio Preto que usa Redes Neurais para fazer a detecção. A seção 3 apresenta algumas das tecnologias de inteligência computacional que podem ser usadas pelo sistema. 2 SISTEMAS DE DETECÇÃO DE INTRUSÃO (SDI) Mesmo depois de definida uma boa política de segurança e da configuração e instalação de programas e tecnologias para a proteção do sistema, ainda existe a possibilidade de falhas ou de ações maliciosas de usuários tanto externos quanto internos. Portanto, se torna desejável a existência de sistemas capazes de realizar a detecção de tais falhas e informar o administrador da rede. Tais sistemas são conhecidos como Sistemas de Detecção de Intrusão (SDI) 1. Detecção de Intrusão é definida em SPAFFORD et al. [1998] como o problema de identificar pessoas que estejam usando um sistema computacional sem autorização (por exemplo crackers) e aqueles que tem acesso legítimo ao sistema mas estão abusando de seus privilégios e intrusão seria qualquer conjunto de ações que tentem comprometer a integridade, confidencialidade ou disponibilidade de um recurso. As funcionalidades de um sistema de detecção tornam-se de vital importância na medida em que fornecem meios de inferir sobre o conteúdo das conexões permitidas e detectar as que apresentem um comportamento suspeito ou não condizente com a política de segurança implantada. Os SDI são classificados sob diferentes ópticas na literatura da área. As principais classificações utilizadas são em termos da forma como o sistema aborda o problema de detectar intrusão e em termos do tratamento dos dados. De acordo com o Método de Detecção são classificados em: Modelo de Detecção por Uso Indevido: a detecção é feita através da procura de tentativas de explorar pontos fracos conhecidos do sistema, que podem ser descritas por um padrão específico ou seqüência de eventos ou dados (a assinatura da intrusão) Modelo de Detecção por Anomalia: a detecção é feita procurando por mudanças nos padrões de utilização ou comportamento do sistema. É construído um modelo estatístico que contém métricas derivadas da operação do sistema, e sempre que for detectado um desvio estatístico significativo do modelo, é sinalizada uma intrusão. Além disso, diversos SDI empregam ao mesmo tempo técnicas para detecção de anomalias e de uso indevido. Algumas são baseadas em técnicas de prédeterminação de padrões futuros, a partir do comportamento anterior, enquanto outras, utilizam técnicas estatísticas para determinar o comportamento anômalo. Em ambos os casos, quando o comportamento monitorado não está de acordo com o comportamento esperado, pode haver um indicativo de intrusão. Os modelos são baseados na hipótese de que a exploração das vulnerabilidades de um sistema envolve algum tipo de desvio. Deste modo, violações de segurança podem ser detectadas a partir de algoritmos agindo nos computadores em questão, ou sobre a rede como um todo. A outra classificação é feita separando os SDIs de acordo com o tratamento dos dados: Sistemas Baseados em Rede: Examinam os dados que trafegam pela rede através da monitoração online dos pacotes (sniffing). Sistemas Baseados em Host: Analisam dados de auditoria recolhidos normalmente pelos sistemas operacionais e buscam de diversas formas pelos padrões de ataque. Em ambos os casos o SDI é freqüentemente um grande módulo monolítico. Este módulo executa todo o monitoramento, obtenção e manipulação de dados e tomada de decisão para todo o sistema. Um problema observado neste tipo de abordagem para a construção de um SDI é o overhead imposto no sistema que está sendo protegido. É importante ressaltar que um sistema de detecção de intrusão não inclui prevenção de intrusão, somente detecção e a comunicação de sua ocorrência ao administrador. Em SPAFFORD et al. [1998] são apresentadas as características desejáveis de um SDI: Ele deve rodar continuamente com um mínimo de supervisão humana. Ele deve ser tolerante a falhas no sentido que deve ser capaz de se recuperar no caso do sistema cair, tanto acidentalmente ou por ações maliciosas. 1 Em inglês: Intrusion Detection Systems

27 Ele deve resistir à subversão, ou seja, o próprio sistema tem que ser capaz de identificar se foi modificado por um atacante. Ele deve impor um overhead mínimo no sistema onde está rodando para que não interfira em sua performance. Ele deve ser capaz de ser configurado de acordo com a política de segurança do sistema que ele está monitorando. Deve ser capaz de adaptar mudanças no sistema e no comportamento dos usuários. O IDS deve ser escalável para suportar a carga de monitorar várias estações e ainda produzir resultados confiáveis e a tempo. Uma boa fonte de informações sobre Sistemas de Detecção de Intrusão em desenvolvimento ou prontos ao redor do mundo, é SOBIREY [2000]. 2.2 ACME! - O Sistema de Detecção de Intrusão Uma das características inovadoras deste sistema de detecção de intrusão por abuso consiste em introduzir um agente de segurança capaz de detectar comportamento intrusivo em conexões estabelecidas [CANSIAN et al., 1997a, 1997b, 1997c, BONIFÁCIO Jr. et al., 1998a]. Este agente atua capturando e decifrando pacotes que são transmitidos através da rede sob monitoramento. Para fazer uma inferência sobre a condição de segurança das conexões, o agente emprega um sistema especialista e uma rede neural que irá prover um coeficiente de suspeita, o qual, baseado em informações intrusivas previamente registradas, dará uma idéia a respeito da severidade do ataque ou o grau de suspeita das atividades naquela conexão. O sistema baseia-se no fato de que uma intrusão pode ser detectada a partir de uma análise de modelos predeterminados, que são anômalos se comparados com ações normais. A grande maioria dos ataques é resultado de um pequeno número de ataques conhecidos, e são relatados por equipes como o CERT. O uso de redes neurais pode fornecer mecanismos para o reconhecimento de ataques, bem como uma capacidade de adaptação em resposta a mudanças nas técnicas de intrusão. O módulo de pré-seleção determina e realiza uma filtragem inicial dos eventos que possam representar interesse, como por exemplo, que tipo de protocolo deve ser monitorado, quais os serviços mais críticos, ou quais destinos ou origens devem ser considerados ou descartados. Estes dados são enviados ao sistema especialista para serem analisados e depois da tomada de decisões servirão como elementos de análise para monitoração dos eventos de risco e vão também determinar quando o sistema deve começar a capturar todos os dados de uma determinada sessão. Esses dados são armazenados na lista de monitoração. Uma vez que o módulo de pré-seleção e o sistema especialista identificaram os acessos que diferem dos padrões inicialmente aceitáveis, todos os pacotes provenientes da conexão são enviados para o módulo de conexão, que os organiza numa relação de causa e efeito, identificando um fluxo de dados unidirecional. Se for necessário (e possível) são formados pares de vetores de fluxo de modo a representar bidirecionalmente o tráfego de dados, de uma sessão ponto a ponto em particular. Esses vetores bidirecionais são chamados vetores de conexão e são enviados para o analisador semântico. A função principal do analisador semântico é preparar o vetor de estímulo, que conterá os dados que serão analisados pela rede neural. Ele age sobre os vetores de conexão, fazendo uma filtragem e buscando perfis de ataques que estejam presentes nos dados. Esses perfis, que estão armazenados em uma base de dados e que podem ser atualizados conforme a necessidade, são na verdade strings de caracteres relevantes, pertencentes a assinaturas de ataques, e contém informações sobre como uma sessão suspeita se desenvolve. A rede neural analisa o vetor de estímulo de cada sessão, com os respectivos pesos que representam a importância da ocorrência dos eventos, e procura atribuir um grau de suspeita, que representa o estado de segurança da sessão. O sistema de gerenciamento recebe então o valor numérico que representa o estado de segurança das sessões suspeitas e as mapeia, classificando-as pelo grau de severidade. A partir deste ponto, várias ações podem ser tomadas, tais como emissão de vários níveis de alerta aos administradores, disparo de processos de auditoria, ativação de contramedidas para isolar o host ou o domínio originador do ataque através do ajuste de, por exemplo, um firewall. 3 INTELIGÊNCIA COMPUTACIONAL Esta seção apresenta algumas das tecnolgias de inteligência computacional que poderiam ser empregadas nos Sistemas de Detecção de Intrusão. 3.1 Redes Neurais As Redes Neurais Artificiais (RNA) representam uma forma de computação não algorítmica caracterizada por sistemas que, em algum nível, relembram a estrutura do cérebro humano. Segundo CARVALHO et al. [1999] RNAs são sistemas paralelos distribuídos compostos por unidades de processamento simples (nodos) que computam determinadas funções matemáticas (normalmente não-lineares). Essas unidades são normalmente dispostas em camadas (uma ou mais)

28 e interligadas por um grande número de conexões, geralmente unidirecionais. O conhecimento representado no modelo geralmente está associado a um peso que é dado a essas conexões e serve para ponderar a entrada recebida por cada neurônio da rede. PRECHELT [1995] ainda adiciona que cada nodo possui uma pequena quantidade de memória e trabalha com dados numéricos e não simbólicos, além de operarem apenas em seus dados locais e nas entradas que recebe através dessas conexões. A solução de problemas através de RNAs é bastante atrativa, já que a forma como estes são representados internamente pela rede e o paralelismo natural inerente à arquitetura das RNAs criam a possibilidade de um desempenho superior ao dos modelos convencionais. Ainda segundo CARVALHO et al. [1999] o procedimento usual na solução de problemas em uma RNA passa ainda por uma fase de aprendizagem, onde um conjunto de exemplos é apresentado à rede, a qual extrai automaticamente as características necessárias para representar a informação fornecida. Essas características são usadas posteriormente para gerar respostas para o problema. A capacidade de aprender através de exemplos e de generalizar a informação aprendida são, sem dúvida, os atrativos principais da solução de problemas através de RNAs. A generalização que está associada à capacidade de a rede aprender através de um conjunto reduzido de exemplos e posteriormente dar respostas coerentes para dados não conhecidos, é uma demonstração de que a capacidade das RNAs vai muito além do que simplesmente mapear relações de entrada e saída. Em PRECHELT [1995] podemos encontrar vários algoritmos de aprendizado classificados de acordo com o método que utilizam Aprendizado Supervisionado É o método de aprendizado mais comum no treinamento de RNAs e é assim chamado porque a entrada e a saída desejadas para a rede são fornecidas por um supervisor externo. O objetivo é ajustar os parâmetros da rede, de forma a encontrar uma ligação entre os pares de entrada e saída fornecidos. A Figura 1 ilustra o mecanismo de aprendizado supervisionado. Entrada Professor RNA Erro - Saída Figura 1: Aprendizado Supervisionado + O professor indica explicitamente um comportamento bom ou ruim para a rede, visando direcionar o processo de treinamento. A rede tem sua saída corrente (calculada) comparada com a saída desejada, recebendo informações do supervisor sobre o erro da resposta atual. A cada padrão de entrada submetido à rede, compara-se a resposta desejada (que representa uma ação ótima para ser realizada pela rede) com a resposta calculada, e ajustando-se os pesos das conexões para minimizar o erro. A desvantagem do aprendizado supervisionado é que, na ausência do professor, a rede não conseguirá aprender novas estratégias para situações não cobertas pelos exemplos do treinamento da rede. O backpropagation é um exemplo de algoritmo de aprendizado supervisionado Aprendizado Não-Supervisionado Como o próprio nome sugere, no aprendizado não-supervisionado, não há um professor ou supervisor para acompanhar o processo de aprendizado. Embora o aprendizado supervisionado seja muito parecido com a maneira que o ser humano aprende, muitos dos sistemas biológicos aprendem de maneira não-supervisionada, como por exemplo os estágios iniciais dos sistemas de visão e de audição. Para estes algoritmos, somente os padrões de entrada estão disponíveis para a rede, ao contrário do aprendizado supervisionado, cujo conjunto de treinamento possui pares de entrada e saída. A partir do momento em que a rede estabelece uma harmonia com as regularidades estatísticas da entrada de dados, desenvolve-se nela uma habilidade de formar representações internas para codificar características da entrada e criar novas classes ou grupos automaticamente. Este tipo de aprendizado, só se torna possível quando existe redundância nos dados de entrada. Sem redundância seria impossível encontrar quaisquer padrões ou características dos dados de entrada. Existem vários algoritmos para implementação do aprendizado não-supervisionado. Entre eles temos o Aprendizado Hebbiano, Modelo de Linsker, Regra de Oja, Regra de Yuille e Aprendizado por Competição Aprendizado por Reforço O Aprendizado por Reforço pode ser visto como um caso particular de aprendizado supervisionado. A principal diferença entre o aprendizado supervisionado clássico e o aprendizado por reforço é a medida de desempenho usada em cada um dos sistemas. No aprendizado supervisionado, a medida de desempenho é baseada no conjunto de respostas desejadas usando um critério de erro conhecido, enquanto que no aprendizado por reforço o desempenho é baseado em qualquer medida que

29 possa ser fornecida ao sistema. No aprendizado por reforço, a única informação de realimentação fornecida à rede é se uma determinada saída está correta ou não, isto é, não é fornecida à rede a resposta correta para o padrão de entrada. A idéia básica que está por trás do termo reforço tem sua origem em estudos experimentais sobre aprendizado dos animais. Nesse contexto, é interessante lembrar a Lei do Efeito que diz que quanto maior a satisfação obtida com uma certa experiência em um animal, maiores as chances dele aprender Redes Construtivas A arquitetura de uma RNA pode ter um impacto significativo no seu desempenho para uma dada aplicação. Várias técnicas têm sido desenvolvidas para a otimização desta arquitetura. Estas técnicas podem ser agrupadas em duas abordagens. A primeira envolve o uso de um procedimento sistemático que permita a exploração de um conjunto de possíveis arquiteturas. A segunda defende a necessidade de uma regra ou conjunto de regras, que permita a escolha da melhor arquitetura para um problema específico. As Redes Neurais Artificiais Construtivas, RNACs se encaixam na segunda abordagem. Essas redes otimizam sua topologia permitindo a inserção e remoção de elementos durante o processo de treinamento. A otimização de arquiteturas neurais envolve, geralmente, a avaliação empírica de um grande número de arquiteturas. O principal inconveniente desta abordagem é a necessidade de treinar várias redes antes de encontrar a melhor arquitetura para o problema atacado. Existem vários métodos para tornar mais eficiente esta procura, os quais podem ser agrupados em três abordagens: Otimização genética; Técnicas de Prunning; Redes Construtivas. A terceira abordagem advoga que a arquitetura de uma rede pode ser definida utilizando uma rede inicialmente pequena, na qual novas unidades são inseridas durante o treinamento. Algoritmos de aprendizado como este são chamados algoritmos construtivos (growing). A definição da arquitetura por um algoritmo construtivo pode incluir uma fase de prunning, onde após o crescimento da estrutura da rede, nodos ou conexões irrelevantes podem ser removidos. Existem vários modelos de redes construtivas, os quais podem ser classificados segundo vários critérios, como por exemplo: Conexões ajustadas; Limite para o crescimento da rede; Conectividade dos nodos; Estrutura adicionada durante o crescimento. O quarto critério apresenta pelo menos três variações. Algumas RNACs crescem sua arquitetura inserindo um nodo por vez, que é o caso das NTN (do inglês Neural Tree Networks) e CasCor (do inglês Cascade Correlation). As redes Upstart e Tiling expandem suas arquiteturas inserindo mais de uma unidade por vez. Já as redes treinadas com os algoritmos Tower e Pyramid criam uma camada de cada vez [CARVALHO et al., 1999] A Rede Neural do SDI do ICMC Em BONIFÁCIO [1998] são apresentados os experimentos e os resultados obtidos com este sistema de rede neural MLP. Estas redes são geralmente treinadas pelo algoritmo backpropagation. Este algoritmo usa uma generalização da regra delta rule para treinar uma rede com várias camadas começando na camada de saída e voltando camada por camada. Geralmente, este treinamento requer diversos passos. Como o algoritmo backpropagation requer um longo tempo para treinar a rede, algumas modificações foram utilizadas que aceleram o processo de treinamento. As variações do backpropagation que foram usadas são Quickprop e Rprop. As redes neurais usadas nos experimentos têm 126 neurônios na camada de entrada correspondentes aos 126 bits do vetor de estímulo (gerado a partir dos padrões de invasões conhecidos). Diversas configurações diferentes foram testadas para identificar a que apresenta a melhor performance para este problema. Os testes foram realizados com o simulador SNNS (Sttutgart Neural Network Simulator) 2. Foram feitos testes com 8 topologias diferentes, todas com 126 neurônios na camada de entrada e um na camada de saída. As topologias usadas foram: (126 neurônios de entrada e 1 de saída, sem camadas intermediárias), , , , , (com uma camada intermediária, onde o segundo número indica o número de neurônios nesta camada), e (com duas camadas intermediárias). Foi usada uma segunda camada intermediária na tentativa de se aumentar a performance. Nos testes, foi verificado que a rede com a melhor performance foi a , então foi decidido inserir a segunda camada intermediária nesta topologia, com 1 e 5 neurônios. Todas as topologias utilizadas são completamente conectadas, isto é, todos os neurônios em uma camada estão conectadas a todos os neurônios da camada seguinte. Cada uma das 8 topologias foi testada utilizando-se todos os algoritmos com todos os 2 Pode ser encontrado em (visitado em 16/03/2000)

30 respectivos possíveis parâmetros. Para cada possível configuração (topologia, algoritmo de treinamento e parâmetros) foi verificado que valores diferentes nos pesos iniciais dos neurônios causaram grandes diferenças na saída da rede. Para conseguir um resultado confiável, foram feitos 20 treinamentos diferentes para cada configuração possível e foi usado o valor médio como um valor de comparação adequado. Foram feitos 1440 treinamentos diferentes e os gráficos com os resultados podem ser encontrados em BONIFÁCIO [1998]. A análise dos resultados mostrou que a rede neural com a melhor performance foi a , com duas camadas intermediárias, algoritmo de treinamento backpropagation e parâmetros n = 0.2 e delta = 0.5, apresentando uma taxa média de erro de 5.067%. É interessante notar também que este algoritmo de treinamento com estes parâmetros obteve os melhores resultados, e nas topologias com apenas uma camada intermediária, os melhores resultados situaram-se entre as topologias e , tornando-se pior com mais ou menos neurônios na camada intermediária. 3.2 Algoritmos Evolucionários Algoritmo Evolucionário (AE), segundo BEASLEY [2000] é um termo usado para descrever sistemas para resolução de problemas que usam modelos computacionais de alguns dos mecanismos conhecidos da evolução como elementos chaves do seu projeto e implementação. Vários algoritmos evolucionários foram propostos, entre eles: algoritmos genéticos, programação evolucionária, estratégias de evolução e programação genética. Todos eles compartilham uma base conceitual simulando a evolução de estruturas individuais através de processos de seleção, mutação e reprodução. Mais precisamente, os AEs mantém uma população de estruturas, que se desenvolve de acordo com as regras de seleção e outros operadores, que são referenciados como operadores de busca (ou operadores genéticos), como recombinação e mutação. Cada indivíduo na população recebe uma medida de sua adaptabilidade (fitness) ao ambiente. A reprodução concentra sua atenção em indivíduos de alta adaptabilidade explorando, portanto, a informação de adaptabilidade disponível. Recombinação e mutação perturbam estes indivíduos, fornecendo heurísticas gerais para exploração. Embora simplista através de um ponto de vista biológico, estes algoritmos são suficientemente complexos para fornecer mecanismos de adaptação robustos e poderosos Algoritmos Genéticos O algoritmo genético é um modelo de aprendizado de máquinas que deriva seu comportamento de uma metáfora de alguns dos mecanismos de evolução da natureza. Existem várias definições para algoritmos genéticos, uma das possíveis é encontrada em PRECHELT [1995]: Um algoritmo genético é um programa de otimização que começa com uma população de procedimentos codificados, estocasticamente gera mutações nessa população e depois usa um processo de seleção para escolher os mutantes com maior adaptabilidade e talvez uma recombinação de processos para combinar propriedades, ou preferencialmente, os mutantes mais qualificados. BEASLEY [2000] diz que estes algoritmos conseguem essa simulação do mecanismo de evolução da natureza criando em uma máquina uma população de indivíduos representados por cromossomos, em essência um conjunto de strings de caracteres que são análogas aos cromossomos base-4 que nós vemos em nosso DNA. Os indivíduos dessa população então passam por um processo de evolução simulada. Algoritmos Genéticos, segundo FILHO [1997], são algoritmos de otimização global, baseados nos mecanismos de seleção natural e da genética. Eles empregam uma estratégia de busca paralela e estruturada, mas aleatória, que é voltada em direção ao reforço da busca de pontos de "alta aptidão", ou seja, pontos nos quais a função a ser minimizada (ou maximizada) tem valores relativamente baixos (ou altos). Na prática, no entanto, podemos implementar este modelo genético de computação usando arrays de bits ou caracteres para representar os cromossomos. Operações simples de manipulação de bits permitem a implementação de crossover, mutação e outras operações. Embora uma quantidade significativa de pesquisa tenha sido feita em strings de tamanho variável e outras estruturas, a maioria dos trabalhos com algoritmos genéticos está concentrado em strings de caracteres de tamanho fixo. Quando o algoritmo genético é implementado é geralmente feito de uma maneira que envolve o seguinte ciclo: Avalie a adaptabilidade (fitness) de todos os indivíduos da população. Crie uma nova população executando operações como crossover, reprodução proporcional ao fitness e mutação nos indivíduos cujo fitness acabou de ser medido. Descarte a população antiga e execute o ciclo novamente usando a nova população. Cada uma destas iterações (ciclos) compõe uma geração. Não existe razão teórica para isso como um modelo de implementação. Além disso, esse comportamento pontual não é encontrado em populações na natureza como um todo, mas este é um modelo de implementação conveniente.

31 A primeira geração (geração 0) deste processo opera em uma população gerada randomicamente de indivíduos. A partir daí, as operações genéticas, atuando juntamente com as medidas de fitness, operam para melhorar a população. Resumindo, durante cada iteração, os princípios de seleção e reprodução são aplicados a uma população de candidatos que pode variar, dependendo da complexidade do problema e dos recursos computacionais disponíveis. Através da seleção, determinam-se quais indivíduos conseguirão se reproduzir, gerando um número determinado de descendentes para a próxima geração, com uma probabilidade determinada pela seu índice de aptidão. Em outras palavras, os indivíduos com maior adaptação relativa têm maiores chances de se reproduzir. Apesar de aleatórios, os AGs não são caminhadas aleatórias não direcionadas, pois exploram informações históricas para encontrar novos pontos de busca onde são esperados melhores desempenhos. O ponto de partida para a utilização de Algoritmos Genéticos, como ferramenta para solução de problemas, é a representação destes problemas de maneira que os Algoritmos Genéticos possam trabalhar adequadamente sobre eles. A maioria das representações são genotípicas, utilizam vetores de tamanho finito em um alfabeto finito. Tradicionalmente, os indivíduos são representados genotípicamente por vetores binários, onde cada elemento de um vetor denota a presença (1) ou ausência (0) de uma determinada característica: o seu genótipo. Os elementos podem ser combinados formando as características reais do indivíduo, ou o seu fenótipo. Teoricamente, esta representação é independente do problema, pois uma vez encontrada a representação em vetores binários, as operações padrão podem ser utilizadas, facilitando o seu emprego em diferentes classes de problemas. A utilização de representações em níveis de abstração mais altos tem sido investigada. Como estas representações são mais fenotípicas, facilitariam sua utilização em determinados ambientes, onde essa transformação "fenótipo - genótipo" é muito complexa. Neste caso, precisam ser criados os operadores específicos para utilizar estas representações. O princípio básico do funcionamento dos AGs é que um critério de seleção vai fazer com que, depois de muitas gerações, o conjunto inicial de indivíduos gere indivíduos mais aptos. A maioria dos métodos de seleção é projetada para escolher preferencialmente indivíduos com maiores notas de aptidão, embora não exclusivamente, a fim de manter a diversidade da população. Um método de seleção muito utilizado é o Método da Roleta (detalhado também em CARVALHO et al. [1999], onde indivíduos de uma geração são escolhidos para fazer parte da próxima geração, através de um sorteio de roleta. Neste método, cada indivíduo da população é representado na roleta proporcionalmente ao seu índice de aptidão. Assim, aos indivíduos com alta aptidão é dada uma porção maior da roleta, enquanto aos de aptidão mais baixa é dada uma porção relativamente menor da roleta. Finalmente, a roleta é girada um determinado número de vezes, dependendo do tamanho da população, e são escolhidos, como indivíduos que participarão da próxima geração, aqueles sorteados na roleta Algoritmos Meméticos Algoritmos Meméticos são uma abordagem de busca heurística aplicada em problemas de otimização baseados em população. Eles têm mostrado, segundo MOSCATO [1998] que são algumas ordens de magnitude mais rápidos do que os tradicionais Algoritmos Genéticos para alguns domínios de problemas. Basicamente, eles combinam heurísticas de busca local com operadores de crossover. MOSCATO & NORMAN [1992] introduziram o termo algoritmo memético para descrever algoritmos evolucionários em que a busca local tem um papel significativo. Esse termo é motivado pela noção de meme de Richard Dawkins como uma unidade de informação que se reproduz enquanto as pessoas trocam idéias. Existe uma diferença chave entre os genes e os memes: antes que um meme seja passado adiante, ele é tipicamente adaptado pela pessoa que o transmite, enquanto a pessoa pensa, entende e processa o meme. O gene, por outro lado é passado por inteiro. Moscato e Normam equipararam esse pensamento ao refinamento local, e portanto promoveram o termo algoritmo memético para descrever algoritmos genéticos que usam busca local exaustivamente. Informalmente, se um (verdadeiro) otimizador local é adicionado a um AG e aplicado a todo filho antes que seja inserido na população (incluindo a população inicial) então um algoritmo memético pode ser pensado simplesmente como um tipo especial de busca genética dentro do subespaço de ótimo local. Recombinação e mutação geralmente vão produzir soluções que estão fora deste espaço de ótimo local (e podem ser marcados como estragados ), mas um otimizador local pode então consertar tais soluções para produzir filhos que no final caiam dentro desse subespaço, caracterizando um algoritmo memético. 3.3 Redes Bayesianas Em AALBORG existe a seguinte definição resumida para Redes Bayesianas: Uma Rede Bayesiana é um grafo acíclico e direcionado onde cada nó representa uma varável randômica. Cada nó contém os estados da variável randômica que ele

32 representa e uma tabela de probabilidade condicional (ou em termos mais gerais, função de probabilidade condicional). A tabela de probabilidade condicional de um nó contém as probabilidades de que ele esteja em um estado específico dependente do estados de seus pais. As Redes Bayesianas podem ser encontradas na literatura sob diversos nomes: Redes Bayes (Bayes Nets), Redes Probabilístico-Causal (Causal Probabilistic Networks), Redes Bayesianas de Confiança (Bayesian Belief Networks) ou simplesmente Redes de Confiança (Belief Networks). Uma rede Bayesiana consiste de um conjunto de nós e um conjunto de bordas (edges) direcionadas entre estes nós. Essas bordas refletem relações de causa-efeito dentro do domínio. Esses efeitos normalmente não são completamente determinísticos (por exemplo doença sintoma). A força de um efeito é modelada como uma probabilidade: 1. Se amidalite Então P ( temp > 37.9 ) = 0,75 2. Se bronquite Então P ( temp > 37.9 ) = 0,65 Para que as afirmações 1 e 2 não sejam lidas como regras, normalmente uma notação diferente é usada: P ( temp > 37.9 bronquite ) = 0.65 Se 1 e 2 forem lidos como Se não estiver saudável e... Então..., Também existe a necessidade de uma especificação de como as duas causas combinam. Isto é, é preciso ter a probabilidade de ter uma febre se ambos os sintomas estiverem presentes e se o paciente for completamente saudável. Resumindo, é preciso especificar as probabilidades condicionais: P ( temp > 37.9 bronquite, amidalite ) Nesta situação, tanto bronquite quanto amidalite podem receber os estados sim e não. Então, é preciso especificar para todos os nós a força de todas as combinações de estados para as possíveis causas. Fundamentalmente, as redes Bayesianas são usadas para atualizar probabilidades quando chega uma informação. A base matemática para isso, é o Teorema de Bayes: P(A B) P(B) = P(B A) P(A) O método de atualização das Redes Bayesianas usam uma perspectiva global, e se o modelo e as informações estiverem corretas, pode ser provado que o método calcula as novas probabilidades de maneira correta (considerando os axiomas da teoria da probabilidade clássica) [JENSEN]. Qualquer nó na rede pode receber qualquer informação já que o método não distingue entre inferências a favor ou contra a direção das bordas. Também, entrada simultânea de informação em vários nós não vai afetar o algoritmo de atualização. As Redes Bayesianas tentam modelar as dependências do próprio domínio e por isso são também chamados de Sistemas de Suporte à Decisão. 4. PROPOSTA A proposta deste trabalho é a de fazer uma análise destas tecnologias em um nível mais prático. Decidir por exemplo quais são os custos envolvidos na implementação de cada um dos métodos e a sua adequação à área a que se destina a ferramenta a ser desenvolvida. Esta análise deve levar em consideração alguns aspectos prncipais. São eles: Carga de Processamento: Qualquer que seja a tecnologia escolhida ela deve ser rapidíssima na análise dos dados recolhidos. Como a tecnologia usada para os SDI baseados em rede atuam capturando pacotes na rede, estes devem ser analisados e processados rapidamente, para que não se perca nenhum dos pacotes e para que uma ação possa ser disparada em tempo hábil, ou seja, não adiante tentar bloquear uma conexão depois que o invasor já conseguiu informações vitais, como por exemplo, um arquivo de senhas. Todas as técnicas apresentadas acima envolvem uma fase em que é preciso ensinar ao sistema aquilo que queremos que ele reconheça. Independentemente se para ensinar usamos condicionamento (apresentamos os dados repetidamente até o software fixar um padrão) ou experiência (em que o software aprende separando dados em grupos com características semelhantes), o aprendizado deve ser muito rápido. Facilidade de Reconfiguração: A área de Segurança da Informação é hoje em dia uma das que mais rapidamente se modifica. Várias vulnerabilidades são identificadas e apresentadas a cada dia. Para que um Sistema de Detecção de Intrusão esteja sempre atualizado com as mais novas técnicas usadas pelos invasores, ele precisa ser facilmente reconfigurável. Para isso, seria dsejável que o sistema fosse capaz de passar a reconhecer os novos padrões sem esquecer aquilo que ele já conhece. Em algumas dessas técnicas de Inteligência computacional, o sistema teria que ser totalmente retreinado, incluindo tudo aquilo que ele já conhecia. Um sistema ideal seria aquele que fossem apresentados os novos padrões, e a partir daí, com um rapido retreinamento o sistema já estivesse preparado para as novas invasões. Possiblidade de Implementação em Agentes: A implementação de um SDI usando agentes de software é hoje uma tendência. Consultando as Referências Bibliográficas deste artigo podemos encontrar vários artigos que mostram essa tendência [BERNARDES, 1999], Uma característica desejável, seria a de que esses agentes fossem dotados de mobilidade, ou seja, que pudessem se locomover no sistema. Como serão dotados de inteligência, o sistema pode ser capaz de identificar

33 uma tentativa de intrusão e mover-se para uma máquina onde ele consiga capturar e analisar as informações com maior rapidez. Para isso, o código deste software deve ser pequeno, para que ele tenha a agilidade exigida nas situações de risco a que ele estará submetido. Esse trabalho deve também atualizar os módulos de inteligência do ACME! e a sua arquitetura, e justificar a escolha feita baseando-se principalmente nos três parâmetros descritos acima. Baseando-se no que foi apresentado, podemos ter um direcionamento da associação que deve ser feita entre o tipo de inteligência e o modelo de detecção de intrusão a serem usados. Redes Neurais, por exemplo são mais indicadas para serem usadas em SDI com modelo de detecção por uso indevido, porque elas tem uma capacidade de generalização inerente. Já os SDI por anomalia, envolvem um certo conhecimento do sistema e necessitam da capacidade de prever uma próxima ação. Redes Bayesianas sâo indicadas para aplicações deste tipo, porque poderiam retornar a probabilidade de que o atacante tomará uma ou outra ação a seguir, antecipando os seus movimentos. 5. CONCLUSÃO Um sistema criado nesses moldes, usando agentes (móveis ou não) e dotado de inteligência para fazer a detecção de intrusão baseando-se no reconhecimento de padrões pode, e deve passar a ser usado em larga escala no mundo conectado de hoje. Aplicações de Comércio Eletrônico podem ter sua segurança melhorada em muitos níveis com um sistema deste tipo, uma vez eles são capazes de dar uma nível de proteção maior, trabalhando junto com outras ferramentas como um firewall, criptografia de dados, conexões seguras e outras mais. REFERÊNCIAS BIBLIOGRÁFICAS [AALBORG] - Aalborg University, Dept. of Computer Science, Denmark. Bayesian Belief Networks. [online] [Citado em 16/03/2000]. Disponível na internet: < [BEASLEY, 2000] - BEASLEY, D., FAQ: comp.ai.genetic part 2/6 (A Guide to Frequently Asked Questions). [online]. [Citado em 23/02/2000]. Disponível na internet: < > [BERNARDES, 1999] - BERNARDES, M.C. Avaliação do uso de agentes móveis em segurança computacional. São Carlos: ICMC/USP, p. (Dissertação de Mestrado). Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo. [BONIFÁCIO, 1998] - BONIFÁCIO Jr., J.M. Sistemas de segurança distribuído: integração de firewalls com sistemas de detecção de intrusão. São Carlos : ICMC/USP, P. (Dissertação de Mestrado). Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo. [BONIFÁCIO Jr. et. al., 1998a] - BONIFÁCIO Jr., J.M., CANSIAN, A.M., CARVALHO, A.C.P.L., MOREIRA, E.S. Neural networks applied in intrusion detection systems. In: IEEE International Joint Conference on Neural Networks - IJCNN '98. Proceedings... Anchorage, Alaska : IEEE, P. [CANSIAN et al., 1997a] - CANSIAN, A.M., MOREIRA, E.M., CARVALHO, A.C.P.L., BONIFÁCIO Jr., J.M. Network intrusion detection using neural networks. In: International Conference on Computational Inteligence and Multimedia Applications, ICCIMA 97. Proceedings... Gold Coast, Australia : p [CANSIAN et al., 1997b] - CANSIAN, A.M., MOREIRA, E.M., MOURO, R.B., MORISHITA, F.T., CARVALHO, A.C.P.L. An adaptative system for detecting intrusion in networks. In: International Congress on Information Engineering, III. Proceedings... Buenos Aires, Argentina : p [CANSIAN et al., 1997c] - CANSIAN, A.M., MOREIRA, E.M., CARVALHO, A.C.P.L., BONIFÁCIO Jr., J.M. Um modelo adaptativo para detecção de comportamento suspeito em redes de computadores. In: Brazilian Symposium on Computer Networks, SBRC'97, XV. Proceedings... São Carlos : SBRC, p [CARVALHO et al., 1999] - BRAGA, A.P., CARVALHO, A.P.L.F., LUDERMIR, T.B. Redes neurais artificiais : teoria e aplicações. 250p. (no prelo). [CROSBIE & SPAFFORD, 1995a] - CROSBIE, M., SPAFFORD, E.H. Defending a computer system using autonomous agents. [online]. [Citado em 15/02/2000]. Department of Computer Sciences, Purdue University, (Relatório Técnico CSD-TR ; Coast TR 95-02). Disponível na internet : < [FILHO, 1997] - Elson Felix Mendes Filho. Algoritmos Genéticos. LABIC-ICMC, USP São Carlos, Brasil. [online]. [Citado em 23/02/2000]. Disponívle na internet: < [JENSEN ] - JENSEN, F.V., A Brief Overview of the Three Main Paradigms of Expert Systems. Dept. of Computer Science, Aalborg University, Denmark. [online] [Citado em 16/03/2000]. Disponível na internet:

34 < ml>. [MOSCATO, 1998] - MOSCATO, P., Memetic Algorithm s Home Page. [online] [Citado em 14/03/2000] Disponível na internet. < me.html> [MOSCATO & NORMAN, 1992] - MOSCATO, P., NORMAN, M.G. A memetic approach for the travelling salesman problem implementation of a computational ecology for combinatorial optimisation on message-passing systems. In : International Conference on Parallel Computing and trasputer Applications. Proceedings... Amsterdam : IOS Press, [PRECHELT, 1995] - PRECHELT, L. FAQ in comp.ai.neural-nets. [online]. [Citado em 23/02/2000]. Disponível na internet: < > [REGGIANI, 2000] REGGIANI, L. Agentes Neurais Prevêem Desastres?. Info Exame, maio p [SOBIREY, 2000] - SOBIREY, M. Michael Sobirey's Intrusion Detection Systems page. [online]. [Citado em 12/04/2000]. Disponível na internet: [SPAFFORD et al., 1998] - SPAFFORD, E., BALASUBRAMANIYAN, J.S., FERNANDEZ, J.O.G., ISACOFF, D., ZAMBONI, D. An architecture for intrusion detection using autonomous agents (COAST Technical Report 98/05).

35 ANÁLISE DE SEGURANÇA DO ACESSO REMOTO VPN Emilio Tissato Nakamura Instituto de Computação Universidade Estadual de Campinas CP Campinas-SP Paulo Lício de Geus Instituto de Computação Universidade Estadual de Campinas CP Campinas-SP (19) RESUMO As redes privadas virtuais (Virtual Private Network VPN) possuem uma importância cada vez maior para os negócios das organizações, porém possuem sérias implicações de segurança. O acesso remoto VPN, onde o cliente pode acessar as informações remotamente através de um software cliente, possui implicações de segurança específicas que precisam ser consideradas, onde a principal delas é a possibilidade de utilizar o cliente como uma ponte entre a Internet e a rede da organização. Este artigo visa analisar as possibilidades de ataques que podem ser exploradas contra os clientes VPN, e apresenta algumas sugestões de defesa contra esses riscos. ABSTRACT The importance of Virtual Private Network (VPN) to organizations businesses has been steadily increasing despite its serious security implications. The remote access VPN, which may be used to provide information access remotely through a client software, has specific security concerns that need to be considered. The main problem is the possibility to use the client as a bridge between the Internet and the organization network. This paper presents an analysis of possible attacks against the VPN clients and presents some defense suggestions against those risks. 1 INTRODUÇÃO O ambiente cooperativo pode ser caracterizado pelo alto nível de conectividade entre as organizações, onde a necessidade cada vez maior de segurança implica na utilização de diversas tecnologias, sejam elas para permitir a continuidade dos negócios, ou para prover a segurança necessária para essas conexões. Além disso, a VPN possui também importantes aspectos econômicos, principalmente com relação à desnecessidade de se manter uma infra-estrutura de comunicação própria. No caso do acesso remoto VPN, não é mais necessário que a própria organização mantenha a sua estrutura de acesso remoto, já que os usuários passam a utilizar os provedores de acesso, ao invés de discarem para a própria organização. As redes privadas virtuais (Virtual Private Network VPN) constituem uma das tecnologias que possibilitam, além da economia com os custos de comunicação, que essa comunicação seja realizada com segurança. A efetividade da segurança porém é colocada sob questionamento, uma vez que o backbone da comunicação é uma rede pública, e o que está em jogo são as informações e os recursos da organização. Este artigo tem como objetivo analisar as possibilidades de ataques contra as organizações que podem ser realizadas quando o acesso remoto VPN é utilizado, e apresentar as sugestões de medidas que podem ser tomadas para que os riscos de ataques sejam minimizados. ORGANIZAÇÃO INTERNET PARCEIRO 2 O ACESSO REMOTO VPN A VPN possibilita a conectividade em níveis globais a custos relativamente baixos, permitindo assim que as comunicações das organizações sejam realizadas de modo a tornar possível a adoção de um modelo de negócio mais rápido e mais dinâmico. Fig. 1 Acessos à organização via VPN, que utiliza uma rede pública como a Internet, eliminando a necessidade de uma conexão dedicada ou de uma estrutura de acesso remoto. O acesso remoto VPN possui a vantagem de poder ser utilizado pelos clientes ou pelos pequenos parceiros que ainda não possuem uma conexão direta com a Internet, e que portanto necessitam utilizar os provedores de acesso. Além desses

36 usuários externos, existe ainda o grande número de funcionários que trabalham de suas próprias residências, e de telecommuters, que estão sempre viajando e possuem pontos de conexões diferentes a cada momento. O acesso remoto VPN objetiva solucionar os problemas de conexões desses usuários, e devido ao seu grande potencial de uso, a sua importância para o mundo atual é bastante grande. O tunelamento criação do túnel virtual entre o cliente, nesse caso, e a rede da organização é iniciado a partir de um software cliente instalado no equipamento do usuário. Outros tipos de VPN, como os que conectam redes diferentes (gateways VPN), não serão considerados neste artigo. 2.1 Como Funciona O software cliente na qual se baseou a análise funciona da seguinte maneira, lembrando que as outras soluções de acesso remoto VPN funcionam de modo similar: o usuário precisa instalar em seu equipamento um software, o cliente VPN, que é o responsável pela inicialização do tunelamento, que é baseado no IP Security (IPSec). A configuração desse software é feita através de um arquivo que contém todos os parâmetros de tunelamento necessários, que deve ser importado para o software mediante a utilização de uma chave simétrica. Essa chave e o arquivo de configuração são gerados pela entidade certificadora, e a chave simétrica utilizada no processo de importação aumenta o nível de segurança do processo, ao evitar que o arquivo de configuração seja capturado e utilizado indiscriminadamente. A segurança desse processo será analisada posteriormente. Resumidamente, os passos do funcionamento do acesso remoto VPN são: 1. O usuário instala o software cliente; 2. A entidade certificadora gera um arquivo contendo os parâmetros necessários para a conexão IPSec, entre eles o certificado digital, a chave assimétrica e os algoritmos criptográficos a serem utilizados; 3. A entidade certificadora gera uma chave simétrica que deve ser utilizada pelo usuário para a importação do arquivo de parâmetros no software cliente; 4. O usuário deve configurar o software cliente através da importação do arquivo de parâmetros utilizando a chave simétrica, gerados pela entidade certificadora; 5. O usuário recebe o arquivo de parâmetros e a chave simétrica; 6. O usuário utiliza a chave simétrica para importar o arquivo de parâmetros; 7. O usuário configura o software cliente através da importação do arquivo de parâmetros, e assim está apto a iniciar um tunelamento IPSec para a rede da organização; 8. A conexão IPSec é negociada entre o usuário e a rede da organização de acordo com os parâmetros do usuário e do servidor, que possui uma lista dos recursos que cada usuário pode acessar. Um ponto interessante é que, uma vez configurado o software cliente VPN, através da importação dos parâmetros do túnel IPSec, a autenticação é feita baseada no equipamento, e não necessariamente no usuário. Isso cria algumas aberturas na segurança da rede da organização, como será visto adiante. 3 A SEGURANÇA DO ACESSO REMOTO VPN Ataques do tipo Denial of Service (DoS) certamente são um grande fardo que podem resultar em grandes prejuízos. Porém, nesta análise o enfoque está em garantir a segurança da rede interna da organização, ou seja, garantir que o uso do acesso remoto VPN não resulte em uma brecha de segurança e conseqüentes quebras de confidencialidade ou de integridade dos recursos da organização. O enfoque da análise será dado em cima desta possibilidade, em pontos que incluem o protocolo IPSec, as configurações do software cliente, a possibilidade do cliente ser utilizado como ponte para a rede da organização, o compartilhamento de arquivos do Windows e a utilização de modems. É sabido, contudo, que ataques DoS são muitas vezes armados como parte de um ataque ativo a um recurso. 3.1 IPSec A segurança da conexão é baseada fundamentalmente no IPSec, que é reconhecidamente um protocolo seguro, e padrão de facto das VPNs. A autenticação do cliente, a autenticação do servidor e a confidencialidade e integridade dos dados são providas por esse protocolo e pelos algoritmos criptográficos negociados pelo mesmo. Porém, não se deve esquecer que o fato de um protocolo ser seguro não garante a segurança do sistema, já que essa segurança depende da correta implementação do protocolo. Diversos casos de erros na implementação que comprometiam a segurança foram descobertos, principalmente em algoritmos criptográficos. Portanto, uma falha na implementação do IPSec pode comprometer o sistema, e deve ser verificado através de insistentes testes e análises de todas as possibilidades de conexões possíveis. Mesmo a implementação e o projeto do cliente VPN podem ter problemas que podem comprometer totalmente a segurança. Ataques teóricos contra o IPSec foram demonstrados em [BEL 97], porém implementar

37 essas técnicas seria bastante improvável, devido à complexidade dos cenários necessários, que exigem análise constante e rápida de todos os pacotes da conexão. 3.2 Segurança do Certificado Digital e da Chave Assimétrica Foi visto que o certificado digital e a chave assimétrica, além dos parâmetros necessários para a criação do túnel IPSec, são armazenados em um arquivo, que deve ser importado pelo cliente. Os riscos existentes com relação à apropriação indevida do certificado digital e da chave assimétrica estão relacionados com a captura desse arquivo de configuração da VPN, e também com o uso não autorizado ou com o roubo do equipamento do usuário. Esses riscos serão vistos a seguir Capturando o Arquivo de Configuração da VPN Um ataque visando a captura do arquivo de configuração não surtiria efeito, pois para que ele possa ser utilizado, é necessário utilizar uma chave simétrica para importá-lo no software cliente do usuário. Assim, o ataque teria sucesso apenas se o hacker capturar também a chave de importação do arquivo. Essa abordagem, de tornar imprescindível a utilização de dois elementos (arquivo de configuração e chave de importação), aumenta o nível de segurança do esquema, já que é mais difícil o hacker obter esses dois elementos distintos que se relacionam entre si. A grande questão está no modo em que esses elementos são enviados ao cliente. É essencial que um canal seguro seja utilizado para a transferência do arquivo de configuração e da chave de importação. Caso não seja possível utilizar um canal seguro, o nível de segurança do processo de transferência pode ser incrementado utilizando-se dois canais diferentes, como por exemplo, o telefone e o , um para a transferência do arquivo de configuração, e o outro para a transferência da chave de importação Roubo ou Utilização Indevida do Equipamento do Usuário Uma outra possibilidade é o roubo do equipamento do usuário. Roubando-se o equipamento, o acesso à rede interna torna-se praticamente automático, pois o software cliente já está apropriadamente configurado para o seu uso. Essa é uma possibilidade que deve ser analisada com cuidado, já que tem sido observado um aumento significativo na criminalidade envolvendo roubos de notebooks. Além disso, ainda é possível roubar o disco rígido de desktops de maneira relativamente simples. Alguns equipamentos possuem até mesmo uma gaveta removível para o posicionamento do disco rígido, tornando assim mais fácil a ação de quem tem a intenção de roubá-lo. Outra oportunidade perigosa ocorre quando um equipamento contendo o software cliente VPN é enviado para a assistência técnica. É possível recuperar e copiar diversos tipos de informações desse equipamento, o que pode comprometer a segurança do sistema. O que também pode ocorrer com o cliente VPN é alguém usar o equipamento emprestado em momentos de ausência do dono para fazer a conexão VPN. Esses problemas podem ser minimizados de uma maneira simples, através da utilização de uma senha de acesso no software cliente VPN. O seu nível de segurança, no entanto, depende do método de armazenamento da senha e do algoritmo criptográfico utilizado pelo software. Uma análise com relação a isso é importante, pois diversos casos de senhas fáceis de serem descobertas já foram relatados, como são os casos das utilizadas em documentos do Word ou do Excel, e até mesmo das senhas de login da rede Microsoft e dos protetores de tela. Além dos problemas com os algoritmos, diversos métodos de recuperação de senhas são conhecidos. Um desses métodos pode ser visto em [SHA 98], onde são descritos sofisticados ataques algébricos e estatísticos utilizados para localizar chaves de criptografia escondidas em uma grande string ou em grandes arquivos. 3.3 Uma Possibilidade Perigosa Cliente VPN como Gateway Uma característica que abre um grande leque de possibilidades de ataques é a utilização do cliente VPN como um gateway entre a Internet e a rede interna. Isso pode ocorrer porque o equipamento do usuário passa a ter duas conexões, uma com a Internet e outra, via tunelamento IPSec, com a rede da organização. Deste modo, o hacker pode utilizar uma conexão (Internet) para passar para a outra (túnel IPSec), alcançando assim a rede da organização. O nível de segurança envolvido aqui é portanto bastante preocupante, já que o cliente está disponível (porém não aberto) a todo o universo da Internet. Essa ponte pode ser caracterizada porque o cliente VPN age sobre a pilha TCP/IP do cliente, de modo que todo pacote endereçado à rede da organização é transformado em um pacote IPSec, que são pacotes válidos e autenticados. Será analisada a seguir como isso é possível, e se um ataque dessa natureza pode mesmo ser

38 utilizado contra a organização. Será visto que é necessário que o hacker seja capaz de rotear pacotes através desse cliente VPN, ou que ele tenha o controle sobre essa máquina, seja ele fisicamente, através de vírus ou cavalos-de-tróia, ou ainda através de ataques para dominá-la. ORGANIZAÇÃO INTERNET Hacker Cliente VPN Túnel IPSec Ponte através do cliente VPN Fig. 2 Utilizando o cliente VPN como uma ponte entre a Internet e a rede da organização Roteamento de Pacotes através do Cliente VPN Um dos métodos para fazer com que o cliente VPN atue como um gateway entre a Internet e a rede da organização é através do roteamento de pacotes por esse cliente. Caso esse cliente possua a capacidade de roteamento, então um hacker pode enviar pacotes para o cliente da Internet, que por sua vez rotearia esses pacotes para a rede da organização. A capacidade de roteamento depende do sistema operacional em uso pelo cliente. Pode-se afirmar que os usuários que utilizam o Windows 9x ou o Windows NT Workstation estão imunes a esse tipo de ataque, pois esses sistemas operacionais não possuem essa capacidade. O mesmo não se pode dizer daqueles que utilizam o Windows NT Server, o Linux ou os sabores de Unix em geral, que são capazes de rotear pacotes. Porém, pela lógica, esses clientes não devem rotear pacotes para a rede interna da organização, ou seja, rotas padrões para a rede interna devem ser evitadas a todo custo. Portanto, primeiramente uma rota com destino à rede interna da organização deve ser incluída, o que pode ser considerado difícil, porém possível mediante um ataque a esse equipamento. Uma possibilidade de forçar o roteamento é a utilização de uma funcionalidade do TCP/IP, o source routing. Através dele é possível criar pacotes com informações de roteamento, ou seja, é possível enviar um pacote para o equipamento do cliente VPN com informações sobre qual rota esse pacote deve seguir, que nesse caso seria para a rede da organização. Essa é uma funcionalidade com enormes implicações de segurança, já que permite que um hacker envie pacotes com informações de roteamento para qualquer destino desejado, sendo que essa rota normalmente seria proibida. Além disso, o source routing é utilizado também para que firewalls sejam driblados, e para que uma rota de retorno dos pacotes seja definida, o que pode ser utilizado em ataques mais sofisticados, que dependem de uma resposta da vítima, e que são geralmente utilizados em conjunto com o IP Spoofing. Um ponto com relação ao source routing é que essa funcionalidade pode ser utilizada tanto por hosts roteadores quanto por hosts que não atuam como roteadores. Por isso a preocupação que se deve ter também com o Windows NT Workstation e com o Windows 9x [MIC 99-4]. No Windows NT essa opção não podia ser desabilitada, o que é possível somente agora, através do Service Pack 5 [MIC 99-1]. Mesmo assim, foi descoberto uma vulnerabilidade no Windows que permitia a utilização do source routing, mesmo ela estando desabilitada [NAI 99]. O patch de correção da vulnerabilidade está disponível, menos para o Windows 9x e o Windows NT 4.0 Server, Terminal Server Edition [MIC 99-2] Ataques ao Sistema Operacional, aos Aplicativos e aos Serviços Uma outra possibilidade de invadir a rede interna é através do controle da máquina do usuário. Existem diversos ataques conhecidos que tiram proveito de falhas nos sistemas operacionais, nos aplicativos ou nos serviços. Uma dessas inúmeras falhas poderia ser utilizada para que o hacker assumisse o controle da máquina ou roubasse arquivos que seriam utilizados no ataque à rede interna. Esse mesmo tipo de ataque poderia ainda ser utilizado para se alterar tabelas de roteamento, que teve a sua possibilidade descrita na seção anterior. Geralmente o Windows 9x e o Windows NT Workstation não disponibilizam muitos serviços, e portanto são menos susceptíveis a ataques. Um port scanning revelou as seguintes portas abertas nos sistemas operacionais da Microsoft em uma instalação padrão:

39 Windows 9x porta 139; Windows NT Workstation portas 135 e 139; Windows NT Server (funcionando como servidor proxy) portas 7, 9, 13, 17, 19, 135, 139, As portas 135 e 139 podem ser exploradas para ataques do tipo DoS, que é o único método de ataque possível conhecido para essas portas. Com isso, pode-se considerar que máquinas com Windows 9x ou Windows NT Workstation em sua instalação típica, sem nenhum serviço adicional e, principalmente, sem estar contaminado com um vírus ou cavalo-de-tróia, possuem menores chances de serem explorados em um ataque do que o Linux, o Unix ou o Windows NT Server Vírus e Cavalos-de-Tróia Os vírus e os cavalos-de-tróia são uma das maiores ameaças ao esquema de segurança da VPN. Esse pode ser considerado o ponto mais crítico dentro do sistema de segurança do acesso remoto VPN, já que os usuários (o elo mais fraco da segurança de uma organização) podem contaminar seus próprios equipamentos através da execução de programas maliciosos, que geralmente adotam doses de engenharia social, como a que se iniciou com o vírus Melissa, que induzia o usuário a abrir o contaminado. Um cavalo-de-tróia instalado, combinado com a possibilidade de existência da conexão com a Internet e com o túnel VPN, torna possível o mais perigoso dos ataques contra a rede interna da organização, já que o hacker pode ter acesso a todos os dados da rede interna da organização acessíveis através da VPN. Mesmo a necessidade de uma chave para a inicialização do túnel perde a sua efetividade, já que um cavalo-de-tróia, como o Back Orifice, pode capturar tudo o que o usuário digita, além de ser possível ainda capturar a tela do usuário. 3.4 Problemas com Compartilhamento de Arquivos do Windows Um outro ponto a ser considerado são os compartilhamentos de arquivos do Windows. Uma configuração equivocada do sistema operacional pode permitir que seus arquivos sejam acessíveis não apenas pelos demais equipamentos da sua rede, mas também pela Internet (através da opção NetBEUI over TCP/IP). Com isso, as informações residentes na máquina do cliente podem ficar disponíveis através desse compartilhamento. Essas informações podem ser confidenciais, tendo sido armazenadas no equipamento do cliente depois de uma conexão segura através de IPSec. 3.5 Problemas com Modems O perigo dos modems foi analisado por Brian McWilliams em [McW 97], onde foi utilizado a técnica de war dialing. Através dele, é possível discar para diversos números de telefones em busca de conexões abertas, que podem servir de ponto de entrada para sistemas de computadores ou de telecomunicações. Caso um equipamento com o software cliente VPN responda a uma dessas chamadas, ele pode ser explorado para que uma conexão à rede da organização seja iniciada. 4 SOLUÇÕES Foi visto que os problemas de segurança aparecem principalmente devido à existência de duas conexões no cliente, uma com a Internet e outra, via túnel IPSec, com a rede da organização. Outros problemas são a segurança do certificado digital armazenado no equipamento do cliente, a possibilidade de ataques através de vírus e cavalosde-tróia, o compartilhamento de arquivos do Windows, e a utilização indiscriminada de modems. Todas essas possibilidades de ataques podem ser minimizadas através de uma boa política de segurança. É esse o principal elemento de um sistema de segurança, e é através da sua correta implementação e gerenciamento que muitos dos problemas podem ser eliminados. Além da política de segurança bem definida, uma defesa mais ativa também deve ser utilizada, como por exemplo, a utilização de port scannings ou de firewalls individuais nos clientes, como serão discutidas nas próximas seções. O papel do firewall dentro do esquema de acesso remoto VPN também é discutido brevemente. 4.1 Firewall O firewall é um elemento essencial na arquitetura de segurança de qualquer organização. Ele é essencial porque atua na borda da rede da organização, realizando um controle de acesso onde apenas os usuários legítimos podem atravessar essa barreira. Na solução que inclui não somente o acesso remoto VPN, mas a VPN em geral, o firewall tem a função de aceitar somente os pacotes relativos aos serviços disponíveis (internamente e externamente), e os pacotes IPSec relativos à VPN. A autenticação dos usuários é baseada no IPSec, e como o posicionamento do gateway IPSec com relação ao firewall é um tópico extenso e complexo, ele não será analisado neste artigo. 4.2 Política de Segurança

40 A política de segurança é fundamental para todas as organizações, e deve tratar de diversos aspectos técnicos, operacionais e organizacionais. Alguns dos aspectos que devem ser tratados pela política de segurança, com relação ao acesso remoto VPN, são: Segurança física, como por exemplo, o estabelecimento de regras para o acesso aos equipamentos, que evitam que eles sejam roubados ou sejam acessados temporariamente de modo indevido; Procedimentos em caso de roubo ou perda. Caso um notebook seja roubado, por exemplo, esse roubo deve ser notificado imediatamente, de modo que o seu certificado digital seja revogado nesse mesmo instante; Utilização de senha no protetor de tela para evitar que terceiros utilizem o equipamento em horários oportunos, como a hora do almoço, para ter o acesso à rede da organização via túnel IPSec. Procedimentos a serem tomados em caso de envio do equipamento à assistência técnica também devem ser bem descritos, para se evitar a cópia dos dados do disco rígido; Definição de quais serviços podem rodar nesses equipamentos. Foi visto que cada serviço funciona como uma porta de entrada que o hacker pode explorar para a realização de um ataque. Quanto menos portas abertas existirem, menores as possibilidades de ataques. Serviços não essenciais devem ser portanto desabilitados; Uma política de atualização dos sistemas operacionais/aplicativos/serviços é essencial, já que são essas atualizações que trazem soluções para bugs e vulnerabilidades que podem ser explorados pelos hackers; Procedimento para as conexões VPN. Uma das regras necessárias é desconectar o cabo de rede no momento da conexão VPN, caso esse equipamento faça parte de uma outra rede. Na realidade, essa prática deve ser utilizada sempre que um modem é utilizado, para evitar que alguém da Internet tenha acesso aos outros pontos dessa rede. No esquema do acesso remoto VPN, a desconexão do cabo de rede evita também que outros usuários da mesma rede desse cliente consigam entrar na rede interna da organização via VPN; Uma política de prevenção contra vírus e cavalosde-tróia é essencial, tanto com relação à educação dos usuários, que precisam saber quais tipos de arquivos podem ser abertos e executados em seu equipamento, quanto para a utilização e atualização dos anti-vírus; Política de utilização de modems, principalmente não deixar o modem em espera, já que uma conexão externa pode comprometer não apenas a segurança da VPN, mas também da própria rede da organização; Política que trata do roteamento, que determina quais máquinas trabalham como roteadores ou se existe mesmo a necessidade de deixar a opção de source routing habilitada, o que é uma situação extremamente rara. A política de segurança é assim imprescindível para a organização. Porém, no caso do acesso remoto VPN, uma série de complicações vem à tona Como implantar uma política de segurança em equipamentos de terceiros, que geralmente são utilizados também para outros fins? Como controlar, por exemplo, o equipamento de um revendedor que é utilizado para controle das vendas, acesso à Internet e leitura de s, além da conexão VPN? Como exigir que uma política de segurança seja seguida por esse usuário? Como garantir que essa política estará sendo seguida? Essa política poderia ser mais facilmente implementada caso os equipamentos pertencessem à própria organização que disponibiliza o serviço, já que permitiria um controle mais refinado do equipamento, podendo-se controlar o que o usuário pode instalar, o que o usuário pode acessar, o que o usuário pode apagar, etc. Porém, essa não é uma situação que pode ser considerada normal, sendo portanto necessário grandes esforços adicionais, como um acompanhamento eficiente e uma auditoria constante. Além disso, medidas mais proativas também devem ser adotadas. Elas auxiliam na segurança da solução, e algumas delas serão apresentadas a seguir. 4.3 Sem Acesso Simultâneo com a Internet e com a VPN Foi visto que as possibilidades de ataques mais concretas são devidas ao fato do cliente VPN possuir uma conexão direta com a Internet e outra com a organização, via túnel VPN. A utilização do cliente VPN como gateway depende do source routing, portanto essa opção deve ser imediatamente desabilitada. Essa medida porém não elimina os riscos com os vírus e cavalosde-tróia, que devem ser combatidos de outra forma, principalmente através de uma política de segurança eficiente. Os riscos podem ser eliminados se o cliente aceitar somente conexões IPSec. Isso eliminaria os

41 riscos de ataques ao sistema operacional/aplicativos/serviços do cliente, além de tornar a conexão VPN segura mesmo se o cliente VPN estiver contaminado com um vírus ou cavalode-tróia, já que os comandos enviados ao equipamento contaminado seriam todos descartados. Mesmo se alguém conseguir enviar pacotes IPSec ao equipamento, os certificados digitais serão sempre verificados, e como o cliente VPN não troca certificados com o hacker, essa conexão não será permitida. Portanto, caso o cliente VPN possua essa opção de aceitar somente conexões IPSec, ela deve ser habilitada. Porém, o que se tem observado é que essa possibilidade não é implementada nos clientes VPN, principalmente devido à complexidade envolvida quando uma conexão PPP discada é utilizada. Uma alternativa poderia ser configurar o cliente VPN para que ele envie todos os seus pacotes somente através desse túnel IPSec, ou seja, todos os pacotes que são enviados através de seu modem devem ser transformados em pacotes IPSec para a rede da organização. Isso faria com que um hacker da Internet consiga enviar pacotes ou comandos para o cliente VPN, porém ele não receberia de volta os pacotes de resposta, que seriam enviados à rede da organização, em vez de serem enviados ao hacker. Assim, o hacker não teria acesso a nenhuma informação da organização. Essa solução pode funcionar, porém com o custo de maior tráfego na rede da organização, e a possibilidade de ataques DoS. Do ponto de vista do usuário, a sua largura de banda com o provedor seria esgotado, e do ponto de vista da rede da organização, seu canal com a Internet poderia ser comprometido caso haja um ataque coordenado, onde diversos clientes VPN enviam ao mesmo tempo uma quantidade muito grande de pacotes para a rede da organização. Assim a rede da organização ficaria inacessível, o que resultaria em prejuízos. Essa situação pode ainda provocar uma possibilidade mais séria, onde o hacker poderia criar pacotes com comandos maliciosos que seriam enviados automaticamente para a rede da organização via o cliente VPN. O hacker seria impossibilitado de obter respostas, porém a rede da organização poderia passar a negar serviços legítimos (ataque DoS). Uma solução mais simples é através da alteração da tabela de roteamento do cliente. A idéia aqui é a de eliminar o roteamento padrão (default gateway), que é inserido na tabela no momento da conexão do cliente com o provedor, e inserir apenas duas rotas: uma para o provedor, enviando os pacotes através da conexão PPP, e outra para o gateway VPN, enviando os pacotes para o provedor. Desta forma, o cliente seria capaz de enviar pacotes apenas para o provedor e para o gateway VPN, passando por esse provedor. O envio de pacotes para outros destinos não seria possível apenas com essas duas rotas. Os problemas envolvidos na alternativa anterior, onde o hacker teria a chance de enviar pacotes maliciosos para o cliente, causando negação de serviços, ainda é válido para este caso. Ele apenas não é capaz de obter respostas a esses pacotes. 4.4 Port Scannings Através da utilização de port scannings (varredura de portas TCP/IP) nos clientes VPN é possível verificar quais serviços estão rodando nos respectivos equipamentos, além de ser possível determinar também se ele está ou não contaminado com determinados vírus ou cavalos-de-tróia. Assim, caso uma contaminação ou serviços indevidos ou desnecessários sejam detectados, as devidas providências podem ser tomadas. O port scanning poderia ser um requerimento para o estabelecimento de uma conexão VPN entre o cliente e a rede da organização. Uma regra que poderia ser utilizada é que a conexão só seja efetivada depois de uma varredura. Outra regra poderia ser que a varredura seja executada periodicamente, dependendo da política de segurança da organização. Além do port scanning, que verifica as portas abertas, o scanning de vulnerabilidades também poderia ser utilizado, de acordo com as necessidades. Isso minimizaria as possibilidades de ataques, já que vulnerabilidades de sistemas operacionais, aplicativos e serviços seriam detectados e corrigidos, teoricamente, antes que os hackers mais comuns tirassem proveitos deles. A dificuldade em se adotar essa prática está no processo de execução das varreduras, já que os endereços IPs dos clientes são dinâmicos. Varreduras em sistemas não autorizados podem resultar em diversos problemas éticos e legais, e por isso ele deve ser feito com extremo cuidado, e apenas em equipamentos nos quais se tenha a certeza que estão se conectando à rede da organização. 4.5 Firewall Individual A utilização do firewall individual pode minimizar grande parte dos problemas de segurança. Esse tipo de firewall atua na camada de enlace de dados do equipamento do usuário, e filtra pacotes IP (TCP, UDP, ICMP), e outros como o NetBEUI, IPX, ARP. Através dele é possível controlar acessos aos recursos, monitorar todo o tráfego gerado ou que chega ao sistema, gerar regras de acordo com uma aplicação específica que

42 está funcionando, e gerar registros de todos os acessos do sistema [SIG 99]. É possível criar regras de acordo com as seguintes características [SIG 99]: Quando um aplicativo específico está funcionando; Em determinado dispositivo Ethernet ou serial; Quando um número de telefone específico é utilizado; Para serviços, arquivos ou compartilhamentos específicos; Para endereços IPs específicos; Para direção de fluxo dos pacotes; Para usuários específicos; Para conexões VPN ou conexões discadas. Assim, através de um firewall individual é possível obter um controle sobre as conexões do cliente, de modo que uma política poderia definir a exigência de sua utilização. Isso eliminaria os problemas com cavalos-de-tróia, que poderiam ainda infectar o cliente. Porém o cliente não poderia ser controlado através dos comandos, que não chegariam a ele, já que eles seriam bloquados pelo firewall individual. Os problemas envolvendo o roteamento através do cliente também poderia ser contornado. Porém, não se deve esquecer que um vírus sempre pode reescrever essas regras do firewall individual, mesmo que isso exija um trabalho extra para o atacante. Além disso, basta que a solução fique conhecida para que ela passe a se tornar também alvos dos atacantes. Isso reforça novamente a importância de uma política de segurança bem definida. CONCLUSÃO O uso de VPNs é essencial para as organizações, por possibilitar as conexões entre seus clientes, fornecedores, parceiros e funcionários. Sua importância cresce porque a sua implantação é simples e o retorno econômico é grande. Porém, as implicações de segurança que aparecem quando se utiliza uma rede pública, como a Internet, são bastante relevantes, e incluem ainda a utilização de um firewall. Além dos cuidados com possíveis problemas na implementação do IPSec, do cliente VPN e no projeto da VPN, uma política de segurança bem definida para os clientes que forem utilizar a VPN é essencial. Os problemas de segurança que podem existir são de natureza física (roubo do equipamento ou acesso físico a esse equipamento) e principalmente quanto à possibilidade de conexões múltiplas (com a Internet e com o túnel VPN), que podem tornar esse cliente um gateway entre a Internet e a rede interna da organização. Roteamento, vírus e cavalos-de-tróia são os elementos envolvidos nessas conexões múltiplas, que incluem ainda o source routing, relacionado com o roteamento. O uso de ports scannings e scannings de vulnerabilidades regulares realizam uma auditoria de quem deseja se conectar à rede via VPN, de modo que serviços desnecessários, equipamentos contaminados com vírus ou cavalos-de-tróia, e vulnerabilidades possam ser identificados. O firewall individual incrementa o nível de segurança do sistema ao atuar na camada de enlace de dados e permitir a criação de diversas regras que impedem a atuação de vírus, cavalos-de-tróia e a utilização do cliente como um gateway. Assim, o acesso remoto VPN traz uma série de benefícios à organização e a seus usuários, porém incrementa as implicações de segurança na rede da organização. Abrir a rede interna para esses usuários requer que os cuidados citados acima sejam tomados para se evitar problemas maiores, que podem aparecer posteriormente. Os problemas discutidos são pertinentes a um ambiente cooperativo, principalmente devido à sua conexão com a Internet. Os ambientes cooperativos são um fato no mundo atual, onde a competitividade global exige novas soluções em seus processos de negócios. E essas novas soluções necessitam de segurança suficiente para que elas sejam justificáveis. REFERÊNCIAS BIBLIOGRÁFICAS [BAY 98] Bay Networks. Understanding and Implementing Virtual Private Networking (VPN) Services. Papers/2746.html. 29/01/99. [BEL 97] BELLOVIN, Steven M. Probable Plaintext Cryptanalysis of the IP Security Protocols. AT&T Labs Research. Florham Park, NJ, USA: [CHE 98] Check Point Software Technologies Ltd. 04/01/99. [CHE 98-1] Check Point Software Technologies Ltd. Redefining the Virtual Private Network. March 4, [CHE 98-2] Check Point Software Technologies Ltd. Virtual Private Network

43 Security Components A Technical White Paper. March 23, [FOR 98] Forrester Research Inc. 04/01/99. [GAR 98] GARFINKEL Simson L. Advanced Telephone Auditing with PhoneSweep: A Better Alternative to Underground War Dialers /08/99. [ISS 99] ISS Internet Security Systems. ISS X- Force White Paper Back Orifice 2000 Backdoor Program. September 1999.b [SIG 99] [STU 98] SIGNAL 9 SOLUTIONS. ConSeal PC Firewall. 10/08/99. STUTZ, Michael. Wardialer Goes Corporate. October 7, /08/ Oct/ISN-774 [McW 97] McWilliams, Brian. Did You Forget to Lock the Back Door?. PC World News Radio. September 19, /08/99. ta/0997/ html [MIC 99-1] Microsoft Corporation. TCP/IP Source Routing Feature Cannot Be Disabled. 18/08/99. /articles/q217/3/36.asp [MIC 99-2] Microsoft Corporation. Microsoft Security Bulletin (MS99-038) Patch Available for Spoofed Route Pointer Vulnerability. September 20, /09/99. [MIC 99-3] Microsoft Corporation. Data in Route Pointer Field Can Bypass Source Routing Disable. September 20, /09/99. /articles/q238/4/53.asp [MIC 99-4] Microsoft Corporation. Microsoft Security Bulletin (MS99-038): Frequently Asked Questions. September 20, /09/99. etins/ms99-038faq.asp [NAI 99] Network Associates, Inc. Security Advisory Windows IP Source Routing Vulnerability. September 20, /09/ html [SHA 98] SHAMIR, Adi; SOMEREN, Nicko van. Playing Hide and Seek With Stored Keys. September 22, 1998.

44

45 AVALIAÇÃO DA SEGURANÇA DA URNA ELETRÔNICA BRASILEIRA Eng. Amílcar Brunazo Filho Moderador do Fórum do Voto Eletrônico RESUMO Uma polêmica estabeleceu-se sobre a impossibilidade de se conferir a apuração dos votos na urna eletrônica brasileira. Um impasse sobre este tema foi atingido tanto num debate técnico no SSI 99 quanto num debate político no Plenário do Senado Federal do Brasil. Este trabalho faz uma análise deste problema, sugere uma solução e propõe que o voto eletrônico seja tratado como um sistema de alto risco de fraude. ABSTRACT A controversy was settled about the Brazilian Electronic Voting Machine and it s impossibility to grant de poll. A dilemma was reached either in SSI 99 technical debate as in a political debate in Brazilian Federal Senate. This article analyses this subject, offers a solution and proposes that e-vote be treated as high fraud risk system. 1 INTRODUÇÃO Neste ano de 2000 o Brasil torna-se o primeiro país do mundo a fazer uma eleição 100% informatizada em todos os seus níveis, desde o cadastramento dos eleitores até a publicação do resultado final. Mais de 107 milhões de eleitores votarão em 315 mil seções eleitorais para eleger cerca de prefeitos e de 53 mil vereadores. Neste processo a Justiça Eleitoral contará com aproximadamente urnas eletrônicas e com uma Rede de Totalização Privativa de abrangência nacional, interligando 28 computadores de grande porte e milhares de terminais e pontos de acesso. O orçamento previsto para a informatização total do voto no Brasil entre 1996 e 2000 foi de U$ 546,4 milhões (Camarão, 1997, pg. 203). Com um processo informatizado destas dimensões e com esta responsabilidade, a questão da segurança e confiabilidade torna-se complexa e assume importância maior. Seu projeto não deveria ficar relegado a um pequeno grupo de técnicos e merece ser debatido no meio acadêmico, tanto no lado jurídico da questão quanto nos seus aspectos de informática, como já foi proposto no Simpósio de Segurança em Informática, SSI 99. Dando continuidade à idéia de ampliar o debate técnico sobre este tema, apresenta-se a seguir uma análise sobre o processo de validação, certificação, teste e auditoria da apuração dos votos na urna eletrônica brasileira, com a finalidade de esclarecer argumentos em torno da polêmica que ficou evidente na 22ª Reunião Pública Extraordinária da Comissão de Constituição, Justiça e Cidadania do Senado Federal, do dia 01 de Junho de 2000, cuja ata pode ser obtida em (http1), durante o debate que travaram o Ministro Nelson Jobim, do TSE, e o Senador Roberto Requião sobre adeqüabilidade do Projeto de Lei do Senado PLS 194/99 (Requião, 1999, http2), o qual impõe novas regras para a auditoria da apuração nas urnas eletrônicas. Na seção 1.1, deste artigo, é apresentado um glossário dos principais termos e conceitos utilizados, para facilitar a escrita e a compreensão do artigo. Na seção 2 é descrito o PLS 194/99 para destacar o ponto central desta polêmica, que é a impressão do voto como meio de possibilitar a auditoria da apuração eletrônica. Na seção 3 é apresentada a legislação brasileira relacionada com a segurança, auditoria e fiscalização do voto informatizado, ressaltando-se seus pontos fortes e suas lacunas, e comenta-se alguns ângulos jurídicos da questão da impressão do voto. Esta análise do lado jurídico da questão não é aprofundada por escapar do escopo deste Simpósio. Na seção 4 é descrito quais foram os procedimentos de validação, certificação e testes de auditoria das urnas eletrônicas, nas eleições de 1996 e de 1998, para se comparar, na seção 5, com o sugerido pela Norma Técnica Internacional ISO/IEC de Dez/99 (http3), a qual estabelece Critérios de Avaliação da Segurança no âmbito da Tecnologia de Informação. Ao final são apresentas as conclusões. 1.1 Glossário Apresentamos a seguir, a definição de alguns termos que serão usados neste artigo: Apuração dos Votos É o processo de contagem dos votos de cada urna. No caso da urna eletrônica a apuração é feita na própria Seção Eleitoral onde se deu a votação. No caso de urnas tradicionais, a apuração se dá nas Zonas de Apuração. Totalização dos Votos É o processo de contagem dos votos de todas as urnas de todas as seções eleitorais. É feita por programas contidos na Rede de Totalização do TSE, a qual tem terminais de acesso em todos os TRE

46 estaduais e nas sedes das Zonas Eleitorais municipais. Boletim de Urna (BU) É o documento que contém o resultado da apuração de cada urna eletrônica. Por lei, deve ser impresso, publicado na própria seção eleitoral e distribuído aos partidos políticos. Uma versão digitalizada do BU é gravada num disquete magnético para servir de transporte do BU para os terminais de entrada da Rede de Totalização. Programa Básico Trata-se do conjunto autônomo de programas da urna eletrônica posto para funcionar logo que este é ligado. O Programa Básico da urna eletrônica é composto por: Sistema Básico de Entrada e Saída (BIOS), Sistemas Operacional e Gerenciadores de Dispositivos (Device Drivers). Programa Aplicativo Trata-se de programa de computador, não autônomo (precisa que um Sistema Operacional esteja instalado e funcionando), que é o responsável pela recepção e ordenação dos dados originados ou destinados aos equipamentos periféricos. Criptografia São técnicas matemáticas de se embaralhar (cifrar) um conjunto de dados ou textos, com a finalidade de esconder ou tornar incompreensível as informações ali contidas, ou seja, a Criptografia é idealizada para defender a confidencialidade dos dados. As técnicas de criptografia normalmente utilizam dois elementos no seu processo: 1) a fórmula ou algoritmo de ciframento; 2) uma seqüência de números, chamados chave. Para se reconstruir o texto ou dados originais necessita-se conhecer a chave inversa (ou de deciframento ) mais a fórmula ou algoritmo inverso (ou de deciframento ) ao utilizado no ciframento. Assinatura Digital São técnicas matemáticas utilizadas para que se possa saber quem ou que equipamento gerou certo documento e se tal documento não foi adulterado, ou seja, a Assinatura Digital é idealizada para se garantir a integridade dos dados. Estas técnicas normalmente utilizam algumas fórmulas peculiares de criptografia, chamadas de assimétricas ou de Chaves Públicas, onde tanto a fórmula de ciframento, quanto a chave e a fórmula de deciframento são divulgadas para conhecimento público. Apenas a chave usada para ciframento é mantida secreta por aquele que vai fazer a assinatura digital. Assim, qualquer pessoa que conheça os dados públicos pode verificar que tal documento, assinado digitalmente, proveio de determinada pessoa ou equipamento. Sistemas Fechados Diz-se de um sistema criptográfico onde tanto as chaves quanto as fórmulas de criptografia e de deciframento são mantidas em segredo. Um ataque externo à um sistema fechado é dificultado pois não se conhece a fórmula de deciframento. Porém sistemas fechados tem pouca resistência ao ataque de elementos internos (que tiveram acesso à suas fórmulas). Outro problema é que sistemas fechados não podem ser provados como matematicamente seguros. Utilizar um Sistema Fechado de Criptografia implica diretamente em confiar cegamente no fornecedor. Sistemas Abertos Diz-se de um sistema criptográfico onde as fórmulas de criptografia e de deciframento são divulgadas publicamente e apenas as chaves são mantidas em segredo. A vantagem de Sistemas Abertos é que se pode calcular e provar qual o tempo médio que um atacante, que não conheça a chave secreta, terá que gastar para reconstruir o texto original por tentativa e erro. Se este tempo médio for maior (bem maior) que o tempo em que a informação deve permanecer protegida, considera-se o sistema seguro. Um sistema de Assinatura Digital é sempre um Sistema Aberto, por sua própria concepção. Ataque Ação de algum agente, interno ou externo à corporação, com o objetivo de deturpar o funcionamento esperado de um equipamento, programa ou sistema. Ataque Destrutivo Um ataque cujo objetivo é paralisar ou atrasar o funcionamento regular do sistema-alvo, visando reduzir sua disponibilidade para uso (availability) sem, no entanto, construir algum resultado falso. Ataque Dirigido ou Construtivo Um ataque que visa construir, de forma escamoteada, um resultado falso durante o funcionamento do sistema atacado, tentando fazer o resultado falso ser aceito como verdadeiro. Ataque de Força Bruta É o ataque a um sistema de criptografia ou de bloqueio lógico de acesso no qual que tenta descobrir a senha ou a chave por tentativa e erro de todas as combinações possíveis. Quando se fala que existe prova matemática que um dado sistema de segurança resiste a um ataque por tanto tempo, normalmente está se referindo a Ataque de Força Bruta. Assim, esta prova matemática não garante a inviolabilidade do sistema pois outras formas de ataque, que se valham de características particulares dos sistemas ou do vazamento de informações podem, eventualmente, obter sucesso em tempo menor. Vício em programa refere-se a modificações espúrias introduzidas em programas de computador com a finalidade de provocar um funcionamento diferente do objetivo do projeto. Segurança (security e safety) As palavras security e safety são regularmente traduzidas para o português por segurança mas referem-se a conceitos diferentes. Security é o nome dado ao estudo de sistemas

47 informatizados onde se pretende garantir a confidencialidade, a integridade e a disponibilidade dos dados, como é o caso do voto eletrônico. Já Safety é o estudo de sistemas para garantir seu funcionamento correto mesmo com a ocorrência de falhas (de equipamentos ou programas) durante sua operação. Potencial de dano Numa análise da segurança de um sistema deve-se atribuir um valor ao potencial de dano de cada falha ou fraude que existir. No caso de security, este valor deve refletir a grandeza e a importância dos danos provocados se tal fraude ocorrer. Por ex., uma fraude que possa eleger um governador, como ocorrido no Rio de Janeiro em 1982, que ficou conhecida como Caso Proconsult (Mineiro, 2000, http4), deve ter um valor de Potencial de Dano bem maior que uma fraude que só possa eleger um vereador, como a compra de votos de alguns eleitores. Valor do Risco O Valor do Risco de uma fraude é calculado como o produto do seu Potencial de Dano versus sua Probabilidade de Ocorrência. É um valor que os auditores de segurança devem procurar obter para que seja possível comparar sistemas e riscos diferentes entre si. Sistemas de Alto Risco Diz-se de sistemas informatizados cujo Potencial de Dano é muito elevado e a Probabilidade de Ocorrência não é desprezível. Na área de safety, sistemas que envolvam risco de vida ou de grandes danos ambientais, como um sistema de controle de aeronaves ou usinas nucleares, são classificados como de alto risco. Na área de security, o Processo Eleitoral Informatizado tem as características de Sistema de Alto Risco pois a Probabilidade de Ocorrência de Fraudes é alta devido aos grandes interesses envolvidos e o Potencial de Dano, que é entregar o poder político a um eleito ilegítimo, também é alto. Validação refere-se ao processo de análise de um projeto de equipamento ou de um programa de computador, com a finalidade de se determinar se atende ao objetivo desejado. A validação se dá antes da produção final do equipamento ou programa e deve ser feita por auditores que deverão seguir normas técnicas prédeterminadas na elaboração de seus relatórios. A norma ISO/IEC é recomendada para processos informatizados na área de security. Certificação refere-se ao processo de acompanhamento da produção de um equipamento ou da carga de um programa em computador de forma a se verificar se o produto final corresponde ao projeto ou programa que foi validado anteriormente. A certificação se dá ao final do processo de implantação ou fabricação do sistema e antes da sua operação. 2. A POLÊMICA SOBRE O PLS 194/ A Proposta do PLS 194/99 O Projeto de Lei do Senado PLS 194/99 (Requião, 1999, http2), que visa ampliar a segurança e a fiscalização do voto eletrônico, foi apresentado pelo Senador Roberto Requião no dia 31 de Março de 1999, propondo modificar a Lei n.º 9.504, de 30 de setembro de 1997, a qual estabelece normas para as eleições. As alterações na Urna Eletrônica propostas pelo PLS 194/99, que também são apresentadas por Brunazo (1999), são essencialmente duas: 1) que se desvincule a identificação do eleitor da máquina de votação, para impossibilitar a identificação do voto; 2) que se proceda a conferência da apuração eletrônica em 3% das urnas eletrônicas, escolhidas a posteriori, por meio da recontagem dos votos impressos, os quais deverão ser conferidos pelo eleitor antes de serem depositados numa urna convencional. No caso de divergência entre a contagem eletrônica e a recontagem dos votos impressos, outras urnas seriam conferidas dentro de um processo judicial aberto para determinar a origem da diferença. Este Projeto de Lei foi aprovado pela Comissão de Constituição, Justiça e Cidadania, CCJ, do Senado Federal em 15 de setembro de 1999, e foi colocado na pauta de votação do Plenário do Senado do dia 03 de Maio de Desde então a votação do PLS 194/99 foi adiada e remarcada três vezes atendendo a pedidos partidos do Presidente do Tribunal Superior Eleitoral, TSE, Ministro José Néri da Silveira, dirigidos ao Sen. Roberto Requião e encaminhados ao Presidente do Senado, Sen. Antônio Carlos Magalhães. 2.2 A Polêmica sobre a Impressão do Voto No dia 01 de Junho de 2000, data da última votação adiada, o Ministro do TSE, Sr. Nelson Jobim, apresentou as críticas oficiais do TSE sobre o PLS 194/99, durante uma Reunião Pública Extraordinária (http1) da CCJ do Senado, especialmente convocada para este fim. O Ministro Jobim concentrou suas críticas ao item 2 acima, ou seja, à impressão do voto como meio de se proceder a auditoria da apuração. Seus argumentos foram respondidos pelo Senador Requião e, ao final do debate, ficou decidido que técnicos assessores do Senado e do TSE se reuniriam para procurar uma solução técnica consensual, ficando a votação do PLS 194/99 em suspenso. Idêntico impasse, sobre a adeqüabilidade da impressão do voto como meio de conferência da apuração eletrônica, já havia surgido durante o debate na Mesa Redonda ocorrida no Simpósio de Segurança em Informática de 1999, cujo tema foi:

48 Aspectos Técnicos de Segurança Relacionados com o Voto Eletrônico. Os argumentos daqueles que se opõe à utilização da impressão do voto como meio de permitir a conferência da apuração eletrônica e os contra-argumentos dos que defendem o uso do voto impresso, são apresentados a seguir: Argumento 1 - A impressão do voto introduz um risco de fraude adicional à urna eletrônica atual, por troca dos votos impressos. É um retorno às fraudes do passado, permitindo um ataque dirigido que acarretaria a anulação de toda a urna, construindo um resultado falso e distorcendo a verdade eleitoral. Contra-argumento - A simples troca dos votos impressos, não permite a construção de um resultado falso, pois tal ataque só seria eficaz se houvesse fraude idêntica no processo eletrônico de apuração, o que é dificultado por serem técnicas totalmente dispares de ataque. Neste caso, a impressão do voto cria dificuldades adicionais ao atacante, que teria que fraudar dois sistemas bem diferentes entre si, para obter sucesso. No caso da troca apenas dos votos impressos, sem equivalente troca dos votos apurados eletronicamente, as diferenças apareceriam apenas se a urna fosse escolhida para recontagem e, neste caso, seria aberto um processo judicial para determinar se o desvio de votos ocorreu na urna eletrônica ou com votos impressos. Outras urnas seriam abertas para auxiliar a tomada de decisão do juiz que poderia validar o resultado mais confiável, sem anular os votos de toda seção. Assim, o Potencial de Dano deste alegado ataque deve ser estimado na sua devida proporção, pois a situação agora é diferente do caso do sistema tradicional de voto onde se o atacante obtivesse sucesso em trocar os votos de uma urna teria conseguido um ataque dirigido completo, pois teria desviado com sucesso os votos de aproximadamente 500 eleitores. No caso da urna eletrônica com o voto impresso, se o atacante tiver sucesso em trocar os votos em papel de uma urna vinculada a uma urna eletrônica, teria conseguido apenas um ataque destrutivo detectável, que daria trabalho aos auditores, mas cujo efeito de alterar a Verdade Eleitoral seria anulado. Desta forma, o Potencial de Danos da troca de votos impressos na urna eletrônica é muito menor e a fraude associada é ineficaz. Ainda que seja correto afirmar que a impressão do voto abre oportunidade de um ataque, este ataque é destrutivo e é incorreto dizer este tipo de ataque nos leva de volta a mesma situação do passado, quando os ataques eram construtivos e dirigidos. Argumento 2 - A impressão do voto encarece a urna; Contra-argumento - O aumento de custo da urna é compensado pela maior segurança e transparência dada ao sistema. A confiabilidade do processo democrático justifica o maior custo. Um estudo sobre quais seriam tais custos nunca foi apresentado pelo TSE ou pelos que alegam tais custos seriam impeditivos para que se faça a conferência da apuração; Argumento 3 - A impressão do voto provoca aumento no número de casos de urnas com mau funcionamento; Contra-argumento - O aumento de casos de mau funcionamento deve ser resolvido pela melhoria das especificações técnicas e acertos nos planos de contingências que permita a substituição da unidade de impressão defeituosa. Afinal a urna eletrônica deve funcionar apenas 8 horas a cada dois anos. Não é argumento que justifique o impedimento de se conferir a apuração; Argumento 4 - A impressão do voto é um retrocesso tecnológico; Contra-argumento - O uso de documento impresso como forma de permitir a conferência e auditoria é largamente adotado em inúmeros processos informatizados modernos, como a impressão obrigatória de notas fiscais em caixas comerciais eletrônicos, recibos de transações bancárias e com cartão de crédito e, até mesmo no próprio sistema de voto informatizado brasileiro, com o uso dos Boletins de Urna impressos, os quais viabilizam a conferência da Totalização do Votos pelos Partidos Políticos. O Boletim de Urna impresso, exigido por Lei, é a principal defesa do eleitor contra fraudes informatizadas na Totalização dos Votos, como ficou inequivocamente demonstrado no Caso Proconsult em 1982, relatado em artigo pelo jornalista Procópio Mineiro (Mineiro, 2000, http4), que foi o responsável direto pela descoberta daquela fraude. Apenas e tão somente por que existiam os Boletins de Urna impressos, que viabilizavam a conferência externa, foi possível se detectar a fraude que estava em andamento dentro do processo eletrônico. É uma clara incoerência utilizar o papel impresso na BU, para permitir a fiscalização da Totalização, e negar o uso de papel impresso no voto para permitir a fiscalização da Apuração; Argumento 5 - A impressão do voto permite a volta de outras fraudes antigas como o voto-decabresto ; Contra-argumento Tais fraudes antigas com o voto de papel só são possíveis se o voto impresso for entregue nas mãos do eleitor. Se a urna mostrar o voto impresso ao eleitor através de um visor de forma que o eleitor possa conferir mas não

49 manusear o voto, tais fraudes não serão possíveis. Argumento 6 - A impressão do voto permite a ataque destrutivo por quem queira bloquear a votação, bastando o eleitor repetidas vezes alegar que o voto impresso não corresponde ao votado; Contra-argumento Este tipo de ataque não é vulnerabilidade exclusiva da urna eletrônica que imprime o voto. Ele pode ocorrer também com a urna eletrônica atual (sem impressão do voto) e até com o sistema tradicional de voto. É um ataque raro e pouco eficaz que sempre foi resolvido pelos mesários durante a votação. Não há motivo para acreditar que será diferente. Argumento 7 - A impressão do voto não é necessária, tanto que não houve recursos para recontagem do voto em 96 quando o voto era impresso; Contra-argumento Como se pode ver em Camarão (1997, pg. 81, item 4), em 1996 o voto do eleitor na urna eletrônica era impresso com a finalidade de impedir a perda dos votos no caso de pane na urna. Este voto impresso não era mostrado para a conferência do eleitor, de forma que não tinha nenhum valor como documento para auditoria ou recontagem. Além disso, a legislação da época não previa nenhum caso no qual se poderia pedir a recontagem da apuração eletrônica. Não havendo condições legais e não havendo documentos técnicos adequados para auditoria é de se esperar que não houvessem recursos neste sentido. A proposta do PLS 194/99 cria o voto impresso como um documento confiável e válido para a auditoria e estabelece as condições legais em que as urnas poderão e serão recontadas. Argumento 8 - A conferência da apuração pelo voto impresso não é necessária pois quem faz os programas não tem conhecimento dos números dos candidatos no momento da programação e, assim, não poderiam programar o desvio de votos; Contra-argumento Os programas das urnas são apresentados aos partidos políticos 60 dias antes do dia de votação e são carregados nas urnas em torno de uma semana antes da votação. Os números dos candidatos são definidos 90 dias antes da votação e mesmo antes disso são conhecidos pelo público os números dos partidos políticos e dos principais candidatos majoritários. Conforme relatado pelo Jornal do Brasil de 30 de Agosto de 2000, pg. 4, técnicos do TSE declararam que os programas ainda estavam sendo modificados e que a última versão só ficaria pronta dia 05 de setembro, de forma que há tempo disponível para que um fraudador dos programas possa prepará-los para desviar votos de forma dirigida. Argumento 9 - A conferência da apuração pelo voto impresso não é necessária pois os Partidos Políticos terão conhecimento de todos os programas da urna para avaliá-los e validá-los; Contra-argumento Em 96, 98 e 2000 o Firmware (BIOS), o Sistema Operacional (VirtuOS) e a Biblioteca de Criptografia, não foram apresentados para a análise dos fiscais dos partidos. Além disso, como já foi dito, os programas da urna foram modificados e só ficaram prontos um mês após a apresentação para os fiscais. Também nunca se permitiu que algum fiscal de partido certificasse se os flash de carga das urnas continham o mesmo programa que foi analisado. Desta forma, a conferência da apuração eletrônica se torna necessária uma vez que não houve validação e certifação integral e correta. Argumento 10 - A conferência da apuração pelo voto impresso não é necessária pois os Partidos Políticos poderão testar as urnas no dia da lacração. Contra-argumento Em 96 e em 98 a urna escolhida para ser testada era recarregada, antes do teste, com um programa especial para o teste. Depois do teste, o programa de votação era, então, recolocado na urna. Desta forma, em nenhum momento o programa de votação não modificado foi testado efetivamente. A mesma situação está prevista ocorrer em Argumento 11 - A conferência da apuração pelo voto impresso não é necessária pois a Norma ISO estabelece critérios para a validação e certificação dos programas da urna. Contra-argumento A Norma ISO , que será analisada com mais detalhes na seção 5 adiante, define critérios para a avaliação da segurança de sistemas informatizados mas não estabelece em nenhum momento que sistemas com auditoria por documentos impressos sejam melhores ou piores que sistemas puramente digitais. A norma propõe que tais alternativas sejam descritas e avaliadas segundo critérios bastante completos de forma a permitir uma comparação do nível de segurança oferecido por cada alternativa. Nenhum estudo deste tipo foi feito pelo TSE e oferecido para análise aos fiscais dos partidos. 3 ASPECTOS JURIDICOS 3.1Legislação Relacionada à Segurança do Voto Eletrônico A fiscalização e o direito de recontagem do voto no sistema tradicional de votação é coberto por 37 artigos da Lei 4.737/65, conhecida como Código Eleitoral (Ferreira, 1991), e outros 11 artigos da Lei 9.504/97 (Santo, 2000, http8). Já a segurança e fiscalização da urna eletrônica, que também é chamada de Sistema de Votação e

50 Apuração, é regulada apenas pelos 2 artigos da Lei 9.504/97 seguintes: Art. 61. A urna eletrônica contabilizará cada voto, assegurando-lhe o sigilo e inviolabilidade, garantida aos partidos políticos, coligações e candidatos ampla fiscalização. Art. 66. Os partidos e coligações poderão fiscalizar todas as fases do processo de votação e apuração das eleições, inclusive o preenchimento dos boletins de urna e o processamento eletrônico da totalização dos resultados, sendo-lhes garantido o conhecimento antecipado dos programas de computador a serem usados. 1 o No prazo de cinco dias, a contar do conhecimento dos programas de computador a que se refere este artigo, o partido ou coligação poderá apresentar impugnação fundamentada à Justiça Eleitoral. 2 o Os partidos concorrentes ao pleito poderão constituir sistema próprio de fiscalização, apuração e totalização dos resultados, contratando, inclusive, empresas de auditoria de sistemas, que, credenciadas junto à Justiça Eleitoral, receberão, previamente, os programas de computador e, simultaneamente, os mesmos dados alimentadores do sistema oficial de apuração e totalização. Os Art. 67 e 68 da Lei também abordam a fiscalização, mas são aplicáveis apenas ao Sistema de Totalização de Resultados e não ao Sistema de Apuração. Assim, a Lei relativa ao voto eletrônico prevê apenas que os partidos poderão conhecer os programas das urnas e terão cinco dias para contestá-los. Nada é dito sobre testes do sistema, normas técnicas a serem respeitadas e principalmente, nada é dito sobre a possibilidade de conferência ou recontagem da apuração, de forma que o resultado que sai da urna, o Boletim de Urna, é definitivo, não havendo forma legal de se recorrer deste resultado. 3.2 Impressão do Voto: Um Ângulo Jurídico O Procurador da República Dr. Celso Antônio Três escreveu uma carta, que pode ser vista em (http5), onde analisa sob estrito ângulo legal, a questão da impressão do voto pela urna eletrônica como meio de permitir a conferência da apuração, de forma que confiabilidade do sistema possa ser compreendida por um cidadão comum mediano, que não possua conhecimentos especializados. A interpretação do procurador é que: A essência do debate não localiza-se na segurança do engenho informático. Mesmo que a ciência pudesse asseverar a absoluta invulnerabilidade - sabidamente não pode -, a cidadania não estaria plenamente contemplada. A transparência da soberania popular exercida pelo cidadão no Estado Democrático de Direito perfectibiliza-se tão somente quando o eleitor, de per si, por mero uso de suas faculdades, possa fiscalizar a fiel observância do seu voto. A Justiça Eleitoral, Ministério Público, Partidos Políticos, demais candidatos, etc., são apenas co-interessados nessa lisura. Porém, o cidadão - porque titular exclusivo de um direito constitucional público subjetivo - é que deve estar apto a sindicar o processo eleitoral. Para isso, faça-se o que necessário for, a exemplo da impressão material (não apenas virtual) das cédulas. É o cidadão titular de um direito inalienável e pessoal de defesa. Assim os termos processuais devem ser consignados de forma a permitir-lhe o mais absoluto controle, segundo as faculdades rotineiras do "homo medium". Portanto, de todo distorcida a dialética que restringe à confiabilidade técnica da apuração. 4 A REAL AVALIAÇÃO DA SEGURANÇA A garantia da Verdade Eleitoral e a segurança do eleitor com as urnas eletrônicas utilizadas nas eleições de 1996 e 1998 foram submetidas a avaliação pelos fiscais dos partidos políticos como manda o Art. 66 da Lei Apresenta-se a seguir como se deu os procedimentos de validação, certificação e testes das urnas nestes dois anos eleitorais. 4.1 A Validação dos Programas das Urnas Os procedimentos para a validação dos programas contidos nas urna eletrônicas em 96 e 98 foram muito semelhantes entre si e aos que estão previstos para esta eleição de Sessenta dias antes do dia da votação os partidos políticos foram convidados a comparecer à sede do TSE em Brasília onde lhes foi apresentado os parte dos programas-fonte do Aplicativo de Votação mas, como já foi dito, alguns destes programas foram modificados posteriormente, com a versão final para 2000 tendo ficado pronta somente 30 dias depois da auditoria dos partidos. Porém, três blocos de programas-fonte: a Biblioteca de Criptografia (componente do Programa Aplicativo); o BIOS e Sistema Operacional (componentes do Programa Básico), não foram apresentados para análise dos fiscais dos partidos, o que deu ensejo à um pedido de impugnação (http10) feito pelo partido PDT. A justificativa para a não apresentação destes programas-fonte são discutíveis conforme se vê a seguir: Justificativa 1 Segundo o Ministro do TSE Nelson Jobim (http1), a Biblioteca de Criptografia

51 não pode ser mostrada por motivos óbvios, senão a segurança do sistema todo estaria comprometida. Contra-argumento As funções da Biblioteca de Criptografia são usadas apenas para criptografar o Boletim de Urna (BU) que vai gravado no disquete de transferência dos dados para o Sistema de Totalização. Antes, porém, de ser criptografado o BU é impresso e publicado, como manda o Art. 68 da Lei Assim está sendo criptografado um dado que já é de conhecimento público, de forma que este procedimento não tem função de tornar os dados inacessíveis ou garantir sua confidencialidade. A função da criptografia, neste caso, é para garantir a autenticidade ou integridade da BU, isto é, para impedir a adulteração indevida da BU durante o transporte do disquete. Mas esta função de garantir a autenticidade de dados é melhor coberta pelas técnicas de Assinatura Digital que são, pela própria natureza, Sistemas Abertos que não necessitam ter seus códigos fontes mantidos em segredo. Assim não se justifica a adoção de um sistema de criptografia fechado na urna eletrônica, cujo código-fonte não possa ser analisado pelos fiscais externos, principalmente considerando-se que numa biblioteca qualquer pode ser inserido um vício de programação que fraude a eleição. Além disso, deve-se considerar que se a segurança e a confiabilidade do voto eletrônico depende da manutenção de um segredo nas mãos de umas poucas pessoas, o grau de confiabilidade do sistema todo cai. Nos EUA, está se estudando uma proposta de open source Internet voting software (http11) justamente para contornar a insegurança natural de software fechado. Justificativa 2 O Sistema Operacional VirtuOS, usado na urna, é de mercado e está protegido por direito autoral, não podendo o TSE mostrar o seu código-fonte. Contra-argumento A decisão de utilizar o VirtuOS como sistema operacional da urna não é obrigatória nem mandatória. O Art. 66 da Lei obriga o TSE a apresentar todos os programas para análise dos partidos. Se o TSE não pode apresentar o código-fonte do VirtuOS, deveria adotar outro sistema operacional aberto, como o Linux por exemplo. Justificativa 3 O BIOS e o Sistema Operacional estão assinados digitalmente e sua autenticidade pode ser comprovada a qualquer momento. Contra-argumento Conforme fica claro na Resolução , de 05/09/2000, do TSE, não é permitido aos partidos políticos conferirem as assinaturas digitais dos programas carregados na urna, por se tratar de dispositivo de segurança! Esta é uma decisão totalmente contrária às técnicas de assinatural digital, na qual se publica o algorítmo e a chave de deciframento justamente para permitir à outra parte conferir a assinatura. De nada adianta se afirmar que os programas estão assinados se não se permite a conferência desta assinatura. Justificativa 3 O não é possível introduzir vício para desviar votos no Sistema Operacional sem conhecimento da estrutura de dados que é definida apenas no Programa Aplicativo de Votação. Contra-argumento Este argumento está simplesmente errado. É perfeitamente possível desviar votos sem conhecer a estrutura interna dos dados. Basta que o Sistema Operacional interfira nas chamadas de leitura de teclado e de escrita na tela para gerar um pequeno banco de dados com os números dos candidatos e a respectiva tela. A partir da construção deste banco de dados o programa viciado poderia apresentar ao eleitor a tela solicitada e enviar ao programa aplicativo um número adulterado do candidato. Todas as rotinas de criptografia e segurança internas do aplicativo seriam inúteis contra este tipo de ataque. Além do mais, a empresa Microbase, que fornece o Sistema Operacional da urna, também assessora a Procomp, empresa que produz o programa aplicativo, não havendo uma clara e evidente separação entre tais equipes de programadores. 4.2 A Certificação da Carga das Urnas Durante a carga e lacração das urnas, antes do dia de votação, os partidos são chamados à auditarem o processo. Mas tal auditoria não é feita em quase nenhum local de carga espalhado pelo país e nos pouquíssimos casos em que algum fiscal compareceu, a auditoria não passou de um acompanhamento visual de tudo que é feito pelos operadores contratados pela Justiça Eleitoral. O TSE entende que o papel dos fiscais durante a carga das urnas deve-se restringir ao acompanhamento visual dos atos dos técnicos e não é permitido que os fiscais verifiquem se os flashde-carga contém os programas previamente aprovados, o que também deu ensejo ao pedido de impugnação (http10) feito pelo PDT. Assim, nenhum fiscal de nenhum partido político, em 1996 e 1998, em todo o Brasil, jamais fez uma análise do conteúdo dos discos de carga das urnas, para verificar se a assinatura digital dos programas conferia com o que seria devido. Nenhum relatório formal de tal auditoria existe. 4.3 Os Testes das Urnas Prontas Após a carga das urnas e antes da sua lacração, os fiscais dos partidos podem, segundo o Art. 9 da Resolução do TSE (http9), testarem até 3% das urnas para verificarem se ela faz a apuração

52 correta. Porém tal teste foi feito de maneira completamente inadequada. Após ser escolhida para teste, a urna é carregada com um disquete de inicialização que altera parâmetros internos da urna e cujo programa reconhece que está sob teste, pedindo a senha especifica. O teste consiste na emissão de um relatório inicial vazio, a zerésima, na colocação de votos quaisquer e emissão da BU final com o resultado da apuração. Após o teste a urna volta a ser carregada com o flash de carga para recuperar a situação que estava antes da modificação para o teste. Desta forma, o programa original de votação e apuração, sem modificações, nunca foi testado por nenhum fiscal externo ao TSE. 4.4 O Responsável pela Fiscalização Como se vê da seção anterior, uma série bem grande de falhas na segurança com o programa da urna eletrônica provêm de despreparo ou omissões dos fiscais dos partidos políticos, mas o Ministro Jobim (http1) afirma que o TSE não pode ser responsabilizado pela falta de preparo dos partidos em fiscalizarem o processo eleitoral. Segundo Camarão (1997), o TSE decidiu em 1994 desenvolver a urna eletrônica com o principal objetivo de acabar com as fraudes que ocorriam no sistema tradicional de votos. As fraudes que foram eliminadas ou dificultadas com a urna eletrônica eram, todas elas, advindas de falhas na fiscalização. Se os fiscais dos partidos falhassem no acompanhamento: dos mesários estes poderiam induzir o eleitor ou votar por eleitores faltosos do transporte da urna fraudadores poderiam trocar os votos das urnas dos apuradores estes poderiam adulterar os votos do preenchimento dos BU este poderia ser adulterado. Com a urna eletrônica, o TSE tomou uma posição ativa para resolver problemas resultantes do despreparo ou desatenção dos fiscais dos partidos. Mas a solução adotada apenas transferiu a esfera de fiscalização para outro nível muito mais sofisticado. No sistema tradicional, os fiscais deveriam ter capacidade de acompanhar mesários, o transporte das urnas e os escrutinadores, que são atividades bastante simples bastando pouco preparo para se ter um fiscal apto. E, ainda assim, falhavam. O Caso Proconsult (Mineiro, 2000) é um bom exemplo, pois a conferência da totalização foi feita por uma pequena equipe de estagiários de jornalismo usando calculadoras e que acabaram detectando uma fraude que estava passando por baixo dos olhos dos fiscais dos partidos. Com a urna eletrônica, os fiscais devem ser especialistas em informática e em segurança de dados. Mesmo os fiscais de campo, que deveriam conferir se as cargas das urnas estão sendo feitas com discos não adulterados, deveriam receber treinamento técnico em informática. O conhecimento adequado da norma ISO , por exemplo, demanda cursos específicos. O trabalho de fiscalização é muito técnico, difícil e até arriscado pois pequenos erros na fiscalização podem levar a fraudes gigantescas que distorçam até o resultado da eleição para Presidente da República. Desta forma, a urna eletrônica aumentou muito as dificuldades de fiscalização pelos partidos. Não é correto se afirmar que o TSE não pode ser responsabilizado por este problema, pois foi o TSE que iniciou o processo de sofisticar a fiscalização sem prever uma preparação ou treinamento para os partidos e seus fiscais. 5. A NORMA ISO/IEC A Norma Técnica Internacional ISO/IEC de Dezembro de 1999 (http3) estabelece Critérios de Avaliação da Segurança (security) no âmbito da Tecnologia de Informação. Esta norma vem sendo desenvolvida desde 1990 e sua primeira versão beta data de abril de Uma segunda versão beta foi publicada em outubro de Pelo Item 3.2, Part 1 desta norma, seu objetivo é fornecer aos projetistas, aos auditores e, principalmente, aos usuários de sistemas informatizados condições de poder comparar a segurança de sistemas diferentes para se poder escolher qual mais atende melhor as necessidades. É uma norma bastante complexa que envolve, na sua aplicação, não apenas uma empresa produtora e seus engenheiros, mas sim toda uma comunidade técnica e econômica, pois a avaliação de cada sistema parte de padrões gerais, chamados de Perfil de Proteção, que devem vir definidos de fora do âmbito das empresas envolvidas no fornecimento de dado produto. Normalmente devem provir de entidades governamentais ou comunitárias. Também, após o término da avaliação de um produto ou sistema, este ainda deverá receber sua certificação por entidades, externas e independentes ao conjunto de fornecedores e usuários, criadas e preparadas para tal finalidade, pois a ISO (Part 1, Scope, Item D) declara textualmente que não é uma norma de certificação, é apenas de avaliação. Assim, a aplicação desta norma é tanto precedida quanto seguida de atividades feitas por entidades comunitárias especializadas, de forma que não é só o TSE, por exemplo, que deve se preparar para aplicar a Norma ISO à urna eletrônica. Também os Partidos Políticos teriam que contratar engenheiros especializados para acompanhar desde o projeto até a implantação, passando pela

53 construção de todos os componentes da urna eletrônica pois, antes de um sistema ser avaliado, todos os seus componentes devem também ser avaliados e certificados, resultando numa cascata de certificações. Também deve-se considerar que o nível do rigor necessário para avaliar um sistema de voto eletrônico é muito elevado. Na área de safety existe o conceito de Sistemas de Alto Risco para classificar sistemas que possam por em risco vidas humanas ou provocar enormes danos ambientais no caso de falha de algum de seus subsistemas ou componentes. Uma das propostas deste trabalho é que também em security se classifique os sistemas pelo seu nível de risco. De forma similar, definir-se-ia os conceitos de Potencial de Dano, Probabilidade de Ocorrência, Valor do Risco e Sistemas de Alto Risco como está apresentado no Glossário, seção 1.1, com a diferença que em security refere-se a fraudes e não a falhas. Assim teríamos o potencial de dano de uma fraude, a probabilidade de ocorrência de uma fraude, etc. Por exemplo, o Potencial de Dano de uma fraude sistêmica resultante de vício introduzido no programa de apuração de todas as urnas, por um programador desonesto, é muito maior que o Potencial de Dano da fraude que mesários desonestos podem cometer introduzindo votos na urna, o que sugere que as defesas contra o primeiro tipo de fraude sejam muito mais rigorosos que contra a outra fraude menos danosa. O Voto Eletrônico sem dúvida deveria ser classificado como Sistema Informatizado de Alto Risco de Fraude e, como tal, deveria ser avaliado com muito rigor. Para se adequar a avaliação da urna eletrônica brasileira à norma ISO , com todo rigor que exige um Sistema de Alto Risco, demoraria anos. Mas, o mais importante que se obtém de uma análise da norma com relação a seu uso na avaliação da urna eletrônica, são dois procedimentos sugeridos: 1- Um produto ou sistema deve ter sua segurança avaliada segundo os critérios da norma e receber uma certificação segundo critérios prévios estabelecidos por entidades comunitárias ou governamentais, ANTES de ser programado e preparado para operar. 2- A norma nada diz contra ou a favor do uso de documentação impressa pelo sistema sob avaliação. Apenas sugere que sistemas diferentes sejam avaliados sob os mesmos critérios propostos pela norma e, depois de avaliados formalmente, sejam julgados por suas qualidades e defeitos apontados. Nenhuma destas duas recomendações foram seguidas durante a construção e operação das urnas brasileiras de 1996, 1998 e de A definição do projeto e a fabricação das urnas foi contratada antes de se apresentar os seus projetos e programas para validação e aprovação pelos fiscais dos partidos políticos. Estes só tiveram conhecimento de parte dos programas-fonte utilizados na urna 60 dias antes da eleição, quando todo o processo de implantação e operacionalização da eleição informatizada já está em pleno andamento e comprometido de forma irreversível. Não será mais possível se suspender o fornecimento das urnas ou o seu uso durante as próximas eleições, caso algum item de projeto for rejeitado, sem provocar grande confusão e perdas de verbas já gastas. Isto ficou demonstrado neste ano de 2000, quando o pedido de impugnação do PDT contra os programas das urnas (http10), impetrado no prazo legal (5 dias após a apresentação dos programas aos partidos), foi rejeitado pelo TSE, entre outros argumentos, por não haver tempo hábil de implementar as propostas sugeridas. Não é assim que se procede, por exemplo, nos estados americanos que aceitam o uso de urnas eletrônicas. As legislações dos Estados Americanos da Virgínia ( , linha D, http6) e de Massachusetts (Chapter 54, Section 32, http7), deixam claro que primeiro os equipamentos de votação eletrônica devem ser aprovados por comissões de órgãos dos governos estaduais, a quais não têm prazo para apresentar seus relatórios, e somente depois desta aprovação é que poderão ser encomendados e comprados por órgãos municipais para serem utilizados em eleições. Quanto ao comprovante impresso conferido pelo eleitor, que fazia parte das propostas do TRE/RS-UFRS (Price, 1995), do TRE/MG-IBM, do TRE/MT-IBM e que, segundo Camarão (1997, pg. 72 e 77), constava do Anteprojeto de Lei proposto pela Comissão de Informatização de 1996 do TSE ao Congresso Nacional, foi eliminado do projeto definitivo da urna sem nenhum estudo comparativo de avaliação dos riscos que tenha sido apresentado à sociedade ou aos Partidos Políticos. 6 CONCLUSÃO Da análise dos procedimentos que foram praticados durante o projeto, fabricação, operação e fiscalização externa das urnas eletrônicas brasileiras, nos anos de 1996, 1998 e 2000, fica evidente que houve falhas na segurança do sistema eleitoral informatizado. Principalmente a parte relativa a fiscalização externa está eivada de falhas e omissões que acabam por reduzir a confiabilidade do sistema eleitoral informatizado brasileiro à confiança das pessoas envolvidas na sua produção. Não se efetuaram validação, certificação e testes de forma adequada e confiável. A validação foi incompleta pois parte dos programas-fontes das urnas não são apresentados aos fiscais dos partidos. A certificação de que os discos de carga continham o programa validado, simplesmente não

54 foi feita por nenhum partido político. Os teste públicos de funcionamento são irregulares pois se altera o conteúdo da máquina sob teste, antes e depois do teste. A norma ISO/IEC , seja versões beta ou a atual versão definitiva, nunca foi utilizada para a avaliação do sistema, especialmente pelos fiscais dos partidos, que simplesmente a ignoram. Nenhum estudo dos riscos envolvidos com a eliminação da possibilidade de conferência da apuração foi apresentado ou previamente debatido em público ou no meio acadêmico. Todas estas condições, principalmente a dificuldade prática dos fiscais dos partidos validarem os programas e certificarem urnas, levam a conclusão deste trabalho no sentido de que: Deve-se corrigir o projeto da urna eletrônica brasileira para tornar possível a conferência e auditoria da apuração. Tornando-se possível a conferência da apuração torna-se muito mais fáceis e menos rigorosas as necessidade de validação e certificação prévias a serem feitas pelos fiscais dos partidos, aumentando a tolerância do sistema contra falhas na fiscalização. Sugere-se ainda que: A forma de se proceder a esta auditoria seja por meio da impressão do voto, o qual deverá ser mostrado ao eleitor para ser aprovado antes de ser depositado automaticamente, sem manipulação pelo eleitor, numa urna convencional, das quais uma parte será usada numa conferência estatística da apuração. AGRADECIMENTOS O autor agradece principalmente a todos os assinantes ativos do Fórum do Voto Eletrônico (http12) pelo contribuição constante que têm dado, sem as quais não se teria juntado todas estas informações sobre o voto eletrônico no Brasil. Dentre todos estes colaboradores, destaco o engenheiro Márcio Teixeira da empresa Tasco Ltda. de Belo Horizonte, o advogado Paulo Gustavo Sampaio Andrade, de Teresina, responsável pela página jurídica Jus Navegandi, o analista Evandro Oliveira da Prodabel de Belo Horizonte e o jornalista Oswaldo Maneschy da Defensoria Pública do Rio de Janeiro pelas muitas horas de dedicação cedidas por amor à causa. CAMARÃO, Paulo César Bhering. O Voto Informatizado: Legitimidade Democrática. São Paulo: Empresa das Artes, FERREIRA, Pinto. Código Eleitoral Comentado. São Paulo, Saraiva, MINEIRO, Procópio. Proconsult Um Caso Exemplar. Cadernos do Terceiro Mundo, Rio de Janeiro, Editora Terceiro Milênio, n.219, p. 17, Abril/Maio PRICE, Roberto Tom. Votação Informatizada: Projeto UFRGS. Porto Alegre: Instituto de Informática da Universidade Federal do Rio Grande do Sul, REQUIÃO, Roberto. PLS 194/99 Projeto de Lei do Senado. Brasília: Senado do Brasil, SANTO, Stella Bruna. Manual das Eleições. São Paulo: Fundação Perseu Abramo, REFERÊNCIAS NA INTERNET (http1) Ata da 22ª Reunião Pública Extraordinária da CCJ do Senado, de 01 de Junho de 2000: ntes/ccj/atas/ ex022.zip (http2) Projeto de Lei do Senado, PLS 194/99: (http3) International Standard ISO/IEC : (http4) PROCONSULT um caso exemplar: (http5) Carta do Procurador Celso Antônio Três: (http6) Lei do Estado da Virgínia, USA: (http7) Chapter 54, Sections 32, 33E, 33H, 35 e 67 da Lei do Estado de Massachusetts, USA: (http8) Lei 9.504/97 e demais leis eleitorais: m (http9) Resoluções do ano 2000 do TSE: html (http10) Pedido de impugnação da urna pelo PDT: (http11) The Smart Iniciative Projects List : (http12) Fórum do Voto Eletrônico - Voto-E : REFERÊNCIAS BIBLIOGRÁFICAS BRUNAZO Filho, Amílcar, A Segurança do Voto na Urna Eletrônica Brasileira.. In: SIMPÓSIO DE SEGURANÇA EM INFORMÁTICA, 1999, São José dos Campos. Anais... São José dos Campos: ITA, P

55 AVALIAÇÃO DE AÇÕES COOPERATIVAS NA ANÁLISE DA SEGURANÇA DO SISTEMA DE TELEDESTRUIÇÃO DE UM VEÍCULO DE SONDAGEM Carlos Lahoz, Martha Abdala Divisão de Eletrônica Instituto de Aeronáutica e Espaço S. J. Campos SP lahoz@iae.cta.br, martha@iae.cta.br Carlos Moura Divisão de Operações Centro de Lançamento de Alcântara São Luis MA moura@iae.cta.br Rogério de Lemos Computing Laboratory University of Kent at Canterbury CT2 7NF Canterbury UK r.delemos@ukc.ac.uk RESUMO Este trabalho apresenta uma avaliação da abordagem orientada a objetos cooperativos empregada no modelamento e análise de segurança do sistema de destruição de um foguete de sondagem. Uma característica distinta desta abordagem em relação a da orientada a objetos é que ela enfoca o comportamento das interações entre componentes, ao invés dos próprios componentes. A avaliação é feita pela comparação dos conjuntos de corte mínimo obtidos dos diagramas de árvore de falhas das especificações do sistema em linguagem natural e orientada a objetos cooperativos. ABSTRACT This work presents an evaluation of the cooperative object-oriented approach that is used in the modelling and analysis of the remote destruction system of a sounding rocket. A distinct feature of this approach compared with an object-oriented one is that focus is given to the behaviour of the interactions between components, rather than on the components themselves. The evaluation of the approach is performed by comparing the minimal cut sets of the fault tree diagrams obtained from the natural language specification of the system and the corresponding cooperative object-oriented model. 1 INTRODUÇÃO A análise de segurança é o processo de avaliação de sistemas críticos que determina se o risco associado ao uso de um sistema é aceitável. Um dos maiores problemas da análise de segurança de sistemas complexos, normalmente caracterizados pelo alto índice de acoplamento entre seus componentes, está na dificuldade de extrair o comportamento interativo dos seus componentes. A modelagem através de ações cooperativas permite representar de forma explícita as interações entre os componentes, com isto caracterizando seu comportamento colaborativo. Este tipo de modelagem permite realizar uma análise de segurança mais efetiva nos estágios iniciais do projeto de software que inclui: identificar as falhas associadas à violação das especificações de segurança, e prover evidência que o comportamento do sistema será seguro. Entretanto é necessário se obter confiança na habilidade desta abordagem de produzir especificações que sejam seguras contra falhas acidentais. Para tal, a análise baseada em modelos orientados a objetos cooperativos tem de ser comparada com uma análise baseada em técnicas tradicionais. Neste artigo, a viabilidade da técnica orientada a objetos cooperativos de produzir especificações seguras é avaliada dentro do contexto de um sistema de destruição do veículo de sondagem VS-40X. A avaliação é feita comparando-se o conjunto de corte mínimo da árvore de falhas da especificação em linguagem natural do sistema de destruição, com o conjunto de corte mínimo da especificação em termos de ações cooperativas. A organização do restante deste trabalho é a seguinte. A seção 2 descreve a técnica orientada a objetos cooperativos. A seção 3 descreve a técnica de Análise de Árvore de Falhas (Fault Tree Analysis FTA), que é uma técnica qualitativa para análise dedutiva da segurança. A seção 4 apresenta o foguete de sondagem juntamente com os seus requisitos de segurança e missão. Na seção 5 introduzimos o sistema de destruição do foguete de sondagem e enumeramos as suas falhas; além disto, apresentamos as árvores de falhas associadas à especificação do sistema em linguagem natural e em ações cooperativas. Na seção 6 fazemos a avaliação do modelo de ações cooperativas, através da comparação dos conjuntos de corte mínimo das árvores de falhas. Finalmente, na seção 7, discutimos as conclusões e as contribuições deste estudo ao projeto dos veículos de sondagem. 2 A MODELAGEM ATRAVÉS DE AÇÕES COOPERATIVAS A técnica de ações cooperativas descreve o comportamento de sistemas dando ênfase à análise das interações entre os seus componentes (de Lemos, 2000). Partindo do pressuposto que acidentes são provocados mais comumente por falhas em múltiplos componentes, ao invés de falha em um único componente, esta técnica se propõe a extrair da especificação dos componentes as dependências comportamentais existentes entre eles. No projeto de orientação a objetos cooperativos, o comportamento colaborativo entre dois ou mais objetos é representado em termos de ações cooperativas, cuja estrutura de representação permite a modelagem e análise das interações entre os objetos. Assumindo-se que os componentes de um sistema permanecem inalterados, um modelo orientado a objetos cooperativos permite que a análise de segurança de um sistema se restrinja às interações entre os componentes e, com isto, evitando analisar o comportamento integral do sistema.

56 Dentro da técnica orientada a objetos cooperativos, a ação cooperativa representa aspectos tanto estruturais como de comportamento do sistema. Em termos gerais a ação cooperativa é representada pelo seu nome, atributos e comportamento. Os atributos são descritos em termos de constantes e variáveis e o comportamento da ação cooperativa é expresso em termos do comportamento normal, excepcional e de falha. Objetos podem participar em uma ou mais ações cooperativas, e no mínimo dois objetos têm de ser associados a uma ação cooperativa. A especificação do comportamento das ações cooperativas é feita através de uma lógica de predicados de primeira ordem (Extended Real Time Logic - ERTL) voltada para o modelamento e análise de sistemas híbridos (de Lemos 1996; Hall 1996). 3 ANÁLISE DE ÁRVORE DE FALHAS A Análise de Árvore de Falhas (FTA Fault Tree Analysis) tem por objetivo determinar as causas para a ocorrência de um evento não desejável, que na análise de segurança está relacionado a ocorrência de perigos. Esta técnica, através de uma abordagem dedutiva, parte de um perigo do sistema e procede para trás procurando as falhas do sistema que são causadoras deste perigo. Como é um método top-down, o evento topo representa o perigo, e os eventos primários as causas dos perigos. Somente as relações entre o evento topo e os eventos primários são descritos (conjuntos de corte). O objetivo desta análise é encontrar os conjuntos de corte mínimo, que são os conjuntos com o menor número de eventos primários que, caso ocorram, geram o evento topo (Kececioglu, 1991). 4 O FOGUETE DE SONDAGEM VS-40X O foguete de sondagem VS-40X é um veículo baseado no foguete VS-40, do Programa Espacial Brasileiro, que tem como função principal levar ao espaço equipamentos científicos em sua carga útil. Seu vôo sub-orbital segue uma trajetória parabólica apropriada para realizar experimentos que requerem, por exemplo, ambiente de microgravidade. Trata-se de um foguete de dois estágios, equipados com sistemas de pilotagem, com propulsores carregados com propelente sólido, tipo composite, especificado para permitir o domínio das tecnologias imprescindíveis para a consecução de um veículo lançador de satélites. 4.1 Requisitos de Missão e Segurança do Veículo VS-40X Os requisitos de missão e segurança do VS-40X devem ser considerados para as etapas de preparação para o lançamento e de vôo do veículo que são: Pré-lançamento: do início da contagem regressiva até T0 (o instante em que ocorre a desconexão dos umbilicais); Inicial: livre evolução sobre a plataforma de lançamento (T0 a T0+5s); Intermediária I: fim da visualização pelo Circuito Fechado de TV (de T0+5s a T0+15s); Intermediária II: até ao início da fase de vôo balístico (de T0+15s até o término da fase propulsada); Final: do início da fase de vôo balístico até ao final do vôo Requisitos de Missão do VS-40X Dentre os requisitos de missão do veículo será considerado neste trabalho aquele que pode influenciar, ou ser influenciado, pelos requisitos de segurança, que é: o veículo não deverá ser destruído inadvertidamente em condições normais de vôo. Os demais requisitos de missão que estão associados às metas a serem alcançadas pelo vôo do veículo não são aqui abordados Requisitos de Segurança do VS-40X Os requisitos de segurança do VS-40X permitem a manutenção da integridade do ambiente do veículo no que tange a danos a propriedades e perdas de vidas, quando há uma falha no comportamento do sistema. Dependendo da fase do vôo e da trajetória do veículo, identificamos dois tipos de acidentes: uma destruição inadvertida do veículo na rampa de lançamento, ou nos primeiros instantes de vôo, podendo causar danos às instalações de lançamento, lesões ou perdas de vidas; no restante da trajetória, a queda de destroços, após uma falha no comportamento do veículo, podendo causar danos a propriedades, lesões ou perdas de vidas. Portanto, os requisitos de segurança do sistema de destruição são os seguintes: o veículo não pode ser destruído nas fases de Pré-lançamento e Inicial; o veículo tem que ser destruído nas fases Intermediária I e II, quando o Ponto Provável de Impacto, PPI, adentrar na Zona Protegida, ZP. 4.2 Componentes do Sistema de Segurança do VS- 40X Operador de segurança: responsável pelo acionamento do telecomando para a

57 destruição do veículo. Tem como auxiliar de decisão o CFTVe o SISGRAF. CFTV: o Circuito Fechado de Televisão faz o rastreamento ótico do veículo na etapa Intermediária I do vôo. SISGRAF: o Sistema de Visualização Gráfica exibe, em monitores gráficos, mapas digitalizados da área de lançamento do veículo, onde é representada a trajetória de seu vôo e a Linha Limite de Impacto, LLI, com o Ponto Provável de Impacto, PPI, além de outras informações úteis para o operador de segurança. Telemetria: faz a comunicação entre o veículo e a base de lançamento, fornecendo dados do veículo como: pressão interna dos motores, acelerações e leitura dos magnetômetros nos eixos do veículo. Telecomando: comando executado pelo operador de segurança para provocar a destruição remota do veículo. Caixa de Segurança: sistema que inibe ou habilita o sistema de segurança bem como mantém interface de comunicação com o banco de controle e a telemetria. Quando o veículo está em solo, possui uma ligação física com o Banco de Controle, através do conector dos umbilicais. Nos instantes iniciais de vôo ocorre o rompimento desta ligação, ativando o relé de segurança (fecha o jumper). Este dispara o temporizador que habilitará a caixa de segurança para possível destruição do veículo. BC: o Banco de Controle é o sistema responsável pelo controle do veículo, desde sua energização até a decolagem. É a partir do BC que ocorre a energização do sistema elétrico do veículo que acionará o relê de segurança da caixa de segurança. 5 SISTEMA DE DESTRUIÇÃO DO VS-40X O sistema de destruição do VS-40X é responsável por assegurar que os requisitos de segurança sejam atendidos, sem violar o requisito de missão. Quando há uma falha no comportamento do sistema, isto inclui: garantir a integridade do veículo em condições normais de vôo e manter a integridade do ambiente, no que tange a danos a propriedades e perdas de vidas. A habilitação do sistema de destruição é acionada pela caixa de segurança, instalada no veículo, após a fase Inicial de vôo. O temporizador instalado dentro da caixa de segurança é ativado logo após a desconexão dos umbilicais do veículo, inicializando o processo de habilitação da destruição. Todo este sistema é energizado em solo, quando o veículo está na rampa, pelo Banco de Controle. A destruição do veículo pode ser realizada de diferentes modos, dependendo do sistema implementado. O sistema de teledestruição tem como componente principal o operador de segurança, que decide sobre a destruição do veículo em solo. Outro sistema existente é o da autodestruição, onde a decisão para destruição é tomada pelo sistema de proteção a bordo do veículo. Um terceiro sistema de destruição é o composto pelos dois anteriores, que a princípio, dá ao operador de segurança a responsabilidade por esta decisão, que é passada para o sistema de proteção a bordo, caso o primeiro fique impossibilitado de monitorar a trajetória e a integridade do veículo. Neste trabalho é abordado o sistema de teledestruição do VS-40X, cujos procedimentos operacionais estão inseridos no Plano de Segurança, considerando diferentes fontes de informação dependendo da etapa de vôo: nos primeiros instantes do vôo, por rastreamento ótico proveniente dos monitores de CFTV onde estão traçadas a Linha Limite de Impacto, LLI (enquanto a informação proveniente dos radares é imprecisa). Uma vez que a trajetória do veículo ultrapassa estas linhas, o operador emite o telecomando para destruição do veículo. nas restantes etapas do vôo, por rastreamento do sinal dos radares que fornecem as informações através do SISGRAF - que representa graficamente estes dados. O Ponto Provável de Impacto, PPI, não pode evoluir fora da Zona Não Protegida, ZNP delimitada pela LLI. Em casode falha, o veículo (ou os destroços do veículo) não pode cair na Zona Protegida, ZP. 5.1 Descrição da Teledestruição A habilitação da destruição fica inibida no veículo durante a preparação para o lançamento, na rampa, até os primeiros instantes de vôo, onde acontece o período de livre evolução. Estas fases, denominadas de Pré-lançamento e Inicial, em função da dinâmica do foguete, dura até 4 ou 5 segundos depois do lançamento. Depois dos primeiros instantes do vôo até o início da fase de vôo não propulsado, a teledestruição fica habilitada, e a decisão para a destruição do veículo será baseada no rastreamento visual proveniente de imagens do CFTV na fase Intermediária I, no rastreamento dos sinais de radar e nos dados sobre o veículo fornecidospela telemetria, na fase Intermediária II. Na fase Final do vôo, a teledestruição também é desabilitada.

58 EnableDestruction: attributes: participants: oc OperatorConsole v Vehicle v.sb SafetyBox behaviour: initial: Φ( oc.safedest v.disumbil v.destroyed v.sb.endest v.sb.safedest v.prelaunchphase v.initialphase v.intermediatephase, 0) normal: pre-condition: t Θ( enabledestruction, t) Θ( oc.safedest, t) operation: t Θ( oc.safedest, t) Θ( v.sb.safedest, t) T0: t<t0 Θ( v.sb.safedest, t) Θ( v.disumbil, T0) Θ( v.sb.endest, T0+5) post-condition: t Θ( enabledestruction, t) Θ( v.sb.endest, t) Θ( v.destroyed, t) failure: t Φ(commission_enableDestruction, t) Φ(enableDestruction, t) Φ(v.preLaunchPhase v.initialphase, t) Φ(v.sb.enDest, t) t Φ(omission_enableDestruction, t) Φ(enableDestruction, t) Φ(v.intermediatePhase, t) Φ( v.sb.endest, t) Figura 1 - Ação cooperativa EnableDestruction Falhas no Sistema de Teledestruição Associadas aos Requisitos de Segurança As possíveis falhas associadas à violação dos requisitos de segurança são: Falha 1: o veículo é destruído pelo operador de segurança quando a destruição está habilitada, nas fases de Pré-lançamento e Inicial de vôo. falha do operador de segurança e falha na caixa de segurança ou falha do operador de segurança e falha nas entradas da caixa de segurança. Falha 2: o veículo invade a ZP e o veículo não é destruído nas fases Intermediária I e II. Falha 2.1: o veículo invade a ZP e o operador de segurança não é informado. falha no CFTV impede que o operador detecte a saída do veículo da ZNP (fase Intermediária I) ou falha no SISGRAF impede que o operador detecte o PPI invadindo a ZP (fase Intermediária II); Falha 2.2: o PPI invade a ZP, o operador de segurança aciona a destruição, mas o veículo não é destruído. falha em um dos equipamentos relacionados à habilitação da destruição do veículo ou falha no telecomando que não ativou a destruição do veículo. Falha 2.3: o PPI invade a ZP, o operador de segurança é informado, mas não aciona a destruição. falha do operador de segurança ao não acionar a destruição Falhas no Sistema de Teledestruição Associadas aos Requisitos de Missão A possível falha associada à violação do requisito de missão é: Falha 3: o veículo está na ZNP e é destruído, nas fases Intermediária I ou II. falha do operador de segurança ao acionar a destruição ou sinal espúrio aciona a destruição. 5.2 Representação das Ações Cooperativas As ações cooperativas EnableDestruction e RemoteDestruction são definidas para representar, respectivamente, a habilitação da destruição e a teledestruição do veículo. A Figura 1 mostra a ação cooperativa EnableDestruction que descreve o comportamento dos componentes da teledestruição do veículo. A descrição do comportamento normal da ação cooperativa inclui a pré-condição para que os componentes do sistema entrem na ação cooperativa: o operador de segurança habilita a destruição do

59 RemoteDestruction: attributes: participants: so SafetyOperator oc.cctv CCTV oc.sisgraf SISGRAF oc.tm Telemetry v Vehicle v.rc RemoteControl v.sb SafetyBox behaviour: initial: Φ( so.actdest oc.cctv.outsidesp oc.sisgraf.outsidesp oc.tm.outsidesp oc.sisgraf.operational v.destroyed v.rc.operational v.sb.endest v.prelaunchphase v.initialphase v.intermediatephase, 0) normal: pre-condition: t Θ( remotedestruction, t) Θ( (v.sb.endest v.rc.operational oc.sisgraf.operational), t) invariant: t Φ(remoteDestruction, t) Φ(v.sb.enDest v.rc.operational oc.sisgraf.operational, t) operation: t Φ(remoteDestruction, t) Θ( (oc.cctv.outsidesp oc.sisgraf.outsidesp oc.tm.outsidesp), t) Θ( so.actdest, t) t Φ(remoteDestruction, t) Θ( so.actdest, t) Θ( v.sb.actdest, t) t Φ(remoteDestruction, t) Θ( v.sb.actdest, t) Θ( v.destroyed, t) post-condition: t Θ( remotedestruction, t) Θ( v.sb.endest, t) Θ( ( v.rc.operational oc.sisgraf.operational), t) Θ( v.destroyed, t) failure: t Φ(commission1_remoteDestruction, t) Φ(remoteDestruction, t) Φ(v.preLaunchPhase v.initialphase, t) Φ(so.actDest, t) t Φ(commission2_remoteDestruction, t) Φ(remoteDestruction, t) Φ(v.intermediatePhase, t) Φ( (oc.cctv.outsidesp oc.sisgraf.outsidesp oc.tm.outsidesp), t) Φ(so.actDest, t) t Φ(omission_remoteDestruction, t) Φ(remoteDestruction, t) Φ(v.intermediatePhase, t) Φ((oc.cctv.outsideSP oc.sisgraf.outsidesp oc.tm.outsidesp), t) Φ( so.actdest, t) t Φ(commission3_remoteDestruction, t) Φ(remoteDestruction, t) Φ(v.intermediatePhase, t) Φ( so.actdest, t) Φ(v.sb.actDest, t) Figura 2 - Ação cooperativa RemoteDestruction sistema. As operações associadas a esta ação cooperativa: uma vez que o operador habilita a destruição do sistema, a caixa de segurança também habilita a destruição que deve ser 5 segundos após a ruptura dos umbilicais. A pós-condição para que os componentes do sistema saiam da ação cooperativa é a inibição da destruição pela caixa de segurança, ou a destruição do veículo. A descrição do comportamento de falha inclui duas condições. Uma falha de comissão, quando a destruição do veículo é habilitada durante as fases de Pré-lançamento e Inicial. Uma falha de omissão, quando a destruição não é habilitada durante as fases Intermediária I e II. A Figura 2 mostra a ação cooperativa RemoteDestruction que descreve o comportamento dos componentes da teledestruição do veículo. A descrição do comportamento normal da ação cooperativa inclui a pré-condição para que os componentes do sistema entrem na ação cooperativa: a destruição está habilitada e os equipamentos estão operacionais. A invariante que estabelece as condições que devem ser mantidas durante a execução da ação cooperativa é: a destruição está habilitada e os equipamentos estão operacionais. A condição para a destruição remota pelo operador de segurança é a saída do veículo da ZNP. A pós-condição para que os componentes do sistema saiam da ação cooperativa é a destruição desabilitada, ou falha em um dos equipamentos, ou a destruição do veículo. A descrição do comportamentode falha inclui quatro condições que são apresentadas a seguir, três relacionadas à segurança e uma relacionada à missão. Uma falha de comissão, quando o veículo é destruído pelo operador durante as fases iniciais. Uma falha de omissão durante as fases intermediárias, quando os equipamentos estão operacionais, a destruição está habilitada, um dos equipamentos detecta o veículo fora da ZNP, mas o operador não destrói o veículo.

60 danos materiais ou perdas de vidas devido a queda de destroços G0 o veículo é destruído pelo operador de segurança quando a destruição está habilitada nas fases Pré-lançamento, Inicial e Final G1 o veículo não é destruído quando invade a ZP nas fases Intermediária I e II G2 o veículo é destruído pelo operador de segurança quando a destruição está habilitada G3 fases Pré-lançamento, Inicial e Final G6 falha na habilitação da destruição G4 falha do operador de segurança 1 falha nas entradas da caixa de segurança G5 falha na caixa de segurança t atraso < 5seg 2 falha no BC 3 falha no jumper dos umbilicais 4 Figura 3a - Árvore de falhas associada aos requisitos de segurança do modelo em linguagem natural Uma falha de comissão durante as fases intermediárias, quando o operador não destrói o veículo quando este sai da ZNP. E, por fim, outra falha de comissão (falha espúria), quando o veículo é destruído embora a destruição não tenha sido acionada pelo operador. 5.3 Diagramas de Árvores de Falha As árvores de falhas associadas aos requisitos de segurança dos dois modelos apontam o evento topo G0, como danos materiais ou perdas de vidas devido a queda de destroços e os outros nós das árvores são identificados por G1, G2, e asssim por diante. Os eventos básicos, que não podem ser mais decompostos, por exemplo, falha do operador de

61 Danos Materiais ou Perdas de Vidas devido a Queda de Destroços G0 o veículo é destruído nas fases Pré-lançamento, Inicial e Final G1 o veículo não é destruído quando invade a ZP nas fases Intermediária I e II G2 o veículo não é destruído quando invade a ZP G3 fases Intermediária I e II G10 o veículo invade a ZP e o operador de segurança não é informado G4 o veículo invade a ZP, o operador de segurança aciona a destruição, mas o veículo não é destruído G5 o veículo invade a ZP, o operador de segurança é informado, mas não aciona a destruição G6 veículo fora da ZNP 6 equipamentos sinalizam que o veículo está dentro da ZNP G7 veículo fora da ZNP 6 o operador de segurança aciona a destruição, mas o veículo não é destruído G8 veículo fora da ZNP 6 falha do operador de segurança 1 falha no CFTV 7 falha no SISGRAF 8 falha nas entradas da caixa de segurança ou na caixa de segurança G9 falha no telecomando 5 falha na caixa de segurança 2 falha no BC 3 falha no jumper dos umbilicais 4 Figura 3b - Árvore de falhas associada aos requisitos de segurança do modelo em linguagem natural

62 segurança, são identificados por números. As árvores de falhas associadas ao requisito de missão têm como evento topo o veículo é destruído em condições normais de vôo e, nos dois modelos, apenas dois eventos básicos: falha do operador de segurança e sinal espúrio aciona a destruição. Os diagramas das árvores de falhas associadas aos requisitos de segurança dos modelos em linguagem natural estão representados nas Figuras 3a e 3b, e em ação cooperativa, nas Figuras 4a e 4b. danos materiais ou perdas de vidas devido a queda de destroços G0 falha na destrição remota G1 falha de comissão 1: durante as fases de Pré-lançamento ou Inicial, a destruição e habilitada e o operador de segurança aciona a destruição do veículo G2 falha de omissão G3 a destruição e habilitada e o operador de segurança aciona a destruição do veículo G4 fases Pré-lançamento, Inicial e Final G7 falha de comissão: a destruição e habilitada por uma falha do equipamento G5 falha do operador de segurança 1 falha na caixa de segurança 2 falha nas entradas da caixa de segurança G6 falha no BC 3 falha no jumper dos umbilicais 4 Figura 4a - Árvore de falhas associada aos requisitos de segurança do modelo em ações cooperativas

63 danos materiais ou perdas de vidas devido a queda de destroços G0 falha na destruição remota G1 falha de comissão 1 G2 falha de omissão: durante as fases Intermediária I e II, o veículo está fora da ZNP, mas a destruição não é acionada G3 o veículo está fora da ZNP, mas a destruição não é acionada G4 fases Intermediária I e II G8 destruição não é acionada G5 veículo fora da ZNP 6 falha no telecomando 5 falha de omissão : a destruição do veiculo não é habilitada em t atraso >= 5seg G6 equipamentos sinalizam que o veículo está dentro da ZNP G7 falha do operador de segurança 1 falha na caixa de segurança 2 falha no BC, que não ativa a energização 3 falha no jumper dos umbilicais 4 falha no CFTV 7 falha no SISGRAF 8 Figura 4b - Árvore de falhas associada aos requisitos de segurança do modelo em ações cooperativas 6 AVALIAÇÃO DO MODELO DE AÇÕES COOPERATIVAS A avaliação do modelo de ações cooperativas foi feita comparando-se o conjunto de corte mínimo das árvores de falhas obtidas das descrições do sistema de teledestruição do foguete VS-40X em linguagem natural e em ações cooperativas. O objetivo era verificar se os eventos básicos levantados no modelo de ações cooperativas coincidiam com aqueles levantados no modelo da linguagem natural, que refletem o sistema atual.

64 Os seguintes conjuntos de corte mínimo, CCM, foram obtidos das árvores de falhas relativas aos requisitos de segurança: CCM linguagem natural = {3,1}, {4,1}, {2,1}, {6,7}, {6,8}, {6,2}, {6,3}, {6,4}, {6,5}, {6,1}; CCM ações cooperativas = {2,1}, {3,1}, {4,1}, {5,6}, {2,6}, {3,6}, {4,6}, {7,6}, {8,6}, {1,6}; e das árvores de falha relativas aos requisitos de missão: CCM linguagem natural = {1}, {9}; CCM ações cooperativas = {1}, {9}; Se os conjuntos de corte mínimo estivessem parcialmente sobrepostos ou complementares, as razões deveriam ser investigadas: uma nova falha poderia estar sendo criada ou removida ou os modelos seriam totalmente incompatíveis. Como os conjuntos de corte mínimo obtidos foram equivalentes, concluímos que o modelo avaliado é válido, pois considera todas as possíveis causas dos perigos associados ao sistema obtidas no modelo em linguagem natural, possuindo, portanto, o mesmo nível de confiança deste. modelagem de sistemas críticos. O mesmo processo de comparação qualitativa dos conjuntos de corte mínino das árvores de falha poderia ser utilizado, de forma geral, em sistemas evolutivos. Por exemplo, se o sistema de teledestruição do foguete de sondagem for substituído por um sistema de autodestruição, então uma análise similar à realizada neste artigo poderá ser empregada para verificar se o nível de confiança que temos atualmente na teledestruição pode ser obtido neste outro sistema. Uma vez que foi obtida evidência sobre a integridade da técnica orientada a objetos cooperativos, outra linha futura de trabalho seria a verificação formal de modelos baseados em ações cooperativas, através dos verificadores automáticos das propriedades de segurança de sistemas, bem como a realização de sua análise paramétrica. AGRADECIMENTOS Os autores agradecem o apoio financeiro e logístico da CAPES, do British Council, e do Instituto de Aeronáutica e Espaço, IAE. 7 CONCLUSÕES Quando se introduz uma nova técnica para a modelagem e análise de sistemas seguros contra falhas acidentais, existe a necessidade de se demonstrar de antemão que a técnica é confiável na sua utilização, isto é, a técnica tem condições de identificar pelo menos todos os eventos indesejáveis de um sistema que uma técnica existente poderia identificar. O objetivo deste artigo era demonstrar que a técnica orientada a objetos cooperativos é adequada para o modelamento e a análise de segurança de sistemas críticos. Para comprovar que confiança pode ser colocada na forma de representar as interações entre os componentes de um sistema através de ações cooperativas, foi feita uma comparação qualitativa dos conjuntos de corte mínimo das árvores de falhas dos modelos em linguagem natural e de ações cooperativas, do sistema de destruição de um veículo de sondagem. Os resultados deste estudo, através da validação do modelo do sistema de destruição baseado em ações cooperativas, demonstraram a integridade da técnica orientada a objetos cooperativos na REFERÊNCIAS BIBLIOGRÁFICAS DE LEMOS, Rogério, Safety Analysis of an Evolving Software Architecture. In: 5 TH IEEE HIGH ASSURANCE SYSTEM ENGINEERING SYMPOSIUM (HASE 00), Nov. 2000, Albuquerque. KECECIOGLU, Dimitri, Reliability Engineering Handbook, vol 2. New Jersey: Prentice Hall, DE LEMOS, Rogério, HALL, J. G., Extended RTL in the Specification and Verification of an Industrial Press. Hybrid Systems III. LECTURE NOTES IN COMPUTER SCIENCE Berlin, Alemanha, 1996, p HALL, J. G.; DE LEMOS, Rogério, ERTL: an Extension to RTL for the Specification, Analysis and Verification of Hybrid Systems. In: 8TH EUROMICROWORK. ON REAL-TIME SYSTEMS, Jun. 1996, L'Aquila. Proceedings... L'Aquila: 1996, pp. 3-8.

65 IDENTIFICAÇÃO DA NECESSIDADE DE ESPECIFICAÇÃO FORMAL NO PROJETO DE PROTOCOLOS CRIPTOGRÁFICOS Clóvis Freire Júnior Centro de Computação de Aeronáutica de Brasília - CCABR Comando da Aeronáutica - Ministério da Defesa Brasília - DF (61) ssi1@ccabr.maer.mil.br Luiz Antonio da Frota Mattos Departamento de Ciência da Computação Instituto de Ciências Exatas - Universidade de Brasília Brasília - DF (61) r 216 frota@cic.unb.br RESUMO Protocolos criptográficos são utilizados para implementação de serviços de segurança: sigilo, autenticação, integridade e não repúdio. Quando um protocolo é projetado com falhas, seus objetivos podem ser subvertidos por invasores. Durante a última década, vários métodos formais têm sido propostos a fim de analisar os protocolos criptográficos. Desta forma, linguagens formais de especificação de protocolos criptográficos vêm sendo utilizadas por analistas de protocolos. Nesta pesquisa é evidenciada a necessidade da utilização de linguagens formais de especificação também por projetistas dos protocolos a fim de garantir a correta utilização e implementação dos mesmos. Isto é feito com base na comparação de especificações formais por reconhecidos pesquisadores na área, Gavin Lowe, Stephen Brackin e Jon Millen. ABSTRACT Cryptographic protocols are used to implement security services: secrecy, integrity, authentication or nonrepudiation. When such protocols are unintentionally designed with flaws, intruders may attack its objectives. During last decade, formal methods have been proposed to design and analyze cryptographic protocols. So, formal cryptographic protocol specification languages have been used by protocol analysts. This work focus the need to use formal specification languages by protocol s designers to guarantee the right use and implementation of them. This is done by comparing formal specifications produced by recognizable researches in this field, Gavin Lowe, Stephen Brackin e Jon Millen. 1 INTRODUÇÃO Com a crescente demanda por aplicações através da Internet, como o ensino à distância, as redes privadas virtuais, o comércio eletrônico e outros, torna-se cada vez mais necessária a utilização de protocolos criptográficos. Isso porque agora não estamos mais em um ambiente fechado de uma rede local de computadores. Não conhecemos os usuários da rede pelos nomes, não sabemos onde trabalham, não possuímos informações que nos façam ter confiança nos processos. Precisamos que esta confiança seja assegurada pela forma como as transações eletrônicas são realizadas. Os protocolos criptográficos são utilizados para implementação de serviços de segurança tais como sigilo, que é a garantia de que somente os participantes legítimos do protocolo conhecem as informações transmitidas; integridade, significando que as mensagens trocadas pelos participantes do protocolo não foram alteradas durante a passagem pela rede; autenticação, que é a garantia de que são os participantes legítimos do protocolo que estão trocando mensagens; não-repúdio, significando que os participantes legítimos do protocolo não podem negar o envio ou o recebimento de mensagens do protocolo. No entanto, os protocolos criptográficos estão sujeitos a erros no desenvolvimento, erros estes que podem ocorrer em qualquer uma das fases do seu ciclo de vida. Uma análise de requisitos do protocolo criptográfico que não capture os reais requisitos do usuário, ou uma falha no projeto, ou uma falha na análise e na verificação de conformidade com os requisitos poderão levar ao desenvolvimento e implementação de um protocolo criptográfico que não garantirá os serviços de segurança desejados pelo usuário. Mesmo que um protocolo criptográfico seja desenvolvido de forma correta, ou seja, os requisitos sejam os reais requisitos do usuário e o projeto seja realizado de acordo com eles, ainda assim, não existirá a garantia de que o protocolo realizará os serviços de segurança para o qual foi desenvolvido. Isso porque, na utilização de um protocolo criptográfico, deve ser levada em conta a ação de agentes externos. Tais agentes externos são chamados de invasores ou intrusos, e são participantes da rede de computadores que tentam subverter os objetivos do protocolo criptográfico, a fim de impossibilitar a realização dos serviços de segurança pelos quais o protocolo é responsável. Esses invasores podem atacar os protocolos criptográficos das seguintes formas: pela substituição, modificação, exclusão ou criação das mensagens, ou pelo ataque aos algoritmos criptográficos utilizados. O desenvolvimento de protocolos criptográficos é, portanto, bastante complexo, e não é incomum que sejam descobertas falhas em protocolos criptográficos que já estejam sendo utilizados e estudados por vários anos. Um exemplo é um dos três protocolos criptográficos apresentados em 1978

66 por Roger Needham e Michael Schroeder no trabalho Using Encryption for Authentication in Large Networks of Computers, que ficou conhecido como Needham Schroeder conventional key protocol. Ele foi utilizado por mais de dois anos, até que, em 1981, os pesquisadores D. Denning e G. Sacco, no trabalho Timestamps in Key Distribution Protocols, demonstraram que ele possuía uma falha e propuseram um protocolo criptográfico alternativo (DENNING e SACCO, 1981). Tal protocolo foi utilizado por mais 13 anos, até que ABADI e NEEDHAM (1994) demonstraram que este também possuía falhas. Em 1995, Gavin Lowe apresentou um ataque, até então desconhecido, a outro dos protocolos do trabalho original de Needham e de Schroeder, o protocolo Needham Schroeder public key, e é notável que isso tenha ocorrido 17 anos depois de sua publicação (LOWE, 1995). Durante a última década, vários métodos formais têm sido propostos a fim de analisar e projetar protocolos criptográficos. Tais métodos formais se dividem basicamente em: métodos de construção de ataques, que utilizam a construção de conjuntos de possíveis ataques baseados em propriedades algébricas de modelos matemáticos de protocolos criptográficos; os métodos de construção de provas, que formalmente modelam a computação realizada nos protocolos criptográficos e realizam provas de teoremas acerca deste modelo de computação; e os métodos baseados em lógicas modais, que analisam a evolução dos conceitos de crença e de conhecimento aplicados aos agentes do protocolo criptográfico ao longo da execução do mesmo (MEADOWS, 1995; GRITZALIS, SPINELLIS e GEORGIADIS, 1999). Para utilização de tais métodos, os protocolos criptográficos devem ser traduzidos da notação nãoformal encontrada na literatura para uma notação formal. Assim, algumas linguagens formais de especificação de protocolos criptográficos foram propostas e vêm sendo usadas na análise dos mesmos (BRACKIN, 1997; LOWE, 1997a; MIILEN e DENKER, 2000). O objetivo desta pesquisa é mostrar que as linguagens formais de especificação devem ser utilizadas não só pelos analistas mas também pelos projetistas de protocolos criptográficos a fim de permitir a correta implementação dos protocolos. O trabalho está dividido em seis seções. Uma breve revisão bibliográfica é apresentada na segunda seção. Na seção 3, é discutida a metodologia empregada na pesquisa. Os resultados são apresentados na seção 4 e discutidos na seção 5. Por fim, na seção 6 é apresentada a conclusão. 2 REVISÃO BIBLIOGRÁFICA Para especificar formalmente os protocolos criptográficos, é necessário ter conhecimento dos seguintes pontos: 1. a lista de mensagens trocadas entre os agentes dos protocolos; 2. o significado de cada termo contido em cada uma das mensagens; 3. as suposições iniciais acerca das propriedades dos elementos das mensagens, tais como chaves criptográficas e funções de cifração, decifração e hash; 4. os objetivos dos protocolos. Destes, os objetivos são os mais negligenciados nas especificações não-formais usualmente encontradas na literatura. BOYD (1997) publicou um trabalho no qual discorre sobre os objetivos dos protocolos criptográficos. A questão dos objetivos é importante tanto para o projetista, como para o analista e para o implementador do protocolo criptográfico. Segundo Colin Boyd: o projetista deve fazer uso dos objetivos do protocolo criptográfico para justificar cada campo de mensagem e todo o processo criptográfico envolvido; o analista deve fazer uso dos objetivos do protocolo criptográfico para direcionar suas tentativas de encontrar novos ataques ao mesmo; o implementador do protocolo criptográfico deve perceber de forma clara quais os objetivos do mesmo a fim de trabalhar dentro desses requisitos. Os protocolos criptográficos de autenticação podem possuir dois objetivos distintos, a autenticação dos agentes do protocolo e o estabelecimento de uma chave secreta para comunicação entre dois ou mais agentes. Segundo alguns autores, o objetivo de autenticação de agentes ainda pode ser subdvidido em vários outros, refinando o grau de autenticação que pode ser obtido ao final do protocolo. ABADI (1998) sugeriu a existência de dois tipos de objetivos de autenticação, LOWE (1997b) propôs uma hierarquia de objetivos de autenticação com seis subdivisões, e SCHNEIDER (1996) classificou nove tipos em seu trabalho. Bill Roscoe, no trabalho Intensional Specifications of Security Protocols (9 th IEEE Computer Security Foundations Workshop), propôs uma divisão dos objetivos entre aqueles que devem ser trabalhados pelos projetistas e os que devem ser observados pelos analistas. Todos estes autores citam a falta de formalismo na especificação dos protocolos como fator que compromete a segurança na implementação dos mesmos. No entanto, os esforços desprendidos por tais autores têm sido na proposição de linguagens de especificação formal para uso dos analistas de protocolos e não na sua utilização por parte dos projetistas. (FREIRE, 2000)

67 3 METODOLOGIA Com o intuito de mostrar a necessidade de especificação formal por parte dos projetistas, foram estudadas as especificações de objetivos de vários protocolos relacionados na compilação realizada por CLARK e JACOB (1997). Foram analisados os objetivos de 41 desses protocolos criptográficos, especificados em três linguagens formais por três reconhecidos pesquisadores na área: Gavin Lowe, usando a linguagem CASPER (LOWE, 1997a); Stephen Brackin, com a linguagem ISL (BRACKIN, 1997); e Jonathan Millen, que revisou um conjunto de especificações na linguagem CAPSL produzidas por FREIRE (2000). Os objetivos foram classificados entre os de estabelecimento de chave secreta e os de autenticação de agentes do protocolo. Foram comparados os objetivos especificados por cada autor e, para cada protocolo, verificou-se as diferenças encontradas. As especificações dos protocolos na linguagem ISL estão disponíveis em publicação de BRACKIN (1999). As especificações em CAPSL podem ser encontradas no site dedicado à linguagem ( Já as especificações na linguagem CASPER não foram publicadas, estando somente referenciadas (LOWE, DONAVAN e NORRIS, 1999). Desta feita, um contato com o pesquisador Gavin Lowe foi realizado e o mesmo, após tomar conhecimento do trabalho a ser desenvolvido, forneceu o conjunto de especificações em CASPER feitas por ele e por dois de seus então alunos, Ben Donavan e Paul Norris. 4 RESULTADOS Os objetivos dos protocolos compilados por Clark e Jacob, conforme análise de Gavin Lowe, Stephen Brackin e Jon Millen, encontram-se listados na Tabela 1. Os protocolos são identificados pelo nome e pelo número em que são referenciados na lista de Clark e Jacob. Nas especificações utilizando a linguagem ISL, os objetivos especificados na forma genérica: A Believes B Conveyed F, onde A e B são agentes do protocolo e F é um dos termos trocados nas mensagens, foram classificados como objetivos de autenticação e representados por: B autentica-se frente a A com base em F. Os objetivos especificados na forma: B Believes SharedSecret A B K; A Believes SharedSecret A B K; onde A e B são agentes do protocolo e K é uma chave criptográfica, foram classificados como objetivos de estabelecimento de chaves e representadas por : K é segredo compartilhado por A e B. Nas especificações realizadas por Gavin Lowe usando a linguagem CASPER, os objetivos especificados na forma genérica: Agreement(A,B,F), onde A e B são agentes do protocolo e F é um dos termos trocados nas mensagens, foram classificados como objetivos de autenticação e representados por: A autentica-se frente a B com base em F. Os objetivos especificados na forma: Secret(A,F,[B]); onde A e B são agentes do protocolo e F um dos termos usados nas mensagens, foram classificados como objetivos de estabelecimento de chaves e representadas por : F é segredo compartilhado por A e B. E por fim, nas especificações em CAPSL revisadas por Jon Millen, os objetivos especificados na forma genérica: PRECEDES A: B F, onde A e B são agentes do protocolo e F é um dos termos trocados nas mensagens, foram classificados como objetivos de autenticação e representados por: A autentica-se frente a B com base em F. Os objetivos especificados na forma: SECRET K: A,B; onde A e B são agentes do protocolo e K um dos termos usados nas mensagens, foram classificados como objetivos de estabelecimento de chaves e representadas por : K é segredo compartilhado por A e B. TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continua) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL ISO Symmetric Key One-Pass Unilateral Authentication Protocol ISO Symmetric Key Two-Pass Unilateral Authentication Protocol com base em {Na,B,Text1}Kab com base em {Rb,B,Text2}Kab com base em Na com base em Rb com base em Na, Text1 com base em Rb, Text2

68 TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continuação) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL ISO Symmetric Key Two-Pass Mutual Authentication Protocol ISO Symmetric Key Three-Pass Mutual Authentication Using Non- Reversible Functions com base em {Na,B,Text1}Kab B autentica-se frente a A com base em {Nb,A,Text3}Kab com base em {Ra,Rb,B,Text2}Kab B autentica-se frente a A com base em {Rb,Ra,Text4}Kab K é segredo compartilho por A e B com base em K B autentica-se frente a A com base em K com base em Na B autentica-se frente a A com base em Nb com base em Ra, Rb B autentica-se frente a A com base em Rb Ra é segredo compartilhado por A e B Na é segredo compartilhado por A e B com base em Ra B autentica-se frente a A com base em Ra, Rb com base em Na, Text1 B autentica-se frente a A com base em Nb, Text3 com base em Ra, Rb, Text2 B autentica-se frente a A com base em Rb, Ra, Text4 Ra é segredo compartilhado por A e B K é segredo compartilhado por A e B com base em Rb, Ra, K B autentica-se frente a A com base em Rb, Ra K Andrew Secure RPC Protocol K_ab é segredo compartilhado por A e B com base em {Nb+1}Kab B autentica-se frente a A com base em {Na+1,Nb}Kab com base em Na, Nb B autentica-se frente a A com base em Na, Nb Na e Nb são segredos compartilhados por A e B K_ab é segredo compartilhado por A e B com base em Na, Nb B autentica-se frente a A com base em Na, Nb, K_ab, N_b ISO One-Pass Unilateral Authentication with CCFs ISO Two-Pass Unilateral Authentication with CCFs ISO Two-Pass Mutual Authentication with CCFs com base em sha(kab,ta,b,text1) com base em Na com base em Na,Text1 com base em sha(kab,rb,b,text2) com base em Rb com base em Rb,Text2 com base em sha(kab,ta,b,text1) B autentica-se frente a A com base em sha(kab,tb,a,text3) com base em Na B autentica-se frente a A com base em Nb com base em Na, Text1 B autentica-se frente a A com base em Nb, Text ISO Three-Pass Mutual Authentication with CCFs com base em sha(kab,ra, Rb,B,Text2) B autentica-se frente a A com base em sha(kab,rb,ra,text4) com base em Ra B autentica-se frente a A com base em Rb com base em Ra, Rb, Text2 B autentica-se frente a A com base em Rb, Ra, Text Needham Schroeder Protocol with Conventional Keys Kab é segredo compartilhado por A e B com base em Kab B autentica-se frente a A com base em Kab Protocolo Não Especificado Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab, Nb

69 TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continuação ) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL Denning Sacco Protocol Otway-Rees Protocol Amended Needham Schroeder Protocol Wide Mouthed Frog Protocol Kab é segredo compartilhado por A e B Kab é segredo compartilhado por A e B Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab Kab é segredo compartilho por A e B Yahalom Kab é segredo compartilhado por A e B com base em Kab Carlsen s Secret Key Initiator Protocol ISO Four-Pass Authentication Protocol Kab é segredo compartilhadoda por A e B B autentica-se frente a A com base em Kab com base em Kab Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab com base em Kab B autentica-se frente a A com base em Kab Kab é segredo compartilhado por A e B com base em Nb com base em Kab Kab é segredo compartilhado entre A, B e S Nb é segredo compartilhado entre A,B e S com base em Nb B autentica-se frente a A com base em Na B autentica-se frente a A com base em Kab com base em Kab B autentica-se frente a A com base em Kab, Text7 com base em Kab, Text5 Kab é segredo compartilhado por A e B S autentica-se frente a A com base em Kab, Tm com base em Kab, Tm Kab é segredo compartilhado por A e B S autentica-se frente a B com base em Kab, Nb S autentica-se frente a A com base em Kab, Na Kab é segredo compartilhado por A e B com base em Kab, Nb B autentica-se frente a A com base em Kab, Nb Kab é segredo compartilho por A e B S autentica-se frente a B com base em Kab, A, Ts A autentica-se frente a S com base em Kab, B, Ta Kab é segredo compartilhado por A e B com base em Kab, Nb Kab é segredo compartilhado por A e B com base em Kab, N_b Kab é segredo compartilhado por A e B com base em Kab, Na, Text5 B autentica-se frente a A com base em Kab, Nb, Text7

70 TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continuação ) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL ISO Five-Pass Authentication Protocol Woo and Lam Authentication Protocol Pi Woo and Lam Authentication Protocol Pi Woo and Lam Authentication Protocol Pi 2 Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab A autentica-se frente a S com base em Nb com base em Nb A autentica-se frente a S com base em Nb com base em Nb A autentica-se frente a S com base em Nb com base em Nb B autentica-se frente a A com base em Text6 com base em Text5, Text6 com base em Nb com base em Nb com base em Nb Kab é segredo compartilhado por A e B com base em Text8, Ra, Rb B autentica-se frente a A com base em Text6, Ra, Rb com base em Nb com base em Nb com base em Nb Woo and Lam Authentication Protocol Pi 3 A autentica-se frente a S com base em Nb com base em Nb com base em Nb com base em Nb Woo and Lam Authentication Protocol Pi f A autentica-se frente a S com base em Nb com base em Nb com base em Nb com base em Nb Woo and Lam Mutual Authentication Protocol Kpq é segredo compartilhado por P e Q P autentica-se frente a Q com base em Kpq Q autentica-se frente a P com base em Kpq P autentica-se frente a Q com base em Kpq Q autentica-se frente a P com base em Kpq Kpq é segredo compartilhado por P e Q P autentica-se frente a Q com base em, N2 Q autentica-se frente a P com base em N2, N Needham- Schoreder Signature Protocol A autentica-se frente a S com base em msg com base em msg com base em msg com base em msg Neumen Stubblebine parte1 Kab é segredo compartilhado por A e B com base em Kab com base em Kab B autentica-se frente a A com base em nenhum termo Kab é segredo compartilhado por A e B com base em Nb, Kab Neumen Stubblebine parte2 Kab é segredo compartilhado por A e B com base em Kab B autentica-se frente a A com base em Kab com base em nenhum termo B autentica-se frente a A com base em nenhum termo com base em N_b, Kab B autentica-se frente a A com base em N_a, Kab Kehne Langendorfer Schoenwalder parte1 Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab Protocolo Não- Especificado Kab é segredo compartilhado por A e B com base em Nc, Kab

71 TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continuação ) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL Kehne Langendorfer Schoenwalder parte The Kao Chow Repeated Authentication Protocol The Kao Chow Repeated Authentication Protocol - 2 Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab Kab é segredo compartilhado por A e B Kt é segredo compartilhado por A e B B autentica-se frente a A com base em Kab com base em Kab B autentica-se frente a A com base em Kab com base em Kab B autentica-se frente a A com base em Kab com base em Nb B autentica-se frente a A com base em Kab com base em Nb com base em N_b, Kab B autentica-se frente a A com base em N_a, Kab Kab é segredo compartilhado por A e B B autentica-se frente a A com base em Na com base em Nb Kab é segredo compartilhado por A e B Kt é segredo compartilhado por A e B B autentica-se frente a A com base em Na, Kab com base em Nb, Kab The Kao Chow Repeated Authentication Protocol - 3 Kab é segredo compartilhado por A e B Kt é segredo compartilhado por A e B B autentica-se frente a A com base em Kt B autentica-se frente a A com base em Kab com base em Nb Kab é segredo compartilhado por A e B Kt é segredo compartilhado por A e B B autentica-se frente a A com base em Na, Kab com base em Nb, Kab ISO Public Key One-Pass Unilateral Authentication Protocol ISO Public Key Two-Pass Unilateral Authentication Protocol Iso Public Key Two-Pass Mutual Authentication Protocol com base em {Na,B,Text1}Ka com base em Na,Text1 com base em Na,Text1 com base em {Ra,Rb,B,Text2}Ka com base em Ra,Rb,Text2 com base em Ra,Rb,Text2 com base em {Na,B,Text1}Ka B autentica-se frente a A com base em {Nb,A,Text3}Ka com base em Na,Text1 B autentica-se frente a A com base em Nb,Text3 com base em Na,Text1 B autentica-se frente a A com base em Nb,Text Iso Three Pass Parallel Mutual Authentication Protocol com base em {Ra,Rb,B,Text2}Ka B autentica-se frente a A com base em {Rb,Ra,A,Text4}Kb com base em Ra,Rb,Text2,Text4 B autentica-se frente a A com base em Rb com base em Ra,Rb,Text2 B autentica-se frente a A com base em Rb, Ra, Text ISO Two-Pass Parallel Mutual Authentication Protocol com base em {Ra,Rb,B,Text3}Ka B autentica-se frente a A com base em {Rb,Ra,A,Text5}Kb com base em Rb,Text5 B autentica-se frente a A com base em Ra com base em Ra,Rb,Text3 B autentica-se frente a A com base em Rb, Ra, Text5

72 TABELA 1. Objetivos de protocolos criptográficos segundo Stephen Barckin, Gavin Lowe e Jon Millen (continuação ) Protocolo Brackin - ISL Lowe - CASPER Millen - CAPSL Bilateral Key Exchange with Public Key Needham- Schroeder Public Key Protocol Hwang and Chen s Modified SPLICE/AS K é segredo compartilhado por A e B com base em K B autentica-se frente a A com base em Nb, Ka com base em Nb, Kb Não especificado com base em K B autentica-se com A com base em K NA e Nb são segredos compartilhados por A e B com base em Na e Nb B autentica-se frente a A com base em Na e Nb C autentica-se frente a S com base em N2 S autentica-se frente a C com base em N2 K é segredo compartilhado por A e B com base em Nb B autentica-se frente a A com base em Na com base em Nb B autentica-se frente a A com base em Na C autentica-se frente a S com base em N2 S autentica-se frente a C com base em N2 A Figura 1 mostra o número de vezes em que ocorreu concordância entre os autores com respeito a existência ou não do objetivo de estabelecimento de chaves. 21 Dos 19 protocolos que atingiram essa condição, em 17 Millen e Brackin concordaram quanto a que termo deveria ser mantido em segredo. Houve concordância entre os três pesquisadores em Brackin, Lowe e Millen -21 Brackin e Lowe - 0 Brackin e Millen -16 Millen e Lowe -4 FIGURA 1. Concordância com respeito a existência ou não do objetivo de estabelecimento de chaves Em 21 dos 41 protocolos os três pesquisadores concordaram quanto a existência ou não desse objetivo. No entanto, em outros 20 protocolos, pelos menos um pesquisador teve uma interpretação diferente dos protocolos. Na Figura 2 pode ser observado o número de vezes em que os autores concordaram quanto a que 17 somente um protocolo especificado. A Figura 3 traz o número de vezes em que os autores concordaram quanto a existência ou não de objetivos de autenticação de agentes. Em 23 dos 41 protocolos, os três autores concordaram quanto a existência de objetivos de autenticação. Em outros 18 protocolos Brackin, Lowe e Millen -1 Brackin e Lowe - 0 Brackin e Millen - 17 Millen e Lowe - 1 Discordam -0 FIGURA 2. Concordância com respeito a que termo deveria ser mantido em segredo para atingir o objetivo de estabelecimento de chaves. termo deveria ser mantido em segredo, nos protocolos em que pelo menos dois autores consideraram a existência do objetivo de estabelecimento de chaves. especificados, ocorreu alguma discordância. A discordância total em 4 protocolos representa a discordância entre dois autores e a não especificação do protocolo pelo terceiro.

73 Brackin, Lowe e Millen - 23 Brackin e Lowe - 2 Brackin e Millen - 3 Millen e Lowe -9 Discordam - 4 FIGURA 3. Concordância com respeito a existência ou não do objetivo de autenticação de agentes. Na Figura 4 é mostrado o número de vezes em que ocorreu concordância entre as especificações com respeito a autenticação entre dois agentes específicos do protocolo com base em um determinado termo, nos protocolos que pelo menos dois autores consideraram a existência do objetivo de autenticação de entidades. Observando a Figura 3 é possível constatar que quando se trata da existência ou não do objetivo de autenticação de agentes, os autores concordaram em pouco mais da metade dos protocolos. Ao analisar a Figura 4, percebemos que quando existe concordancia quanto a existência do objetivo de autenticação, os autores, na maioria dos casos, Brackin, Lowe e Millen -0 Brackin e Lowe -5 Brackin e Millen -0 Millen e Lowe -11 Discordam - 25 FIGURA 4. Concordância com respeito a autenticação entre dois agentes específicos do protocolo com base em um determinado termo. Dos 41 protocolos, em 25 houve discordância total entre os três pesquisadores, cada um especificou ou agentes diferentes a serem autenticados ou termos diferentes a serem usados para permitir a autenticação. Não houve concordância entre os três autores em nenhum dos protocolos especificados. 5 DISCUSSÃO Com base na Figura 1, é possível observar que houve concordância entre os autores, quanto a existência ou não de objetivos relativos ao estabelecimento de chaves, em apenas parte dos protocolos especificados. Em 16 dos casos, Millen e Brackin concordaram entre si e discordaram de Lowe, ou seja, em quase metade dos casos, os três autores não concordaram nem mesmo quanto a existência do objetivo de estabelecimento de chaves quando analisaram os mesmos protocolos. Na Figura 2 pode ser visto que quando comparados apenas os protocolos que possuem dentre seus objetivos o estabelecimento de chaves, Brackin e Millen concordaram em quase todas as vezes quanto a qual termo deveria ser segredo para os agentes do protocolo. discordam quanto a que agente se autentica e com base em qual termo. 6 CONCLUSÃO Considerando que, com base nessas especificações, foram realizadas análises dos protocolos e tais análises tentam verificar se os protocolos atingem os objetivos propostos, devemos reconsiderar a validade dessas análises já que não existe consenso quanto a quais são os reais objetivos dos protocolos. Também devemos observar que se três reconhecidos pesquisadores da área de especificação e análise de protocolos criptográficos não concordam quanto aos objetivos dos protocolos, o que dizer de profissionais menos capacitados que tentam implementar protocolos a partir da descrição não-formal encontrada na literatura? Se é difícil identificar os objetivos de um protocolo, observamos que ainda mais difícil é obter as suposições iniciais a respeito dos termos utilizados nas mensagens trocadas e sobre os estados iniciais dos agentes do protocolo. Tais dados são essenciais para a correta implementação do protocolo e a obtenção do mecanismo de segurança desejado.

74 Desta forma, é possível verificar que as especificações formais realizadas pelos projetistas são necessárias para a garantia da correta utilização dos protocolos criptográficos. AGRADECIMENTOS Os autores agradecem à Gavin Lowe, por fornecer as especificações em CASPER dos protocolos da lista de Clark e Jacob, e também ao Centro de Computação de Aeronáutica de Brasília (CCABR) e ao Departamento de Ciência de Computação da Universidade de Brasília, pelo apoio que possibilitou o desenvolvimento dessa pesquisa. REFERÊNCIAS BIBLIOGRÁFICAS ABADI, M. and NEEDHAM, R. Prudent Engineering Practice for Cryptographic Protocols. Digital Systems Research Center, SRC Research Report 125. June 1994 ABADI, Martin. Two facets of authentication. In 11 th IEEE Computer Security Foundations Workshop, IEEE Computer Society. June pp BOYD, C. Towards Extensional Goals in Authentication Protocols. Proceedings of the 1997 DIMACS Workshop on Design and Formal Verification of Security Protocols BRACKIN, Stephen. Automatic Formal Analyses of Cryptographic Protocols. Proceedings of the 19th National Conference on Information Systems Security. October An interface specification language for automatically analyzing cryptographic protocols. Symposium on Network and Distributed System Security Complete, Automatic Analysis of Cryptographic Protocols: Sixth Quarterly Report. Published as ATR9905, Arca Systems, Inc. January CLARK, J. and JACOB, J. A Survey of Authentication Protocol Literature: Version November [cited March 2000]. Available from Internet. < www-users. cs. york. ac. uk/~jac/papers/drareviewps. ps >. DENNING, D. and SACCO, G. Timestamps in Key Distribution Protocols. Communcations of the ACM. August 1981 apud CLARK, J. and JACOB, J. A Survey of Authentication Protocol Literature: Version November [cited March 2000]. Available from Internet. <http :// ~jac/ >. FREIRE, C. Aplicação da CAPSL na Especificação de Protocolos Criptográficos. Dissertação de Mestrado, Departamento de Ciência da Computação, Instituto de Ciências Exatas, Universidade de Brasília. Junho GRITZALIS, S., SPINELLIS, D. and GEORGIADIS, P. Security protocols over open networks and distributed systems: Formal methods for their analysis, design, and verification. Computer Communications, 22(80). May pp LOWE, G. An Attack on the Needham-Schroeder Public-Key Authentication Protocol. Information Processing Letters, volume 56, number pp Casper: A Compiler for the Analysis of Security Protocols. Proceedings of 10 th IEEE Computer Security Foundations Workshop. 1997a.. A Hierarchy of Authentication Specifications. Proceedings of 10 th IEEE Computer Security Foundations Workshop. 1997b. LOWE, G., DONAVAN, B. and NORRIS, P., Analyzing a Library of Security Protocols using Casper and FDR. Workshop on Formal Methods and Security Protocols MEADOWS, Catherine. Formal verification of cryptographic protocols : a survey. Advances in Cryptology, Proceedings of ASIACRYPT 94, Springer Verlag pp MILLEN, J. and DENKER, G. CAPSL Integrated Protocol Environment. DARPA Information Assurance Conference. January SCHNEIDER, S. Security propertis and CSP. In IEEE Computer Society Smposium on Security and Privacy, Oakland

75 FALSIFICAÇÃO DE ENDEREÇOS IP: UM PERIGO QUE RONDA OS SERVIÇOS DE RESOLUÇÃO DE NOMES NA INTERNET Claudio de Castro Monteiro CEULP Centro Universitário Luterano de Palmas Curso de Bacharelado em Sistemas de Informação GPARC Grupo de Pesq. Aplicada em Redes de Computadores Vagner José Sacramento CEULP Centro Universitário Luterano de Palmas Curso de Bacharelado em Sistemas de Informação GPARC Grupo de Pesq. Aplicada em Redes de Computadores RESUMO O serviço DNS é amplamente utilizado, e extremamente necessário na Internet para resolução de nomes. Mesmo as redes que possuem firewalls e outros mecanismos de defesas não ignoram este serviço, aceitando e permitindo a passagem de pacotes que se destinam a aplicação DNS. Sendo assim, técnicas minuciosas podem ser utilizadas para explorar vulnerabilidades ou facilidades existentes neste serviço, ocasionando grandes transtornos e prejuízos para os administradores de rede e usuários finais. Esta pesquisa foi realizada com a finalidade de comprovar a veracidade da falsificação de endereços IP's na resolução de nomes de domínios, em servidores DNS configurados sob os sistemas operacionais Linux e WindowsNT. Após a implementação da falsificação de endereços IP's em servidores DNS, rodando nos sistemas operacionais citados, concluímos que eles se encontram vulneráveis, podendo ter seu cache poluído. ABSTRACT The service DNS is used thoroughly, and extremely necessary in the Internet for resolution of names. Even the nets that possess firewalls and other mechanisms of defenses don't ignore this service, accepting and allowing the passage of packages that are destined the application DNS. Being like this, meticulous techniques can be used to explore vulnerabilidades or existent means in this service, causing great upset and damages for the net administrators and final users. This research was accomplished with the purpose of checking the truthfulness of the falsification of addresses IP's in the resolution of names of domains, in servers DNS configured under the operating systems Linux and WindowsNT. After the implementation of the falsification of addresses IP's in servers DNS, rotating in the mentioned operating systems, we concluded that they meet vulnerable, could have its polluted cache. 1 INTRODUÇÃO A maioria das redes que compõem a Internet usufruem dos serviços de DNS (Domain Name System) para resolução de nomes de domínios. As redes que possuem sistemas defensivos não ignoram estes serviços, aceitando e permitindo a passagem de pacotes que se destinam a aplicação DNS. A partir da afirmação de que a maioria das redes não restringem o tráfego de pacotes destinados aos serviços de DNS, técnicas de ataques mais sofisticadas podem ser aplicadas, fazendo com que uma simples requisição de resolução de nome aparentemente normal, possa ocasionar um ataque ao servidor DNS da rede. A partir do estudo realizado sobre os protocolos que compõem a suite 1 TCP/IP, podemos identificar uma série de falhas na implementação de diversos protocolos[1], permitindo que certos tipos de ataques sejam aplicados, inclusive o que envolve a falsificação de endereços IP fornecidos por servidores DNS na resolução de nomes de domínios(dns SPOOF). O DNS SPOOF utiliza diversos recursos para realizar a falsificação de IP na resolução de nomes de um determinado servidor DNS. Um recurso utilizado é o IP SPOOF, que consiste nas facilidades que o protocolo IP oferece 1 Conjunto de protocolos no preenchimento de pacotes IP, de acordo com as necessidades de um atacante, técnicas como DNS SPOOF, BLIND SPOOF, HIJACKING SPOOF, ICQ SPOOF e outros, simplesmente utilizam essa facilidade. Essa pesquisa tem o propósito de expor pontos vulneráveis em um dos serviços mais utilizados na Internet(DNS), mostrando aspectos práticos das conseqüências e da implementação da falsificação de endereços IP's na resolução de um determinado nome de domínio fornecido por servidores DNS, disponibilizando a informação para sociedade, para que todos saibam da existência de algumas vulnerabilidades que podem ser exploradas nos serviços de nomes, e possam aprimorar as medidas de segurança implantadas em suas redes, não permitindo que os únicos possuidores de tais conhecimentos sejam os invasores. 2 CONSIDERAÇÕES SOBRE OS PROTOCOLOS IP E UDP Cada host 2 na Internet é identificado de forma unívoca através do endereço IP atribuído na sua configuração. Os endereços IP's estão associados às 2 Equipamento com uma ou mais interface de comunicação interligado na rede.

76 interfaces de rede e não aos hosts que as contêm O protocolo IP defini o esquema de endereçamento desses hosts. Este protocolo se encontra na camada de rede da arquitetura TCP/IP conforme mostrado na figura abaixo. Fig. 1 - Arquitetura TCP/IP O protocolo IP carrega consigo informações necessárias para identificar um host tais como origem ou destino de um pacote. Na figura abaixo é mostrado a estrutura deste protocolo [8] Vers Hlen Service Type Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source IP Address Destination IP Address Options (if any) Data... Fig. 2 Estrutura do Protocolo IP Padding O protocolo IP transfere dados entre os hosts através de datagramas. Esses datagramas são entregues para o endereço referenciado no campo destination address do protocolo IP [8]. Em conjunto com o protocolo IP podemos utilizar o protocolo UDP da camada de transporte para gerenciar o processo de transmissão dos pacotes pela rede. O UDP é um protocolo não orientado a conexão e não confiável, não tendo controle de envio de datagramas entre uma aplicação e outra. A aplicação assume toda a responsabilidade pelo o controle de erros, dentro do nível de qualidade de serviço que a mesma requer. A figura abaixo mostra a estrutura do pacote UDP. Porta origem Tamanho DATA Porta destino Checksum Fig. 3 Estrutura do protocolo UDP Um datagrama UDP pode conter opcionalmente uma soma de checksum que irá testar a integridade dos datagramas recebidos. Os datagramas corrompidos são descartados e devem ser recuperados pela aplicação [8]. Para identificar para qual aplicação destina-se um pacote recebido, é utilizado na camada de transporte o conceito de porta (port). Essa porta é representada por um número inteiro que é associado a uma aplicação a partir da negociação com o sistema operacional. Existem aplicações que tem o número da sua porta padronizada, conhecida mundialmente. Algumas dessas aplicações são : DNS, FTP, TELNET, HTTP etc. Para calcular o checksum conforme o exigido pelos padrões de implementação do protocolo UDP(RFC 768) é necessário utilizar um pseudo cabeçalho que contém algumas informações do protocolo IP. Como podemos ver no código transcrito abaixo os tipos de informações tratadas pelo pseudo cabeçalho são: endereço IP de origem, endereço IP de destino, tipo de protocolo utilizado e o tamanho do pacote UDP.... struct pseudo_udp_header *pseudo=null; pseudo = (struct pseudo_udp_header *) ((char *)udp2-12); bzero((char *)pseudo,sizeof(struct pseudo_udp_header)); pseudo->source.s_addr = source; pseudo->dest.s_addr = dest; pseudo->zero = 0; pseudo->protocol = IPPROTO_UDP; pseudo->length = htons(udphdrsize); udp->source = htons(sport); udp->dest = htons(dport); udp->len = htons(udphdrsize + datasize); udp->check = in_cksum((u_short *)pseudo,20); /*Desfazendo do Pseudo Cabeçalho*/ bzero((char *)pseudo,sizeof(struct pseudo_udp_header));... 3 O SERVIÇO DE NOMES Os serviços de nomes são utilizados para facilitar a identificação da origem de uma determinada informação. É mais simples a utilização do nome do que o endereço IP , sendo que ambos referenciam a mesma máquina. Os responsáveis por traduzir o nome de domínio para o seu respectivo endereço IP são os servidores DNS [6]. A comunicação entre as máquinas pertencente as diversas redes que compõem a Internet, ocorre baseando-se nos endereços IP's e não nos nomes de domínios. Sendo assim, podemos requisitar algum serviço que esteja disponível em uma determinada

77 máquina localizada em algum lugar do mundo, tanto digitando o seu endereço IP quanto digitando o seu nome, pois ambos referenciam a mesma máquina. A única diferença é que quando for digitado o nome da máquina, será requisitado os serviços do servidor DNS na resolução do nome de domínio para o seu respectivo endereço IP [5]. Abaixo são mostradas algumas informações sobre as máquinas citadas no exemplo logo a seguir = mascote.mydomain.com = dns.mydomain.com = dns.ola.com = ns.internic.net = ns.com :53 = dns.ola.com Formato do pacote enviado: Endereço IP: PortaÆ Endereço IP: Porta No exemplo a ser detalhado, o cliente mascote.mydomain.com tenta acessar o site O primeiro passo realizado foi questionar o servidor DNS primário da rede (dns.mydomain.com) pelo endereço IP da máquina www que pertence ao domínio ola.com, para que logo em seguida seja possível requisitar a página web. [mascote.mydomain.com] [dns. mydomain.com] : :53 [A? No exemplo acima foi enviado uma requisição para resolução do nome ( a fim de obter o endereço IP correspondente. Essa requisição foi enviada para o servidor DNS primário da rede utilizando a porta de origem 2000 e a porta de destino 53 (Porta padrão em que todos servidores DNS atendem requisições). Logo em seguida, o servidor DNS tentará resolver o nome informado por mascote.mydomain.com. [dns.mydomain.com] [ns.internic.net] : :53 [dns? Como o servidor DNS (dns.mydomain.com) não tem autoridade sob o domínio ola.com ele pergunta ao servidor ns.internic.net qual é o servidor de nomes que responde pelo domínio ola.com, caso ele não saiba ele envia uma resposta para dns.mydomain.com informando o servidor DNS que tem autoridade sob todos domínios '.com'. [ns.internic.net] [dns.mydomain.com] : :53 [ns para.com é ] Logo em seguida, dns.mydomain.com enviará uma requisição para o servidor de nomes responsável por todos domínios '.com' perguntando a ele qual é o endereço IP do servidor DNS que tem autoridade sob o domínio ola.com. [dns.mydomain.com] [ns.com] : :53 [dns?ola.com] Resposta de ns.com é mostrada abaixo: [ns.com] [dns.mydomain.com] : :53 [O dns de ola.com é: ] Note que agora o servidor dns.mydomain.com conhece o endereço IP do servidor de nomes responsável pelo domínio ola.com. Em seguida, ele enviará uma pergunta para este servidor questionando qual é o endereço IP da máquina [dns.mydomain.com] [dns.ola.com] : :53 [A? Resposta de dns.ola.com será então: [dns.ola.com] [dns.mydomain.com] : :53 [ == ] Agora que o servidor dns.mydomain.com sabe o endereço IP da máquina ele armazena esta informação em cache por um determinado tempo, enviando logo em seguida uma resposta para o cliente mascote.mydomain.com. [dns.mydomain.com] [mascote.mydomain.com] : :2000 [ == ] A partir do momento em que mascote.mydomain.com conhece o endereço IP de ele pode requisitar a página web. [mascote.mydomain.com] [ : :80 [pede página web - GET /index.htm] Os passos mostrados acima, demostram o funcionamento básico de um servidor DNS, para resolução de um nome de domínio em que ele não tem autoridade. Logo após a resolução do nome de domínio questionado, o servidor DNS está apto a responder para qualquer cliente DNS que, o endereço IP da máquina é enquanto esta informação não expirar em seu cache.

78 3.1 Formato do Pacote DNS e Descrição da sua Estrutura Todas comunicações que envolvem o protocolo DNS, apresentam um simples formato de mensagem dividida em 5 seções [4]: Cabeçalho Pergunta(s) Resposta(s) Autoridade(s) Adicional Fig. 4 Formato de uma mensagem enviada por um servidor DNS a) A seção de cabeçalho sempre está presente. O cabeçalho inclui campos que especificam quais das seções restantes estão presentes, e também especifica se a mensagem é uma pergunta ou uma resposta. b) A seção de pergunta contém campos que descrevem uma pergunta a um servidor de nome. Estes campos descrevem um tipo de pergunta(tipo DE QUERY), uma classe da pergunta (TIPO DE CLASSE), e um nome de domínio (Nome a ser resolvido). As últimas três seções têm o mesmo formato. c) A seção de resposta contém registros que responde uma pergunta; d) Seção de autoridade contém registros que aponta para um ou mais servidor(es) de nome(s) que tem autoridade sob o domínio em questão; e) A seção de registros adicional contém informações adicionais sobre a pergunta realizada, mas não é estritamente respostas para a pergunta. Como todos protocolos da suíte TCP/IP, o protocolo DNS possui vários campos para desempenhar suas funcionalidades, sendo assim, passaremos a descrever a função de cada um dos campos que compõem as cinco seções do pacote DNS, de acordo com o padrão de implementação deste protocolo (RFC 1035). DNS packet header (Cabeçalho do Pacote DNS) O cabeçalho do pacote DNS contém os seguintes campos: ID QR Opcode AA TC RD RA Z RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT Fig. 5 Formato do cabeçalho DNS Estrutura do Cabeçalho DNS de acordo com a RFC 1035: ID - O ID permite identificar cada pacote DNS. Ele é utilizado somente para reconhecer as diferentes requisições enviadas ou recebidas. Flags - Os flags são divididos em várias partes : FLAGS Tamanho em Bits QR 1 Opcode 4 AA 1 TC 1 RD 1 RA 1 ZERO 3 RCODE 4 QR - Se o bit = 0 significa que o pacote é uma pergunta, se =1 ele é uma resposta. opcode - O valor é = 0 para uma requisição normal e, 1 para uma requisição reservada. AA - Se igual a 1, significa que o servidor de nomes tem autoridade sob o domínio informado. RD - se o flag for = 1, significa que "Requisição Recursiva" está sendo imposta na pergunta. RA - Este flag é = 1 se a recursão está disponível. Este flag é setado com valor 1 quando a resposta do servidor de nomes suporta recursão. Zero - Inicializado com valor 0 (zero); Rcode - Contém a mensagem de erro de retorno do DNS. 0 significa que nenhum erro foi encontrado 1 "Erro no Formato " significa que o servidor foi incapaz de interpretar a pergunta enviada. 2 "Servidor Falhou" O servidor falhou na resolução da pergunta enviada 3 "Erro no Nome" O nome de domínio perguntado não existe 4 "Não Implementado" O servidor de nomes não suporta o tipo de requisição especificada na pergunta 5 "Recusado" O servidor de nomes recusa processar a informação da pergunta enviada devido as políticas de segurança configurada. QDCOUNT - Informa a quantidade de pergunta. ANCOUNT - Informa a quantidade de resposta. NSCOUNT - Informa a quantidade de servidores de nomes que tem autoridade sob o domínio informado. ARCOUNT - Quantidade de informações adicionais. Seção de pergunta do pacote DNS Logo abaixo é mostrado o formato da seção de pergunta enviada em uma requisição para resolução de nomes ou endereço IP.

79 Nome a ser resolvido Tipo de Query Tipo de Classe Fig. 6 Formato da Seção de Pergunta Descrição dos campos: Nome a ser resolvido: é representado por uma seqüência de caracteres que juntos irão compor rótulos intercalados por um número que representa o seu tamanho. Ex: O nome é representado em uma pergunta da seguinte forma: 3 w w w 3 o l a 3 c o m 0 Tipo de query: Neste campo conterá o tipo de requisição a ser resolvida, se é de um nome ou de um endereço IP (reverso). Nome Valor Descrição A 1 Resolver um nome de domínio PTR 12 Resolver endereço IP Fig. 7 Tipos de Query Tipo de classe: Especifica a classe que compõem a Pergunta. Seção de Resposta, de Autoridade, de Adicionais do pacote DNS A seção de resposta, autoridade e adicionais apresentam o mesmo formato, a mesma estrutura em uma resposta enviada por um servidor DNS. O formato destas seções é mostrado abaixo: Nome a ser resolvido TIPO CLASSE TTL (Tempo de validade da resposta) Tamanho da Resposta Dados da Resposta Fig. 8 Formato da Seção de Resposta Nome a ser resolvido: O nome de domínio contido na seção de resposta do servidor DNS é o mesmo enviado na seção de pergunta. Ex.: 3www3ola3com0 Tipo: Este campo especifica o significado dos dados no campo "Dados da Resposta". classe: Especifica a classe dos dados no campo "Dados da Resposta". A classe é igual a 1 para dados da Internet. Tempo de validade (TTL): Este campo guarda um valor em segundos informando por quanto tempo a informação vai ter validade no cache. Tamanho da resposta: Informa o tamanho do campo "dados da resposta". Se o campo "tamanho da resposta" for igual a 4, significa que os dados da resposta são 4 bytes longo. Dados da resposta: Aqui é colocado o endereço IP ou o nome obtido na resposta do servidor DNS. Contém a resposta da pergunta realizada. Um exemplo do preenchimento de um pacote DNS enviado em uma pergunta é mostrado logo abaixo: dns.mydomain.com:53 dns.ola.com:53 [A? ID = 2005 QR = 0 AA = 0 TC = 0 RD = 1 RA = 0 OPCODE = 0 RCODE = 0 QDCOUNT = htons(1) ANCOUNT = 0 NSCOUNT = 0 ARCOUNT = 0 Seçao de Pergunta Nome a ser resolvido = [3 w w w 3 o l a 3 c o m 0] tipo de questão = htons(1) Tipo de query=htons(1) Fig. 9 Formato de uma Pergunta enviada por um servidor DNS Está é a pergunta, agora será mostrado a resposta de dns.ola.com. dns.ola.com:53 dns.mydomain.com:53 [ ID = 2005 QR = 1 AA = 1 TC = 0 RD = 1 RA = 1 OPCODE = 0 RCODE = 0 QDCOUNT = htons(1) ANCOUNT = htons(1) NSCOUNT = 0 ARCOUNT = 0 Seção de Pergunta Nome a ser resolvido = [3 w w w 3 o l a 3 c o m 0] Tipo de questão = htons(1) Tipo de query=htons(1) Seção de Resposta Nome a ser resolvido = [3 w w w 3 o l a 3 c o m 0] Tipo = htons(1) Classe = htons(1) TTL = 3600 Tamanho da Resposta = htons(4) Dados da Resposta = inet_addr(" ") Fig. 10 Formato de um pacote de resposta enviado por um servidor DNS Podemos perceber que algumas informações são iguais tanto no pacote de pergunta quanto no pacote de resposta enviado por dns.ola.com. Um dos

80 campos que apresenta a mesma informação tanto na pergunta quanto na resposta é o ID. Como foi explicado anteriormente o campo ID do pacote DNS serve para identificar as diferentes perguntas e respostas enviadas por ele. Sendo assim, para cada pergunta enviada contendo uma requisição de resolução de um domínio, o servidor DNS a identifica com um número específico, e fica aguardando uma resposta que tenha o mesmo identificador(id). No exemplo abaixo é mostrado uma pergunta de resolução do nome enviada para o servidor dns.ola.com com ID = dns.mydomain.com:53 dns.ola.com:53 [A? Resposta de dns.ola.com. dns.ola.com:53 dns.mydomain.com:53 Para gerar o pacote de resposta corretamente, tem que ser tratado algumas particularidades de implementação do protocolo DNS, conforme o exigido pelo padrão de implementação deste protocolo, detalhados nas RFC's 1034 e Uma informação de extrema importância, relatada pela RFC 1035, é que o campo "Nome a ser resolvido" da seção de resposta do pacote DNS, não tem o mesmo conteúdo do campo "Nome a ser resolvido" da seção de pergunta. Para reduzir o tamanho da mensagem, o serviço DNS utiliza uma compressão, que elimina a repetição de nomes de domínios na mesma mensagem. A entrada de nomes de domínios, mais especificamente o campo "Nome a ser resolvido" da seção de resposta, da seção de autoridade e da seção de adicionais, são sobrepostos por um ponteiro para ocorrência anterior de mesmo nome, que no caso é o campo "Nome a ser resolvido" da seção de pergunta. Sendo assim, o campo "Nome a ser resolvido" da seção de resposta, da seção de autoridade e da seção de adicionais são representados por um offset 1 que tem a seguinte formação: OFFSET A partir da depuração de pacotes de respostas enviadas por servidores DNS, percebemos através do tcpdump e de uma outra ferramenta conhecida como ethereal, (excelente ferramenta gráfica para depurações de pacotes), que o valor de offset 0xc00c é padrão em todos os pacotes. Sendo assim, definimos que este valor de offset deve ser utilizado em todos pacotes de respostas. O preenchimento do campo "Nome a ser resolvido" da seção de resposta do pacote DNS é mostrado no código abaixo. 1 offset - Endereço de memória.... u_short offset = -1; offset = 0xc00c; PUTSHORT(offset,answer);... 4 IP SPOOFING: A FALSIFICAÇÃO DE ENDEREÇOS IP O IP SPOOFING é um recurso utilizado para falsificar a origem do pacote. Consiste nas facilidades que o protocolo IP oferece no preenchimento de pacotes IP, de acordo com as necessidades de um atacante. Técnicas como DNS SPOOF, BLIND SPOOF, HIJACKING SPOOF, DOS e outros, simplesmente utilizam essa facilidade [6]. O IP SPOOFING é a técnica de preencher pacotes IP com um endereço de origem qualquer a fim de completar a ilusão de um pacote válido recebido em uma conexão ou sessão [1]. As facilidades de aplicar o IP SPOOFING em uma determinada ocasião, é mostrado no código a seguir, onde é preenchido o pacote IP de acordo com a necessidade.... ip_header->ip_v = IPVERSION; ip_header->ip_tos = 0; /*Informando o IP DE ORIGEM*/ ip_header->ip_src.s_addr = source; ip_header->ip_dst.s_addr = dest; ip_header->ip_p = IPPROTO_UDP; ip_header->ip_ttl = MAXTTL; ip_header->ip_hl = 5;... 5 COMO ACONTECE O SPOOFING DE IP EM SERVIDORES DNS O SPOOFING DE IP em servidores DNS ocorre quando é enviado uma resposta falsa para um servidor de nomes, utilizando o mesmo ID do pacote DNS de uma pergunta enviada, fazendo com que este servidor DNS aceite uma informação falsa contendo um endereço IP qualquer como resposta da resolução do nome de domínio questionado. Quando um servidor DNS faz uma pergunta para outro servidor, questionando o endereço IP de um determinado nome de domínio, ele fica aguardando uma resposta do mesmo. Caso ele receba uma resposta contendo as informações esperadas, ele simplesmente as retém. Os detalhes verificados na resposta recebida pelo servidor DNS são: se o campo ID e o campo "Nome a ser resolvido" do pacote DNS são iguais aos enviados na pergunta;

81 se a porta de origem é igual a porta de destino do pacote UDP enviado na pergunta; se o endereço IP de origem é igual ao endereço IP de destino enviado na pergunta. Mas suponhamos que esta resposta tenha sido enviada por um terceiro que está se passando pelo servidor DNS questionado, as informações da resposta recebida como resolução do nome de domínio questionado podem estar incorretas, fazendo com que o servidor DNS armazene em cache um endereço IP falso sobre o domínio em questão. A figura 11 abaixo demonstra a aplicação da falsificação de IP em uma resolução de nomes com o ID do cabeçalho DNS igual a inicialização. A linha de execução deste programa ficou definida da seguinte forma: DNShide <interface [eth0/ppp0]> <IP do servidor DNS vítima> <IPSPOOF invertido> <URL a ser "spoofada"> Ex.: DNShide eth Esta linha de comando informa que o programa DNShide deverá "sniffar" a interface de comunicação eth0 e enviar uma resposta para o servidor DNS que tem o endereço IP , fornecendo ao mesmo uma informação incorreta dizendo que o nome de domínio tem Qual é o IP de dns.mydomain.com dns.ola.com [A? :53 [[2005] = :53 Responde primeiro tentando ser passar por dns.ola.com DNShide mascote.mydomain.com Fig. 11 FALSIFICAÇÃO DE IP em servidores de nomes Podemos perceber que a falsificação de IP na resolução de nomes de domínios, mais conhecido como DNS SPOOF, tem a finalidade de enviar uma resposta falsa para o servidor de nomes, fazendo com que ele armazene em cache, por um determinado tempo, um endereço IP falso sobre um determinado nome de domínio, desviando a origem da informação. Para comprovarmos a veracidade da falsificação de endereços IP's na resolução de nomes de domínio em servidores DNS configurados sob os sistemas operacionais Linux e WindowsNT, implementamos um programa que envia uma resposta de resolução de nomes com endereços IP's falsos. Este programa ficou conhecido como DNShide.c. Para executar este programa é necessário entrar com alguns parâmetros para sua correta endereço IP Devido a aplicação implementada (DNShide), desempenhar a funcionalidade de um sniffer para capturar os pacotes da rede, e a funcionalidade de enviar uma resposta falsa para um servidor DNS, é necessário que ela esteja rodando em uma máquina que se encontre na mesma rede do servidor DNS que irá receber a resposta falsa. Sendo assim o DNShide deverá está rodando na máquina P, na tentativa de enviar uma resposta falsa para o servidor Y. Uma das informações que teremos que saber para formular o pacote de resposta é o ID do cabeçalho DNS enviado na pergunta pelo servidor Y. Para adquirirmos esta e outras informações necessárias foi implementado um sniffer no próprio DNShide, que tem a funcionalidade de pegar todos pacotes que estão transitando pela rede local e filtrá-

82 los de modo a selecionar somente aqueles que se destinam a um servidor DNS, ou seja, filtrar todos pacotes que tenham a porta de destino do protocolo UDP igual a 53. Após identificado o pacote de pergunta do servidor DNS que irá receber uma resposta falsa, deverá ser retirado dele, as informações necessárias para formular o pacote de resposta. Estas informações são: O "ID" do cabeçalho DNS, "Nome a ser resolvido" da seção de pergunta, "porta de origem" e "porta de destino" do pacote UDP, "IP de origem" e "IP de destino" do pacote IP. Parte código utilizado para colocar a interface no modo promiscuo, identificar a pergunta enviada pelo servidor Y e formular o pacote da resposta a ser enviado para este servidor é mostrado abaixo: /*COLOCAR A INTERFACE DE COMUNICAÇÃO NO MODO PROMISCUO*/... int fd; struct ifreq ifr; fd=socket(af_inet,sock_packet, htons(0x800)); if(fd < 0) { perror("cant get SOCK_PACKET socket"); exit(0); } strcpy(ifr.ifr_name, d); s=ioctl(fd, SIOCGIFFLAGS, &ifr); if(s < 0) { close(fd); perror("cant get flags"); exit(0); } ifr.ifr_flags = IFF_PROMISC; s=ioctl(fd, SIOCSIFFLAGS, &ifr); if(s < 0) printf("a interface nao pode ser setada no modo promiscuous)");... /*FILTRO UTILIZADO PARA IDENTIFICAR A PERGUNTA DO SERVIDOR DNS VÍTIMA */... if(ip->ip_p == IPPROTO_UDP) if(ip->ip_src.s_addr == dnsvitima) if(ntohs(udp->dest)==53) if(dns->qr == 0) return(true);... // PREENCHENDO O PACOTE DNS DE RESPOSTA... offset = 0xc00c; dns2->id = dns->id; /*Identificador do pacote*/ dns2->qr = 1; dns2->opcode = QUERY; dns2->aa = 0; dns2->tc = 0; dns2->rd = 1; dns2->ra = 1; dns2->unused = 0; dns2->rcode = 0; dns2->qdcount = htons(1); dns2->ancount = htons(1); dns2->nscount = htons(0); dns2->arcount = htons(0); question = (char *)packet2 + IPHDRSIZE + UDPHDRSIZE + DNSHDRSIZE; question += sizelabel+1;... Após retirar as informações necessárias do pacote enviado na pergunta realizada pelo servidor DNS vítima, é então montado um pacote de resposta manipulando as camadas de rede, transporte e aplicação, preenchendo os pacotes IP,UDP e DNS, com as devidas particularidades de implementação pertinentes de cada protocolo. O último passo é enviar este pacote de resposta para o servidor DNS vítima, aplicando a falsificação de endereço IP na resolução de um nome de domínio. Para testarmos o programa implementado, simulamos um ambiente baseado na figura 11, onde temos duas máquinas ligadas no mesmo barramento ethernet, pertencentes a mesma rede local, sendo elas a máquina Y e a máquina P. A máquina Y é o servidor DNS primário da rede local, e a máquina P é uma estação qualquer com sistema operacional Linux, interligada na mesma rede de Y. A máquina X é qualquer outro servidor DNS situado em algum lugar do mundo. Nos experimentos realizados, utilizamos um servidor DNS(máquina Y), que trabalha sob o sistema operacional Linux com kernel ou WindowsNT 4.0 com service pack 6. Em nosso caso, foi configurado uma máquina com dual boot 1 bastando iniciá-la com o sistema operacional desejado. Preparado o ambiente, realizamos vários experimentos. Primeiro enviamos uma resposta de resolução de nome, contendo informações falsas a fim de poluir o cache do servidor DNS da máquina Y, rodando sob o sistema operacional WindowsNT 4.0. Os passos realizados neste experimento estão detalhados a seguir. Baseado na figura 11 conseguimos falsificar o endereço IP em uma resposta de resolução de nome, enviando uma pergunta para dns.mydomain.com questionando qual é o endereço IP da máquina No entanto, como este servidor não tem autoridade sob o domínio informado, ele enviou uma pergunta para o servidor de nomes que tem autoridade sob o domínio ola.com. Neste exato momento o DNShide estava rodando na máquina P "sniffando" os pacotes da rede local, capturando assim o pacote enviado pelo servidor DNS(máquina Y) destinado a máquina dns.ola.com(máquina X), e retirando deste pacote as informações necessárias para montar uma resposta("id" do cabeçalho DNS, "Nome a ser resolvido" da seção de pergunta, "porta de origem" e "porta de destino" do pacote UDP, "IP de origem" e "IP de destino" do pacote IP. Logo em seguida, o DNShide preenche o pacote IP atribuindo ao campo source IP address o endereço IP do servidor dns.ola.com com intuito de fazer com que o pacote pareça estar vindo desta máquina, preenche o pacote UDP conforme o esperado por dns.mydomain.com e preenche o pacote DNS com uma informação incorreta sobre a resolução do nome 1 dual boot - Informa as opções de inicialização da máquina, tendo a disponibilidade de optar por um dos dois sistemas operacionais instalados.

83 de domínio questionado, informando que o endereço IP da máquina de nome é , e envia uma resposta contendo estas informações para o servidor dns.mydomain.com. Quando o servidor Y envia uma pergunta para o servidor X, ele fica aguardando uma resposta do mesmo, ou seja, ele fica aguardando uma resposta que tenha o mesmo ID do cabeçalho DNS enviado na pergunta, o endereço IP de origem do pacote IP igual ao endereço IP de destino enviado na pergunta e as portas de origem e destino do protocolo UDP igual a 53. Ao testamos o servidor DNS do WindowsNT e do Linux enviando duas respostas com conteúdos diferentes. Na primeira tentativa, o DNShide rodando na máquina P, envia uma resposta para Y tentando se passar por X. As informações do pacote na resposta enviada são as seguintes: ID do cabeçalho DNS igual 2005, "Nome a ser resolvido" da seção de pergunta do pacote DNS igual a [3 w w w 3 o l a 3 c o m 0], porta de origem do protocolo UDP = qualquer uma acima de 1024, porta de destino do protocolo UDP igual a 53, source IP address (ENDEREÇO IP DE ORIGEM) = qualquer endereço IP diferente de Logicamente não deveria funcionar, pois a máquina Y está aguardando uma resposta que tenha o campo source IP address do pacote IP igual a , conforme explicado no parágrafo anterior. No entanto, o servidor DNS do WindowsNT aceitou a resposta enviada pela máquina P, demonstrando que o único detalhe analisado e exigido por este servidor para autenticar um pacote DNS é que a resposta tenha o mesmo ID e o mesmo "Nome a ser resolvido" da pergunta que ele enviou, desprezando boa parte das informações do protocolo IP e do protocolo UDP. Ex: o endereço IP de origem(pacote IP) e a porta de origem(pacote UDP). Quando tentamos realizar os mesmos testes exemplificados acima com um servidor DNS rodando sob sistema operacional Linux, não obtivemos nenhum sucesso, pois ele checa além do ID do cabeçalho DNS, todas informações do pacote recebido, analisando todos os campos do protocolo IP e UDP. Caso as informações do pacote recebido não estejam dentro das exigências esperadas, ele simplesmente o despreza. Ficamos surpresos com o fato do WindowsNT aceitar um pacote DNS sem realizar uma checagem de autenticidade da origem da informação, não verificando se o endereço IP de origem da resposta recebida é igual ao endereço IP de destino da pergunta enviada. Na segunda tentativa, o DNShide rodando na máquina P envia uma resposta para Y tentando se passar por X com as seguintes informações: ID do cabeçalho DNS igual 2005, "Nome a ser resolvido" da seção de pergunta do pacote DNS igual a [3 w w w 3 o l a 3 c o m 0], portas de origem e de destino do protocolo UDP igual a 53, source IP address do pacote IP(ENDEREÇO IP DE ORIGEM) = Após o envio da resposta com o conteúdo mostrado acima, concluímos que os servidores DNS configurados sob os sistemas operacionais Linux ou WindowsNT aceitaram a resposta sem nenhuma restrição, armazenando em seu cache uma informação incorreta, especificando que o endereço IP do nome de domínio é igual a e não Para testar se a resposta enviada pelo DNShide foi armazenada em cache pelos servidores DNS do Linux e do WindowsNT realizamos os os seguintes passos: 1º Executamos a aplicação nslookup #> nslookup 2º Ativamos o servidor dns.mydomain.com para responder todas perguntas do nslookup #> server=dns.mydomain.com 3ºPerguntamos para o servidor dns.mydomain.com qual é o endereço IP da máquina #> 4º Conferimos a resposta enviada para o nslookup, que foi o endereço IP = confirmando a aceitação da resposta enviada pelo DNShide. #> CONSEQÜÊNCIAS Após certificado que o servidor DNS armazenou em cache uma informação incorreta sobre um determinado nome de domínio, várias conseqüências poderão ser explorados. Uma das conseqüências da falsificação do endereço IP na resolução de um nome de domínio é a alteração da origem da informação requisitada na abertura de uma página web. Por exemplo: Quando o usuário digitar no browser de navegação(internet Explorer, Netscape, lynx ou outro qualquer), o endereço da página irá aparecer uma página que está armazenada no servidor Web de endereço IP e não a página do servidor Web de endereço IP Uma outra conseqüência que pode ser explorada é a tentativa de driblar mecanismos de defesas baseados em wrappers 1. É muito comum administradores de rede permitirem a execução de certas aplicações somente para determinadas máquinas ou somente para uma única máquina da sua rede, especificando o nome ou o endereço IP da mesma. Abaixo é mostrado um exemplo de configuração do TCP_WRAPPER liberando a aplicação TELNET somente para uma única máquina na rede. Dois arquivos precisam ser editados: hosts.allow e hosts.deny. /etc/hosts.allow : libera a execução dos serviços. /etc/hosts.denny: inibe a execução dos serviços. 1 wrappers Mecanismos de software usados para filtrar a utilização de alguns serviços: telnet, ftp, talk, etc.

84 # Esta configuração foi realizada na máquina #mascote.mydomain.com # configuração do arquivo hosts.allow in.telenetd: bandit.ola.com # a linha acima informa que o TELNET está #aberto somente para a máquina: #bandit.ola.com #configuração do arquivo hosts.denny in.telenetd:all # A linha acima está negando a aplicação #TELNET para todos exceto os permitidos # no arquivo hosts.allow. Caso um intruso consiga poluir o cache do servidor DNS utilizado por mascote.mydomain.com, informando para este servidor que o endereço IP da máquina bandit.ola.com é o endereço IP da sua máquina, ele terá a sua disposição uma seção de telnet disponível em mascote.mydomain.com. Isso pode acontecer porque, todas as vezes que o serviço TELNET for requisitado na máquina mascote.mydomain.com, ela irá perguntar ao servidor DNS primário da rede qual é o endereço IP de bandit.ola.com e, após a resposta do servidor DNS, mascote irá verificar se o endereço IP da máquina que está requisitando o serviço TELNET é igual ao endereço IP respondido pelo servidor DNS, se for igual ela libera a seção de TELNET, caso contrário ela simplesmente reporta que o serviço não está acessível. 7 REFLEXÕES FINAIS Devido o serviço DNS ser um dos mais utilizados na Internet, e extremamente necessário em uma rede que requer os serviços de resolução de nomes, realizamos essa pesquisa com fins de comprovar as vulnerabilidades ou facilidades existente neste serviço, que permitem a falsificação de endereços IP's em pacotes de respostas de resolução de nomes, enviados por servidores DNS. Após a implementação de um programa que realiza a falsificação de endereços IP's em pacotes de respostas enviados para servidores DNS, realizamos vários experimentos, que nos permitiram concluir que servidores DNS configurados sob os sistemas operacionais Linux e WindowsNT se encontram vulneráveis, podendo ter seu cache poluído com uma resposta falsa. No entanto, podemos afirmar que tivemos maiores facilidades de comprovar a situação exposta, em servidores DNS que trabalham sob o sistema operacional WindowsNT 4.0. E o pior de tudo, é que mesmo as redes que se encontram configuradas abaixo de firewall's, podem ser vítimas da aplicação da falsificação de endereços IP's em pacotes de respostas enviados para os seus servidores DNS. Temos o propósito de divulgar para sociedade os perigos sem barreiras que cercam os serviços de nomes na Internet, relatando os detalhes da aplicação da falsificação de endereços IP's em respostas enviadas para servidores DNS e as conseqüências que podem ser exploradas após o servidor DNS ter seu cache poluído. 7 REFERÊNCIAS BIBLIOGRÁFICAS [1] Monteiro, Claudio. Estudo e Verificação da Segurança em Sites Internet. Dissertação de Mestrado Defendida em Dezembro de 1997 no Departamento de Sistemas e Computação da Universidade Federal da Paraíba. [2] Farrow, Rik. UNIX System Security. Reading, MA: Addison Wesley, [3] Ferbrache, David e Gavin Shearer. Unix Instalation, Security e Integrity. Englewood Cliffs, NJ: Prentice Hall, [4] Wood, Patrick H. e Stephen G. Kochan. UNIX System Security. Camel, IN: Hayden Books, [5] M. Bishop. A Taxonomy of UNIX System and Network Vulnerabilities. Technical Report CSE-95-10, Univ. of California at Davis, Sept, [6] G. Simson and S. Gene. Pratical Unix & Internet Security. O Reilly & Associates, [7] C. D. Brent and Z. D. Elizabeth. Building Internet Firewalls. O Reilly & Associates, [8] Comer, D. E. and D. L. Stevens. Internetworking with TCP/IP Vol I - Architecture e Protocols. Prentice-Hall, 1994.

85 FILTRAGEM COM ESTADOS DE SERVIÇOS BASEADOS EM RPC NO KERNEL DO LINUX Marcelo Barbosa Lima Instituto de Computação Universidade Estadual de Campinas CEP Campinas SP Paulo Lício de Geus Instituto de Computação Universidade Estadual de Campinas CEP Campinas SP RESUMO As tecnologias mais tradicionais de firewall filtros de pacotes e agentes proxy apresentam limitações que dificultam o suporte a certos protocolos e serviços TCP/IP, principalmente aqueles serviços que usam portas alocadas dinamicamente. Filtros de pacotes com estados são uma boa alternativa, pois permitem a criação de regras de filtragem dinâmicas para tais serviços. Este trabalho mostra detalhes da implementação de um filtro de pacotes com estados capaz de tratar serviços baseados em RPC. Foi usado como ponto de partida o filtro com estados implementado no novo kernel do Linux (série 2.4). O resultado deste trabalho foi aprovado e será incorporado à próxima versão oficial do núcleo deste sistema operacional. ABSTRACT Most traditional firewall technologies, such as packet filters and proxy agents, present limitations that make it difficult to support some TCP/IP protocols and services, mainly those services that use ports dynamically allocated. Stateful Packet Filter are a good alternative, because permits the setup of dynamic filtering rules for such services. This work shows details of the implementation of a stateful packet filter able to handle RPC-based services. It was used like start point the stateful filter implemented in new Linux kernel (2.4 series). The result of this work was approved and will be officially incorporated into the next operating system version. 1 INTRODUÇÃO Existem diversos serviços e protocolos de aplicação que podem ser responsabilizados pelo crescimento surpreendente da Internet. Muitos outros estão surgindo rapidamente sobre a infraestrutura de rede atual como resultado deste sucesso, impulsionados pela tecnologia e devido à pressão de usuários cada vez mais exigentes. Além disso, o aumento na velocidade das linhas de comunicação e no desempenho das máquinas têm facilitado o desenvolvimento de protocolos mais complexos. Tais protocolos envolvem a movimentação de uma grande diversidade de dados pela rede, em quantidades variáveis, com exigências diferentes na qualidade de serviço e, em geral, usam várias portas alocadas dinamicamente para as diferentes sessões ou conexões necessárias. Por outro lado, a maioria destes serviços não trazem muitos mecanismos de segurança embutidos e, geralmente, herdam muitos dos problemas da suíte TCP/IP original. É importante, portanto, que as tecnologias de segurança sejam capazes de agregar segurança a estes serviços para que usuários, em redes locais com maiores requisitos de segurança, possam usufruir destes atraentes serviços e protocolos. Infelizmente, as tecnologias tradicionais de firewall têm suas limitações e nem sempre conseguem tratar convenientemente todos estes interessantes serviços existentes na rede. Serviços baseados em UDP e RPC são representantes importantes desta classe de serviços. Neste trabalho serão tratados exclusivamente os problemas relacionados a serviços baseados em RPC. O leitor mais interessado em uma discussão mais geral sobre o assunto pode buscar informações na referência [12]. Na seção 2, serão discutidos os problemas existentes para a filtragem de serviços baseados em RPC. A seção 3 apresenta brevemente a nova geração de filtros de pacotes filtros de pacotes com estados (Stateful Packet Filter, SPF) e como filtros com estados podem solucionar os problemas mencionados na seção 2. A seção 4 mostra detalhes da implementação de um SPF no kernel de desenvolvimento 2.3.x do Linux. Na seção 5 será visto como este filtro da seção 4 foi estendido para oferecer suporte a serviços baseados em RPC. Finalmente, a seção 6 traz algumas considerações finais e a conclusão do trabalho. 2 SERVIÇOS BASEADOS EM RPC Existem vários protocolos de chamada a procedimentos remotos conhecidos como RPC. O mais popular e que será usado em nossa discussão, neste trabalho, é o Sun RPC, que foi originalmente desenvolvido pela Sun Microsystems [15]. Nos protocolos UDP e TCP, os cabeçalhos dos pacotes reservam somente 2 bytes para os campos com números de portas, ou seja, existem somente possíveis portas para todos os serviços TCP e UDP ( para cada). Se tivesse que reservar um número de porta bem definido para cada serviço existente, ter-se-ia um número de serviços limitado por este valor. Entre outras coisas, RPC oferece uma boa solução para este problema [2].

86 Cada serviço baseado em RPC recebe um número de programa único de quatro bytes (isto permite serviços diferentes). Como RPC é implementado acima do nível de transporte, deve existir algum mecanismo de mapeamento entre os números dos serviços RPC, oferecidos em uma máquina, e os números de porta que estes serviços estão usando em um dado momento. No Sun RPC, o Portmapper/Rpcbind é o responsável por este mapeamento e é o único servidor baseado em RPC que usa um número de porta pré-definido (porta 111, em ambos TCP e UDP). Quando um servidor RPC é iniciado, ele aloca um número de porta qualquer e registra-se junto ao Portmapper/Rpcbind. Nesta comunicação, ele passa o seu número de programa, a porta usada, o número de versão e o número do protocolo para o Portmapper/Rpcbind a ser usado na comunicação com os clientes. Vale comentar que o servidor usa o próprio protocolo RPC nesta comunicação. Estas informações são, na verdade, os parâmetros para um procedimento PMAPPROC_SET a ser executado pelo Portmapper/Rpcbind. Um cliente, desejando comunicar-se com este servidor RPC, comunica-se com o Portmapper/Rpcbind para consultar o número de porta usado pelo serviço. Na verdade, ele também faz uma chamada remota ao procedimento PROC_GETPORT, passando como parâmetros o número de programa, a versão e o protocolo usado. No momento em que o cliente obtém a porta usada pelo servidor, ele pode comunicar-se diretamente com o serviço RPC, sem nenhum envolvimento do Portmapper/Rpcbind. Por não usarem números de portas prédefinidos, não se tem como criar regras estáticas para filtragem de serviços baseados em RPC. A alocação de portas é feita dinamicamente e pode mudar com o passar do tempo (máquina ou servidor podem ser reinicializados, por exemplo). Bloquear tráfego de pacotes para o Portmapper/Rpcbind não resolve, pois um atacante pode descobrir o número da porta usada por algum serviço baseado em RPC, fazendo tentativas para todas as portas não reservadas. Outros serviços RPC podem usar números de portas prédefinidos, como é o caso do NFS que usa a porta 2049 [14]. Mesmo assim, é aconselhável bloquear acesso ao Portmapper/Rpcbind para evitar que eles sejam usados para ataques à própria máquina. O Portmapper/Rpcbind tem um recurso chamado proxy forwarder, que permite que clientes façam uma chamada ao procedimento PMAPPROC_CALLIT, passando como parâmetro o número de um programa RPC, sua versão, um número de procedimento deste serviço e os parâmetros para este procedimento. O Portmapper/Rpcbind faz a chamada ao procedimento do serviço, caso esteja registrado, e retorna os resultados obtidos para o cliente. Notar que isto pode ser perigoso para alguns serviços, uma vez que o Portmapper/Rpcbind tem privilégios de super-usuário e a requisição parece vir de uma máquina confiável (a própria máquina). A solução encontrada para a filtragem de serviços baseados em RPC, com filtros de pacotes estáticos, é simplesmente bloquear todo tráfego de pacotes UDP, pois a grande maioria destes serviços usam UDP como protocolo de transporte [2]. 3 FILTROS DE PACOTES COM ESTADOS (STATEFUL PACKET FILTER - SPF) Filtros de pacotes tradicionais não mantêm informações de estados das conexões ou sessões que passam pelo firewall [12]. Pacotes são analisados independentemente, usando somente as informações existentes nos seus cabeçalhos de rede e transporte e regras de filtragem. Se um pacote qualquer com as flags de sincronismo SYN e ACK ligadas chegar ao filtro de pacotes, o filtro supõe que este seja parte de algum canal virtual existente entre a rede interna e a rede externa. Silenciosamente, este o aceita, caso esteja de acordo com o conjunto de regras que implementa a política de segurança local. Entretanto, um bom firewall não deve permitir que pacotes não válidos entrem na rede a ser protegida. Pacotes não válidos são aqueles que não satisfazem as regras de filtragem e/ou não pertencem a nenhuma conexão ou sessão existente através do firewall. Isto, além de garantir a perfeita implementação da política de segurança da rede interna, evita diversos ataques já bem conhecidos e outros que poderão aparecer no futuro usando pacotes devidamente construídos e/ou mal formados. Um bom exemplo destes ataques são os pacotes ou fragmentos de pacotes, que satisfazem às regras de filtragem, mas não pertencem a nenhuma conexão ou sessão existente entre a rede interna e a externa, enviados para derrubar uma máquina alvo, explorando alguma falha na implementação da pilha de protocolos TCP/IP de um determinado sistema operacional existente na rede interna. Aliás, um atacante pode descobrir os sistemas operacionais usados em máquinas internas, enviando alguma seqüência bem definida de pacotes com características não especificadas nos padrões dos protocolos e, de acordo com as respostas obtidas, inferir sobre o sistema usado pela máquina. Em um filtro de pacotes com estados, quando um pacote SYN/ACK chega ao filtro, ele normalmente verifica, em suas tabelas de estados das conexões e sessões, se este pertence a alguma conexão em andamento através do firewall. Caso não exista uma conexão TCP válida para este pacote, ele é descartado e, possivelmente,

87 registrado nos logs. Portanto, mesmo que o filtro esteja configurado com uma única regra permitindo todo tráfego de pacotes entre as redes, estes pacotes continuarão sendo bloqueados no firewall, já que não pertencem a nenhuma conexão válida segundo suas tabelas de estados. Esta solução garante sempre uma maior segurança, visto que somente pacotes autorizados pelas regras de filtragem ou pertencentes às sessões e conexões válidas entre as redes podem atravessar o filtro. Uma outra vantagem desta solução é a melhora no desempenho, pois somente os primeiros pacotes das conexões ou sessões são verificados com as regras de filtragem, que geralmente é uma tarefa de mais alto custo computacional. Vale ressaltar aqui que este é o comportamento mais normal das atuais implementações de filtros de pacotes com estados. Nem sempre este processo de filtragem com estados trabalha exatamente desta forma em todas as implementações. Portanto, não existe uma especificação padrão para a implementação de um SPF, ou seja, o termo stateful especifica que o filtro deve manter informações de estados das sessões e conexões, mas não como estas informações devem ser mantidas nem como elas devem ser usadas no processo de filtragem. Para alguns serviços e protocolos de aplicação, como o caso do FTP, algum trabalho extra precisa ser feito também no nível de aplicação. Estes codificam certas informações dos níveis de rede e transporte, como números de portas e endereços IP, na parte de dados dos pacotes. Para estes casos especiais, filtros de pacotes com estados podem acompanhar o fluxo de dados da aplicação, extrair as informações necessárias para suas tabelas de estados e para criação de regras dinâmicas. No caso do FTP, o filtro pode extrair, por exemplo, a porta que o cliente usará para uma conexão de dados. Desta forma, é possível garantir o correto funcionamento destes protocolos e serviços. Por já fazerem algum trabalho nesta camada de comunicação para alguns serviços, alguns SPFs, como o CISCO-PIX e o FW-1, permitem também alguma filtragem no nível de aplicação, como em agentes proxy. Entretanto, a filtragem neste caso é geralmente bastante simples, verificando somente a parte de dados dos pacotes individualmente, sem qualquer remontagem do fluxo de dados do serviço. Apesar disso, muitos serviços de aplicação transmitem comandos do protocolo e suas respectivas respostas em unidades pequenas, que cabem em um único datagrama IP e podem perfeitamente ser filtrados por filtros de pacotes com estados. Um bom exemplo é o caso da comunicação entre clientes RPC e o Portmapper, que será destacada neste trabalho. As mensagens enviadas pelos clientes, requisitando o número da porta usada por algum servidor RPC, ocupam somente 56 bytes, enquanto uma resposta com o número da porta usada ocupa 28 bytes da parte de dados. Nestes casos, não há a necessidade de remontagem dos dados dos pacotes de uma comunicação para filtrar comandos do serviço ou protocolo de aplicação. A grande vantagem obtida com esta filtragem é que o SPF desempenha o papel de um agente proxy dedicado sem comprometer o desempenho. Por manter estados das conexões e sessões, um filtro de pacotes com estados permite também associar pacotes ICMP de erro ou controle à sua devida conexão ou sessão. Estes pacotes trazem informações que permitem identificar a conexão ou sessão da máquina à que se refere a mensagem ICMP. Usando estas informações, o filtro pode verificar a existência desta sessão ou conexão em suas tabelas de estados e permitir a passagem dos mesmos. 3.1 Filtragem com estados de serviços baseados em RPC Foi visto na seção 2 que a característica de não usar números de porta pré-definidos é o principal problema para a filtragem estática de serviços baseados em RPC. Um servidor RPC aloca o número de porta dinamicamente, junto ao sistema operacional, e registra-se ao servidor de nomes portmapper/rpcbind, informando a porta sendo usada em um determinado momento. Isto impossibilita a criação de regras estáticas para estes serviços usando número de portas fixos e previamente conhecidos. Uma boa solução para este problema é utilizar informações de estados extraídas da comunicação entre um cliente RPC e o portmapper/rpcbind para possibilitar a criação de regras dinâmicas para tais serviços. Um filtro de pacotes com estados pode simplesmente acompanhar uma sessão UDP (ou uma conexão TCP) envolvendo clientes RPC e o portmapper/rpcbind, dando atenção especial aos dados trocados em todas as chamadas ao procedimento PMAPPROC_GETPORT. Associando requisições às suas respostas e extraindo as informações relevantes, é possível manter as informações das portas sendo usadas e, consequentemente, permitir a comunicação entre clientes e servidores RPC. Esta solução de acompanhar todas as sessões entre clientes RPC e o portmapper/rpcbind e extrair as informações necessárias foi implementada neste trabalho, como será visto mais adiante na seção 5. 4 IPTABLES: UM FILTRO DE PACOTES COM ESTADOS NO KERNEL DO LINUX

88 Com o aumento no desempenho dos processadores, alguns sistemas operacionais passaram a implementar o processo de filtragem de pacotes no núcleo do sistema. Nas versões 2.0.x e 2.2.x de produção do kernel do Linux, por exemplo, pode-se encontrar respectivamente os filtros Ipfwadm e Ipchains, que implementam simplesmente uma filtragem estática dos pacotes. Neste trabalho, entretanto, tem-se mais interesse na nova infra-estrutura usada para tratamento e filtragem dos pacotes que estará presente na série de produção 2.4 do kernel, neste sistema operacional. Como ainda não há uma versão estável deste novo kernel, muito do que será apresentado neste documento é baseado nas versões 2.3.x de desenvolvimento e poderá sofrer pequenas mudanças até a sua versão final. Contudo, as idéias básicas usadas na implementação certamente permanecerão as mesmas. 4.1 Netfilter O Netfilter é um framework independente da interface normal de Berkeley Sockets, que gerencia e organiza como os pacotes que chegam ao kernel do Linux devem ser tratados, nas séries de desenvolvimento 2.3 e de produção 2.4. Ele define, por exemplo, que partes do kernel podem realizar algum trabalho com o pacote quando este atingir certos pontos do núcleo do sistema operacional [13]. Nesta nova infra-estrutura, cada protocolo define hooks (IPv4 define 5), que são pontos bem definidos na pilha de protocolos por onde passam os pacotes. Quando um pacote chega a um determinado hook, o Netfilter checa que módulos do kernel estão registrados para oferecer algum tratamento especial naquele ponto. Caso existam, cada módulo seqüencialmente recebe o pacote (desde que, obviamente, ele não seja descartado ou passado para o espaço de processos por um módulo anterior) e pode, portanto, examiná-lo, alterá-lo, descartá-lo, injetá-lo de volta ao kernel ou passá-lo para o espaço de processos, dependendo da funcionalidade de rede que esteja implementando. Estes módulos geralmente registram-se em mais de um hook ao mesmo tempo, podendo, até mesmo, fazer trabalhos diferentes com os pacotes em cada um deles. Desta forma, pode-se definir quais módulos devem ser carregados e registrados perante o Netfilter, sempre que algum tratamento especial com os pacotes for necessário. Além disso, esta interessante infra-estrutura facilita a implementação de novos módulos e permite que os módulos pré-existentes sejam facilmente estendidos, usando interfaces de comunicação bem definidas. Alguns dos módulos nativos são o NAT, o Iptables e o módulo de Connection tracking. Notar que, diferentemente das versões mais antigas do kernel do Linux, as diversas funções de rede são implementadas em módulos independentes. Nas versões 2.0.x e 2.2.x, o IP masquerading, por exemplo, era implementado junto ao processo de filtragem de pacotes e das funções de roteamento no kernel. Isso tornava o código confuso e acarretava alguma perda no desempenho. Com este novo esquema, IP masquerading, por ser um caso especial de NAT, é implementado usando o módulo de NAT. Este último, por sua vez, é totalmente independente do módulo de filtragem. 4.2 Módulo de Connection Tracking (Conntrack) Este módulo foi originalmente implementado para ser usado pelo módulo de NAT. Todavia, possibilita também que os outros módulos no kernel possam utilizá-lo. O papel do módulo Conntrack é manter informações de estados de todas as conexões e sessões. O módulo Iptables, em suas versões iniciais, não fazia filtragem com estados, mas foi rapidamente e facilmente estendido para basear seu processo de decisão também nas informações de estados mantidas pelo módulo Conntrack. Portanto, a grosso modo, este módulo de Connection tracking é o verdadeiro responsável pela parte stateful do filtro de pacotes implementado no kernel do Linux. Cada pacote chegando ao kernel é associado a uma estrutura de dados (skb_buff). Todos os componentes do núcleo do sistema operacional, que realizam algum trabalho com um determinado pacote, recebem o apontador para a estrutura de dados correspondente. Desta forma, os cabeçalhos e dados do pacote não precisam ser recopiados durante sua travessia pela pilha de protocolos. Portanto, esta estrutura de dados, dentre outras coisas, tem apontadores para os cabeçalhos dos diferentes níveis de rede e para a parte de dados do pacote. Nas séries 2.3 e 2.4, ela apresenta um campo extra (nfmark), no qual o módulo Conntrack codifica o estado para o pacote em sua sessão ou conexão. Vale notar que este módulo não deve descartar pacotes, com exceção de alguns casos excepcionais (pacotes mal formados). Esta função é deixada para o módulo de filtragem (Iptables). Portanto, depois de passar pelo módulo Conntrack, um pacote atravessa o kernel com o seu respectivo estado, que pode ser: INVALID: para pacotes que não pertencem e não criam uma conexão ou sessão. Pacotes ICMP não válidos são um bom exemplo; NEW: para pacotes que iniciam uma nova conexão ou sessão;

89 ESTABLISHED: para pacotes pertencendo a uma conexão já estabelecida; RELATED: para pacotes relacionados a alguma conexão ou sessão já estabelecida. Por exemplo, pacotes ICMP relacionados a alguma conexão existente. O módulo de Connection tracking atribui um estado a cada pacote que chega ao kernel, de acordo com o andamento da comunicação a que pertence. Para isso, ele usa uma tabela hash (conhecida como Separate Chaining) para manter as informações de estados de todas as conexões e sessões passando pelo núcleo do sistema operacional. Nesta tabela, cada posição guarda uma lista encadeada, onde cada nó representa uma conexão ou sessão (estrutura ip_conntrack_tuple_hash), contendo as informações necessárias para identificá-la unicamente (os endereços IP de origem e destino, os números de portas de origem e destino, o protocolo usado), apontadores para os seus vizinhos na lista e para uma outra estrutura de dados (ip_conntrack) com informações de estados propriamente ditas referentes à comunicação. Usando estas informações, o módulo de Contrack consegue atribuir o estado adequado para cada pacote dentro de sua respectiva conexão ou sessão. Além da tabela de estados das conexões e sessões, o módulo Conntrack também mantém uma lista de conexões ou sessões aguardadas (expect_list). Cada nó nesta lista guarda as informações dos endereços IP de origem e destino envolvidos, o número da porta destino e o protocolo a ser usado. Se um pacote tiver as mesmas informações em seus cabeçalhos de rede e transporte de uma das entradas nesta lista, o módulo assume que este pertence a esta conexão ou sessão esperada e atribui o estado RELATED ao pacote. Dai em diante, todos os pacotes desta conexão ou sessão relacionada recebem sempre o estado de RELATED. Além disso, cria-se uma entrada na tabela de estados para esta nova conexão ou sessão e retira a entrada correspondente da lista de conexões ou sessões aguardadas. Isto é equivalente a criar uma regra dinâmica para permitir a comunicação. Esta lista é, portanto, essencial para permitir o funcionamento correto de certos serviços e protocolos TCP/IP. O FTP é um bom exemplo destes protocolos, pois define o número de porta a ser usado na conexão de dados durante a conexão de controle [14]. Para acomodar bem tais serviços e protocolos, o módulo Conntrack oferece módulos auxiliares para alguns protocolos (conhecidos como helpers ) e permite que outros, para protocolos ainda não suportados, sejam facilmente implementados e agrupados ao módulo de Connection tracking. Os helpers acompanham os dados trocados em uma comunicação envolvendo algum determinado protocolo e extraem as informações necessárias para permitir as conexões ou sessões relacionadas. Com estas informações, este módulo auxiliar pode criar uma entrada para a conexão ou sessão na lista. Cada uma destas entradas permanece nesta lista enquanto durar a conexão ou sessão que a originou ou até que o primeiro pacote da sessão ou conexão relacionada chegue. Isto significa que não há timeouts associados, podendo dificultar um pouco o suporte a certos protocolos. Pode ser necessário, dependendo do protocolo, que um determinado helper gerencie uma lista de sessões ou conexões aguardadas particular para o correto tratamento de conexões ou sessões relacionadas. Esta foi a solução adotada para o caso do RPC que será visto na próxima seção. 4.3 Iptables O Iptables [13] é considerado um filtro de pacotes com estados porque ele permite o uso, no seu processo de filtragem, do estado atribuído pelo módulo de Connection tracking aos pacotes das diferentes sessões ou conexões. O módulo Iptables sozinho implementa somente uma filtragem estática dos pacotes como seus antecessores: Ipfwadm e Ipchains. Entretanto, quando o módulo Conntrack está presente no kernel, mantendo os estados das conexões ou sessões, o Iptables permite que o administrador de segurança crie regras baseadas nos estados dos pacotes dentro de suas respectivas conexões ou sessões. Desta forma, é possível a criação de regras permitindo a passagem, através do firewall, de todos os pacotes com estados ESTABLISHED e RELATED, sem comprometimento da segurança requerida. 5 ESTENDENDO O IPTABLES 5.1 Mensagens RPC O protocolo RPC [14] envolve basicamente dois tipos de mensagens: mensagens call e mensagens reply. Uma mensagem call é originada quando um cliente RPC envia uma requisição para a execução de um procedimento em particular. Depois que o procedimento é executado, o servidor RPC envia de volta uma mensagem reply, contendo os resultados retornados na execução do procedimento. A Figura 1 mostra o formato de uma mensagem call, quando encapsulada dentro de um datagrama UDP.

90 Figura 1: Mensagem Call com UDP A mensagem call inicia com o campo XID (Transaction ID) que é um valor inteiro estabelecido pelo cliente e retornado sem nenhuma alteração pelo servidor. Quando o cliente recebe uma mensagem reply do servidor, ele compara o campo XID desta última mensagem (observar a existência do campo também na Figura 2) com o XID enviado. Desta forma, o cliente RPC pode verificar se a mensagem recebida se trata de uma resposta válida à sua requisição. É interessante ressaltar ainda que, caso o cliente retransmita a sua mensagem call, o valor usado anteriormente no campo XID, na mensagem original, não é alterado. Isto evita problemas com mensagens duplicadas ou atrasadas na rede. O campo seguinte serve para distinguir entre mensagens call (valor inteiro 0) e mensagens reply (valor inteiro 1). A versão corrente do protocolo Sun RPC é 2 e, portanto, é este valor que é sempre transmitido no campo RPC version. A seguir pode-se ver os campos program number, version number e procedure number que unicamente identificam um procedimento específico no servidor. Os campos credentials e verifier são usados para fins de autenticação e não serão tratados em detalhes neste trabalho. Na comunicação entre um cliente e o portmapper/rpcbind, que é mais interessante para este trabalho, não existe nenhum esquema de autenticação, no modo de operação normal, sendo usado. Embora estes campos tenham tamanhos variáveis, o número de bytes usados é codificado como parte do campo: os primeiros quatro bytes, em cada um destes dois campos, representam o tamanho total dos mesmos. Além disso, mesmo que nenhum esquema de autenticação esteja sendo usado, este campo também deve transmitir um valor inteiro 0, que indica a ausência de um esquema de autenticação. Finalmente, tem-se o campo procedure parameters com os parâmetros que devem ser passados ao procedimento. O formato deste campo depende da definição de cada procedimento remoto. Deve-se notar aqui que este campo também tem tamanho variado. Para o caso de um datagrama UDP não existem problemas, pois o tamanho deste campo é igual ao tamanho total do pacote UDP subtraído do comprimento total de todos os outros campos mostrados acima. Entretanto, quando TCP estiver sendo usado, um campo extra de quatro bytes entre o cabeçalho TCP e o XID é introduzido, codificando o tamanho total da mensagem RPC. A Figura 2 mostra o formato de uma mensagem reply também encapsulada em um pacote UDP. O XID é copiado da mensagem call correspondente, como já foi discutido nesta seção. O campo seguinte tem valor 1 indicando que a mensagem se trata de um reply. A versão do protocolo RPC é 2, como no caso das mensagens call. O campo status recebe o valor 0 se a mensagem foi aceita (ela pode ser rejeitada, no caso de se estar usando outra versão do RPC ou de alguma falha na autenticação, e o valor atribuído, neste caso, será 1). O verifier tem o mesmo papel do caso anterior para mensagens call. O campo accept status recebe o valor 0 quando o procedimento é executado com sucesso. Neste caso, um valor diferente de zero identifica um determinado caso de erro, como por exemplo, um número de procedimento inválido sendo enviado pelo cliente. Como em mensagens call, se o protocolo de transporte TCP estiver sendo usado, um campo extra de quatro bytes é introduzido entre o cabeçalho TCP e o XID. Isto é útil para o cliente descobrir o tamanho correto do campo procedure results, com os resultados retornados pelo procedimento.

91 Figura 2: Mensagem reply com UDP Os campos destas mensagens são codificados usando o padrão de representação XDR, possibilitando que clientes e servidores RPC usem arquiteturas diferentes. XDR define como os vários tipos de dados são representados e transmitidos em uma mensagem RPC (ordem dos bits, ordem dos bytes, etc.). Portanto, o transmissor cria mensagens codificando todos os dados usando XDR e, do outro lado, o receptor decodifica os dados da mensagem usando este mesmo padrão de representação. Nas figuras 1 e 2, os campos usados transmitem principalmente valores inteiros. Portanto, pode-se concluir que um inteiro em XDR é codificado usando quatro bytes de dados. 5.2 Estendendo o módulo de Connection Tracking Inicialmente foi implementado um módulo auxiliar (ip_conntrack_rpc) para inspecionar o andamento de todas as tentativas de comunicação com o portmapper/rpcbind. Somente mensagens RPC, usando UDP ou TCP, requisitando a execução de procedimentos PMAPPROC_GETPORT e suas respectivas respostas são acompanhadas pelo módulo. O objetivo deste módulo é manter uma lista interna (lista de conexões ou sessões RPC aguardadas) com informações de estados extraídas da parte de dados dos pacotes e permitir que um outro módulo (ipt_rpc_known), estendendo o módulo de filtragem Iptables, possa verificar esta lista e, com base nestas informações, fazer a filtragem corretamente dos serviços baseados em RPC. Cada entrada na lista, representada por uma estrutura de dados (expect_rpc), mantém: os endereços IP do cliente e do servidor RPC, o protocolo a ser usado na comunicação, o número da porta usada pelo servidor RPC e um timeout associado à entrada. Como visto anteriormente, o funcionamento do protocolo RPC inicia quando o cliente se comunica com o portmapper/rpcbind para determinar o número da porta usada por um determinado servidor RPC naquela máquina. Nesta comunicação, o cliente passa como parâmetros o número de programa do serviço, o protocolo e a versão desejada. O módulo Conntrack responsável pelo tratamento do RPC acompanha todas estas requisições. Ele, na verdade, cria uma lista de requisições, para manter o histórico de todas as consultas ao portmapper/rpcbind. Cada entrada na lista de requisições (estrutura de dados request_p) mantém: o endereço IP do cliente, o XID, o número de porta do cliente, o protocolo a ser usado na comunicação com o servidor RPC e um timeout associado à entrada. Este timeout evita que consultas forjadas criem um número indefinido de novas entradas em ataques de DoS (Denial of Service), consumindo recursos na máquina filtradora. Caso este servidor esteja registrado, o portmapper/rpcbind retornará o número da porta usada pelo servidor naquela máquina. Quando esta mensagem reply chega ao módulo Conntrack, este pode verificar se existe uma entrada na lista de requisições e, caso exista, pode criar uma entrada na lista de conexões ou sessões RPC aguardadas. Nesta verificação, além das informações mantidas na lista de requisições, o módulo observa o XID, o endereço IP e a porta do cliente nestas mensagens. Isso é necessário, pois a informação do protocolo a ser usado não está disponível na mensagem reply. Para que uma entrada seja criada na lista de conexões ou sessões RPC aguardadas esta informação também é necessária. Se não existir uma entrada na lista de requisições correspondendo à mensagem reply, o módulo Conntrack simplesmente descarta a mensagem para um acompanhamento mais correto das comunicações. O leitor pode imaginar uma situação em que o portmapper/rpcbind, por algum motivo, atrasa a execução do procedimento PMAPPROC_GETPORT e o cliente retransmite a requisição. Pode-se supor então um cenário onde o timeout para entrada na lista de requisições expira e a mensagem de requisição retransmitida pelo cliente é perdida em trânsito e, portanto, não seria vista pelo módulo Conntrack. Caso esta mensagem reply chegue ao cliente, ele tentará fazer a comunicação com o servidor RPC normalmente. Entretanto, esta comunicação não será permitida devido a inexistência de uma entrada para ela na lista de conexões ou sessões RPC aguardadas. Um outro aspecto importante é o tratamento das possíveis comunicações subseqüentes dos clientes com os servidores RPC. O timeout associado a cada entrada na lista de conexões ou sessões aguardadas tem como objetivo básico permitir futuras tentativas de comunicação de clientes usando sua respectiva cache de respostas

92 anteriores do portmapper/rpcbind. Se a entrada fosse excluída imediatamente após o fim da comunicação, futuras tentativas não seriam permitidas. Obviamente, clientes bem implementados devem prover um esquema de recuperação para falhas deste tipo. Esta falha seria similar ao caso de um servidor registrado ser reinicializado e o cliente, usando as informações da cache, tentar usar o serviço. 5.3 Estendendo o Iptables Como já foi mencionado, o módulo de filtragem, nas séries 2.3 e 2.4 do kernel, baseia sua decisão também em informações de estados dos pacotes dentro de suas respectivas sessões ou conexões. Um módulo estendendo o Iptables foi criado para tratar todos os pacotes RPC com estado NEW (iniciando uma sessão ou conexão) chegando ao módulo de filtragem. Desta forma, o Iptables permite todas as tentativas de comunicação com o portmapper/rpcbind com consultas aos números de portas sendo usadas pelos servidores registrados. Portanto, não há a necessidade de uma regra permitindo explicitamente a comunicação com o servidor de nomes do RPC. Este novo módulo do Iptables também é o responsável em verificar as entradas da lista de conexões e sessões aguardadas e permitir que clientes se comuniquem normalmente com servidores RPC. 5.4 Testes de Sanidade e Cuidados Adicionais com Fragmentos e Pacotes Truncados Para um correto acompanhamento das mensagens RPC, alguns cuidados devem ser tomados com respeito à sanidade dos pacotes. Além disso, os módulos devem tomar cuidados extras para evitar que pessoas mal intencionadas possam subverter o mecanismo de filtragem de pacotes. O módulo Conntrack, antes de inspecionar a parte de dados de todos os pacotes RPC, verifica se há uma má formação e calcula o checksum do cabeçalho de transporte no pacote. Se UDP estiver sendo usado, esta última operação somente é feita se o campo de checksum tiver um valor diferente de zero, indicando que ele foi calculado, já que a checagem em UDP é opcional e percebida através do valor diferente de zero. Pacotes e fragmentos de pacotes cuidadosamente construídos foram previstos durante a implementação, tendo-se em mente, principalmente, a vulnerabilidade recente encontrada no FW-1 e Cisco-PIX no suporte ao FTP. Com este problema, um atacante é capaz de subverter o filtro de pacotes com estados. Para isto, bastava forçar que os pacotes do protocolo FTP fossem devidamente truncados e, explorando um problema existente na inspeção da parte de dados, abrir brechas no firewall. Como já mencionado, as mensagens RPC trocadas entre clientes e o portmapper/rpcbind são extremamente pequenas. Desta forma, cabem facilmente em qualquer MTU (Maximum Transmission Unit) existente nas interfaces de rede atuais. Desta forma, pacotes RPC fragmentados são tratados como um comportamento anormal e simplesmente ignorados pelo módulo Conntrack. Além disso, pacotes RPC, onde a parte de dados é maior que o esperado, são imediatamente descartados. Se um cliente usar TCP para a comunicação com o portmapper/rpcbind, os valores dos atributos da conexão devem ser sempre suficientemente grandes para não truncar a parte de dados nos pacotes. Em geral, o valor mínimo atribuído ao parâmetro MSS (Maximum Segment Size), por exemplo, é idêntico à MTU usada pelo meio físico para evitar a indesejável fragmentação de pacotes. Pode-se concluir, com isso, que não há boas razões para usar valores muito pequenos para este parâmetro e, portanto, qualquer tentativa disto é vista como um ataque contra o filtro de pacotes com estados. 6 CONCLUSÃO Este trabalho mostrou que filtros de pacotes com estados oferecem condições para a filtragem de serviços baseados em RPC. Vale notar ainda que soluções semelhantes podem ser adotadas para outros protocolos e serviços mais complexos. Um bom exemplo é o serviço Real Audio, para transmissão de áudio na Internet. Neste serviço, o cliente estabelece uma conexão TCP usando a porta 7070 do servidor. Usando esta conexão, ele envia suas requisições e números de portas UDP que ficarão esperando os dados do servidor. Múltiplas sessões UDP serão usadas para aumentar a vazão, garantindo a qualidade do som. Esta quantidade de portas usadas pode sobrecarregar muito mais rapidamente proxies dedicados. Além disso, o aumento no overhead pode prejudicar a qualidade do som. Um SPF, por outro lado, pode acompanhar a conexão TCP e permitir as sessões UDP muito facilmente. Vale ressaltar, porém, que agentes proxy dedicados devem ser adicionados sempre que o fluxo de dados para algum serviço precisar ser remontado/normalizado e inspecionado mais detalhadamente. AGRADECIMENTOS Os autores agradecem ao CNPq, à FAEP- UNICAMP pelo financiamento ao trabalho e, principalmente, ao Rusty Russel por todos os esclarecimentos e sugestões a respeito da nova

93 infra-estrutura de tratamento e filtragem de pacotes no kernel do Linux. REFERÊNCIAS BIBLIOGRÁFICAS [1] AVOLIO, Frederick M. Application Gateways and Stateful Inspection: Brief Note Comparing and Contrasting. Trusted Information System, Inc. (TIS). Janeiro, [2] CHAPMAN, D. Brent; ZWICKY, D. Elizabeth. Building Internet Firewalls. O Reilly & Associates, Inc [3] CHECKPOINT, Software Technologies Ltd. CheckPoint Firewall-1 White Paper, Version 3.0, junho, [4] CHECKPOINT, Software Technologies Ltd. Stateful Inspection Firewall Technology, Tech Note, [5] CHESWICK, William ; BELLOVIN, Steven M. Firewalls and Internet Security Repelling the wily hacker. Addison Wesley, [6] GONÇALVES, Marcus. Firewalls Complete. McGraw-Hill, [7] POUW, Keesje Duarte. Segurança na Arquitetura TCP/IP: de Firewalls a Canais Seguros. Campinas: IC-Unicamp, Janeiro, Tese de Mestrado. [8] POUW, Keesje Duarte; GEUS, Paulo Licio de. Uma Análise das Vulnerabilidades dos Firewalls. WAIS 96 (Workshop sobre Administração e Integração de Sistemas), Fortaleza. Maio, [9] RUSSEL, Ryan. Proxies vs. Stateful Packet Filters. Junho [10] SPONPH, Marco Aurélio. Desenvolvimento e análise de desempenho de um Packet Session Filter. Porto Alegre RS: CPGCC/UFRGS, Tese de Mestrado. [11] LIMA, Marcelo Barbosa; GEUS, Paulo Lício de. Comparação entre Filtro de Pacotes com Estados e Tecnologias Tradicionais de Fiewall. SSI99, São José dos Campos, [12] LIMA, Marcelo Barbosa. Provisão de Serviços Inseguros Usando Filtros de Pacotes com Estados. Campinas: IC-Unicamp, Setembro [13] Netfilter Home Page. URL: Julho, [14] STEVENS, W. Richard. TCP/IP Illustrated. Addison Wesley, [15] Sun Microsystems. RPC: Remote Procedure Call Protocol Specification. Version 2. RFC 1057, Junho, 1988.

94

95 PERSPECTIVAS PARA O ESQUEMA DE AUTENTICAÇÃO DO S.O. UNIX José Roberto Bollis Gimenez CEPPE Centro de Pós Graduação, Pesquisa e Extensão UNG - Universidade Guarulhos CEP: jroberto@unesp.br RESUMO Este artigo mostra que o esquema de autenticação tradicional do S.O. UNIX está agonizante devido ao acelerado desenvolvimento do hardware e das técnicas de força bruta utilizadas para quebrar senhas. Também questiona a política de senhas fortes e propõe alternativas para assegurar a continuidade do esquema de autenticação através de senhas, uma vez que a entropia envolvida no processo de escolha das senhas chegou ao ponto máximo aceitável. ABSTRACT This paper shows that the traditional authentication scheme used in the O.S. UNIX is agonizing due to the fast improvement in hardware technology and brute force password cracking techniques. The strong password politics are also questioned and it is proposed some alternatives to maintaining the authentication password scheme, as the entropy involved in the password choice process has reached its tolerated maximum. 1 INTRODUÇÃO Dentre as formas de implementar autenticação em um sistema computacional, a senha foi, com certeza, a primeira idéia a ser pensada. Mesmo considerando os modernos métodos de identificação fisiológica, a existência de um segredo que possa ser compartilhado entre o usuário e o sistema constitui ainda o meio mais prático e eficiente de reconhecimento, pois dispensa o uso de dispositivos especiais de entrada de dados e desobriga o usuário do sistema de portar cartões magnéticos ou outro tipo de hardware pessoal para identificação. A autenticação através de senhas, entretanto, requer certos cuidados, tanto por parte do usuário, quanto do sistema computacional. Enumeraremos a seguir estes cuidados: 1. Deve haver um mecanismo que bloqueie o acesso quando forem detectadas sucessivas tentativas infrutíferas. De outra forma, um intruso poderia testar um número ilimitado de senhas e obter acesso indevido. Este método de ataque é conhecido como ataque do dicionário on-line. 2. É necessário que as senhas sejam armazenadas no sistema de forma codificada, de tal sorte que, se alguém conseguir acesso indevido ao arquivo de senhas, este não conseguirá fazer uso imediato delas. Nesse sentido está envolvida uma função matemática cuja inversa é desconhecida, para a codificação das senhas. Devido às características dessa função, o método da forca bruta é o que se mostra mais promissor quando se deseja quebrar a segurança do sistema. Note que este método exige a aquisição, em uma fase anterior, do arquivo de senhas. Esta abordagem é conhecida como ataque do dicionário off-line. 3. Deve ser eliminada a correspondência biunívoca existente entre a senha em plaintext e a seqüência codificada. Pela adição de alguns componentes, conhecidos como salt, é possível fazer com que uma mesma senha gere uma série de diferentes seqüências de código. Com isso, impõe-se uma maior dificuldade aos métodos de força bruta, dificultando o uso de seqüências memorizadas. Por parte do usuário também são necessários alguns cuidados: 1. Escolha de uma senha que ele seja capaz de memorizar, dispensando a necessidade de anotála em algum lugar externo ao sistema, o que poderia comprometer a segurança da autenticação. 2. Escolha de uma senha que seja difícil de ser adivinhada por terceiros. Embora estes requisitos sejam necessários para o estabelecimento de um esquema de autenticação seguro, veremos que eles não são suficientes. O desenvolvimento de técnicas para quebra de senhas, aliado ao enorme ganho de desempenho adquirido pelos dispositivos de hardware nos últimos anos, trouxeram a necessidade de novos cuidados: no caso do sistema computacional, foi preciso incluir uma maneira de evitar que o arquivo com as senhas codificadas ficasse visível a qualquer usuário, impedindo que terceiros pudessem ter acesso ao conteúdo deste arquivo, dificultando dessa forma a obtenção de elementos para o ataque do dicionário off-line. O método usado para ocultar este arquivo é comumente chamado de shadow password [SPAFFORD and SIMSON, 1996]. Já no lado do usuário estes cuidados especiais constituem à chamada política de senhas fortes, onde o usuário assume parte da complexidade do esquema de autenticação, tendo que inventar senhas capazes de resistir ao ataque do dicionário.

96 Não bastando esta exigência de criatividade sobre a personalidade dos usuários, alguns administradores de rede também passaram a exigir que estes mudassem a senha periodicamente. Esta exigência prende-se a uma desconfiança, por parte do administrador, de que a senha criada pelo usuário não seja forte o bastante para resistir a um ataque persistente. Está claro que qualquer senha, por mais forte que seja, culminará por ser quebrada através de um ataque exaustivo (que teste uma a uma, todas as senhas possíveis). Dessa forma, é necessário que haja a troca das senhas em intervalos de tempo significativamente menores que o período estimado para que sejam descobertas. As experiências que nos levaram à elaboração deste trabalho permitem concluir que estamos vivendo o momento de uma nova quebra de paradigma, e que alguns conceitos precisam ser revistos para garantir a continuidade do sistema de autenticação através de senhas. Antes porém, é interessante fazer algumas considerações acerca dos pontos acima mencionados, tendo em vista, especialmente, o Sistema Operacional UNIX. Quando o método de autenticação usado no UNIX foi criado, em 1976, os computadores de então não conseguiam realizar mais que quatro execuções da função crypt(3) por segundo [PROVOS and MAZIERES, 1999]. Nos dias atuais, uma moderna estação de trabalho, com software otimizado, pode executar cerca de execuções dessa rotina. Expressando estes números de uma outra forma, pode-se dizer que o hardware atual consegue fazer em apenas um segundo todo o esforço realizado por quase três dias de operação de uma máquina construída há 24 anos atrás. A política de senhas fortes representa, em termos técnicos, o aumento de um parâmetro conhecido em teoria da informação como Entropia, pois as senhas passam a serem escolhidas a partir de um conjunto mais amplo de elementos. O que se procurou com o aumento da entropia do processo de geração de senhas foi acompanhar a evolução do hardware, impondo-lhe um maior esforço computacional como resposta ao ganho de desempenho obtido. Ocorre, entretanto, que chegamos a um ponto limite, em que é difícil aumentar a entropia do processo de escolha de senhas, ao passo que a tecnologia de hardware continua em pleno desenvolvimento. Outra questão a ser considerada é que o esquema de autenticação utilizado nos sistemas UNIX presume o conhecimento público de todas as etapas envolvidas no processo. A função crypt(3), ou então algoritmos como o MD5 ou o Blowfish, representam procedimentos matemáticos bem conhecidos. A providência de ocultar o arquivo de senhas com o uso de shadow password não condiz com a filosofia inicialmente adotada de um esquema aberto de autenticação. Ela é uma evidência de que esta idéia inicial sucumbiu à evolução do hardware e das técnicas de ataque usando força bruta. Por outro lado, a idéia de forçar os usuários ao uso de senhas fortes denota que a técnica de shadow password não oferece qualquer tranqüilidade com relação a impedir o acesso de terceiros ao arquivo de senhas. Neste ponto, também é bom observar que a política de utilização de senhas fortes é um aspecto que oferece mais problemas que solução. Primeiro porque o usuário nem sempre entende a necessidade de manter uma senha forte. Ele tem uma tendência natural de achar que a autenticação de sua área no sistema somente se relaciona com suas próprias informações (como, de fato, deveria ser). Depois, o conceito de senha forte é um pouco subjetivo e nem sempre corretamente entendido pelo usuário. O administrador, temendo que um intruso ganhe acesso à área de algum de seus usuários, e a partir daí galgue privilégios superiores no sistema, procura forçá-los ao uso de senhas fortes, sem contudo proporcionar-lhes qualquer realimentação sobre a qualidade de suas escolhas. Nesse processo, muitos administradores terminam por usar, eles próprios, um programa para quebrar senhas, apenas para investigar como anda a inventividade de seus usuários. 2 RESULTADOS EXPERIMENTAIS Exatamente no sentido de investigar a qualidade das senhas em uso, ou a resistência destas senhas ao ataque do dicionário off-line, é que o autor recorreu ao uso de um software tipo cracker. Para isso foi instalado o programa John The Riper em uma estação Compac Alpha DS20. O arquivo de senhas analisado foi o tradicional usado no S.O. UNIX, conhecido como /etc/passwd, e produzido através da função crypt(3). O benchmarking do conjunto software mais estação aponta para uma capacidade de processamento de senhas por segundo. Como o teste foi feito em um final de semana prolongado, toda a capacidade da estação pode ser usada exclusivamente para este fim. No arquivo de senhas haviam 73 linhas de código, correspondentes a igual número de usuários do sistema. Considerando que estes usuários são todos profissionais de computação, e de longa data são orientados à adoção de senhas fortes através de uma política de conscientização bastante severa, os resultados foram surpreendentes: em apenas 72 horas de execução do programa foram quebradas 11 senhas. Este processo, no entanto, não foi interrompido até o limite de um mês, quando 22 senhas haviam sido quebradas. Mais um ponto deve ser considerado em favor da força bruta: nenhuma configuração especial ou otimização foi implementada no programa, mantendo-se os ajustes originais. Os resultados da execução do John estão apresentados na Tabela 1. Como pode ser observado, grande parte das senhas quebradas foram criadas seguindo as recomendações normalmente fornecidas para a criação de senhas fortes.

97 Tabela 1 Senhas quebradas pelo programa John The Riper em: a) 3 dias de execução b) 30 dias de execução. a) senhas quebradas após 3 dias gclaus claus G. Claus maira hoje M. E. Paiva jjgebran phanton1 J. J. Gebran alexan hiei A. M. Deusajute marnog a17n M. A. Nogueira renatag lipegi R. C. S. Silva vivaldo debatu T. Vivaldo ldiber mumuland L. Diber adacris acao31 A. C. A. Silveira manen nrm135 M. R. Manen 10 passwords cracked, 63 left b) senhas quebradas após 30 dias jrenato nagoag J. R. B. Guimaraes albano 232aas A. A. Santos: jmendes vovo31 J. M. Pereira blveiga amongium B. L. A. Veiga vavo 15T6D A. B. Sousa simoni burrosme S. M. Gomes ademar a@cph A. S. Mauer gahecker moyhuci G. A. Hecker agcb 0dvt0c A. G. C. Batista eric jucanana E. Shimata ssilva ju9lu S. Silva beta mfwyals M. E. Lima 22 passwords cracked, 51 left 3 O ESQUEMA DE SENHAS DO UNIX Ao invés de armazenar as senhas em plaintext, o que representaria perigo de serem capturadas por outros usuários do sistema, o UNIX armazena um hash da senha. Sempre que um usuário pretende fazer login no sistema, uma senha deve ser digitada. Este então calcula o hash correspondente à senha digitada e o compara àquele previamente armazenado no sistema, permitindo que haja o login do usuário somente no caso de haver um casamento como resultado desta comparação. Tradicionalmente o UNIX emprega a função crypt(3) para a criação dos hashes das senhas. Esta função utiliza o algoritmo DES, porém de uma forma um pouco diferente daquela para a qual o algoritmo foi concebido. Ao invés de codificar a senha, ele utiliza os primeiros 8 caracteres desta, que correspondem a 56 bits, como chave para a codificação de um bloco inicial de 64 bits, gerando um novo bloco codificado, também de 64 bits, o qual não possui qualquer relação conhecida com a senha inicial que permita obtê-la usando o processo inverso. Ainda que isto pudesse ser suficiente para impedir um ataque analítico, este procedimento é repetido 25 vezes, usando sempre o resultado anterior como entrada da próxima iteração. Isto suprime totalmente qualquer chance de um ataque analítico. Como forma de impedir que uma senha produza sempre o mesmo hash, o que permitiria associar usuários que adotassem senhas iguais, ou ainda pior, facilitar um ataque usando senhas précalculadas, foi estabelecido um mecanismo de salt, o qual implica na adição de um número de 12 bits à seqüência inicial a ser codificada. Este número de bits proporciona a geração de 4096 diferentes hashes para uma mesma senha. O bloco resultante, de 64 bits, é então armazenado usando-se seis bits por caractere, produzindo, dessa forma, uma seqüência de 11 caracteres. Já o salt necessita de apenas dois destes caracteres para ser armazenado. Obviamente, o salt é armazenado em plaintext. A concatenação destas duas seqüências de caracteres resulta em uma seqüência de 13 caracteres, os quais são armazenados juntamente com o nome da conta, além de outras informações pertinentes a esta conta, em uma mesma linha do arquivo /etc/passwd. 4 A ENTROPIA DO ESQUEMA DE SENHAS O que se pretendia com as 25 iterações da função crypt(3) na época de sua concepção era extinguir a ameaça de um ataque analítico às seqüências de hash e não a criação de procedimento matemático que exigisse elevado esforço computacional. Ainda assim, esta função apresentava uma complexidade considerável, que inviabilizava qualquer ataque baseado na força bruta. Tanto o poder computacional das estações era insuficiente para efetuar um número considerável de tentativas por unidade de tempo, como também não haviam dicionários apropriados para este fim. A prova que o ataque do dicionário off-line não era motivo para causar preocupação está na própria forma como o arquivo /etc/passwd era armazenado, que dispensava cuidados especiais para evitar seu acesso. Com o tempo, o ataque do dicionário passou a ser preocupante para os administradores de sistema. Embora existam 2 56 possibilidades para a criação de uma senha no UNIX, o que corresponde a 7,2 x 10 16, os usuários normalmente restringem o universo de escolha às palavras de seu vocabulário rotineiro, reduzindo este número para menos de um milhão de possibilidades. De fato, o esquema de autenticação tradicional usado no UNIX ainda oferece espaço para um nível de entropia resistente ao ataque do dicionário offline. Naturalmente, esse incremento de segurança seria obtido à custa de novas e mais pesadas exigências sobre a criatividade e capacidade de memorização do usuário. A Tabela 2 mostra o tempo necessário para testar à exaustão todas as combinações possíveis de 3, 4, 5, 6, 7 e 8 caracteres para diversos tipos de alfabeto. Um alfabeto de 10 elementos seria, por exemplo, o caso de senhas criadas apenas com algarismos decimais. Um

98 alfabeto de 26 elementos seria o caso de senhas formadas apenas por letras minúsculas. Com 36 elementos teríamos letras e algarismos, enquanto que 64 estaria incluindo também as letras maiúsculas. Por fim, o alfabeto de 128 elementos estaria contemplando todos os caracteres ASCII. O desempenho considerado para a elaboração da tabela foi o de uma estação de trabalho tida como topo de linha. Ainda que este recurso não esteja disponível a qualquer indivíduo, sabemos que é apenas uma questão de tempo para que um computador pessoal disponha de um poder computacional semelhante. Tabela 2 Tempo necessário para testar à exaustão todas as senhas formadas por conjuntos de caracteres de 10, 26, 36, 64 e 128 elementos ms 90 ms 230 ms 1,3 s 10 s 4 50 ms 2,3 s 8,4 s 1,4 min 22 min ms 1 mim 5 mim 1,4 horas 2 dias 6 5 s 26 mim 3 horas 4 dias 8,5 mês. 7 1 mim 11 horas 4,5 dias 8,5 mês. 90 anos 8 8 mim 2,9 dias 5,4 mês. 45 anos 11 milên Na tabela 2 procuramos colocar em negrito a parcela correspondente às senhas que ainda demandam um tempo considerável para serem quebradas. É preciso ainda considerar que a distribuição de probabilidade dos caracteres encontrados nas senhas dos sistemas reais não obedecem a uma distribuição de probabilidade uniforme e tampouco existe independência estatística entre eles. Estas características, que são conseqüentes da necessidade de memorização da senha pelo usuário, são exploradas pelo software de cracking, o que permite afirmar que os resultados da Tabela 2 constituem limitantes superiores ao tempo de busca. De fato, estes valores consideram o tempo necessário para testar todas as senhas e não o tempo médio para descobrir uma senha. Para o caso de um arquivo com muitas senhas, o tempo médio necessário pode ainda ser reduzido pois, a cada hash calculado, todas as senhas com o mesmo salt são comparadas. Ou seja, as senhas são agrupadas pelo número do salt, reduzindo o número de cálculos, caso hajam senhas com o mesmo salt. 5 ALTERNATIVAS DE SEGURANÇA A conclusão que se chega a partir de toda esta discussão é que a forma tradicional de autenticação usada no UNIX deve ser abolida em favor de um esquema mais seguro. A proposta aqui apresentada é bastante simples e reside na troca da função usada para criar o hash da senha por uma função não conhecida. Dessa forma, ainda que um indivíduo mal intencionado consiga obter o arquivo de senhas do sistema, de nada adiantará, pois sem o conhecimento da função que gerou os hashes, não há como descobrir as senhas. Esta providência também apresenta outras vantagens, uma vez que livra os usuários (e o próprio administrador), da odiosa política de senhas fortes. A qualidade das senhas pode mesmo ser avaliada pelo próprio sistema, através de uma rotina que confira a senha escolhida para garantir que o usuário não esteja escolhendo senhas óbvias, como por exemplo o nome da própria conta. Em suma, o sistema meramente precisa se proteger de ataques on-line. Ataques on-line dificilmente são bem sucedidos. Mesmo assim, alguns cuidados devem ser envidados para evitar que eles tenham efeitos colaterais indesejáveis, como é o caso do bloqueio de contas através de sucessivas tentativas infrutíferas de login [SPAFFORD and SIMSON, 1996]. Voltando a questão da substituição da função geradora de hashes, muitas alternativas se aplicam com sucesso. A abordagem mais simples seria promover pequenas alterações na própria função crypt(3), de tal forma que ela produzisse resultados diferentes da original. Por exemplo, ao invés de processar 25 iterações, este número poderia ser alterado para várias centenas, bastando para isso variar um único parâmetro em seu código fonte. Outra alternativa seria a adição de um valor inicial à seqüência a ser codificada. Este valor seria definido e mantido exclusivamente pelo administrador do sistema e funcionaria como uma metasenha. O recurso de aumentar o número de iterações para um número consideravelmente maior também aumenta o esforço computacional na mesma proporção, o que dificulta o ataque do dicionário. Entretanto, o objetivo agora já não é mais oferecer resistência ao ataque do dicionário, e sim ocultar a função geradora de hashes. Neste sentido, devem ser tomadas medidas para evitar que o código executável da nova função seja roubado do sistema (Logicamente, o código fonte deve ser excluído do sistema). Uma boa técnica para esconder a função geradora de hashes é fazer com que esta utilize variáveis retiradas de outros pontos do sistema (como por exemplo, combinações de bits do MAC address da estação). Dessa forma, ainda que o código executável fosse roubado, além das complicações de praxe para encontrar um hardware idêntico ao da estação original, e de um tedioso trabalho de engenharia reversa, ainda estariam faltando elementos para se iniciar um ataque. Não convém discutir as possíveis alterações que permitem ocultar a função geradora de hashes. Isto porque a melhor opção é exatamente a que o administrador pode implementar a partir de sua própria imaginação, pois não está relatada em nenhum lugar.

99 A alteração da função crypt(3) pode ser mais facilmente implementada em sistemas de domínio público, como por exemplo o LINUX, onde o código fonte das rotinas estão disponíveis. Uma outra abordagem, já empregada em algumas versões do LINUX e do FreeBSD, consiste na substituição da função crypt(3) pelo Algoritmo MD5. Este algoritmo permite que sejam usados mais de 8 caracteres como argumento para a geração do hash da senha. Ele também proporciona um número de combinações extremamente maior, já que os hashes MD5 possuem 128 bits, em contraste com os 64 da função crypt(3). Entretanto, como já discutimos, a entropia desse processo não depende do domínio ou do contradomínio da função geradora de hashes e sim da qualidade da escolha das senhas por parte dos usuários um parâmetro sempre difícil e desagradável de ser controlado. Talvez a maior virtude do MD5 como gerador de hashes seja o esforço computacional requerido, que é bem superior ao da função crypt(3). O benchmarking do programa John the Riper aponta para um fator de 500 vezes entre a complexidade computacional destas rotinas. Muitas alternativas são apontadas na literatura visando incrementar a segurança do processo de autenticação [NEEDHAM and SCHROEDER, 1987]. Algumas delas constituem produtos acabados e bem conhecidos, como é o caso do Kerberos [STEINER and NEUMAN, 1988]. Outras sugerem o uso de one-time-password [HARE, C. and SIYAN, 1996]. Todos estes produtos utilizam criptografia, combinando uma série de ferramentas matemáticas existentes, tais como: rotinas de codificação, algoritmos de chave pública, geradores de hash, além de todo um esquema onde estão envolvidos inclusive servidores de autenticação. De forma geral, estes produtos endereçam também outros problemas de segurança que não apenas a quebra da senha. De fato, alterar a função geradora de hashes, usar shadow password, adotar políticas de senhas fortes, assim como outras medidas semelhantes, de nada adiantam quando as senhas circulam em plaintext pela rede. As medidas aqui discutidas presumem que esta questão esteja devidamente solucionada através de técnicas apropriadas, como por exemplo o uso de Secure Shell. O que se pretendeu neste artigo foi discutir alternativas para a continuidade do esquema de autenticação através de medidas simples, fáceis de implementar e que não provoquem grandes alterações no sistema. Apesar de existirem esquemas sofisticados de autenticação e proteção dos dados em trânsito em uma rede, os fornecedores de sistemas UNIX não os incorporam em seus produtos, deixando para o administrador a tarefa de procurar alternativas que venham a suprir esta deficiência. 6 CONCLUSÃO Os esquemas tradicionais de autenticação por senhas, em que todas as etapas do processo de codificação são abertas e conhecidas, não são mais convenientes para a segurança dos sistemas. A evolução do hardware permitiu que os ataque de força bruta passassem a representar ameaças não mais suportadas pela política de senhas fortes, normalmente adotada como remédio pelos administradores de rede mais conscientes. A transparência do esquema de senhas deve dar lugar a mecanismos onde o administrador oculta um ou mais parâmetros para garantir a inviolabilidade do sistema. Estas medidas eliminam totalmente a possibilidade do ataque do dicionário, sem que haja necessidade de grandes investimentos ou que produtos sofisticados sejam agregados ao processo de autenticação do sistema. Da mesma forma que no esquema tradicional de autenticação, medidas complementares devem ser adotadas para evitar que a senha seja capturada em plaintext através de outros artifícios. AGRADECIMENTOS O autor agradece o apoio dado pela UNG na elaboração deste artigo. REFERÊNCIAS HARE, C. and SIYAN, K., Internet Firewalls and Network Security, 2 nd ed., New Riders Publishing, Indianapolis, NEEDHAM, R. M. and SCHROEDER, M. D., Authentication Revisited, Operating Systems Rev., vol. 21, p. 7, Jan, PROVOS, N. and MAZIERES, D., A Future- Adaptable Password Scheme, Proc. USENIX Conf., Monterey, pp , June, SCHNEIER, B. Applied Cryptography, 2 nd Ed., John Wiley, New York, SPAFFORD, G. and SIMSON, G., Practical Unix and Internet Security, 2 nd Ed, O'Reilly & Assoc, Sebastopol, 1996 STEINER, J. G., NEUMAN, B. C. and SCHILLER, J. I., Kerberos: An Authentication Service for Open Network Systems, Proc. Winter USENIX Conf., USENIX, pp , 1988.

100

101 PROGRAMAS SEGUROS: VULNERABILIDADES COMUNS E CUIDADOS NO DESENVOLVIMENTO Felipe Massia Pereira * Instituto de Computação UNICAMP Campinas SP felipe.pereira@ic.unicamp.br Paulo Lício de Geus Instituto de Computação UNICAMP CP Campinas SP paulo@ic.unicamp.br RESUMO O presente artigo trata de vulnerabilidades encontradas em programas supostamente seguros principalmente programas SUID/SGID e de alguns cuidados a serem tomados no momento de desenvolver um programa seguro. Esta é uma área importante nestes dias em que é muito difundido o desenvolvimento de serviços de rede. A programação descuidada é a causa maior de erros nos programas e, conseqüentemente, de falhas de segurança em sistemas computacionais, que podem vir a ser descobertos e explorados por atacantes conectados à Internet. Este trabalho dá uma breve visão sobre alguns estudos anteriores acerca deste tema. Nós tratamos sobre a linguagem C e o sistema UNIX, já que são mais usados na Internet. Além disso, muitas ferramentas estão disponíveis para auxiliar programadores a escreverem programas seguros, das quais nós apresentamos algumas. ABSTRACT This article addresses vulnerabilities found in supposedly secure programs mainly SUID/SGID programs and presents some guidelines to be considered during the development of secure programs. This is an important area in these days of widespread network services programming. Careless programming is the major cause of bugs and, consequently, of security holes in computer systems, which may be found and exploited by attackers connected to the Internet. This work overviews some previous studies about this topic. We deal with the C language and the UNIX system, mostly used in the Internet. Also, many tools are available to help the programmers write safe programs, some of which we talk about. 1 INTRODUÇÃO A programação segura de sistemas já vem sendo estudada há um bom tempo. O primeiro ataque da Internet o Worm, em 1988 explorava um erro de programação no fingerd (Spafford 1989). Depois deste ataque, o grupo de Berkeley verificou seu código e eliminou similares da função gets() dos servidores de rede a explorada pelo worm e outros fornecedores de UNIX também assim o fizeram (Garfinkel and Spafford 1996). Vários cientistas e programadores alertaram, na época, para o perigo do uso de outras funções semelhantes, tais como strcpy(). A mais simples definição para o que seja um programa seguro é um programa que é capaz de executar sua tarefa suportando quaisquer tentativas de subvertê-lo. Além dos programas diretamente envolvidos com as políticas de segurança de um sistema por exemplo o programa login do UNIX também os programas que podem afetar essas políticas devem ser seguros (Al-Herbish 1999). A programação segura envolve programas especiais que atuam em fronteiras de segurança e que, às vezes, interagem com outros de formas inesperadas. Certas coisas que são assumidas como verdadeiras ou que são irrelevantes para outros programas devem ser levadas em conta em programas seguros. No UNIX, esses programas são executados pelo root ou são programas SUID de outro usuário (Bishop 1996b). Um estudo empírico feito por Miller em 1990 identificou diversas falhas nos programas mais utilizados do UNIX, cobrindo um total de 88 programas e 7 versões do sistema. No contexto do estudo, uma falha significava ou que o programa * Bolsista CNPq tinha caído gerando um arquivo core ou que ele tinha simplesmente parado de responder (Miller 1990). O teste feito era a passagem de uma cadeia extensa de caracteres aleatórios como entrada para os programas. O programa que gerava a cadeia aleatória foi batizado de fuzz. Em 1995, um estudo semelhante foi feito pelo próprio Miller junto com uma nova equipe, dessa vez com maior abrangência de programas e versões de UNIX (Miller 2000). A taxa de falhas em utilitários de versões comerciais de UNIX ainda era muito alta: de 15 43%. Além disso, muitas das falhas descobertas no estudo de 1990 foram encontradas na sua forma exata nos testes de Porém, este novo grupo de Miller não conseguiu fazer cair nenhum serviço de rede de nenhuma versão de UNIX testada. O mais relevante nestes estudos é que estas falhas que os programas apresentam são potenciais falhas de segurança. Se no lugar de uma string aleatória fosse passada uma string cuidadosamente construída para fazer um ataque de estouro de buffer, seriam grandes as chances de que este ataque tivesse êxito. Como veremos na seção 2, os ataques de estouro de buffer visam executar código arbitrário com as credenciais do programa atacado. Assim, se o programa for SUID root e o código arbitrário executa um shell, o atacante obtém um shell de root, ou seja, sem nenhuma restrição de segurança. Neste artigo, procuramos dar uma breve visão sobre o mais comum ataque às aplicações o estouro de buffer. Este ataque é descrito na seção 2. Na seção 3, descrevemos algumas classes de vulnerabilidades que afetam programas supostamente seguros. Na seção 4, descrevemos

102 algumas das ferramentas que auxiliam o programador a desenvolver código imune a ataques de estouro de buffer. Na seção 5, apresentamos uma conclusão seguida das referências utilizadas. 2 ATAQUE POR ESTOURO DE BUFFER 1 Os ataques de estouro de buffer buffer overflow têm sido a forma mais comum de vulnerabilidade nos últimos 10 anos. Ainda hoje, as vulnerabilidades de estouro de buffer dominam a área de vulnerabilidades de penetração em redes remotas. Se essa vulnerabilidade pudesse ser eliminada, grande parte dos problemas mais sérios de segurança também o seria. O primeiro grande incidente de segurança da Internet o Worm, em 1988 utilizava a técnica do estouro de buffer no programa fingerd. Cowan aponta alguns números (Cowan 1999). De 13 comunicados do CERT em 1998, 9 envolviam estouro de buffer e pelo menos metade dos de 1999 também. Uma pesquisa informal na lista de discussão sobre vulnerabilidades Bugtraq, mostrou que 2/3 dos participantes acham que os estouros de buffer são a principal causa das vulnerabilidades. Numa visita à página de atualizações da distribuição RedHat Linux 6.2, pudemos ver que 4 de 15 atualizações corrigiam vulnerabilidades de estouro de buffer. O principal objetivo do estouro de buffer é subverter uma função de um programa privilegiado de forma que o atacante possa controlar este programa e, se o programa for privilegiado o suficiente, controlar também a máquina onde ele está sendo executado. Normalmente o alvo do ataque é um programa com privilégios de superusuário (um programa SUID-root, por exemplo), que será conduzido a executar um código similar a exec(sh) para obter um shell de root. A calculada a um programa SUID vulnerável para obter um shell privilegiado. A vulnerabilidade do programa é caracterizada por uma cópia ou leitura desta string sem verificação de limites do vetor destino. A Figura 1 mostra como o quadro de procedimento e as variáveis automáticas normalmente são armazenados na pilha. Se o vetor destino é uma variável local da função, ele também se localiza na pilha. Portanto, caso a string seja maior que o espaço alocado do vetor, a cópia pode sobrescrever o endereço de retorno. Essa forma do ataque é mais conhecida como stack smashing. variáveis automáticas da função antigo FP end. retorno argumentos da função quadro do procedimento anterior SP FP endereços mais altos Figura 1: Situação da pilha após uma chamada de função 2. A string tem seu formato descrito na Figura 2. O atacante pode utilizar-se de um programa auxiliar 0 TAM / 2 TAM 1 NOPs Cadeia de instruções NOP shellcode Código que executa um shell Endereço do shellcode Essa parte deve sobrescrever o endereço de retorno com o endereço do shellcode Figura 2: Formato de uma string utilizada em um ataque de estouro de buffer. fim de atingir este objetivo final, o atacante precisa alcançar dois sub-objetivos (Cowan 1999): 1) fazer com que o seu código arbitrário esteja no espaço de endereçamento do programa; 2) fazer o programa saltar para o endereço onde o código está. Numa das suas formas mais comuns do ataque o atacante passa uma string cuidadosamente 1 Buffer overflow attack. para gerá-la. Como podemos ver na figura, a string de TAM bytes que será passada como argumento para uma função é dividida em três regiões. A primeira região é preenchida com diversas instruções NOP s. A segunda região situa-se no centro da string e contém o código que dispara o shell o shellcode. A terceira e última região é preenchida com cópias do endereço do início do código de shell. Ao ser passada como parâmetro 2 O layout da pilha depende da arquitetura e do compilador. A figura exibe a pilha de um programa C em uma arquitetura compatível com Intel x86.

103 para um programa, a terceira região dessa string deverá sobrescrever o endereço de retorno da função atacada com o endereço passado pelo atacante que aponta para o início do código que ele quer executado. Quando a função executar uma instrução RET, o código do atacante passa a ser executado. A obtenção do código de shell é um passo relativamente simples. AlephOne fornece em seu tutorial códigos de shell para diversas plataformas bem como detalhes de como efetivar o ataque (AlephOne 1996). Mas o atacante pode gerá-lo simplesmente construindo um programa que executa um shell e fazendo engenharia reversa no código através de um depurador. Enfim, o shellcode obtido será uma seqüência de bytes que representam as instruções de máquina para disparar o shell. É importante que este código não contenha caracteres especiais como \0, \n ou EOF, pois geralmente a vulnerabilidade a ser atacada no programa é um procedimento de cópia de bytes que vai parar ao encontrá-los; dessa forma o buffer pode não ser estourado. É possível substituir as instruções que geram esses bytes por outras equivalentes. As instruções NOP ajudam na etapa de calcular o endereço do início do shellcode. Se elas não precedessem shellcode, o atacante precisaria descobrir o endereço exato do início do mesmo, que é uma tarefa penosa e demorada. De outra forma, se o endereço usado pelo atacante for qualquer um dentro da faixa dos NOP s, o código será alcançado após a execução de alguns NOP s e o ataque terá sucesso. Há casos em que o buffer a ser explorado é pequeno demais, ou seja, menor que o tamanho do shellcode. Nestes casos, o ataque deve fazer o programa saltar para o endereço de uma variável de seu próprio ambiente, a qual conterá o shellcode. Algumas arquiteturas permitem que se marque o segmento de pilha como não executável SPARC, por exemplo. Isso evita que o código localizado na pilha seja executado, mas não evita por completo o ataque de estouro de buffer, pois há outras formas do ataque. Uma dessas formas consiste em fazer o endereço de retorno apontar para um código existente na aplicação que faz algo que interesse ao atacante por exemplo, uma chamada exec com argumentos diferentes. Outras formas incluem forçar chamadas a outros locais como o heap ou o segmento de dados. No sistema operacional Linux, a pilha é executável porque em alguns momentos o próprio sistema precisa de código executável na pilha por exemplo, para implementar sinais (Wheeler 2000). 3 OUTRAS VULNERABILIDADES Na presente seção, apresentamos outras vulnerabilidades e relacionamos alguns cuidados para codificação de programas seguros, a exemplo de um trabalho similar na área de software crítico (ALMEIDA et al. 1999). Os exemplos referem-se à linguagem C e ao sistema operacional UNIX, pois são a linguagem e o sistema mais utilizados na rede. Outras linguagens de programação, no entanto, merecem atenção. A linguagem perl, por exemplo, possui um modo mais seguro de funcionamento chamado modo taint. Neste modo, o interpretador toma cuidados especiais, principalmente em relação aos dados de entrada, que previnem contra armadilhas de programação que possam causar falhas de segurança. Compiladores Pascal, por exemplo, possuem uma opção que habilita a verificação de limites, que é de grande ajuda nos casos de estouro de buffer. Essa funcionalidade pode ser agregada à linguagem C através de patches para o compilador, como veremos na seção Verificação de Argumentos Muitos bugs relacionados a segurança surgem porque um atacante envia um argumento inesperado ou de formato inesperado para um programa ou uma função de um programa (Garfinkel and Spafford 1996). Por isso é bom verificar todos os argumentos. Atenção extra deve ser dada aos argumentos passados para o programa na linha de comando. É bom também garantir que os argumentos que são passados às funções do UNIX são realmente o esperado. Por exemplo, se o programador pensa que seu programa está abrindo um arquivo no diretório atual, ele pode usar a função index para verificar se o nome do arquivo contém um caractere barra (/). Se o nome do arquivo contém a barra, e não deveria, então o programa não deve abrir o arquivo (Garfinkel and Spafford 1996). 3.2 Erros em ponteiros e vetores Este item tem bastante em comum com o anterior, mas merece especial atenção. Um erro comum relacionado à utilização de ponteiros é acessar os elementos de um vetor em seqüência sem verificar os seus limites. O seguinte trecho de código mostra como este erro pode ser cometido: while ((c = fgetc(fin))!= '*') { string[i++] = c; } O trecho acima está lendo um caractere por vez do arquivo fin e guardando em string, ao mesmo tempo que incrementa o índice i. Esta construção enquanto é executada até que o caractere lido seja um asterisco *. É fácil notar que se o caractere asterisco estiver muito distante, o índice i pode alcançar o fim do espaço alocado para string. Isso poderá resultar na sobrescrita de outras variáveis, das informações guardadas no quadro de procedimento como o endereço de retorno, registradores salvos, etc. ou na violação do segmento. Encontramos invariavelmente na literatura que o programador não deve fazer uso de funções que não verificam limites de vetor para operações em

104 strings de tamanho arbitrário. Por exemplo, as funções gets(), strcpy() e strcat() devem ser substituídas por suas similares fgets(), strncpy() e strncat(), respectivamente. Essas três últimas são mais seguras porque permitem a passagem de um parâmetro adicional, especificando um limite no número de bytes a serem operados. A GNU conta com um conjunto de regras de programação para seus desenvolvedores (Stallman et al. 2000). Essas regras dizem que o programador deve alocar todas as estruturas dinamicamente, sem tentar adivinhar o tamanho máximo de alguma entrada do usuário. A equipe do FreeBSD preparou uma página na web que contém diversas sugestões para a elaboração de um programa seguro. A primeira dica diz para não utilizar as funções gets e sprintf (FreeBSD 2000). 3.3 Verificação de Valores de Retorno A não verificação de valores de retorno é um sinal de programação descuidada. Quase todas as chamadas de sistema do UNIX retornam um código de erro. Até mesmo chamadas aparentemente impossíveis de falharem, podem falhar em circunstâncias adversas. Quando as chamadas falham, a variável errno contém um valor que determina o motivo da falha. Por exemplo, uma versão antiga do su, quando não conseguia abrir o arquivo de senhas, presumia que havia ocorrido um erro catastrófico e invocava um shell de root para arrumar o sistema. Um possível ataque era abrir 19 arquivos e então realizar um exec su root. Se o máximo de arquivos abertos por processo, para a plataforma em questão, fosse 20, o ataque teria sucesso em obter um shell de root. Uma possível solução para este problema de segurança seria utilizar a variável errno para distinguir um erro realmente catastrófico de um ataque (Bishop 1996b). 3.4 Ambiente de Execução A maneira mais simples de projetar um programa seguro é não assumir nada em relação ao seu ambiente e definir tudo explicitamente sinais, umask, diretório atual, variáveis de ambiente. São comuns ataques onde são feitas algumas mudanças no ambiente do processo que o programador não previu. Uma falha de segurança muito conhecida envolvendo essa classe de problemas estava presente no programa /usr/lib/preserve (Garfinkel and Spafford 1996). Este programa, que é utilizado por editores como o vi e o ex, cria automaticamente um backup do arquivo se o usuário é desconectado inesperadamente do sistema antes de gravar as modificações no seu arquivo. O preserve grava as mudanças num arquivo temporário num diretório especial e depois usa o programa /bin/mail para enviar uma mensagem ao usuário avisando que o arquivo foi salvo. Como os arquivos editados pelos usuários podem ser de caráter confidencial, o diretório usado por versões mais antigas do preserve não era acessível à maioria dos usuários do sistema. Portanto, para permitir que o preserve gravasse nesse diretório, estes programas foram deixados como SUID root. O preserve executava o programa mail com a chamada system(), que usa o sh para interpretar a string que é executada. Existe uma variável de ambiente pouco conhecida chamada IFS internal field separator a qual contém os caracteres que o sh usa como separadores dos tokens para fazer o parsing da cadeia de caracteres. Normalmente esta variável é definida como espaço (ou TAB, nova linha etc.). Mas se esta variável incluísse o caractere barra (/), então executando o vi e depois executando o preserve, era possível fazer com que ele executasse um programa no diretório atual chamado bin; este programa era executado com privilégios de root (/bin/mail era interpretado pelo shell como um programa bin com parâmetro mail). Para obter o shell de root permanente, bastava que este arquivo bin fosse um script que copiasse um shell para o diretório do usuário e mudasse seus atributos para SUID root. Na verdade era dessa forma que o preserve era atacado. Alguns livros sugeriam a seguinte correção: system("ifs='\n\t '; \ PATH=/bin:/usr/bin; \ export IFS PATH; command"); Isto está errado (Bishop 1996b), pois antes o usuário poderia ter feito: IFS="I$IFS"; PATH=".:$PATH" E assim, o primeiro comando da chamada system seria a atribuição para a variável chamada FS, pois o caractere I passou a ser considerado um separador. Cuidado deve ser tomado quando uma variável está definida mais de uma vez no ambiente. Qual variável será utilizada primeira ou última depende do sistema. Além disso, as chamadas system e popen são desaconselhadas por vários autores porque invocam o shell e podem ter resultados inesperados dependendo dos argumentos passados e das variáveis de ambiente (Garfinkel and Spafford 1996). 3.5 Condições de Disputa 3 O programador deve estar ciente que seu programa não executa atomicamente. Em ambiente multitarefas, vários processos estão em execução pseudo-simultânea e isto dá margem a uma classe de ataques que exploram as condições de disputa. A falha mais comum neste tipo de vulnerabilidade ocorre no acesso aos arquivos (Bishop 1996a). O seguinte trecho de código é uma amostra: 3 Race conditions.

105 if (access(nome_arq, W_OK) == 0){ if ((fd=open(nome_arq,o_wronly)) == NULL){ perror(nome_arq); return(0); } /*... grava no arquivo... */ } Programas SUID root não têm seus acessos verificados por ocasião de uma chamada open. Por isso, eles têm que verificar o acesso aos arquivos por si mesmos. O exemplo acima mostra o trecho de um programa desse tipo. A chamada open, quando executada pelo usuário root, nunca dará erro de permissão (afinal, root pode tudo...). Portanto, é necessário verificar se o usuário real pode abrir o arquivo. Isso é feito através da chamada access, que devolve 0 em caso positivo. O grande defeito desse trecho de código é que há uma janela de vulnerabilidade entre a chamada access e a chamada open. O atacante pode substituir o arquivo original por um link para qualquer arquivo que deseje ler e não tenha acesso ou seja, mudar o conteúdo que é apontado pelo nome de arquivo contido na variável nome_arq. A chamada access será efetuada sobre um arquivo enquanto a chamada open será efetuada em outro arquivo. Essa falha faz parte de uma classe de falhas chamada TOCTTOU Time Of Check To Time Of Use (Bishop 1996a). Para evitar esse tipo de vulnerabilidade, o programador deve procurar utilizar as funções que recebem como argumento o descritor do arquivo em vez das que recebem o nome do arquivo. 3.6 Seguimento de Links Simbólicos Um processo pode ser enganado de forma a abrir um arquivo que não pretendia através de um ataque de link simbólico. Uma vulnerabilidade do programa license manager (do Solaris 2.5.1) referente a este tipo de ataque foi publicada na lista BUGTRAQ por Eriksson (Eriksson 1998). Este programa do Solaris criava arquivos de lock de posse do root e no modo 0666 (gravável por todos usuários). O programa não verificava links simbólicos ao criar o arquivo. Uma chamada open era feita para criar o arquivo se ele não existisse ou abri-lo caso contrário. O problema com um link simbólico é que uma chamada open segue o link e não considera que o link constitui um arquivo criado. Portanto, se o atacante tivesse um arquivo /tmp/arq ligado simbolicamente a /.rhosts um arquivo que só pode ser acessado pelo root este último arquivo seria aberto de forma transparente e seria gravável por todos os usuários. O problema requer duas condições para ser resolvido. Se o arquivo não existe, e nenhum link simbólico existe no seu lugar, então o arquivo pode ser criado. Porém, só é possível utilizar uma chamada de sistema para fazer isto, de forma a evitar as condições de disputa (v. seção 3.5). Uma possível solução é criar um arquivo com permissão de apenas escrita para a UID real do programa; então, uma chamada a fstat pode ser feita para obter o caminho completo do arquivo que foi criado e compará-lo com o caminho do arquivo que se pretendia criar. Se o caminho não estiver correto, o arquivo precisa ser apagado, senão o programa pode passar a utilizá-lo normalmente (Al- Herbish 1999). 3.7 Ligação Dinâmica Na ligação dinâmica, as funções de biblioteca não estão na memória no momento do início da execução do programa. Em vez disso, há um chamado stub. Quando uma função que não está na memória é chamada, o stub se encarrega de procurar a função e carregá-la, para que o fluxo possa ser então desviado para ela. Muitos sistemas UNIX, no momento de carregar a rotina para a memória, procuram a mesma em diretórios que estão guardados em variáveis de ambiente, tais como LD_LIBRARY_PATH ou LD_PRELOAD. Dessa forma, um programa SUID que utiliza ligação dinâmica tem partes controladas pelo usuário. Um possível ataque a essa vulnerabilidade é como segue (Bishop 1996b). Seja fgets uma função a ser carregada dinamicamente que é utilizada por um programa SUID. O atacante pode criar uma biblioteca dinâmica no seu diretório pessoal contendo a seguinte rotina fgets substitutiva: fgets(char *buf, int n, FILE *fp) { execl("/bin/sh", "-sh", 0); } E colocá-la numa biblioteca dentro do diretório atual. Ao executar: $ LD_PRELOAD=.:$LD_PRELOAD $ progsuid # O diretório corrente é colocado no início do caminho de busca de bibliotecas; assim, a rotina fgets encontrada pelo stub será a rotina do atacante, que dispara um shell com as permissões do dono do programa. Na verdade, os programas SUID desconsideram a variável LD_PRELOAD e utilizam as bibliotecas localizadas em diretórios confiáveis. Porém, um processo filho invocado por um programa SUID herda seu ambiente e irá utilizar a variável LD_PRELOAD. Sugere-se que em programas SUID, as bibliotecas sejam ligadas estaticamente. Os compiladores geralmente fornecem uma opção para isso.

106 3.8 Chamada de Subprocessos É importante que os processos SUID root abram mão de seus privilégios antes de executar outros programas. Isto porque as credenciais do processo pai são herdadas pelo processo filho. Bishop relata um incidente de segurança envolvendo alguns jogos populares que estavam presentes no sistema (Bishop 1996b). Os jogos precisavam alterar o placar geral (que qualquer usuário, por seu desempenho no jogo pode indiretamente alterar) e por isso eram SUID root. Foi descoberto que a UID efetiva não era redefinida quando um shell era disparado pelo jogo. Portanto, era possível rodar um jogo que mantinha um arquivo de placar e chamar um subshell este teria privilégios de root. A regra básica de segurança de computadores é minimizar os danos resultantes de um ataque. Para este problema dos jogos SUID root, uma das soluções é ser mais restritivo no que tange à escolha do usuário e do grupo. Em vez de root, seria mais seguro ter um usuário chamado games que teria a posse dos arquivos de placar. Se assim o fosse, o ataque dos jogos teria obtido os privilégios do usuário games apenas, que são bem mais restritos. 3.9 Meta-caracteres do shell Várias vulnerabilidades estão associadas à passagem de caracteres que possuem significado especial para o shell os meta-caracteres. Uma delas, a famosa falha de segurança do programa phf, incluído na distribuição do NCSA httpd, ocorria devido ao uso de um shell para executar um programa externo (AUSCERT 1996). Uma função de biblioteca chamada escape_shell_cmd(), que tinha por objetivo prevenir a exploração de chamadas como system() e popen(), falhava em não detectar o caractere de nova linha ( \n ). Garfinkel e Spafford sugerem que o programador procure por meta-caracteres do shell em qualquer string fornecida pelo usuário e que será passada para outro programa, gravada num arquivo ou usada como um nome de arquivo (Garfinkel e Spafford 1996). Geralmente é mais seguro verificar se só existem caracteres bons do que verificar a string quanto a um conjunto de caracteres maus. Al-Herbish, no entanto, alerta que o ideal é não utilizar o shell, pois ao escrever procedimentos para remover caracteres especiais o programador se expõe a erros, como ocorreu no caso da vulnerabilidade do phf (Al-Herbish 1999). 4 FERRAMENTAS Diversas ferramentas existem para auxiliar o programador a desenvolver código seguro, com relação a estouro de buffer, que é a principal vulnerabilidade no nível de aplicação. Nesta seção procuramos apresentar algumas delas. Podemos dividir as ferramentas de verificação de código em estáticas e dinâmicas. As estáticas analisam o código sem que o mesmo esteja sendo executado enquanto que as dinâmicas trabalham em tempo de execução. Além das ferramentas aqui descritas, existem várias outras relacionadas na página BoundsChecking Esta ferramenta de verificação dinâmica foi inicialmente desenvolvida por Richard Jones e Paul Kelly (Jones and Kelly 1997). Atualmente ela é mantida por Herman Ten Brugge e distribuída sob os termos da GPL. Mais informações podem ser obtidas na página Trata-se de pequenas alterações feitas no gcc para adicionar código de verificação nas operações aritméticas e no uso de ponteiros, mantendo uma tabela de regiões alocadas conhecidas. Os autores realizaram testes de desempenho verificando que o tempo de execução de um programa compilado com BoundsChecking é praticamente o mesmo em relação à versão normal. Porém, isso depende muito do modo como o programa foi escrito. 4.2 StackGuard O StackGuard é uma extensão ao compilador que melhora o código executável produzido pelo compilador de forma que ele possa detectar ataques de estouro de buffer contra a pilha. O efeito é transparente ao funcionamento normal dos programas. Esta ferramenta foi proposta por Cowan (Cowan 1998). O StackGuard funciona basicamente inserindo uma palavra especial (canary word) na pilha, entre o endereço de retorno e as variáveis locais. Grande parte dos ataques de estouro de buffer se dá através da alteração do endereço de retorno que está na pilha. O StackGuard consegue, através dessa palavra que foi inserida na pilha, detectar mudanças no endereço de retorno. O teste é feito antes do retorno, através de código extra inserido automaticamente, desviando a execução para a rotina de emergência se detectar a alteração. Recentemente a Wirex lançou uma distribuição de Linux chamada Immunix OS 6.2. Ela é baseada diretamente no RedHat Linux 6.2, mas todos os programas com código-fonte em C disponível foram recompilados com o compilador StackGuard. Maiores informações sobre o StackGuard podem ser obtidas no site StackShield O StackShield possui o mesmo objetivo do StackGuard: detectar escritas indevidas na pilha. Eles diferem na forma como essa escrita é detectada e tratada. O StackShield atua como um processador de programas-fonte assembly, é suportado pelos front-ends do GCC e é distribuído sob a licença GPL. O StackShield modifica o prólogo e o epílogo das funções nos programas compilados pelo GCC. No prólogo das funções ele faz uma cópia do

107 endereço de retorno para um espaço que não pode ser atingido e compara, no epílogo da função, se os dois valores são diferentes. Se forem diferentes, o endereço de retorno foi modificado e o endereço de retorno original é restaurado para que o programa siga executando. Porém, como geralmente os ataques de estouro de buffer alteram grande parte do estado do programa, as chances são grandes do mesmo vir a falhar. No fim de agosto de 1999 ocorreu uma discussão na lista BUGTRAQ envolvendo esta ferramenta e sua similar. O autor do StackGuard Cowan questionou a autenticidade de uma informação 4 contida na página do StackShield, que dizia que o StackShield é mais seguro que o StackGuard. Cowan fez uma comparação entre os dois sistemas e contestou a afirmação do autor do StackShield, dizendo ainda que em determinado modo de operação o StackGuard apresentava uma performance melhor que a do StackShield. No entanto, uma das vantagens do StackShield em relação ao outro, é que ele pode ser utilizado com o gdb. O StackGuard, por sua vez, só irá funcionar com um gdb alterado, que conheça o seu formato de quadro de procedimento. Maiores informações sobre o StackShield podem ser obtidas no site LCLint Logo após o nascimento da linguagem C, sem prototipação de funções, era de comum acordo que a depuração de programas era uma tarefa difícil. Dessa forma, foi criada uma ferramenta chamada lint capaz de fazer diversas verificações estáticas do código. Este programa foi escrito por S. C. Johnson no início dos anos 70 e foi a primeira ferramenta de validação estática de código. Com a criação do C padrão ANSI. algumas verificações do lint tornaram-se supérfluas. John Guttag e Jim Horning criaram a ferramenta LCLint, muito semelhante ao lint. Os comandos de lint podem ser emulados por LCLint, e os erros detectados por lint tais como: declarações não utilizadas, inconsistências de tipos, código inatingível, utilização antes da definição, prováveis laços infinitos e casos de fall-through, valores de retorno ignorados e caminhos de execução sem retorno, são também detectadas pelo LCLint. A idéia básica por trás do LCLint é executá-lo antes de compilar o código. Assim o LCLint vai procurar os possíveis erros no programa informando o usuário de seus achados. O LCLint possui vários modos de análise. No modo mais básico, ele atua como um verificador estático, sem tomar conhecimento da semântica do programa e é recomendado para depuração de código escrito por outrem. Em outro modo de operação, o LCLint interpreta anotações passadas dentro de 4 No momento da escrita deste artigo, essa mesma informação ainda consta na página. comentários do programa, nas quais o programador pode informar o significado do seu programa. Este último modo é bem mais poderoso que o primeiro e nele o LCLint pode deduzir se o programa faz o que o programador realmente quer que ele faça. O código fonte de LCLint pode ser encontrado em Binários para Linux, Windows e FreeBSD também estão disponíveis. 4.5 Purify O Purify, da Rational, adiciona instruções adicionais no código objeto antes de cada operação de LOAD e de STORE. Das diferenças entre o Purify e as outras ferramentas comentadas até o momento, é que ela atua no código objeto e não necessita do código fonte para que seja aplicada. Portanto, o programador pode com o Purify, proteger seu programa de bugs que aparecem até mesmo em bibliotecas fornecidas por terceiros. O Purify apresenta facilidade de uso e os binários gerados por ele podem ser manipulados por um depurador comum. Além disso, ele oferece a opção de uma interface gráfica onde podem ser exibidas as mensagens de erro. Dentre os muitos erros que podem ser identificados pelo código gerado com o Purify, destacamos os seguintes: variáveis locais não inicializadas; memória alocada dinamicamente não inicializada, utilização de locais de memória já liberados; escrita ou leitura além dos limites de um vetor; erros de estouro de pilha; Maiores informações sobre o Purify podem ser obtidas no site 5 CONCLUSÕES A maior parte dos ataques de segurança atuais baseia-se no estouro de buffer, que é uma técnica bem conhecida e relativamente antiga. Isso mostra que os programadores ainda não se adaptaram para escrever programas realmente seguros. Citando o que diz na página intitulada Security Code Guidelines da Sun (Sun 2000): uma corrente só pode ser tão forte quanto o mais fraco de seus elos O elo mais fraco no caso de linguagens projetadas visando a segurança como Java é o programador. A solução neste caso é o treinamento e a informação, apenas. No caso da linguagem C, cujos princípios de projeto não visavam a segurança do código gerado, além do treinamento, é desejável que se utilize ferramentas de verificação de código, como as apresentadas na seção 4, e patches que agregam funcionalidades de segurança ao compilador.

108 Podemos encontrar na rede, farta documentação com regras e cuidados para o desenvolvimento de código seguro. A maioria refere-se à linguagem C e ao ambiente UNIX, mas documentos referentes a outras linguagens como CGI, Perl, Java, etc. estão disponíveis. 6 REFERÊNCIAS BIBLIOGRÁFICAS AL-HERBISH, Thamer. Secure Unix Programming FAQ. Version 0.5, May 16, Cópia principal em ALMEIDA Jr., J. R.; CAMARGO Jr., J. B.; BASSETO, B. A.; CUNHA, R. S.; PAZ, S. M. Uma Lista de Inspeção para a Análise de Software Crítico. In: SIMPÓSIO SOBRE SEGURANÇA EM INFORMÁTICA, 99, São José dos Campos. Anais... São José dos Campos: P ALEPHONE. Smashing the Stack for Fun and Profit. Phrack Magazine. Volume 7, edição 49, arquivo 14 de 16, AUSCERT. AUSCERT Advisory AA-96.01: Vulnerability in NCSA/Apache CGI example code. Documento on-line. URL: es/aus_1996.html. 14 de Março de BISHOP, M. and DILGER, M. Checking for Race Conditions in File Accesses. Computing Systems 9(2), pp , Primavera de 1996 (a). BISHOP, Matt. UNIX Security: Security in Programming. SANS '96, Washington DC, Maio de 1996 (b). BISHOP, Matt. Writing Safe SUID Programs. Network Security 1997, New Orleans, LA, Outubro de COWAN, Crispin et al. StackGuard: Automatic Adaptive Detection and Prevention of Buffer- Overflow Attacks. 7 th USENIX Security Conference, pp , San Antonio, TX, Janeiro de COWAN, Crispin et al. Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade. DARPA Information Survivability Conference and Expo (DISCEX), de Janeiro de ERIKSSON, Joel. License Manager s lockfiles (Solaris 2.5.1). BUGTRAQ. Mensagem online. URL: 21 de Outubro de FREEBSD. FreeBSD Security Information. Documento on-line. URL: 8 de Junho de GARFINKEL, S. and SPAFFORD, G. Practical Unix & Internet Security. 2ª Edição, O Reilly, JONES, R. W. M. and KELLY, P. H. J. Backwards-compatible bounds checking for arrays and pointers in C programs. AADEBUG 97, Linköping, Suécia, MILLER, B. P. et al. An Empirical Study of the Reliability of UNIX Utilities. Communications of ACM. Volume 33, number 12, December 1990, MILLER, B. P. et al. Fuzz Revisited: A Reexamination of the Reliability of UNIX Utilities and Services. 18 de fevereiro de ftp://grilled.cs.wisc.edu/technical_papers/fuzzrevisited.ps.z SPAFFORD, Eugene. Crisis and Aftermath. Communications of ACM. Volume 32, número 6, Junho de 1989, p STALLMAN, Richard et al. GNU Coding Standards. Free Software Foundation Inc. Última atualização em 27/06/2000. Documento on-line. URL: standards_toc.html STEVENS, W. Richard. Advanced Programming in the UNIX Environment. Addison-Wesley, SUN Microsystems Inc. Security Code Guidelines. Documento on-line. URL: security/seccodeguide.html. Versão de 2 de fevereiro de WHEELER, David A. Secure Programming for Linux and UNIX HOWTO. Versão 2.20, julho de URL:

109 SELECTION OF CHANNELS FROM A TREE-STRUCTURED FILTER BANK FOR SPEAKER IDENTIFICATION André Gustavo Adami Center for Spoken Language Understanding Oregon Graduate Institute of Science and Technology Beaverton OR - USA (503) adami@cse.ogi.edu ABSTRACT Speaker identification systems make decisions based on the features extracted from the speaker s voice. Despite the use of the entire spectrum of the signal, do all extracted features really contribute to the performance of the system? One approach to answer that question is to find the range of frequencies that really helps the performance of a speaker recognition system. Using a tree-structured filter bank to divide the signal in several bands based on the human auditory system, this work investigates the frequency ranges that characterize a speaker s identity. 1 INTRODUCTION Today, systems that recognize the identity of people have got the attention of many researchers because of our unsafe world. Many applications are employing this technology to make sure that only the right people can access some specific data or property. However, this technology is not accurate as it needs to be. Thus many researchers are searching for characteristics in humans that make a person s identity unique. One of the answers for this problem can be found in Biometrics, which is an area that studies physiological and behavioral characteristics in humans to use in an identity recognition system. Many human traits are used for identity recognition, such as iris, face, hand geometry, fingerprint, voice, veins, and DNA. One of the biometrics widely studied and used, voice is a good way to recognize a person because it is natural, ubiquitous, easy to acquire, and inexpensive. Even though this human trait is not accurate as the iris, it offers a wide range of applications such as person authentication over the telephone or Internet, forensic applications, and access control. Speaker recognition systems can be divided into two types: Speaker verification: a speaker claims an identity and the system must decide if the identity claimed is false or true; Speaker identification: the system must assign an identity to a speaker based on the enrolled population. This type of system can be divided into two types: open-set (a speaker can either belong or not to the enrolled population) and closed-set (a speaker belong to the enrolled population). Both types of speaker recognition system can be text-independent (there are no restrictions about what must be spoken) and text-dependent (the user must say something already defined by the system). A speaker recognition process has two main tasks: to create a speaker model based on samples collected from some speaker and to compute a probability or a distance to decide if the input speech belongs or is the nearest to any model in the system. However, the decision is made assuming that the features extracted from the speech by the system contain reliable speaker specific information. An overview of the subject is given by Doddington, 1985 and Furui, Even though there are many approaches to improve the accuracy of the speaker recognition systems, the analysis of different frequency bands of an input signal, also called multi-band model, shows to be the best approach (Sharma, 1999; Besacier, Bonastre, and Fredouille, 2000) because: It can deal with noise conditions that corrupt part oh the speech spectrum; It can work only with the frequency bands that hold more of the speaker s characteristics; It can approximate the frequency bands to the critical bands, which have a human auditory motivation. The goal of this work is to implement a textdependent open-set speaker identification system using a tree-structured filter bank and to find the frequency bands that represent better the speaker s identity. The channels are selected using a maximum likelihood criterion, whereas the least relevant channels are eliminated. 2 SYSTEM DESCRIPTION The entire speech signal is passed through the tree-structured filter bank in order to split it in several frequency bands. From each frequency band, also called channel, a set of features is extracted and is used to compute the probabilities that the signal was produced by each speaker (it is assumed that the distribution of the features is normal and statistically

110 independent). In the classification task, the probabilities, which are normalized using an impostor model, are used to decide if the speaker either belongs or not to the enrolled population. The system is depicted in Figure 1. Speech Signal Tree-structured Filter Bank Channel 1 Channel 2 Channel 15 Feature Extraction Enrolled Population Model Feature Extraction Classification Speaker Identity or Rejection Figure 1 Speaker recognition system using a treestructured filter bank Each part of the system is described in the following sections. 2.1 Tree-structured Filter bank Feature Extraction Impostors Model A tree-structured filter bank is a technique to design a M-channels filter bank by cascading smaller systems (Strang and Nguyen, 1997). The nonuniform frequency bands of the tree-structured filter bank can reproduce the critical bands, where the perception of a particular frequency by the auditory system is influenced by the energy (Moore, 1997). Thus, the features of the signal are extracted from each critical band, like the auditory system. The first step in order to implement the filter bank is to design filters that provide no distortion and no aliasing to the signal. A minimum phase lowpass filter (Lang, Odegard and Burrus, 1994) is used to implement a two-channel orthogonal filter bank, which is the building block of the tree-structured filter bank. The highpass and the reconstructions filters are designed using the set of equations 1: H ( z) = z F ( z) = H 0 F( z) = H 1 1 N H0 ( z) ( z) ( z ) (1) where H 0 is the minimum phase lowpass filter. The double shift orthogonality is used to check the orthogonality of the filter bank (Strang and Nguyen, 1997). The topology of the tree-structured filter bank used in this paper tries to approximate to 1-Bark spacing critical bands (Sharma, 1999), which is presented in Table 1. Table 1 Cut-off frequencies of the 1-Bark spacing critical bands filters for 8kHz sampling frequency Critical band number Lower cut-off frequency (Hz) Upper cut-off frequency (Hz) The cut-off frequencies of the filters obtained by the tree-structure filter bank are as specified in Table 2. Table 2 Cut-off frequencies of tree-structured filter bank for 8kHz sampling frequency Critical band number Lower cut-off frequency (Hz) Upper cut-off frequency (Hz)

111 Feature Extraction The tree-structured filter bank is used to approximate to the auditory system, which behaves as if it contains a bank of bandpass filters, with some overlap (Moore, 1997). From each channel, the signal is squared and divided into segments of 40ms. Each segment is decimated by factor 10 in order to reduce the dimensionality. The log of the reduced segment is computed because the perception of sound for humans is in a sort of logarithmic scale (higher frequencies are perceived easier than the lower frequencies) (Moore, 1997). The nonuniformity of the filter bank makes different the number of samples coming out of each channel. In the end of this process, channels 1 to 8 have one element, channels 9 to 12 have two elements, channels 13 and 14 have four elements, and channel 15 has eight elements. The feature vector is composed by the output of all channels, as it is presented in Figure 2. Channel feature vector 40 ms 80 ms time Figure 2 Feature vector composition; every 40ms the output of all channels is put together to form a feature vector 2.3 Classification The negative log-likelihood ratio with threshold η is used to classify if the features belong to an enrolled speaker. The discriminant function is described in equation 2. p( x ω1 ) h ( x) = log (2) p x ω ( ) 2 where x is a feature vector, p(x ω i ) is a normal probability density function. Since many feature vectors are extracted from each input signal, it is assumed that each vector characterizes individually the speaker s identity and then the class condition density is the product of the class conditional density of each vector, as presented in equation 3: N 1 2 N x i i= 1 p ( x, x,..., x θ) = p( θ) (3) The function p(x i θ) represents the likelihood of a single vector x i uttered by the speaker modeled by θ ((Reynolds, 1994; Reynolds, 1995 and Besacier, Bonastre, and Fredouille, 2000). In order to improve the classification, the likelihood ratio uses a set of impostors as class ω 2. This approach can be assumed as a type of normalization that increases the likelihood ratio for enrolled speakers and decreases the likelihood ratio for impostors (Reynolds, 1994; Reynolds, 1995; Markov, 1998 and Besacier, Bonastre, and Fredouille, 2000). The decision process chooses the speaker that has the greatest negative log-likelihood and this value is greater than a threshold (equation 4), which is defined in the training phase. Speakeri = arg max h( x), h(x) > η (4) i This type of classification can produce two types of errors: false rejection (the rate of enrolled speakers who are rejected by the system) and false acceptance (the rate of impostors who are accepted by the system). The goal is to design a classifier that has the minimum equal error rate. 3 EXPERIMENTS This section describes the corpus used to do the experiments, the way that the channels were selected to compose the feature vector and the results from the experiments. All experiments seek for the minimum false acceptance error rate because it is safer to reject an enrolled speaker than to accept an impostor.

112 3.1 Corpus The corpus is a collection of speech samples of 19 male speakers, who spoke the word mango (Cole, Noel, and Noel, 1998). The data were collected over digital telephone lines, at 8kHz 8-bit. In the experiment, seven randomly selected speakers compose the enrolled population. Eight samples from each speaker are used to train the speaker model. Four different speakers with twelve samples each are used to compose the impostor model. In the testing phase, 4 samples of each enrolled speaker and 68 samples from 8 impostors are used. 3.2 Baseline Results In order to compare the results of the channel selection criteria, the system was trained and tested with all channels. The best identification result obtained with 15 channels is 80%. 3.3 Channels Selection Criteria A separability criterion is used to select the channels that are important to characterize a speaker s identity. This approach reduces the number of channels combinations that can be used in the classification process by choosing the only ones that have good class separability. In order to define class separability criterion, within-class and between-class matrices are used to formulate that criterion (Fukunaga, 1990). The within-class matrix shows the scatter of samples around their respective expected vectors (equation 5). S L = w P i i=1 Σ i (5) The between-class matrix is the scatter of the expected vectors around the mixture mean as in equation 6. S b M 0 = = L i= 1 L i= 1 P i ( M M )( M M ) PM i i i 0 i 0 T (6) where M 0 represents the expected vector of the mixture distribution. However, to formulate a criterion for class separability, it is necessary to convert these matrices to a number. There are several ways to do this, and the chosen ways to perform this conversion are described in equations 7 and 8: J 1 = tr( S w S ) (7) 1 b tr( Sb ) J 4 = (8) tr( S ) w The task is to find the combination of the original channels X s for which the criteria functions J 1 or J 4 of i s X X s i X ~ s class separability are maximized. Thus, a subset is sought using the equation 9. ~ J ( X ) = max J ( X ) i = 1,4 (9) 3.4 Results The method for channel selection uses the class separability criteria described in section 3.2 to estimate more precisely the relative effectiveness of the each channel. The method begins by evaluating the separability criteria of groups of 6 channels. Then one channel is added and it is checked if the criteria is maximized or not. In case of maximization, the channel is added and the search goes on. After the channel selection, some of the classification results and the features used in the speaker identification system are presented in Table 3. Table 3 Classification error rates and the frequencies range used in the classifier. False False Features Freq J4 Rej % Acc % Hz kHz 0-275Hz 1-2kHz 2.5-4kHz 0-250Hz 1-2kHz 2.5-4kHz 0-2kHz 3-4kHz 0-.5kHz 1-2kHz 2.5-4kHz 0-.5kHz 1-2kHz 3-4kHz 0-275Hz 1-2kHz 3-4kHz 0-125Hz 1-2kHz 3-4kHz 0-275Hz 1-1.5kHz 2.5-4kHz

113 The class separability criteria J 1 (equation 7) and J 4 (equation 8) are very helpful to decide which combination has a good separability, but J 4 showed to represent better the class separability. Based on Table 2, the combination of channels that represents better the speaker identity is: 1, 2, 9, 10, 11, 12, 14, and 15. Most of the selected channels in this paper agree with the channels selected in (Besacier, Bonastre, and Fredouille, 2000). Figure 3 shows some channel combination and the false rejection error for each one. Channel Figure 3 False rejection error rates and the channels used in each classification It can be noticed from Figure 3 that some channels, such as 13, do not help at all the system, which can be assumed that there is redundancy of information of the speaker. Another reason for only few channels describe better the speaker specific information is that the context or the phonemes in the word used in this paper carry more information about the speaker (Kajarekar, 1999). 4 CONCLUSION False rejection % The tree-structured filter bank described in this paper proves to be suitable for the speaker identification problem. The feature extraction process does not take long time to be performed but this approach cannot be used for pipelined input signals because it demands that the entire signal be passed through the filter bank at once. The nonuniformity of the tree-structured filter bank increases the complexity of the feature extraction because each channel can have different number of samples coming out of it. As the results presented in section 3.3, the frequencies from 0 to 250Hz (channels 1 and 2), from 1 to 2kHz (channels 9 to 12), and from 3 to 4kHz (channels 14 and 15) play an important role in the criteria of class separability. The improvement in performance shows that the selection of channels is very important in the specific information of the speaker. As future work, different features can be tested in order to select the important frequency bands. Another interesting work would be the development of an on-line selection method. ACKNOWLEDGEMENT The author would like to express his thanks to CAPES (Federal Agency for Post-Graduate Education), which supports this work. REFERENCES BESACIER, L; BONASTRE, J. F., and FREDOUILLE, C. Localization and Selection of Speaker-specific Information with Statistical Modeling. Speech Communication, v. 31, p , COLE, R.; NOEL, M., and NOEL, V. The CSLU Speaker Recognition Corpus. In Proceedings of ICSLP, Sydney, Australia, DODDINGTON, G. R. Speaker Recognition Identifying People by their Voices. In: proceedings IEEE, v. 73, pp , 1985 FUKUNAGA, K. Introduction to Statistical Pattern Recognition. San Diego: Academic Press, FURUI, S. An Overview of Speaker Recognition Technology. In: Workshop on Automatic Speaker Recognition. Martigny, Switzerland, pp KAJAREKAR, S.; MALAYATH, N. and HERMANSKY, H., Analysis of Speaker and Channel Variability in Speech. In: Proceeding of the Workshop on Automatic Speech Recognition and Understanding, Keystone-CO, Dec LANG, M.; Selesnick, I.; ODEGARD, J. E. and BURRUS, C.S. Constrained FIR Filters Design for 2-Band Filter Banks and Orthonormal Wavelets. In: IEE DSP Workshop, 6. Oct MARKOV, K. P. and NAKAGAWA, S. Textindependent Speaker Recognition using Nonlinear Frame Likelihood Transformation.. Speech Communication, v. 24, p , MOORE, B. C. J. An Introduction to the Psychology of Hearing. San Diego: Academic Press, REYNOLDS, D. Experimental Evaluation of Features for Robust Speaker Identification. In:

114 IEEE Trans. Speech and Audio Processing, v. 2, pp , REYNOLDS, D. Speaker Identification and Verification using Gaussian Mixture Speaker Models, Speech Communication, v. 17, pp , SHARMA, S. R. Multi-Stream Approach to Robust Speech Recognition. Beaverton: ECE/OGI, (PhD Thesis) STRANG, G. and NGUYEN, T. Wavelets and Filter Banks. Wellesley: Wellesley-Cambridge Press, 1997.

115 TÉCNICAS DE SCAN EM REDES USANDO OS RECURSOS DA PILHA TCP/IP Antônio Pires de Castro Júnior Instituto de Computação (IC) Universidade Estadual de Campinas UNICAMP 6176, , Campinas SP, Brasil Nelson Luis Saldanha da Fonseca Instituto de Computação (IC) Universidade Estadual de Campinas UNICAMP 6176, , Campinas SP, Brasil RESUMO As técnicas de scan são usadas para analisar e obter informações sobre o ambiente computacional. Este artigo faz um levantamento das principais técnicas utilizadas para fazer scan em redes usando os recursos da pilha TCP/IP. ABSTRACT Scanning is used to analyze and to get descriptive information about a computer environment. This paper surveys scanning techniques for the TCP/IP stack. Network security and scanning are discussed in the paper. 1 INTRODUÇÃO Atualmente, tem surgido um grande número de ferramentas e técnicas para auxiliar no gerenciamento e na auditoria de ambientes computacionais. Estas se baseiam em, simplesmente, fazer o scan do ambiente com o intuito de obter informações relevantes para fazer seu levantamento topológico. Apesar da finalidade de ajudar no trabalho dos administradores e profissionais de segurança em redes de computadores, estas técnicas estão sendo, cada vez mais, utilizadas para fins maliciosos. Segundo (Longman, 1995), scan significa: 1. Examinar uma área cuidadosamente, procurando uma pessoa ou coisa em particular; 2. Ler alguma coisa rapidamente para entender seu significado principal ou encontrar alguma informação em particular. Em redes, scanning é um método para descobrir e explorar canais de comunicação em ambientes computacionais. A idéia é testar todos os canais que ficam escutando na rede quanto possível. Os principais tipos de informações coletadas pelas técnicas de scan são: Identificar os serviços UDP/TCP sendo executados; Arquiteturas dos Sistemas (Sparc, Alpha, x86); Endereço IP das máquinas alvo; Sistema Operacional da máquina alvo. Visto por este prisma, diversos recursos da pilha TCP/IP podem ser aplicados com o intuito de obter informações relevantes do ambiente computacional. Esta possibilidade se deve ao fato de existir opções no protocolo TCP/IP que divulgam e registram informações do ambiente. Outro fato que permite obter informações é a existência de diferentes implementações do protocolo TCP/IP para diferentes plataformas. Estas diferenças são exploradas pelas técnicas de scan. O presente artigo faz uma revisão das técnicas de scanning, as quais obtém informações do ambiente computacional através da pilha TCP/IP. 2 OPÇÕES DO DATAGRAMA IP O campo de opções do cabeçalho IP não é requerido em todo datagrama, é muito usado para fazer testes e análises em redes. O comprimento deste campo varia dependendo de quais opções são selecionadas e as duas pontas devem, previamente, concordar em utilizar esta opção. Nesta seção são apresentadas as possíveis opções que podem acompanhar o datagrama IP para testar e obter informações do ambiente computacional. 2.1 Opção Record Route A opção record route permite o remetente criar uma lista vazia de endereços IPs e fazer com que cada roteador que repasse este datagrama insira seu endereço IP na lista. Quando o datagrama chega, a máquina destino pode extrair e processar a lista de endereços IPs. Usualmente, o computador que recebe o datagrama ignora o record route. Para usar o record route as duas máquinas tem que concordar em coorperar. 2.2 Opção Source Route A idéia por trás do source route é prover uma maneira do remetente ditar o caminho que o datagrama deve seguir para chegar no destino. O remetente cria uma lista de endereços IPs que especificam o caminho que o datagrama deve seguir. Ele é importante, por exemplo, para testar o throughput de uma rede física em particular. O IP suporta duas formas de source routing: strict source routing; e loose source routing.

116 2.3 Opção Timestamp Esta opção trabalha como o record route, só que cada entrada na lista contém dois itens de 32 bits: o endereço IP; e um timestamp. Tendo a rota registrada ao longo do caminho com o timestamp é útil porque permite o destino saber exatamente qual caminho o datagrama seguiu. Para evitar que os roteadores divulguem estas informações, os administradores de redes devem desabilitar as opções do datagrama IP no sistema operacional e/ou fazer a filtragem desses dados. 3 USANDO O ICMP PARA FAZER SCAN O Internet Control Message Protocol é um mecanismo que reporta erros ou mensagens de atenção no envio de pacotes na rede, ele foi projetado como um mecanismo de propósito específico para a família de protocolos TCP/IP. O protocolo ICMP reporta diferentes tipos de erros, dependendo do valor inteiro contido no campo TYPE do cabeçalho ICMP. Nesta seção são detalhados os tipos de mensagens ICMP que podem ser utilizados para fazer scan em ambientes computacionais. 3.1 Testando o estado dos Hosts na rede, usando o Ping Os protocolos TCP/IP provêem uma facilidade para ajudar o administrador da rede ou usuários à identificar problemas de rede. A ferramenta mais usada invoca mensagens ICMP echo request e espera os ICMP echo replays, são usados para testar quando um destino é alcançado ou se está respondendo. Em vários sistemas, o comando usado para invocar o envio de mensagens ICMP echo request é o ping. Sofisticadas versões do ping enviam uma série de ICMP echo request, captura as respostas, e provê estatísticas sobre os datagramas. Versões menos sofisticadas enviam somente um ICMP echo request e espera o ICMP echo replays. Quando um ICMP echo request é enviado para um endereço de broadcast, todos os hosts que fazem parte daquela rede vão responder, assim, pode-se descobrir todos os hosts e seus endereços IP de uma determinada rede, como no exemplo abaixo: ping Existem também endereços de grupos padronizados. Todos os computadores na sub-rede respondem: ping ou, todos os roteadores na sub-rede respondem: ping Apesar da RFC estabelecer que todo roteador ou host deve implementar esta funcionalidade não é aconselhável permitir que estes forneçam ICMP echo replays, por este motivo vários administradores de redes desligam esta funcionalidade de seus servidores ou hosts que estão em contato direto com a Internet. 3.2 Testando Destination Unreachable Quando um roteador não pode repassar ou entregar um datagrama IP, ele envia uma mensagem de destination unreachable de volta para a origem. Esta mensagem é importante para descobrir a topologia da rede e muito usada pelas técnicas de scan, pois fornecem informações importantes, como: O endereço IP do host que originou a mensagem; Permite saber se o ambiente possui trechos com MTU menores; Permite saber se existem filtros (firewalls) no ambiente. 3.3 Controle de fluxo e Congestionamento Source Quench A mensagem ICMP source quench reporta o congestionamento do host que originou a mensagem. Ocorre porque o remetente envia mais pacotes do que o destino consegue repassar. Esta mensagem é uma requisição dizendo para o host que a recebe para reduzir o seu fluxo de transmissão de datagramas. Usualmente, roteadores congestionados enviam uma mensagem source quench para cada datagrama descartado. É utilizada para controle de fluxo e congestionamento, a sua implementação não é obrigatória. Esta mensagem fornece a informação, para o remetente, que existe um roteador no caminho cujo repasse de datagramas é lento, obtendo, assim, no cabeçalho do datagrama IP, o endereço IP deste roteador. 3.4 Aprendendo e mudando as tabelas de roteamento - redirect Os roteadores são responsáveis pelo repasse de pacotes de uma rede para outra, eles devem aprender com a rede, ou seja, se uma determinada rota muda, seja temporariamente ou permanentemente, o roteador deve mudar esta rota na tabela de roteamento.

117 Para que estes roteadores aprendam com o tempo foi criada a mensagem de ICMP redirect. Quando um roteador detecta que um host não está usando a melhor rota, ele envia uma mensagem de ICMP redirect, requisitando que o host mude sua rota, o host, então, obedece e muda sua tabela de roteamento. Na mensagem ICMP redirect, além dos campos normais, existe um campo de 32 bits que é o endereço do novo roteador que o host deve usar para trafegar o datagrama, e esta rota deverá ser incluída na sua tabela de roteamento. Para evitar que um host envie esse tipo de mensagem, deve ser desabilitada esta funcionalidade no sistema operacional. 3.5 Diminuindo o TTL time exceed Quando um roteador descarta um datagrama porque o time-to-live (TTL) chegou a zero ou ocorreu um timeout enquanto esperava por fragmentos do datagrama, ele envia uma mensagem ICMP time exceeded de volta para o host que originou o datagrama. Para identificar o roteador mais próximo de um determinado host é só enviar um datagrama com TTL igual a um, o roteador, então, irá enviar de volta a origem uma mensagem ICMP time exceeded com seu endereço IP. Desta maneira um usuário mal intencionado poderá identificar os roteadores da rede. O ICMP time exceeded é utilizado pelo traceroute para descobrir o endereço IP dos roteadores no caminho. 4 USANDO A CAMADA DE TRANSPORTE TCP/IP Nesta seção são descritos os tipos de técnicas utilizadas para fazer scan usando recursos da camada de transporte TCP/IP. 4.1 Vanilla TCP connect() scanning É a forma mais básica de TCP scanning. Tenta abrir uma conexão em toda porta interessante, se a porta estiver no estado listening, a conexão terá sucesso, se não estiver no estado listening, a conexão não terá sucesso. A grande vantagem desta técnica e que qualquer usuário pode realizála, não exige privilégios especiais. Outra vantagem é a sua velocidade. Possui como desvantagem a facilidade de detecção e filtragem. É o método de scanning mais rápido suportado pelo nmap. 1 1 É a ferramenta de scan em redes mais conhecida atualmente. 4.2 TCP SYN (half open) scanning Não abre uma conexão TCP completa. É enviado um pacote com o flag SYN setado e espera a resposta. Se a resposta for um SYN/ACK a porta está no estado listening, se a resposta for um RST a porta não está listening. A vantagem é que vários sites não registram esta tentativa de conexão, e a desvantagem é que precisa ter privilégios de root (super usuário) para construir pacotes SYN. 4.3 TCP FIN scanning Envia um pacote TCP com o flag FIN setado para uma determinada porta e espera pela resposta. Se a resposta vier com o flag RST setado é porque a porta está no estado fechado. Já as portas abertas, geralmente, ignoram o pacote. A vantagem desta técnica é que diversos filtros não a detectam. 4.4 TCP XMAS scanning Envia um pacote TCP com todos os flags setados (URG, ACK, PST, RST, SYN e FIN) para uma determinada porta e espera pela resposta. 4.5 TCP NULL scanning Envia um pacote TCP sem nenhum flag setado para uma determinada porta e espera pela resposta. Se na resposta vier o flag RST setado e porque a porta esta no estado fechado. 4.6 SYN/FIN scanning using IP fragments (bypass some packet filters) Tem a vantagem de transpor filtros. Esta técnica é uma modificação das técnicas da subseção 4.2 e subseção TCP ACK and Window scanning É uma combinação das técnicas de ACK scan e Window scan. O ACK scan é muito usado para saber se determinada porta esta sendo filtrada ou não, para isso, é enviado um pacote com o flag ACK setado, se um RST voltar é porque a porta não é filtrada. Se não voltar nada ou um ICMP unreachable voltar é porque a porta é filtrada. O Window scan é similar ao ACK scan, só que às vezes pode-se detectar portas abertas que podem estar sendo filtradas, isso acontece devido à anomalia do tamanho da janela TCP reportada por alguns SOs. 4.8 UDP raw ICMP port unreachable scanning Consiste em enviar uma mensagem UDP e esperar pela resposta ICMP de erro para portas

118 fechadas. Pode ocorrer o falso positivo, porque o UDP não garante a entrega de pacotes. 4.9 TCP Ping scanning Consiste, basicamente, em enviar um pacote TCP com o flag SYN setado e esperar o pacote com os flags SYN/ACK, serve para identificar se um host está respondendo ou não Remote OS identification by TCP/IP fingerprinting Consegue identificar os SOs das máquinas alvo. As técnicas utilizadas podem ser encontradas na seção 6. 5 SERVIÇOS E PORTAS MAIS COMUNS UTILIZADAS PELAS TÉCNICAS DE SCAN As técnicas de scan baseiam-se principalmente em obter informações de lugares, como, por exemplo, as portas, para saber quais os serviços estão sendo executados em determinadas máquinas (programas daemons). Obtendo informações dos serviços, como tipos e versões dos programas, os atacantes podem saber quais técnicas aplicar para invadir o ambiente. A técnica de scanear portas e bastante difundida, por isso nesta seção são expostas algumas portas e serviços comumente scaneadas. 5.1 Echo (UDP, TCP porta 7) Responde aos pacotes UDP e devolve os caracteres enviados pelos pacotes TCP. Este serviço pode ser usado pelo atacante para confirmar se existe um computador com aquele determinado endereço IP e se este está funcionando, "vivo". 5.2 Systat (TCP porta 11) O serviço systat é designado para prover informações sobre o status do computador para outros computadores na rede. Vários sites tem configurado o arquivo /etc/inetd.conf para que as conexões TCP na porta 11 sejam respondidas com a saída dos comandos who e w. Este serviço provê certas informações como: usernames; login times; e hosts de origens que podem ser usados para desferir ataques contra o sistema. Para verificar se este serviço esta sendo usado em um computador basta, somente, fazer um telnet para a máquina alvo na porta 11. Para desabilitar o serviço, simplesmente comente ou remova a linha começando com a palavra systat do arquivo /etc/inetd.conf. 5.3 Daytime (UDP, TCP porta 13) O serviço daytime é designado para fornecer algumas informações, como: o dia da semana; o mês corrente; o dia do mês; o horário; e o ano corrente. Estas informações são apresentadas de forma clara e legível para o usuário, como apresentado abaixo: ra995477@xingu% telnet jaguari 13 Trying Connected to jaguari.dcc.unicamp.br. Escape character is '^]'. Wed Jun 14 18:28: Connection closed by foreign host. Estas informações são perigosas porque alguns programas usam estas como base para a chave criptográfica, comprometendo, assim, alguns protocolos seguros. 5.4 File Transfer Protocol FTP (TCP porta 20 e 21) O File Transfer Protocol (FTP) permite o usuário transferir arquivos entre sistemas. As implementações UNIX consistem de dois programas: o programa cliente ftp; e o programa servidor /etc/ftpd ou /usr/etc/in.ftpd. A porta 21 é usada para enviar comandos e a porta 20 é usada, ocasionalmente, para enviar dados, entretanto é mais comum para o cliente e servidor negociar o número da porta, sendo esta maior que A comunicação FTP pode ser passiva ou ativa. Geralmente, quando um usuário conecta em um servidor FTP, este mostra para o cliente algumas informações, como: hostname e domínio do servidor; o programa daemon FTP usado pelo servidor; e, também, o sistema operacional do servidor. Estas informações deveriam ser barradas pelo administrador da rede que opera o servidor de FTP, pois facilitam a vida dos atacantes. Um problema neste protocolo é que os dados trafegam em claro, assim, há o perigo dos sniffers TELNET (TCP porta 23) Telnet é um serviço que permite o usuário logar em um computador remoto, fornecendo um terminal virtual. No UNIX a versão do telnet é implementada com os programas cliente e o servidor telnet. 2 São programas que ficam observando a rede e pegando informações que trafegam sem cifragem.

119 Como no FTP, quando um usuário conecta em um servidor TELNET, este mostra para o cliente algumas informações, como: hostname e domínio do servidor; e o sistema operacional do servidor. Estas informações deveriam ser barradas pelo administrador da rede, pois, também, facilitam a vida de um atacante. Como mostrado abaixo: ra995477@xingu% telnet xingu Trying Connected to xingu.dcc.unicamp.br. Escape character is '^]'. UNIX(r) System V Release 4.0 (xingu) login: Um problema neste protocolo é que os dados trafegam sem cifragem, assim, há o perigo dos sniffers. A melhor maneira para não permitir sniffers de pacotes na rede é através de one-time passwords e/ou criptografia. Um outro problema do TELNET é que os atacantes podem hijacking uma sessão telnet que está em progresso, usando a técnica conhecida como session hijacking. Então, depois que o usuário loga no sistema usando sua senha, o atacante pode obter o controle da sessão e usar qualquer comando que quiser. A única maneira de eliminar esta técnica de telnet hijacking é através do uso de criptografia. Conexões de rede, usando telnet, permitem ao atacante obter muitas informações sobre a máquina alvo, as quais podem ser usadas para localizar outros pontos de vulnerabilidade na rede. 5.6 Simple Mail Transfer Protocol SMTP (TCP porta 25) O Simple Mail Transfer Protocol é um serviço para transferência de mail entre computadores. Existem diferentes sistemas de entrega de na internet, como: smail; MMDF; PMDF; sendmail e outros. O programa telnet pode, também, ser usado para conectar outras portas TCP, as quais estão associadas processos que estão no estado listening. Se o atacante quiser saber qual o serviço de SMTP usado, ele pode, simplesmente, fazer um telnet para o servidor na porta 25, o servidor de SMTP fornece algumas informações, como: o nome do host e o domínio da rede; o servidor e a versão do serviço de SMTP; informações sobre o dia, mês, ano e horário. 5.7 TACACS (UDP porta 49) O TAC Access Control Server é um protocolo que é usado para autenticar logins para servidores de terminal. TACACS define o conjunto de tipos de pacotes que podem ser enviados do servidor de terminal para o servidor de autenticação. O pacote de login é uma indagação, a qual indica que o usuário deseja logar no servidor de terminal. O servidor TACACS examina o username e o password que estão presentes no pacote de login e envia de volta o pacote de resposta que pode ser tanto de aceite ou de rejeição. O perigo neste serviço é que a senha não é criptografada com o TACACS. Então, eles são susceptíveis aos sniffers. 5.8 Domain Name System DNS (TCP e UDP porta 53) O Domain Name System é uma base de dados distribuída que é usada pelos computadores para conversão de endereços IP em nomes de hosts e vice-versa. O DNS é um serviço importante de ser mencionado neste artigo, porque, se o atacante ganha acesso neste servidor, ele obtêm informações de todos os hosts da rede, como: endereço IP dos hosts; nome dos hosts; outros servidores de DNS; e mail exchange. Com estas informações o atacante consegue mapear toda a rede. 5.9 Trivial File Transfer Protocol TFTP (UDP porta 69) O Trivial File Transfer Protocol é um programa de transferência de arquivo baseado no UDP, ou seja, não provê conexão e, por consequência, segurança. Existe um conjunto de arquivos que o programa TFTP permite transmitir, esses arquivos podem, então, ser transmitidos para qualquer um na internet que solicitar por estes. Como o TFTP não provê segurança, muitos administradores de redes não estão permitindo executar o seu daemon. Se for necessário usar este serviço, o administrador deve tomar o cuidado de restringir o acesso, para que o TFTP transfira arquivos, de um diretório específico finger (TCP porta 79) O programa finger é usado para mostrar várias informações dos usuários do ambiente, como: nome de login; nome completo; diretório no sistema; o tipo de shell usado; data do último login; e outras. O serviço finger revela informações que podem ser usadas como base para ataques engenhosos na rede. O finger permite, facilmente, que estranhos obtenham informações relevantes, como a lista de usuários do sistema, aumentando, assim, as chances de ataque. Para resolver este problema vários administradores decidem desabilitar este serviço.

120 Para remover este serviço basta tirar ou comentar a linha do servidor finger no arquivo /etc/inetd.conf HyperText Transfer Protocol HTTP (TCP porta 80) O HyperText Transfer Protocol é um protocolo que é usado para requerer e receber documentos de servidores na World Wide Web (WWW). Os servidores WWW já foram muito explorados, devido às vulnerabilidades nos seus códigos. Outros códigos muito explorados são os famosos CGIs, os quais devem ser bem administrados operacionalmente, pois deixam relevantes brechas de segurança no ambiente. Atualmente, a porta 80 é muito utilizada para realizar testes de fingerprinting, isso devido ao seu grande uso na internet Post Office Protocol POP (TCP porta 109 e 110) O Post Office Protocol é um sistema que provê aos usuários, nas máquinas clientes, uma maneira de acessar suas mensagens de , individualmente, sem montar o diretório de spool. O POP requer que o usuário se autentique para que possa acessar seu , uma das maneiras mais usadas atualmente e através de senhas. Estas senhas trafegam sem cifragem possibilitando o ataque através de sniffers. Mas, é claro, existem outros meios de se autenticar em um servidor POP, como usando a opção APOP, ou usando a versão do POP que tem sido modificada para trabalhar com Kerberos.(Garfinkel e Spaffor, 1996) 5.13 Sun RPC s portmapper (UDP e TCP porta 111) O programa portmapper é usado como parte do sistema Sun Microsystem's Remote Procedure Call para dinamicamente atribuir portas TCP e UDP usadas para chamadas de procedimento remoto. O portmapper é similar ao inetd daemon, de fato eles fazem a mediação da comunicação entre os clientes e os servidores da rede. Este fato facilita a vida das técnicas de scan, pois ficam sabendo, através de uma única porta (111), das comunicações que utilizam RPC no ambiente computacional. Este fato se deve em parte a padronização UNIX do portmapper, pois assume que a segurança será descrita pelos servidores e permite que qualquer cliente de rede comunique com qualquer servidor RPC. Vários administradores de redes restringem o acesso aos seus portmappers colocando regras de filtragem em seus firewalls para bloquear pacotes na porta Identification Protocol auth (TCP porta 113) O Identification Protocol permite identificar o usuário associado com uma particular conexão TCP/IP. Quando o servidor quer saber o nome real da pessoa que iniciou a conexão TCP/IP, ele simplesmente abre uma conexão com o identd daemon da máquina cliente, o qual envia uma representação humanamente legível do usuário que iniciou a conexão, usualmente o username e o full name contido no arquivo /etc/passwd. O Identification Protocol não é uma boa aproximação para segurança em redes, porque ele depende da honestidade dos computadores do outro lado da conexão TCP/IP Network News Transport Protocol NNTP (TCP porta 119) O Network News Transport Protocol é usado por grandes sites para transportar artigos usenet entre servidores de news. O protocolo, também, permite usuários em estações de trabalho distribuídas lerem news e postarem mensagens para a usenet. O NNTP pode ser configurado com uma lista de controle de acesso (ACL) para determinar quais computadores tem a permissão para usar quais características. A ACL é baseada no hostname, então, a segurança do NNTP pode ser quebrada através de IP spoofing ou através de ataque de DNS. É muito fácil que usuários não autorizados consigam ler ou postar artigos usenet sem ter permissão. Para proteger os servidores NNTP, os administradores inserem regras de filtragem em seus firewalls para evitar este tipo de ataque Network Time Protocol NTP (UDP porta 123) O Network Time Protocol é um dos últimos protocolos de uma série de protocolos projetados para deixar o ambiente computacional figurar o mesmo time. Apesar do NTP ser um protocolo sofisticado ele não foi projetado para resistir a ataques. Uma variedade de problemas podem ser aplicados se o atacante puder mudar o system clock, como: Atacante pode tentar o replay attack. Por exemplo: se o sistema usar kerberos, tickets antigos do kerberos podem ser novamente usados; ou se usar um sistema de password baseado no time, senhas antigas podem funcionar; Sistema de log trabalha com o tempo, se o atacante mudar o time para o futuro, o sistema

121 de log pode apagar algumas entradas no arquivo por pensar que estão antigas; Arquivos batch podem sofrer com a mudança do time. O daemon cron, por exemplo, pode não ser executado se o time for mudado Simple Network Management Protocol SNMP (UDP porta 161 e 162) O Simple Network Management Protocol é um protocolo projetado para permitir o gerenciamento remoto de dispositivos na rede. Para ser gerenciado com o SNMP, o dispositivo precisa ser capaz de receber pacotes na rede. O SNMP pode ser de grande valor para os atacantes. Os atacantes podem obter importantes informações se construírem cuidadosas mensagens SNMP, como: aprender a estrutura interna da rede; mudar configurações de rede; e, também, desligar algumas operações. Para combater esta vulnerabilidade, vários sistemas SNMP incluem provisões para segurança baseado em senhas. O SNMPv2 já inclui algumas características mais seguras NEXTSTEP Window Server NSWS (TCP porta 178) Aplicações NEXTSTEP usam conexões TCP na porta 178 para comunicar com o NEXTSTEP Display PostScript Window Server. A aplicação que pode conectar com o Window Server tem o total controle da estação de trabalho a qual o Window Server está executando, como o servidor X, a aplicação pode ler o conteúdo da tela e enviar eventos para outras aplicações, ou ler e escrever qualquer arquivo na estação a qual o usuário logado tem acesso rexec (TCP porta 512) O daemon de execução remota /usr/sbin/rexecd permite usuários executarem comandos em outros computadores sem estar logados neles. Um cliente abre uma conexão e transmite mensagens que especificam o username, a senha e o nome do comando a ser executado. Ao contrário do telnet, rexecd provê diferentes mensagens de erro para inválidos usernames e senhas. Se o username que o programa cliente provê for inválido, o rexecd retorna uma mensagem de erro: Login incorrect. Se o username é correto e a senha está errada, o rexecd retorna uma mensagem de erro: Password incorrect. Com estas informações o atacante pode testar no sistema nomes de contas válidas e suas senhas rlogin e rsh (TCP portas 513 e 514) Os programas rlogin e rlogind provêem serviço de terminal remoto que é similar ao telnet. A diferença é que o rlogin não requer que o usuário digite o seu username, e em conexões com computadores ou usuários confiáveis o computador que recebe a conexão deixa o usuário logar sem digitar a senha. Os programas rsh e rshd são similares ao rlogin e rlogind só que ao invés de logar o usuário, eles permitem o usuário executar um comando no sistema remoto. Estes serviços são perigosos devido ao seu nível de confiança interno ao ambiente, ou seja, os arquivos que contém informações sobre esta confiança, como: /etc/hosts.equiv; e ~/.rhosts. Em virtude dos fatos acima expostos, muitos administradores de redes bloqueiam estes serviços Routing Internet Protocol RIP (UDP porta 520) O protocolo de roteamento RIP é usado por gateways para trocar informações sobre novas redes e novos gateways. O RIP é implementado em vários sistemas UNIX pelo daemon routed. Outros daemons podem ser: gated; bird; e etc. O daemon routed é um programa que recebe pacotes de computadores na rede e acredita nestes computadores quando dizem: "Eu sou a melhor opção de gateway para você chegar em qualquer lugar". Então esta confiança permite aos atacantes mudarem a rotas de pacotes para poder analisa-los e/ou simplesmente confundir a rede. É claro que, também, o RIP divulga para outros gateways externos os endereços e rotas da minha rede interna. Por esta razão, vários sites em vez de usar rotas dinâmicas usam rotas estáticas. 6 TÉCNICAS PARA IDENTIFICAR O SISTEMA OPERACIONAL - FINGERPRINTING As técnicas de fingerprinting consistem em obter informações valiosas de uma máquina através da pilha TCP/IP, para descobrir qual o sistema operacional. Existem várias razões, motivação, para utilizar estas técnicas, algumas são mostradas abaixo: diversos furos de segurança dependem da versão do sistema operacional; permite aos atacantes (hackers) refinarem mais suas estratégias de ataque; possibilita empregar engenharia social Estas técnicas podem ser empregadas porque as RFC's muitas vezes não explicam, claramente,

122 como os sistemas devem tratar certas situações, e isto implica em implementações diferentes das pilhas TCP/IP. Esta seção trata, então, das técnicas de fingerprinting, tanto as clássicas como as mais inteligentes, usadas pelas técnicas de scan. 6.1 Técnicas clássicas As técnicas clássicas são, na verdade, métodos comuns e simples de obter informações valiosas de um ambiente computacional. ra995477@xingu% telnet tigre SunOS 5.7 login: Mais informações: ra995477@xingu% telnet Red Hat Linux release 6.0 (Hedwig) Kernel on na i686 login: Não é necessário usar técnicas elaboradas de fingerprinting se a máquina anuncia para todo mundo qual é o seu SO corrente. Infelizmente, muitos fabricantes de sistemas deixam este tipo de informação e os administradores não as removem. O problema em confiar nesta técnica e que os administradores estão desabilitando este tipo de informação, muitos sistemas oferecem poucas informações e é muito fácil o administrador mudar a configuração com o objetivo de fornecer informações que não refletem a realidade. Mas mesmo desabilitando os banners, muitas aplicações permitem recuperar este tipo de informações sobre o sistema. Por exemplo, o ftp: ra995477@xingu% ftp tigre Connected to tigre.dcc.unicamp.br. 220 tigre FTP server (SunOS 5.7) ready. User (tigre.dcc.unicamp.br:(none)): ra Password required for ra Password: Se for permitido FTP anonymous, pode ser feito o download do /bin/ls ou outro comando binário e determinar para qual arquitetura este comando foi desenvolvido. Outra técnica clássica inclui a recuperação do registro do DNS (raramente funciona) e aplicar engenharia social. Se a máquina está com a porta 161/udp (snmp) aberta, pode-se conseguir muitas informações usando a ferramenta snmpwalk da distribuição CMU SNMP, da seguinte forma: snmpwalk < IP_máquina > public system 6.2 Técnicas mais elaboradas Existem muitas técnicas que podem ser utilizadas para identificação da fingerprinting da pilha de rede. Basicamente, a técnica consiste em identificar diferenças entre sistemas operacionais e desenvolver um código que classifique estas diferenças. Se combinar estes dois processos, poderá chegar a um nível de refinamento da informação satisfatório. Neste item são apresentadas algumas das principais técnicas utilizadas para identificação de SOs, estas são utilizadas por ferramentas de scans como o nmap[nmap, 2000] e o nessus[nessus, 2000] Investigação de FIN (FIN probe) Nesta técnica é enviado um pacote FIN (ou qualquer pacote sem o flag de ACK ou SYN) para uma porta aberta e esperamos por uma resposta. A implementação correta da RFC793 3 diz para não responder, mas muitas implementações furadas como o MS Windows, BSDI, CISCO, HP/UX, MVS e IRIX respondem com um RESET Investigação FALSA (BOGUS flag) A idéia consiste em enviar um flag TCP indefinido (64 ou 128) no cabeçalho TCP de um pacote SYN. As versões do Linux anterior ao mantêm este flag setado em sua resposta. Não foi encontrado em outro sistema este erro. Porém, outros sistemas operacionais parecem resetar a conexão (resposta com RST) quando recebem um pacote SYN+BOGUS. Este comportamento é útil para identificar o sistema Padrão TCP de ISN (TCP ISN Sampling) A idéia por traz desta técnica é a identificação de padrões do Número Inicial de Seqüência (ISN - Initial Sequence Number) escolhido pelo TCP ao responder um pedido de conexão. Estes números podem ser classificados em vários grupos, como: Aqueles que sempre utilizam o mesmo valor, como: hub3com (usa 0x803); impressora Apple LaserWriter printers (usa 0xC7001); Tradicional 64K, utilizada em muitas versões antigas do Unix; Modelo que depende do horário onde o ISN é incrementado por um valor fixo a cada período de tempo, utilizado pelo windows; 3 A RFC793 especifica que portas fechadas devem responder com RST (RESET) e portas abertas devem ignorar o pacote, mas muitos fornecedores não seguem as especificações, e respondem com RST aos pacotes FIN enviados para portas abertas.

123 Incremento randomico, utilizado pelas versões mais novas de Solaris, IRIX, FreeBSD, Digital, Unix, Cray, Linux 2.2.* e muitos outros; Randomico verdadeiro, utilizado pelo Linux 2.0.*, Open VMS, AIX mais novo, etc; O tradicional 64K e o modelo que depende do horário são muito fáceis de adivinhar, sem falar no valor constante. O nmap(nmap, 2000) é o primeiro sistema que utiliza esta técnica.(fyodor, 1998) Bit de não fragmentação Diversos sistemas operacionais começaram a setar o bit de não-fragmentação em alguns pacotes enviados. Com isso temos vários benefícios de desempenho. E bom observar que nem todos os sistemas operacionais fazem isso e alguns fazem em diferentes casos, sendo assim, se analisarmos estes bits podemos obter mais informações sobre o nosso alvo Janela deslizante inicial do TCP (TCP Initial Window) Esta técnica envolve análise do tamanho da janela dos pacotes de retorno. Os scanners antigos classificam o sistema operacional, como BSD 4.4, quando o pacote RST possui uma janela com valor diferente de zero. Os scanners mais novos como queso(queso, 2000) e nmap(nmap, 2000), através das janelas, conseguem determinar o tipo de sistema operacional. Este teste fornece uma série de informações, uma vez que alguns sistemas operacionais podem ser identificados unicamente pela janela (por exemplo, AIX é o único sistema operacional que usa (0x3F25)). Na sua nova pilha TCP, que foi completamente rescrita para o NT5 a Microsoft usa 0x402E, isto é interessante, pois se trata, exatamente, do mesmo número utilizado pelo OpenBSD e FreeBSD Valor do ACK (ACK Value) Embora algumas pessoas pensem que este valor seja um padrão, as implementações usam valores diferentes para o bit ACK em alguns casos. Por exemplo: enviando um pacote com FIN/PSH/URG para uma porta TCP fechada, muitas implementações vão setar o ACK com o mesmo ISN inicial enviado, entretanto o Windows e algumas impressoras enviam seq+1; enviando um SYN/FIN/PSH/URG para uma porta aberta, o windows comporta-se de forma inconsistente, devolvendo o próprio seq ou seq+1 ou um valor randomico Mensagem ICMP de erro (ICMP Message Quoting) As RFCs especificam que as mensagens ICMP de erro devem conter uma pequena parte da mensagem que causou o erro. Por exemplo, para uma mensagem de port unreachable, quase todas as implementações enviam somente o cabeçalho IP + 8 bytes da mensagem que gerou o erro. Porém, Solaris retorna um pouco mais e o Linux retorna muito mais que o Solaris. O bom disso é que as ferramentas de scan, como o nmap(nmap, 2000), podem identificar se um sistema é Solaris ou Linux mesmo que eles não tenham portas abertas Tipo de Serviço (Type of Service TOS) Esta técnica verifica o valor do campo tipo de serviço (TOS) retornado pelas mensagens de ICMP port unreachable. Quase todas as implementações setam este tipo de erro ICMP com valor zero, mas o Linux usa 0xcC0. Este não é um valor padrão para TOS. Se este campo for zero é possível identificar as versões antigas, logo se pode identificar as versões velhas e novas do Linux Controle de Fragmentação (Fragmentation Handling) Esta técnica tira proveito do fato de que as várias implementações, freqüentemente, fazem a remontagem dos pacotes de forma diferente. Algumas escrevem a porção antiga juntamente com a nova e em outros casos a porção antiga tem precedência. Existem várias formas diferentes de determinar como o pacote foi remontado Opções do TCP (TCP Options) Apesar de nem todas as pilhas TCP/IP implementarem, as opções TCP são realmente uma mina de ouro em termos de divulgação de informação. Estas opções servem para negociar o tamanho do segmento (MSS - Maximum segment size) com o destino. Esta técnica funciona identificando se uma máquina implementa as opções, enviando um pacote com as opções setadas. Se o alvo possuir suporte ele responderá o segmento com as opções, também, setadas. Um exemplo de opções, tirado do nmap é: Window Scale=10;NOP;Max SegmentSize=265;Timestamp;End of Ops; Alguns sistemas operacionais, como a recente versão do FreeBSD, suportam todas as opções acima, enquanto outros, como o Linux, suportam apenas algumas. O kernel mais novo do Linux

124 suporta todas. Esta característica do sistema operacional o torna mais vulnerável a ataques TCP. Mesmo que vários SOs suportem opções semelhantes, pode-se diferenciar estes pelos valores das opções. 7 PRINCIPAIS PROGRAMAS UTILIZADOS PARA FAZER SCAN Nesta seção são fornecidas algumas ferramentas que de alguma forma fornecem informações sobre o ambiente computacional. A maioria destas ferramentas são usadas por todos os SOs Unix like, como: ifconfig - Fornece informações das interfaces de rede habilitadas na máquina, como: endereço IP, de rede e de broadcast; qual o enlace de dados utilizado; endereço MAC do device; e algumas estatísticas. Muito utilizado em testes realizados pelos administradores e técnicos em redes de computadores; netstat - Fornece informações da própria máquina, permite visualizar a estrutura de dados relacionadas as redes, estatísticas desde o último boot e repetição temporizada para estatísticas instantâneas; nslookup - Converte um endereço IP em nome e vice-versa, permite saber quem é o servidor DNS; rpcinfo - Fornece informações dos serviços que utilizam rpc (mountd, nfs, rpcbind, rstatd, etc); ping - Permite obter informações se a máquina esta viva ou não. Este programa simplesmente envia um ICMP echo request e fica esperando o ICMP echo replays; finger - Mostra informações de usuários do ambiente e permite fazer engenharia social; tcpdump - É uma ferramenta de análise de rede, eavesdropping; ypwhich - Em redes que utilizam o NIS, retorna o nome do servidor de NIS; ypcat - Em redes que utilizam o NIS, imprime os valores de todas as chaves da base de dados do NIS; traceroute - É usado para descobrir rotas para determinado destino, obtendo os IPs dos roteadores no caminho; 8 - CONCLUSÃO As técnicas de scan são métodos utilizados para testar e debuggar ambientes computacionais com o intuito de analisar e obter informações relevantes para fazer seu levantamento topológico. Apesar da finalidade de ajudar no trabalho dos administradores e profissionais de segurança em redes de computadores, estas técnicas estão sendo utilizadas por usuários maliciosos. Assim, profissionais em informática precisam conhecer e saber como estas técnicas trabalham e funcionam para prevenir seus ambientes contra os invasores. Neste sentido, este artigo fez um levantamento das principais técnicas de scan em redes usando os recursos da pilha TCP/IP, dando uma abordagem direcionada para segurança em redes. Por fim é importante dizer que a segurança dos computadores está sempre em movimento. E os administradores de redes precisam estar atentos, pois os hackers usam as mais novas ferramentas de ataque para penetrar em sistemas. Em ordem para manter o host seguro, devemos manter as ferramentas sempre atualizadas. AGRADECIMENTOS Os autores agradecem o apoio financeiro do CNPq. REFERÊNCIAS BIBLIOGRÁFICAS LONGMAN, Group Ltda, Dictionary of contemporary English Longman, Third Edition, FYODOR, The Art of Port Scanning, FYODOR, Remote OS Detection via TCP/IP stack Fingerprinting, GARFINKEL, Simon and SPAFFOR, Gene, Practical UNIX & Internet Security, o reilly, 2 nd edition, COMER, Douglas E., InternetWorking with TCP/IP, prentice hall, volume I 3 rd edition, 1995 and 4 th edition, 2000, volume II 3 rd edition, CHESWICK, William R. and BELLOVIN, Steven M., Firewalls and Internet Security, addisonwesley, TANENBAUM, Andrew S., Redes de Computadores, editora campus, 3 rd edition, ARKIN, Ofir, Network Scanning Techniques, Understanding how it is done, PubliCom (Communications Solutions), novembro de 1999, disponível em em 06/2000. HOWTO s, Linux, Solaris e FreeBSD. NMAP, disponível em em 06/2000. Nessus, disponível em em 06/2000. Queso, disponível em em 06/2000.

125 TEIAS DE CONFIANÇA Paulo André Sant'Anna Perez 1 Departamento de Ciência da Computação Universidade Católica de Goiás Goiânia - GO paulo.perez@uol.com.br Paulo Licio de Geus Instituto de Computação Universidade Estadual de Campinas Campinas - SP paulo@ic.unicamp.br RESUMO Este artigo introduz na comunidade de segurança o modelo de relações de confiança denominado Teias de Confiança (WebS of Trust - WeST). Este contempla uma nova definição para confiança no âmbito computacional e enumera suas relações e utilizações. O conceito de Teia de Confiança é definido à partir do grafo de confiança construído com base nas relações entre as entidades. A arquitetura WeST é apresentada e sua aplicação em segurança é discutida. ABSTRACT This paper introduces the Webs of Trust (WeST), a new trust relationship model, to the security community. WeST adopts a new trust definition in a computing scope and enumerates trust relationships and its applications. The Webs of Trust concept is defined over a trust graph created using entity trust relationships. The WeST architecture is presented and its application is evaluated. 1. INTRODUÇÃO Nos dias atuais, a informática está presente em todos os segmentos da sociedade, seja em nossas casas, em escolas, na indústria ou no comércio em geral. Esta presença significativa, associada ao extensivo uso das redes de computadores, tem tornado a informática elo vital das comunicações e mais recentemente do comércio eletrônico. Neste contexto, não só nosso dinheiro mas também nossas informações pessoais, e porque não dizer nossas vidas, estão dependentes de todo este aparato tecnológico. Sendo assim, é cada vez mais crítico garantir requisitos mínimos de segurança, seja esta associada à integridade dos dados, aos direitos de acesso ou mesmo à verdadeira identidade dos componentes do sistema (usuários, computadores, processos e outros). A segurança de tais sistemas computacionais está fortemente dependente da segurança inerente a cada um de seus componentes e das relações entre eles, as quais envolvem troca de dados e/ou procedimentos. Estas relações normalmente envolvem preceitos de confiança, ou seja, para que aconteça o intercâmbio de informações entre as componentes do sistema, necessariamente em algum nível do relacionamento uma entidade deve "confiar" na outra, seja na veracidade, autenticidade ou corretude de suas informações. O paradigma de confiança tanto pode estar presente no nível de hardware, quando por exemplo a CPU solicita um operação de leitura do disco e "confia" ou não que os dados que recebeu da controladora são realmente os que estão gravados no disco; no nível de software, quando por exemplo um cliente tenta resolver um nome junto a um servidor DNS e obtém um endereço IP no qual ele irá ou não "confiar"; ou mesmo no nível do próprio usuário que pode ou não "confiar" na veracidade das informações que o sistema a ele apresenta. Estes diversos exemplos mostram o conceito de confiança presente em diferentes situações nas quais estão em jogo não só a segurança lógica (security) de um sistema como também a segurança física (safety) do mesmo. Na comunidade de segurança, até hoje, o conceito de confiança tem sido até certo ponto tratado de forma superficial ou mesmo negligenciado. Normalmente associou-se a idéia de que relações de confiança, entre os componentes de um sistema, são ponto-a-ponto e binárias, onde ou tem-se total confiança ou nenhuma confiança. A confiança total tipicamente está presente entre componentes membros de um mesmo grupo de sistema, fortemente acoplados a este, onde existe ou total ou quase total conhecimento de seus procedimentos internos e segurança (tanto lógica quanto física). Nos demais casos tradicionalmente atribui-se um nível de "não confiança" ou "confiança mínima". Em muitos casos, diante da veemente necessidade de se "confiar em alguém", foram definidas "entidades confiáveis", como é o caso das entidades certificadoras oficiais, e mecanismos de software foram implementados para assegurar a autenticidade e corretude das informações providas por tais entidades. Pode-se claramente ver um exemplo disto no atual modelo de comércio eletrônico através da Internet. A observação de que em diferentes contextos o uso de relações de "confiança" torna-se cada vez mais necessário, é a motivação para o desenvolvimento deste trabalho, onde pretendemos propor uma abordagem para o conceito de "confiança" que se adeqüe à concepção atual e que seja extensível o suficiente para satisfazer as necessidades advindas das novas, e cada vez mais complexas, tecnologias. 1 Doutorando do Instituto de Computação - Universidade Estadual de Campinas Campinas - SP

126 Neste trabalho apresentamos, para discussão e avaliação, os preceitos básicos do modelo que denominamos de Teias de Confiança (WebS of Trust - WeST), que devem ser vistos não como as respostas para todas as perguntas, ao invés, são o início da discussão de uma área ainda obscura dentro da comunidade de segurança. Nas seções que se seguem apresentamos o estado da arte em que se encontra o tema deste trabalho, discutimos sistemas correlacionados, apresentamos os objetivos deste trabalho, apresentamos nosso paradigma de confiança, as Teias de Confiança, para em seguida mostrar uma aplicação exemplo e analisar os questionamentos dela advindos. Por fim são tecidas as conclusões pertinentes ao trabalho que aqui é proposto. 1.1 Estado da Arte Em toda a bibliografia pesquisada pudemos observar que os trabalhos na área de segurança ou não abordam o conceito de confiança, ou o fazem de forma tradicional, binária e ponto-a-ponto. A proposição de uma nova abordagem para confiança, como pretendese neste trabalho, implica em inúmeras conseqüências passíveis de controvérsia e que portanto representam um sério entrave ao seu desenvolvimento. Normalmente tem-se a imagem de que "confiamos em quem conhecemos", e esta visão está presente em todos os trabalhos relacionados ao assunto e que podem ser vistos na Seção 1.2. Nestes, a ênfase recai sobre os aspectos criptográficos envolvidos (chaves, autenticidade, certificação, etc.) de modo que tais aspectos validem ou não as relações de confiança entre duas entidades. No nosso entendimento, a "confiança" a ser estabelecida entre as entidades de um sistema transcende aos mecanismos utilizados para ratificar a identidade dos participantes, onde podemos dizer que "antes mesmo de saber se estamos falando com quem imaginamos, temos de saber se podemos e o que podemos conversar com o outro, e também se podemos acreditar em suas respostas". Este conhecimento é íntimo à entidade e apenas ela pode responder por ele. Grandes esforços, feitos por grandes corporações, foram observados no sentido de desenvolver um modelo de confiança que possa ser largamente utilizado na Internet, uma vez que há uma demanda por isto. Porém tais esforços pecam ao normalmente basear seu modelo numa arquitetura hierárquica centralizada, a qual nem sempre é bem recebida por parte dos usuários. Acreditamos que existe uma demanda por um conceito mais amplo de "confiança", a qual justifica o desenvolvimento deste trabalho. 1.2 Trabalhos Correlatos Como dito, não existe especificamente nenhum trabalho que aborde confiança pelo mesmo ângulo que vemos; sendo assim, apresentamos algumas das diferentes abordagens que contribuem para nosso questionamento. PGP O sistema PGP [1] foi originalmente concebido para permitir a troca segura de mensagens entre usuários através da criação e validação das credenciais destes. No PGP, cada usuário é responsável pela geração e gerência de suas chaves públicas e privadas, as quais estão associadas a um identificador do usuário (tipicamente formado pelo do mesmo). Para que um usuário A conheça/confie em B, ele previamente deve ter de alguma forma (segura ou não) obtido e introduzido no sistema a chave pública de B. Da mesma forma, A pode pegar a chave pública de B, assiná-la (com sua chave secreta) e manda-la para C (que previamente conhecia A); desta forma A está "apresentando" B a C. Cada usuário deve informar ao PGP em quais usuários ele confia como "apresentadores" de novos usuários. O sucesso do PGP vem do fato deste permitir que relações de confiança entre uma entidade e outra possam ser estendidas aos demais componentes do sistema, isto desde que haja relações de "apresentação" entre eles, tornando o sistema apropriado para o uso em redes largamente extensas e caóticas, como é o caso da Internet. Pelo mesmo motivo que o PGP é elogiado, ele também é criticado. O fato de uma entidade "confiar" em outra torna esta vulnerável a falsas informações advindas da outra entidade. No nosso entender, à medida que se estabelece uma relação de confiança de uma entidade para com a outra, inerentemente herda-se a fragilidade que o PGP apresenta e não há forma absolutamente segura de contornar tal dificuldade. A relevância do PGP para este trabalho está no fato de que ele foi um dos primeiros a apresentar um modelo que usa a confiança, ponto-a-ponto e binária, mas que não é hierárquico. PolicyMaker Blaze e outros [2] apresentaram um modelo, que denominaram de Gerência de Confiança (Trust Management), que trata da gerência das relações de confiança entre os componentes de um sistema. A abordagem do modelo está centrada no uso de técnicas criptográficas para certificar a autenticidade de uma entidade para em seguida, baseando-se em políticas definidas pelo usuário, "confiar" ou não a execução de certos serviços. Este modelo deu origem à uma ferramenta intitulada PolicyMaker [3].

127 O mérito do PolicyMaker está no fato de que ele permite à entidade localmente manter as informações (chaves, políticas, etc.) pertinentes às demais entidades com quem se relaciona, de forma completamente autônoma. Blaze, em outros trabalhos [4], discute a descentralização do mecanismo de Gerência de Confiança adotado pelo PolicyMaker. O modelo de Gerência de Confiança apresentado no PolicyMaker tem seu foco na autenticidade das entidades participantes e o modelo de confiança continua a ser binário. KeyNote Como extensão ao PolicyMaker, Blaze e outros [5] propuseram um sistema mais complexo de Gerência de Confiança, que acrescenta uma linguagem para a definição de credenciais, "políticas" e "ações" a serem adotadas pelo sistema. O KeyNote não introduziu significativas modificações ao modelo de confiança anteriormente proposto pelo PolicyMaker, estando seu mérito nas novas facilidades de utilização e na RFC a que deu origem. 1.3 Objetivos do Trabalho Diante das motivações apresentadas anteriormente traçamos os objetivos deste trabalho, que são: definição de um conceito de confiança que seja poderoso o suficiente para atender as atuais necessidades do contexto de segurança, e flexível o suficiente para poder ser adaptado às contingências que ainda estão por vir; com base no conceito de confiança proposto, formular as relações de confiança entre as entidades de um sistema e as demais entidades; proposição de uma arquitetura de confiança que implemente o modelo proposto; proposição e implementação de um framework para o desenvolvimento de aplicações que possam fazer uso da arquitetura desenvolvida. avaliação dos resultados obtidos, comparando-os com os dos modelos existentes. Todos estes objetivos são por demais complexos e serão tratados ao longo de um extenso projeto de pesquisa em desenvolvimento no Laboratório de Administração e Segurança de Sistemas (LAS) do Instituto de Computação da Unicamp. Neste artigo são apresentados os conceitos básicos que conduzirão esta empreitada. 2. CONFIANÇA A imagem do conceito de confiança, que mais nos parece familiar, nos leva à idéia de associar confiança à segurança, ou seja, vendo os dois conceitos relacionados entre si, onde o quanto confiamos em uma entidade depende do quanto esta é segura. Esta visão, apesar de coerente e legítima, não é a que melhor pode expressar confiança entre entidades que são independentes entre si e que não necessariamente são plenamente visíveis, tendo seus detalhes internos revelados, aos olhos de terceiros. Este modelo de independência é o notoriamente visto em toda a Internet, ou mesmo em redes onde os clientes estão distribuídos ou fora do total controle da administração da rede. Sendo assim, é nosso objetivo propor uma definição para o conceito de confiança que transcenda à imagem popular, sendo flexível o bastante para ser aplicada às grandes redes hoje existentes, que não necessariamente são hierárquicas ou de total conhecimento de seus participantes, como é o caso da própria Internet. 2.1 Definição de Confiança Na busca de uma definição adequada para confiança no escopo de segurança, vamos confrontar diversas definições e destas estabeleceremos a mais pertinente ao contexto. Segundo o Dicionário Aurélio da Língua Portuguesa, tem-se: "Confiança: (S.) 1. Segurança íntima de procedimento 2. Crédito, fé 3. Boa fama 4. Segurança e bom conceito que inspiram as pessoas de probidade, talento, discrição, etc. 5. Esperança firme 6. Familiaridade 7.(Pop) Atrevimento, petulância 8.(Bras) Atos libidinosos; licença 9.(Bras/RS) Empregado (ou outra pessoa) de confiança. Esta definição claramente associa confiança à segurança, boa fé, que tem-se de um procedimento, de forma pessoal. Apesar de tal definição trazer à luz o aspecto segurança, a mesma ainda não é suficiente para o propósito deste trabalho, uma vez que este conceito ainda pode ser mais estendido. No Dicionário Collins da Língua Inglesa, tem-se a seguinte definição: Trust: n. confidence in the truth, reliability, etc. of a person or thing; obligation arising from responsibility; charge or care; arrangement in which one person administers property, money, etc. on another s behalf; property held for another; group of companies joined to control a market. - v. believe in and rely on; expect or hope; consign to someone s care. Nesta definição fica mais clara a relação entre confiança e credibilidade, veracidade que uma pessoa,

128 ou coisa, possui, inclusive apontando a responsabilidade advinda de tal confiança. A partir destas definições, neste trabalho, define-se confiança no contexto de segurança como sendo: Confiança: (S.) Veracidade, autenticidade, credibilidade de informações ou procedimentos advindos de outra entidade. Nesta definição pretende-se deixar claro que a confiança que uma entidade tem em outra representa o quanto ela "acredita", "tem fé" nas informações e/ou procedimentos que a outra entidade lhe manda. Desta forma, confiar está intimamente ligado a acreditar. 2.2 Relações de Confiança A definição de confiança nos permite estabelecer as relações de confiança, onde pretende-se expressar confiança que uma entidade tem em outra. Tipicamente o que vemos está apresentado na Figura 1, onde temos duas entidades (A e B) e as relações de confiança entre elas são dadas pelas respostas às perguntas: "A confia em B?" e "B confia em A?". Este tipo de relação é o mais comum onde temos a confiança expressa como sendo um valor binário (sim ou não). A A confia em B? Figura 1 - Relações de Confiança entre A e B Uma das propostas básicas deste projeto está em ampliar este tipo de relação de forma a permitir que relações de confiança possam assumir qualquer domínio de valores, que não apenas os binários, desta feita temos relações como mostradas na Figura 2. A B B confia em A? B É relevante salientar que as entidades são vistas como sendo autônomas e que suas relações de confiança são de sua inteira responsabilidade. 2.3 Aplicações Relações de confiança estão comumente presentes em diversos contextos computacionais, como por exemplo: Relações Cliente/Servidor: Cliente fazendo consulta a servidor DNS Host (cliente) autenticando usuário (em servidor) NIS Cliente montando filesystem em servidor NFS Browser (cliente) abrindo página (de servidor) web Relações Planares: Troca de chaves públicas entre hosts/usuários Mecanismos de autenticação de pacotes, etc. Em todos estes exemplos existem relações em que necessariamente componentes do sistema (não necessariamente todao) necessitam confiar em outras. 3. TEIAS DE CONFIANÇA Partindo da definição de confiança e das relações que definimos na Seção 2, neste pretendemos contextualizar estas definições dentro de um paradigma maior de confiança, onde as relações não só estão presentes aos pares (ponto-a-ponto) como também podem ser vistas como parte de um grafo que contém todas as componentes do sistema. 3.1 Modelo Ponto-a-Ponto A visão mais convencional de confiança leva justamente a um modelo ponto-a-ponto, onde estabelece-se uma relação de confiança entre duas entidades independentes. No contexto deste trabalho, esta relação tem um peso associado, que pode simbolicamente representar "o quanto" uma entidade "confia" na outra (Figura 3). Quanto A confia em B? Quanto B confia em A? Figura 2 - Novas Relações de Confiança entre A e B O objetivo em introduzir tal modificação está em permitir, ao nosso modelo de confiança, tanto satisfazer os paradigmas atuais quanto ser aplicável ao modelo de Teias de Confiança que apresentamos na Seção 3. 0,8 A B 0,6 Figura 3 - Modelo de Confiança Ponto-a-Ponto

129 Tem-se a seguinte notação: T AB = "o quanto A confia em B" = 0,8 T BA = "o quanto B confia em A" = 0,6 É pertinente enfatizar que se pode adotar qualquer representação para os diferentes valores de confiança, e que neste exemplo, T entre 0 e 1. Tal abordagem poderia representar os valores percentuais de quanto uma entidade confia na outra. Uma maior discussão sobre qual a representação ideal a ser adotada e os parâmetros para sua definição serão foco de subsequentes estudos ao longo do desenvolvimento deste trabalho. Neste ponto, nosso objetivo é lançar os fundamentos que guiarão tal empreitada. 3.2 Grafo de Confiança Tendo como base o modelo ponto-a-ponto, surge a extensão natural onde tem-se um grafo orientado G=(V,E) que representa as diversas relações de confiança entre os diversos elementos do grafo (Figura 4). A T AB T BA T BC C T CB B T CD T DC T EB Figura 4 - Grafo de Confiança T BE Neste modelo os vértices representam as diversas entidades e as arestas expressam as relações de confiança, sendo seus pesos os níveis de confiança associados. É natural observar que neste grafo são possíveis laços ou mesmo sub-grafos desconexos, uma vez que as relações de confiança entre as entidades tanto podem induzir relações circulares (A confia em B, que confia em C, que confia em A), quanto pode haver o caso onde não existe nenhuma relação de confiança entre subconjuntos de vértices do grafo. Neste grafo, em relação a um dado vértice, definimos duas regiões de vizinhança: D E far WeST: que representa os vértices alcançáveis através de um caminho qualquer. Como exemplo, se tomarmos como referencial o vértice B, seu near WeST é o conjunto de vértices {A,C,E} e seu far WeST é conjunto unitário {D}. 3.3 Caminhos de Confiança Quando nos referimos a um vértice V qualquer, para cada vértice U de seu near WeST, por definição, existe um único caminho dado pela aresta que liga V a U. Porém para o caso de um vértice X pertencente ao conjunto far WeST podem existir diversos caminhos que liguem V a X. Estes caminhos denominamos de caminhos de confiança. Ao nos utilizarmos do conceito de caminhos de confiança podemos inferir relações de confiança entre duas entidades que não estejam diretamente relacionadas. Isto pode vir a ser algo necessário quando estamos lidando com sistemas contendo um grande número de componentes, como é o caso da Internet. Ao falarmos de caminhos de confiança num grafo de confiança dois questionamentos surgem: Dentre os diversos caminhos que ligam um vértice V a outro vértice U, pertencente ao far WeST de V, qual escolher e porque? Uma vez que estamos inferindo a confiança entre um vértice V e um outro vértice U pertencente ao seu far WeST, tendo escolhido o caminho que os liga, qual o valor resultante da confiança entre os dois? Neste ponto do desenvolvimento deste trabalho ainda não temos as respostas para tais perguntas mas vemos duas frentes de estudo desta direção: os algoritmos para escolha de caminhos de confiança e o algoritmo para cálculo da confiança resultante ao longo de um caminho. 3.4 Teias de Confiança Uma vez que cada vértice do grafo, ou seja, cada entidade do sistema, tem autonomia suficiente para responder por seus relacionamentos de confiança e escolher dentre os diversos possíveis caminhos de confiança qual aquele que mais lhe convém, a partir de um mesmo grafo contendo todos os componentes do sistema temos inúmeras visões diferentes, que correspondem à visão que cada componente tem do mesmo grafo. O conjunto de todas estas visões denominamos de Teias de Confiança (WeST). near WeST: que representa os vértices diretamente ligados, ou seja, com os quais existem arestas ligando;

130 4. ARQUITETURA WEST A partir da teoria desenvolvida para o modelo de Teias de Confiança é nosso objetivo o desenvolvimento de uma arquitetura que dê suporte ao desenvolvimento e utilização de aplicações que façam uso deste paradigma. Esta arquitetura é apresentada nesta seção. 4.1 Modelo em Camadas As aplicações que em alguma instância fazem uso de conceitos de confiança (PGP, PolicyMaker, KeyNotes e outros) trazem dentro de si (do espaço da aplicação) a infra-estrutura necessária ao desempenho de suas funções. O que vemos é uma arquitetura onde tem-se presente a aplicação e o sistema sobre o qual ela roda (Figura 5). Aplicação do Usuário Sistema Operacional existentes e que apenas acrescentam como parâmetro o nível de confiança desejado. Exemplo: w_connect (sockfd, servaddr, servaddrlen, trustlevel) Camada de Confiança Camada que responde pela gerência das informações pertinentes à entidade (suas relações de confiança, parâmetros de configuração, etc.), implementa os algoritmos para determinação de caminhos de confiança e seus respectivos pesos, e assegura e provê os requisitos de confiança especificados pela aplicação. Camada de Comunicação Segura Enquanto que nos trabalhos relacionados ao assunto os aspectos criptográficos estão em primeiro plano, para nós eles fazem parte da camada de comunicação segura e basicamente compõem os mecanismos necessários para assegurar e prover a comunicação entre duas entidades da teia, atendendo os requisitos de confiança especificados pela camada de confiança. Figura 5 - Arquitetura Convencional Nossa proposta está em desenvolver um arquitetura disposta em camadas que se interponha entre a aplicação do usuário e o sistema operacional, provendo de forma transparente à aplicação as facilidades de confiança de que ela necessite (Figura 6). 5. APLICAÇÃO A título de aplicação do modelo, aqui apresentamos (Figura 7) um exemplo que servirá de subsídio para considerações. Este exemplo basicamente é parte da rede interna do LAS. Middleware Aplicação do Usuário Framework Camada de Confiança Camada de Comunicação Segura Sistema Operacional P 0,6 0,1 0,3 S 1,0 Q 1,0 LAS V 0,4 1,0 0,7 1,0 0,3 O 0,3 GIP M 0,9 1,0 F 1,0 R Figura 6 - Arquitetura WeST Figura 7 - Exemplo LAS Camada do Framework Esta camada tem por função prover um framework que forneça as primitivas básicas para o desenvolvimento de aplicações que façam uso do paradigma de confiança WeST. Para facilitar o desenvolvimento de tais aplicações, a princípio, pretendemos disponibilizar primitivas similares às hoje Neste grafo os vértices {P,S,Q,V,O} representam hosts do domínio LAS (representado pelo vértice LAS) e os vértices {F,M,R} representam hosts do subdomínio GIP (vértice GIP). Os pesos nas arestas representam os níveis de confiança (percentuais) que cada vértice tem no outro.

131 Apenas como exemplo de aplicação do modelo, os serviços que um host confia a outro (cliente ou servidor) foram definidos com base nos pesos das arestas, ou seja, com base nas relações de confiança (Tabela 1). T Serviço 0 nenhum > 0 ssh 0,1 cliente DNS, cliente proxy http 0,2 servidor NFS read-only 0,3 servidor NFS read-write (com auth) 0,4 yppasswd 0,6 relay SMTP 0,7 DNS stub 0,9 servidor NFS suid 1,0 confiança total Tabela 1 - Associação entre Níveis de Confiança e Serviços Se a escolha do caminho de confiança basear-se no caminho de maior peso resultante, e se adotarmos que o algoritmo para determinação do peso resultante de um caminho estipula ser valor como sendo o produtório dos pesos ao longo do caminho, temos a seguinte matriz de adjacência: P Q,LAS S V O M,GIP F R P 1,0 0,6 0,18 0,24 0,18 0,42 0,12 0,38 Q,LAS 0,1 1,0 0,3 0,4 0,3 0,7 0,21 0,63 S 0,1 1,0 1,0 0,4 0,3 0,7 0,21 0,63 V 0,1 1,0 0,3 1,0 0,3 0,7 0,21 0,63 O 0,1 1,0 0,3 0,4 1,0 0,7 0,21 0,63 M,GIP 0,1 1,0 0,3 0,4 0,3 1,0 0,3 0,9 F 0,1 1,0 0,3 0,4 0,3 1,0 1,0 0,9 R 0,1 1,0 0,3 0,4 0,3 1,0 0,3 1,0 Tabela 2 - Matriz de Adjacência WeST para a Rede LAS Por esta matriz podemos fazer algumas observações: todas as maquinas da rede LAS e GIP podem fazer uso do serviço de proxy oferecido pelo host P; apenas os hosts {S,V,O,M,R} podem acessar em modo read-write, mediante autenticação, o serviço de NFS do host Q; o host P pode ser relay de SMTP apenas para o host Q, e este pode ser relay apenas para o host M; fica clara a existência de uma relação hierárquica entre os hosts {S,V,O,M} e o host {Q}. Escolhemos este exemplo para ilustrar que as relações de confiança podem ser utilizadas em associação com os serviços oferecidos entre as componentes do sistema, porém tal exemplo sucinta os seguintes questionamentos: Como determinar os pesos de cada aresta, ou seja, quais parâmetros devem ser levados em consideração para a escolha da relação de confiança presente entre as entidade do grafo? Como relacionar os serviços e os níveis de confiança necessários para o desempenho destes serviços? Uma vez que este grafo pode ser por demais extenso, como que uma entidade autônoma pode por si mesma determinar a relação de confiança que tem com outra de seu conjunto far WeST, sem para tanto deter o conhecimento de todo o grafo? Mais uma vez lembramos que nesta fase do trabalho estes e outros inúmeros questionamentos perfazem os subsídios para o desenvolvimento de toda a pesquisa. 6. CONCLUSÃO Uma vez que o modelo WeST representa um novo paradigma para o conceito de confiança dentro do espectro de segurança, tanto encontramos vantagens no mesmo como desvantagens, a saber: Vantagens O conceito mais amplo de confiança permite englobar a atual definição e estendê-la de forma a inferir relações de confiança entre entidades não diretamente relacionadas. Através deste modelo pode ser possível formalizar e determinar os requisitos de confiança necessários às diversas aplicações e serviços. Toda a complexidade de implementação do conceito fica completamente transparente à aplicação do usuário, sendo de responsabilidade do middleware WeST. A elaboração de um Framework contendo primitivas de comunicação similares às existentes facilita o porte e desenvolvimento de aplicações. O modelo tanto pode se comportar de forma hierárquica quanto planar. Os pesos das arestas, ou seja, as relações de confiança, podem ser dinâmicas, mudando de acordo com a contingência. O modelo é flexível, permitindo novas definições de pesos e requisitos.

132 O modelo é extensível, permitindo que diferentes algoritmos para determinação de caminhos sejam usados (peso mínimo, comprimento mínimo, custo mínimo, etc.) Desvantagens "Confiança é um conceito normalmente binário e/ou subjetivo, o que em muito dificulta a sua formalização como um conceito de valores contínuos. A quase inexistência de modelos similares torna por demais extenso este trabalho. A complexidade do modelo implica numa maior dificuldade de implementação. Não pretendemos propor um modelo de confiança, onde a mesma possa ser assegurada e garantida automaticamente e independentemente de qualquer intervenção humana. É nosso pensamento que, numa primeira instância, as entidades que participam do sistema sejam autônomas e que exista "alguém" que responda (se responsabilize) pelos relações de confiança pertinentes à entidade. Neste sentido, é possível que existam falhas de segurança na entidade e que estas se propaguem por outras entidades da rede. Porém, como todos sabemos o mesmo problema é hoje visto em todos os sistemas computacionais que de alguma forma dependam uns dos outros, e não sabemos até que ponto existe solução para este impasse. É claro para nós que uma vez que os sistemas computacionais continuamente tornam-se mais complexos, com inúmeros componentes interrelacionados e interdependentes, a busca pela segurança total onde todos os membros do sistema tenham confiança máxima entre si, até certo ponto, é como a busca pela "pedra filosofal", um árduo caminho que ninguém pode afirmar que terá um resultado final satisfatório e que portanto não será trilhado por este trabalho. 7. REFERÊNCIAS BIBLIOGRÁFICAS [1] P. Zimmermann, PGP User's Guide, MIT Press, Cambridge, [2] M. Blaze, J. Feigenbaum, J. Lacy. Compliance Checking in the PolicyMaker Trust Management System. Proceedings of 2 nd Financial Crypto Conference. Anguilla LNCS #1465, pp , Springer-Verlag, [3] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust Management. Proceedings of the 17 th IEEE Symposium on Security and Privacy. pp IEEE Computer Society, [4] M. Blaze, J. Feigenbaum, J. Lacy. The Role of Trust Management in Distributed Systems Security. Chapter in Secure Internet Programming: Security Issues for Mobile and Distributed Objects (Vitek and Jensen, eds.). Springer-Verlag, [5] M. Blaze, J. Feigenbaum, J. Lacy. The KeyNote Trust-Management System Version 2. IETF Network Working Group, RFC 2704, September 1999.

133 UM ESTUDO SOBRE ASPECTOS DA SEGURANÇA EM BANCO DE DADOS Dirson Santos de Campos Universidade de Brasília - UnB Instituto de Ciências Exatas Departamento de Ciências da Computação Campus Universitário Asa Norte Brasília, DF dirson@cic.unb.br Luiz Antônio da Frota Mattos Universidade de Brasília - UnB Instituto de Ciências Exatas Departamento de Ciências da Computação Campus Universitário Asa Norte Brasília, DF frota@cic.unb.br RESUMO Identificar as ameaças e os requisitos básicos da segurança é fundamental para a implementação da segurança aos objetos armazenados em um banco de dados. Estes objetos devem seguir a política de segurança estabelecida pelo cliente. Um banco de dados é considerado seguro se um mecanismo de proteção obriga o mesmo a executar corretamente a política de segurança implantada. Modelos de segurança de banco de dados foram projetados para implementar mecanismos de proteção aos objetos internos do banco a fim de executar corretamente a política de segurança. É necessário verificar como foi implementada a segurança nos diversos banco de dados existentes antes de adotar alguns deles. Este artigo descreve através do estudo do Postgres as características mais importantes a serem consideradas do ponto de vista da segurança para se adotar um banco de dados. ABSTRACT To identify threats and basic requirements of security is very important to implement security to the objects stored in a database. These objects ought to follow the customer's security policy. A database is considered secure if a protection mechanism forces it to execute a correctly policy security. Models of database security were projected to implement protection mechanism to the internal objects of the bank in order to execute a correctly policy security. It is necessary to verify how security was implemented in the several existent databases before adopting one of them. This article describes through the study of the Postgres the most important characteristics to be considered from the security point of view before adopting a database.. 1 INTRODUÇÃO A segurança de um banco de dados (BD) é baseada em modelos e métodos que procuram garantir a proteção dos dados contra a divulgação, alteração ou destruição não autorizada. Em síntese é garantir que um usuário tenha, de fato, autorização para executar a operação que estiver tentando executar. Podemos portanto questionar os fatores que deverão ser analisados para obter esta segurança. O primeiro passo é identificar as ameaças e requisitos da segurança do BD para poder aplicar uma política de segurança correta. Existe uma dificuldade de identificação precisa destes itens, os quais serão identificados neste artigo. Na busca de uma solução segura é necessário utilizar mecanismos de proteção que permitam o banco executar corretamente a política de segurança exigida pela empresa ou instituição a qual ele pertence. Sendo assim, para proporcionar uma solução segura ideal ao cliente, o administrador do banco de dados Database Administration (DBA) deverá analisar a segurança em sua plenitude abordando aspectos físicos e lógicos. Política de segurança, seus mecanismos e as características da segurança exigida pelo cliente são os três principais itens de uma solução segura (Jajodia, 1998). A política de segurança define as exigências de segurança conforme afirma Jajodia (Jajodia, 1998), ou seja, como e o quê será implementado via hardware, software e os controles externos à área de computação necessários para garantir a segurança do sistema. Geralmente as definições da política de segurança são voltadas às grandes metas de segurança da empresa conseqüentemente, não inclui todos os detalhes necessários a implementação da segurança no BD. Mecanismos de segurança esclarecem as funções intencionais da política de segurança que atendem suas exigências. Esses mecanismos transformam-se em elementos internos do modelo de segurança do banco de dados (Castano, 1995). Alguns destes mecanismos são referentes à integridade dos dados e obedecem os princípios fundamentais da integridade. Este artigo define quais os elementos internos do modelo de segurança e quais são os princípios fundamentais da integridade do BD. É importante verificar o que foi efetivamente implementado no sistema gerenciador do banco de dados (SGBD). Detalhamos aqui as principais características do Postgres, BD objeto-relacional aberto, inicialmente desenvolvido pela

134 Universidade de Berkeley, CA EUA até a versão 4.2. Atualmente, ele é mantido por uma comunidade que possui milhares de desenvolvedores por todo o mundo com uma estrutura similar a da comunidade Linux, onde um grupo de seis membros senior decidem sobre mudanças no kernel do BD. A comunidade mantém um sítio oficial (www. postgresql.org) e resolveu modificar o nome oficial do Postgres para Postgresql. A versão testada neste artigo foi a disponível na distribuição Debian GNU/Linux na plataforma Linux (versão ). As duas principais contribuições deste artigo são a de organizar e evidenciar os requisitos necessários à construção de uma política consistente inerente a um BD e apresentar uma análise sistemática da segurança do SGBD Postgresql com ênfase no controle de acesso e na integridade. O artigo foi dividido em seções que discutem aspectos relevantes sobre o que foi exposto acima. A seção 2 aborda as ameaças a segurança do banco de dados. A seção 3 os requisitos de proteção do banco de dados. A seção 4 aspectos sobre a política de segurança. A seção 5 sobre a integridade do banco. A seção 6 sobre os elementos do modelo de segurança interno do banco de dados. Na seção 7 é feita uma análise sobre a segurança no SGBD Postgres, enfocando as características principais do ponto de vista da segurança, e na seção 8 apresentamos uma conclusão. 2 AMEAÇA A SEGURANÇA EM BANCO DE DADOS A ameaça pode ser identificada com um agente hostil qualquer que acidentalmente ou intensionalmente ganhe acesso não autorizado a recursos do banco de dados (Castano, 1995). Ameaças para a segurança do banco de dados podem ser física ou lógica ( Dastjerdi, 1996). As ameaças físicas são : forçar a revelação da senha (password), roubo, destruição física do servidor, escuta passiva utilizando o cabeamento. As ameaças lógicas, via software, podem fornecer acessos não autorizados a informações podendo resultar na revelação de informação confidencial, modificação ilegal de dados, ou destruição dos recursos do banco de dados. Particularmente, fatores externos ao BD, tais como, o sistema operacional (SO), software de rede (local, departamental ou global) e protocolos de comunicações necessitam de cuidados especiais. As ameaças lógicas podem ser classificadas como (Clack, 1987) : - Revelação da informação caracterizada por toda e qualquer leitura de dados através de acesso direto ou indireto (por inferência estatística da informação) de agentes hostis e usuários legais (acidentalmente ou intencionalmente), visando obter privilégios de leitura espúrios. - Modificação ilegal dos dados causada por manipulação de dados imprópria ou modificação intencional por um usuário legítimo (conhecido também como ataques de integridade de dados). - Negação de serviço Denial of Service causada pela monopolização de recursos do sistema em que o acesso a outros usuários seja impedido ou dificultado (conhecido também como ataques de disponibilidade). As ameaças a segurança também podem ser classificadas de acordo com a maneira que ocorrem: intencionais ou acidentais (Hinke, 1988). Ameaças acidentais incluem : - Desastres naturais como terremotos, inundação, incêndio; - Erros ou bugs no hardware ou no software; - Erros humanos. Ameaças intencionais incluem : - Abuso de privilégios e autoridade por parte de usuários legítimos; - Agentes hostis que executam programas ocultos sem função legítima na segurança do sistema, tais como, cavalos de troia, vírus e trapdoors. Um cavalo de troia é um programa oculto que abaixo de uma função legítima coleciona informações que serão usadas mais tarde para quebrar o sistema. Os vírus possuem a capacidade de se duplicarem e permanentemente danificam o meio onde são reproduzidos. Trapdoor são segmentos do código que ficam residentes na memória do computador que permitem seus donos burlarem os mecanismos de proteção que dão acesso aos dados e recursos do sistema. Ele consegue capturar na memória, por exemplo, o trecho do código onde está armazenado a senha (password). A segurança em todos estes aspectos descrito acima garantem a segurança do BD como um todo. A debilidade de fatores externos ao BD permitem fragilizar fortes medidas de segurança interna ao BD. 3 REQUISITOS DE PROTEÇÃO DE UM BANCO DE DADOS A proteção de um BD das possíveis ameaças representa a proteção de seus recursos, particularmente os dados armazenados, de leituras ou atualização não autorizadas de forma acidental ou intencional (Dastjerdi, 1996). Os requisitos básicos de proteção são :

135 - Proteção a acesso não autorizado; - Proteção contra inferência; - Proteção à integridade; - Responsabilidade e auditoria; - Autenticação do usuário; - Gerenciamento de dados sensíveis; - Proteção em multiníveis; - Detenção. 3.1 Proteção a Acesso não Autorizado Consiste basicamente em conceder acesso ao BD somente a usuários autorizados. Chamadas de acesso devem ser checadas pelo SGBD. Os controles de acesso a BD são mais complexos de que os utilizados para SO. Controles em BD precisam ser aplicados a objetos de uma granularidade mais fina como registros, atributos e valores. Adicionalmente, dados em um banco de dados são semanticamente relacionados, permitindo portanto que um usuário venha a conhecer um valor de um item de dados sem acessá-lo diretamente, mas inferindo através dos valores conhecidos. 3.2 Proteção contra Inferência Consiste basicamente em impedir a obtenção de informação confidencial a partir de dados não confidenciais. Problemas de inferência afetam BD estatísticos onde DBA devem estar atento contra rastreamento da informação através da utilização de ferramentas estatísticas como medidas de dispersão, assimétria e curtose, análise da variância entre outras. 3.3 Proteção à Integridade Requisito de integridade engloba proteção do BD contra acesso não autorizado que possa modificar o conteúdo dos dados, tais como, erros, vírus, sabotagens ou falhas no sistema que possa danificar os dados armazenados. Este tipo de proteção é parcialmente carregada de controles de sistemas apropriados de vários procedimentos de recuperação e cópia e parcialmente de procedimentos de segurança ad-hoc. A integridade é vital ao BD e merece um análise mais profunda abordada na seção 5 deste artigo. 3.4 Responsabilidade e Auditoria O objetivo básico da auditoria e responsabilidade é permitir o armazenamento de toda e quaisquer requisições de acesso a objetos do BD, tanto para operações de leitura quanto para operações de escrita por um determinado período de tempo que deverá ser formalmente descrito na política de segurança. Auditoria e responsabilidade são ferramentas úteis para a integridade física dos dados, assim como para análise posterior de uma seqüência de acessos ao banco de dados. 3.5 Autenticação do Usuário A identificação única dos usuários do BD é o principal objetivo da autenticação do usuário. Identificação de usuários é a função básica de todo mecanismo de autorização. O acesso é autorizado ao usuário quando identificado pelo SGBD Gerenciamento de Dados Sensíveis Dados sensíveis e/ou classificados por motivo estratégicos da empresa não podem ser públicos. Geralmente os BD que contém dados sensíveis e públicos exibem uma maior complexidade de proteção. Controle de acesso a esses dados consistem primariamente em proteger a confidencialidade dos dados sensíveis, permitindo acesso apenas a usuários autorizados. Estes usuários têm permissão para um conjunto de operações dos dados e estão conscientes das conseqüências da propagação de quaisquer informações a terceiros. Os dados públicos podem ser disponibilizados, geralmente pela internet e tratam-se de informações institucionais ou mercadológicas, porém quando são gerados através de informações oriundas do BD são necessárias auditorias periódicas para detectar quaisquer tentativa de acesso indevido ao BD através de servidores de hipertexto da empresa. Lembre-se que um possível invasor procurar pontos onde a segurança é menos rígida, websites, infelizmente podem representar um deles. Problemas podem emergir quando usuários autorizados puderem acessar um determinado conjunto de dados sensíveis separadamente, apesar de não poderem acessar todos os dados concorrentemente. 3.7 Proteção em Multiníveis O objetivo é permitir a classificação da informação em vários níveis de proteção. Proteção em multiníveis Multilevel Secure (MLS) é um modelo que permite capturar as exigências de segurança de informações classificadas de forma hierárquica ou departamental em organizações do tipo militares, governamentais ou comerciais (Qian, 1997). Este modelo é utilizado para implementar gerenciamento de dados sensíveis e/ou classificados. Níveis ou classes de segurança são compostas de dois componentes: um hierárquico e outro não hierárquico, por este motivo a proteção multinível possui dois tipos de

136 políticas de segurança de controle de acesso, mandatória e discricionária. Detalhes dessas políticas serão discutidas na seção Detenção O objetivo da detenção é evitar a transferência de informação não desejada entre programas ou sistemas, como por exemplo, evitar a transferência de dados para programas não autorizados através de uma sessão de comunicação aberta entre uma estação cliente e o servidor. A transferência de informações ocorrem através de: - Canais autorizados; - Canais de memória e - Canais ocultos. Um canal autorizado permite a saída de informações através de ações expressamente autorizadas, exemplo, consulta servidor-cliente através de um protocolo criptográfico. Canais de memória são áreas da memória RAM onde os dados armazenados não são acessados por outros aplicativos devido ao gerenciamento de memória do sistema operacional. Um canal oculto é um canal de comunicação entre processos de um sistema. Por exemplo, um programa que varie sua taxa de paginação, quando processa alguns dados críticos, pode transferir informação a um outro programa que pode rastrear os dados críticos examinando aquela variação. A abordagem do canal oculto é voltada a detenção de intrusos externos ao SGBD. 4 POLÍTICAS DE SEGURANÇA Estudos dos requisitos de segurança foram desenvolvidos por diversos pequisadores com um objetivo de eliminar as ameaças lógicas (Pfleeger, 1997). É necessário definir uma política própria de segurança para o BD, relembrando que um BD é considerado seguro se, e somente se, um mecanismo de proteção obriga o BD a executar corretamente a política de segurança. Note que podem ter muitos mecanismos que realizem a mesma política de segurança. A política de segurança deve ter características apropriadas à segurança do BD. Essas características devem ser suportadas por mecanismos de segurança. A lista abaixo fornece as caraterísticas da política de segurança para BD (Castano, 1995): - Política de controle de acesso; - Política de inferência; - Política de identificação e autenticação do usuário; - Política de auditoria; - Política de consistência. 4.1 Política de Controle de Acesso A Política de Controle de Acesso garante que todos os direitos de acesso a objetos do SGBD são concedidos de acordo com os privilégios e as regras de acesso. Ela pode ser dividida do ponto de vista do banco de dados em: - Política discricionária (arbitrária) - Política mandatária (obrigatória) e - Política de controle de acesso baseado em regras. A política de Controle de Acesso Discricionário - DAC Discretionary Access Control especifica os privilégios dos usuários para os diferentes recursos do sistema, incluindo a capacidade de transferir privilégios para outros usuários (Sandhu, 1998). Ela é baseada em : - Identificação e autenticação; - Segurança por visões; - Concessão e revogação de privilégios; - Modificação de consulta. A política de Controle de Acesso Mandatório ou obrigatório - MAC Mandatory Access Control são controles onde o acesso de um sujeito a um objeto é feito baseado em regras e axiomas derivados da política de segurança da empresa (Osborn, 1997). A política MAC tem as seguintes propriedades básicas : - Atribuir níveis de segurança para todos os objetos do banco de dados. - Atribuir uma liberação de segurança para cada usuário do banco. - O banco de dados deve garantir que todos os usuários só possuam acesso aos dados para os quais eles têm autorização. Descrições dos modelos DAC e MAC podem ser encontradas em Campos (Campos, 2000) e Castano (Castano, 1995). A política de controle de acesso baseado em regras - RBAC Role-Based Access Control Models surgiu da necessidade de empresas comerciais protegerem informação com características confidenciais. Cada organização tem requisitos de segurança únicos, muitos dos quais são difíceis de serem reconhecidos usando controle de acessos tradicional como MAC e DAC (Didriksen, 1997). Em muitas empresas, os usuários finais não são donos dos objetos dos sistemas dos quais tem acesso. Nestas empresas, a corporação é a "atual" dona dos objetos dos sistemas assim como dos programas e dos processos. Recentes pesquisas indicam que a política RBAC é mais flexível e tem baixo custo de administração devido a simplificação do gerenciamento de permissões descentralizado

137 (Sandhu, 1998a). 4.2 Política de Inferência A política de inferência especifica como proteger a informação classificada da sua revelação de forma indireta através de ferramentas como a manipulação estatística. Mecanismos de inferência podem ser utilizados para extrair informações do SGBD, violando possíveis regras da políticas MAC e RBAC. Isto pode ocorrer devido ao poder expressivo da linguagem declarativa de consulta ao banco de dados Política de identificação e Autenticação do usuário A política de identificação e autenticação do usuário indica os requisitos para uma correta identificação do usuário. A identificação do usuário é uma função básica para qualquer mecanismo de segurança. Em algumas bases de dados críticas pode-se utilizar outros mecanismos que extrapolam o controle de acesso tradicional, por exemplo, autenticação biométrica (mapeamento da retina), onde o armazenamento dos dados da retina ficam armazenados no próprio BD, havendo regras e axiomas específicos que não permitem a substituição dos dados gravados da retina do usuário pelos dados da retina de um intruso Política de Auditoria Diversas pesquisas mostram que realmente não existe sistema 100% seguro e dessa forma tal afirmação não pode ser considerado uma falácia! Por essa razão é necessário estipular uma política de auditoria no BD onde são definidos todos os requisitos para a manutenção dos registros aos acessos no banco de dados. Não é possível armazenar todos os acessos durante todo o tempo, pois os arquivos de log do banco cresceriam de tal forma que seria inviável na prática armazená-los. Questões como por quanto tempo devem ser armazenados informações de acesso ao BD e quais os tipos de acesso devem ser armazenados devem ser respondidas prontamente por essa política. A política de auditoria é também uma ferramenta útil para a integridade física dos dados assim como para análise do perfil do acesso dos usuários Política de Consistência A política de consistência define os estados nos quais uma transação de dados é considerada válida ou correta e inclui aspectos da integridade operacional, integridade semântica e integridade física do banco de dados, discutidas na seção 5 deste artigo. A maioria do esforço de pesquisa na segurança de BD é dedicada a política de controle de acesso e a política de inferência ( Dastjerdi, 1996). 5 INTEGRIDADE Um aspecto relevante à proteção de objetos internos de um BD é a sua integridade. Integridade no contexto do banco de dados significa precisão, correção e validade. O objetivo é preservar o banco contra atualizações não válidas que são normalmente causadas por erros na entrada de dados do operador, do programador, da aplicação, por falha do sistema e a falsificação deliberada (Date, 1998). A integridade passa pelos seguintes princípios básicos (Sandhu, 1995) : - Transações bem formadas, pressupõem consistência de dados, abstração de dados em relação ao meio físico e atomicidade transacional; - Continuidade da operação de manipulação de dados, se a transação for interrompida (ex. queda do link cliente-servidor) o sistema deve ser capaz de continuar a transação do ponto que parou ou de acordo com as regras de segurança simplesmente cancelar a mesma desde seu início; - Delegação de autoridade via controle de acesso do banco de dados; - Autenticação de usuários; - Realização de checks-points, ponto de checagem temporais ou atemporais das transações entre dados ; - Integração com as ferramentas de segurança do banco de dados. A integridade é parte integrante do kernel do SGBD. Normalmente a integridade pode ser dividida em integridade do sistema, operacional, semântica e física (Silberschatz, 1997). A integridade do sistema é definida como a habilidade do sistema em operar de acordo com as especificações, independentemente de quaisquer tentativas delibaradas ou não de fazê-lo agir diferentemente. A integridade operacional assegura a consistência de dados durante as transações correntes. A integridade semântica é a parte da integridade dos dados interessada na exatidão das informações do banco de dados na presença de modificações do usuário. A integridade física do BD assegura sua imunidade física depois de falhas na energia, reconstruindo fisicamente a tabela.

138 Segurança e integridade são conceitos fundamentais em banco de dados, porém pode ocorrer violações da segurança onde a integridade não é violada e vice-versa. Shankar (Shankar, 1977) e Fernandez (Fernandez, 1981) propuseram a relação entre segurança e integridade (figura 1) mais aceita na comunidade acadêmica. Os sujeitos são os agentes ativos do sistema computacional, que poderão requerer acesso a objetos. Os agentes ativos representam ameaças potenciais aos objetos internos do banco de dados analisado. Os objetos são agentes passivos. Eles contêm informações a serem protegidas. Usuário Modificação da informação Segurança Violada Modificação não autorizada Segurança não Violada Modificação autorizada Modificação não é possível Correto (usualmente não existe) Inadivertidamente Incorreto Maliciosamente Incorreto Correto Integridade Violada Integridade não Violada Figura 1 Relação entre segurança e integridade Analisando a figura 1 pode-se perceber que existem casos que a segurança não é violada e a integridade é violada e vice-versa. Há casos onde ambas são violadas. 6 ELEMENTOS DO MODELO DE SEGURANÇA INTERNO DO BD A segurança de um banco de dados é baseada em modelos e métodos que procuram garantir que os dados sejam protegidos. Estes modelos são parte integrantes do sistema gerenciador de banco de dados (SGBD). Para executar esta tarefa o SGBD necessita de controlar os elementos de um modelo de segurança apropriado ao BD. Este modelo interno tem os seguintes componentes : - Sujeitos; - Direitos; - Modos de Acesso; - Políticas; - Autorizações; - Direitos Administrativos e - Axiomas. O relacionamento entre estes componentes foi descrito por Castano (Castano, 1995) e na figura 2. Os modos de acesso são os tipos de acesso que sujeitos podem exercer em um determinado objeto. Esse acesso sujeito-objeto gera um fluxo de informação. Uma violação no fluxo de informação ocorre através de uma chamada de transferência de dados entre dois objetos, para os quais, baseado em fluxo admitido, aquela transferência não é autorizada. Mecanismos de controle devem negar a execução dessas chamadas. As políticas são regras para o estabelecimento de controle de acesso. As autorizações são os conjuntos de acessos que o sujeito pode exercer individualmente ou através de um grupo em um determinado objeto. Os direitos administrativos são os privilégios para modificação de autorizações de acesso a um determinado objeto ou grupos de objetos. Os axiomas são as propriedades da transição de estados embutidas no sistema. Na implementação de um modelo de segurança em um SGBD todos estes elementos deverão ser contemplados no projeto de segurança do banco de dados. Alguns desses fatores são mais difíceis de modelar, especificar e verificar do que outros, tais como, modos de acesso, políticas e autorizações.

139 Modos de acesso 8VXiULRV 6XMHLWRV $GPLQLVWUDGRU GH 6HJXUDQoD Direitos Administrativos Requisições sobre operações administrativas Processos Controle de Acesso 6ROLFLWDomR GH $FHVVR $FHVVR $XWRUL]DGR Controle sobre operações administrativas $FHVVR 1HJDGR $FHVVR $XWRUL]DGR Autorizações 2EMHWRV Axiomas e Políticas Figura 2 Elemento do modelo de segurança interno do banco de dados 7 SEGURANÇA NO SGBD POSTGRES Nesta seção analisaremos as características de segurança do SGBD Postgres com ênfase no controle de acesso e integridade. O seu design atual nos permite modelar os elementos de segurança interna proposto por Castano (Castano, 1995) o que nos garante suporte a implementação de uma política DAC suportada totalmente por comandos sql. No Postgres o DAC possui mecanismos para permitir aos usuários limitar o acesso de outros usuários aos seus dados. Este controle permitem privilégios de acesso de leitura, escrita e execução de regras com os comandos grant/revoke. A remoção da e/ou modificação de estruturas são possíveis através do comando SQL alter, drop table, e drop index (Lockhart, 2000). A política DAC é o controle de acesso básico do Postgres que permite aos diversos usuários acessarem os diversos objetos do BD. Cada BD contém um arquivo nomeado pg_hba.conf (disponível no diretório de pg-data) que controle quem podem conectar cada banco de dados. Todo cliente que tem acesso a um banco de dados deve ser coberto por uma das entradas em pg_hba.conf. A política MAC não é suportada diretamente por comandos Sql (ANSI SQL standard ou sql92), entretanto é possível reproduzi-la no Postgres, desde que o DBA realmente conheça a política MAC e as restrições e ferramentas adminstrativas constante no manual do adminstrador do Postgres (Lockhart, 2000). A política MAC no Postgres pode ser conseguida através de um controle restrito sobre quem pode definir funções e regras de segurança. São recomendados uma auditoria sistemática nos arquivos pg_class, pg_user, pg_proc, pg_group, pg_trigger e pg_rewrite para veficar quais usuários podem efetivamente criar tais funções e regras. A política RBAC, principalmente as propostas por pesquisas mais recentes, como a política RBAC de Sandhu (Sandhu, 1998a) ainda não foi implementada no Postgres isto devido a dificuldade na descentralização de permissões. No Postgres os privilégios de sistema e objetos internos ao BD estão distribuídos em várias tabelas (pg_atribute, pg_group, pg_index, pg_trigger, entre outras) o que dificulta a implementação do modelo PRA97 proposto por Sandhu. O Postgres é um banco de dados objetorelacional (BDOR) aberto. Sua primeira implementação (Stonebraker, 1986) e suas atualizações estão proporcionando suporte a novas tecnologias do BD usadas em aplicativos fora do domínio clássico da base de dados puramente relacional. Estes novos aplicativos incluem entre outros: - CAD (Projeto Auxiliado por Computador);

140 - CASE (Engenharia de Software Auxiliada por Computador); - Aplicações multimídia; - OIS (Sistema de Informação de Escritório); - GIS (Sistemas de Informação Geográfica); - Sistema de Hipertexto. Esses novos aplicativos requerem novos modelos de dados, novas linguagens de consultas e novos modelos de transações. Estas extensões do modelo de dados ocasionam novas necessidades no modelo de segurança do BD. O modelo de dados Postgres (Stonebraker, 1987) e suas extensões possuem diversas características da orientação à objeto onde uma classe é mapeada para uma relação, uma instância de um objeto para uma tupla, uma identificação de um objeto para a identificação de uma tupla, um método para um atributo ou funções de atributos. A adequação dos dados aos princípios básicos de integridade (Sandhu, 1995) no Postgres é garantida por mecanismos de : - Protocolos com base em bloqueios (lock) e registro de tempo (timestamp). Eles garantem que o acesso a dados seja feito de maneira mutuamente exclusiva, isto é, enquanto uma transação acessa a um item de dados, nenhuma outra transação pode modificá-los; - Log de transações. Transações de modificações de dados (inserts, deletes e update) são escrita no arquivo de log do BD, esta duplicação permite recuperação de uma transação no caso de uma falha abrupta do sistema; - Controle de transações. Efetiva uma transação concorrente e começa uma nova através do comando commit ou aborta uma transação concorrente através do comando rollback; - Controle de checkpoints. Utilizando-se de caching de transações que força a gravação de uma transação de forma completa da memória RAM para o disco rígido; - Utilização de gatilhos (triggers). Suportado por comandos sql em um único comando ou bloco de comando executado automaticamente em conseqüência de uma modificação de um objeto do BD, geralmente usado para garantir integridade referencial; - Restrições de integridade. Suportado por comandos sql as restrições de domínio e de integridade referencial; - Backup On-line. Permite fazer backup mesmo com usuários acessando o BD sem destruir a integridade dos dados e das transações. A segurança no Postgres é detalhada por Stonebraker (Stonebraker, 1990), Momjian (Momjian, 2000) e Lockhart (Lockhart, 2000). Ao longo do tempo, com o surgimento de novas versões, novas características da segurança foram acrescentadas. A segurança da base de dados no Postgres é implementada em vários níveis, tais como : - Proteção aos objetos do banco de dados; - Proteção a conexões TCP/IP; - Autenticação de usuário; - Controle de acesso baseado em host ; - Controle de acesso discricionário e mandatório. Todos os objetos são protegidos contra acesso de outros usuários, somente a conta do superusuário Postgres tem acesso livre a todos os objetos. Conexões de um cliente via TCP/IP para o servidor de banco de dados são permitidas, porém existe a possibilidade dessas conexões de cliente serem restringidas pelo endereço IP ou pelo nome do usuário através de script no arquivo de pg_hba.conf no diretório pg_data. A autenticação de usuário é feita para todos os usuários do Postgres que estão contidos no arquivo pg_user. Atualmente, a verificação da identidade do usuário é executada em distintas formas : - através do shell do usuário e - através da rede. No shell do usuário, um demon (programa que fica residente na memória) do SGBD captura a identidade original do usuário antes de executar um sessão do usuário Postgres. O id(identidade) original do usuário é usado como a base para validação de todo tipo de controle de acesso. A autenticação via rede ocorre quando o Postgres é instalado como banco distribuído. O administrador deve configurar o arquivo pg_hba.conf que está disponível no diretório pgdata para especificar que sistema de autenticação será também distribuído, por default, o BD é instalado apenas em um servidor. Podem ser feitas conexões de clientes usando a autenticação do sistema operacional (a versão avaliada neste artigo foi na plataforma unix) ou conexões via Internet (TCP/IP). Os métodos de autenticação suportados pelo Postgres são : - Trust (confiança) - a conexão é permitida incondicionalmente; - Reject (rejeição) a conexão é rejeitada incondicionalmente; - Crypt (criptografado) a estação cliente ao se conectar ao banco é pedido uma senha do usuário. A senha é enviada encriptada na sessão aberta pelo protocolo TCP/IP e comparada a senha contida na tabela pg_shadow. Se as senhas são idênticas a conexão é permitida; - password (senha) - a estação cliente abre uma sessão no servidor onde é pedida uma senha que é enviada às claras pela rede, esta senha

141 é comparada com a senha contida na tabela pg_shadow. Se as senhas coincidirem a conexão é permitida.; - Krb4 e krb5 suporte através de conexões TCP/IP da autenticação do usuário utilizando o protocolo Kerberos versão 4 e 5 (Neuman, 1994); - Hostssl suporte ao controle de acesso via Secure Socket Layer (SSL), se habilitado no servidor. O controle de acesso discricionário e mandatório segue a política DAC e MAC descritas no início dessa seção. Não há nenhuma função explícita para suportar encriptação dos dados dentro do Postgres. Não foi implementado o padrão SQL 1999 (SQL 3). 8 CONCLUSÃO Não é possível executar um política de segurança correta sem reconhecer as reais ameaças físicas e lógicas do BD. A identificação precisa das ameaças é o primeiro passo para uma correta política de segurança. O segundo passo é um estudo sistemático dos requisitos de segurança do BD. O DBA precisa estar atento as outros detalhes da proteção de dados tais como, inferência, responsabilidade e auditoria sistemáticas dos arquivos de log, principalmente em tentativas de acesso mal sucedidas e adotar uma política diferenciada de proteção a dados sensíveis. Após identificar as ameaças e os requisitos de segurança específicos do BD é possível implementar uma política de segurança capaz de diminuir e monitorar os riscos de acesso indevido aos objetos do BD. Com os requisitos da política de segurança bem definidos o DBA deverá procurar um SGBD com mecanismos e ferramentas que suporte na plenitude as exigências de segurança definida pelo cliente. Este é o terceiro passo para implementar uma solução segura. É importante salientar que a debilidade da segurança devido a fatores externos ao BD permitem fragilizar fortes medidas de segurança interna ao BD. Um SGBD robusto do ponto de vista da integridade dos dados deve obedecer os seguintes princípios de integridade (Sandhu, 1995) : transações bem formadas, continuidade da operação de manipulação de dados, delegação de autoridade via controle de acesso do banco de dados, autenticação de usuários, realização de checks-points e integração com as ferramentas de segurança do banco de dados. Caso o BD não suporte estes princípios de integridade não poderá ser considerado robusto quanto a sua integridade. Pesquisas demostram que se um BD suporta com exatidão os elementos do modelo de segurança interno do BD ele pode ser considerado robusto do ponto de vista da segurança. Segundo Castano (Castano, 1995) esses elementos são : sujeitos, objetos, modo de acesso, autorizações, direitos, axiomas e políticas. A análise do Postgres nos revelou a adequação aos princípios básicos de integridade que é garantida por mecanismos de : protocolos com base em bloqueios (lock), log de transações, controle de transações, controle de checkpoints, uso de gatilhos (triggers) e restrições de integridade. O Postgres devido as características do seu design atual permite suportar com precisão os elementos do modelo de segurança interno do BD proposto por Castano (Castano, 1995). A análise acima nos permite concluir que o Postgres é considerado robusto quanto a segurança e a integridade. A respeito do suporte às políticas de controle de acesso o estudo mostrou que a o DAC é o controle de acesso básico utilizado pelo Postgres. A política MAC não é suportada diretamente por comandos Sql (ANSI SQL standard ou sql92), entretanto é possível reproduzi-la no Postgres, embora sua reprodução seja trabalhosa, pois exige do DBA conhecimento intermediário da política MAC e das restrições e ferramentas adminstrativas do Postgres. Será necessário a configuração manual de algumas tabelas do sistema, o esforço maior será nas tabelas pg_rewrite e pg_trigger. Modernas políticas de controle baseada em regras como a proposta por Sandhu (Sandhu, 1998a) ainda não foram implementada no Postgres. Outras características positivas do Postgres com relação a segurança são : - Diversos métodos de autenticação suportados tais como trust, reject, crypt, password. - Suporte ao protocolo Kerberos versão 4 e 5 e ao Secure Socket Layer (SSL); - Suporte total ao sql 92; - Documentação de boa qualidade (em inglês); - Suporte a várias plataformas de SO; - Suporte comercial; As restrições sobre a ótica da segurança no Postgres são : - Não existe um algoritmo criptográfico implementado no pacote Postgres que poderia impedir a leitura dos dados no caso de uma invasão por intruso; - Não implementação do novo padrão SQL 1999 (SQL 3) em sua totalidade, não permitindo assim, o uso das novas características inclusas no SQL 3; - Não implementou suporte para as novas políticas RBAC; - Curva de aprendizado inicial baixa com relação a configuração do SGBD, pois existe dezenas tabelas de sistema e arquivos de configuração. A

142 configuração é feita em linha de comando (versão linux); - Suporte comercial inferior ao padrão dos grandes BD comerciais; Trabalho futuro sobre segurança em banco de dados é fazer uso de um método formal capaz de verificar os aspectos da segurança do BD. Um outra sugestão é analisar comparativamente banco de dados com relação a segurança. AGRADECIMENTOS Os autores agradecem as avaliações, críticas e sugestões recebidas por revisores anônimos. E agradecem ainda o apoio da Universidade de Brasília-UnB. O primeiro autor agradece o total apoio recebido pela Universidade Federal de Goiás UFG. REFERÊNCIAS BIBLIOGRÁFICAS CAMPOS, D. S. e Mattos, L.A.F. Modelo de Segurança em Banco de Dados. Relatorio de Pesquisa CIC/UnB, Agosto de CASTANO, S., Fugine, M., Martella, G., Samarati P. Database Security. Addison-Wesley CLACK, D.; Wilson, D. R. A Comparasion of Commercial and Military Computer Security Policies. In Proceeding Computer Society Symposium on Security and Privacy, pg , Oakland, CA., DASTJERDI, A. B., Pieprzyk, J., Naini, R. S. Security in Databases: A Survey Study. University of Wollongong Australia, DATE, C. J. An Introduction to Database System, 7 th edition. Addison-Wesley Publishing Company Inc DIDRIKSEN, Tor. Rule Based Database Access Control - A Practical Approach. ACM. ACM Trans. Database Systems, FERNANDEZ, E. B., Summers R. C., Wood C. Database Security and Integrity. Addison- Wesley HINKE T. H. DBMS technology vs. Threats. In Database Security: Status and Prospects (C.E. Landwehr, ed.) Amsterdam : Elsevier Science (North-Holland), JAJODIA, Sushil. Database security and Privacy, CRC Press, Association for Computing Machinery - ACM LOCKHART, T. PostgreSQL Administrator's Guide. Copyright by PostgreSQL Inc MOMJIAN, B. PostgreSQL: Introduction and Concepts. Addison-Wesley NEUMAN, B. CLIFFORD e T. Kerberos: An Authentication Service For Computer Networks IEEE Communications Magazine, Volume 32, No 9, pag , Set OSBORN, S. L. Mandatory Access Control and Role-Based Access Control Revisited, Proceedings of Second ACM Workshop on Role-Based Access Control, Nov PFLEEGER, C. P. Security in Computing. Second Eddition. Pretice Hall Inc QIAN, X. and Lunt, T. F. A Semantic Framework of the Multilevel Secure Relational Model, IEEE Transactions on Knowledge and Data Engineering, vol. 9, no. 2, pp , March-April SANDHU, R.S. and Jajodia, S. Integrity Mechanisms in Database Management Systems, In Information Security: An Integrated Collection of Essays, M. Abrams, S. Jajodia, H. Podell, eds., IEEE Computer Society, 1995, pages SAN DHU, R. and Qamar M. How to do Discretionary Access Control Using Roles. In Proceedings of 3rd ACM Workshop on Role- Based Access Control, Fairfax, Virginia, October, SANDHU, R. and Bhamidipati V. An Oracle Implementation of the PRA97 Model for Permission-Role Assignment. In Proceedings of 3rd ACM Workshop on Role-Based Access Control, Fairfax, Virginia, October, 1998a. SILBERSCHATZ, A., Korth, H. F., Sudarshan, S. Database System Concepts - 3th edition. McGraw-Hill Companies, Inc SHANKAR, K. S., The total computer security problem: on overview. Computer 10,6 (June 1977), STONEBRAKER, M. & Lawrence A. R. The Design of Postgres. Association for Computing Machinery, ACM STONEBRAKER, M. & Lawrence A. R. The POSTGRES Data Model. Association for Computing Machinery - ACM STONEBRAKER, M. and Lawrence, A. R. The Implementation of Postgres. Association for Computing Machinery - ACM

143 UM MECANISMO PARA DISTRIBUIÇÃO SEGURA DE VÍDEO MPEG Cíntia Borges Margi LARC - Escola Politécnica Universidade de São Paulo São Paulo SP cbmargi@larc.usp.br Graça Bressan LARC Escola Politécnica Universidade de São Paulo São Paulo SP gbressan@larc.usp.br Wilson Vicente Ruggiero LARC Escola Politécnica Universidade de São Paulo São Paulo SP wilson@larc.usp.br RESUMO Este trabalho faz um levantamento dos principais aspectos envolvidos na distribuição segura de material multimídia, principalmente vídeo MPEG, e propõe um mecanismo de distribuição e reprodução de vídeos MPEG que atenda a estes requisitos. Diversos métodos de criptografia para vídeos MPEG são analisados e comparados. A partir dos principais requisitos, um mecanismo para distribuição segura de vídeo MPEG é proposto, inclusive com a especificação do servidor e do visualizador. O artigo também apresenta os resultados iniciais da implementação. ABSTRACT This work intends to list the main aspects in secure multimedia distribution, mainly MPEG video, and proposes a mechanism for distributing and playing MPEG video that meets these requirements. Several MPEG video encryption methods are analyzed and compared. Based on the main requirements, a secure distribution mechanism of video MPEG is proposed, including the server and the player specification. This paper also presents the first implementation results. 1 INTRODUÇÃO Com o aumento da distribuição de material multimídia através da Internet, principalmente com conteúdos valiosos como é o caso do ensino a distância, a discussão dos aspectos de segurança envolvidos torna-se um assunto muito importante. Esta questão fica mais interessante quando se leva em conta a distribuição de material multimídia com acesso controlado em um ambiente de decodificação em tempo real. Utilizar material multimídia na Web significa integrar e disponibilizar vídeos, áudio, textos, imagens e/ou animações. Cada uma destas mídias possui características diferentes tanto na sua codificação, como no modo de distribuição. Os principais aspectos de segurança a serem discutidos na distribuição de material multimídia são controle de acesso, integridade e sigilo. Mas, estas questões estão interligadas, já que o sigilo torna-se relevante quando o acesso ao material é controlado. Os textos, animações, desenhos e simulações podem ser transmitidos com segurança através de SSL (Secure Sockets Layer), utilizando criptografia e certificados digitais. O uso de certificados digitais (Feghhi et al., 1999) garante a autenticidade do servidor, e o uso de criptografia garante a confidencialidade e a integridade das informações. Portanto, esta questão possui uma solução satisfatória. Em se tratando de vídeo, outros aspectos devem ser considerados. Este trabalho propõe-se a analisar os aspectos de segurança envolvidos, levantar os requisitos e especificar um mecanismo seguro para distribuição e reprodução de material multimídia, mais especificamente de vídeo MPEG. Além disso, discute os resultados iniciais da sua implementação. O artigo está organizado da seguinte forma: a seção 2 trata dos aspectos de segurança envolvidos na distribuição de material multimídia, a seção 3 apresenta o padrão de compressão MPEG, enquanto a seção 4 apresenta os mecanismos existentes de criptografia para MPEG. A seção 5 apresenta os requisitos e a especificação do mecanismo proposto, enquanto a seção 6 apresenta os primeiros resultados da implementação, e a seção 7, as conclusões do trabalho. 2 SEGURANÇA NA DISTRIBUIÇÃO DE MATERIAL MULTIMÍDIA Os diferentes aspectos de segurança que caracterizam um sistema de computadores (Stallings, 1998) são: Autenticidade: A verificação da autenticidade é necessária ao processo de identificação, seja de um usuário para um sistema, de um sistema para o usuário ou de um sistema para outro sistema. A troca de certificados digitais e o uso de assinatura digital permite garantir a autenticidade do servidor e do cliente envolvidos na transação. Integridade: Consiste em proteger a informação contra modificação sem a permissão explicita do proprietário daquela informação. A modificação inclui ações como escrita, alteração de conteúdo, alteração de status, remoção, criação e o atraso de informações transmitidas. A integridade pode ser verificada através do hash da mensagem, que produz um resumo de tamanho fixo. Confidencialidade: Consiste em proteger a informação contra leitura ou cópia por alguém que não tenha sido explicitamente autorizado pelo proprietário daquela informação. Este tipo de segurança inclui não apenas a proteção da informação como um todo, mas também de partes da informação que podem ser utilizadas para inferir sobre o todo. O sigilo, ou confidencialidade, é obtido através de criptografia.

144 Controle de Acesso : Consiste na capacidade de se permitir ou negar acesso aos serviços e recursos oferecidos pelo sistema. Acessos desconhecidos ou feitos por pessoas não autorizadas podem significar a necessidade de uma verificação de todos os recursos envolvidos em busca de possíveis estragos que possam ter sido causados ao sistema, mesmo que aparentemente nada tenha ocorrido. O controle de acesso pode ser implementado através de validação de senhas, ou através de identificação por certificados digitais. Os serviços de segurança devem considerar a proteção da informação nas suas mais variadas formas: armazenada em discos, fitas de backup ou impressas. Os aspectos de segurança a serem enfocados neste trabalho envolvem sigilo, controle de acesso e integridade. Assim, as técnicas de segurança necessárias são assinatura digital, criptografia e certificados digitais. 3 O PADRÃO MPEG Um vídeo com qualidade VCR é composto de quadros na freqüência de 30 quadros por segundo. A digitalização produz quadros em uma resolução com 640 x 480 pixels, sendo que 1 segundo de vídeo resulta em 27 MB. Como o volume de dados de vídeo é muito grande, tornam-se necessárias técnicas de compressão. O padrão MPEG-1, criado em 1991, foi desenvolvido para armazenar sinais digitais de áudio e vídeo colorido com qualidade VCR (Vídeo Cassete Record), e ser transmitido a uma taxa de 1,5 Mbps (LeGall, 1991). O padrão MPEG trata a compressão de vídeo e áudio, especificando como estes sinais são associados e sincronizados, sendo definido em três camadas: a camada de sistema, a camada de vídeo e a camada de áudio. A compressão de vídeo consiste em eliminar as informações redundantes (correlatas). Estas correlações podem aparecer de duas formas: correlação espacial e temporal. A correlação espacial é observada em uma mesma imagem, ou seja, são as informações redundantes que aparecem em uma imagem, como a cor de fundo. Para eliminar a correlação espacial utiliza-se a Transformada Discreta de Cosseno (DCT), seguida da quantização dos coeficientes obtidos. Já a correlação temporal é observada em dois quadros consecutivos; por exemplo a primeira cena mostra uma sala com móveis e uma pessoa, enquanto na segunda cena aparece a mesma sala, porém a pessoa mudou de lugar. Para eliminar a correlação temporal, utiliza-se o processo chamado de Compensação de Movimento, que é o emprego da técnica DPCM (Differential Pulse Code Modulation), codificando apenas as diferenças encontradas entre os quadros. Em MPEG-1 o quadro é dividido em blocos 16 x 16 amostras para luminância, e blocos de 8 x 8 amostras para cada sinal de crominância. Um macrobloco é composto por um bloco de luminância (4 x (8 x 8) amostras) e dois blocos de crominância (1x (8 x 8) + 1x (8 x 8) amostras), conforme observa-se na Figura 1. O vetor de movimento indica a translação espacial de um bloco para o outro, sendo utilizado na Compensação de Movimento para eliminar a correlação temporal. 16 amostras Figura 1: Constituição do Macrobloco MPEG As cadeias de vídeo MPEG podem ter três tipos de quadros: quadro I (intra-frame): é um quadro codificado somente com informações da imagem, não dependendo de qualquer quadro passado ou futuro; quadro P (forward predicted frame): este quadro é codificado relativamente ao quadro de referência precedente mais próximo (quadro I ou quadro P); quadro B (bi-directional predicted frame): sua codificação é feita relativa ao quadro de referência precedente mais próximo (quadros I ou P), ou ao quadro de referência sucessivo mais próximo, ou a ambos. Uma seqüência típica de quadros MPEG é apresentada na Figura 2, onde a dependência entre os quadros I, P e B pode ser observada (Mitchel et al.,1996). Note que se um quadro I não é decodificado corretamente, todos os quadros seguintes apresentarão erros, até a decodificação do próximo quadro I. I 16 amostras Luminância 8 amostras Crominância I B B P B B Figura 2: Interdependência de Quadros para uma Seqüência MPEG A camada de vídeo MPEG é dividida em seis camadas (Figura 3): - Camada de Seqüência de Vídeo - Camada de Grupos de Imagens (GOP) - Camada de Imagem - Camada de slice - Camada de Macroblocos - Camada de Blocos

145 Cabeçalho de Seqüência Seqüência de Vídeo GOP GOP... Código de fim de Seqüência Existem diversos mecanismos de criptografia para MPEG, porém cada um deles possui enfoque diferente. Dentre estes mecanismo podem ser citados: Criptografia Simples, Criptografia Seletiva, Algoritmo de Permutação Zig-zag, VEA (Video Encryption Algorithm) e Permutação Pura. Cabeçalho de GOP Cabeçalho de Imagem Cabeçalho de slice Cabeçalho de Macrobloco Imagem (Picture) Figura 3: Estrutura da Camada de Vídeo MPEG Cada uma destas camadas é identificada pelo seu cabeçalho, cujos valores podem ser observados na Tabela 1 (Mitchel et al, 1996). Tabela 1: Códigos de início de vídeos MPEG Nome do Código de Início Valor em Hexadecimal extension_start code B5 group_start_code B8 picture_start_code Reservado B0 Reservado B1 Reservado B6 sequence_end_code B7 sequence_error_code B4 sequence_header_code B3 slice_start_code slice_start_code AF user_data_start_code B2 O cabeçalho de seqüência de vídeo contém os parâmetros de inicialização da decodificação, como altura e largura do quadro, taxa de quadros, taxa de bits e tamanho do buffer. O processo de compressão MPEG segue os seguintes passos: 1. processo de identificação dos quadros; 2. preparação dos blocos de dados; 3. codificação: transformada discreta de coseno (DTC), quantização, supressão de seqüências repetidas (aplicada em zig-zag) e codificação de Huffman. 4 CRIPTOGRAFIA PARA MPEG Imagem (Picture)... slice slice... Macro bloco Macro bloco Bloco Bloco... Código de fim de Macrobloco Criptografia Pura ou Simples No mecanismo de criptografia pura (Naive Encryption), os vídeos MPEG são tratados como dados, ou seja, não são consideradas as características da codificação MPEG. O arquivo MPEG é criptografado utilizando um algoritmo de criptografia convencional, como o DES ou IDEA, e, então, o arquivo MPEG é enviado. Após receber o arquivo MPEG, este é decriptografado e o arquivo obtido pode ser assistido. Observe que o arquivo MPEG estará desprotegido (decriptografado) no disco do usuário. Este mecanismo proporciona um nível de segurança alto, já que a dificuldade em quebrar o algoritmo é aquela apresentada ao tentar quebrar o DES ou o IDEA. Outra característica deste mecanismo é não alterar o tamanho do arquivo após a criptografia. A desvantagem deste algoritmo é ser muito lento (Qiao et al., 1998), e causar aumento no atraso durante a decodificação da cadeia de vídeo (Spannos et al., 1996), tornando inviável utilizá-lo em aplicações de tempo real. 4.2 Criptografia Seletiva A criptografia seletiva procura utilizar as características das cadeias de vídeo MPEG para diminuir a quantidade de informações criptografadas. Os quadros I são aqueles que carregam mais informações, enquanto os quadros P e B representam variações da imagem em quadros I adjacentes. Assim, se os quadros I forem criptografados será difícil compreender o conteúdo de uma cadeia de vídeo. Alguns mecanismos também permitem criptografar os quadros I e P, ou todos os quadros (I, P e B). Porém, quando criptografa-se somente os quadros I e executa-se o arquivo em player MPEG convencional que suporte erros, ainda é possível perceber o conteúdo do vídeo (Agi et al., 1996). Uma solução proposta (Agi et al,. 1996) é aumentar a freqüência dos quadros I, mas isto diminui a compressão, aumentando o tamanho do arquivo. Dentre os diversos trabalhos que implementam este tipo de mecanismo podem ser citados: SE_MPEG(Li et al,. 1996), Aegis (Spannos et al., 1995) (Spannos et al., 1996) e SECMPEG (Meyer et al,. 1995). No SE_MPEG com criptografia somente de quadros I, a degradação da performance (fps) devido à criptografia varia de 10 a 15% (Li et al., 1996). Já para os quadros I, P e B, varia de 13 a 22% (Liet al,. 1996). Apesar de parecerem índices altos de degradação, segundo (Li et al., 1996), estes

146 resultados são compatíveis com aplicações para Internet. O Aegis também encripta o cabeçalho de seqüência de vídeo, dissimulando a identidade de uma cadeia MPEG. O código de seqüência final também é encriptado, dificultando ainda mais o reconhecimento de uma cadeia MPEG. Os atrasos obtidos com Aegis são muito próximos daqueles obtidos com um player convencional e o nível de segurança é aceitável, mas não é adequado para aplicações sensíveis (Agi et al., 1996), já que com player com suporte a erros ainda é possível identificar a imagem criptografada. O SECMPEG propõe uma variação do padrão MPEG para a transmissão segura de vídeo, que incorpora criptografia seletiva e informações adicionais no cabeçalho. 4.3 Algoritmo de Permutação Zig-Zag O mecanismo proposto associa a criptografia a compressão da imagem e do vídeo (JPEG e MPEG) (Tang, 1996). Este mecanismo de criptografia utiliza uma lista randômica de permutação para fazer o mapeamento dos blocos 8 x 8 no vetor 1 x 64, ao invés de fazê-lo em zig-zag (que é utilizado pelo padrão MPEG). A partir de quatro experimentos com a ordem dos coeficientes DC e AC no vetor 1 x 64 concluiuse que: - a posição do coeficiente DC é importante; - a imagem ainda é compreensível se o coeficiente DC for zero e os coeficientes AC forem permutados em zig-zag; - o último coeficiente AC pode ser mudado para zero através da matriz de quantização sem prejuízo à qualidade da imagem. Outro mecanismo estudado é a divisão do coeficiente DC (d 0 d 1 d 2 d 3 d 4 d 5 d 6 d 7 ) em duas partes com quatro bits, sendo uma delas colocada no lugar do coeficiente DC (d 0 d 1 d 2 d 3 ) e outra no lugar do último coeficiente AC (d 4 d 5 d 6 d 7 ). Assim, a codificação / criptografia utiliza este mecanismo, e em seguida aplica a lista de permutação ao vetor 1 x 64, ao invés da permutação em zig-zag. Este algoritmo aumenta consideravelmente o tamanho das cadeias de vídeo, já que, quando alterase a ordem do vetor 1x64, reduz-se a capacidade de compressão (esta é maximizada quando aplica-se à lista de permutação em zig-zag, o que aumenta o número de símbolos repetidos de Huffman). A Tabela 2 mostra o desempenho do algoritmo para dois vídeos: flower.mpg e tennis.mpg. Tabela 2: Desempenho do Algoritmo de Permutação Zig- Zag Tempo para codificação Vídeo Algoritmo Original (sem criptografia) Algoritmo de Permutação Zig-Zag flower.mpg seg seg tennis.mpg seg seg 4.4 VEA (Video Encryption Algorithm) O algoritmo Video Encryption Algorithm (VEA) utiliza o comportamento estatístico do vídeo comprimido (Qiao et al., 1997). A análise estatística feita com as cadeias de vídeo MPEG trata as cadeias de vídeo como bytes. A primeira observação feita é que a freqüência de ocorrência dos valores destes bytes (0 a 255) é praticamente a mesma para qualquer valor do byte. Analisando esta distribuição para meio byte, em qualquer posição da cadeia, não ocorre nenhuma alteração na distribuição de freqüência. Ainda, observa-se que diferentes cadeias MPEG possuem o mesmo comportamento. Outro estudo realizado é relacionado a freqüência de ocorrência de digramas (pares de números adjacentes). Esta análise divide o quadro I em porções, e então verifica-se o número de ocorrências do par de maior freqüência na porção. Se um destes pares se repetir, então um digrama se repetiu. Observou-se que não há nenhum padrão de byte repetido com porções de 1/16 de um quadro I. Esta informação é relevante para o desenvolvimento do algoritmo VEA. O algoritmo VEA assume que uma porção do quadro I terá a seguinte forma: a 1 a 2...a 2n-1 a 2n. Separase os bytes pares dos bytes ímpares, obtendo duas novas cadeias (lista par e lista ímpar). Aplica-se a função Ou-exclusivo entre as listas par e ímpar, obtendo-se c 1 c 2...c n. Escolhe-se uma função de criptografia E, e aplica-se a lista par. O texto criptografado é c 1 c 2...c n E (a 2 a 4...a 2n ). O VEA proporciona um ganho de 47% no tempo total de criptografia em relação à criptografia com o IDEA (Qiao et al,. 1997). 4.5 Permutação Pura Os resultados estatísticos que permitiram o desenvolvimento do VEA, também validam o uso da Permutação Simples. A permutação simples embaralha os bytes das cadeias por permutação. A cardinalidade da chave de permutação depende do nível de segurança desejado, podendo variar de 64 números até 1/8 de um quadro I (Qiao et al., 1998). 4.6 Comparação Entre Os Mecanismos Descritos Alguns dos mecanismos de criptografia descritos podem alterar o tamanho da cadeia de vídeo MPEG, como o de Permutação em Zig-Zag. O nível de segurança de cada um dos mecanismos é diferente, além do tempo necessário para a criptografia(ou velocidade de criptografia) (Qiao et al., 1998). Assim, pode-se comparar estes algoritmos segundo três parâmetros: velocidade de criptografia, nível de segurança e tamanho das cadeias de vídeo. A Tabela 3 mostra os resultados desta comparação (Qiao et al., 1998), parecendo o VEA ser o melhor algoritmo.

147 Tabela 3: Comparação dos Algoritmos de Criptografia MPEG Algoritmo Nível de Segurança Velocidade Tamanho das Cadeias Criptografia Pura Alto Lento Sem alterações Criptografia Moderado Rápido Aumenta Seletiva Permutação Zig-zag Muito baixo Muito rápido Aumenta muito VEA Alto Rápido Sem alterações Permutação Pura Baixo Super rápido Sem alterações 5 UM MECANISMO SEGURO PARA A DISTRIBUIÇÃO DE VÍDEO MPEG Uma vez analisados os mecanismos de criptografia existentes, é possível levantar quais as características importantes para um mecanismo seguro de distribuição de vídeo MPEG. A implementação deste mecanismo resultou em: - um player MPEG seguro, o S/Viewer, - na definição do esquema de codificação / criptografia MPEG para o servidor de vídeo, o S/Server, - no protocolo de acesso ao vídeo. 5.1 Requisitos Este mecanismo de distribuição segura de vídeo MPEG considera os seguintes aspectos de segurança:? Controle de Acesso;? Reprodução de Material Autenticado;? Diversos Níveis de Segurança Reprodução de Material Autenticado Para iniciar a reprodução de um vídeo MPEG seguro, o S/Viewer solicita o certificado digital do servidor de vídeo, garantindo desta forma a autenticidade do material a ser reproduzido. Além disto, o player também verifica a integridade do vídeo a ser reproduzido, através da verificação do hash do mesmo, que está encriptado na assinatura digital Níveis de Segurança Os vídeos disponíveis no servidor possuem diferentes requisitos de segurança. Estes níveis podem ser obtidos através de dois modos: - utilizando diferentes esquemas de codificação / criptografia MPEG; - através do uso de diferentes chaves de criptografia para diferentes clientes. A Tabela 3 (Qiao et al, b ) mostra que diferentes esquemas de criptografia oferecem níveis diferentes de segurança e de velocidade. Maior segurança, em geral, resulta em menor velocidade de criptografia. Desta forma, a escolha do esquema de criptografia deve considerar um compromisso entre atender aos requisitos de segurança e oferecer um desempenho adequado em termos de tempo de codificação / decodificação. Um nível adicional de segurança, para casos mais críticos, pode ser obtido através do uso de chaves diferentes de criptografia para clientes diferentes terem acesso a um mesmo vídeo. 5.2 Arquitetura do Sistema A Figura 4 ilustra a arquitetura do sistema proposto e implementado Controle de Acesso Os vídeos armazenados no servidor são divididos em dois grupos: vídeos de acesso público e de acesso restrito. Os vídeos de acesso público podem ser reproduzidos por qualquer usuário, fazendo parte dos privilégios de todos os usuários que acessem o servidor de vídeo após a sua identificação. Já os vídeos de acesso restrito, como é o caso daqueles pertencentes aos cursos online, possuem associados a eles uma lista com os usuários que tem a autorização para reproduzi-los. A lista de permissão de acesso de um vídeo é criada quando da inserção do mesmo no servidor de vídeo, podendo ser alterada por seu responsável posteriormente. A identificação do usuário é feita através de seu certificado digital, e os seus privilégios são determinados verificando as listas de acesso dos vídeos. Figura 4: Arquitetura do Sistema O servidor de vídeo, S/Server, possui uma base de dados associada, onde estão cadastrados os vídeos com as informações necessárias (nível de segurança e usuários que terão acesso aos vídeos) e os usuários com as suas permissões. O S/Viewer permite ao usuário assistir vídeos MPEG padrão ou seguros (vms - vídeo MPEG seguro), além de poder escolher entre assistir um vídeo gravado localmente ou acessar um servidor de vídeo. O cliente se comunica com o servidor através do protocolo TCP, utilizando uma porta entre as disponíveis. A implementação do servidor suporta

148 múltiplas conexões, através da criação de novos processos. 5.3 Especificação A especificação do mecanismo de distribuição segura de vídeo MPEG consta de três partes: do protocolo de acesso, do servidor de vídeo (S/Server) e do player (S/Viewer). As próximas seções tratam desta especificação. Cliente Envia seu Certificado Validação do Certificado do Servidor Requisita lista de vídeos Disponibiliza lista ao usuário Requisita um vídeo específico Identificação Identificação Requisição de lista de vídeos Lista de vídeos Requisição do vídeo Vídeo MPEG seguro Servidor Validação do Certificado do Cliente Envia seu Certificado Verifica direito de acesso e envia lista de vídeos Montagem do cabeçalho e envio do vídeo criptografado Execução do vídeo Figura 5: Diagrama de Tempo das Mensagens Trocadas entre o Cliente e o Servidor para Acesso ao Vídeo MPEG Seguro Protocolo de Acesso Para acessar um vídeo disponível no S/Server (servidor de vídeo), o S/Viewer (o player MPEG seguro proposto) irá estabelecer uma conexão com o mesmo. A Figura 5 ilustra as mensagens trocadas durante o processo de acesso ao vídeo. A primeira mensagem que o cliente envia contém um campo de controle, o seu certificado digital e o horário da requisição criptografado com a sua chave privada (E KRC [tempo]), conforme observase na Figura 6. Controle Certificado Digital E KR[tempo] Figura 6: Formato da Mensagem de Identificação do Cliente O campo de controle é utilizado para identificar o tipo da mensagem, neste caso uma mensagem de identificação. O horário da requisição deve ser indicado para que o servidor possa rejeitar requisições antigas, que se atrasaram no trajeto até o servidor, ou então para evitar ataques do tipo replay, onde um usuário inválido reenvia uma requisição válida para tentar obter acesso aos vídeos. Ao receber esta mensagem, o servidor irá verificar o certificado digital do cliente, e decriptografar o horário recebido com a chave pública do cliente. Se este horário estiver num intervalo de tempo válido, o servidor envia o seu certificado digital, o horário recebido do cliente encriptado com a chave pública do mesmo, e o horário atual criptografado com a sua chave privada em uma mensagem de identificação (Figura 7). Controle Certificado Digital E KU[tempo recebido] E KR[tempo] Figura 7: Formato da Mensagem de Identificação do Servidor O cliente irá verificar o certificado digital do servidor, se o horário recebido criptografado com a sua chave pública é o mesmo que enviou, e se o horário recebido assinado pelo servidor é válido. Se os horários estiverem corretos e o certificado digital do servidor de vídeo corresponder ao escolhido pelo cliente, este terá a garantia de estar acessando o servidor desejado. Após a verificação dos certificados, o cliente irá efetuar uma requisição dos vídeos disponíveis (Requisição de Lista de Vídeos), ou então solicitar um vídeo específico (Requisição de Vídeo). Observe que no caso de um curso a distância, o próprio curso indicará o nome do vídeo a ser exibido, fazendo assim uma requisição direta do vídeo. No caso da requisição de lista de vídeos disponíveis (Figura 8) identificada pelo campo de controle, o servidor irá verificar quais os privilégios do cliente e irá responder com a lista de vídeos. O cliente, então, irá selecionar o vídeo desejado e fazer uma Requisição de Vídeo. Figura 8: Formato da Mensagem de Requisição de Lista de Vídeos Quando o servidor recebe uma requisição de vídeo (Figura 9), este verifica se o usuário possui permissão de acesso ao mesmo. Em caso afirmativo, inicia o processo de transmissão do vídeo MPEG seguro. Caso contrário, envia uma mensagem de erro informando que o acesso ao vídeo não foi permitido. Controle Controle E KR[tempo] Nome do Vídeo E KR [tempo] Figura 9: Formato da Mensagem de Requisição de Vídeo

149 Todas as mensagens trocadas entre o servidor e o cliente possuem um campo com o horário, assinado digitalmente pelo remetente. Desta forma garante-se a autenticidade das mensagens, e evita-se ataques do tipo reply. É importante registrar estas transações de controle de acesso e troca de certificados em um arquivo de log do servidor de vídeo. Com estas informações é possível identificar quais são os usuários do sistema e quem acessa os vídeos disponíveis, permitindo uma posterior auditoria, cobrança, ou até mesmo uma simples verificação dos vídeos mais acessados O servidor de Vídeo: S/Server O servidor de vídeo é responsável pela criptografia e pela transmissão do vídeo MPEG. Uma vez recebida a requisição do vídeo, o servidor deve cumprir as seguintes etapas, conforme ilustrado na Figura 10:? criptografar o vídeo MPEG, ou localizar um já criptografado;? montar o cabeçalho MPEG seguro;? montar o arquivo a ser transmitido;? transmitir o arquivo. Criptografia do vídeo MPEG solicitado, ou localização do mesmo Montagem do cabeçalho (código de início + E KUC[E KRS[K vms] + Hash do vídeo] ) Montagem do arquivo a ser transmitido (cabeçalho + arquivo mpeg criptografado) Transmissão do arquivo MPEG seguro Figura 10: Fluxograma da Criptografia e Transmissão do Vídeo Seguro A criptografia do vídeo MPEG é feita utilizando um dos esquemas apresentados anteriormente, conforme o nível de segurança:? escolhe-se o algoritmo correspondente ao nível de segurança e desempenho desejados, determinado quando o vídeo é cadastrado no servidor.? em geral, utiliza-se o mais eficiente, tomando como base a comparação mostrada na Tabela 3, que implica na utilização do VEA (Qiao et al, 1998). A criptografia do arquivo MPEG pode ser realizada antes da transmissão do mesmo, ou somente quando o usuário solicita o vídeo (criptografia on the fly). Caso a criptografia seja anterior à requisição, esta será atendida mais rapidamente, porém o nível de segurança é menor já que diversos usuários receberão vídeos MPEG seguros criptografados com a mesma chave. A criptografia no instante da requisição permite que diferentes usuários recebam arquivos MPEG seguros e com diferentes chaves de criptografia. O cabeçalho MPEG seguro é necessário para que o visualizador (S/Viewer) possa reproduzir o vídeo MPEG. Este cabeçalho é composto pelo código de início de seqüência de vídeo VMS (vídeo MPEG seguro), pela chave de criptografia do vídeo VMS (K VMS ) e pelo hash do vídeo VMS. Para garantir a confidencialidade da chave de criptografia do vídeo (K VMS ) e do hash do vídeo VMS, estas informações são criptografadas com a chave pública do usuário (K UC ). Além disto, para garantir a autenticidade da chave de criptografia do vídeo (K VMS ), esta é criptografada com a chave privada do servidor (K RS ). Assim o cabeçalho fica conforme observa-se na Figura 11. Código de início E KUC[E KRS[K vms] + Hash do vídeo] Figura 11: Cabeçalho do Arquivo MPEG seguro (VMS) Após montar o cabeçalho, este é acrescentado ao arquivo MPEG criptografado, e a transmissão do mesmo é iniciada. A transmissão do arquivo pode ocorrer de duas formas: o arquivo completo ou por streaming Reprodução do Vídeo MPEG: S/Viewer Reproduzir um vídeo MPEG criptografado significa decriptografá-lo e decodificá-lo simultaneamente e em tempo real. Ou seja, o vídeo não fica disponível ao usuário decriptografado. O player seguro deve ser capaz de reproduzir vídeos MPEG padrão e vídeos MPEG criptografados. Para identificar o tipo de vídeo a ser reproduzido é necessário determinar um código de início para o vídeo MPEG criptografado, uma vez que todo vídeo MPEG padrão é identificado pelo seu código de início de seqüência. Assim, o primeiro passo para a reprodução de um vídeo é identificar o tipo de MPEG: padrão ou criptografado. Se for um arquivo MPEG padrão, a reprodução é executada normalmente. Caso seja um vídeo MPEG criptografado, são necessários os outros passos. Se o vídeo a ser reproduzido for um MPEG criptografado, é necessário desmontar o cabeçalho e decriptografar as informações criptografadas utilizando para tanto a chave privada do cliente (D KRC [E KRS [K VMS ] + Hash do vídeo], resultando em E KRS [K VMS ] e no Hash do vídeo).

150 Verifica código de início para determinar tipo de vídeo MPEG MPEG Padrão MPEG Criptografado Decodifica segundo o padrão MPEG Desmonta cabeçalho do arquivo D KUC[ E KRS [K vms + Hash] Verifica certificado digital do servidor OK Não Verifica hash do arquivo MPEG criptografado Erro Reprodução terminada OK Não D KUS[K vms] Erro Reprodução terminada Reprodução do vídeo MPEG criptografado Figura 12: Fluxograma do Mecanismo de reprodução de vídeo MPEG criptografado Então, o certificado do servidor é verificado. Em seguida, calcula-se o hash do arquivo MPEG criptografado e compara-se com o hash recebido. Caso ocorra algum erro, a reprodução do arquivo é terminada. Esta descrição considera que o hash do vídeo é calculado para todo o arquivo MPEG, assim é necessário ter recebido o arquivo todo para iniciar a sua reprodução. Na distribuição de vídeo por streaming, o método de cálculo do hash do arquivo MPEG é aplicado nas partes do arquivo MPEG. O próximo passo é obter a chave K VMS (através de D US [K VMS ]) para, então, iniciar a reprodução do vídeo. A Figura 12 mostra as etapas do processo de reprodução de um vídeo MPEG pelo player proposto. 6 IMPLEMENTAÇÃO E RESULTADOS INICIAIS O player MPEG seguro (S/Viewer) e o servidor (S/Server) propostos utilizam o software MPEG implementado na parte 5 do padrão ISO/IEC e Este programa foi desenvolvido em linguagem C, que é a mesma linguagem adotada para o desenvolvimento do servidor e do player seguro. O decodificador MPEG utilizado gera a saída do vídeo em um display gráfico executável no ambiente Unix. Assim, este Mecanismo de Distribuição Segura de Vídeo foi implementado no ambiente Unix (Linux Red Hat 6.1 com Kernel ). No desenvolvimento da Interface Gráfica do S/Viewer, utilizou-se o aplicativo Glade (Glade). Este aplicativo permite que sejam montadas janelas com botões e menus de maneira amigável. É possível utilizar a interface padrão GTk, ou a Gnome para gerar as janelas, gerando o código correspondente em uma linguagem de programação escolhida. A Figura 13 mostra a tela inicial do S/Viewer. Tanto o S/Viewer como o S/Server manipulam certificados digitais, utilizam funções de Hash e diversos algoritmos de criptografia padronizados. No desenvolvimento do S/Server e do S/Viewer foi utilizada a biblioteca OpenSSL (OpenSSL), que implementa os padrões de diversos algoritmos e certificados digitais, possui código aberto e documentação disponível. O mecanismo proposto encontra-se em fase de validação do protocolo de comunicação entre o cliente e o servidor. Durante os testes iniciais, verificou-se que o protocolo apresentava uma falha, estando sujeito a reply ataques, que foi corrigida através de temporização.

151 Figura 13: Tela Inicial do S/Viewer A próxima etapa de validação trata dos testes de desempenho do cliente e do servidor, considerando a codificação / criptografia e a decodificação / decriptografia. 7 CONSIDERAÇÕES FINAIS O presente trabalho trata de um mecanismo para distribuição segura de vídeo MPEG, sendo discutidos níveis de segurança específicos para este tipo de vídeo. Os níveis de segurança dependem das diversas técnicas de criptografia de vídeo MPEG apresentadas neste trabalho. Porém o mecanismo desenvolvido pode ser facilmente adaptado para outros tipos de arquivos de vídeo, e até mesmo para áudio, havendo alterações apenas nos níveis de segurança, e suas respectivas técnicas de criptografia. A partir da análise dos mecanismos de criptografia MPEG existentes e do levantamento dos requisitos de um MPEG player seguro, foi possível especificá-lo e implementá-lo. Os resultados iniciais indicam novas etapas a serem cumpridas. Com a implementação do MPEG player, o próximo passo é a realização de testes para verificar o nível de segurança do mecanismo e sua velocidade de criptografia e decriptografia. Quanto maior o nível de segurança, menor o desempenho. Assim, determinar um compromisso entre o nível de segurança e desempenho é necessário. LEGALL, D.J. MPEG: A Video Compression Standard for Multimedia Applications. Communications of the ACM, Vol. 34, nº 4, April LI, Y.; CHEN, Z.; TAN, S. & CAMPBELL, R.H. "Security Enhanced MPEG Player". In proceedings of the First International Workshop on Multimedia Software Development (MMSD 96), Berlin, Germany, March MEYER, J; GADEGAST, F. Sicherheitsmechanismen für Multimedia-Daten am Beispiel MPEG-I Video. Projektbericht, TU Berlim, MITCHEL, J.L.; PENNEBAKER, W.B.; FOGG, C.E; LEGALL, D.J. MPEG Video Compression Standard". Chapman and Hall, OpenSSL: QIAO, L.; NAHRSTEDT, K. A New Algorithm for MPEG Video Encryption. In proceedings of the First International Conference on Imaging, Science, Systems and Technology (CISST 97), Las Vegas, Nevada, July QIAO, L.; NAHRSTEDT, K. Comparison of MPEG Encryption Algorithms. In Computer & Graphics, vol. 22, nº 4, SPANOS, G.A; MAPLES, T.B. Performance Study of a Selective Encryption Scheme for the Security Networked, Real-Time Video. In proceedings of Fourth International Conference on Computer Communications and Networks, Las Vegas, Nevada, September SPANOS, G.A; MAPLES, T.B. Security for Real-Time MPEG Compressed Video in Distributed Multimedia Applications. In FIFTEENTH IEEE INTERNATIONAL PHOENIX CONFERENCE ON COMPUTERS AND COMMUNICATIONS, Scottsdale, AZ, March STALLINGS, W. "Criptography and Network Security, Principles and Practice", Prentice Hall, 2 nd Edition, TANG, L. Methods for Encrypting and Decrypting MPEG Video Data Efficiently. In Proceedings of The Fourth ACM International Multimedia Conference (ACM Multimedia 96), Boston, MA, November REFERÊNCIAS BIBLIOGRÁFICAS AGI, I.; GONG, L. An Empirical Study of Secure MPEG Video Transmission. In proceedings of the Internet Society Symposium on Network and Distributed System Security, San Diego, CA, Feb FEGHHI, J; FEGHHI, J; WILLIAMS, P. Digital Certificates, Applied Internet Security. Addison Wesley, Glade: