$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. Vida útil da sessão muito longa. Um ano inteiro é muito. Se o cookie for invadido com êxito, é possível um longo acesso à conta do usuário pelo invasor.
2. Sinalizador httpOnly ausente. Se definido como TRUE, os cookies serão acessíveis apenas através do protocolo HTTP. Ou seja, neste caso, os cookies não estarão disponíveis para linguagens de script como JavaScript.
3. Sem hash de cookie.
4. Falta de definir o sinalizador seguro. O sinalizador seguro indica que um cookie deve ser enviado do cliente por uma conexão HTTPS segura. Se definido como TRUE, o cookie do cliente será enviado ao servidor somente se uma conexão segura for estabelecida.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

A primeira pergunta com a qual o questionário encontrou futuros estagiários se referia às principais e amplamente conhecidas vulnerabilidades da web. A única dificuldade aqui é a necessidade de vê-los no código fonte em PHP. No entanto, ninguém definiu a tarefa de "ocultar bugs".

Aqui está uma lista de vulnerabilidades que podem ser detectadas nesta lista em ordem de frequência de sua detecção:

O hash de senha usando o algoritmo MD5 foi observado até por candidatos distantes da web. No entanto, também havia nuances interessantes, por exemplo, muitos candidatos usavam termos muito incorretos, tentando descrever os problemas com suas próprias palavras. “Vulnerabilidades no algoritmo”, “funções unidirecionais”, “a existência de colisões” e outras mudanças estranhas entraram em batalha; após uma análise mais aprofundada, elas acabam sendo nada mais que um conjunto de grandes palavras que não revelam a essência. Obviamente, aqui fomos a uma reunião e não encontramos falhas nas pessoas que estão se preparando para embarcar no caminho para aprender a sabedoria da segurança da informação. Para obter uma "compensação", basta mencionar a ameaça, que, em caso de comprometimento do banco de dados, os hashes md5 podem ser resolvidos por um invasor em um tempo aceitável e senhas (ou seqüências de caracteres equivalentes) podem ser obtidas em texto não criptografado. E, é claro, muitos mencionaram a falta de sal e força bruta com base no uso de mesas arco-íris. Também percebemos esses comentários de maneira positiva, especialmente se o entrevistado explicou por que isso é uma ameaça.

Injeção potencial de SQL. É difícil adicionar algo; ao formar uma chamada para o banco de dados, a entrada do usuário de login e senha é concatenada diretamente com a solicitação. Se for improvável que você possa manipular o valor da senha nesse estágio (um hash é retirado dele), a introdução de uma injeção no nome de usuário não será difícil para um invasor em potencial.

Saída de informações de depuração desnecessárias que levam a um ataque XSS. Ao ler atentamente a listagem, é possível prestar atenção à chamada de eco, que exibe a solicitação gerada para o banco de dados nos comentários HTML da página. Obviamente, essa conclusão de informações adicionais para a página é completamente opcional e, provavelmente, simplesmente esquecida pelo desenvolvedor após a realização dos testes. Essas informações adicionais são muito benéficas para o invasor e permitem uma compreensão muito melhor de como o aplicativo funciona. Infelizmente, porém, isso é apenas metade do problema. O fato é que um invasor pode manipular o conteúdo da variável de consulta e seu conteúdo não pode ser filtrado ou escapado antes de ser exibido ao usuário - há um possível ataque XSS. No entanto, sua exploração pode acabar sendo uma dor de cabeça devido à função do strtoupper mal localizada. O vetor injetado pelo invasor será maiúsculo e, se isso não for um problema para as tags HTML, o Javascript ficará muito ofendido com essa apelação. Isso pode ser verificado facilmente usando o console do navegador.



Bem, pelo menos, aparentemente, o invasor terá que recorrer aos chamados "ataques sem script" ou técnicas sofisticadas para ignorar a filtragem (nesse caso, o JSFUCK faria), para que o fato de um risco à segurança não cancele isso.

Um erro na lógica do mecanismo de gerenciamento de sessões foi a parte mais interessante da tarefa. Sua descoberta exigia não apenas ler a fonte linha por linha, mas também entender a lógica de toda a listagem. Pode-se sentir que algo está errado observando a configuração de um cookie contendo o ID do usuário codificado em base64 no bloco de lembrete-me. Uma análise mais aprofundada da lógica desse mecanismo nos leva ao pensamento: “Acontece que um invasor que conhece ou passa pelo ID pode fazer login em qualquer conta sem inserir um nome de usuário e senha?!”. Sim, de fato, um invasor pode gerar independentemente um usuário de cookie do seu lado e atribuir a ele qualquer valor de ID codificado por base64. O envio de uma solicitação com esse cookie sem nome de usuário e senha acionaria a função do_login e efetuaria login na conta de outra pessoa.

