כנס אבטחת מידע – OWASP AppSec Israel 2015

ביום שלישי, ה-13 באוקטובר 2015 התקיים כנס AppSec Israel 2015. זו הפעם השניה שאני משתתפת בכנס, והוא תמיד מעניין – זה כיף לראות איך פורצים, ולשמוע סיפורי הצלחה של אבטחה.

הלו”ז של הכנס נמצא כאן.

עריכה: יש סרטונים של כל ההרצאות, מצגות של כל ההרצאות, ותמונות מהכנס.

הרצאה מרכזית – ג’רמיה גרוסמן מ-Red Rat

תקציר ההרצאה

ג’רמיה סיפר איך התחיל את דרכו בתחום אבטחת המידע. לפני 15 שנה, בשנת 2000, פורסם שמישהו מצא חולשות באמאזון, ביאהו ובעוד אתר. ג’רמיה לא התרגש, מאחשר שנראה היה לו סביר שבאתרים כאלה תהיינה  פרצות אבטחה. מה שכן הקפיץ אותו היה ההודעה של האתרים הללו לאחר שהם תיקנו את הפרצות: הן טענו שכעת האתרים שלהם מוגנים.
ג’רמיה אוהב לשבור דברים (דבר שנוהג לעצבן את ילדיו…), ואמירה כזו היוותה הרמה להנחתה מבחינתו: הוא פתח לעצמו חשבון ביאהו, וחיפש דרכים לפרוץ למערכת. אחרי שהוא מצא דרך, הוא הודיע על זה ליאהו. הם בתמורה התרשמו, ונתנו לו חולצה. הם גם ביקשו שימשיך לחפש פרצות. הוא הסכים ברצון ונכנס לקשר דואלים עם מנכ”ל יאהו.
יום בהיר אחר הוא קיבל מיאהו זימון לראיון. לא היו לו שום ציפיות כי אין לו שום הכשרה בתחום, ובראיון עצמו, בו הם ניסו להתקיל אותו בכל דרך בתחום, הוא לא ידע לענות על שום שאלה…הוא היה בטוח שהוא נכשל בראיון, אבל להפתעתו הם הציעו לו משכורת משולשת ממה שהוא הרויח באותו זמן. אז הוא התחיל לעבוד ביאהו

חזרה לימינו אנו. ג’רמיה התחיל עם כמה שאלות: .

• איך מגדילים (scale) אבטחת מידע?
• איך להציע למשתמשים שירות ולא מוצר?
• איך לטפל בכל האתרים בכל הזמן?

ואז הוא התחיל להראות נתונים:

• מי תוקף את האתרים שלנו?
  • הפוליטיים. תוקפים ולועגים. הם מזיקים ומעצבנים אבל לא מדאיגים.
  • עברייני רשת ושלוחי מדינות הם מפחידים כי הם עקשנים – משלמים להם והם יעשו מה שצריך.
• איך תוקפים?
  • גניבת זהות (50%)
  • דלת אחורית (40%)
  • SQL (כ-20%) – הם תוקפים אתר שאתה לא זוכר שיש לך, ודרכו נכנסים לאתרים האחרים. הם בוחרים איך ומה הם תוקפים.

לוקח המון ימים לתקן פריצות. מי שרוצה  לחדש בתחום אבחת מידע – שימצא דרך לקצר את הזמנים.

50% מהארגונים מניחים שהם יותקפו ב-12 החודשים הבאים, לא משנה מה ינסו לעשות כדי למנוע את זה. סוג של אפטיות מעציבה.

מה אפשר לעשות? לקנות ביטוח. אנשים מעדיפים לא להשקיע במניעה אלא בפיצוי.

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

