Auditoria de segurança

Transcrição

1 Segurança em Sistemas de Comunicação Relatório do Trabalho Prático nº 4 Auditoria de segurança Documento elaborado pela equipa: Jorge Miguel Morgado Henriques jmmh@student.dei.uc.pt Ricardo Nuno Mendão da Silva rnsilva@student.dei.uc.pt Data de entrega:

2 1

3 Índice Introdução e Objectivos... 3 Metodologia... 4 NMAP (NETWORK MAPPER)... 5 NETVISION... 8 Falhas de segurança (KEVIN) (BILL.DEI.UC.PT) (POTATO.DEI.UC.PT) Relatórios Conclusão

4 Introdução e Objectivos Este trabalho tem por objectivo a realização de uma auditoria de segurança a uma rede local, com vista à elaboração de um relatório descritivo das vulnerabilidades encontradas e aponte medidas de correcção para os problemas de segurança detectados. Não existem restrições no que diz respeito às ferramentas escolhidas para levar a cabo a auditoria. Os problemas de segurança poderão estar ligados a vulnerabilidades passíveis de comprometer a segurança quando exploradas remota ou localmente (no(s) servidor(es) activos nessa rede). A rede alvo é a /25. 3

5 Metodologia De modo a levar a cabo a auditoria, foram utilizadas diversas ferramentas a fim de obter o máximo de informação possível. Para efectuar recolha de informação sobre a rede e a sua topologia, foram utilizados o Traceroute (tracert no Windows) e o VisualRoute. Figura 1 Traceroute a partir de casa Para efectuar scanning da rede procurando hosts activos e efectuar port scanning aos mesmos foram utilizados o ping e o nmap. Através do ping é possível determinar se um host se encontra activo ou não contudo, numa rede que pode ter até 128 hosts, torna-se pouco produtivo utilizar esta técnica. Por isso foi utilizado o nmap que já permite, entre outros, fazer ping sweeps a uma rede. No entanto o nmap não se resume a isto. O nmap (network mapper) é um port scanner que permite explorar diversas técnicas de port scanning para verificar um conjunto alargado de máquinas em simultâneo. As diversas técnicas que utiliza permitem detectar hosts activos na rede, que serviços (aplicações e respectivas versões) eles disponibilizam, o sistema operativo utilizado (e respectiva versão), tipos de filtros de pacotes usados, e outros. Assim estamos na presença de uma ferramenta muito importante neste tipo de acções. Outra ferramenta muito útil que encontrámos e que também permite fazer host discovery e port scanning é o NetVision (da Axcence Software). Apesar 4

6 de uma trial version, pudemos com esta aplicação descobrir os hosts activos na rede e posteriormente efectuar um port scannning a cada uma das máquinas observando os serviços disponibilizados por estes. Acaba por se revelar uma ferramenta semelhante nmap, contudo este possibilita uma gama de configurações mais alargada. NMAP (NETWORK MAPPER) Com o nmap começámos por executar o comando seguinte: nmap sp PS /25 Este comando permite efectuar um Ping Scan (-sp) para verificar quais hosts se encontram activos. Com o parâmetro PS alteramos a técnica de port scanning de TCP Connect para TCP Syn de forma a diminuirmos a probabilidade de o port scanning ser detectado por firewalls em modo statefull. Contudo, estes pings continuam a usar o porto 80, definido por defeito no nmap, e é neste ponto que reside a causa de insucesso deste scan. Qualquer normal gestor de redes e sistemas, tendo conhecimento do facto de uma ferramenta utilizada em sondagens sobre a rede, utilizar por defeito o porto 80, pode muito bem configurar o router que serve de entrada à rede para responder a esse tráfego por forma a simular uma máquina activa na rede. Se isto for feito para todos os endereços da rede, é mais uma forma de induzir o atacante em erro. Assim o resultado deste primeiro scan não foi bem o esperado, apesar de ter chamado a nossa atenção para o facto de duas das possíveis máquinas terem um nome associado ao IP, nome esse que aparece e que está registado no servidor de DNS. Tivemos de afinar a nossa busca. nmap sp PS /25 E com este comando eliminámos um número enorme de hosts que aparentemente estariam activos mas na verdade não estavam. Contudo, um dos hosts que nos tinha chamado a atenção por estar registado no servidor de DNS com o nome potato.dei.uc.pt também deixou de aparecer. 5

