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

1. מידע פרטי של 31 מיליון אנשים היה גלוי בשרתי AI Type

קישור: https://thenextweb.com/security/2017/12/05/personal-info-31-million-people-leaked-popular-virtual-keyboard-ai-type/

מתוך הכתבה:

the app’s database server was left online without any form of authentication. This meant anyone could access the company’s treasure-trove of personal information, which totals more than 577 gigabytes of data, without needing a password

Some information is worryingly personal. It contains the precise location of the user, their phone number and cell provider, and according to Whittaker, the user’s IP address and ISP, if they use the keyboard while connected to Wi-Fi.

For reasons unclear, it also uploaded a list of each app installed on the phone, allowing the makers to, in theory, determine what banking and dating apps were being used.

כמה לקחים -

1. כל מי שעובד בצוות יכול (וצריך) לשאול - למה אין סיסמא בקוד החיבור הזה ל DB? בואו נגדיר אחת.

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

דוגמאות דומות -

1. אתר JDate שמר את כל תמונות המשתמשים ב S3 Bucket פתוח לציבור. כך היה אפשר לראות את כל התמונות של כל מנויי האתר. לינק: https://www.geektime.co.il/jdate-pics-revealed-for-everybody/

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

קישור: https://internet-israel.com/חדשות-אינטרנט/רשלנות-משמעותית-במשרד-הפנים-חושפת-את-פ/ הסיפור השני על שרת לא מאובטח שייך למשרד הפנים והפעם השרת הוא Redis ולא מונגו, אבל הנזק אותו נזק. מתוך הכתבה:

מדובר בשרת רדיס שנמצא בכתובת 82.166.96.26 שפתוח לרשת ללא הגנה כלל. כל מה שצריך זה שימוש ב-CLI של רדיס וזה הכל.

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

By default, if no "bind" configuration directive is specified, Redis listens for connections from all the network interfaces available on the server. It is possible to listen to just one or multiple selected interfaces using= the "bind" configuration directive, followed by one or more IP addresses.

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

3. השרת של גיל ספורט מספר הרבה יותר מדי פרטים על המערכת

קישור: http://www.gilsport.co.il טעות נפוצה נוספת ב Deployment של מערכת היא שרתים ששולחים לגולשים שלהם יותר מדי מידע. מאגרי מידע ברשת כמו:

https://www.cvedetails.com/vulnerability-search.php

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

לקחים -

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

2. יש לא מעט כלים אוטומטיים שיודעים לעבור על האתר שלכם ולזהות תבניות כמו HTTP Headers לא מאובטחים. מומלץ להשתמש בהם כחלק מתהליך הפיתוח.

4. התקרית של event stream

קישור: https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident גירסא 1.1 של החבילה flatmap-stream כוללת קוד "סוס טרויאני". הקוד הזה מחפש התקנות של ארנק ביטקוין בשם Copay, ואם יש לכם קופיי מותקן על המכונה הסוס הטרויאני ישלוף משם את החשבון והמפתח הפרטי שלכם וישלח את זה למרכז הבקרה.

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

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

לקחים -

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

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

5. דלת אחורית אותרה בספריית Bootstrap Sass

קישור: https://www.zdnet.com/article/backdoor-code-found-in-popular-bootstrap-sass-ruby-library/ סיפור דומה קרה עם ספריית Ruby פופולרית בשם Boostrap Sass. גירסא חדשה שעלה למאגר כללה דלת אחורית ולכן כל מי שהתקין אותה על השרת שלו הפך את השרת לפגיע.

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

6. צ'ט בוט באתר טיקט מסטר גנב מידע של גולשים

קישור: https://www.bankinfosecurity.com/ticketmaster-breach-traces-to-embedded-chatbot-software-a-11144 הרבה פעמים יותר קל לפרוץ לאחד הספקים שלכם מאשר אליכם - כך לפחות גילו ב Ticket Master כשהצ'ט בוט שהם הטמיעו באתר מחברת Inbenta Technologies התחיל לגנוב פרטי לקוחות.

שימו לב לשורה הבאה מתוך הכתבה:

Inbenta has confirmed the breach, but suggested that Ticketmaster should not have been using its JavaScript chatbot software on a card payment page.

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

לקחים -

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

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

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

7. השתלטות על מערכת נגיש בקליק הובילה לפגיעה במאות אתרים ישראלים

קישור: https://www.israeldefense.co.il/he/node/37666

הגירסא הישראלית של אותו באג נוצרה כשרשומות ה DNS של מערכת נגיש בקליק נחטפה וכך הפורצים הצליחו להחליף את ה JavaScript שמערכת ההנגשה האוטומטית שלחה.

8. גניבת פרטי עובדים של eBay הובילה לגניבת מידע משרתי החברה

קישור: https://www.kaspersky.com/blog/a-confirmed-ebay-leak-another-password-alert/14953/ במאי 2014 איביי הודיעה על זיהוי פירצה בשרתים שלה וגניבה גדולה של פרטי משתמשים. הגניבה קרתה אחרי שהפורצים הצליחו להשיג פרטי גישה של אנשי תמיכה ובעזרת פרטי גישה אלה "שתו" את כל המידע.

מתוך הכתבה:

Apparently the breach occurred some time ago, which is a bad news on its own. According to an eBay Inc. announcement, the incident took place “between late February and early March”, but had only been discovered last week;

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

לקחים -

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

2. מערכת הרשאות טובה חייבת להיות מלווה במערכת זיהוי פריצות או זיהוי התנהגות חריגה. החודשיים וחצי שעברו בין הפירצה לגילוי הם הרבה יותר מדי זמן (ושווה להשוות את זה לפירצה שקרתה לאחרונה ב Stack Overflow שהם התוקף התגלה תוך דקות מרגע השימוש בפרטי הגישה הגנובים).

9. הבית היהודי חשף את פרטי כל חברי המפלגה

קישור: https://internet-israel.com/חדשות-אינטרנט/הבית-היהודי-חושפת-את-מספרי-הזהות-והכתו/

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

10. עובד לאומי קארד גנב מאגר נתונים

קישור: https://www.calcalist.co.il/local/articles/0,7340,L-3648957,00.html אלירן רוזנס הוא עובד לשעבר בלאומי קארד שהחליט ב 2015 לנקום בחברה על רקע אי קידום. הוא העתיק מאגר נתונים של מעל מיליון לקוחות. הוא העתיק את המידע עוד כשעבד בלאומי קארד ואז טס איתו לתאילנד ומשם ניסה לסחוט את החברה.

מתוך אחת הכתבות בנושא:

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

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

11. מנהל התמיכה ב Active Trail העתיק מאגרי מידע

קישור: https://www.globes.co.il/news/article.aspx?did=1001215074 ב 2017 ליאור שרעבי נשפט ל-3 שנות מאסר בפועל אחרי שגנב מאגרי מידע מהמעסיק שלו אקטיב טרייל במטרה לסחוט בכירים בבנק יהב. מתוך הכתבה:

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

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

12. תבנית וורדפרס פגיעה הפילה אתר וורדפרס שלי

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

הקוד הבא הופיע בקובץ upload.php בתבנית וורדפרס שפעם קניתי והוביל לפריצה לכל השרת:

if ($_POST['url']) {
  $uploaddir = $_POST['url'];
}

$first_filename = $_FILES['uploadfile']['name'];
$filename = md5($first_filename);
$ext = substr($first_filename, 1 + strrpos($first_filename, '.'));
$file = $uploaddir . basename($filename . '.' . $ext);

if (move_uploaded_file($_FILES['uploadfile']['tmp_name'], $file)) {
  echo basename($filename . '.' . $ext);
} else {
  echo 'error';
}

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

13. הרצת קוד מרחוק במערכת FlexPaper

קישור: https://redtimmysec.wordpress.com/2019/03/07/flexpaper-remote-code-execution/ תוכנת פלקספייפר הפכה מסמכי PDF ל SWF כדי להציג אותם בדפדפן. התוכנה כללה קוד פגיע שאיפשר לכל אחד להריץ קוד מרחוק באמצעות שילוב של באגים שמופיע בקישור.

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

14. פירצת Blind SQL Injection ב Mysql.com

קישור: https://seclists.org/fulldisclosure/2011/Mar/309 אתר mysql.com היה פגיע ב 2011 לפירצה מסוג Blind SQL Injection.

לקחים -

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

15. מערכת PHP BB פגיעה למתקפת Denial Of Service דרך מנגנון החיפוש

קישור: https://seclists.org/fulldisclosure/2019/Apr/40 קוד: https://github.com/phpbb/phpbb/commit/3075d2fecc9f5bb780bb478c0851a704c7f9b392

מתקפות מניעת שירות מודרניות תוקפות את המערכת בשיכבת היישום, כלומר מנצלות התנהגות "כבדה" של היישום כדי להפיל את כל השרת. כך במערכת PHP BB מנגנון ה Full Text Search היה עלול להיקלע לחיפוש מאוד כבד אם מבקשים לחפש תווים מסוימים.

לקחים -

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

