Results 1 to 3 of 3
Hi all, My server seems to be abused for a rather elaborate way of relaying spam despite being a closed-relay server. The trick is that messages are sent using the ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 12-04-2012 #1
- Join Date
- Dec 2012
Bouncing spam sent 'from localhost' on my server (Qmail)
My server seems to be abused for a rather elaborate way of relaying spam despite being a closed-relay server. The trick is that messages are sent using the victim's address as sender and a random address at a dead domain that has its MX set to 127.0.0.1 (like blackplanet.com). This way my server doesn't block the relay, and bounces the message to the "sender" with the "although I'm listed as best preference etc" errormessage. I guess the point is that the receiver of the bounce is supposed to be curious enough to read through the entire bounce message and get to the original dating site advertisement. While these are only bounces, it still got me listed on CBL which is quite a nasty problem because this server hosts mail for several clients who can now no longer reach Hotmail/Live/Gmail.
Now the scary thing is that these mails are all sent by invoking qmail locally on my server, the mails actually originate from 127.0.0.1 (not the bogus domains), so somebody can run the qmail process which is how the mails end up on my server in the first place.
I have the qmail patch that lists the user who invoked qmail in the headers. This appears to be the qmail user. Also, I had a watcher dump a netstat --program each time "mail from 127.0.0.1" appeared in my maillog. The process connecting FROM 127.0.0.1 TO 127.0.0.1:smtp was listed as "-". I also searched through all the vhost-logs of the site this server hosts, and the global apache log, to check for suspicious requests at the times the spam messages were sent but there were none. (It's a small server).
Now this morning I spent over an hour writing this forum post including lots of extra info, seeing the "autosaved" flash up all the time, and then when posting it I got a blank screen and then found that the "autosave" only saved the first line, so I'm going to stick to the most important bit of this post first and maybe later when I gather enough courage I will add all the details again in case somone wants to help track down this problem. For now I'd really like to know:
1. As hot fix to get me off the black lists: (This really is urgent!) Is there a way to tell qmail to supress this specific bounce message? (The "although I'm listed as best preference.." error). It's a useless error anyway, as it will only occur in situations where I screw up or when serious hacking it taking place. No normal user should ever need to see it. If I could prevent this bounce from being sent, it would stop my server from distributing garbage. I'd still need to figure out how or why someone is invoking qmail from my server but that's slightly less urgent.
2. Is there any way to get more information about how qmail was invoked (by what user, script or progress) when the header reports qmail runs as "qmail user" and netstat lists the owning process as "-"?
In case anyone wants to help me hunting down the actual problem, I'll include the details in this thread I spent so much time on this morning, and then select all+copy before I send. For now I just hope someone can answer at least one of the above 2 questions.
Last edited by maurits; 12-04-2012 at 12:35 PM. Reason: Left out a bit too much information in the hasty rewrite :)
- 12-04-2012 #2
- Join Date
- Dec 2012
Ok, I MAY have an answer here, in any case I clearly removed a backdoor.
A year(?) ago when Russians stole a large number of Twitter passwords with email addresses, mine was among them. Later I already found that these people were quite cleverly attempting to use the same passwords elsewhere. On my server I appeared to have a forgotten ftp-account with a part of my email address as login name and the same password. And sure enough, somebody has been logging in and putting stuff in a cgi-bin directory.
Just for other people hunting for suspicious stuff, I'll describe what it was and what they did to obfuscate it:
They uploaded cgi files called "news.cgi", "images.cgi" and "manual.cgi" in various subdirectories, all with unreadable perl code consisting only of mostly * < > signs. They accessed these cgi-files using various IP-addresses listing googlebot as client, to make them less suspicious when viewing your log files. (I found this out by specifically looking for these cgi files in the logs, and then resolving the listed IPs, sure enough they weren't coming from Google). Now of course the times of these cgi-accesses didn't match the sending of the spam messages really, but I'm guessing the cgi accepts some parameters at runtime or uses a random delay before doing its thing to make tracing more difficult. (I didn't dare run the scripts myself).
Now I can't put a hard link between these cgi's and the sending of mails from 'localhost' but after many problemfree years it would be a real coincidence if two completely unrelated break-ins happened at the same time.
Obviously it's also time to install tripwire on this server. Better late than never.
- 12-04-2012 #3
- Join Date
- Dec 2012
So interestingly enough, qmail being invoked from a cgi happens quite "anonymously", there is no link whatsoever to apache or the name of the script even when the uid is displayed in the header or netstat catches the qmail process in the act and is called with the --program flag.
Also, script kiddies have gotten quite a bit further than dumb brute-force scripts, since they clearly managed to get from an email address registered on twitter to a similar loginname on the mailserver associated with that email address. Some manual labour must have been involved here. (I know it must have been a stolen password since I continuously log for brute force attacks and I've seen some happen but never a succesful one).