Breakpointing-Bad-Public
/
vpn-attacks
7
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
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.
9 Commits
1 Branch
0 Tags
530 MiB
Tree: 5882c33314
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5882c33314'
${ noResults }
vpn-attacks/old-readme

83 lines
2.7 KiB
Raw Normal View History

adding original attack test scripts and demos
3 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
  1. # VeepExploit
  3. The current version of VPN attack code
  7. ##### Attack Machine Environment
  9. * C++
  10. * libtins (http://libtins.github.io/download/)
  13. ## Server-side attack
  16. #### Requirements
  18. * VPN client connected to a VPN server
  19. * Attack machine sitting somewhere in between VPN server and client forwarding all traffic between the two
  21. ***Note:*** Full virtual test environment setup for the server-side attack is detailed in the README within the `virt-lab` folder
  24. #### Running the DNS Attack Script
  26. 1. Change to udp-dns attack folder - `cd other-end-attack/dnuss/full_scan`
  27. 2. Compile attack script - `make`
  28. 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`
  29. 3. Try to inject from attack router - `sudo ./uud_send <dns_server_ip> <src_port (53)> <vpn_server_ip> <start_port> <end_port>`
  33. ## Client-side attack
  36. #### Requirements
  38. * VPN client connected to a VPN server
  39. * Reverse path filtering disabled on the VPN client machine
  40. * Attack router acting as the local network gateway for the victim (VPN client) machine
  43. #### Running the Full Attack Script
  45. * Rebuild all the attack scripts: `./rebuild_all.sh`
  46. * `cd full_attack`
  47. * Change `attack.sh` vars to appropriate values
  48. * `sh attack.sh <remote_ip>`
  50. ***Note:*** `remote_ip` specifies the IP address of the HTTP site.
  53. #### Testing Indivual attack phases
  56. ##### Phase 1 - Infer victim's private address
  58. * `cd first_phase`
  59. * `python3 send.py <victim_public_ip> <private_ip_range>`
  61. ***Note:*** `private_ip_range` specifies a `/24` network such as `10.7.7.0`.
  64. ##### Phase 2 - Infer the port being used to talk to some remote address
  66. * `cd sec_phase`
  67. * Edit `send.cpp` to use the correct MAC addresses
  68. * `g++ send.cpp -o send -ltins`
  69. * `./send <remote_ip> <remote_port> <victim_wlan_ip> <victim_priv_ip>`
  71. ***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.
  74. ##### Phase 3 - Infer exact sequence number and in-window ack
  76. * `cd third_phase`
  77. * Edit `send.cpp` to use the correct MAC addresses
  78. * `g++ send.cpp -o send -ltins`
  79. * `./send <remote_ip> <remote_port> <victim_wlan_ip> <victim_priv_ip> <victim_port>`
  82. ***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.