כשהוא מספר את הדברים הללו, הוא בד”כ נשאל מה עושים ה-Red Hat בתחום הזה. התשובה שלו היא שהם מנתחים את הדברים שהם לא צפו ושהיו צריכים לצפות (אין הרבה כאלה), ומנסים ללמוד מהם. כתוצאה מכך  כעת הם מציעים עסקה לאתרים: אם האתרים מתקנים את הפרצות, אז Red Hat מתחייבת שאם האתר נפרץ הם יחזירו את ההכסף, ואת חצי המליון הראשון של ההפסדים.

לפי הנתונים על החברה ב-3 מדדים, אפשר לדעת מה כדאי לשפר.

האינטרנט הוא ההמצאה הכי חשובה שנחווה בחיינו. עושים בו הכל, והוא מחבר 2 מיליארד אנשים. לכן עבודה על אבטחת המקום הזה היא דרך טובה לבלות את זמנו.

 

 מת לחיות 0x3E9

תקציר ההרצאה

המרצה דיבר על נסיונות שילוב של תוצאות של כלי ניתוח סטטיים וידנמיים ל- Reverse engineering. מתברר שהיו נסיונות כאלה לאורך השנים:

• IDA –splode
• FUncap – צולל לתוך IDA. היתרון שלו הוא שהוא הופך את השורה למחרוזת.

מה הבעיות בהן?

• המידע הוא ענק ובלתי מאונדקס, ואי אפשר לערוך חיפוש
• קושי להוסיף פונקציונליות מותאמת אישית.

לכן הוא פיתח כלי משלו, פלגאין ל-IDA, בשם DIE, ר”ת של Dynamuc IDA  Enrichment. הפלגאין הזה מאפשר לקבל ערכים של משתנים, והוא הראה בהרצאה איך הוא עושה זאת.

הוא רצה לחפש function argument type. הוא מצא את המשתנה tinfo_t, שמכיל ים של מידע על כל מיני משתנים. מאחר שלכל משתמש ישנם המשתנים המעניינים אותו,  הוא בנה אפשרות לחבר לפלגאין שלו פלגאין שיבקש ערכים של ארגומנטים מסויימים. המוצר שלו צריך לדעת לנתח את הטיפוסים ולהחזיר את הערך כראוי. הוא הסביר איך הוא עשה זאת עבור משתנים בוליאניים, עבור פוינטרים, ועבור מערכים.

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

 

From zero to secure in 1 minute

תקציר ההרצאה

הנושא של ההרצאה היה איך לאבטח אתרים השוכנים בענן (IaaS), ובאופן ספציפי, אבטחה של שכבת ה-orcastration.

לפני כמה חודשים היתה פריצה ל-BrowserStack. האקר סרק אותם גילה שרת בלתי מפוצ’פץ’. מתברר שזה שרת שהרימו לפני שנתיים ושכחו ממנו. הוא מצא api key נועד ל-auot scaling (פונה ל-management platform של אמאזון ומבקש להרים עוד שרת). חוץ מזה התברר שמי שהגדיר את המפתח הזה לא נתן לו את ההרשאות הנכונות, ולכן הפורץ הצליח לפתוח פורט ולהלבין לעצמו כתובת ב-firewall והקים לעצמו שרת חדש. מהשרת הזה הוא התחבר וחיבר אליו דיסק גיבוי. בתוך הדיסק מצא הרשאות ל-DB. הפורץ ניסה למשוך את כל רשימת הלקוחות אבל עשה טעות ונעל את כל הרשומות וזה הקפיץ את המערכת. אלמלא כן, הוא היה יכול להמשיך את מסע הנזקים שלו.

