Internet Security Auditors miembro de grupo de Asesores Ejecutivos Global del PCI SSC


El PCI SSC lanzó hace unos meses una nueva iniciativa para contar con un grupo de expertos a nivel global de empresas abriendo la presentación de candidaturas a todas las empresas que participan como asesores en todo el mundo, que superan las 450. Internet Security Auditors presentó la candidatura con la representación su Director de Consultoría y socio, Miguel A. Domínguez.

Tras dos meses de revisión de las candidaturas, que debían cumplir con amplios requerimientos a nivel de compañía y representante, el PCI SSC confirmó que la nuestra había sido seleccionada para formar parte de un exclusivo grupo de 20 empresas a nivel mundial.

El grupo de Asesores Ejecutivos del PCI SSC pretende servir los próximos dos años como un canal directo para la comunicación entre el liderazgo superior de los asesores de seguridad de pagos y el liderazgo senior de PCI SSC.

Los asesores serán responsables de proporcionar asesoramiento, comentarios y orientación al PCI SSC; proporcionar aportes tanto abiertos como expertos tanto desde el punto de vista comercial como técnico; representar los puntos de vista e intereses del evaluador PCI y las comunidades evaluadas; y estar disponible y dispuesto a participar en proyectos especiales PCI SSC.

Este es un importante hito para Internet Security Auditors porqué nos sitúa con la responsabilidad de ser la única empresa de origen iberoamericana, con el interés de representar a países que representan a más de 800 millones de habitantes, y que nos permitirá aportar la experiencia de la compañía en países que el PCI SSC considera claves en sus iniciativas de la seguridad de los Medios de Pago además de situar a la compañía entre el Top20 de empresas del mundo PCI.

Preguntas y Respuestas sobre el nuevo tipo de examen de CISSP CAT (Computerized Adaptive Testing)

Estos últimos meses se han presentado muchas inquietudes por el cambio del modelo de examen que ha adoptado el (ISC)2, y que viene siendo una tendencia entre muchas organizaciones, para la realización de los exámenes de CISSP. Este nuevo modelo de examen, en el que el examinado debe ir respondiendo preguntas y, en base a sus respuestas, las preguntas se adaptan y definen, tiene como objetivo reducir el tiempo y cantidad de preguntas y, se pretende, evaluar de forma más efectiva el conocimiento del examinado ante las materias en las que se examina.

Pero esto modelo también ha hecho que surjan dudas. En base a la experiencia de uno de nuestros compañeros del equipo consultor de Internet Security Auditors, y sin pretender ser un P/R “oficial” ni encuesta, hemos planteado algunas preguntas y respuestas que, no han sido respondidas por el (ISC)2.

1. ¿Es verdad que si se responde bien a las preguntas de CISSP solo se respondería de 100 a 110?  y si le va mal responde las 150 preguntas totales del examen?
En principio, el número de preguntas oscila entre el mínimo de 100 y el máximo de 150. De acuerdo con el (ISC)2, el examen finaliza cuando el sistema puede determinar con una confianza del 95%, que el candidato se encuentra por encima o por debajo del estándar para pasar el examen. En mi caso, respondí 148 preguntas agotando el tiempo máximo de 3h de examen, encontrándome finalmente por encima del estándar para pasar el examen.

2. ¿Como es el nuevo criterio de evaluación para las preguntas del examen CISSP, tiene alguna pregunta mayor valor que las restantes?
En principio, el valor de las preguntas depende de la actual ponderación de los dominios (actualizada a Abril de 2018). No ha habido cambios significativos, pero conviene tenerlos en cuenta para dedicar más esfuerzos en aquellas áreas con más peso (y especialmente, en aquellas que se tengan menos conocimientos/experiencia).

3. ¿Se requiere experiencia en todos los dominios del CISSP o estudiando términos y definiciones es suficiente para pasar el examen de certificación?
No es estrictamente necesario tener experiencia en todos los dominios. Aprendiendo por conocimiento, estudiando los materiales disponibles y practicando el examen es posible pasarlo (como es mi caso). Sin embargo, una vez aprobado, para poder solicitar el certificado es necesario demostrar que se tiene experiencia en al menos 2 dominios.

4. ¿El tipo de preguntas de opción múltiple en la anterior versión del examen CISSP, es la misma que en el actual modelo de examen de certificación de ISC2 para el examen CISSP?
En principio, el tipo de preguntas de opción múltiple es el mismo. Es importante fijarse bien en cual es el criterio para responder, este suele verse claramente en mayúsculas en el enunciado (“el MEJOR método”, “el MAS seguro”, etc). Por otro lado, el examen también incluye preguntas innovadoras avanzadas (en mi caso fueron tan solo unas pocas), del estilo drag&drop que consisten en ordenar todas las respuestas en base a un criterio dado.

5. ¿Para la nueva versión del examen, es posible poder retornar y revisar las preguntas contestadas o no del examen?
En el modelo CAT, durante el examen no es posible revisar ni cambiar las respuestas a las preguntas que ya han sido respondidas. Es importante tenerlo en cuenta.

6. Para el actual examen de certificación de CISSP, ¿sigue el mismo concepto para responder las preguntas de 'pensar como administrador' CIO/CISO? ¿o ahora es más técnico el examen?
En base a mi experiencia, no sentí la necesidad de tener que situarme mentalmente más en un nivel de gestión, o bien, más en un nivel técnico, para poder responder las preguntas. Sin embargo, sí que conforme sentía que respondía correctamente más preguntas, las siguientes trataban aspectos más específicos y concretos, incluidos detalles técnicos particulares de ciertas tecnologías/protocolos/etc.

7. ¿Qué documento, guía y/o recurso de estudio crees que pueda recomendar como referencia de estudio para en el examen CISSP?
Personalmente, he utilizado la Official Study Guide de Sybex y el CISSP CBK. Considero que la Official Study Guide es un recurso básico, para poder obtener una visión completa de todos los dominios, en un primer nivel de profundidad. Respecto al CISSP CBK, considero que es un recurso complementario especialmente recomendable para las personas que no dispongan de suficiente experiencia en todos los dominios. Permite alcanzar un segundo nivel de profundidad, que puede permitir acabar de entender y clarificar determinados conceptos sobre los que se pueden tener dudas, o que se habían entendido de forma diferente.

8. ¿Cuánto tiempo hay para realizar el nuevo examen de certificación CISSP, dado que ya son solo 150 preguntas máximo?
El tiempo máximo disponible es de 3h, no habiendo un límite de tiempo mínimo.

9. ¿Cuál de estos dos factores crees que es el principal para pasar con éxito el examen de certificación, experiencia o saber interpretar correctamente las preguntas?
Creo que el factor principal es entender correctamente cada uno de los conceptos, aclarando las dudas más importantes que se tengan, y revisando que nos cuadren nuestras respuestas con las justificaciones oficiales (en ocasiones uno está convencido de haber entendido un concepto correctamente, sin embargo, puede haberse entendido de forma diferente, llevándonos a error a la hora de responder). Por otro lado, creo que la experiencia ayuda, permite diferenciar aquellos conceptos/aspectos esenciales de aquellos que son importantes (que son muchos), y nos permite tener un grado de confianza respecto a unos dominios que a su vez nos permite centrarnos en aquellos en los que cojeamos más.  

10. ¿Las guías de estudio oficiales de ISC2 para la certificación CISSP aún son válidas para esta nueva versión de examen?
La nueva revisión de 2018 de la Official Study Guide de Sybex ya está actualizada a la versión actual del examen. Si es posible, recomendaría hacerse con ella pues incorpora los cambios en los dominios que se han producido desde la revisión de 2015. En mi caso, no me fue posible adquirir y revisar la revisión de 2018, sin embargo, utilizando la de 2015, buscando en Internet el resumen de los cambios entre revisiones, y estando un poco al día de los actuales paradigmas y tecnologías (Cloud computing, generadores de códigos de 2FA -ej. Google Authenticator-, etc) fue suficiente.


Carlos Sans García - CISSP, CISA, ISO 27001 LA, ISO22301 LA
Depto. de Consultoría

Actualizaciones en Materia de Seguridad de la Información de la Circular Básica Jurídica de la SFC

De acuerdo con la legislación colombiana, la Superintendencia Financiera de Colombia (en adelante SFC) somete a inspección, vigilancia y control a las entidades que realizan la inversión o manejo de recursos recibidos o captados del público. Esta definición no incluye a las entidades que se dedican a prestar servicios en la red asociados al comercio electrónico para almacenar, procesar y/o transmitir el pago correspondiente a operaciones de venta en línea comúnmente conocidas como pasarelas de pago. Sin embargo, teniendo en cuenta que una de las responsabilidades de la SFC es la de preservar la confianza pública de los ciudadanos y la estabilidad del sistema financiero, ésta ha decidido regular a las pasarelas a través de la relación contractual que se genera cuando los establecimientos de crédito y los administradores de sistemas de pago de bajo valor (aquellos que tienen lugar entre consumidores, empresas y el gobierno, generalmente por bajas cuantías y de menor urgencia, dado que no hay un número único que defina la frontera entre un pago individual de alto o uno de bajo valor, su categorización termina siendo basada en la naturaleza de las operaciones, los instrumentos de pago utilizados, los canales de pago por los cuales se efectúan las correspondientes transferencias de dinero y lo crítico que puede ser la pronta oportunidad del pago) establecen relaciones comerciales con las pasarelas de pago para las actividades relacionadas con la prestación de servicios de aplicación de comercio electrónico para almacenar, procesar y/o transmitir el pago correspondiente a operaciones de venta en línea.

La vinculación a la vigilancia que realizará la SFC de las pasarelas de pago se da en la Circular Externa 008, publicada el 5 de junio de 2018, donde se incorporan las nuevas responsabilidades para las pasarelas de pago, formalizando algunas que ya estaban heredando de manera contractual como son el cumplimiento de las regulaciones relacionadas con la prevención de lavado de activos y financiación del terrorismo (SARLAFT).

Otras responsabilidades adicionadas están asociadas al cumplimiento de la Ley 1581 de 2012 -de Protección de Datos Personales- y la Ley 1266 de 2008 -Ley de Habeas Data- que, por la definición del alcance de estas leyes, estos establecimientos ya deberían estar cumpliendo.

