Redes Sociales

lunes, 12 de mayo de 2014

Presentación para convencer al Consejo de Administración de la necesidad de un plan de seguridad

Como comentaba en el anterior post, estoy asistiendo a un curso de Ciberseguridad industrial con Samuel Linares y Nacho Paredes, del CCI. Por cierto que el curso merece la pena. El pasado Sábado se nos pidió defender ante un consejo de Administración la necesidad de implantar un plan de seguridad integral en la industria. Una práctica muy útil que puede ocurrirnos alguna vez a lo largo de nuestra carrera.

La presentación que tenía yo preparada no fue escogida por mi equipo como la final, básicamente por no ser una industria, la eléctrica que conociéramos, cosa que es verdad. Pero como ya la tengo hecha, pues al menos la voy a colgar del blog, que igual a alguien le interesa o parece interesante.

La idea de la presentación es que somos una industria electrica, ElectroACME Corp., empresa de 5000 trabajadores que ha sido declarada recientemente una infraestructura crítica por el gobierno español. A partir de ahí, nos presentaríamos ante el consejo de administración y tendríamos siete minutos para defender la necesidad de un plan de seguridad para la industria.

Mi Powerpoint hubiera sido este.

Cabe mencionar que este powerpoint era una idea inicial que hubiera sido necesario mejorar a lo largo de los 30 minutos que se nos dejó para ello. En todo caso, la idea era dar un mensaje rápido, llamativo y convincente que concienciara al consejo de administración del problema al que se enfrenta su empresa. Por otra parte, debo decir que me alegro de no haber salido yo a defenderlo... ¡¡porque allí volaban los cuchillos!!.

miércoles, 7 de mayo de 2014

Ciberseguridad industrial desde el punto de vista del acceso fisico a las instalaciones

Ahora que estoy asistiendo a un curso de Ciberseguridad industrial con Samuel Linares y Nacho Paredes, del CCI, me doy cuenta de la problemática existente de seguridad en el ámbito industrial, no solo en España sino en todo el mundo.

También he descubierto que el problema en la industria no son solo los SCADAs, idea que flotaba en el ambiente desde el archiconocido caso de Stuxnet. La seguridad es un problema que afecta a todos los ámbitos, desde el físico, el tecnológico, el personal y hasta a la dirección.

Escribo esta entrada un poco para aclarar ideas tras haber leido algunos documentos. No pretendo presentar nada novedoso.

INTECO realizó en 2013 una guía de seguridad del puesto de operador de un SCADA, que no deja de ser un resumen de buenas prácticas que también podrían aplicarse a cualquier puesto de trabajo de oficina. De la concienciación de los trabajadores mucho se ha hablado, pero hay un entorno que es igual de importante y que es el gran olvidado a la hora de hablar de sus riesgos y de su seguridad. Se trata del entorno de las infraestructuras físicas de las industrias.

Por supuesto que la industria se toma muy en serio su seguridad física y en la práctica totalidad de recintos existen guardias de seguridad que velan por la integridad física de los recintos. ¿Pero es suficiente?. Estos recintos suelen ser vastas extensiones sólo separadas del exterior por una simple valla y en la inmensa mayoría de los casos el contingente de control se reduce a uno o dos guardas de seguridad.

Cada día se producen a nivel nacional varias intrusiones físicas en infraestructuras críticas, algunas nunca son descubiertas y otras son consideradas vulgares accesos en busca de herramientas, cobre... pero estos accesos, ¿podrían ser ciberataques?. La respuesta es que sí. Muy pocos accesos físicos a infraestructuras críticas y plantas industriales son tratados como ciberataques.

Sin embargo, muchos componentes de sistemas de control industriales (ICS) pueden ser encontrados "en el campo" o "en planta". Y cuando digo "en el campo" me refiero a que muchas estaciones se encuentran en lugares remotos a muchos kilometros de cualquier pueblo cercano.

Instalación de gas natural
Estación extractora de gas natural

El acceso no autorizado a casetas de control es frecuente, pero este tipo de accesos han sido siempre considerados como crímenes contra la propiedad únicamente. En el mundo actual, cada vez mas interconectado, este tipo de accesos podrían adquirir otra dimensión.

