ಟೆಲ್ ಅವಿವ್ ವಿಶ್ವವಿದ್ಯಾನಿಲಯ ಮತ್ತು ಹರ್ಜ್ಲಿಯಾ (ಇಸ್ರೇಲ್) ನಲ್ಲಿರುವ ಇಂಟರ್ ಡಿಸಿಪ್ಲಿನರಿ ಸೆಂಟರ್‌ನ ಸಂಶೋಧಕರ ಗುಂಪು ಹೊಸ ದಾಳಿ ವಿಧಾನ (), ನೀವು ಯಾವುದೇ DNS ಪರಿಹಾರಕಗಳನ್ನು ಟ್ರಾಫಿಕ್ ಆಂಪ್ಲಿಫೈಯರ್‌ಗಳಾಗಿ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ 1621 ಬಾರಿ ವರ್ಧನೆ ದರವನ್ನು ಒದಗಿಸುತ್ತದೆ (ಪರಿಹಾರಕಕ್ಕೆ ಕಳುಹಿಸಲಾದ ಪ್ರತಿ ವಿನಂತಿಗೆ, ಬಲಿಪಶುವಿನ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾದ 1621 ವಿನಂತಿಗಳನ್ನು ನೀವು ಸಾಧಿಸಬಹುದು) ಮತ್ತು ದಟ್ಟಣೆಯ ವಿಷಯದಲ್ಲಿ 163 ಬಾರಿ.
ಸಮಸ್ಯೆಯು ಪ್ರೋಟೋಕಾಲ್‌ನ ವಿಶಿಷ್ಟತೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಪ್ರಶ್ನೆ ಸಂಸ್ಕರಣೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಎಲ್ಲಾ DNS ಸರ್ವರ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. (ಸಿವಿಇ -2020-8616), (ಸಿವಿಇ -2020-12667), (ಸಿವಿಇ -2020-10995), и (CVE-2020-12662), ಹಾಗೆಯೇ Google, Cloudflare, Amazon, Quad9, ICANN ಮತ್ತು ಇತರ ಕಂಪನಿಗಳ ಸಾರ್ವಜನಿಕ DNS ಸೇವೆಗಳು. ಈ ಪರಿಹಾರವನ್ನು DNS ಸರ್ವರ್ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ, ಅವರು ತಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿನ ದುರ್ಬಲತೆಯನ್ನು ಸರಿಪಡಿಸಲು ನವೀಕರಣಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಿದರು. ದಾಳಿಯ ರಕ್ಷಣೆಯನ್ನು ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ
, , , .
ದಾಳಿಯು ಆಕ್ರಮಣಕಾರರು ಹಿಂದೆ ಕಾಣದ ಕಾಲ್ಪನಿಕ NS ದಾಖಲೆಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ವಿನಂತಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದಾಳಿಕೋರರನ್ನು ಆಧರಿಸಿದೆ, ಇದಕ್ಕೆ ಹೆಸರು ನಿರ್ಣಯವನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ಆದರೆ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ NS ಸರ್ವರ್‌ಗಳ IP ವಿಳಾಸಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ಅಂಟು ದಾಖಲೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದೆ. ಉದಾಹರಣೆಗೆ, ದಾಳಿಕೋರರು attacker.com ಡೊಮೇನ್‌ಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ DNS ಸರ್ವರ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ಮೂಲಕ sd1.attacker.com ಹೆಸರನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ದಾಳಿಕೋರನ DNS ಸರ್ವರ್‌ಗೆ ಪರಿಹಾರಕಾರರ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, IP NS ಸರ್ವರ್‌ಗಳನ್ನು ವಿವರಿಸದೆಯೇ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ NS ದಾಖಲೆಗಳನ್ನು ಸೂಚಿಸುವ ಮೂಲಕ ಬಲಿಪಶುವಿನ DNS ಸರ್ವರ್‌ಗೆ sd1.attacker.com ವಿಳಾಸದ ನಿರ್ಣಯವನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ಉಲ್ಲೇಖಿಸಲಾದ NS ಸರ್ವರ್ ಅನ್ನು ಮೊದಲು ಎದುರಿಸದ ಕಾರಣ ಮತ್ತು ಅದರ IP ವಿಳಾಸವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಕಾರಣ, ಗುರಿ ಡೊಮೇನ್ (victim.com) ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಿರುವ ಬಲಿಪಶುವಿನ DNS ಸರ್ವರ್‌ಗೆ ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ NS ಸರ್ವರ್‌ನ IP ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸಲು ಪರಿಹಾರಕ ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಸಮಸ್ಯೆಯೆಂದರೆ, ಆಕ್ರಮಣಕಾರರು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕಾಲ್ಪನಿಕ ಬಲಿಪಶು ಸಬ್‌ಡೊಮೈನ್ ಹೆಸರುಗಳೊಂದಿಗೆ ಪುನರಾವರ್ತನೆಯಾಗದ NS ಸರ್ವರ್‌ಗಳ ದೊಡ್ಡ ಪಟ್ಟಿಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು (fake-1.victim.com, fake-2.victim.com,... fake-1000. ಬಲಿಪಶು.com). ಪರಿಹಾರಕವು ಬಲಿಪಶುವಿನ DNS ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಆದರೆ ಡೊಮೇನ್ ಕಂಡುಬಂದಿಲ್ಲ ಎಂಬ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದರ ನಂತರ ಅದು ಪಟ್ಟಿಯಲ್ಲಿನ ಮುಂದಿನ NS ಸರ್ವರ್ ಅನ್ನು ನಿರ್ಧರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಎಲ್ಲವನ್ನೂ ಪ್ರಯತ್ನಿಸುವವರೆಗೆ ದಾಳಿಕೋರರು ಪಟ್ಟಿ ಮಾಡಿರುವ NS ದಾಖಲೆಗಳು. ಅಂತೆಯೇ, ಒಬ್ಬ ಆಕ್ರಮಣಕಾರರ ವಿನಂತಿಗಾಗಿ, ಪರಿಹಾರಕಾರರು NS ಹೋಸ್ಟ್‌ಗಳನ್ನು ನಿರ್ಧರಿಸಲು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. NS ಸರ್ವರ್ ಹೆಸರುಗಳು ಯಾದೃಚ್ಛಿಕವಾಗಿ ರಚಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸಬ್‌ಡೊಮೇನ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವುದರಿಂದ, ಅವುಗಳನ್ನು ಸಂಗ್ರಹದಿಂದ ಹಿಂಪಡೆಯಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆಕ್ರಮಣಕಾರರಿಂದ ಪ್ರತಿ ವಿನಂತಿಯು ಬಲಿಪಶುವಿನ ಡೊಮೇನ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ DNS ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳ ಕೋಲಾಹಲಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಸಂಶೋಧಕರು ಸಮಸ್ಯೆಗೆ ಸಾರ್ವಜನಿಕ DNS ಪರಿಹರಿಸುವವರ ದುರ್ಬಲತೆಯ ಮಟ್ಟವನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದರು ಮತ್ತು ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಪರಿಹಾರಕಕ್ಕೆ (1.1.1.1) ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುವಾಗ, ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು (PAF, ಪ್ಯಾಕೆಟ್ ಆಂಪ್ಲಿಫಿಕೇಶನ್ ಫ್ಯಾಕ್ಟರ್) 48 ಪಟ್ಟು ಹೆಚ್ಚಿಸಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದಾರೆ, Google (8.8.8.8) - 30 ಬಾರಿ, FreeDNS (37.235.1.174) - 50 ಬಾರಿ, OpenDNS (208.67.222.222) - 32 ಬಾರಿ. ಹೆಚ್ಚು ಗಮನಾರ್ಹವಾದ ಸೂಚಕಗಳನ್ನು ಗಮನಿಸಲಾಗಿದೆ
ಹಂತ3 (209.244.0.3) - 273 ಬಾರಿ, Quad9 (9.9.9.9) - 415 ಬಾರಿ
SafeDNS (195.46.39.39) - 274 ಬಾರಿ, Verisign (64.6.64.6) - 202 ಬಾರಿ,
ಅಲ್ಟ್ರಾ (156.154.71.1) - 405 ಬಾರಿ, ಕೊಮೊಡೊ ಸೆಕ್ಯೂರ್ (8.26.56.26) - 435 ಬಾರಿ, DNS.Watch (84.200.69.80) - 486 ಬಾರಿ, ಮತ್ತು Norton ConnectSafe (199.85.126.10 ಬಾರಿ) -569. BIND 9.12.3 ಆಧಾರಿತ ಸರ್ವರ್‌ಗಳಿಗೆ, ವಿನಂತಿಗಳ ಸಮಾನಾಂತರೀಕರಣದ ಕಾರಣದಿಂದಾಗಿ, ಗಳಿಕೆಯ ಮಟ್ಟವು 1000 ವರೆಗೆ ತಲುಪಬಹುದು. ನಾಟ್ ರೆಸಲ್ವರ್ 5.1.0 ನಲ್ಲಿ, ಗಳಿಕೆಯ ಮಟ್ಟವು ಸುಮಾರು ಹತ್ತಾರು ಬಾರಿ (24-48) ನಿರ್ಧರಿಸಿದಾಗಿನಿಂದ NS ಹೆಸರುಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಒಂದು ವಿನಂತಿಗಾಗಿ ಅನುಮತಿಸಲಾದ ಹೆಸರಿನ ರೆಸಲ್ಯೂಶನ್ ಹಂತಗಳ ಸಂಖ್ಯೆಯ ಆಂತರಿಕ ಮಿತಿಯ ಮೇಲೆ ನಿಂತಿದೆ.
ಎರಡು ಪ್ರಮುಖ ರಕ್ಷಣಾ ತಂತ್ರಗಳಿವೆ. DNSSEC ಯೊಂದಿಗಿನ ವ್ಯವಸ್ಥೆಗಳಿಗಾಗಿ ಬಳಕೆ DNS ಸಂಗ್ರಹ ಬೈಪಾಸ್ ಅನ್ನು ತಡೆಯಲು ಏಕೆಂದರೆ ವಿನಂತಿಗಳನ್ನು ಯಾದೃಚ್ಛಿಕ ಹೆಸರುಗಳೊಂದಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. DNSSEC ಮೂಲಕ ಶ್ರೇಣಿಯ ಪರಿಶೀಲನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅಧಿಕೃತ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸದೆ ನಕಾರಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸುವುದು ವಿಧಾನದ ಮೂಲತತ್ವವಾಗಿದೆ. ಒಂದು ನಿಯೋಜಿತ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದಾದ ಹೆಸರುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಸರಳವಾದ ವಿಧಾನವಾಗಿದೆ, ಆದರೆ ಈ ವಿಧಾನವು ಕೆಲವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಏಕೆಂದರೆ ಮಿತಿಗಳನ್ನು ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ.
ಮೂಲ: opennet.ru