Cita

"Those who are willing to pay a penny of security for a penny of usability will eventually have neither"

25 septiembre 2016

Lista de referencias y recursos forenses

Además de lo comentado en anteriores artículos, dejo aquí una lista de artículos y referencias a recursos forenses que me han parecido interesantes para todos los que nos iniciamos en esta materia. 

Enjoy it!


Forensic Discovery (libro):
http://www.porcupine.org/forensics/forensic-discovery/

SANS:
http://computer-forensics.sans.org/community/whitepapers/http://computer-forensics.sans.org/blog/
Enlace a SIFT: https://digital-forensics.sans.org/community/downloads

DFRWS:
http://www.dfrws.org/archive/papers

Wiki:
http://www.forensicswiki.org 


En Dragonjar:
http://www.dragonjar.org/category/informatica-forense 

En Flu-Project:
http://www.flu-project.com/2013/12/recopilacion-de-la-cadena-herramientas.html
http://www.flu-project.com/search/label/autopsy


Análisis forense en SecurityArtWork:
http://www.securityartwork.es/?s=an%C3%A1lisis+forense

FastIR Collector:
http://www.securityartwork.es/2016/04/20/fastir-collector/

Análisis de evidencias volátiles:
http://www.securityartwork.es/2015/10/14/adquisicion-de-evidencias-volatiles/


Para volatility:
http://www.securityartwork.es/2014/06/03/volwrapper-envolvente-para-volatility/
http://marcoramilli.blogspot.com.es/2015/05/volatility-on-darkcomet.html?m=1
http://volatility-labs.blogspot.com.es/2014/01/truecrypt-master-key-extraction-and.html
http://www.sahw.com/wp/archivos/2011/11/02/analisis-avanzado-de-memoria-de-sistemas-microsoft-windows-con-volatility/

Autopsy & cia:
http://www.sleuthkit.org/

MiTec Tools:
http://www.mitec.cz/index.html

Dumpit & Hibr2bin:
https://blog.comae.io/your-favorite-memory-toolkit-is-back-f97072d33d5c

Mimikatz:
https://github.com/gentilkiwi/mimikatz

Password cracking:
http://www.computersecuritystudent.com/SECURITY_TOOLS/PASSWORD_CRACKING/lesson2/
http://bernardodamele.blogspot.com.es/2011/12/dump-windows-password-hashes.html 

unhide:
http://unhide-forensics.info/

Repositorio de herramientas:
http://www.sniferl4bs.com/2016/09/repositorio-de-herramientas-forenses.html 

23 julio 2016

Administración Linux


Aquí dejo una serie de comandos y programas en Linux (bastante básicos) para tenerlos siempre a mano. Y, de paso, los publico por si pueden servirle a los que están empezando:

Linux básico:

Información sobre el s.o.:
$ uname -a
$ cat /proc/version
$ lsb_release -a

Información sobre las particiones:
$ df -h
$ sudo fdisk -l
$ cat /proc/partitions
$ mount

Una partición se ha llenado porque hay un directorio que crece mucho: añadir otro disco; asignarle espacio y formatearlo con gparted; después seguir las indicaciones del siguiente blog
https://lavidaestux.wordpress.com/2015/03/28/mover-el-home-a-otra-particion-o-disco/


Uso de la memoria del sistema:
$ free -h
$ cat /proc/meminfo

Información sobre el DNS configurado:
$ cat /etc/resolv.conf

Puerta de acceso predeterminada:
$ sudo route

Dirección IP:
$ sudo ifconfig

Añadir un usuario:
$ sudo useradd -g grupo -d /home/usuario -m -s /bin/bash -e 2017-01-01 usuario
Ponerle una contraseña:
$ passwd usuario

La configuración de arranque de la shell está en $HOME/.bashrc
Podemos cambiar los permisos base de los ficheros, añadiendo una linea umask

Cerrar permanentemente un servicio:
$ update-rc.d -f servicio remove
$ /etc/init.d servicio stop