Una obligación nueva, que es una buena práctica de la industria, es la de dar información al consumidor financiero sobre la manera como se realiza el procedimiento de pago, que consiste en una alineación perfecta con los estándares de la industria en materia de seguridad en relación con los programas de concientización que se deben mantener, de manera continua, para asegurar que el eslabón más débil en la cadena de seguridad, los usuarios, realice sus procesos de la manera adecuada.

Dentro de las nuevas responsabilidades sobre las pasarelas de pago, nace una adición que es la adopción de un estándar de la industria de medios de pago con tarjeta que no estaba dentro de las obligaciones de las entidades vigiladas. El estándar en mención es el PCI DSS (que está mal relacionado en la primera mención a este -denominándolo PCI DDS- pero indicado de manera correcta en la segunda mención).

Para entender el alcance de esta nueva responsabilidad debemos conocer un poco sobre este estándar. PCI DSS, acrónimo del término en inglés Payment Card Industry Data Security Standard, fue desarrollado por 5 de las grandes franquicias de pago (Visa, MasterCard, Discover, American Express, JCB) con el objetivo de proteger los datos de tarjeta en los procesos, tecnologías y personas relacionadas con el almacenamiento, procesamiento y transporte de dichos datos.

PCI DSS define un conjunto de controles orientados a preservar la confidencialidad de los datos de tarjeta, los controles definidos pasan desde políticas y procedimientos, pasando por el establecimiento de mecanismos técnicos de monitoreo y control hasta llegar a algunos detalles asociados a versiones específicas de algoritmos.

La cadena de obligación de cumplimiento habitualmente venía dada por la relación contractual que existe entre las diferentes partes que componen el ambiente de medios de pago, entre estos componentes tenemos: las franquicias, los adquirientes, los comercios y los proveedores de servicio. Las pasarelas de pago suelen ubicarse dentro del rango de proveedores de servicio, aunque algunas realizan funciones adicionales.

Aunque esta obligación de cumplimiento del estándar está definida en los diferentes contratos, la aplicación de la misma en muchos casos no se da por falta de control de los adquirientes sobre sus proveedores de servicio y se hace de manera irregular.

El proceso de validación de cumplimiento está diseñado para que algunas empresas que han pasado estándares rigurosos de validación,  formación continua y aseguramiento de calidad, sean acreditados para realizar dichas verificaciones de cumplimiento, estas organizaciones deben seleccionar especialistas teniendo en cuenta su experiencia y certificaciones en temas relacionados con seguridad de la información, para luego hacerlos formar y certificar por parte del PCI SSC (Payment Card Industry Standards Security Council), una vez certificados obtienen el título de QSA (Qualified Security Assessor) y se debe hacer un proceso anual de re-entrenamiento y re-certificación para el mantenimiento de dicha acreditación.

Cerrando el paréntesis que se abre para la explicación sobre el estándar, debemos analizar la implicación de este requisito. La imposición del mismo nace de la necesidad de brindar seguridad en un canal que anteriormente no estaba regulado por el estado y que es un vector de ataque de las organizaciones criminales ya que da acceso a grandes cantidades de datos de tarjetas, lo que hace de este sector un objetivo bastante atractivo.

El estándar está definido para ser cumplido sobre ambientes que manejen tarjetas franquiciadas; cuando la SFC lo pone como obligación para las pasarelas de pago amplía su alcance a tarjetas no franquiciadas, obligando a muchas pasarelas que centran su servicio en tarjetas no franquiciadas a cumplir con dicho estándar, y de paso asegurando que la información del consumidor financiero colombiano tiene unos mecanismos mínimos de protección.

Al asumir el estándar PCI DSS, la SFC deja en manos del PCI SSC la seguridad de los medios de pago del consumidor financiero colombiano, esto tiene dos puntos de vista: el malo, una regulación colombiana que depende de un ente que no es colombiano para definir los mecanismos de control para proteger la información de los residentes en Colombia; el bueno, este ente se mantiene a la vanguardia en temas de seguridad de la información y está alineado con las buenas prácticas de la industria.

La validación de cumplimiento del estándar es delegada por la SFC en los QSA (Qualified Security Assessor) que son las empresas calificadas para verificar la correcta implantación de los controles de la norma en un ambiente, lo cual asegura una vigilancia continua de la alineación de las empresas con el estándar, sin embargo, no hace referencia a quien debe realizar el monitoreo de que dichas validaciones de cumplimiento sean realizadas.

Otro elemento importante incluido es el requerimiento de mantener vigente la certificación de manera anual, esto busca garantizar que los controles de seguridad son mantenidos por las organizaciones como parte de su operación diaria brindando un ambiente seguro para las operaciones realizadas a través de estas pasarelas.

Fuera de los cambios relacionados con las pasarelas de pago encontramos que esta circular, además de actualizar algunos términos, hacer salvedades necesarias y aclarar la redacción en algunos puntos, extiende el alcance de otros numerales o sub-numerales de la norma, entre estos tenemos:
  • Los canales e instrumentos de prestación de servicios financieros que estaba limitando el ámbito de aplicación a tarjetas de crédito y móviles, dando alcance a las tarjetas débito y a cualquier dispositivo electrónico que sirva para realizar operaciones.
  • Esta ampliación permite asegurar que todos los tipos de tarjetas y nuevos medios de pago, como por ejemplo carteras electrónicas son tenidas en cuenta dentro de los controles que se deben tener en cuenta en el momento de usar alguno de los canales o instrumentos de prestación de servicios financieros asegurando que las entidades financieras no dejen de cumplir sus obligaciones por cuenta de una falta de especificidad de la norma.
  • El análisis periódico de vulnerabilidades, que anteriormente era obligatorio para los establecimientos de crédito y los administradores de pago de bajo valor, ha extendido su alcance a las sociedades especializadas en depósitos y pagos electrónicos y las entidades vigiladas que permitan la ejecución de órdenes electrónicas para la transferencia de fondos, la compra, venta o transferencia de títulos valores y la emisión de pólizas de seguros, por sistemas de acceso remoto para clientes, Internet o dispositivos móviles.
  • La ampliación de este alcance busca que todos los canales o entidades que los usuarios del sistema financiero usan para movimientos financieros estén monitoreados de acuerdo con las buenas prácticas de la industria relacionadas con el monitoreo del estado de seguridad técnica de los canales usados para este tipo de transacciones.
  • El envío de información confidencial cifrada por correo electrónico ahora se amplía a canales como mensajería instantánea o cualquier otra modalidad de comunicación electrónica.
  • Este cambio busca proteger la información confidencial de los usuarios del sistema financiero, sin embargo, aunque es loable el intento al ampliar los canales por los que es transmitida la información, no busca corregir una mala práctica de la industria que es la de usar un dato de carácter público (el número de documento de identificación) como la parte secreta en el proceso de cifrado para proteger dicha información. Esperemos que en una próxima iteración de las mejoras a esta circular se incluya el término cifrado fuerte y se incluya que este cifrado se realice mediante el uso de una contraseña seleccionada por el usuario.

Otros cambios importantes realizados en la regulación:
  • Un cambio que se ve muy pequeño y que puede pasar inadvertido, pero es interesante es el de la modificación de los tiempos de retención de las imágenes de video que se baja de 8 a 6 meses y se limita a las operaciones monetarias que antes estaba circunscrita para los servicios financieros. Este control que tiene un impacto significativo en el costo de la operación de cada oficina y cajero automático donde se prestan servicios financieros, desde una perspectiva de riesgo permite a las entidades centrar los esfuerzos en los puntos más sensibles de las operaciones financieras que son las operaciones monetarias, la reducción de tiempos de almacenamiento pueden obedecer a un análisis de riesgos realizado por la SFC, a las estadísticas de reclamaciones realizadas por los usuarios en las entidades financieras, y a la cantidad de información que pueda brindar una grabación de video en operaciones no monetarias, esta reducción de tiempos de almacenamiento se mantiene dentro de los estándares de la industria.
  • El punto donde la reducción de tiempos de almacenamiento se percibe fuera de buenas prácticas de la industria es el del almacenamiento de los registros de información enviada y recibida en los centros de atención telefónica, este control en la industria habitualmente maneja tiempos de retención de 1 año y en esta versión de la regulación se ha bajado a 6 meses, si tenemos en cuenta que mediante estos canales se hacen cambios en los productos, incluyendo adquisiciones y cancelaciones de los mismos, este plazo podría considerarse como insuficiente desde la perspectiva de trazabilidad en el ciclo de vida de los productos.
  • Un cambio que resulta peligroso desde el punto de vista de seguridad es la eliminación de la restricción de almacenamiento de datos sensibles o confidenciales en los móviles sin incluir un control para asegurar que cuando se almacene se haga en condiciones de seguridad. Este cambio, que desde el punto de vista de usabilidad es beneficioso para el usuario, debería estar acompañado de controles técnicos que permitan salvaguardar los mecanismos de accesos a las cuentas de los usuarios.
En resumen, la SFC, cumpliendo con su mandato de proteger a los usuarios del sistema financiero colombiano, sigue llenando el espacio en temas de seguridad donde las entidades financieras deberían haber tomado la iniciativa en muchos aspectos y que no han hecho su tarea de manera satisfactoria.
Queda pendiente hacer algunos ajustes a esta regulación para que las entidades hagan su deber de protección de la información de sus clientes de manera correcta ya que se aprovechan vacíos gramaticales para dar soluciones incompletas a temas fundamentales de seguridad.

Esta actualización de la regulación en temas de seguridad es un acierto de la SFC ya que trae novedades importantes en ampliación de alcances e inclusión de estándares de la industria que son buenas prácticas del medio de seguridad y que buscan proteger al usuario financiero.

Autor: Javier Roberto Amaya Madrid.  - CISM, PCI QSA, P2PE QSA, PCI 3DS, PCI PCIP, MCPS, ISO 27001 LA
Consultor en Seguridad

Cómo proteger Wordpress (3/3): Seguridad por ocultación

Seguridad por ocultación en Wordpress
¿Cómo saber si un plugin está instalado en una web Wordpress?
Wordpress instala los plugins en el directorio web wp-content/plugins/
Una estructura habitual de encontrarnos por tanto en nuestro servidor web es:

/var/www/html/wordpress/wp-content/plugins/plugin_name_1
/var/www/html/wordpress/wp-content/plugins/plugin_name_2
/var/www/html/wordpress/wp-content/plugins/plugin_name_3

Y en el código html de la página se traducirá en:

http://www.dominio.com/wp-content/plugins/plugin_name_1
http://www.dominio.com/wp-content/plugins/plugin_name_2
http://www.dominio.com/wp-content/plugins/plugin_name_3

Una manera de identificar los plugins que tiene instalados una web hecha en Wordpress es revisar el código HTML de la web, en búsqueda de la cadena wp-content/plugins.

De esta manera podríamos ver sólo algunos plugins, digamos los que están en ejecución en ese momento. Pero podemos ver todos los instalados de otra manera. Esto es, podemos hacer peticiones, por diccionario, a dichas urls:

http://www.dominio.com/wp-content/plugins/*

Un diccionario de plugins para tomar como ejemplo sería éste.
Por ejemplo, si hacemos una petición como la siguiente:

curl -I http://www.dominio.com/wp-content/plugins/plugin_name 

y esta petición nos devolviera un 200 (OK) como retorno HTTP, tendríamos la confirmación de que dicho plugin está instalado. Si por el contrario recibiéramos un 404 (Not Found) tendríamos descartada su presencia.

¿Cómo saber la versión el plugin instalado?
Por consenso y estandarización, todos los desarrolladores de plugins han de incluir el fichero readme.txt. En dicho fichero se hace una descripción del plugin: su desarrollador, la versión, una descripción del mismo, o instrucción de instalación entre otras.

Si lanzamos una petición a dicho fichero:
http://www.dominio.com/wp-content/plugins/plugin_name/readme.txt

Podremos consultar en concreto la versión del plugin y, por extensión, las vulnerabilidades conocidas de dicha versión del plugin.

Este escenario conlleva un riesgo directo a la seguridad de cualquier website Wordpress puesto que anuncia públicamente sus componentes y versiones, y facilita enormemente el trabajo a un atacante.

¿Cómo ocultar los plugins de Wordpress instalados?
En el primer capítulo veíamos cómo denegar el acceso a ficheros sensibles mediante .htaccess.
Sin embargo no podríamos evitar la enumeración de plugins.

Aquí entra en escena el concepto de seguridad por ocultación. Lo que vamos a hacer es ponérselo un poquito más difícil a un posible atacante.

Sabemos que ante peticiones del tipo

curl -I http://www.dominio.com/wp-content/plugins/plugin_name

si el plugin plugin_name está instalado devolverá un http return code 200, y si no lo está será un 404. Asumiendo que no podremos evitar el 200, intentaremos evitar el 404. O dicho de otra manera, vamos a devolver siempre (sea cual sea el plugin consultado) un 200 para que el atacante reciba que tenemos tal cantidad de plugins instalados que no pueda discernir con sencillez cuáles son ciertos y cuáles no.

Para ello sólo bastaría crear una estructura de carpetas sobre

/var/www/html/wordpress/wp-content/plugins/

con los nombres de los plugins de nuestro diccionario. Ni más ni menos que 70.000 plugins pueden confundir lo suficiente a nuestro atacante. Cuando empiece el ataque probando nombres de plugins siempre recibirá un 200 suplantando la existencia real y no podrá saber por este método cuáles son ciertos y cuáles falsos.

¿Cómo ocultar la versión de los plugins realmente instalados?
Al tener bloqueada la respuesta a ficheros readme.txt en el fichero .htaccess como vimos en el capítulo 1, tampoco podrá saber sus versiones, ni de los falsos ni de los verdaderos.

¿Cómo saber si una plantilla está instalada en una web Wordpress?
Wordpress instala las plantillas en el directorio web wp-content/themes/

Saber la versión de la plantilla instalada es muy sencillo. Revisando el código HTML de una web Wordpress fácilmente encontraremos la ruta que delata el nombre de la plantilla en uso:

http://www.dominio.com/wp-content/themes/theme_name_1

¿Cómo evitar la ruta de instalación wp-content/themes/ para evitar la identificación de la plantilla?
Se puede hacer, requiriendo por parte del usuario un conocimiento alto acerca de Wordpress ya que requeriría modificar el código del CMS. Sin embargo existe un riesgo adicional. Muchos desarrolladores de plantillas y plugins utilizan enlaces mencionando explícitamente la carpeta wp-content en sus códigos, y en caso de instalarlos encontraríamos enlaces rotos puesto que nuestra ruta ya cambió de nombre, con lo que no funcionarían. En realidad la tarea de administración se puede complicar considerablemente. Es por ello que esta medida de seguridad requiere ser sopesada seriamente ya que puede no compensar lo suficiente.

¿Cómo saber la versión de la plantilla instalada?
Siguiendo el ejemplo anterior, una petición a:

http://www.dominio.com/wp-content/themes/theme_name/readme.txt 

nos devolverá el fichero del desarrollador donde se revela la versión de la plantilla.

Como vimos en el primer capítulo, mediante el bloqueo configurado en .htaccess del fichero readme.txt, el atacante no podrá acceder a dicho fichero y por tanto consultar la versión.

Aquí ponemos fin a esta serie de tres artículos:
  • En el primero vimos una serie de recomendaciones generales a alto nivel.
  • En el segundo entramos en algunas configuraciones más técnicas limitando el acceso a algunos recursos críticos.
  • En éste hemos aplicado el concepto de seguridad por ocultación en una instalación de Wordpress.
Conclusiones
Wordpress no es un gestor de contenidos más inseguro que otros. Quizás su principal virtud es a la vez su gran debilidad. Wordpress tiene una gran comunidad de desarrolladores generando contenido (plantillas y plugins), lo cual convierte su comunidad en una fuente muy rica y variada en componentes.

Sin embargo esto también supone su principal vulnerabilidad, ya que es frecuente encontrar plantillas y sobre todo plugins desarrollados con fallos graves de seguridad. Por tanto deberemos tener especial cuidado a la hora de integrar componentes nuevos en nuestra web.

Esperamos haber ayudado a mejorar la seguridad de las aplicaciones web de nuestros lectores. Sabemos que no existe la protección total, pero estamos convencidos de que las recomendaciones recopiladas en esta serie de artículos, constituyen un salto cualitativo en la seguridad de cualquier website hecho Wordpress.

Esperamos que sean de su agrado.



Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Cómo proteger Wordpress (2/3): Configuraciones de seguridad con .HTACCESS

Continuando el primer artículo de esta serie de recomendaciones sobre cómo proteger Wordpress, abordaremos esta vez una serie de recomendaciones para configurar en nuestro servidor web privado.

Nos apoyaremos en este caso en el fichero .htaccess, un archivo de configuración muy conocido en entornos web php y que nos permite aplicar políticas de acceso a directorios y ficheros. No es objeto de este artículo explicar cómo funciona htaccess, partimos de la base de que ya existe ese conocimiento y partiremos de ahí para hacer nuestras recomendaciones.

Desactivar la navegación de directorios
Wordpress trae habilitada por defecto la navegación de directorios en varias partes de su estructura. Por citar sólo algunos ejemplos podríamos encontrar:

http://192.168.10.3/wp-content/uploads/ 
http://192.168.10.3/wp-includes/ 
http://192.168.10.3/wp-content/plugins/plugin-name/

Esto permite a un atacante navegar por los directorios pudiendo tener acceso a ficheros ocultos.

Para deshabilitar esta característica añadiremos la línea:

Options All -Indexes

Bloquear la enumeración de usuarios
Es posible identificar los usuarios de una instalación de Wordpress de una manera bastante sencilla. Las peticiones:

http://ejemplo.com/?author=0 
http://ejemplo.com/?author=1  
http://ejemplo.com/?author=2  


automáticamente redirigen a unas url con el enlace permanente donde se muestra el username real de quien escribió:

http://ejemplo.com/author/usuario0/
http://ejemplo.com/author/usuario1/
http://ejemplo.com/author/usuario2/


Incluso añadiendo el nombre en el título la página:


Para evitar esta práctica podemos redirigir al atacante a una url externa cada vez que la petición coincida con el patrón mencionado anteriormente. Podemos añadir las siguientes líneas:

<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC]
    RewriteRule .* http://example.com/? [L,R=302]
</IfModule>

Siendo example.com el sitio al que enviar la redirección.

Bloquear ficheros readme.html readme.txt y similares
Por consenso y estandarización, todos los desarrolladores de plugins y plantillas han de incluir el fichero readme.txt en su paquete de instalación. En dicho fichero se hace una descripción del plugin o plantilla: su desarrollador, la versión, una descripción del mismo, o instrucción de instalación entre otras.

De la misma forma, en cada versión nueva que se lanza, Wordpress añade el fichero readme.html  donde igualmente se muestra la versión instalada.

Éstos son solo dos ejemplos, pero existen más ficheros con información de configuración, y para evitar estas filtraciones de seguridad vamos a bloquear el acceso a todos estos ficheros:

RewriteRule (?:readme|license|changelog|-config|-
sample)\.(?:php|md|txt|html?) - [R=404,NC,L]


Proteger el área de administración restringiendo por IP
En el primer artículo  de esta serie, comentábamos la necesidad de proteger el portal de login de Wordpress contra ataques de fuerza bruta. En dicho artículo recomendábamos el uso del algún plugin de seguridad que permitiera el bloqueo de usuarios por intentos fallidos al introducir contraseña.

En este sentido gracias al fichero .htaccess vamos a añadir una capa de seguridad antes del propio Wordpress. En los casos en los que la administración de la página siempre se haga desde unas localizaciones físicas con IP estática, se puede restringir el acceso para que exclusivamente se pueda hacer desde esas IPs:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "WordPress Admin Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
# oficina
allow from xx.xx.xx.xxx
# VPN
allow from zz.zz.zz.zz
</LIMIT>

Proteger el acceso al área de administración con usuario y contraseña
En los casos en los que no se pueda restringir por IP o en los que se quiera añadir una capa adicional, podemos configurar un acceso por usuario y contraseña al portal del login.


Tendremos que crear un fichero con las credenciales:

htpasswd -c /path/.htpasswd usuario

Donde /path es la ruta donde queremos dejar el fichero, que debe estar fuera del esquema de carpetas del servidor web. usuario es el username de la credencial. El comando nos pedirá por duplicado la contraseña.

A continuación creamos un fichero .htaccess en el directorio /wp-admin/ con las siguientes líneas:

AuthName "Panel de admin"
AuthUserFile /path/.htpasswd
AuthGroupFile /dev/null
AuthType basic
require valid-user
Donde /path es la ruta donde se dejó el fichero .htpasswd.

Bloquear tráfico XMLRPC
El protocolo XMLRPC es un protocolo de comunicación via HTTP de datos en formato XML. Este protocolo se utiliza como si se tratase de una API para conectar el Wordpress con aplicaciones de terceros. Esta comunicación se hace a través del fichero:

http://ejemplo.com/xmlrpc.php

Este protocolo tiene el riesgo de sufrir ataques de denegación de servicio, así que en caso de no utilizarse es recomendable bloquear su acceso:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Redirigir todas las páginas de error del servidor web a una página estándar

Habitualmente los atacantes consiguen inferir bastante información de las aplicaciones web con los mensajes de error. Por ejemplo, si se hace una petición a un recurso y éste no existe devolverá un error 404 (not found) con su página correspondiente, pero si el recurso existe pero no se tiene permisos sobre él obtendremos un 403 (Forbidden) y otra página de error. Aquí ya se puede deducir información.



Por este motivo una buena práctica es capturar estas respuestas y devolver una web genérica en su lugar para que el atacante no reciba los mensajes a primera vista:

ErrorDocument 403 /error.html
ErrorDocument 404 /error.html
ErrorDocument 500 /error.html

En el siguiente artículo, abordaremos algunas recomendaciones de seguridad bajo el concepto de Seguridad por ocultación.


Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Cómo proteger Wordpress (1/3): Recomendaciones Generales

Wordpress continúa siendo la referencia absoluta en lo que respecta a gestores de contenido para páginas web un año más. Se estima que una de cada tres páginas web en internet es un Wordpress, lo que supone una cifra descomunal. Dada su gran cuota de utilización lleva varios años en el punto de mira de los cibercriminales.

Muchos de nuestros clientes también utilizan Wordpress y pensamos que sería una buena idea ofrecer una serie de recomendaciones con respecto a su configuración. Hemos redactado una serie de tres artículos en la que comenzaremos con aspectos generales a alto nivel, hasta ir profundizando más a nivel técnico en algunos puntos.

En cualquier caso, estos tres artículos pretenden no ser un manual de instalación y configuración estricto y ceñido, sino por el contrario, nos gustaría presentar estos artículos como una guía de buenas prácticas y recomendaciones flexibles a cualquier uso. En un mundo tan cambiante como el de la ciberseguridad, nada ofrece una garantía total ante los cibercriminales, pero esperamos ayudar a mejorar la seguridad de nuestros clientes y de cualquier usuario de Wordpress.

RECOMENDACIONES GENERALES
Los CDN:
Los CDN son una potente medida de seguridad frente a varios tipos de ataques. Sin duda, su principal protección es contra ataques de DDoS (denegación de servicio distribuida). Al ser capaces de distribuir dinámicamente tráfico a lo largo de sus grandes redes, consiguen dispersar de manera efectiva grandes volúmenes de tráfico sin afectar al rendimiento de una aplicación web.

Hemos conocido múltiples casos de clientes y organizaciones que son víctimas de ataques de DDoS por parte de su competencia comercial, por sabotajes corporativos o hacktivismo. En estos casos, contratar un CDN es una medida efectiva para paliar los efectos de estos ataques.

Sin embargo los CDN también ofrecen servicios de WAF (Firewall de Aplicación Web) e IDS (Sistemas de Prevención de Intrusiones) de tal forma que entran a proteger ataques contra la lógica de la aplicación, protegiendo contra hackeos e intrusiones en los sistemas del cliente. Como siempre, la protección de un CDN es evadible en algunas ocasiones, pero sin duda representa una protección eficiente.

No debemos olvidar que los CDN por último también cumplen notablemente una función de optimización de la web ya que tienen un rendimiento excelente en la descarga de la web a los clientes.

Wordpress suele integrarse perfectamente con los CDN, hasta el punto de que la mayoría ofrecen plugins oficiales para instalar de tal forma que el propio Wordpress y el CDN se integren a la perfección.

Los ejemplos son múltiples pero podríamos mencionar aquí a Akamai, CloudFlare, Sucuri o los mismos CDN de Amazon o Google.

VPS siempre mejor que un Hosting compartido       
El riesgo de alojar una web Wordpress o de cualquier otro tipo, en un hosting compartido, es que la web será alojada en el mismo servidor que cientos de otras aplicaciones web. Por este motivo la seguridad de nuestra web ya no depende exclusivamente de ella misma, sino también de todas las demás. Una vulnerabilidad que ponga en jaque el servidor web nos afectará a nosotros también.

Por este motivo siempre es más recomendable contratar un servidor dedicado (VPS) donde la seguridad corra por nuestra cuenta y tengamos la confianza de depender en exclusiva de nosotros mismos. Es cierto que podrían existir otros vectores por parte del proveedor de servicios de hosting, sin embargo, las posibilidades de sufrir una ataque por esa vía serían mucho más remotas que en el caso de alojarnos en un hosting compartido.

Plugins: menos es más
Los plugins son la principal amenaza en las páginas Wordpress. Al estar desarrollados por terceros, habitualmente no han sido desarrollados teniendo en cuenta la seguridad y acumulan montones de vulnerabilidades importantes. Es recomendable instalar la menor cantidad de ellos y siempre que no usemos alguno, eliminarlo del Wordpress.

