Reply
 
Thread Tools Display Modes
  #21  
Old 08-12-11, 09:47 AM
malcolmd malcolmd is offline
Guru
 
Join Date: Aug 2010
Location: Huntsville, AL
Posts: 81
And to Apache 2.2.3-43...

The CVE here:
http://www.cvedetails.com/cve/CVE-2011-0419/

Points to:
http://rhn.redhat.com/errata/RHSA-2011-0507.html

on the RedHat site, which indicates that their fix was made to apr-1.2.7-11.

...both of which we're distributing with *now.

So, as ezekielmudd mentioned, maybe Apache / APR isn't the right direction?
__________________
Malcolm Davenport
Digium, Inc. | Senior Product Manager
Reply With Quote
  #22  
Old 08-12-11, 03:56 PM
phoneguy phoneguy is offline
Member
 
Join Date: Jan 2008
Posts: 71
Ok so we just had a client in paid support inform us they thought they were hacked. We logged in and saw in the ps aux the following


root 12379 3.4 0.2 49960 10984 pts/0 S+ 13:25 0:00 /usr/bin/perl ./mycnf 174.142.177.241 10000 0
root 12380 3.2 0.2 49960 10984 pts/0 S+ 13:25 0:00 /usr/bin/perl ./mycnf 174.142.177.242 10000 0
root 12381 3.3 0.2 49960 10980 pts/0 S+ 13:25 0:00 /usr/bin/perl ./mycnf 174.142.177.243 10000 0
root 12382 3.4 0.2 49960 10984 pts/0 S+ 13:25 0:00 /usr/bin/perl ./mycnf 174.142.177.244 10000 0


There were about 2000 lines of that and the IP's kept changing as the port scan was running. Load average was up to 150 in TOP.

The file this time was located in /usr/books/.n I tar'd up the files and if anyone wants them please email Ward as I sent them to him also.

The only ports open on the firewall for this customer was 80, 5060 and 10000-20000 for SIP. Everything else was closed down. I see nothing in the access files for apache on someone failing to log in and fail2ban did not detect any failed logins. This was not a FreePBX Distro but a different FreePBX based system. They were running an older apache and php and advised them to upgrade those packages but the customer decided to do a re install instead and than upgrade the packages.

If anyone else runs into this please be very careful killing the processes as each time we have done this they than DoS attack the IP that you killed the process from.
__________________
Tony Lewis
Schmooze Com, Inc./FreePBX Dev Team
Reply With Quote
  #23  
Old 08-12-11, 04:06 PM
malcolmd malcolmd is offline
Guru
 
Join Date: Aug 2010
Location: Huntsville, AL
Posts: 81
So after they reinstall, can they trap all traffic going to that machine for a day or two so we can get a better idea of what's being exploited?
__________________
Malcolm Davenport
Digium, Inc. | Senior Product Manager
Reply With Quote
  #24  
Old 08-12-11, 04:31 PM
phoneguy phoneguy is offline
Member
 
Join Date: Jan 2008
Posts: 71
And here is another one from the same customer different box.

root 10209 2.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10210 2.0 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10211 1.8 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10212 2.0 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10213 2.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10214 1.8 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10215 0.2 0.1 7948 2060 ? Ss 15:20 0:00 sshd: root@pts/
root 10217 2.2 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10218 2.2 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10219 1.8 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10220 1.8 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10221 2.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10222 2.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10223 1.7 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10224 1.7 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10225 1.7 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10226 1.7 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10227 1.7 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10228 1.6 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10229 1.6 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10230 0.5 0.1 4752 1492 pts/2 Ss 15:20 0:00 -bash
root 10254 1.5 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10255 1.5 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10256 1.5 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10257 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10258 1.5 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10259 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10260 1.5 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10261 1.5 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10262 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10263 1.5 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10264 1.5 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10265 1.5 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10266 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10267 1.0 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10268 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10269 1.0 0.0 1740 384 pts/0 R+ 15:20 0:00 ./exim new vuln
root 10270 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10271 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10272 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10273 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 10274 1.0 0.0 1740 384 pts/0 S+ 15:20 0:00 ./exim new vuln
root 11773 0.0 0.0 1748 412 pts/0 S+ 14:20 0:00 ./exim new vuln
root 11814 0.0 0.0 4564 1064 pts/0 S+ 14:20 0:00 sh -c perl x.pl
root 11815 0.0 2.6 38448 34564 pts/0 S+ 14:20 0:00 perl x.pl 202.1
root 12314 0.0 0.0 1748 412 pts/0 S+ 14:21 0:00 ./exim new vuln
root 12377 0.0 0.0 4564 1068 pts/0 S+ 14:21 0:00 sh -c perl x.pl
root 12378 0.0 1.8 28208 24328 pts/0 S+ 14:21 0:00 perl x.pl 202.1
nagios 18092 0.0 0.0 5080 944 ? Ss 12:05 0:00 /usr/local/nagi
root 18899 0.0 0.0 1748 412 pts/0 S+ 14:29 0:00 ./exim new vuln
root 18953 0.0 0.0 4564 1068 pts/0 S+ 14:29 0:00 sh -c perl x.pl
root 18954 0.0 8.1 110128 106244 pts/0 S+ 14:29 0:00 perl x.pl 202.1
root 23242 0.0 0.0 5032 1156 ? Ss 13:28 0:02 SCREEN
root 23243 0.0 0.1 4752 1528 pts/0 Ss 13:28 0:00 /bin/bash
root 23261 0.0 0.0 4756 860 pts/0 S+ 13:28 0:00 /bin/bash

