Re: [Full-disclosure] Full-Disclosure Digest, Vol 93, Issue 11
Scott Miller wrote: > You seem to be assuming that denying a random user access to FB is a > security liability ;>] Indeed -- sounds more like a useful public service... Regards, Nick FitzGerald ___ 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] Full-Disclosure Digest, Vol 93, Issue 11
You seem to be assuming that denying a random user access to FB is a security liability ;>] >full-disclosure-boun...@lists.grok.org.uk wrote on 11/10/2012 07:00:02 AM: > -- > > Message: 2 > Date: Thu, 08 Nov 2012 04:28:33 -0300 > From: "Chris C. Russo" > Subject: [Full-disclosure] A damn aweful facebook DOS > To: full-disclosure@lists.grok.org.uk > Message-ID: <509b5f21.90...@calciumsec.com> > Content-Type: text/plain; charset=ISO-8859-1 > ... > End of Full-Disclosure Digest, Vol 93, Issue 11 > *** > ___ 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] List Charter
[Full-Disclosure] Mailing List Charter John Cartwright - Introduction & Purpose - This document serves as a charter for the [Full-Disclosure] mailing list hosted at lists.grok.org.uk. The list was created on 9th July 2002 by Len Rose, and is primarily concerned with security issues and their discussion. The list is administered by John Cartwright. The Full-Disclosure list is hosted and sponsored by Secunia. - Subscription Information - Subscription/unsubscription may be performed via the HTTP interface located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure. Alternatively, commands may be emailed to full-disclosure-requ...@lists.grok.org.uk, send the word 'help' in either the message subject or body for details. - Moderation & Management - The [Full-Disclosure] list is unmoderated. Typically posting will be restricted to members only, however the administrators may choose to accept submissions from non-members based on individual merit and relevance. It is expected that the list will be largely self-policing, however in special circumstances (eg spamming, misappropriation) then offending members may be removed from the list by the management. An archive of postings is available at http://lists.grok.org.uk/pipermail/full-disclosure/. - Acceptable Content - Any information pertaining to vulnerabilities is acceptable, for instance announcement and discussion thereof, exploit techniques and code, related tools and papers, and other useful information. Gratuitous advertisement, product placement, or self-promotion is forbidden. Disagreements, flames, arguments, and off-topic discussion should be taken off-list wherever possible. Humour is acceptable in moderation, providing it is inoffensive. Politics should be avoided at all costs. Members are reminded that due to the open nature of the list, they should use discretion in executing any tools or code distributed via this list. - Posting Guidelines - The primary language of this list is English. Members are expected to maintain a reasonable standard of netiquette when posting to the list. Quoting should not exceed that which is necessary to convey context, this is especially relevant to members subscribed to the digested version of the list. The use of HTML is discouraged, but not forbidden. Signatures will preferably be short and to the point, and those containing 'disclaimers' should be avoided where possible. Attachments may be included if relevant or necessary (e.g. PGP or S/MIME signatures, proof-of-concept code, etc) but must not be active (in the case of a worm, for example) or malicious to the recipient. Vacation messages should be carefully configured to avoid replying to list postings. Offenders will be excluded from the mailing list until the problem is corrected. Members may post to the list by emailing full-disclosure@lists.grok.org.uk. Do not send subscription/ unsubscription mails to this address, use the -request address mentioned above. - Charter Additions/Changes - The list charter will be published at http://lists.grok.org.uk/full-disclosure-charter.html. In addition, the charter will be posted monthly to the list by the management. Alterations will be made after consultation with list members and a consensus has been reached. ___ 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] BananaDance Wiki b2.2 - Multiple Web Vulnerabilities
Title: == BananaDance Wiki b2.2 - Multiple Web Vulnerabilities Date: = 2012-11-10 References: === http://www.vulnerability-lab.com/get_content.php?id=745 VL-ID: = 745 Common Vulnerability Scoring System: 7.1 Introduction: = Banana Dance is an open-source PHP/MySQL-based program. It is designed to combine the simplicity of wiki-publishing software with the versatility of a CMS. The program also promotes community-building through organized and user-rated commenting features. Highly flexible with theme-integration and extension availability Banana Dance can be used for all types of purposes, whether it be to create an entire website, a product owner`s manual, or an `article`-posting site. (Copy of the Vendor Homepage: http://www.bananadance.org ) Abstract: = The vulnerability Laboratory Research Team discovered multiple web vulnerabilities in the official BananaDance Wiki b2.2 CMS. Report-Timeline: 2012-11-10: Public or Non-Public Disclosure Status: Published Exploitation-Technique: === Remote Severity: = High Details: 1.1 A SQL Injection vulnerability is detected in the BananaDance Wiki B2.2 Content Management System. The vulnerability allows an attacker (remote) or local privileged moderator/admin user account to execute own SQL commands on the affected application dbms. The sql injection vulnerability is located in user management module with the bound vulnerable alpha listing parameter. Successful exploitation of the vulnerability results in dbms & application compromise. Exploitation requires no user interaction & without privileged user account. Vulnerable Module(s): [+] User Management Vulnerable Parameter(s): [+] alpha 1.2 Multiple persistent input validation vulnerabilities are detected in the BananaDance Wiki B2.2 Content Management System. The bugs allow remote attackers to implement/inject malicious script code on the application side (persistent) of the vulnerable module. The persistent vulnerabilities are located in the user, banned user, badge module listing with the bound vulnerable username and email parameters. Successful exploitation of the vulnerability can lead to session hijacking (manager/admin) or stable (persistent) context manipulation. Exploitation requires low user inter action (view listing) & a registered low privileged web application user account. Vulnerable Module(s): [+] Add User - Listing [+] Banned User - Listing [+] Badges - Listing Vulnerable Parameter(s): [+] Username & Email (Profil) Proof of Concept: = 1.1 The sql injection vulnerability can be exploited by local privileged user accounts and moderators. For demonstration or reproduce ... PoC: BananaDance Wiki b2.2 - SQL Vulnerability http://bananadance-wiki.127.0.0.1:1339/admin/index.php?l=users&alpha=A'-1 [SQL-INJECTION!]-- width="1000" height="800"> http://bananadance-wiki.127.0.0.1:1339/admin/index.php?l=users&alpha=M'-1 [SQL-INJECTION!]-- width="1000" height="800"> http://bananadance-wiki.127.0.0.1:1339/admin/index.php?l=users&alpha=K'-1 [SQL-INJECTION!]-- width="1000" height="800"> 1.2 The persistent input validation vulnerabilities can be exploited by remote attacker with low privileged application user account and low required user inter action. For demonstration or reproduce ... Review: Add (Existing) User - Listing "><[PERSISTENT EXECUTION OF INJECTED SCRIPT CODE!];)" <<="" a=""> 2012-06-20 ESTANDAR 0 0 0 URL(s): http://bananadance-wiki.127.0.0.1:1339/admin/index.php?l=users > http://bananadance-wiki.127.0.0.1:1339/admin/index.php?l=users_add Risk: = 1.1 The security risk of the local sql injection vulnerability is estimated as medium(+) because of the required moderator account. 1.2 The security risk of the persistent input validation vulnerabilities are estimated as high. Credits: Vulnerability Laboratory [Research Team] - Kathrin SL (ka...@vulnerability-lab.com) Disclaimer: === The information provided in this advisory is provided as it is without any warranty. Vulnerability-Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability- Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not appr
Re: [Full-disclosure] TTY handling when executing code in lower-privileged context (su, virt containers)
There are a few things to consider from my experience: 1. It's easy to say "don't use weak passwords", however unless you're using some 2 factor system or systematically forcing random passwords, people are generating the passwords, and history tells us that most people are very bad at that task. 2. Most organizations institute lockout policies for normal user accounts, so generally even a weak user password can't be guessed within 5 or 10 tries. However, root can't generally be locked out, so they are open to brute force attacks. I have first hand experience responding to incidents that resulted from root being successfully brute forced. 3. The concept of individual accountability is becoming increasingly important for many organizations. This doesn't matter much in some, particularly small, environments, but in a setting with dozens or hundreds of administrators, it is quite important. SUDO is about the only effective way of enabling large numbers of admins to operate on a system while maintaining accountability. It is not bullet proof, but it is a quite effective solution generally. So, I am genuinely curious - how does blocking root logins and requiring SUDO weaken a system? I definitely have a lot to learn, and I feel like I am missing something. Regards, Jerry On Nov 10, 2012, at 1:30 PM, Michal Zalewski wrote: >> I think you've taken that far too literaly. My understanding of it is to >> protect against a) brute force retardation b) dumb attackers. > > The advice weakens the security of your system, because it means I > just need to compromise your unprivileged account (in which you run > your browser, mail client, and so on) to own the entire box. > > As for the benefits, care to elaborate? I'm not sure what a) and b) > really mean. If you're worried about brute-force, don't use trivial > passwords. If you worry about opportunistic attacks, do that and then > patch your stuff every now and then. > > /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/ ___ 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] [DSA 2573-1] radsecproxy security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2573-1 secur...@debian.org http://www.debian.org/security/ Luciano Bello November 10, 2012 http://www.debian.org/security/faq - - Package: radsecproxy Vulnerability : SSL certificate verification weakness Problem type : remote Debian-specific: no CVE ID : CVE-2012-4523 CVE-2012-4566 Ralf Paffrath reported that Radsecproxy, a RADIUS protocol proxy, mixed up pre- and post-handshake verification of clients. This vulnerability may wrongly accept clients without checking their certificate chain under certain configurations. Raphael Geissert spotted that the fix for CVE-2012-4523 was incomplete, giving origin to CVE-2012-4566. Both vulnerabilities are fixed with this update. Notice that this fix may make Radsecproxy reject some clients that are currently (erroneously) being accepted. For the stable distribution (squeeze), these problems have been fixed in version 1.4-1+squeeze1. For the testing distribution (wheezy), these problems have been fixed in version 1.6.2-1. For the unstable distribution (sid), these problems have been fixed in version 1.6.2-1. We recommend that you upgrade your radsecproxy 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.11 (GNU/Linux) iEYEARECAAYFAlCeylIACgkQQWTRs4lLtHkHaACcDHUTL37Y/8wTylt4xFSkwJVJ BI0AoIVkG7fkhBYWb7VEAIDSK5kjRHqJ =N4xn -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/
[Full-disclosure] Gajim fails to handle invalid certificates
Gajim does not seem to properly handle invalid/broken/expired
certificates. The _ssl_verify_callback function in tls_nb.py is called
by OpenSSL for every certificate in the certificate chain (CA first,
server certificate last) but always return True whether an error was
encountered or not.
This forces OpenSSL to verify each certificate until none is left, at
which points it will call _ssl_verify_callback one last time with an
error number of 0.
(This behavior is documented here: man 3 SSL_CTX_set_verify
"If verify_callback returns 1, the verification process is continued.
If verify_callback always returns 1, the TLS/SSL handshake will not be
terminated with respect to verification failures and the connection will
be established."
And can be observed in function
crypto/x509/x509_vfy.c:internal_verify() in OpenSSL source code.)
_ssh_verify_callback only stores the last error code, which always is 0
unless an error was encountered in the deepest level of the chain (the
CA), so gajim will not warn as long as the CA is recognized.
(...)
This problem goes beyond expired certificates. It is also possible to
edit any existing and valid server certificate by changing the CN
manually. The certificate's signature will be become invalid and OpenSSL
will detect it and return errnum 7 ("Certificate signature failure") but
gajim will not warn and will proceed with the connection anyway...
References:
https://trac.gajim.org/ticket/7252
___
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] Re: EasyPHP 12.1 - Remote code execution of any php/js on local PC
A fix written by some user of EasyPHP has been posted on EasyPHP official forum and also github.com in the meantime: http://www.easyphp.org/forums/read.php?52,151031,151075#msg-151075 https://github.com/relliance/easyphp-codetester-fix The authors of EasyPHP still stay completely quiet about this. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
