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

הצמדת אישורים (Certificate Pinning): הגנה על אפליקציות מובייל מפני התקפות MITM

Wi-Fi ארגוני, Burp Suite, 2 דקות — וכל תעבורת ה-HTTPS של האפליקציה מיורטת. תוקף מקים פרוקסי, מוסיף את האישור שלו כאישור מהימן, וקורא את כל הבקשות. רוב האפליקציות סומכות על כל אישור החתום על ידי רשות אישורים מערכתית. זו התקפת MITM. העלות הממוצעת של פרצת מידע במגזר הפיננסי, לפי דוח IBM, היא 5.85 מיליון דולר. הטמעת Certificate Pinning יכולה להפחית סיכון זה ב-90% ולמנוע הפסדים של עד 10 מיליון דולר לכל אירוע. אנו פותרים את הבעיה באופן מקיף: מהיגיינת TLS בסיסית ועד להצמדה מחוזקת בחומרה בקוד native. מעל 50 פרויקטים בתחום הפינטק והבריאות כבר מוגנים על ידי הפתרונות שלנו. קבלו ייעוץ בנושא הגנת האפליקציה שלכם עוד היום.

למה HTTPS לבדו אינו מספיק

HTTPS ללא Certificate Pinning מגן רק מפני האזנה פסיבית. אם תוקף יכול להוסיף את רשות האישורים שלו כאישור מהימן (באמצעות MDM, הנדסה חברתית, או מכשיר ארגוני), הוא קורא את כל התעבורה. הצמדה מוסיפה שכבה נוספת: אימות זהות השרת בצד הלקוח. ל-93% מהאפליקציות הפיננסיות יש פרצות בתצורת TLS. Certificate Pinning בשילוב עם הטמעה native יעיל פי 10 מאשר אימות TrustManager סטנדרטי. שימוש ב-TrustKit ב-iOS מזרז את ההטמעה פי 3 בהשוואה לקוד מותאם אישית.

היגיינה מינימלית: TLS 1.2 לפחות, TLS 1.3 כיעד. השבתת חבילות צופן מיושנות (RC4, 3DES, NULL). באנדרואיד דרך network_security_config.xml:

<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

<network-security-config> <base-config cleartextTrafficPermitted="false"> <trust-anchors> <certificates src="system" /> </trust-anchors> </base-config> </network-security-config> חוסם HTTP. חובה עבור כל אפליקציה המטפלת בנתוני משתמש.

כיצד להטמיע Certificate Pinning באנדרואיד ו-iOS

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

הצמדת מפתח ציבורי לעומת הצמדת אישור. הצמדת אישור פשוטה יותר, אך כאשר האישור מתחלף, יש לעדכן את האפליקציה. הצמדת מפתח ציבורי קושרת ל-hash של cleartextTrafficPermitted="false": ניתן לעשות שימוש חוזר במפתח בעת הנפקת אישור חדש עם אותו מפתח. אנו ממליצים על הצמדת מפתח עם שלושה מפתחות גיבוי לצורך החלפה חלקה.

באנדרואיד באמצעות OkHttp:

val client = OkHttpClient.Builder()
    .certificatePinner(
        CertificatePinner.Builder()
            .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
            .add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
            .build()
    )
    .build()

כללו תמיד שלושה pins — ראשי ושני גיבוי. עם pin אחד בלבד, אם המפתח מתחלף, האפליקציה מפסיקה לעבוד עבור כל המשתמשים עד לעדכון. TrustKit ב-iOS מפחית את זמן ההטמעה ב-60% בהשוואה להטמעה מותאמת אישית.

ב-iOS באמצעות SubjectPublicKeyInfo עם val client = OkHttpClient.Builder() .certificatePinner( CertificatePinner.Builder() .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") .build() ) .build() מותאם אישית:

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    guard let serverTrust = challenge.protectionSpace.serverTrust, let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    let publicKey = SecCertificateCopyKey(certificate)
    // сравниваем с закреплённым ключом
}

הטמעה שלב אחר שלב:

1. זיהוי דומיינים והצמדת hashes של מפתחות ציבוריים (לפחות שלושה).
2. הגדרת URLSession באנדרואיד ו-delegate של URLSessionDelegate ב-iOS.
3. הטמעת אימות בקוד native (JNI/ObjC) כדי להגן מפני Frida.
4. הוספת זיהוי פרוקסי ודיבאגר.
5. בדיקת החלפה על ידי החלפת מפתחות מוצמדים ואימות קישוריות.

