S3 Ep146: ספר לנו על ההפרה הזו! (אם אתה רוצה.)

S3 Ep146: ספר לנו על ההפרה הזו! (אם אתה רוצה.)

S3 Ep146: ספר לנו על ההפרה הזו! (אם אתה רוצה.) PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

מוזר אבל נכון

אין נגן אודיו למטה? להקשיב ישירות בסאונדקלאוד.

עם דאג אמות ופול דאקלין. מוזיקת ​​אינטרו ואאוטרו מאת אדית מדג'.

אתה יכול להאזין לנו ב Soundcloud, Apple Podcasts, Google Podcasts, Spotify ובכל מקום שבו נמצאים פודקאסטים טובים. או פשוט זרוק את כתובת האתר של הזנת ה-RSS שלנו לתוך הפודקטצ'ר האהוב עליך.


קרא את התמליל


DOUG.  עדכוני פיירפוקס ועוד באג עם שם מרשים, וה-SEC דורש חשיפה.

כל זה, ועוד, בפודקאסט הביטחון העירום.

[מודם מוזיקלי]

ברוכים הבאים לפודקאסט, כולם.

אני דאג אמות'; הוא פול דאקלין.

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

רכבתי אתמול על אופניים במשך 10 מייל אמריקאי, שלדעתי הם בערך 16 ק"מ, וכל זה תוך כדי משיכת ילד קטן אך לא כבד מאחורי האופניים בכרכרה דו-גלגלית.

ואני עדיין חי כדי לספר את הסיפור.

האם זו דרך ארוכה לרכוב על אופניים, פול?


ברווז.  [צוחק] זה תלוי כמה רחוק באמת היית צריך ללכת.

כאילו, אם זה היה בעצם 1200 מטר שהיית צריך ללכת והלכת לאיבוד... [צחוק]

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

אבל 10 מייל זה בסדר.

האם ידעת שהמיילים האמריקאים והמיילים הבריטיים הם, למעשה, זהים?


DOUG.  זה טוב לדעת!


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

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

...כולם מוגדרים במונחים של מטר.

אינץ' אחד הוא בדיוק 25.4 מ"מ

שלוש דמויות משמעותיות זה כל מה שאתה צריך.


DOUG.  מרתק!

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

השבוע, ב-01 באוגוסט 1981, Music Television, הידועה גם בשם MTV, עלתה לאוויר כחלק מחבילות טלוויזיה אמריקאיות בכבלים ובלוויין, והציגה לציבור סרטוני מוזיקה.

הראשון שיחק את [SINGS, RATHER WELL in Fact] את "Video Killed the Radio Star" של The Buggles.

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


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

מה שמסתובב מסתובב, דאגלס.


DOUG.  בסדר, ובכן, בוא נדבר על העדכונים האלה של Firefox.

אנו מקבלים מנה כפולה של עדכוני Firefox החודש, מכיוון שהם במחזור של 28 ימים:

פיירפוקס מתקן שלל פגמים בגרסה הראשונה מבין שתיים החודש

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

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


ברווז.  כן, שוב קליק ישן וטוב.

אני אוהב את המונח הזה כי הוא די מתאר מה זה.

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

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

...כל הדברים האלה, כן, אתה כן רוצה להישאל.

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

אבל אם יש לך כפתור במקום שבו יופיע החלון הקופץ, ופיתוי המשתמש ללחוץ עליו, תוכל למשוך את הקליק, אבל הקליק יישלח לתיבת הדו-שיח של ההרשאות שעדיין לא ממש ראית.

מעין מצב מרוץ ויזואלי, אם תרצה.


DOUG.  בסדר, והשני היה: קנבס מחוץ למסך יכול היה לעקוף מגבלות חוצות מוצא.

אתה ממשיך ואומר שדף אינטרנט אחד יכול להציץ בתמונות המוצגות בדף אחר מאתר אחר.


ברווז.  זה לא אמור לקרות, נכון?


DOUG.  לא!


ברווז.  המונח בז'רגון לכך הוא "מדיניות מאותו מקור".

אם אתה מפעיל את אתר X ואתה שולח לי חבורה שלמה של JavaScript שמגדיר עומס שלם של עוגיות, אז כל זה מאוחסן בדפדפן.