Evitar que nuestra máquina responda al ping:
# echo "/proc/sys/net/ipv4/icmp_echo_ignore_all=1" >>/etc/sysctl.conf
# sysctl -p

dhdh

Escaneo con nmap:

Verlo todo (muy ruidoso):
$ nmap -A localhost
Ver los puertos abiertos y sus servicios:
$ nmap -sV localhost

Ver los puertos en los que está escuchando:
$ nmap -sS-sU-p--v localhost

Escaneo de red para ver qué máquinas están activas:
$ nmap -sn 192.168.1.0/24

Ver qué sistema operativo:
$ nmap -O localhost

Escaneo ICMP:
$ nmap -sO localhost 


Escaneo SYN/TCP:
$ nmap -sS localhost

Escaneo TCP connect:
$ nmap -sT localhost

Escaneo UDP:
$ nmap -sU localhost


Análisis con netstat:

Ver los puertos abiertos:
$ netstat -lnput

Otro día, más. ¡Feliz verano!





 




 










26 mayo 2016

Entrevista en Xataka Seguridad



Os dejo el enlace a una entrevista que me han hecho en Xataka, junto a Yago Jesús (@yjesus) y Óliver López.

Precisamente a Yago fue a una de las primeras personas a las que conocí cuando empecé a adentrarme en este mundillo y os puedo decir que es un tío superabordable y encantado de compartir conocimiento con los demás. Además, el blog en el que colabora (Security by Default) fue uno de los primeros que empecé a leer. Lo encontré en internet, ya no recuerdo ni cómo, y un comentario de un compañero de oficina ("ah, sí, ese es un blog muy bueno") me hizo volver a la plaza. Y desde entonces es un must en mi lista (al igual que otros de los que hablo en la entrevista). 

A pesar de lo que diga el título, yo no me considero una experta, ni mucho menos. Soy más bien una "padawan". Pero estuve encantada de compartir mi experiencia con los lectores y aportar mi granito de arena. Seguro que nuestros comentarios os pueden ayudar en algo si pensais iniciaros en el apasionante mundo de la seguridad informática.

Tampoco me considero hacker, solo una persona con conocimientos informáticos que quiere hacer su trabajo bien y está encantada de aprender. Pero no porque piense que un hacker es un delincuente. La RAE sigue manteniendo esa acepción y, hasta cierto punto, lo entiendo porque refleja el uso que se da de las palabras. Y no hay más que ver los comentarios en la entrevista para ver que mucha gente todavía lo entiende así. Pero los idiomas son como seres vivos que nacen, crecen, se reproducen y mueren. El significado de las palabras va evolucionando y cada vez más gente no comparte el sinónimo hacker=delincuente. Tal vez habría que añadir un "en desuso" delante de la definición y completarlo con otra acepción nueva. Para mí, la mejor definición la dio Román en una entrevista, cuando dijo: 

"un hacker es una persona con una serie de habilidades de pensamiento lateral y de capacidad de pensamiento disruptivo. Una persona que sabe cómo salir de los protocolos estándares o de normas que podrían limitarle en distintos caminos". 

Según eso, un hacker no es ni bueno ni malo per se: depende de cómo use las citadas habilidades. Pero fijaos que la definición tiene mucha miga: es como una forma de ver las cosas y de encarar las situaciones y problemas que, no sé hasta qué punto se pueden enseñar o se llevan dentro. Ahora bien, la técnica, eso sí se enseña y se aprende si eres listo. Y en eso estoy... ¿Alguien más se anima?

Quizá os animéis después de leer la entrevista. Que la disfrutéis.

http://www.xataka.com/seguridad/como-llegar-a-ser-un-hacker-varios-expertos-en-seguridad-nos-lo-cuentan

02 mayo 2016

TOR Hidden Services



Después de haber contado en otro post cómo TOR es uno de los medios disponibles para proteger nuestra privacidad y evitar la creación pasiva de la huella digital, en éste voy a explicar (muy por encima) cómo se establece la conexión entre un cliente y un servicio en la red TOR (TOR Hidden Service):

Para que un cliente se pueda conectar con un hidden service éste tiene que anunciar su existencia en la red TOR. Para ello, el servicio elige algunos nodos al azar, construye circuitos hacia ellos y les envía su clave pública para que actúen como punto de introducción. Después crea un descriptor formado por la clave pública y un resumen de cada punto de introducción, los firma con su clave privada y lo sube a una tabla hash distribuida. El nombre del descriptor se genera automáticamente a partir de la clave pública y tendrá la extensión .onion. Éste es el nombre que tiene que conocer el cliente para poder acceder al descriptor, donde verá cuáles son los puntos de introducción al hidden service y la clave pública de éste.

El cliente se puede conectar con el hidden service mediante de un proxy que soporte SOCKS 4a, como Polipo. Lo que hace la aplicación cliente es crear un circuito con un nodo elegido al azar, al que le dice un secreto de un solo uso para que dicho nodo actúe como punto de encuentro.

Una vez hecho eso, el cliente forma un mensaje de introducción con la dirección del punto de encuentro y el secreto de un solo uso, lo cifra con la clave pública del hidden service y lo envía a uno de los puntos de introducción para que éste se lo envíe al hidden service, quien descifrará el mensaje para saber cuál es el nodo que actúa como punto de encuentro. Con esa información, el hidden service crea un circuito para llegar hasta él y envía al punto de encuentro un mensaje de encuentro con el secreto de un solo uso enviado por el cliente. Entoces, el punto de encuentro notifica al cliente que la conexión se ha establecido. A partir de ese momento, la comunicación se realizará por los circuitos que el cliente y el hidden service tienen establecidos con el punto de encuentro.

 


Pasos para configurar nuestro propiot servicio TOR (en un ordenador con debian y sucedaneos):

1) Instalar TOR:
$ apt-get install tor
$ deb http://deb.torproject.org/torproject.org wheezy main
$ deb-src http://deb.torproject.org/torproject.org wheezy main
$ gpg --keyserver keys.gnupg.net --recv 886DDD89>
$ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

(cambiar wheezy por la distro que tengamos).

2) Definir el directorio del hidden service y la dirección del servidor:
Para ello, introducir la siguientes lineas en el fichero /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8090

(En vez de la dirección del localhost, poner nuestra dirección externa; el localhost sirve para pruebas de laboratorio).

3) Arrancar TOR:
$ sudo /etc/init.d/tor restart>

Con eso, se han creado en /var/lib/tor/hidden_service el hostname y el private_key.

Para probarlo, accedemos con un navegador TOR a la dirección .onion que aparezca en el hostname.

Más información:









05 marzo 2016

Qué hemos visto en la RootedCON7

Jueves:

https://pennyofsecurity.blogspot.com.es/2016/03/que-hemos-visto-en-la-rootedcon7-jueves.html

Viernes:

https://pennyofsecurity.blogspot.co.ke/2016/03/que-hemos-visto-en-la-rootedcon7-viernes.html

Sábado:

Hemos visto a Daniel García (@cr0hn) explicándonos un concepto de nombre por él inventado (solo el nombre, el ataque ya existía): el de Broker and MQ injection. Lo demostró en directo: cómo podía interceptar las tareas del Broker e, incluso, inyectarle otras nuevas para, por ejemplo, envíar un mensaje de correo falsificado o envenenar la caché de una web. No es un problema del broker en sí, sino de cómo se configure: si se pone expuesto a internet y sin estar debidamente "securizado". Presentó una herramienta para automatizarlo todo: "enteletaor" (palabro albaceteño).


Después hemos visto a Daniel Martínez (@Dan1t0) abusando de las funcionalidades del Whatsapp Web (que no hackeándolo) para construirse una web de descargas multimedias.

Este año también hemos podido volver a ver al brillante equipo de @Layakk (José Picó y David Pérez) atacando 3G (eso sí: dentro de una jaula de faraday). Los cuatro ataques que explicaron y demostraron en directo fueron: IMSI Caching, geolocalización de terminal, DoS persistente y downgrade selectivo a 2G.


