Today my logs showed how exactly the spammers exploited the old script. I do not log the mail body, but only sender, recipient and subject, but that’s enough to show the used pattern. In fact the subject variable was used, but different from what I expected.
The following is the how it looks. Email addresses have been replaced by invalid ones. For the sake of brevity I added “\r\n” for all explicit line breaks:
\r\n Content-Type: multipart/alternative;\r\n boundary=414f67f4df73cd51475e25661d1c271c\r\n Subject:\r\n bcc: email@example.com\r\n bcc: firstname.lastname@example.org\r\n bcc: email@example.com\r\n bcc: firstname.lastname@example.org\r\n bcc: email@example.com\r\n bcc: firstname.lastname@example.org\r\n bcc: email@example.com\r\n bcc: firstname.lastname@example.org\r\n \r\n This is a multi-part message in MIME format.\r\n \r\n --414f67f4df73cd51475e25661d1c271c\r\n Content-Transfer-Encoding: 7bit\r\n Content-Type: text/plain\r\n \r\n \r\n \r\n --414f67f4df73cd51475e25661d1c271c\r\n Content-Transfer-Encoding: 7bit\r\n Content-Type: text/plain\r\n \r\n \r\n \r\n --414f67f4df73cd51475e25661d1c271c--\r\n .\r\n
The actual trick was using the dot on a separate line which would cause the
sendmail binary to skip any further input. So another conclusion to add to the last article would be to tell
sendmail explicitly to not consider the single dot as an end of mail marker, which is possible through the respective command line option.
PS: The logfile proves there has nothing come through anymore … and I feel lucky I found out about this exploit after “only” 10 days.