O Security Enhanced Linux (SELinux) é uma camada adicional de segurança do sistema. Ele não utiliza as regras de firewall (iptables, firewalld…) e também não utiliza o sistema de acesso/permissão “UGOA” (user, group, others, all).
A proposta do SELinux é utilizar Controle de Acesso Obrigatório (Mandatory Access Control, MAC) que é baseado em objeto, restringindo o acesso de um usuário ou iniciador a esse objeto.

O SELinux se baseia em um conjunto de regras de segurança que determinam qual processo pode acessar quais arquivos, diretórios e portas. Esse controle é feito através de um rótulo que cada processo, porta ou arquivo recebe. Esse rótulo, dentro do SELinux é conhecido “context”.
Cada contexto tem uma política de acesso para determinar o que pode ser acessado e o que não pode ser acessado. Porém, o SElinux funciona de forma restritiva, ou seja, caso a regra não seja explícita, o acesso será negado.
Os rótulos do SELinux têm vários contextos: usuário, função, tipo e sensibilidade.

A política direcionada (SELINUXTYPE=targeted que está no arquivo de configuração do SELinux, demonstrada a seguir), que é a política padrão ativada. Ele se baseia no contexto “TIPO”. Eles são facilmente identificados, pois geralmente terminam com _t.

Contexto do arquivo SELinux:
unconfined_u:object_r:user_home_dir_t:s0 /home/bruno/

_u: User
_r: Role
_t: Type
s: Level

Abaixo, alguns contextos de tipo para arquivos e diretórios:

– /home é user_home_dir_t;
– /var/www/html é httpd_sys_content_t;
– /tmp e /var/tmp é tmp_t.

Também há contextos para portas de um servidor web, por exemplo, que é o http_port_t.

Isso tudo impede que serviços que foram comprometidos não tenha acessos a outras áreas do sistemas operacional.
Um bom exemplo é o caso do Apache. Caso comprometido, o usuário e grupo apache têm acesso ao /tmp. Com as regras restritivas do SELinux, o acesso do apache só sera do diretório /var/www/html

Alguns comandos utilizam a opção “-Z” para exibir os contextos do SELinux.

Exemplos:

# ps uaZ
# ls -Z

ENTENDENDO E ALTERANDO OS ESTADOS DO SELINUX

Para fins didáticos, vamos separar o processo do SELinux em algumas partes.
A primeira, mais básica: Ativado e Desativado.
Ativado: Ele inicia junto ao sistema operacional;
Desativado: Ele NÃO inicia junto ao sistema operacional.

Para fazer isso na inicialização, pode passar um parâmetro no Kernel informando seus estados.
Para Desativar, basta passar o parâmetro selinux=0
Para Ativar, basta passar o parâmetro selinux=1
Mais a frente, demonstro como fazer no arquivo de configuração e de forma definitiva.

Quando o SELinux está Ativo, ele tem dois estados de funcionamento: Imposição (enforcing) e Permissivo (permissive)

Imposição: o SELinux está ativo e impõe que as regras de controle de acesso sejam utilizado no Sistema Operacional.
Permissivo: o SELinux está ativo mas apenas registra quais regras de controle de acesso foram violadas sem impedir qualquer tipo de acesso.

A vantagem da utilização do modo Permissivo é o fato de não alterar o acesso ao sistema e poder utilizar para estudos, testes ou correções de problemas.
Quando o SELinux está desativado, nem mesmo o registro dos acessos é feito.

Para fazer uma verificação manual do SELinux e assim saber em qual modo ele está, pode verificar manualmente ou através do seu arquivo de configuração

getenforce = Verifica o estado atual do SELinux.
setenforce = Aplica um novo estado para o SELinux

Para o modo Imposição (Enforcing):
setenforce 1” ou “setenforce Enforcing

Para o modo Permissivo (Permissive):
setenforce 0” ou “setenforce Permissive

ARQUIVO DE CONFIGURAÇÃO DO SELINUX

O arquivo de configuração do SELinux fica em “/etc/selinux/config“. Nele é possível modificar de forma definitiva o comportamento do SELinux ao iniciar o sistema;

# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – No SELinux policy is loaded.
SELINUX=enforcing

# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# minimum – Modification of targeted policy. Only selected processes
# are protected.
# mls – Multi Level Security protection.
SELINUXTYPE=targeted

Basta utilizar o nome do estado do SELinux no parâmetro de mesmo nome.

SELINUX=enforcing
SELINUX=permissive
SELINUX=disabled

Ao finalizar, basta salvar o arquivo e reiniciar o sistema.
Quando o sistema é reiniciado, os parâmetros do Kernel são lidos. Assim como fizemos manualmente informando o estado Ativado ou Desativado, o arquivo de configuração irá informar se o SELinux está ativado selinux=0 ou 1 e qual o seu estado enforcing=0 ou 1

HERANÇAS DOS CONTEXTOS DO SELINUX

Como dito anteriormente, todos os processos e arquivos são rotulados. Novos arquivos herdam o contexto do diretório pai.
Porém, essa herança pode ser prejudicada de duas formas:

1 – Se um arquivo for criado em um diretório e movido para outro, o contexto será do diretório onde foi criado.

Exemplo:

# echo “Servidor Apache” >> /tmp/index.html
# ls -Z /tmp/index.html
# mv /tmp/index.html /var/www/html
# ls -Z /var/www/html/index.html

Observe que o contexto continuará como do diretório /tmp
unconfined_u:object_r:user_tmp_t:s0 /var/www/html/index.html

2 – A outra forma é copiando o arquivo e mantendo seus atributos (cp -a), pois o contexto é preservado.

# echo “Servidor Apache” >> /tmp/index.html
# ls -Z /tmp/index.html
# cp -a /tmp/index.html /var/www/html
# ls -Z /var/www/html/index.html

ALTERAÇÃO DOS CONTEXTOS DO SELINUX

Para alterar os contextos do SELinux, são necessário conhecer 3 comandos:
– semanage
– restorecon
– chcon

O “semanage” serve para fazer a declaração de qual será o rótulo padrão, porém ele tem que vir acompanhado do argumento fcontext.
O “restorecon” faz com que o contexto padrão seja aplicado aos diretórios e arquivos.
Já o “chcon” faz altera o contexto, porém não fica de forma permanente como o “semanage fcontext“. Ele é ideal para a realização de testes por não ficar permanente e pode ser facilmente removido com a execução do “restorecon

Exemplo:

# mkdir /testeSeLinux
# ls -dZ /testeSeLinux
unconfined_u:object_r:default_t:s0 /testeSeLinux/

# chcon -t ssh_exec_t /testeSeLinux
# ls -dZ /home/bruno/testeSeLinux
unconfined_u:object_r:ssh_exec_t:s0 /testeSeLinux/

# restorecon -v /testeSeLinux
Relabeled /testeSeLinux from unconfined_u:object_r:ssh_exec_t:s0 to unconfined_u:object_r:default_t:s0

# ls -dZ /home/bruno/testeSeLinux
unconfined_u:object_r:default_t:s0 /testeSeLinux/

No exemplo acima:
– Criamos um diretório /testeSeLinux
– Mudamos o contexto, não definitivamente, de default_t para ssh_exec_t
– Restauramos o contexto do diretório /testeSeLinux para o padrão (default_t)

DEFINIÇÃO DAS REGRAS DE CONTEXTO PADRÃO DO SELINUX

Utilizando o “semanage fcontext“, podemos definir um novo contexto padrão para diretórios e arquivos.
O “restorecon” utiliza os contextos definidos pelo “semanage” para restaurar o contexto padrão.

A utilização do “semanage fcontext” pode ser para adicionar, deletar ou listar dos tipos de contexto:

-a (–all): Adiciona um registro
-d (–delete): Apaga um registro
-l (–list): Lista os registros

Para a utilização desses comandos, será necessário verificar se os pacotes policycoreutils e policycoreutils-python-utils estão instaladas em seu Sistema Operacional. Também é necessário o entendimento da seguinte expressão regular: (/.*)? que significa “opcionalmente, corresponder uma / seguida por qualquer número de caracteres” e na prática ele lê o diretório em questão e seus arquivos recursivamente.

A utilização segue a seguinte lógica:

# semanage fcontext -a -t contexto ‘/diretório(/.*)?’

A opção -a é utilizada para adicionar um contexto; A opção -t é o tipo do contexto.
O argumento é o diretório que será aplicado o contexto junto com a expressão regular no final, dentro de aspas simples.

Exemplo:

# mkdir /MeuSite
# echo “Teste do Meu Site” >> /MeuSite/index.html
# ls -Zd /MeuSite
# ls -Z /MeuSite
# semanage fcontext -a -t httpd_sys_content_t ‘/MeuSite(/.*)?’
# restorecon -RFvv /MeuSite
# ls -Zd /MeuSite
#  ls -Z /MeuSite

AJUSTE DO SELINUX COM BOOLEANOS

Os booleanos do SELinux são opções que alteram o comportamento da política do SELinux, regras que podem ser habilitadas ou desabilitadas para fazer ajustes seletivos.
Instale o pacote selinux-policy-doc e com o comando “man -k _selinux” poderá ver todos os manuais disponíveis com todas as regras que utilizam booleanos.

Para fazer esses ajustes, utilizaremos os seguintes comandos:

– getsebool
– setsebool
– semanage boolean (Esse será utilizado apenas para consulta)

O comando “getsebool” lista os booleanos e seus estados. Pode listar todos de uma única vez (-a) ou um específico

# getsebool -a
# getsebool httpd_enable_homedirs

O comando “setsebool” modifica os valores dos booleanos

# setsebool httpd_enable_homedirs on
# semanage boolean -l | grep httpd_enable_homedirs
httpd_enable_homedirs (on , off) Allow httpd to enable homedirs

Nesse ponto você observará que existe entre parênteses as palavras on e off. No primeiro campo, indica o estado atual do valor daquele booleano e o segundo campo indica se aquele valor será persistente ao reiniciar o sistema. No exemplo acima, a opção httpd_enable_homedirs está ativada no momento, porém se a máquina for reiniciada esse estado voltará para desativado.
Para tornar esse valor persistente, vamos utilizar a opção -P.

# setsebool -P httpd_enable_homedirs on
# semanage boolean -l | grep httpd_enable_homedirs
httpd_enable_homedirs (on , on) Allow httpd to enable homedirs

Nesse momento, a opção httpd_enable_homedirs está ativada e caso seja necessário reiniciar o host, a opção permanecerá ativa.

Caso queira listar todos os booleanos que estão com o valor diferente do padrão, basta executar:
# semanage boolean -l -C

ENTENDENDO OS PROBLEMAS DO SELINUX

Todas as ações tomadas pelo SELinux são gravadas em log, portanto podemos utilizar essas informações para verificar se há algum serviço que o SELinux está impedindo de ser executado. Como vimos anteriormente, o “restorecon” server para restaurar o contexto padrão de um diretório. Ele pode resolver em muitos casos, porém é sempre importante entender como o SELinux funciona e suas mensagens para assim resolver o problema mais rapidamente.

Você precisa instalar o pacote setroubleshoot-server para que as mensagens do arquivo “/var/log/audit/audit.log” envie um resumo da informação que o SELinux gerar para o arquivo “/var/log/messages“. Caso sua distribuição não tenha o arquivo messages, instale o pacote rsyslog e inicie o serviço.

Exemplo:
Vamos simular um erro para que assim possa ser gerado o alerta no sistema de auditoria do linux e enviado para o arquivo de mensagens.
Você irá precisar instalar o apache para o exemplo a seguir:

# systemctl start httpd
# echo “Meu Site” >> /root/meusite.html
# mv /root/meusite.html /var/www/html
# curl http://localhost/meusite.html

Nesse momento você verá a seguinte mensagem do Apache:

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don’t have permission to access /meusite.html
on this server.<br />
</p>
</body></html>

Isso gerou um alerta que está nos logs que comentamos anteriormente:

# tail /var/log/audit/audit.log

type=AVC msg=audit(1598297683.712:239): avc: denied { getattr } for pid=5356 comm=”httpd” path=”/var/www/html/meusite.html” dev=”dm-0″ ino=8409719 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

# tail /var/log/messages

localhost setroubleshoot[1913]: SELinux is preventing httpd from getattr access on the file /var/www/html/meusite.html. For complete SELinux messages run: sealert -l 14fa81a0-f8be-40a1-82da-908440c823c8

Nos dois arquivos, é possível observar a negação do acesso ao arquivo “/var/www/html/meusite.html
No arquivo messages, é possível ver a sugestão da utilização do comando “sealert” para ver informações adicionais

# sealert -l 14fa81a0-f8be-40a1-82da-908440c823c8

O “sealert” trará o mesmo conteúdo, mas de duas formas. Uma mais organizada e outra no modo “raw” que trás o mesmo conteúdo do “audit.log

Utilizando a saída do “sealert“, é possível observar três campos importante para o nosso erro:

Contexto de origem system_u:system_r:httpd_t:s0
Contexto de destino unconfined_u:object_r:admin_home_t:s0
Objetos de destino /var/www/html/meusite.html [ file ]

no Raw messages:

scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 path=”/var/www/html/meusite.html”

O “Contexto de origem” ou “scontext” é o contexto que o selinux espera para o “Objetos de destino” ou “path“. Já o “Contexto de destino” ou “tcontext” mostra a informação que o SELinux encontrou no “Objetos de destino” ou “path“. No nosso caso, era esperado “httpd_t” e foi encontrado “admin_home_t“, pois o arquivo foi criado no “/root” (admin_home_t) e movido para “/var/www/” e como vimos anteriormente, isso gera um erro.

Vamos verificar como está o contexto de “/var/www/html

# ls -Zd /var/www/html
system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Agora vamos restaurar o contexto dos arquivos dentro do diretório “/var/www/html

# restorecon -RFvv /var/www/html/
Relabeled /var/www/html/meusite.html from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:httpd_sys_content_t:s0

A saída do comando (por causa da opção -vv) mostra que o contexto do arquivo foi alterado de admin_home_t para httpd_sys_content_t. Com isso, o arquivo html deve estar disponível para acesso.

# curl http://localhost/meusite.html
Meu Site

Apesar de uma explicação básica sobre o SELinux, é possível entender sua importância, como trabalhar com ele e ainda tratar alguns erros.
O objetivo é tirar um pouco da ideia que o SELinux é muito complicado e que só serve para desabilitar após a instalação.

Referências:
https://www.redhat.com/pt-br/topics/linux/what-is-selinux
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/index

Ao som de: Curumin – Passarinho

Essa semana fui perguntado quais ferramentas eu conhecia para buscar vulnerabilidades em sites e hosts. Informei as mais conhecidas como Nessus e OpenVAS.
Porém, me lembrei de uma lista que guardo nos favoritos de alguns sites e ferramentas que também utilizo, porém não cabia na conversa (e minha memória não é melhor que a minha lista de favoritos)

Antes da lista, algumas considerações:

  • Deixando claro que essa não é uma lista definitiva e nem completa, porém é uma forma de compartilhamento de informações.
  • Também não existe ferramenta melhor que a outra. Cada um tem seu propósito e funciona de forma diferente. Pode ser que cada uma delas traga uma informação e cabe a você pegar as melhores informações na hora de gerar seu relatório.
  • Algumas dessas ferramentas não recebem mais atualizações, porém ainda são excelente.

Agora sim, uma pequena descrição de cada uma dessas ferramentas e seus respectivos sites:

theHarvester (https://github.com/laramies/theHarvester)
Ferramenta para a coleta de dados de um host sendo possível encontrar e-mails, subdomínios, IPs e URLs.
Usa vários motores do busca como o Google e Bing, mas também outros mais específicos como o netcraft e shodan.

Netcraft (https://toolbar.netcraft.com/site_report)
Como comentado acima, um tipo de motor de busca, mas que faz uma busca completa em um site.
É possível saber se o site já foi reportado como inseguro e quais são os serviços que mantém o site online.

Shodan (https://www.shodan.io/)
Outro motor de busca, porém mais voltado para dispositivos de rede na internet.
Muito utilizado para levantar informações sobre hosts ou fazer busca de hosts vulneráveis.

Censys (https://censys.io/)
Muito semelhante ao Shodan, também faz buscas na internet usando consultas personalizadas.

Maltego (https://github.com/paterva)
O Maltego é utilizado para fazer busca de informações na internet, semelhante ao theHarvester, porém ele é bem mais visual e mais automatizado.
Excelente quando se pretende levantar informações de um domínio.

nmap (Zenmap e NSE) (https://github.com/nmap/nmap)
Provavelmente a ferramenta mais conhecida dessa lista, o NMAP é uma ferramenta open source para fazer um scan em rede.
Muito utilizada para descobrir portas e vulnerabilidade nos hosts de uma rede. A sua interface gráfica é o Zenmap.

whatsweb (https://github.com/urbanadventurer/WhatWeb)
Caso queira saber quais aplicações e suas versões, redirecionamentos e configurações de um site, o WhatWeb vai ser muito útil.
Ele faz uma consulta ao domínio e retorna as informações da tecnologia que dá suporte ao site, incluindo CMS.

dirb (https://gitlab.com/kalilinux/packages/dirb)
O dirb é um scanner de conteúdo WEB. Ele varre um domínio por completo atrás de outros subdomínios, estando esses publicados ou ocultos.
Geralmente utilizado para encontrar subdomínios que o administrador queria esconder.

dmitry (https://github.com/jaygreig86/dmitry/)
Também com o propósito de levantar informações sobre um domínio, o dmitry usa motores de busca para levantar informações.

Nikto (https://github.com/sullo/nikto)
Assim como os outros acima, busca informações de um domínio. Uma de suas vantagens é a utilização em docker e as constantes atualizações no seu projeto do github

What CMS? (https://whatcms.org)
O site “What CMS?” faz busca no site buscando informações que possam levar a uma possível identificação de um CMS. Está na dúvida se o site é wm WordPress? Esse site irá te ajudar!

WPscan (https://github.com/wpscanteam/wpscan)
Essa ferramenta é voltada para o CMS WordPress. Ela reúne em seu banco de dados as informações das vulnerabilidades conhecidas para o WordPress e assim tenta encontrar essas brechas.

joomscan (https://github.com/rezasp/joomscan)
Assim como WPscan, o joomscan é uma ferramenta voltada a um CMS, mas nesse caso, como o nome sugere, ao Joomla!

sqlmap (https://github.com/sqlmapproject/sqlmap)
Aumentando a lista das ferramentas focadas em uma ferramenta, o sqlmap é uma ferramenta para exploração automatizada utilizando a técnica de SQL Injection.
Feita em python, suporta os bancos de dados mais populares do mercado.

Red Hawk (https://github.com/Tuhinshubhra/RED_HAWK)
Ferramenta feita em PHP para obter informações de sites. De acordo com a sua documentação, ele consegue informações como consultas whois e dns, subdomínios, detecção de CMS.

uniscan (https://sourceforge.net/projects/uniscan/)
Apesar de ser uma das ferramentas mais desatualizadas da lista, é ainda bastante eficiente.
É utilizada para buscar vulnerabilidades dos tipos “Remote File Include, Local File Include e Remote Command Execution” em sites.

skipfish (https://github.com/spinkham/skipfish)
Ferramenta criada pelo Google que faz busca recursiva e ataques de dicionário para buscar vulnerabilidades em sites.

OWASP Zap (https://github.com/zaproxy/zaproxy)
A OWASP é uma comunidade online com foco na melhoria da segurança de softwares. Uma de suas contribuições mais famosas é a sua lista de TOP 10 de vulnerabilidades mais atacadas no mundo.
Essa comunidade criou o ZAP (Zed Attack Proxy) que realiza uma busca automatizada de vulnerabilidades em sites. Também existe a possibilidade de utilizar a ferramenta para buscas manuais.

Sn1per (https://github.com/1N3/Sn1per)
o Sn1per é um framework para um pentest automatizado. Ele utiliza outras ferramentas para conseguir os seus resultados.
Isso não quer dizer que ele é uma ferramenta ruim, pelo contrário. Ele utiliza as melhores ferramentas para conseguir o melhor resultado.

Este artigo tem a finalidade meramente acadêmica. Os autores desse artigo, e de qualquer outro artigo deste site, não se responsabilizam por qualquer atividade relacionada a esse material sendo executadas por qualquer pessoa. O uso indevido dessas informações podem resultar em acusações criminais interpostas contra as pessoas em questão.


Ao Som de Porcupine Tree – The Sound of Musak

Uma das maiores reclamações dos estudantes da segurança da informação, é o fato de utilizar máquinas virtuais para os estudos. Muitos acham frustante por não estar instalado em uma máquina física. Pensando nisso, foi desenvolvida uma distribuição para ser instalada em um Raspberry Pi e que é intencionalmente vulnerável. Essa distribuição é a RasPwn OS.

A distribuição RasPwn OS é baseada na distribuição Debian Wheezy. De acordo com o Github oficial, é uma distro Linux no espírito da distro “Damn Vulnerable Linux (DVL)” e usa o Raspberry Pi 2B e 3 para emular um servidor Linux vulnerável, por tanto esse é o único propósito do RasPwn OS e ele não deve ser exposto a internet, pois pode comprometer toda a sua rede interna. 

No meu caso, tenho um Raspberry Pi 3 com cartão de memória de 16 gb. É o suficiente para começar os estudos. Também é possível instalar no Raspberry Pi 2B, porém precisa de uma adaptador wifi conectado a uma das portas USB, pois não possui uma interface interna de wifi, ao contrário do Raspberry Pi 3 que já possui wifi integrado.

Meu Raspberry Pi 3... <3

Meu Raspberry Pi 3…

 

Baixei a imagem no site oficial, extrai usando o 7ZIP e fiz a cópia da ISO para o cartão utilizando o Etcher. O procedimento usado para gerar o conteúdo da imagem pode variar, não sendo uma regra.

Após esse procedimento, coloquei o cartão no slot do Raspberry e liguei a fonte na energia. Caso queira acompanhar a primeira inicialização do OS, basta colocar um monitor HDMI. O sistema reiniciará uma vez e após isso estará pronto para o uso.

 

A primeira coisa a se fazer é conectar-se o sistema operacional que você utilizará para estudar no wifi que o RasPwn criou. 
SSID: RasPwn OS
Senha: In53cur3!

Depois de conectar-se a rede wifi criada, utilize um browser e acesse o endereço: http://playground.raspwn.org/. Essa é a página principal do RasPwn OS e que dará acesso aos outros sistemas instalados no mesmo sistema. Você notará que a rede criada é a 192.168.99.0/24, assim você pode passar algum scanner de rede para testes.

A documentação oficial da distribuição informa os ips atribuídos a cada serviço:

Bind (192.168.99.1, 192.168.99.10) – DNS Server
Postfix (192.168.99.18) – Mail Transfer Agent
Dovecot (192.168.99.18) – Mail Client Server
Samba (192.168.99.10) – Windows File Sharing Server
Apache2 (192.168.99.13) – Web Server
Nginx (192.168.99.7) – Web Server
MySQL Server (127.0.0.1) – Database Server
OpenSSH (192.168.99.1) – SSH server

 

Além disso, há alguns aplicativos instalado com versões desatualizadas para as vulnerabilidades conhecidas serem exploradas:

Concrete 5.6.3.4 – http://playground.raspwn.org/concrete5/
Drupal 6.34 – http://playground.raspwn.org/drupal-6.34/
Drupal 7.34 – http://playground.raspwn.org/drupal-7.34/
Joomla 2.5.28 – http://playground.raspwn.org/joomla-2/
Joomla 3.4.0 – http://playground.raspwn.org/joomla-3/
osCommerce 2.3 – http://playground.raspwn.org/oscommerce/
phpBB 3.0.13 – http://playground.raspwn.org/phpBB3/
WordPress 3.8.1 – http://playground.raspwn.org/wordpress3/
WordPress 4.1 – http://playground.raspwn.org/wordpress4
Zen-Cart 1.5.4 – http://playground.raspwn.org/zencart
PhpMyAdmin 3.4.11 – http://playground.raspwn.org/phpmyadmin/
Samba SWAT 3.6.6 – http://playground.raspwn.org:901 (wifi adapter only)
Roundcube 0.7.2 – http://playground.raspwn.org/roundcube/

 

Há também serviços WEB para testes de vulnerabilidades:

OWASP Bricks – http://playground.raspwn.org/bricks
Damn Vulnerable Web Application (DVWA) – http://playground.raspwn.org/dvwa
OWASP Hackademic – http://playground.raspwn.org/hackademic
OWASP Mutillidae II – http://playground.raspwn.org/mutillidae
Peruggia – http://playground.raspwn.org/peruggia
WackoPicko – http://wackopicko.playground.raspwn.org (wifi adapter only)
WebGoat – http://playground.raspwn.org:8080/WebGoat (wifi adapter only)

 

Para título de exemplo, vou usar o DVWA para exemplificar a vulnerabilidade XSS (Cross-Site Scripting)

 

 

Primeiramente, vamos acessar o DVWA:

http://playground.raspwn.org/dvwa
Login: admin
Senha: password

 

 

Iremos fazer os testes com 3 níveis de segurança: Low, Medium e High.

Todos os 3 ataques abaixo são do tipo Refletido ou Não Persistente.

Vamos começar com o Low. Para fazer isso, no Menu da esquerda, basta clicar em DVWA Security.

 

Só escolher Low e depois clicar em Submit.

 

 

Agora, vamos acessar a página para testes XSS. No menu da esquerda, clicar em XSS (Reflected).

 

 

Como estamos estudando, vamos olhar o código do fonte da página para assim entender como funcionam as proteções.

 

 

Para ver o código fonte (lembre-se que não é possível ver em uma página comum da web, pois o código php será interpretado e exibido apenas o resultado HTML final), basta clicar no final da página em View Source.

 

 

Como é possível observar, não há nenhuma proteção para evitar o XSS, então podemos utilizar o XSS mais básico (afinal, a segurança está setada para Low)

 

 

No único campo que há (What’s your name?):

<script>alert(“Ataque XSS LOW”);</script>

 

 

Sucesso!

 

Agora com o nível de segurança em “Medium”. Lembre-se de mudar o nível na página de configuração.

 

 

Mais uma vez, vamos olhar o código fonte:

 

 

Agora é possível observar que no código há uma proteção para evitar que o código <script> seja interpretado. Porém, é apenas para <script>, caso utilize o mesmo texto, mas com letras maiúsculas e minúsculas, o script será interpretado. Logo, por exemplo, podemos utilizar <ScRiPt>.

 

 

<ScRiPt>alert(“Ataque XSS MEDIUM”);</sCrIpT>

 

 

Sucesso!

 

Uma outra forma é colocar o script dentro do código script. Estranha explicação, então vamos para a prática e ficará mais claro.

 

 

<scri<script>pt>alert(“Ataque XSS MEDIUM 2”);</scri<script>pt>

 

 

Sucesso!

A explicação é que com a proteção da forma que está, a string <script> será suprimida, isso fará que o texto que está “em volta” da string fica um texto só, e será novamente <script>, assim executando o código.

 

E finalmente, nível de segurança HIGH!

 

 

Novamente, olhando o código fonte, podemos perceber que o código agora está mais sofisticado, impedindo que o <script> seja executado de qualquer forma. Então, vamos tentar inserir código html.

 

 

<img src=x onError=alert(“document.cookie”);>

 

Sucesso!

Nesse exemplo, é inserido um código html de imagem, porém a imagem não existe, logo existe um tratamento para o erro que é executado quando essa condição for verdadeira, que é o caso. Assim, o código XSS é executado. Também é possível perceber que foi utilizado o parâmetro alert(document.cookie) que serve para exibir o cookie da sessão atual.

 

Depois de contemplado os 3 ataques em modo Refletido, agora em modo Persistente:

No menu da esquerda, clicar em XSS (Stored).

 

 

Em todos os exemplos, vamos colocar os códigos no campo “Name”

Começando pelo Persistente no modo LOW:

 

 

Sempre é bom olhar o código fonte para verificar se há alguma proteção.

Como é no nível LOW, não há nenhuma proteção:

 

 

Então, vamos usar o ataque básico:

<script>alert(“Ataque XSS LOW”);</script>

 

 

Pode observar que não foi possível inserir todo texto no campo Name. Logo, vamos inspecionar o elemento.

 

 

Observe que na linha destacada, há a limitação para apenas 10 caracteres . Vamos aumentar pra 100!

 

 

É possível observar que agora o código cabe todo. Agora é só executar:

 

 

Sucesso! 

Como as informações inseridas ficam no banco de dados, vamos dar um reset no banco antes de ir para o nível de segurança “Medium”

Para fazer isso, basta ir no menu do lado esquerdo e clicar em “Setup / Reset DB”.

 

 

No final da página, basta clicar em “Create / Reset Database DB”.

 

 

Ao fazer isso, os bancos serão apagados e criados novamente. Assim, podemos passar para o nível de segurança Medium.

 

 

Agora no nível “MEDIUM” e já olhando o código fonte:

 

 

Há a mesma proteção que já observamos no mesmo nível no modo Persistente, então vamos usar as mesmos scripts.

 

 

E aparentemente, também há a limitação de 10 caracteres. Então vamos mudar logo pra 100 também.

 

 

<ScRiPt>alert(“Ataque XSS MEDIUM”);</sCrIpT>

 

 

Também funciona a mesma técnica de colocar o “script” dentro de outro “script”.

 

 

<scri<script>pt>alert(“Ataque XSS MEDIUM 2”);</scri<script>pt>

 

 

Sucesso!

Agora, level “HIGH”. Não esquecer de dar reset no banco novamente.

 

 

Analisando o código fonte, também há a mesma proteção, logo vamos usar o mesmo código.

 

 

E adiantando também a limitação do campo “Name”, então vamos mudar logo pra 100 e colocar o código.

 

 

<img src=x onError=alert(“document.cookie”);>

 

 

Sucesso!

Isso é uma pequena amostra sobre o que é possível fazer com o RasPwn OS na parte de estudos. Espero trazer mais exemplos usando esse sistema, com outros sistemas e outras vulnerabilidades.

Caso queira testar com mais códigos XSS, no site GBHackers há uma lista com 500 exemplos: https://gbhackers.com/top-500-important-xss-cheat-sheet/

Espero ter ajudado e até uma próxima.

Ao som de: Rashid – Interior ft. Rapadura

 

Fontes:

http://raspwn.org/
https://github.com/alphacharlie/RasPwn
https://computersecuritystudent.com/SECURITY_TOOLS/DVWA/DVWAv107/lesson9/index.html
https://www.hackingarticles.in/xss-exploitation-dvwa-bypass-security/
http://2001594623noviani.blog.binusian.org/2018/05/27/cross-site-scripting-xss-on-dvwa/