אבל רק JavaScript נוסף מאתר X יכול לקרוא את הנתונים האלה בחזרה.

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

ברור שזה די חשוב.

ונראה כאן שלמיטב הבנתי, אם היית מעבד דף שעדיין לא הוצג...

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

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

הם הבחינו בזה, או שזה נחשף באחריות, וזה תוקן.

והשניים האלה, אני חושב, נכללו בפגיעויות הנקראות ברמה "גבוהה".

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

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

כי באבטחת סייבר, כדאי לעולם לא לומר לעולם!


DOUG.  בסדר, אתה מחפש את Firefox 116, או אם אתה בגרסה מורחבת, 115.1.

אותו דבר עם Thunderbird.

ובואו נעבור ל... הו, בנאדם!

פול, זה מרגש!

יש לנו BWAIN חדש אחרי BWAIN כפול בשבוע שעבר: באג עם שם מרשים.

לזה קוראים התנגשות+כוח:

ביצועים ואבטחה מתנגשים שוב בהתקפת "Collide+Power".


ברווז.  [צוחק] כן, זה מסקרן, נכון, שהם בחרו שם שיש בו סימן פלוס?


DOUG.  כן, זה מקשה לומר.


ברווז.  לא יכול להיות סימן פלוס בשם הדומיין שלך, אז שם הדומיין הוא collidepower.com.


DOUG.  בסדר, תן לי לקרוא מהחוקרים עצמם, ואני מצטט:

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

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


ברווז.  [צוחק] כן, זה הגיוני מאוד אם אתה כבר יודע על מה הם מדברים!

כדי לנסות להסביר את זה באנגלית פשוטה (אני מקווה שהבנתי את זה נכון)...

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

Zenbleed: כיצד החיפוש אחר ביצועי מעבד יכול לסכן את הסיסמאות שלך

יש עומס שלם של נתונים שנשמרים בתוך המעבד ("מטמון" הוא המונח הטכני עבורו) כך שה-CPU לא צריך ללכת להביא אותו מאוחר יותר.

אז יש הרבה דברים פנימיים שאתה לא באמת מצליח לנהל; המעבד מטפל בזה בשבילך.

ולב ההתקפה הזה נראה משהו כזה...

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

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

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

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

מספר הסיביות השונות בין הערך הישן במטמון לערך החדש *משנה את כמות הכוח הנדרשת לביצוע פעולת עדכון המטמון*.

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

די מסקרן, דאג!


DOUG.  יוצא מן הכלל.

בסדר, יש כמה הקלות.

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


ברווז.  כן, זה מעניין, לא?

זה אומר "קודם כל" (טקסט רגיל) "אתה" (באיטלקית) "לא צריך לדאוג" (מודגש). [צוחק]

אז, בעצם, אף אחד לא הולך לתקוף אותך עם זה, אבל אולי מעצבי המעבד רוצים לחשוב על זה בעתיד אם יש דרך לעקוף את זה. [צוחק]

חשבתי שזו דרך מעניינת לנסח את זה.


DOUG.  אוקיי, אז ההקלה היא בעצם לבטל את ההיתמרות.

ככה זה עובד?


ברווז.  שרשרת יתר מחמירה את זה הרבה יותר, עד כמה שאני יכול לראות.

אנחנו כבר יודעים ש-hyperthreading היא בעיית אבטחה מכיוון שהיו מספר נקודות תורפה שתלויות בה בעבר.

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

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

אם אתה מפעיל את OpenBSD הישן והטוב, אני חושב שהם החליטו ש-hyperthreading הוא פשוט קשה מדי לאבטחה באמצעות הקלות; יכול גם פשוט לכבות אותו.

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

אז אני חושב ש כיבוי hyperthreading יחסן אותך מאוד נגד ההתקפה הזו.

הדבר השני שאתה יכול לעשות הוא, כפי שאומרים המחברים בהדגשה: אל תדאג. [צחוק]


DOUG.  זו הקלה גדולה! [צוחק]


ברווז.   יש קצת (אצטרך לקרוא את זה, דאג)...

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

אני מאמין שלפחות למעבדי אינטל יש הקלה שלדעתי תעזור נגד זה.

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

יש תכונה שאתה יכול להגדיר בשם סינון RAPL, ו-RAPL הוא קיצור של מגבלת כוח ממוצע ריצה.