Así mismo, mantener actualizados la plantilla en uso y todos los plugins nos protegerá de vulnerabilidades en versiones previas.

Proteger servicios en la misma IP que nuestra web
Suponiendo que disponemos nuestro propio servidor privado, no es recomendable alojar servicios adicionales como FTP, SSH o cualquier otro, en la misma IP pública del servidor web ya que estamos facilitando el trabajo a un cibercriminal. Al conocer nuestro dominio, conocería por tanto la IP de nuestro servidor y, por tanto, descubriría dichos servicios. Estaríamos aumentando la probabilidad de sufrir un ataque ya que no sólo tendríamos que proteger la web, sino también tendríamos que proteger los servicios publicados.

De ser posible, dichos servicios deben ser ofrecidos a través de VPN puesto que suelen utilizarse para actualizar contenidos en la web o administrar el servidor. Por tanto, no tienen por qué estar accesibles para cualquier persona en internet.

Convertir Wordpress en una web estática
Una página estática es aquella donde sus peticiones no manejan parámetros. Simplemente se solicitan y se descargan archivos con el código html.

Las virtudes de Wordpress como gestor de contenidos son sus infinitas posibilidades de personalización de los contenidos en la web. Sin embargo, en la mayoría de casos no se hacen cambios como demasiada asiduidad. Además, si la web tiene como funcionalidad exclusiva la de mostrar contenidos (imaginemos la página web de una empresa donde sólo se anuncian sus servicios y una página con información de contacto) sin ningún elemento dinámico como ecommerce, foros, etc, podemos tomar la decisión de convertirla en una web estática.

Si éste es el caso, una recomendación puede ser la de tener dos entornos. Un entorno de desarrollo donde realizamos todos los cambios y actualizaciones en el Wordpress original, y otro entorno de producción donde lo que subimos es una copia estática de la web.

Proteger Wordpress es una tarea ardua ya que son múltiples los elementos a revisar: el propio motor de Wordpress, la plantilla instalada, los plugins de terceros… De esta manera, podríamos quitarnos un gran número de vulnerabilidades de raíz.

Plugins de Seguridad

El mercado de los plugins de terceros de Wordpress es infinito. Con respecto a la seguridad son múltiples los plugins que existen y no será objeto de este artículo compararlos. Lo que sí es importante tener en cuenta son las funcionalidades que nos ofrecen y que deben cubrir obligatoriamente:

Función de firewall de aplicación web (WAF)
El plugin elegido debe poder actuar como firewall web en nuestra aplicación. Esto es imprescindible en especial si no tenemos un CDN contratado. Esta función nos protegerá de posibles vulnerabilidades en el código de Wordpress, de la plantilla o de cualquiera de los múltiples plugins instalados.

Protección contra ataques de fuerza bruta en el login
Debemos tener una protección contra ataques de fuerza bruta en la página de login de Wordpress. Así cuando un usuario ingrese varias veces mal la contraseña, automáticamente quedará bloqueado por un tiempo determinado o indefinidamente. Muchos plugins de seguridad de Wordpress traen integrada esta funcionalidad. De no ser el caso deberíamos contar con ella.

Existen algunos plugins que cambian la url de login de Wordpress para complicar la tarea de los atacantes que quieren forzar nuestra web. Esta medida sin embargo no creemos que sea recomendable. Siempre preferimos y recomendamos instalar la menor cantidad de plugins de terceros posible para reducir el número de vulnerabilidades. Además modificar la estructura original de Wordpress con frecuencia acaba complicando la administración en futuras actualizaciones y subidas de versión.

Backup
La recomendación eterna y más evidente. Necesitamos tener un backup de nuestro Wordpress, tanto de los ficheros y carpetas de nuestro web server como de la base de datos. En caso de tener algún problema, es imprescindible tener una copia de seguridad para restaurar.

En el siguiente artículo abordaremos unas configuraciones técnicas.


Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Vicente Aguilera miembro del Jurado de los Trofeos de la Seguridad TIC


Un año más, Vicente Aguilera forma parte del selecto grupo que compone el Jurado de los XII Trofeos de la Seguridad TIC, que estudia y analiza las distintas candidaturas que se presentan a estos premios.

Este certamen internacional se encuentra organizado por la revista Red Seguridad (revista independiente especializada en Seguridad de la Información), y se premia a las personas o entidades – del sector público y privado - que se hagan acreedoras de ello.
Los trofeos son los siguientes:
  • T1- Trofeo al producto/servicio o sistema de seguridad más innovador
  • T2- Trofeo a la empresa SegTIC del año
  • T3- Trofeo a la institución u organismo público en materia de seguridad TIC
  • T4- Trofeo a la trayectoria profesional pública o privada en seguridad TIC
  • T5- Trofeo a la capacitación, divulgación, concienciación o formación en seguridad TIC
  • T6- Trofeo al centro educativo SegTIC del año
  • TE- Trofeo extraordinario del jurado
La entrega de premios se realizará el 19 de junio en COEM (Auditorio). C/ Mauricio Legendre, 38 (Madrid).

Más información:
http://www.redseguridad.com/content/download/69076/554294/file/bases%20trofeos%20red%202018-min.pdf