[Full-disclosure] New tool for penetration testing!!!

[runlvl]

Insecurity Research is happy to announce the release of version 2.0,
get it now while it is still hot !

Insect Pro 2.0 is a penetration security auditing and testing software
solution designed to allow organizations of all sizes mitigate,
monitor and manage the latest security threats vulnerabilities.

We’re always working to improve Insect Pro and now the users obtain
all the metasploit functionalities plus all the Insect Pro modules
merge all in a unique application.

We invite you to take a visual tour where you can find screen shots and
videos, visit us at http://www.insecurityresearch.com

We are really thankful with the community, thanks for all your support
that keep us coding!

There is no fixed price to get it, you can obtain the full version
with updates from $20 !

Get it now from: http://www.insecurityresearch.com

Juan Sacco

-- 
_
Insecurity Research - Security auditing and testing software
Web: http://www.insecurityresearch.com
Insect Pro 2.0 was released stay tunned
___
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] University of Central Florida Multiple LFI

[Chris M]

All true, I too have worked in education and fully understand that things
tend to run in a not-so-business-like fashion, often policies and procedures
are often outdated and not followed, if even staff know where to find them
or of their existence. This does not mean this is right, however. If
universities are to become players in this modern world of technology, they
cannot do so half-heartedly, and must stand up and realise these deployments
which SOMEONE put in need to be maintained. Unfortunately, it sometimes has
to fly in their face before they will stand up and take notice. Some people
just can't be rationalised with, more drastic action is often required. I am
not saying this is right either, but simply fact.

On Sun, Feb 20, 2011 at 5:18 PM, Caspian Kilkelly <
casp...@random-interrupt.org> wrote:

> Chris and Luis,
> Thinking that a university IT department is a centralized, monolithic
> structure (like it is in most businesses) is stretching it. Most of the
> places I've worked with or for have little internal empires run by whoever
> got there first, and their budgets are pretty slim. Having something like a
> regular infrastructure meeting would be great if the heads of the official
> infrastructure department even knew who the other infrastructure
> stakeholders were, but they usually don't.
>
> Additionally, 5 days or even 12 is far too short a time to disclose vulns
> for institutions that have a support response time of a week or more (most
> universities move at a glacial pace). While I realize that you think this is
> critical, their IT managers might not have any idea what the problem is
> (communications are poor, they are usually undertrained and underpaid), and
> certainly have about 300 other things to think about that are likely just as
> serious to them (like prof Fuzzyhair's massive lab installation, or the
> director of research needing a new pc). Next time, make a few phone calls,
> and not to the peons who run the support desk (no offense, help desk), call
> the head of IT or the president, rector, or someone equally high up, and
> give them enough time to respond. You catch more flies with honey, etc..
>
>
> Caspian
>
>
> On 2011-02-19, at 1:02 PM, Chris M  wrote:
>
> Agreed - by not taking further steps following the complete negligence of
> the institution to protect the security of their assets (and thereby placing
> students & staff at risk) there must be some further incentive to bring this
> to their attention. If anything they should have regular infrastructure
> meetings where items like this should be at the top of the agenda.
>
> Its unfortunate that it has to come to this with many institutions - I have
> had many similar experiences.
>
> On Sat, Feb 19, 2011 at 5:54 PM, Hack Talk < 
> hacktalkb...@gmail.com> wrote:
>
>> Weev,
>>
>> I actually know many of the "techrangers" who are UCF employed students
>> which are in charge of maintaining websites and have spoken to them
>> personally about these and other vulnerabilities many times in the past and
>> they have yet to patch them. In addition to that I have gone so far as to
>> finding one of the developer's website ( 
>> http://www.stevenmonetti.com/) and not only emailing him, but adding him
>> to my gTalk list (the invitation to which he has yet to accept after about a
>> month) and after looking at his resume left him a text message and a
>> voicemail all with no contact back. I am flat out when reporting
>> vulnerabilities and let the affected party know from day one that I follow
>> the RFP Responsible Disclosure Policy and if I don't hear back in 5 days I
>> no longer need to work with them. On days 3 and 5 I always email back if
>> they haven't gotten back in contact with me and once again reiterate the
>> disclosure policy. At this point they must not care enough if I was doing
>> that every 3 days for quite some time. If they don't care about their own
>> security then something must happen to make them care.
>>
>>
>> Luis Santana
>>
>>
>>
>> On Sat, Feb 19, 2011 at 12:49 PM, Eyeballing Weev 
>> <
>> eyeballing.w...@gmail.com> wrote:
>>
>>> Shawn,
>>>
>>> "Hack Talk" would rather fire off 5 emails than pick up a phone, make a
>>> phone call and call someone from the WHOIS information since by his own
>>> admission he's a Florida resident who lives near UCF or maybe he's
>>> worried about law enforcement after all ;-)
>>>
>>>
>>> On 02/19/2011 12:46 PM, Hack Talk wrote:
>>> > Hey Shawn,
>>> >
>>> > I typically follow the Rain Forest Puppy Responsible Disclosure Policy
>>> > which I'm sure many people have read. I even extended the contact time
>>> > to 2 weeks since Universities are quite busy places. During those 2
>>> > weeks I personally emailed them back 5 times and did not get a single
>>> > response back. This is not the first time the University has neglected
>>> > to respond to vulnerabilities affecting their sites and as such I
>>> > decided that enough was enough an

[Full-disclosure] [SECURITY] [DSA 2170-1] mailman security update

[Thijs Kinkhorst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
Debian Security Advisory DSA-2170-1   secur...@debian.org
http://www.debian.org/security/   Thijs Kinkhorst
February 18, 2011  http://www.debian.org/security/faq
- -

Package: mailman
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2010-3089 CVE-2011-0707

Two cross site scripting vulnerabilities were been discovered in
Mailman, a web-based mailing list manager. These allowed an attacker
to retreive session cookies via inserting crafted JavaScript into
confirmation messages (CVE-2011-0707) and in the list admin interface
(CVE-2010-3089; oldstable only).

For the oldstable distribution (lenny), these problems have been fixed in
version 1:2.1.11-11+lenny2.

For the stable distribution (squeeze), this problem has been fixed in
version 1:2.1.13-5.

For the testing (wheezy) and unstable distribution (sid), this problem
has been fixed in version 1:2.1.14-1.

We recommend that you upgrade your mailman 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 v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNYQIWAAoJEOxfUAG2iX573uEH/iCu1JjYMCh/lu2uB2PGQZHy
hwiuJCBKU6Ufg8gQ7kC7uxp/hF3NF+1RQbmYr384tLu/m+w8guvs3y7oYO/mZTPj
OEZwkWJhl+9PrfEXxv4NxMpZPUXP/MGGPVKB8ALmYPx0/o1E38gfRzQWBKRMqbkK
WxJs0olI7j4eC7YXirad3kBjmHTOgJj/nF3TCCKXVvvCPDeybfItuKP+BwE+fRV0
lofha4JN++ZcgeU9W7MurHTyMoYv2vSiOKHy+WN6SUUKc9n9sIa86aBM0YiFMigb
OdF/J0SUJvgbmCi4eRmMTDIFzUHwBqPHqIsfuyfEm5M/IIthokra7hDV8iyWLVI=
=E9qi
-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] University of Central Florida Multiple LFI

[Hack Talk]

Caspian,

I'm not here to catch flies, I'm here to ensure holes get patched. As I've
stated time and time again I contacted many people all throughout the "food
chain" and even went so far as contacted web developers on their personal
cellular devices. When Brown University had a problem I emailed their
security contact and within 5 hours I received word back; the same is not
true of UCF. When Berkeley had a gaping hole in their security which allowed
me into their administrative backend, I again emailed the security contact
listed in their whois information and within 12 hours heard back from them
with the vulnerability itself being patched within 18 hours; the same is not
true of UCF. I've contacted schools and organizations much larger than UCF
and received not only faster response times but have been given explicit
security contacts should I find anything new; after having disclosed over 20
bugs to UCF, I've yet to ever receive a _single_ email back or even given an
explicit security contact despite asking for one in _every_ email I send. At
this point, following the RFP Disclosure Policy, I no longer feel obligated
to work with them and will more than likely instantly disclose any
vulnerability I find in their code; if FD doesn't approve they should
consider their stance on Full Disclosure as a disclosure policy.

*"Full disclosure* requires that full details of a security vulnerability
are disclosed to the public, including details of the vulnerability and how
to detect and exploit it. The theory behind *full disclosure* is that
releasing vulnerability information immediately results in quicker fixes and
better security. Fixes are produced faster because vendors and authors are
forced to respond in order to protect their system from potential attacks as
well as to protect their own image. Security is improved because the *window
of exposure*, the amount of time the vulnerability is open to attack, is
reduced."

Luis Santana


On Sun, Feb 20, 2011 at 12:18 PM, Caspian Kilkelly <
casp...@random-interrupt.org> wrote:

> Chris and Luis,
> Thinking that a university IT department is a centralized, monolithic
> structure (like it is in most businesses) is stretching it. Most of the
> places I've worked with or for have little internal empires run by whoever
> got there first, and their budgets are pretty slim. Having something like a
> regular infrastructure meeting would be great if the heads of the official
> infrastructure department even knew who the other infrastructure
> stakeholders were, but they usually don't.
>
> Additionally, 5 days or even 12 is far too short a time to disclose vulns
> for institutions that have a support response time of a week or more (most
> universities move at a glacial pace). While I realize that you think this is
> critical, their IT managers might not have any idea what the problem is
> (communications are poor, they are usually undertrained and underpaid), and
> certainly have about 300 other things to think about that are likely just as
> serious to them (like prof Fuzzyhair's massive lab installation, or the
> director of research needing a new pc). Next time, make a few phone calls,
> and not to the peons who run the support desk (no offense, help desk), call
> the head of IT or the president, rector, or someone equally high up, and
> give them enough time to respond. You catch more flies with honey, etc..
>
>
> Caspian
>
>
> On 2011-02-19, at 1:02 PM, Chris M  wrote:
>
> Agreed - by not taking further steps following the complete negligence of
> the institution to protect the security of their assets (and thereby placing
> students & staff at risk) there must be some further incentive to bring this
> to their attention. If anything they should have regular infrastructure
> meetings where items like this should be at the top of the agenda.
>
> Its unfortunate that it has to come to this with many institutions - I have
> had many similar experiences.
>
> On Sat, Feb 19, 2011 at 5:54 PM, Hack Talk < 
> hacktalkb...@gmail.com> wrote:
>
>> Weev,
>>
>> I actually know many of the "techrangers" who are UCF employed students
>> which are in charge of maintaining websites and have spoken to them
>> personally about these and other vulnerabilities many times in the past and
>> they have yet to patch them. In addition to that I have gone so far as to
>> finding one of the developer's website ( 
>> http://www.stevenmonetti.com/) and not only emailing him, but adding him
>> to my gTalk list (the invitation to which he has yet to accept after about a
>> month) and after looking at his resume left him a text message and a
>> voicemail all with no contact back. I am flat out when reporting
>> vulnerabilities and let the affected party know from day one that I follow
>> the RFP Responsible Disclosure Policy and if I don't hear back in 5 days I
>> no longer need to work with them. On days 3 and 5 I always email back if
>> they haven't gotten back in co

Re: [Full-disclosure] [Google Chrome Browser] Google Mail Checker Plus: JavaScript Code Execution

[Jardel Weyrich]

The XSS in Google Mail Checker Plus was reported in 06/2010. However, the
latest version is still vulnerable.

The PoC can be an email with a body like this:
Anything in this line, or nothing at all
alert('you are vulnerable');

I posted a notification on their support forum yesterday.

-jardel

On Sat, Feb 19, 2011 at 7:59 PM, ck  wrote:

> Well, at least ">alert(/XSS/) works great:
>
> http://img6.imagebanana.com/img/4tyst18d/one.png
> http://img6.imagebanana.com/img/wh9zwmc6/two.png
>
> Thx to Friedrich Hausberger for his mail to FD :)
>
> ck
>
> ___
> 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] University of Central Florida Multiple LFI

[Caspian Kilkelly]

Chris and Luis,
Thinking that a university IT department is a centralized, monolithic structure 
(like it is in most businesses) is stretching it. Most of the places I've 
worked with or for have little internal empires run by whoever got there first, 
and their budgets are pretty slim. Having something like a regular 
infrastructure meeting would be great if the heads of the official 
infrastructure department even knew who the other infrastructure stakeholders 
were, but they usually don't. 

Additionally, 5 days or even 12 is far too short a time to disclose vulns for 
institutions that have a support response time of a week or more (most 
universities move at a glacial pace). While I realize that you think this is 
critical, their IT managers might not have any idea what the problem is 
(communications are poor, they are usually undertrained and underpaid), and 
certainly have about 300 other things to think about that are likely just as 
serious to them (like prof Fuzzyhair's massive lab installation, or the 
director of research needing a new pc). Next time, make a few phone calls, and 
not to the peons who run the support desk (no offense, help desk), call the 
head of IT or the president, rector, or someone equally high up, and give them 
enough time to respond. You catch more flies with honey, etc..


Caspian


On 2011-02-19, at 1:02 PM, Chris M  wrote:

> Agreed - by not taking further steps following the complete negligence of the 
> institution to protect the security of their assets (and thereby placing 
> students & staff at risk) there must be some further incentive to bring this 
> to their attention. If anything they should have regular infrastructure 
> meetings where items like this should be at the top of the agenda.
> 
> Its unfortunate that it has to come to this with many institutions - I have 
> had many similar experiences.
> 
> On Sat, Feb 19, 2011 at 5:54 PM, Hack Talk  wrote:
> Weev,
> 
> I actually know many of the "techrangers" who are UCF employed students which 
> are in charge of maintaining websites and have spoken to them personally 
> about these and other vulnerabilities many times in the past and they have 
> yet to patch them. In addition to that I have gone so far as to finding one 
> of the developer's website (http://www.stevenmonetti.com/) and not only 
> emailing him, but adding him to my gTalk list (the invitation to which he has 
> yet to accept after about a month) and after looking at his resume left him a 
> text message and a voicemail all with no contact back. I am flat out when 
> reporting vulnerabilities and let the affected party know from day one that I 
> follow the RFP Responsible Disclosure Policy and if I don't hear back in 5 
> days I no longer need to work with them. On days 3 and 5 I always email back 
> if they haven't gotten back in contact with me and once again reiterate the 
> disclosure policy. At this point they must not care enough if I was doing 
> that every 3 days for quite some time. If they don't care about their own 
> security then something must happen to make them care.
> 
> 
> Luis Santana
> 
> 
> 
> On Sat, Feb 19, 2011 at 12:49 PM, Eyeballing Weev  
> wrote:
> Shawn,
> 
> "Hack Talk" would rather fire off 5 emails than pick up a phone, make a
> phone call and call someone from the WHOIS information since by his own
> admission he's a Florida resident who lives near UCF or maybe he's
> worried about law enforcement after all ;-)
> 
> 
> On 02/19/2011 12:46 PM, Hack Talk wrote:
> > Hey Shawn,
> >
> > I typically follow the Rain Forest Puppy Responsible Disclosure Policy
> > which I'm sure many people have read. I even extended the contact time
> > to 2 weeks since Universities are quite busy places. During those 2
> > weeks I personally emailed them back 5 times and did not get a single
> > response back. This is not the first time the University has neglected
> > to respond to vulnerabilities affecting their sites and as such I
> > decided that enough was enough and that by publicly disclosing these
> > vulnerabilities they would be forced to patch their code. I've worked
> > with many Universities in the past to patch there vulnerabilities and
> > they have responded typically within 12 hours of me sending my initial
> > email alerting them to the issue. Being a .edu does not exempt you from
> > hackers wanting into your system and it does not mean you can get away
> > with having gaping holes in security for months without patching them.
> >
> > Full Disclosure as a methodology is about forcing people to fix their
> > holes which is exactly what I was hoping would happen to UCF.
> >
> > Thanks for doing your best to extinguish the flamewar that was starting :D.
> >
> >
> > Luis Santana
> >
> >
> >
> 
> ___
> 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] [ MDVSA-2011:032 ] eclipse

[security]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2011:032
 http://www.mandriva.com/security/
 ___

 Package : eclipse
 Date: February 20, 2011
 Affected: 2009.0, 2010.0, 2010.1, Enterprise Server 5.0
 ___

 Problem Description:

 A vulnerability has been found and corrected in eclipse:
 
 Multiple cross-site scripting (XSS) vulnerabilities in the Help
 Contents web application (aka the Help Server) in Eclipse IDE before
 3.6.2 allow remote attackers to inject arbitrary web script or HTML via
 the query string to (1) help/index.jsp or (2) help/advanced/content.jsp
 (CVE-2010-4647).
 
 Packages for 2009.0 are provided as of the Extended Maintenance
 Program. Please visit this link to learn more:
 http://store.mandriva.com/product_info.php?cPath=149&products_id=490
 
 The updated packages have been patched to correct this issue.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4647
 ___

 Updated Packages:

 Mandriva Linux 2009.0:
 f23eac06e77995e1a9c3caa733196b08  
2009.0/i586/eclipse-ecj-3.4.0-0.22.3.1mdv2009.0.i586.rpm
 c573647789a7e62ca529c6865b996472  
2009.0/i586/eclipse-jdt-3.4.0-0.22.3.1mdv2009.0.i586.rpm
 9678c08c8f1e1a2a043f1201df8d8c9c  
2009.0/i586/eclipse-pde-3.4.0-0.22.3.1mdv2009.0.i586.rpm
 ba3c1070a867ddfa09d1561dc277461f  
2009.0/i586/eclipse-platform-3.4.0-0.22.3.1mdv2009.0.i586.rpm
 73daed8dff7db542c98375aab26d5639  
2009.0/i586/eclipse-rcp-3.4.0-0.22.3.1mdv2009.0.i586.rpm
 860d77097f83cc488b8d200e5cf5450c  
2009.0/i586/eclipse-swt-3.4.0-0.22.3.1mdv2009.0.i586.rpm 
 ec28ad60f56519d420c33bdae5b80f5f  
2009.0/SRPMS/eclipse-3.4.0-0.22.3.1mdv2009.0.src.rpm

 Mandriva Linux 2009.0/X86_64:
 4719459988c3a26bebfdac2e0842553f  
2009.0/x86_64/eclipse-ecj-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm
 929e861f6167ec7059edd54bed1c14ce  
2009.0/x86_64/eclipse-jdt-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm
 bdd017bd5ed64eca233be66ab82317b2  
2009.0/x86_64/eclipse-pde-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm
 1891e792345b5ba3e3ece5fccc579607  
2009.0/x86_64/eclipse-platform-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm
 bc0bff96d509dc86b08d8cb12bab35fc  
2009.0/x86_64/eclipse-rcp-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm
 a693baad1931bdf15143e17523f87db7  
2009.0/x86_64/eclipse-swt-3.4.0-0.22.3.1mdv2009.0.x86_64.rpm 
 ec28ad60f56519d420c33bdae5b80f5f  
2009.0/SRPMS/eclipse-3.4.0-0.22.3.1mdv2009.0.src.rpm

 Mandriva Linux 2010.0:
 ef7f0f74134db1f9da23d60a79d3c2ae  
2010.0/i586/eclipse-ecj-3.4.2-0.2.3.1mdv2010.0.i586.rpm
 85ef610955b0123bb2ee0698f38e0370  
2010.0/i586/eclipse-jdt-3.4.2-0.2.3.1mdv2010.0.i586.rpm
 6db56a26cbf672e3940469fdf1b3fa97  
2010.0/i586/eclipse-pde-3.4.2-0.2.3.1mdv2010.0.i586.rpm
 dee812dc8095b39d02ded98505310f97  
2010.0/i586/eclipse-platform-3.4.2-0.2.3.1mdv2010.0.i586.rpm
 c15519d73f277fa321c10b8676a08a51  
2010.0/i586/eclipse-rcp-3.4.2-0.2.3.1mdv2010.0.i586.rpm
 d1775b88bca758d0c02ebec17dcf9b66  
2010.0/i586/eclipse-swt-3.4.2-0.2.3.1mdv2010.0.i586.rpm 
 776bda7419053c29891fc46eb9334070  
2010.0/SRPMS/eclipse-3.4.2-0.2.3.1mdv2010.0.src.rpm

 Mandriva Linux 2010.0/X86_64:
 ef7d51d4030eef85c19d2c2b88b510fd  
2010.0/x86_64/eclipse-ecj-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm
 f1f7001813002eab80894c25e09d5ad6  
2010.0/x86_64/eclipse-jdt-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm
 6f6778ea8728995fab3c53d9eaaa5ae1  
2010.0/x86_64/eclipse-pde-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm
 e925bd43bd3e7fc0b2a6558a2216f4f2  
2010.0/x86_64/eclipse-platform-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm
 a925253c01fa9608b60eb67da2ce2c61  
2010.0/x86_64/eclipse-rcp-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm
 7fd7f5f75604249efec239ec382e5049  
2010.0/x86_64/eclipse-swt-3.4.2-0.2.3.1mdv2010.0.x86_64.rpm 
 776bda7419053c29891fc46eb9334070  
2010.0/SRPMS/eclipse-3.4.2-0.2.3.1mdv2010.0.src.rpm

 Mandriva Linux 2010.1:
 761aa1ab2aba68a0791342b8dc32a94b  
2010.1/i586/eclipse-ecj-3.4.2-0.2.3.1mdv2010.2.i586.rpm
 7a73b1b2c7c5dc2d87e6baa630ff5baa  
2010.1/i586/eclipse-jdt-3.4.2-0.2.3.1mdv2010.2.i586.rpm
 f4f42a48d7bba008347e4546312bf533  
2010.1/i586/eclipse-pde-3.4.2-0.2.3.1mdv2010.2.i586.rpm
 1136d33a8c5cdeca908e4aa949dbc749  
2010.1/i586/eclipse-platform-3.4.2-0.2.3.1mdv2010.2.i586.rpm
 22ac420305e99ae871f1bb79b2a02022  
2010.1/i586/eclipse-rcp-3.4.2-0.2.3.1mdv2010.2.i586.rpm
 93c1d6dc0a33582f17b70973fcd7f7df  
2010.1/i586/eclipse-swt-3.4.2-0.2.3.1mdv2010.2.i586.rpm 
 f6b9958cea21e3a5b8776ce189d0a0b4  
2010.1/SRPMS/eclipse-3.4.2-0.2.3.1mdv2010.2.src.rpm

 Mandriva Linux 2010.1/X86_64:
 d87be0097e241a8e3c2c4f593fee002f  
2010.1/x86_64/eclipse-ecj-3.4.2-0.2.3.1mdv2010.2.x86_64.rpm
 80e3535c9a106f96bfba7d0f3b57f0b6  
2010.1/x86_64/eclipse-jdt-3.4.2-0.2.3.1mdv2010.2

Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal

[MustLive]

Hello Zach!

> fucking *two days*? Is that even enough time for the vendor to
> acknowledge?

You've read inattentively - between informing of developers and disclosing
of vulnerabilities the two months and two days have passed (as you can see
in Timeline section). So be more attentive next time.

About how much time developers need to fix the holes.

1. The developers need enough time and I'm always giving them enough time.
In different cases I gave different time: sometimes it was month or few
months, sometimes it was year or even more. But always sufficient amount of
time (and if developer just ignore the hole, then regardless of given time,
such developer never fix it). In average I'm giving two months for fixing.

2. Different developers need different amount of time. It also depends on 
number of vulnerabilities.

For example, developer of PHPXref fixed holes on the next day after I
informed him (http://phpxref.sourceforge.net/Changelog). And developers of
MyBB, which I informed about multiple vulnerabilities last week, they are
still investigating them (for more then week), as they stated.

Mozilla requires just ten days, as they stated
(http://ha.ckers.org/blog/20070803/mozilla-says-ten-fucking-days/). And I
had such cases, when admins of web sites fixed holes in a few minutes after
receiving of my letter (as they stated, when quickly answered me after the
fixes).

So there are developers which fix holes quickly enough.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

- Original Message - 
From: Zach C.
To: MustLive
Cc: bugt...@securityfocus.com ; full-disclosure@lists.grok.org.uk ;
submissi...@packetstormsecurity.org
Sent: Thursday, February 17, 2011 7:54 PM
Subject: Re: [Full-disclosure] Vulnerability in reCAPTCHA for Drupal


fucking *two days*? Is that even enough time for the vendor to acknowledge?
On Feb 17, 2011 9:20 AM, "MustLive"  wrote:
> Hello list!
>
> I want to warn you about Insufficient Anti-automation vulnerability in
> reCAPTCHA for Drupal.
>
> In project MoBiC in 2007 I already wrote about bypassing of reCaptcha for
> Drupal (http://websecurity.com.ua/1505/). This is new method of bypassing
> reCaptcha for Drupal.
>
> -
> Affected products:
> -
>
> Vulnerable are all versions of reCAPTCHA plugin for Captcha module
> versions
> before 6.x-2.3 and 7.x-1.0.
>
> --
> Details:
> --
>
> Insufficient Anti-automation (WASC-21):
>
> In different forms in Drupal the vulnerable captcha-plugin reCAPTCHA is
> using. Drupal's Captcha module is vulnerable itself, so besides reCAPTCHA
> other captcha-plugins also can be vulnerable (at that this exploit is a
> little different from exploit for default Captcha module for Drupal).
>
> For bypassing of captcha it's needed to use correct value of captcha_sid,
> at
> that it's possible to not answer at captcha (captcha_response) or set any
> answer. This method of captcha bypass is described in my project Month of
> Bugs in Captchas (http://websecurity.com.ua/1498/). Attack is possible
> while
> this captcha_sid value is active.
>
> Vulnerabilities exist on pages with forms: http://site/contact,
> http://site/user/1/contact, http://site/user/password and
> http://site/user/register. Other forms where reCAPTCHA is using also will
> be
> vulnerable.
>
> Exploit:
>
> http://websecurity.com.ua/uploads/2011/Drupal%20reCAPTCHA%20bypass.html
>
> 
> Timeline:
> 
>
> 2010.12.11 - announced at my site.
> 2010.12.14 - informed reCAPTCHA developers.
> 2010.12.14 - informed Google (reCAPTCHA owner).
> 2011.02.16 - disclosed at my site.
>
> I mentioned about this vulnerability at my site
> (http://websecurity.com.ua/4752/).
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
>
> ___
> 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/

[Full-disclosure] [Google Chrome Browser] Google Mail Checker Plus: JavaScript Code Execution

[ck]

Well, at least ">alert(/XSS/) works great:

http://img6.imagebanana.com/img/4tyst18d/one.png
http://img6.imagebanana.com/img/wh9zwmc6/two.png

Thx to Friedrich Hausberger for his mail to FD :)

ck

___
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] (a present for andrew wallace, with love from cal)‏

[Cal Leeming [Simplicity Media Ltd]]

Whoa, that went *completely* over my head lol ;(

On 20 Feb 2011 02:17,  wrote:

On Sat, 19 Feb 2011 20:10:59 GMT, "Cal Leeming [Simplicity Media Ltd]" said:
> Son, this is how we d...
Unfortunately, he's probably been around longer than you have...


> On Sat, Feb 19, 2011 at 5:31 PM, andrew.wallace <
andrew.wall...@rocketmail.com> wrote:

> > We know you're desperate for attention when you post pictures of
yourself
> > to the public doma...
But he still doesn't make sense.  A security professional who's been around
as long as he has should know that in any Bern convention signatory nation,
merely posting a picture does *not* release it into the "public domain",
and that in fact it's (depending on the nation) somewhere between difficult
and impossible to actually release something into public domain before the
copyright has expired.  Therefore, we are obviously being trolled by
a fake Andrew...
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/