Notice the screen session. If you go into screen you will see the following.
[+] 202.161.45.177
[+] 202.162.217.59
[+] 202.162.217.57
[+] 202.162.217.56
[+] 202.162.217.58
[+] 202.162.217.60
[+] 202.162.217.61
[+] 202.162.77.52
sh: fork: Cannot allocate memory
[+] 202.162.78.9
[+] 202.162.77.36
sh: fork: Cannot allocate memory
[+] 202.162.78.8
sh: fork: Cannot allocate memory
[+] 202.162.77.25
sh: fork: Cannot allocate memory
[+] 202.162.78.59
sh: fork: Cannot allocate memory
[+] 202.164.172.195
[+] 202.164.172.197
sh: fork: Cannot allocate memory
[+] 202.164.189.226
[+] 202.164.189.225
[+] 202.164.189.228
sh: error while loading shared libraries: libtermcap.so.2: failed to map segment from shared object: Cannot allocate memory
sh: fork: Cannot allocate memory
[+] 202.165.247.91
[+] 202.167.231.47
[+] 202.167.231.46
[+] 202.168.64.111
[+] 202.168.64.110
[+] 202.170.120.224
[+] 202.170.120.225
[+] 202.170.122.83
[+] 202.170.126.52
[+] 202.170.127.103
[+] 202.170.127.76
[+] 202.170.127.66
[+] 202.170.127.73
[+] 202.170.127.9
[+] 202.170.127.84
[+] 202.170.38.231
[+] 202.171.133.31
[+] 202.171.136.198
[+] 202.171.136.195
[+] 202.171.136.205
[+] 202.171.136.214
[+] 202.171.136.217
[+] 202.172.169.16
[+] 202.172.169.42
[+] 202.172.169.18
[+] 202.172.32.144
[+] 202.172.32.223
[+] 202.173.130.5
[+] 202.173.138.29
[+] 202.173.141.190
[+] 202.173.142.160
[+] 202.173.140.192
[+] 202.173.151.16
[+] 202.173.180.34

I tar'd up the files this time from /usr/books and sent them again to ward for anyone who wants them.
__________________
Tony Lewis
Schmooze Com, Inc./FreePBX Dev Team
Reply With Quote
  #25  
Old 08-12-11, 05:42 PM
wardmundy wardmundy is offline
Nerd Uno
 
Join Date: Oct 2007
Posts: 6,055
Originally Posted by malcolmd View Post
And to Apache 2.2.3-43...

The CVE here:
http://www.cvedetails.com/cve/CVE-2011-0419/

Points to:
http://rhn.redhat.com/errata/RHSA-2011-0507.html

on the RedHat site, which indicates that their fix was made to apr-1.2.7-11.

...both of which we're distributing with *now.

So, as ezekielmudd mentioned, maybe Apache / APR isn't the right direction?
Reviewing the notes, it doesn't appear that these would compromise a system other than creating a Denial of Service condition. We still need to figure out how they're getting in. We seem to have a pretty good handle on what's going on once they arrive.
Reply With Quote
  #26  
Old 08-12-11, 06:51 PM
ezekielmudd ezekielmudd is offline
Junior Member
 
Join Date: Jan 2009
Location: Calgary, Canada
Posts: 17
That machine is totally compromised. It's a goner.

They're exploiting exim - the mail program. Check out this slashdot article: http://it.slashdot.org/story/10/12/1...it-In-the-Wild

Bite the bullet and take that machine off line immediately!

You can just shut down the outward facing eth0 or eth1 if you want to do a forensic examination the system while sitting in front of the machine.

The hacker is using a file called "x.pl" to do nasty things. Find it and delete it. That will clean up the stuff you can see.

If it were me, I'd format the disk and reinstall the most recent version of the OS.
Reply With Quote
  #27  
Old 08-12-11, 07:26 PM
phoneguy phoneguy is offline
Member
 
Join Date: Jan 2008
Posts: 71
Just for clarification they did not have exim installed on the system that got hacked just so nobody things the machine got hacked through exim. They were just trying to hack into other machines that had exim running.
__________________
Tony Lewis
Schmooze Com, Inc./FreePBX Dev Team
Reply With Quote
  #28  
Old 08-12-11, 11:03 PM
ezekielmudd ezekielmudd is offline
Junior Member
 
Join Date: Jan 2009
Location: Calgary, Canada
Posts: 17
Ah, my mistake. Sorry about that Chief.

My money is back on the phpmyadmin exploit then.

I've experienced that one personally.
Reply With Quote
  #29  
Old 08-13-11, 06:14 AM
wardmundy wardmundy is offline
Nerd Uno
 
Join Date: Oct 2007
Posts: 6,055
Here's Where We Are
Vulnerability: Any stock CentOS 5.x or 6.x system with Apache and PHP exposed to Internet access with no IP address restrictions (WhiteList).

UPDATED: See this post for the latest information. It appears that the security hole may be limited to 64-bit Linux systems as well as Proxmox servers with OpenVZ support.

How Do They Get In: Some (perhaps unknown) vulnerability in stock versions of Apache and PHP on CentOS systems allows the attacker to gain system access. We really don't know any more than that at this juncture. But this does not appear to be a PHPmyAdmin exploit as that utility is locked down by secure htaccess password on some systems that have been compromised. Fail2Ban is not detecting hack attempts so it appears the attacker is walking right in with this exploit.

Privileges: Still unclear whether attacker is gaining root access or merely same access as enjoyed by Apache on the attacked system. To do what they're doing would NOT require root privileges on your system. The attacker brings a customized version of WebMin with their own password.

What Happens Once They're In: In a nutshell, your system is turned into a zombie. Using perl and WebMin (their own version), they can interconnect your server into a worldwide network of machines used to launch denial-of-service and other malicious attacks against other systems on the Internet.

How Do I Know If My Machine Has Been Compromised? Examine some of the previous comments in this thread. Run ps awx on your server and look for long lists of processes running perl scripts. Look in the /usr directory for a directory called game, games, books, etc. Inside those directories, run ls -all which will show hidden files beginning with a period. There will be a directory called .n or .s or something similar. Look in /etc/cron.daily. There will be a new script as outlined in this thread. NOTE: The zombie software is old and signatures already exist in anti-virus programs. The exploit to gain access may be entirely new.

What Should Be in /usr? On a stock PIAF system, you should see the following directories:

bin games kerberos libexec man share tmp etc include lib local sbin src X11R6

The games directory will be empty when you ls -all

What Should Be in /etc/cron.daily? On a stock PIAF system, you should see the following files:

0anacron cups makewhatis.cron prelink tmpwatch 0logwatch logrotate mlocate.cron rpm


How to Fix It: If your system has been compromised, reformat the disk and reinstall. If they haven't gotten in or if you've started over, (1) immediately turn off Internet access to web services on your servers. You can implement a whitelist of safe IP addresses for web access using IPtables or your hardware-based firewall. We will post a HOW-TO shortly. (2) Upgrade Apache to latest version and PHP to latest 5.2 or 5.3 version. For PIAF users, we are working on an upgrade which should be available in the next couple days. It's not easy!

NOTE: Just because your system has not yet been compromised does NOT mean you are safe. Your system still needs to be secured. Turn OFF Web Access Now!

For Standard PIAF servers and Proxmox PIAF installs ONLY:

How to Temporarily Disable Web Access: Log in as root. Issue command: iptables -D INPUT -p tcp -m tcp --dport 80 -j ACCEPT

How to Temporarily Enable Web Access: Log in as root. Issue command: iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

How to Temporarily Enable Web Access for Specific IP Address : iptables -A INPUT -p tcp -m tcp -s 123.45.67.8 --dport 80 -j ACCEPT

NOTE: These settings only work on stock PIAF servers, not hosted systems such as RentPBX. These settings are temporary until a reboot or service iptables restart.

For RentPBX-hosted PIAF servers ONLY:

How to Temporarily Disable Web Access: Log in as root. Issue command: iptables -D RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

How to Temporarily Enable Web Access: Log in as root. Issue command: iptables -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

NOTE: These settings only work on RentPBX PIAF servers, not standard PIAF systems. These settings are temporary until a reboot or service iptables restart.

Last edited by wardmundy : 09-01-11 at 05:19 PM.
Reply With Quote
  #30  
Old 08-13-11, 07:13 AM
alesko alesko is offline
Guru
 
Join Date: Jan 2011
Posts: 22
One question - is it possible to be more secured with HTTPS and if the HTTPS is accesses from different port then 80 or 443 from the outside?
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 11:49 PM.


Design by Vjacheslav Trushkin, color scheme by ColorizeIt!.
Powered by vBulletin®
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2007-2012, Ward Mundy & Associates