Hay que darse cuenta que para facilitar su interconexión y el trabajo de los operadores, los ICS ya no disponen de sistemas operativos propietarios, sino que muchas veces utilizan sistemas operativos como Microsoft Windows o distribuciones Linux que no se actualizan tan a menudo como debieran.

ICS de una caldera de vapor

El acceso físico a estos sistemas de control industrial podría implicar acciones tales como cambios en ficheros de configuración, la instalación de hardware no autorizado, realizar reconocimientos (esnifado) de red o simplemente el robo de información (de criticidad variable).

Por poner un ejemplo, la instalación en los sistemas de control de campo, de dispositivos USB que permitieran un acceso remoto a dichos dispositivos mediante un enlace wireless. Esto proporcionaría una ruta para futuros ataques y un control remoto de una parte de la estación. Además, Una vez instalados estos dispositivos son dificilmente detectables. Por ultimo si se conectan a dispositivos que estén conectados a internet, desde estos dispositivos se podría llegar a conseguir acceso a otros sistemas dentro de la compañía.

Keylogger Wireless
Keylogger con capacidad de conexión a redes inalámbricas

Esto era solo un ejemplo, también se podría realizar acciones tales como:

  • La instalación de troyanos.
  • La instalación de aparatos o software de espionaje de red.
  • La instalación de Keyloggers, videologgers, etc.
  • La instalación de PLCs o cualquier otro tipo de dispositivo.

Como posibles vías de ataque, no estamos hablando solo de cortar un trozo de alambrada y meternos dentro del recinto, también podríamos hablar de:

  • Ataques a través de Redes Wifi
  • Conexiones a internet
  • Personal poco concienciado (El típico ataque del USB)
  • Dispositivos móviles conectados a la red
  • Dispositivos de calibración comprometidos

Recientemente se ha hablado mucho de PLCPwn, un PLC usado para realizar ataques de cualquier tipo en la infraestructura de red. Este PLC podría ser implantado con cierta facilidad durante un acceso físico no autorizado a una planta industrial. Incluye un modulo GSM que le permitiría recibir instrucciones en remoto y un interfaz wireless para crear y conectarse con un red inalámbrica que pueda ser utilizada para ataques remotos.

PLCPwn oculto entre otros PLCs legítimos
PLCPwn oculto entre otros PLCs legítimos

El responsable de seguridad del centro nos dirá que este escenario que planteamos aquí es muy improbable ya que existe un equipo de personas encargado de velar por la seguridad de la planta y que existen cámaras de seguridad. Sin embargo ya se ha demostrado que un equipo de guardias de seguridad no siempre es suficiente para mantener la seguridad física y lógica del recinto.

Cuando quien está detrás de estos accesos son terroristas o industrias rivales, es muy posible que un equipo de seguridad de una o dos personas no sea suficiente.

Además estos grupos profesionales habrán hecho su trabajo y encontrado posibles puntos débiles estudiando:

  • las rutinas diarias.
  • las acciones de respuesta ante anteriores intrusiones.
  • la complacencia de los trabajadores.
  • fallos en la comunicación entre los diferentes grupos.

Los encargados de seguridad de una planta buscaran las típicas pistas que puedan indicar que se haya producido una intrusión:

  • Puertas abiertas.
  • Alarmas desconectadas.
  • Personal no autorizado a través de videocámaras.
  • Candados que ya no abren.
  • Daños o señales de forzado de puertas o vallas.

...pero si quien accede son profesionales, ¿dejarían estas pistas?. Y si se detectan estos accesos, ¿como podemos saber que no ha habido un acceso a la infraestructura de red o no se ha instalado algún dispositivo para un futuro acceso remoto?

Aparte de las anteriores indicaciones, es necesario mantener un equipo que vele por la ciberseguridad del recinto y detecte cosas como:

  • Pérdidas de conectividad o un comportamiento extraño en la red.
  • Conexiones sin explicación aparente entre componente de campo.
  • Un comportamiento inexplicable de sistemas de control.
  • Elementos que falten o que hayan aparecido inexplicablemente y no estuvieran en el inventario.
  • Un aumento de facturas de tarificación de datos en las comunicaciones de la estación.
  • Nuevas redes Wifi o de radiofrecuencia.

