¿Es la implementación del servicio de notificaciones push de Apple vulnerable a un ataque MitM?

No tengo mucho tiempo ahora y no lo he verificado a fondo, así que esto es solo lo que recuerdo al analizar esto hace unos meses.

Con OS X 10.9 y iOS 7, Apple introdujo algún tipo de identificación de certificado para el servicio de inserción, es decir, no permite que ninguna CA que el sistema sepa firme su certificado de servidor de inserción, sino solo una CA específica. La identificación de este certificado fue un poco extraña, ya que tenía algún tipo de fecha de caducidad del 1 de enero de 2014, pero no me interesé por lo que eso significa exactamente y no sé si las últimas versiones de OS X y iOS todavía incluyen esto.

  

Certificado de hoja no reconocido

Por lo que tengo entendido, este mensaje no significa que apsd no pueda verificar el certificado en absoluto, sino que podría significar que la identificación del certificado no pudo verificarlo (lo que significaría que la fijación del certificado es actualmente opcional, lo que a su vez podría tiene que ver con la fecha de caducidad).

Es posible que no tenga que preocuparse por esto directamente, ya que la validación normal del certificado SSL aún funciona (como lo confirma su prueba). Por otro lado, me encantaría saber por qué la fijación de certificados no funciona y qué significa la fecha de caducidad.

ACTUALIZACIÓN : aquí hay más información sobre por qué se muestra el mensaje de registro.

Puede mostrar el certificado del servidor utilizando openssl (parece que el mismo certificado se entrega en los puertos 443 y 5223):

openssl s_client -prexit -connect 1-courier.push.apple.com:5223  2>/dev/null | openssl x509 -noout -text |grep -E '(Subject.*CN|Serial)'

A partir de 2014-05-10, muestra la siguiente información:

Serial Number: 1277288244 (0x4c21df34)
Subject: C=US, ST=California, L=Cupertino, O=Apple Inc., CN=courier.push.apple.com

El binario apsd contiene varios certificados X.509 utilizados para la fijación de certificados. Escribí una secuencia de comandos para buscar certificados en un binario . Aquí hay un extracto cuando lo ejecutamos en apsd :

+ 469280 Found cert with CN "courier.sandbox.push.apple.com" and serial "1277027356"
+ 470416 Found cert with CN "courier.push.apple.com" and serial "1276925395"
+ 471584 Found cert with CN "Entrust.net Certification Authority (2048)" and serial "946059622"
[skipping some code signing certificates]

Como puede ver, el certificado anclado para courier.push.apple.com tiene un número de serie diferente al que recibe el servidor push de Apple . Entonces, ambos son certificados diferentes y, aparentemente, este es el motivo del mensaje de registro Unrecognized leaf certificate que ve. Como apsd aún se conecta al servidor, esto significa que apsd no requiere un certificado de hoja fija para que coincida.

Otra cosa que puede ver es el tercer certificado, un certificado de CA . El año pasado, cuando intenté que apsd se conectara a pushproxy , tuve que reemplace el certificado de CA para hacer apsd trust pushproxy. Esto significa que, mientras no se verifica el certificado de hoja, apsd solo puede permitir certificados de una determinada CA raíz. No verifiqué esto recientemente.

Para verificar esto a fondo, además de verificar si la fijación de certificados de CA para la conexión SSL sigue siendo efectiva, uno tendría que verificar otra cosa. Antes de conectarse al servidor push, apsd descarga una 'bolsa de configuración' . Esta bolsa se descarga a través de HTTP, pero se firma. La bolsa contiene el nombre de host apsd y luego intenta conectarse. Esta es una manera que estoy usando para que pushproxy redirija apsd a otro host. Puede encontrar más información sobre la bolsa en el pushproxy README y en script para generar tal bolsa .

Ya que nadie respondió aún, pensé que tal vez debería poner mi método de cómo probé esto y luego alguien podría señalar si eso está bien o no.

Escribí un servidor básico en python escuchando en el puerto 5223 de esta manera:

