Please provide a demo vulnerable app to demonstrate the issue,

[JarvisXD]

I am not able to find any app vulnerable during my assessments. can you please provide demo vulnerable app so that i can get proper idea about the exploitation because tools always say that 'No alternative host for {DomainName}. HELP ME

[ashley-campbell]

How do you get that far? I am unable to figure out how to route network traffic of a device through the Java tool

On Wed, Dec 20, 2017 at 2:42 AM, Riddler__ notifications@github.com wrote:

I am not able to find any app vulnerable during my assessments. can you please provide demo vulnerable app so that i can get proper idea about the exploitation because tools always say that 'No alternative host for {DomainName}. HELP ME

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ChrisMcMStone/spinner/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/AZvoGAlM-EOGfYG6fnVxRaOzHEBDAVAqks5tCOSbgaJpZM4RINM5 .

[JarvisXD]

Make sure device and the attacker machine on same wifi network.

1) goto wifi settings > select wifi > advance > set proxy settings to attacker's_machine_IP:443 and change IP settings from DHCP to Static.Set your IP and chnage DNS IP to attacker's_machine_IP. Now start the tool it should work now

[sanvital]

I am in a Mac development environment that produces an iOS app. I am using the Mac's "Internet Sharing" capability (in the Sharing system preference) to direct the network traffic on my development phone to my Mac (i.e. share my ethernet internet connection over WiFi and connect to this hotspot on my phone), which is running the spinner tool. The spinner log is showing my phone's network traffic being routed through spinner, and the URL that my app accesses with CA (non-leaf) pinning does get rerouted (some of the time, maybe 25%, the majority of the time some other error occurs such that the connection fails prior to the evaluation of "server trust"); however, the (occasional) eventual failure in server trust does not appear to be due to hostname verification (i.e. noticing that the identity of the leaf cert does not match the intended server), since I have actually commented out the part of my code that allows for the hostname check (i.e. use SecPolicyCreateSSL to create “a policy object for evaluating SSL certificate chains" and supply a hostname that ”if present, the policy will require the specified hostname to match the hostname in the leaf certificate" and then include this policy in the trust object via SecTrustSetPolicies).

Instead, what I am seeing is that my server trust method (URLSession:didReceiveChallenge:completionHandler:) is provided a cert for the redirected server (I added a call to SecCertificateCopySubjectSummary to print out a "simple string which hopefully represents a human understandable summary", and I do see that the summary string for the cert matches the "Forwarding to:" log message in spinner). I obtain this leaf cert via SecTrustGetCertificateAtIndex using index 0 and "the leaf cert (index 0) is always present regardless of whether the trust reference has been evaluated or not"). So far, so good. However, once the actual evaluation is called (SecTrustEvaluate) then the following log message is produced during the execution of this OS call, "NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9806)". The SecTrustResultType returned by the call is kSecTrustResultRecoverableTrustFailure, i.e. the evaluation failed, however, it seems like the failure is due to a failure in some other part of the SSL negotiation.

My personal summary, I do not recommend investigating failures in CA pinning of iOS apps using spinner. The more technical details of the associated academic paper appears to lean towards Android (which is understandable given its more open nature), thus, I presume that the testing of the tool also leaned Android. Perhaps a more comprehensive README could illuminate the specific, verified utility of this tool. It is entirely possible that I have simply failed in the (poorly documented) setup phase of this tool.

[ChrisMcMStone]

@sanvital Hi, thanks for taking the time to try out the tool and writing about your experience. You are somewhat right in suggesting that the the focus of this research was on Android apps. However, only in so far as we did not carry out much reverse engineering of iOS apps to look at code handling hostname verification. We do test a large number of iOS apps for the flaw with Spinner and find it is a problem in some apps (see the HSBC apps mentioned in the paper).

The SecTrustResultType returned by the call is kSecTrustResultRecoverableTrustFailure, i.e. the evaluation failed, however, it seems like the failure is due to a failure in some other part of the SSL negotiation.

Could you please explain this in more detail? What makes you think the failure is caused by some other part of the SSL negotiation? If this is the case, what part of the SSL negotiation is failing? Thanks.

[ChrisMcMStone]

@ashley-campbell You need to make sure that the device you are testing apps on has it's DNS IP set to the IP of the machine running Spinner.

[ChrisMcMStone]

@JarvisXD This error message suggests that an alternate domain with the same certificate chain (excluding the leaf) cannot be found on Censys.io (providing you have entered valid Censys login credentials in the config). You can try manually redirecting the TLS traffic to another site with the -m flag.

[JarvisXD]

Already did that can you please provide a demo vulnerable app ? Or tell me i will code

[JarvisXD]

Did that also no luck. Need to create a demo vulnerable app. Thanks for help

[ChrisMcMStone]

@JarvisXD no luck? What are the log messages saying?

[sanvital]

@ChrisMcMStone The basis for my conclusion that the trust failure was due to a configuration error in either my setup of spinner or spinner's internal execution is mainly due to the mentioned log message that appears in the debug console while running my app in Xcode,

NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9806)

This message specifically happens as I step-over SecTrustEvaluate, thus, the internal execution of this Security framework call writes this message to the console log. My presumption, based on normal coding practices, is that a system framework call would write to the console log only under abnormal or erroneous circumstances. Yes, when everything is working properly (in an appropriate, hostname-checking implementation) the trust-evaluate should fail but failure is not an error in this situation, rather, it is an expected, potential result.

Furthermore and secondarily, this error message is happening even after I have altered my cert pinning code to specifically skip the hostname check, as I detailed in my prior message

I have actually commented out the part of my code that allows for the hostname check (i.e. use SecPolicyCreateSSL to create “a policy object for evaluating SSL certificate chains" and supply a hostname that ”if present, the policy will require the specified hostname to match the hostname in the leaf certificate" and then include this policy in the trust object via SecTrustSetPolicies)

Thus, I was hoping/expecting the trust evaluation to actually succeed despite spinner's MITM redirection, i.e. I wanted to see the spinner tool effectively evade a purposefully faulty implementation of root/CA pinning.