Re: [Full-disclosure] Removing seless email addresses (on FD list)
Christian Sciberras uuf6...@gmail.com writes: Can't we somehow limit this? I recall in other newsgroups software, several bounced(reply) emails to a periodic (monthly? bimonthly?) ping would automatically retire the email in question (perhaps after a warning or something such). http://en.wikipedia.org/wiki/Variable_envelope_return_path -- Alan J. Wylie http://www.wylie.me.uk/ ___ 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] Google's robots.txt handling
It is possible to use white listing for robots.txt. Allow what you want google to index and deny everything else. That way google doesn't make you a goole dork target and someone browsing to your robots.txt file doesn't glean any sensitive files or folders. But this will not stop directory bruting to discover your publicly exposed sensitive data, that probably should not be exposed to the web in the first place. I would rather have some one pound on my server to find something, I might have more time to respond, rather than having mr. bad googleing for the weakness in the web site and only making one request to get what they are after. http://www.sans.org/reading_room/whitepapers/awareness/robotstxt_33955 Its not a great paper, but it might have some value for those that have not looked into how this file works. -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Hurgel Bumpf Sent: Monday, December 10, 2012 11:26 AM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Google's robots.txt handling Hi list, i tried to contact google, but as they didn't answer my email, i do forward this to FD. This security feature is not cleary a google vulnerability, but exposes websites informations that are not really intended to be public. (Additionally i have to say that i advocate robots.txt files without sensitive content and working security mechanisms.) Here is an example: An admin has a public webservice running with folders containing sensitive informations. Enter these folders in his robots.txt and protect them from the indexing process of spiders. As he doesn't want the /admin/ gui to appear in the search results he also puts his /admin in the robots text and finaly makes a backup to the folder /backup. Nevertheless these folders arent browsable but they might contain f(a)iles with easy to guess namestructures, non-encrypted authentications (simple AUTH) , you name it... Without a robots.txt nobody would know about the existance of these folders, but as some folders might be linked somewhere, these folders might appear in search results when not defined in the robots.txt The admin finds himself in a catch-22 situation where he seems to prefer the robots.txt file. Long story short. Although google accepts and respects the directives of the robots.txt file, google INDEXES these files. This my concern. http://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+Disallow%3A+%2Fadmin http://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+Disallow%3A+%2Fbackup http://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+Disallow%3A+%2Fpassword As these searches can be used less for targeted attacks, they more can be used to find victims. http://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+%2FDisallow%3A+wp-admin http://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+%2FDisallow%3A+typo3 Just be creative This shouldn't be a discussion about bad practice but the google feature itself. Indexing a file which is used to prevent indexing.. isn't that just paradox and hypocrite? Thanks, Conan the bavarian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ *** This message (including any files transmitted with it) may contain confidential and/or proprietary information, is the property of Interactive Data Corporation and/or its subsidiaries, and is directed only to the addressee(s). If you are not the designated recipient or have reason to believe you received this message in error, please delete this message from your system and notify the sender immediately. An unintended recipient's disclosure, copying, distribution, or use of this message or any attachments is prohibited and may be unlawful. *** ___ 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] Removing seless email addresses (on FD list)
On Tue, Dec 11, 2012 at 11:58:58PM +0100, Christian Sciberras wrote: It is quite annoying to have a volley of bounce mail form non-existent/(re)moved mailboxes. Can't we somehow limit this? I recall in other newsgroups software, several bounced(reply) emails to a periodic (monthly? bimonthly?) ping would automatically retire the email in question (perhaps after a warning or something such). We do. You are seeing the 1% that have odd bounce setups that defeat the automated bounce processing. The fact that the bounce comes to you and not the list will also give you a hint as to why it is hard to catch these :) When time permits I also examine bounces I receive from sending messages like this, the List Charter, etc. This is not a fun task. As a general point, please do not post administrivia to the list unless absolutely necessary - email me directly in the first instance, thanks. Cheers - John ___ 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] Google's robots.txt handling
On 12.12.2012 at 00:23 Lehman, Jim jim.leh...@interactivedata.com wrote: It is possible to use white listing for robots.txt. Allow what you want google to index and deny everything else. That way google doesn't make you a goole dork target and someone browsing to your robots.txt file doesn't glean any sensitive files or folders. But this will not stop directory bruting to discover your publicly exposed sensitive data, that probably should not be exposed to the web in the first place. Maybe I misunderstood something, but do you really think that sensitive can be hidden in secret directories on publicly reachable web servers? -- Christoph Gruber By not reading this email you don't agree you're not in any way affiliated with any government, police, ANTI- Piracy Group, RIAA, MPAA, or any other related group, and that means that you CANNOT read this email. By reading you are not agreeing to these terms and you are violating code 431.322.12 of the Internet Privacy Act signed by Bill Clinton in 1995. (which doesn't exist) ___ 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-2012:179 ] cups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2012:179 http://www.mandriva.com/security/ ___ Package : cups Date: December 12, 2012 Affected: 2011., Enterprise Server 5.0 ___ Problem Description: A vulnerability was discovered and corrected in cups: CUPS 1.4.4, when running in certain Linux distributions such as Debian GNU/Linux, stores the web interface administrator key in /var/run/cups/certs/0 using certain permissions, which allows local users in the lpadmin group to read or write arbitrary files as root by leveraging the web interface (CVE-2012-5519). The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5519 http://www.cups.org/str.php?L4223 ___ Updated Packages: Mandriva Linux 2011: 621faa1bcabbfe6c820f34d323b15ed6 2011/i586/cups-1.4.8-2.2-mdv2011.0.i586.rpm 67c994f6deab1ec43abfc03bc469fde3 2011/i586/cups-common-1.4.8-2.2-mdv2011.0.i586.rpm 0eb1e071e924b8fbcba7782c861d0faa 2011/i586/cups-serial-1.4.8-2.2-mdv2011.0.i586.rpm d82bafdbffa2843e8c87f44ff38f09bd 2011/i586/libcups2-1.4.8-2.2-mdv2011.0.i586.rpm b91e9da16dc9d1dbc69ad8a32c591609 2011/i586/libcups2-devel-1.4.8-2.2-mdv2011.0.i586.rpm 76d0886860017257283b49f07948c8a2 2011/i586/php-cups-1.4.8-2.2-mdv2011.0.i586.rpm 15055e0d0e17ea5189cf29590e535c95 2011/SRPMS/cups-1.4.8-2.2.src.rpm Mandriva Linux 2011/X86_64: 63a3439642483ba8b58964b050440eb7 2011/x86_64/cups-1.4.8-2.2-mdv2011.0.x86_64.rpm 667e8c1b429aa470a25cce5bcaa58a81 2011/x86_64/cups-common-1.4.8-2.2-mdv2011.0.x86_64.rpm 2acfd14c74298e32bca2c2d63f50078b 2011/x86_64/cups-serial-1.4.8-2.2-mdv2011.0.x86_64.rpm 124d5cba345b9f712b123a9e426629a2 2011/x86_64/lib64cups2-1.4.8-2.2-mdv2011.0.x86_64.rpm 4c427f6d8051690096192651701d63cc 2011/x86_64/lib64cups2-devel-1.4.8-2.2-mdv2011.0.x86_64.rpm cf9ef4e6d1e4c5902915e51ab6443778 2011/x86_64/php-cups-1.4.8-2.2-mdv2011.0.x86_64.rpm 15055e0d0e17ea5189cf29590e535c95 2011/SRPMS/cups-1.4.8-2.2.src.rpm Mandriva Enterprise Server 5: 7a7947b4348b46d88771c86d71bf93a8 mes5/i586/cups-1.3.10-0.6mdvmes5.2.i586.rpm 6be2cef2bb36f325fd2f39c382c691b5 mes5/i586/cups-common-1.3.10-0.6mdvmes5.2.i586.rpm 7797b6be2eda38cbe9b02aafdcf4382d mes5/i586/cups-serial-1.3.10-0.6mdvmes5.2.i586.rpm 341ec5bea5633ff702737e0bc41e866a mes5/i586/libcups2-1.3.10-0.6mdvmes5.2.i586.rpm 73c5dedc648f96b4cc596aae5a91d888 mes5/i586/libcups2-devel-1.3.10-0.6mdvmes5.2.i586.rpm f4f93fb5602887b9d89d6f9824170d96 mes5/i586/php-cups-1.3.10-0.6mdvmes5.2.i586.rpm 25d5330e8744ddd498da35eb63d9c423 mes5/SRPMS/cups-1.3.10-0.6mdvmes5.2.src.rpm Mandriva Enterprise Server 5/X86_64: 4245234df94e9a8b3b2b5cea86c84b9f mes5/x86_64/cups-1.3.10-0.6mdvmes5.2.x86_64.rpm ba51ee8a0d66e4241da0728aaabd9ec2 mes5/x86_64/cups-common-1.3.10-0.6mdvmes5.2.x86_64.rpm 5e0b48292098166e884cd4e39b68211e mes5/x86_64/cups-serial-1.3.10-0.6mdvmes5.2.x86_64.rpm b6259d9d194e3f2944ccb691d331109e mes5/x86_64/lib64cups2-1.3.10-0.6mdvmes5.2.x86_64.rpm 9a631b030200ffad1f6765d07b63faad mes5/x86_64/lib64cups2-devel-1.3.10-0.6mdvmes5.2.x86_64.rpm b575b13ff39b05c14922702bec3acfcc mes5/x86_64/php-cups-1.3.10-0.6mdvmes5.2.x86_64.rpm 25d5330e8744ddd498da35eb63d9c423 mes5/SRPMS/cups-1.3.10-0.6mdvmes5.2.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFQyI3wmqjQ0CJFipgRAvI+AJwLllv72jGuBMfZvcrwmtUdioHA3QCdHKOK xlTaJDfD2DO3j2YqWIOaX0Y= =lwFY -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] Network Reconnaissance in IPv6 Networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, We have published a revision of our IETF Internet-Draft entitled Security Implications of IPv6 on IPv4 Networks. This document has now been adopted as a working group item of the IETF opsec working group. The I-D is available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets. At the risk of sounding our own horn, we consider this document a must read about IPv6 network reconnaissance. You can find other documents, slideware, videos, and other materials about IPv6 security at our web site: http://www.si6networks.com And yes, you can follow us on Twitter: @SI6Networks 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) iQIcBAEBAgAGBQJQyR/jAAoJEK4lDVUdTnSSUroP/0SeyLtYlVL2IPwxW8yS7LTd kAv1Pc0rCodBbJUOJyZJ70b/UjAdQPJprPfelAyqbGwvwBKIfA8uxExcOwluFtuW B1D47ApzJixYj/83fCZ3WYjJkCG09RC/V6+SfXxfETPO/yL8Wilj0WmvsTf0DtcM AR5RT0cEj6v2VKa7w34LU9pAPu2xwu4JX7W/7ELYTuJ96BT63eLiLY21d1TGItd1 XLbWIbzbfq3l3O3ppD6L4SUv/vYj9oUQ1y88V7pg1iCfsLgZu8G1FIU2nYsYnvC8 51BJnCjFgFP8BwA3HVoLMRBX/qSu729empDcA50WD5VRxcXz1/nJMEK3Cj0hPAO9 EH9TvFx+6b2FZLfkarCwrBBoHK9ucqJj6VoiRxaKgo61mA8hCQQ8lQzvqpHUmce9 /eydahf9FPCK7YZ+QlgRWOAqljH8JFKtZ5a7gAEC8YTg0MB2l0Iu7MuycICuVS3F jHc8qApiaZyHqOCrxDjCEjAbYdgRsEBEFYGdEyjnyXH/rfoqRKpkZ3yVuyRtO9Vc jDJVN9/f36Cqpm8XlWVePcxUW6XYhV4gPrhNXbcQqttUjAZDKo5AFbmxMCmF/+EZ nVGu+oOaGxy1PlPd6NdzEBL0OdveF9yrxVkQgrhgVXJ6Y0X5DxRF6Pxbm3SY8ncC WTQuhkKKmIIfeOQJXm1Z =J6Sl -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] Network Reconnaissance in IPv6 Networks (errata)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, (My previous email was referencing the wrong document -- the text below has been fixed as appropriate) We have published a revision of our IETF Internet-Draft entitled Network Reconnaissance in IPv6 Networks. This document has now been adopted as a working group item of the IETF opsec working group. The I-D is available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning. At the risk of sounding our own horn, we consider this document a must read about IPv6 network reconnaissance. You can find other documents, slideware, videos, and other materials about IPv6 security at our web site: http://www.si6networks.com And yes, you can follow us on Twitter: @SI6Networks 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) iQIcBAEBAgAGBQJQySF7AAoJEK4lDVUdTnSSCg0QAKz4a6dkv5O6TYAArzCbxXbY KAp5XzWapoc9qNq8z0gQYErncHpYPRIBTqOkKT6IHsBa+1VudoAkSGShVdYIV4rO 0CUIS/skqkoAuATkdtWegzn2UIfSKzTz+JmYBtHDTePX2lUfw0RYbWQc1MML3UzL yP5j8uPCj6EVsLCAAD3qLI2Jlqkv6NuMyDceG21kZR95wqWFBv0hpGM/Kp/3zbls RB2kYtv0hcM6OMnX/JHeSLh76VpCxzY+u4GFtIyrIrRZzrtUBRjdWFNPsEZP71oW nRr/xwthcmSm0qqe7q0pwH1txq4BFthFCshapQncjwi9NQ2ucMGGWG1yFidguveL 2WETkfzs6o1gojveT2bGuc+3kbZOBQP7svOogCTUuopkBoSH/SMmRmKYXZ9NP/Py /SedirfSxoa4ojCEQD8ITsHziws3x+X0ibkC5aSm9P4Q9A09dRCYSHhxnEczbrQa ju4wHlQPyh+cZ4TmKs6D6PrSSzI5hk1B56pCD/gYeHi9cxPbvwL+KWfBzCOSbqMj FLYNElBBmeBLOk0khVKW/oVVJ2MaEdOOC2X5QFBIUv6Z6EqBJavGzuS62KxGmscD MiD8t4C0FoW6042k6SXcEz2n5BP8PgVic3PjXe4ZFWwdGu0fex5fegYlGEAYniqh 8/g8fNArB1kSkY5pGZDC =WFsd -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] Google's robots.txt handling
I wouldn't consider this an issue. If Google didn't do this, someone else would have (e.g. my rather old http://www.aushack.com/robanukah/ does it but I never bothered to index the web at large). I believe it was suggested to Shodan and others, so it was only a matter of time. If anything, Google is raising awareness by including it in their results (which I noticed cropped up about 6 months (?) ago). It is also worth noting that some organisations (and some security appliances) use it for bait. E.g. robots.txt = Disallow: /database.bak and as soon as a request is seen the IP is blacklisted permanently, because their behaviour either means that a spider is disobeying robots, or more than likely it is a human poking around where they shouldn't be. Should Google index it? Probably not - but then you're back to point #1, if they didn't someone else would have - and Google does a better job at it, so by all means... Interestingly, Google indexes their own sites https://www.google.com/search?q=inurl:robots.txt+filetype%3Atxt+site%3Agoogle.com. At least they're not playing double standards. My only questions is *why* did they suddenly decide to include this? I'd hazard a guess that they released new improved indexing code, and this was a by-product of their improvement (perhaps related to the TXT file-type?). -Patrick ___ 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] RVAsec 2013 CFP Now Open
What: RVAsec 2013 When: May 30 – June 1, 2013 Where: Richmond, Virginia CFP Deadline: February 4th, 2013 at 11:59 PM Eastern Info: http://rvasec.com/ RVAsec is a Richmond, VA based security convention that brings top industry speakers to the midatlantic region. In its first year, RVAsec 2012 attracted 175 security professionals from across the country. For 2013, the conference is expanding to a two day and dual-track format, with a mixed focus on technical and management/business presentations. All talks must be 55 minutes in length, and submissions will need to select from one of two tracks: - Business - Technical Speaker Perks - Free admission to RVAsec - Invitation to the RVAsec speaker party - RVAsec T-shirt, badge attendee swag bag - One 50% off pass for a friend or co-worker - Fame and glory, internet style! - Opportunity to be the recipient of the RVAsec “STFU” sign RVAsec has a limited travel budget, but speakers who request travel assistance may be eligible for: - Travel allotment up to $300 - 3 nights hotel at the Crowne Plaza Richmond Downtown Please note that companies that fund their speaker’s travel will receive a free Associate Sponsorship Level. For more information submission guidelines: http://rvasec.com/2013-cfp/ -- http://www.cirt.net | http://rvasec.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/
