jchambers
commented
3 years ago Thank you for the report. I'll look into it.
It's my fault for not having clear instructions, but in the future, please do not report security vulnerabilities in public issues. Doing so advertises the vulnerabilities to bad actors until a new release is out and a majority of users have updated to the new release. Again, I emphasize that this is on me for not publishing clear instructions for what to do instead, and I'll make sure to get those instructions published as part of this issue.
Drauggy
Hey! I ran into vulnerability like man in the middle attack in Pushy code. Pushy uses the Netty library under the hood, which does not include hostname verification logic by default (see https://github.com/netty/netty/issues/9930). This looks logical, since SSLContext does not know anything about the type of protocol used and, accordingly, does not know how to check the host correctly. Pushy does not validate the hostname of remote connection and does not validate it against alternative name in certificate from peer. I tested this vulnerability myself. This can be done most simply by replacing dns -name in / etc / hosts Thus, if an attacker organizes a spoofing attack (arp-spoofing, dns -spoofing ...) and stands in the middle, then using a certificate issued by a trusted certification authority, but in a name different from the name of the target address (api.push.apple.com, api .development.push.apple.com), then it will be able to receive automatically decrypted push messages. A logical solution to this problem, as I see it, may be to add the default HostnameVerifier class to the utils package. And to make it possible for the end user to change this verifier as the strategy pattern does. For version 0.13.10, which I am using in my project, you can do this as follows: Insert the following code into the ApnsChannelFactory class in the body of the initChannel method:
.....
.... The implementation of the DefaultHostnameVerifier can be seen from the appache http client.
An example of a trace stack for a verifier's error when making a mitm attack:
11:33:10,419 WARN [io.netty.util.concurrent.DefaultPromise] (nioEventLoopGroup-2-1) An exception was thrown by com.turo.pushy.apns.ApnsChannelFactory$1$1.operationComplete(): java.net.ConnectException: HostnameVerifier exception.
11:33:10,419 ERROR [stderr] (pusher_task_executor_thread1) java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Channel closed before HTTP/2 preface completed.