[Full-disclosure] New Blog Post: Attacking the Windows 7/8 Address Space Randomization
Hello List, Below is a link to my new Blog Post, http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/ I hope you enjoy it! Kingcope ___ 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] CVE ID Syntax Change - Call for Public Feedback
CVE ID Syntax Change - Call for Public Feedback --- January 22, 2013 Due to the increasing volume of public vulnerability reports, the Common Vulnerabilities and Exposures (CVE) project will change the syntax of its standard vulnerability identifiers so that CVE can track more than 10,000 vulnerabilities in a single year. The current syntax, CVE--, only supports a maximum of 9,999 unique identifiers per year. Since a change in the ID syntax will affect many parties including end users and vendors, the CVE project is soliciting feedback from the public before making this change. The public feedback period will continue through the RSA Conference in February 2013, where attendees will be able to speak with CVE personnel from MITRE and members of the CVE Editorial Board. After a formal Editorial Board vote, the final selection will be made and the public will be notified, probably in March 2013. The syntax change is scheduled to go into effect on January 1, 2014, so that people will have enough time to change their processes and software to handle the new ID syntax. With guidance from the CVE Editorial Board, we have identified three options for a new ID syntax, summarized as follows: *) Option A (Year + 6 digits, with leading 0's) Examples: CVE-2014-01, CVE-2014-00, CVE-2014-123456 *) Option B (Year + arbitrary digits, no leading 0's except IDs 1 to 999) Examples: CVE-2014-0001, CVE-2014-54321, CVE-2014-123456 *) Option C (Year + arbitrary digits + check digit) Examples: CVE-2014-1-8, CVE-2014--3, CVE-2014-123456-5 One of these options will be selected as the new syntax for CVE identifiers. More details are available at the end of this message. If you wish to comment on any of these options, you can: *) Email your commeent to to cve-id-cha...@mitre.org, which is monitored by CVE team members at MITRE. *) Post to a new, public discussion list that is focused on the CVE ID change. To subscribe, send email to lists...@lists.mitre.org . In the body of the email, type: subscribe CVE-ID-SYNTAX-DISCUSS-LIST *) Reply on any of the public mailing lists to which this announcement has been posted. Due to the high volume of replies that we expect to receive, we will not be able to respond to every email message; however, we will publish a summary of responses. Thank you to the entire community for supporting CVE, and we look forward to your feedback. Regards, The CVE Project Option A: Year + 6 digits, with leading 0's Example identifiers: CVE-2014-01, CVE-2014-000999, CVE-2014-001234, CVE-2014-00, CVE-2014-01, CVE-2014-054321, CVE-2014-09, CVE-2014-10, CVE-2014-123456, CVE-2014-99 Strengths: This CVE ID syntax will seem familiar to consumers who are used to the old-style syntax from 1999 through 2013, since there are 6 digits instead of 4. This might make adoption easier and minimize confusion. The syntax would avoid some ID parsing problems that could occur with the other schemes, such as inadvertent truncation or fixed-length assumptions that would cause the wrong ID to be extracted. It would also support the use of multiple consecutive IDs that can be easily sorted and displayed without special logic. The fixed length might be a desirable property to some consumers or CVE-processing implementers; the other options have variable-length IDs. Some CVE-processing software that automatically extracts or publishes CVE identifiers might not need to be changed, if it already assumes that more than 4 digits could be used. There will be enough IDs to support up to 1 million vulnerabilities per year. This is effectively future-proof for CVE, because CVE's scope is expected to remain largely restricted to vulnerabilities that have been analyzed by humans. If more than 1 million IDs are required, this would represent such a large paradigm shift in vulnerability disclosure and tracking that the entire industry would not be able to manage the volume using today's practices. Limitations: Immediately upon the first publication of an ID using this syntax, many CVE programs that assume the old-style syntax would stop functioning correctly. The larger number of digits could increase the risk of typos, especially with the leading zeroes. Some consumers might intentionally remove leading zeroes, assuming the old-style 4-digit number. - Option B: Year + arbitrary digits, no leading 0's except IDs 1 to 999 - Note: in this option, extra digits would not be added until at least 10,000 IDs are needed. When necessary, only one additional digit is added. For IDs 1
[Full-disclosure] CVE-2013-1393
# # # COMPASS SECURITY ADVISORY http://www.csnc.ch/ # # # # CVE ID : CVE-2013-1393 # CSNC ID: CSNC-2013-002 # Product: Drupal CurvyCorners # Vendor: Drupal # Subject: Cross-site Scripting - XSS # Risk:High # Effect: Remotely exploitable # Author: Stephan Rickauer (stephan.rickauer _at_ csnc.ch) # Date:January 23rd 2013 # # Introduction: - Compass Security discovered a web application security flaw in the CurvyCorners module of the Drupal CMS. Vulnerable: --- All CurvyCorners 6.x-1.x versions. All CurvyCorners 7.x-1.x versions. Not vulnerable: --- unknown Fix/Patches: If you use the CurvyCorners module, uninstall the module - there is no patch available to fix this issue. The module is no longer supported. Description: The CurvyCorners module enables you to create rounded corners on HTML block elements. The module doesn't sufficiently filter user entered text when being displayed. This vulnerability is mitigated by the fact that an attacker must have a role with the permission administer curvycorners. Exploiting this vulnerability will lead to so-called cross-site scripting (XSS) and allows the impersonation of logged-in Drupal users. Milestones: --- December 14th 2012 Vulnerability discovered December 14th 2012 Vendor contact established December 14th 2012 Vendor acknowledged issue January 17th 2013 CVE ID assigned by MITRE January 23rd 2013 Public release of advisory by vendor References: --- XSS reference: http://en.wikipedia.org/wiki/Cross-site_scripting Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Recently, vulnerabilities of this kind have been exploited to craft powerful phishing attacks and browser exploits. Drupal SA-CONTRIB-2013-008: http://drupal.org/node/1896718 ___ 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] IPv6: How to avoid security issues with VPN leaks on dual-stack networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, Techtarget has just published an article I've authored for them, entitled How to avoid security issues with VPN leaks on dual-stack networks. The article is available at: http://searchsecurity.techtarget.com/tip/How-to-avoid-security-issues-with-VPN-leaks-on-dual-stack-networks (Note: There are some banners (?) intermixed... but the whole article can be viewed without registration... just keep scrolling down!9 Its Abstract is: - cut here The imminent exhaustion of freely available IPv4 addresses has, over a number of years, led to the incorporation of IPv6 support by most general-purpose operating systems. However, many applications, such as VPN client and server software, have been lagging behind to become IPv6-ready. This results in scenarios in which dual-stacked hosts employ IPv6-unaware VPN software, thus opening the door to security vulnerabilities, such as VPN traffic leaks. In this tip, we'll discuss how these VPN security issues arise and the various mitigation options available for containing VPN traffic leaks. - cut here P.S.: Any comments will be welcome. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRARJhAAoJEK4lDVUdTnSS8WUQAIqZ7hw4LZxEafwStMHaKBi0 /xa3WJH/tbwpzuZrMkNwo6fyfUIaJuQnjIT0HNnYWpRIO/uj/EgRK/dRp40x3ad8 mz+4iaS/dKRMnF1n1APtAkqrhoWMATh8KB7KeZRDdPL7t+JXKwrA9O8uQln95bN+ shUig9oGtFTZX6k8F1x+LjtU/i6OOr5zwoJxwQiW2OBx+w5srFRH2nBokvusWKsb upIVinOn0HEVfYRYWCYlvGy9m6Q3qlaXT4E98bjI0RlwIgXsGDtdkENkrvBxu7ot My9Z7WY5NNZqrOdCZb2N1gXl6KMPhP7SZUQTcCia0n3vmvkDpGIsW+3SPwSPJx8q d+BxR+UwKI9X7zdHJEQSPbgafrEmrpqWuNiOLG6tgh9rt8BuTqQzIg59nmPHzw8z KtleAMSR8DSEt3ykbuq0DBJXc0dV1iAyWbhpWqzzcufRrmZrJq6BfSuK7LStpMLq g8QDhiSQErd/T4v8eeFe8UElQCj2VTsGDUURNQ0NlZGAuHwmZ44F6AzQs+8w/cXm y2a0sOw/O+sxhbIaB+Bxg4UDa5oqSbv4GH9YVMPDj5z3NrxJqVbE1/8haRMrVQwG zNIamZ0HB78wN9ZUJsrG4bqBF3+JYAGk0qHdhpDt/+O90xIBySusVsj6dzSEn3sE UosnX2qHWbM0FaKOoV3B =MtBC -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] SEC Consult SA-20130124-0 :: Critical SSH Backdoor in multiple Barracuda Networks Products
SEC Consult Vulnerability Lab Security Advisory 20130124-0 === title: Critical SSH Backdoor in multiple Barracuda Networks Products vulnerable products: Barracuda Spam and Virus Firewall Barracuda Web Filter Barracuda Message Archiver Barracuda Web Application Firewall Barracuda Link Balancer Barracuda Load Balancer Barracuda SSL VPN (all including their respective virtual Vx versions) vulnerable version: all versions Security Definition 2.0.5 fixed version: Security Definition 2.0.5 impact: Critical homepage: https://www.barracudanetworks.com/ found: 2012-11-20 by: S. Viehböck SEC Consult Vulnerability Lab https://www.sec-consult.com === Vendor/product description: - URL: https://www.barracudanetworks.com/products/ Vulnerability overview/description: --- 1) Backdoor accounts Several undocumented operating system user accounts exist on the appliance. They can be used to gain access to the appliance via the terminal but also via SSH. (see 2) These accounts are undocumented and can _not_ be disabled! 2) Remote access via SSH An SSH daemon runs on the appliance, but network filtering (iptables) is used to only allow access from whitelisted IP ranges (private and public). The public ranges include servers run by Barracuda Networks Inc. but also servers from other, unaffiliated entities - all of whom can access SSH on all affected Barracuda Networks appliances exposed to the Internet. The backdoor accounts from 1) can be used to gain shell access. This functionality is entirely undocumented and can only be disabled via a hidden 'expert options' dialog (see Workaround). Proof of concept: - URLs and other exploit code (passwords) have been removed from this advisory. A detailed advisory will be released within a month including the omitted information. 1) Backdoor accounts The passwd and shadow file show that the following accounts exist. Some passwords could be recovered (short attack with tiny wordlist): root:x:0:0:root:/root:/bin/bash -- UID: 0! hash removed NOT CRACKED during given time (confirmed static in tested appliances) build:x:0:0:Build User:/root:/boot/os_tools/clone_interactive.pl -- UID: 0! hash removed NOT CRACKED during given time shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown -h now hash removed CRACKED password removed product:x:700:100::/home/product:/bin/bash hash removed CRACKED password removed ca:x:704:65534:ACL reset user:/home/ca:/home/emailswitch/code/firmware/current/bin/clear_acls.sh hash removed CRACKED password removed support:x:705:705::/home/support:/home/product/code/firmware/current/bin/request_support.pl hash removed CRACKED password removed websupport:x:706:706::/home/websupport:/home/emailswitch/code/firmware/current/bin/request_web.pl hash removed CRACKED password removed qa_test:x:707:707::/home/qa_test:/root/qa_test1.pl hash removed NOT CRACKED during given time The following users have public keys added to their authorized_keys file: remote:x:0:0:Remote Access:/home/remote:/bin/bash -- UID: 0! # cat /home/remote/.ssh/authorized_keys2 ssh-dss B3NzaC1kc3MAAACBAM3angjOeIjCePKw8a/zTugPKK+hoYkpQhyXY8+BN q14nCInlcrzhavCiQCVKNTVtpW0A2hs75/QGslwrTpulsX89ZQL0Wx915iNbaf0P5sXoU rA0iPoPoL3nIXWskjc6xj+x66svIVHxiBYpnTSaBNaJhxU5/3eK+/3sSPrAR0NFQD u09YU0d2eG63v+zHmSIKCMZ8vnwAAAIAPaB34rhWjIRE5hz6YxU8jeEnPZPr3ZX8hbshk asrrcQG+L0UeTGKoL7JTYQ2vu/549xXBpheiTAKunYES6RwURziz11vq6oWix3Wo6GGOb yS53MIbyyc4DrB4zLDUI4PJFLBxwKTOBOSU7OuCH7sQ6rzaMrsDZIf6GxeTrDIN1gAAAI AlkA1hEFFmRh7SfOkN4oGFcvZl/71PTEXnK3HZZopYW5WIqueTl6NALiq6FobY+U8b/NQ ibvXXEinLP6dgqd/xnYYhwoUMuP5GPDhUkl+xKoBjAd+33yT4AN1ymWx/LZZ+9uQXt08k Q3sgpXBhW6YT+rqrJLgc9l3Y2/exVGJjYA== manager@support01.barracudanetwo rks.com cluster:x:1000:1000::/home/cluster:/bin/bash # cat /home/cluster/.ssh/authorized_keys2 ssh-dss B3NzaC1kc3MAAACBAJ5O8UhVP3lb0Mff66uHMkvcZlxPJF/7pgtcq5Qd/ 7cuwqv65/BiDU2oNOWAIfaO89K+kLvrt+VY3TdemTrcRGiTZfzXeRASB9wWVI7rPPsIYs S47lBEp7PYJANWXd6rYgfTw3fr1PYHpUBDgxOcHshmL469lDDbx6CodrwgK4e/FQD a/pjlqnKmBtWNqBXB89J3qhb06QAAAIAiQCodsX5QqA8TBP6scOYIckkHiUbIireamxVa U587P7uthFiMVnKrj9MTzwgFebTQQ02B9LQpXfmMdQdZi2Hb8FCwP1cuxp0yAHKqYh3ss hCzhDq2lrw1NrAVlrkp4dqj0lvwEUp3BYf9VnveylrfiHA45hyXdXdzfxdn7/CDQQAAAI AOtKcLIsZ30Y4HG0Qk4cYqKw8QryvS36xbvywX7Tq8/7N5D0LrjaCzBYo8cBIBxHjpePT D7pOSgUiuXk16y8ffTYzLexSqL0wFLV5GIIxAeXhtCtIUPVXRZzTm97NiErikbfjDRx0P PZKcOH8A1LX4Y0nLoBbnNnPvhcIXfElkow== At least the user product can be used to login and get a shell on the appliance. It was confirmed that this user can access
[Full-disclosure] SEC Consult SA-20130124-1 :: Authentication bypass in Barracuda SSL VPN
SEC Consult Vulnerability Lab Security Advisory 20130124-1 === title: Unauthenticated setting of Java System Properties authentication bypass product: Barracuda SSL VPN vulnerable version: Security Definition 2.0.5 fixed version: Security Definition 2.0.5 impact: Critical homepage: https://www.barracudanetworks.com/ found: 2013-01-06 by: S. Viehböck SEC Consult Vulnerability Lab https://www.sec-consult.com === Vendor/product description: - Securely connecting remote users to files, applications, and secure sites - residing behind the firewall - is vital for worker mobility as well as for business continuity and data loss prevention (DLP). The Barracuda SSL VPN is a powerful plug-and-play appliance purpose-built to provide remote users with secure access to internal network resources. It does this while giving administrators unrivaled insight and tools for managing remote network access. URL: https://www.barracudanetworks.com/products/sslvpn Vulnerability overview/description: --- 1) Unauthenticated setting of Java system properties Unauthenticated users can set an arbitrary Java system property to an arbitrary value. Among other attacks (eg. DoS), this allows an attacker to break the applications security mechanisms. (see 2) 2) Unauthenticated access to critical functions The vulnerability in 1) can be used to bypass access restrictions in order to get access to the 'API' functionality. This enables an unauthenticated attacker to download configuration files and database dumps. Furthermore the system can be shutdown and new admin passwords can be set using this functionality without prior authentication! Proof of concept: - URLs and other exploit code have been removed from this advisory. A detailed advisory will be released within a month including the omitted information. 1) Unauthenticated setting of Java system properties The following request sets the system property 'foo' to the value 'bar': URL removed Affected script: setSysProp.jsp 2) Unauthenticated access to critical functions The following requests disable access restrictions for the 'API' functionality: URLs removed Affected script: setSysProp.jsp Then full API access is available without prior authentication. Interesting functions are for instance: * ConfDump URL removed Full dump of the /home/bvs/code/firmware/current/sslexplorer/conf/ directory. * SqlDump URL removed Full dumps of databases. valid options are: config, explorer_auditing, explorer_configuration and explorer_local. Note: this function is vulnerable to local file disclosure too URL removed * Shutdown URL removed Shutdown/restart of appliance. * SetSuperUserPassword Allows setting the passwords of users in the superuser group. URL removed Vulnerable / tested versions: - The vulnerability has been verified to exist in Barracuda SSL VPN version 2.2.2.203, which was the most recent version at the time of discovery. Vendor contact timeline: 2013-01-10: Sending advisory and proof of concept exploit via encrypted channel. 2013-01-14: Vendor confirms receipt and provides BNSEC IDs. 2013-01-14: Vendor sends listing of reported vulnerabilities and release schedule. 2013-01-21: Conference call - discussing implemented solutions. 2013-01-23: Barracuda Networks releases alert secdef 2013-01-24: SEC Consult releases coordinated security advisory. Solution: - Update to Security Definition 2.0.5. Workaround: --- No workaround available. Advisory URL: -- https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm ~~~ SEC Consult Unternehmensberatung GmbH Office Vienna Mooslackengasse 17 A-1190 Vienna Austria Tel.: +43 / 1 / 890 30 43 - 0 Fax.: +43 / 1 / 890 30 43 - 25 Mail: research at sec-consult dot com www.sec-consult.com EOF S. Viehböck / @2013 ___ 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 22 Jan 2013 08:32:11 + Benji m...@b3nji.com wrote: Someone please explain to me why he had to run a vulnerability scanner to check one vulnerability, and again, how are we still arguing about this? Whether you think he had a 'right' to test this or not, he was either too dumb or too naive to know it was against the law. I do not think the issue is whether or not he broke the law; rather, the issue is whether or not the law serves the people's interest. I am not a Canadian, so maybe I do not really have a say, but given that this kid did not cause any measurable damage, it seems hard to make the case that he should have been punished for his actions. Throwing a student out of school because he used a pen-testing tool is more damaging to the school and to society as a whole than what the student actually did. There is also the matter of the school itself. They were presented with a student who had found a vulnerability, reported it, and then checked to see if there were still problems. Does expulsion really sound like a reasonable punishment to you? Does any punishment seem in order, given that the student made no attempt to maliciously exploit his discoveries? It seems to me that a much better approach would have been to offer the student a chance to present the vulnerability in a computer security class. The school's mission is, theoretically, to teach its students -- why, then, would they remove from the student body someone who could do just that? Sure, maybe the school has a policy of expulsion for any student who breaks the law -- but why would the school expel a student preemptively, before he was even found guilty by a court (or even charged with a crime)? If he had been arrested, it would have made sense for the school to put him on academic suspension until the conclusion of his criminal case, at which point a guilty verdict might mean expulsion. - -- Ben - -- Benjamin R Kreuter UVA Computer Science brk...@virginia.edu KK4FJZ - -- If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them. - George Orwell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBCgAGBQJRAVBTAAoJEOV0+MnZK9ijzUsP/i6XrD9ruCG/IJEaV7wlAmqm 9/QTXIjQ0HbMdVWfc1PhK4OHeHuGOOuKRMlr6OXl6DGCxn0I1LFkeu624MVRNZyW WhgMFi0tzMBozMyQEElcaQjK5dEnWOBGVUPvfkjnhhA+I4agqoRB2ocqWDPuN6Lq 7DixO1sqWgPksTwhaOPB1XnHKs9naqXKH2aTyS093VOm4FQyWSPASJq+MV93YiUP lkYkbwULnCdnXcUG++FLPZcLxf8ZGb48zlWWcnqowmaHYqm5DqLeGFrFF8wsyWho nK9vdCmPCc/yblRDe+HgjYgVS6zti838YD1IzX2taEGn2Ottbuo4jhmYOdviUM2D 52iKhbrdALy+08d13dM1+E4DMJjL82UGxZwgq5QOwnaUTpkqM/yGVjgNmpna/5LE zBOTkre4p8mgm/77jiFcfyD+gv16CmqsgwytcAqPxFYbOkHkY4WchPkGLccm20kV WTBEzRStOR1I0hi9xUqfiZMgRPIQfEsRsmxFiGUtXjnXhwEM6IJjz06SQ4B1103q iAZNHa/zXZuQl9cG/Ef3Szzc1JOWgR6YZb+tGTrDvtObKZXSpp7MvsyVtilcjHsE klq1HwXsdqXNeHFC9Zr1f+PTLkkpuYLOklhPFuVI+2kUs0ZfQUbFy2JlrvJeioFy nRO0oCbGKhg6Row344Iu =P/Ts -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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
The real funny part is where 15 teachers voted .. you mean there are 15 teachers at Dawson that understand the implications of a pen test tool? I am in Montreal and I know Dawson, they are usually much saner than that! Let's see if they now have the guts to do a Mea Culpa and fix this injustice. Gary Baribault Courriel: g...@baribault.net GPG Key: 0x685430d1 Signature: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 On 01/24/2013 10:16 AM, Benjamin Kreuter wrote: On Tue, 22 Jan 2013 08:32:11 + Benji m...@b3nji.com wrote: Someone please explain to me why he had to run a vulnerability scanner to check one vulnerability, and again, how are we still arguing about this? Whether you think he had a 'right' to test this or not, he was either too dumb or too naive to know it was against the law. I do not think the issue is whether or not he broke the law; rather, the issue is whether or not the law serves the people's interest. I am not a Canadian, so maybe I do not really have a say, but given that this kid did not cause any measurable damage, it seems hard to make the case that he should have been punished for his actions. Throwing a student out of school because he used a pen-testing tool is more damaging to the school and to society as a whole than what the student actually did. There is also the matter of the school itself. They were presented with a student who had found a vulnerability, reported it, and then checked to see if there were still problems. Does expulsion really sound like a reasonable punishment to you? Does any punishment seem in order, given that the student made no attempt to maliciously exploit his discoveries? It seems to me that a much better approach would have been to offer the student a chance to present the vulnerability in a computer security class. The school's mission is, theoretically, to teach its students -- why, then, would they remove from the student body someone who could do just that? Sure, maybe the school has a policy of expulsion for any student who breaks the law -- but why would the school expel a student preemptively, before he was even found guilty by a court (or even charged with a crime)? If he had been arrested, it would have made sense for the school to put him on academic suspension until the conclusion of his criminal case, at which point a guilty verdict might mean expulsion. -- Ben ___ 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
yeah, this is why most banks sucks: they won't let me try to break in, even if I have my money there and only doing it for making sure that it is secure. I promise I wouldn't touch anything else. On Tue, Jan 22, 2013 at 3:08 AM, Sanguinarious Rose sanguiner...@occultusterra.com wrote: And that is the reason why no one wants to report anything they find, it's because of people like you and your kind of thinking. Did they public post all the private information? No Did they try to use it for malious or illicit purposes? No Did they report it when they found it? Yes A horrible moral compass indeed! Arrest these people for being concerned and reporting it after stumbling upon security flaws! Amiright? On Mon, Jan 21, 2013 at 8:06 PM, Nick FitzGerald n...@virus-l.demon.co.uk wrote: Jeffrey Walton wrote: On Mon, Jan 21, 2013 at 5:42 PM, Philip Whitehouse phi...@whiuk.com wrote: Moreover, he ran it again after reporting it to see if it was still there. Essentially he's doing an unauthorised pen test having alerted them that he'd done one already. If his personal information is in the proprietary system, I believe he has every right to very the security of the system. BUT how can he verify (I assume that was the word you meant?) proper security of _his_ personal details? He would have to test using someone _else's_ access credentials. That is unauthorized access by most relevant legislation in most jurisdictions. Alternately, he could try accessing someone else's data from his login, and that is equally clearly unauthorized access. He and his colleague who originally discovered the flaw may have used each other's access credentials to access their own data, or used their own credentials to access the other's data _in agreement between themselves_ BUT in so doing most likely broke the terms of service of the system/their school/etc, _equally_ putting them afoul of most unauthorized access legislation. Is he allowed to opt-out of the system (probably not)? If not, he has a responsibility to check. BUT he has no resposibility to check on anyone _else's_ data and no _authority_ to use anyone else's credentials to check on his own. So, what responsibility does he really have? It sounds like he should have left well alone once he had reported this to the university and the vendors. That he did not have the sense or moral compass to recognize that tells us something important about him. 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/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu ___ 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
On Thu, 24 Jan 2013 10:16:29 -0500, Benjamin Kreuter said: There is also the matter of the school itself. They were presented with a student who had found a vulnerability, reported it, and then checked to see if there were still problems. Does expulsion really sound like a reasonable punishment to you? Does any punishment seem in order, given that the student made no attempt to maliciously exploit his discoveries? It seems to me that a much better approach would have been to offer the student a chance to present the vulnerability in a computer security class. The school's mission is, theoretically, to teach its students -- why, then, would they remove from the student body someone who could do just that? I've seen reference to a few more details on this - namely: 1) The kid, as part of his major, signed an ethics document. 2) He was either told or agreed to not run the scanner again. 3) He did so anyhow. and that he didn't get kicked out because he ran the scanner, but because he did so *in violation of the ethics standard*. I'll probably have to go back and find references for all that - but even without that, it's something to think about. If somebody agrees not to do something, and then does it anyhow, is he *trustworthy* enough for a degree in that field? pgp9c8S3qSviZ.pgp Description: 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
@Valdis, your correct. He was expelled for other reasons. Despite receiving clear directives not to, he attempted repeatedly to intrude into areas of College information systems that had no relation with student information systems. These actions and behaviours breach the *code of professional conducthttp://www.dawsoncollege.qc.ca/public/72b18975-8251-444e-8af8-224b7df11fb7/info_desk/420a0_-_professional_conduct.pdf * for Computer Science students, a serious breach that requires the College to act. /pd On Thu, Jan 24, 2013 at 12:34 PM, valdis.kletni...@vt.edu wrote: On Thu, 24 Jan 2013 10:16:29 -0500, Benjamin Kreuter said: There is also the matter of the school itself. They were presented with a student who had found a vulnerability, reported it, and then checked to see if there were still problems. Does expulsion really sound like a reasonable punishment to you? Does any punishment seem in order, given that the student made no attempt to maliciously exploit his discoveries? It seems to me that a much better approach would have been to offer the student a chance to present the vulnerability in a computer security class. The school's mission is, theoretically, to teach its students -- why, then, would they remove from the student body someone who could do just that? I've seen reference to a few more details on this - namely: 1) The kid, as part of his major, signed an ethics document. 2) He was either told or agreed to not run the scanner again. 3) He did so anyhow. and that he didn't get kicked out because he ran the scanner, but because he did so *in violation of the ethics standard*. I'll probably have to go back and find references for all that - but even without that, it's something to think about. If somebody agrees not to do something, and then does it anyhow, is he *trustworthy* enough for a degree in that field? ___ 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
Hello, Am 24. Januar schrieb valdis.kletni...@vt.edu: I've seen reference to a few more details on this - namely: 1) The kid, as part of his major, signed an ethics document. 2) He was either told or agreed to not run the scanner again. 3) He did so anyhow. A better solution would have been to not do the steps 1 and 2 but make an NDA (Ok, we know and you know but that's enough by now.) instead. I mean, some kind of responsible disclosure. By proposing this ethics document it was the college being unprofessional and not the kid. Kind regards Stefan -- make -it ./work GnuPG-Key: B96CF8D2 s...@tanis.toppoint.de Fingerprint: D8AC D5E7 6865 19B1 385F 8850 2AB7 6A82 B96C F8D2 signature.asc Description: Digital 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
On Thu, 24 Jan 2013 19:59:53 +0100, Stefan Weimar said: 1) The kid, as part of his major, signed an ethics document. A better solution would have been to not do the steps 1 and 2 but make an NDA (Ok, we know and you know but that's enough by now.) instead. I mean, some kind of responsible disclosure. By proposing this ethics document it was the college being unprofessional and not the kid. I think you misunderstand - the ethics document was signed *when he applied as a student. If you think that's unprofessional, you might want to consider that doctors, lawyers, and other professions have ethics standards as well. As does anybody who has a CISSP: https://www.isc2.org/ethics/default.aspx I'd say anybody who persisted in doing something after they promised not to would be running afoul of the necessary public trust and confidence clause of the CISSP code of ethics? pgpGXtSgvS14j.pgp Description: 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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
On Thu, Jan 24, 2013 at 2:22 PM, valdis.kletni...@vt.edu wrote: On Thu, 24 Jan 2013 19:59:53 +0100, Stefan Weimar said: 1) The kid, as part of his major, signed an ethics document. A better solution would have been to not do the steps 1 and 2 but make an NDA (Ok, we know and you know but that's enough by now.) instead. I mean, some kind of responsible disclosure. By proposing this ethics document it was the college being unprofessional and not the kid. I think you misunderstand - the ethics document was signed *when he applied as a student. If you think that's unprofessional, you might want to consider that doctors, lawyers, and other professions have ethics standards as well. As does anybody who has a CISSP: That has not stopped lawyers and judges from perverting the legal system in the US. Judge James Ware FTW! http://en.wikipedia.org/wiki/James_Ware_(judge). https://www.isc2.org/ethics/default.aspx TLDR; Just kidding. Its actually quite short. I wonder of the college gave him a contract, and called it a code of ethics. I'd say anybody who persisted in doing something after they promised not to would be running afoul of the necessary public trust and confidence clause of the CISSP code of ethics? Well, there could be a lot of wiggle room. How much of it is subjective? Is it like Christianity, where the 10 Commandments are taken as 10 Suggestions? Jeff ___ 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 2612-1] ircd-ratbox security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2612-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff January 24, 2013 http://www.debian.org/security/faq - - Package: ircd-ratbox Vulnerability : programming error Problem type : remote Debian-specific: no CVE ID : CVE-2012-6084 It was discovered that a bug in the server capability negotiation code of ircd-ratbox could result in denial of service. For the stable distribution (squeeze), this problem has been fixed in version 3.0.6.dfsg-2squeeze1. For the testing distribution (wheezy), this problem has been fixed in version 3.0.7.dfsg-3. For the unstable distribution (sid), this problem has been fixed in version 3.0.7.dfsg-3. We recommend that you upgrade your ircd-ratbox 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.12 (GNU/Linux) iEYEARECAAYFAlEBqQcACgkQXm3vHE4uylqiNQCeMoOg3cwLxuUxFMx4if6HRZ5n Q1UAoIZ5vDAHxoyDGAx2oY2q++Dc4qNV =O+2l -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] Student expelled from Montreal college after finding vulnerability that compromised security of 250, 000
Hi Valid, Am 24. Januar schrieb valdis.kletni...@vt.edu: I think you misunderstand - the ethics document was signed *when he applied as a student. Ah, ok. It's a different story then. I'd say anybody who persisted in doing something after they promised not to would be running afoul of the necessary public trust and confidence clause of the CISSP code of ethics? Yes, you're absolutely right. Kind regards Stefan -- make -it ./work GnuPG-Key: B96CF8D2 s...@tanis.toppoint.de Fingerprint: D8AC D5E7 6865 19B1 385F 8850 2AB7 6A82 B96C F8D2 signature.asc Description: Digital 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/
