דוח בדיקת חדירה עבור החלפה מרכזית

תקציר ניהול

צוות Exchange Central פנה אל Sayfer על מנת לבצע בדיקות חדירות מלאות של קופסאות שחורות על אפליקציית האינטרנט שלהם ובדיקת Whitebox עבור ארכיטקטורת הקריפטו שלהם בדצמבר 2021.

לפני הערכת השירותים הנ"ל, קיימנו פגישת פתיחה עם הצוות הטכני של Centralized Exchange וקיבלנו סקירה כללית של המערכת והמטרות למחקר זה.

במהלך תקופת המחקר של 4 שבועות גילינו 10 נקודות תורפה במערכת. הפגיעויות המסוכנות ביותר היו הזרקת SQL ופגמים בלוגיקה עסקית.

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

מתודולוגיית הערכת אבטחה

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

ממצאי הערכת אבטחה

שמירת מפתחות MPC פרטיים בצורה לא מאובטחת

תיאור

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

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

ישנם 3 מפתחות שנמצאים בשימוש בתוך חתימת מפתח MPC. 1 מאוחסן במכונה מוגנת פיזית. 2 האחרים מאוחסנים בתוך אותה מכונה ייעודית ב-GCP.

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

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

הקלות

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

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

SQL Injection

תיאור

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

משתמש ב transaction נקודת הקצה שהצלחנו לנצל לרעה more פרמטר שאילתת כתובת אתר להזרקת מטען זדוני של SQL:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

המטען בו השתמשנו היה:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b - מה שבמקרה זה, בודק אם המופע הפועל של Postgres הוא גרסה 10 או לא.

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

הקלות

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

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

יש לחטא כל קלט של משתמש ל-executor של SQL במקום לשמש כמחרוזת שאילתת SQL פשוטה.

למידע נוסף על שלמות הזרקת SQL, עיין ב- SQL Iמניעת njection CheatSheet.

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

תיאור

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

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

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

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

הקלות

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

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

אימות חלש יותר בערוץ אלטרנטיבי

תיאור

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

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

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

[IMAGE_REDACTED]

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

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

[IMAGE_REDACTED]

הקלות

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

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

סקור את המטא-קבצים של שרת האינטרנט לאיתור דליפת מידע

תיאור

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

• ████████████████████████.gitignore
• ██████████████████████████████./yml-compose.
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

מצאנו שלושה סוגים של קבצים שעלולים להזיק לשירותי ████████, .gitignore, swagger-ui ו docker-compose.yml קובץ. שלושת הקבצים הללו חושפים נתונים רגישים

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

הקלות

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

חסרה כותרת מדיניות אבטחת תוכן

תיאור

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

לא מצאנו כותרת CSP באף אחת מהתגובות של השרת.

[IMAGE_REDACTED]

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

מדיניות CSP בסיסית צריכה לתאר לפחות את דומיינים ברשימת ההיתרים המוגדרים כברירת מחדל עבור קבצים סטטיים (כמו סקריפטים, תמונות ו-CSS). ו frame-ancestors כדי למנוע התקפות לחיצות.

לפרטים נוספים:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

הקלות

הוספת ה- Content-Security-Policy: [policy] על כל תגובה שבה טעינת משאבים חיצוניים עלולה להיות מסוכנת

אנו ממליצים מאוד להשתמש בו ולבדוק אותו תחילה עם הווריאציה "דיווח בלבד" כדי לבדוק את המדיניות שלך לפני שחרורו לייצור:

Content-Security-Policy-Report-Only: [policy]

בדיקת כותרות אבטחה

תיאור

1. דפדפנים תומכים בכותרות HTTP רבות שיכולות לשפר את אבטחת היישומים כדי להגן מפני מגוון התקפות נפוצות, הכותרות מוחלפות בין לקוח אינטרנט (בדרך כלל דפדפן) לשרת כדי לציין את הפרטים הקשורים לאבטחה של תקשורת HTTP.

כשמסתכלים על כותרות האבטחה ████████, חסרים הדברים הבאים:

• X-Content-Type-Options

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

• קפדני-תחבורה-אבטחה

HSTS הוא מנגנון מדיניות אבטחת אינטרנט שעוזר להגן על אתרים מפני התקפות שדרוג לאחור של פרוטוקולים וחטיפת קובצי Cookie. היא מאפשרת לשרתי אינטרנט להכריז שדפדפני אינטרנט צריכים לקיים איתו אינטראקציה רק ​​באמצעות חיבורי HTTPS מאובטחים, ולעולם לא באמצעות פרוטוקול HTTP לא מאובטח.

• מפנה-מדיניות

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

• בקרת גישה-אפשר-מקור

לכותרת יש את הערך "*" אשר חושף את ה-API עבור כל אתר, ייתכן שזו לא התוצאה הרצויה.

הקלות

הוספת הכותרות שהוזכרו לעיל לכל שירותי הקצה האחורי.

סקור את המטא-קבצים של שרת האינטרנט לאיתור דליפת מידע

תיאור

תוך כדי מחקר היעד עם DevTool הצלחנו להציג את קוד המקור הקדמי ללא כל ערפול. פגיעות זו מתרחשת מכיוון שחבילות JS נשלחות עם מפות מקור לייצור, המאפשרות לקרוא את קוד המקור המקורי עם הערות שעלולות לחשוף מידע, למשל, קובץ paths.ts הבא:

█████████████████████/paths.ts [IMAGE_REDACTED]

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

הקלות

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

שרת טביעות אצבע

תיאור

בעוד שמידע שרת חשוף כשלעצמו אינו בהכרח פגיעות, זהו מידע שיכול לסייע לתוקפים לנצל פגיעויות אחרות שעלולות להתקיים. רוב נקודות הקצה אינן חושפות מידע על השרת דרך כותרות HTTP או דפי שגיאה.
באמצעות בקשת ה-HTTP הנוספת הבאה הצלחנו להטביע טביעת אצבע של שרת Nginx באמצעות תגובה של 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

גוף התגובה הוא:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

הקלות

ישנן דרכים שונות לטשטש כותרות של שרת אינטרנט, השיטות הנפוצות ביותר הן:

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

נספח א': תיקוני הערכת אבטחה

יעודכן על ידי צוות Sayfer לאחר העדכון הראשון.