פרצו לוורדפרס שלי? 5 מקומות שבהם תוקפים מתחבאים

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

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

חמישה מקומות לבדוק, בסדר שאני הייתי הולך בו:

1. מנהלים שאף אחד לא מכיר
2. קובצי PHP במקומות שאין להם מה לחפש בהם
3. תוספים וקוד שנטען אוטומטית
4. משימות cron ו-hooks
5. ספאם שרק גוגל רואה

תצטרכו SSH ו-WP-CLI. הריצו כל פקודה מתיקיית השורש של האתר, זו שיש בה wp-config.php. במקום example.com שימו את הדומיין שלכם. הכול עובד גם דרך phpMyAdmin ומנהל קבצים, רק לאט יותר ועם הרבה יותר קליקים.

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

1. חשבונות מנהל נסתרים

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

אז שואלים את מסד הנתונים. wp db query מעביר את ה-SQL ישר ל-MySQL, ואף hook של וורדפרס לא מקבל זכות דיבור. הפקודה הזו מציגה את 20 החשבונות החדשים ביותר. השורה הראשונה שומרת את הקידומת של הטבלאות (בדרך כלל wp_), והשנייה מכניסה אותה לשאילתה:

P=$(wp db prefix)
wp db query "SELECT ID, user_login, user_email, user_registered FROM ${P}users ORDER BY ID DESC LIMIT 20"

בשאילתות בהמשך כתוב wp_. אם wp db prefix מדפיס קידומת אחרת, השתמשו בה.

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

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

בדקו גם סיסמאות אפליקציה. הן מאפשרות לסקריפט להתחבר דרך ה-REST API בלי הסיסמה הרגילה של המשתמש ובלי 2FA, כך שסיסמת אפליקציה גנובה שורדת החלפת סיסמה:

wp db query "SELECT user_id FROM wp_usermeta WHERE meta_key = '_application_passwords'"

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

למה לא wp user list --role=administrator? הפקודה רצה דרך וורדפרס, ו---skip-plugins עדיין טוען תוספי must-use, ושם בדיוק קוד ההסתרה אוהב לגור (ראו בדיקה 3).

מישהו נכנס כמנהל ב-3 בלילה

במסך המשתמשים רק 2 המנהלים שלי

במסד הנתונים יש 3

2. Web shells ו-PHP במקומות שהוא לא שייך אליהם

Web shell הוא קובץ PHP שנותן למי שמוצא אותו לוח בקרה בדפדפן: לדפדף בקבצים, להריץ פקודות, לערוך את מסד הנתונים. בדרך כלל הוא קטן, הרבה פעמים מוסווה בקוד מעורפל, ונקרא בשם שמתמזג עם הסביבה: wp-cache.php,‏ class-wp-xyz.php, או index.php בתיקייה שמעולם לא הייתה צריכה כזה.

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

find wp-content/uploads -iname '*.ph*'

היא מוצאת כל קובץ .php,‏ .phtml ו-.phar שם. תוצאה טובה: כלום. גם קובץ index.php ריק עם // Silence is golden זה בסדר, יש תוספים ששמים כאלה כדי לחסום רשימת תיקיות. כל דבר ארוך יותר שווה הצצה.

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

wp core verify-checksums

תוצאה טובה: Success: WordPress installation verifies against checksums. תוצאה רעה: File doesn't verify against checksum (קובץ ליבה שונה) או File should not exist (מישהו הוסיף קובץ).

אחר כך התוספים מ-wordpress.org:

wp plugin verify-checksums --all

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

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

find . -name '*.php' -ctime -14

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

השתמשו ב--ctime, לא ב--mtime. תוקפים אוהבים לעשות לקבצים שלהם touch אחורה ל-2019, וככה shell בן שבוע נראה כאילו הגיע עם התבנית. touch יכול לזייף את זמן השינוי של התוכן, אבל לא את זמן השינוי של ה-inode, אלא אם יש לו root.

ולסיום, חפשו עם grep את ההסוואות הרגילות:

grep -rlE 'eval\s*\((base64_decode|gzinflate|str_rot13|\$_)' --include='*.php' .

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

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

3. תוספים שלא מופיעים במסך התוספים

שני סוגים של קוד נטענים בלי שמישהו “הפעיל” אותם אי פעם:

• תוספי Must-use. כל קובץ PHP שנמצא ישירות ב-wp-content/mu-plugins/ רץ בכל בקשה. אי אפשר לכבות אותם מלוח הבקרה.
• Drop-ins. שמות קבצים מסוימים ב-wp-content/ שוורדפרס טוען לפי השם: advanced-cache.php,‏ object-cache.php,‏ db.php,‏ maintenance.php,‏ db-error.php,‏ php-error.php,‏ fatal-error-handler.php, ו-sunrise.php ברשת אתרים (multisite).

