Exploit en MySQL aprovecha vulnerabilidad para obtener acceso de administrador Root

Estándar

Fuente: http://www.muycomputerpro.com/2012/06/11/una-vulnerabilidad-en-mysql-permite-ganar-acceso-root/

Varios exploits para un fallo de autenticación en MySQL se están extendiendo en diversos canales en Internet, en parte porque este error es especialmente sencillo de aprovechar para ganar acceso root a la base de datos.

El único factor que disminuye su peligrosidad es el hecho de que depende de la librería C con la que se implementó MySQL. Este “bypass” del sistema de contraseñas tiene ya asignada un código de vulnerabilidad, la CVE-2012-2122, y permite que un atacante logre acceso root a la base de datos repitiendo varias veces el intento de acceder a dicha cuenta con una contraseña incorrecta.

La vulnerabilidad ha sido detallada por el coordinador de seguridad de MariaDB -un fork de MySQL, y se debe a un error en el llamado error de casting al comparar la contraseña esperada con la contraseña introducida.

Oracle ya corrigió el problema de este bug -que codificó como 64884– tanto en MySQL 5.1.63como en MySQL 5.5.24, ambos lanzados hace un mes. La corrección consiste en un simple cambio en una línea, y un parche similar se puede aplicar al código fuente de MariaDB.

Distribuciones como Ubuntu (10.04, 10.10, 11.04, 11.10 y 12.04), openSUSE 12.1 64 bits, Fedora 16 64 bits y Arch Linux tienen esta vulnerabilidad, mientras uqe Debian, RHEL, CentOS y Gentoo parecen estar a salvo. Lo ideal es actualizar los paquetes en los sistemas afectados cuanto antes.

Fuente 2: http://www.hackplayers.com/2012/06/evasion-de-autenticacion-en.html

Sergei Golubchik, el coordinador de seguridad de MariaDB (un derivado de MySQL con licencia GPL), ha encontrado un serio bug en MySQL y MariaDB que podría permitir a un atacante evadir la autenticación de la base de datos.

La vulnerabilidad identificada como CVE-2012-2122puede afectar a todas las versiones 5.1.61, 5.2.11, 5.3.5, 5.5.22 y anteriores de ambos motores de base datos, siempre que hayan sido compiladas con librerías que permiten que la rutina memcmp() pueda llegar a devolver enteros fuera del rango de -128 a 127 (Linux glibc
sse-optimized
).

Cuando un usuario se conecta a MariaDB/MySQL, se calcula un token (un hash SHA a partir de su contraseña y una cadena al azar) y se compara con el valor esperado. Debido a una serie de pruebas incorrectas, puede ocurrir que el token y el valor esperado se consideren iguales, incluso si la función memcmp() devuelve un valor distinto de cero. En este caso, MySQL/MariaDB puede pensar que la contraseña es correcta, aunque no lo sea. Debido a que el protocolo utiliza cadenas aleatorias, la probabilidad de provocar este error es de aproximadamente de 1 sobre 256.

Esto significa que, si se conoce un nombre de usuario para conectarse (y el root casi siempre existe), podremos conectarnos con “cualquier” contraseña con repetidos intentos de conexión. Unos 300 intentos sólo nos llevaran una fracción de segundo, así que básicamente la protección con contraseña de la cuenta es como si no existiera. Además cualquier cliente puedo hacerlo, no hay necesidad de una biblioteca libmysqlclient especial“.

Contramedidas:

La primera regla para securizar MySQL es no exponer la base de datos en la red. La mayoría de las distribuciones de Linux configuran el acceso al demonio de MySQL sólo para localhost. En caso de que sea necesario habilitar el acceso remoto al servicio, MySQL también proporciona controles de acceso basados en host.

Lo más fácil es modificar el archivo my.cnf con el fin de restringir el acceso al sistema local. Busca la sección [mysqld] y cambia (o añade una nueva línea para configurar) el parámetro “bind-address” a “127.0.0.1”. Reinicia el servicio de MySQL para aplicar esta configuración.

La siguiente recomendación claramente es actualizar o parchear la base de datos. Oracle ya corrigió el error en MySQL, bug id 64884, con las versiones MySQL 5.1.63 y 5.5.24, ambas publicadas hace un mes. La corrección aplicada es un único cambio en una línea; también hay un parche similar disponible para MariaDB. En breve, se espera que las distintas distribuciones de Linux vaya publicando parches para sus correspondientes versiones de MySQL.

Referencias:
 
CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability
CVE-2012-2122 : Mysql Authentication Bypass Exploit
Simple authentication bypass for MySQL root revealed 
CVE-2012-2122: A Tragically Comedic Security Flaw in MySQL (comprobación de sistemas afectados)

Sistemas vulnerables:

  • Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 ) ( via many including@michealc )
  • OpenSuSE 12.1 64-bit MySQL 5.5.23-log ( via @michealc )
  • Fedora 16 64-bit ( via hexed )
  • Arch Linux (unspecified version)

Sistemas NO vulnerables:

  • Official builds from MySQL and MariaDB (including Windows)
  • Red Hat Enterprise Linux, CentOS (32-bit and 64-bit) [ not conclusive ]
  • Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
  • Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
  • Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch )
  • Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Gentoo 64-bit 5.1.62-r1 ( via @twit4c )
  • SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c )

mysql1 Una vulnerabilidad en MySQL permite ganar acceso root

Evitar ataques SQL Injection en IIS7 con SQL Server

Estándar

En este post hablaremos sobre un tema que interesa a cualquiera que desarrolle o trabaje con bases de datos en una aplicación web, los ataques con inyección SQL.

¿Que es un ataque con inyección SQL (SQL injection)?

En principio los ataques SQL injection son combinaciones de técnicas para conocer datos sobre la configuración de un servidor web y de su base de datos, de forma que, de manera mas o menos directa, se pueda conseguir acceso a la misma, para usarla en beneficio del atacante, bien borrando datos, copiandolos y vendiendolos posteriormente o manipulandolos para conseguir algún objetivo, como puede ser la propagación de un virus desde esa misma página.

Los ataques consisten en la adición de sentencias SQL especiales que, ejecutadas en el servidor, le den al atacante información tecnica sobre la base de datos y posteriormente acceso de algún tipo.

¿Son evitables todos los ataques  SQL Injection?

Un servidor web publico siempre podrá ser accedido por cualquier usuario que acceda a la página o conecte a través de un programa informático, con lo que siempre estará expuesto. Incluso en servidores internos de redes empresariales podemos tener problemas con cualquier usuario, por eso son importantes el uso de todas las técnicas que vamos a ver en este post.

Es probable que nos dejemos alguna ya que vamos a hablar sobre servidores IIS y SQL Server, podeis dejar vuestras aportaciones en los comentarios si teneis alguna para otras bases de datos o servidor web.

¿Cualquier base de datos es susceptible de un ataque SQL Injection?

En principio las mas usadas en aplicaciones web como Mysql, Oracle, SQL Server y Access (increible que todavia se use para webs) son susceptibles de ser atacadas para conseguir el acceso, cada una con sus diferentes sintaxis, pero en general las técnicas son similares.

Técnicas de defensa ante ataques SQL Injection

1. Páginas de error personalizadas

No hay que ponerselo fácil a los atacantes de nuestras webs.

Al principio de un ataque se usan diferentes sentencias para que la página proporcione errores de sintaxis al intentar ejecutarlas y de esa manera conocer que versión de base de datos usa nuestra aplicación, para ser más precisos en las siguientes oleadas. Si queremos ver los errores cuando estamos desarrollando, pero queremos que sean invisibles al resto de usuarios, podemos generar una página de error personalizada que solo muestre los detalles a una determinada IP o si estas logado en un panel de control de la propia web, mientras que el resto de usuarios veran un bonito mensaje creado por ti sin detalles sobre el error.

2. Uso de procedimientos almacenados.

Una de nuestras experiencias contra ataques de inyeccion SQL fue en un cliente que ya tenia la aplicacion web funcionando y nos llamo para realizar un proyecto de SEO. La web tenia distintas funcionalidades, aunque basicamente era un buscador de textos cientificos. Nuestra sorpresa llego cuando al revisar el código en ASP muchas llamadas a la base de datos se realizaban de manera directa haciendo “select ” con parametros querystring (GET) en vez de usar procedimientos almacenados contra SQL Server.

¿Que implica ejecutar selects con parametros?

Los select con parametros son la puerta de entrada a los ataques SQL injection ya que salvo excepciones que ya veremos mas abajo, su uso deja abierta la puerta para que poniendo un simple punto y coma “;” todo lo que venga detras en el querystring sea ejecutado en la base de datos.

/pagina.asp?id=1;update users set name=’codigo javascript con enlace a un virus’

si en el script pagina.asp usamos una select abierta podemos hacer que la base de datos ejecute la sentencia detrás del ; en este caso cambiando el valor de un campo en toda la tabla de usuarios por un codigo javascript que nos lleve a una pagina con virus, que fue lo que ocurrió en este cliente. Todos los que trabajamos con bases de datos usamos nombres muy parecidos en muchas aplicaciones, por comodidad y sencillez de mantenimiento, con lo que determinadas tablas suelen tender a tener el mismo nombre en muchas webs haciendo mas fácil un ataque dirigido en este sentido.

¿Cual es la ventaja de los procedimientos almacenados?

En el caso de los procedimientos los parametros entran por separado y ademas “tipados”, esto significa que si el servidor espera un valor numerico (int) al recibir el “update …” fallará y no se ejecutará. Y en el caso de varchars podria incorporar el texto en un update, pero nunca se ejecutaría directamente minimizando el riesgo.

¿Tiene alguna debilidad un procedimiento almacenado?

Si, en general en el momento que un procedimiento almacenado se hace “dinámico”, es decir, que no ejecuta directamente siempre la misma operación, sino que recibe en un parámetro la sentencia sql y la ejecuta de manera interna. En este caso el problema es el mismo que en las selects abiertas.

Siempre hay que usar procedimientos parametrizados (ejemplo en ASP):

set cmd=Server.CreateObject(“ADODB.Command”)
Set Cmd.ActiveConnection = wConn
Cmd.CommandType = adCmdStoredProc
Set rs= Server.CreateObject(“ADODB.Recordset”)
Cmd.CommandText = “PROCEDIMIENTO_ALMACENADO”
Cmd.Parameters(“@ID”) = request.QueryString(“id”)
set RS=Cmd.Execute()

3. Filtros en la configuración de la web.

En el caso de IIS7 podemos generar un filtro bastante efectivo en toda la página web haciendo uso del archivo web.config, colocando unas cuantas lineas que protejan los parametros hacia ASP y ASP.NET.

Debajo de <system.webServer> colocaremos este código que dejamos, esto filtra en las URL todas las palabras clave listadas, que , salvo excepciones, son usadas solo en entornos de base de datos. Si el servidor IIS encuentra una coincidencia, muestra el error 404 de no encontrado cuando el atacante intente acceder a la página con esos parametros o URL.

<security>
<requestFiltering>
<filteringRules>
<filteringRule name=”SQLInjection2″ scanQueryString=”true”>
<appliesTo>
<add fileExtension=”.asp” />
<add fileExtension=”.aspx” />
</appliesTo>
<denyStrings>
<add string=”–” />
<add string=”/*” />
<add string=”alter” />
<add string=”begin” />
<add string=”create” />
<add string=”cursor” />
<add string=”delete” />
<add string=”drop” />
<add string=”fetch” />
<add string=”insert” />
<add string=”kill” />
<add string=”open” />
<add string=”select” />
<add string=”sys” />
<add string=”table” />
<add string=”union” />
<add string=”update” />
<add string=”top” />
<add string=”iif” />
<add string=”from” />
<add string=” or ” />
<add string=” in ” />
<add string=”chr” />
<add string=”asc(” />
<add string=”curdir” />
<add string=”len(” />
<add string=”ascii” />
<add string=”substring” />
<add string=”length” />
<add string=”@version” />
<add string=”exists” />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>

el problema es que puede haber excepciones en las que haya palabras clave que podamos usar en alguna URL, lo que haria que tuviesemos que quitarlas de este filtro inicial.

4. Función de limpieza

Puede no ser técnicamente muy acertada, pero sin duda es muy efectiva, ya que nos permite dejar pasar en primera instancia determinadas palabras y luego filtrarlas en parametros según nuestra conveniencia, en ASP seria tal que así:
function clear_param(texto)

dim texto_final
texto_final=replace(texto, “SELECT”, “”)
texto_final=replace(texto_final, “‘”, “”)
texto_final=replace(texto_final, “UPDATE”, “”)
texto_final=replace(texto_final, “DELETE”, “”)
texto_final=replace(texto_final, “DROP”, “”)
texto_final=replace(texto_final, “UNION “, “”)
texto_final=replace(texto_final, “%”, “&#37;”)
texto_final=replace(texto_final, “%00”, “”)
texto_final=replace(texto_final, ” TOP “, “”)
texto_final=replace(texto_final, ” GROUP “, “”)
texto_final=replace(texto_final, “=”, “”)
‘texto_final=replace(texto_final, “>”, “&#62;”)
‘texto_final=replace(texto_final, “<“, “&#60;”)
texto_final=replace(texto_final, “IIF”, “”)
texto_final=replace(texto_final, “FROM”, “”)
texto_final=replace(texto_final, ” OR “, “”)
texto_final=replace(texto_final, ” AND “, “”)
texto_final=replace(texto_final, ” IN “, “”)
texto_final=replace(texto_final, ” CHR “, “”)
texto_final=replace(texto_final, ” ASC(“, “”)
texto_final=replace(texto_final, ” CurDir “, “”)
texto_final=replace(texto_final, “LEN(“, “”)
texto_final=replace(texto_final, “SHELL”, “”)
texto_final=replace(texto_final, “ASCII”, “”)
texto_final=replace(texto_final, “SUBSTRING”, “”)
texto_final=replace(texto_final, “LENGTH”, “”)
texto_final=replace(texto_final, “version”, “”)
texto_final=replace(texto_final, “exists”, “”)
clear_param=texto_final

End function

una función de este tipo servirá para limpiar un querystring en el caso de que por alguna razón debamos usarlo directamente sobre una select, para complementar el filtro en web.config:

clear_param(request.QueryString(“id”))

5. Bloqueo de IP´s

Como medio de disuasión es interesante si el atacante no es demasiado habil ya que burlar un bloque de Ip es relativamente sencillo con programas para navegación anónima, pero tambien sirve como bandera del ” te hemos visto y estamos preparados” lo que puede hacer que ese hacker se interese por otras webs más faciles que la nuestra. En la página de errores personalizados podemos tener una función que guarde un log con el error y la IP que lo ha producido, si además guardamos los parametros querystring que han producido el fallo podemos identificar los intentos de hacking a la web y la IP del atacante.

Todas estas técnicas de prevención de ataques SQL injection son aplicables en otros lenguajes, servidores web y bases de datos, usando en cada caso su propia sintaxis.

Si te ha servido este post o se nos olvida algo, por favor, deja un comentario y cuéntanos tu experiencia.

Un gusano se expande gracias a twitter usando el acortador de URL´s goo.gl

Estándar

Un gusano esta en rapida expansion usando twitter y utilizando el servicio de redirección goo.gl de Google para dirigir a los usuarios hacia la página de un falso antivirus.

Durante el día de hoy, esta búsqueda de Twitter muestra los miles de mensajes por los cuales sigue extendiéndose el gusano.

De acuerdo a expertos en seguridad que siguen este virus, la cadena del gusano redireccióna a los usuarios a una página Web que sirve el “Escudo de Seguridad” Rogue AV. La página está utilizando técnicas de ocultación que incluyen el uso de criptografía RSA en JavaScript para ocultar el código de la página.

Nicolas Brulez experto de Kaspersky Labs (mas información ) dice que los enlaces originales de  “goo.gl” en los mensajes de Twitter están redirigiendo a los usuarios a diferentes dominios con una página “m28sx.html” .

Esa página redirige a un dominio estático con una dirección de nivel superior de Ucrania.

Como si no fuera suficiente, este dominio redirecciona al usuario a otra dirección IP que se ha vinculado en el pasado a las distribuciones de falsos anti-virus. “Esta dirección IP, entonces hará el trabajo de redirección final, que conduce al lugar del falso antivirus”, explicó Brulez.

Una vez que una sesión de usuario del navegador se redirige al sitio malicioso, un mensaje de advertencia afirma que el equipo está ejecutando aplicaciones sospechosas y se anima al usuario a ejecutar una exploración.

Siempre dará como resultado que la máquina está infectada con virus, y así engañar al usuario para descargar una herramienta de desinfección falsa y provocar la infección del equipo.