מתקפות סייבר על אתרי WordPress קטנים: למה זה קורה ואיך להתגונן

זה עדיין רק הפרולוג

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

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

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

הפעם, היעד הוא אתר ⁦WordPress⁩

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

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

נמצאות פגיעויות שניתן לנצל מבחוץ ללא אימות

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

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

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

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

הטמעת תיקוני חירום בסביבת הייצור

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

יישום צעדים לחיזוק ההגנות

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

• חסימת גישה חיצונית לקבצי תצורה, יומנים וגיבויים

• ביטול האפשרות להצגת רשימת קבצים בתיקיות (Directory Listing)

• הגדר את תיקיית ההעלאה כך שתוכניות לא יוכלו לפעול

• חסימת xmlrpc.php, המשמש לעתים קרובות להתקפות brute-force

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

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

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

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

כאן מתחילה עוד משימה חשובה.

האם זה נוצל בזמן שהחולשות נשארו?

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

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

התקפות הגיעו כמעט כל יום

• התקפות brute-force על כניסת המנהל: עשרות אלפי פעמים (מאלפי מקורות חיבור שונים)

• התקפות brute-force באמצעות xmlrpc.php: עשרות אלפי פעמים

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

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

מעקב אחר פעולות המשתמשים המחוברים

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

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

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

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

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

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

זהות החשבונות התוקפים

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

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

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

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

סיכום תוצאות החקירה

• לא היו כניסות לא מורשות לחשבונות לקוחות בפועל

• ככל שמראים היומנים מהתקופה הנותרת, אין ראיות לכך שניצלו פרצות

• אין תיעוד של מידע סודי שהושג מבחוץ

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

התייעצות לגבי דואר זבל

למפעיל האתר הייתה שאלה נוספת עבורנו.

"אני מקבל הודעות דואר זבל ללא הרף; האם זה קשור?"

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

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

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

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