A menção dessas 4 vulnerabilidades na resposta dos candidatos influenciou diretamente suas pontuações.

No entanto, muito dependia da qualidade da resposta. Mencionar maneiras de corrigir a situação, observações sobre fatores adicionais que afetam a viabilidade de um ataque, o uso dos termos certos e a capacidade de estruturar seus pensamentos, comentários sobre fraquezas adicionais ou ameaças em potencial - tudo isso aqueceu nossos corações e levou a um aumento na classificação final.

No trabalho do auditor, muitas vezes é necessário lidar com novas tecnologias, e a capacidade de entendê-las é muito importante. Incluindo essa pergunta no questionário, assumimos que a maioria dos candidatos mal ouvia falar da tecnologia dos tokens JWT, exceto pelo nome. Portanto, essa questão, em primeiro lugar, visava a capacidade de pesquisar e analisar informações de fontes públicas. Como resultado, uma pessoa que perdeu a emissão do Google a pedido de "JWT" ​​e "jwt vulnerability" pode chegar às seguintes conclusões:

1. Esse token não possui um algoritmo de assinatura; portanto, um invasor pode modificar qualquer campo dentro do token, o que não é assumido pelo conceito de tokens JWT.

2. Os campos dentro do token contêm a senha do usuário em texto não criptografado; armazenar essas informações no token é, no mínimo, uma má prática. Na maioria dos casos, você pode recusar tal decisão e, assim, aumentar seu nível de segurança.

3. Lembrando a falta de uma assinatura e nossa capacidade de modificar os campos dentro do token, é lógico supor que alterar o valor de isAdmin possa aumentar nossos privilégios para privilégios de administrador.

4. Outra idéia interessante que poucas pessoas mencionadas em sua resposta se refere ao fato da capacidade de transferir entrada do usuário nos campos de um token JWT. Em uma situação normal, um invasor não pode influenciar os dados no token de forma alguma, o que significa que os desenvolvedores geralmente podem negligenciar a introdução de verificações adicionais no código dos manipuladores. Isso sugere a idéia simples: mas vamos tentar realizar ataques clássicos não através dos parâmetros GET / POST, mas através de campos de token. Isso pode dar um resultado inesperadamente bom. Essa abordagem criativa, com a justificativa correta de nossas ações, foi muito apreciada por nós na avaliação de ambos, este e outros assuntos.

Muitos candidatos em suas respostas organizaram uma breve recontagem de como o token JWT é estruturado e, onde é usado, foi interessante ler e, no entanto, antes de tudo, avaliamos os aspectos da resposta em relação à segurança.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

Vamos considerar, em ordem, quais são os principais problemas visíveis nas consultas fornecidas:

1) De fato, como o identificador numérico do usuário "10012" é observado na solicitação, o primeiro passo é verificar se é possível alterar a senha de outro usuário? Posso especificar o ID de outra pessoa o suficiente?
As vulnerabilidades da classe IDOR são bastante fáceis de explorar e geralmente têm alta criticidade.

2) A solicitação para alterar a senha ocorre pelo método POST, o token CSRF não é observado e o tipo de conteúdo é “texto / sem formatação”. Existe a possibilidade de falsificar uma solicitação.

Conseqüentemente, para alterar a senha da vítima, basta que o invasor os convença a visitar o link "malicioso".

3) Nos cabeçalhos de resposta, o servidor revela a versão do software usado . Isso pode ser chamado de vulnerabilidade, mas é melhor esconder esses banners - os invasores podem encontrar facilmente as explorações conhecidas de 1 dia neles, além do valor do software usado simplificar bastante o planejamento de novos ataques.

4) Teremos o maior prazer em ver a frase "O que acontecerá se mudarmos o formato dos dados de JSON para XML ?"

O fato é que as estruturas modernas são inteligentes, onívoras e podem processar dados em diferentes formatos. E ao analisar XML, muitas vezes é permitida uma vulnerabilidade XXE perigosa. Com sua ajuda, o invasor pode "ir" para a rede interna, pode ler arquivos de configuração do servidor e, ocasionalmente, executar o RCE.

5) Eu também queria ver um comentário como "Por que o conhecimento do antigo não é verificado ao alterar a senha?"

Quanto à “Variante nº 2”, há uma “armadilha” nela - os cabeçalhos CORS são usados ​​aqui e o Tipo de Conteúdo da solicitação já está definido como “application / json”.

O erro que a grande maioria dos candidatos cometeu é a resposta do formulário "-Este é o asterisco em Allow-Origin, o que significa que você pode enviar solicitações de qualquer site!"

Não, você não pode. Primeiro, o cabeçalho Allow-Credentials: True está ausente, o que significa que o navegador deve executar a solicitação "com cookies", para que a solicitação seja anônima, sem uma sessão. E segundo, mesmo que esse cabeçalho estivesse presente, o navegador ainda proibiria o envio de cookies - apenas por causa do "asterisco". A combinação deles é proibida e o navegador é ignorado.

O objetivo da pergunta era determinar a familiaridade do estagiário com técnicas modernas (e não tão) para conduzir ataques do MitM. Vejamos os cenários possíveis com base em um despejo de tráfego existente:

1) falsificação de ARP
A falsificação de ARP é a maneira mais antiga e fácil de implementar ataques MitM. Consiste no envio de uma solicitação ARP gratuita ao host A.

O endereço IP do host B é o endereço IP e nosso endereço MAC é o endereço MAC. Essa solicitação permite modificar a tabela ARP no host A, forçando-o a enviar solicitações ao nosso dispositivo ao tentar entrar em contato com o host B. O host B geralmente é o gateway padrão.

Ferramentas recomendadas: bettercap, arpspoof

2) LLMNR, falsificação de NBNS
Resolução de nome de difusão seletiva local e serviço de nome NetBIOS são os protocolos usados ​​para resolver nomes de host na rede local. Diferentemente do protocolo DNS, não há servidor dedicado que armazena todas as informações; em vez disso, a solicitação é transmitida a todos os hosts da rede; se o nome do host na solicitação corresponder ao nome do host do dispositivo, ele enviará uma resposta.

Como foi observado corretamente na resposta, o invasor pode responder a essas solicitações enviando seu endereço IP na resposta, o que levará ao fato de que, no futuro, a vítima entrará em contato com o dispositivo do invasor, em vez do dispositivo cujo nome de host apareceu na solicitação. Além disso, um invasor pode solicitar autenticação NTLM da vítima, o que faz com que o dispositivo vítima envie um hash NTLM, que pode ser usado ainda mais para força bruta.

Ferramentas recomendadas: Respondente

3) falsificação de WPAD
A falsificação WPAD pode ser atribuída a um caso especial de falsificação LLMNR e NBNS. O protocolo de detecção automática de proxy da Web é usado para configurar automaticamente um servidor proxy HTTP.

O dispositivo envia uma solicitação LLMNR / NBNS com o nome do host wpad, recebe o endereço IP correspondente e tenta acessar o arquivo wpad.dat via HTTP, que armazena informações sobre as configurações de proxy.

Como resultado, um invasor pode executar falsificação de LLMNR / NBNS e fornecer à vítima seu arquivo wpad.dat; como resultado, todo o tráfego HTTP e HTTPS passará pelo invasor.

Ferramentas recomendadas: Responder, mitm6

4) Anúncio do roteador
Como você pode ver no dump, existem dispositivos com IPv6 habilitado na rede. Enquanto estiver na rede, você pode tentar enviar mensagens para o anúncio do roteador IPv6 da vítima para alterar o gateway ou o servidor DNS padrão.

As mensagens de anúncio de roteador (RA) fazem parte do mecanismo SLAAC (Stateless Address Autoconfiguration), necessário para obter automaticamente endereços IPv6 em uma rede, sem usar um servidor DHCPv6 ou em conjunto com ele. Isso é feito enviando periodicamente mensagens de multicast RA para o roteador, que contém o endereço de gateway padrão, o prefixo da rede, o endereço do servidor DNS, o prefixo do domínio.

Ferramentas recomendadas: pacote bruto

5) falsificação de DHCP
Além disso, em um despejo, as solicitações de descoberta de DHCP do mesmo dispositivo são repetidas em alguns intervalos. Podemos concluir que não há servidor DHCP nesta rede e responder à próxima solicitação de descoberta, indicando a vítima como um gateway padrão para o dispositivo.

Ferramentas recomendadas: Yersinia

6) falsificação de HSRP
Além disso, os pacotes HSRP podem ser vistos no dump. O protocolo Hot Standby Router pode aumentar a disponibilidade de roteadores que atuam como o gateway padrão. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . ! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

Exemplo

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . Mas , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)