הוא משמש עבור תוכניות שרוצות לראות את ביצועי ה-CPU למטרות ניהול צריכת חשמל, כך שאינך צריך לפרוץ לחדר השרתים ולשים צג מתח על חוט עם בדיקה קטנה על לוח האם. [צוחק]

אתה באמת יכול לגרום למעבד לומר לך כמה כוח הוא משתמש.

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

אז תקבלו תוצאות שבממוצע הן מדויקות, אבל שבהן כל קריאה בודדת תכבה.


DOUG.  כעת נפנה את תשומת ליבנו לעסקת SEC החדשה הזו.

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

SEC דורשת מגבלת גילוי של ארבעה ימים בגין הפרות אבטחת סייבר

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

אז, התחלה ראשונה טובה, אבל אולי לא אגרסיבית כמו שהיינו רוצים?


ברווז.  אני מסכים עם ההערכה שלך שם, דאג.

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

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

ואז הגעתי לקטע הזה (וזו לא הודעה לעיתונות ארוכה מאוד של ה-SEC) שאמרה בערך, "ברגע שהחלטת שאתה באמת צריך לדווח על זה, אז עדיין יש לך ארבעה ימים לדווח על כך."

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

אולי אנחנו קצת קשוחים בכתבה?


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

אז על איזה סוג של תוכנת כופר אנחנו מסתכלים?


ברווז.  כן, רק כדי להסביר, חשבתי שזה חלק חשוב מזה.

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

...אם רק סבל מהתקפת תוכנת כופר מספיק בהכרח כדי להיות הפרת נתונים מהותית.

מסמך ה-SEC הזה בכלל לא מזכיר את "מילה R".

אין אזכור לדברים ספציפיים לתוכנת כופר.

ותוכנת כופר היא בעיה, לא?

במאמר רציתי להבהיר שהמילה "תוכנת כופר", שבה אנחנו עדיין משתמשים באופן נרחב, היא כבר לא ממש המילה הנכונה, נכון?

כנראה שעלינו לקרוא לזה "תוכנות סחיטה" או פשוט "סחיטת סייבר".

אני מזהה שלושה סוגים עיקריים של התקפת תוכנת כופר.

סוג A הוא המקום שבו הנוכלים לא גונבים את הנתונים שלך, הם פשוט יכולים לטרוף את הנתונים שלך באתרם.

אז הם לא צריכים להעלות דבר אחד.

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

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

ואז, כמובן, יש את התקפת תוכנת הכופר מסוג C, והיא: "גם A וגם B."

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

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

... איפה זה מתחיל, במקרה של התקפות כופר.


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

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

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

אדם אומר:

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


ברווז.  עשית מספיק?


DOUG.  כן.


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

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

ולמעשה עשוי להיות משקל רב לחשוף זאת מרצון, גם אם החוק אמר שלא חייבים.


DOUG.  ואז, עבור סוג ב', זווית הסחיטה, אדם אומר:

זה מצב מסובך.

תיאורטית, הייתי אומר, "כן."

אבל סביר להניח שזה יוביל להרבה גילויים ולפגיעה במוניטין העסקי.

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

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


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

הוא רחש גם את זה, לא?

הוא אמר:

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

אז, אנחנו לא ממש יודעים איך זה יתפתח, ואני בטוח שגם ה-SEC לא ממש יודע.

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

מה שבעצם מוביל לעייפות הפרצות, לא?

אם יש לך כל כך הרבה חדשות רעות שהן לא נורא חשובות פשוט שוטפים אותך...

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

הזמן יגיד, דאגלס.


DOUG.  כן, מסובך!

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

אז תודה לך, אדם, על ששלחת את ההערה.


ברווז.  אכן כן!


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

אתה יכול לשלוח דוא"ל ל-tips@sophos.com, אתה יכול להגיב על כל אחד מהמאמרים שלנו, או שאתה יכול לפנות אלינו בחברתית: @nakedsecurity.

זו ההופעה שלנו להיום; תודה רבה על ההקשבה.

עבור פול דאקלין, אני דאג אמות', מזכיר לך עד הפעם הבאה...


שניהם.  הישאר בטוח.

[מודם מוזיקלי]


בול זמן:

עוד מ ביטחון עירום