Entenda melhor o HTTP CORS



O que é CORS ou Cross-Origin-Resource Sharing

Primeiramente, vamos entender o significado de uma origem (origin), que provém do Same Origin Policy.

Dois sites são considerados 'same origin' se eles têm em comum:

- hostname;
- protocolo http, https;
- se trabalham na mesma porta (80, 8080, 7001...).

Por exemplo, 
http://www.siteblindado.com e http://www.siteblindado.com/labs possuem a mesma origem.
Entretanto, http://www.siteblindado.com:7001 e http://www.siteblindado.com:8080 possuem origens distintas.

O Same Origin Policy restringe como um script de uma origem pode interagir com o conteúdo de uma outra origem. É um mecanismo de segurança para que os browsers diminuam as ações de scripts maliciosos. 

Tendo em vista o cenário acima, quando uma aplicação web consegue ler os dados de uma outra aplicação, estamos falando de CORS.
Sendo assim, essa especificação permite uma comunicação cross-domain, através do browser. Essa feature é possível ao adicionar no HTTP Headers as origens que são permitidas para o cross-domain. Ou seja, o CORS serve para flexibilizar o Same Origin Policy.
Ainda, vale ressaltar que CORS é muito utilizado, especialmente em APIs.

Na configuração dos Headers, o Origin fica responsável por validar se a request tem a origem do domínio correto. 

O Access-Control-Allow-Origin fica responsável por validar se o 'response' é permitido ou não. Caso seja ‘setado’ de forma indevida, torna a aplicação vulnerável. 

E o que a torna vulnerável?

Misconfiguration (Top 10 Owasp), a configuração incorreta da feature faz com que a mesma fique vulnerável. O erro mais comum é "setar" os domínios permitidos com um wildcard (*). Exemplo:

GET /api/labs.php
Host: 
www.siteblindado.com
Origin: 
www.siteblindado.com

Quando enviado a request acima, é obtido o response com o header Access-Control-Allow-Origin:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true


Quando o header é mal configurado, como a inserção de um wildcard, permite que qualquer domínio tenha acessos aos dados da aplicação.
A partir do momento que qualquer aplicação pode obter dados da aplicação mal configurada, é possível explorar e obter informações privilegiadas ao enviar o 'response' para uma outra aplicação ou server que o invasor desejar. 

Outra possibilidade de exploração, (caso a aplicação tenha sido configurada com o CORS para aceitar apenas o domínio 
teste.com, quando feito o request pelo atacante) seria da seguinte forma: 

GET /api/labs.php
Host: 
siteblindado.com
Connectrion: Close
Origin: 
atacanteteste.com

O response seria: 

HTTP/ 1.1 200 OK
Access-Control-Allow-Origin: 
atacanteteste.com
Access-Control-Allow-Credentials: True


Este erro ocorre, pois possivelmente o back-end foi mal configurado, aceitando “*
teste.com”, ou seja, toda origem que termina em 'teste.com' será validada e o request será aceito. 

Como evitar? 

O melhor método para diminuir riscos é apostar na configuração correta de acordo com suas aplicações.
Caso a aplicação não seja de acesso para conteúdo público, por exemplo, nunca configure o Access-Control-Allow-Origin com um wildcard (*).

Utilize outros headers para uma melhor política de segurança, como a combinação do Access-Control-Allow-Origin, Access-Control-Allow-Credentials e Access-Control-Allow-Methods, para validar e requerer credencias e métodos (GET, POST, DELETE, PUT) que a aplicação no cross-domain poderá utilizar.

Conclusão

Por mais que seja 'apenas' um header, o CORS pode tornar sua aplicação vulnerável a ataques críticos. A combinação com outros headers mal configurados pode, ainda, permitir exposição de dados da aplicação da API e, inclusive, em um RCE.
Mas a aprofundação destes tópicos a gente deixa para os próximos posts. Neste artigo, fica o alerta para que os desenvolvedores realizem a configuração correta da aplicação como um todo.

Referencias

https://www.pivotpointsecurity.com/blog/cross-origin-resource-sharing-security/

https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)

https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Controle_Acesso_CORS





Testando WebSocket



