Archive

Archive for the ‘Services – Software’ Category

Recolección de información con OSINT Parte 2 – Usando Google Hacking Python Client

abril 16, 2015 1 comentario

En el post anterior se ha visto la forma en la que se puede utilizar la librería python-twitter para acceder al inmenso volumen de información almacenada en Twitter. Dicha librería es capaz de utilizar los servicios REST que dispone Twitter para que los desarrolladores puedan acceder a su plataforma de forma programática. Así es posible extraer información sobre cuentas públicas en Twitter y realizar búsquedas aplicando varios criterios. En este artículo mencionaré otra librería frecuentemente utilizada en procesos relacionados con OSINT, dicha librería es “google-api-python-client”. Se trata de una librería que cuenta con clases y utilidades para extraer información pública contenida en varios de los servicios de Google.
El proceso de instalación de esta librería es bastante trivial y se puede llevar a cabo utilizando “pip”, “easy_install” o tirando directamente del código fuente que se encuentra alojado en la siguiente ruta: https://github.com/google/google-api-python-client. No obstante, además de instalar la librería también es necesario crear una aplicación de consola de Google, para lo cual es necesario tener una cuenta valida. Para aquellos que nunca han creado una aplicación desde el gestor de de aplicaciones de Google, a continuación se explica el procedimiento a seguir.

Creando una aplicación con Google Developers Console.

Con una cuenta de Google valida y estando autenticado en cualquiera de sus servicios (como por ejemplo Gmail), es posible utilizar la consola de administración de aplicaciones que Google dispone para los desarrolladores. Dicha consola se encuentra disponible en el siguiente enlace: https://console.developers.google.com y como se puede apreciar en la siguiente imagen, después de pinchar sobre el botón “Create Project” se debe poner un nombre al proyecto y un identificador único. El identificador lo puede generar Google por ti o puedes ingresar uno propio.

osint2-1

Una vez creada la aplicación, el siguiente paso consiste en activar los servicios que se desea utilizar. La lista es bastante larga y cada servicio corresponde a una temática muy concreta, por ejemplo, es posible activar Calendar API, Books API, Drive API, BigQuery API, Custom Search API, etc. Si el lector está interesando en ver todas las aplicaciones a las que se puede acceder de forma programática utilizando la librería, puede ver el listado del siguiente enlace: https://developers.google.com/api-client-library/python/apis/.

El proceso de activación de cualquiera de las APIs disponibles es bastante simple y con una cuenta gratuita se incluyen varias características que en la mayoría de los casos son más que suficientes. Por ejemplo, el servicio de búsquedas de Google es “Custom Search API” y tiene una limitación de 1000 búsquedas al día, algo que para fines no comerciales, resulta muy aceptable. Otro servicio interesante es el BigQuery API, en el que se puede utilizar la infraestructura de Google para realizar procesos de minería de datos y Big Data, algo de lo que os hablaré en un próximo artículo.
Para realizar las pruebas, se habilitará el servicio “Custom Search API” y posteriormente, se debe crear el conjunto de claves para poder consumir el servicio con las credenciales y la autorización necesaria. Para ello existe la opción “Credentials” bajo el menú “APIs & auth”.

 

osint2-2

Tal como se puede apreciar en la imagen anterior, es posible utilizar dos mecanismos de autenticación, por un lado podemos generar los tokens de OAuth2 o crear un identificador único para el acceso. La diferencia entre ambos mecanismos es que utilizando los tokens de OAuth se gestionan detalles de acceso y autorización, algo que resulta vital para ciertos servicios que requieren consentimiento por parte del creador de la aplicación para que otros usuarios puedan utilizarla, mientras que en el caso del identificador único de acceso, se hace una validación simple y en cualquier caso, a servicios que no requieran autorización previa, como es el caso de la ejecución de búsquedas simples utilizando el buscador de Google. El servicio de Custom Search API no necesariamente requiere autenticación Oauth, con lo cual se puede crear una nueva API Key. A la fecha de redactar este artículo la creación de una API solicita un tipo concreto de clave, entre los posibles valores a seleccionar se encuentran: “Server”, “Browser”, “Android”, “iOS”. Se debe seleccionar el tipo de clave dependiendo de la forma en la que la aplicación (que evidentemente actuará como cliente) se conectará al servicio de Google en cuestión. En este caso concreto se puede seleccionar “Server” y en tal caso, se solicitará restringir el acceso por dirección o segmento de direcciones IP, en el caso de no ingresar ningún valor, la API admitirá cualquier cliente sin importar su dirección IP.

Llegados a este punto, ya es posible comenzar a utilizar la librería y para ello, es necesario crear una instancia de la API de google por medio de la función “build” contenida en el módulo “apiclient.discovery”.

La función “build” recibe como argumentos el nombre del servicio que se desea utilizar, la versión y las credenciales de acceso al servicio. Por ejemplo, para acceder al servicio de Books API y Custom Search API, se utiliza la función de la siguiente forma:


serviceBooks = build('books', 'v1', developerKey=”<api_key>”)

serviceCustomSearch = build("customsearch","v1",developerKey="<api_key>")

Como se puede apreciar, crear una instancia de cualquier servicio es una tarea bastante simple, no obstante, no todos los servicios de Google se gestionan de igual manera y algunos de ellos, como es el caso de Custom Search API, es necesario crear un nuevo motor de búsqueda personalizado contra un sitio web en Internet y posteriormente, recuperar el identificador del motor creado o su URL pública para que puedan ejecutarse las peticiones correctamente contra el servicio. Para crear un motor de búsqueda personalizado de Google se debe ingresar al sitio de administración de motores ubicado en la siguiente ruta: https://www.google.com/cse/all

Desde allí se puede crear un motor y tal como se enseña en las siguientes imágenes, es necesario definir sobre cuáles sitios se deben realizar las búsquedas.

 osint2-3Creación de un motor de búsqueda personalizado.

 osint2-4Motor de búsqueda creado.

El siguiente paso para poder utilizar la API desde cualquier script en Python es el de obtener el identificador del motor de búsqueda, que tal como se enseña en la siguiente imagen, se encuentra disponible tras pinchar sobre el botón “ID de motor de búsqueda”.

osint2-5

Una vez obtenido el identificador del motor de búsqueda, se puede utilizar la única función definida en el servicio correspondiente a Custom Search API, la cual permitirá utilizar el motor para realizar búsquedas sobre los dominios previamente definidos.

from apiclient.discovery import build 
service = build("customsearch","v1",developerKey="<api_key>")

results= service.cse().list(q="python",
			cx="<id_engine>" ,num=10).execute()

Como se puede apreciar, utilizar Python para realizar una búsqueda sobre el servicio Custom Search API es bastante simple, solamente es necesario especificar el criterio de búsqueda, el identificador del motor y el número de resultados que se obtendrán de la consulta. Estas búsquedas son dirigidas contra uno o varios sitios concretos, lo que supone una ventaja a la hora de recolectar información concreta sobre, por ejemplo, los usuarios de redes sociales como Twitter o Facebook.

Los resultados devueltos se encuentran en formato JSON, pero la API hace la labor de convertir la cadena devuelta por el servicio en un diccionario que pueda ser tratado directamente desde Python.


from apiclient.discovery import build 

service = build("customsearch","v1",developerKey="<api_key>")
res = service.cse().list(q="python", cx="<id_engine>" ,num=10).execute()
print res.keys()
print res['url']
print res['queries']
print res['searchInformation']

Hasta este punto, solamente se han realizado búsquedas, sin embargo esto solamente es la punta del iceberg, ya que faltan labores mucho más complejas para analizar y relacionar la información obtenida. En próximas entradas se hablará un poco más sobre esto.

Saludos y Happy Hack!
Adastra.

HoneyPots Parte 3 – Configuración y análisis de malware con Dionaea

abril 14, 2015 Deja un comentario

En el articulo anterior he hablado sobre el funcionamiento e instalación de Dionaea, un honeypot que es capaz de detectar payloads maliciosos y recolectar muestras de malware para su posterior análisis. Para la detección de shellcodes utiliza otra librería de la que ya se ha hablado anteriormente llamada LibEmu, la cual utiliza varias técnicas avanzadas para encontrar patrones maliciosos basadas en heurísticas del tipo GetPC. En este articulo, se continuará con la exploración de las funcionalidades incluidas en Dionaea y las opciones de configuración que se pueden utilizar para modificar el comportamiento del programa según las necesidades particulares del “blue team” o equipo defensor.

En primer lugar, el fichero de configuración del programa se encuentra ubicado en la siguiente ruta (suponiendo que el software se ha instalado en el directorio /opt/dionaea): “/opt/etc/dionaea/dionaea.conf”.

Cuando se trabaja con ficheros de configuración, algo que es de agradecer es que sean fáciles de entender y se encuentren debidamente separados por secciones. Esto es algo que tiene Dionaea y cuando se abre el fichero de configuración por defecto, rápidamente se pueden apreciar las siguientes secciones de configuración: “logging”, “processors”, “downloads”, “submit”, “bistreams”, “listen” y “modules”. A continuación, se explica brevemente para que sirve cada uno de estos bloques de configuración.

“logging”: Es una sección que puede ayudar a ver las trazas que realmente son importantes y que ayudan a detectar un ataque en curso. Configurar adecuadamente esta sección puede ser bastante conveniente, ya que Dionaea es un programa que genera muchísimas trazas de log que en la mayoría de los casos resultan abrumadoras y poco informativas. En esta sección es posible establecer diferentes niveles de trazas, tales como info, debug, warning, error y all. Por defecto, las trazas generadas por Dionaea se almacenan en el directorio “/opt/dionaea/var/log”.

