כבר קרוב לשנה שהמנגנון המותקף ביותר ב-Wordpress (מעבר נסיונות לביצוע Brute Force קלאסי באמצעות wp-login.php) הוא מנגנון ה-XML-RPC של WordPress.
מה הוא מנגנון ה-XML-RPC?
מנגנון ה-XML-RPC הוא מנגנון המאפשר שליחת (או קבלת) מידע משרת HTTP באמצעות שליחת פקודות בפורמט XML.
הייתרון בשליחת פקודות בפורמט כזה הוא פשטות הכתיבה.
לדוגמא, ביצוע login ל-wordpress באמצעות מנגנון ה-XML-RPC (כלומר, המידע שנשלח לשרת לצורך ההזדהות) יראה כך:
<?xml version="1.0" encoding="iso-8859-1"?> <methodCall> <methodName>wp.getUsersBlogs</methodName> <params> <param><value>admin</value></param> <param><value>sylvia</value></param> </params> </methodCall>
גם אם אנחנו לא מתכנתי על, אנחנו יכולים לראות כי נעשה שימוש ב-methodName בשם wp.getUsersBlog, שאם הייתי צריך לנחש.. הייתי אומר שמדובר במשהו שמתייחס למשתמשים בבלוג אליו אנו פונים.
ובהמשך, מועברים הפרמטרים admin ו-sylvia, שגם כאן, בניחוש מושכל.. ניתן להניח שמדובר בשם המשתמש והסיסמא שאנו שולחים לצורך ההזדהות.
בקיצור – פשוט למדי.
כיצד המנגנון בא לידי ביטוי ב-Wordpress?
ב-Wordpress בחרו לממש את ה-API שלהם XML-RPC כך שיהיה ניתן לעשות כמעט הכול מרחוק (את רשימת הפונקציות שניתן לבצע ניתן למצוא בקישור הבא)
למשל, יצא לכם פעם לעבוד עם הפלאגין Jetpack? או לכתוב POST ממיקום מרוחק (כמו למשל מ-wordpress.com אם אתם מרכזים שם מספר בלוגים או באמצעות Windows Live Writer)?
גם אם התשובה היא לא, חשוב להתייעץ עם גורם טכני (מתכנת, או הספרות הטכנית של WordPress במידה ואתם המתכנת) לפני ביטול המנגנון.
רגע, מה זה API?
ממש על רגל אחת, API הם ראשי תיבות של Application Programming Interface.
או בפשטות, סט של פקודות, ספריות קוד ופונקציות שנות שנועדו על מנת לאפשר כתיבה מסודרת ומהירה יותר של הקוד (לדוגמא: במקרה של כתיבה באמצעות API כלשהו, ייתכן והמתכנת לא יצטרך לבנות פונקציות של פעולות בסיסיות ב-Wordpress בעצמו – כי אלו כבר קיימות עבורו במסגרת ה-API של WordPress).
כיצד באה לידי ביטוי ההתקפה?
עד עתה הסברנו בקווים כללים על המגנון, בואו נצלול פנימה על מנת להבין את מהות ההתקפה.
ישנם 2 צורות שבה ההתקפה באה לידי ביטוי:
- Brute force:
התקפה מסוג Brute force היא אחת מסוגי ההתקפות העתיקות והפרמיטביות ביותר, הרעיון פשוט- המטרה הבסיסית ביותר של ההתקפה היא "לפצח" את סיסמת הגישה ל-Wordpress ע"י סריקת צרופים רבים של שם משתמש וסיסמא (מתוך קובץ "מילון" כלשהו המכיל את הצרופים).
בהנחה שלפחות חלק (ומחקרים מראים שמדובר בחלק לא קטן) של המשתמשים עובדים עם ססמאות פשוטות (12345, qwerty qazwsx וכו'), תוך זמן סביר, באמצעות סריקה של כמה מאות סיסמאות – ניתן יהיה לעלות על הסיסמא.וחזרה ל-XML-RPC, מכיוון שבתחילת המאמר ציינו כי היישום של XML-RPC ב-Wordpress הוא למטרת שירות בקשות מרחוק, הרי שטבעי שהמנגנון יהפוך למנגנון שבאמצעותו מנסים (בקלות יחסית, הרי למטרה זו בדיוק המנגנון נועד) לבצע התקפות מסוג זה.חשוב לציין, Brute force אומנם "נולד" במקור כמנגנון ל"פיצוח" ססמאות, אך בפועל ניתן להשתמש בו למטרות רבות אחרות.
למשל, ל-Wordpress יש אפשרות "לתשאל" (באמצעות XML-RPC) מודול מסויים של המערכת, כך שלמעשה- במידה והמודול קיים, WordPress תחזיר תשובה לגביו.. ובמידה והוא לא קיים, היא תציין שהוא לא קיים (ולכן היא לא מחזירה תשובה).
רעיון בסיסי שכזה יכול לאפשר לתוקף לנסות להבין איזה מודול קיים באתר ואיזה לא – ובהתאם, לבנות תוכנית תקיפה. - DDOS:
תאמינו או לא, "בזכות" המבנה איתו עובדת WordPress אפשר להפוך את האתר שלכם בקלות יחסית לחלק ממתקפת "זומבים" (כינוי למחשב שמבצע פעולות לא רצוניות במסגרת התקפה של מחשבים מרובים) על אתר צד שלישי כלשהו.
ה"אשם" בכך הוא מנגנון ה-PingBack של WordPress.
גם היישום פשוט: pingback (נקרא גם TrackBack) הוא מעין מנגנון של "תגובה מרחוק" – כלומר, כאשר בלוג אחר מבצע קישור לבלוג שלכם, ה-PingBack מתריע לכם על תגובות המקשרות למאמר באתר שלכם.
משמע, בסה"כ מדובר על התראה כי מישהו אחר קישר למאמר שלכם.איך זה הופך להתקפה?
פשוט מאוד, כל אחד יכול לשלוח אליכם PingBack (באמצעות XML-RPC) ו"להגיד" שהוא הגיע ממקום אחר.דוגמא:
<methodCall> <methodName>pingback.ping</methodName> <params> <param><value><string>http://victim</string></value></param> <param><value><string>http://reflector</string></value></param> </params>
בדוגמא זו, אם נכניס את הערכים victim (האתר אותו אנו רוצים לתקוף) ואת ה-Reflector (האתר ממנו מתבצעת התקיפה) – אנו נבצע התקפה בה האתר Reflector שולח בקשה לאתר victim, וזאת מבלי שאנחנו (ה"מוח הקרימינלי" מאחורי העניין) לא מעורב בכלל – תכפילו את זה בכמה אלפי אתרים וקיבלתם התקפה יפה.
אגב, כלל לא מדובר בהתקפה מסוג חדש, ההתקפה (התאורתית בזמנו, עד ש"תפסה תאוצה") הוכחה ע"י חוקרי אבטחה כבר בשנת 2007 (!!!).
כיצד מתגוננים?
צריך לזכור שכאשר מביטים על ההתגוננות מ"איום" ה-XML-RPC צריך לחשוב על 2 המישורים בהם פועלת ההתקפה:
- איך נמנעים מלהיות מותקפים באמצעות התקפת BruteForce כלשהיא
- כיצד אנו מונעים מהאתר שלנו לשמש כ-Reflector להתקפת אתרים צד שלישי (כאשר כאן האינטרס שלנו הוא כמו האינטרס לבצע חיסון: אם כולם יבצעו כמונו, סביר להניח שההתקפה תדעך).
יחד עם זאת, ההתגוננות ב-2 המקרים מתחלקת ל-2:
- אין צורך להתגונן וזאת מכיוון שחברת אחסון האתרים שלנו כבר דואגת להגנה הזו מהצד שלה (כחלק מה-WAF אותו היא מפעילה).
- יש צורך להתגונן מכיוון שמדובר בחברת אחסון לא אחראית (שלא מפעילה WAF, או פשוט לא טורחת לחסום התקפות מסוג זה).
במקרה כזה, יש מספר אופציות:
א. חסימת הגישה לקובץ ה-XML-RPC באמצעות מנגנון ה-htaccess.
חלופה חכמה יכולה להיות לחסום את הקובץ לכתובות IP ספציפיות או עבור UserAgent מסויים (לדוגמא, ה-UserAgent של מודול ה-Jetpack), כתבתי בעבר מדריך שיכול לסייע בכך בשם "טיפים וטריקים ב-htaccess".ב. ביטול Feature באמצעות הוספת "Filter" לקובץ ה-functions.php עם התוכן הבא:
add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['wp.getUsersBlogs'] );
return $methods;
} );
* שימו לב, פעולה זו צריך להתבצע רק ע"י אדם המבין בקוד המקור של WordPress, פעולה לא נכונה יכולה לגרום ל-Wordpress להפסיק לעבוד כהלכה.
במידה ואינך יודע כיצד לבצע זאת, ניתן לשקול להשתמש ב-Plugin הקיים לביצוע המשימה.
ג. ביטול כלל מנגנון ה-XML-RPC ב-Wordpress, דרך קלה לעשות זאת היא באמצעות הפלאגין הבא: Disable XML-RPC.
אני ממליץ לעבוד עם ה-Plugin כי סביר להניח שייתכן והאתר שלכם כן משתמש במנגנון ה-XML-RPC, ה-Plugin הוא דרך מהירה להחזיר את המנגנון לפעולה במקרה וגיליתם שמשהו הפסיק לפעול לאחר כיבויו.
ובכל אופן, מחיקה של קובץ ה-XML-RPC.PHP אינה מומלצת.
לסיכום
סביר להניח כי מטרת היוצר והרעיון המקורי היו טובים, אבל האופן שבו צד שלישי יוכל להשתמש במנגנון לא נלקח בחשבון.
גם כאן לדעתי, למרות שהדגמנו מספר דרכים בהם ניתן להתמודד עם האיום באופן עצמאי – מתוך הנחה שאתם מתפעלים יותר מאתר אחד.. למה לשבור את הראש? הנושא צריך להיות מכוסה ללא ספק באחריות חברת האחסון שלכם, ואם היא לא עושה זאת- אולי שווה לחשוב על להחליף ספק.
כמו תמיד נציין כי כלל האתרים תחת שרתי ה-Linux ב-SPD Hosting מוגנים מהתקפות מסוג זה ואין צורך להטמיע את המנגנונים באופן עצמאי.
כחלק מהתפקידים שלי בחברה, אני אחראי על תוכניות ההכשרה של עובדים חדשים.
חי ונושם Hosting, קוד פתוח ו-Linux (ויש גם מילה טובה ל-Windows)
- ריבוי אתרים בחשבון = סיכון אבטחה - יולי 16, 2017
- Let's encrypt – תעודות SSL, ובחינם! - ינואר 17, 2017
- PHPMailer Exploit - דצמבר 28, 2016
השאר תגובה