Segundo a OWASP, WebSockets HTML5 permite que o cliente/servidor criem canais Full-duplex (bidirecionais), possibilitando uma comunicação assíncrona independente da atualização da página após um handshake inicial HTTP.
Plataformas que precisam de comunicação rápida costumam utilizar este meio para envio e recebimento de requisições específicas.
O protocolo possui algumas características bem conhecidas que podem ser exploradas causando algum tipo de transtorno.
Entre elas, o servidor não valida o cabeçalho da origem das requisições, portanto o servidor aceitará comunicação vinda de qualquer lugar possibilitando um ataque de CSRF, por exemplo.
Quando um canal não seguro é utilizado, um atacante pode interceptar a comunicação em texto claro e realizar as requests de seu próprio computador. É importante reconhecer na primeira etapa do teste se a comunicação está utilizando um canal seguro (wss://).
Uma terceira característica encontrada no protocolo é a possibilidade de abertura de inúmeras conexões viabilizando um ataque de negação de serviço.
Existem programas e extensões de browser conhecidos para captura e leitura dos dados de comunicação que utilizam Web Sockets.
As mitigações de tais características são simples, mas requerem atenção. A validação da origem da requisição, utilizar um canal de seguro de comunicação e limitar uma quantidade de conexões por IP são boas práticas que podem ser implementadas para contornar os problemas apresentados.
Conclusão:
Fique ligado ao executar testes de invasão em sites que utilizam esta tecnologia. Se entre interações com a aplicação não são realizadas requisições HTTP, é possível que esteja utilizando WebSockets para troca de informações. Entender como é feito e se inicia o processo de comunicação é um passo essencial para os testes. A partir daí, basta interceptar as requisições e testá-las de acordo com o escopo de cada chamada. O entendimento do funcionamento deste recurso não é difícil, mas seu uso não costuma ser muito difundido.
Você já usou Websocket em alguma aplicação? Já testou alguma aplicação que utiliza este recurso? Conta pra gente.
Fontes:
https://www.owasp.org/index.php/Testing_WebSockets_(OTG-CLIENT-010)
https://www.blackhillsinfosec.com/how-to-hack-websockets-and-socket-io/
https://www.virtuesecurity.com/pentesting-websockets/
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications 

Desmistificando a Deep Web – Um guia básico



A Mariana’s Web, conhecida vulgarmente também como “Deep Web”, refere-se a todas as partes da internet que não podem ser indexadas pelos motores de busca convencionais. Por conseguinte, a Deep Web inclui dados contidos em data base privados, estudos acadêmicos, sites de acesso restrito, fóruns, etc.
Muitos usuários utilizam a Deep Web para trocar informações e documentar dados importantes anonimamente, sendo uma incrível ferramenta para dar voz a todos. É utilizado também por aqueles que lutam contra regimes ditatoriais, empregados insatisfeitos, vítimas que queiram denunciar seus algozes, entre outros.
Porém, isso abre margem também para usuários que queiram cometer atos ilícitos, como venda de drogas, armas, tráfico humano e pedofilia.
As pessoas normalmente tratam a Deep Web por termologias errôneas, como tendo “camadas”, quando isso não é uma verdade. A Deep Web é na verdade organizada através de redes totalmente independentes entre si, por exemplo, as redes ONION (Tor), Freenet, I2P, Hyperboria, Retroshare, Hybridshare, JAP, Clos, Galet, Zeronet, Psiphon, Oneswarm, Osíris, Ants, etc.
A mais básica de ser acessada é a rede .onion (Tor). Para acessá-la, basta conectar-se ao TOR, colocar algum link e navegar. Para acessar a i2p, por exemplo, é necessário que haja algumas configurações de IP, o que requer um nível intermediário de conhecimento do usuário. Outro exemplo é a rede .clos, que exige um nível avançado do usuário para ser acessada, sendo necessário até o uso de keys para acessar certos sites.
Neste artigo iremos tratar somente da rede Onion (tor) para reduzir o escopo. Esta rede é um ótimo princípio para se visualizar as possibilidades e perigos existentes dentro da Deep Web.


O QUE É E COMO FUNCIONA O TOR?

O Tor é uma ferramenta de código aberto que tem como objetivo fornecer anonimato e privacidade para aqueles que utilizam a internet. O seu proposito é impedir que algum órgão ou, alguém, saiba identificar quais sites um usuário está visitando, além de prevenir que os sites identifiquem o seu utilizador. Alguns usuários valorizam o anonimato do Tor por tornar mais difícil para que governos censurem sites ou conteúdos que podem estar hospedados em outros lugares do mundo.

Os voluntários do Tor executam milhares de "relays" para o projeto Tor. "Relay" é um servidor que permite que qualquer outro usuário possa fazer requisições de rotas de acesso para trafegar através delas.



A figura acima ilustra o caso simples de um único relay, com três utilizadores lhe pedindo para encaminhar o tráfego para três sites. Um observador pode ver o tráfego entrando e saindo do relay, mas não pode determinar qual é o usuário que está visitando qual site e porque o tráfego é criptografado. No entanto, se o operador é um relay malicioso, eles podem trivialmente (com facilidade, a partir de uma técnica de ponto de vista) ligar os dois.
Quando um usuário visita um site através de um relay, o seu tráfego parece vir dele em vez de mostrar a real localização do usuário. Assim, o usuário permanece anônimo ao site em si.

Para se defender contra um operador de relay malicioso, o usuário escolhe três deles e encadeia os três juntos. Eles são rotulados como Guard, Middle e exit, conhecido também como circuito threehop (veja a Figura 2). Isso faz com que um ataque se torne significativamente trabalhoso, pois um atacante precisa controlar todos os três relays para ser capaz de ligar os utilizadores utilizando o Tor aos locais de onde estão visitando os sites. O atacante é incapaz de influenciar a escolha/decisão dos relays feita pelo browser do usuário. A única opção de um atacante seria, portanto, controlar um número significativo de relays na esperança de que o sistema do usuário escolha três dentro de seu escopo de controle, e isto é pensado para ser impraticável.



Serviços ocultos - Hidden Services

Embora a capacidade de acessar a Internet anonimamente seja valiosa em países onde as liberdades pessoais são restritas, isso é apenas uma das características do Tor. A outra característica importante são os "serviços ocultos" (Hidden services - HSES), a capacidade de hospedar um site (ou de serviços de Internet) de forma anônima.
Dentro deste caso, tanto o visitante quanto o site são anônimos entre si. Usando esse recurso, blogs políticos ou fóruns podem ser hospedados em regimes repressivos, sem medo de punição. Tal como acontece com qualquer outra tecnologia, tal como esta, a rede Tor também permite a possibilidade de material orientado criminalmente a ser hospedado com um grau significativo de impunidade. A coleção de Tor HSES é muitas vezes referida como a Dark net, embora existam outras ferramentas menos populares, que também podem ser considerados no mesmo foco (por exemplo, a Internet Invisible Projeto, conhecido como I2P).
É crucial saber como serviços ocultos trabalham para ser capaz de entender a metodologia utilizada na medição da atividade na Dark Net. Vamos supor que João está hospedando um HS e Maria deseja visitar o seu site. Quando João primeiro cria seu site, ele constrói um documento detalhando os "pontos de introdução", ou relays dentro da rede que poderão retransmitir mensagens para ele. Ele publica este documento em uma tabela hash distribuída (DHT), que pode ser pensada como um diretório de banco de dados distribuídos por todos os relays na rede, ou seja, não há controles de relays simples ou possui todas as DHT em qualquer tempo em que for acessado. Para criar essa base de dados, todos os relays da rede são colocados em um círculo e ordenados de acordo com um identificador único (Veja a Figura 3, os relays são rotulados como h). O Hidden Service é então mapeado no círculo em dois pontos. João publica informações sobre sua introdução e aponta para os três relay para cada um destes locais, de modo que existem cópias em exatamente seis relays. Ao publicar a informação, ele usa um circuito de três hops “pulos” para permanecer anônimo aos diretórios de retransmissão dos relays.



O local em que João publica neste diretório aparecem aleatórios, se alterando todos os dias, mas é possível para Maria descobrir suas informações. A localização muda diariamente para tornar mais difícil para uma pessoa para controlar os relays que detêm informações do João.
Maria, então, calcula quais relays no circuito contêm as informações de João e constrói o circuito de “três de salto” three-hop para os relays, solicitando uma cópia de sua informação. Ao utilizar um circuito three-hop, ele permanece anônimo para os diretórios dos relays. Ela agora tem informações sobre a introdução de João, que aponta e transmite uma mensagem a um deles para pedir a João para construir uma conexão para um relay de encontro que ela escolhe. O relay encontra e passa a retransmitir a mensagens entre João e Maria, e uma vez que ambos têm uma conexão, o relay de encontro através de circuitos de three-hop, o relay não sabe a identidade de qualquer uma das partes. O “relay de encontro” não pode inspecionar o tráfego, porque ele é criptografado.

Utilizações úteis na Deep Web
Com os casos recentes de representação na mídia mainstream, somente as más utilizações da Deep Web são documentadas. Neste artigo, também quero exaltar as utilizações positivas da rede:


  • Megabancos de dados multi-URL que são muito grandes para os mecanismos de pesquisa indexarem corretamente.

  • Páginas de acesso temporizadas. Isso pode incluir a página da Web interna para um teste que você está realizando em um curso on-line.

  • Sites protegidos por senha e somente para membros.

  • Registros, certificados, diretórios de nomes, índices de bibliotecas, etc.

  • Conteúdo de mídia digital bloqueado em um paywall. As organizações de notícias usam isso como parte de seu modelo de receita para incentivar leitores/espectadores a se inscrever e pagar por reportagens jornalísticas.

  • O painel de back-end de qualquer tipo de conta individual, seja bancário, plataformas sociais, serviços de e-mail, etc. Isso só está disponível depois que uma conta é conectada e acessada. Em seguida, a URL é alterada para um endereço particular de acordo.

  • Comunicações de usuário a usuário de duas partes ou segmentos nas redes sociais, serviços de bate-papo, plataformas de mensagens, etc.

Principais grupos (não criminosos) que se beneficiam dos recursos de comunicações criptografadas na Deep Web

Denunciantes e jornalistas

Agente de inteligência nacional, funcionários do governo, funcionários corporativos, cidadãos comuns, ex-espiões, membros das forças armadas… são todos os tipos de indivíduos que, sob a máscara do anonimato, podem comunicar informações confidenciais aos jornalistas para expor as irregularidades. Denunciantes imprevisíveis como Edward Snowden e Chelsea Manning usaram essa rota para compartilhar documentos confidenciais e expor atos duvidosos de seus governos/contratantes.

Defensores da liberdade de expressão e anti-censura e manifestantes políticos

Qualquer um que procure fugir da vigilância do governo (que, em muitos casos, poderia mais tarde ser usado para oprimir a liberdade de expressão) encontra na Deep Web um bom lugar para se comunicar anonimamente.

Cidadãos em locais com regimes opressores que precisam de acesso a notícias e informações que não conseguem em seu país

A Deep Web também é composta por sites e serviços que são especificamente reunidos para acesso em locais onde informações são bloqueadas. Isso significa que eles são acessíveis através do Tor ou em outras redes obscuras.
Para mais informações, no final do artigo, seguem vários links de referência para um estudo mais aprofundado sobre o tema.


Boas praticas para a utilização da rede Onion (TOR)

Nesta parte do artigo, demonstramos algumas boas práticas para a utilização da rede TOR.



1.    Primeira regra: tenha consciência do que você está fazendo
Caso você queira fazer parte de algum fórum ou qualquer outro método de discussão dentro da Deep Web, mantenha sempre o anonimato. Evite utilizar a mesma conexão para acessar outros sites que não sejam somente os da Deep Web. Por mais que acessar a rede onion seja algo relativamente fácil e não tão perigoso quanto é dito por ai, a melhor ferramenta de segurança que possuímos é a consciência do que estamos fazendo. Bloqueie a execução automática de javascript (isso já vem configurado por default no browser Tor) e não baixe nada sem antes fazer uma verificação detalhada, aliás, evite fazer download na Deep Web.

2.    Segunda regra: utilize uma máquina virtual
Faça o uso de máquinas virtuais para que você consiga ter um melhor controle de um ambiente controlado.
Programas aconselhados:
·         Oracle VM VirtualBox – download: https://www.virtualbox.org/wiki/Downloads
·         Vmware - download: https://my.vmware.com/web/vmware/downloads
·         Qubes OS - https://www.qubes-os.org/downloads/

3.    Terceira regra: utilize sistemas operacionais em modo “live
Aconselho você a utilizar um sistema operacional Linux que tenha um modo live de operação. Como estou fazendo este documento para uma equipe com direcionamento para segurança, recomendo que algum dos sistemas operacionais abaixo sejam usados:
·         Kali Linux – download: https://www.kali.org/downloads/
·         Parrot Os – download: https://www.parrotsec.org/download-home.php
·         Tails OS – download: https://tails.boum.org/index.en.html

4.    Quarta regra: utilize o Tor
Os links .onion são acessíveis em qualquer browser, basta somente adicionar um .link após a terminação onion. Porém, sem o TOR você perde toda a sua anonimidade ao acessar estes sites.
Caso o seu sistema Linux não venha com o TOR por default, faça o download do mesmo e realize a sua instalação.
O TOR está disponível também para Microsoft Windows, Apple OS X e até mesmo para Android.

5.    Quinta regra: utilize a placa de rede em modo NIC (opcional)
Esta regra é opcional, porém recomendada para quem é extremamente precavido. Por padrão, a tradução de endereços de rede (NAT) é configurada pelo software de virtualização (VM) de tal forma que o OS instalado partilha um endereço IP com o host. Efetivamente, isto significa que os dois compartilham uma conexão com a internet e os pacotes podem ser interceptados, em ambos os sentidos e em ambas as máquinas. Além disso, com esta configuração padrão, um malware pode comprometer os drivers do software de virtualização e aumentar a superfície de ataque também. A melhor maneira de evitar isso é utilizar uma conexão NIC (sic), ou seja, usar um cartão de interface de rede dedicada em seu sistema operacional rodando na VM. Em termos leigos: utilize um adaptador WiFi e configure no VirtualBox para conectá-lo à sua máquina virtual. Para segurança adicional, altere o endereço MAC do seu NIC dedicado (agora controlado pelo OS no VM). Estas medidas devem assegurar que o tráfego entre o sistema operacional host e o sistema operacional convidado nunca se misturem.

Conclusão
Para finalizar, queremos deixar claro que a Deep Web é um lugar fascinante para qualquer pessoa da internet. Ela pode oferecer todo tipo de conhecimento, registros, dados e conteúdo que uma pessoa poderia passar dias pesquisando. Pode levar alguns passos para percorrer os vários links e caminhos virtuais para encontrar os temas que você está procurando, mas isso faz parte da diversão.
A Deep Web pode ser uma ferramenta maravilhosa e extremamente poderosa, pois conhecimento é poder. Se você está pronto para a tarefa, pode encontrar as respostas que está procurando em suas profundezas. Basta fazer as perguntas certas!


Referências:

XML eXternal Entity (XXE)


O Ataque XXE é um tipo específico de Server-Side Request Forgery (SSRF) e acontece quando uma request utilizando XML é tratada de forma insegura, possibilitando assim a queda do serviço e/ou o acesso direto aos arquivos e informações do servidor, entre outros impactos. Isso acontece quando a informação recebida pelo servidor, contendo referência a uma entidade externa, é processada de forma insegura.
Uma das formas mais comuns de exploração é o caso de campos de upload de arquivo, em que o arquivo importado tem efeito direto na aplicação. É importante ressaltar que arquivos com outras extensões como docx, pptx, pdf, entre outros, também possuem dados em XML em sua construção. Logo, o ataque não se limita apenas à passagem simples de dados em XML nas request ou apenas a arquivos de extensão .xml.
Uma das características do XML é permitir que o desenvolvedor referencie dados armazenados local ou remotamente a um dado endereço.
Os códigos abaixo, por exemplo, possibilitam o acesso ao arquivo passwd e lsb-release respectivamente.
      <?xml version="1.0" encoding="ISO-8859-1"?>
      <!DOCTYPE foo [
       <!ELEMENT foo ANY >
       <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

POST http://example.com/xml HTTP/1.1

      <!DOCTYPE foo [
      <!ELEMENT foo ANY>
      <!ENTITY bar SYSTEM "file:///etc/lsb-release">
]>
<foo>
&bar;
</foo>

O modo mais seguro de prevenir o XXE é desabilitando o seu uso completamente. Quando não é possível desabilitar o recurso, entidades externas e declarações de tipo de documento externo devem ser desativadas de maneira específica para cada parser.

Tratativas:
Em alguns casos, a tratativa não é tão simples, devido a problemas nas bibliotecas que realizam o parse do XML.
Em códigos PHP, por exemplo, habilitar a libxml_disable_entity_loader mitiga este tipo de problema.
Aplicações em Java que utilizam bibliotecas XML costumam ser vulneráveis por possibilitarem de forma padrão o uso de entidades externas. É necessário desativá-las.
Em C/C++, para a biblioteca libxml2, as opções XML_PARSE_NOENT e XML_PARSE_DTDLOAD não devem ser definidas.
Para estas e outras opções de mitigações em outras linguagens, recomendamos a leitura da OWASP: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

Conclusão
A vulnerabilidade apresentada é simples, mas seu risco é muito alto. Hoje, muitas bibliotecas que utilizam XML para leitura de dados já possuem seus meios de mitigação, mas ainda assim, desenvolvedores desavisados podem deixar passar este recurso e possibilitar sua exploração.

Referências
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet
https://www.infosec.com.br/xml-external-entity/
https://www.acunetix.com/blog/articles/xml-external-entity-xxe-vulnerabilities/
https://resources.infosecinstitute.com/xxe-attacks/#gref
https://www.bugcrowd.com/advice-from-a-bug-hunter-xxe/
https://depthsecurity.com/blog/exploitation-xml-external-entity-xxe-injection