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

PHP 5.2.13 Release parchea 30 bugs y medidas de seguridad

PHP.net anunciaba hoy la salida de la versión 5.2.13 de PHP solucionando más de 30 bugs en el funcionamiento de PHP y reparando algunas fallas de seguridad.

Entre ellas errores en las funciones strip_tags, DOMDocument::LoadXML, filter_input, etc..

Se recomienda, como en cada nueva versión la actualisación de los sistemas PHP 5.x.x

Reporte de PHP.net

Apple Safari 4 y Google Chrome 4 CSS style Stack Overflow Dos/Poc

Hace cosa de 2 horas me llegaba este retweet de Dragon sobre esta vulnerabilidad.

Lastimosamente tengo el chrome 5 y no dispongo de safari así que no lo he probado.

Link del exploit: http://url4.eu/1TCJS

Vulnerabilidad en Wordpress 2.9

Thomas Mackenzie ha encontrado un bug del tipo Failure to Restrict URL Access en Wordpress 2.9 y superiors.

Los post que están en la basura pueden ser cambiados de usuarios por usuarios logueados en el sistema. Este problema sólo afecta a aquellos sitios que tengan escritores y colaboradores ajenos al círculo íntimo del blogger principal. No es un error de importancia para aquellos blogs como este en el que escribimos un número reducido de personas y que además todas somos administradoras.

Fuente: Segu-info y Linux Hispano

Vulnerabilidad en Wordpress: Full Path Disclosure

Hoy revisando los mensajes en elhacker.net leo un pequeño aviso de full path disclosure en Wordpress.

No comenta si son solo algunas versiones o todas, lo que es evidente es la vulnerabilidad.

El FPD se proudce en el directorio /wp-includes/.

El motivo, sospecho, se debe a que Wordpress trabaja mesclando varias páginas, y al abrir una de estas sin las demás se produce un error al intentar cargar una función como es el caso:

Fatal error: Call to undefined function add_filter() in /home/-censored-/public_html/wp-includes/user.php on line 70

Como se puede apreciar se produce un error intentando cargar una función llamada add_filter y eso nos da el FPD.

La solución:

Se me ocurren dos:

La primera podría ser agregar error_reporting(0); en cada linea del documento.

La segunda, depende más de la forma de trabajar de Wordpress, pero sería imitar en parte el método de SMF con un define('WP', 1) y en cada página comprobar si está definida o die();

La forma de encontrar el FPD fué al entrar al directorio /wp-includes/ y desde allí ir abriendo archivos hasta que uno de error, en caso de que no apache no nos indexen los archivos también podemos buscar los archivos afectados.

Entre los archivos afectados están update.php, user.php y rss.php por citar tres de ellos.

Ahora que conocemos el problema y la solución, solo falta protejer nuestro blog de wordpress, si lo tenemos.
Saludos

Chuleta vulnerabilidades OWASP Top 10 2010



Hoy en Google Reader me encuentro que Jeff Williams compartia este pdf proveniente del blog greeboo.net bajo la licencia de Creative Commons Attribution-Share.

El PDF trata de un TOP 10 de vulnerabilidades/errores a la hora de la programación de aplicaciones.

Desde las ya más que conocidas Injections y XSS pasando por sessiones de usuario desprotejidas, poca encriptación, etc.

Son 2 hojas que realmente vale la pena tener cerca a la hora de programar nuestra aplicación.

Descargar: OWASP 2010 TOP 10

0day en base de datos oracle

Un experto en seguridad informática considera que nueve de cada diez bases de datos Oracle son vulnerables a un ataque que podría dar a los hackers el acceso y control de la sensibilidad de las empresas y los sistemas de base de datos del gobierno, sin la necesidad de una identificación de usuario o contraseña.

David Litchfield, jefe de investigación en NGSSoftware Ltd, una compañía con sede en Reino Unido dijo haber reportado a Oracle la vulnerabilidad desde Noviembre (Oracle 10.2.0.4), pero no fue solucionado en los parches de seguridad de enero. Por lo que ha decidido hacerlo público (”11g 0day exploit”) durante la conferencia Black Hat en Washington el miércoles.

Litchfield dijo que “permite a un atacante sin un ID de usuario y contraseña tomar el control completo. Todos los firewalls se vuelven irrelevantes”.

Aunque es posible prevenir la explotación cambiando la configuración por defecto del software, Litchfield cree que nueve de cada diez bases de datos son vulnerables. Añadió que no había manera de saber si los hackers ya aprovechan la vulnerabilidad para acceder a una base de datos.

Mientras tanto Black Hat retiró el video de David Litchfield donde se mostraba el código y Oracle no ha hecho algún comentario al respecto.

Fuente: latinohack.com

Cuando el administrador se duerme

A lo largo de mi "carrera", que no es larga precisamente he tenido la oportunidad de comprobar la verdad absoluta de un administrador web, "si te duermes te joden".

Cuando un admin dice "no tengo ganas de actualizar el soft", "una contraseña robusta es dificil de recordar" y todas esas frases que a los amantes de la seguridad nos da pánico escuchar es cuando se producen los mayores errores en la securisación del servidor.


Hoy vamos a hablar de un caso en especial, resulta que anoche estaba aburrido y me dirijí a la comunidad DragonJAR donde leí un paper de Shell Root sobre controlar un servidor via XAMPP, entusiasmado con la idea y con ganas de probar lo aprendido ideé una dork en google que, impresionantemente, el tercer resultado de esta tenia los valores por defecto de XAMPP es decir:

user: root
no password

Cuando lo vi me dió verguenza ajena....

Lo mas "divertido" de la página es lo que reza en su index:

The main objective of the MOMENT project is to design and implement a mediator architecture to offer a unified interface to all data bases and measurement facilities for IP traffic monitoring and service supervision. Thus its users will be able to submit advanced queries based on semantic access, with possible combinations of different data sources, with privacy protection mechanisms.

Y bien... para finalizar dejo un par de capturas del desastre

xammp owned

Se aprecia claramente que el usuario es root


Y el desastre de desastres... una shell subida...

Espero que a partir de ahora configuren con un mínimo de seguridad sus servidores!!

Bug en Mysql en tipos BINARY, VARCHAR, CHAR

Como un artículo anterior este viene de la mano de ^Tifa^ y como su descubridora todos los méritos a su persona.

El escenario




mysql> CREATE TABLE ejemplo(
    -> nombres BINARY(20));
Query OK, 0 rows affected (0.39 sec)
 
mysql> INSERT INTO ejemplo VALUES('Juan'),('Pepe'),('Jose');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec)
 
 
Ese es el escenario.
Ahora una actualización de datos:
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = hex('Juan');
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec) 

Como se aprecia ni se actualiza ni se borra...

Intentamos solucionar el tema con un alter:

 
mysql> DESCRIBE ejemplo;
+---------+------------+------+-----+---------+-------+
| FIELD   | Type       | NULL | KEY | DEFAULT | Extra |
+---------+------------+------+-----+---------+-------+
| nombres | BINARY(20) | YES  |     | NULL    |       |
+---------+------------+------+-----+---------+-------+
1 row IN SET (0.00 sec)
 
mysql> ALTER TABLE ejemplo MODIFY nombres varchar(25);
Query OK, 3 rows affected (0.45 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec)
 
 
ni por ahí...
Esto también se aplica también a tablas con datos tipo char, varchar,etc 
si se altera a binary.
 
mysql> CREATE TABLE ejemplo2(
    -> nombres varchar(20));
Query OK, 0 rows affected (0.38 sec)
 
mysql> INSERT INTO ejemplo2 VALUES('pepe'),('Juan'),('pedro'),('luis');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| pepe    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows IN SET (0.00 sec)

Un ejemplo con varchar funcionando perfectamente

mysql> UPDATE ejemplo2 SET nombres = 'Cucu' WHERE nombres = 'pepe';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| Cucu    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows IN SET (0.00 sec)
 
 
Ahora alteramos a Binary
mysql> ALTER TABLE ejemplo2 MODIFY nombres BINARY(20);
Query OK, 4 rows affected (0.27 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+----------------------+
| nombres              |
+----------------------+
| Cucu                 |
| Juan                 |
| pedro                |
| luis                 |
+----------------------+
4 rows IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
 
se jodió la tabla...
volvemos a varchar
 
mysql> ALTER TABLE ejemplo2 MODIFY nombres varchar(20);
Query OK, 4 rows affected (0.10 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> DESCRIBE ejemplo2;
+---------+-------------+------+-----+---------+-------+
| FIELD   | Type        | NULL | KEY | DEFAULT | Extra |
+---------+-------------+------+-----+---------+-------+
| nombres | varchar(20) | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
1 row IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
Como se aprecia gracias al Changed: 0
no se actualizaron los datos pese a su tipo varchar.
 
 
Fuente original: Mini-Bug en Mysql 

Posible 0Day para MySQL 5.x

Leyendo hoy el blog de Security By Default me entero de que posiblemente tengamos una preocupación más todos los webmasters que utilizamos MySQL.

Aunque SbD ni afirma ni desmiente que el 0Day sea verdadero, la empresa detrás del 0Day, intevydis, parece ser de fiar

Dicha empresa comercializa un 'pack' de exploits para Canvas y ha colgado un video que muestra el 0Day para MySQL en versiones 5.x

Fuente: SbD