כל חברה שמפתחת בסביבות ענן רוצה לחסום ולטפל בדברים הללו. השאלה היא אם יש לנו הכלים לטפל בהם. למשל, במקרה הזה מספיק שהיו מפצ’פצ’ים את השרת, או נתונים את ההרשאות הנכונות, וזה לא היה קורה. אבל אנשי אבטחת מידע כושלים בזה. ומדוע? מפני שיש כמה הנחות יסוד שאנשי אבטחת מידע מניחים, אבל הם כבר לא מתאימים למציאות של ימינו.
למשל, נהוג ששרתי פרודקשן הם קודש – לא נוגעים בהם. גם כשמטליאים אותם זה פעם בכמה זמן, וזה ארוע. אבל העולם משתנה – חברות בימינו מעלות שינויים לפרודקשן כמה פעמים ביום. זה משנה את החשיבה שיש בעולם האבטחת המידע. האוטומציה שבבניית שרתים וירטואליים גם מאפשרת להרוס ולהקים שרתים בצורה קבועה.
דבר נוסף – יש שרתים שקיימים רק כמה דקות. אם רוב הבקרות המתקנות שלנו (ניהול פץ’, בדיקות פריצה) הן פעם ב-, איך אפשר לעשות את זה לשרת שנמצא באוויר שעתיים בחודש? אנשים עוברים לענן כדי שהתשתית לא תעצור אותם, ואז אבטחת המידע מעכבת אותם.

Cloudfiog – נותן פריימורק לאוטומיצה של תהליכים אבטחתיים. כששרת עולה, הוא צריך לטעון לתוכו את כל ההקשחות. Encryption נכון מונע את הפריצה (בתנאי שאני מצפין כשהמפתחות אצלי). יכול להשתמש בכל מה שאנו מכירים – דיסק encryption.המוצר Cloudfiog משתמש בתוכנה בשם locks. זו אחת הבקרות היותר חזקות שאפשר להגדיר בסביבות האלה.

Cloudfiog בנוי מרכיבים, כשכל רכיב זה משהו שאפשר להחליף במשהו אחר שמשתמשים בו בארגון. למשל, cloud init, הוא סקריפיטים שרצים ודואגים להרים את כל מה שצריך בשביל האבטחה. זה אומר שכשהשרת עולה, הוא כבר מוכן עם כל ההקשחות. בשלב הזה מריצים גם configuration management. או למשל, IAM Roles – לא את כל ההרשאות שהשרת צריך בהתחלה, צריך לאורך כל חיי השרת. כשהשרת מסיים את כל הדברים הוא עם מינימום הרשאות מול הענן. ובסוף התהליך מקדדים את הדיסק.

באמצעות המוצר הזה אפשר להרים שרת וירטואלי מאובטח ללא עיכובים. זה הכיוון ללכת בו כעת.

Security Automation in the Agile SDLC – Real World Cases

תקציר ההרצאה

המרצה סיפר סיפורים מהשטח, עם לקוחות אמתיים – איך הטמיעו אבטחה בתוך תהליך הפיתוח.

הסיפור הראשון היה על חברת ביטוח שרצתה לעבור ל-agile והחליטה להבנות את האבטחה תוך כדי. הרימו שרתי continuous integration שבונה כל יום שרתים. האתגרים היו:

• הלקוח נמצא במעבר, ובחלק מהמערכות השרתים הם CI ובחלק לא. אין שתי מערכות שהן אותו דבר.
• המפתחים לא מבינים הרבה באבטחה (מפתחים מבוגרים, כשהם למדו לא דיברו על אבטחה).
• נושא הבדיקות האוטומטיות היה מאד חלש. הרבה לקוחות רוצים את בדיקות האבטחה לפני שהם סיימו את בדיקות הפונקציונליות. זה לא טוב, כי יש השפעה של תיקוני הפונקציונליות על האבטחה, כך שלא ניתן לתקן אבטחה לפני שהפונקציונליות מתפקדת.

תהליך:

