Mensajes

Es lo que he dicho!

Sale dando a copiar ruta del enlace, porque si pones ver código fuente de la página ahí esta, es como poner ...

http://rapidshare.com/files/15829328...AL_.part01.rar

Saludos

Eso es porque el link "completo" esta en el código fuente, así que si buscas ahí lo encontrarás 

Saludos

Tienes razón, retiro lo dicho, creo que me voy a tener que montar una VM con Vista 

Saludos

pero seguiria abriendose en forma visible xD y seria muy obvio que estan infectados  

Call ShellExecute(0&, "OPEN", "http://www.google.es", vbNullString, vbNullString, SW_HIDE)

Saludos

Que dice al pie del foro?  

Saludos

P.D: igualmente los del foro siempre estan parchados XD

Por que no disminuír un poco la calidad de las imagenes? 

Saludos

Un consejo para el próximo abril negro ... leer las bases  

http://foro.elhacker.net/analisis_y_diseno_de_malware/abril_negro_2009_concurso_de_desarrollo_de_malware-t252105.0.html

Método de calificación:

Los principales jueces de este evento seréis vosotros mismos con vuestros votos. Para evitar que solo se valore el aspecto gráfico del trabajo (ya que es lo primero que se ve)  se incluirán dos criterios más de calificación:

    - El trabajo más original
    - El mejor código

Los miembros de el staff de elhacker.net serán los encargados de valorar estos dos aspectos de los trabajos, quedando lógicamente excluidos de la valoración de sus propios trabajos.
La puntuación extra por obtener uno de estos dos títulos es el equivalente a obtener un +10% de los votos totales emitidos por los usuarios redondeados a la baja.

Dicho de otra forma, si en total los usuarios del foro han emitido 65 votos en total, una aplicación con uno de estos dos títulos obtendría 6 puntos extra.

Nadie dijo que esta votación es la última palabra 

[aquí]

Por todos es conocido que los servidores web son uno de mayores objetivos de los ataques de hoy en día. El dinero y los datos accesibles a través de los portales web, con la finalidad de ofrecer un servicio, una vez más, se ven afectados por una nueva amenaza, un nuevo tipo de ataque.

En concreto, esta nueva técnica ha sido expuesta durante la conferencia OWASP Appsec Poland 2009 por parte de los expertos en seguridad Stefano Di Paola y Luca Carettoni y ha llegado en modo de correo a los suscritos a Bugtraq.

¿En qué consiste el ataque?
Pues una vez más (como sucede con un SQL Injection o una inyección de comandos) en la reacción que tiene el servidor web ante la manipulación de algún parámetro o cabecera en una aplicación web.

En este caso, consiste en la interpretación que tiene un servidor web cuando se repite el nombre de un parámetro dentro de la misma petición. Un ejemplo:

http://www.miaplicacion.com/index.asp&variable1=val1&variable2=val2

En este caso, cada variable recibiría su valor correcto por parte del servidor web y todo OK.

Sin embargo, supongamos que http://www.miaplicacion.com/index.asp&variable1=val1&variable1=val2

¿Qué valor tendría variable1 esta vez? Pues la respuesta es: depende del servidor web que lo interprete. Unos servidores asignarán el val1 y otros asignarán val2. En otros casos como IIS, su mecanismo interno los concatenará.

Por ejemplo, IIS se sabe que los concatena separándolos por comas. Apache solamente se queda con el primer valor que recibe un parámetro desechando el resto.

El impacto de este comportamiento por parte de los servidores Web puede ser enorme a la hora de procesar los argumentos, y puede dar lugar a múltiples posibilidades como sobreescritura de parámetros HTTP definidos por la aplicación en la URI, alteración del comportamiento de la aplicación, acceso y modificación de variables,... etc

Algo muy interesante es que aquellas empresas que como medidas preventivas de protección de sus aplicaciones web tengan un WAF (Web Application Firewall), que les permita sanitizar la entrada de las peticiones entrantes, tampoco estarán protegidas del todo.

En líneas generales, los Firewalls de Aplicaciones Web analizan las peticiones web basándose en firmas generalmente. Estas firmas son expresiones regulares que enfrentan contra las peticiones (los parámetros, las cabeceras, incluso el cuerpo de la página, etc...) de manera que, como si de un antivirus se tratara, si alguna de las "cadenas" coincide con la petición, la misma es bloqueada. Ahora bien, aprovechando esta nueva línea de ataque, es posible encapsular en la misma variable (repetida varias veces con diferente valor) un ataque, que si fuera en una sola variable, sería fácilmente detectada y bloqueada por cualquier WAF. De esta manera, al analizar cada parámetro, no se delimitaría como algo maliciosa la petición y sin embargo, al ser reensamblada e interpretada por el servidor web, sí que podría ser un riesgo en la seguridad de la aplicación.

Aquellos WAFs que no estén basados en tecnología de reverse proxy (proxy inverso) permitirán ser bypasseados ante este tipo de ataque.

Como ya indicamos en posts(1) anteriores( y 2), existe algún Firewall de Aplicaciones Web con un motor basado en ponderar los valores de los diferentes parámetros (con un funcionamiento parecido a un antispam) que en algunos de estos casos sería completamente efectivo (scoring list) además de porque está basado en tecnología de proxy inverso y en Apache, que como hemos visto sólo se quedaba con el primer valor asignado a un parámetro, reenviando sólo este valor al servidor final.

La presentación completa puede ser descargada aquí así como vista en Slideshare. Su lectura es altamente recomendable.

Fuente:http://www.securitybydefault.com/2009/05/seguridad-web-http-parameter-pollution.html

Lo de los mensajes en el foro libre no sería problema si no se estuviesen preocupando en aumentar el número de mensajes 

[whk presidente]

En el msn?
whk presidente