What does mean this bizarre msgid? maillog: Mar 31 19:31:15 cu sm-mta[5352]: h2VFVEGS005352: from=<nb@sindbad.ru>, size=1737, class=0, nrcpts=1, msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAfp4Fa2ShPE2u4pP/QpPDIMKAAAAQAAAAj+zb4Isbuk+tYEPVF9Vf, proto=ESMTP, daemon=MTA, relay=wg.pu.ru [193.124.85.219] -- Nikolaj I. Potanin, SA drweb.ru ID Anti-Virus Lab (SalD Ltd) nikolaj@drweb.ru St. Petersburg, Russia ph.: +7-812-3888624
At 10:18 AM 3/31/2003, Nikolaj I. Potanin wrote:>What does mean this bizarre msgid?It means that someone's trying to exploit a buffer overrun vulnerability. --Brett
>>Mar 31 19:31:15 cu sm-mta[5352]: h2VFVEGS005352: from=<nb@sindbad.ru>, >>size=1737, class=0, nrcpts=1, >>msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAfp4Fa2ShPE2u4pP/QpPDIMKAAAAQAAAAj+zb4Isbuk+tYEPVF9Vf, >>proto=ESMTP, daemon=MTA, relay=wg.pu.ru [193.124.85.219]> I don't know if it "means" anything, but a message that an SMTP client > tried to deliver to my SMTP server would be rejected, because it didn't > have an '@' in it.Anyway, newly updated sendmail _did_ deliver this message, is there any means to make it reject such kind of mail (i.e. containing illegal msgid)? -- Nikolaj I. Potanin, SA drweb.ru ID Anti-Virus Lab (SalD Ltd) nikolaj@drweb.ru St. Petersburg, Russia ph.: +7-812-3888624
On Mon, Mar 31, 2003 at 09:18:08PM +0400, Nikolaj I. Potanin wrote:> What does mean this bizarre msgid? > > maillog: > Mar 31 19:31:15 cu sm-mta[5352]: h2VFVEGS005352: from=<nb@sindbad.ru>, > size=1737, class=0, nrcpts=1, > msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAfp4Fa2ShPE2u4pP/QpPDIMKAAAAQAAAAj+zb4Isbuk+tYEPVF9Vf, > proto=ESMTP, daemon=MTA, relay=wg.pu.ru [193.124.85.219]It was a long Message-ID which sendmail truncated to 100 characters when printing the log message, i.e. printf(... msgid=%.100s ...). It's kind of interesting, because it is base64 encoded data which begins with the string `PCDFEB09': 0000 50 43 44 46 45 42 30 39 00 01 00 02 00 00 00 00 |PCDFEB09........| 0010 00 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 |................| 0020 00 7e 9e 05 6b 64 a1 3c 4d ae e2 93 ff 42 93 c3 |.~..kd¡<M®â.ÿB.Ã| 0030 20 c2 80 00 00 10 00 00 00 8f ec db e0 8b 1b ba | Â........ìÛà..º| 0040 4f ad 60 43 d5 17 d5 5f |O`CÕ.Õ_| Google'ing for that string turns up a lot of hits, which seem to be Microsoft TNEF attachements. *shrug* Perhaps it is a sneaky way of sending some data out-of-band :-) or maybe it is just a buggy application. Too bad you don't have the entire message. I don't think it is anything to worry about, really. Cheers, -- Jacques A. Vidrine <nectar@celabo.org> celabo.org NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Oh, and elm apparently has a buffer overflow in Message-ID header handling too. See linuxsecurity.com/advisories/redhat_advisory-1497.html --Brett
At 12:56 PM 31/03/2003 -0600, Jacques A. Vidrine wrote:>It's kind of interesting, because it is base64 encoded data which >begins with the string `PCDFEB09': > >0000 50 43 44 46 45 42 30 39 00 01 00 02 00 00 00 00 |PCDFEB09........| >0010 00 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 |................| >0020 00 7e 9e 05 6b 64 a1 3c 4d ae e2 93 ff 42 93 c3 |.~..kd?<M??.?B.?| >0030 20 c2 80 00 00 10 00 00 00 8f ec db e0 8b 1b ba | ?........???..?| >0040 4f ad 60 43 d5 17 d5 5f |O?`C?.?_| > >Google'ing for that string turns up a lot of hits, which seem to be >Microsoft TNEF attachements. *shrug* Perhaps it is a sneaky way of >sending some data out-of-band :-)Actually, will not some MS email clients (e.g. lookOUT) honor attachments that begin in the headers ? I recall a discussion similar to this on email AV scanner lists... Because MS would decode an attachment crammed in the subject line, this could be a way to bypass email scanners and cram viruses in the subject... Combined with the fact that there are many unpatched email clients out there, this would be a nice way to spread an email worm. Perhaps the MS client would try and decode an attachment in the messageID ? ---Mike>or maybe it is just a buggy >application. Too bad you don't have the entire message. > >I don't think it is anything to worry about, really. > >Cheers, >-- >Jacques A. Vidrine <nectar@celabo.org> celabo.org >NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos >jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se >_______________________________________________ >freebsd-security@freebsd.org mailing list >lists.freebsd.org/mailman/listinfo/freebsd-security >To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
On Mon, Mar 31, 2003 at 02:39:49PM -0500, Mike Tancsa wrote:> Actually, will not some MS email clients (e.g. lookOUT) honor attachments > that begin in the headers ? I recall a discussion similar to this on email > AV scanner lists... Because MS would decode an attachment crammed in the > subject line, this could be a way to bypass email scanners and cram viruses > in the subject... Combined with the fact that there are many unpatched > email clients out there, this would be a nice way to spread an email worm. > > Perhaps the MS client would try and decode an attachment in the messageID ?That would explain why someone was sending such a Message-ID header, and I guess I would not be surprised that some Microsoft MUA would do something bone-headed like that. Cheers, -- Jacques A. Vidrine <nectar@celabo.org> celabo.org NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
At 12:39 PM 3/31/2003, Mike Tancsa wrote:>Actually, will not some MS email clients (e.g. lookOUT) honor attachments that begin in the headers ?I haven't heard of this, but it's certainly possible. Many MTAs automatically strip TNEF attachments from the body of the message, but they may miss them if they're in a header. The TNEF signature string could be misdirection, too. --Brett
So I did a grep for msg IDs similar to the one that is being discussed and I got the following 3 examples. There is some humour perhaps in the fact that 2 are from the bugtraq mailing list. :) All 3 are from microsoft outlook and both of the bugtraq samples are from the same individual. I would like to see some analysis of this. The chance that generated msg IDs could correspond so closely is about 1/googleplex so we can assume some mechanism. Are these systems in fact infected with a virus and is embedded base64 in the MSG ID a viral vector? 07-Mar-00:01/mail.log:Mar 7 18:10:19 koibito sendmail[3110]: h27NAIVK003110: from=<bugtraq-return-8642-cmr=iisc.com@securityfocus.com>, size=11569, class=-60, nrcpts=1, msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAnPQpmkc/vBG8Jfb3ld blgcKAAAAQAAAAm4xh+UzWb0OinqZZoa2a, proto=ESMTP, daemon=MTA, relay=outgoing2.securityfocus.com [205.206.231.26] 15-Mar-00:01/mail.log:Mar 15 17:59:59 koibito sendmail[8293]: h2FMxxQr008293: from=<bugtraq-return-8739-cmr=iisc.com@securityfocus.com>, size=3175, class=-60, nrcpts=1, msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAnPQpmkc/vBG8Jfb3ld blgcKAAAAQAAAAtJa3PVSM7kCcGxoCbmy6, proto=ESMTP, daemon=MTA, relay=outgoing3.securityfocus.com [205.206.231.27] 26-Mar-00:01/mail.log:Mar 26 10:00:43 koibito sendmail[19304]: h2QF0gQr019304: from=<waldman@rotys.com>, size=4002, class=0, nrcpts=1, msgid=<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAdSnUABYNYU6DjpQqV8 1Jr8KAAAAQAAAAojU6KWs7KEKqLEcvgjY/, proto=ESMTP, daemon=MTA, relay=4t174240.aspadmin.net [209.126.174.240] (may be forged) Here are the full IDs: Date: Fri, 7 Mar 2003 23:46:35 +0200 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAnPQpmkc/vBG8Jfb3ldblgcKA AAAQAAAAm4xh+UzWb0OinqZZoa2ajAEAAAAA@yahoo.com> ... X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAnPQpmkc/vBG8Jfb3ldblgcKA AAAQAAAAtJa3PVSM7kCcGxoCbmy6BQEAAAAA@yahoo.com> ... X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAdSnUABYNYU6DjpQqV81Jr8KA AAAQAAAAojU6KWs7KEKqLEcvgjY/hwEAAAAA@rotys.com> ... X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106