ຊ່ອງໂຫວ່ທີ່ອະນຸຍາດໃຫ້ການເຊື່ອມຕໍ່ TCP ທີ່ເຮັດຜ່ານອຸໂມງ VPN ຖືກແຮັກ

ຈັດພີມມາ ເຕັກນິກການໂຈມຕີ (CVE-2019-14899) ທີ່ອະນຸຍາດໃຫ້ແພັກເກັດຖືກຫຼອກລວງ, ແກ້ໄຂ ຫຼືປ່ຽນແທນໃນການເຊື່ອມຕໍ່ TCP ທີ່ສົ່ງຜ່ານອຸໂມງ VPN. ບັນຫາມີຜົນຕໍ່ Linux, FreeBSD, OpenBSD, Android, macOS, iOS ແລະລະບົບອື່ນໆທີ່ຄ້າຍຄືກັບ Unix. Linux ສະຫນັບສະຫນູນກົນໄກການ rp_filter (ການກັ່ນຕອງເສັ້ນທາງປີ້ນກັບກັນ) ສໍາລັບ IPv4, ການເປີດມັນຢູ່ໃນໂຫມດ "Strict" neutralizes ບັນຫານີ້.

ວິທີການດັ່ງກ່າວອະນຸຍາດໃຫ້ການທົດແທນແພັກເກັດໃນລະດັບຂອງການເຊື່ອມຕໍ່ TCP ຜ່ານພາຍໃນອຸໂມງທີ່ຖືກເຂົ້າລະຫັດ, ແຕ່ບໍ່ອະນຸຍາດໃຫ້ເຂົ້າໄປໃນການເຊື່ອມຕໍ່ທີ່ໃຊ້ຊັ້ນການເຂົ້າລະຫັດເພີ່ມເຕີມ (ຕົວຢ່າງ, TLS, HTTPS, SSH). ຂັ້ນຕອນການເຂົ້າລະຫັດທີ່ໃຊ້ໃນ VPN ບໍ່ສຳຄັນ, ເພາະວ່າແພັກເກັດທີ່ຖືກປອມມາຈາກອິນເຕີເຟດພາຍນອກ ແລະຖືກປະມວນຜົນໂດຍ kernel ເປັນແພັກເກັດຈາກອິນເຕີເຟດ VPN. ເປົ້າຫມາຍຂອງການໂຈມຕີຫຼາຍທີ່ສຸດແມ່ນການແຊກແຊງການເຊື່ອມຕໍ່ HTTP ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ, ແຕ່ ບໍ່ຖືກຍົກເວັ້ນ ແລະໃຊ້ການໂຈມຕີເພື່ອຈັດການການຕອບສະຫນອງ DNS.

ການຫຼອກລວງແພັກເກັດທີ່ປະສົບຜົນສໍາເລັດໄດ້ຖືກສະແດງໃຫ້ເຫັນສໍາລັບອຸໂມງທີ່ສ້າງຂື້ນໂດຍໃຊ້ OpenVPN, WireGuard ແລະ IKEv2/IPSec. Tor ບໍ່ອ່ອນໄຫວຕໍ່ກັບບັນຫາ, ເພາະວ່າມັນໃຊ້ SOCKS ເພື່ອສົ່ງຕໍ່ການຈະລາຈອນ ແລະຖືກຜູກມັດກັບການໂຕ້ຕອບແບບ loopback. ສໍາລັບ IPv4, ການໂຈມຕີເປັນໄປໄດ້ຖ້າ rp_filter ຖືກຕັ້ງເປັນໂຫມດ "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). ໃນເບື້ອງຕົ້ນ, ລະບົບສ່ວນໃຫຍ່ໃຊ້ໂຫມດ "ເຂັ້ມງວດ", ແຕ່ເລີ່ມຕົ້ນຈາກ ລະບົບ 240, ປ່ອຍອອກມາເມື່ອເດືອນທັນວາທີ່ຜ່ານມາ, ຮູບແບບການເຮັດວຽກເລີ່ມຕົ້ນໄດ້ຖືກປ່ຽນເປັນ "Loose" ແລະການປ່ຽນແປງນີ້ໄດ້ຖືກສະທ້ອນໃຫ້ເຫັນໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນຂອງການແຈກຢາຍ Linux ຫຼາຍ.

rp_filter ກົນໄກ ນຳ ໃຊ້ແລ້ວ ສໍາລັບການຢັ້ງຢືນເສັ້ນທາງແພັກເກັດເພີ່ມເຕີມເພື່ອປ້ອງກັນການປອມແປງທີ່ຢູ່ແຫຼ່ງ. ເມື່ອຕັ້ງເປັນ 0, ບໍ່ມີການກວດສອບທີ່ຢູ່ຂອງແຫຼ່ງແມ່ນດໍາເນີນການແລະແພັກເກັດໃດໆສາມາດຖືກສົ່ງຕໍ່ລະຫວ່າງການໂຕ້ຕອບເຄືອຂ່າຍໂດຍບໍ່ມີຂໍ້ຈໍາກັດ. ຮູບແບບທີ 1 “ເຂັ້ມງວດ” ລວມມີການກວດສອບແຕ່ລະແພັກເກັດທີ່ມາຈາກພາຍນອກເພື່ອປະຕິບັດຕາມຕາຕະລາງການກຳນົດເສັ້ນທາງ, ແລະຖ້າອິນເຕີເຟດເຄືອຂ່າຍທີ່ແພັກເກັດໄດ້ຮັບນັ້ນບໍ່ກ່ຽວຂ້ອງກັບເສັ້ນທາງການຕອບສະໜອງທີ່ດີທີ່ສຸດ, ແພັກເກັດຈະຖືກຍົກເລີກ. ໂໝດ 2 "ວ່າງ" ຜ່ອນຄາຍການກວດສອບເພື່ອໃຫ້ຕົວດຸ່ນດ່ຽງການໂຫຼດ ຫຼືການກຳນົດເສັ້ນທາງທີ່ບໍ່ສົມມາຕຣິກເຮັດວຽກເມື່ອໃດ
ເສັ້ນທາງການຕອບໂຕ້ອາດຈະຜ່ານການໂຕ້ຕອບເຄືອຂ່າຍອື່ນທີ່ບໍ່ແມ່ນເສັ້ນທາງທີ່ແພັກເກັດທີ່ເຂົ້າມາ.

ໃນໂຫມດວ່າງ, ແພັກເກັດທີ່ເຂົ້າມາຈະຖືກກວດສອບກັບຕາຕະລາງການສົ່ງຕໍ່, ແຕ່ຖືວ່າຖືກຕ້ອງຖ້າທີ່ຢູ່ແຫຼ່ງແມ່ນສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານການໂຕ້ຕອບເຄືອຂ່າຍໃດໆ. ການໂຈມຕີທີ່ສະເຫນີແມ່ນອີງໃສ່ຄວາມຈິງທີ່ວ່າຜູ້ໂຈມຕີສາມາດສົ່ງແພັກເກັດທີ່ມີທີ່ຢູ່ແຫຼ່ງປອມທີ່ສອດຄ້ອງກັບການໂຕ້ຕອບ VPN, ແລະເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າແພັກເກັດນີ້ຈະເຂົ້າໄປໃນລະບົບໂດຍຜ່ານການໂຕ້ຕອບເຄືອຂ່າຍພາຍນອກແລະບໍ່ແມ່ນຜ່ານ VPN, ໃນ rp_filter ໂຫມດ "ວ່າງ" ເຊັ່ນຊຸດດັ່ງກ່າວຈະບໍ່ຖືກຍົກເລີກ.

ເພື່ອປະຕິບັດການໂຈມຕີ, ຜູ້ໂຈມຕີຕ້ອງຄວບຄຸມປະຕູຜ່ານທີ່ຜູ້ໃຊ້ເຂົ້າເຖິງເຄືອຂ່າຍ (ຕົວຢ່າງ, ຜ່ານອົງການ MITM, ເມື່ອຜູ້ຖືກເຄາະຮ້າຍເຊື່ອມຕໍ່ກັບຈຸດເຂົ້າເຖິງໄຮ້ສາຍທີ່ຄວບຄຸມໂດຍຜູ້ໂຈມຕີ, ຫຼືຜ່ານ. ການ hack router). ໂດຍການຄວບຄຸມປະຕູຜ່ານທີ່ຜູ້ໃຊ້ເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍ, ຜູ້ໂຈມຕີສາມາດສົ່ງແພັກເກັດປອມທີ່ຈະໄດ້ຮັບການຮັບຮູ້ໃນສະພາບການຂອງການໂຕ້ຕອບເຄືອຂ່າຍ VPN, ແຕ່ການຕອບສະຫນອງຈະຖືກສົ່ງຜ່ານທາງອຸໂມງ.

ໂດຍການສ້າງກະແສຂອງແພັກເກັດປອມທີ່ທີ່ຢູ່ IP ຂອງອິນເຕີເຟດ VPN ຖືກປ່ຽນແທນ, ຄວາມພະຍາຍາມແມ່ນເຮັດເພື່ອໃຫ້ມີອິດທິພົນຕໍ່ການເຊື່ອມຕໍ່ທີ່ສ້າງຂຶ້ນໂດຍລູກຄ້າ, ແຕ່ອິດທິພົນຂອງແພັກເກັດເຫຼົ່ານີ້ສາມາດສັງເກດເຫັນໄດ້ໂດຍຜ່ານການວິເຄາະຕົວຕັ້ງຕົວຕີຂອງການຈະລາຈອນທີ່ຖືກເຂົ້າລະຫັດທີ່ກ່ຽວຂ້ອງ. ກັບການດໍາເນີນງານຂອງ tunnel ໄດ້. ເພື່ອປະຕິບັດການໂຈມຕີ, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາທີ່ຢູ່ IP ຂອງອິນເຕີເຟດເຄືອຂ່າຍອຸໂມງທີ່ຖືກມອບຫມາຍໂດຍເຄື່ອງແມ່ຂ່າຍ VPN, ແລະຍັງກໍານົດວ່າການເຊື່ອມຕໍ່ກັບໂຮດສະເພາະແມ່ນມີການເຄື່ອນໄຫວຜ່ານອຸໂມງ.

ເພື່ອກໍານົດ IP ຂອງການໂຕ້ຕອບເຄືອຂ່າຍ virtual VPN, ແພັກເກັດ SYN-ACK ຖືກສົ່ງໄປຫາລະບົບຜູ້ຖືກເຄາະຮ້າຍ, ລໍາດັບລໍາດັບຂອງທີ່ຢູ່ virtual ທັງຫມົດ (ກ່ອນອື່ນຫມົດ, ທີ່ຢູ່ທີ່ໃຊ້ໃນ VPN ແມ່ນຖືກຄິດໄລ່ຕາມຄ່າເລີ່ມຕົ້ນ, ຕົວຢ່າງ, OpenVPN. ໃຊ້ເຄືອຂ່າຍຍ່ອຍ 10.8.0.0/24). ການມີຢູ່ຂອງທີ່ຢູ່ສາມາດຖືກຕັດສິນໄດ້ໂດຍອີງໃສ່ການໄດ້ຮັບຄໍາຕອບທີ່ມີທຸງ RST.

ໃນລັກສະນະທີ່ຄ້າຍຄືກັນ, ການປະກົດຕົວຂອງການເຊື່ອມຕໍ່ກັບເວັບໄຊທ໌ໃດຫນຶ່ງແລະຫມາຍເລກພອດຢູ່ໃນຝ່າຍລູກຄ້າຖືກກໍານົດ - ໂດຍການຈັດລຽງຜ່ານຕົວເລກພອດ, ຊຸດ SYN ຖືກສົ່ງໄປຫາຜູ້ໃຊ້, ເປັນທີ່ຢູ່ຂອງແຫຼ່ງ, ເຊິ່ງຢູ່ໃນເວັບໄຊທ໌ຂອງ. IP ແມ່ນຖືກແທນທີ່, ແລະທີ່ຢູ່ປາຍທາງແມ່ນ virtual IP VPN. ພອດເຊີຟເວີສາມາດຄາດຄະເນໄດ້ (80 ສໍາລັບ HTTP), ແລະຫມາຍເລກພອດຢູ່ໃນຝ່າຍລູກຄ້າສາມາດຖືກຄິດໄລ່ໂດຍ brute force, ການວິເຄາະສໍາລັບຕົວເລກທີ່ແຕກຕ່າງກັນການປ່ຽນແປງຄວາມເຂັ້ມຂົ້ນຂອງການຕອບສະຫນອງ ACK ໃນການປະສົມປະສານກັບການຂາດແພັກເກັດທີ່ມີ RST. ທຸງ.

ໃນຂັ້ນຕອນນີ້, ຜູ້ໂຈມຕີຮູ້ທັງສີ່ອົງປະກອບຂອງການເຊື່ອມຕໍ່ (ທີ່ຢູ່ IP ແຫຼ່ງ / ພອດແລະທີ່ຢູ່ IP ປາຍທາງ / ພອດ), ແຕ່ເພື່ອສ້າງແພັກເກັດປອມທີ່ລະບົບຜູ້ຖືກເຄາະຮ້າຍຈະຍອມຮັບ, ຜູ້ໂຈມຕີຕ້ອງກໍານົດລໍາດັບ TCP ແລະ. ຕົວເລກການຮັບຮູ້ (seq ແລະ ack) - ການເຊື່ອມຕໍ່. ເພື່ອກໍານົດຕົວກໍານົດການເຫຼົ່ານີ້, ຜູ້ໂຈມຕີສືບຕໍ່ສົ່ງແພັກເກັດ RST ປອມ, ພະຍາຍາມຕົວເລກລໍາດັບທີ່ແຕກຕ່າງກັນ, ຈົນກ່ວາລາວກວດພົບຊຸດການຕອບໂຕ້ ACK, ການມາຮອດທີ່ຊີ້ໃຫ້ເຫັນວ່າຈໍານວນດັ່ງກ່າວຕົກຢູ່ໃນປ່ອງຢ້ຽມ TCP.

ຕໍ່ໄປ, ຜູ້ໂຈມຕີຊີ້ແຈງຄວາມຖືກຕ້ອງຂອງຄໍານິຍາມໂດຍການສົ່ງແພັກເກັດທີ່ມີຈໍານວນດຽວກັນແລະສັງເກດເຫັນການມາຮອດຂອງຄໍາຕອບ ACK, ຫຼັງຈາກນັ້ນລາວເລືອກຈໍານວນທີ່ແນ່ນອນຂອງລໍາດັບປະຈຸບັນ. ວຽກງານແມ່ນສັບສົນໂດຍຄວາມຈິງທີ່ວ່າຄໍາຕອບຖືກສົ່ງພາຍໃນອຸໂມງທີ່ຖືກເຂົ້າລະຫັດແລະການປະກົດຕົວຂອງພວກເຂົາຢູ່ໃນກະແສການຈະລາຈອນທີ່ຖືກສະກັດພຽງແຕ່ສາມາດວິເຄາະໂດຍໃຊ້ວິທີການທາງອ້ອມເທົ່ານັ້ນ. ບໍ່ວ່າລູກຄ້າຈະສົ່ງແພັກເກັດ ACK ໄປຫາເຊີບເວີ VPN ຫຼືບໍ່ແມ່ນຖືກກໍານົດໂດຍອີງຕາມຂະຫນາດແລະຄວາມຊັກຊ້າຂອງການຕອບສະຫນອງທີ່ຖືກເຂົ້າລະຫັດ, ເຊິ່ງກ່ຽວຂ້ອງກັບການສົ່ງແພັກເກັດປອມ. ຕົວຢ່າງ, ສໍາລັບ OpenVPN, ຂະຫນາດແພັກເກັດທີ່ຖືກເຂົ້າລະຫັດຂອງ 79 ຊ່ວຍໃຫ້ທ່ານສາມາດຕັດສິນໄດ້ຢ່າງຖືກຕ້ອງວ່າມີ ACK ພາຍໃນ.

ຈົນກ່ວາການປ້ອງກັນການໂຈມຕີຈະຖືກເພີ່ມເຂົ້າໃນ kernel ລະບົບປະຕິບັດການເປັນວິທີການຊົ່ວຄາວຂອງການຂັດຂວາງບັນຫາ ແນະ ນຳ ການນໍາໃຊ້ຕົວກອງແພັກເກັດໃນລະບົບຕ່ອງໂສ້ "preroute", ສະກັດກັ້ນການຖ່າຍທອດຂອງແພັກເກັດທີ່ທີ່ຢູ່ IP virtual ຂອງອຸໂມງແມ່ນລະບຸເປັນທີ່ຢູ່ປາຍທາງ.

iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP

ຫຼືສໍາລັບ nftables

nft ເພີ່ມຕາຕະລາງ ip raw
nft ເພີ່ມຕ່ອງໂສ້ ip raw prerouting '{ type filter hook prerouting priority 0; }'
nft ເພີ່ມກົດລະບຽບ ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'

ເພື່ອປົກປ້ອງຕົນເອງເມື່ອໃຊ້ອຸໂມງທີ່ມີທີ່ຢູ່ IPv4, ພຽງແຕ່ຕັ້ງ rp_filter ເປັນໂໝດ “Strict” (“sysctl net.ipv4.conf.all.rp_filter = 1”). ໃນດ້ານ VPN, ວິທີການກວດຫາເລກລໍາດັບສາມາດຖືກບລັອກໂດຍການເພີ່ມ padding ພິເສດໃສ່ແພັກເກັດທີ່ຖືກເຂົ້າລະຫັດ, ເຮັດໃຫ້ແພັກເກັດທັງຫມົດມີຂະຫນາດດຽວກັນ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru