CategoríaSeguridad

Temas relacionados con seguridad informatica.

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

Seguridad versus Usabilidad: El caso del banco Santander

Con el fin de mejorar la interacción del usuario con algun sistema, los diseñadores y desarrolladores adoptan distintas técnicas de usabilidad para hacerle el trabajo más fácil al usuario, el problema es cuando se prioriza la usabilidad por sobre la seguridad. Para muchos podría parecer que la gente que desarrolla los sistemas piensan que los usuarios son unos tontos unos niños ingenuos, y que por no hacerlos pensar “donde hacer click” le dan todo en bandeja pasando por alto las normas de seguridad. Es por esto que escribiré sobre como la usabilidad pasa por encima de la seguridad.

Como ejemplo, tomaré el caso del Banco Santander y analizaré como una función para hacerle el trabajo más fácil al usuario puede atentar contra la seguridad del mismo usuario. Para muchos podría ser algo básico, pero si lo ven como si fueran un usuario “normal“, se darán cuenta que realmente es un riesgo y que al usuario le podría pasar perfectamente.

Esta es la pantalla de inicio de sesión que vemos al ingresar a www.santander.cl.

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