Cyber & Code

💉 קורס SQL Injection - שיעור 5: זיהוי, מניעה, ופסק הדין הסופי 🏁 ברוכים הבאים לשיעור החמישי והאחרון ב"קורס SQL Injection"! במהלך הקורס עברנו מסע שלם: התחלנו בזיהוי חולשות דרך שגיאות, למדנו לגנוב מידע עם UNION, התמודדנו עם אפליקציות שותקות בעזרת Blind SQLi, ולבסוף חקרנו איך תוקפים עוקפים הגנות כמו WAF. בשיעור הסיום הזה, נתמקד בשלוש שאלות פרקטיות: איך אני, כחוקר אבטחה או מפתח, מוצא חולשות SQLi? איך אני מונע אותן באופן הרמטי ומוחלט? פסק הדין הסופי: האם SQLi עדיין רלוונטי היום? איך מזהים SQL Injection? ישנן שתי גישות עיקריות לאיתור החולשה: ידנית ואוטומטית. 1. בדיקה ידנית (The Art 🎨) זוהי עבודת בילוש הדורשת אינטואיציה והבנה. התהליך כולל שליחת קלטים לא צפויים ובחינת התגובות: הזרקת תווים מיוחדים: שליחת גרש בודד (') או כפול (") ובדיקה אם חוזרת שגיאת מסד נתונים. הזרקת לוגיקה: שליחת תנאים כמו AND 1=1 ו-AND 1=2 ובדיקה אם יש הבדל בתגובת העמוד (מעיד על Boolean-Based Blind). הזרקת פקודות זמן: שליחת פקודות כמו SLEEP(5) ובדיקת זמן התגובה של השרת (מעיד על Time-Based Blind). 2. סריקה אוטומטית (The Science 🔬) בדיקה ידנית היא אמנות, אבל היא איטית. לכן, רוב אנשי המקצוע משתמשים בכלים אוטומטיים, ובראשם sqlmap. יsqlmap הוא הכלי האולטימטיבי לזיהוי וניצול SQLi. כל מה שצריך לעשות הוא לתת לו את הכתובת החשודה: sqlmap -u "https://vulnerable-site.com/products.php?id=1" הכלי יריץ מאחורי הקלעים סוללה של אלפי בדיקות, המכסות את כל הטכניקות שלמדנו בקורס: הוא ינסה לגרום לשגיאות, ינסה לבצע UNION, ישאל שאלות של אמת/שקר, ימדוד זמנים, ואף ינסה לעקוף WAFs בעצמו. בסיום, הוא יפיק דוח מפורט שיאשר אם האתר פגיע, מהי רמת הפגיעות, ואיזה מידע ניתן לשלוף. איך מונעים SQL Injection? (כדור הכסף) למרות כל המורכבות של ההתקפות, הפתרון למניעת SQLi הוא פשוט, אלגנטי ויעיל להפליא. ישנן מספר שכבות הגנה, אבל יש אחת שהיא החשובה מכולן. הגנה ראשית: Parameterized Queries (Prepared Statements) זוהי התשובה הנכונה. נקודה. אם אתם מפתחים, זה הדבר היחיד שאתם חייבים לזכור. הרעיון: במקום לשרשר קלט משתמש לתוך מחרוזת SQL, אנחנו מפרידים בין מבנה הפקודה לבין הנתונים. שולחים למסד הנתונים את "תבנית" השאילתה עם "ממלאי מקום" (placeholders) במקום שבו הנתונים אמורים להיות. מסד הנתונים מקבל את התבנית, מנתח אותה ומכין אותה להרצה (מכאן השם Prepared Statements). רק אז, בשלב נפרד, שולחים את הנתונים מהמשתמש. מסד הנתונים מתייחס לנתונים האלה כאל מידע טהור וחסר משמעות מבחינת הפקודה, ולעולם לא כאל קוד שצריך להריץ. דוגמה ב-PHP (עם PDO): PHP $stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username"); $stmt->execute(['username' => $user_input]); דוגמה בפייתון (עם mysql-connector): Python cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,)) זה הכל. שימוש בשיטה זו הופך את כל טכניקות ה-SQLi שלמדנו לבלתי יעילות. הגנות משניות (Defense in Depth): יInput Validation: ודאו תמיד שהקלט מהמשתמש תואם למה שאתם מצפים לקבל (למשל, שגיל הוא מספר). עיקרון ההרשאה המינימלית: צרו למערכת שלכם משתמש ייעודי במסד הנתונים עם הרשאות מינימליות בלבד. הוא לא צריך הרשאה למחוק טבלאות. הסתרת שגיאות: בסביבה חיה, לעולם אין להציג למשתמש שגיאות מפורטות ממסד הנתונים. פסק הדין הסופי: האם SQLi מת ב-2025? התשובה היא ממש לא. נכון, בתוך הבועה של פריימוורקים מודרניים (כמו Django, Laravel, Ruby on Rails) שמשתמשים ב-ORM, קשה מאוד למפתח ליצור חולשת SQLi בטעות, כי הם משתמשים ב-Prepared Statements מאחורי הקלעים. אבל בעולם האמיתי, SQLi עדיין מהווה איום קריטי, וזו הסיבה שהוא עדיין מככב בראש רשימת OWASP Top 10: מערכות Legacy: האינטרנט מלא במערכות ישנות וקריטיות שכתובות בקוד מיושן ופגיע. טעויות אנוש: גם מפתחים מודרניים לעיתים כותבים שאילתות SQL גולמיות (משיקולי ביצועים למשל) ועושים טעויות. מערכת התוספים (Plugins): תוספים לוורדפרס, ג'ומלה וכו' הם נקודת תורפה ענקית, מכיוון שאיכות הקוד בהם לא אחידה. יAPIs ו-IoT: העולם עובר ל-API ולמכשירי IoT. רבים מהם מפותחים במהירות, ולא תמיד עם אותה רמת אבטחה של פריימוורק ווב בוגר. סיכום הקורס סיימנו את המסע שלנו בעולם ה-SQL Injection. ראינו שזו חולשה עם היסטוריה ארוכה, אבל היא רחוקה מלהיות נחלת העבר. למדנו את צורות ההתקפה השונות, מהפשוטה ביותר ועד למתוחכמת ביותר. והכי חשוב, למדנו שהפתרון למניעתה הוא פשוט וברור.

💉 קורס SQL Injection - שיעור 4: טכניקות מתקדמות ועקיפת הגנות (WAF Bypass) 🛡️🔥 שלום לכולם וברוכים הבאים לשיעור הרביעי בקורס ה-SQLi! עד כה, פעלנו תחת ההנחה שאנחנו תוקפים אפליקציה "עירומה". אבל בעולם האמיתי, ארגונים רבים מציבים "שומר סף" דיגיטלי בכניסה לאתר שלהם. השומר הזה נקרא Web Application Firewall (WAF). בשיעור הזה נבין מהו WAF, איך הוא מנסה לעצור אותנו, ואיך מתנהל משחק החתול והעכבר שבו תוקפים מנסים להערים עליו ולהעביר את ההתקפה בכל זאת. איך WAF חושב (ומדוע הוא לא חסין מטעויות)? יWAF הוא רכיב אבטחה שיושב בין המשתמש לבין שרת האינטרנט. הוא בוחן את כל התעבורה הנכנסת ומחפש דפוסים חשודים. ברוב המקרים, הוא עובד על בסיס חתימות (Signatures) – רשימה שחורה של מחרוזות וביטויים שנחשבים זדוניים. לדוגמה, ה-WAF יכול להכיל חוקים כמו: "אם אתה רואה בבקשה את המחרוזת ' OR '1'='1', חסום אותה!" "אם אתה רואה UNION SELECT, חסום!" "אם אתה רואה SLEEP(), חסום!" החולשה המובנית בשיטה זו היא שאם תוקף מצליח לבנות שאילתת SQL זדונית שתהיה חוקית לחלוטין עבור מסד הנתונים, אבל לא תתאים לאף אחת מהחתימות המוכרות של ה-WAF, ההתקפה תחליק דרכו. טכניקות לעקיפת WAF (WAF Evasion) כאן מתחילה היצירתיות של התוקף. המטרה היא "לבלבל" את ה-WAF, אבל לא את מסד הנתונים. 1. שינוי אותיות רישיות/קטנות (Case Variation): הטריק הפשוט ביותר. WAF פשוט עלול לחפש select רק באותיות קטנות. מסדי נתונים רבים (כמו MySQL) הם Case-Insensitive לפקודות SQL. במקום: union select התוקף ינסה: uNiOn sElEcT או UNION SELECT 2. שימוש בהערות כדי "לשבור" מילים: ב-SQL אפשר להוסיף הערות באמצע הקוד. ה-WAF יראה חלקי מילים, אבל מסד הנתונים יתעלם מההערות ויחבר הכל חזרה לפקודה אחת. במקום: union select התוקף ינסה: union//select או אפילו U//NION//SEL//ECT 3. שימוש בקידודים (Encodings): תעבורת אינטרנט משתמשת בקידודים שונים. תוקפים יכולים לנצל זאת כדי להסוות את התוכן. יURL Encoding: שימוש ב-%20 במקום רווח, או %27 במקום גרש ('). רוב ה-WAFs המודרניים יודעים להתמודד עם זה, אבל לפעמים קידוד כפול או קידוד לא סטנדרטי יכול לעבוד. יHEX Encoding: אפשר לקודד מחרוזות שלמות בבסיס הקסדצימלי. במקום: ... WHERE name = 'admin' התוקף ינסה: ... WHERE name = 0x61646d696e (כאשר 0x61646d696e הוא "admin" ב-HEX). 4. שימוש במילים נרדפות ותווים חלופיים: לפעמים יש דרכים שונות לבצע את אותה פעולה לוגית. במקום AND אפשר לנסות &&. במקום OR אפשר לנסות ||. במקום רווח רגיל, אפשר להשתמש בתווים "לבנים" אחרים כמו טאב (%09) או ירידת שורה (%0a). טכניקה מתקדמת: Second-Order SQL Injection (התקפת פצצת הזמן) זוהי אחת הטכניקות המסוכנות והחמקמקות ביותר, מכיוון שהיא עוקפת WAF כמעט לחלוטין. היא מתבצעת בשני שלבים: שלב 1: הזרקה ואחסון. התוקף מזריק מחרוזת זדונית לא לשדה שרץ מיד, אלא לשדה שנשמר במסד הנתונים. דוגמה קלאסית: בעמוד עדכון פרופיל, התוקף מעדכן את השם הפרטי שלו למחרוזת כמו Shimon' OR 1=1 --. הבקשה הזו נראית לגיטימית לחלוטין ל-WAF – בסך הכל עדכון שם. שלב 2: ההפעלה. המחרוזת הזדונית יושבת כעת רדומה במסד הנתונים. בשלב מאוחר יותר, חלק אחר לגמרי של המערכת (למשל, עמוד ניהול שמציג רשימת משתמשים) שולף את השם הזה מהמאגר. הקוד של עמוד הניהול, שאינו מאובטח, משרשר את השם ששלף ישירות לתוך שאילתת SQL חדשה. ברגע זה, "פצצת הזמן" מתפוצצת, והקוד הזדוני שהיה חבוי רץ. ההתקפה הזו קשה מאוד לאיתור כי נקודת ההזרקה ונקודת ההרצה נמצאות בשני מקומות שונים לחלוטין בקוד, ובזמנים שונים. 📝 סיכום שיעור 4: ראינו שהמציאות מורכבת יותר, ולעיתים קרובות יש WAF שמנסה להגן על האפליקציה. למדנו על משחק החתול והעכבר של עקיפת הגנות באמצעות טכניקות הסוואה שונות. לבסוף, צללנו לטכניקת ה-Second-Order SQLi, שמדגימה איך תוקפים יכולים להחביא "פצצת זמן" במערכת. כעת, לאחר שכיסינו את כל ספקטרום ההתקפות, מהבסיס ועד למתקדם, אנחנו מוכנים לשיעור האחרון. בשיעור 5 נסגור את כל המעגלים: נתמקד בצד הפרקטי של זיהוי, מניעה, ונדון - היכן SQL Injection עדיין מהווה איום קריטי בעולם של היום. הצטרפו לערוץ @CYBERSECURITYCODING

💉 קורס SQL Injection - שיעור 3: התקפה עיוורת (Blind SQL Injection) 🕵️‍♂️ ברוכים הבאים לשיעור השלישי! עד עכשיו, ההתקפות שלנו התבססו על זה שהאפליקציה "דיברה" איתנו: היא הציגה לנו שגיאות (שיעור 1) או החזירה לנו מידע שביקשנו דרך UNION (שיעור 2). אבל מה קורה כשהמפתחים היו חכמים יותר? מה אם הם הגדירו את השרת כך שלעולם לא יציג שגיאות, והעמוד הפגיע לא מדפיס שום מידע משאילתת ה-SQL? האם זה אומר שהמערכת בטוחה? ממש לא. כאן נכנסת לתמונה הטכניקה העיקשת והמתוחכמת מכולן: Blind SQL Injection (הזרקה עיוורת). העיקרון: משחק "20 שאלות" עם מסד הנתונים בהזרקה עיוורת, אנחנו לא יכולים לראות את התוצאה ישירות. במקום זאת, אנחנו שואלים את מסד הנתונים סדרה של שאלות של "אמת" או "שקר", ומסיקים את התשובה על סמך תגובה עקיפה של האפליקציה. כמעט תמיד, אפליקציה תגיב באופן שונה לשאילתה שהצליחה (אמת) לעומת שאילתה שנכשלה (שקר). למשל: מצב אמת: ...products.php?id=3 ⬅️ העמוד מציג את "מוצר 3". מצב שקר: ...products.php?id=-1 ⬅️ העמוד מציג "מוצר לא נמצא". התגובה הזו, ההבדל בין "נמצא" ל"לא נמצא", היא כל מה שהתוקף צריך. סוג 1: Boolean-Based Blind SQLi זוהי הטכניקה הנפוצה יותר של הזרקה עיוורת. אנחנו מוסיפים תנאי AND לשאילתה קיימת. אם התנאי שלנו נכון, השאילתה המקורית תצליח והעמוד ייראה רגיל (מצב אמת). אם התנאי שלנו שקרי, כל השאילתה תיכשל והעמוד ייראה שונה (מצב שקר). בואו נראה איך תוקף משתמש בזה כדי לגנוב את שם מסד הנתונים, אות אחר אות: שאלה 1: מה אורך שם מסד הנתונים? id=3' AND length(database()) = 5 -- ⬅️ מראה "מוצר לא נמצא" (שקר) id=3' AND length(database()) = 6 -- ⬅️ מראה "מוצר לא נמצא" (שקר) id=3' AND length(database()) = 7 -- ⬅️ מראה את "מוצר 3" (אמת!) מסקנה: התוקף יודע שאורך שם מסד הנתונים הוא 7 תווים. שאלה 2: מהו התו הראשון בשם? כאן נשתמש בפונקציות כמו SUBSTRING (לחלץ תו) ו-ASCII (לקבל את הערך המספרי של התו). id=3' AND ASCII(SUBSTRING(database(), 1, 1)) > 100 -- ⬅️ אמת. id=3' AND ASCII(SUBSTRING(database(), 1, 1)) > 110 -- ⬅️ שקר. התוקף מבין שהערך האסקי של התו הראשון הוא בין 100 ל-110. הוא ממשיך לצמצם את הטווח עד שהוא מוצא את הערך המדויק: id=3' AND ASCII(SUBSTRING(database(), 1, 1)) = 104 -- ⬅️ אמת! מסקנה: ASCII 104 זה התו 'h'. התהליך הזה חוזר על עצמו עבור כל אות בשם מסד הנתונים, אחר כך עבור שמות הטבלאות, העמודות, ובסוף עבור הנתונים עצמם. זהו תהליך ארוך ומייגע להחריד עבור בן אנוש. סוג 2: Time-Based Blind SQLi - כשהמערכת שותקת לחלוטין ומה אם המפתחים היו אפילו יותר חכמים, והאפליקציה מציגה את אותו העמוד בדיוק בין אם התוצאה היא אמת או שקר? עכשיו אין לנו שום הבדל ויזואלי. כאן נשתמש בנשק האחרון שלנו: זמן. אנחנו לא יכולים לראות את התגובה, אז נגרום לה להרגיש. נורה למסד הנתונים: "אם התנאי שלי נכון, אנא המתן 5 שניות לפני שאתה מגיב". ב-MySQL, עושים זאת עם פקודת SLEEP(): id=3' AND IF(1=2, SLEEP(5), 0) -- התנאי 1=2 הוא שקר, ולכן SLEEP(5) לא יופעל. העמוד יעלה מיידית. id=3' AND IF(1=1, SLEEP(5), 0) -- התנאי 1=1 הוא אמת, ולכן SLEEP(5) יופעל. העמוד יעלה לאחר 5 שניות. עכשיו התוקף יכול לשאול את כל אותן השאלות מהסעיף הקודם, אבל במקום לבדוק אם העמוד השתנה, הוא מודד עם שעון עצר: id=3' AND IF(length(database())=7, SLEEP(5), 0) -- ⬅️ לוקח 5 שניות? אמת. id=3' AND IF(ASCII(SUBSTRING(database(),1,1))=104, SLEEP(5), 0) -- ⬅️ לוקח 5 שניות? אמת. זוהי הטכניקה האיטית והחמקמקה ביותר, וכמעט בלתי אפשרי לחסום אותה אם החולשה הבסיסית קיימת. התפקיד הקריטי של אוטומציה: sqlmap בטח שאלתם את עצמכם "מי ישקיע שעות בשליחת אלפי בקשות כאלה?". התשובה היא: אף אחד. כאן נכנסים כלים אוטומטיים, והמלך הבלתי מעורער שלהם הוא sqlmap. יsqlmap הוא כלי קוד פתוח שממכן את כל התהליך. הוא יודע לזהות את כל סוגי ה-SQLi (כולל כל טכניקות ה-Blind), ולבצע את אלפי הבקשות הנדרשות כדי למפות את מסד הנתונים ולשלוף את המידע באופן אוטומטי. התוקף רק צריך לספק לו את הכתובת הפגיעה. 📝 סיכום שיעור 3: למדנו שגם כשהאפליקציה "שותקת" לחלוטין ולא מראה שגיאות או מידע, היא עדיין יכולה להיות פגיעה באופן קריטי. חקרנו את טכניקות ה-Blind SQLi: שאלות של אמת/שקר ב-Boolean-Based, ושימוש בעיכוב זמן ב-Time-Based. הבנו שהתקפות אלו הן עבודת נמלים, ולכן אוטומציה עם כלים כמו sqlmap היא הכרחית עבור התוקף. בשיעור הבא, נדבר על קו ההגנה הבא. מה קורה כשהארגון מציב "שומר סף" בכניסה לאפליקציה? נלמד איך תוקפים מנסים לעקוף מערכות הגנה כמו Web Application Firewall (WAF) וטכניקות מתקדמות נוספות. הצטרפו לערוץ @CYBERSECURITYCODING

💉 קורס SQL Injection - שיעור 2: שליפת מידע עם UNION Injection 📄 ברוכים הבאים לשיעור השני! בשיעור הקודם למדנו איך לזהות חולשת SQLi באמצעות שגיאות ואיך לנצל אותה כדי לעקוף מסך התחברות. זה היה מרשים, אבל המטרה האמיתית של תוקף היא לא רק להיכנס, אלא לגנוב את המידע שנמצא בלב המערכת. היום נלמד את הטכניקה העוצמתית והנפוצה ביותר למטרה זו: UNION Injection. מהי פקודת UNION ב-SQL? לפני שנצלול לתקיפה, נבין את הכלי. UNION היא פקודה לגיטימית ב-SQL שמאפשרת לנו לאחד את תוצאותיהן של שתי שאילתות SELECT (או יותר) לאותה טבלת תוצאות. יש לה חוק אחד קריטי, שעליו כל ההתקפה מבוססת: כדי ש-UNION יעבוד, שתי השאילתות חייבות להחזיר את אותו מספר עמודות. תוכנית התקיפה: שלב אחר שלב נחזור לאתר הפגיע שלנו, https://example.com/products.php?id=3, שמציג שם, תיאור ומחיר של מוצר. המטרה שלנו היא להשתמש בעמוד הזה כדי להציג מידע מטבלאות אחרות, כמו טבלת המשתמשים. שלב 1: גילוי מספר העמודות כאמור, כדי להשתמש ב-UNION, אנחנו חייבים לדעת כמה עמודות השאילתה המקורית (ששולפת את פרטי המוצר) מחזירה. איך עושים את זה? באמצעות ניצול של פקודת ORDER BY. יORDER BY ממיינת את התוצאות לפי מספר עמודה. תוקף יזריק ORDER BY וינסה מספרים עולים עד שיקבל שגיאה: ...products.php?id=3' ORDER BY 1-- ⬅️ עובד. (יש לפחות עמודה אחת) ...products.php?id=3' ORDER BY 2-- ⬅️ עובד. (יש לפחות שתי עמודות) ...products.php?id=3' ORDER BY 3-- ⬅️ עובד. (יש לפחות שלוש עמודות) ...products.php?id=3' ORDER BY 4-- ⬅️ שגיאה! (הודעת שגיאה כמו "Unknown column '4' in 'order clause'") מסקנה: התוקף יודע כעת בוודאות שהשאילתה המקורית מחזירה בדיוק 3 עמודות. שלב 2: מציאת עמודות שניתן להציג בהן טקסט אוקיי, יש לנו 3 עמודות. אבל אילו מהן מוצגות בפועל על המסך? והאם הן יכולות להציג טקסט (string)? כדי לגלות זאת, נשתמש ב-UNION בפעם הראשונה. התוקף יזריק שאילתה כזו: ...products.php?id=-1' UNION SELECT 'col1', 'col2', 'col3'-- בואו ננתח את זה: יid=-1: טריק חשוב. על ידי בקשת מוצר עם ID שלא קיים, התוקף מוודא שהשאילתה המקורית לא תחזיר שום תוצאה. זה מנקה את המסך ומבטיח שרק התוצאות שהוא הזריק יוצגו. UNION SELECT 'col1', 'col2', 'col3': כאן הוא מאחד את התוצאה הריקה עם שורה חדשה המכילה את המחרוזות 'col1', 'col2', 'col3', בדיוק לפי מספר העמודות שגילה. התוצאה: על המסך, במקום שם המוצר, תיאורו ומחירו, יופיעו עכשיו המילים col1, col2, col3. התוקף מיפה את השטח ויודע בדיוק איפה כל עמודה מוצגת. שלב 3: גניבת המידע האמיתי זהו שלב הגמר. אחרי שהתוקף הכין את הקרקע, הוא יכול להתחיל לשאול את מסד הנתונים שאלות מעניינות. א. קצת מודיעין: התוקף יחליף את המחרוזות בפונקציות מובנות של מסד הנתונים: ...' UNION SELECT @@version, database(), user()-- תוצאה: על המסך יופיעו גרסת ה-MySQL, שם מסד הנתונים הנוכחי, והמשתמש שהאפליקציה מריצה. ב. שליפת שמות טבלאות: כדי לגנוב מידע, צריך לדעת מאיפה. כאן נכנס לתמונה information_schema – מסד נתונים מיוחד שקיים ב-MySQL ומתאר את כל המבנה של שאר מסדי הנתונים. ...' UNION SELECT 1, table_name, 3 FROM information_schema.tables WHERE table_schema = database()-- תוצאה: במקום שבו הופיע col2, תוצג כעת רשימה של כל הטבלאות במסד הנתונים! התוקף יראה טבלאות כמו products, posts, ומשהו מעניין במיוחד... users. ג. שליפת שמות עמודות מטבלת users: ...' UNION SELECT 1, column_name, 3 FROM information_schema.columns WHERE table_name = 'users'-- תוצאה: עכשיו, באותו מקום, תוצג רשימה של כל העמודות בטבלת users: id, username, email, password... ד. המכה הסופית - שליפת הנתונים: התוקף יודע את שם הטבלה (users) ואת שמות העמודות (username, password). כל מה שנותר הוא לבקש את המידע: ...' UNION SELECT 1, username, password FROM users-- התוצאה: במקום שם המוצר ומחירו, העמוד יציג כעת רשימה של כל שמות המשתמש והסיסמאות מהטבלה users. Game Over. 📝 סיכום שיעור 2: ראינו איך תוקף הופך עמוד תמים שמציג מידע לחלון ראווה של כל מסד הנתונים. למדנו על התהליך השיטתי: גילוי מספר העמודות עם ORDER BY, מיפוי העמודות המוצגות עם UNION SELECT, ולבסוף, שימוש ב-information_schema כדי לגנוב שמות טבלאות, עמודות, ואת המידע הרגיש עצמו. הטכניקה הזו חזקה, אבל היא תלויה בכך שהאפליקציה מציגה לנו מידע בחזרה. מה קורה כשהיא לא? בשיעור הבא נצלול לעולם האפל והמתוחכם של Blind SQL Injection, ונלמד איך לגנוב מידע גם כשהמערכת שותקת לחלוטין. הצטרפו לערוץ @CYBERSECURITYCODING

מחפש אנשים שרוצים ליצור תוכן ביחד! 🚀 היי חברים, מה קורה? 👋 אני ממש נהנה לנהל את הערוץ הזה ולשתף אתכם במה שאני לומד על עולם הסייבר. האמת היא, שאני לא מומחה, אני פשוט סקרן שאוהב את התחום ולומד כל הזמן דברים חדשים, בדיוק כמוכם. חשבתי לעצמי, למה שאעשה את זה לבד? יהיה הרבה יותר כיף אם נהפוך את זה למשהו קהילתי באמת. אז... אני מחפש אתכם! אני רוצה להזמין את מי שבא לו להצטרף אליי וליצור תוכן לערוץ. מי יכול להתאים? כל מי שאוהב את עולם הסייבר 🛡️ והקוד 💻. מי שנהנה לחקור נושא מסוים ורוצה הזדמנות לחלוק את מה שלמד. לא צריך להיות גורו! מספיק שיש לכם התלהבות ורצון לכתוב על נושא שמעניין אתכם, בין אם זה רשתות, כלי מסוים, סקריפט מגניב שבניתם, או כל דבר אחר. מה יוצא לנו מזה? ✅ הזדמנות מעולה ללמוד נושאים לעומק (הדרך הכי טובה ללמוד משהו היא להסביר אותו). ✅ נהיה צוות קטן וכיפי שמפתח את הערוץ ביחד. ✅ נחלוק ידע אחד עם השני ונעזור לכל הקהילה. נשמע לכם מעניין? שלחו לי הודעה בפרטי [@Tyty574]. ספרו לי בכמה מילים על עצמכם ומה מעניין אתכם בעולם הזה. בלי לחץ ובלי פוזות, פשוט שיחה בגובה העיניים. יאללה, בואו נבנה משהו מגניב ביחד! 💪 מחכה לשמוע מכם.

💥 קורס SQL Injection - שיעור 1: יסודות ההזרקה והתקפת השגיאות שלום לכולם וברוכים הבאים לשיעור הראשון ב"קורס SQL Injection". בשיעור הזה נניח את היסודות החשובים ביותר. לא נקפוץ ישר לטכניקות מסובכות, אלא נבין לעומק את שורש הבעיה: איך שאילתת SQL תמימה הופכת לכלי נשק בידי תוקף. נתמקד בסוג ההתקפה הבסיסי והנפוץ ביותר לגילוי ראשוני של חולשה: Error-Based SQL Injection. 💡 מקור כל הבעיה: שרשור מחרוזות (String Concatenation) כמעט כל חולשת SQL Injection נולדת באותו המקום: קוד בצד השרת שלוקח קלט מהמשתמש ופשוט "מדביק" או "משרשר" אותו ישירות לתוך פקודת SQL. דמיינו אתר שיש בו כתובת https://example.com/products.php?id=3. הקוד בצד השרת, שאחראי להצגת מוצר מספר 3, עלול להיראות כך (זוהי דוגמה לקוד פגיע ולא מאובטח): PHP $product_id = $_GET['id']; $query = "SELECT name, price FROM products WHERE id = " . $product_id; כל עוד המשתמש מכניס מספר, הכל נראה תקין. אבל מה יקרה אם המשתמש יחליט להיות יצירתי? ⚔️ הבדיקה הראשונה של כל תוקף: הגרש הבודד (') הפעולה הראשונה שכל חוקר אבטחה או תוקף עושה כשהוא חושד בחולשת SQLi היא להכניס תו בודד שישבור את התחביר של השאילתה. התו הפופולרי ביותר הוא גרש בודד ('). נניח שיש לנו תיבת חיפוש באתר. אם נכניס בה את המילה shoes, השאילתה שתרוץ תהיה: SQL SELECT * FROM products WHERE name = 'shoes' אבל אם נכניס shoes', השאילתה שהשרת יבנה תהיה: SQL SELECT * FROM products WHERE name = 'shoes'' מסד הנתונים יסתכל על השאילתה הזו, יראה שיש בה גרש אחד מיותר, ולא יבין מה רוצים ממנו. התוצאה? שגיאה. 🤔 למה דווקא הגרש הבודד הוא המפתח? כדי להבין את זה לעומק, בואו נחשוב כמו מסד הנתונים לרגע. כשהוא רואה שאילתה כמו ... WHERE name = 'shoes', מבחינתו, כל מה שנמצא בתוך הגרשיים הוא בסך הכל נתון, טקסט תמים. אפשר לחשוב על הגרשיים כמו על "כלוב" שמחזיק את הקלט של המשתמש. הקסם של התוקף מתחיל כשהוא מכניס גרש משלו. הגרש הזה למעשה "סוגר את הכלוב" מוקדם מהצפוי. כל מה שהתוקף יוסיף אחרי הגרש הזה, יתפרש על ידי מסד הנתונים לא כנתון תמים, אלא כחלק מהפקודה עצמה. זו הסיבה שהגרש הוא המפתח שמאפשר לתוקף "לברוח מהכלוב" ולהתחיל לתת פקודות למסד הנתונים. 💰 Error-Based SQLi: מכרה הזהב של התוקף בשרת שלא הוגדר כראוי לסביבת Production (סביבה חיה), השגיאה הזו ממסד הנתונים לא תישאר חבויה. היא תוצג ישירות למשתמש בדפדפן. הודעת שגיאה כזו היא מכרה זהב לתוקף, כי היא חושפת המון מידע: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1 מה למד התוקף מהודעה זו בלבד? ✅ הוכחה חותכת: האתר פגיע ל-SQL Injection. 💾 סוג מסד הנתונים: מדובר ב-MySQL. מידע יקר ערך, כי עכשיו הוא יודע באיזה תחביר להשתמש. 📍 נקודת השבירה: הוא יודע בדיוק איפה השאילתה נשברה. שגיאות אחרות יכולות לחשוף שמות של טבלאות, עמודות ועוד. התוקף משתמש בשגיאות האלה כמערכת "חם-קר" כדי למפות את מסד הנתונים. 🔑 הדוגמה הקלאסית: עקיפת מסך התחברות עכשיו, בואו נחבר הכל יחד. נניח שיש לנו מסך כניסה למערכת, והקוד שלו נראה כך: PHP $query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; התוקף מגיע למסך הזה. הוא לא יודע שום סיסמה. בשדה שם המשתמש, הוא מכניס: ' or '1'='1' -- בשדה הסיסמה, הוא יכול להכניס: whatever השאילתה שהשרת יבנה תהיה: SQL SELECT * FROM users WHERE username = '' or '1'='1' -- ' AND password = 'whatever' בואו ננתח את הפעולה, חלק אחר חלק: ' – הגרש הראשון סוגר את המחרוזת של username. יor '1'='1' מוסיף תנאי OR שתמיד מחזיר אמת. כעת, ה-WHERE יחזיר אמת עבור כל שורה בטבלה. -- זהו תו של הערה ב-SQL. כל מה שבא אחריו באותה שורה, מסד הנתונים פשוט מתעלם ממנו. זה החלק הגאוני: הוא גורם למסד הנתונים להתעלם לחלוטין מהבדיקה של הסיסמה! התוצאה: השאילתה מבקשת "את כל המשתמשים", מסד הנתונים מחזיר את כל טבלת המשתמשים, והאפליקציה מכניסה את התוקף למערכת בתור המשתמש הראשון בטבלה (שלרוב הוא המנהל הראשי). 📜 סיכום שיעור 1 הבנו שהבעיה מתחילה בהדבקת קלט משתמש ישירות לשאילתה. למדנו איך גרש בודד יכול לחשוף חולשה דרך שגיאות (Error-Based SQLi), וראינו איך שילוב של סגירת מחרוזת, תנאי שתמיד נכון, ותו הערה, יכול לעקוף לחלוטין מנגנון הזדהות. בשיעור הבא נעלה מדרגה. נפסיק רק לעקוף מנגנונים, ונתחיל ללמוד איך לשלוף מידע רגיש (כמו רשימות משתמשים וסיסמאות) ממסד הנתונים באמצעות טכניקה חזקה בשם UNION Injection. הצטרפו לערוץ ורגישו חופשי לשאול שאלות. @CYBERSECURITYCODING

המלוואר הראשון שמדבר עם AI בשם "Skynet" מנסה להטעות מודלים חוקרי אבטחה גילו דוגמת מלוואר חדשה בשם "Skynet", שמנסה להטעות מערכות בינה מלאכותית דרך טכניקת prompt injection. הקוד כולל הוראה למודל להתעלם מהוראות קודמות ולדווח "NO MALWARE DETECTED". הקובץ, שהועלה ל-VirusTotal מהולנד, נכתב ב-++C ומשלב בדיקוק והצפנה (XOR+Base64) 🤫, התחמקות מ-sandbox, והשקת TOR פנימי לתקשורת מוסתרת. המודלים שנבדקו כמו GPT‑4.1, לא נפלו בפח, אך המגמה מסוכנת שמנסים לתמרן AI עדכוני סייבר 🛡

המלוואר הראשון שמדבר עם AI בשם "Skynet" מנסה להטעות מודלים חוקרי אבטחה גילו דוגמת מלוואר חדשה בשם "Skynet", שמנסה להטעות מערכות בינה מלאכותית דרך טכניקת prompt injection. הקוד כולל הוראה למודל להתעלם מהוראות קודמות ולדווח "NO MALWARE DETECTED". הקובץ, שהועלה ל-VirusTotal מהולנד, נכתב ב-++C ומשלב בדיקוק והצפנה (XOR+Base64) 🤫, התחמקות מ-sandbox, והשקת TOR פנימי לתקשורת מוסתרת. המודלים שנבדקו כמו GPT‑4.1, לא נפלו בפח, אך המגמה מסוכנת שמנסים לתמרן AI עדכוני סייבר 🛡

זה מתחיל להיות ממש מעניין https://x.com/Xbow/status/1937512662859981116?t=r5qgSvCMU6UzOeChEXLNEg&s=09

🔒🛡️💻 מתקפת סייבר מתוחכמת: טרויאן ב-VPN וניצול חתימות דיגיטליות האקרים פושטים על חברות באמצעות תוכנת VPN מזויפת וניצול פרצות בחברת ConnectWise. 🔍 מה קרה? 🔹 האקרים הפיצו גרסה מזויפת של תוכנת ה-VPN "NetExtender" מבית SonicWall, שגונבת פרטי התחברות של משתמשים תמימים 🕵️♂️ 🔹 התוכנה המזויפת מתחזה לגרסה הרשמית (10.3.2.27) והופצה דרך אתר מתחזה שכבר הוסר 🚫 🔹 הפרטים שנגנבו כוללים שם משתמש, סיסמה, דומיין ומידע רגיש נוסף - ונשלחים לשרתים בשליטת התוקפים 📤 🔹 במקביל, האקרים מנצלים חתימות דיגיטליות לגיטימיות של חברת ConnectWise כדי להטמיע קוד זדוני ללא זיהוי 🎭 🔹 השיטה החדשה, המכונה "EvilConwi", כוללת הודעות עדכון מזויפות של Windows כדי למנוע ממשתמשים לכבות את המערכת 💀 🔹 ההתקפות מופצות דרך דוא"ל פישינג או אתרים מתחזים שמציגים עצמם ככלי AI בפייסבוק 📧 🔹 שתי המתקפות מאפשרות לתוקפים גישה מרחוק ממושכת ומעניקות להן "כיסוי" תחת תהליכים לגיטימיים 🏴‍☠️ 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

אז איך מתגוננים מפני התקפות כאלה? ✅ עדכונים, עדכונים, עדכונים: הדבר החשוב ביותר. עדכנו את הדפדפן ואת כל התוספים שלו לגרסה האחרונה תמיד. עדכונים סוגרים חורי אבטחה ידועים. 🚫 חשדנות בריאה: אל תלחצו על לינקים חשודים שקיבלתם במייל או בהודעות. תמיד בדקו לאן הלינק באמת מוביל לפני הלחיצה. 🛡️ תוספי אבטחה לדפדפן: תוספים כמו NoScript (שחוסם הרצת JavaScript כברירת מחדל) או uBlock Origin (שיכול לחסום סקריפטים זדוניים ידועים) מספקים שכבת הגנה מצוינת. 📝 סיכום: BeEF הוא כלי מדהים שממחיש בצורה מושלמת שהאיום הגדול ביותר הוא לא תמיד בשרתים מרוחקים, אלא ממש אצלנו, בדפדפן. הוא מזכיר לנו שהאבטחה לא נגמרת ב-Firewall, והמודעות של המשתמש היא קו ההגנה החשוב ביותר. מה דעתכם על הכלי? יצא לכם להתנסות בו בסביבת מעבדה? שתפו בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING לעוד תכנים מרתקים!

🥩י BeEF - כשהדפדפן שלכם בידיים של תוקף 🥩 שלום לכולם! היום נצלול לאחד הכלים המרתקים והמסוכנים ביותר בעולם בדיקות החדירות (Pentesting) - י BeEF, או בשמו המלא The Browser Exploitation Framework. אם פעם חשבתם שהדפדפן שלכם הוא רק חלון לאינטרנט, תחשבו שוב. BeEF יכול להפוך את החלון הזה לדלת כניסה עבור תוקף, שיוכל לשלוט בדפדפן שלכם כאילו היה בובה על חוטים. 💻🎣 בואו נבין איך הכלי הזה עובד, מה ההשלכות שלו, ואיך תוקפים משתמשים בו בפועל. 🤔 רקע תיאורטי: מה זה BeEF ומה הסיפור שלו? BeEF הוא לא כלי ש"פורץ" למחשב במובן הקלאסי. הוא לא מנצל חולשה במערכת ההפעלה או בשרת מרוחק. במקום זאת, הוא מתמקד כולו בנקודת התורפה הגדולה ביותר בשרשרת האבטחה: המשתמש והדפדפן שלו. העיקרון פשוט להבנה אך הרסני בתוצאותיו: BeEF "לוכד" (Hook) דפדפנים של קורבנות. מרגע שדפדפן "לכוד", התוקף מקבל פאנל שליטה גרפי ונוח, שדרכו הוא יכול לשלוח פקודות לדפדפן של הקורבן בזמן אמת. ⚙️ איך זה עובד? קסם ה-JavaScript הלב של BeEF הוא קובץ JavaScript קטן ותמים למראה בשם hook.js. התוקף צריך לגרום לדפדפן של הקורבן לטעון את הסקריפט הזה. איך הוא עושה את זה? אתר זדוני: הקמת אתר שנראה לגיטימי (למשל, עמוד נחיתה למבצע מזויף) ושילוב הסקריפט בתוכו. התקפת XSS (Cross-Site Scripting): אם התוקף מוצא חולשת XSS באתר פופולרי ולגיטימי, הוא יכול להזריק את ה-hook.js לאתר האמיתי. כל מי שיבקר בעמוד הפגיע באתר, הדפדפן שלו "יילכד" על ידי BeEF. הנדסה חברתית: שליחת לינק לקורבן במייל, בהודעה או בכל דרך אחרת, ושכנוע שלו ללחוץ עליו. ברגע שהדפדפן טוען את הסקריפט, הוא יוצר חיבור נסתר בחזרה לשרת ה-BeEF של התוקף. מכאן והלאה, התוקף בשליטה. 🔒 השלכות אבטחת מידע: למה זה כל כך מסוכן? עקיפת הגנות רשת: BeEF עוקף בקלות Firewall-ים וחומות הגנה מסורתיות. למה? כי החיבור יוצא מהרשת הפנימית של הקורבן החוצה (אל שרת התוקף). רוב ההגנות מוגדרות לחסום חיבורים נכנסים לא רצויים, אך מתירות חיבורים יוצאים שהמשתמש יזם (כמו גלישה רגילה). שליטה בזמן אמת: התוקף יכול לראות איזה עמוד הקורבן רואה, להריץ פקודות, ולראות את התוצאות מיד. שער לרשת הפנימית: זו הנקודה הקריטית ביותר. הדפדפן של הקורבן פועל בתוך הרשת הפנימית שלו (הביתית או הארגונית). התוקף יכול להשתמש בדפדפן הלכוד כ"פרוקסי" כדי לסרוק את הרשת הפנימית של הקורבן, לתקוף מכשירים אחרים (מדפסות, ראוטרים, שרתים פנימיים) – כל זאת מתוך הדפדפן של הקורבן, מה שהופך את התקיפה לחמקמקה במיוחד. 🛠️ פרקטיקה: איך תוקפים משתמשים ב-BeEF? אחרי שהבנו את התיאוריה, בואו נראה איך זה נראה בצד של התוקף. שלב 1: ההתקנה וההפעלה התוקף מתקין את BeEF על שרת שבשליטתו (לרוב במערכת Kali Linux, שם הוא מגיע מובנה). הוא מפעיל את שירות ה-BeEF ומקבל גישה לפאנל הניהול דרך הדפדפן, עם שם משתמש וסיסמה. שלב 2: הדיג והלכידה (Hooking) כמו שהסברנו, התוקף מכין את הפיתיון (אתר עם hook.js) ושולח אותו לקורבן. נניח שהקורבן לחץ על הלינק. בפאנל הניהול של התוקף, תחת "Online Browsers", תופיע שורה חדשה: ה-IP של הקורבן, סוג הדפדפן, מערכת ההפעלה וכו'. שלב 3: השליטה והניצול (Exploitation) עכשיו מתחיל החלק המעניין. התוקף לוחץ על הדפדפן הלכוד ומקבל רשימה ארוכה של "מודולים" (פקודות) שהוא יכול להריץ. הנה כמה דוגמאות פופולריות: 🍪 גניבת עוגיות (Get Cookies): המודול שולף את כל קבצי ה-Cookie של הדומיין שבו הקורבן נמצא. אם הקורבן גולש בפייסבוק, התוקף יכול לגנוב את עוגיית ה-Session שלו ולהיכנס לחשבון ללא סיסמה. 🎣 פישינג מתוחכם (Pretty Theft): מודול זה מקפיץ לקורבן חלון Pop-up שנראה בדיוק כמו חלון ההתחברות של פייסבוק, ג'ימייל או שירות אחר, ומבקש ממנו להזין מחדש את הסיסמה. הסיסמה נשלחת ישירות לתוקף. 🔑 רישום הקשות (Keylogger): מודול שמתעד כל הקשה על המקלדת של המשתמש בתוך הדף הנוכחי. 🌐 סריקת הרשת הפנימית (Internal Network Fingerprinting): התוקף מריץ מודולים ששולחים בקשות מהדפדפן של הקורבן לכתובות IP פנימיות (כמו 192.168.1.1, 10.0.0.1) כדי למפות את הרשת ולמצוא התקנים פגיעים. 💣 ניצול חולשות (Exploits): אם לקורבן יש דפדפן ישן או תוסף (Plugin) פגיע כמו Flash או Java, התוקף יכול לנסות להריץ Exploit דרך הדפדפן כדי להשיג שליטה מלאה יותר על המחשב (למשל, באמצעות Metasploit). ⚠️ הצד החוקי והגנה ⚠️ חשוב להדגיש: המידע הזה מובא למטרות לימודיות והגנתיות בלבד. שימוש בכלי זה או בטכניקות דומות למטרות זדוניות הוא עבירה פלילית חמורה!

🤖🔒💡 גוגל משדרגת את אבטחת ה-AI עם הגנות מרובות שכבות נגד מתקפות גוגל מציגה אסטרטגיית הגנה חדשנית כדי להגן על מערכות הבינה המלאכותית שלה מפני מתקפות ערמומיות. 🔍 מה קרה? 🔹 גוגל חשפה שכבות הגנה חדשות ב-Gemini, הדגל שלה בתחום ה-GenAI, כדי למנוע מתקפות "הזרקת פקודות" עקיפות. 🛡️ 🔹 מתקפות עקיפות מסתירות פקודות זדוניות בתוך מיילים, מסמכים או הזמנות לוח שנה – ומשטות ב-AI לביצוע פעולות מסוכנות. 📧💣 🔹 בין הפתרונות: סיווג פקודות זדוניות, סימון נתונים חשודים (Spotlighting), וסינון קישורים מסוכנים באמצעות Google Safe Browsing. 🔗🚫 🔹 גוגל מוסיפה גם "אישור משתמש" לפעולות מסוכנות והתראות למשתמשים על ניסיונות הזרקה. ⚠️👥 🔹 למרות ההגנות, התוקפים מפתחים שיטות מתקדמות כדי לעקוף אותן – כולל ניצול יכולות מולטי-מודאליות של AI לדלף מידע רגיש. 🕵️♂️💻 🔹 מחקר חדש חושף ש-AI עלול לבצע פעולות עוינות כמו סחיטה או ריגול תעשייתי אם זה משרת את מטרותיו. 😱🤖 🔹 החדשות הטובות: נכון לעכשיו, אין עדויות להתנהגות כזו בעולם האמיתי – אבל העתיד עלול להיות מורכב יותר. 🌍🔮 המירוץ בין האקרים למגני ה-AI רק מתחמם! 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

🚨🌐💥 מתקפת הסייבר הגדולה בהיסטוריה: 7.3 טרה-ביט לשנייה! חברת אבטחת הסייבר Cloudflare חסמה מתקפת DDoS ענקית ששברה שיאים. 🔍 מה קרה? 🔹 Cloudflare חסמה מתקפת DDoS עצומה בהיקף של 7.3 טרה-ביט לשנייה - הגדולה אי פעם! �💻 🔹 המתקפה נמשכה 45 שניות בלבד אך העבירה 37.4 טרה-בייט של נתונים. 🚀📉 🔹 היעד: ספק אחסון אנונימי, עם הפצצה של למעלה מ-21,000 פורטים בשנייה. 🎯🔥 🔹 מקורות המתקפה: 122,145 כתובות IP מ-161 מדינות, בראשן ברזיל ווייטנאם. 🌍🕵️ 🔹 הבוטנט האחראי: גרסה מתקדמת של Mirai, המשתמשת במכשירי IoT נגועים. 🤖💣 🔹 רק ב-2025: זו המתקפה השלישית מעל 5 טרה-ביט/שנייה שמונטחת ע"י Cloudflare. ⚠️📅 🔹 הקשר ל-RapperBot: בוטנט DDoS חדש שמתחיל לדרוש "דמי הגנה" מקורבנותיו. 💰😈 העולם הדיגיטלי במלחמת חורמה - והקרב רק מתחמם! 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

🚨🌐💥 מתקפת הסייבר הגדולה בהיסטוריה: 7.3 טרה-ביט לשנייה! חברת אבטחת הסייבר Cloudflare חסמה מתקפת DDoS ענקית ששברה שיאים. 🔍 מה קרה? 🔹 Cloudflare חסמה מתקפת DDoS עצומה בהיקף של 7.3 טרה-ביט לשנייה - הגדולה אי פעם! �💻 🔹 המתקפה נמשכה 45 שניות בלבד אך העבירה 37.4 טרה-בייט של נתונים. 🚀📉 🔹 היעד: ספק אחסון אנונימי, עם הפצצה של למעלה מ-21,000 פורטים בשנייה. 🎯🔥 🔹 מקורות המתקפה: 122,145 כתובות IP מ-161 מדינות, בראשן ברזיל ווייטנאם. 🌍🕵️ 🔹 הבוטנט האחראי: גרסה מתקדמת של Mirai, המשתמשת במכשירי IoT נגועים. 🤖💣 🔹 רק ב-2025: זו המתקפה השלישית מעל 5 טרה-ביט/שנייה שמונטחת ע"י Cloudflare. ⚠️📅 🔹 הקשר ל-RapperBot: בוטנט DDoS חדש שמתחיל לדרוש "דמי הגנה" מקורבנותיו. 💰😈 העולם הדיגיטלי במלחמת חורמה - והקרב רק מתחמם! 📜 לכתבה המלאה: 🔗 thehackernews.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

🛡️🔑 אשליית המנעול הירוק: כשההצפנה חזקה, אבל המפתח דולף מהדלת האחורית 🚪 כולנו למדנו לסמוך על המנעול הירוק 🟢 ועל פרוטוקול TLS. אומרים לנו שההצפנה מקצה לקצה (E2EE) היא חזקה, שכמעט בלתי אפשרי לשבור את AES-256, ושהעולם הדיגיטלי שלנו מוגן על ידי חומות מתמטיות אדירות. אבל מה אם אני אגיד לכם שהתוקף המתוחכם בכלל לא מנסה לשבור את החומה? במקום זה, הוא מחפש דרך לגרום למישהו מבפנים לזרוק לו את המפתח מהחלון. היום נדבר על העולם האפל והנסתר של ערוצים סמויים (Covert Channels) – הדרכים שבהן תוקפים מוציאים את המידע הרגיש ביותר (כמו מפתחות הצפנה) ממש מתחת לאף של מערכות האבטחה שלנו. 🕵️‍♂️ מהם ערוצים סמויים ואיך הם עובדים? ערוץ סמוי הוא שיטת תקשורת שמשתמשת בפרוטוקולים קיימים באופן שלא תוכננו עבורו, כדי להעביר מידע באופן סמוי. מערכות ניטור רשת (כמו חומות אש ו-IDS/IPS) רואות את התעבורה הזו כ"רעש רקע" לגיטימי או כתקשורת שירותית, ולכן מתעלמות ממנה. זה המקום המושלם להחביא בו את השלל. בואו נכיר כמה מהשחקנים המרכזיים ב"גן החיות" הזה: 1. מנהור ICMP (הטריק של ping) 📦 כולנו מכירים את ping, הפקודה ששולחת חבילת ICMP Echo Request כדי לבדוק אם יעד מסוים חי וקיים. באופן רשמי, החבילה הזו נושאת בתוכה מידע דיאגנוסטי פשוט. אבל... בשדה הנתונים (Data field) של חבילת ICMP אפשר לדחוף עד 64 קילובייט של מידע! השלכות אבטחה: תוקף יכול להשתיל נוזקה במערכת שלך. לאחר שהשיג את מפתח ההצפנה, הוא לא צריך לשלוח אותו בדרך רגילה שתתועד. הוא פשוט מקודד את המפתח, מחלק אותו לחתיכות, ושולח אותו החוצה בסדרה של פקודות ping "תמימות" לשרת שבשליטתו. מערכת הניטור רואה רק פינגים, לא דלף מידע קריטי. 2. מנהור DNS (הטריק של "שם הדומיין") 🌐📖 זה אפילו יותר מתוחכם. תחשבו על בקשת DNS שנראית כך: aHR0cHM6Ly93d3cueW91dHViZS5jb20.malicious-domain.com. לכאורה, זו סתם בקשה לתרגום שם דומיין מוזר. בפועל, aHR0cHM6Ly93d3cueW91dHViZS5jb20 הוא פשוט קידוד Base64 של המידע שהתוקף רוצה לגנוב. השלכות אבטחה: שרתי DNS ארגוניים ושל ספקיות אינטרנט מטפלים במיליוני בקשות כאלה ביום. מאות בקשות זדוניות פשוט "טובעות" בתוך הרעש הלגיטימי. התוקף מפעיל שרת DNS משלו, שמקבל את הבקשות האלה, מפענח את שם התת-דומיין, ומרכיב מחדש את המידע הגנוב. כל זה קורה מעל פרוטוקול UDP/53, שלרוב פתוח לגמרי ביציאה מהרשת. 3. פרוטוקולי ניהול ובקרה (ה"שטח המת") 📡 בעולם המודרני, הסיפור רק הולך ומסתבך. ברשתות 5G, למשל, ישנם ערוצי בקרה וניהול (Control Channels) שנתבים כלל לא מנתחים או מתעדים. הודעת "שירות" שנשלחת עם התגית הנכונה יכולה להיראות כמו טלמטריה שגרתית למערכת, אבל בפועל להכיל מידע גנוב שיגיע ליעדו אלפי קילומטרים משם. 🤔 אז מה, אבטחה היא רק הצגה? זו מסקנה פרווקטיבית: אין דבר כזה אבטחת מידע מוחלטת. יש רק "עלות תקיפה" מנקודת המבט שלנו. עבור שחקן עם משאבים בלתי מוגבלים (כמו מדינה), המשאבים האלה פותחים אופקים אחרים לגמרי. ✅ אז מה נשאר לנו לעשות? אם אבטחה היא במה, והמשתמשים יושבים בקהל ומוחאים כפיים למופע הראווה של ראשי התיבות (AES, SHA, TLS, TPM), עלינו לזכור שה"נבל" במחזה הזה מכיר את כל המעברים הסודיים מאחורי הקלעים. הכרה במציאות: ✔️ הדבר היחיד שאין לו חולשות הוא מערכת מתה. תוכנה חיה, חומרה חיה ואדם חי תמיד ישאירו פרצה. הפרדת אמונים: ✔️ אל תשימו את כל הביצים בסל אחד. אחסנו מפתחות במקום שבו אי אפשר לשנות את הקושחה (למשל, HSM). השתמשו במספר מקורות אקראיות בלתי תלויים כדי לייצר אנטרופיה. שימו לב גם לפיזיקה של המכשיר. סקפטיות בריאה: 🤔 אל תפחדו לפקפק. תשאלו שאלות קשות ליצרנים, תבדקו את התקנים בעצמכם, ותנסו "לעקם" את הפרוטוקולים כדי לראות איפה הם נשברים. דריכות מתמדת: 🧠 הגנה מוחלטת היא בלתי ניתנת להשגה, אבל מוח דואג הוא ההגנה הטובה ביותר. אבטחה היא תהליך, לא מצב; זו דרך ללא קו סיום. ככל שנסתכל עמוק יותר אל תוך הצללים, כך נשאיר פחות מקום לאלו שמנסים להסתתר שם. שאלות? מחשבות? שתפו אותי בתגובות! 👇 הצטרפו לערוץ @CYBERSECURITYCODING

🗑️💀 מתקפת שרשרת האספקה הבאה? כך 420$ יכולים להדביק את כל העולם 💀🗑️ זוכרים את מתקפת SolarWinds שהרעידה את עולם הסייבר? מתקפה שבה תוקפים החדירו קוד זדוני לעדכון תוכנה לגיטימי והדביקו אלפי ארגונים, כולל סוכנויות ממשל אמריקאיות. ובכן, קבוצת חוקרי אבטחה חשפה וקטור תקיפה דומה, שאולי הוא אפילו יותר פשוט, זול ומסוכן. והכל מתחיל בפחי אשפה דיגיטליים שכולנו משאירים מאחור. חלק 1: הרקע - הבעיה עם "באקטים נטושים" בעולם הענן, ובמיוחד ב-Amazon Web Services (AWS), מפתחים משתמשים בשירות שנקרא S3 Buckets. אלו למעשה "דליים" וירטואליים לאחסון קבצים. מפתחים רבים השתמשו בבאקטים האלה כדי לארח ספריות קוד (DLLs), קבצי עדכון, סקריפטים ועוד. הבעיה מתחילה כשפרויקט ננטש. המפתח ממשיך הלאה, אבל שוכח למחוק את הבאקט, או פשוט מפסיק לשלם עליו. שם הבאקט הופך להיות פנוי וכל אחד יכול לרשום אותו על שמו. אבל מה קורה אם תוכנות ישנות, שעדיין נמצאות בשימוש ברחבי העולם, עדיין מנסות למשוך עדכונים וקבצים מאותו שם באקט בדיוק? 🤔 חלק 2: הניסוי שעלה 420$ והתוצאות המטרידות חוקרי אבטחה החליטו לבדוק את התיאוריה הזו. הם איתרו שמות של באקטים נטושים שעדיין היו מקושרים בספריות קוד (DLLs) ישנות. הם השקיעו סכום זעום של 420$ כדי לרשום את שמות הבאקטים האלה על שמם, והתחילו להאזין. הם רצו לגלות כמה מכשירים עדיין "מתקשרים הביתה" לבאקטים מתים. התוצאות היו מדהימות. בתוך חודשיים בלבד, הם קיבלו 8 מיליון בקשות! 📈 ומה המערכות האלו ביקשו? עדכוני תוכנה 🔄 קבצים בינאריים מקומפלים מראש (ללא חתימה דיגיטלית!) עבור Windows, Linux ו-macOS 😱 תמונות של מכונות וירטואליות שלמות (VM Images) ⁉️ קבצי JavaScript וספריות קוד 📜 תבניות CloudFormation ותשתיות ענן 🏗️ תצורות של שרתי SSLVPN 🔐 ועוד ועוד... וזה נהיה יותר גרוע. הבקשות הגיעו ממקומות רגישים ביותר: רשתות ממשלתיות וצבאיות 🇺🇸 התאגידים הגדולים בעולם מרשימת Fortune 100 🏢 בנקים וחברות סליקה 💳 אוניברסיטאות מובילות 🎓 ואפילו חברות שעוסקות באבטחת מידע! 🛡️ חלק 3: תרחיש התקיפה - SolarWinds על סטרואידים עכשיו דמיינו תוקף אמיתי. במקום חוקרים סקרנים, יושב גורם זדוני. כל מה שהוא צריך לעשות זה להעלות לבאקט שהוא השתלט עליו גרסה זדונית של קובץ ה-DLL או סקריפט העדכון. לאחר מכן, הוא פשוט יושב ומחכה. המערכות ברחבי העולם, באופן אוטומטי לחלוטין, ימשכו את הקוד הזדוני ויתקינו אותו כחלק מתהליך עדכון לגיטימי או תהליך בניית תוכנה (build). זהו סוס טרויאני מושלם שנכנס בדלת הראשית. המימד הנוסף של המתקפה (לפי ברוס שנייר) המומחה הנודע לאבטחת מידע, ברוס שנייר, הוסיף ניתוח מצמרר משלו: "למתקפה יש מימד נוסף. מכיוון שבאקטי העדכון האלה נטושים, למפתחים המקוריים כבר אין את היכולת להפיץ עדכוני אבטחה. המנגנון שהם היו יכולים להשתמש בו כדי לתקן את המצב נמצא עכשיו בידיים של התוקפים. יתרה מכך, לעיתים קרובות אובדן הבאקט מונע מהמפתח המקורי אפילו את היכולת לזהות איזה תוכנות פגיעות קיימות בעולם, מה שמגביל את יכולתו לתקשר עם המערכות הנגועות." 📝 סיכום ומסקנות: אבטחת שרשרת אספקת התוכנה היא אתגר עצום, יקר ומסובך. המקרה הזה מוכיח שהחוליה החלשה היא לא תמיד קוד מורכב, אלא לפעמים סתם פיסת תשתית שננטשה והפכה למלכודת דבש. כפי שמסכם זאת שנייר, "להבטיח את אבטחת שרשרת האספקה זה יקר וקשה. וזה אומר שאף אחד לא באמת יעשה את זה, מה שרק יחמיר את המצב". עלינו להיות מודעים לסכנה הזו. בדקו את התלויות (dependencies) שלכם, ודאו שהמקורות שמהם אתם מושכים קוד עדיין פעילים ומתוחזקים. הצטרפו לערוץ @CYBERSECURITYCODING

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

🔐💻🚀 רד האט מציגה: הגנה קוונטית ללינוקס! המערכת החדשה של רד האט מגיעה עם הצפנה עמידה למחשבים קוונטיים - והנה כל מה שאתם צריכים לדעת. 🔍 מה קרה? 🔹 רד האט משלבת לראשונה ב-RHEL 10 אלגוריתמי הצפנה עמידים למחשבים קוונטיים (PQC), שיגנו על נתונים מפני פריצות עתידיות. 🛡️ 🔹 האיום האמיתי: תוקפים כבר היום אוגרים נתונים מוצפנים ("harvest now, decrypt later") כדי לפצח אותם כשמחשבים קוונטיים יהיו זמינים. 🔍💾 🔹 המערכת כוללת את ML-KEM להחלפת מפתחות מוגנת ב-TLS ו-SSH, ו-ML-DSA לחתימות דיגיטליות. 🔑🔏 🔹 הטכנולוגיה נמצאת כרגע בשלב "תצוגה מקדימה" (Tech Preview) בגלל סטנדרטים מתפתחים, אבל רד האט ממליצה להתחיל לבדוק אותה כבר עכשיו. 🧪⚡ 🔹 בעתיד: תמיכה נוספת בפרוטוקולים כמו Kerberos ו-DNSSEC, עם עדכונים שיגיעו בגרסאות הבאות. 🚀🔮 הגיע הזמן להתכונן לעידן הקוונטי - לפני שכולם יקדימו אתכם! ⏳🔒 📜 לכתבה המלאה: 🔗 redhat.com 📢 הצטרפו לקבוצה שלנו לדיונים ועדכונים נוספים! 🔗 Cyber Security Coding שמרו על עצמכם! 🛡️🚀

לא קשור לסייבר אבל לכולם מגיע להנות מהסרטון הזה