למסך התוספים יש לשוניות בדיוק בשבילם, Must-Use ו-Drop-in. שורה אחת של נוזקה (add_filter('show_advanced_plugins', '__return_false')) מעלימה את שתיהן. ותוסף רגיל יכול למחוק את עצמו מהרשימה הראשית עם הפילטר all_plugins, ולהמשיך להיטען כרגיל.

אז תסתכלו על התיקיות, לא על המסך. קודם תוספי must-use:

ls wp-content/mu-plugins/

“No such file or directory” זה בסדר: אין תוספי must-use. כל קובץ שכן נמצא שם צריך להיות משהו שחברת האחסון או תוסף מוכר שמו שם (אחסון מנוהל אוהב להוסיף משלו).

אחר כך ה-drop-ins, שיושבים ישירות ב-wp-content:

ls wp-content/*.php

index.php זה רגיל. כל שם מרשימת ה-drop-ins למעלה צריך להיות שייך לתוסף המטמון שלכם או לחברת האחסון.

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

wp db query "SELECT option_value FROM wp_options WHERE option_name = 'active_plugins'"

התשובה היא מערך PHP בפורמט serialized, מכוער אבל קריא: a:2:{i:0;s:19:"akismet/akismet.php";...}. כל רשומה צריכה להיות תוסף שאתם מזהים. עכשיו השוו למה שיש בדיסק:

ls wp-content/plugins/

כל תיקייה שם צריכה להיות תוסף שהתקנתם בכוונה.

4. קוד שרץ לפני וורדפרס, או לפי לוח זמנים

כאן גרה ההדבקה החוזרת. מוחקים את ה-shell, הולכים לישון, ובבוקר הוא שוב באותה תיקייה. משהו החזיר אותו.

auto_prepend_file. אפשר להגיד ל-PHP להריץ קובץ לפני כל סקריפט באתר. בדקו בכל המקומות שבהם ההגדרה הזו יכולה להתחבא:

grep -r auto_prepend_file --include='*.ini' --include='.htaccess' .

תוצאה טובה: כלום. Wordfence מגדיר אותה בכוונה בשביל חומת האש שלו (wordfence-waf.php). כל דבר אחר שמצביע על קובץ שאתם לא מכירים הוא בעיה.

wp-config.php. פתחו וקראו מלמעלה עד למטה. אמורות להיות בו הגדרות: פרטי מסד הנתונים, מפתחות ו-salts, כמה שורות define(). חפשו include או require לנתיב מוזר, חומה של טקסט מקודד, או קוד לפני בלוק ההערות הראשון.

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

grep -rlE 'HTTP_REFERER|HTTP_USER_AGENT' --include='.htaccess' .

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

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

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

wp cron event list

רע: hook עם שם שנראה אקראי, כמו wp_x9f3k_check, שאף תוסף שלכם לא מסביר.

אחר כך אלה של השרת, של המשתמש שהאתר רץ תחתיו:

crontab -l

“No crontab” זה בסדר. רע: שורה שמריצה curl ... | sh או wget מדומיין שאתם לא מכירים. זו מכונה להדבקה חוזרת.

אני: מוחק את ה-web shell

גם אני: לא בודק את ה-cron

ה-shell: בבוקר הוא שוב שם

5. ספאם שרק גוגל רואה

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

בדקו מה העולם החיצוני רואה:

1. חפשו בגוגל site:example.com וגללו. עמודים בשפה שאתם לא כותבים בה, או כתובות כמו /?p=cheap-..., הם סימן רע.
2. פתחו את אבטחה ופעולות ידניות ב-Google Search Console. הרבה פעמים גוגל יגיד לכם לפני שהלקוח יגיד.
3. בקשו עמוד מהשרת שלכם כשאתם מתחזים ל-Googlebot. הפקודה מדפיסה רק את השורות ששונות בין מה שאתם מקבלים למה ש-Googlebot מקבל:

diff <(curl -sL https://example.com/) <(curl -sL -A Googlebot https://example.com/)

ואותו דבר למבקר שמגיע מתוצאה בגוגל:

diff <(curl -sL https://example.com/) <(curl -sL -e https://www.google.com/ https://example.com/)

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

אחר כך חפשו במסד הנתונים סקריפטים שהוזרקו:

wp db search '<script' wp_posts wp_options

היא מציגה כל תגית <script ששמורה בפוסטים ובהגדרות.

חלק מהתוצאות יהיו לגיטימיות: קוד אנליטיקס, וידג’טים של צ’אט, HTML ששמר בונה עמודים. אתם מחפשים סקריפטים שנטענים מדומיינים שמעולם לא שמעתם עליהם, או String.fromCharCode ו-atob( שמתאמצים להסתיר כתובת.

וכבר כשאתם ב-wp_options, ודאו את שתי הכתובות שבהן וורדפרס חושב שהוא גר:

wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home')"

שתיהן צריכות להיות הדומיין שלכם. אותה סיבה כמו קודם: SQL נקי, כך שתוסף must-use לא יכול לסנן את התשובה.

שלוש דלתות שבוטים דופקים עליהן, עם פריצה או בלי

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

ספאם בתגובות שלא עובר דרך הטופס שלכם

בוטים לא ממלאים את טופס התגובות. הם מדלגים על העמוד ושולחים POST ישר לכתובת שהטופס שולח אליה, כך ש-captcha או מלכודת honeypot שחיה רק ב-JavaScript של הטופס פשוט לא רצה.

יש שתי כתובות כאלה. הקלאסית, wp-comments-post.php, מקבלת תגובות מכל אחד כשהתגובות פתוחות. כתובת ה-REST,‏ /wp-json/wp/v2/comments, דוחה תגובות אנונימיות כברירת מחדל. ודאו שאצלכם זה עדיין ככה. זו אחת משתי הפקודות שיכולות לשנות משהו: אם הכתובת פתוחה, היא שולחת תגובת בדיקה אמיתית.

curl -s -d 'post=1&author_name=test&author_email=test@example.com&content=test' https://example.com/wp-json/wp/v2/comments

התשובה שאתם רוצים היא 401 עם "code":"rest_comment_login_required". אם במקום זה נוצרה תגובה (לכו למחוק אותה), משהו הפעיל את הפילטר rest_allow_anonymous_comments. בררו מה, וכבו אותו אם אתם לא יודעים למה הוא שם.

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

wp comment count

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

אחר כך הציגו את התגובות המאושרות שיש בהן קישור:

wp comment list --status=approve --search=http --fields=comment_ID,comment_author,comment_author_url

קישורי ספאם שאושרו הם גם ספאם SEO, רק בגרסה העצלה.

מה עושים:

• לא משתמשים בתגובות? סגרו אותן ב-הגדרות ← דיון לפוסטים חדשים, סגרו גם בישנים (הפקודה הזו משנה נתונים: wp db query "UPDATE wp_posts SET comment_status = 'closed'"), וחסמו את הכתובת בשרת, כמו שהצ’קליסט חוסם את xmlrpc.php.
• משתמשים בהן? שימו לפניהן סינון בצד השרת, כמו Akismet או Antispam Bee. הם בודקים את הבקשה עצמה, אז הם תופסים בוטים שמעולם לא טענו את העמוד.

שמות משתמש של מנהלים שמחולקים בחינם

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

# REST API: look for "slug" - one per user who has published a post
curl -s https://example.com/wp-json/wp/v2/users

# Author archives: the "location:" line ends in /author/<username>/
curl -sI 'https://example.com/?author=1'

# RSS feed: the author's display name on every post
curl -s https://example.com/feed/ | grep creator

# oEmbed: "author_name" and "author_url" for any page
curl -s 'https://example.com/wp-json/oembed/1.0/embed?url=https://example.com/'

# Core sitemap (WordPress 5.5+): one author archive URL per user
curl -s https://example.com/wp-sitemap-users-1.xml

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

ה-slug והחלק בכתובת אחרי /author/ הם ה-user_nicename של המשתמש. וורדפרס יוצר אותו משם המשתמש, כך שברוב האתרים הוא הוא שם המשתמש. אם גם בפיד שם התצוגה זהה לשם המשתמש, כל חמש הדרכים מובילות לאותה תשובה.

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

• תנו לכל מנהל כינוי ושם תצוגה ששונים משם המשתמש (משתמשים ← פרופיל ← שם תצוגה).
• שנו את ה-nicename, שלא מופיע במסך הפרופיל: wp user update 1 --user_nicename=alex-k.
• הסתירו את /wp/v2/users ממבקרים לא מחוברים בעזרת תוסף האבטחה, כמו בחלק של ה-REST API בצ’קליסט.
• הורידו את מפת האתר של המשתמשים אם אתם לא צריכים עמודי מחבר בחיפוש:

add_filter( 'wp_sitemaps_add_provider', function ( $provider, $name ) {
    return 'users' === $name ? false : $provider;
}, 10, 2 );

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

קבצים שלא התכוונתם לפרסם

שרת הווב מעביר קובצי .php ל-PHP, וכל דבר אחר מגיש כהורדה רגילה. wp-config.php בטוח כי הוא רץ ולא מוצג. תעשו ממנו עותק בשם wp-config.php.bak, וזה כבר קובץ טקסט עם סיסמת מסד הנתונים, במרחק בקשה אחת.

wp-config.phpרץ, לא רואים כלום

wp-config.php.bakטקסט רגיל, הסיסמה בפנים

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

• עורכי טקסט משאירים אותם: nano כותב wp-config.php.save כשהוא קורס, vim מחזיק .wp-config.php.swp כל עוד הקובץ פתוח, emacs שומר wp-config.php~.
• “רגע, אני רק אגבה” מהיר משאיר בשורש האתר wp-config.php.bak,‏ wp-config.old או backup.sql.
• define('WP_DEBUG_LOG', true) כותב כל שגיאת PHP ל-wp-content/debug.log, עם נתיבים בשרת, שמות תוספים, ולפעמים הנתונים שגרמו לשגיאה.
• פריסה עם git pull משאירה תיקיית .git. אם השרת מגיש אותה, כל אחד יכול להוריד את הקוד שלכם ואת כל ההיסטוריה שלו, כולל כל סיסמה שאי פעם נכנסה ל-commit.

בוטים מבקשים את השמות האלה בדיוק בכל אתר שהם סורקים. תבקשו ראשונים:

for f in wp-config.php.bak wp-config.php.save wp-config.php~ .wp-config.php.swp wp-config.old backup.sql wp-content/debug.log .git/HEAD .env; do echo "$(curl -so /dev/null -w '%{http_code}' https://example.com/$f) $f"; done

היא מדפיסה קוד תשובה ליד כל שם. כל מה שהוא לא 403 או 404 צריך בדיקה. יש תבניות שעונות על עמודים שלא קיימים עם 200, אז פתחו את הכתובת לפני שנכנסים לפאניקה: .git/HEAD מתחיל ב-ref: refs/heads/, ועותק של הקונפיג מתחיל ב-<?php.

הרשימה הזו מכסה רק את השמות הנפוצים. את השאר חפשו בשרת:

find . -maxdepth 3 | grep -E '\.(sql|gz|zip|bak|old|save|swp|log)$|~$'

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

ומה שנשאר מהפריסה:

ls -d .git

אתם רוצים לראות “No such file or directory”.

מה עושים:

• העבירו גיבויים ו-dumps מחוץ לשורש האתר, או מחקו אותם.
• תשאירו את לוג הדיבאג, אבל מחוץ לאתר: define('WP_DEBUG_LOG', '/home/user/logs/wp-debug.log'); עובד מוורדפרס 5.1. בפרודקשן, כשאתם לא מדבגים, כבו אותו.
• חסמו בשרת קבצים שמתחילים בנקודה וסיומות של גיבויים, כרשת ביטחון לפעם הבאה. ל-Apache, ב-.htaccess שבשורש:

RedirectMatch 404 /\.(?!well-known)
<FilesMatch "\.(bak|old|orig|save|swp|sql|log)$|~$">
    Require all denied
</FilesMatch>

השורה הראשונה מסתירה את .git,‏ .env וכל קובץ אחר שמתחיל בנקודה, אבל לא נוגעת ב-.well-known, כי Let’s Encrypt צריך אותה כדי לחדש את התעודה. ב-nginx אותה עבודה עושה location ~ /\.(?!well-known) { deny all; }.

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

מצאתם משהו?

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

הניקיון, בקצרה:

• החליפו את כל הסיסמאות: משתמשי וורדפרס, מסד הנתונים, לוח הבקרה של האחסון, FTP/SFTP ו-SSH.
• החליפו את ה-salts כדי שכל עוגיות ההתחברות הגנובות ימותו בבת אחת: wp config shuffle-salts.
• בטלו סיסמאות אפליקציה שאתם לא יודעים להסביר.
• מצאו איך נכנסו. בדקו את לוגי הגישה של שרת הווב סביב תאריך ה-user_registered של המנהל הזר וזמני השינוי של קובצי ה-shell. בדרך כלל זה תוסף לא מעודכן.
• אם יש ספק, שחזרו מגיבוי שישן יותר מהראיה המוקדמת ביותר, ואז עדכנו הכול לפני שמחזירים את האתר לאוויר.

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