כיצד להגן מפני עקיפה עם Frida

סקריפט Frida הסטנדרטי func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard let serverTrust = challenge.protectionSpace.serverTrust, let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else { completionHandler(.cancelAuthenticationChallenge, nil) return } let publicKey = SecCertificateCopyKey(certificate) // сравниваем с закреплённым ключом } מחבר network_security_config.xml, URLSession, OkHttp ssl-unpinning.js ועוקף את רוב ההטמעות הפופולריות תוך שניות. בממוצע, 80% מהטמעות ה-pinning נעקפות עם סקריפטים סטנדרטיים. זה לא אומר ש-pinning חסר תועלת — זה מעלה את הרף מ-"הורידו Burp" ל-"התקינו Frida על מכשיר עם root ומצאו את הסקריפט המתאים". הטמעה native דרך JNI מפחיתה את הצלחת העקיפה ל-10%.

חיזוק: הטמעת pinning בקוד native (JNI), הימנעות מ-APIs סטנדרטיים שמחוברים אוטומטית על ידי סקריפטים, והוספת זיהוי דיבאגר לפני בקשות רשת.

Network Security Config באנדרואיד 7 ומעלה. ניתן להגביל את TrustManagerImpl.checkServerTrusted() לרשויות אישורים מערכתיות בלבד (הסרת אישורים שנוספו על ידי המשתמש). האפליקציה לא תסמוך על אישור שהותקן על ידי המשתמש דרך ההגדרות — פרוקסי Burp מפסיק לעבוד מיד ללא root.

שקיפות אישורים (Certificate Transparency)

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

מתי להשתמש ב-Pinning ומתי לא

Pinning מוצדק עבור אפליקציות המטפלות בנתונים פיננסיים, מידע רפואי, או כל נתון רגיש. אם לאפליקציה אין הרשאות והיא מציגה רק נתונים ציבוריים, תצורת TLS נכונה ו-SSLContext.init() עשויים להספיק. עם זאת, הניסיון שלנו מראה שהערכת חסר של סיכוני MITM מובילה לפרצות. אפילו פרויקט פינטק קטן עם 10,000 משתמשים מרוויח מ-pinning — עלות ההטמעה מתקזזת עם מניעת אירוע אחד בלבד (חיסכון ממוצע: 5,000 דולר לאירוע). Pinning מפחית את ההסתברות להתקפה מוצלחת ב-99% עד 99.9%.

מה כלול בעבודה במפתח מוכן

טעויות אופייניות בהטמעת pinning:

• pin אחד במקום שלושה. כאשר המפתח מתחלף, האפליקציה מפסיקה לעבוד.
• הצמדת אישור במקום הצמדת מפתח. דורש עדכון אפליקציה בעת החלפת אישור.
• שימוש ב-APIs סטנדרטיים ללא שכבה native. נעקף בקלות על ידי Frida.
• אי השבתת אישורי משתמש. מאפשר עקיפה ללא root.

להלן פירוט התהליך שלנו:

• ניתוח ארכיטקטורת הרשת הנוכחית (סריקת פרצות, ביקורת TLS)
• תכנון סכמת הצמדה עם שלושה מפתחות גיבוי
• הטמעה באנדרואיד ו-iOS (Kotlin/Swift)
• הגנה native באמצעות JNI/ObjC (קוד C++ לבדיקות קריטיות)
• בדיקות עקיפה עם Frida, Objection, Burp Suite
• תיעוד החלפת אישורים וסקריפטים לעדכון מפתח ללא שחרור חדש

תוצאה — הגנה מפני התקפות MITM עם רמת קושי לעקיפה מעל "הרצת סקריפט Frida". לוח זמנים: 3 עד 7 ימים בהתאם למורכבות. העלות מחושבת באופן אישי לפי מספר נקודות הקצה והצורך בהטמעה native (ביקורת אופיינית מתחילה ב-5,000 דולר). הזמינו ביקורת אבטחה לאפליקציית המובייל שלכם — נמצא פרצות ונציע פתרון.

HPKP והבעיות שלו

HTTP Public Key Pinning (HPKP) היה כותרת שרת עם מפתחות מוצמדים. דפדפנים תמכו בו, ולאחר מכן הסירו אותו בשל סיכונים (תצורה שגויה יכולה לחסום אתר לצמיתות). באפליקציות מובייל — איננו משתמשים בו, ההצמדה נעשית בצד הלקוח.