7 Figura 2 Scan da rede /25 Resolvemos continuar a trabalhar nas pesquisas do nm ap. Desta vez optámos por efectuar pings ICMP Echo através do comando: nmap sp PE /25 aos quais obtivemos resposta de 4 hosts, 3 dos quais descobertos na pesquisa anterior e mais o (potato.dei.uc.pt). Figura 3 Scan da rede /25 Ainda com o nmap é possível efectuar port scanning de forma a ver quais as portas efectivamente abertas, e os serviços aí disponíveis, bem como as suas versões. Em seguida mostramos um exemplo disso mesmo. 6

8 7 Figura 4 Port Scanning ao host (bill.dei.uc.pt)

9 NETVISION Com esta ferramenta, as conclusões foram idênticas. Os hosts activos encontrados foram os mesmos. Figura 5 Utilização de NetVision e NetTools para efectuar Scan da rede e Port Scannning do host Temos em segundo plano a aplicação NetVision que arrancou primeiro e identificou os host activos (no rectângulo laranja). Em primeiro plano ficou a aplicação NetTools que permitiu efectuar port scanning a um do host activos, neste caso o bill.dei.uc.pt (informação relevante nos rectângulos encarnados). 8

10 Assim sendo concluímos que os hosts activos nos quais deveríamos procurar vulnerabilidades, atentando aos serviços disponibilizados, são: (KEVIN); (bill.dei.uc.pt); (potato.dei.uc.pt);

11 Falhas de segurança Depois de encontrados os hosts activos na rede, devemos debruçar a nossa auditoria em cada um dos hosts em particular, efectuando port scannings e utilizando ferramentas de detecção remota de problemas. Neste capítulo resolvemos recorrer ao Nessus como forma de encontrar vulnerabilidades ou falhas de segurança em cada host. O Nessus é um remote security scanner. Esta aplicação permite efectuar uma auditoria remota a um host ou a um conjunto de hosts e verificar se existem problemas de segurança passíveis de serem explorados. Além de detectar falhas de segurança nos serviços, o Nessus procura ainda verificar se é mesmo possível explorar as vulnerabilidades conhecidas para os serviços em causa, actuando como cracker. Quando utilizamos o Nessus para um conjunto alargado de hosts, este recorre ao nmap para efectuar o scan da rede em busca dos hosts activos e depois é sobre estes hosts que o Nessus realiza o port scanning e a respectiva identificação de vulnerabilidades. No caso do nosso trabalho foram efectuadas auditorias em modo individual aos hosts que achámos que seriam realmente hosts activos e foi também efectuado o teste à rede completa. Acabámos por obter relatórios de segurança para cada IP da rede dado que o nmap identificou cada IP como activo ( Host xxx.xxx.xxx.xxx appears to be up. ). Contudo, pelos relatórios, facilmente se concluiu que os hosts activos eram os quatro já identificados nas etapas anteriores. Apenas se perdeu maisl algum tempo, já que a pesquisa completa da rede fica um pouco mais demorada mas assim também nos permitiu obter informação mais precisa. De seguida passamos a descrever as falhas encontradas pelo Nessus em cada um dos hosts activos (KEVIN) O sistema operativo não foi identificado com exactidão mas, segundo o Nessus será uma máquina com Windows 2000 SP4 ou Windows XP Professional SP2. 10

12 Por via do porto 445/TCP foi possível enumerar as partilhas SMB do host (apesar de não constituir ameaça relevante ao sistema): IPC$ ; Data ; ADMIN$ ; C$. Estas falhas foram detectadas, realizando a auditoria ligado através da rede e-u. Em seguida apresentamos as falhas detectadas ao efectuar a auditoria a partir de uma máquina ligada na rede da escola ( ). Este host tem um web server dísponível no porto 80. Os métodos de debug estão activas neste servidor o que envolve um risco médio, devido ao facto de, nestas condições, o servidor pode sofrer ataques de cross-site-scripting e cross-site-tracing que podem levar à descoberta das credenciais dos utilizadores deste servidor web. O aconselhado é que se desactivem estes métodos. Por via do porto 445/TCP foram ainda encontradas duas falhas críticas no sistema operativo Windows que permitem que seja executado código malicioso no host remoto. A solução em ambas as falhas passa pela aplicação de um update lançado pela Microsoft. Estas soluções encontram-se documentadas nos Microsoft security Bulletin MS e MS e os updates encontram-se disponíveis no site da Microsoft. Através desse mesmo porto foi ainda possível ao Nessus enumerar as partilhas SMB do host (apesar de não constituir ameaça relevante ao sistema): IPC$ ; Data$ ; ADMIN$ ; C$ (BILL.DEI.UC.PT) Este host revelou pelo porto 515/TCP uma falhas de segurança de risco elevado, relacionadas com o deamon lpd instalado. Através de determinados comandos, pode-se crashar o deamon e através de determinados tipos de pacotes pode-se até executar código remotamente, no âmbito do serviço afectado. 11

13 Outra falha de risco elevado encontrada através deste porto foi uma vulnerabilidade no NIPrint que permite a um atacante remotamente levar um buffer interno a overflow de modo a permitir execução de código. Em ambas as falhas não se encontram ainda soluções, restando ao gestor de rede filtrar o tráfego para estas portas de modo eficaz, caso não seja possível negar mesmo todo o tráfego para as mesmas. No caso destes serviços, não nos parece que haja qualquer necessidade em estarem disponíveis a ligações do exterior, pelo que se aconselha que o tráfego proveniente do exterior para estes portos seja filtrado de forma eficaz, nomeadamente no router por onde passa o acesso a esta rede. Por via do porto 111/TCP foi possível identificar uma falha de segurança de risco elevado. Esta falha prende-se com o facto da RPC library ter um overflow de inteiros numa função específica, permitindo a um atacante executar código remotamente com os previlégios que possuem os programas que estiverem a correr, tipicamente root. A solução para esta vulnerabilidade passa por aplicar o respectivo patch lançado pelo fabricante, ou caso ainda não tenha sido lançado um que possa ser aplicado, aconselha-se que os serviços que usem esta função sejam desactivados na medida do possível. Neste mesmo porto, detectou-se uma outra falha de risco médio. Acontece que no porto 111/TCP encontra-se disponível o RPC portmapper, que permite a um atacante obter uma lista dos serviços RPC. É aconselhado que o tráfego para este porto seja filtrado. No porto 21/TCP o Nessus detectou mais uma falha de risco elevado. Esta falha permite bloquear ou até reiniciar o Windows através da leitura de um dispositivo MS-DOS através do FTP, usando um nome como COM\CON, AUX.htm ou AUX. Assim é possível fazer com que o sistema esteja constantemente a crashar e reiniciar evitando assim que funcione da forma desejada. A solução para este problema passa por um upgrade disponibilizado pela Microsoft. Contudo esta falha não se aplica a esta máquina, visto estarmos na presença de uma maquina Linux (pelo que foi identificado pelo próprio Nessus). Ainda neste porto, foi detectado que o servidor FTP não filtra argumentos do comando ls. Assim é possível consumir todos os recursos da máquina com um comando ls w C. O risco desta vulnerabilidade é elevado. 12

14 É possível forçar o servidor FTP a ligar-se a outros hosts através do comando PORT. Este problema permite ao atacantes usar os recursos da nossa rede para efectuar scan em outros hosts levando-os a pensar que o ataque provém da nossa rede, deixando-os passar na nossa firewall. A solução passa por efectuar um upgrade ao servidor de FTP ou mudar de servidor. Por outro lado, deve-se também desactivar a conta anónima de modo a impedir logins anónimos. Do exterior foi possível obter informação sobre o caminho real para a área publica do ftp (/var/ftp) através do comando CWD. Assim o atacante sabe onde deve colocar um ficheiro.rhost usando outros problemas de segurança. Aconselha-se ao procedimento de upgrade do servidor FTP. No porto 443/TCP temos um servidor Apache (Red Hat Linux). Com a configuração actual, é possível listar os conteúdos desse servidor web com o comando GET // HTTP/1.0. A solução a adoptar é usar os ficheiros índex em vez das welcome pages que vêm por defeito. Ainda neste porto pode-se verificar que a versão de SSL usada é a 2.0. Como já foi mencionado neste relatório, é uma versão para a qual já foram encontrada falhas e aconselhase mexidas na configuração, neste caso do Apache, de modo a usar SSL 3.0 ou TLS 1.0. Outra alteração que se deve efectuar na configuração deste serviço é na directiva ServerTokens Prod de m odo a lim itar a inform ação que o servidor fornece sobre si mesmo. Foi possível perceber ainda que o servidor tem activa a página de Welcome por defeito. Isto pode indicar que o servidor não é utilizado e, cão seja essa a realidade, deve-se desligar por completo. Ao nível de pacotes ICMP, foi possível detectar a data do sistema através de ICMP timestamp requests (13) e ICMP timestamp replies (14). Assim, um possível atacante pode violar todos os protocolos de autenticação baseados na data do sistema. A solução é filtrar a entrada de ICMP timestamp requests e o envio de ICMP timestamp replies. Através do porto 32772/UDP, pelo serviço rusersd é possível ter acesso a informação preciosa para um atacante como a regularidade de uso da máquina, nomes de utilizadores, e outros. Normalmente não é boa ideia deixar este serviço acessível, embora seja apenas uma vulnerabilidade de rico médio. No porto 651/UDP, através do serviço rstatd é possível a um atacante ter acesso a dados da utilização do procesador, uptime do sistema, utilização de 13

15 rede, e outros. Não se recomenda que este serviço seja deixado acessível. O risco é moderado. Foi possível identificar o sistema operativo como sendo Linux Red Hat 8.0 ou 9. Já testando de fora da rede escolar (a partir de casa), foi possível detectar uma falha no porto 993/TCP. Encontra-se disponível neste porto um servidor IMAP. Este servidor está a aceitar ligações encriptadas em SSL 2.0, que é conhecidamente inseguro e já deixou de ser usado há alguns anos. De modo a resolver este problema, o administrador deverá desactivar o SSL 2.0 e activar o SSL 3.0 ou TLS 1.0 em alternativa. No porto 995/TCP temos um servidor POP3 dísponível, com encriptação SSL 2.0. É aconselhado que seja alterado para 3.0 ou TLS 1.0, visto que SSL 2.0 tem problemas de segurança conhecidos. No porto 79/TCP está disponível o serviço Finger que fornece aos atacantes informação útil como usernames e outros. No relatório efectuado pelo Nessus foi possível encontrar alguma informação sobre a conta root. A forma de solucionar este problem a passa por com entar a linha finger no ficheiro /etc/inetd.conf. No porto 22/TCP está disponível um servidor de SSH (SSH OpenSSH_3.5p1) com suporte para os protocolos da versão 1 e da versão 2. É aconselhado desactivar a compatibilidade com a versão 1 dado que estes protocolos não são totalmente seguros. Este mesmo servidor tem ainda outra falha que se prende com a descoberta da existência de determinado login pela comparação do tempo que o servidor demora a responder a uma password errada para os casos de o login ser inexistente e ser válido. Para solucionar esta falha deve-se desactivar o PAM caso não esteja a ser utilizado, ou efectuar upgrade ao OpenSSH. No porto 7/TCP foi detectado o serviço echo disponível. Este serviço actualmente não é utilizado e deve ser desactivado assim que possível pois torna a máquina vulnerável a ataques de Denial of Service (DOS). Neste caso, que se pensa ser uma máquina Linux, deve-se com entar a linha echo no /etc/inetd.conf. Esta vulnerabilidade foi detectada, através de uma ligação da rede exterior à rede da escola (neste caso foi detectado a partir de casa). 14

16 (POTATO.DEI.UC.PT) Ao nível de pacotes ICMP, foi possível detectar a data do sistema através de ICMP timestamp requests (13) e ICMP timestamp replies (14). Assim, um possível atacante pode violar todos os protocolos de autenticação baseados na data do sistema. A solução é filtrar a entrada de ICMP timestamp requests e o envio de ICMP timestamp replies. Foiainda possívelao N essus crashar o host através de um ataque Pim p. Esta vulnerabilidade permite ao atacante crashar o host constantemente à sua vontade não deixando que a máquina seja usada no seu proposto. A forma de solucionar este problema é filtrar o tráfego IGMP que entra na maquina na firewall. Estas falhas foram detectadas a partir de uma localização dentro da rede interna da escola. A partir do exterior nenhuma destas falhas foi detectada No porto 22/TCP está disponível um servidor de SSH (SSH OpenSSH_3.5p1) com suporte para os protocolos da versão 1 e da versão 2. É aconselhado desactivar a compatibilidade com a versão 1 dado que estes protocolos não são totalmente seguros. Ao nível de pacotes ICMP, foi possível detectar a data do sistema através de ICMP timestamp requests (13) e ICMP timestamp replies (14). Assim, um possível atacante pode violar todos os protocolos de autenticação baseados na data do sistema. A solução é filtrar a entrada de ICMP timestamp requests e o envio de ICMP timestamp replies. No porto 123/UDP foi possível obter bastante informação do host, com base no servidor NTP. A forma de solucionar este problema é configurar o servidor NTP de forma restringir o acesso aos pacotes de informação (restrict default ignore). 15

17 Foi ainda detectada neste host uma falha de risco elevado. Foi possível crashar o host com um ataque oshare. O sistema operativo desta máquina corre o Linux Kernel (i386). As falhas encontradas nesta máquina foram sensivelmente as mesmas tanto testanto dentro da rede da escola como a partir do exterior. Relatórios Os relatórios elaborados pelo Nessus seguem em anexo. 16

18 Conclusão Este trabalho consistia numa auditoria de segurança a uma determinada rede, sobre a qual apenas sabíamos o endereço ( /25). Para executar esta tarefa, foram-nos dadas algumas referências de ferramentas a usar e alguns procedimentos. A partir daí, competia-nos a nós desenvolver o raciocínio, conjugar com os resultados obtidos das ferramentas de análise e desenvolver um relatório que abordasse precisamente as falhas de segurança e as suas soluções. Foi assim que abordamos o trabalho, com uma natural falta de experiência de quem tem pela primeira vez uma cadeira especificamente sobre segurança de sistemas de comunicação, contudo, o interesse que temos pela área e, neste caso concreto, o interesse que o trabalho despertou, atenuou de certa forma as dificuldades que sentimos. Como é óbvio, a grande dificuldade prendeu-se talvez com a interpretação de alguns resultados obtidos, mas ainda assim pensamos que desenvolvemos um bom trabalho. Como já referimos, foi uma tarefa que se revelou bastante interessante, não só no seu objectivo mas igualmente nos moldes em nos foi proposta. 17