Widespread vulnerabilities in Libero.it/Infostrada.it web portals

["Rosario Valotta" <rosario.valotta () gmail com>]

<--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-->

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/