Para evitar que estas intrusiones no se conviertan en ciberataques, la solución no es (solo) aumentar el contingente de seguridad. De hecho, muchas veces el mayor atacante lo tenemos dentro: nuestros propios trabajadores.

Hay que realizar una serie de acciones tales como:

  • Tareas de concienciación de los trabajadores.
  • Preparar un plan de seguridad integral de las instalaciones que englobe los aspectos físicos y lógicos.
  • Realizar simulaciones de ataques físicos.
  • Realizar un inventario de los equipos y su infraestructura, manteniendo en el mismo un soporte gráfico del estado en que se encuentran.

Durante la revisión ocular del recinto es necesario preguntarse cosas como ¿adonde podría yo acceder una vez que haya ganado acceso físico al recinto?. ¿Se puede acceder a la red de control o de dirección desde allí?. Si es así, un atacante también podría. Si manipulo alguno de estos componentes, ¿puede este cambio impactar en el rendimiento de la infraestructura?

Si la respuesta a alguna de estas preguntas es que sí, debemos escalarlo al responsable porque se hace necesario una revisión del recinto y de su seguridad y preparar un plan para minimizar el impacto ante este tipo de intrusiones.

La revisión del recinto deberá realizarse con el encargado de seguridad

Durante la revisión del recinto será necesario conectarse a cada dispositivo y comprobar (en base a un inventario previamente realizado):

  • los logs
  • el "uptime", es decir el tiempo que lleva funcionando, cada dispositivo. Un reinicio de varios dispositivos simultaneamente podría indicar un acceso no autorizado
  • nuevas cuentas de usuario o cambios en el sistema
  • nuevos dispositivos removibles conectados (USBs, etc)
  • la configuración del dispositivos
  • comprobar las fechas de modificación de los ficheros de configuración
  • comprobar la versión del firmware del dispositivo
  • realizar un escaneo de malware en el dispositivo
  • en caso de que todo este aparentemente bien, actualizar el inventario.

Y por supuesto, si encontramos algo raro. Informar al encargado.

miércoles, 26 de marzo de 2014

Revisiting Winrar "0-day"

Tras leer este blog, me decidi a probar esta "vulnerabilidad" en el winrar que tenía en casa (que resultó ser la v5.01 y que es la descarga recomendada a día de hoy).

Lo primero que comprobé es que es cierto que aparecen dos veces los nombres de los ficheros, uno de ellos (el "primer nombre") al principio del fichero y otro (el "segundo nombre") justo al final. Sin embargo en la versión 5.01 el comportamiento es diferente al explicado en el blog antes mencionado.

En el caso de la version 5.01 de Winrar el "primer nombre" del que se habla en an7isec no se utiliza para nada, hasta el punto de que si se borra por completo, el fichero ZIP sigue siendo perfectamente válido.

Esto quiere decir que tanto para la previsualización como para la extracción final del fichero se utiliza el "segundo nombre".

Se puede modificar este segundo nombre, por supuesto, pero si por ejemplo a un ejecutable le ponemos una extensión PNG, el sistema operativo intentará abrir el ejecutable con el visor de imágenes resultando inútil el cambio realizado. Es igual que si le cambiáramos la extensión o el nombre ANTES de comprimir el fichero.

Y como muestra, un botón:

Como no tenía un malware a mano, hice la prueba con el socorrido putty.exe. Tras crear un fichero ZIP con Winrar de dicho ejecutable, al abrirlo con un editor hexadecimal vemos que, ciertamente tiene un primer nombre:

...y un segundo nombre:

Comprobamos que, si eliminamos por completo el primer nombre:

...no pasa nada:

...y si le cambiamos la extensión al ejecutable "malicioso":

...nos lo intentará abrir con el visualizador por defecto para esa extensión:

Con lo cual podemos sugerir que con las versiones actuales de Winrar podemos estar tranquilos.

martes, 25 de marzo de 2014

Vulnerabilidad 0-day en Microsoft Word

Microsoft publicó hoy un comunicado avisando de una vulnerabilidad 0-day que afecta a Microsoft Word. El problema podría comprometer a todas las versiones de Microsoft Word 2003 a Microsoft Word 2010. La vulnerabilidad parece no existir en Microsoft Word 2013 debido a que en esta versión se fuerza el uso de ASLR.

La vulnerabilidad se puede propagar (y de hecho ya se esta aprovechando) mediante correo electrónico utilizando un fichero RTF modificado que incluye un payload que descarga un troyano desde un sitio remoto de forma inadvertida para el usuario. No es necesario siquiera abrir dicho documento RTF y bastaría con previsualizarlo con Microsoft Outlook, ya que éste usa Microsoft Word como visor de correo.

Microsoft proporciona un Fix-It para resolver de forma temporal el problema. Este Fix-It se puede instalar desde aquí.

Por otra parte, se ha visto que el tener instalado EMET evita la ejecución del payload del RTF.

Aparentemente la funcionalidad de descarga del troyano dejará de funcionar el 8 de Abril de 2014. El troyano descargado es un fichero llamado svchost.exe que aloja un malware genérico escrito en Visual BASIC que se conecta por https con la IP 185.12.44.51 (alojado en Suiza) para descargarse scripts VBS y ficheros MSI que instalará en el equipo comprometido.

Para mas información se pueden leer estas noticias:

viernes, 14 de marzo de 2014

Probando el DVWA (Parte I)

Hoy me decidí a instalar DVWA para hacer pruebas de conocimientos de sql injection y demás. DVWA es la Damn Vulnerable Web Application y su nombre lo dice todo. Básicamente se trata de una XAMPP con PHP y MySQL.

Tras instalarla, el primer problema que encuentro (aparte de un error de MySQL que habia que cambiar la contraseña del usuario root) es que me aparece la página de login y no tengo ni idea de qué usuario y contraseña utilizar:

Por suerte lo tengo instalado en local y puedo ver el fuente de login.php, que tira de la base de datos de MySQL 'dvwa' y dentro, de la tabla 'users'. Dicha tabla es algo asi:

Esas contraseñas parecen un MD5... vamos a intentar descifrarlas. Vamos a alguna de las multiples páginas que hacen resolucion inversa de MD5, por ejemplo gromweb y le damos:

Ok, pues para el usuario admin, la contraseña es password. Vamos a ver el resto.... Para el usuario gordonb es abc123, para el usuario 1337 es charley y para el usuario pablo es letmein.

Una vez dentro me sale esta página principal:

Command Execution

Pruebo a comenzar con la ejecución de comandos. Me sale esta pantalla donde se supone que introduciendo una IP, me hará ping a dicha IP. De hecho funciona. Pero hay algo más, seguro. Tras unas cuantas pruebas:

...me empiezo a escamar y miro el código fuente... hasta que me doy cuenta de que estoy en modo NO-VULNERABLE, opción que se puede modificar en el fichero config.inc.php:

Según la documentación, el modo de seguridad 'high' es seguro contra contra todas las vulnerabilidades y además nos muestra buenas prácticas de programación.

En este modo la herramienta del ping "con vulnerabilidad de ejecución de comandos" esta escrita asi:

Es decir, se "explota" la IP por el simbolo punto y luego se comprueba si cada parte es numerica con la funcion is_numeric de PHP. Tras investigar un poco, no hay forma de saltarse esta comprobación.

Así pues, pasemos al modo 'medium' (Tampoco es plan de ir a lo facil).

Ahora si. Simplemente poniendo un simbolo "pipe" nos permite ejecutar cualquier comando linux:

En este modo, se filtran los codigos '&&' y ';', pero todo lo demás, lo deja ejecutar.

File Upload

Pruebo a continuación la opción de subida de ficheros (Upload). Para ello voy a escribir un script PHP que me haga un simple ls. Algo así:

Al subirlo me da un error muy explicativo:

Your image was not uploaded. O sea que esta esperando una imagen. ¿Y si le ponemos una extension jpg al php?. A ver... ¡¡Vaya, y nos pone la ruta completa!!:

Entiendo que ahora solo hay que ejecutar ese jpg... Vaya... ¡pues no!:

Ah! pero para eso tenemos la ejecución de comandos que probamos antes. Si vamos a Command Execution y le pedimos que nos haga ping a:

8.8.8.8|mv ../../hackable/uploads/prueba.jpg ../../hackable/uploads/prueba.php

...ahora ya podremos ejecutar dicho PHP:

Y hasta aquí por ahora. Esta wapo este DVWA, permite probar conceptos y aprender como se debe programar en PHP de forma segura.

jueves, 27 de febrero de 2014

Pasos seguidos para la limpieza de las VMs del curso de INTECO "Ingeniería social y analisis de sospechas"

En el último curso impartido por INTECO desde el pasado Martes hasta hoy hemos hablado de ingeniería y "analisis de sospechas", curioso nombre cuando de lo que se trata es de detección y limpieza de troyanos.

Como parte práctica nos han dado cuatro máquinas virtuales infectadas que había que limpiar "a mano", sin herramientas de limpieza automática (léase cualquier tipo de antimalware). En esta entrada describiré los pasos que seguimos (los de mi grupo) para la limpieza de dichas máquinas virtuales.

Resolución maquina virtual VM02

Se arranca la maquina y se comprueba el problema:

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD

cd HD

Se busca el listado de fichero creados los días 20 y 21 de Febrero (Sabemos que es cuando se infectaron las máquinas). No se encuentra ningun exe, ningun lnk ni nada interesante.

Encontramos dos ficheros interesantes:

  • Una carpeta setup
  • Un fichero llamado At1.job, que es una tarea programada.
  • LockScren.AO.lnk

La carpeta setup resulta ser c:\windows\system32\oobe\setup\setup.exe

Al mirar los contenidos del fichero At1.job vemos que se ejecuta el fichero setup.exe de la ruta anterior.

Probamos a mover ese fichero setup.exe a otra ruta. Rearrancamos Windows, y ya no aparece el Ransomware.

Restauramos una versión anterior de Windows.

Buscamos las entradas del registro que llamen a este setup.exe y aparecen las siguientes:

HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache=”C:\windows\system32\oobe\setup\setup.exe”
HKU/1-5-21..../Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell=”C:\windows\system32\oobe\setup\setup.exe”

Las borramos. También borramos el fichero setup.exe.

El fichero lnk es un enlace al ejecutable que infectó la máquina, por lo que sabemos de que virus se trata (con enviar el fichero setup.exe también nos habria valido).

Buscamos por internet LockScren.AO y encontramos esta página:

http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/LockScreen.AO#tab=2

Resolucion VM03

Al arrancar la máquina, aparece este error de la ejecución de “other.res”:

Se busca ese fichero y aparece en

c:\Documents and Settings/aula2/Application Data/other.res

La pantalla de error tiene un icono muy pixelado que claramente pretende engañar.

El other.res también aparece en el administrador de tareas.

Se arranca la maquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados los días 21 de Febrero (sabemos que las maquinas fueron infectadas en esa fecha).

Se encuentra un fichero Flash7.ocx.exe que suena raro:

En los momentos después de la ejecución del troyano se ven ficheros temporales de internet y la instalacion de Flash.

Volvemos a Windows.

Vemos que el Flash7.ocx (realmente Flash7.ocx.exe) tiene exactamente el mismo icono que el error. Lo mandamos a Virustotal.

Virustotal nos dice que es un virus y lo detectan 38 de 47 antivirus y que se llama urausy.

Mientras tanto se busca other.res en el registro de Windows:

Tambien se encuentra esta entrada:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell=explorer.exe, C:\Documents and Settings\aula2\Application Data\Other.res

Lo borramos y matamos el proceso. Tambien borramos el fichero.

Buscamos Flash7.ocx.exe en el registro. Aparece la siguiente entrada:

La ruta es HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache/

La borramos.

Borramos la carpeta completa Flash. No deja borrarla. Rearrancamos Windows en modo a prueba de fallos, tampoco la conseguimos borrar, por lo que entramos desde Linux y nos la cargamos.

Se borra tambien BRNDLOG.BAK en %UserProfile%/aula2/AppData/Microsoft/Iexplorer



Resolución maquina virtual VM04

Se arranca la maquina y se comprueba el problema.

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Sabemos que el bicho se instaló ese día en la máquina). No se encuentra ningun exe, ningun lnk ni nada interesante.

Buscamos por internet y encontramos un virus parecido llamado gpcode.ak, y una entrada de un blog( http://www.securelist.com/en/weblog?weblogid=208187531) donde indica que la única solucion es recuperar los ficheros usando photorec, ya que despues de encriptarlos, el virus los borra y los ficheros borrados, si no se a tocado demasiado el sistema, se pueden recuperar.

Nos ponemos a ello y recuperamos un montón de ficheros:

Eliminamos el fichero Bliss.bmp, que es el fondo de pantalla con la calavera.

Este es el resultado:



Resolución VM05

Se arranca la máquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque. Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reincia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Fecha de instalación del troyano). Encontramos tres ficheros interesantes:

  • Un fichero setup.exe
  • Un fichero sdrive64.exe
  • Un fichero Skomaz.lnk

Buscamos dicho Skomaz en internet y encontramos esta páginas http://www.spywarelib.com/remove--Trojan-spy-skomaz.html.

...donde habla del fichero sdrive64.exe. Y esta:

https://www.virustotal.com/es/file/e7fa7e304b3ab56c695a51d8caf832b79563969465b388420381ac13ac8b550b/analysis/

Donde habla de que el virus tiene 1165824 bytes.

Buscamos ficheros de ese tamaño y casualmente encontramos que hay uno llamado setup.exe (el de antes).

Los borramos y arrancamos. Ya no aparece la pantalla de rescate pero Windows no funciona.

Es porque en vez de lanzar explorer.exe en alguna entrada del registro esta lanzando sdrive64.exe

Lo encontramos en HKCU/Microsoft/Windows NT/Winlogon/Shell=C:\Documents and settings\aula2\Local Settings\Temp\sdrive64.exe

Voila!

jueves, 20 de febrero de 2014

Cifrado de correos electrónicos con GPG (1/2)

Voy a aprovechar un trozo del tema 9 del curso de seguridad de la Hacker High School, de la que soy traductor, para poner en contexto lo que es PGP, las claves públicas y privadas, MIME y S/MIME, de cara a luego a hacer la práctica del funcionamiento de todos estos conceptos. Lo hago por que la verdad, me ha parecido una explicación muy amena, sencilla e interesante y creo que todos deberíamos SIEMPRE enviar nuestros correos cifrados y firmados y evitar así que ocurran cosas como lo de la NSA. Ahí va:

PGP viene de Pretty Good Privacy (En castellano, Bastante Buena Privacidad) y fue desarrollado por Phil Zimmermann. Es posible que buscando por internet nos encontremos con la versión de código abierto llamada GPG (GNU Privacy Guard). GPG esta disponible gratis para muchas plataformas, y solo usa algoritmos abiertos y públicamente evaluados.

GPG trabaja sobre el principio de gestión de claves públicas y privadas, lo que significa que las claves tienen una parte PÚBLICA que se la puedes dar a cualquiera que quieras que te envíe un correo cifrado, y una parte PRIVADA que debes mantener en secreto, y que es la única forma de descifrar el mensaje que has recibido. Al conjunto de clave pública y privada se le llama par de claves, y generalmente es lo primero que generas cuando instalas GPG en una máquina. El par de claves está protegido por una contraseña de manera que puede no ser modificado por nadie más que por el dueño. Puede ser necesario alterar el par de claves cuando quieras cambiar las direcciones de correo que el par de claves soporta, o por si quieres hacer uso de otras funciones.

Dado que necesitas la clave pública de alguien a quien quieras enviar un mensaje cifrado, existen servidores como pgp.mit.edu donde puedes descargar la clave o claves públicas asociadas con una dirección de correo en concreto, así como subir tu propia clave pública. Es posible que las claves hayan expirado o que se pierdan las contraseñas privadas, de manera que siempre usa la última clave o incluso mejor, pide al destinatario de tu correo que te mande la suya y confirma y confirma el fingerprint (una especie de más corto).

MIME (Multi-Purpose Internet Mail Extensions) es un conjunto de extensiones del protocolo de correo SMTP (Simple Mail Transfer Protocol). MIME permite enviar como adjuntos diferentes tipos de contenidos tanto de datos como multimedia, audio, video, imágenes, ficheros comprimidos, y aplicaciones. La cabecera MIME se inserta al principio del correo electrónico y el cliente de correo del receptor usa esta información para determinar qué programa está asociado con el fichero adjunto. MIME por sí mismo no proporciona ningún tipo de seguridad a los correos o a los adjuntos.

S/MIME (Secure/Multipurpose Internet Mail Extensions) es un protocolo que añade las características de firma digital y cifrado a los ficheros adjuntados al mensaje mediante MIME. Usando firma digital, S/MIME consigue garantizar la autenticidad, integridad y no repudio del mensaje (“no repudio” significa que no puedes negar que lo hayas mandado tu). S/MIME proporciona privacidad y seguridad (usando el cifrado) a los correos que usen este protocolo.

Cuando consultas un servidor de claves, ¿Cómo puedes estar segur@ de que una clave pública de un destinatario de correo electrónico es realmente la suya y no ha sido subida por cualquier otra persona?. La solución a este problema es que estas claves pueden ser firmadas por terceras personas. Imagina que ya tienes la clave (pública) de alguien en quien confías, y que sabe quien es la persona a la que quieres mandar un correo electrónico. Esa otra persona puede firmar la clave pública, lo que significa que le añade un poco más de confianza a esa clave, dado que tu ya conoces a esta otra persona. Esto es conocido como confianza heredada. Por supuesto, también puedes encontrar otra forma de ponerte en contacto con el destinatario y pedirle que te mande su clave pública, o recibir la “huella” de la clave – la huella es un checksum de la clave que es fácil y rápida de verificar. En un servidor de claves, cada clave también tendrá un ID o identificador – que es otro checksum con el mismo objetivo.

Enviar un correo cifrado usando GPG. La mayor parte de los clientes de correo soportan extensiones que facilitan el manejo de claves y el cifrado de mensajes. Los mejor es comprobar de antemano si el destinatario de tu mensaje tiene una clave pública y obtenerla, ya sea de un servidor de claves, o del propio receptor del mensaje.

A continuación, escribe el correo electrónico como haces habitualmente (de nuevo recomendamos usar texto plano en vez de formato HTML), añade cualquier fichero adjunto que necesites y dile a tu cliente de correo que lo cifre y lo mande. Si decidiste firmar el correo, el cliente de correo habrá usado tu clave privada para firmar el mensaje primero, y a continuación habrá usado la clave pública de tu destinatario para cifrar el correo y todos los ficheros adjuntos. Si proteges tu par de claves con una contraseña(¡deberías!), tu cliente de correo te pedirá esa contraseña.

Recibir un correo cifrado usando GPG. Los correos cifrados con PGP contienen o bien un fichero adjunto marcado como GPG, o tienen un bloque de texto con una cabecera que le dice al cliente de correo que acaba de recibir un correo cifrado. El cliente de correo ahora accede a tu clave privada (posiblemente pidiéndote antes una contraseña) y descifra el mensaje y todos los adjuntos. Si el mensaje no fue cifrado con tu clave pública este descifrado simplemente fallará. Si el mensaje fue firmado por el emisor, la extensión (o plugin) GPG del cliente de correo usará la correspondiente clave pública para verificar la firma también. El plugin de GPG que utilices te alertará de cualquier problema que encuentre con las firmas o ficheros adjuntos, pero en general, una vez instalado, el uso de GPG es bastante fácil.