[Full-disclosure] [Security-news] SA-CONTRIB-2012-172 - Zero Point - Cross Site Scripting (XSS)

[security-news]

View online: http://drupal.org/node/1853376

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-172
  * Project: Zero Point [1] (third-party module)
  * Version: 6.x, 7.x
  * Date: 2012-November-28
  * Security risk: Critical [2]
  * Exploitable from: Remote
  * Vulnerability: Cross Site Scripting

 DESCRIPTION  
-

Zero Point is an advanced theme which includes many options, ideal for a wide
range of sites.

The theme does not escape path aliases exposing a Cross site scripting (XSS)
vulnerability in URLs. There are no mitigating factors.

CVE: Requested

 VERSIONS AFFECTED  
---

  * zeropoint 6.x-1.x versions prior to 6.x-1.18
  * zeropoint 7.x-1.x versions prior to 7.x-1.4

Drupal core is not affected. If you do not use the contributed Zero Point [3]
module, there is nothing you need to do.

 SOLUTION  


Install the latest version:

  * If you use the Zero Point theme for Drupal 6.x, upgrade to zeropoint
6.x-1.18 [4]
  * If you use the Zero Point theme for Drupal 7.x, upgrade to zeropoint
7.x-1.4 [5]

Also see the Zero Point [6] project page.

 REPORTED BY  
-

  * samatha [7]

 FIXED BY  


  * Florian Radut [8] the module maintainer
  * Christian López Espínola [9]

 COORDINATED BY  
--

  * Klaus Purer [10] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [11].

Learn more about the Drupal Security team and their policies [12], writing
secure code for Drupal [13], and securing your site [14].


[1] http://drupal.org/project/zeropoint
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/project/zeropoint
[4] http://drupal.org/node/1853358
[5] http://drupal.org/node/1853350
[6] http://drupal.org/project/zeropoint
[7] http://drupal.org/user/534190
[8] http://drupal.org/user/35316
[9] http://drupal.org/user/959536
[10] http://drupal.org/user/262198
[11] http://drupal.org/contact
[12] http://drupal.org/security-team
[13] http://drupal.org/writing-secure-code
[14] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [Security-news] SA-CONTRIB-2012-168 - Services - Information Disclosure

[security-news]

View online: http://drupal.org/node/1853200

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-168
  * Project: Services [1] (third-party module)
  * Version: 6.x, 7.x
  * Date: 2012-11-28
  * Security risk: Moderately critical [2]
  * Exploitable from: Remote
  * Vulnerability: Information Disclosure

 DESCRIPTION  
-

This module enables you to access content from a remote client.
The module doesn't sufficiently adhere to standard Drupal permissions and
exposes users emails via the user index method.

This vulnerability is mitigated by the fact that an attacker most know the
path to the user resource and must be able to access user profiles (have
'access user profiles' permission).

CVE: Requested

 VERSIONS AFFECTED  
---

  * Services 6.x-3.x versions prior to 6.x-3.3.
  * Services 7.x-3.x versions prior to 7.x-3.3.

Drupal core is not affected. If you do not use the contributed Services [3]
module, there is nothing you need to do.

 SOLUTION  


Install the latest version:

  * If you use the Services module for Drupal 6.x, upgrade to Services 6.x-3.3
[4]
  * If you use the Services module for Drupal 7.x, upgrade to Services 7.x-3.3
[5]

Also see the Services [6] project page.

 REPORTED BY  
-

  * Fox (hefox) [7] of the Drupal Security Team

 FIXED BY  


  * Fox (hefox) [8] of the Drupal Security Team
  * Kyle Browning [9] the module maintainer

 COORDINATED BY  
--

  * Fox (hefox) [10] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [11].

Learn more about the Drupal Security team and their policies [12], writing
secure code for Drupal [13], and securing your site [14].


[1] http://drupal.org/project/services
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/project/services
[4] http://drupal.org/node/1842026
[5] http://drupal.org/node/1842022
[6] http://drupal.org/project/services
[7] http://drupal.org/user/426416
[8] http://drupal.org/user/426416
[9] http://drupal.org/user/211387
[10] http://drupal.org/user/426416
[11] http://drupal.org/contact
[12] http://drupal.org/security-team
[13] http://drupal.org/writing-secure-code
[14] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news

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

[Full-disclosure] [Security-news] SA-CONTRIB-2012-170 - MultiLink - Access Bypass

[security-news]

View online: http://drupal.org/node/1853244

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-170
  * Project: Multi-Language Link and Redirect (MultiLink) [1] (third-party
module)
  * Version: 6.x, 7.x
  * Date: 2012-November-28
  * Security risk: Moderately critical [2]
  * Exploitable from: Remote
  * Vulnerability: Access bypass

 DESCRIPTION  
-

MultiLink allows you to generate in-content links to a suitable node or node
translation based on the visitor's language preferences. It allows the Node
Title of the target node to be shown as the visible text and title attribute
for the generated link.

Prior to versions 6.x-2.7 and 7.x-2.7 the module doesn't check the the
current user has access to a node referenced by the generated link, so that
node title (only) may be disclosed to a user who would otherwise have no
access to that node.

This vulnerability is mitigated by the fact that an attacker must have a role
with the permission to edit text using an Input Format for which the
MultiLink Filter has been enabled.

CVE: Requested

 VERSIONS AFFECTED  
---

  * MulitLink 6.x-2.x versions prior to 6.x-2.7 [3].
  * MulitLink 7.x-2.x versions prior to 7.x-2.7 [4].

Drupal core is not affected. If you do not use the contributed Multi-Language
Link and Redirect (MultiLink) [5] module, there is nothing you need to do.

 SOLUTION  


Install the latest version - see the project page
http://drupal.org/project/multilink [6] for downloads.

Also see the Multi-Language Link and Redirect (MultiLink) [7] project page.

 REPORTED BY  
-

  * Andy Inman [8] the module maintainer

 FIXED BY  


  * Andy Inman [9] the module maintainer

 COORDINATED BY  
--

  * Stéphane Corlosquet [10] of the Drupal Security Team
  * Greg Knaddison [11] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [12].

Learn more about the Drupal Security team and their policies [13], writing
secure code for Drupal [14], and securing your site [15].


[1] http://drupal.org/project/multilink
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/node/1289292
[4] http://drupal.org/node/1289294
[5] http://drupal.org/project/multilink
[6] http://drupal.org/project/multilink
[7] http://drupal.org/project/multilink
[8] http://drupal.org/user/216383
[9] http://drupal.org/user/216383
[10] http://drupal.org/user/52142
[11] http://drupal.org/user/36762
[12] http://drupal.org/contact
[13] http://drupal.org/security-team
[14] http://drupal.org/writing-secure-code
[15] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [Security-news] SA-CONTRIB-2012-171 - Webmail Plus - SQL injection - (unsupported)

[security-news]

View online: http://drupal.org/node/1853268

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-171
  * Project: Webmail Plus [1] (third-party module)
  * Version: 6.x
  * Date: 2012-November-28
  * Security risk: Critical [2]
  * Exploitable from: Remote
  * Vulnerability: SQL Injection

 DESCRIPTION  
-

The Webmail plus module is a full-featured email client for Drupal. It's
designed to provide email for any or all members of a Drupal site.

The module doesn't sufficiently sanitize user input as it is used in a
database query.

CVE: Requested

 VERSIONS AFFECTED  
---

  * All Webmail Plus module versions.

Drupal core is not affected. If you do not use the contributed Webmail Plus
[3] module, there is nothing you need to do.

 SOLUTION  


Uninstall the module:

  * If you use the Webmail Plus module you should disable the module.

Also see the Webmail Plus [4] project page.

 REPORTED BY  
-

  * Fox [5] of the Drupal Security Team

 COORDINATED BY  
--

  * Gerhard Killesreiter [6] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [7].

Learn more about the Drupal Security team and their policies [8], writing
secure code for Drupal [9], and securing your site [10].


[1] http://drupal.org/project/webmail_plus
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/project/webmail_plus
[4] http://drupal.org/project/webmail_plus
[5] http://drupal.org/user/426464
[6] http://drupal.org/user/83
[7] http://drupal.org/contact
[8] http://drupal.org/security-team
[9] http://drupal.org/writing-secure-code
[10] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news

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

[Full-disclosure] [Security-news] SA-CONTRIB-2012-169 - Email Field - Cross Site Scripting and Access bypass

[security-news]

View online: http://drupal.org/node/1853214

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-169
  * Project: Email Field [1] (third-party module)
  * Version: 6.x
  * Date: 2012-11-28
  * Security risk: Less critical [2]
  * Exploitable from: Remote
  * Vulnerability: Cross Site Scripting, Access bypass

 DESCRIPTION  
-

The email module provides a field type (CCK / FieldAPI) for storing email
addresses and a formatter to output the email address as a link to a contact
form. The contact form formatter allows a site visitor to email the stored
address without letting them see what that e-mail address
is.
 Access bypass

The module didn't sufficiently check access for the contact form page,
allowing a site visitor to email the stored address on the entity without
having access to the field itself.
This vulnerability is mitigated by needing to to use a field permission
module (other than CCK's Content Permissions) with those email fields and
need to have the field contact field formatter configured for either full or
teaser display modes.

CVE: Requested

 Cross Site Scripting

Furthermore the mailto link wasn't sanitized when output to the screen. This
vulnerability is mitigated by the fact that Drupal's form validation for
emails prevents malicious emails and would need to be bypassed to exploit
this vulnerability, e.g. by importing data from external sources and not
doing validation.

CVE: Requested

 VERSIONS AFFECTED  
---

  * Email Field 6.x-1.x versions prior to 6.x-1.3.

Drupal core is not affected. If you do not use the contributed Email Field
[3] module, there is nothing you need to do.

 SOLUTION  


Install the latest version:

  * If you use the Email Field module for Drupal 6.x, upgrade to Email 6.x-1.4
[4]

Also see the Email Field [5] project page.

 REPORTED BY  
-

  * Fox (hefox) [6]

 FIXED BY  


  * Matthias Hutterer [7] the module maintainer

 COORDINATED BY  
--

  * Fox (hefox) [8] of the Drupal Security Team
  * Greg Knaddison [9] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [10].

Learn more about the Drupal Security team and their policies [11], writing
secure code for Drupal [12], and securing your site [13].


[1] http://drupal.org/project/email
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/project/email
[4] http://drupal.org/node/1852612
[5] http://drupal.org/project/email
[6] http://drupal.org/user/426416
[7] http://drupal.org/user/59747
[8] http://drupal.org/user/426416
[9] http://drupal.org/user/36762
[10] http://drupal.org/contact
[11] http://drupal.org/security-team
[12] http://drupal.org/writing-secure-code
[13] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news

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

[Full-disclosure] [Security-news] SA-CONTRIB-2012-167 - Mixpanel - Cross site scripting (XSS)

[security-news]

View online: http://drupal.org/node/1853198

  * Advisory ID: DRUPAL-SA-CONTRIB-2012-167
  * Project: Mixpanel [1] (third-party module)
  * Version: 6.x
  * Date: 2012-November-28
  * Security risk: Moderately critical [2]
  * Exploitable from: Remote
  * Vulnerability: Cross Site Scripting

 DESCRIPTION  
-

This module provides integration with the Mixpanel real-time analytics
service.

The module doesn't sufficiently escape the Mixpanel token when adding the
tracking Javascript to the page.

This vulnerability is mitigated by the fact that an attacker must have a role
with the permission "access administration pages".

CVE: Requested

 VERSIONS AFFECTED  
---

  * Mixpanel 6.x-1.x versions prior to 6.x-1.1.

Drupal core is not affected. If you do not use the contributed Mixpanel [3]
module, there is nothing you need to do.

 SOLUTION  


Install the latest version:

  * If you use the Mixpanel module for Drupal 6.x, upgrade to Mixpanel 6.x-1.1
[4]

Also see the Mixpanel [5] project page.

 REPORTED BY  
-

  * David Snopek [6]

 FIXED BY  


  * wundo [7] the module maintainer
  * David Snopek [8]

 COORDINATED BY  
--

  * Greg Knaddison [9] of the Drupal Security Team

 CONTACT AND MORE INFORMATION  


The Drupal security team can be reached at security at drupal.org or via the
contact form at http://drupal.org/contact [10].

Learn more about the Drupal Security team and their policies [11], writing
secure code for Drupal [12], and securing your site [13].


[1] http://drupal.org/project/mixpanel
[2] http://drupal.org/security-team/risk-levels
[3] http://drupal.org/project/mixpanel
[4] http://drupal.org/node/1852098
[5] http://drupal.org/project/mixpanel
[6] http://drupal.org/user/266527
[7] http://drupal.org/user/25523
[8] http://drupal.org/user/266527
[9] http://drupal.org/user/36762
[10] http://drupal.org/contact
[11] http://drupal.org/security-team
[12] http://drupal.org/writing-secure-code
[13] http://drupal.org/security/secure-configuration

___
Security-news mailing list
security-n...@drupal.org
Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news

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

Re: [Full-disclosure] Apple WGT Dictionnaire 1.3 - Script Code Inject Vulnerability

[Thor (Hammer of God)]

On Nov 27, 2012, at 5:52 PM, Vulnerability Lab  
wrote:

> Proof of Concept:
> =
> The software validation vulnerability can be exploited by local attackers 
> with required user interaction and privileged local system account.
> For demonstration or reproduce ...
> 
> PoC: Script Code Inject
> "VL Tester
> “http://vuln-lab.com>>
> "
> "alert(document.cookie)http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OT Google raises sploit bounties

[Michal Zalewski]

> I would be interested what bounties they would pay
> for operation Аврора or for a botnet of say 1M host.

Reward amounts are public; for example, here are the rules for the web
app program:

http://www.google.com/about/appsecurity/reward-program/

Neither malware on user machines nor attacking employees is within
scope, though: the program is mostly about recognizing original
research into potential design and implementation flaws in our code.

We occasionally decide to extend rewards of some sort to people who
report very interesting or sensitive issues that fall outside the
scope of the existing programs, but we don't offer Microsoft-style
bounties for identifying malware authors, etc.

/mz

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

Re: [Full-disclosure] OT Google raises sploit bounties

[Dan Kaminsky]

On Wed, Nov 28, 2012 at 6:23 AM, Georgi Guninski wrote:

> On Tue, Nov 27, 2012 at 10:32:16PM -0800, Dan Kaminsky wrote:
> > > One Google employee responds to another Google employee about Google
> > > stuff...
> > >
> >
> > It's almost like security people at Google have been security people for
> a
> > very long time, and are given a redonkulously long leash ;)
> >
> > --Dan
>
> I would be interested what bounties they would pay
> for operation Аврора or for a botnet of say 1M host.
>
> microsoft are paying ridiculously low for botnets :)
>
>
>
Attackers get a higher ROI than defenders.  Same as it ever was.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OT Google raises sploit bounties

[Georgi Guninski]

On Tue, Nov 27, 2012 at 10:32:16PM -0800, Dan Kaminsky wrote:
> > One Google employee responds to another Google employee about Google
> > stuff...
> >
> 
> It's almost like security people at Google have been security people for a
> very long time, and are given a redonkulously long leash ;)
> 
> --Dan

I would be interested what bounties they would pay
for operation Аврора or for a botnet of say 1M host.

microsoft are paying ridiculously low for botnets :)


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

Re: [Full-disclosure] The email that hacks you

[Bogdan Calin]

Thanks aditya,

The code is not published on the blog post but it's visible in the video.
It's very simple to reproduce this problem.

On 11/28/2012 1:53 PM, aditya wrote:
> I totally agree with Christian, it is as insane as passing username and 
> passwords using GET
> requests. But congrats Bogdan for the bringing to us a nice hack.
> 
> Have u shared the code as well Bogdan?
> 
> On Wed, Nov 28, 2012 at 5:07 PM, Christian Sciberras  >
> wrote:
> 
> From an architectural perspective, "auto logins" or whatever they're 
> called should work through
> a random string, just as most providers already do.
> There is absolutely no reason to pass the username/password from a URL, 
> especially when in plain
> text as in these cases.
> Since there is no loss of features (there are safer, saner, sensible 
> alternatives), I think this
> is better considered a bug, since it is never actually needed in the 
> first place.
> 
> Also, with the random token system, I think it is best to still require 
> the user/pass when the
> URL the user is directed to is going to do something such as 
> modifying/updating stuff.
> 
> 
> Chris.
> 
> 
> 
> On Wed, Nov 28, 2012 at 12:15 PM, Bogdan Calin  > wrote:
> 
> Yes, I agree with you.
> 
> However, my opinion it that it should be fixed once and for all in 
> iOS/Webkit (and the other
> browsers) by disabling resources loaded with credentials.
> 
> At some point, as a protection for phishing, URLs with the format
> scheme://username:password@hostname/ were disabled.
> When you enter in the browser bar something like that it doesn't work 
> in most browsers.
> 
> I was surprised to see that doing something like  src='scheme://username:password@hostname/path'> works in Chrome and 
> Firefox but if you enter the
> same URL in the browser bar it doesn't work. This doesn't work in 
> Internet Explorer, which
> is the
> right behavior in my opinion.
> 
> I don't see any good reason why something like this should work. 
> Closing this in browsers
> will solve
> this problem once and for all.
> 
> On 11/28/2012 1:00 PM, Guifre wrote:
> > Hello,
> >
> > "I can also confirm that this attack works on iPhone, iPad and Mac's
> > default mail client."
> >
> > Of course, it works anywhere where arbitrary client-side code can be
> > executed... IMAHO, the issue here is not your iphone loading images,
> > there are millions of attack vectors to trigger this attack... The
> > problem is the CSRF weaknesses of your router admin panel that 
> should
> > be fixed by synchronizing a secret token or by using any other well
> > known mitigation strategy against these attacks.
> >
> > Best Regards,
> > Guifre.
> >
> 
> --
> Bogdan Calin - bogdan [at] acunetix.com 
> CTO
> Acunetix Ltd. - http://www.acunetix.com
> Acunetix Web Security Blog - http://www.acunetix.com/blog
> Follow us on Twitter - http://www.twitter.com/acunetix
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> 
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> 
> 
> 
> -- 
> Regards
> Aditya Balapure
> 
> 

-- 
Bogdan Calin - bogdan [at] acunetix.com
CTO
Acunetix Ltd. - http://www.acunetix.com
Acunetix Web Security Blog - http://www.acunetix.com/blog
Follow us on Twitter - http://www.twitter.com/acunetix

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

Re: [Full-disclosure] The email that hacks you

[aditya]

Please if you could share the code, I would like to test it for my router
as well.

Thanks

On Wed, Nov 28, 2012 at 6:02 PM, Bogdan Calin  wrote:

> Thanks aditya,
>
> The code is not published on the blog post but it's visible in the video.
> It's very simple to reproduce this problem.
>
> On 11/28/2012 1:53 PM, aditya wrote:
> > I totally agree with Christian, it is as insane as passing username and
> passwords using GET
> > requests. But congrats Bogdan for the bringing to us a nice hack.
> >
> > Have u shared the code as well Bogdan?
> >
> > On Wed, Nov 28, 2012 at 5:07 PM, Christian Sciberras 
> >  uuf6...@gmail.com>>
> > wrote:
> >
> > From an architectural perspective, "auto logins" or whatever they're
> called should work through
> > a random string, just as most providers already do.
> > There is absolutely no reason to pass the username/password from a
> URL, especially when in plain
> > text as in these cases.
> > Since there is no loss of features (there are safer, saner, sensible
> alternatives), I think this
> > is better considered a bug, since it is never actually needed in the
> first place.
> >
> > Also, with the random token system, I think it is best to still
> require the user/pass when the
> > URL the user is directed to is going to do something such as
> modifying/updating stuff.
> >
> >
> > Chris.
> >
> >
> >
> > On Wed, Nov 28, 2012 at 12:15 PM, Bogdan Calin  > > wrote:
> >
> > Yes, I agree with you.
> >
> > However, my opinion it that it should be fixed once and for all
> in iOS/Webkit (and the other
> > browsers) by disabling resources loaded with credentials.
> >
> > At some point, as a protection for phishing, URLs with the format
> > scheme://username:password@hostname/ were disabled.
> > When you enter in the browser bar something like that it doesn't
> work in most browsers.
> >
> > I was surprised to see that doing something like  > src='scheme://username:password@hostname/path'> works in Chrome
> and Firefox but if you enter the
> > same URL in the browser bar it doesn't work. This doesn't work
> in Internet Explorer, which
> > is the
> > right behavior in my opinion.
> >
> > I don't see any good reason why something like this should work.
> Closing this in browsers
> > will solve
> > this problem once and for all.
> >
> > On 11/28/2012 1:00 PM, Guifre wrote:
> > > Hello,
> > >
> > > "I can also confirm that this attack works on iPhone, iPad and
> Mac's
> > > default mail client."
> > >
> > > Of course, it works anywhere where arbitrary client-side code
> can be
> > > executed... IMAHO, the issue here is not your iphone loading
> images,
> > > there are millions of attack vectors to trigger this attack...
> The
> > > problem is the CSRF weaknesses of your router admin panel that
> should
> > > be fixed by synchronizing a secret token or by using any other
> well
> > > known mitigation strategy against these attacks.
> > >
> > > Best Regards,
> > > Guifre.
> > >
> >
> > --
> > Bogdan Calin - bogdan [at] acunetix.com 
> > CTO
> > Acunetix Ltd. - http://www.acunetix.com
> > Acunetix Web Security Blog - http://www.acunetix.com/blog
> > Follow us on Twitter - http://www.twitter.com/acunetix
> >
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
> >
> >
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
> >
> >
> >
> > --
> > Regards
> > Aditya Balapure
> >
> >
>
> --
> Bogdan Calin - bogdan [at] acunetix.com
> CTO
> Acunetix Ltd. - http://www.acunetix.com
> Acunetix Web Security Blog - http://www.acunetix.com/blog
> Follow us on Twitter - http://www.twitter.com/acunetix
>



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

[Full-disclosure] Hacking Competition PHDAYS CTF Quals 2012 Starts

[PHD]

The qualifying stage of the PHDays CTF international information security 
contest starts in December.

The teams will try their hands at security assessment, vulnerabilities 
detection and exploitation as well as fulfilling reverse engineering tasks. The 
conditions of PHDays CTF Quals, as opposed to many other competitions of the 
kind, are brought as close to real life as possible: all the vulnerabilities 
are not fictional, but indeed occur on present-day information systems.

Winners: The winners of the contest will be those who gain the highest score 
earlier than others. On the basis of the PHDays CTF Quals results, the 
strongest teams will be invited to participate in PHDays III CTF.

Registration for Quals: From the 28th of November till the 14th of December, 
2012.
Time when Quals will be held: From 10 a.m. of the 15th of December till 10 a.m. 
of the 17th of December, 2012 (Moscow time).

The main contest will take place on the 22nd and 23rd of May, 2013 in Moscow 
during the third international information security forum Positive Hack 
Days. Big money prize is waiting for the winners!

Details
You can learn more about PHDays CTF Quals and register by following the link 
http://quals.phdays.com.

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

Re: [Full-disclosure] The email that hacks you

[aditya]

I totally agree with Christian, it is as insane as passing username and
passwords using GET requests. But congrats Bogdan for the bringing to us a
nice hack.

Have u shared the code as well Bogdan?

On Wed, Nov 28, 2012 at 5:07 PM, Christian Sciberras wrote:

> From an architectural perspective, "auto logins" or whatever they're
> called should work through a random string, just as most providers already
> do.
> There is absolutely no reason to pass the username/password from a
> URL, especially when in plain text as in these cases.
> Since there is no loss of features (there are safer, saner, sensible
> alternatives), I think this is better considered a bug, since it is never
> actually needed in the first place.
>
> Also, with the random token system, I think it is best to still require
> the user/pass when the URL the user is directed to is going to do something
> such as modifying/updating stuff.
>
>
> Chris.
>
>
>
> On Wed, Nov 28, 2012 at 12:15 PM, Bogdan Calin wrote:
>
>> Yes, I agree with you.
>>
>> However, my opinion it that it should be fixed once and for all in
>> iOS/Webkit (and the other
>> browsers) by disabling resources loaded with credentials.
>>
>> At some point, as a protection for phishing, URLs with the format
>> scheme://username:password@hostname/ were disabled.
>> When you enter in the browser bar something like that it doesn't work in
>> most browsers.
>>
>> I was surprised to see that doing something like > src='scheme://username:password@hostname/path'> works in Chrome and
>> Firefox but if you enter the
>> same URL in the browser bar it doesn't work. This doesn't work in
>> Internet Explorer, which is the
>> right behavior in my opinion.
>>
>> I don't see any good reason why something like this should work. Closing
>> this in browsers will solve
>> this problem once and for all.
>>
>> On 11/28/2012 1:00 PM, Guifre wrote:
>> > Hello,
>> >
>> > "I can also confirm that this attack works on iPhone, iPad and Mac's
>> > default mail client."
>> >
>> > Of course, it works anywhere where arbitrary client-side code can be
>> > executed... IMAHO, the issue here is not your iphone loading images,
>> > there are millions of attack vectors to trigger this attack... The
>> > problem is the CSRF weaknesses of your router admin panel that should
>> > be fixed by synchronizing a secret token or by using any other well
>> > known mitigation strategy against these attacks.
>> >
>> > Best Regards,
>> > Guifre.
>> >
>>
>> --
>> Bogdan Calin - bogdan [at] acunetix.com
>> CTO
>> Acunetix Ltd. - http://www.acunetix.com
>> Acunetix Web Security Blog - http://www.acunetix.com/blog
>> Follow us on Twitter - http://www.twitter.com/acunetix
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



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

Re: [Full-disclosure] The email that hacks you

[Guifre]

Hello,

"I can also confirm that this attack works on iPhone, iPad and Mac's
default mail client."

Of course, it works anywhere where arbitrary client-side code can be
executed... IMAHO, the issue here is not your iphone loading images,
there are millions of attack vectors to trigger this attack... The
problem is the CSRF weaknesses of your router admin panel that should
be fixed by synchronizing a secret token or by using any other well
known mitigation strategy against these attacks.

Best Regards,
Guifre.

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

Re: [Full-disclosure] Remote Command Execution on Cisco WAG120N

[Gary]

On Mon, Nov 26, 2012 at 6:11 AM, Benji wrote:
> Command execution through Dynamic DNS setup is quite clearly not expected 
> functionality.

Agreed but that's still not "remote command execution" per my explanation below.


 On Tue, Nov 27, 2012 at 9:33 AM, andfarm wrote:
> Through cross-site request forgery. ... (If the form is accessible via GET, 
> the attack
> becomes even easier, as an attacker can cause the form to be "submitted" 
> without the
> involvement of a script -- by using an  tag, for example.)
>
> If the user already has a valid session on the router, the request will 
> typically go through,
> unless the router firmware supports some form of XSRF protection. (Most do 
> not.)

If so, where's the HTML and CGI source from a WAG120N admin UI that
supports this theory? Here's the original post with new comments.

> 1º Authenticate and browse to /setup.cgi?next_file=Setup_DDNS.htm

Yes, by its name it looks like it could be a dynamic DNS setup page.
The author has access to this device to confirm or deny that along
with my other statements below. But it doesn't seem to matter what
this page's intended functionality is per the "exploit" outlined below
since it's just one of possibly many unvalidated submission forms.

> 2º All the fields you see are vulnerables to command execution as root, so 
> inject
> "qwe.com;cat /etc/passwd> /www/Routercfg.cfg;" into the Hostname field

So we've abused a submission form that doesn't practice proper form
validation. "The goal of web form validation is to ensure that the
user provided necessary and properly formatted information needed to
successfully complete an operation."[1] Apparently, the form is also
not checking the hostname field for anything that complies with ASCII
standard or Unicode internationalized domain names. In addition, the
web server process apparently has privileges enough to write to the
OS. So it is probably running as root or the file perms are borked in
relation to what privileges the service's user /ought/ to have.

> 3º Everything is done, just download the file /Routercfg.cfg (Authenticated 
> is requiered)
> root::0:0:root:/:/bin/sh
> nobody::99:99:Nobody:/:/sbin/sh

In order to download the file that's been modified, we still have to
authenticate to the device. And then what do we get in return? An
empty password file that I can't really do anything with. For one, we
presumably already know the root or otherwise privileged user's
password that's not even exposed in this file. Also, passwords have
been stored in shadow files since about System V Release 3.2 in 1998
and BSD 4.3 in 1990 so we might want to look for something more
lucrative. Can we use the same commands to copy a shadow file in to
Routercfg.cfg? If so, what do we gain? A password that we already
know? How is that a danger to the end user? They might be able to
issue a "reboot" command. Again, where's the danger of exploit by
remote unauthenticated users or scripts in the wild? Yes, it's stupid.
Yes, it's not best practice.

We still have an authentication wall and no HTML or CGI source code
supporting the veracity of the author's claims. We don't really need
those things, however, because even then we're still looking at an
"exploit" that requires the end user knowing the the admin's user name
and password. So it may be worth reporting to the vendor as bad
engineering for not using best OS and application security practices.
But we don't see bypass or escalation of privileges and the author
didn't list what user names were used to authenticate. Again, where's
the security risk?

Throughout my day I authenticate to at least a dozen or more devices
that I have read/write access to. Should I report those
vulnerabilities to Cisco, Oracle, Canonical, Apple, Microsoft, et al?
Or should I just post them to a security discussion list as some great
revelation? There are probably several dozen of these SOHO grade
devices with similarly poor architecture  -- hence the intention of my
original reply. Report it to the vendor? Yes. Post it on a public list
or open a CVE? Probably not. At the very least it's sloppy science and
too sparse on relevant details. Alternately, report it to the list for
what it is -- improper form validation instead of "remote command
execution" which suggests that anyone scanning for public IPs can find
one of these devices and issue commands to it without authenticating
whether it's by web form, SSH, etc.

-Gary

1. 
http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-and-tutorials
q.v. http://en.wikipedia.org/wiki/Arbitrary_code_execution

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

[Full-disclosure] Paypal Bug Bounty #21 - Persistent Encoding Vulnerability

[Vulnerability Lab]

Title:
==
Paypal Bug Bounty #21 - Persistent Encoding Vulnerability


Date:
=
2012-11-25


References:
===
http://www.vulnerability-lab.com/get_content.php?id=684


VL-ID:
=
684


Common Vulnerability Scoring System:

3


Introduction:
=
PayPal is a global e-commerce business allowing payments and money transfers to 
be made through the Internet. Online money 
transfers serve as electronic alternatives to paying with traditional paper 
methods, such as checks and money orders. Originally, 
a PayPal account could be funded with an electronic debit from a bank account 
or by a credit card at the payer s choice. But some 
time in 2010 or early 2011, PayPal began to require a verified bank account 
after the account holder exceeded a predetermined 
spending limit. After that point, PayPal will attempt to take funds for a 
purchase from funding sources according to a specified 
funding hierarchy. If you set one of the funding sources as Primary, it will 
default to that, within that level of the hierarchy 
(for example, if your credit card ending in 4567 is set as the Primary over 
1234, it will still attempt to pay money out of your 
PayPal balance, before it attempts to charge your credit card). The funding 
hierarchy is a balance in the PayPal account; a 
PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master 
Card or Bill Me Later (if selected as primary 
funding source) (It can bypass the Balance); a verified bank account; other 
funding sources, such as non-PayPal credit cards.
The recipient of a PayPal transfer can either request a check from PayPal, 
establish their own PayPal deposit account or request 
a transfer to their bank account.

PayPal is an acquirer, performing payment processing for online vendors, 
auction sites, and other commercial users, for which it 
charges a fee. It may also charge a fee for receiving money, proportional to 
the amount received. The fees depend on the currency 
used, the payment option used, the country of the sender, the country of the 
recipient, the amount sent and the recipient s account 
type. In addition, eBay purchases made by credit card through PayPal may incur 
extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its 
corporate headquarters are in San Jose, California, United 
States at eBay s North First Street satellite office campus. The company also 
has significant operations in Omaha, Nebraska, Scottsdale, 
Arizona, and Austin, Texas, in the United States, Chennai, Dublin, Kleinmachnow 
(near Berlin) and Tel Aviv. As of July 2007, across 
Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), 
China s bankcard association, to allow Chinese consumers 
to use PayPal to shop online.PayPal is planning to expand its workforce in Asia 
to 2,000 by the end of the year 2010.
Between December 4ñ9, 2010, PayPal services were attacked in a series of 
denial-of-service attacks organized by Anonymous in retaliation 
for PayPal s decision to freeze the account of WikiLeaks citing terms of use 
violations over the publication of leaked US diplomatic cables.

(Copy of the Homepage: www.paypal.com) [http://en.wikipedia.org/wiki/PayPal]


Abstract:
=
The Vulnerability Laboratory Research Team discovered a Web Vulnerability in 
the official Paypal Plaza website application.


Report-Timeline:

2012-08-14: Researcher Notification & Coordination
2012-08-14: Vendor Notification
2012-08-16: Vendor Response/Feedback
2012-10-29: Vendor Fix/Patch by PayPal Inc
2012-11-25: Public or Non-Public Disclosure


Status:

Published


Exploitation-Technique:
===
Remote


Severity:
=
Medium


Details:

A persistent input validation vulnerability is detected in the official Paypal 
Plaza website application (Customers).
The bug allows an attacker (remote) to implement/inject malicious script code 
on the application side (persistent) of the paypal plaza 
egreetings web service. The vulnerability is located in the (Step 5 Preview) 
eGreeting module notification with the bound vulnerable 
your name and  recipient’s name parameters. The vulnerability can be exploited 
by remote attackers with low or medium required user inter 
action and without privileged Customer/Pro/Seller account. Successful 
exploitation of the vulnerability can lead to session hijacking (customers), 
account steal via persistent web attacks, persistent phishing or stable 
(persistent) mail notification context manipulation.

Vulnerable Type(s):
  [+] eGreetings Service


Vulnerable Site(s):
  [+] Paypal Plaza (paypal-plaza.com)


Vulnerable Module(s):
  [+] Step 5 Preview for eGreeting


Vulnerable Parameter(s):
 

[Full-disclosure] Paypal Bug Bounty #27 - Community Web Vulnerability

[Vulnerability Lab]

Title:
==
Paypal Bug Bounty #27 - Community Web Vulnerability


Date:
=
2012-11-24


References:
===
http://www.vulnerability-lab.com/get_content.php?id=704


VL-ID:
=
704


Common Vulnerability Scoring System:

2.1


Introduction:
=
PayPal is a global e-commerce business allowing payments and money transfers to 
be made through the Internet. Online money 
transfers serve as electronic alternatives to paying with traditional paper 
methods, such as checks and money orders. Originally, 
a PayPal account could be funded with an electronic debit from a bank account 
or by a credit card at the payer s choice. But some 
time in 2010 or early 2011, PayPal began to require a verified bank account 
after the account holder exceeded a predetermined 
spending limit. After that point, PayPal will attempt to take funds for a 
purchase from funding sources according to a specified 
funding hierarchy. If you set one of the funding sources as Primary, it will 
default to that, within that level of the hierarchy 
(for example, if your credit card ending in 4567 is set as the Primary over 
1234, it will still attempt to pay money out of your 
PayPal balance, before it attempts to charge your credit card). The funding 
hierarchy is a balance in the PayPal account; a 
PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master 
Card or Bill Me Later (if selected as primary 
funding source) (It can bypass the Balance); a verified bank account; other 
funding sources, such as non-PayPal credit cards.
The recipient of a PayPal transfer can either request a check from PayPal, 
establish their own PayPal deposit account or request 
a transfer to their bank account.

PayPal is an acquirer, performing payment processing for online vendors, 
auction sites, and other commercial users, for which it 
charges a fee. It may also charge a fee for receiving money, proportional to 
the amount received. The fees depend on the currency 
used, the payment option used, the country of the sender, the country of the 
recipient, the amount sent and the recipient s account 
type. In addition, eBay purchases made by credit card through PayPal may incur 
extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its 
corporate headquarters are in San Jose, California, United 
States at eBay s North First Street satellite office campus. The company also 
has significant operations in Omaha, Nebraska, Scottsdale, 
Arizona, and Austin, Texas, in the United States, Chennai, Dublin, Kleinmachnow 
(near Berlin) and Tel Aviv. As of July 2007, across 
Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), 
China s bankcard association, to allow Chinese consumers 
to use PayPal to shop online.PayPal is planning to expand its workforce in Asia 
to 2,000 by the end of the year 2010.
Between December 4ñ9, 2010, PayPal services were attacked in a series of 
denial-of-service attacks organized by Anonymous in retaliation 
for PayPal s decision to freeze the account of WikiLeaks citing terms of use 
violations over the publication of leaked US diplomatic cables.

(Copy of the Homepage: www.paypal.com) [http://en.wikipedia.org/wiki/PayPal]


Abstract:
=
The Vulnerability Laboratory Research Team discovered a a client side Web 
Vulnerability and a stable error in the official Paypal Community Forum Portal.


Report-Timeline:

2012-09-17: Researcher Notification & Coordination
2012-09-18: Vendor Notification
2012-10-19: Vendor Response/Feedback
2012-10-29: Vendor Fix/Patch
2012-11-26: Public Disclosure


Status:

Published


Exploitation-Technique:
===
Remote


Severity:
=
Medium


Details:

A client side input validation vulnerability and a stable persistent error are 
detected in the official PayPal Community website.
The vulnerability is located in the add tags function and the bound replace 
module.attackers can produce posts with permanent 
errors bye replacing a standard value string with   > `` < ../ and a string 
code or path to an existing url. Normally it should not be 
possible to inject script code as foldername and replace it with more script 
code to crash with an unhandled exception. Attackers 
can inject on client side when the exception-handling is bypassed via another 
validation vulnerability.


Vulnerable Module(s):
[+] add tags

Vulnerable Parameter(s):
[+] rc


Proof of Concept:
=
The vulnerability can be exploited by remote attackers with medium or high 
required user inter action.
For demonstration or reproduce ...


POC:
https://www.paypal-community.com/t5/forums/tagreplacepage/message-scope/core-node/board-id/US-Hot-Topics/user-scope/single

[Full-disclosure] Paypal Bug Bounty #11 - Redirection Web Vulnerability

[Vulnerability Lab]

Title:
==
Paypal Bug Bounty #11 - Redirection Web Vulnerability


Date:
=
2012-11-22


References:
===
http://www.vulnerability-lab.com/get_content.php?id=648


VL-ID:
=
648


Common Vulnerability Scoring System:

2


Introduction:
=
PayPal is a global e-commerce business allowing payments and money transfers to 
be made through the Internet. Online money 
transfers serve as electronic alternatives to paying with traditional paper 
methods, such as checks and money orders. Originally, 
a PayPal account could be funded with an electronic debit from a bank account 
or by a credit card at the payer s choice. But some 
time in 2010 or early 2011, PayPal began to require a verified bank account 
after the account holder exceeded a predetermined 
spending limit. After that point, PayPal will attempt to take funds for a 
purchase from funding sources according to a specified 
funding hierarchy. If you set one of the funding sources as Primary, it will 
default to that, within that level of the hierarchy 
(for example, if your credit card ending in 4567 is set as the Primary over 
1234, it will still attempt to pay money out of your 
PayPal balance, before it attempts to charge your credit card). The funding 
hierarchy is a balance in the PayPal account; a 
PayPal credit account, PayPal Extras, PayPal SmartConnect, PayPal Extras Master 
Card or Bill Me Later (if selected as primary 
funding source) (It can bypass the Balance); a verified bank account; other 
funding sources, such as non-PayPal credit cards.
The recipient of a PayPal transfer can either request a check from PayPal, 
establish their own PayPal deposit account or request 
a transfer to their bank account.

PayPal is an acquirer, performing payment processing for online vendors, 
auction sites, and other commercial users, for which it 
charges a fee. It may also charge a fee for receiving money, proportional to 
the amount received. The fees depend on the currency 
used, the payment option used, the country of the sender, the country of the 
recipient, the amount sent and the recipient s account 
type. In addition, eBay purchases made by credit card through PayPal may incur 
extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly owned subsidiary of eBay. Its 
corporate headquarters are in San Jose, California, United 
States at eBay s North First Street satellite office campus. The company also 
has significant operations in Omaha, Nebraska, Scottsdale, 
Arizona, and Austin, Texas, in the United States, Chennai, Dublin, Kleinmachnow 
(near Berlin) and Tel Aviv. As of July 2007, across 
Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), 
China s bankcard association, to allow Chinese consumers 
to use PayPal to shop online.PayPal is planning to expand its workforce in Asia 
to 2,000 by the end of the year 2010.
Between December 4ñ9, 2010, PayPal services were attacked in a series of 
denial-of-service attacks organized by Anonymous in retaliation 
for PayPal s decision to freeze the account of WikiLeaks citing terms of use 
violations over the publication of leaked US diplomatic cables.

(Copy of the Homepage: www.paypal.com) [http://en.wikipedia.org/wiki/PayPal]


Abstract:
=
The Vulnerability Laboratory Research Team discovered a Web Vulnerability in 
the official Paypal ecommerce website application.



Report-Timeline:

2012-07-06: Researcher Notification & Coordination
2012-07-06: Vendor Notification
2012-08-10: Vendor Response/Feedback
2012-10-29: Vendor Fix/Patch
2012-11-22: Public or Non-Public Disclosure


Status:

Published


Exploitation-Technique:
===
Remote


Severity:
=
Low


Details:

A client side redirection vulnerability is detected in the official Paypal 
ecommerce website content management system (Customer/Pro/Seller).
The bugs allow remote attackers to form client side requests to redirect a 
victim with the report (bericht) function from paypal to an external 
malicious target (website|server).  The vulnerability is located in the Reports 
(Berichte) - Export module with the bound vulnerable back-to-portal 
& portal_url parameter. The vulnerability can be exploited by remote attackers 
with medium or high required user inter action and without privileged 
Customer/Pro/Seller account. Successful exploitation of the vulnerability can 
lead exter redirections, client side spam mails & client side phishing mails.

Vulnerable Type(s):
  [+] Customer/Pro/Seller Accounts


Vulnerable Section(s):
  [+] Reports (Berichte) - Export


Vulnerable Module(s):
  [+] Export as File (Send Mail)


Vulnerable Parameter(s):
  [+] back-to-portal&portal_url


Proof of Co

[Full-disclosure] Apple WGT Dictionnaire 1.3 - Script Code Inject Vulnerability

[Vulnerability Lab]

Title:
==
Apple WGT Dictionnaire 1.3 - Script Code Inject Vulnerability


Date:
=
2012-11-27


References:
===
http://www.vulnerability-lab.com/get_content.php?id=774


VL-ID:
=
774


Common Vulnerability Scoring System:

2.3


Introduction:
=
http://www.apple.com/downloads/dashboard/reference/dictionnaire.html


Abstract:
=
The Vulnerability Laboratory Research Team discovered a script code inject 
vulnerability in Apples (MacOSx) Widget Dictionnaire v1.3 software. 


Report-Timeline:

2012-11-27: Public Disclosure


Status:

Published


Exploitation-Technique:
===
Local


Severity:
=
Medium


Details:

A persistent script code inject vulnerability is detected in the Dictionnaire, 
Dictionary of the French language based on TLFi (in French), Software. 
The vulnerability allows a local attacker execute malicious codes to compromise 
the connected client system in the lan. The command execution 
vulnerability is located in the search field of the Dictionnaire module. The 
malicious injected script code will be directly executed out of 
the result field. Successful exploitation of the vulnerability results in 
system compromise via script code injections, persistent software 
context manipulation, external malware loads or malicious external redirects. 

Vulnerable Software Module(s):
[+] Search Box

Vulnerable Software Parameter(s):
[+] Search Field


Proof of Concept:
=
The software validation vulnerability can be exploited by local attackers with 
required user interaction and privileged local system account.
For demonstration or reproduce ...

PoC: Script Code Inject
"VL Tester
“http://vuln-lab.com>>
"
"alert(document.cookie)http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [SECURITY] [DSA 2578-1] rssh security update

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -
Debian Security Advisory DSA-2578-1   secur...@debian.org
http://www.debian.org/security/ Yves-Alexis Perez
November 28, 2012  http://www.debian.org/security/faq
- -

Package: rssh
Vulnerability  : insufficient filtering of rsync command line
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2012-2251 CVE-2012-2252 
Debian Bug : 

James Clawson discovered that rssh, a restricted shell for OpenSSH to be used
with scp/sftp, rdist and cvs, was not correctly filtering command line options.
This could be used to force the execution of a remote script and thus allow
arbitrary command execution. Two CVE were assigned:

CVE-2012-2251
Incorrect filtering of command line when using rsync protocol. It was
for example possible to pass dangerous options after a "--" switch. The 
rsync
protocol support has been added in a Debian (and Fedora/Red Hat) 
specific
patch, so this vulnerability doesn't affect upstream.

CVE-2012-2251
Incorrect filtering of the "--rsh" option: the filter preventing usage 
of the
"--rsh=" option would not prevent passing "--rsh". This vulnerability 
affects
upstream code.

For the stable distribution (squeeze), this problem has been fixed in
version 2.3.2-13squeeze2.

For the testing distribution (wheezy), this problem has been fixed in
version 2.3.3-6.

For the unstable distribution (sid), this problem has been fixed in
version 2.3.3-6.

We recommend that you upgrade your rssh packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBCgAGBQJQtUm5AAoJEG3bU/KmdcCl+mYH/i+Qu3RJaGkNZhz0JphBAMvT
L2g1dbzNQOAePwvo69XIhNuAVAAqltV2N/GRvdlBORR7/W1NO9QOBodPwTkf4N9e
enl9z9+Wxb9Z1NgRCkAjTd6rkdzxFPpAzTe4uF4WfUH306lbTDHZyR3KZgEFqOdS
/16vbWoQ2QYz/hjIdlQI4GArBL+AZ5Fucq5oFqb5VcXv63Yi0U9qTliYH4iO/rzf
CkDbm7cdD7bO7LbshEqC+Cz1khVDfIG/KakzByxoNgcvMCoyhE5v8QNp6qnCPf3U
2yZ+8X5rm3on0j6YUF7+qeBTcLSAinHY+6Qzq9r+T7/xa77N+NGWUmW18EkYup8=
=Rfew
-END PGP SIGNATURE-

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

Re: [Full-disclosure] The email that hacks you

[Christian Sciberras]

>From an architectural perspective, "auto logins" or whatever they're called
should work through a random string, just as most providers already do.
There is absolutely no reason to pass the username/password from a
URL, especially when in plain text as in these cases.
Since there is no loss of features (there are safer, saner, sensible
alternatives), I think this is better considered a bug, since it is never
actually needed in the first place.

Also, with the random token system, I think it is best to still require the
user/pass when the URL the user is directed to is going to do something
such as modifying/updating stuff.


Chris.



On Wed, Nov 28, 2012 at 12:15 PM, Bogdan Calin  wrote:

> Yes, I agree with you.
>
> However, my opinion it that it should be fixed once and for all in
> iOS/Webkit (and the other
> browsers) by disabling resources loaded with credentials.
>
> At some point, as a protection for phishing, URLs with the format
> scheme://username:password@hostname/ were disabled.
> When you enter in the browser bar something like that it doesn't work in
> most browsers.
>
> I was surprised to see that doing something like  src='scheme://username:password@hostname/path'> works in Chrome and
> Firefox but if you enter the
> same URL in the browser bar it doesn't work. This doesn't work in Internet
> Explorer, which is the
> right behavior in my opinion.
>
> I don't see any good reason why something like this should work. Closing
> this in browsers will solve
> this problem once and for all.
>
> On 11/28/2012 1:00 PM, Guifre wrote:
> > Hello,
> >
> > "I can also confirm that this attack works on iPhone, iPad and Mac's
> > default mail client."
> >
> > Of course, it works anywhere where arbitrary client-side code can be
> > executed... IMAHO, the issue here is not your iphone loading images,
> > there are millions of attack vectors to trigger this attack... The
> > problem is the CSRF weaknesses of your router admin panel that should
> > be fixed by synchronizing a secret token or by using any other well
> > known mitigation strategy against these attacks.
> >
> > Best Regards,
> > Guifre.
> >
>
> --
> Bogdan Calin - bogdan [at] acunetix.com
> CTO
> Acunetix Ltd. - http://www.acunetix.com
> Acunetix Web Security Blog - http://www.acunetix.com/blog
> Follow us on Twitter - http://www.twitter.com/acunetix
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] The email that hacks you

[Bogdan Calin]

Yes, I agree with you.

However, my opinion it that it should be fixed once and for all in iOS/Webkit 
(and the other
browsers) by disabling resources loaded with credentials.

At some point, as a protection for phishing, URLs with the format
scheme://username:password@hostname/ were disabled.
When you enter in the browser bar something like that it doesn't work in most 
browsers.

I was surprised to see that doing something like  works in Chrome and Firefox but 
if you enter the
same URL in the browser bar it doesn't work. This doesn't work in Internet 
Explorer, which is the
right behavior in my opinion.

I don't see any good reason why something like this should work. Closing this 
in browsers will solve
this problem once and for all.

On 11/28/2012 1:00 PM, Guifre wrote:
> Hello,
> 
> "I can also confirm that this attack works on iPhone, iPad and Mac's
> default mail client."
> 
> Of course, it works anywhere where arbitrary client-side code can be
> executed... IMAHO, the issue here is not your iphone loading images,
> there are millions of attack vectors to trigger this attack... The
> problem is the CSRF weaknesses of your router admin panel that should
> be fixed by synchronizing a secret token or by using any other well
> known mitigation strategy against these attacks.
> 
> Best Regards,
> Guifre.
> 

-- 
Bogdan Calin - bogdan [at] acunetix.com
CTO
Acunetix Ltd. - http://www.acunetix.com
Acunetix Web Security Blog - http://www.acunetix.com/blog
Follow us on Twitter - http://www.twitter.com/acunetix

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

[Full-disclosure] The email that hacks you

[Bogdan Calin]

Hi guys,

I wrote a blog post about how an email can compromise your internal network 
when using iDevices in
combination with a certain type of routers.

http://www.acunetix.com/blog/web-security-zone/the-email-that-hacks-you/

-- 
Bogdan Calin - bogdan [at] acunetix.com
CTO
Acunetix Ltd. - http://www.acunetix.com
Acunetix Web Security Blog - http://www.acunetix.com/blog
Follow us on Twitter - http://www.twitter.com/acunetix

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