CategoríaHacking

El captcha de Facebook es una farsa, no sirve y está de adorno!

Los captchas (Completely Automated Public Turing test to tell Computers and Humans Apart) son mecanismos de detección de robots o procesos automatizados que se conectan a nuestros sistemas y nos permite diferenciar entre humanos y maquinas. Muchas veces los captchas previenen registros masivos, bots que se dedican a recolectar información o bien intentos de ataques (por ejemplo fuerza bruta).

En el caso de Facebook, el captcha está de adorno. Manualmente, un usuario puede hacer uso de google para buscar personas y llegar a su página de Facebook, por ejemplo, buscamos a “Juan Perez” y llegamos a su perfil https://www.facebook.com/juan.perez, Facebook nos mostrará un captcha para poder ver si perfil

Si ingresamos las palabras que nos aparecen (iedshm, and) podremos ver un poco más sobre el usuario como su foto

Una persona debería poder ver este tipo de información si ingresa a facebook e ingresa el captcha correspondiente, para evitar que programas automatizados o bots se dediquen a recolectar información de los usuarios, pero la verdad es otra. El captcha de Facebook está de adorno.

Seguir leyendo

Mini-Post: Acceso directo a archivos de descarga

Una forma de hacer un bypass a los sistemas de autenticación es poder acceder a archivos “sensibles” que sólo un usuario con autorización debería poder ver. Existen muchos sitios que tienen panel de administración pero no protegen los directorios donde se encuentran los archivos, por ejemplo, imaginemos que el usuario “admin” subió un archivo con datos de acceso a un servidor y en el sistema configuró que sólo algunos usuarios puedan verlo, sin embargo, cualquier persona que se sepa la URL puede acceder a el … Aunque suene bastante simple e incluso estúpido, es lamentable que existan sistemas o sitios web que lo permiten.

Por lo general, esto sucede cuando no existe una capa intermedia entre el archivo y el sistema, sino que se linkea directamente. Algo que debería ser https://www.dominio.cl/sistema/index.php/descargar/949394 es https://www.dominio.cl/sistema/admin/archivos/usuarios_y_passwords.docx, y en el peor de los casos hasta se puede eliminar el nombre del archivo y listar el contenido del directorio “archivos” 😉

Los sistemas web deberían manejar internamente un “id” o nombre ficticio del archivo, hasheado y mapeado al momento de subirlo, para no permitir que cualquier usuario pueda acceder. Por ejemplo, si tenemos la URL de prueba dada anteriormente, 949394 correspondería al ID del archivo, el sistema debería -internamente- hacer una consulta a la base de datos y ver a que archivo corresponde ese ID, luego ver quienes tienen permisos para acceder a ese archivo y, luego de verificar la sesión y permisos, permitir la descarga del archivo.
Para evitar la descarga directa de los archivos, el directorio “uploads” debería estar fuera del directorio de la aplicación, por ejempo, si el directorio de la aplicación es /var/www/html/sistema1/, el directorio debería estar fuera de “sistema1”, sino, aunque hagas todas las validaciones posibles, de todas formas se podrá acceder directamente al archivo saltandose la validación de la aplicación.

Está preparado el gobierno chileno para recibir un ataque de robo de información ?

Ultimamente se han puesto de moda los ataques de “Anonymous”, ataques como tirar un sitio abajo o saturación de servidores, algo bastante simple que no requiere mucho conocimiento y es por esto que mucha gente se ha sumado. Algunos medios los han llamado ‘hackers‘ otros ‘simples aficionados que se descargan un programa, introducen una URL, se coordinan y presionan enter‘. Por suerte del gobierno no se comparan con los ataques originales de Anonymous o LulzSec. Cuando digo “originales” me refiero a esos ataques que han salido a la luz donde divulgan información sobre las cuentas de usuario e información sensible y privada de las empresas, no a unos wannabe.

Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.

El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.

Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.

Seguir leyendo

Falabella y Ripley: ¿Sitios realmente seguros?

Falabella y Ripley son dos “grandes tiendas” que permiten que sus clientes puedan realizar compras online, ambas dicen ser “100% seguras” y están certificadas por VeriSign. El primer error: existe la seguridad al 100% ?

Ambos sitios son vulnerables a ataques Cross-Site Scripting, permitiendo que un atacante use el sitio web de cada tienda para falsificar contenido y robar información o realizar estafas, aprovechandose de la confianza que el usuario tiene en el sitio web.
Los sitios afectados son: https://www.falabella.cl y https://www.ripley.cl incluyendo los sitios “seguros” (https) de cada uno.

Lo más irónico es que los sitios estan “certificados” por una empresa de seguridad que según ellos:

Verisign, líder mundial en certificación de comercio electrónico.

Aunque no me sorprende, luego de haber encontrado hace un tiempo un XSS en el propio sitio web de VeriSign.

Otra cosa que tambien les debería dar verguenza a estas empresas es prometer 100% de seguridad al usuario, como dice en sus propios sitios web:

Todo esto es una mentira.

Seguir leyendo

Búsqueda de servicios DNS con Transferencia de Zona abierta (AXFR)

Ya vimos que los servidores mal configurados que permiten realizar transferencias de zona sin restricciones desde cualquier IP son muchos.

Para saber si un servidor DNS es “vulnerable” a este tipo de ataque usamos la herramienta dig, primero obtenemos los dns que estan asociados al dominio, para este ejemplo usaremos el dominio zerial.org.

$ dig NS zerial.org
; < <>> DiG 9.7.3 < <>> NS zerial.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 64152
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 6

;; QUESTION SECTION:
;zerial.org. IN NS

;; ANSWER SECTION:
zerial.org. 86400 IN NS ns1.linode.com.
zerial.org. 86400 IN NS ns3.linode.com.
zerial.org. 86400 IN NS ns2.linode.com.
zerial.org. 86400 IN NS ns5.linode.com.
zerial.org. 86400 IN NS ns4.linode.com.

Ya tenemos la lista de los servidores dns de zerial.org, para probar la transferencia de zona cambiamos NS por AXFR y forzamos que use el DNS que nosotros elijamos, en este caso probaremos ns3.linode.com:

$ dig AXFR zerial.org @ns3.linode.com

; < <>> DiG 9.7.3 < <>> AXFR zerial.org @ns3.linode.com
;; global options: +cmd
; Transfer failed.

Failed. No hemos logrado transferir la zona desde ns3.linode.com, lo que nos indica que aparentemente se encuentra bien configurado.
Otro ejemplo usando un dominio que sepamos que tiene esta falla: finanzas.gov.ar.
Obtenemos los dos:

$ dig NS finanzas.gov.ar

; < <>> DiG 9.8.0-P4 < <>> NS finanzas.gov.ar
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 38476
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;finanzas.gov.ar. IN NS

;; ANSWER SECTION:
finanzas.gov.ar. 7006 IN NS ns3.zoneedit.com.
finanzas.gov.ar. 7006 IN NS ns9.zoneedit.com.

Probamos el segundo dns, ns9.zoneedit.com.

$ dig AXFR finanzas.gov.ar @ns9.zoneedit.com

; < <>> DiG 9.8.0-P4 < <>> AXFR finanzas.gov.ar @ns9.zoneedit.com
;; global options: +cmd
finanzas.gov.ar. 7200 IN SOA ns3.zoneedit.com. soacontact.zoneedit.com. 2011266765 2400 360 1209600 300
finanzas.gov.ar. 7200 IN NS ns3.zoneedit.com.
finanzas.gov.ar. 7200 IN NS ns9.zoneedit.com.
finanzas.gov.ar. 7200 IN A 201.253.123.35
finanzas.gov.ar. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.
mail.finanzas.gov.ar. 7200 IN CNAME ghs.google.com.
googleffffffff85ca3fa2.finanzas.gov.ar. 7200 IN CNAME google.com.
asignaciones.finanzas.gov.ar. 7200 IN A 186.136.205.252
docs.finanzas.gov.ar. 7200 IN CNAME ghs.google.com.
www.finanzas.gov.ar. 7200 IN A 201.253.123.35
mapas.finanzas.gov.ar. 7200 IN A 201.253.123.35
finanzas.gov.ar. 7200 IN SOA ns3.zoneedit.com. soacontact.zoneedit.com. 2011266765 2400 360 1209600 300
;; Query time: 355 msec
;; SERVER: 66.240.231.42#53(66.240.231.42)
;; WHEN: Thu Aug 11 13:49:31 2011
;; XFR size: 18 records (messages 18, bytes 1138)

La transferencia de zona se hizo de forma exitosa.

Para poder analizar de forma automatica un listado de dominios, hice un script en bash que usa DIG para obtener los dns de cada dominio y prueba realizar AXFR por cada dominio en todos sus dns.

#!/bin/bash

digcmd=$(which dig)
domain=$1
echo -n "[+] Getting NS domains from $1 ..."
ns_domains=$(dig NS $domain @4.2.2.2|grep ^$domain|awk {'print $5'}|sed 's/.$//g')
echo -e "\t[OK]"
for ns in $ns_domains; do echo "[-] Found: "$ns; done
for ns in $ns_domains
do
	echo -n "Trying Zone Transfer from $ns: "
	$digcmd AXFR $domain @$ns|egrep 'Transfer failed|timed out|end of file'>/dev/null
	if [ $? -eq 1 ]
	then
		echo -e "\tSuccess."
	else
		echo -e "\tFail."
	fi
done

Seguir leyendo

AXFR: Una vulnerabilidad que pasa desapercibida …

Las transferencias de zona en los servidores de DNS en simples palabras se usa para replicar lo que hay en un maestro hacia su escalvo. Si esta caracteristica se encuentra mal configurada podria ser usada por un atacante para obtener información sensible sobre el dominio.
Un servidor maestro debe filtrar por dirección IP qué esclavos pueden realizar transferencias, si esto no se configura correctamente entonces cualquier atacante podría consultar por las zonas de los dominios que administra.

imagen: https://getglue.com/topics/p/dns_zone_transfer

Las transferencias de zona se realizan mediante AXFR, que según su descripción:

Las siglas AXFR hace referencia a la transferencia por zonas de un DNS primario a un DNS secundario o de un DNS primario a un server maestro y de un server maestro a un DNS secundario, si llegara a existir algún problema de configuración o actualización del software de cualquiera de estos servidores se podrían explotar una serie de vulnerabilidades como por ejemplo un DoS y la integridad y confidencialidad de la base de datos del DNS primario se verían comprometidas, se estima que alrededor de un 60% de los servidores DNS en internet son vulnerables.

(Fuente: https://es.wikipedia.org/wiki/AXFR)

Tambien exsite la transferencia de zona incremental (IXFR).

Seguir leyendo