• צוות הפיתוח איפשרו כניסה חופשית למערכת הבאגים. זה לא דבר ברור מאליו בכלל, אבל לטענת המרצה, הפתיחות בין צוות הפיתוח לצוות האבטחה היא חיונית לעבודה משותפת טובה ויעילה.
• פעם בשבוע מתכנסת קבוצת עבודה ומחליטה ידנית מה מהבאגים האבטחתיים הפתוחים מונע העלאה לפרודקשן. היה שיתוף פעולה יפה.
• הוחלט שעושים את כל הדברים האלה רק על המערכות החדשות, כדי להתגבר על האתגר הראשון.
• משתמשים בכלים של static  analysis (של איכות, לא של אבטחה). מאחר שהוא מביא יותר מדי מידע, הוא נעשה ידנית ולא אוטומטית – לא שובר את ה- build.

 

הסיפור הראשון הוא על לקוח אנגלי מעולם ה-retail. יש פלטפורמה אחת עם flavors שונים. הלקוח הזה היה הרבה יותר בשל – עובד ב-scrum עם ספרינטים של 3 שבועות. קשיח. אוטומציה של בדיקות חזקה.

האתגר היה שבצד האבטחה הם לא היו בשלים: ביצעו פעם בשנה בדיקות פריצה עם חברה שלא מצאה הרבה בעיות. הם נפגשו החברה של המרצה אחרי שפרצו להם…

מי שהניע את התהליך היה הפיתוח – זאת הדרך היחידה לגרום לזה לעבוד. האבטחה בסה”כ מפקח. במשך התהליך הוחלט שעל אף שצוות הפיתוח רצה בדיקות אבטחה, הם לא רצו לבצע אותם כל יום – כי זה יצר בלגן גדול מדי – אלא פעם בשבוע. כך, בשבוע השני, מתקנים את הבאגים שנמצאו בסוף השבוע הראשון; בשבוע השלישי מתקנים את הבאגים שנמצאו בסוף השבוע השני; ואם בסוף השבוע השלישי נותרו בעיות אבטחה – הפיצ’ר לא נכנס. זה הסתנכרן עם אופן העבודה שלהם על באגים פונקציונליים רגילים.

 

Too Big to Fail – Breaking WordPress Core

תקציר ההרצאה

ההרצאה מבוססת על סדרה של שלושה פוסטים באתר צ’ק פוינט, בה מסופר על פריצה (מבוקרת) של אחד מפרצני צ’ק פוינט לאתר וורדפרס, בהתבסס על פרצות הנמצאות ב-core של וורדפרס. כמובן שהפרצות הללו תוקנו. ההרצאה היתה גרסה מקוצרת של סדרת הפוסטים, וכמו”כ יתכן שאני לא דייקתי בהבנתי. לכן אם יש לכם זמן, עדיף שתקראו את הפוסטים המקוריים.

מה שמונע גישה למסכים באדמין, זה capabilities. אבל אפילו המשתמש הפשוט ביותר – המנוי (subscriber)- יכול לגשת לשם, רק עם יכולות מוגבלות מאד.הנחת הפריצה היתה שאנחנו משתמש מסוג קורא – אתרים רבים מאפשרים הרשמה חופשית, שתוצאתה היא משתמש מסוג subscriber. מטרת הפריצה היא, באמצעות משתמש מסוג כזה, להגיע ליכולות גבוהות יותר במערכת, עד כדי יכולת להזיק לאתר.

וורדפרס בודקת יכולות בעזרת הפונקציה Current_user_can. הפונקציה הזו היא switch ענק של כל היכולות במערכת. ב-case של edit_post יש תנאי שבודק את $post. אם הוא ריק – לא צריך הרשאות. באמצעות הבאג הזה אנחנו יכולים לגשת לכל מקום שבודק את ההרשאות שלנו מול ה-post id שסיפקנו – הטריק הוא לתת post id שלא קיים – הוא אינו בודק אם ה-post_id שסיפקנו הוא ולידי! כך אפשר לגשת ל-edit_post(), שגם בו מתבצעת הבדיקה על $post בלי לבדוק אם ה-post_id הוא ולידי. הבעיה היא ש-edit_post קורא לפונקציה update_post שכן בודקת אם הפוסט קיים. אז אמנם לא ניפול על הראשונה, אבל ניפול על השניה. אז אנחנו צריכים ליצור פוסט בין הפונקציה הראשונה לשניה. איך נעשה זאת? יש פונקציה של press this שיוצרת פוסט בלי לבדוק אם המשתמש הנוכחי הוא המחבר של הפוסט, ואפשר להפעיל אותה. אבל איך נעכב את ההפעלה של הפונקציה השניה עד שנריץ את press this? בתוך הפונקציה edit_post יש קוד שמטפל ב-$terms ע”י הפיכתם למערך והתייחסות לכל אחד כערך נפרד, בו ניגשים עם כל אחד מהערכים ל-DB עם SELECT. אמנם SELECT-ים הם קצרים, אבל אנחנו יכולים לשלוט באורך של המערך, ולמעשה לשלוח מליוני קריאות SELECT ל-DB!