“processors”: Permite definir los servicios que debe arrancar el programa, tales como SSH, MSSqld, FTP, etc. Además, permite definir una serie de detalles de configuración sobre el proceso de emulación de cada uno de dichos servicios, pudiendo establecer detalles como el número de sockets, número máximo de conexiones abiertas y otros detalles que permiten controlar el funcionamiento de LibEmu.

“downloads”: En esta sección se define el directorio en donde se deben guardar las muestras de malware recolectadas por el honeypot.

“bistreams”: En esta sección se define el directorio en donde se guardarán los registros de la interacción entre el atacante y el honeypot, lo que permitirá posteriormente replicar los ataques y depurar.

“submit”: Además guardar las muestras de malware recolectadas por el honeypot en la máquina local, también es posible transferir dichas muestras por http o ftp a un servidor externo. En esta sección se pueden definir los detalles de conexión a dichos servidores externos en el caso de que se quiera enviar el malware a un motor de análisis ubicado en una máquina remota, como por ejemplo, una que tenga Cuckoo en ejecución.

“listen”: Permite definir las interfaces de red que serán utilizadas por el honeypot para arrancar cada uno de los servicios definidos en la sección de “processors”. Existen 3 modos, el automático vincula todas las interfaces de red encontradas en el sistema, el manual permite definir cuales serán las interfaces de red utilizadas y finalmente, el tercer mecanismo permite definir una expresión regular para recuperar todas las interfaces de red que cumplan con el patrón definido.

“modules”: Finalmente, en esta sección se pueden definir detalles de configuración de los módulos que utiliza Dionaea. Algunos de los módulos más interesantes que soporta este honeypot son LibEmu, p0f, curl, nfq, python, fail2ban, entre otros.

Después de explicar las principales secciones de configuración del programa, ahora se procede a utilizar Dionaea y ver cómo funciona cuando un atacante intenta hacerse con el control de un servicio ejecutado en el honeypot.

Arrancando Dionaea y detectando posibles ataques

Una buena practica a la hora de arrancar Dionaea es utilizar un usuario del sistema con privilegios limitados, para ello se utilizan los interruptores “-u” y “-g”.

>./dionaea -L ‘*’ -u adastra -g users

 

Después de levantar Dionaea (en una máquina virtual preferiblemente), lo primero que se puede hacer es ejecutar un escaneo contra dicha máquina para ver qué puertos se encuentran abiertos.

>nmap -sT -n 192.168.1.98

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-15 23:46 CETNmap scan report for 192.168.1.98
Host is up (0.00012s latency).Not shown: 989 closed ports
PORT STATE SERVICE
21/tcp open ftp

22/tcp open ssh

42/tcp open nameserver

80/tcp open http

135/tcp open msrpc

443/tcp open https

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3306/tcp open mysql

5060/tcp open sip

5061/tcp open sip-tls

 

Como se puede apreciar, aparecen servicios como MSSql, SIP, MySQL y SMB, todos ellos servicios que ha levantado automáticamente Dionaea.

Ahora bien, se puede utilizar metasploit framework para probar el comportamiento de Dionaea cuando un atacante intenta enviar peticiones maliciosas contra alguno de los servicios que se encuentran activos.

SMB es un buen protocolo para probar, ya que existen varios exploits disponibles para atacar este tipo de servicios.

>msfconsolemsf>use exploit/windows/smb/ms06_040_netapi
msf exploit(ms06_040_netapi) >set PAYLOAD windows/shell/bind_tcp
PAYLOAD => windows/shell/bind_tcp
msf exploit(ms06_040_netapi) > set RHOST 192.168.1.98

RHOST => 192.168.1.98

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

 

Posteriormente, en el fichero de logs de Dionaea se podrán ver varios registros que indican el intento de ataque. Dicho fichero por defecto se encuentra ubicado en “/opt/dionaea/var/log/dionaea.log”.

[15032015 23:52:00] connection connection.c:1745-debug: connection_stats_accounting_limit_exceeded stats 0x2b8d720[15032015 23:52:01] pcap pcap.c:180-debug: 192.168.1.98:4444 -> 192.168.1.98:55386[15032015 23:52:01] pcap pcap.c:190-debug: reject local:’192.168.1.98:4444′ remote:’192.168.1.98:55386′[15032015 23:52:01] incident incident.c:365-debug: reporting 0x2c66a20[15032015 23:52:01] incident incident.c:354-debug: incident 0x2c66a20 dionaea.connection.tcp.reject[15032015 23:52:01] incident incident.c:167-debug: con: (ptr) 0x2c67c20[15032015 23:52:01] python module.c:778-debug: traceable_ihandler_cb incident 0x2c66a20 ctx 0x2a134d0[15032015 23:52:01] logsql dionaea/logsql.py:637-info: reject connection from 192.168.1.98:55386 to 192.168.1.98:4444 (id=1005)

[15032015 23:52:01] connection connection.c:667-debug: connection_free_cb con 0x2c67c20

[15032015 23:52:01] connection connection.c:676-debug: AF 0 0 con->local.domain

 

Además de los logs, también se almacenan los flujos de entrada y salida en el directorio “/opt/dionaea/var/dionaea/bistreams”. Se puede también probar otros exploits que intenten comprometer el servicio SMB como es el caso del conocidio exploit “LSASS”.

msf exploit(ms06_040_netapi) > use exploit/windows/smb/ms04_011_lsass
msf exploit(ms04_011_lsass) > set RHOST 192.168.1.98
RHOST => 192.168.1.98
msf exploit(ms04_011_lsass) > exploit

[*] Started reverse handler on 192.168.1.98:4444

[*] Binding to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Bound to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Getting OS information…

[*] Trying to exploit Windows 5.1

 

Dionaea es capaz de detectar el ataque y registrarlo en el fichero de logs.

[16032015 00:16:41] connection connection.c:4349-debug: connection_unref con 0x2b8d320[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c001530 dionaea.shellcode.detected[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c001530 ctx 0x2a134d0[16032015 00:16:41] thread threads.c:52-debug: Thread fn 0x41d38d con 0x2b8d320 data 0x2c5a760 took 0.000018 ms[16032015 00:16:41] incident incident.c:212-debug: could not find key ‘con'[16032015 00:16:41] incident incident.c:365-debug: reporting 0x7fd24c0711d0[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c0711d0 dionaea.module.emu.profile[16032015 00:16:41] incident incident.c:167-debug: profile: (string) [

{

“call”: “LoadLibraryA”,

“args” : [

“ws2_32″

],

“return” : “0x71a10000″

}

]

[16032015 00:16:41] incident incident.c:167-debug: con: (ptr) 0x2b8d320

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a0cfc8

[16032015 00:16:41] emu dionaea/emu.py:45-debug: profiling

[16032015 00:16:41] emu dionaea/emu.py:53-info: profiledump [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]

[16032015 00:16:41] connection connection.c:1368-debug: connection_sustain_timeout_set 0x2b8d320 3.000000

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a134d0

[16032015 00:16:41] logsql dionaea/logsql.py:699-info: emu profile for attackid 1009

 

Puede ser muy complicado buscar y encontrar información útil sobre los incidentes reportados por el honeypot en los logs, por este motivo existe una base de datos SQLite que almacena todos los resultados relevantes. Para consultarla basta con ejecutar la utilidad “readlogsqltree”.

>python /opt/dionaea/bin/readlogsqltree /opt/dionaea/var/dionaea/logsql.sqlite

 

Los resultados que enseña la ejecución anterior son mucho más condensados y fáciles de leer, ya que identifica únicamente aquellos registros que Dionaea ha detectado como incidentes o intentos de ataque.

dcerpc request: uuid ‘3919286a-b10c-11d0-9ba8-00c04fd92ef5′ (DSSETUP) opnum 9 (DsRolerUpgradeDownlevelServer (MS04-11))profile: [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]2015-03-16 00:28:17connection 1010 SipSession udp connect 192.168.1.98:5060 -> /192.168.1.98:47685 (1010 None)Method:OPTIONSCall-ID:78617845@192.168.1.98User-Agent:LJtDLdXwaddr: <> ‘sip:nobody@192.168.1.98:None’

to: <> ‘sip:nobody@192.168.1.98:None’

contact: <> ‘sip:nobody@192.168.1.98:None’

from: <> ‘sip:LJtDLdXw@192.168.1.98:5060′

via:’UDP/192.168.1.98:5060′

 

Por otro lado, cuando un exploit transfiere algún tipo de fichero a la máquina atacada, el honeypot captura y almacena dicho fichero en el directorio que se ha definido en la sección de configuración “downloads”. Dichos ficheros pueden ser utilizados posteriormente para ser analizados con Cuckoo o con cualquier otra herramienta de análisis de malware.

msfcli exploit/windows/smb/ms10_061_spoolss PNAME=XPSPrinter RHOST=192.168.1.98 EXITFUNC=process LHOST=192.168.1.98 LPORT=4444 E
[*] Initializing modules…PNAME => XPSPrinter
RHOST => 192.168.1.98
EXITFUNC => process
LHOST => 192.168.1.98

LPORT => 4444

[*] Started reverse handler on 192.168.1.98:4444

[*] Trying target Windows Universal…

[*] Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Attempting to exploit MS10-061 via \\192.168.1.98\XPSPrinter …

[*] Printer handle: 0000000000000000000000000000000000000000

[*] Job started: 0x3

[*] Wrote 73802 bytes to %SystemRoot%\system32\jv3zNgf80OaKcs.exe

[*] Job started: 0x3

[*] Wrote 2237 bytes to %SystemRoot%\system32\wbem\mof\tOpOFGImh6sT6j.mof

[-] Exploit failed: NoMethodError undefined method `unpack’ for nil:NilClass

 

En este caso concreto, al utilizar el exploit SMB Spoolss, se transfiere un fichero malicioso al servicio atacado y Dionaea lo almacena en el directorio “/opt/dionaea/var/dionaea/binaries”

 

>ls -l var/dionaea/binaries/
total 152
-rw——- 2 adastra adastra 73802 mar 16 00:45 c9a0a0ccbd330b43d5196cd69b80159d-rw——- 2 adastra adastra 73802 mar 16 00:45 spoolss-d1fgrg.tmp
>file var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d

var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d: PE32 executable (GUI) Intel 80386, for MS Windows


>file var/dionaea/binaries/spoolss-d1fgrg.tmp

var/dionaea/binaries/spoolss-d1fgrg.tmp: PE32 executable (GUI) Intel 80386, for MS Windows

El programa descargado es un ejecutable PE para sistemas Windows, capturado y almacenado por Dionaea.

Saludos y Happy Hack!
Adastra.

HoneyPots Parte 2 – Introducción a Dionaea

marzo 26, 2015 Deja un comentario

Dionaea es un honeypot realmente interesante, ya que su principal objetivo es la captura y análisis de muestras de malware. Es capaz de levantar varios tipos de servicios y esperar a que los atacantes intenten hacerse con el control de dicho servicio por medio de peticiones maliciosas y el envío de payloads. Dionaea utiliza la librería libemu para la detección de shellcodes y tal como se ha mencionado en un articulo anterior sobre dicha librería, se utilizan heurísticas GetPC/GetEIP para determinar si un payload determinado es malicioso y en algunos casos, ejecutarlo en un entorno controlado de ser necesario.

Una instancia de Dionaea puede levar varios tipos de servicios, entre los que destacan HTTP, FTP, TFTP, SMB, entre otros. Cada uno de estos servicios se encuentra especialmente preparado para captar la atención de un atacante y que intenté enviar una muestra de malware, ya que al final de cuentas, es el objetivo de este honeypot.

El funcionamiento general de Dionaea se resume de una forma muy bien explicada en el sitio web oficial del proyecto (http://dionaea.carnivore.it/) sin embargo, también intentaré explicarlo de la mejor forma que pueda en los siguientes párrafos.

Antes que nada, este honeypot sigue un “workflow” bastante simple en el que se definen cada una de las fases de captura, detección, análisis y posterior categorización de muestras de malware, dichas fases se resumen brevemente a continuación:

Conectividad y protocolos soportados por Dionaea

Una de las principales características de este honeypot, es que soporta rutinas no bloqueantes, lo que mejora considerablemente el desempeño general del sistema y permite ejecutar múltiples operaciones de escritura y lectura sobre uno o varios sockets sin necesidad de esperar una respuesta por parte del receptor. Estas características en Dionaea son implementadas utilizando Python y tal como os comentaba en algún post anterior, para crear “corutinas” se puede utilizar el módulo asyncio que ya viene incluido en a partir versión 3.x de Python, así como también otros módulos como Twisted o Tornado que sirven básicamente para lo mismo. Dionaea en este caso utiliza el módulo asyncio y además, también utiliza las librerías libudns y libev para peticiones DNS no bloqueantes y recibir notificaciones sobre diferentes tipos de eventos en el entorno de red respectivamente.

Por otro lado, tal como se puede apreciar también en la documentación, los protocolos soportados por Dionaea son implementaciones propias del honeypot y en algunos casos, como por ejemplo para el servicio SMB, se implementan completamente en Python.

 

Intentos de explotación y detección del malware

Cuando un atacante comienza a comprobar que el supuesto servicio puede ser vulnerable, lo más probable es que comience a atacarlo por medio de peticiones maliciosas y el envío de payloads que puedan “reventar” el proceso remoto. En este caso, el proceso de perfilado es realizado por Libemu registrando todas las invocaciones a las funciones del sistema con sus correspondientes argumentos, es decir, haciendo un “hooking” de cada una de las funciones definidas en el programa. No obstante, existen muchos shellcodes que son “multi-stage”, los cuales ejecutan una rutina de código simple que únicamente se encarga de descargar de un sitio remoto otro(s) shelcode(s). En este caso concreto, únicamente registrando las invocaciones a las funciones del sistema no seria suficiente para perfilar el programa y por este motivo, Dionaea también permite la ejecución del shellcode con el fin de determinar cuál es el objetivo del programa. Evidentemente, para esto muy posiblemente será necesario permitir que el shellcode realice conexiones de red, por este motivo es muy recomendado ejecutar el honeypot en una máquina virtual y de ser posible, aislada del segmento de red interno.

Finalmente, cuando el shellcode ha sido perfilado tras el registro de las funciones invocadas y/o las conexiones de red que se han llevado a cabo tras la ejecución del programa malicioso, Dionaea es capaz de determinar la intención del programa y categorizarlo. Las categorías que maneja Dionaea para clasificar muestras de malware son: Consolas bind y reversas, programas que ejecutan la función WinExec, programas que utilizan la función URLDowloadToFile y payloads multi-staged.

 

Registro y sistema de incidentes

Finalmente el honeypot procede a guardar una copia del shellcode y a registrar cada una de las acciones que ha realizado el programa para posterior análisis. Por otro lado, también cuenta con un sistema de incidentes que permite ver rápidamente las conclusiones más relevantes sobre el programa analizado, sin necesidad de navegar por enormes ficheros de log en busca de dichos resultados.

Instalación de Dionaea

Cuando se le echa un vistazo al proceso de instalación explicado en la página web de Dionaea, muy probablemente lo primero que piensa más de uno es “esto no lo instala ni dios”, pero la realidad es que el proceso es bastante simple, siempre y cuando se sigan todos los pasos explicados y se cumpla con todas las dependencias exigidas. Algunas de dichas dependencias casi seguro ya se encuentran en el sistema mucho antes de comenzar con la instalación, tales como libcurl o LibEmu si has seguido el articulo anterior, pero la mayoría deben instalarse manualmente desde el código fuente de cada una de las dependencias.

Como regla general, es mejor seguir cada uno de los pasos descritos en el siguiente enlace: http://dionaea.carnivore.it/#compiling Además, tener en cuenta que el “prefijo” (opción prefix del ejecutable “configure”) debe apuntar al directorio “/opt/dionaea” por lo tanto dicho directorio debe ser accesible para el usuario con el que se realice el proceso de instalación. Una recomendación que lo permitirá instalar rápidamente, consiste en descargar y desempaquetar todas las librerías en el directorio “/opt” y ejecutar la construcción (configure), compilación (make) e instalación (make install).
Después de instalar todas las dependencias, es necesario descargar el proyecto desde el GitHub y para ello, también se puede ubicar en el directorio “/opt”, pero asignando un nombre distinto al directorio de salida, ya que “/opt/dionaea” ya existe y contiene todas las librerías y dependencias que se han ido instalando. Se puede ejecutar algo como esto:

git clone git://git.carnivore.it/dionaea.git
			dionaea-git

 

Posteriormente, desde el directorio “/opt/dionaea-git” se puede ejecutar el mismo procedimiento de instalación descrito en la página.
En mi caso concreto, no he tenido ningún problema instalando Dionaea en sistemas Debian Squeeze y Wheezy, sin embargo, en el caso de Ubuntu, en la versión 14.04 hay un problema con el enlazado de la librería “libcrypto” dando un error similar al siguiente cuando se ejecuta el comando “make”.

 

/usr/bin/ld: note: ‘X509_gmtime_adj’ is defined in DSO /lib/libcrypto.so.10 so try adding it to the linker command line

/lib/libcrypto.so.1.0.0: could not read symbols: Invalid operation

 

En tal caso es necesario realizar el enlace de dicha librería de forma manual. Para ello, es necesario dirigirse al directorio “/opt/dionaea-git/src” y ejecutar la utilidad “libtool” para enlazar a la librería “libcrypto.so”

 

../libtool –tag=CC –mode=link gcc -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -I/opt/dionaea/include/ -I../include -I .. -fno-strict-aliasing -std=c99 -D_GNU_SOURCE -D_GNU_SOURCE -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -Wall -Werror -Wstrict-prototypes -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -Wl,–export-dynamic -pthread -o dionaea dionaea-dionaea.o dionaea-dns.o dionaea-refcount.o dionaea-node_info.o dionaea-util.o dionaea-connection.o dionaea-modules.o dionaea-pchild.o dionaea-log.o dionaea-signals.o dionaea-incident.o dionaea-threads.o dionaea-bistream.o dionaea-processor.o -L/opt/dionaea/lib /opt/dionaea/lib/libev.so -lm -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -L/opt/dionaea/lib/ /opt/dionaea/lib/liblcfg.so -L/usr/local/lib -lssl -ludns -pthread -Wl,-rpath -Wl,/opt/dionaea/lib -Wl,-rpath -Wl,/opt/dionaea/lib /lib/x86_64-linux-gnu/libcrypto.so.1.0.0

 

Notar que ha sido necesario especificar la ubicación de la librería y en este caso concreto, se encuentra en “/lib/x86_64-linux-gnu/libcrypto.so.1.0.0” pero evidentemente puede cambiar un poco dependiendo del sistema y de la arquitectura utilizada.

Después de ejecutar los comandos de compilación e instalación en “dionaea-git”, se generará un ejecutable con nombre “dionaea” junto con otras utilidades en el directorio “/opt/dionaea/bin”.

Para comprobar que la instalación ha sido correcta y que se puede levantar el honeypot normalmente, se puede ejecutar la utilidad “/opt/dionaea/bin/dionaea” de la siguiente forma.

> ./dionaea -l all,-debug

 

Se podrán ver varias trazas relacionadas con el arranque de cada uno de los servicios del honeypot, pero tal como se puede ver en el listado de interruptores de la herramienta, se trata de un software que es altamente configurable y con el que se pueden crear soluciones defensivas y de alerta temprana muy interesantes.

>./dionaea -H

Dionaea Version 0.1.0

Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2

Started on Galilei running Linux/x86_64 release 3.13.0-46-generic

Dionaea Version 0.1.0

Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2

Started on Galilei running Linux/x86_64 release 3.13.0-46-generic

-c, –config=FILE use FILE as configuration file

Default value/behaviour: /opt/dionaea/etc/dionaea.conf

-D, –daemonize run as daemon

-g, –group=GROUP switch to GROUP after startup (use with -u)

Default value/behaviour: keep current group

-h, –help display help

-H, –large-help display help with default values

-l, –log-levels=WHAT which levels to log, valid values all, debug, info, message, warning, critical, error, combine using ‘,’, exclude with – prefix

-L, –log-domains=WHAT which domains use * and ? wildcards, combine using ‘,’, exclude using –

-u, –user=USER switch to USER after startup

Default value/behaviour: keep current user

-p, –pid-file=FILE write pid to file

-r, –chroot=DIR chroot to DIR after startup, warning: chrooting causes problems with logsql/sqlite

Default value/behaviour: don’t chroot

-V, –version show version

Default value/behaviour:

-w, –workingdir=DIR set the process’ working dir to DIR

Default value/behaviour: /opt/dionaea

examples:

# dionaea -l all,-debug -L ‘*’

# dionaea -l all,-debug -L ‘con*,py*’

# dionaea -u nobody -g nogroup -w /opt/dionaea -p /opt/dionaea/var/run/dionaea.pid

En este corto articulo solamente se han visto las principales características de Dionaea, pero aun no se ha visto en ejecución utilizando algunos de los interruptores soportados por la herramienta y con opciones de configuración personalizadas en el fichero “dionanea.conf”. Esto es lo realmente interesante y lo explicaré en el próximo articulo que publicaré en este blog.

Saludos y Happy Hack!
Adastra.

HoneyPots Parte 1 – Kippo

marzo 24, 2015 Deja un comentario

Este será el primer articulo de una serie en la que se hablará sobre algunos de los honeypots más utilizados para la detección y prevención de ataques. Antes de continuar y para los que no lo saben, un Honeypot en informática es un servicio activo que acepta y procesa peticiones como cualquier servidor del tipo SSH, HTTP, SMB, etc. Pero en realidad se encarga de monitorizar y registrar los intentos fallidos de autenticación y cualquier ataque contra el supuesto servicio, se trata de un señuelo. Es una forma de engañar a un atacante haciéndole creer que se encuentra perfilando y analizando un servicio del objetivo, cuando en realidad lo que está haciendo es suministrándole información al objetivo sobre las actividades que está realizando.
Uno de los más conocidos y utilizados es Kippo, un honeypot que se encarga de levantar un servicio SSH en el puerto indicado y registrar todos los intentos de autenticación realizados contra dicho servicio. Kippo es un honeypot altamente personalizable y es posible utilizarlo para localizar a un atacante e incluso, para que pueda iniciar sesión en el supuesto sistema y permitirle interactuar con un sistema de ficheros ficticio, el cual también es configurable.

A continuación se explica como instalar y configurar Kippo en un sistema Linux.

Instalación y configuración de Kippo.

Kippo es un sistema que ha sido desarrollado utilizando Python y Twisted, una potente librería de la que ya he hablado en alguna ocasión. Una de las ventajas de Kippo, es que se puede lanzar de forma programática desde un script en Python gracias a las funciones definidas en el modulo “twistd” de Twisted, esto significa que puedes crear tus propios scripts en Python y arrancar Kippo en cualquier momento.

Para instalar Kippo, se debe tener Python instalado y algunas librerías en el entorno, tales como Twisted, PyCrypto y service_identity Zope. Una vez cumplidas dichas dependencias, se puede descargar el proyecto desde su repositorio en GitHub.

>git clone https://github.com/desaster/kippo.git

>ls -F

data/ doc/ honeyfs/ kippo.cfg.dist log/ start.sh* txtcmds/

dl/ fs.pickle kippo/ kippo.tac README.md stop.sh utils/

 

Lo primero que se puede apreciar en el directorio descargado, es que existen dos ficheros ejecutables que son “start.sh” y “stop.sh”, evidentemente son utilizados para iniciar y detener Kippo, pero antes de iniciar el Honeypot, se deben conocer las propiedades de configuración que permitirán personalizar el servicio y que sea más difícil para un atacante determinar que se trata de un honeypot. El script “start.sh” buscará el fichero de configuración “kippo.cfg” en el directorio desde donde se ejecuta y como se puede apreciar en el listado de contenidos del directorio, dicho fichero no existe, pero si que se puede ver el fichero “kippo.cfg.dist”, el cual se puede renombrar a “kippo.cfg”. El fichero “kippo.cfg.dist” contiene las propiedades que pueden ser útiles para iniciar el servicio con por la configuración defecto. Algunas de dichas propiedades (las más interesantes) se explican a continuación.

ssh_addr: Interfaz de red en la que iniciará el honeypot. El valor por defecto es “0.0.0.0”

ssh_port: Puerto en el que iniciará el honeypot. El valor por defecto es “2222”

hostname: Será cadena que verá un atacante cuando consiga una shell en el honeypot. Evidentemente, es una buena recomendación poner un nombre que parezca pertenecer a un servidor real en el objetivo.

download_path: Directorio en el que se guardaran todos los ficheros que intente descargar el atacante en el servidor.

filesystem_file: Probablemente es una de las propiedades más interesantes a la hora de engañar a un atacante haciéndole creer que se encuentra en un sistema legitimo, ya que esta propiedad se encarga de definir un sistema de ficheros completo, con sus correspondientes ficheros, permisos y demás. Este fichero se debe encontrar en formato de objetos serializados en Python (Pickle). Se puede utilizar el script “utils/createfd.py” para crear dicho sistema de ficheros partiendo de un sistema elegido por el usuario.

data_path: En el directorio indicado en esta propiedad se debe ubicar el fichero “usersdb.txt” en el se definirá por cada línea, el usuario y sus credenciales de acceso al supuesto honeypot. Evidentemente, se recomienda indicar una contraseña que sea fácilmente predecible para que el atacante pueda entrar y contar con más tiempo para saber de quien se trata.

txtcmds_path: En el directorio indicado en esta propiedad se deben definir los programas y utilidades que podrá ejecutar el atacante una vez se encuentre dentro del honeypot.

ssh_version_string: Será el banner que devolverá el servicio cuando se realicen peticiones sobre el puerto definido en la propiedad “ssh_port”

interact_enabled: Kippo permite controlar las sesiones que el atacante tenga iniciadas contra el honeypot en un servicio independiente de monitoreo. Por defecto dicha propiedad se encuentra desactivada, pero es muy útil para ver en tiempo real lo que está haciendo el atacante en el honeypot.

interact_port: Puerto en el que se iniciará el servicio de monitoreo. Solamente tiene sentido indicar un valor en esta propiedad si “interact_enabled” tiene el valor “true”.
Existen otras propiedades en Kippo que también pueden ser interesantes para el lector, por ese motivo se recomienda leer la documentación para hacerse una idea de cuáles son dichas propiedades.

Una buena practica para captar la mayor cantidad de atacantes, consiste en el definir el honeypot un puerto que no requiera privilegios de root para ser utilizado, como por ejemplo el “2222” y redireccionar todas peticiones entrantes por el puerto “22” al puerto donde está corriendo el honeypot. Esto puede hacerse muy fácilmente utilizando una regla de iptables como la siguiente.

iptables -t nat -A PREROUTING -p tcp –dport 22 -j REDIRECT –to-port 2222

Ahora bien, si se cuenta con un servicio SSH productivo, se recomienda levantarlo en un puerto distinto al “22”.

El siguiente fichero de configuración puede ser utilizado para arrancar Kippo con algunos valores de configuración personalizados.

[honeypot]

ssh_port = 2222

hostname = PROServer

log_path = log

download_path = dl

contents_path = honeyfs

filesystem_file = fs.pickle

data_path = data

txtcmds_path = txtcmds

rsa_public_key = data/ssh_host_rsa_key.pub

rsa_private_key = data/ssh_host_rsa_key

dsa_public_key = data/ssh_host_dsa_key.pub

dsa_private_key = data/ssh_host_dsa_key

exec_enabled = true

fake_addr = 172.28.78.10

ssh_version_string = SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

interact_enabled = true

interact_port = 5000

 

El fichero anterior debe ubicarse en el directorio de Kippo con el nombre “kippo.cfg”. Ahora es el momento de lanzar el script “start.sh” para iniciar el honeypot.

>./start.sh

twistd (the Twisted daemon) 14.0.0

Copyright (c) 2001-2014 Twisted Matrix Laboratories.

See LICENSE for details.

Starting kippo in the background…

EL servicio quedará abierto en el puerto “2222” y además, es posible ver los logs que ha generado Kippo en el proceso de arranque.

>cat log/kippo.log

2015-01-25 23:57:37+0100 [-] Log opened.

2015-01-25 23:57:37+0100 [-] twistd 14.0.0 (/usr/bin/python 2.7.6) starting up.

2015-01-25 23:57:37+0100 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-01-25 23:57:37+0100 [-] HoneyPotSSHFactory starting on 2222

2015-01-25 23:57:37+0100 [-] Starting factory <kippo.core.ssh.HoneyPotSSHFactory instance at 0x7fa27d2b67e8>

2015-01-25 23:57:37+0100 [-] Factory starting on 5000

2015-01-25 23:57:37+0100 [-] Starting factory <twisted.internet.protocol.Factory instance at 0x7fa27c03cd40>

>nc localhost 2222

SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

>

 

Como se puede ver, el banner devuelto por el servicio es el mismo que se ha definido en la propiedad “ssh_version_string”. Por otro lado, también se ha abierto el puerto “5000” para monitorizar el servicio. En dicho puerto se podrá acceder a una consola de administración básica que permitirá listar las sesiones activas, visualizar en tiempo real lo que el atacante está digitando en la consola del honeypot e incluso, interactuar con dicha sesión y escribir en la misma consola que el atacante está utilizando, algo que evidentemente despertaría sus sospechas.

>telnet -e q 127.0.0.1 5000

Telnet escape character is ‘q’.

Trying 127.0.0.1…

Connected to 127.0.0.1.

Escape character is ‘q’.

*** kippo session management console ***

List of commands:

list – list all active sessions

view – attach to a session in read-only mode

hijack – attach to a session in interactive mode

disconnect – disconnect a session

help – this help

exit – disconnect the console

 

En el fichero “log/kippo.log” se podrán ver las trazas de cada uno de los intentos de conexión que se han realizado contra el honeypot.

2015-01-26 00:06:42+0100 [kippo.core.ssh.HoneyPotSSHFactory] New connection: 127.0.0.1:43249 (127.0.0.1:2222) [session: 2]

2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] Remote SSH version: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa

2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] outgoing: aes128-ctr hmac-md5 none

2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] incoming: aes128-ctr hmac-md5 none

2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] NEW KEYS

2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] starting service ssh-userauth

2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth none

2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth keyboard-interactive

2015-01-26 00:06:51+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/123456] failed
2015-01-26 00:07:01+0100 [-] adastra failed auth password

2015-01-26 00:07:01+0100 [-] unauthorized login:

2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password

2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/asadas] failed

2015-01-26 00:07:04+0100 [-] adastra failed auth password

2015-01-26 00:07:04+0100 [-] unauthorized login:

2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password

2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/wwqwq] failed

Si el atacante consigue acceso, podrá ver una consola en el supuesto servicio y podrá interactuar con ella, limitado únicamente por los comandos que se han definido en la propiedad “txtcmds_path” del fichero de configuración utilizado para arrancar Kippo.

>ssh -p2222 localhost -l root

Password:

root@PROServer:~# ls

root@PROServer:~# pwd

/root

root@PROServer:~# whoami

root

root@PROServer:~# id

uid=0(root) gid=0(root) groups=0(root)

root@PROServer:~# uname -a

Linux PROServer 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux

 

Desde la consola de administración, se puede ver la nueva sesión creada en el honeypot y se puede interactuar con ella.

>telnet -e q 127.0.0.1 5000

Telnet escape character is ‘q’.

Trying 127.0.0.1…

Connected to 127.0.0.1.

Escape character is ‘q’.

*** kippo session management console ***

List of commands:

list – list all active sessions

view – attach to a session in read-only mode

hijack – attach to a session in interactive mode

disconnect – disconnect a session

help – this help

exit – disconnect the console

list

ID clientIP clientVersion

3 127.0.0.1 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

view 3

** Attaching to #3, hit ESC to return

ls

root@PROServer:~# pwd

/root

root@PROServer:~# whoami

root

root@PROServer:~# id

uid=0(root) gid=0(root) groups=0(root)

root@PROServer:~#

** Interactive session closed.

hijack 3

** Attaching to #3, hit ESC to return

Te he pillado…

bash: Te: command not found

root@PROServer:~# whoami

root

disconnect 3

** Disconnecting session #3

exit

Connection closed by foreign host.

 

El comando “list” ha permitido visualizar las sesiones iniciadas en el honeypot y con los comandos “view” y “hijack” se puede interactuar con una de dichas sesiones, el primero solamente permite ver lo que el atacante escribe en la consola del honeypot, mientras que el segundo permite interactuar directamente con dicha sesión y enviar comandos/mensajes al atacante. Finalmente el comando “disconnect” interrumpe una sesión activa, cortando la conexión entre el atacante y el honeypot.

Más sobre Honeypots en un próximo articulo.

Saludos y Happy Hack!

Adastra.

Conceptos básicos de HSTS y configuración en Apache

febrero 19, 2015 1 comentario

HSTS o Http Strict Transport Security es un mecanismo que intenta mitigar los ataques de MITM sobre SSL obligando a los clientes a utilizar únicamente conexiones cifradas con TLS/SSL. Su funcionamiento no es demasiado complicado y aporta un mecanismo de defensa adicional que a día de hoy, es prácticamente imprescindible para mantener un buen nivel de seguridad en el canal de comunicación.
HSTS es un mecanismo que se encuentra soportado por los principales servidores web modernos, tales como Apache o NGNIX y además, navegadores a la altura de Firefox, Opera o Chrome soportan las cabeceras HTTP necesarias para obligar el uso de HSTS en el lado del cliente.
Si un servidor web soporta HSTS, todas las respuestas emitidas a los clientes contendrán la cabecera HTTP “Strict-Transport-Security”, lo cual le indica al cliente que todas las peticiones que se realicen contra el servidor web deben utilizar un certificado valido y todas las conexiones se deben realizar utilizando el protocolo HTTPS únicamente. El comportamiento de los clientes que soportan la política HSTS es bastante simple y muy efectivo ante ataques de MITM. En primer lugar, se encargan de cambiar el esquema “http://” por “https://” de todos los enlaces que hacen referencia al servidor web con HSTS y por otro lado, si la existe cualquier problema con el canal de comunicación, la comunicación es cortada automáticamente, como por ejemplo el caso típico en el que el certificado que se presenta al usuario es auto-firmado o de una identidad no verificada.
En este articulo se explicará cómo se puede habilitar HSTS en un servidor web Apache y se inspeccionarán las cabeceras de las peticiones enviadas por los clientes y las respuestas del servidor, de esta forma quedará mucho más claro el funcionamiento de HSTS en un servidor web.

Habilitando HSTS en Apache

Habilitar HSTS en un servidor web Apache es algo que inicialmente puede parecer trivial, ya que solamente es necesario cargar el módulo “headers” y utilizar la directiva “Header” con el valor HSTS correspondiente, sin embargo, algo que hay que tener presente es que los navegadores web ignoran la cabecera “Strict-Transport-Security” si no hace parte de una conexión HTTPS. Dicho de otra forma, si un cliente realiza una petición HTTP a un servidor y la respuesta de dicho servidor contiene la cabecera “Strict-Transport-Security”, dicha cabecera no tendrá ningún valor para el cliente y sera ignorada, ya que los navegadores deben recibir la cabecera “Strict-Transport-Security” en una conexión HTTPS para que la apliquen sobre el dominio en cuestión.

Dicho esto, queda claro que habilitar HSTS es solamente una pequeña parte de una configuración segura, ya que será necesario habilitar el módulo de SSL/TLS en un VirtualHost del servidor web. En un articulo de hace algún tiempo, ya hablaba sobre cómo hacer esto, así que te recomiendo visitar el siguiente enlace. El fichero de configuración completo, que se puede utilizar para habilitar HTTPS y HSTS puede ser la siguiente:

ServerAdmin debiadastra@thehackerway.comServerName Galileo:80

ServerRoot “/opt/httpd-2.4.10″

ErrorLog “logs/error_log”

LogLevel warn

Listen 80

Listen 443

LoadModule authz_core_module modules/mod_authz_core.so

LoadModule headers_module modules/mod_headers.so

LoadModule unixd_module modules/mod_unixd.so

LoadModule ssl_module modules/mod_ssl.so

<IfModule unixd_module>

User adastra

Group adastra

</IfModule>

<IfModule alias_module>

ScriptAlias /cgi-bin/ “/opt/httpd-2.4.10/cgi-bin/”

</IfModule>

<Directory “/opt/httpd-2.4.10/cgi-bin”>

AllowOverride None

Options None

Require all granted

</Directory>

<IfModule ssl_module>

SSLRandomSeed startup builtin

SSLRandomSeed connect builtin

</IfModule>

<VirtualHost *:443>

Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”

DocumentRoot “/opt/httpd-2.4.10/htdocs/hstsTesting”

SSLEngine on

<Directory /opt/httpd-2.4.10/htdocs/hstsTesting>

Options Indexes FollowSymLinks

SSLRequireSSL

</Directory>

SSLCertificateFile /opt/httpd-2.4.10/webserver.crt

SSLCertificateKeyFile /opt/httpd-2.4.10/webserver.key

<IfModule mime_module>

AddType application/x-x509-ca-cert .crt

AddType application/x-pkcs7-crl .crl

</IfModule>

</VirtualHost>

Si el usuario intenta visitar el servidor utilizando el protocolo HTTPS, verá la siguiente pantalla de error indicando que la conexión no es segura y por ese motivo se ha cancelado la navegación.

hsts1

El motivo de esto, es que los certificados utilizados por el servidor web no han sido emitidos por una CA de confianza para el cliente y dado que se ha indicado que la comunicación debe realizarse con HSTS, la comunicación entre el cliente y el supuesto servidor no puede continuar llevándose a cabo. Esto evita que se realicen ataques de “SSL Stripping” con herramientas tan conocidas como SSLStrip.

Esta configuración del lado del servidor es vital para mantener sitios web con un nivel de seguridad añadido. Por otro lado, desde el cliente también es posible habilitar este “opt-in” de seguridad para determinados dominios, de tal forma que aunque el servidor no incluya explícitamente la cabecera estándar HSTS, el navegador por si solo bloqueará cualquier intento de conexión no segura, evitando problemas con el canal de comunicación. Un buen ejemplo de configuración de HSTS en el lado del cliente se encuentra en el navegador Chrome, el cual permite gestionar dóminos personalizados que deben seguir la norma HSTS. Para entrar a esta interfaz de administración del navegador, es necesario ingresar a la siguiente ruta: chrome://net-internals/#hsts

Una vez allí, Chrome enseñará la interfaz que se puede ver en la siguiente imagen para la gestión de dominios con HSTS.

hsts2

Por otro lado, si la configuración anterior no se ha aplicado para un dominio concreto y aunque dicho dominio tenga HSTS habilitado, si las peticiones iniciales se realizan utilizando HTTP, aun cabe la posibilidad de utilizar una herramienta como “sslstrip” para realizar un ataque de “hijacking”. Por ejemplo, una configuración bastante común consiste en redireccionar todo el trafico por HTTP a HTTPS, es decir, en el caso que el usuario solicite el sitio web “http://example.com”, automáticamente se realizará la redirección a “https://example.com” y dado que la petición inicial ha sido utilizando HTTP, aun existe la posibilidad de llevar a cabo un ataque. Por este motivo, navegadores como Chrome y posteriormente otros como Firefox y Opera implementan un mecanismo conocido como “HSTS Preload List” o lista de dominios HSTS precargada. Dicho mecanismo, como su nombre lo indica, carga una lista de dominios que deben cumplir con la normativa HSTS en el momento en el que el navegador arranca, de esta forma si el usuario solicita el recurso “http://example.com” la comunicación automáticamente será cortada, obligando al usuario a ingresar en la versión segura con HTTPS. Para tener los valores adecuados en dicha lista, se utiliza un algoritmo de rastreo en busca de la cabecera HSTS en múltiples sitios en Internet, además, cualquiera puede enviar una solicitud para que su sitio web sea incluido en dicha lista (la cual es compartida entre Chrome, Safari y Firefox). Para realizar dicha solicitud, basta con ingresar el dominio en cuestión en el siguiente sitio: https://hstspreload.appspot.com/
Este articulo ha sido una introducción al funcionamiento de HSTS y en uno próximo, veremos en detalle el funcionamiento de “sslstrip2”.

Un Saludo y Happy Hack!

Adastra.

Procesamiento del lenguaje natural con NLTK para Ingeniería social automatizada

febrero 17, 2015 3 comentarios

En una entrada anterior os hablaba de un proyecto que llevo estudiando desde hace algún tiempo para el análisis de emociones, dicho proyecto es “wefeelfine” y tal como os comentaba, cuenta con una API Rest que permite realizar varios tipos de consultas para obtener un listado de sentimientos recolectados en Internet. La recolección de datos que realiza dicha plataforma se basa en la ejecución de varios procesos de crawling para extraer y almacenar información de múltiples sitios en Internet, sin embargo, una de las cosas que más me ha llamado la atención es el procesamiento de los textos y las funciones utilizadas para determinar la polaridad de dichas palabras. La complejidad de un proceso de “stemming” (derivación y combinaciones de palabras) sobre el lenguaje natural no es una tarea sencilla, especialmente cuando hablamos de las características propias de cada lenguaje, al final ocurre que solamente nos podemos centrar en un conjunto limitado de lenguajes, tal como ocurre en “wefeelfine” que solo procesa los textos escritos en ingles y en castellano, aunque este último con bastantes deficiencias. Si estás pensando en desarrollar un proceso de minería de datos sobre alguna red social como Twitter, Facebook o cualquier otro sitio web en Internet, lo más probable es que te interese también extraer información útil a la que posteriormente le puedas aplicar algún tipo de análisis estadístico sobre marcas, tendencias o de carácter histórico/evolutivo. En cualquier caso, es necesario aplicar técnicas de “Procesamiento del lenguaje Natural” o NLP (Natural Lenguage Processing) por sus siglas en ingles, las cuales permiten aplicar patrones a un texto concreto y extraer información de interés (no confundir con NLP: Neuro-Linguistic Programming). Antes de continuar, viene bien explicar en qué consiste NLP y cómo se puede utilizar la librería NLTK en Python.

¿Qué es NLP?

Se trata de un conjunto de técnicas que permiten el análisis y manipulación del lenguaje natural. Dada la complejidad intrínseca que acompaña cualquier proceso de NLP, muchas de las técnicas automatizadas están relacionadas con el uso de la IA (Inteligencia Artificial) y las ciencias cognitivas. Para aplicar las técnicas más comunes en NLP, la librería NLTK (Natural Language Tool Kit) permite que cualquier programa escrito en lenguaje Python pueda invocar a un amplio conjunto de algoritmos que sustentan las principales técnicas de NLP para la generación de métricas, frecuencia de términos, polaridad negativa/positiva de frases y textos, entre otras muchas técnicas.
Existen algunos
términos comunes en NLP que se deben comprender antes de poder aplicar cualquier técnica y entender los resultados que arrojan, dichos términos resultarán de lo más lógicos, pero si no se tienen en cuenta a la hora de programar, pueden resultar confusas las funciones y resultados arrojados por NLTK.

Token: Se trata de la unidad más simple de procesamiento y representa una palabra en el texto.
Sentencia: Secuencia ordenada de tokens.
Tokenización: Se trata del proceso de segmentar una sentencia en cada uno de los tokens que la componen. Aunque puede ser un proceso simple para textos escritos en algunas lenguas, especialmente en el caso de las románicas cuyo token separador es un espacio, en otras lenguas como las altaicas, extraer los tokens de una sentencia es un proceso mucho más complejo debido a la sintaxis y semántica de los escritos en dichas lenguas.
Corpus: Cuerpo del mensaje que se encuentra compuesto por un conjunto de sentencias.
Part-of-speech (POS): Dependiendo de la semántica del lenguaje, cada token que compone una sentencia puede ser un verbo, un adjetivo, un pronombre, un articulo, etc. Un POS es simplemente una clasificación para cada token dentro de una sentencia, de esta forma es posible identificar el significado de cada token y las partes clave de cada sentencia.
Árbol: Todos los textos están compuestos por varias sentencias y cada sentencia tiene varios tokens con sus respectivos POS. Un árbol parseado incluye cada una de las dependencias de las sentencias y cada parte del texto. Es una forma de ordenar cada uno de los elementos del “corpus” de una forma que sea fácil de consultar.

Ahora que se ha expuesto la terminología básica, lo siguiente es conocer las principales técnicas definidas en un proceso NLP.

Etiquetado de POS: Una de las principales labores en un proceso de NLP, es identificar cada una una de las sentencias de un texto y clasificar cada uno de los tokens con sus correspondientes POS. Un “POS Tagger” es una rutina que se encarga de crear un diccionario con cada uno de dichos tokens y sus correspondientes POS. Por ejemplo, si la sentencia “El coche es rojo” es procesada por un POS Tagger el resultado es el siguiente: {“El” : AT , “coche” : NN , “es” : VB, “rojo” : JJ}
Donde cada POS asume los siguientes valores:
AT : Artículo
NN : Sustantivo
VB: Verbo
JJ: Adjetivo.

Parsers:
Un parser se encarga de producir un árbol de tokens con sus correspondientes POS partiendo de una sentencia determinada. Muchos de estos parsers depende un POS Tagger antes de poder generar un árbol.

Morfología:
Consiste en el proceso de catalogar cada token de una sentencia y extraer sus “morfemas” y “
raíces” para posterior análisis. Para comprender lo anterior, es necesario saber que cada token tiene una morfología que determina la estructura interna de la palabra. La morfología de una palabra puede dar lugar a nuevas palabras a partir de su morfema base y en todo caso, es importante diferenciar la morfología de la sintaxis de una palabra, ya que la morfología intenta determinar la estructura interna de las palabras, mientras que la sintaxis explica las normas para crear oraciones y textos.

Traductor:
Se trata de unas las principales aplicaciones de NLP, en la que partiendo de un texto escrito en un lenguaje determinado, es posible conseguir su traducción en otro lenguaje. Es una tarea compleja y requiere que el texto origen se encuentre correctamente
construido y cada bloque semántico del “corpus” se encuentre perfectamente redactado para conseguir una traducción legible en otro lenguaje. Google Traductor es uno de los servicios más completos y mejor implementados (que conozco) que utiliza parsers y POS Taggers avanzados para conseguir la traducción más exacta posible.

Instalación y uso básico de NLTK

La instalación del proyecto NLTK puede realizarse fácilmente utilizando PIP o easy_install.

sudo pip install -U nltk

Una dependencia opcional que también puede instalarse con PIP es numpy. Para verificar que ha quedado correctamente instalada, basta con importar el módulo ntlk y si no se aprecia ningún error, se puede asumir que el proceso de instalación ha ido bien.

Por otro lado, además de la librería también es necesario instalar una serie de ficheros y diccionarios con patrones para varios tipos de estructuras gramaticales llamados “corporas”, dichos ficheros se instalan de forma independiente por medio de un gestor de descargas que puede iniciarse utilizando el modulo nltk

>python
>>>import nltk
>>>nltk.download()


Invocando a “download” se abre una ventana en la que se pueden gestionar todos los ficheros “corpora” en diferentes
categorías. Si es la primera vez que se utiliza nltk, se realizará la descarga de dichos ficheros.
Los corpus principal
es que se suelen utilizar en el procesamiento de texto son conocidos como “gutenberg”, el cual incluye una selección de 18 textos del proyecto Gutenberg (http://www.gutenberg.org/) y contiene más de 1.5 millones de palabras. Para consultar los textos de gutenberg incluidos en el corpus de NLTK, se pueden ejecutar las siguientes instrucciones.

>>>from nltk.corpus import gutenberg

>>>print gutenberg.fileids()

['austen-emma.txt',

'austen-persuasion.txt',

'austen-sense.txt',

'bible-kjv.txt',

'blake-poems.txt',

'bryant-stories.txt',

'burgess-busterbrown.txt',

'carroll-alice.txt',

'chesterton-ball.txt',

'chesterton-brown.txt',

'chesterton-thursday.txt',

'edgeworth-parents.txt',

'melville-moby_dick.txt',

'milton-paradise.txt',

'shakespeare-caesar.txt',

'shakespeare-hamlet.txt',

'shakespeare-macbeth.txt',

'whitman-leaves.txt']

Ahora es el momento de comenzar a utilizar la librería y para ello, se puede utilizar el siguiente script, el cual se encarga de pintar por pantalla cada uno de los textos del proyecto gutenberg, el número de caracteres, el número de tokens, el número de sentencias y el número de veces que un item del vocabulario aparece en una sentencia.

from nltk.corpus import gutenberg
for fileid in gutenberg.fileids():
    num_chars = len(gutenberg.raw(fileid))
    num_tokens = len(gutenberg.words(fileid))
    num_sents = len(gutenberg.sents(fileid))
    num_vocab = len(set(w.lower() for w in gutenberg.words(fileid)))
    print str(num_chars) + &quot; - &quot; + str(num_tokens) + &quot; - &quot; + str(num_sents) + &quot; - &quot; + str(num_vocab)

Aunque se ha utilizado un corpus que se encuentra implementado en NLTK, también es posible utilizar uno propio y de hecho, es lo más común para realizar diferentes tipos de análisis sobre los datos de un texto. Para ello se pueden utilizar las clases PlaintextCorpusReader o BracketParseCorpusReader.

from nltk.corpus import PlaintextCorpusReader
import nltk
wordlists = PlaintextCorpusReader(&quot;/home/adastra/Escritorio/textos&quot;, '.*')
wordlists.words('prueba.txt')
print &quot;Sentences: &quot;+str(len(wordlists.sents()))
for sentence in wordlists.sents():
    tokens = nltk.word_tokenize(str(sentence))
    tagged_tokens = nltk.pos_tag(tokens)
    verbs = 0
    for tagged in tagged_tokens:
        token, tag = tagged
        if tag == 'VBP' or tag == 'VB':
            verbs += 1
    print &quot;Tokens: &quot;+str(len(tokens)) + &quot; - Verbs: &quot;+str(verbs)&lt;/td&gt;

El script anterior lee el fichero “prueba.txt” que se encuentra en el directorio “/home/adastra/Escritorio/textos” y se encarga de contar el número de sentencias, el número de tokens por sentencia y los verbos de cada sentencia, los cuales están marcados con el tag “VBP” o “VB”.

Estas son solamente algunas de las características incluidas en NLTK y me dejo muchas, muchísimas cosas que se pueden hacer con esta librería y que entran en el campo de la lingüística y el análisis de datos.
Antes de terminar con este articulo, os indico brevemente un proyecto que utilizan NLTK y que cuenta con algunos servicios que pueden utilizarse por medio de peticiones HTTP planas. Dicho proyecto es “text-processing”. Desde la URL http://text-processing.com/demo/ pueden apreciarse 4 ejemplos del procesamiento de texto en lenguaje natural, siendo el más interesante, desde mi punto de vista, el que corresponde con el análisis de sentimientos. Como comentaba antes, dicho servicio se puede invocar directamente por medio de una petición HTTP utilizando el método POST, algo que se puede hacer con cualquier lenguaje de programación e infinidad de herramientas, entre las que se incluyen wget y curl.

>curl -d “text=spain is different” http://text-processing.com/api/sentiment/

{“probability”: {“neg”: 0.38781650900239895, “neutral”: 0.59783687451926548, “pos”: 0.61218349099760105}, “label”: “neutral”}

Como se puede apreciar, el parámetro “text” es el que incluye el texto que la plataforma debe procesar y el resultado es una estructura JSON con el porcentaje que indica qué tan “negativa”, “positiva” o “neutral” es la frase. En este caso, se ha enviado el texto “spain is different” y como se puede apreciar en el resultado, la plataforma determina que el texto es neutral, aunque el porcentaje de “positivismo” es del 61% frente a un 38% de “negatividad”. Al parecer, ni la plataforma, ni NLTK son capaces de distinguir la ironía.

Todo esto puede ser muy interesante para procesos automatizados de ingeniería social que permitan recolectar información de sitios en internet como Twitter o Facebook y determinen la polaridad de los mensajes de ciertas cuentas y además, determinar si las condiciones climáticas en la hora y lugar desde donde se publico el tweet han podido tener algún tipo de influencia.
Esta y otras ideas, se desarrollarán en mayor detalle en próximos artículos.

Un saludo y Happy Hack!
Adastra.

20 eepsites en la web profunda de I2P que te podrían interesar

febrero 5, 2015 2 comentarios

Este año puede ser muy interesante para I2P ya que por lo que he podido percibir en la red por comentarios en blogs, foros y en varios canales IRC, la gente está comenzando a utilizar más activamente I2P tanto como solución “InProxy” como solución “Outproxy”, especialmente desde la última edición de la CCC celebrada en Hamburgo. Ya os comentaba en la última entrada que 2015 es el año en el que deberías comenzar a pensar en I2P como una buena alternativa a TOR ya que se trata de una red madura y con mucho que ofrecer. Siguiendo esa misma línea, os dejo un listado de eepsites en I2P que a lo mejor resultan de vuestro interés, pero antes de eso, es importante hablar un poco sobre SusiDNS y el sistema de nombrado que utiliza I2P.

Tal como os he explicado anteriormente en una serie de artículos sobre I2P que he redactado hace unos años, el sistema de nombrado que utiliza un router depende de un fichero de texto que vincula un dominio “.i2p” con una dirección en base32 o base64, que es realmente el “destination” del servicio. En I2P no existe un sistema centralizado para resolver la dirección de un destino con su correspondiente dominio “.i2p”, no funciona como el clásico y conocido DNS, todos los hostnames son locales. Este sistema de nombrado se puede gestionar por medio de la aplicación “SusiDNS”, la cual se encuentra instalada por defecto en todos los routers de I2P en la siguiente dirección: http://127.0.0.1:7657/susidns/index. Algunos de los EEPSites que se listan a continuación ya se encuentran incluidos en el sistema de nombrado, sin embargo es posible que algunos no lo estén, por ese motivo es necesario hacerlo manualmente utilizando SusiDNS.

Por otro lado, es posible que una dirección “.i2p” no se encuentre almacenada en el addressbook local y en estos casos, el usuario tiene dos alternativas, o bien adicionar dicha dirección en cualquiera de los addressbook de la instancia local de I2P o utilizar un “jump service” que servirá de proxy entre el cliente y el destino sin necesidad de agregar el dominio y la dirección base32/base64 en el addressbook local. Algunos de los “jump services” más utilizados son los siguientes:

http://i2host.i2p

http://stats.i2p

http://no.i2p

http://i2pjump.i2p

Aclarados estos puntos, se listan algunos “eepsites” interesantes en la red de I2P. De esta forma, podrás comenzar a utilizar I2P, navegar por la web profunda y acceder a contenidos e información que sea de tu interés.

1. I2P Wiki (UGHA).

Una wiki bastante simple pero con buenos recursos sobre otros eepsites en I2P y recursos variados.

URL I2P: http://ugha.i2p/

URL Base32: http://z3f3owc72awbywk4p6qb5l2mxgitvs6ejztggbpn2a3ddmymfjda.b32.i2p

2. INR (I2P Name Registry).

Probablemente es uno de los recursos más interesantes para cualquier usuario que recién está comenzando con I2P. Incluye un directorio de servicios ocultos en I2P que los usuarios registran para que cualquiera pueda acceder a su correspondiente “destination”.

URL I2P: http://inr.i2p

URL Base32: http://joajgazyztfssty4w2on5oaqksz6tqoxbduy553y34mf4byv6gpq.b32.i2p

3. Foro de discusión de ZZZ.

Seguramente es para muchos conocido que el usuario “zzz” es uno de los desarrolladores de I2P y que lleva el proyecto desde el principio y dado que I2P sigue estando en versión “beta”, un buen recurso para conocer las últimas novedades es su foro de discusión, donde cualquiera puede registrarse y abrir un hilo. Es un recurso que te será muy útil para aprender y posteriormente apoyar al proyecto (con código, obviamente).

URL I2P: http://zzz.i2p/

URL Base32: http://ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p/

4. Planet I2P.

Sitio dedicado a las últimas novedades en I2P.

URL I2P: http://planet.i2p/

URL Base32: http://y45f23mb2apgywmftrjmfg35oynzfwjed7rxs2mh76pbdeh4fatq.b32.i2p

5. Abusos Judiciales.

España es un país en el que se comenten innumerables atropellos y abusos judiciales y parece ser, que es poco lo que los afectados pueden hacer al respecto. Este servicio oculto no solamente se encuentra en I2P, sino que también se puede encontrar en TOR en la dirección onion http://2dn2dmxt5uwnxz3j.onion/ y su finalidad es exponer los principales abusos judiciales cometidos en España y las medidas legales que pueden aplicar los afectados. Además incluye consejos muy interesantes para protegerse y denunciar querellas falsas, denuncias, multas injustas, etc. Espero que ninguno de vosotros se encuentre nunca en una situación legal delicada, pero si así fuese, este sitio puede resolver algunas de las dudas que puedas tener.

URL I2P: http://abusos.i2p/

URL Base32: http://jnvf5uh4cnw5xv4yjwr5m4mv672ayacdj6lvsqyxkjtbzbuquxgq.b32.i2p/

6. APlus

Se trata de una red social muy simple en la que sus miembros pueden intercambiar mensajes y chatear. Para poder utilizarla, es necesario estar registrado, de lo contrario solamente podrás buscar los usuarios que se encuentran registrados.

URL I2P: http://aplus.i2p

URL Base32: http://h67lym6btfqinjs5ye272fo6uze2uvjk6t7qabibocjedfcv5fva.b32.i2p/

7. Strategic Intelligence Network (SIN)

Un sistema que recolecta y analiza los últimos acontecimientos en cada país del mundo y en base a dicha información, se encarga de generar distintos niveles de “SecCon” (Security Conditions) en cada país. Este sistema es interesante para conocer de primera mano la situación social y política de cada país del mundo y si eres una persona que suele viajar mucho, puedes leer las recomendaciones que incluye para mantener unos niveles de seguridad mínimos tanto en el viaje como en la estancia.

URL I2P: http://sin.i2p

URL Base32: http://tph27jvsnriyy3fcxmg44icunb5ugi3qhue3e7skwn4awp5j5zyq.b32.i2p/

8. GIT Hosting

Si tienes un proyecto de desarrollo de software y te interesa publicarlo en la web profunda de I2P, puedes registrarlo en el sitio git.repo.i2p y realizar su administración utilizando las utilidades de GIT del mismo modo que con cualquier repositorio en Internet.

URL I2P: http://git.repo.i2phttp://pull.git.repo.i2p/http://push.git.repo.i2p/

URL Base32: http://vsd2vtgtuua2vwqsal2mpmxm2b2cpn3qzmqjoeumrrw2p4aot7uq.b32.i2p/w

http://3so7htzxzz6h46qvjm3fbd735zl3lrblerlj2xxybhobublcv67q.b32.i2p/

http://jef4g5vxnqybm4zpouum3lzbl6ti6456q57nbyj5kfyldkempm3a.b32.i2p/

9. eepstatus

Servicio muy similar a INR, se encarga de verificar que los eepsites que se encuentran en el listado se encuentran activos y aquellos que no lo están, tienen una marca roja indicando la última fecha en la que se han visto en linea. Del mismo modo que ocurre con INR, se trata de un listado que se alimenta de sitios registrados por los usuarios de I2P y por un motor de indexación que incluye el servicio, por lo tanto es posible encontrar con servicios ocultos con contenidos inadecuados o ilegales y es importante ser consciente de ello y tomar las medidas oportunas.

URL I2P: http://identiguy.i2p/

URL Base32: http://3mzmrus2oron5fxptw7hw2puho3bnqmw2hqy7nw64dsrrjwdilva.b32.i2p/

10. PasteThis

Servicio similar a PasteBin para I2P. Los textos compartidos pueden ser públicos o privados

URL I2P: http://pastethis.i2p

URL Base32: http://erkqiwnjl7vtysqd3wvddv6tfvnhswarqkbn4blhdlhfxn7cf2ha.b32.i2p/

11. Postman Tracker

Uno de los servicios más conocidos en I2P para subir ficheros torrent en I2P. Es importante tener en cuenta que es posible que algunos de los torrents que se encuentran almacenados, no tengan el contenido que dicen tener. Cuidado, te puedes llevar una sorpresa.

URL I2P: http://tracker2.postman.i2p/

URL Base32: http://ahsplxkbhemefwvvml7qovzl5a2b5xo5i7lyai7ntdunvcyfdtna.b32.i2p/

12. LaWiki

Una wiki en castellano muy completa sobre el uso de I2P y con explicaciones muy detalladas sobre privacidad, anonimato y cuestiones técnicas relacionadas con I2P, TOR, FreeNet, etc. Se recomienda su lectura!

URL I2P: http://lawiki.i2p

URL Base32: ddwc3z7tm6yuvh4mzmqne2ifn7qglbz73zyqxtkewlpzl7kpmqzq.b32.i2p

13. Killyourtv

Se trata de un blog con información técnica bastante útil. Encontraras varios manuales y servicios interesantes. Además, incluye una de las mejores guías que he visto sobre Tahoe, algo de lo que hablaré en un próximo articulo.

URL I2P: http://killyourtv.i2p/

URL Base32: http://aululz24ugumppq56jsaw3d7mkbmcgo7dl2lgeanvpniyk2cbrda.b32.i2p/

14. Shadowlife

Un blog de opinión sobre temas relacionados con anonimato y privacidad. Hace algún tiempo leí algunos artículos sobre anonimato online y offline que me parecieron interesantes, seguramente a ti también.

URL I2P: http://shadowlife.i2p

URL Base32: http://jme44x4m5k3ikzwk3sopi6huyp5qsqzr27plno2ds65cl4nv2b4a.b32.i2p

15. ZeroBin

Similar a PasteThis, pero permite publicar mensajes de forma privada y con una fecha de caducidad. Además tiene la opción de que se auto-destruya después de que el mensaje es leído.

URL I2P: http://zerobin.i2p

URL Base32: http://3564erslxzaoucqasxsjerk4jz2xril7j2cbzd4p7flpb4ut67hq.b32.i2p/

16. Syndie

Syndie es un sistema para la creación y gestión de foros descentralizados en I2P. Es muy popular entre los usuarios.

URL I2P: http://www.syndie.i2p

URL Base32: http://7lm3yzpuejhpl4tt4l7o4ndqlu7hgijohofh7oaydx7q7kelenbq.b32.i2p

17. Postman

Servicio en I2P para crear cuentas de correo electrónico de forma anónima. Es probablemente el servicio más conocido en I2P para este tipo de tareas. Una cuenta en Postman puede ser utilizada en cualquier cliente de I2P para recepción y envío de mensajes de correo electrónico. Fijaros en la sección “Pages” a la derecha, allí se encuentran todas las opciones disponibles en Postman.

URL I2P: http://hq.postman.i2p

URL Base32: http://27ivgyi2xhbwjyqmnx3ufjvc2slg6mv7767hxct74cfwzksjemaq.b32.i2p

18. I2P Find

Del mismo modo que existe el servicio TORFind para la búsqueda de servicios ocultos en TOR, I2PFind es un servicio que permite buscar servicios ocultos en I2P y/o en TOR. Además, cualquiera puede registrar su propio dominio I2P para que sea indexado por el motor de búsqueda.

URL I2P: http://i2pfind.i2p

URL Base32: http://cgkswg5iezxdvfds2p5lgvhfhvd6sv3r72yioarywnwgmiazbw3q.b32.i2p/

19. Ihave2P

Se trata de un sitio oculto que ofrece varios tipos de servicios, como por ejemplo un pastebin con cifrado y mi favorito, servidores proxy del tipo http/https/socks a la clearnet por medio de TOR y/o I2P. Este último en concreto, se encuentra disponible en una dirección distinta (http://ihave2proxy.i2phttp://ginbb7blr6rvgfkuyx7435rakosdilzeduklygrkwaw3dwduntcq.b32.i2p/).

URL I2P: http://ihave2p.i2p

URL Base32: http://s6npkh5hzslijnzohm2om32un4sh4r2urp6hry2fya6oo55ehcyq.b32.i2p/

20. Torrent Finder

Buscador de Torrents en la web profunda de I2P.

URL I2P: http://torrentfinder.i2p

URL Base32: http://mpc73okj7wq2xl6clofl64cn6v7vrvhpmi6d524nrsvbeuvjxalq.b32.i2p/

Una lista de 20 servicios ocultos (eepsites) en I2P que espero que te ayuden a perder el miedo a navegar por este tipo de redes y encontrar cosas (legales) que sean de tu interés.

Un saludo y Happy Hack!
Adastra.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.411 seguidores

A %d blogueros les gusta esto: