Archivo

Archivo para 30 enero 2010

Mudanza

Como habréis podido notar -porque sois unos lectores muy avispados, suponiendo que haya algún lector- he trasladado el blog a wordpress.com. El servicio de blogger.com es bastante malo. Desde mi punto de vista google ha abandonado su servicio de blogging para dedicarse a otros asuntos, lo que ha dado lugar a que mucha gente, entre ellos yo mismo, hayan ido abandonando paulatinamente blogger para encontrar algo más moderno y cómodo. Entre las características que agradezco de wordpress es su mayor capacidad para formatear una entrada, su coloreado de código por defecto, su cómoda forma de incluir imágenes o videos con su nota al pie y su enorme cantidad de plantillas oficiales, con resoluciones por encima de 800×600 de blogger. No todo es malo en blogger, claro, su integración con los servicios de google es cómoda, pudiendo colocar una columna con los RSS que más lees. También hay que resaltar que blogger no te cobra por utilizar tu propio dominio con su servicio, cosa que wordpress.com sí que hace, por un precio varias veces superior al valor del dominio.

Esta semana no ha habido post debido al trajín de la mudanza ;) Espero que para la semana que viene haya algo interesante que contar.

Categorías:General Etiquetas: , ,

Cómo montarte una botnet de routers for dummies

Mucho se ha hablado sobre Shodan en la blogosfera desde su aparición. No tengo intención de hablar sobre las maravillas y capacidades de shodan en este post, pero sí lo usaré para ilustrar una curiosidad que quizá la mayoría de la gente no conoce; al menos en España.

Nosotros estamos acostumbrados a que cuando contratas internet con el proveedor que sea, te haga llegar un router y tengas que configurarlo tú. Normalmente viene con una configuración por defecto, pero si quieres cambiar la clave o el canal de la wifi, entras al router y lo cambias por ti mismo, lo mismo pasa para la clave de administración o cualquier parámetro -simple o avanzado- del router. Además, si por cualquier motivo necesitases algún tipo de asistencia telefónica de la operadora, deberás llamar a un número de pago por el que te cobrarán todo lo que deseen y un porcentaje de propina.

Pues esto no es así en todo el mundo, amigos. En América Latina, las operadoras son mucho más amables con sus clientes, y todas las gestiones que se deban realizar sobre el router del cliente son realizadas por los técnicos de la compañía. Si el usuario quiere cambiar la clave WPA, llama a la operadora y ellos se conectan a su router y realizan el cambio. Así con todos los parámetros. Y todo esto gratis. Sí, así es la vida.

Y diréis, “muy bien, ¿pero esto qué tiene que ver con la seguridad? No vengas a llorarnos con tus traumas”. Vale, tenéis razón, solo que en realidad existe un pequeño problema. Estos países, imagino que por comodidad para la operadora, entregan los routers con la interfaz web de administración expuesta a internet, y además, con las claves por defecto. ¡Imaginad que cada usuario pusiera la suya! Dar el servicio de asistencia sería más complicado (¿?). Alguno pensará que podrían tener un rango limitado de IPs con acceso, de tal forma que sólo las operadoras tuvieran acceso. Sí, podrían, pero sería menos divertido.

Y para muestra, un botón

Y para muestra, un botón

Llegados a este punto es donde entra en juego Shodan. Esta maravilla permite realizar una búsqueda por país y por servicio. Así por ejemplo podemos buscar algo como:

http://shodan.surtri.com/?q=+country:CL+port:80

http://shodan.surtri.com/?q=country:CL+port:80+country:MX&page=5

Y encontraremos -entre otras cosas-, cantidad de routers domésticos que ofrecen el panel de administración a todo aquel que sepa la password por defecto de cada modelo. ¿Quien quería una botnet de routers? Daos prisa, ¡que me las quitan de las manos!

Categorías:seguridad Etiquetas: , , ,

XSS sobre SSL y los filtros de navegador

El otro día salió una conversación a raíz del XSS clásico que ha afectado a la web de la presidencia española de la UE. Alguien preguntaba si una web con SSL a la que se le inyecta código javascript mediante XSS daría algún tipo de alerta de “contenido no seguro” o no. Yo respondí que no, pero como no se me terminó de creer (eso está bien, hay que dudar de todo) hice una pequeña prueba. He montado un servidor web con SSL y certificado autofirmado, con una página web que tiene el siguiente código:

<body>

<form action="sslxss.php" method="get">
<input type="text" id="texto" name="texto">
<input type="submit" value="Ale">
</form>

<br>
<br>
<?
echo $_GET["texto"];
?>
</body>

Este código es obviamente vulnerable a XSS, y la pinta que tiene es la que se muestra en la imagen.

Vista de la web

Vista de la web

Pues bien, iba yo todo contento a calzarle mi XSS de libro cuando…

XSS clásico que falla en chrome

XSS clásico que falla en chrome

¿Pero qué pasa aquí? ¡Yo he programado el código y vamos que si es vulnerable! Podríamos intentarlo con nuestro viejo Firefox 3.5 con el mismo resultado.

XSS clásico que falla en firefox

XSS clásico que falla en firefox

Vaya, parece que hay algo que anda filtrando las comillas, ¿magic quotes? ¿el navegador?. Vamos a darle una pequeña vuelta a la cosa a ver si tengo razón. Firefox ha caído fácil, en cuanto hemos quitado las comillas, y en vez de meter alert(“XSS”); hemos utilizado alert(123); ha saltado la esperada ventanita.

Evitando el filtro de comillas, firefox traga

Evitando el filtro de comillas, firefox traga

Como era de esperar, no hay avisos SSL de contenido no seguro. Sin embargo, Chrome se nos sigue escapando. Podemos probar también con:

<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
<IMG SRC="javascript:alert('XSS');">

o con una variedad importante de métodos de evasión de filtros y la mayoría fracasarán. Chrome en Linux y Mac ha incluido recientemente un filtro antiXSS que, como estamos viendo, funciona bastante bien. Aunque le han encontrado las cosquillas, todos esos fallos están ya solucionados. Esto no pretende ser un estudio del filtrado XSS de Chrome (quizá para otra ocasión), así que nos quedamos con la idea de que el SSL no ofrece ninguna garantía adicional frente al XSS y de que en Chrome es más díficil que en Firefox ;)

Nos rendimos ante el filtro XSS de Chrome, de momento

Nos rendimos ante el filtro XSS de Chrome, de momento

Categorías:hacking Etiquetas: , ,

RootedCon, calentando motores

Ya existe mucha información disponible sobre las fechas, los precios y los cursos previos a la RootedCon. Además, está abierto desde ayer el proceso de registro (yo ya tengo el mío), con unos precios muy asequibles, así que aprovecha y regálate la entrada por reyes, aunque si la compras antes del 31 de diciembre te cuesta tan solo 50 euros (25 para estudiantes).

No podéis faltar

¿Cómo? ¿No sabes de qué te estoy hablando? ¿Vives en un búnker? ¡La RootedCon! Se trata de una convención de seguridad informática que pretende ser el equivalente español de la DefCon o la BlackHat. Con el equivalente español quiero decir que se trata de una conferencia organizada en España, pero con proyección internacional. Aunque aún no se han hecho públicas las ponencias (todavía está abierto el CFP), estoy seguro que sus organizadores no nos van a decepcionar. Y es que esta RootedCon está organizada por los más selectos hackers del panorama nacional: Román “Pato-WC”, RoMaNSoft, Ricardo Galán, Javier Olascoaga… Y participando más o menos en la organización, pero rondando por allí y colaborando con lo que pueden están también los de siempre, Chema Alonso, Alejandro Ramos, Rubén Santamarta

Con este elenco y esos precios, no te lo puedes perder, y si además quieres aprender en profundidad sobre algún tema, mírate los cursos que ofrecen y apúntate, que las plazas son muy limitadas.

¡Nos vemos en la RootedCon!

Categorías:eventos, seguridad Etiquetas: , ,

Solución al reto De-ICE Level 1 (y II)

26/01/2010 2 comentarios

Bueno, en el artículo anterior conseguimos acceso a la máquina víctima con las credenciales del usuario bbanter. En este, veremos cómo podemos elevar privilegios hasta llegar a hacernos con la password de root y con la información confidencial que contiene la víctima. Vamos al lío.

Acabamos de entrar en el sistema, y lo primero es hacer algunas comprobaciones iniciales de nuestra situación. ¿Qué permisos tenemos?¿Podemos subirnos a root?¿Qué más usuarios hay en la máquina?¿Cuales son los más privilegiados?

Contenido de /etc/passwd

Contenido de /etc/passwd

Fijemonos en un par de cosas. En primer lugar, ese aviso en el usuario root, que indica algo acerca de la encriptación del ftp y el password de root. En segundo lugar, fijaos que el usuario aadams, tiene un gid de 10, y que si miramos en /etc/groups, pertenece al grupo wheel. El grupo wheel suele ser un grupo con privilegios de administración, así que si no podemos acceder directamente a root, igual deberíamos tratar de pasar por aadams.

Una de las cosas que podemos hacer, es tratar de encontrar los ficheros setuid que pertenezcan a root o a aadams, y tratar de localizar los scripts, ya que es difícil localizar binarios oficiales con fallos que nos permitan elevar privilegios y requiere mucho más tiempo del que tenemos.

¿Algún setuid interesante?

¿Algún setuid interesante?

Bueno, no ha habido suerte, pero mientras hacíamos esto, hemos dejado un ataque con brutessh contra el usuario aadams (igual que el que usamos contra bbanter). Y como eso tarda un rato, lanzamos un análisis con nikto por si hubiera algo interesante; no lo hay. Ojeamos por si hubiera algún exploit para el kernel, y aunque lo hay, la máquina no dispone de herramientas de compilación (punto a favor). Aunque he intentado compilarlo en una slax, no he tenido éxito (problemas de dependencias, librerías distintas…). Mientras exploramos algunas otras posibilidades el ataque por fuerza bruta ha tenido éxito, y hemos obtenido la password de aadams. Accedemos al sistema con el nuevo usuario, y comprobamos de nuevo el estado en que nos encontramos.

El hash del password de root es nuestro

El hash del password de root es nuestro

En primer lugar comprobamos que somos del grupo wheel, y tratamos de acceder al cofre del tesoro, pero no tenemos permisos suficientes. Bueno, tratamos de usar sudo con la esperanza de que perteneciendo a wheel podamos hacerlo y… bueno, no podemos subir a root, pero fijaos en el mensaje “not allowed to execute /bin/bash”, lo que quiere decir que existen algunos comandos que sí podemos ejecutar. Tras varias pruebas, encontramos que cat es uno de ellos, y como es obvio, echamos un ojo al fichero /etc/sudoers a ver qué más podemos hacer. Parece que poca cosa, pero suficiente para leer /etc/shadow y llevarnos el hash del password de root para crackearlo con calma. Además, podemos acceder al ftp, y descubrimos que lo que hay allí es un fichero cifrado con supuesta información acerca de sueldos.

Usamos john the ripper con dos diccionarios diferentes

Usamos john the ripper con dos diccionarios diferentes

Ha sido fácil, en apenas unos minutos, john nos ha encontrado la password de root. Podíamos haber utilizado rainbow tables e incluso haber buscado ese hash en google, pero esto no ha sido costoso. Con la password de root en mano, suponemos que nos servirá para descifrar el archivo de sueldos (el comentario en /etc/password sugería esto). Se nos plantea un problema, ¿qué algoritmo se ha utilizado para cifrar el fichero? Podríamos haber examinado el contenido del fichero cifrado (con un hexdump) y quizá habríamos localizado algo de información relevante, pero en realidad tampoco hay tantos tipos, y puesto que hemos llegado hasta aquí a base de fuerza bruta

Desciframos con openssl

Desciframos con openssl

Sí amigos, un script bastante simple que prueba todas las opciones de cifrado que da openssl y luego un file a todos los ficheros, a ver cual es el descifrado (el ASCII, obviamente). No nos queda más que ir al responsable de la empresa y presentar nuestro informe, un poco flojo, puesto que pese a haber conseguido acceso root y los datos confidenciales, se ha realizado todo con técnicas de fuerza bruta; aunque oye, la seguridad de las contraseñas es algo que se debe tener en cuenta.

El premio gordo

El premio gordo

Por supuesto, esta es mi solución al reto, seguro que hay muchas otras, y mejores que esta, pero funciona, ¿no? ;) Esto ha sido todo por ahora, más adelante contaremos como resolver el siguiente nivel.

Categorías:hacking, wargame Etiquetas: , , ,

Solución al reto De-ICE Level 1 (I)

26/01/2010 1 Comentario

En esta entrada vamos a mostrar una posible solución al reto De-ICE, nivel 1. Ilustraremos un camino bastante directo a la solución, dejando los callejones sin salida para una entrada posterior. La información referente a este nivel es la siguiente:

SCENARIO

IP Subnet Mask: 255.255.255.0

The scenario for this LiveCD is that a CEO of a small company has been pressured by the Board of Directors to have a penetration test done within the company. The CEO, believing his company is secure, feels this is a huge waste of money, especially since he already has a company scan their network for vulnerabilities (using nessus). To make the BoD happy, he decides to hire you for a 5-day job; and because he really doesn’t believe the company is insecure, he has contracted you to look at only one server – a old system that only has a web-based list of the company’s contact information.

The CEO expects you to prove that the admins of the box follow all proper accepted security practices, and that you will not be able to obtain access to the box. Prove to him that a full penetration test of their entire corporation would be the best way to ensure his company is actually following best security practices.

CONFIGURATION

PenTest Lab Disk 1.100:

This LiveCD is configured with an IP address of 192.168.1.100 – no additional configuration is necessary.

Pentest Machine:

Your second system will use the BackTrack (v.2) LiveCD as provided by remote-exploit.org. A copy of the LiveCD can be downloaded from remote-exploit.org. This disk is configured to obtain an IP address through DHCP – thus no additional configuration is required. All tools necessary to exploit Disk 1.100 can be found on the BackTrack Disk. No additional installations will be necessary.

Router Configuration:

The PenTest Lab system and the PenTest machine must connect to a router that has been configured with the following values:

DHCP Server: active

Pool Starting Addr.: 192.168.1.2

LAN TCP/IP:

IP Address: 192.168.1.1

Podéis encontrar más información en los foros de heorot.net. Las imágenes para el reto las podéis descargar también en el foro, en este hilo. Una vez tenemos la máquina virtual levantada, comenzamos con un escaneo sencillo para determinar las oportunidades que tenemos de lograr nuestro objetivo:

Escaneo con nmap

Escaneo con nmap

Como se puede apreciar en la imagen, parece que la víctima es un Linux 2.6.x, tiene un servidor SMTP, IMAP, POP, un SSH, un Apache y un FTP. Esto es todo lo que tenemos, y por supuesto sus versiones. Una búsqueda en los sitios habituales no arroja ningún exploit remoto de interés, así que iremos a una prueba un poco más manual de los servicios, como se muestra en la siguiente imagen.

Acceso ftp y ssh

Acceso ftp y ssh

Vaya, parece que hay algún problema con la configuración del FTP, lo que nos va a impedir su uso por el momento. En cuanto al SSH, parece funcionar correctamente, pero por desgracia no tenemos la password de root, ni constancia de que existan otros usuarios. Vamos a seguir indagando en los servicios disponibles de la víctima. Algo que deberíamos haber hecho en primer lugar, es abrir un navegador y ver qué encontramos en el servidor web.

Web de la empresa

Web de la empresa

Si os fijáis bien, veréis que se puede extraer información útil de esta página web. En primer lugar tenemos varias direcciones de correo, que además siguen un patrón: 1erApellidoNombre. Con los nombres de usuarios que hay aquí, y con un poco de imaginación, podemos hacer una suposición acerca de algunos de los usuarios que hay en el sistema. Así a bote pronto algo como:
marym
mmary
root
mariem
mmarie
patrickp
ppatrick
patp
ppat
...
aadams
adamsa
adama
aadam
banterb
bbanter
bobb
bbob
...

Ponemos especial atención a los nombres que aparecen como miembros del equipo de administración de la web, ya que es más que probable que tengan una cuenta privilegiada en el sistema, o al menos una desde la que se puedan escalar privilegios. ¿Cómo saber si alguno de estos usuarios existe? Podríamos coger esta lista y tratar de lanzar un ataque de fuerza bruta contra el servicio SSH, con todos estos usuarios y un buen diccionario. Quizá funcionaría, pero tardaríamos un tiempo muy valioso que quizá podamos acortar con un poco de ingenio.

Enumeración por SMTP

Enumeración por SMTP

Si os fijáis, el servidor SMTP permite la enumeración de usuarios, pero hacerlo vía telnet, uno a uno es muy tedioso. Por lo tanto, hemos utilizado smtpguess; una utilidad que desarrollé a raiz de este reto para realizar esta función. Bien, ahora tenemos unos usuarios válidos en la máquina. Vamos a tratar de realizar un ataque de fuerza bruta al servicio SSH (previamente hemos descartado otras opciones, que dan para otro post completo). Deberíamos usar hydra o némesis, pero tienen problemas con la librería de ssl moderna y hay que retroceder a la backtrack 2 o compilarse una versión de xhydra enlazada contra el ssl viejo. Por lo tanto vamos a utilizar brutessh, que si bien es bastante más simple, cumple su función. En primer lugar, vamos a probar un diccionario para dummies, es decir, que va a contener los nombres de los usuarios, sus cuentas en el sistema y algunas palabras del texto que veíamos en la web (nunca se sabe, por ejemplo marmot :P ).

brutessh en acción

brutessh en acción

¡Premio! El usuario bbanter no ha sido muy cuidadoso con su password, y nos ha regalado el acceso a la víctima :) Con esto es suficiente por ahora, que el post ya es bastante largo de por sí. El acceso a la víctima y la escalada de privilegios, en otro post.

Categorías:hacking, wargame Etiquetas: , , ,

Descubriendo usuarios a través de SMTP con smtpguess

Esta semana descubrí el pentest lab de heorot.net (en los foros tenéis las descargas y algo de documentación y pistas) y decidí probarlo. Dedicaremos otro post más adelante a ver la solución que hallé al nivel 1 del reto cuando lo complete definitivamente. No es que haga falta comerse mucho el coco para superar este primer nivel -no me gusta la forma que he hallado de superar algunas partes, pero ya lo comentaremos despacio en un post futuro-, pero su desarrollo ha dado lugar a una pequeña herramienta que pongo a vuestra disposición.

Llegado un punto del reto, resulta útil e interesante tratar de obtener los usuarios existentes en el sistema objetivo a través de SMTP. Partimos de una lista de usuarios que hemos recopilado -cada uno como ha podido/querido-. El proceso de enumeración a través de SMTP es sencillo, pero tedioso, por lo que decidí que podía automatizarlo de manera sencilla en python, y así nació smtpguess. De momento smtpguess funciona en python 2.6 -debería funcionar igual en 2.5 pero no en 3.x-, requiere que el servicio SMTP esté escuchando y que el puerto en el que lo haga no esté cerrado. Lo he liberado bajo GPLv2 y está disponible para su descarga desde aquí: https://sites.google.com/site/securityetalii/

La versión actual es la 0.1 y su funcionalidad aún no es completa -falta completar el soporte SSL por ejemplo-. Por ahora permite los métodos VRFY y RCPT TO para enumerar usuarios y funciona en un sólo thread. Aquí os dejo un ejemplo de uso:


adrian@Andromeda:~$ ./smtpguess.py
Missing Parameter!
smtpguess v0.1 by Adrián Bravo
Usage: ./smtpguess.py -h  [-p ] -m  -u  [-s] [-v]
where:
-h   -- Targets hostname
-p   -- SMTP server port
-m   -- Supported enumerating modes are verify and rcpt
-u   -- Path to the file containing user names to be tested
-v   -- Verbose: Shows the server responses
-s   -- Use SSL. NOT FULLY IMPLEMENTED IN THIS VERSION

Vamos a pedirle que se conecte a localhost, dejaremos el puerto sin especificar (por defecto es el 25) y le indicaremos que utilice el método RCPT TO, ya que normalmente el método VRFY está deshabilitado por los administradores.


adrian@Andromeda:~$ ./smtpguess.py -h localhost -m rcpt -u users.txt
Trying to connect to SMTP server...
Conection established successfully
Enumerating Users...
--------------------
--> root exists!
--> lp exists!
manolito doesnt exist : (
--> syslog exists!
antoñito doesnt exist : (
--> adrian exists!

Como podéis ver, ha encontrado varios nombres de usuario :) Ahora ya tenemos parte del trabajo, encontrar credenciales para alguno y a jugar. Y ya sabéis, si tenéis cualquier duda o sugerencia, poned un comentario.

Categorías:hacking, herramientas Etiquetas: , , ,

Una lástima

Quiero aprovechar esta breve entrada para dejar constancia del fiasco de la manifestación de ayer en la puerta del sol, “Por el futuro de la informática. Contra la precariedad“, convocada por la CGT. Creo que para las pocas veces -¿ha sido la primera?- que un sindicato convoca una manifestación a favor de los que trabajamos en el mundo de la informática (sí, a todos, que esto no era por colegios ni regulaciones), la respuesta de la gente ha sido lamentable; no debíamos llegar a 100 personas.

Hubo un antidisturbios al que le entraba la risa mientras comentaba por el walkie “Sí, unos setenta concentrados”. Había casi más antidisturbios que manifestantes. Al final va a ser verdad lo que decían nuestros políticos de que “los informáticos viven muy bien”.

Categorías:General

Comenzamos

Hoy da comienzo la andadura de este blog dedicado a la seguridad, los sistemas, la programación, la tecnología et al. Trataré de que, principalmente, se base en mis experiencias personales dentro del mundo de la seguridad y los sistemas, aunque no descarto que en épocas de poco tiempo libre haga eco de otras noticias o temas relevantes que encuentre en la red ;) Espero que disfrutéis.

Comenzamos…

Categorías:General
Seguir

Get every new post delivered to your Inbox.