#!/usr/bin/python
import SocketServer
import ssl

class requestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        print self.client_address[0] + ' connected.'
        receivedData = self.request.recv(4096)
        print receivedData

        #self.request.sendall('test')
        return

server = SocketServer.TCPServer(('0.0.0.0', 5223), requestHandler)
server.socket = ssl.wrap_socket(server.socket, server_side=True, keyfile='privateKey.pem', certfile='selfSignedCert.pem')
#server.socket = ssl.wrap_socket(server.socket, server_side=True, keyfile='privateKey.pem', certfile='selfSignedCert.pem', cert_reqs=ssl.CERT_REQUIRED, ca_certs='expectedClient.pem')
print 'Listening on port 5223'
server.serve_forever()

La línea comentada de server.socket al final es la versión con la que se solicita al cliente (apsd) el certificado. He creado los certificados llamando a openssl en la consola:

openssl req -new -x509 -days 365 -nodes -out selfSignedCert.pem -keyout privateKey.pem

El expectedClient.pem que he extraído utilizando Wireshark del tráfico real donde se encuentra en el formato DER . Así que lo he convertido a PEM con este código:

#!/usr/bin/python
import ssl

inFileHandle = open('clientCert.der', 'rb')
outFileHandle = open('clientCert.pem', 'wb')
outFileContent = ssl.DER_cert_to_PEM_cert(inFileHandle.read())
outFileHandle.write(outFileContent)
inFileHandle.close()
outFileHandle.close()

Ahora necesitaba engañar a apsd de que xxx-courier.push.apple.com es en realidad 127.0.0.1 . Escribí un bouncer (proxy) básico de DNS que busca una consulta con dicha dirección y responde que la IP es 127.0.0.1.
Aquí está el código:

#!/usr/bin/python
import SocketServer
import socket

DNS_server = '8.8.8.8' # Your ISP's DNS server(8.8.8.8 is Google Public DNS)
DNS_formatted_address_match = '-courier' + chr(4) + 'push' + chr(5) + 'apple' + chr(3) + 'com' + chr(0)

class requestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        queryData = self.request[0]
        incomingSocket = self.request[1]

        transactionID = queryData[:2] # First two bytes
        DNS_formatted_query_address = queryData[12:].split(chr(0))[0] + chr(0) # First 12 bytes are DNS header

        if DNS_formatted_address_match in queryData:
            # DNS protocol explained: http://technet.microsoft.com/en-us/library/dd197470(v=ws.10).aspx
            forgedResponse = (transactionID + 
                            chr(129) + chr(128) + 
                            chr(0) + chr(1) + 
                            chr(0) + chr(1) + 
                            chr(0) + chr(0) + 
                            chr(0) + chr(0) + 
                            DNS_formatted_query_address + 
                            chr(0) + chr(1) + 
                            chr(0) + chr(1) + 
                            chr(192) + chr(12) + chr(0) + chr(1) + 
                            chr(0) + chr(1) + 
                            chr(0) + chr(0) + chr(0) + chr(60) + chr(0) + chr(4) + 
                            chr(127) + chr(0) + chr(0) + chr(1))

            incomingSocket.sendto(forgedResponse, self.client_address)
        else:
            outgoingSocket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
            outgoingSocket.sendto(queryData, (DNS_server, 53))
            responseData = outgoingSocket.recv(4096) # DNS response should not be more than 512 bytes so this should be more than enough
            incomingSocket.sendto(responseData, self.client_address)

        return

server = SocketServer.UDPServer(('0.0.0.0', 53), requestHandler)
print 'Listening on port 53'
server.serve_forever()

Debe iniciarlo con sudo , porque de lo contrario no querrá enlazar en el puerto 53. Y el último paso fue cambiar el servidor DNS en mis preferencias de red a 127.0. 0.1 para que la búsqueda de DNS en realidad pase por el bouncer y luego al ISP.

Eso es todo!

Ahora puedes probarlo tú mismo si quieres ...