כמה מילים על התקיפה המתוכננת ביום ראשון

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

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

בניגוד למה שרבים חושבים, התקפה של אנונימוס אינה רק התקפה מסוג DDoS אלא גם נסיונות פריצה או השחתה של אתרים. את החלק של DDoS בארץ סופגים ספקי האינטרנט הישראליים (שכבר החלו להיערך לכך מלפני שבועיים), וסביר להניח שאחד הדברים הראשונים שהם (הספקים) יעשו בחלק מהמקרים הוא חסימת התקשורת מחו"ל לישראל לשרתים מסויימים, כך שאם השרת (בין אם פיזי או וירטואלי) מותקף, ואתה מתארח אצל ספק קטן, אתה צריך להודיע לספק והוא יבקש מהספק הראשי (נטויז'ן/סלקום, 012/אורנג', 014/בזק-בינלאומי) לחסום זמנית תקשורת מחו"ל. לא נעים שגולשים מחו"ל לא יצליחו לגלוש לחלק מהאתרים, אבל אין הרבה ברירות.

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

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

מה בוני אתרים ומתחזקי אתרים ושרתים יכולים לעשות? מספר דברים:

  1. גיבוי – צרו גיבוי מיידי ואל תסמכו על שרות הגיבוי של הספק שאתם נמצאים אצלו. ביום ההתקפה סביר להניח שידי הספק תהיינה מלאות (כבר יצא לי לשוחח עם כמה ספקים שהם אדישים לחלוטין למה שיקרה ביום א') ושחזור יכול לקחת זמן. "הפתעה" נוספת שיכולה לקרות היא גילוי שהספק מעוניין בתשלום עבור שחזור. לכן אני ממליץ להיכנס לפאנל ניהול של החשבון שלכם, ליצור גיבוי ולהוריד אותו אליכם כך שתוכלו לשחזר ביום א' אם יפרץ האתר/שרת שלכם.
  2. מעבר על הרשאות: אתרים שרצים על לינוקס, מומלץ להיכנס למנהל קבצים ולבדוק שההרשאות הן המינימום ההכרחי: 644 לקבצים, 755 לתיקיות (אפשר 701 לתיקיה אם אתם משתמשים ב-SuExec ודומיו). לא להשאיר תיקיות עם הרשאות כתיבה/קריאה/הרצה לכל העולם ואחותו (הרשאות 777). 
  3. עדכונים: עדכון גירסת האפליקציה/תוספים/עיצובים – ודאו כי יש ברשותכם גירסה אחרונה.
  4. עברו על ה-DB שלכם ווודאו כי אין משתמש בשם admin או User ID שהוא 1. כמו כן, הסתכלו ב-MD5 של הסיסמאות, ואם אותו מספר חוזר בכל המשתמשים, אז כנראה בעבר פרצו ל-DB שלכם, שנו את הסיסמאות. 
  5. בעלי שרתי VPS/שרתים פיזיים – התקינו חומת אש (בלינוקס: CSF מומלץ) פנימית, והגדירו אלו מדינות יהיו חסומות (רמז: השכנים שלנו ועוד כמה מדינות "חובבות" ישראל), כך תקטינו את הסיכוי שיפרצו אליכם.

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

לאחר יום א', מומלץ שוב לבדוק את ה-DB והקבצים לראות שלא החדירו לכם קבצים חדשים או לא שינו לכם את ה-DB.

תוסף מעניין לוורדפרס: להחביא מגוגל, למנוע העתקות

הכל התחיל לפני מספר ימים. דבורית שרגל (בעלת הבלוג Velvet Underground שמתארח אגב, אצלנו) כתבה בקצרה על בעיה שיש לה: כאחת שנמצאת בתחום התקשורת, היא מקבלת לעיתים בקשות “דרושים” – חברות ועסקים בתחום התקשורת מחפשים אנשים מסויימים והיא מפרסמת את המודעות אצלה באתר (כאן). דבר מעולה, לדעתי.

רק ישנה בעיה קטנה: כמו שקורה במקרים רבים, תמיד יהיה מי שינסה לנצל את המצב בשביל לעשות עוד כמה שקלים וידפוק את האנשים הטובים בדרך. במקרה הזה מדובר בחברת All Jobs שפשוט החליטה להיכנס לאתר ולהעתיק את העבודות לטובת המנויים המשלמים שלהם. קרדיט לדבורית? משהו? חס ושלום! פשוט מעתיקים ללא בושה, גם כאשר דבורית ביקשה להפסיק – הם כלל לא מקשיבים.

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

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

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

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

  1. יש להגדיר בתוסף עצמו את גודל הריבוע שבו הטקסט יופיע. כדאי לשים לב, גודל קטן מדי יגרום לטקסט להופיע רק בחלקו.
  2. אפשר להגדיר כל מיני אספקטים של רקע, CSS וכו’
  3. לאחר שהכל הוגדר, אפשר לכתוב את הפוסט והיכן שרוצים שהטקסט יהפך לתמונה, מכניסים [imgtxt type=text]התוכן המוגן שלי[/imgtxt]
  4. התוסף גם מאפשר לחובבי ה-Latex ואלו המעוניינים ליצור קוד QR לעשות זאת בקלות ישירות מהבלוג (מעולה לסקירות).

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

תהנו.

הפריצה והגניבה של כרטיסי האשראי: אנליזה שלי

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

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

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

נתחיל בבסיס (המאמר הולך להיות עמוס במונחים טכנולוגיים אך אנסה לפשט כמה שאפשר): בעקרון מערכת Linux רגילה שפותחים משתמש חדש (שהוא אינו עם הרשאות root ואינו בעל הרשאות sudo – הרשאות המאפשרות בעצם לשנות את כל המערכת), אינו יכול לשנות מאומה זולת התיקיה שלו. אם לדוגמא יש לו הרשאה של גישה לבסיס נתונים, הוא יכול ליצור בסיס נתונים, לתת הרשאות בתוכו, ליצור משתמשים נוספים ובסיסי נתונים נוספים (לפי כל מיני מגבלות שמנהל השרת קובע). המשתמש יכול להתפרע עם ההרשאות – אבל רק עד הרמה של המשתמש שלו, כלומר אין לו אפשרות “לטפס” עם ההרשאות “כלפי מעלה” לכיוון הרשאות סיסטם.

כל זה כמובן מדובר על מערכת Linux שמותקנת ומעודכנת עם הטלאים האחרונים (yum update או apt-get update תלוי בהפצה) ועם הגדרות הקשחה נוספות. אותם בוני אתרים טענו שיש להם תקן PCI (אם הבנתי נכון) כך שאם באמת היה להם תקן PCI, מי שמימש אותו היה צריך להקשיח את המערכת.

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

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

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

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

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

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

האם ניתן לעשות משהו כדי למנוע? כן, לא מעט:

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

ויש עוד דרכים ושיטות אחרות שמומחי אבטחה יכולים להמליץ עליהן.

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