Después hemos visto a Román (@patowc), organizador de la Rooted, conectándose a un canal de IRC para hablar con los hacktivistas de la 9 (@La9deAnon), quienes enviaron una carta por ese medio y contestaron a las preguntas que él les transmitía del público.

Por la tarde, Raúl Siles (@raulsiles) dio una masterclass sobre cómo hackear los dispositivos del Internet of Thing que se comunican por radiofrecuencia por debajo de 1 GHz. Para ello, utilizó herramientas como HackRF, inspectrum y GNURadio.



Después, Chema Alonso (@chemaalonso) y Pablo González (@pablogonzalezpe) explicaron los peligros que puede haber con los token OAUTH si los usa un atacante, en conjunción con el spear phishing para hacerse con el acceso a tu cuenta (sin necesidad de pillarte la contraseña y sin que haya 2FA que te salve).

Y, para terminar, Pablo San Emeterio (@psaneme) y José Miguel Cañete contaron cómo se podría montar un dispositivo de vigilancia autónoma con un drone y un vehículo terrestre, por menos de 600€. Construido y programado por ellos.

Eso ha sido todo por este año. Si tenéis interés en alguna charla en particular, podéis pedir más información a los ponentes; que, de todos modos, acabarán subiendo las diapos y los videos a la web de la rooted. También tenéis los comentarios que hemos ido poniendo los asistentes en Twitter con el hashtag #rooted2016.

El próximo año, más.





04 marzo 2016

Qué hemos visto en la RootedCON7 (viernes)

El resumen del jueves se puede consultar aquí: 

Viernes:

Hemos visto a Pedro Cabrera (@PCabreraCamara) "secuestrando" un drone pilotado por un voluntario del público:



Algo para tener en cuenta. Sobre todo, considerando los incidentes recientes con drones

Más tranquila la charla de Juan Garrido (@tr1ana) sobre seguridad defensiva: cómo utilizar las propias herramientas de Windows (como el FSRM) para protegerse (o mitigar los efectos) de problemas como el ransomware o los exploits.

Laura García (@lainn_) y Ricardo J. Rodríguez (@RicardoJRdez) hablaron del malware para iOS, mucho menos extendido que para Android, pero todavía presente, incluso para dispositivos sin jailbreak (aunque menos). En total, han contado 35 familias distintas de malware.


Después, Hicham Tolimat (@Hi_T_ch) explicó la herramienta Docker y sus ventajas frente a las técnicas habituales de virtualización. Hizo una llamada a la comunidad hacker para que colaboraran en la seguridad de dicha herramienta.


Tras la comida, Matías Katz (@MatiasKatz) nos mostró un código que permite bloquear un equipo utilizando un elemento hardware y también otro (usado a modo de backdoor) que permite desbloquearlo mediante los audiojacks o la pantalla. Ambos usan DBUS y funcionan para portátiles con Linux.  Las demos las hizo en directo. Aquí podéis ver el código:


Y después, pudimos asistir a un Panel hecho expresamente para aquellos que están interesados en poner en marcha sus proyectos de startups de ciberseguridad.

Tras el Panel, la última charla, de Andrés Tarasco (@atarasco) versó sobre la piratería de TV por satélite y los protocolos nagra. Quedó claro que España ocupa el puesto número uno en la escala mundial de piratería.

Y eso es todo por hoy. Hasta mañana. Sweet dreams and happy hacking!

Qué hemos visto en la RootedCON7 (jueves)

Jueves:

Federico Dios (@DiosFederico) nos ha explicado cómo Akamai elebora el informe sobre el Estado de Internet: Akamai cuenta con cuatro tipos distintos de plataformas y, por algunas de ellas, pasa entre un 15% y un 30% del tráfico de internet; entre algunas cosas curiosas que se ven en el informe está el hecho de que haya muchas botnets alojadas en raspberries pies.



Jorge Hurtado nos ha hablado de la estupidez de las amenazas que nos cuelan los fabricantes: en los portátiles, los antivirus, el IoT... En vista de lo cual, ¿por qué no desarrollar un sello que sea garantía de unos mínimos niveles de seguridad?


Abel Valero (@sanguinawer) ha hecho una excelente exposición de cómo hacer un análisis estático y dinámico del bootkit rovnix y ha explicado un poquito como logran la persistencia en arranque estos bichos. Ojo: que el mismo ejemplar sirve para 32bits y para 64bits. Radare2 (@radareorg) ya incluye un plugin para analizar cómodamente estas metamorfosis de código ensamblador.



Jonathan Shimonovich ha explicado el problema existente con los certificados con los que ciertas app de control remoto de móviles (mRST) cifran sus plugins. El resultado es que cientos de miles de dispositivos son vulnerables. Si quieres saber si el tuyo lo es, puedes descargar en Google Play el "Certifi-gate scanner" de Check Point. Y, por si fuera poco, el servidor de control se puede cambiar con un simple SMS.



Rafael Sánchez (@R_a_ff_a_e_ll_o ) y Francisco J. Gómez (@ffranz ) han presentado la herramienta MrLooquer para el escaneo de direcciones IPv6. Qué sí: que hay más de las que crees (si hasta llegan spams con origen v6) y la seguridad por oscuridad no es buena. ¿Quizá tú también tengas IPv6 expuestas sin saberlo? Búscate.



Alfonso Muñoz (@mindcrypt) ha salido con un lector de ondas cerebrales para mostrarnos cómo se pueden utilizar éstas para, por ejemplo, controlar un videojuego. También existe la posibilidad de utilizarlas como un medio de autenticación o como cifra. Pero la "lectura de la mente" también presenta problemas de privacidad: ¿qué pasa si, mientras lo usamos, nos leen información no deseada? ¿acabaremos todos con un gorro de aluminio?



En el RootedPanel se presentó una mesa redonda sobre el papel de los francotiradores cibernéticos y los problemas que esto plantea.


Y, por último, Elias Grande presentó su herramienta de Footprinting, Odin, que incluye análisis de DNSSec y crawdler de redes sociales. Puede usarse para controlar el shadow IT de las organizaciones antes de que se convierta en un problema.



¡Mañana, más!

14 febrero 2016

TM-Score complementa un DLP



Hoy, un post muy breve para introducir un concepto nuevo. 

Muchos conoceréis los sistemas DLP (Data Loss Prevention), que se centran en los datos y en impedir el acceso a información sensible por parte de personas no autorizadas. Sin embargo, estos sistemas no toman en cuenta el peligro que supone el acceso a los datos por parte de usuarios autorizados y el mal uso que hagan de ellos; por ejemplo, revelando información confidencial intencionada o inintencionadamente. 

Por esto, es interesante este paper en el que se propone definir una medida del mal uso potencial de un documento, llamada TM-Score, que sirva para estimar el daño que podría causar a una organización el que un usuario esté constantemente accediendo a documentos autorizados.Esta solución se propone como un complemento a los DLP y los sistemas de control de acceso, no como una alternativa a ellos. 

Con este sistema, hay que calcular el TM-Score individual de cada documento y TM-Score acumulado de cada usuario. Eso se hace de la siguiente manera: a cada documento se le asigna un TM-Score individual, en función de la cantidad de información que contiene y de la sensibilidad de ésta. A su vez, el TM-Score de cada usuario se va acumulando cada vez que éste accede a información nueva de un documento y se calcula en función de la cantidad, el tipo y la calidad de la información a la que el usuario tiene acceso mediante ese documento. Y para calcular que parte de la información del documento resulta nueva para el usuario, el paper propone dos métodos: fingerprinting y similaridad del coseno. 


Esta propuesta es de finales del 2014 (poco más de un año). ¿Conocéis algún sistema que la implemente?

07 febrero 2016

Gestión de Incidentes: adquisición de evidencias forenses (y II)



En una entrada anterior estuvimos comentando lo útil que podía ser la ISO 27037 para la adquisición de evidencias forenses.

