MASTG-DEMO-0155: WKNavigationDelegate Accepting Any Server Certificate
Download MASTG-DEMO-0155 IPA Open MASTG-DEMO-0155 Folder Build MASTG-DEMO-0155 IPA
Sample¶
The code below implements WKNavigationDelegate with a webView(_:didReceive:completionHandler:) override that calls completionHandler(.useCredential, URLCredential(trust: serverTrust)) without first calling SecTrustEvaluateWithError. This accepts any certificate the server presents in a WKWebView, regardless of whether it is expired, self-signed, or issued for the wrong hostname.
The WebView is used to load self-signed.badssl.com, which serves a self-signed certificate that is not trusted by the iOS system trust store. A correctly implemented delegate would cancel this connection.
| MastgTest.swift | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | |
Steps¶
- Extract the app ( Exploring the App Package) and locate the main binary
./Payload/MASTestApp.app/MASTestApp. - Run radare2 (iOS) with the script to identify the WKNavigationDelegate authentication challenge handler and determine whether
SecTrustEvaluateWithErroris called.
| webview_auth_challenge.r2 | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | |
| run.sh | |
|---|---|
1 2 | |
Observation¶
The output contains five sections followed by the disassembly file for the handler:
- Custom authentication-challenge handlers: lists every function whose signature references
NSURLAuthenticationChallenge.InsecureWKNavigationDelegate(0x00004000) appears here because it implements a custom challenge handler. This is the broad signal that the app has taken over part of the server trust evaluation, regardless of whether it does so correctly. - Accessors into the challenge protection space: the
objc_msgSend$protectionSpace(0x00015980) andobjc_msgSend$serverTrust(0x000159e0) stubs confirm the app reaches intochallenge.protectionSpace.serverTrust, an indication of manual server trust handling. - xrefs to WKNavigationDelegate challenge handler implementation:
axffon the ObjC challenge handler method shows its call to the Swift implementation.InsecureWKNavigationDelegate's ObjC method (0x41f8) calls the Swift implementation at0x00004000. - SecTrustEvaluateWithError calls: this section is empty.
SecTrustEvaluateWithErroris not imported into the binary, confirming it is never called by any challenge handler. - xrefs to SecTrustEvaluateWithError: empty for the same reason.
Reviewing the disassembled code ( Reviewing Disassembled Objective-C and Swift Code), the disassembly and AI-reversed Swift below confirm the insecure handler:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
Evaluation¶
InsecureWKNavigationDelegate surfaces in the "Custom authentication-challenge handlers" section, so it has taken control of the server trust evaluation and warrants manual review.
The test case fails because SecTrustEvaluateWithError is not imported into the binary at all — the "SecTrustEvaluateWithError calls" section in output.txt is empty.
The disassembly confirms this:
serverTrustis obtained at0x00004064.- the only check is a
nilguard at0x0000408c(cbz x0, 0x4120). NSURLCredentialis created directly at0x000040d8with no call toSecTrustEvaluateWithErroranywhere in the function.
The AI-reversed Swift makes the pattern explicit: any non-nil trust object presented to the WKWebView is accepted unconditionally.