Re: [Full-Disclosure] Writing Trojans that bypass Windows XP Service Pack 2 Firewall
Sometimes too much truth hurts. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [SECURITY] [DSA 568-1] New cyrus-sasl-mit packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 568-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze October 16th, 2004 http://www.debian.org/security/faq - -- Package: cyrus-sasl-mit Vulnerability : unsanitised input Problem-Type : local Debian-specific: no CVE ID : CAN-2004-0884 Debian Bug : 275498 A vulnerability has been discovered in the Cyrus implementation of the SASL library, the Simple Authentication and Security Layer, a method for adding authentication support to connection-based protocols. The library honors the environment variable SASL_PATH blindly, which allows a local user to link against a malicious library to run arbitrary code with the privileges of a setuid or setgid application. The MIT version of the Cyrus implementation of the SASL library provides bindings against MIT GSSAPI and MIT Kerberos4. For the stable distribution (woody) this problem has been fixed in version 1.5.24-15woody3. For the unstable distribution (sid) this problem will be fixed soon. We recommend that you upgrade your libsasl 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/c/cyrus-sasl-mit/cyrus-sasl-mit_1.5.24-15woody3.dsc Size/MD5 checksum: 737 c28b9688bbb9de9f920594ba8ac2b9d5 http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/cyrus-sasl-mit_1.5.24-15woody3.diff.gz Size/MD5 checksum: 125280 324fed374135082dce487d78f46db72f http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/cyrus-sasl-mit_1.5.24.orig.tar.gz Size/MD5 checksum: 494457 ac3837c071c258b80021325936db2583 Alpha architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_alpha.deb Size/MD5 checksum:38780 daa298d1425c5381e5d223c04fd16312 http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_alpha.deb Size/MD5 checksum:30282 d6b4f4eb7a96a320094ea8ff698a68bd ARM architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_arm.deb Size/MD5 checksum:37270 85d60315293f4115f5b8469262a8e839 http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_arm.deb Size/MD5 checksum:28368 834ab3c7b7db63e7b6420986ecbcfe02 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_i386.deb Size/MD5 checksum:37012 0a70a5abb8a75f9407a492f7342360be http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_i386.deb Size/MD5 checksum:28188 8e472ccc4076d9ce7596363e53c4401f Intel IA-64 architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_ia64.deb Size/MD5 checksum:41274 fa2ef8e398ca8c1cf733ea86f017a8ea http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_ia64.deb Size/MD5 checksum:32360 4933dc10dcc21dd22968a7eb9ecee6a7 HP Precision architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_hppa.deb Size/MD5 checksum:38502 07c04f8e1709650cfc8a9dcf06dcca82 http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_hppa.deb Size/MD5 checksum:29204 fa6282350f600ab5aacc0cdc9c1ee808 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_m68k.deb Size/MD5 checksum:36788 bad1e3f4176662fba63453703e211257 http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-krb4-mit_1.5.24-15woody3_m68k.deb Size/MD5 checksum:27630 628baec08c7e6a80aff4488a51f02cad Big endian MIPS architecture: http://security.debian.org/pool/updates/main/c/cyrus-sasl-mit/libsasl-gssapi-mit_1.5.24-15woody3_mips.deb Size/MD5 checksum:37782 c2f35e650480997a46e5b4c1cc296e7e
[Full-Disclosure] Re: Any update on SSH brute force attempts?
Hola a Colombia, Fabio! y Cc: al listo - Personal aside (others read on below please), Many years ago, my father used to travel there (and many other places in South and Central America) on business. My travels have been fairly wide, but have not yet taken me to your country. Some day! It's a good idea to instrument SSHD to log cleartext passwords for failed login attempts. I don't have time to write the code myself, but if someone else has it, I'll consider using it for a while. Anyone? Here is the list of non-existent users attempted: account adam admin alan backup cip51 cip52 cosmin cyrus data frank george guest henry horde iceuser irc jane john master matt mysql noc oracle pamela patrick rolo server sybase test user web webmaster www www-data wwwrun And the few present users attempted: adm apache nobody operator root -Jay On Fri, 15 Oct 2004, Fabio wrote: Date: Fri, 15 Oct 2004 22:01:29 -0400 From: Fabio [EMAIL PROTECTED] To: Jay Libove [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Any update on SSH brute force attempts? Would you mind to provide me the username that were tried? have you ever modify your ssh daemon to log clear text passwords? Jay Libove wrote: A month or three back, I engaged in some conversation with others here on full-disclosure about brute force login attempts several of us were seeing on our SSH servers. Brute force isn't really the right description, as each account is only tried a few times (root gets about 50). As we surmised before, this still looks like an attack looking for certain known ID/password combinations. Recently, a couple of times a week, I see repeats of this which now have as many as fifty different accounts being attacked. (Almost none of which exist on my server, and none of which will have common passwords thankyouverymuch). What are you doing/changing about your SSH configurations to reduce the possibility of these attacks finding any kind of hole in the OpenSSH software (that's what I run, so that's the only version I'm particularly concerned about) ? Are you doing anything at all? Thanks -Jay ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Senior M$ member says stop using passwords completely!
http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx thank you Randall M ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Any update on SSH brute force attempts?
And the few present users attempted: adm apache nobody operator root In addition to what others have suggested, you could use PAM to enforce account lockouts in the event that the attacker does focus the attempts on a real account. The Linux module for this is pam_tally. You can also put an unlock script on a cron job to then prevent DoS of all of your accounts. Not perfect, but effective. hth, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: Any update on SSH brute force attempts?
Jay wrote- --- Hola a Colombia, Fabio! --- y Cc: al listo - That's some funny shit mate...security aside ,I've LMAO at this all afternoon. Keep up the good parody. Thanks. Sean. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Senior M$ member says stop using passwords completely!
No... Senior Microsoft member says: use passPHRASES instead of passWORDS. You should read the article before you start flaming. -- Aviv. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RandallM Sent: Saturday, October 16, 2004 3:14 PM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Senior M$ member says stop using passwords completely! http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx thank you Randall M ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx Jesus, that guy just doesn't get it, does he? Pre-computation attacks are a somewhat new and interesting phenomenon we are starting to encounter 'in the wild' through chainsaw security consultants. What they do is they pre-compute all of the possible LM or NT password hashes of a given length with a given character set and burn the pre-computed password-hash-to-password-mappings to DVD. Heck they can even submit their request to have your password hash reversed back into a password using a web page someone has setup to do the job for you (sorry, not going to give out THAT URL here.) . . . for free! Even if this was a new attack, a full rainbow table shouldn't be possible against a secure hash. Bottom line, M$ dropped the ball, and has refused to pick it up. The LM hash is no longer cryptographically secure... When was it? Pass-phrase LENGTH, not complexity defeats these attacks. Not if your hashes are chunked like some (all?) of M$'s. Precomputed chunks with a good lookup table defeats longer passwords. Mind you, I am no expert on M$ cryptography, but someone on their security team ought to know a bit more than this. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Your daily internet traffic report
Router locationindex router1.iust.ac.ir Iran (Tehran) 29 Which one of you are attacking Iran http://www.internettrafficreport.com/asia.htm thank you Randall M ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
That much is obvious. Read the the full article, do a little background research and get back to us when you reach a more sensible conclusion. Reactionary conclusions based on obvious article 'skimming' make it apparent you didn't do your homework before posting. FWIW I have used rainbow tables for dictionary-styled attacks for about 7 years now. There have been available CLI-based tools for generating dictionary lists using different character sets for the better part of the past 10 years. There are also many dictionary lists in multiple languages available on many university public FTP sites to build and extend your own from. Personally, I'm surprised this style attack took this long to catch on. On Sat, 16 Oct 2004 10:46:44 -0400, Tim [EMAIL PROTECTED] wrote: Mind you, I am no expert on M$ cryptography, but someone on their security team ought to know a bit more than this. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
On Sat, 2004-10-16 at 11:46, Frank Knobbe wrote: It's a nice recommendation of MS to make (to use long passphrases instead of passwords). But I don't consider 14 chars a passphrase. Perhaps they should enable more/all password components to handle much longer passwords/phrases. heh... I suck. Scratch that msg (where's my coffee?). My gaming laptop is even configured to log in automatically with AutoLogon=1 and a password that is longer than 14. Perhaps a faint memory of pain from the old Winders days wallowed up inside me. Oh well, I'll shut up now... signature.asc Description: This is a digitally signed message part
Re: [SPAM] [Full-Disclosure] Your daily internet traffic report
On Sat, 16 Oct 2004, RandallM wrote: Routerlocationindex router1.iust.ac.irIran (Tehran) 29 Which one of you are attacking Iran http://www.internettrafficreport.com/asia.htm I am a bit puzzled. Why o they think that some random routers and ICMP echo requests mak a good representation? Most routers will regard any ICMP request to them as a low priority issue. But there is no garantue that a drop of packets is an indication of the router being busy. It could be dropped halfway and you will never know why. But the internet topology is much, much more complex. Doing ICMP echo requests to 1 router and telling everyone what a country statistic is so far besides the truth I will not call it a lie. (I hate to insult lies by implying them in this.) I have been on some provider location through out the Netherlands yet there is only one (and a rather obscure one at that) router which should represent the Netherlands. Next thing they will show is graphs of pig airtraffic I guess. Hugo. -- I hate duplicates. Just reply to the relevant mailinglist. [EMAIL PROTECTED] http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of magicians, for they are subtle and quick to anger. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Senior M$ member says stop using passwords completely!
I did. He said stop using passwords. I'm not flamming, I was passing on an article. thank you Randall M |-Original Message- |From: Aviv Raff [mailto:[EMAIL PROTECTED] |Sent: Saturday, October 16, 2004 10:19 AM |To: 'RandallM'; [EMAIL PROTECTED] |Subject: RE: [Full-Disclosure] Senior M$ member says stop |using passwords completely! | | |No... |Senior Microsoft member says: use passPHRASES instead of passWORDS. | |You should read the article before you start flaming. | |-- Aviv. | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of RandallM |Sent: Saturday, October 16, 2004 3:14 PM |To: [EMAIL PROTECTED] |Subject: [Full-Disclosure] Senior M$ member says stop using |passwords completely! | | | |http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx |http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx | |thank you |Randall M | | | ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Any update on SSH brute force attempts?
On Fri, 2004-10-15 at 23:23, Kevin wrote: Use one time passwords (OTP, e.g. S/Key). How about: Require (long) DSA keys? I'd like to see someone brute-force trough a 4096 bit key :) Cheers, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
On Sat, 2004-10-16 at 09:46, Tim wrote: Even if this was a new attack, a full rainbow table shouldn't be possible against a secure hash. True if the hashes are salted. (with more than one byte please, otherwise they just use 256 DVDs :) Pass-phrase LENGTH, not complexity defeats these attacks. Not if your hashes are chunked like some (all?) of M$'s. Precomputed chunks with a good lookup table defeats longer passwords. It's a nice recommendation of MS to make (to use long passphrases instead of passwords). But I don't consider 14 chars a passphrase. Perhaps they should enable more/all password components to handle much longer passwords/phrases. Let me guess, that will all be fixed in Longshot. Cheers, Frank signature.asc Description: This is a digitally signed message part
[Full-Disclosure] bmon exploit
details included inside the script Idan. bmon.sh Description: Binary data
[Full-Disclosure] [FLSA-2004:1237] Updated gaim package resolves security issues
--- Fedora Legacy Update Advisory Synopsis: Updated gaim package resolves security issues Advisory ID: FLSA:1237 Issue date:2004-10-16 Product: Red Hat Linux Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1237 CVE Names: CAN-2004-0006 CAN-2004-0007 CAN-2004-0008 CAN-2004-0500 CAN-2004-0754 CAN-2004-0784 CAN-2004-0785 --- --- 1. Topic: An updated gaim package that fixes several security issues is now available. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 3. Problem description: Issues fixed with this gaim release include: Multiple buffer overflows that affect versions of Gaim 0.75 and earlier. 1) When parsing cookies in a Yahoo web connection, 2) YMSG protocol overflows parsing the Yahoo login webpage, 3) a YMSG packet overflow, 4) flaws in the URL parser, and 5) flaws in HTTP Proxy connect. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0006 to these issues. A buffer overflow in Gaim 0.74 and earlier in the Extract Info Field Function used for MSN and YMSG protocol handlers. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0007 to this issue. An integer overflow in Gaim 0.74 and earlier, when allocating memory for a directIM packet results in heap overflow. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0008 to this issue. Buffer overflow bugs were found in the Gaim MSN protocol handler. In order to exploit these bugs, an attacker would have to perform a man in the middle attack between the MSN server and the vulnerable Gaim client. Such an attack could allow arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0500 to this issue. An integer overflow bug has been found in the Gaim Groupware message receiver. It is possible that if a user connects to a malicious server, an attacker could send carefully crafted data which could lead to arbitrary code execution on the victims machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0754 to this issue. A shell escape bug has been found in the Gaim smiley theme file installation. When a user installs a smiley theme, which is contained within a tar file, the unarchiving of the data is done in an unsafe manner. An attacker could create a malicious smiley theme that would execute arbitrary commands if the theme was installed by the victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0784 to this issue. Buffer overflow bugs have been found in the Gaim URL decoder, local hostname resolver, and the RTF message parser. It is possible that a remote attacker could send carefully crafted data to a vulnerable client and lead to a crash or arbitrary code execution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0785 to this issue. Users of Gaim are advised to upgrade to this updated package which contains Gaim version 0.82.1 and is not vulnerable to these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #1237 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gaim-0.82.1-0.73.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/gaim-0.82.1-0.73.2.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gaim-0.82.1-0.90.3.legacy.src.rpm i386:
Re: [SPAM] [Full-Disclosure] Your daily internet traffic report
Hugo van der Kooij wrote: On Sat, 16 Oct 2004, RandallM wrote: Router locationindex router1.iust.ac.ir Iran (Tehran) 29 Which one of you are attacking Iran http://www.internettrafficreport.com/asia.htm I am a bit puzzled. Why o they think that some random routers and ICMP echo requests mak a good representation? The routers are not random. They are routers from folk who've *volunteered* to be a part of this. Jeeze, Loise, doesn't anyone do homework anymore? While I suspect that Iran may be getting a DOS here and there, I'd point out that there are other trouble spots across Asia, and I'm sure that's due to the incredible amount of compromised machines out that way, as much as anything. But the internet topology is much, much more complex. Doing ICMP echo requests to 1 router and telling everyone what a country statistic is so far besides the truth I will not call it a lie. (I hate to insult lies by implying them in this.) Uh-huh. Complexity is not what's being offered here. It's still a useful statistic, as long as you think of it as part of a picture (no one ever declared it as the whole). There are all sorts of places to pick this information up (including CAIDA, and CYMRU). I have been on some provider location through out the Netherlands yet there is only one (and a rather obscure one at that) router which should represent the Netherlands. Then suggest to some of those locations that they ought to be a part of this, so as to represent a more accurate picture. Don't meddle in the affairs of magicians, for they are subtle and quick to anger. -- Do not meddle in the affairs of wizards, for they are subtle, and quick to anger. Do not meddle in the affairs of dragons, for you are crunchy, and taste good with catsup. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [SPAM] [Full-Disclosure] Your daily internet traffic report
hi, Most routers will regard any ICMP request to them as a low priority issue. do they? icmp is not only about 'echo'. there's lot of other functions via type/code - fragmentation, mtu etc, vital for traffic signalization. administrators, who blindly closes all icmp traffic are plain stupid idiots. all the best, W. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Google Desktop Search
What is the added benefit of sending MD5 hashes instead of plain-text passwords? I mean, the MD5 hash will be the same for the same password, isn't it? I hope that Yahoo has implemented something more complicated that that, otherwise it is plain pointless. -- rem. [EMAIL PROTECTED] wrote: Read the javascript in the headers of Yahoo's login page: -- Begin javascript comments from Yahoo -- /* * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message * Digest Algorithm, as defined in RFC 1321. * Copyright (C) Paul Johnston 1999 - 2000. * Updated by Greg Holt 2000 - 2001. * See http://pajhome.org.uk/site/legal.html for details. */ -- End Javascript comments from Yahoo -- THEY don't even cache, or pass, your password. Like all secure programs, they store, and transmit, an MD5 Sum. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Outlook cid: handling - Request for Information
!--
It has recently come to my attention that it is possible to
circumvent functions inside of Microsoft Outlook 2003 and some
other MUA's by using href tags containing cid:;. By default
such MUAs no longer download web referenced images and objects,
however images referencedby cid:; strings are embedded (as
attachments with special names) within the e-mail.
Contrary to the policy of not downloading images, it would seem
that these are packaged with the mail (decentralised) AND are
displayed despite non-image download policies.
--
The download restriction is in refernce to remote files. CID:
is 'content id' it references the content of the appropriate
boundry of the MIME mail message. Which in this case would be an
image. The image is encoded and embedded within the mail message
itself. Not on a remote server and does not /cannot download. It
is a link inside the email to an encoding of the image which is
then rendered. For example:
img src=cid:malware;
--=_NextPart_000_0004_01C4B234.2209FD20
Content-Type: image/gif;
name=youlickit[1].gif
Content-Transfer-Encoding: base64
Content-ID: malware
R0lGODlhogCiAOb/AP8hAP8QAP8AAPdCAPcAAO97AO8IAOfeQufWUuetY+eUA
N7OEN7OAN7G
Simply put it is connecting to the base64 encoded image within
the email message by identifying it with the name malware. As
http is to a webserver, so CID is to the content of the mail
message.
It's not being downloaded from anywhere other than from within
the mail message. However if what you are after is to not view
images, the only way is to accept all email in plain text. But
in Outlook Express [maybe Outlook 2003 haven't checked], an
attached image file even in a plain text message, will be
rendered.
It is a machine generated CID like this:
CENTERIMG SRC=CID:{F69034DE-F779-4AA2-B5A9-
7413133C2A29}/malware.JPG/CENTER
This harkens back to the day of the 'slide show' feature in
Outlook Express. But again it is not retrieved remotely, rather
from within the email message itself via the CID.
You may try some sort of filter in Outlook 2003 or definitely on
the server to remedy whatever is concerning you.
--
http://www.malware.com
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Google Desktop Search
Yahoo! is the lamest network online corp wise. The queuing up of security reports and the priority of them is all wrong, me thinks they are a tad under staffed I can access admin areaz of Yahoo!, I have various screenshots to prove it. I gave up contacting Yahoo! after they failed to be polite and reply to people trying to help them, to avoid script kidz getting near. Been keeping an eye on Yahoo! most of my online life.. I know the place inside out and upside down. :-) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Full-Disclosure Posts
Should Full-Disclosure only allow so-called -real- names? Excellent idea. I'll go first. -- http://www.malware.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [SPAM] Re: [SPAM] [Full-Disclosure] Your daily internet traffic report
On Sat, 16 Oct 2004, Willem Koenings wrote: Most routers will regard any ICMP request to them as a low priority issue. do they? icmp is not only about 'echo'. there's lot of other functions via type/code - fragmentation, mtu etc, vital for traffic signalization. administrators, who blindly closes all icmp traffic are plain stupid idiots. That should have read ICMP ECHO request. I know IOS (Cisco) does handle it as very low priority traffic. So it will be the first to be dropped or answered extremely late. While your filtering point is valid and in fact occurs in major networks these days which make troubleshooting a pain if you forget a major ISP can will actually drop required traffic. But I was only pointing out that the specific request is handled with low priority in some (perhaps most) routers and is not an accurate reference point. Hugo. -- I hate duplicates. Just reply to the relevant mailinglist. [EMAIL PROTECTED] http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of magicians, for they are subtle and quick to anger. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Full-Disclosure Posts
Should Full-Disclosure only allow so-called -real- names? I was on Nanog (a network admin list) and they have a rule where you can only post with a first and second name, instead of an alias or nick, to kind of give more credibility that you are a security professional and not a hax0r or script kiddie. Should the same rule be pro actively implemented to Full-Disclosure or is it a dead duck idea? I know hax0rs or script kiddies would probably use fake first and second names if it was implemented, but at least the list would look neat and a tad more professional? Feedback welcomed ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] TCP / IP
I am just a student learning about TCP/IP and dont know where to post this idea, figured posting it here would get me some flames and links. Why not make the window the size of the file to be transmitted and the ack back have the segments missing thereby reducing overall overhead and lag time. ie host1 1mb file --- sent -- host2 host1 -- ack missing 3 6 8 segments -- host2 host1 -- segments 3 6 8 sent --- host2 host1 -- FIN --- host2 The window could be dynamic according to content size. Buffers would have to be huge but with RAM so cheap these days why not ? or am I smoking newbie crack ? Dan __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Full-Disclosure Posts
Exelent Idea.. ;-P On Sun, October 17, 2004 0:15, [EMAIL PROTECTED] said: Should Full-Disclosure only allow so-called -real- names? I was on Nanog (a network admin list) and they have a rule where you can only post with a first and second name, instead of an alias or nick, to kind of give more credibility that you are a security professional and not a hax0r or script kiddie. Should the same rule be pro actively implemented to Full-Disclosure or is it a dead duck idea? I know hax0rs or script kiddies would probably use fake first and second names if it was implemented, but at least the list would look neat and a tad more professional? Feedback welcomed ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -Mister Xploitable Gmail ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Senior M$ member says stop using passwords completely!
Hello Mr Espinola, That much is obvious. Read the the full article, do a little background research and get back to us when you reach a more sensible conclusion. The reason for my post was to point out that Mr. Hensing doesn't appear to be a reliable source of information on the topic of passwords and hash security. If you haven't come to the same conclusion, perhaps you should do more homework yourself. Reactionary conclusions based on obvious article 'skimming' make it apparent you didn't do your homework before posting. Pardon me for my reactionary style. I am merely frustrated by M$'s irresponsible business practices, and their unwillingness to correct the problems that they make for every internet user (not just Windows users). FWIW I have used rainbow tables for dictionary-styled attacks for about 7 years now. There have been available CLI-based tools for generating dictionary lists using different character sets for the better part of the past 10 years. There are also many dictionary lists in multiple languages available on many university public FTP sites to build and extend your own from. Your point? I agree that these have been around a while, but even if they have been, it shouldn't change the fact that a hash is either secure or it isn't, for the level of computation possible by today's computers. Yes, good passwords are always a must, along with a good hash, but what he defines as good, is a joke. I mean really, how many bits of entropy are in an english sentence? Last I heard, about 1 to 1.5 bits per character. Mr. Hensing comes across as (if I may paraphrase): You foolish users, why aren't you using secure passphrases??? 8-character passwords just aren't good enough because of all of these big nasty hackers have great cracking tools!!! Which, of course, is horseshit. You ever tried building a rainbow table for salted SHA? How much disk you got? Let's see... for 8-character alphanumerics w/ 10 special characters, on a 14bit salt, you'll need around (46^8)*(7+20)*(2^14) ~= 8868422 TerraBytes Do let me know if I fudged on any of those off-the-napkin calculations. So, the moral of the story is, he doesn't know what he is talking about. Feel free to defend him, but I am not posting any more on this topic. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Google Desktop Search
Not necessarily -- that's what salt characters are for in crypto. Check out Applied Cryptography. The added value is that if you have the plain text password, you have the password, if you have the hash, you still have to crack it, or BF it. MD5sum is one of the methods that Unix/Linux use for OS password storage. What Yahoo is doing isn't perfect, but it's a damn site better than pointless. M. What is the added benefit of sending MD5 hashes instead of plain-text passwords? I mean, the MD5 hash will be the same for the same password, isn't it? I hope that Yahoo has implemented something more complicated that that, otherwise it is plain pointless. -- rem. [EMAIL PROTECTED] wrote: Read the javascript in the headers of Yahoo's login page: -- Begin javascript comments from Yahoo -- /* * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message * Digest Algorithm, as defined in RFC 1321. * Copyright (C) Paul Johnston 1999 - 2000. * Updated by Greg Holt 2000 - 2001. * See http://pajhome.org.uk/site/legal.html for details. */ -- End Javascript comments from Yahoo -- THEY don't even cache, or pass, your password. Like all secure programs, they store, and transmit, an MD5 Sum. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Full-Disclosure Posts
I wonder how they handled the Cisco guy whose actual legal name was 'megazone' (Without the quotes, IIRC). Or the chinese couple that wanted to name their kid '@'? (The symbol ususally pronounced as 'at'). On Sat, 16 Oct 2004, [EMAIL PROTECTED] wrote: Should Full-Disclosure only allow so-called -real- names? I was on Nanog (a network admin list) and they have a rule where you can only post with a first and second name, instead of an alias or nick, to kind of give more credibility that you are a security professional and not a hax0r or script kiddie. Should the same rule be pro actively implemented to Full-Disclosure or is it a dead duck idea? I know hax0rs or script kiddies would probably use fake first and second names if it was implemented, but at least the list would look neat and a tad more professional? Feedback welcomed ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Full-Disclosure Posts
Well, if it were a list for security professionals - with a consensus on what security was and with a shared view how to look and act professional - maybe. But then again, many people here would probably not qualify as security pro in the economic sense - they are not employed in security per sé, whilst many people so employed are ignorant of this list and the likes. They sell firewalls in a box or ISO cretfication advice. Nanog on the other hand is a list for people that might actually meet in jobrelated ways. FD isn't, it is more for the vulnerability-inclined, while most security pro's I meet are procedure minded. I have yet to meet a security officer that could actually grasp a sniffer trace or an auditor that could read code And as far as security consultants go - well, ah, there are some good ones, i guess. But maybe we could do a poll here: what job pays your bills. My guess would be many sysadmins and proggers. But not to worry, I can act professional myself, like wear a tie - if someone could mail the link tothe manual on how to do the double windsor - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 17, 2004 12:15 AM Subject: [Full-Disclosure] Full-Disclosure Posts gt; Should Full-Disclosure only allow so-called -real- names? I was onBR gt; Nanog (a network admin list) and they have a rule where you can onlyBR gt; post with a first and second name, instead of an alias or nick, toBR gt; kind of give more credibility that you are a security professional andBR gt; not a hax0r or script kiddie.BR gt; BR gt; Should the same rule be pro actively implemented to Full-Disclosure orBR gt; is it a dead duck idea?BR gt; BR gt; I know hax0rs or script kiddies would probably use fake first andBR gt; second names if it was implemented, but at least the list would lookBR gt; neat and a tad more professional?BR gt; BR gt; Feedback welcomedBR gt; BR gt; ___BR gt; Full-Disclosure - We believe in it.BR gt; Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Full-Disclosure Posts
[EMAIL PROTECTED] wrote: Should Full-Disclosure only allow so-called -real- names? I was on Nanog (a network admin list) and they have a rule where you can only NANOG is not even remotely a network admin list. It is comprised (mostly) of those folk who administer and make decisions on what we used to consider the backbone. North American Network Operators Group (NANOG) does occasionally talk about the administration of networks, but they aren't interested in your puny /29 in your parent's basement. post with a first and second name, instead of an alias or nick, to kind of give more credibility that you are a security professional and not a hax0r or script kiddie. They really aren't all that interested in having *security professionals* (whatever that might mean) on the list, although they don't reject such things. It isn't the purpose of the list. Do you provide support for MCI? How about Verisign? Those are the sort of folk that list is intended for. In addition, the FAQ will tell you that a recognized pseudonym as an acceptable substitute (that means that the pseudonym needs to have been around for quite a while, cookie). Should the same rule be pro actively implemented to Full-Disclosure or is it a dead duck idea? It would be silly to think of such a thing. I'd say that more than half the posts here are mixed between goofy handles, and truenames (c.f. Truenames, Vinge), and that the signal and noise has no correlation between those (i.e. goofy handle is not necessarily noise, and lord knows truenames are no guarantee of signal). I know hax0rs or script kiddies would probably use fake first and second names if it was implemented, but at least the list would look neat and a tad more professional? Of course, anyone still using the term hax0r as though it were meaningful might want to think further about what a security professional might be. Feedback welcomed Voila! -- Do not meddle in the affairs of wizards, for they are subtle, and quick to anger. Do not meddle in the affairs of dragons, for you are crunchy, and taste good with catsup. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [SPAM] [Full-Disclosure] Your daily internet traffic report
Most routers will regard any ICMP request to them as a low priority issue. do they? icmp is not only about 'echo'. there's lot of other functions via type/code - fragmentation, mtu etc, vital for traffic signalization. administrators, who blindly closes all icmp traffic are plain stupid idiots. Lots 'o flame but no light. How about sharing your knowledge of why certain icmp traffic should be allowed and the risks associated with allowing that traffic? Regards, Lee ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Nessus experience
- Original Message - From: Tate Hansen [EMAIL PROTECTED] checks_read_timeout: maximum number of seconds to wait for a probe response: wait doing a recv() plugins_timeout: the maximum number of seconds of lifetime for a vulnerability check If you set checks_read_timeout to 1 second and plugins_timeout to 5 seconds, you'll blaze through the scan. The problem is you may lose accuracy because That is quite interesting. Correct me if I am wrong, but it looks like if the target interface that one is scanning is blocked/down for some reasons, nessusd does not learn about it. (I guess it might be too much to expect). That is, every one of the plugins will get delayed leading to a huge time. Usually I haven't had the patience to wait for the whole scan in such cases; I guess it could take days, am I right ? regards, Samir Kelekar I'm not sure if I understand your question, but I'll try to expand a little and see if I can answer it. checks_read_timeout and plugins_timeout allow you to specify the maximum amount of time you want any one check to consume (*see Note at bottom). If the target host is down or blocked, then it really depends on how you configured nessus. For example, if you configure nessus to perform the port scan and you have the parameters 'unscanned_closed' and 'optimize_test' set to 'yes', then the only vulnerability checks that should get executed are checks in which the dependencies have been satisfied: this typically means nessus found a port in an open state and determined the protocol in use. Most scripts define dependency requirements like: script_dependencie(find_service.nes,http_version.nasl); script_require_ports(Services/www,80) script_require_keys(www/apache) The above implies a vulnerability check would only run if: 1) find_service.nes and http_version.nasl were executed before this script 2) a port is in the open state using the http protocol If those dependencies are not met, then the vulnerability check is not supposed to be executed. So, hopefully to answer your question, if the host is blocked or down, that would imply nessus did not find any open ports - which causes most vulnerability check dependencies not to be satisfied and the vulnerability check not be executed. You can verify this in your case by watching the nessusd.messages log file while you are running a nessus vulnerability scan: If the dependencies are satisfied, but the plugin_timeout is exceeded, you should see messages like: [...] httpver.nasl (pid 2441) is slow to finish - killing it (FYI: I do notice the reported time of some vulnerability checks exceed the value specified for the plugins_timeout; I'm not sure if this is due to server load, latency, or particularly code paths traversed, but overall it seems to work okay) If the dependencies are not satisfied for whatever reason, you should see: [.] : Not launching http_login.nasl against [.] none of the required tcp ports are open (this is not an error) [.] : Not launching DDI_Directory_Scanner.nasl against [.] none of the required tcp ports are open (this is not an error) *Note: I don't remember for sure, but I think plugin_timeout only affects certain categories of vulnerability checks: ACT_ATTACK, ACT_DENIAL, ACT_GATHER_INFO, etc. (there are more categories in NASL2): Not ACT_SCANNER, ACT_PASSIVE. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] TCP / IP
--- Richard Golodner [EMAIL PROTECTED] wrote: DB, what about file sizes larger than your original window? Give us all a little more detail as to how this might work. Rich The inital syn sends seq number mss source and dest ports to receiver ( why not add window = size of the file to be sent ? ) receiver sends its mss and ack of window size back port opens and data flows once data is all sent ( end packet has special flag to ensure window is closed ) receiving host checks for missing parts and sends ack back with those segments it is missing Its not really a major change of anything ... just with the broadband we have nowdays why not do the error checking all at once ? ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
