פריצת וורדפרס – כיצד עושים זאת האקרים ערבים והאקרים רוסים

לפני הכל:

אני מתחזק שרת וירטואלי (VPS) כבר שנתיים בחברת CloudVPS ולפני זה 4 שנים בשני חברות בחו"ל. כמו כן כבר כמה שנים טובות משתמש בלינוקס Debian, Ubuntu ו Aptosid (למעשה שלושת מבוססים על Debian).  כך שאי אפשר להגיד שאינני חוסר ניסיון בלינוקס או בניהול שרתים.
בנוסף לכך אני עובד עם וורדפרס כבר מעל חמש שנים ומודע לכל בעיות אבטחה שישנם למערכת זאת.

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

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

פריצה לכאורה רגילה, נכנסתי לתבנית ותיקנתי את הקוד.

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

פריצה נפוצה ביותר – האקרים ערביים

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

פריצה קצת יותר מורכבת

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

פריצות שנובעות מתבניות או פלאגינים

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

פריצה יחסית חדשה שעוד לא יצא לי לראות אותה

פריצה של האקרים רוסיים התחלת בתחילת חודש ינואר.ב 25 לינואר הייתה פריצה לכמה אתרי וורדפרס בארץ. בלילות של 3-5 לפברואר הייתה פריצה דומהת הרבה מאוד וורדפרסים בעולם (בין היתר גם שרת שלי קיבל את המנה שלו). אחד האתרים היה גם אתר wp-e-commerce. לכאורה הפטרון מאוד פשוט וקל, בודקים מה הקובץ הבעייתי ומחליפים אותו. לא כולם בדקו את זה, חלק פשוט שחזרו מתוך גיבוי והמשיכו לעבוד.
אני חפרתי בתוך הקוד וגיליתי שיש בעיה עם קובץ wp-config.php. מה שקורה, שותלים בקובץ קוד זדוני מקודד base64. לפי מה שהבנתי הקוד הזה גורם לגולשים שמגיעים דרך גוגל לעבור לאתרים רוסים (היו שלושה אתרי תוכן למבוגרים  ועוד אתר הכרויות).

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

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

אז התחלתי לחפור בתוכם וראיתי קוד מקודד base64. הורדתי את הקובץ למחשב האישי שלי והתחלתי לבדוק אותו בשרת המקומי על מערכת הפעלה Debian וCentos שלמעסה זה מה שמותקן אצלי בשרת.

כשאר פתחתי את הקובץ .img.php  .fp.php הבנתי שיש לי אין ספור אפשרויות עבודה על השרת, יכולתי לחזור אחורה עד התיקייה ראשית  (Home). ז"א שכל התיקיות של משתמשים (לא של המערכת) פתוחים בפני ואני יכול לעשות מה שאני רוצה.

בקובץ השני .db.php ראיתי רשימה של כל הסיסמאות של האתרים שמאוחסנים אצלי (בסיס נתונים, FTP וכו…).

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

חסמתי את כל הסיסמאות ואת כל הגישות ל Cpanel דרך Firewall, הפעלתי את הגיבוי של שבוע אחרון (2/02/12) והלכתי לשון בשקט.

בבוקר קמתי וראיתי שאתרים שוב נפרצו.

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

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

בשלב הזה אמרתי לעצמי שצריך לחשוב קצת מחוץ לקופסא, אמנם אינני האקר מקצועי בתחום מערכות ניהול תוכן (פעם אחרונה שפרצתי לאתרים זה היה בשנת 2000 כשאר עוד הכול התנהל על בסיס HTML בלבד). אבל לאחר כמה שעות טובות של מחשבה ותחקור קבצי וורדפרס בגרסאות שונות הביעו אותי למסכנה מאוד מעניינת: מה קורה עם כל אותם קבצים שקיימים בשרת מגרסאות 2.xx – 3.2? כמו כן מה קורה לתוספים שלכאורה לא מתעדכנים כי אין להם עדכון (לדוגמא – akismet שעדכון אחרון שלו היה ב 11/1/12).

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

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

"אלגוריתם" של פריצה:

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

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

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

בשלב השלישי, קובץ מכיל בתוכו קידוד base64 שנמצא בתוך אחד התיקיות מתחבר לבסיס נתונים ומחליף שם משתמש ומייל למנהל ראשי (שהוא משתמש מספר 1).

בשלב רביעי, מתחבר אותו משתמש לניהול קבצי תבנית ושותל את אותו קוד שנמצא בקובץ index.php. אם בעל אתר מחליף קובץ index.php לקובץ מקורי, הפריצה עדיין תעבוד.

המלצות:

1. לעדכן אתר לגרסה הכי חדשה. אולי היא איטית יותר אבל היא בטוחה יותר.
2. להיפתר מכל אותם הקבצים שלא אמורים להיות באתר (גם אם זה תוסף כבוי שאנחנו משתמשים בו מדי פעם לצרכים כאלה ואחרים, אפשר להתקין אותו בכל רגע.)
   wp-atom.php
   wp-commentsrss2.php
   wp-config-sample.php
   wp-feed.php
   wp-rdf.php
   wp-rss.php
   wp-rss2.php
3. לבדוק מדי שבוע תאריך עדכון של קובץ wp-config.php.
4. לאחר עדכון להיכנס ל FTP ולבדוק שכל הקבצים באותו תאריך, אם אחד מהם לא זהה לתאריך של אחרים (למעט קבצי ליבה) חשוב לבדוק מה הסיבה.
5. כנ"ל דרך FTP לבדוק תעריך עדכון קבצי תבנית.

סיכום:

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

1. לא תמיד גיבוי עוזר, לפחות אחרון או שניים אחרונים.
2. מערכת מעודכנת ומאובטחת לא מהווה חסם רציני לפורצים.
3. תוספים מעודכנים גם כן לא תמיד עוזרים.
4. כנראה האקרים רוסים מצאו את הפריצה, שתלו קבצים והאקרים ערביים פשוט ניצלו את זה לטובתם.
5. האקרים היום כבר מזמן הפכו להיות רציניים יותר מאשר לשנות שם של קובץ index.php או index.html, לכן צריך לקחת אותם ברצינות רבה. בכל מקרה הם יהיו תמיד צעד אחד לפנינו.

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

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

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