Message-ID: <20070329142807.30798.qmail@securityfocus.com>
Date: 29 Mar 2007 14:28:07 -0000
From: rosario.valotta@...il.com
To: bugtraq@...urityfocus.com
Subject: Widespread vulnerabilities in Libero.it/Infostrada.it web portals

<--start-->
Following the advisory of the XSS vulnerability found on Libero.it  (italian ISP) portal, 
and after the "official" response given by the portal owners which stated that in no way user accounts would be at risk, 
several other XSS vulns have been found on Libero.it/Infostrada.it portals (both are from the same provider, different names for historical reasons). 

The current post has the only aim to demonstrate that the previous vulns are not occasional and a hardening in Libero/infostrada portals application security is really urgent 
is required in order to preserve and protect users privacy.


First Vulnerability 
------------------

This PoC widely demonstrate how an attacker can use another XSS vuln + a lack of access control on private Libero.it Community  
pages for organize a phishing attack.

Step 1. On the community pages is possible, for Libero users to create a personal blog; 
this blog can be administred through some admin private pages while the published blog pages are fro public use. 
The page:

http://blog.libero.it/XSS/aux_messaggio.php?
is a private admin page used  to alert for possible errors encoutered during the publication of a blog page. 

The page is XSS vulnerable:
 
http://blog.libero.it/XSS/aux_messaggio.php?msg=<script>alert(document.cookie)</script>


Step 2.  The attacker sends a link to the victim (e.g. inviting him to have a look at a content of his personal community space). 
The link is so made:

http://blog.libero.it/XSS/login.php?rest=1&loginbox=login_riservato&from=http%3A%2F%2Fblog.libero.it%2FXSS%2Faux_messaggio.php%3Fmsg%3D%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E%26nocache%3D1175124994

this links uses a second vuln of the portal that lacks of access control to private pages (a normal user should not can access to an admin page of my blog) to redirect the user to the XSS page.

Step 3. The javascript embedded in the URL:
- reads the cookie of the user
- sends it to the attacker phishing site
- redirect the request to the phishin site

Step 4. The phishing site present the Libero login form, pretending the password typed is not correct.

As the redirect comes from a REAL Libero,it AUTH page the secnario is extremely realistic.....




Second Vunerability
-----------------------

Same XSS problems are present in www.infostrada.it servers, with a
serious XSS vulnerability exploitable in a page used for subscribe to
the service:

<http://www.infostrada.it/pls/portal30/inorder_155.pkg_pronto1055.show_page1?
pref=02&tel=%3Cscript%3Ealert(%22a%22)%3C/script%3E&offer=HI>

The parameter "tel=" for the phone number is unchecked for ANY script.
Wrong, wrong, wrong, wrong. :)




Third vulnerability
----------------------

Problems in Libero are not, though,  limited to JS and XSS scripts for
Phishing purpose.
Infostrada.it servers  are prone
to SQL errors for unchecked values:

<http://www.infostrada.it/pls/portal30/infostrada.offerta.dettaglio?vid=%3E>

Errors reported are prone to information leaking about Environment.
Take these lines for
example:

> PLSQL_GATEWAY=WebDb
> GATEWAY_IVERSION=2
> SERVER_SOFTWARE=Oracle HTTP Server Powered by Apache/1.3.12 (Unix) ApacheJServ/1.1 mod_ssl/2.6.4 OpenSSL/0.9.5a mod_perl/1.24
> GATEWAY_INTERFACE=CGI/1.1
> SERVER_PORT=80

Same SQL problem is present in <155.libero.it> eg:

<http://155.libero.it/pls/portal30/w155.page_offerta.libero?tipo=%3E>


Fourth vulnerability
----------------------
The domain 155.libero.it allows customers of Wind (a fixed and mobile
telecom Italian operator) to manage their own telephone lines.

During the authentication session attention was given only to the
security of the data transfer (HTTPS), but the security of the
application itlself was neglected.

Submitting the login the form, all data are sent to a page which
performs a first validation. This page creates a form with the data
needed for the authentication, without validating the data themselves
though.
Usually, the entered username gets checked by the system, leaving the
password to itself, for what concerns both the length and the contents.

Therefore, it is possibile to inject, through the "password" field
JavaScript code to create the XSS.

A PoC of the URL is as follows:
https://libero.it/pls/portal30/w155.pkg_authentication.Login_url?p_requested_url=/pls/portal30/w155.home&site2pstoretoken=&ssousername=anyrandomname&password="><script>alert('doh!');</script><br
style="


By skillfully exploiting the XSS it is possible to lead an unexperienced
user to believe that the URL is truly secure simply because the HTTPS
protocol is being used.
Besides that, by using the JS method
onLoad="document.directLoginForm.submit();" the XSS (perhaps utilized
just to steal the authentication token) could be totally invisible to
the user.

I'd also like to report that the page is also reachable in its
unencrypted form using plain HTTP protocol.




Contributors:

Rosario Valotta   (first vuln)
rosario.valotta at gmail dot com

Matteo G.P. Flora	(second & third vulns)
Mf at matteoflora dot com	
http://www.matteoflora.com

Matteo Carli		(fourth vuln)
matteo at matteocarli dot com
http://www.matteocarli.com

<--end-->

Powered by blists - more mailing lists