אז כעת אנחנו מחברים, ויכולים להרחיב את הפעילות שלנו לתגובות. כן, עם ההרשאות החדשות שלנו מתברר שאפשר ליצור גם תגובות.  אםנם לא בקלות, כי אחד התנאים שבהם יצרנו את הפוסט הוא שהוא נמצא בפח, ואי אפשר לכתוב תגובות לפוסט שנמצא בפח. אבל צ’ק פוינט מצאו פירצה בצורת בגרסאות הפוסט – מתברר שניתן לכתוב תגובה לגרסה של פוסט! ובתוך התגובות נמצאה פירצה נוספת – אם תגובה הושלכה לפח, והמשתמש רוצה להוציאה מהפח, מורצת פונקציה בשם wp_untrash_post_comments(), ובה יש שאילתא UPDATE בלתי מאוסקפת (unescaped)! אפשר לעשות עם זה כל מיני דברים – החל באישור של תגובות ושינוי הפוסטים אליהם הם משוייכים, וכלה בשבירת מנגנון התגובות בזה שנותנים לתגובה ID זדוני השובר את ה-auto-increment של מנגנון התגובות, או אפילו XSS בהצגת התגובות.

כעת הגענו למצב בו אנחנו יכולים לשלוט בתוכן הפוסט. וורדפרס מאפשרת הכנסת תגיות HTML, והיא בודקת את תוכן הקוד מול XSS. היא גם מאפשרת להכניס shorcode-ים, ומבצעת בדיקה של תקינות shortcode. א-ב-ל – בדיקת תקינות ה-HTML מתבצעת לפני ההכנסה ל-DB, ואילו בדיקת תקינות השורטקוד מתבצעת לפני ההצגה על המסך. אפשר לנצל את זמני הבדיקה השונים כדי להכניס קוד זדוני ב-attribute של shortcode. שימוש משולב של מרכאות ומרכא בודד, בתוך שורטקוד שאחריו תגית HTML, הם הדרך לעשות זאת (הדוגמה וההסבר נמצאים בחלק השלישי).
אבל כזכור, הפוסט עדיין נמצא בפח. הדרך להוציא אותו משם היא עם הפונקציה mw_editPost(), שאמנם בודקת יכולות כאשר הפוסט הוא בסטטוס published, אבל שוכחת לעשות זאת כשהוא במצב של Private. בונוס נוסף הוא שפונקציה זו מאפשרת ללעשות את הפוסט sticky. הידד!

מסקנה: אין קוד נקי לגמרי מפרצות.

 

Cross-Site Search Attacks

תקציר ההרצאה

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

ההרצאה הראתה איך אפשר למצוא מידע מתוך ג’ימייל, בינג, ועוד אתרים מוכרים – על אף מכשול ה-same origin policy, על סמך ניסויים שעשו המרצה וצוותו.

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

לצורך הניסוי שלנו נניח כי יש לנו משתמשת בשם אליס, שאנו רוציל לגלות עליה מידע פרטי. איך בכלל אנחנו (התוקפים) מגיעים למחשב שלה? אולי היא גלשה לאתר זדוני שנמצא בו הקוד שלנו. אולי התוקף הרים – או מצא – אתר ושם בו את הקוד הזדוני שלו. כשאליס גולשת לשם היא מורידה אליה סקריפט זדוני. הדפדפן אינו חושד שזה סקריפט זדוני. הסקריפט מריץ בקשות לג’ימייל. מאחר שאליס מחוברת לג’ימייל, הסקריפט משתמש במידע שיש בדפדפן.

בבקשה הראשונה נבקש משהו פשוט: תן לי כל מה שיש בדואל הנכנס או היוצא. הבקשה הזאת, כמו כל בקשה של משתמש לגימייל, מעבירה request לשרת. ג’ימייל מאמת כי הדפדפן צירף כל מה שצריך (כי אליס מחוברת לג’ימייל, אולי בטאב אחר). עכשיו אנחנו נתקלים במכשול ה-SOP – הדפדפן לא מוכן לקבל את התשובה מג’ימייל, כי הסקריפט איננו ג’ימייל, כלומר הדפדפן לא נותן לקרוא את ה-request וה-response. (בלי המדיניות הזאת, כל אתר שגולשים אליו היה יכול לפנות בשמנו לאתרים אחרים).

מה אפשר לעשות? אפשר להשתמש ב-side channel בהקשר של מדידת זמן (side channel הוא משהו צדדי, שמי שפיתח לא חשב שאפשר לדלות ממנו מידע). אנחנו נמדוד כמה זמן לקח כל התהליך (השאלה והתשובה) וכך נלמד כל מידע שרק נרצה.

אבל זה לא פשוט (אילו זה היה טריוויאלי, כבר היו מכריזים על זה כבעיה קריטית):

• מדידת זמנים אינה דבר יציב (הוא תלוי בסוג החיבור, סוג הדפדפן, הרשת, JS). גם אם נניח שזה יציב – מה אפשר ללמוד מהבדל של 0.0001 שניות
• חלון הזדמנויות מאד קטן. אי אפשר לעשות התקפות מרובות בזמן קצר, מפני שאז זה עלול להתפרש כ-DdoS ולהחסם.
• הסוד הוא לשאול את השאלות הנכונות:

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

המדידות צריכות להיות צמודות זו לזו כדי לא לתת לפרמטרים אחרים להשפיע.

בעיות:

• צריך להריץ את הזוגות כמה פעמים, כדי לוודא שלא קרו דברים בינתיים שמשפיעים על המהירות. כאן צריך להסתמך על סטטיסטיקה.
• הדגימות צריכות להיות קטנות כדי לא ליפול על DdoS. יש מודל תיאורטי שמאפשר להגיע למסקנות האלה גם על דגימות קטנות.
• אנחנו רוצים לגרום שהתשובה במקרה של true תהיה יותר ארוכה, לכן נשתמש ב-Response-length inflation. אפשר לחפש מחרוזת שבטוח יש עליה תשובה, עם or של מחרוזת שכנראה ודאי איננה. ג’ימייל מוסיפה את מחרוזת החיפוש לכל תוצאה.

איך, למשל, מגלים את שם המשתמש של מי שפרצנו אליו?
שולחים בקשה עם תחום של שמות (שם שמתחיל ב-a עד שם שמתחיל ב-k, וכן הלאה. לפי אורך התשובות מגלים מהו התחום שבו נמצא שם המשתמש, וממשיכים לצמצמם את התחום – כמו חיפוש אריה במדבר), ותוך 42 שניות אפשר לגלות את שם המשתמש. מה עוזר שם המשתמש? אם אנחנו מתשאלים אתר מפוקפק, כזה שמי שגולש אליו לא רוצה שיידעו זאת, זה יכול להיות מידע מאד מעניין.
באותו אפון, אפשר לגלות עם מי המשתמש מתכתב, על אילו נושאים הוא מתכתב, וכן הלאה.

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