jueves, 29 de octubre de 2015

Cracking WPA2 PSK/WPA PSK por fuerza bruta

Algunos aún nos acordamos de los garrafales fallos de seguridad que tenía el protocolo WEP para redes inalámbricas, que en cuestión de minutos y con o sin clientes conectados, cualquiera podía hackearnos el acceso inyectando tráfico y sacando nuestra contraseña. Tras esto y por esto surgieron los protocolos WPA y WPA2 para aumentar la seguridad de este tipo de redes pero ¿Realmente son inexpugnables?
Para responder a esa pregunta deberemos diferenciar 3 escenarios.
  • El primer escenario es puramente con los protocolos WPA/WPA2 y su utilización sin tecnologías complementarias tales como WPS. En este escenario podemos considerar segura una red wifi que los implemente.
  • El segundo escenario, que es el más extendido, es el uso de una de las variantes de WPA/WPA2 que es WPA PSK/WPA2 PSK. En este escenario, tal y como vamos a procedimentar a lo largo de este artículo, no se pueden considerar seguras al darse el caso de poderse crackear. Toda la seguridad de estas redes quedará soportada por la complejidad de la contraseña y este hecho en la mayoría de los casos es un riesgo en si mismo dado que muy poca gente/empresas cumplen una política de contraseñas adecuada (las empresas suelen tener unas políticas muy sesudas en cuanto a complejidad, longitud, frecuencia de cambio,…etc. Pero en pocos casos la cumplen).
  • El tercer escenario es tener combinadas una red inalámbrica con WPA/WPA2 más otra tecnología como por ejemplo WPS. El problema está en que independientemente de la seguridad que pueda darnos WPA/WPA2, estaremos absolutamente supeditados a que la tecnología complementaria que estemos utilizando no tenga fallos de seguridad. Por ejemplo cualquier red inalámbrica que tenga WPS 1.0 puede comprometerse en cuestión de minutos gracias al error descubierto por Stefan Viehböck.
Teniendo en cuenta lo descrito, la tecnología WPA PSK/WPA2 PSK puede ser válida para entornos puramente personales pero nunca para entornos profesionales/empresariales por la posibilidad de ser comprometida, debiendo elegir para estos entornos WPA/WPA2 puros. Además de lo anterior, donde he reflexionado sobre lo puramente tecnológico, deberemos tener en cuenta los fallos de seguridad que se dan en la capa 8 (Layer 8) y que pueden hacer sucumbir hasta el mejor diseño de seguridad tecnológica. Por ejemplo si tenemos una red wifi absolutamente robusta pero un usuario colabora con un ataque Wi-Phishing de manera involuntaria, todo nuestro trabajo habrá sido en vano. Al final del artículo expondré como debe configurarse una red inalámbrica segura.

¿Cómo funcionan WPA PSK y WPA2 PSK?

A efectos de filosofía, WPA y WPA2 funcionan de la misma manera, la diferencia que tienen es en como cifran cada uno las comunicaciones y como garantizan la integridad de las mismas:
  • WPA basa su cifrado en TKIP (Temporary Key Integrity Protocol) que está basado en ARC4 (como el protocolo WEB) y utiliza una versión antigua de MIC (Message Integrity Code) para garantizar la integridad del mensaje.
  • WPA2 basa su cifrado en CCMP (Counter-mode/CBC-MAC Protocol) basado en AES (Advanced Encrytion System) y utiliza una versión muy reciente de MIC (Message Integrity Code) para garantizar la integridad del mensaje.
A grandes rasgos, cuando un equipo se intenta conectar a un AP (Access Point) tendrá que pasar por 2 fases para conseguirlo, una primera fase de autentificación y otra de asociación. De esta manera se produce un intercambio de claves donde mediante la PSK tanto el cliente como el AP generarán la clave PMK y se utilizará durante la sesión en curso con el fin de garantizar que en esta comunicación no se producen problemas por ejemplo de suplantación por parte de un SSID malicioso. Con esta PMK más 2 números aleatorios generados uno por el cliente y otro por el AP e intercambiados entre ellos, se generará la clave PTK con la que se cifrarán todas las comunicaciones (esta PTK es idéntica para ambos). A este intercambio de información para la generación de la PTK se le llama 4-way-Handshake.

¿Que hace posible el ataque a la clave PSK?

Lo que posibilita el ataque es que si escuchamos toda la autenticación del cliente, previamente autenticado (con WPA PSK/WPA2 PSK no realizará el proceso de re-autenticación), tendremos capturadas la PMK, las MAC, los números aleatorios y los SSID. Con esto y sabiendo que la PMK se genera mediante el algoritmo PBKDF2 y que el único valor que nos falta es la PSK lo único que tendremos que hacer es probar frases con este algoritmo, comparando el resultado y una vez obtenido el valor tendremos la clave PSK que se ha usado en la autenticación. Y esta situación la podremos forzar gracias al ataque 0 o ataque de desautenticación, por esto elegiremos redes que tengan algún cliente conectado.

Pasos para realizar este ataque

Antes de empezar con los pasos indicar que el artículo se ha realizado con la tarjeta Tp-Link TL-WN722N que implementa un chip Atheros AR9271 y desde mi punto de vista es la mejor tarjeta para auditorías por su estabilidad, lo excelente que es escuchando y su gran relación calidad precio (menos de 15€). Si estáis probando con otra tarjeta y veis que no obtenéis el Handshake después de 5 minutos, creerme que es debido al chip que tenga vuestra tarjeta. Por ejemplo si probáis estos pasos con la tarjeta Edimax EW-7318USG que implementa un chip RT257, tardaréis una eternidad (o nunca lo conseguiréis) porque es algo sorda. Además de esto deberemos tener instalado el paquete aircrack-ng (para instalarlo en debian realizaremos un apt-get install aircrack-ng).

1-. Comprobamos que nuestro sistema reconoce la tarjeta wifi que le hemos pinchado. Para ello usamos el comando iwconfig.
METEMPSICOSIS ~ # iwconfig


2-. Ponemos nuestra tarjeta en modo monitor con el comando airmon-ng. En el paso anterior comprobamos que mi tarjeta es la wlan0 así que lanzaré el siguiente comando para ponerla en modo monitor y la interfaz mon0 que resulta es la que está en modo monitor y por tanto la que usaremos a lo largo de los siguientes pasos.
METEMPSICOSIS # airmon-ng start wlan0


3-. Miramos todas las redes que tenemos disponibles y deberemos elegir una que el tipo de autenticación sea PSK y tenga clientes conectados (recordamos que sin clientes conectados no los podemos desautenticar y por tanto no podemos escuchar la autenticación para obtener el handshake). Yo he generado una red para esta prueba que es METEMPSICOSIS con el BSSID 84:9C:A6:B0:4D:E9, que está en el canal 2 y que tiene un cliente conectado con MAC 7C:FA:DF:45:0B:0B.
METEMPSICOSIS # airodump-ng mon0


 4-. Ahora nos pondremos a capturar el tráfico. La estructura del comando es airodump-ng -w <nombre del archivo de la captura> -c <canal> --bssid <bssid del AP> <interfaz_en_modo_monitor>

METEMPSICOSIS # airodump-ng -w captura -c 2 --bssid 84:9C:A6:B0:4D:E9 mon0


5-.Ahora mientras estamos escuchado el trafico lanzamos el ataque de desautenticación o del 0 en otra pestaña/ventana/consola (es importantísimo no cerrar ni cancelar el comando anterior, tiene que seguir lanzado mientras ejecutemos este ataque, de lo contrario no escucharemos la autenticación.). La estructura del comando es aireplay-ng -0 <número de reintentos> -a <bssid del AP> -c <MAC del cliente conectado>. En principio con 50 reintentos tendremos suficiente pero si nuestra tarjeta es un poco sorda deberemos aumentarlo y si vemos que con más de 100 no conseguimos el handshake deberemos considerar el cambio de tarjeta.

METEMPSICOSIS # aireplay-ng -0 50 -a 84:9C:A6:B0:4D:E9 -c 7C:FA:DF:45:0B:0B mon0


6-. Una vez finalizado el ataque del 0 veremos cómo nos ha aparecido el handshake donde tenemos lanzado el comando que estaba escuchando las comunicaciones.


7-. Tras haber obtenido el handshake cancelaremos la escucha y comprobaremos que se ha generado el archivo .cap que contiene todo el contenido de nuestra escucha.


8-. Ahora tenemos 2 vertientes para conseguir la clave:
  • Usar un diccionario que tenemos generado para probar las claves.
    • A mi esta es la que más me gusta porque puedo generar un diccionario "especial" combinando los resultados de uno generado con crunch con otros diccionarios de referencia que podemos encontrar en la web,...etc.
      • La sintaxis del comandos es aircrack-ng -a 2 <nombre del archivo .cap> -e default -b <bssid del AP> -w diccionario
  • Utilizar crunch en vivo para, sin necesitar un diccionario previamente creado, probar claves.
    • La gran ventaja de esto es que no necesitamos nada de espacio en disco para almacenar el diccionario. Podéis consultar el artículo que escribí sobre como generar diccionarios con crunch.
      • La sintaxis del comandos es crunch <todas las opciones que requiera para generar el diccionario> ||  aircrack-ng -a 2 <nombre del archivo .cap> -e default -b <bssid del AP> -w -
    9-. Tras lanzarlo empezará el proceso que comprobará todas las claves candidatas.


    10-. En el momento que dé con la clave el proceso se parará indicándonos en pantalla la que es (yo he preparado un diccionario para el artículo con el fin de no tardar unos días).



    ¿Cómo evitar el ataque a la clave PSK?

    Para evitar este ataque deberemos evitar a toda costa que nos puedan realizar el ataque 0 sin realizar una re-autenticación posterior. Por ello deberemos montar una WPA/WPA2 de las denominadas empresariales. Esto es lo mismo que decir que la conexión debe estar configurada utilizando 802.1x para la autenticación del puerto y EAP a un servidor RADIUS para  autenticar la conexión. De esta manera evitaremos que tras el ataque se pase automáticamente a la fase de intercambio de claves.

    miércoles, 21 de octubre de 2015

    org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: SimpleFSLock@/opt/tomcat/repository/index/com.openkm.dao.bean.NodeBase/write.lock

    Cuando paramos OpenKM de una manera incorrecta, bien porque paramos el servidor que aloja la aplicación de OpenKM sin pararlo primero de manera ordenada o bien porque matamos el servicio de la aplicación directamente, es muy posible que se corrompan o se bloqueen los índices de lucene. De esta manera si tenemos una aplicación, por ejemplo en java, trabajando contra OpenKM y se nos produce este bloqueo o corrupción de los índices de lucene tendremos entre otros este conjunto de errores (los pongo con el fin de que a la gente le sea más fácil encontrar este artículo):
    • ERROR com.openkm.dao.HibernateUtil- could not init listeners
      org.hibernate.HibernateException: could not init listeners
       
    • ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/OpenKM].[CXFServlet]- El Servlet.service() para el servlet [CXFServlet] en el contexto con ruta [/OpenKM] lanzó la excepción [La ejecución del Filtro lanzó una excepción] con causa raíz
      org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: SimpleFSLock@/opt/tomcat/repository/index/com.openkm.dao.bean.NodeBase/write.lock

    Pasos para solucionarlo

    Antes de nada indicar que mi tomcat, donde esta desplegado OpenKM, está instalado en /opt/tomcat/ y el directorio donde se encuentra el repositorio de OpenKM lo tengo en /opt/tomcat/repository/.

    1.- Entramos en el directorio bin de nuestro tomcat.
    [root@openkm ~]# cd /opt/tomcat/bin/

    2.- Paramos el servicio de tomcat donde está desplegado OpenKM.
    [root@openkm: /opt/tomcat/bin/]# ./shutdown.sh

    3.- Como siempre, es recomendable realizar un backup del directorio index, que es donde se almacenan los índices de lucene sobre los que vamos a realizar las siguientes acciones. Para ello basta con realizar un tar del directorio.
    [root@openkm: /opt/tomcat/bin/]#  tar -czvf index.tar.gz /opt/tomcat/repository/index

    4.- Eliminamos el directorio index de nuestro repositorio
     [root@openkm: /opt/tomcat/bin/]# rm -rf /opt/tomcat/repository/index

    5.- Levantamos el tomcat que tiene el OpenKM
    [root@openkm: /opt/tomcat/bin/]# ./startup.sh

    Tras esto OpenKM regenerará toda la estructura de índices de lucene. No os preocupéis si a priori no veis que se ha vuelto a generar la carpeta index y su contenido cuando lo arrancamos tras borrarla porque lo regenerará en el momento en el que empecemos a descargar, subir o ver documentos.

    sábado, 10 de octubre de 2015

    Error ORA-28000: the account is locked

    Cuando al intentar logarnos en una base de datos Oracle nos da el error ORA-28000: the account is locked, significa que el usuario con el que estamos intentando entrar está bloqueado (es posible que por superar el número máximo de intentos erróneos al realizar login). Ante esto tenemos 2 posibles escenarios:

    1- Conocemos otro usuario con permisos para desbloquear usuarios
    Si estamos en esta situación  deberemos logarnos con él y lanzar la siguiente consulta para verificar que el usuario está bloqueado. En el ejemplo que pongo a continuación voy a coger el usuario APEX_PUBLIC_USER:
    SQL> select username,account_status from dba_users;                               

    USERNAME                       ACCOUNT_STATUS
    ------------------------------              --------------------------------
    SYSTEM                               OPEN
    SYS                                       OPEN
    ANONYMOUS                      OPEN
    APEX_PUBLIC_USER          LOCKED
    APEX_040000                       LOCKED
    OUTLN                            EXPIRED & LOCKED
    XS$NULL                        EXPIRED & LOCKED
    XDB                                 EXPIRED & LOCKED
    CTXSYS                           EXPIRED & LOCKED
    MDSYS                            EXPIRED & LOCKED
    FLOWS_FILES                EXPIRED & LOCKED

    USERNAME                       ACCOUNT_STATUS
    ------------------------------               --------------------------------
    HR                                      EXPIRED & LOCKED


    Y una vez comprobado que el usuario realmente tiene el estatus bloqueado (LOCKED) lo desbloqueamos con la siguiente consulta:

    SQL> alter user APEX_PUBLIC_USER account unlock;

    Tras esto el usuario estará desbloqueado. Lo podemos comprobar lanzando de nuevo la consulta anterior:

    SQL> select username,account_status from dba_users;                              

    USERNAME                       ACCOUNT_STATUS
    ------------------------------             --------------------------------
    SYSTEM                                   OPEN
    SYS                                          OPEN
    ANONYMOUS                         OPEN
    APEX_PUBLIC_USER             OPEN
    APEX_040000                         LOCKED
    OUTLN                            EXPIRED & LOCKED
    XS$NULL                        EXPIRED & LOCKED
    XDB                                EXPIRED & LOCKED
    CTXSYS                          EXPIRED & LOCKED
    MDSYS                           EXPIRED & LOCKED
    FLOWS_FILES               EXPIRED & LOCKED

    USERNAME                       ACCOUNT_STATUS
    ------------------------------             --------------------------------
    HR                                    EXPIRED & LOCKED




    2- Es el único usuario que tenemos para acceder a la base de datos y está bloqueado
    En este caso deberemos acceder sin credenciales como indiqué en el artículo ERROR ORA-01017: invalid username/password; logon denied y en el momento que hayamos accedido al servidor realizaremos el paso 1.