Gran parte de las ciudades del mundo son cada vez más “inteligentes”, lo cual se convierte en nuevos blancos para ciberatacantes. Las ciudades han ido incorporando nuevas tecnologías durante varios años, pero últimamente la tasa de tecnologización ha aumentado significativamente y muchas ciudades de todo el mundo son cada vez más inteligentes. Las nuevas tecnologías, junto con una conectividad más rápida y fácil, permiten a las ciudades optimizar recursos, ahorrar dinero y al mismo tiempo ofrecer mejores servicios a sus ciudadanos.

Una “ciudad inteligente” (Smart city en inglés) se puede definir como una ciudad que usa tecnología para automatizar y mejorar servicios de la comunidad, incrementando el nivel de vida de sus ciudadanos. En la ciudad inteligente del futuro todo estará conectado y automatizado. Esto todavía no es una realidad, pero mientras tanto, muchas ciudades ya están elaborando grandes presupuestos para poder ser más inteligentes en un futuro cercano.

Pero, ¿qué pasaría si uno o más servicios altamente dependientes de tecnología no funcionar? ¿Cómo se verían afectados los desplazamientos dentro de la ciudad sin el funcionamiento de los sistemas de control de tráfico, sin semáforos o sin transporte público? ¿Cómo responderían los ciudadanos a un suministro inadecuado de agua o electricidad, a calles oscuras, o simplemente a una interrupción del servicio de recogida de basuras en verano con la consecuente proliferación de olores, insectos, ratas, patógenos, etc.?

¡La ciudad “inteligente” sería un CAOS!

Desafortunadamente esto podría ocurrir muy fácilmente debido a que muchas ciudades están implementando nuevas tecnologías sin tener en cuenta que estos estos sistemas son vulnerables desde el punto de vista de la ciberseguridad y por tanto están expuestos a ciberataques. Normalmente todos los aparatos y sistemas se someten a rigurosas pruebas de funcionalidad, resistencia a condiciones atmosféricas etc., pero prácticamente no se les somete a ningún test de intrusión en el que algún hacker pueda modificar y alterar sus condiciones de funcionamiento.

¿Qué hace que una ciudad sea más inteligente? ¿Qué tecnologías se usan? ¿Qué vulnerabilidades podrían presentar estas nuevas tecnologías desde el punto de vista de la ciberseguridad? Algunas de las tecnologías que podrían contribuir a incrementar la inteligencia de la ciudad y sus posibles vulnerabilidades serían:

• Control de tráfico inteligente: Semáforos y señales que se adaptan basándose en el volumen y las condiciones de tráfico actuales. Se detecta el tráfico actual y la información en tiempo real se utiliza para coordinar y mejorar el flujo en calles, carreteras, cuestas, etc.

  Posible vulnerabilidad: Es posible introducir datos falsos en los sistemas de control de tráfico y configurarlos con opciones y tiempos incorrectos en los semáforos, señales de tráfico…, y así sucesivamente.

• Estacionamiento Inteligente: Los ciudadanos pueden utilizar una aplicación de estacionamiento para encontrar plazas de aparcamiento disponibles, revisión de precios y sus cambios según la hora del día, la disponibilidad, la ubicación, etc.

  Posible vulnerabilidad: Vulnerar esta aplicación podría generar un colapso en un parking concreto, desviando todos los conductores a dicho parking, o incluso haciendo que siempre acudieran a cierto parking con mayor frecuencia de forma que sus propietarios percibieran mayores beneficios.

• Alumbrado público inteligente y Gestión de energía inteligente (Smart Grid): El alumbrado público inteligente se gestiona de forma centralizada. Las luces de la calle se pueden adaptar a las condiciones climáticas, pueden reportar problemas, o se pueden automatizar por hora del día. Las luces de la calle se pueden incluso apagar y encender dependiendo de la detección de vehículos y personas en movimiento. Por otro lado, una red inteligente (Smart Grid) puede entregar energía dependiendo de las necesidades. Los contadores inteligentes pueden comunicarse con la red inteligente para programar un suministro de energía a una hora específica con un menor coste económico. La red inteligente puede incluso apagar el calentador de agua de nuestra casa durante las horas pico, en las que la electricidad es más cara. Los edificios inteligentes utilizan el mismo principio para conservar energía y comprar electricidad cuando las tasas son “low cost”.

  Posible vulnerabilidad: Muchos proveedores permiten que se dé acceso privilegiado para cualquier persona a un dispositivo o sistema conectado a una red local, ya que asumen que la red interna es segura. Normalmente muchos implementan sistemas inalámbricos y protocolos de comunicación por cable con poca o sin seguridad. La mayoría de los nuevos dispositivos son inalámbricos (como los contadores inteligentes, las farolas, sensores, semáforos, tuberías inteligentes, cámaras de tráfico y vigilancia etc.), lo que hace que sean fáciles de implementar, pero también fáciles de hackear si la comunicación no está debidamente encriptada. Por otra parte, las conexiones vía cable requieren acceso físico y eso hace que sean más difíciles de hackear, pero algunos de estos sistemas cableados como PLC (Power Line Communication) están más expuestos y es más fácil acceder a ellos. Un atacante tan solo tiene que conectarse a la red eléctrica para obtener acceso y tener todos estos dispositivos a su merced.

• Transporte público inteligente: Se proporciona a los ciudadanos la información en tiempo real acerca de los horarios (bus, tren y metro) y posibles retrasos. Los pagos sin contacto físico permiten a los ciudadanos pagar con facilidad, incluso utilizando un teléfono inteligente.

  Posible vulnerabilidad: Con solo mostrar información incorrecta mediante la manipulación de los sistemas de información de transporte público, es posible influir en el comportamiento de las personas para causar retrasos, hacinamiento, y así sucesivamente. Por ejemplo, falsificando un retraso en una línea de metro, los atacantes pueden provocar que la gente se concentre en otra línea provocando una avalancha de personal. También un atacante podría alterar los sistemas de pago. Si los sistemas de pago no funcionan, la gente podría viajar gratis o incluso miles de personas podrían saturar con quejas los mostradores de atención al cliente o las líneas telefónicas.

• Gestión inteligente del agua: Las tuberías inteligentes miden la calidad del agua, detectan fugas, distribuyen el agua y detectan problemas. Técnicas similares se utilizan para gasoductos y oleoductos.

  Posible vulnerabilidad: Los ataques sobre los sensores inalámbricos de las tuberías y el envío de datos falsos a la central tendría graves consecuencias en cuanto a medidas tan importantes como la calidad del agua. Cualquier filtración o contaminación no sería detectada e implicaría suministrar agua en mal estado a los ciudadanos, con las consecuencias en la salud de estos.

• Gestión de residuos inteligente: Los sensores en los contenedores de residuos detectan el volumen de basura, el olor y así sucesivamente. La recogida de basura puede ser más eficiente si se descartan previamente los contenedores vacíos y se detiene con anterioridad solo delante de los contenedores que huelen.

  Posible vulnerabilidad: Los ataques sobre los sensores inalámbricos de los contenedores y el envío de datos falsos a la central tendría graves consecuencias en cuanto a la recogida de basuras. La basura podría llegar a acumularse en ciertas zonas de la ciudad, con su consecuente impacto sobre la salud de los ciudadanos y sobre el medio ambiente.

• Seguridad ciudadana: Cámaras de vigilancia, sensores de detección de bala y otros dispositivos de seguridad proporcionan información en tiempo real sobre lo que está pasando y dónde. Tecnología de “conteo” de personas, tales como el seguimiento de los teléfonos móviles o comunicación (como WiFi o Bluetooth) se utiliza para determinar el número de personas en un área determinada como una calle, un parque o un edificio.

  Posible vulnerabilidad: Las cámaras de tráfico y vigilancia son los ojos de la ciudad y al atacarlos, los atacantes pueden provocarle ceguera a las ciudades inteligentes. No siempre es posible reiniciar remotamente las cámaras. Además, los ataques de denegación de servicio se pueden hacer persistentes mediante la modificación de firmware. La ciudad se quedaría sin vigilancia.

Estas tecnologías están respaldadas por:

• Sistemas de gestión de la ciudad: Estos sistemas ayudan a automatizar diferentes tareas de administración de la ciudad.

  Posible vulnerabilidad: Un atacante podría manipular la información del mapa de localización y las órdenes de trabajo para enviar trabajadores públicos o de alguna contrata para hacer una intervención sobre canalizaciones de gas, agua o cables de comunicación, con la intención de dañar esas instalaciones.

• M2M (Machine to Machine): Con el fin de hacer una ciudad más inteligente, se necesitan dispositivos (máquinas) que hablen entre sí, de forma que se tomen decisiones de forma automática.

  Posible vulnerabilidad: Las nuevas tecnologías están siendo integradas dentro de las viejas tecnologías, las cuales son más vulnerables. Algunos sistemas antiguos requieren de tecnología en medio que haga de traductora de protocolos de comunicación con los nuevos sistemas. Como algunos sistemas no funcionan en los nuevos (los cuales poseen sistemas operativos más seguros), se utilizan sistemas operativos más viejos y vulnerables. Esto añade complejidad, aumenta la superficie de ataque, y ralentiza la incorporación de nuevas tecnologías. Un claro ejemplo sería el edificio inteligente Burj Khalifa, el edificio más alto y más inteligente del mundo. Los sistemas principales del edifico se ejecutan con el sistema operativo Windows XP, que es viejo, anticuado y menos seguro que los nuevos sistemas operativos. Esto convierte Burj Khalifa en un blanco fácil para posibles ataques cibernéticos.

• Sensores: Usados para todo, los sensores (a menudo sin cable) suministran datos de forma continua a las ciudades inteligentes. Ejemplos: Sensores de tiempo (detectan las condiciones climáticas y envían alertas), sensores sísmicos (situados en puentes y bajo tierra, detectan daños en túneles y en infraestructuras causados por terremotos, envejecimiento u otros problemas), sensores de niveles de polución (detectan e informan sobre niveles de polución en diferentes partes de la ciudad), sensores de olor (para la basura, gas natural…detectan posibles problemas), sensores de inundaciones, sensores de sonido (pueden detectar disparos, alarmas, actividad….etc.).

  Posible vulnerabilidad: La mayoría de los sensores utilizan tecnologías inalámbricas fácilmente accesibles. Los ataques que impliquen comprometer sensores y enviar datos falsos pueden afectar directamente a los sistemas, ya que las decisiones y acciones que estos tomen dependerán de datos falsos. Esto podría tener un gran impacto en función de cómo los sistemas afectados utilizan los datos e interactúan con otros sistemas.

• Datos de dominio público: Los gobiernos comparten datos (a veces en tiempo real) para que las personas puedan desarrollar aplicaciones.

  Posible vulnerabilidad: Los datos públicos (open data) están disponibles para los atacantes, a veces en tiempo real. Estos datos pueden ayudar a determinar el mejor momento para los ataques, ataques de horario, crear disparadores de ataque, coordinar ataques, y así sucesivamente. Con esto los atacantes no necesitan actuar a ciegas. Pueden actuar de forma precisa basándose en datos reales.

• Aplicaciones móviles: En un ecosistema de ciudad inteligente, las aplicaciones móviles fomentan la interacción entre los ciudadanos y la ciudad. Los ciudadanos pueden obtener información de los sistemas de la ciudad, sensores, y así sucesivamente a través de aplicaciones móviles, y con ello tomar decisiones en función de la información que reciben.

  Posible vulnerabilidad: Los atacantes podrían dirigirse a empresas de desarrollo de aplicaciones móviles o simplemente modificar los datos con los que se nutren las aplicaciones. Las aplicaciones móviles son un objetivo importante, ya que los ciudadanos van a tomar decisiones y actuar en base a la información suministrada por esas aplicaciones. Hackear aplicaciones móviles tiene un impacto directo en el comportamiento de los ciudadanos. Por ejemplo, si la aplicación de transporte público está mostrando un retraso en un autobús, un ciudadano puede optar por viajar a trabajar en coche; si la misma decisión es tomada por cientos de personas en una zona de alta densidad poblacional, el resultado es un atasco de tráfico. También muchos servicios están basados en la localización, lo que significa que la suplantación de GPS y otros ataques son posibles. Las personas perciben la información de localización en tiempo real, y si la ubicación es incorrecta, entonces la gente va a tomar decisiones basadas en información incorrecta. La naturaleza del impacto es función de la medida en que una ciudad depende de los servicios afectados.

Conclusión

Cuanta más tecnología utiliza una ciudad, más vulnerable a los ataques cibernéticos es, por lo que las ciudades más inteligentes tienen los mayores riesgos. Las tecnologías utilizadas por las ciudades deben ser correctamente auditadas antes de su implementación desde el punto de vista de la ciberseguridad. Cuando a una ciudad inteligente se le suministran datos fácilmente manipulables en los que confía ciegamente, y además esta tiene sistemas fácilmente hackeables y problemas de seguridad por doquier, entonces pasa rápidamente de ser una “ciudad inteligente” a ser una “ciudad estúpida”. Esperemos que los responsables tengan todos estos problemas de seguridad en mente.

Dice el dicho que ‘la confianza da asco‘. Esta frase, que se aplica normalmente en tono distendido para describir una característica propia de las relaciones humanas, cobra hoy especial significación en el mundo digital. Y es que la confianza ya no se limita a las relaciones interpersonales, sino que amplía su ámbito de aplicación a las relaciones persona-máquina e incluso máquina-máquina.

Con la llegada de la era digital, Internet y las nuevas formas de comunicación, se nos presentan cada día situaciones, de las cuales la confianza forma parte consustancial. Así pues, acciones cotidianas tales como abrir un email o acceder a una web determinada, implican un ejercicio de confianza que, en ocasiones, realizamos sin ni siquiera ser conscientes y que, lamentablemente pueden llegar a ocasionarnos perjuicios tales como el robo o pérdida de información, chantajes, daño a la imagen personal o corporativa… Aunque dado el perfil de nuestros lectores todo esto puede parecer trivial, casi todos conocemos algún caso, bien sea a través de terceros o de los medios de comunicación, en el cual la confianza mal entendida ha derivado en alguno de los quebrantos mencionados anteriormente.

La gestión de las relaciones de confianza resulta compleja dada su naturaleza, pues cumple en ocasiones las propiedades de asimetría (A confía en B pero B no confía en A) y transitividad (si A confía en B y B confía en C, entonces A confía en C). También cabe destacar que no es igual la gestión de la confianza en el ámbito personal, que se consolida con la cercanía y el tiempo, que en un entorno corporativo. En este último, se establece una relación de confianza entre la empresa y el trabajador, que viene impuesta por la naturaleza misma de la relación contractual entre ambos, y he aquí el problema.

Desde el momento en que damos a un usuario acceso a recursos corporativos, estamos haciendo un ejercicio implícito de confianza, por el cual asumimos el riesgo de que no se va a hacer un mal uso de dichos recursos. En este punto cabe destacar que la confianza puede verse amenazada, no solo por la mala intención de una de las partes, sino también por irresponsabilidad o ignorancia. No se trata de criminalizar al usuario.

Pongamos por ejemplo, una empresa que proporciona acceso a sus empleados a uno de los servicios corporativos, permitiéndoles el acceso desde fuera de la red de la empresa. En general, los usuarios hacen un uso responsable del servicio en cuestión pero un usuario en particular, se conecta a través de una red insegura, exponiendo así sus accesos a dicho servicio a ataques de tipo Man in the Middle. Si bien no hay una intención expresa del usuario de poner en riesgo la seguridad del servicio, lo cierto es que la confianza implícita depositada en el usuario, se ve mermada por la ignorancia o irresponsabilidad de éste.

Por todo ello, es importante tratar de reducir a su mínima expresión el papel que juega la confianza a la hora de establecer una política de seguridad en entornos corporativos. Aplicar el principio de mínimo privilegio, junto con campañas de formación y concienciación de los usuarios son medidas fundamentales para evitar incidentes que puedan comprometer la seguridad de nuestros sistemas y la información que contienen.

En definitiva, no se trata de desconfiar del usuario, sino de desconfiar de la confianza.

En el capitulo anterior analizamos la función IsDebuggerPresent() de la API de Windows, jugamos con el crackme en OllyDbg y vimos como hacer un bypass de esta función para lograr nuestro objetivo.

En esta entrega vamos a ver otra técnica que se basa en el chequeo del campo NtGlobalFlag del PEB (Process Environment Block).

El valor de NtGlobalFlag viene determinado por el valor de los siguientes flags:

• FLG_HEAP_ENABLE_TAIL_CHECK
• FLG_HEAP_ENABLE_FREE_CHECK
• FLG_HEAP_VALIDATE_PARAMETERS

Cuando un proceso es creado por el debugger, el valor de NtGlobalFlag es 0×70, resultado de los valores de los flags que lo componen, 0×10, 0×20 y 0×30 respectivamente. Una nota importante a tener en cuenta es que si dicho proceso, en lugar de ser cargado directamente en el debugger es adjuntado (attached), entonces el valor de NtGlobalFlag no es modificado y mantendrá su valor por defecto: 0 (no está siendo debuggeado).

Si recordamos, la función IsDebuggerPresent() devolvía el valor almacenado en el campo BeingDebugged del PEB. Para consultar el valor de NtGlobalFlag no contamos con ninguna función en lenguaje de alto nivel que nos facilite el trabajo (al menos yo no la he encontrado). Así que tendremos que acceder directamente a la estructura del PEB y, para ello, utilizaremos el lenguaje C y NASM.

En mi cuenta de GitHub podéis descargaros los crackmes; el correspondiente a esta entrega es “crackme02_NtGlobalFlag”:

• https://github.com/reverc0de/saw-anti-debugging

Como podéis ver, los sources constan de un fichero con código en lenguaje C (crackme02_NtGlobalFlag.c) y otro con lenguaje ensamblador (crackme02_NtGlobalFlag_asm.asm). El código en ensamblador es el encargado de obtener el valor de NtGlobalFlag del proceso que se está ejecutando. El código en C simplemente llama a la función en ensamblador y muestra un mensaje con el resultado: si está siendo debuggeado o no.

Una vez que hayáis descargado el crackme, podéis ejecutar directamente el binario compilado, y si no os fiáis, podéis compilar los sources con los siguientes comandos:

# nasm -g -f win32 --prefix _ crackme02_NtGlobalFlag_asm.asm -l crackme02_NtGlobalFlag_asm.lst
-o crackme02_NtGlobalFlag_asm.o

# gcc -c crackme02_NtGlobalFlag.c -o crackme02_NtGlobalFlag.o

# gcc crackme02_NtGlobalFlag.o crackme02_NtGlobalFlag_asm.o -o crackme02_NtGlobalFlag.exe

Para compilar los sources en Windows, necesitaréis NASM y GCC (MinGW); yo los he instalado en un Windows XP 32 Bits.

El código de “crackme02_NtGlobalFlag.c” puede verse a continuación. El código es muy simple, realiza la llamada a la función “ntglobalfunc()” que se encuentra en el fichero de código ensamblador. Esta función consulta y devuelve el valor de NtGlobalFlag. Acto seguido, se realiza una operación AND a nivel de bits (bitwise) entre el valor devuelto y 0×70. Dependiendo del resultado de esta operación, se mostrará un mensaje u otro.

En los comentarios pueden leerse algunas notas sobre los valores: si el proceso está siendo debuggeado, la variable local NtGlobalFlag almacenará el valor 0×70.

/*****************************************************************
* File:		crackme02_NtGlobalFlag.c
* Description:	Es un crackme que implementa la protección
* 		anti-debugging basada en NtGlobalFlag
* Date: 	27/04/2015
* Author: 	reverc0de
* Twitter:	@reverc0de
* Site:		www.reverc0de.com
* Github:	https://github.com/reverc0de/saw-anti-debugging
*****************************************************************/

#include <windows.h>

long ntglobalfunc(void);

int main(void)
{
	unsigned long NtGlobalFlag = 0;
	NtGlobalFlag = ntglobalfunc();

	// NtGlobalFlag == 0x70 (Bitwise) -> Debugger detectado
	// NtGlobalFlag != 0x70 (Bitwise) -> Debugger no detectado
	if (NtGlobalFlag & 0x70)
	{
		MessageBox(0, "Debugger detectado!!","Crackme02 NtGlobalFlag",MB_OK);
		exit(0);
	}
	MessageBox(0, "Debugger NO detectado!!","Crackme02 NtGlobalFlag",MB_OK);
	return 0;
}

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; File:		crackme02_NtGlobalFlag_asm.asm
; Description:	Es un crackme que implementa la protección
; 		anti-debugging basada en NtGlobalFlag
; Date: 	27/04/2015
; Author: 	reverc0de
; Twitter:	@reverc0de
; Site:		www.reverc0de.com
; Github:	https://github.com/reverc0de/saw-anti-debugging
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

[BITS 32]

global ntglobalfunc

section .text

ntglobalfunc:
	push ebp		;guardamos el estado actual de la pila
	mov ebp,esp

	mov eax,[fs:30h]	;Offset hacia el PEB
	mov eax,[eax+68h]	;Offset hacia el campo NtGlobalFlag

    	pop ebp			;restauramos el estado anterior de la pila
	ret 			;return eax = NtGlobalFlag

Ahora que hemos descrito el código, vamos a cargar el crackme en OllyDbg. Si lo ejecutamos desde el debugger, mostrará el mensaje “Debugger detectado!!”.

Vamos a inicializarlo de nuevo y vamos a colocarnos en la posición 004013FD (Ctrl+G). En la imagen a continuación podemos ver el código que nos interesa del crackme.

En esta posición hay una llamada a la posición de memoria 00401480, así que vamos a echarle un vistazo. Esta llamada se corresponde con la llamada a la función “ntglobalfunc()”. Para ir a esa posición, o bien lo hacemos como antes, o hacemos clic derecho sobre la llamada y seleccionamos “Follow” (aún no hemos ejecutado el crackme, solo estamos navegando por el código en el debugger).

Os suena el código de la siguiente imagen, ¿verdad?

Vamos a volver a la posición anterior (004013FD) (ya sabéis, Ctrl+G, o pulsamos “-” para retroceder hasta la posición indicada). Después de la llamada que acabamos de ver, podemos ver como el valor retornado en EAX es almacenado en la pila (“ss” apunta a la pila).

A continuación, se realiza la operación AND entre el valor retornado en EAX y 70h, el resultado es almacenado en EAX. ¿Por qué realizamos esta operación? Si recordamos, el valor de NtGlobalFlag es 0 si el proceso no esta siendo debuggeado. Por lo tanto, si tras la operación AND lógica, EAX es igual a 0, significa que el proceso no esta siendo debuggeado, pero esta comprobación se realiza con la siguiente operación TEST.

Con TEST se comprueba si EAX es 0. Si es así, establece el flag ZF=1 y ZF=0 en cualquier otro caso. Después, JE tomará el salto si ZF=1. Dependiendo del resultado del salto, se mostrará un MessageBox con un texto u otro.

Ya os podéis hacer una idea de alguna forma que otra de romper esta técnica anti-debugging. Al igual que en la entrega anterior, podemos modificar el tipo de salto o cambiar el valor del flag ZF que controla el salto. Otra opción es cambiar el valor del registro EAX con un valor distinto de 0, de forma que el resultado de TEST establezca el flag ZF=1.

Vamos a cambiar el tipo de salto por JMP (salto incondicional). Para ello, nos colocamos en la posición 0040140D y hacemos clic derecho y “Assemble”. Cambiamos JE por JMP. Ahora ejecutamos el proceso y deberíamos obtener el mensaje de “Debugger NO detectado!!”. En la siguiente imagen se muestra la fracción de código que hemos modificado.

Como siempre, es recomendable que vayáis monitorizando el valor de EAX en OllyDbg para ver con mayor claridad que valores adquiere en cada operación, algo que ayuda a comprender el proceso de esta técnica.

Existen otras formas de complementar el valor de NtGlobalFlag del PEB para reforzar esta técnica, por ejemplo, mediante las claves de registro y variables de entorno:

• HKLM\System\CurrentControlSet\Control\SessionManager.
• HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File ExecutionOptions\<filename>.
• Campos de “Load Configuration Table”: FLG_USER_STACK_TRACE_DB y FLG_HEAP_VALIDATE_PARAMETERS.
• Variable de entorno “_NO_DEBUG_HEAP”.

Os recomiendo la lectura del paper de Peter Ferrie “The ultimate Anti-debugging Reference” [PDF], en el cual describe una cantidad de técnicas anti-debugging.

La técnica de este post está muy bien descrita en el paper y describe las variaciones con claves de registro y variables de entorno que hemos nombrado anteriormente.

¡Nos vemos en la próxima entrega!

El equipo de CyLab, perteneciente a la Universidad Carnegie Mellon, ha realizado recientemente un simpático proyecto llamado “Privacy Illustrated“, cuyo objetivo es reflejar de una manera sencilla qué entendemos por privacidad. Este estudio se ha realizado enmarcado en el Deep Lab, un congreso interdisciplinar de ciberseguridad que pretendía examinar la problemática y el impacto de los diferentes aspectos de la seguridad en la cultura y la sociedad.

El estudio ha consistido en pedir a personas de todas las edades que dibujaran lo que significa para ellos la privacidad. Hasta el momento tienen publicadas en torno a 170 imágenes que pueden verse en su web.

Mirando los dibujos, la primera conclusión no se hace esperar: todos valoramos y nos preocupamos por nuestra privacidad.

Este deseo de privacidad o intimidad aparece ya desde nuestra más tierna infancia, aunque va evolucionando conforme vamos creciendo para cubrir las diferentes facetas de nuestra vida. De esta manera he podido observar diferentes estadios:

• Niños entre 5 y 10 años: Los pequeños visualizan una barrera física alrededor de su espacio personal, como puede ser la puerta de la habitación o el baño, que les otorga un cierto grado de autonomía.
• (Pre)Adolescencia: Empiezan a relacionar el concepto con nuevos canales de comunicación (móviles, ordenadores y tabletas), si bien aún lo entienden como un proceso exclusivamente localizado y controlado a través del uso de contraseñas o de su uso sin supervisión.
• Jóvenes (desde los 16 a los 30): Ya a partir de los 16 años, los jóvenes empiezan a reconocer la “falta de privacidad” existente en las redes sociales. En contra de lo que podríamos pensar, los adolescentes son muy conscientes de los peligros a los que se exponen al compartir fotos o información personal y, por tanto, de la necesidad de controlar qué se comparte y con quién.

  Así mismo, muchos dibujos revelan preocupación por los actos de vigilancia en la red (network surveillance) llevados a cabo por gobiernos y grandes empresas, y la necesidad de cifrar las comunicaciones y su información.

• Adultos: Curiosamente, las personas mayores de 30 vuelven a recuperar la noción de intimidad, del derecho al espacio personal y la introversión.

Desde mi punto de vista, esta colección de dibujos muestra en cierta manera cómo empezamos imponiendo nuestra intimidad a través de barreras sólidas que se van permeabilizando para poder filtrar aquello que queremos compartir con el mundo.

Así mismo, es fácil entender que hay diferencias entre distintas generaciones. Los jóvenes ven con mayor naturalidad el compartir “intimidades” y relacionarse a través de redes sociales. Ahora bien, como ya he comentado, sí que me sorprendió gratamente vislumbrar un mayor interés del que esperaba con respecto a su “reputación digital”. De hecho hay otro estudio de Oxford [PDF] que sostiene que existe una relación inversa entre edad y preocupación por la privacidad.

Donde aprecio una mayor vulnerabilidad es en los adolescentes en torno a 12-15 años, cuando, con un acceso importante a redes o aplicaciones de compartición de archivos e información, aún no han alcanzado la madurez suficiente para entender completamente los peligros o las implicaciones morales que conllevan. Es por esto que, en mi opinión, es en estas edades donde debemos centrar nuestros esfuerzos de comunicación y formación.

Para finalizar os invito a que ojeéis las imágenes. Os adelanto que os identificaréis con muchas de ellas, y es que todos sentimos la necesidad de guardarnos algo para nosotros y reclamamos nuestro derecho a la privacidad, con 5 años o con 60.

Anteriormente, de la mano de Juan Manuel Sanz, se ha hablado del Firewall pfsense (I, II, III, IV y V). Hoy vamos a ver un addon muy interesante que nos ayudará a mejorar la seguridad de nuestra red usando pfsense.

pfblockerNG

El addon pfblockerNG es la evolución del antiguo paquete pfblocker. Básicamente es un paquete capaz de descargar y gestionar listas de direcciones IP (IPv4 /6) desde múltiples fuentes y diferentes formatos.

pfblockerNG es capaz de gestionar estas listas de direcciones IP para crear de forma automática reglas en el firewall para permitir o denegar tráfico en los interfaces de nuestro Pfsense.

Ventajas del plugin pfblockerNG frente al tradicional pfblocker:

• Actualización programada de la base de datos GEOIP con soporte IPv4/6.
• Soporte de múltiples formatos para las listas de IP: txt, gz, zip, xlsx, html.
• De-duplicación de direcciones IP basada en la herramienta Grepcidr que permite mejorar la eficiencia de las listas de direcciones IP.
• Pestaña con información sobre las reglas de firewall creadas.
• Posibilidad de visualizar en tiempo real de las denegaciones del firewall en base a las blocklists creadas.

Blocklist para pfblockerNG

La potencia de pfblockerNG reside en el uso de listas que nos permitirán bloquear rangos de direcciones IP de Spammers, botnets, malware, spyware y/o bloques de direcciones IP de países potencialmente peligrosos.

Algunos links a proyectos y/o empresas que mantienen listas que pueden sernos de utilidad para nuestro firewall pfsense:

• EmergingThreats: Compañía fundada en 2003 dedicada a la investigación de ciberamenazas, se ha convertido en una referencia en la detección de malware. Desde su web proporciona listas tanto comerciales como open source para la protección frente a amenazas.
• MalwareDomains: Se encargan de mantener un listado de dominios utilizados para propagar malware y spyware. Se pueden encontrar listas para BIND y otros servidores DNS.
• iBlockLists: Distribuye un gran abanico de listas de direcciones IP comprometidas, Spammers, spyware, malware, etc. que pueden ser usadas multitud de aplicaciones.
• Spamhaus: Mantiene un gran número de bases de datos (“DNSBLs”) y listas como SBL (Spamhaus Block List), Exploits Block List (XBL), Policy Block List (PBL) y Domain Block List (DBL) que ayudan a detectar y prevenir las amenazas.
• AlienVault: Empresa dedicada a la seguridad que ofrece soluciones SIEM y servicios profesionales en el ámbito de la seguridad. Mantiene una lista con un gran número de direcciones.
• OpenBL: También conocido como SSH Blacklist, se encarga de detectar, registrar y reportar distintos tipos de ataques de fuerza bruta.
• Dshield.org: Fundado en el 2001, actualmente el ISC provee análisis y servicios de alerta temprana a miles de usuarios y organizaciones en Internet colaborando estrechamente con muchos ISP.

Algunos enlaces a listas negras:

• Emerging Threats.
• The CINS Score.
• Malware Domain List.
• Malc0de.
• Spamhaus.
• Open BL.

Debemos tener en cuenta que la utilización de un gran número de listas negras, como las mostradas en este post, puede generar un aumento en el consumo de recursos de nuestro firewall pfsense, aspecto que debemos monitorizar.

Como ya se comentó en el anterior post, el ENS tendría que estar implantado al 100% en las diferentes administraciones públicas y proveedores:

• Hace 5 años de su publicación.
• Hace 4 años desde que todo nuevo proyecto debía “nacer” adecuado al ENS.
• Hace 4 años desde que se debía empezar con los planes de adecuación.
• Hace 1 año desde que todo plazo de adecuación acabó y por tanto la implantación debía estar realizada.

3 años parecían tiempo suficiente para llevar a buen puerto las adecuaciones, así que una vez pasado un cuarto año de cortesía, toca medir cómo ha ido esta adecuación. Vamos a verlo.

Echando mano de una búsqueda rápida en Google llegamos a la web www.cumplimientoens.es que parece ofrecer un listado del estado de adecuación de las diferentes administraciones públicas, aunque por desgracia no es un listado oficial, ni completo, ni actualizado.

Mientras esperamos a que aparezcan los primeros datos oficiales que aporte INES, las únicas estadísticas oficiales que hemos encontrado son las que pública periódicamente el CCN pero que, dado su formato y forma de cálculo, no son las idóneas para estimar el volumen de adecuaciones actual:

Estos datos por sí solos no nos dan la información que buscamos, además de que reflejan solo los datos de aquellos organismos que han decidido proporcionarlos voluntariamente.

Para conocer el estado actual del ENS, el siguiente planteamiento ha sido entrar directamente a las webs de las comunidades autónomas en busca de las declaraciones de conformidad que según el artículo 41 deben lucir en sus sedes electrónicas, pero tras hacer un muestreo en las de Madrid, Cataluña, Andalucía y Valencia y no encontrar nada, hemos buscado directamente en Google certificados con diferentes nombres:

Que nadie se venga arriba con esos supuestos 42.900.000 resultados, ya que no reflejan exactamente la situación real… Vamos a ver las diferentes declaraciones:

• El Ministerio de Economía y Competitividad tiene en su web un documento llamado declaración de conformidad, pero al abrirlo vemos que no está actualizado desde hace un año, y en lugar de tener una declaración de conformidad, indica que se está trabajando en la adecuación, pero que aún no están adecuados.

  https://sede.micinn.gob.es/stfls/sede/Ficheros/Certificados/Declaracion_de_Conformidad_al_ENS.pdf

• En la web de la Seguridad Social encontramos otro documento de conformidad, que de nuevo indica que a fecha de agosto de 2014 no se había completado la adecuación. Esta vez la “declaración de conformidad” tiene una estimación de plazos, el cual acabaría en marzo del 2015, pero o bien no se ha completado, o no se ha actualizado la declaración.

  https://sede.seg-social.gob.es/prdi00/groups/public/documents/binario/143909.pdf

• La Fábrica Nacional de Moneda y Timbre también dispone de su declaración de conformidad, en la cual no declaran que cumplan con el ENS, sino que una vez más vemos como se ha revisado el nivel de cumplimiento, y se ha creado un plan de adecuación, pero se desconoce si ha finalizado.

  https://www.sede.fnmt.gob.es/normativa/declaracion-de-conformidad

• ¡No desesperemos! ¡La siguiente declaración de conformidad parece buena! En la web de AENA (nótese que AENA no es ya, tras la reciente salida a bolsa, una empresa pública, y la web referencia a ENAIRE, propietaria del 51% de AENA. En este caso, es a ENAIRE a quien aplicaría el ENS) tenemos una declaración de conformidad donde se indica que se ha acabado con las tareas de adecuación y que el nivel de cumplimiento es satisfactorio.

  https://sede.aena.gob.es/csee/Satellite?blobcol=urldata&blobheader=application%2Fpdf&blobkey=id&
  blobtable=MungoBlobs&blobwhere=1237566144773&ssbinary=true

• Si seguimos revisando declaraciones llegamos a la de la Agencia Tributaria, la cual tampoco confirma que se haya finalizado con el proceso de adecuación.

  https://www.agenciatributaria.gob.es/AEAT.sede/Inicio/_otros_/Normativa_Sede/Otros/
  Declaracion_de_conformidad_con_el_Esquema_Nacional_de_Seguridad/Declaracion_de_
  conformidad_con_el_Esquema_Nacional_de_Seguridad.shtml

• Al revisar la declaración de la Universidad de Granada, encontramos otra declaración correcta de que efectivamente cumplen con el ENS:

  http://secretariageneral.ugr.es/pages/declaracionens

Para facilitar la lectura, resumiremos el resto de declaraciones analizadas:

• Instituto Andaluz de la Mujer: los sistemas se han analizado, pero no queda claro si cumplen o no.

  http://www.juntadeandalucia.es/institutodelamujer/index.php/iam/declaracion-de-conformidad-con-el-esquema-nacional-de-seguridad-ens

• Autoridad Portuaria de Ferrol-San Cibrao: disponen de plan de adecuación, pero no se confirma la adecuación.

  http://sede.apfsc.gob.es/documents/21269/98802/ENS%20Declaracion%20Conformidad

• Diputación de Cáceres: disponen de plan de adecuación, pero no se confirma la adecuación.

  https://sede.dip-caceres.es/carpetaCiudadano/Enlaces.do?id=declaracionens

Así pues, a modo de resumen, de las 9 declaraciones revisadas, solo dos son completas y están actualizadas, siempre, tengámoslo en cuenta, según la información pública disponible (que no implica que sea fiel al 100% a la realidad).

Todos coincidiremos en que no son las estadísticas más fiables del mundo en cuanto a nivel de cumplimiento del ENS, pero a falta de otras más rigurosas me aventuro a concluir que:

• Los organismos que no tienen la declaración de conformidad, probablemente no habrán adecuado sus sistemas al ENS. Implantar un ENS cuesta muchísimo, así que si se ha hecho el esfuerzo, dudo que se pase por alto poner la guinda al pastel publicando la declaración (cuya publicación por otro lado es obligatoria).
• Los organismos con declaraciones de conformidad que apuntan a que se está trabajando en la adecuación, probablemente no habrán acabado la adecuación aun.

Espero que este post sirva para animar a quienes tengan sus adecuaciones pendientes de acabar, de llamamiento a los organismos que no hayan empezado, y de recordatorio a los que no hayan actualizado o publicado su declaración de conformidad :)

En el post anterior (Detección de código malicioso con YARA (I)) os explicamos la funcionalidad de YARA y cómo crear reglas básicas para detectar malware especifico. En este post vamos a usar YARA con Volatility sobre un volcado de memoria RAM para la detección de un Troyano bancario ‘Zeus’. Para los que no sepáis que es Volatily, es una herramienta de código abierto para el análisis de la memoria RAM. Es compatible con el análisis para Linux, Windows, Mac y sistemas Android.

Para el propósito de demostrar la funcionalidad de Volatility con Yara hemos obtenido un volcado de memoria que esta infectado por uno de los troyanos bancarios mas conocidos, ‘Zeus’.

Actualmente Zeus es muy “difícil” de detectar incluso con antivirus y otros softwares de seguridad, ya que usa algunas técnicas de ofuscación. Se considera que esta es la razón principal por la cual se ha convertido en una de las mayores botnets de Internet.

Lo primero que nos hará falta para empezar con nuestra aventura con Volatility será determinar a qué sistema operativo corresponde nuestro volcado, así que utilizaremos el plugin imageinfo para averiguarlo.

./vol.py imageinfo -f <ubicacion del volcado de memoria>

En la ilustración anterior, podemos ver que Volatility sugiere utilizar el perfil WinXPSP2x86.

En la siguiente imagen vemos la lista de los perfiles disponibles en Volatility. Observamos que todos los perfiles que aparecen corresponden a diferentes versiones de Windows. Los perfiles de Linux se incluirán en futuras actualizaciones. Por lo tanto, si estamos usando Linux o Mac, tendremos que crear nuestro propio perfil.

Una vez determinado el perfil para el Volatility utilizaremos el plugin de Yara. Para ello utilizaremos el siguiente comando:

python vol.py --profile=WinXPSP2x86 -f /home/brian/SAW/zeus.vmem yarascan --yara-file=/home/brian/SAW/zeus.yar

Su explicación es la siguiente:

  --profile=WinXPSP2x86 | Para especificar el perfil del sistema operativo.
  -f /home/brian/SAW/zeus.vmem | Ruta de nuestro volcado de memoria.
  yarascan | Ejecutamos el plugin de Yara
  --yara-file=/home/brian/SAW/zeus.yar | Conjunto de reglas que será utilizado por yarascan.

Ejecutando el comando anterior, Yara escaneará todos los procesos de la memoria en busca de patrones que coincidan con las reglas que hayamos especificado en el comando (--yara-file=?)

En la siguiente ilustración apreciamos uno de los procesos en los que Zeus ha inyectado código malicioso (explorer.exe – PID 1724) y la regla Yara que ha coincidido, en este caso (zbot).

Teniendo ya “algo” (Sarcasm) de certeza sobre que efectivamente el proceso está inyectado con código malicioso, utilizaremos otro maravilloso plugin (procdump) para extraer el ejecutable de la memoria. Para ello utilizaremos el siguiente comando:

python vol.py --profile=WinXPSP2x86 -f /home/brian/SAW/zeus.vmem procdump -D /home/brian/SAW/ -p 1724

Su explicación es la siguiente:

  procdump | Ejecutamos el plugin para extraer los procesos
  -D home/brian/SAW/ | Ubicacion donde queremos guardar lo que extraigamos
  -p 1724 | El identificador del proceso que queremos extraer (explorer.exe - Pid 1724)

Tras haber extraído nuestro ejecutable (explorer.exe – PID 1724) de la memoria a (/home/brian/SAW/ejecutable.1724.exe) lo subiremos a Virustotal, a ver cuántos ‘Antivirus’ lo detectan.

Bueno… 9 de 57 no esta mal :/ para haber sido detectado por primera vez en julio de 2007 segun la Wikipedia.

Ya hemos visto como usando la combinación de estas 2 herramientas, nos podría ser muy útil en situaciones de respuesta a incidentes y detección de malware más sofisticado.

Os dejo los links de descarga del volcado y de las reglas por si alguien quiere jugar un poco.

• Volcado de memoria.
• Reglas Yara: http://pastebin.com/cSLqU6Rj

Qué título tan pretencioso, ¿verdad? Algunos de vosotros ya habréis reflexionado sobre el tema que plantea este post, pero es posible que muchos de los lectores consideren que el título sugiere una situación exagerada y fatua. A continuación comparto con vosotros algunos datos recopilados durante la fase de investigación previa a escribir este artículo.

La ciberseguridad mueve cada vez más dinero a nivel mundial, para muestra las siguientes cifras (datos extraídos del informe realizado por el Center for Strategic and International Studies (CSIS) y McAfee , julio 2014):

• Impacto global de la ciberdelincuencia: aproximadamente 445.000 millones de $.
• Impacto económico de la ciberdelincuencia en las empresas: 400 millones de $.
• Las pérdidas globales vinculadas a violaciones de “información personal” podrían llegar a 160.000 millones de dólares.

Por otro lado el uso de las tecnologías para encontrar pareja es cada vez más frecuente ya que cada vez más relaciones de pareja comienzan con un contacto vía Internet:

• En España existen cerca de 10 millones de solteros y solteras mayores de 20 años, según datos del Instituto Nacional de Estadística (INE). La mitad de ellos, es decir unos 5 millones, utiliza Internet mensualmente como medio para encontrar una relación seria. Esta cifra aumenta un 7% cada año.
• En Estados Unidos casi el 75% de los solteros ha utilizado Internet por lo menos una vez para buscar una pareja.
• Del total de parejas que se casan cada año, el 17% se conoció en Internet.
• La gran mayoría de los portales más famosos para encontrar pareja en Internet no son gratuitos. Esta industria pasó de generar unos 700 millones de dólares en 2007 a 1900 millones de dólares en el 2012.

Nuestras relaciones personales forman parte de nuestra intimidad, y los aspectos relacionados con éstas se consideran de carácter confidencial. En este ámbito, cobra especial relevancia para la persona o personas involucradas el control de su privacidad. Algunas de estas cuestiones, como por ejemplo la orientación sexual, incluso están protegidas por la legislación vigente.

Parece claro que existen vínculos entre el dinero, el amor y la seguridad pero, ¿qué relación existe entre la salud de las personas y la ciberseguridad?

Si pensamos en la tecnología que soporta el funcionamiento de herramientas sanitarias, nos encontramos una gran variedad de entornos. Por ejemplo, los sistemas de información RISC (también conocidos como sistemas de gestión de imagen médica) que centralizan las imágenes médicas de diferentes orígenes y tipologías (radiologías, TAC, ecografías, RNMs,…), los implantes médicos (marcapasos, placas, implantes cocleares,…), las sondas (para el suministro de insulina, catéter, monitorización cardiovascular,…) y por supuesto las posibilidades de telecirugía o cirugía remota, que permite realizar operaciones quirúrgicas desde emplazamientos geográficamente distantes.

Parece claro que la dependencia actual entre la tecnología y la salud es, a día de hoy, relevante. Muchos de estos tratamientos ya disponen, o dispondrán en un futuro cercano, de opciones que permitan el uso de sus funcionalidades desde conexiones inalámbricas, siendo obvio la importancia de garantizar su seguridad.

La tecnología favorece y condiciona la evolución de la medicina ofreciendo mejoras relacionadas con la rapidez, sencillez de obtención y fiabilidad de los resultados médicos. En la actualidad las universidades ya disponen de grados (Ingeniería de la Salud, Ingeniería Biomédica, etc.) y máster de varios tipos relacionados con la biomedicina.

También el mundo del celuloide ya ha mostrado o imaginado cómo se realizaría un ataque hacker a un marcapasos (no vamos a desvelar la serie donde se puede ver esto) y líderes mundiales han tomado medidas de seguridad relacionadas con su salud (Cheney, el que fuera vicepresidente de EEUU con Bush, solicitó que le desactivaran las funcionalidades relacionadas con las comunicaciones inalámbricas de su marcapasos, para evitar posibles ataques hacker).

Nos encontramos pues en un momento significativo para las relaciones entre la tecnología y la salud.

Pero, ¿cómo nos preparamos los especialistas de la ciberseguridad? ¿Y los ciberatacantes? A día de hoy pocos dispositivos médicos incluyen medidas que permitan garantizar la seguridad de la tecnología que utilizan. Hasta ahora los fabricantes han priorizado otros aspectos como el uso de materiales compatibles con el cuerpo humano o crear soluciones de tamaño reducido, dejando de lado temas como la seguridad de los dispositivos médicos. No obstante, es ahora cuando tenemos que comenzar a buscar soluciones sólidas que garanticen la salud sin olvidar la seguridad.

En este punto no puedo dejar de preguntarme como profesional de la ciberseguridad qué se considerará más importante: ¿los datos sensibles de un banco o los de un hospital? ¿Cuál sería el riesgo residual para un activo informático que contenga información crítica sobre la salud de los pacientes? ¿Cómo se definiría un plan de continuidad de negocio que tuviera que garantizar la contingencia de los implantes médicos? ¿Qué medidas técnicas se implantarán en los dispositivos médicos para garantizar su seguridad sin perjudicar su funcionalidad?

Desde mi punto de vista garantizar la salud de las personas debe estar por encima del fraude financiero y se me ocurren algunas soluciones a estas preguntas, pero de momento lo único que pretendo es levantar la mano en sentido figurado y proponer un tema de reflexión.

Si la evolución de las tecnologías y sus aplicaciones sigue creciendo al ritmo actual, es muy probable que en poco tiempo la seguridad de la información adquiera una posición crítica entre nuestras prioridades personales como un componente vital en la salud, el dinero y en el amor, quizá hasta formando parte de uno de nuestros deseos principales.

Espero que los profesionales de la biomedicina y de la seguridad sigamos un progreso alineado, que permita cubrir las necesidades de la salud sin olvidar la ciberseguridad, ofreciendo soluciones no sólo adecuadas desde el punto de vista sanitario sino también seguras.

Dicho esto os deseo, ¡salud, dinero, amor y ciberseguridad!

Las referencias a CERT o CSIRT dentro del mundo de la seguridad informática son frecuentes. Todo (o casi todo) el mundo dentro de este ámbito sabe lo que son y cuál es su función.

Sin embargo, en el tiempo que pasé estudiando Ingeniería Industrial jamás, ni una sola vez, escuché ninguna de estas palabras. Y parece razonable que así sea. Al fin y al cabo los “Equipos de Respuesta ante Incidencias de Seguridad Informática” (que eso es lo que son los CERT/CSIRT por si algún lector anda despistado) son, a todas luces, cosa de los informáticos, no de los industriales. Su nombre no da lugar a dudas: “Seguridad Informática”.

No obstante, un día, el que aquí escribe se encontró con otro de esos maravillosos acrónimos que tanto gustan en el mundo TI: ICS-CERT. Y… ¡un momento! Parece que los industriales ya no podemos escurrir el bulto. Porque los ICS son (por sus siglas en inglés) los Sistemas de Control Industrial. Y eso nos toca de lleno. Para aquellos que en este momento no sepan muy bien de qué estoy hablando o que estén preguntándose qué pintan los Sistemas de Control Industrial en un blog de seguridad informática les recomiendo encarecidamente que echen un vistazo a la sección de Ciberseguridad Industrial de esta bitácora.

El ICS-CERT opera dentro del National Cybersecurity and Integration Center (NCCIC) que es una división del Departamento de Seguridad Nacional de los EEUU. Como ocurre con los CERT clásicos, este organismo se encarga de, entre otras cosas, gestionar la publicación de vulnerabilidades y de recopilar las soluciones que los fabricantes dan para las mismas pero, en este caso, en el área de los sistemas de control industrial.

Así pues, en la medida en que existen CERT específicos para este tipo de sistemas, parece que los ataques a infraestructuras de carácter industrial empiezan a generar cierta preocupación. Así que hay alguien que se encarga de avisar al fabricante en caso de encontrarse vulnerabilidades y éste, a su vez, de publicar una solución que resuelva el problema a sus clientes. Después de tanto tiempo ya podemos dormir tranquilos, ¿o no? Veamos una de las últimas alertas publicadas: ICSA-15-064-04.

Se trata de una vulnerabilidad [CVE-2015-2177] para todas las versiones de PLC SIMATIC S7-300 de Siemens, una de las series de autómatas más extendidas en todo tipo de procesos industriales (industrias química, energética, alimentaria o de suministro y depuración de aguas, sin ir más lejos).

La puntuación de esta vulnerabilidad es de 7,8 sobre 10 (CVSS Base) y permite una Denegación de Servicio (DoS) en esos equipos sin autenticación previa. Es decir que, en ciertas circunstancias, sin necesidad de poner ni usuario ni contraseña, un atacante podría dejar “KO” nuestro sistema. Y además podría hacerlo de manera remota, sin estar físicamente cerca de los equipos. Haciendo llegar a nuestro PLC una serie de paquetes de datos creados ad hoc (textualmente en el CVE: “specially crafted packets”) el PLC se queda en modo de defecto. La única opción que tendríamos en ese caso sería reiniciar nuestro PLC.

El problema parece bastante serio. No hace falta tener un conocimiento técnico muy profundo para entender la gravedad de las consecuencias de un paro inesperado en la producción en cierto tipo de industrias. Pero bueno, no hay nada de lo que a priori debamos preocuparnos porque Siemens ha publicado ya su solución (PDF). Y viendo la relevancia de la vulnerabilidad, seguro que ya estaremos a salvo. O quizá no…

Veamos con un poco más de detalle qué nos dice el fabricante. Para mitigar el problema Siemens nos recomienda:

• Aplicar protección de nivel 3 (protección de lectura/escritura).
• Aplicar el concepto de “Protección de celdas”.
• Usar VPN para comunicaciones entre las celdas.
• Aplicar “Defensa en profundidad”.

Lo primero que nos llama la atención es el uso del verbo mitigar. De hecho, si buscamos una vulnerabilidad muy similar publicada por el mismo grupo de investigación [CVE-2014-2256], observamos que Siemens proporciona una actualización de firmware y utilizan otro verbo: “resolver”. Parece que el uso de la expresión “mitigar” es deliberado.

Hagamos un repaso punto por punto a las propuestas de Siemens.

Aplicar protección nivel 3. Buceando un poco en la documentación de los S7-300 vemos que se trata de una protección de acceso a la información de la CPU que se puede activar a través del software de programación de Siemens para estos PLC, STEP 7. Si nos vamos al manual encontramos lo siguiente:

Es decir, si establecemos un nivel de protección 3 se nos solicitará contraseña para cargar y/o descargar el programa que hay en el PLC. Además, y aquí viene algo interesante: “impide la ejecución de funciones online que pudieran impedir negativamente en el proceso”. ¿Podría esto resolver nuestro problema? Busquemos un poco más en el manual.

El concepto “online” en este caso se refiere a estar conectado con nuestro sistema de control a través del software de programación “STEP 7”. Parece poco probable que, tratándose de “specially crafted packets”, su envío haya de realizarse necesariamente a través de STEP 7. Además, en cualquier caso, el PLC sigue intercambiando información con el resto de elementos de nuestro sistema de control (porque para eso está diseñado) por tanto, aún con esta protección habilitada, si somos capaces de acceder a la red donde el PLC se encuentra, podríamos hacerle llegar el paquete malicioso.

Puesto que el código específico no ha sido publicado, no hemos podido reproducir la situación exacta en nuestro laboratorio pero la experiencia con casos similares a este nos dice que este tipo de acciones mitigan el problema pero no lo solventan.

La segunda medida que nos sugiere Siemens es aplicar el concepto “Protección de celdas”. O lo que es lo mismo: segmenta tu red. Pon dentro de una misma celda todos aquellos elementos de tu sistema que no tengan mecanismos propios de protección o que no sean capaces de establecer comunicaciones cifradas (que probablemente no serán pocos). Todos aquellos elementos que deban tener comunicación en tiempo real es conveniente que también estén dentro de la misma celda. Esto, en algún caso y según el proceso, nos deja con una celda del tamaño de nuestro sistema de control completo.

La tercera recomendación es usar conexiones VPN para comunicaciones entre celdas. Asegúrate de que toda la información que viaja entre esos segmentos va convenientemente cifrada. No vaya a ser que alguien sea capaz de leerla sin permiso o, lo que podría ser incluso peor, leerla y devolverla modificada. Aunque en el entorno TI la aplicación de esta recomendación sea trivial, en el entorno industrial puede llegar a ser complicada. En el caso de que fuera posible tener diferentes celdas, la mayoría de equipos que se venden para sistemas de control industrial no acepta protocolos cifrados. ¿Cómo establecer este tipo de comunicaciones si los equipos no las admiten? Además esto tampoco es una verdadera solución para nuestro problema. Si conseguimos acceder a una de las celdas, aunque la comunicación entre ellas sea cifrada, el paquete malicioso seguiría llegando a su objetivo. Una comunicación cifrada (si el cifrado es robusto) es tan frágil como lo sean sus extremos, en este caso, las celdas.

Por último, Siemens nos aconseja aplicar “Defensa en profundidad”. Esto es, crea diferentes perímetros de seguridad lógica alrededor de tu sistema de control industrial. Haz uso de firewalls, proxies y pon en marcha sistemas automáticos de detección y protección frente a intrusiones (IDS/IPS). Lleva a cabo una adecuada política de gestión de usuarios y de renovación de contraseñas y mantén actualizados los antivirus y software de listas blancas en los PCs de la red de control.

Como se ha visto, la solución de Siemens tiene mucho de “hágalo usted mismo”… si puede. Y es que si alguno esperaba algo que se pareciera a un parche o una actualización de firmware ha errado el tiro. El fabricante nos da recomendaciones para que trabajemos en la protección de la arquitectura de nuestro sistema porque no ha encontrado una solución definitiva para proteger el equipo. Y aunque no es ningún disparate trabajar en esa línea, no es lo que se esperaría en el mundo TI como respuesta de un fabricante ante la publicación de una vulnerabilidad. Se transfiere toda la responsabilidad directamente al propietario del equipo.

Ya hemos comentado en algún que otro post que la realidad del entorno industrial es sensiblemente distinta a la del entorno puramente corporativo. Éste ha sido sólo un ejemplo práctico más. Su naturaleza, los requerimientos de funcionamiento de este tipo de sistemas y a menudo también el modo en que se debe trabajar con ellos, impiden la aplicación directa del tipo de soluciones clásicas del entorno TI. Los propietarios y operadores de este tipo de infraestructura han de seguir tomando conciencia y adoptar acciones compensatorias. Evaluar el estado de la ciberseguridad de sus ICS y monitorizar las comunicaciones en los mismos puede ser un buen punto de partida. Bueno, eso o esperar sentado una solución de los fabricantes. Sentado.

Fuentes de las imágenes:

• La ilustración del ICS Cert es una captura de https://ics-cert.us-cert.gov/.
• La imagen del CVSS Score es de http://www.cvedetails.com/.
• La última ilustración es de http://www.harquin.com/pov/?article=113.

Entre una pareja, entre padres e hijos, entre los jefes y sus trabajadores; una buena comunicación es clave para prevenir problemas de seguridad en diferentes ámbitos, sobre todo en el empresarial, donde una de las principales causas de violaciones de datos son las acciones inconscientes e involuntarias de trabajadores de confianza, los también llamados Trusted insiders (inadvertent).

¿Cómo lograr que los trabajadores sean conscientes de que la seguridad de la información es una prioridad para la empresa y que de ellos depende en buen grado? Las campañas de concienciación y los programas de formación son muy importantes pero ¿son suficientes? Una comunicación continua, de calidad, y bidireccional es el pilar fundamental para lograrlo.

Planificación y desarrollo continuo

No puedes pretender que tu hijo adolescente siga tus recomendaciones para no meterse en problemas si cuando era un niño no te preocupaste en cultivar una buena comunicación con él. Lo mismo aplica para el ámbito organizacional: no basta con enviar un e-mail con las normas de seguridad de la empresa cuando ocurre un incidente o realizar una campaña de concienciación por unos meses y olvidarse del tema.

Si se quiere que la seguridad de la información esté presente en la cultura corporativa, las campañas de concienciación deben formar parte de unas comunicaciones internas planificadas y desarrolladas de forma continua, que mantengan al trabajador informado y realmente comprometido con los intereses de la empresa en general, entre ellos la seguridad de la información. Por otra parte, las nuevas tecnologías avanzan muy rápido y con ellas surgen nuevos problemas de seguridad y medidas para enfrentarlos que deben ser comunicadas de manera constante, oportuna y comprensible a los trabajadores.

Variedad, claridad y gancho

Si quieres mucho a tu pareja pero no le dedicas tiempo ni haces nada divertido que rompa la rutina, corres el riesgo de que un “intruso” o “intrusa” se cuele en tu hogar. Lo mismo puede ocurrir en una organización si solo se utiliza el correo para enviar políticas de seguridad difíciles de digerir.

El correo es un buen canal de comunicación pero no es el único, ni siquiera el más eficiente. Las reuniones cara a cara, la intranet, los blogs, las redes sociales y últimamente las aplicaciones móviles, ofrecen una amplia variedad de opciones que deben aprovecharse al máximo para lograr una comunicación integral y eficiente entre la organización y sus trabajadores. Todos estos canales facilitan y enriquecen el desarrollo de campañas de concienciación y programas de formación en seguridad, sobre todo las redes sociales y aplicaciones móviles porque ofrecen la posibilidad de medir el consumo y la satisfacción de los trabajadores a través del registro de los links marcados, los “me gusta” y los comentarios.

Un título aburrido y una parrafada interminable y llena de términos técnicos complejos suelen espantar a cualquier trabajador, quien seguramente no les dedicará ni tres segundos de su atención, aunque tenga la obligación de leer dicho documento y tenerlo presente en su trabajo diario. Los contenidos que se comunican deben ser cercanos, comprensibles y sobre todo, tener gancho, si se quiere que sean entendidos y recordados. Noticias, twitters, posts, vídeos, recomendaciones, casos de la vida real, infografías y tutoriales con contenidos gráficamente atractivos, redactados de manera sencilla y creativa, son algunas de las herramientas de comunicación que se pueden utilizar para difundir las políticas de seguridad de una organización.

En ambos sentidos

Si quieres que tu hijo te preste atención y sea receptivo cuando le hablas sobre temas serios como su seguridad, tú también debes ser capaz de escucharlo y prestarle la misma atención que estás exigiendo cuando te hable a ti. Este principio también es básico en las comunicaciones internas de las empresas.

Si las comunicaciones solo se limitan a la transmisión unidireccional de mensajes por parte de la organización y no se fomenta ni se valora la participación de los trabajadores como emisores de información, la empresa seguramente no podrá evaluar correctamente la efectividad de sus comunicaciones y peor aún, es probable que no detecte a tiempo posibles problemas de seguridad.

Es importante que la comunicación fluya bidireccionalmente de forma vertical y horizontal en la jerarquía de la empresa. En este proceso es imprescindible que sean los líderes quienes promuevan y valoren el intercambio de información entre todos los trabajadores. Para ello contamos con nuevas tecnologías, como las redes sociales y las aplicaciones móviles, que amplían enormemente la interacción entre usuarios y que permiten compartir mucha información.

Fuentes:

• http://www.slideshare.net/TreforSmith/internal-comms-2014
• http://www.ponemon.org/local/upload/file/2014%20The%20Year%20of
  %20the%20Mega%20Breach%20FINAL_3.pdf
• http://www.businessnewsdaily.com/7954-business-communication-failures.html

El objetivo principal de esta entrada y las siguientes que vamos a publicar es ir mostrando diferentes aspectos interesantes del análisis que estamos haciendo de una de las funcionalidades del framework utilizado por el grupo bautizado como “Equation” por la empresa Kaspersky. Este grupo ha utilizado un conjunto de herramientas y funcionalidades, donde alguna de ellas han sido consideradas bastante especializadas y creemos que merecen una especial atención.

Entre todas las herramientas y funcionalidades desarrolladas por el grupo nos hemos centrado en analizar la funcionalidad que permite añadir persistencia en el firmware de los discos duros. De todos modos para más información se puede consultar el siguiente informe de Kaspersky:

- https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf

Las muestras analizadas sobre las que vamos a trabajar durante los artículos son:

Nombre	        Hash	Valor
nls_933w.dll	MD5	11FB08B9126CDB4668B3F5135CF7A6C5
nls_933w.dll	SHA1	FF2B50F371EB26F22EB8A2118E9AB0E015081500
WIN32M.sys	MD5	2B444AC5209A8B4140DD6B747A996653
WIN32M.sys	SHA1	645678C4ED9BBDD641C4FF4DCB1825C262B2D879

En primera instancia vamos a centrarnos en realizar un análisis estático de la librería nls_933w.dll y ver qué módulos importa la librería:

Es destacable (tal y como nos indica la herramienta PEstudio) cómo la librería importa el módulo setupapi.dll. Este módulo ofrece funciones generales de instalación y funciones para la instalación de dispositivos, entre ellas, ofrece funciones para la instalación de drivers.

Tratándose de una librería es muy importante observar qué funciones exporta. Estas funciones son las que el módulo ofrece a otros programas para utilizar su funcionalidad. Vemos a continuación la tabla de exports:

Observando la tabla vemos cinco funciones que se exportan y que son las funciones alcanzables desde otras aplicaciones; después analizaremos cada una de las funciones exportadas.
Otro de los aspectos destacados es que la librería lleva embebido un driver en la sección Resources con el nombre 101. Este driver implementa la lógica para leer y escribir información en determinados dispositivos como discos duros:

El siguiente punto de interés de nuestro análisis estático, a partir del cual podemos inferir parte de los propósitos de la librería, es el análisis de los símbolos que importa:

Se aprecia como la librería importa funciones para trabajar con los Resources (LoadResource(), SizeofResource(), etc.) y poder cargar el driver. Además, vemos como utiliza funciones de gestión de dispositivos (SetupDiEnumDeviceInfo(), SetupDiDestroyDeviceInfoList(), etc.). Otro punto a destacar es el uso de la función DeviceIoControl(), que permite definir un protocolo de comunicación entre el dispositivo y una aplicación cliente mediante códigos de control.

Esta última función se verá después como es fundamental ya que es la encargada de implementar el protocolo de comunicación entre la librería y el driver. Por último se ve como se importan funciones para el manejo del registro, cuyo uso debe ser analizado para detectar y generar posibles indicadores de compromiso.

Otro de los puntos que requieren un análisis son las cadenas del binario:

Como vemos las que destaca la herramienta se corresponden la mayoría con símbolos que ya habíamos observado en el listado de símbolos y que ya hemos comentado qué nos aportan a nuestro análisis estático. Además, podemos ver a la derecha cadenas que están en el driver (recordemos que el driver está embebido en la propia librería) y que ya nos dan información sobre qué funcionalidades podrá darnos el driver (READ_PORT_ULONG, etc.).

En esta entrada hemos hecho un análisis estático de los diferentes elementos de la librería y con hemos podido situarnos y plantearnos una estrategia de análisis. En próximas entradas continuaremos analizando de manera estática y dinámica la librería.

En artículos anteriores del blog hemos tratado únicamente temas de la ley de protección de datos personales española, pero a partir de ahora vamos a comenzar a introducirnos también en la ley colombiana. Los primeros lineamientos sobre la protección de datos personales aparecen con la Constitución política de 1991 con el artículo 15, donde se consagra el derecho de cualquier persona de conocer, actualizar y rectificar los datos personales que existan sobre ella en bancos de datos o archivos de entidades públicas o privadas. Igualmente, ordena a quienes tienen datos personales de terceros respetar los derechos y garantía previstos en la Constitución cuando se recolecta, trata y circula esa clase de información.

Veamos la evolución cronológica de la normativa:

• Ley 1266 de 2008: Se dictan las disposiciones generales del Habeas data y se regula el manejo de la información contenida en bases de datos personales, en especial la financiera, crediticia, comercial, de servicios y la proveniente de terceros países y se dictan otras disposiciones (Habeas Data).
• Decreto 1727 de 2009: Se determina la forma en la cual los operadores de los bancos de datos de información financiera, crediticia, comercial, de servicios y la proveniente de terceros países, deben presentar la información de los titulares de la información.
• Decreto 235 de 2010: Se reglamenta el intercambio de información entre entidades para el cumplimiento de funciones públicas.
• Decreto 2280 de 2010: Se modifica el artículo 3° del Decreto 235 de 2010.
• Decreto 2952 de 2010: Se reglamentan los artículos 12 y 13 de la Ley 1266 de 2008.
• Ley 1581 de 2012: Se dictan disposiciones generales para la protección de datos personales.
• Decreto 1377 de 2013: Se reglamenta parcialmente la Ley 1581 de 2012.
• Ley 1712 de 2014: Se crea la ley de transparencia y del derecho de acceso a la información pública nacional.
• Decreto 886 de 2014: Se reglamenta el artículo 25 de la Ley 1581 de 2012, relativo al Registro Nacional de Bases de Datos.

A diario entregamos nuestros datos personales desmedidamente, ya sea en nuestros círculos sociales o a terceros, por creer en la “buena fe”, respondiendo a “promociones” o porque no nos preocupa la información que otros tratan de nosotros. Como sabemos, el acelerado avance tecnológico ha permitido evidenciar que la información es el activo más importante y por ello el 17 de octubre de 2012 el Gobierno Nacional Colombiano expidió la Ley Estatutaria 1581 de 2012. Mediante esta se establecen las disposiciones generales para la protección de datos personales y la importancia en su tratamiento, tal como lo corroboró la Sentencia de la Corte Constitucional C – 748 de 2011, donde se estableció el control de constitucionalidad de la Ley mencionada.

Clasificación de los datos

• Dato personal público: Es el dato calificado como tal según los mandatos de la ley o de la Constitución Política y todos aquellos que no sean semiprivados o privados, como por ejemplo: documentos públicos, sentencias judiciales, estado civil de las personas.
• Dato personal semiprivado: Es el dato que no tiene naturaleza íntima, reservada, ni pública, y cuyo conocimiento o divulgación puede interesar no sólo a su titular sino a cierto sector o grupo de personas o a la sociedad en general, como por ejemplo: historias crediticias, datos financieros, reporte en las centrales de riesgos.
• Dato personal privado: Es el dato que por su naturaleza íntima o reservada sólo es relevante para la persona titular del dato, como por ejemplo: dirección de vivienda, teléfono, correo electrónico, fotografías, videos, datos que referencien el estilo de vida.
• Dato personal sensible: es la información que afecta a la intimidad de la persona o cuyo uso indebido puede generar su discriminación, como por ejemplo: orientación política, afiliación a sindicatos, religión, ideología, origen racial, afecciones de salud, organizaciones sociales.

¿Cómo puedo hacer uso de mi derecho?

Para dar respuesta al adecuado uso de los datos personales, las entidades públicas o privadas deben contar con canales de comunicación apropiados, ya sean físicos como por ejemplo un formato de solicitud, o electrónicos, que pueden ser diligenciados desde la página Web de entidad a la que se le desea hacer la solicitud. El tiempo de respuesta a la solicitud será un máximo de 10 días hábiles. Las solicitudes pueden ser para corregir, actualizar, eliminar o suprimir los datos personales o revocar la autorización otorgada previamente.

Pero, ¿de no ser atendida mi solicitud donde puedo realizar el reclamo? Actualmente la entidad que se encuentra regulando la protección de datos personales es la Super Intendencia de Industria y Comercio (SIC) y desde su página web es posible realizar las quejas o denuncias.

Espero que les haya gustado la información. Más información en próximas entradas.

En este último capítulo sobre Pfsense (ver I, II, III, IV y V) se explica la configuración de un servidor proxy como Squid en modo transparente para no tener que configurar todos los equipos de la red.

La tarea de este proxy será registrar todas las conexiones HTTP, hacer estadísticas de navegación y denegar ciertos dominios.

El primer paso es instalar estos 3 paquetes: Squid, SquidGuard y Ligthsquid.

Ahora en Services -> Proxy Server -> General, comienza la configuración, Escogiendo cual o cuales serán las interfaces que pasarán a través del proxy. Se elige la interfaz o interfaces por donde queremos que actúe el proxy. En este caso la interfaz LAN.

Allow users on interface activado para que los usuarios conectados a LAN usen el proxy directamente, y Modo transparente, para que no se tenga que configurar en cada equipo la conexión a través de proxy, sino que la navegación se haga de forma automática a través de este.

En las demás opciones dentro de la pestaña General, se puede tener la opción de guardar Log, rotarlos, modificar su formato, no mostrar la versión de Squid o mostrar el contacto que queramos en caso de error HTTP, etc…

Services -> Proxy Server -> Cache Management

• Hard disk cache size: tamaño en disco que dedicamos a los Log (en Mb).
• Sistema de cache en disco: Hay 4 sistemas, elegimos la mejor para un sistema de un solo core y con capacidad suficiente de disco (aufs).
• Memory cache size: tamaño en RAM, usada para la cache negativa y la que está en transito, (no debe superar la mitad de RAM del equipo) (En Mb).
• Minimum object size: por defecto a 0.
• Maximum object size: máximo tamaño del objeto (en kb).
• Maximum object size in RAM: máximo tamaño del objeto en RAM, por defecto 32 kb.

Aparte de estos, hay que definir otros parámetros:

• Política de remplazo en memoria: La más usada es Heap GDSF: optimiza los objetos con mayor rate haciendo uso del mantenimiento de los objetos más pequeños (frecuencia de tamaño dual).
• Política de reemplazo de cache: LFUDA ya que interesa una política con el menor numero de accesos a los discos.
• Low-water-mark in %: límite en % de la memoria de intercambio para que se produzca el remplazo de la cache.

Services -> Proxy Server -> Access Control

• Allowed subnets: las subredes habilitadas para usar el proxy, en ese caso solo las que pertenezcan al rango de LAN.
• Unrestricted IPs: Direcciones que están exentas a las reglas del proxy.
• Banned host addresses: direcciones IP que no tienen permitido el uso del proxy.
• Whitelist: en cada línea se introduce cada dominio que será accesible por los usuarios que pueda navegar por el proxy, se permiten expresiones regulares.
• Blacklist: Lo mismo que whitelist pero para denegar dominios.
• External Cache-Managers: por defecto la dirección IP de la subred LAN y localhost.

Services -> Proxy Server -> traffic Mgmt

Aquí es donde se indican los límites de subida y bajada en Kb.

En las demás secciones como users o auth, no hace falta configurar nada ya que no es un proxy con autenticación sino que es un proxy transparente.

En status -> services se deben activar los servicios relacionados con proxy:

Ahora se debe configurar el filtro del proxy en services -> proxy filter.

Services -> proxy filter -> general settings

Se activa el filtro en el checkbox que pone “Enabled” y en la sección de abajo llamada blacklist options se puede incluir la URL de donde descargar una lista de dominios. En este caso la descargada aquí se divide en varias categorías (downloads, government, drugs, porn, etc…)

Services -> proxy filter -> target categories

Se crea un nuevo objetivo llamado “lista 1”, con lista de dominios, lista de URL y expresiones regulares como se aprecia en la imagen:

Además se puede direccionar a una URL externa:

Ahora una vez creada aparece en el menú principal de target categories:

Después en la pestaña time, se puede personalizar un rango de horas semanal para luego actuar sobre un target:

Se pueden crear varias redirecciones en la pestaña rewrites:

En la pestaña Blacklist se puede descargar el gz incluido antes:

En la pestaña common ACL es donde se puede crear una ACL a partir de varios target y configurarlos con un redirect ya creado. En este caso se puede además añadir los dominios de la lista descargada antes y de la creada (lista1).

Es importante que al final de la lista pongamos allow access en default access [all].

También se puede seleccionar Do not allow IP-Addresses in URL para que el usuario no tenga la opción de evadir un dominio, únicamente poniendo la dirección IP correspondiente, y el RW1 como redirect ya configurado.

Por último, en la pestaña Services -> proxy filter -> Groups ACL se pueden añadir más configuraciones a una ACL, como añadir una subred o tiempo determinados (Times creados):

Para una mejor visualización del Log de Squid, se puede usar proxy report

status –> proxy report

Se configura el tipo de reporte:

La visualización se puede hacer por día, semana, mes, por ancho de banda, por dominios más visitados, etc…

En esta entrada vamos a hablar de la herramienta Simple Event Correlator (SEC), un script que realiza tareas de correlación cogiendo como fuentes cualquier tipo de log que podamos recibir en nuestros sistemas. Sus puntos fuertes son que no consume demasiados recursos en su ejecución y está escrita íntegramente en Perl, sin necesidad de librerías adicionales a las incluidas en la instalación por defecto de este lenguaje, por lo que podremos utilizarlo casi en cualquier plataforma.

El flujo de procesamiento que realiza se divide en tres partes: especificar qué logs queremos monitorizar, definir una serie de reglas que se comprobarán con cada nueva entrada en el log y, si aparece alguna correspondencia, se realizará automáticamente una acción definida previamente.

Las reglas están formadas por una serie de atributos para definir las acciones a realizar. Hay varios tipos de reglas que se pueden crear: detección de patrones, ya sean escritos en la propia regla (Single) o en un script (SingleWithScript), emparejar dos eventos independientes (Pair), o basadas en una hora y/o fecha específicas (Calendar) son varios ejemplos de lo que nos podemos encontrar entre todas sus opciones.

Dependiendo del tipo de regla que vayamos a crear, será necesario emplear unos parámetros determinados. Por ejemplo, los que necesita una regla de tipo Single de manera obligatoria son los siguientes:

• type: El tipo de regla. En este caso, “Single”. No distingue entre mayúsculas y minúsculas.
• ptype: El tipo de patrón utilizado en el campo pattern.
• pattern: El patrón a emplear para que salte la regla.
• desc: La descripción del evento detectado.
• action: La acción que se va a ejecutar una vez se detecta el evento.

Es posible añadir parámetros adicionales a las reglas, como comentarios adicionales (rem) o una segunda acción si la primera no se ejecuta correctamente (action2), todo ello dependiendo de la regla que estemos usando.

Para terminar, vamos a mostrar un caso práctico de aplicación. Supongamos que tenemos un servidor personal donde hemos instalado inicialmente fail2ban y cambiado el puerto de las conexiones SSH al 2552, pero además queremos hacer un registro tanto de las direcciones IP que se bloquean como de las desbloqueadas. Echando un vistazo rápido a los logs de fail2ban, nos encontramos con líneas como las siguientes:

2015-05-17 08:04:15,948 fail2ban.actions: WARNING [apache-fail2ban] Unban 151.80.129.118
2015-05-17 14:43:08,815 fail2ban.actions: WARNING [apache-fail2ban] Ban 74.208.225.40

A continuación escribiremos dos reglas muy similares para que cada una filtre un tipo de evento y lo escriba en su fichero correspondiente. Como ambas van a aplicarse contra el mismo log, solamente necesitaremos un único fichero, el cual llamaremos fail2ban.sec.

type=Single
ptype=RegExp
pattern=(.*)\s(?:.*)\sfail2ban\.actions:\sWARNING\s\[apache-fail2ban\]\sBan\s(.*)
desc=$0
action=write /var/log/bans.txt $1 $2

type=Single
ptype=RegExp
pattern=(.*)\s(?:.*)\sfail2ban\.actions:\sWARNING\s\[apache-fail2ban\]\sUnban\s(.*)
desc=$0
action=write /var/log/unbans.txt $1 $2

Ya solo nos queda lanzar el programa indicando en los parámetros el fichero de reglas que va a aplicar, los logs a monitorizar y especificar que se ejecute como un demonio:

perl sec.pl -conf=fail2ban.sec -input=/var/log/fail2ban.log –detach

Con un poco de paciencia y tiempo tendremos una pequeña base de datos a explotar, como por ejemplo realizar un script para contar cada IP que ha sido bloqueada y si en total suma más de X apariciones pasar a bloquearla indefinidamente. Esto ya depende de las necesidades (y la imaginación) de cada uno.

En resumen, una herramienta sencilla con más potencial del que aparenta a primera vista, tanto por todas las opciones que encontramos en su documentación que es capaz de realizar como la sinergia que posee para ser utilizada junto a otros programas en proyectos más grandes.

Continuando con los interesantes posts de “Coche demasiado inteligente” que escribió Raúl Verdú (I y II), voy a aportar mis conocimientos y experiencia en el sector de la automoción para ampliar más la información sobre el tema. Vamos primero a ponernos en situación, y en la segunda entrada pasaremos a ver los vectores de ataque.

Todavía recuerdo el tiempo que pasé trabajando en Nissan (Barcelona) como ingeniero de calibración de motores de combustión interna. Básicamente los ingenieros modificábamos y mejorábamos parámetros en calibraciones (variables calibrables) con la finalidad de obtener una respuesta o resultado en el funcionamiento del motor y de la conducción del coche en general. Digamos que modificábamos las “neuronas del cerebro” del vehículo para optimizar su sistema de locomoción, así como mejorar sus prestaciones. Los coches utilizan cada vez más componentes electrónicos pensados para mejorar el rendimiento, la seguridad y la comodidad de los usuarios. La mayoría de dichas funcionalidades implica procesar distintos tipos de señales del vehículo y coordinarlas en tiempo real, por lo que es necesario disponer de sensores que proporcionen los datos, unidades que se encarguen de procesarlos (Electronic Control Units o ECUs, ”cerebros”) y una forma de comunicación entre todas ellas (a través de uno o varios buses de datos mediante el Standard Controller Area Network o CAN). Un coche actual tiene docenas de ECUs, dependiendo del modelo, fabricante y versión.

Cuando era ingeniero de calibración en Nissan, utilizaba un cable “Diag 3” con puerto USB con el que me conectaba desde mi portátil a la ECU (normalmente llamada ETK en el sector de la automoción) de un coche de pruebas. Lógicamente, esta ECU era “abierta” (reprogramable, con conexión adicional para pruebas e instrumentación). Para reprogramarla utilizaba una aplicación suministrada por Bosch (famoso fabricante de ECU’s), y para conectarme y hacer cambios en la calibración en tiempo real, un programa desarrollado por el grupo ETAS llamado INCA (famoso gestor de calibraciones). Como anécdota para los informáticos os contaré que cuando yo estaba en Nissan, INCA solo funcionaba con el sistema operativo Windows XP, y con todas sus vulnerabilidades…. Estos industriales y sus equipos expuestos a ciberataques… ;)

¿Pero qué es eso de la calibración? ¿Y por qué os cuento todo esto? Os hago una pequeña síntesis para que os hagáis una idea:

Cuando tú reprogramas una ECU tienes dos archivos a introducir: el software y la calibración. El software comprende la lógica de control y todas las estrategias destinadas a controlar el funcionamiento del coche. Cada ECU y versión de motor tiene su versión de software desarrollada por los ingenieros informáticos de la correspondiente firma automovilística. La calibración es la base de datos (constantes, mapas de motor, etc.) de la cual se sirve el software para ejecutar su acción de control de una forma sensata y eficiente. Estos datos son ajustables, es decir, su valor se puede modificar (son calibrables). De esta forma, los ingenieros de calibración pueden cargar diferentes calibraciones, con sus correspondientes cambios personalizados, en el mismo software.

Luego la ECU es tan solo una caja negra que recibe variables medidas por sensores (inputs), las procesa de forma eficiente gracias a una lógica de control y variables calibrables y a continuación genera una serie de variables de salida (outputs) que serán enviadas a los actuadores para que provoquen una respuesta que coincida con la demanda del usuario (conductor del coche).

Cuando hacía los ensayos, me conectaba con el programa INCA y podía hacer lo que quisiera: cortar la inyección, limitar la velocidad según el par motor y las revoluciones, modificar parámetros de funcionamiento del turbocompresor, el catalizador, la trampa de partículas, etc. Evidentemente los ingenieros hacíamos pruebas con las variables de la lógica de control que íbamos a modificar previamente estudiadas; se trataba de ensayos coherentes con los que poder investigar, hacer grabaciones y analizar el comportamiento del vehículo después de cada cambio. Pero, ¿qué pasaría si un hacker de algún modo cualquiera fuera capaz de acceder al “cerebro” con la finalidad de hacer cambios incoherentes en la calibración? Después de lo que os he contado podéis imaginar que las consecuencias serían nefastas.

Las ECUs se comunican mediante paquetes CAN. La comunicación a través de CAN es “broadcast” y, aunque existen algunas redes segmentadas, cada ECU decide si un paquete de datos está destinado a él o no. No existe ningún tipo de autenticación ni identificación de la fuente de un paquete. En caso de tener acceso a los buses de comunicación CAN, es posible capturar el tráfico entre las distintas ECUs. No sólo eso, también es posible inyectar paquetes que interactúen con los distintas ECUs del vehículo. Esto puede proporcionar un control total, incluyendo el sistema de frenos, motor, luces y cualquier otra funcionalidad que incorpore el vehículo. Durante los últimos años, han surgido diversos estudios que demuestran que es posible interferir con todos estos sistemas del vehículo, como podrían ser los frenos. ¡Qué desastre, nos quedamos sin frenos! ¡Frenos rotos, coches locos!

Por ello, un punto clave se centra en si es posible o no obtener acceso a dicha comunicación. ¿Podrían ser la conexión a Internet o mediante smartphone (bluetooth) posibles vías de acceso a dicha comunicación….? Eso es lo que vamos a ver en esta breve serie de dos artículos.

Además de todas estas funcionalidades que implementan los coches, existen también las relacionadas con la comunicación y servicios derivados de Internet que se incluyen en la nueva generación de coches “conectados”. No me refiero a la asistencia al aparcamiento, sino de acceso a redes sociales, correo electrónico, conectividad con el smartphone, cálculo de rutas, aplicaciones que se ejecutan en el coche, etc.

La conexión coche-Internet se puede realizar de dos modos:

• A partir de la tarjeta SIM del vehículo. Esta conexión es la que se utiliza en los servicios/aplicaciones: In Car Browser Apps por ejemplo.

• A partir del smartphone del usuario (vía bluetooth). Modalidad utilizada en los servicios In Car Smarphones Apps.

Audi ha sido pionero en este campo cuando en 2005 puso en marcha proyectos conjuntos con Google y Nvidia para desarrollar software y hardware, y en 2009 la marca de los cuatro aros ofreció por primera vez conexión a Internet en un automóvil. El sistema Audi Connect se ofrece en casi todos los modelos de la marca, incluido el A1. Los ocupantes de cualquier vehículo Audi equipado con este sistema pueden navegar y acceder al correo electrónico en todo momento, así como utilizar un gran número de servicios online de Google mediante el acceso a Internet.

La conexión se realiza a través de una tarjeta SIM vinculada a una línea de datos, aunque como alternativa se puede acoplar el móvil al equipo del coche vía Bluetooth. Otra función es el punto de acceso inalámbrico WLAN, con la que el teléfono del automóvil permite que el acompañante y los ocupantes de las plazas traseras puedan conectar vía Wi-Fi y de forma simultánea hasta ocho dispositivos diferentes (ordenadores portátiles, iPads, etc) para navegar por Internet, consultar el correo o incluso jugar online, independientemente de sus sistemas operativos. Todo el control de este teléfono se realiza a través del mando del MMI Navigation Plus de Audi, utilizando el volante multifunción, mediante la pantalla táctil con reconocimiento de escritura que se ofrece en algunos modelos, o incluso mediante control por voz.

La inclusión de estas tecnologías implica una serie de nuevos riesgos a los que el usuario no tenía que hacer frente… hasta ahora. Pero eso lo veremos en el siguiente artículo de la serie.

Hay pocos temas capaces de generar tanto debate dentro del campo de la seguridad informática como el de las certificaciones: son geniales, no sirven para nada, generalistas, de producto, con cebolla, sin cebolla… Defensores y detractores esgrimen argumentos bastante válidos a la hora de defender y cuestionar el valor real de las certificaciones de seguridad.

Imaginemos por un momento que tenemos un casco que nos permite, con tan solo pulsar un botón, convertirnos en un fanboy de las certificaciones o en su enemigo más acérrimo. Casco en mano (bueno, en cabeza, la seguridad es lo primero) vamos a repasar algunos argumentos a favor o en contra de las certificaciones de seguridad.

Pros

• Sirven para conseguir entrevistas: Uno de los problemas principales que tiene el personal de RR.HH. para seleccionar candidatos para un perfil es saber quién puede ser un buen candidato (la contratación en seguridad informática tiene su tela, y merece un artículo por sí sola). Las certificaciones de seguridad les vienen como anillo al dedo ya que les proveen de las buzzwords necesarias para poder discriminar candidatos. El tener o no tener las certificaciones correctas puede indicar en muchos casos el paso a la siguiente fase de un proceso de selección.
• Son personales: Se van contigo debajo del brazo cuando cambias de trabajo y son (mantenimiento mediante, del que ya hablaremos) para siempre. A las empresas les suelen gustar las certificaciones, por lo que es un buen argumento a la hora de negociar salarios.
• Demuestran motivación: Se puede entrar a trabajar en seguridad informática desde muchos perfiles (desarrollador, administrador de sistemas, de redes, etc…) De la misma forma, se puede entrar porque de verdad te apasiona la seguridad o simplemente porque es un campo que ahora está de moda y por ende hay mucho trabajo y/o está bien pagado. El que alguien tenga certificaciones de seguridad demuestra en cierta medida que “va en serio” con la seguridad, y que quiere desarrollar su carrera en esta área. La dedicación y la motivación en nuestro campo cuentan. Y mucho.
• Le gustan a tu empresa: Muchos concursos públicos tienen un apartado puntuable relativo a la calidad del personal que va a ejecutar el proyecto. Dado que el 95% del personal van a ser ingenieros y/o grados, las únicas formas de cuantificar la calidad del personal son los años de experiencia… y las certificaciones de seguridad que poseen. Además, a nivel de marketing que una empresa pueda decir que tiene N-cientas certificaciones le sirve para sacar pecho, lo cual tampoco les viene mal.
• Se aprenden cosas nuevas: Nadie sale de la carrera convertido en un experto en seguridad informática. Por mucho que hagamos cursos y nos formemos, siempre hay aspectos o temas particulares que se nos pueden escapar. El preparar una certificación de seguridad (casi siempre relacionada con un campo específico) nos fuerza a profundizar en ese campo, afianzando conceptos y mejorando nuestro conocimiento del tema.
• Se aprende jerga nueva: En muchas certificaciones se estudian conceptos que no son puramente técnicos, pero que ayudan a comprender el negocio de la seguridad. Saber qué entienden los auditores como “apetito del riesgo”, o los gestores de servicios TI como “gestión del cambio” amplia nuestra visión del negocio y ayuda a comprenderlo mejor.
• Superación personal: El pensar que se controla un tema está muy bien. El pasar una prueba objetiva que demuestre que lo dominas está mucho mejor.

Contras

• Su valor real es discutible: Se puede aducir que obtener una certificación es similar a estudiarse un libro y pasar un examen, no significando necesariamente que se posea la profundidad de conocimientos implícita en la certificación.
• El coste es elevado: La mayoría de las certificaciones tienen un coste elevado. Sentarse en el examen suele empezar en 500€, a lo que hay que sumar el material de estudio de la certificación y los (a veces opcionales) cursos de preparación a la certificación.
• Los exámenes no son adecuados: Aunque hay excepciones, prácticamente todos los exámenes de las certificaciones están compuestos de preguntas con respuesta múltiple (con respuestas discutibles en muchos casos), quedando fuera los ejercicios y los casos prácticos que pueden demostrar realmente el conocimiento del examinado. Y pobre de ti si eliges hacer el examen en castellano, ya que traducir una pregunta ya per se complicada en inglés y hacer que mantenga el espíritu de la misma es a veces imposible.
• Mantener la certificación es un infierno: Una vez conseguida la certificación, en muchos casos es necesario mantenerla mediante los famosos CPE (Continuing Professional Education), actividades formativas que deben ser realizadas para mantenerse al día en el ámbito de la certificación. Los CPE a priori parecen una buena idea ya que obligan al certificado a reciclarse de forma periódica, pero el trámite burocrático en algunos casos es, por así decirlo, costoso.
• Si no tienes certificaciones, no eres bueno: Se puede producir un efecto de lógica retorcida que induzca a pensar que “dado que si tienes certificaciones eres bueno, si no las tienes eres malo”, cuando hay profesionales de altísimo nivel que no poseen ni una sola certificación.

Si estás pensando en certificarte, aquí tienes unos cuantos consejos:

• Decide si necesitas certificarte: Una certificación tiene sus beneficios, pero tiene su coste (tanto en dinero como en tiempo de preparación). Infórmate acerca de la certificación y sobre todo cómo puede ayudar a mejorar tus conocimientos y tu perfil profesional.
• Entérate de lo demandada que está en España y en el extranjero. Una buena técnica es buscar en Infojobs o Tecnoempleo las ofertas que la piden, para hacerte una idea de cuán solicitada está.
• Lee bien toda la letra pequeña, sobre todo en lo referente a los requisitos de acceso (en algunos casos hay que tener experiencia previa certificable), si es obligatorio hacer un curso preparatorio y lo que hay que hacer para mantenerla. Tampoco está de menos saber cuándo y dónde se pueden hacer los exámenes (algunas certificaciones tienen fechas fijas y solo se pueden hacer en Madrid/Barcelona, mientras que otras se pueden hacer todo el año en centros autorizados en casi todas las comunidades).
• Plantéate si estás preparado: Una certificación al fin y al cabo es un examen, por lo que hay que llevar la materia bien preparada. Y dado que sentarse al examen cuesta un dinero, evalúa si tienes los conocimientos necesarios para superarla a la primera.
• Intenta que la pague tu empresa: Al final la certificación viene bien a tu empresa, y cuenta como formación, por lo que intenta convencer a tu jefe para que corra a cuenta de la empresa (en algunas consultoras curiosamente te pagan pero casi obligan a que te saques una certificación al año hasta tener las X decididas como óptimas). Otra opción es que te dejen tiempo para prepararla dentro de tu jornada laboral (en alguna empresa se montan hasta grupos de estudio).
• Hazte con un buen material de estudio: Muchas certificaciones tienen guías oficiales, o libros que aglutinan el temario y lo explican de forma coherente y completa. Entérate de qué material de estudio es el mejor para cada certificación.
• Cuidado con los dumps: Dado que casi todos los exámenes son de preguntas con respuesta múltiple, y que en muchos casos se reutilizan preguntas, es posible encontrar en Internet dumps (recopilaciones de preguntas de otros años y/o de pruebas). Algunos sitios de Internet aseguran tener “todas las preguntas” del año, para que solo tengas que estudiarte las respuestas y pasar así el examen (sic). Mucho cuidado con estos dumps, porque las preguntas cambian cada año y en muchos casos las respuestas son erróneas.
• Planifícate: Una certificación acaba siendo como una carrera. Decide cuánto entrenamiento necesitas, y hazle el hueco necesario en tu día a día. Meterte entre pecho y espalda 20 temas en un fin de semana no es la mejor forma de aprobar.
• Si apruebas, haz el papeleo cuanto antes: Si superas el examen, el trabajo no ha terminado. Toca hacer todo el papeleo administrativo (acreditar años de experiencia, adjuntar fotocopias de títulos, recoger firmas de jefes, etc…). Cuanto antes lo hagas antes te lo quitarás de encima, aparte de que te evitarás posibles problemas (como tener que pedirle una firma a un antiguo jefe, algo que aquí puede costar lo suyo).

En mi opinión personal, las certificaciones de seguridad aportan valor… pero podrían aportar más. Exámenes con un contenido práctico más elevado (aunque hay algunas que sí lo tienen, son la excepción) y con un temario moderno y actualizado año a año probablemente incrementarían su dificultad (tanto de hacerlo como de corregirlo), pero haría que fueran mejor valoradas por la comunidad.

Y por supuesto, es necesaria la aplicación general del sentido común (también conocido por ser el menos común de los sentidos) y una buena dosis de humildad. El tener una firma de correo con dos líneas de cargos más otra línea de certificaciones no te convierte automáticamente en el rey del mambo. Y si te presentas en según qué ambientes como “Pepe Palotes, Cert1, Cert2, Cert3” estás cogiendo boletos para hacer el ridículo.

De la misma forma, aunque seas un “L33T Haxxor” que reniegas de las certificaciones cual Linus Torvalds de Microsoft, tampoco es de recibo llamar “corporate bitch” a alguien que sí que las tenga.

Tanto si estamos a favor como en contra de las certificaciones de seguridad, no se puede negar que son un aspecto a tener en cuenta en la realidad actual de la seguridad informática. Lo mejor que podemos hacer es… convivir con ella.

[Full disclosure: El autor posee las certificaciones CISA, CISM, CISSP, CHFI, CCSK e ITILv3f].

Dicen que la buena educación está sobrevalorada, que no sirve para nada, que al final la gente no te hace más caso por ser más educado, pero yo creo que sí que vale para mucho.

Por ejemplo, si yo fuera un hacker (en el peor sentido del término) con muy malas intenciones, que no lo soy, optaría por la opción educada. Aunque en este punto nadie entiende a que me refiero, déjenme que me explique.

Yo optaría por acabar con la programación compleja de malware, las cadenas de correos electrónicos con adjuntos infectados para entrar en los ordenadores de los usuarios, explotar las vulnerabilidades de los dispositivos, etc. En general todo eso lleva mucho trabajo detrás y no siempre surte efecto. Hay un camino mucho más sencillo y educado. Como les decía, creo que las cosas pedidas con educación siempre van mejor. Hasta les hablo de ustedes, ¿se han fijado?

Si yo fuera mala malísima, que no lo soy, programaría una aplicación un tanto idiota y la subiría al Play Store, por ejemplo. Una aplicación que apenas sirviera para hacer algo de luz en la oscuridad, llevar la lista de la compra, hacer capturas de pantalla, etc. Seguro que las opciones que se les ocurren son muchas.

Cuando alguien se instalara mi aplicación le pediría, eso sí, muy educadamente (ya que le dejo utilizar mi aplicación de manera gratuita), que me dé acceso a sus contactos, a sus mensajes, a su ubicación, a su cámara de fotos, a su altavoz. Total, es un precio muy pequeño a pagar comparado con todo lo que yo le ofrezco, ¿no?

Probablemente no quieran apostar a que la gente después de leer detenidamente mis peticiones (como hacemos todos), pulsaría “Aceptar”. Total tampoco sería para tanto. Incluso aunque sea sólo para ver si la aplicación les “encaja”. Al final yo sólo tendría acceso a todos sus contactos, a poder sacar fotos desde su terminal y copiarlas, a activar su cámara de fotos cuando quisiera, a activar su altavoz. ¿Qué problema hay en que un tercero que no conocemos de nada tenga acceso a toda esa información?

No hemos engañando a nadie. Hemos pedido permiso. Muy educadamente. Ante todo la educación.

Pero como ya he dicho al principio yo no soy una mala persona y no creo que nadie haya tenido estas ideas… ¿o sí?

Quizá sí, pero estamos a salvo porque aunque esto tan rebuscado se le llegara a ocurrir a alguien, todo el mundo lee los permisos de las aplicaciones que instala y si le parecen excesivos para las funcionalidades que ofrece, buscan una aplicación alternativa que no comprometa sus datos, ¿verdad? NO. MENTIRA.

En general, los usuarios no prestamos suficiente atención a las aplicaciones que instalamos en nuestros dispositivos móviles, ni siquiera a aquellas que de manera muy evidente nos piden más permisos de los que necesitan para desarrollar las funcionalidades que ofrecen. Veamos dos ejemplos:

Tampoco hay que irse al peor caso. Puede que estas aplicaciones estén programadas de esta forma porque al desarrollador le interesa obtener nuestros datos para enviarnos spam o realizar análisis estadísticos. También es posible que simplemente el desarrollador no sepa hacerlo mejor, o haya incluido esos permisos por si acaso la aplicación los requiere. O sí, si vamos al peor caso, es posible que haya malas intenciones detrás. En cualquier caso, uno sólo de esos motivos me hace pensar que no quiero su aplicación.

Aunque también les digo que la seguridad total no existe y que muchas veces nosotros mismos nos metemos en la boca del lobo aunque el lobo no sea totalmente un lobo. No sé si me entienden. ¿Han comprobado los permisos que les pide la aplicación que seguramente más utilizan en su smartphone?

Recientemente se ha publicado una vulnerabilidad (CVE-2015-2865) que afecta a varios modelos de móviles Samsung Galaxy, y que permite la ejecución remota de código como usuario system siempre que sea posible montar un ataque MitM entre el terminal y los servidores de Samsung (normalmente utilizando técnicas como ARP cache poisoning o similares sobre redes wifi de hoteles, restaurantes, etc. a las que estén conectados el atacante y la víctima).

• Remote Code Execution as System User on Samsung Phones
• Samsung Keyboard Security Risk Disclosed: Over 600M+ Devices Worldwide Impacted
• Prueba de concepto

Estos terminales vienen preinstalados con el teclado virtual Swift, de Samsung. Cuando el usuario instala un language pack adicional para este teclado, o cuando se actualiza uno de los existentes, en primer lugar la aplicación descarga el catálogo de packs en formato JSON desde la URL correspondiente:

http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/languagePacks.json

Por ejemplo, en el caso del language pack para portugués, el trozo relevante del fichero sería similar al siguiente:

{"name":"Português (PT)","language":"pt","country":"PT","sha1":"80d5d77e9155a386b2af2c34f5054eb1643ca08d",
 "version":0,"archive":"http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/pt_PT.zip",
 "live":{"sha1":"2ffe82ac539697e898d0d6f9a021e81b1801fe90","version":1187,
 "archive":"http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/ll_pt_PT.zip"}}

A continuación, el terminal descarga el language pack en sí, contenido en el fichero ZIP indicado en el catálogo:

http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/pt_PT.zip

La vulnerabilidad queda por lo tanto clara: aunque la aplicación sí que verifica que el SHA1 del fichero descargado coincida con el del catálogo, la primera descarga se lleva a cabo por HTTP, y no por HTTPS, por lo que montando un ataque MitM es posible falsificar tanto el SHA1 como el fichero ZIP. Si se introducen rutas relativas en los ficheros incluidos en este ZIP malicioso (path traversal), como el teclado virtual se ejecuta como usuario system es posible (salvando algunas dificultades técnicas detalladas en el informe de la vulnerabilidad) instalar ficheros en rutas clave del dispositivo que permitirán la ejecución de código arbitrario, posibilitando la contaminación del terminal.

Cabe destacar que el teclado virtual Swift no es desinstalable en las condiciones habituales, y que la vulnerabilidad es explotable aunque este teclado no sea el utilizado por defecto, por lo que de momento no se conoce ningún workaround, y es de esperar que la vulnerabilidad se convierta rápidamente en “un clásico” para pentesters y atacantes en general; el módulo para Metasploit debe estar (a fecha del presente) ya en camino, y durante los próximos días se irán conociendo detalles sobre el impacto de la vulnerabilidad en el parque de móviles Samsung español.

Más allá de aprovechar la vulnerabilidad para atacar a nuestros clientes en futuros pentests, sobretodo cuando detectemos móviles Samsung sobre la mesa durante la reunión de arranque de proyecto (en ese momento ya empezaba la fase de reconocimiento, ¿no? :) Estas ocasiones siempre son buenas para tratar de atacar también a los propios atacantes, e intentar aprender de ellos implementando un sencillo honeyclient :)

En este caso, en principio bastaría con tener presente el SHA1 “bueno” actual, descargar el catálogo desde el honeyclient, y comparar los valores:

#!/usr/bin/env python

import urllib2
import json
import time
import re

GOOD_SHA1 = "80d5d77e9155a386b2af2c34f5054eb1643ca08d"
CATALOG_URL = "http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/languagePacks.json"

opener = urllib2.build_opener()
opener.addheaders = [(
    "User-agent",
    # somos un androide :)
    # modificar teniendo en cuenta modelos utilizados en ES
    "Dalvik/1.6.0 (Linux; U; Android 4.4.2; SM-G900T Build/KOT49H)"
)]

catalog = json.loads(opener.open(CATALOG_URL).read())
sha1, zip_url = [(d["sha1"], d["archive"])
                 for d in catalog if d["country"] == "PT"][0]

if sha1 == GOOD_SHA1:
    print "Limpio"
else:
    if not re.match(r"http://skslm\.swiftkey\.net/samsung/downloads/v1\.3-USA/[a-zA-Z_]+?\.zip", zip_url):
        print "WTF!? %s" % zip_url
        exit(1)
    filename = "%s.zip" % int(time.time())
    print "Sucio: malware -> %s" % filename
    req = opener.open(zip_url)
    CHUNK = 16 * 1024
    with open(filename, "wb") as f:
        while True:
            chunk = req.read(CHUNK)
            if not chunk:
                break
            f.write(chunk)

Si el SHA1 “bueno” no coincide con el que hemos obtenido descargando el catálogo a través de la red a la que estamos conectados, significa que hay alguien más on the air, cazando :) y descargaremos el ZIP que nos presenta, que contendrá el malware con el que nos está intentando infectar; con suerte y paciencia, podríamos conseguir un malware diferente al típico meterpreter o cualquier otro artefacto ya trillado, y pasaríamos a analizarlo debidamente en un entorno de laboratorio.

Por supuesto, el SHA1 “bueno” irá cambiando, y sería deseable automatizar su actualización desde una fuente fiable. Además, aunque siempre podemos desplegar el script sobre una red wifi aparentemente vulnerable, dispuesta con un fake AP (en forma de honeypot), lo ideal sería podernos llevar el honeyclient “puesto”, sin necesidad de cargar con el portátil con la Kali, para probarlo cómodamente (y tratar de cazar) cuando visitemos nuevas redes wifi poco confiables :) Podríamos desarrollar el honeyclient como una app con el SDK de Java para Android, generando el correspondiente APK, pero para una prueba de concepto rápida podemos reutilizar el anterior código Python sin apenas modificaciones con ayuda de QPython, un port del intérprete de Python (más algunas librerías extra) en forma de app directamente instalable desde Google Play:

La aplicación nos permite abrir una consola con el intérprete de Python, y también dispone de un editor, con el que podemos abrir, modificar o ejecutar nuestros propios scripts.

En el caso del intérprete, vemos que podemos importar los módulos habituales de la librería estándar:

Copiando el anterior script en Python a la tarjeta SD de nuestro terminal, podemos modificarlo con el editor de QPython. Tan sólo es necesario cambiar la ruta donde guardaremos el fichero ZIP con el malware en caso de que hayamos detectado un ataque (por ejemplo, /storage/sdcard1/ para la tarjeta SD).

Y ya podemos ejecutar el honeyclient desde nuestro terminal. Ésta sería la salida en caso de que no se detecte un ataque:

Y ésta en caso de ataque:

Efectivamente, va guardando los ficheros con el malware en la tarjeta SD:

Además, utilizando la API de Android en nuestro script, podríamos programar la comprobación cuando detectemos conexiones a redes wifi no conocidas hasta el momento, ejecutar el honeyclient como un servicio en segundo plano, y todo lo que se nos pueda ocurrir… Lo interesante, independientemente de que utilicemos el SDK para Java, Python o cualquier otra alternativa, es que podemos añadir más vulnerabilidades (de Android o no) y comprobaciones a nuestro honeyclient “portátil”, lo que nos permitirá acumular información y artefactos a nuestro paso por diferentes redes.

¿Han oído hablar de la nueva normativa europea sobre la protección de datos de carácter personal? Seguramente sí, pero probablemente tengan una imagen difusa sobre el estado de la misma. Al menos, esa es la impresión que yo tengo como interesado en la materia. En cierto modo es como si estuviéramos recibiendo información con cuentagotas: pequeños avances, breves fragmentos del tráiler de una superproducción Hollywodiense Europea que marcará un antes y un después. ¿Creéis que será para tanto?

Dado este escenario, hemos considerado oportuno dedicar el presente artículo a la nueva normativa europea, comentando los cambios más significativos, con la intención de establecer un punto de situación, que ayude a nuestros lectores poner en contexto las noticias que lean sobre el tema y permita aclarar algunas cuestiones al respecto.

¿Es necesaria una nueva normativa para la protección de datos de carácter personal?

Lo primero que habría que preguntarse es precisamente si es necesaria una nueva normativa en este campo; ¿acaso la existente no es válida? En mi opinión la normativa existente ha contribuido muy favorablemente a la protección de nuestra información personal, pero aún así, es necesaria una nueva normativa o, al menos, una revisión profunda de la existente.

Tal y como se indica en la web de la Agencia Española de Protección de Datos la normativa está en proceso de revisión y actualización para tener en cuenta las consecuencias de los desarrollos tecnológicos, la globalización de los intercambios de datos y, en el caso de la Directiva, las modificaciones legales e institucionales que supuso la entrada en vigor en 2009 del Tratado de Lisboa.

A título anecdótico, la LOPD contiene un artículo en el que requiere que las medidas de seguridad se actualicen “habida cuenta del estado de la tecnología”. Es precisamente esa evolución en la tecnología la que precede, en este caso, la actualización no sólo de las medidas de seguridad sino también de la propia normativa.

Desde mi punto de vista y, a grandes rasgos, existen una serie de líneas de mejora claras sobre las que habría que trabajar:

• Adaptación a las nuevas estructuras empresariales y modelos de negocio actuales. La normativa actual se lleva mal con los grupos empresariales, con las subcontrataciones, con las empresas nacionales cuya empresa matriz está en el extranjero, con las empresas nacionales cuyas delegaciones están en otros países, etc.
• Forma y estructura de la normativa. Quizás sea deformación profesional pero supongo que quienes estén familiarizados con las normas ISO y/o cualquier otro grupo de estándares, coincidirán conmigo cuando digo que la forma y la estructura de la normativa existente es compleja y no está pensada para que su aplicación sea intuitiva.
• Impunidad de los “grandes” y sanciones. Si bien es cierto que el rango de sanciones actual es amplio, parece desproporcionado cuando se tiene que aplicar a la pequeña empresa e irrelevante cuando se aplica a grandes multinacionales.
• Nuevas tecnologías. Por supuesto, la evolución en las tecnologías de la información es uno de los aspectos clave que han propiciado la revisión de la normativa actual. La aparición de servicios cloud, nuevas tendencias (BYOD), etc.

Al respecto cabe señalar que en la nueva normativa sí se están considerando algunos de los puntos indicados y otros que, tal y como veremos a continuación, suponen mejoras sobre lo existente, aunque quizás no muy significativas.

Aspectos reseñables sobre la nueva normativa:

• Derechos ARCO “potenciados”. Actualmente ya existían cláusulas que recogen los requisitos relativos al ejercicio de los derechos ARCO (Acceso, Rectificación, Cancelación y Oposición). Sin embargo, se han revisado para destacar el llamado “Derecho al olvido”. Es decir, establecer vías para que un usuario pueda eliminar su huella en Internet.
• Mayor control sobre la información que proporcionas. En este sentido, cabe señalar que una reciente encuesta europea refleja que el 31% considera que no se tiene control alguno sobre la información que se deposita en Internet. Se han establecido mecanismos para que el usuario final tenga mayor “control” sobre su información personal.
• Consentimiento expreso. Siempre que se requiera el consentimiento para el procesamiento de datos, tendrá que ser dado de manera explícita, en lugar de ser asumida.
• Notificación de los incidentes de seguridad relacionados con los datos de carácter personal. Empresas y organizaciones tendrán que notificar las violaciones de datos y sin demora injustificada, cuando sea posible dentro de 24 horas.
• Normativa unificada. Un conjunto único de normas sobre protección de datos, válido en toda la UE.
• Las personas tendrán derecho a someter todos los casos a su autoridad de protección de datos nacional, incluso cuando sus datos personales son procesados fuera de su país de origen. Ejemplo, poder denunciar ante la AEPD un caso de abuso en el extranjero.
• Alcance de aplicación. Las normas de la UE se aplicarán a las empresas no establecidas en la UE, si ofrecen bienes o servicios en la UE o “monitorizan” el comportamiento de los ciudadanos.
• Sanciones. Revisión del sistema y cuantía de las sanciones. Actualización que permitirá ejercer mayor presión sobre las grandes multinacionales.
• Menos trámites para regular el tratamiento de datos. Se eliminarán las cargas administrativas innecesarias, tales como los requisitos de notificación para las empresas de procesamiento de datos personales.

Parece ser que de esto se deduce que no será necesario inscribir ficheros en las agencias de protección de datos. ¿Significa esto que no volveremos a usar los ficheros NOTA? Quien los haya “sufrido” sabrá a que me refiero. ;)

Desde mi punto de vista, la propuesta de nueva normativa contiene modificaciones sensatas que previsiblemente traerán una mejora en la seguridad de nuestros datos personales. Ahora bien, queda pendiente ver la forma final que adoptará la normativa y su posterior aplicación para valorar si es un “taquillazo”. ¿Qué opinan ustedes, merecerá la pena?

Próximamente en los mejores cines (del territorio europeo).

Referencias y enlaces de interés:

• http://ec.europa.eu/justice/data-protection/index_es.htm
• http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm
• http://www.europarl.europa.eu/sides/getDoc.do?type=REPORT&reference=A7-2013-0402&language=ES#title1
• http://www.agpd.es/portalwebAGPD/internacional/Europa/index-ides-idphp.php
• http://www.eleconomista.es/tecnologia/noticias/6793000/06/15/Los-28-aprueban-hoy-la-norma-que-reconoce-el-derecho-al-olvido-en-Internet-.html
• http://www.eleconomista.es/tecnologia-internet/noticias/6709672/05/15/Google-ha-borrado-el-40-de-las-solicitudes-por-el-derecho-al-olvido.html

La entrada Nueva LOPD. ¿Será un peliculón? aparece primero en Security Art Work.

Desde el lanzamiento de los 2 sistemas operativos móviles por excelencia, iOS y Android, el número de personas que piensan que iOS es más seguro que Android se ha ido incrementando de manera muy significativa.

Es cierto que existen diversos factores que influyen y determinan directa e indirectamente esta creencia, como podrían ser:

• Cuota de mercado.
• Malware dirigido.
• Posibilidad de instalar aplicaciones desde fuentes no oficiales.
• Fragmentación de versiones instaladas en los dispositivos.
• Dispositivo (hardware) sobre el que corre el SO.
• Proceso de revisión de aplicaciones enviadas a los canales oficiales.
• …

Sin embargo, cuando hablamos de seguridad, la gente que no está relacionada con el sector TI no se basa en este tipo de factores, sino en algo mucho más básico: los iPhone funcionan bien, son bonitos, son caros, son rápidos, por tanto, son mucho más seguros.

Este artículo no pretende ser una comparativa técnica entre ambos sistemas operativos (las hay para todos los gustos en la red), sino algo que viene bien recordar de vez en cuando a nuestros amigos o amigas que acaban de estrenar su nuevo iPhone, ya que los que trabajamos en el sector TI sí que podemos argumentar a favor y en contra de esta absurda creencia.

Analizando los factores comentados anteriormente, y dependiendo del punto de vista, se puede pensar que la balanza se inclina hacia iOS. Lo cierto es que, como decía el gran Iván Ferreiro, “El equilibrio es imposible”, y la balanza se inclina hacia un lado y hacia otro según el momento.

Si nos centramos, por ejemplo, en el número de vulnerabilidades encontradas en ambos sistemas operativos, observamos que el número de vulnerabilidades encontradas en iOS supera al número de vulnerabilidades encontradas en Android. De acuerdo al informe publicado por Symantec “Internet Security Threat Report 2015”, de las 168 vulnerabilidades detectadas en sistemas operativos móviles durante 2014, el 84% de las mismas corresponden a iOS, mientras que Android se queda en un 11%. El resto de la tarta se la reparten entre BlackBerry OS (4%) y Windows Phone (1%).

No obstante, si observamos el nivel de amenaza de los SO comentados, vemos como Android se corona como el gran objetivo de los desarrolladores de malware. Posiblemente, este dato está estrechamente relacionado con la cuota de mercado que mantienen ambos SO. Según IDC, durante el último trimestre de 2014, Android obtuvo un 76,7%, mientras que iOS, que sigue escalando posiciones, obtuvo un 19,7%.

Por tanto, pese a que la tendencia del mercado del malware está actualmente dirigida hacia Android por razones obvias, no hay que olvidar que esta tendencia puede cambiar en cualquier momento. Además, según los datos comentados, un ataque dirigido contra dispositivos iOS es tan factible o más como uno realizado contra dispositivos Android.

Por poner algún ejemplo, estas son 2 vulnerabilidades descubiertas recientemente para iOS:

La primera, conocida como “No-iOS-Zone” es una vulnerabilidad de DoS presentada en la RSA conference 2015 [PDF], que permite realizar denegación de servicio vía WiFi a todos los terminales con iOS 8 instalado, dejando el iPhone inutilizable.

La segunda, relacionada con una vulnerabilidad en una versión concreta de la librería AFNetworking, afecta a cientos de aplicaciones, haciéndolas vulnerables a ataques del tipo Man in the Middle. Pese que la vulnerabilidad se parcheó al poco tiempo, a día de hoy siguen existiendo muchas aplicaciones en la App Store que no se han actualizado y por tanto, siguen siendo vulnerables.

En definitiva, conviene recordar que un dispositivo no es más seguro por ser más bonito, sino que la seguridad depende, en gran medida, de uno mismo.

Sent from my iPhone.

La entrada Por qué tu iPhone no es tan seguro como parece aparece primero en Security Art Work.