Otra guía muy interesante es la del NIST: Guidelines on Mobile Device Forensics , que da pautas para la recuperación de evidencias forenses en los dispositivos móviles. Por ejemplo, resalta la necesidad de aislar el terminal en cuanto se tenga acceso a él; lo cual es necesario para evitar que se alteren o destruyan las evidencias. Por lo tanto, si el teléfono está conectado a un ordenador, debe quitarse el cable para evitar la transferencia de datos.

La alteración de evidencias podría suceder incluso en remoto, pues en algunos dispositivos es posible hacer un reset de fábrica, un borrado o un bloqueo del terminal, simplemente enviando un mensaje.  Además, las llamadas o los datos entrantes estarían contaminando las pruebas. Incluso si no hay evidencia de que esto haya sucedido, el simple hecho de que se tenga constancia de la existencia de vulnerabilidades asociadas al dispositivo, que pudieran ser explotadas para contaminar las evidencias, podría poner en evidencia la valided de las mismas. Por otra parte, existe también el riesgo de que, si el teléfono está infectado con malware, éste se propague por la red a la que se conecte el teléfono. Y aún más grave sería la posibilidad de que se trate de un teléfono bomba que pueda ser detonado en remoto.

Así pues, hay que aislar el terminal de cualquier tipo de red inalámbrica; lo que puede hacerse de alguna de las siguientes maneras:
- Poniéndolo en modo avión.
- Apagándolo. Pero esto tiene el riesgo de que luego, al encenderlo, nos pida el pin y no podamos acceder a él para obtener las evidencias. Por ello, siempre es mejor dejarlo encendido y conectarlo a la corriente para que no se agote la batería.
- Guardándolo en una caja de Faraday.
- Sustituyendo la SIM por una CNIC (Cellular Network Isolation Card): esto permite que el teléfono siga encendido pero que no tenga conexión con la red de telefonía.
- Pidiéndole a la compañía telefónica que lo saque de la red o haciéndo nosotros mismos un jamming/spoofing del dispositivo (emitir una señal más fuerte que la de la torre que envíe un 
no-carrier<"> al teléfono). Por supuesto, hay que tener en cuenta las implicaciones legales que estos dos métodos pueden tener. Normalmente son las Fuerzas y Cuerpos de Seguridad del Estado (u otros organismos estatales) los que podrán hacer eso, previa autorización judicial.

Otra buena guía es el manual de buenas prácticas de la ACPO (Association Of Chief Police Officers): Good Practice Guide for Computer-Based Electronic Evidence.

Por ejemplo, explica que de un ordenador en funcionamiento se pueden extraer detalles de la conexión a la red y datos de la memoria volatil. Es decir: procesos y servicios en ejecución, información del sistema, información de autoarranque, información del registro, puertos abiertos, puertos cerrados y puertos en escucha, ARP caché, aplicaciones desencriptadas, usuarios y contraseñas y código residente en memoria, entre otras cosas.

Esta información es importante porque permite comprender mejor qué estaba sucediendo en el ordenador en un momento determinado y complementa a la que se pueda extraer del disco. Por ejemplo, una de las cosas que se pueden investigar con los datos de la memoria volatil es la presencia de una puerta trasera abierta por un troyano.

Para recuperar la memoria volatil se puede utilizar un live-USB con las herramientas forenses adecuadas. Los pasos a seguir son:

- Conectar el USB.
- Ejecutar el script con las herramientas.
- Expulsar el USB.
- Desconectarlo.
- Ahora el sistema ya se puede apagar y el USB donde se ha guardado la información se conecta al equipo forense para analizarla, por ejemplo con Volatility.


No siempre es necesario acudir físicamente con las herramientas forenses al puesto a analizar. También se puede obtener información «al vuelo» desde la red a la que el equipo está conectado si está instalado un agente de software forense. 

Otros dispositivos que también se pueden utilizar para obtener información de la conexión de red del dispositivo que se está analizando son los routers y firewalls (cortafuegos). Y puede consultarse desde consola.

Espero que os hayan gustado estas entradas como una pequeña introducción a la gestión de incidentes y adquisición de evidencias.


Por cierto, si queréis saber más sobre la adquisición de evidencias volátilies (a parte del volcado de la RAM), no dejéis de consultar este post de los chicos de Security at Work. Hay cosas muy interesantes.


04 febrero 2016

Gestión de Incidentes: adquisición de evidencias forenses (I)


Cuando comentabamos el ciclo de vida de la gestión de incidentes, dijimos que, tras la detección y el triaje, venían las fases de contención y análisis

Cuando estamos tratando de contener los efectos de un incidente, no debemos olvidar lo importante que es preservar las evidencias para poder hacer un análisis que nos permita analizar qué ha sucedido exactamente. De otro modo, podríamos estar cerrando en falso el incidente, si no sabemos exactamente qué daño nos han hecho (o nos pueden hacer en el futuro) y nos limitamos a restaurar equipos y datos.

En este sentido, la ISO 27037 es muy útil porque provee una guía para la identificación, recuperación, adquisición y conservación de las evidencias digitales. 
Una de las cosas que define esta guía es el papel que desempeñan los DEFR y los DES. El DEFR (Digital Evidence First Responder) es el encargado de dar una respuesta temprana ante un incidente, llevando a cabo la recolección, adquisición y custodia de evidencias digitales. Tiene que tener una serie de habilidades y competencias básicas (definidas en el Anexo A) que le permitan realizar dichas tareas con la debida autoridad. Bajo ciertas circunstancias, algunas de estas tareas pueden ser realiazadas por un DES (Digital Evidence Specialist), especialista en la recogida de evidencias digitales que tiene unos conocimientos técnicos, aunque no cuenta con la misma autoridad y cualificación que el DEFR.


Algunas partes especialmente interesantes de esta guía son el punto 5.4.4. Acquisition, el punto 6 Key components of identification, collection, acquisition and preservation of digital evidence y el punto 7.1.2 Collection. Del punto 6, cabe resaltar sobre todo el apartado 8 (Prioritzing collection and acquisition) donde se hace una distinción entre las evidencias volátiles (que pueden desaparecer) y las no volátiles (que permanecen).




Otras guías muy útiles para la recuperación de evidencias forenses son Guidelines on Mobile Forensics, del NIST, y Good Practice Guide for Computer-Based Electronic Evidence, de la Association of Chief Police Officers (ACPO). Pero éstas ya las explicaremos otro día.


23 enero 2016

#IXJornadasCCNCERT (Securtiy Workshop)


The CCN-CERT is the Spanish Government CERT. And among its responsabilities is assisting the Public Administrations in fighting agains security incidents. It was created in 2006 as a part of the CCN (National Cryptology Centre), asigned to CNI (National Centre of Intelligence).


Every year, it arranges two days for the STIC Workshop to be hold as a meeting place for security professionals. This conference is probably the most prestigious security congress in Spain, having among the speakers many professionals from major international companies like Kasperky and FireEye, as well as from different spanish enterprises and institutions.

The subject of this year's congress was “Detección e intercambio, factores clave” ("Detection and exchange key factors") and it was made up of a plenary and two diferent simultanious modules: "Cyberspying / APTS / Threats, tools and technologies" and "Cybersecurity strategy. ENS and compliance". ENS stands for "Esquema Nacional de Seguridad" ("National Security Scheme").

Among the the talks in the "Cyberspying..." module was a vulnerability disclosure: the Linux Grub2 vul (CVE-2015-8370). This zero day in the Linux bootloader, call "back to 28", was discovered by the cibersecurity research group of the UPV spanish university. You can see all the details here: http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

As for the ENS module, there was a roundtable discussion about the implications of a upcomming regulatory development of the "Law on private security" in public procurement of cybersecurity services. The table was attended by different professionals like a commisary, two hackers and a director civil servant in the field of security.

These are just but a few of the very interesting talks givent at the event. Access to the whole presentation is available in the following links  (Spanish):

- Video recording: