Mensajes

no es una vulnerabilidad.. es una feature.. se ha discutido varias veces.. pero pues.. whk opina que como puedes robar cookies en servers compartidos (como dreamhost).. y no hay manera facil de evitarla.. es una vuln..

yo pienso que no.. pero bueno.. jaja

saludos!

Deberian ponerlo en las opciones del navegador

Pero no está esa opción ni hay forma de prevenirlo sin que modifiques el código fuente del explorador o hagas un complemento que modifique la request de las peticiones.

Imagina que normalmente el RFC dice que yo desde geocities puedo establecerte una cookie para google y eso es una feature pero como decian por ahi, era tan peligroso y molesto que alguien pudiera resetear tus cookies o declarar cookies para ataques de tipo xss como pasó en el foro de defcon que bueno, se parchó y se hizo un sistema de prevención pero según todos esto no era una vulnerabilidad sino una feature.

Actualmente si yo tengo un blog en test.blogger.com tengo acceso a leer las cookies de alguien.blogspot.com aunque las cookies se hayan declarado en funcionamiento único para ese subdominio pero aun así pueden utilizarse para otros subdominios y eso no debería ser así pero es así y es una feature pero para mi es vulnerar mi blog porque mi vecino puede tener mis cookies de acceso a un wordpress o lo de esos famosos foros que te los dan con un subdominio x.

Por lo menos un subdominio puedes declararlo en la ruta de la cookie aunque no sirve de mucho pero en ningún lado puedes declarar que una cookie funcione unicamente en un puerto determinado o decir que solo sea visible en el puerto 80.
Si yo tengo un webadmin en el puerto 10000 y luego voy a mi foro y me encuentro con un lindo xss entonces el atacante va a tener no solo la cookie de acceso del foro sino del webadmin y tira por la borda toda la seguridad de ese sistema web porque están compartiendo el mismo sitio donde se aloja la cookie y para mi eso no debe suceder pero sucede y es para todos una feature.

Yo le decia a sdc.. ahora una feature que te permite robar sesiones no es una vulnerabilidad y bueno, entre conversa y conversa me dió a conocer sobre lo del tactical explotation donde justamente un atacante aprobecha problemas de diseño como este que no son considerado vulnerabilidades pero sirven para ataques tal como por ejemplo el (para mi) xss de google donde con un módulo puedes tener acceso al top.location y puedes hacer muchas cosas como por ejemplo invocar sitios fraudulentos y ejercer el phishing pero es una feature xD aunque para mi el SOP debería prevenir la modificación del top.location del DOM así como lo hace para su lectura pero no lo hace y es una feature que a muchos les puede costar la integridad de sus datos personales.

Bueno, no es vulnerabilidad y no es bug, es una feature para el atacante mas que para el usuario xD

[XSS en "theme name" de "themes and layout settings"]

Ya adjunté al post principal dos soluciones mas para las siguientes fallas de seguridad:

XSS en "theme name" de "themes and layout settings"
http://foro.elhacker.net/nivel_web/auditoria_de_seguridad_hacia_simple_machines_forum_20-t271199.0.html;msg1358063#msg1358063

XSS en "theme url and settings"
http://foro.elhacker.net/nivel_web/auditoria_de_seguridad_hacia_simple_machines_forum_20-t271199.0.html;msg1358065#msg1358065

Tienes razón, mejor lo deschincheto xD

creo que alguien debería de pagarte un buen sueldo por lo que haces

Para eso elbrujo me deposita todo los meses a mi cuenta bancaria al igual que todos los moderadores globales y coadmins (claro que los coadmin ganan mas).

Necesitas habilitar el servidor SMTP, si usas un hosting de pago entonces envía un ticket diciendo que tu servidor smtp no funciona, por lo tanto tu sistema web no anda bien.

Si es un servidor dedicado o propio entonces debes instalarle un servicio SMTP
http://www.sorgonet.com/collaborations/servidor-ies/

Hola, lo que tu necesitas es realizar una inyección SQL.

Hay algunas cosas que debes saber primero, por ejemplo que tipo de base de datos utiliza el servidor y que tipo de petición hace el formulario ya sea GET o POST y sus variables.
Si la petición se hace via GET entonces puedes modificar las variables directamente desde el explorador, en caso contrario te recomiendo que utilizes firebug o la consola de comandos para poder escibir manualmente las peticiones. Generalmente al utilizar firebug de firefox puedes evadir sistemas de protección que se realizan via javascript, modificas los inputs o variaables y lo mandas con tu inyección.

Si el sitio WEB utiliza php entonces lo mas probable es que pueda estar utilizando MySQL, si la página es asp, aspx o jsp entonces lo mas probable es que utilize MSSQL, ambos derivados del lenguaje SQL por lo tanto si quieres aprender a realizar una inyección, lo primero que debes hacer es leer un  par de tutos sobre SQL ya que no saco nada con decirte que intentes con x' or 1='1 ya que no sabrás como ingresaste o no vas a entender nada y vas a seguir con las dudas, además si no pudieras ingresar porque tiene parentesis o resultados a inyectar en md5, etc no vas a saber que hacer.

Si quieres aprender inyección SQL te podemos ayudar pero mínimo debes leer un par de tutoriales sobre SQL y entender el lenguaje o si no es como ejecutar un programa y presionar un botón que te hace todo, asi no vas a poder aprender.

Si quieres leer puedes darle un vistazo al foro de bases de datos y php si es que utilizan php y cuando ya vayas entendiendo un poco mas de lo que se trata el SQL puedes venir y hacer todas las preguntas que quieras acerca de este tipo de seguridad básica.

También puedes dare un vistazo a recopilatorio de post relacionados con la inyección SQL y ese tipo de vulnerabilidades:
http://foro.elhacker.net/nivel_web/temas_mas_destacados_fallas_y_explotaciones_a_nivel_web_actualizado_281109-t244090.0.html

Saludos y suerte!.

Este post quedará con chincheta solamente hasta que termine diciembre.

Enjoy!

Bueno, conversando sobre el tema del SOP y las cookies, realmente quería discutir un poco el tema debido a la incompatibilidad del standard de las cookies y el sistema de protección del navegador ya que el mismo standard dice que se pueden establecer cookies a otros sitios webs cosa que está mas que prevenido y la posibilidad de obtener las cookies de un subdominio la cual no tienes acceso como por ejemplo las cookies de wordpress.com y blogger las para mi no deberían tenerse acceso si el administrador del sitio configuró el sistema web para que las cookies se establecieran unicamente para ese subdominio.

Esto lo quería tocar porque pasa muy similar al tema de los puertos y aunque puedes establecer la ruta de la cookie esta no es respetada para su obtención y según el RFC esto es así y para mi no debería suceder, no puede ser que si tengo un xss en un foro alguien pueda venir y tomar la cookie de mi cpanel.

XSS supuestamente ya no hay pero los csrf todavía no son parchados. Ten cuidado de no andar presionando el botón citar o modificar post nada mas que eso.

Se instaló un demo del diseño del foro igual al de la portada  ya está disponible en los themes por si alguien quiere probarlo.

Si hay alguna falla o incomodidad, sugerencia, etc por favor avisen acá para que podamos ir haciendo los cambios.