Re: Seguridad en PostgreSQL

Alejandro Gasca dijo [Fri, Nov 03, 2006 at 12:25:37PM -0600]:
> Algun link para aprender sobre ataques reales de seguridad a postgres?

Una de las mejores es esta:

http://www.google.com.mx/search?q=postgresql+vulnerability

Si lees los boletines que te menciona, te será fácil entender a qué
tipo de ataques te refieres - Un par de ejemplos:

- Falla en la validación de argumentos de autorización en una sesión
ya iniciada[1]
- Errores de codificación que llevan a posible inyección SQL[2]
- Algunos errores conceptuales de diseño que llevaron a estructuras
abusables (como RULE) que han sido eliminadas en los últimos
releases[3]

Ahora, toma en cuenta que con esto aprendes los _síntomas_, no las
_causas_. si quieres realmente aprender de seguridad en Postgres, vas
a tener que aprender a fondo acerca de Postgres. Por ejemplo, Álvaro
podría callarme respecto a lo que menciono en [3], puesto que no sé a
qué se refiere, sólo cito lo que ví en una página. No he leído el
código que puede sustentar mis palabras.

> por otro lado, yo tambien tengo la idea que es buena practica ocultar
> lo mas que se pueda de la estructura de la base al "usuario final",
> aunque confieso que *no se realmente* en que ayuda eso a evitar ataques
> a la base... como dicen, es mas una medida de "ocultamiento" que puede
> eventualmente ocultar los mismo errores en el diseño de la base, y pues
> eso sale peor.

No sólo es respecto al diseño de la base, sino que de tu
aplicación. Por ejemplo, si el usuario recibe un mensaje de error
indicando que en la tabla "articulos" no existe el ID 450, puede
buscar dónde en la solicitud Web está pidiendo un 450, y generar una
solicitud en que reemplace a ese número por otro, tal vez desplegando
un artículo al que no tiene acceso. O tal vez reemplazándolo por un
bonito:

450; DELETE FROM articulo; --

con lo que si tu aplicación está mal escrita e interpola la entrada
del usuario directamente en tu SQL:

($nombre, $descripcion) = $dbh->selectrow_array("SELECT nombre,
descripcion FROM articulo WHERE id = $cgiparam{id}");

el atacante podrá borrar tu tabla completa. Claro, ¿cómo puedes
protegerte de esto? Evitando interpolar, usando statements preparados
y placeholders:

$sth = $dbh->prepare('SELECT nombre, descripcion FROM articulo
WHERE id = ?');
$sth->execute($cgiparam{id});
($nombre, $descripcion) = $sth->fetchrow_array;

(mis ejemplos son en Perl, pero estas técnicas son iguales en
cualquier lenguaje)

En fin... Este es sólo el más clásico de los ataques a cualquier BD
que hable SQL o algo parecido.

> Por otro lado, que tanto afecta el descubrimiento de vulnerabilidad que
> se habla por ahi del md5? digo porque un usuario cuaquiera podria ver
> los md5 de los passwords, si no se le restrige el select a los
> catalogos para usuarios... o todo esto es pura paranoia?

Es pura paranoia. No entro en detalles, pues otras personas ya lo han
hecho. Bueno, hay un par de puntos que sí agrego - Para que un
atacante pueda "olfatear" el MD5 de tu contraseña, tiene que estar en
la red física donde está tu BD, tu aplicación cliente (digamos, un
servidor Web), o en el camino entre ambas (y normalmente buscarás que
estas dos máquinas estén en misma una red bien protegida). No puede
simplemente olfatear el MD5 desde su computadora en casa. E incluso si
pudiera, supongo que en tu pg_hba.conf tienes restringido el login a
cada una de tus bases de datos con determinado usuario desde
determinado host, ¿o no? Además de eso, supongo que el firewall de tu
sitio filtra cualquier conexión no autorizada, dado que no tienes por
qué aceptar conexiones arbitrarias a Postgres desde fuera de tu red
local, ¿cierto? Bueno, el MD5 -incluso si hubiera sido tronado de la
manera más vil posible, incluso si alguien publica tus contraseñas en
claro en Internet- no debe preocuparte.

Sin embargo, sí te recalco esto: ¿Te interesa la seguridad? ¡Bien!
¡Felicidades, tienes una parte importante del camino andada! El resto
del camino, sin embargo, lleva mucho estudio. No te dejes alarmar sin
saber de lo que se habla, ni te confíes ciegamente de un consejo que
veas por ahí tirado. Ser un buen programador, ser un buen
administrador de sistemas, o en general ser un buen profesional
implican mucho y muy constante trabajo de aprendizaje y
actualización.

Saludos,

[1] http://lists.grok.org.uk/pipermail/full-disclosure/2006-February/042552.html

[2] http://www.postgresql.org/docs/techdocs.50

[3] http://developer.postgresql.org/pgdocs/postgres/release-8-2.html

--
Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF