You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
william 30a0637a75 Delete 'client-side-attack/README.md' 4 years ago
client-side-attack Delete 'client-side-attack/README.md' 4 years ago
demos adding original attack test scripts and demos 4 years ago
ethical-disclosures-and-CVEs Upload files to 'ethical-disclosures-and-CVEs' 4 years ago
pcaps adding original attack test scripts and demos 4 years ago
results adding original attack test scripts and demos 4 years ago
server-side-attack adding original attack test scripts and demos 4 years ago
vendor-patches Adding uncompressed vendor and disclosure info 4 years ago
virtual-test-environment adding original attack test scripts and demos 4 years ago
README.md adding original attack test scripts and demos 4 years ago
old-readme adding original attack test scripts and demos 4 years ago

README.md

vpn-attacks

Attack Machine Environment

Server-side attack

Requirements

  • VPN client connected to a VPN server
  • Attack machine sitting somewhere in between VPN server and client forwarding all traffic between the two

Note: Full virtual test environment setup for the server-side attack is detailed in the README within the virt-lab folder

Running the DNS Attack Script

  1. Change to udp-dns attack folder - cd other-end-attack/dnuss/full_scan
  2. Compile attack script - make
  3. Check to make sure vpn server has a conntrack entry for some vpn client's dns lookup (on vpn-server vm): sudo conntrack -L | grep udp
  4. Try to inject from attack router - sudo ./uud_send <dns_server_ip> <src_port (53)> <vpn_server_ip> <start_port> <end_port>

Client-side attack

Requirements

  • VPN client connected to a VPN server
  • Reverse path filtering disabled on the VPN client machine
  • Attack router acting as the local network gateway for the victim (VPN client) machine

Running the Full Attack Script

  • Rebuild all the attack scripts: ./rebuild_all.sh
  • cd full_attack
  • Change attack.sh vars to appropriate values
  • sh attack.sh <remote_ip>

Note: remote_ip specifies the IP address of the HTTP site.

Testing Indivual attack phases

Phase 1 - Infer victim's private address
  • cd first_phase
  • python3 send.py <victim_public_ip> <private_ip_range>

Note: private_ip_range specifies a /24 network such as 10.7.7.0.

Phase 2 - Infer the port being used to talk to some remote address
  • cd sec_phase
  • Edit send.cpp to use the correct MAC addresses
  • g++ send.cpp -o send -ltins
  • ./send <remote_ip> <remote_port> <victim_wlan_ip> <victim_priv_ip>

Note: <remote_ip> is the address we wanna check if the client is connected to and the <remote_port> is almost always 80 or 443. The <victim_wlan_ip> is the public address of the victim and <victim_priv_ip> was found in phase 1. If the scripts not sniffing any challenge acks, then edit the send.cpp file to uncomment the cout line that prints out the remainder to check if the size of the encrypted packets has slightly changed on this system.

Phase 3 - Infer exact sequence number and in-window ack
  • cd third_phase
  • Edit send.cpp to use the correct MAC addresses
  • g++ send.cpp -o send -ltins
  • ./send <remote_ip> <remote_port> <victim_wlan_ip> <victim_priv_ip> <victim_port>

Note: <victim_port> was found in phase 2. This script currently just injects a hardcoded string into the TCP connnection but could be easily modified.