MITM with IOS failing

[arvind-muthukrishnan]

Steps performed:
1.
Ran nogotofail.mitm server using
"python -m nogotofail.mitm --mode socks --port 8080 --serverssl ../trusted-cert.pem -t traffic.log -e event.log" -A selfsigned -p 1

Made a vulnerable app in android and forced the device to use socks proxy server.(running in machine at 8080). Got the response of MITM Success.
It also worked with mac and linux machines when made insecure connection and on setting socks proxy. for instance, this was the command tested."curl --proxy socks5://my-ip:8080 https://www.google.co.in --insecure"

In similar fashion, on setting socks proxy using a pac file in iPhone and running a vulnerable app (overriding ssl verification). I got an error on client side, "CFNetwork sslhandshake failure(-108) and NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -108)". My understanding about this tool is that any requests made through socks proxy server is subjected to testing.

Note: MITM attack performed through sslsplit and dsniff tool was success and could intercept the resquest and response of IOS vulnerable app.

Error while debugging on server side:
" selfsigned](Unknown) SSL exception: (-1, 'Unexpected EOF') "

I'm not sure if it is a bug or I'm missing something.

[chadbrubaker]

" selfsigned](Unknown) SSL exception: (-1, 'Unexpected EOF') " is probably because the iPhone closed the socket mid handshake(pyOpenSSL errors are pretty useless for debugging sadly).

There might be an issue with the self signed certs I'm generating that iOS rejects for other reasons, but I can't seem to find what the -108 error code means.

[klyubin]

Have you tried the invalidhostname attack against your app in iOS? This attack uses an official cert and can thus help find out whether the issue you are seeing is caused by the way nogotofail generates the self-signed cert or with how it's using OpenSSL to MiTM connection.

The invalidhostname attack requires you to provide the MiTM with a cert (and private key) whose chain-of-trust verifies but which is for the wrong hostname.

[arvind-muthukrishnan]

Thanks for the responses.

@chadbrubaker I couldn't make much debug information from the tool or from my app. Only exception that I could get is (CFNetwork handshake failure -108) when used self-signed certificate. Is there any way to clear this error?

@klyubin I also tried with invalidhostname attack as I'm having one of a valid certificate. This time i got error message of CFNetwork SSLHandshake failed (-9806) in the client side. No debug info from the tool regarding this failure, could be got.
"python -m nogotofail.mitm --mode socks --port 8080 --serverssl ../trusted-cert.pem -t traffic.log -e event.log" -A invalidhostname -p 1

In the above command, "trusted-cert.pem" is the trusted certificate.

[klyubin]

Interesting. Can you confirm that your test app does indeed not verify the
hostname match and chain-of-trust of the server certificate?

I'd suggest one more test: make your test app connect to the hostname which
matches the cert in trusted-cert.pem and see what happens when nogotofail
MiTM mounts the invalidhostname attack. In theory, the MiTM should see the
attack succeed. I wonder what will happen in practice. Perhaps the way the
MiTM acts as a TLS/SSL server doesn't work for iOS clients.
On Nov 25, 2014 20:54, "arvind-muthukrishnan" [email protected]
wrote:

Thanks for the responses.

@chadbrubaker https://github.com/chadbrubaker I couldn't make much
debug information from the tool or from my app. Only exception that I could
get is (CFNetwork handshake failure -108). Is there any way to clear this
error?

@klyubin https://github.com/klyubin I also tried with invalidhostname
attack as I'm having one of a valid certificate. This time i got error
message of CFNetwork SSLHandshake failed (-9806) in the client side. No
debug info from the tool regarding this failure, could be got. In the above
command, "trusted-cert.pem" is the trusted certificate.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[arvind-muthukrishnan]

@klyubin As expected, on loading request with hostname matching my trusted certificate, it showed
"MITM SUCCESS!!!". My problem is that other tools(dsniff and sslsplit) could intercept my data with vulnerable app (confirming ssl validation skip). Nogotofail works good with other devices except IOS.

But as marked in blog, http://googleonlinesecurity.blogspot.in/2014/11/introducing-nogotofaila-network-traffic.html
"Nogotofail works for Android, iOS, Linux, Windows, Chrome OS, OSX, in fact any device you use to connect to the Internet."

Shouldn't it work with IOS ?

[chadbrubaker]

I couldn't find anything about that specific error code in the
documentation which makes this tricky to debug sadly.

What cipher/version does the client select? I wonder if something with
pyopenssl is causing issues. Are you using pyopenssl .13 or .14?
On Nov 25, 2014 10:41 PM, "arvind-muthukrishnan" [email protected]
wrote:

@klyubin https://github.com/klyubin As expected, on loading request
with hostname matching my trusted certificate, it showed
"MITM SUCCESS!!!". My problem is that other tools(dsniff and sslsplit)
could intercept my data with vulnerable app (confirming ssl validation
skip). But this works good with other devices except IOS.

But as marked in blog,
http://googleonlinesecurity.blogspot.in/2014/11/introducing-nogotofaila-network-traffic.html
"Nogotofail works for Android, iOS, Linux, Windows, Chrome OS, OSX, in
fact any device you use to connect to the Internet."

Shouldn't it work with IOS too?

—
Reply to this email directly or view it on GitHub
#32 (comment).

[chadbrubaker]

Oh, I missed that it worked when MiTMing a connection to the invalidhostname destination, that probably rules out pyopenssl doing weird things...

From http://www.opensource.apple.com/source/libsecurity_ssl/libsecurity_ssl-36800/lib/SecureTransport.h:
errSSLClosedAbort = -9806, /* connection closed via error */

That error code sounds like it could mean the client aborted the connection(in the hostname callback?) or the MiTM sent an abort. I'm leaning toward the first but I don't know the iOS SSL APIs much. But that should use error code -9843.

[klyubin]

Can you please confirm that your iOS test app does NOT perform hostname verification? One way to test that is to remove nogotofail MiTM from path, and redirect the app's/device's traffic to a different TLS/SSL server which presents an SSL certificate whose chain-of-trust which verifies. You could redirect this in the hosts file or in the router/firewall.

For example, the app thinks it's connecting to www.apple.com:443 but its traffic is actually sent to www.android.com:443.

[arvind-muthukrishnan]

@chadbrubaker I'm using pyopenssl 0.14. Still need to check in wireshark to find ciphers exchanged between the client and server. Good to know that client "closed connection via error".

I didn't receive any certificate when run with attack "-A selfsigned". But I could get my trusted certificate in case of "-A invalidhostname".
One more doubt. In case of -A selfsigned, when will the self-certificate be generated?

[chadbrubaker]

They'll be generated once the connection is initiated based off what the
remote presents as a cert. They should all be in /tmp prefixed with .ngtf
(I think). The rest of the name I'd a hash of the cn+subject alt name.

On Wed, Nov 26, 2014, 22:29 arvind-muthukrishnan [email protected]
wrote:

@chadbrubaker https://github.com/chadbrubaker I'm using pyopenssl 0.14.
Still need to check in wireshark to find ciphers exchanged between the
client and server. Good to know that client "closed connection via error".

I didn't receive any certificate when run with attack "-A selfsigned". But
I could get my trusted certificate in case of "-A invalidhostname".
One more doubt. In case of selfsigned, when will the self-certificate be
generated?

—
Reply to this email directly or view it on GitHub
#32 (comment).

[dashmesh]

Hi,
Did you have any success with this issue?

I have setup nogotofail on GCE and successfully used it successfully with an android device running an OpenVPN client.

However, the MITM server does not register any traffic coming in from an iOS device running the Open VPN client.

Any help would be appreciated.

Thank you.

[chadbrubaker]

Can you verify on the server with tcpdump that traffic from the iOS device
is passing through the vpn?

Also note that without a client running on the device nogotofail.mitm will
show the traffic as originating from an unknown device.

On Sat, Feb 13, 2016, 15:12 atkVktr [email protected] wrote:

Hi,
Did you have any success with this issue?

I have setup nogotofail on GCE and successfully used it successfully with
an android device running an OpenVPN client.

However, the MITM server does not register any traffic coming in from an
iOS device running the Open VPN client.

Any help would be appreciated.

Thank you.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[dashmesh]

Hi Chad,

Thanks for the help.

You were right in presuming that the tunnel traffic was not reaching the
server. I am not sure yet about what the issue is but I did try it from
three separate devices (one of which is jailbroken like the first one) and
I could detect traffic on interface tun0.

I will keep you posted if I encounter any issues.

Thank you and regards,
Dashmesh

On Sat, Feb 13, 2016 at 8:03 PM, Chad Brubaker [email protected]
wrote:

Can you verify on the server with tcpdump that traffic from the iOS device
is passing through the vpn?

Also note that without a client running on the device nogotofail.mitm will
show the traffic as originating from an unknown device.

On Sat, Feb 13, 2016, 15:12 atkVktr [email protected] wrote:

Hi,
Did you have any success with this issue?

I have setup nogotofail on GCE and successfully used it successfully with
an android device running an OpenVPN client.

However, the MITM server does not register any traffic coming in from an
iOS device running the Open VPN client.

Any help would be appreciated.

Thank you.

—
Reply to this email directly or view it on GitHub
#32 (comment).

—
Reply to this email directly or view it on GitHub
#32 (comment).