Invetigación de RPC

Implementaciones más comunes de RPC

•    RPC está desarrollado en C, pero algunas versiones permiten programar en otros lenguajes como Fortran. Las implementaciones más actuales trabajan sobre XML formando los XML-RPC.

Para la conexión entre un cliente y un servidor utilizando RPC se siguen dos pasos: localizar la máquina servidor, y localizar el proceso en esa máquina.

•    Las implementaciones más evolucionadas de RPC incluye la de Sun ONC (Open Network Computing) y DCE (Distributed Computing Environmet) Soporta el modelo cliente-Servidor sobre el que se construyo un sistema de ficheros en red NFS.

Como se asegura las transmisiones basadas en RPC

La llamada de procedimiento remoto (RPC) segura protege los procedimientos remotos con un mecanismo de autenticación. El mecanismo de autenticación Diffie-Hellman autentica tanto el host como el usuario que realiza una solicitud para un servicio. El mecanismo de autenticación utiliza el cifrado Estándar de cifrado de datos (DES). Las aplicaciones que utilizan RPC segura incluyen NFS y los servicios de nombres, NIS y NIS+.

DIFFIE-HELLMAN

El algoritmo Diffie-Hellman fue el primer algoritmo de llave pública  inventado. Esto significa que sus autores también son los dueños de la idea. El algoritmo puede ser usado para la distribución de llaves, pero no para cifrar o descifrar mensajes. Su seguridad reside en la dificultad de calcular logaritmos discretos en un campo finito comparada con la facilidad de realizar exponenciaciones es en el mismo campo.

 

Como se aseguran las transmisiones basadas en RPC

1. Fallos en los procedimientos llamados

    La ejecución del proceso llamado se detiene por errores del

    hardware o del sistema operativo que lo ejecuta (ejemplo: caída del sistema)

    También por errores internos del propio procedimiento (divisiones

     por 0, índices de arrays fuera de rango, etc.)

2. Fallos en la comunicación

     Perdida de la conexión: la red deja de enviar paquetes (caída de la red, perdida de un    enlace, ...)

    Corrupcion del contenido de alguno de los mensajes enviados.

    Perdida de paquetes: algún mensaje  no llega a su destino.

    Recepcion fuera de orden: paquetes retrasados recibidos de forma desordenada

3. Otros fallos: bugs en el proceso llamado, ataques, etc.

En una base de datos para que se implementan los RPC

SQL Server admite el uso de servidor a servidor RPC, que permite utilizar una conexión a un servidor para llamar a un procedimiento en un servidor secundario. En este artículo se describe un método para utilizar RPC para llamar a cualquier procedimiento almacenado extendido personalizado en un servidor secundario sin cambiar el código de la aplicación.

La llamada a un procedimiento almacenado extendido puede producirse de dos maneras diferentes:

·         Ad-hoc Transact-SQL.

·         Mediante una llamada a un "contenedor" procedimiento almacenado.

En cualquier caso, puede redirigir la llamada a un servidor remoto mediante una llamada de SQL Server RPC sin realizar ningún cambio a la aplicación cliente.

Que vulnerabilidades presentan el uso  de los RPC

La vulnerabilidad podría permitir a un atacante ejecutar código arbitrario y tomar control total del sistema afectado. La configuración por defecto no permite que los usuarios sean atacados por medio de esta vulnerabilidad, aunque podría ser afectada en aplicaciones de terceros.

Vulnerabilidades XMLRPC en PHP

Otra vulnerabilidad bastante común en esta categoría incluye vulnerabilidades en el uso de XML-RPC

XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte.

Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión.

Un común desperfecto está en los distintas implementaciones de XML-RPC en PHP pasando entradas de datos del usuario sin filtrar por la función eval() en el servidor XML-RPC. Esto permite al atacante ejecutar código, en el sistema vulnerable. Cualquier usuario con habilidad de subir XML manualmente al servidor puede insertar código PHP que puede ser ejecutado por la aplicación Web vulnerable.