← חזרה לרשימת המאמרים

DNS Rebinding & LANjack: Architectural Mitigation

מאת שי מרדכי | 26 באפריל 2026 | מחקר ארכיטקטורת רשת

מבוא: קמפיין LANjack

בעקבות חשיפת צוות המחקר של GeoEdge על הקמפיין LANjack, שבה התוקף מנצל שרתי DNS לא מאובטחים (בעיקר ב-Mobile ו-IoT) כדי להפוך דפדפנים ל-Proxy, עלתה אצלי שאלה ארכיטקטונית: האם ניתן לחסום את וקטור התקיפה הזה לחלוטין ברמת ה-Edge Device (הראוטר הביתי או ה-Firewall הארגוני)?

האנלוגיה ל-AWS וההצעה (Deterministic TTL Enforcement)

ב-AWS התמודדו with an אתגר דומה של גישה ל-Secrets (מתקפות SSRF) באמצעות מעבר ל-IMDSv2, שדורש טוקן ומגביל חבילות ל-TTL=1. על בסיס זה, הצעתי מנגנון "Defense in Depth":

אם יצרנים יגדירו בממשק הניהול (Web Management Interface) הגבלת TTL=1 (במקום ה-64 הדיפולטיבי של Linux), המידע החסוי של הראוטר או ה-Firewall יוכל להגיע רק למכשירים הנמצאים במרחק של Hop אחד (מכשירי ה-LAN המקומיים). ברגע שדפדפן נגוע ינסה להוציא את המידע הזה החוצה אל ה-WAN, החבילה פשוט תישמט (Drop) בראוטר הבא. כך נחסמת זליגת המידע החוצה, גם אם הדפדפן עצמו כבר פרוץ.

הוכחת היתכנות (PoC) עם Scapy

כדי להדגים את המנגנון לצוותי ה-PSIRT (Product Security Incident Response Team), יצרתי סביבת סימולציה. באמצעות Scapy, ייצרתי חבילות עם TTL מוגדר, כדי להמחיש את ההבדל בין התנהגות ברירת המחדל לבין מצב מוקשח.

# PoC Simulation: Outbound Exfiltration Attempt
from scapy.all import IP, ICMP, sr1

def simulate_exfiltration(target_ip, ttl_value):
    print(f"[*] Sending probe to {target_ip} with TTL={ttl_value}")
    packet = IP(dst=target_ip, ttl=ttl_value) / ICMP()
    reply = sr1(packet, timeout=2, verbose=0)
    
    if reply is None:
        print("[!] No response. Packet dropped.")
    elif reply.type == 11: # Time Exceeded
        print("[+] SUCCESS (Defense): Packet killed by gateway hop (Time Exceeded).")
    else:
        print("[-] VULNERABLE: Packet successfully routed outside the subnet.")

# Test 1: Standard routing (Current default)
simulate_exfiltration("8.8.8.8", 64)
# Test 2: Proposed Mitigation
simulate_exfiltration("8.8.8.8", 1)

Supporting Evidence (PCAP Files)

בסביבת המעבדה, הופקו שלושה קבצי PCAP שהועברו ליצרנים להוכחת ההיתכנות (PoC). ניתן להוריד ולבחון את החבילות ישירות מתוך המעבדה:

השיח מול התעשייה: Palo Alto Networks & TP-Link

שלחתי את ההצעה וה-PCAPs לצוותי האבטחה של Palo Alto Networks ו-TP-Link. שתי החברות נתנו מענה מקצועי ושקוף, והעלו את אותה סוגיה ארכיטקטונית: Usability vs. Security.

הם אישרו שהניתוח הטכני מדויק והגבלת ה-TTL אכן חוסמת את התקיפה. עם זאת, יישום גורף של TTL=1 ישבור תרחישי רשת מורכבים (כמו Mesh Topologies או L3 VPNs). כאשר משתמש מתחבר מרחוק הביתה או לארגון דרך VPN (במצב TUN), הראוטר מנתב את החבילה בין Subnets, מה שמוריד את ה-TTL ומפיל את החבילה. מעבר למצב TAP (Bridge) יכול היה לפתור זאת, אך הוא לרוב אינו נתמך במכשירים ניידים משיקולי אבטחה.

צוות ה-PSIRT של Palo Alto הבהיר ששימוש ב-TTL סטנדרטי אינו נחשב לחולשת אבטחה, אלא לבקשת תצורה (Configuration request), וצוות TP-Link ציין כי הם שוקלים את ההצעה כפיצ'ר "Opt-in" (מצב מוקשח) בעדכוני Firmware עתידיים.

סיכום

המחקר והאינטראקציה מול צוותי PSIRT בתעשייה חידדו עבורי את המהות של Security Architecture. אבטחה היא לעולם לא רק כתיבת חוקי חסימה; היא ניהול סיכונים מתמיד. הרעיון הטכני המאובטח ביותר עלול להיפסל אם הוא פוגע בפעילות העסקית או העיקרית של המשתמש. שילוב פתרונות כאלו כ-Opt-in למשתמשים מתקדמים מהווה את עמק השווה (Trade-off) הנכון.