2. יש להוסיף מערכות Rate Limit על פעולות כבדות בשרת.

16. מערכת Open CMS פגיעה למתקפת XSS

קישור: https://seclists.org/fulldisclosure/2019/May/12 מתקפת XSS נוצרת כשהשרת לא מנקה את דף ה HTML לפני שליחתו ללקוח. מתקפה זו עשויה לשמש את התוקף כדי לגנוב מידע פרטי מגולשים אחרים באמצעות הרצת קוד JavaScript זדוני אצל אותם גולשים אחרים.

ניקוי קלט הוא צעד הכרחי בדרך להתמודד עם XSS ואיתו גם יישום CSP.

לקחים -

1. שימו לב שאתם משתמשים בכלים אוטומטיים לזיהוי בעיות XSS באתר שלכם.

2. שימו לב להוסיף CSP כדי למנוע ניצול של פירצות ה XSS.

17. בעיית Format String ב libpurple

שימוש בקלט מלוכלך שהגיע מהמשתמש הוא אחד הגורמים המרכזיים לבעיות אבטחה. כלל אצבע טוב הוא לנקות את הקלט לפני פעולה מסוכנת. במקרה של libpurple קשה היה לראות שהפעולה שאנחנו רוצים לבצע היא מסוכנת. בעיית אבטחה שזכתה למספר CVE-2012-2369 נראית כך:

1. פונקציה לכתיבת Debug Log עם החתימה הבאה:

void purple_debug_info 
  (const char *category, 
   const char *format,...)

והקוד שמשתמש בו נראה כך:

static void log_message_cb(void *opdata, const char *message)
{
    purple_debug_info("otr", message);
}

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

לקחים -

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

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

18. מנגנון נעילה חסר במערכת של סטארבאקס

קישור: https://web.archive.org/web/20150609034106/http://sakurity.com/blog/2015/05/21/starbucks.html

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

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

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

לקחים -

1. מומלץ להכיר כמה שיותר חולשות ידועות מתוך מאגר CWE כדי לכתוב קוד מאובטח יותר:

https://cwe.mitre.org/data/definitions/1000.html

19. סיסמאות לא מוצפנות מספיק טוב ב Ashley Madison

קישור: https://blog.cynosureprime.com/2015/09/how-we-cracked-millions-of-ashley.html

אתר אשלי מדיסון נפרץ ב 2015 והתוקפים הפיצו את כל פרטי המשתמשים וסיסמאותיהם המוצפנות לעולם. הבעיה? הסיסמאות היו מוצפנות במנגנון bcrypt שהפך את פריצתן לתהליך מאוד מאוד איטי. קבוצת חוקרים אחת שמה לב שבחלק מסוים מהסיסמאות המוצפנות היה רכיב נוסף שאינו מוצפן.

חלק מהסיסמאות כללו בבסיס הנתונים ליד הסיסמא המוצפנת שדה בשם loginkey. שדה זה נוצר מגיבוב חלש בהרבה של הסיסמא וככל הנראה שימש למנגנון Remember Me. בעזרת ה loginkey אפשר היה לפצח את אותה סיסמא הרבה יותר בקלות בהשוואה למתקפת Brute Force על ה bcrypt.

לקחים -

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

20. מנגנוני אבטחה לא מוצלחים בתוכנת זיהוי רמאות במבחנים Exam Cookie

קישור: https://vmcall.github.io/reversal/2019/05/16/exam-surveillance2.html התוכנה Exam Cookie נכתבה כדי לוודא שאתם לא מרמים במבחנים שאתם פותרים אצלכם על המחשב. אחד המנגנונים שם ניסה לוודא שאתם לא מעתיקים את השאלות החוצה באמצעות זיהוי כל מה שיש לכם ב clipboard בצורה שוטפת.

מסתבר שקל מאוד לעקוף את המנגנון באמצעות משהו שנקרא Windows Hooks. אנחנו יכולים לכתוב קוד שיחסום את הניסיון של Exam Cookie לקרוא את תוכן ה Clipboard.

לקחים -

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

21. פירצה ב OpenSSL איפשרה לפרוץ לכל השרתים שהשתמשו בגירסא הפגיעה

קישור: http://heartbleed.com/

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

הפירצה התגלתה על ידי גוגל באפריל 2014. בזמן הגילוי הערכה היא כי 17% משרתי ה HTTPS באינטרנט היו פגיעים לבאג.

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

22. פירצה בווטסאפ איפשרה להתקין תוכנות ריגול על הטלפון

קישור: https://www.mako.co.il/news-money/tech-q2_2019/Article-886a662b6a4ba61027.htm

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

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