ผู้เขียนต้นฉบับ:ผู้เขียนต้นฉบับ:โคไซน์
ผู้ก่อตั้งเทคโนโลยี SlowMist
การไฮแจ็ก DNS (การไฮแจ็ก) น่าจะเป็นที่คุ้นเคยสำหรับทุกคน ในประวัติศาสตร์ MyEtherWallet, PancakeSwap, SpiritSwap, KLAYswap, Convex Finance ฯลฯ รวมถึง CurveFinance ในปัจจุบัน ได้พบกับโครงการคริปโตเคอเรนซีที่เป็นที่รู้จักมากกว่าโหล แต่หลายคนอาจไม่รู้ต้นตอของการไฮแจ็ก และที่สำคัญกว่านั้นคือ วิธีป้องกัน (จากมุมมองของฝ่ายโครงการและมุมมองของผู้ใช้) ผมจะเล่าสั้นๆ ให้ฟังที่นี่
Domain -> IP_REAL
DNS ช่วยให้เราสามารถค้นหา IP ที่สอดคล้องกันเมื่อเข้าถึงชื่อโดเมนเป้าหมาย:
Domain ->หากความสัมพันธ์ที่ชี้ถูกแทนที่โดยผู้โจมตี:
IP_BAD (ควบคุมโดยผู้โจมตี)
จากนั้นผู้โจมตีสามารถปลอมแปลงเนื้อหาของการตอบสนองจากเซิร์ฟเวอร์ซึ่งเป็นที่ตั้งของ IP_BAD ท้ายที่สุด สำหรับผู้ใช้ อะไรก็ตามที่อยู่ภายใต้โดเมนเป้าหมายในเบราว์เซอร์อาจเป็นปัญหาได้
จริงๆ แล้วการไฮแจ็ก DNS แบ่งออกเป็นหลายความเป็นไปได้ ตัวอย่างเช่น มีสองประเภททั่วไป:
คอนโซลชื่อโดเมนถูกแฮ็ก ผู้โจมตีสามารถแก้ไขระเบียน DNS A โดยพลการ (ชี้ IP ไปที่ IP_BAD ที่ควบคุมโดยผู้โจมตี) หรือแก้ไข Nameservers โดยตรงไปยังเซิร์ฟเวอร์ DNS ที่ควบคุมโดยผู้โจมตี
ดำเนินการไฮแจ็คแบบคนกลางอย่างคร่าวๆ บนเครือข่าย และบังคับให้ชื่อโดเมนเป้าหมายชี้ไปที่ IP_BAD
จุดแรกของการไฮแจ็กสามารถทำได้อย่างเงียบเชียบ นั่นคือจะไม่มีการแจ้งเตือนด้านความปลอดภัยในฝั่งเบราว์เซอร์ของผู้ใช้ เนื่องจากในขณะนี้ ผู้โจมตีสามารถออกใบรับรอง HTTPS ที่ถูกต้องอีกใบหนึ่งได้
การไฮแจ็กจุด 2 ไม่สามารถไฮแจ็กแบบเงียบได้หากชื่อโดเมนใช้ HTTPS และข้อความแจ้งข้อผิดพลาดของใบรับรอง HTTPS จะปรากฏขึ้น แต่ผู้ใช้สามารถบังคับให้เข้าถึงต่อไปได้ เว้นแต่ชื่อโดเมนเป้าหมายจะได้รับการกำหนดค่าด้วยกลไกการรักษาความปลอดภัย HSTS
ข้อเน้นย้ำ: หากชื่อโดเมนของโครงการ Crypto/Web3 ไม่บังคับใช้ HTTPS (หมายความว่า HTTP ยังสามารถเข้าถึงได้) และ HTTPS ไม่ได้บังคับให้เปิดใช้งาน HSTS (HTTP Strict Transport Security) ดังนั้นสำหรับสถานการณ์การลักลอบใช้จุดที่ 2 มันเสี่ยงมาก ตาสว่างกันทุกคน ระวังตัวด้วย
สำหรับฝั่งโครงการ นอกเหนือจากการกำหนดค่า HTTPS + HSTS สำหรับชื่อโดเมนอย่างสมบูรณ์แล้ว การตรวจสอบความปลอดภัยต่อไปนี้สามารถทำได้เป็นประจำ:
ตรวจสอบว่าระเบียน DNS (A และ NS) ที่เกี่ยวข้องกับชื่อโดเมนเป็นปกติหรือไม่
ตรวจสอบว่าใบรับรองที่แสดงชื่อโดเมนในเบราว์เซอร์นั้นกำหนดค่าด้วยตัวเองหรือไม่
ตรวจสอบว่าแพลตฟอร์มที่เกี่ยวข้องของการจัดการชื่อโดเมนได้เปิดใช้งานการตรวจสอบสิทธิ์แบบสองปัจจัยหรือไม่
ตรวจสอบว่าบันทึกคำขอบริการเว็บและบันทึกที่เกี่ยวข้องเป็นปกติหรือไม่
สำหรับผู้ใช้ มีจุดป้องกันหลายจุด และฉันจะอธิบายทีละจุด
http://example[.]com
สำหรับชื่อโดเมนหลัก ห้ามเข้าถึงโดยเด็ดขาดในรูปแบบของ HTTP เช่น:
https://example[.]com
ควรอยู่ในรูปแบบ HTTPS เสมอ:
หากรูปแบบ HTTPS เบราว์เซอร์มีข้อผิดพลาดของใบรับรอง HTTPS อย่าดำเนินการต่อโดยเด็ดขาด สิ่งนี้จะป้องกันการโจมตีการไฮแจ็ก DNS แบบไม่เงียบ
สำหรับการไฮแจ็กแบบเงียบ ไม่ว่าจะเป็นการไฮแจ็ก DNS การแฮ็กเซิร์ฟเวอร์โปรเจ็กต์ ความชั่วร้ายภายใน โค้ดฟรอนต์เอนด์โปรเจ็กต์ถูกวางยาโดยการโจมตีของซัพพลายเชน ฯลฯ จากมุมมองของผู้ใช้ จะไม่มีความผิดปกติในฝั่งเบราว์เซอร์ จนกว่าทรัพย์สินของผู้ใช้จะถูกขโมย
แล้วผู้ใช้จะป้องกันในกรณีนี้ได้อย่างไร?
นอกเหนือจากการเฝ้าระวังในทุกขั้นตอนของการดำเนินการแล้ว (โดยเฉพาะช่วงเวลาที่จำเป็นต้องลงนามและยืนยันกระเป๋าเงิน) ผู้ใช้ควรระมัดระวัง
ฉันขอแนะนำส่วนขยายด้านความปลอดภัยของเบราว์เซอร์ที่รู้จักกันดีในยุค Web2: @noscript (แม้ว่า Twitter จะไม่ได้รับการอัปเดตเป็นเวลานาน แต่ฉันรู้สึกประหลาดใจที่พบว่าเว็บไซต์อย่างเป็นทางการได้รับการอัปเดตและส่วนขยายก็ได้รับการปรับปรุงเช่นกัน updated) ซึ่งเป็นผลงานของ @ma1.
NoScript บล็อกไฟล์ JavaScript ที่ฝังไว้ตามค่าเริ่มต้น
แต่ NoScript มีความคุ้นเคยกับเกณฑ์เล็กน้อย และบางครั้งอาจน่ารำคาญ คำแนะนำของฉันคือการเข้าถึงชื่อโดเมนที่สำคัญสามารถทำได้บนเบราว์เซอร์ที่ติดตั้ง NoScript (เช่น Firefox) และเบราว์เซอร์อื่นๆ (เช่น Chrome)
เป็นแนวปฏิบัติด้านความปลอดภัยที่ดีในการดำเนินการโดยแยกจากกัน หลายสิ่งหลายอย่างที่คุณอาจพบว่ายุ่งยาก หลังจากขับรถและทำความคุ้นเคยแล้ว ทุกอย่างจะดีขึ้น
https://curve[.]fi/js/app.ca2e5d81.js
แต่นี่ไม่ใช่การป้องกันที่สมบูรณ์แบบ(ไม่เคยมีการป้องกันที่สมบูรณ์แบบ) ตัวอย่างเช่น ในการโจมตี @CurveFinance นี้ ผู้โจมตีเปลี่ยนระเบียน DNS A ให้ชี้ไปที่ IP_BAD แล้วสร้างความเสียหายให้กับฟรอนต์เอนด์:
มีการฝังรหัสที่เป็นอันตรายที่เกี่ยวข้องกับการขโมยเหรียญ
หากก่อนหน้านี้เราเชื่อถือ Curve กับ NoScript เราอาจถูกหลอกในครั้งนี้เช่นกัน
ลิงค์ต้นฉบับ
