jueves, 24 de julio de 2014

Herramientas forense para ser un buen CSI. Parte LII: Forense de emails

Compartir este artículo:
En el post de hoy vamos a continuar con la cadena de forense en emails, destripando el contenido del email que os mostramos el otro día: http://www.flu-project.com/2014/07/herramientas-forense-para-ser-un-buen.html.

Al analizar el código fuente de un email, hay que fijarse principalmente en las líneas que empiezan por la palabra: “Received”, comenzando por las que se encuentran en la parte inferior del email.

La primera traza “Received:” será la que nos indica quién es el emisor del email, mientras que la última nos indicará la dirección del receptor.


De esta manera y con un poco de paciencia al leer, es sencillo comprobar el recorrido que ha seguido un email para llegar desde el emisor al receptor.

Sin embargo, habrá casos en los que el emisor ha falsificado, o al menos intentado, la dirección del remitente, para que parezca que era otra persona el emisor. Como ha ocurrido en el caso que os presentamos a continuación:


Para un forense experimentado, esta cabecera no dejará lugar a dudas de que un usuario malintencionado ha intentado engañar al receptor del mensaje, ya que este supuesto correo de hotmail ha salido de un servidor diferente a los habituales de Microsoft.

Por Internet existen multitud de servicios gratuitos que permiten a los usuarios enviar emails anonimizados. También son populares los sistemas de "envío de noticias a un amigo", que por una mala configuración de sus administradores permiten el envío de emails con la suplantación del remitente.

Cuidado con los emails, no os den gato por liebre... :)

Saludos!

miércoles, 23 de julio de 2014

Sudoers: Cambiando de identidad (Parte II de II)

Compartir este artículo:
Continuamos con la segunda parte de "Cambiando de identidad". Ayer hablamos sobre el por qué es necesario utilizar sudoer en una organización, y como se puede entender es totalmente necesario tener una delegación de credenciales eficaz y eficiente. Por otro lado, los alias nos permites agrupar acciones, usuarios, entornos bajo el mismo nombre. Hay distintos tipos de alias como por ejemplo Host_Alias, User_Alias y Cmnd_Alias, los cuales son bastante intuitivos. 

Por último, el elemento más importante ya que es el que realiza la concesión de identidad o no, es la ACL. Son las reglas que el administrador definirá para proporcionar la toma de una identidad a un usuario o no. La sintaxis es la siguiente <usuario/%grupo> <host> = [(<runAsUserList>:<runAsGroupList>)] <comando1>,...,<comandoN>.
Lo que se indica en estas líneas es que el root puede ejecutar bajo cualquier identidad cualquier acción, mientras que el usuario pablo puede ejecutar tomando la identidad de root, ya que no se especifica entre paréntesis ni usuarios ni grupos, el comando date y ninguna acción más.

El comando sudo dispone de unos parámetros que son interesantes para aprovechar su potencial. A continuación se presenta un resumen:
  • -u. Indicará a sudo que identidad se quiere tomar, si se tiene configurado en el archivo que se puede tener. Si no se especifica el parámetro, se intentará ejecutar la acción con la identidad de root por defecto.
  • -k. Este parámetro invalida una sesión anterior de sudo.
  • -l. Informa al usuario de sus privilegios como sudoer.
Ejemplo final del archivo

En el siguiente ejemplo final de archivo de sudoers se configura dos usuarios bajo el alias TECNICOS y otro usuario será el administrador y pertenecerá al grupo de administradores. Además, se configura bajo un alias los comandos que los técnicos podrán utilizar. Se puede entender que los técnicos sólo podrán realizar ciertas acciones bajo la identidad del administrador, mientras que éste podrá ejecutar cualquier acción.
Como conclusión añadir que la delegación de privilegios en ciertas acciones a través de sudo permite obtener una capa de seguridad y de control que no dispone a través de la delegación de credenciales genérica. Sudo no deja de ser un software el cual tiene sus versiones y puede tener implementados fallos explotables, por ejemplo últimamente se ha conocido alguno grave que permitía la escalada de privilegios en el sistema, pero manteniendo sudo actualizado la delegación de identidades por acciones es altamente segura.

Related Posts Plugin for WordPress, Blogger...