# freshly hacked

## SouthOfHeaven

just this morning i noticed my net activity at a solid 70% then found this

ps -edf | grep httpd

apache   31085     1  0 04:25 ?        00:00:00 ./.httpd

apache   31622     1  0 09:14 ?        00:00:45 ./httpd -b .update.conf

seems lke its something called iroffer thats been thrown in, found it in /tmp/.update had a few things uploaded as i checked the files in the directory, obviously seems like a scriptkiddies job, have to take down this box and rebuild now, no telling in how much info might of been downloaded. Any ideas on what else i can look at ?Last edited by SouthOfHeaven on Sat Feb 12, 2005 4:02 pm; edited 1 time in total

----------

## xlulux

how dyou think they got in? i like forensic analising but this kinda sucks man im sorry

----------

## gurke

wow, they might have caused a lot of traffic. if they got shell access, you might check history files. also check logs (your httpd, etc.).

----------

## xming

seeing that the httpd is running as user apache (and I suppose your apache or apache2 is running as user apache too), I think they used some know exploits of php packages (maybe phpBB?).

I hope they only got that far and I hope you are running the latest kernel without local root vunerabilities.

xming

----------

## gentoo_lan

You need to use a chrootkit and see the extent of the damage. If your root password has been exploited you will have to format your hard drive and start all over.

----------

## transient

Take the opportunity to see, if possible, how they did it too. This will allow you to setup your system more securely next time.

The fact theres stuff dumped in /tmp screams of scriptkiddy, as the vast majority of exploits rely on an executable /tmp dir to work their magic.

Yet more info that its scriptkiddies... iroffer is a fileserver for IRC. Most likely your box was intended to become either a warez dump for pr0n, movies etc... or you may also have an IRC server running on your box.

If iroffer hasnt been run yet, then its likely they dont have the root password, as it requires root access to bind to its port.

However, that 70% or so traffic leads me to believe that it has been run, and mabye was running a while ago.

If youre interested, you could probably have some great fun with this, by letting it run and watching all the traffic through something like ethereal, and quite probably watch some interesting conversations  :Razz: 

Could you post what services you are running? Ie, httpd versions, ssh server if any etc...

----------

## SouthOfHeaven

Sorry i didnt reply quicker but text mode Browsers arent that much fun  :Smile: . 

I reformated the system and started over again, backup all the logs and other things incriminating. Funny thing is that this iroffer provides user and password to the irc network it latches on to and i was able to keep that info, havent gotten around to look at the logs. I am thinking it was done throgh an exploit in CPG Nuke, as far as i know php it uses /tmp to upload so thats how im guessing it got into /tmp other then that only one inactive user  in /home was compromised since i forgot to remove read permissions for other in their home dir, and unfortunately i had a symlink in there to my big few hundred gig personal drive there. The one thing i cannot understand is how it was able to execute the file it uploaded. That is what made me realize its time to rebuild. All signs point to scripkiddiot tho, will be looking forward to parsing the logs. I mean luckily there is a db with all the users logged in and their coresponding ips and time of log in then match that with apache logs see which client ip tried to access the certain upload feature of the board and voila we have an ip , contact ISP and authorities declare losses etc and let the fun begin.

Any other info is greatly appreciated from you guys. Still my main dilema has got to be how the uploaded file was executed, unless in fact it was an exploit in PHP not in the actual CPGNuke CMS.

----------

## transient

Unfortunately, you wont be able to make anything stick if youve formatted the computer. Even with backups of the logs etc.. its easy to claim that those backups are forged.

----------

## SubAtomic

```
emerge chkrootkit
```

Here's a script which can give you a little more info about your network status.

```

#!/bin/bash

echo -e

echo -e "                ### --- Network Status Scan --- ###"

echo -e --------------------------------------------------------------------------

echo -e who -a ...

echo -e

/usr/bin/who -a

echo -e

echo -e --------------------------------------------------------------------------

echo -e /bin/netstat -pluant ...

echo -e

/bin/netstat -pluant

echo -e

echo -e --------------------------------------------------------------------------

echo -e /bin/netstat -nr ...

echo -e

/bin/netstat -nr

echo -e

echo -e --------------------------------------------------------------------------

echo -e /sbin/iptables -L ...

echo -e

/sbin/iptables -V

/sbin/iptables -L

echo -e

echo -e --------------------------------------------------------------------------

echo -e /usr/bin/nmap -sT -T Insane localhost ...

echo -e Notes:

echo -e "     (sT) TCP connect() port scan"

/usr/bin/nmap -sT -T Insane localhost

echo -e

echo -e --------------------------------------------------------------------------

echo -e /usr/bin/nmap -sS -sU -sV -sR -O -vv -c -T Insane localhost ...

echo -e Notes:

echo -e "     (sS) TCP SYN stealth port scan"

echo -e "     (sU) UDP port scan"

echo -e "     (sV) Version scan probes open ports determining service & app names/versions"

echo -e "     (sR) RPC/Identd scan (use with other scan types)"

echo -e "     (O)  Use TCP/IP fingerprinting to guess remote operating system"

echo -e "     (vv) verbose verbose"

echo -e "     (c)  Counting stats"

echo -e "     (T) <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> General timing policy"

/usr/bin/nmap -sS -sU -sV -sR -O -vv -c -T Insane localhost

echo -e

echo -e --------------------------------------------------------------------------

echo -e /usr/sbin/chkrootkit ...

echo -e

/usr/sbin/chkrootkit

echo -e

```

Portscanning from another machine would produce better results.

NOTE: If you are running portsentry, chkrootkit may detect this ... INFECTED (PORTS:  1524 31337).

If this really worries you (port 31337 used to be used for Backorifice) you can drop all traffic on that port with iptables ...

```
# Port 31337 used by Portsentry (execute 'fuser 31337/tcp' and check)

# Portsentry produces *** NO OUTBOUND TRAFFIC ***

# Back Orifice also uses this port

# Ultra paranoia *** BLOCK TRAFFIC on port 31337 ***

$IPTABLES -A OUTPUT -o $EXTIF -p tcp --dport 31337 -j DROP

$IPTABLES -A OUTPUT -o $EXTIF -p tcp --sport 31337 -j DROP

```

... where $IPTABLES is the location of your iptables executable (/sbin/iptables in my case) and $EXTIF is your outbound interface.

If you want to get into the forensic side of things, you could set up Snort, snortsam and ACID/BASE, prelude and piwi, sguil and sguild and syslog-ng and php-syslog-ng. Use webalizer to monitor your apache stats. You could then setup a honeynet or something a bit simpler with honeyd. Use snort and bait-n-switch to bring it all together. 

WARNING: This stuff can get very addictive.

----------

## linux_girl

my 2cents check  security update of all your open services then dig into evry log to find someting like : "hey some one deleted something from the log"

```

$last

```

to check logins date and from where !

----------

## CodAv

Some tips for increasing security on a PHP powered web server:

Activate safe_mode restriction in php.ini

Set safe_mode_exec_dir to an empty directory, writeable only by root

Set an open_basedir for each Apache VHost. You can do this via the php_admin_value directive.

Mount /tmp with noexec, nodev and nosuid flags. In most cases, a simple tmpfs ramdisk with a maximum size of 100 MB should be enough. Just insert this line into /etc/fstab, and do a "mount /tmp" afterwards:

```
tmpfs                   /tmp            tmpfs           nodev,noexec,nosuid,size=100M,mode=1777      0 0
```

If a scriptkiddie still manages to drop a file in /tmp, there is no way to execute it.

Make yourself familiar with SSL private/public key authentication, and disable tunneled clear text passwords in your sshd configuration. This eliminates the risk weak passwords pose to your system.

Add a cronjob which runs chkrootkit on a daily basis and mails any findings to you.

Stay up to date and use glsa-check regularily  :Wink: 

----------

## alex6z

Really, you don't have to rebuild your box! Most likely all that happened what there was some exploit to apache/PHP or the like and they gained access to your apache user account.  It's no big deal all you have to do it kill all process with apache as their user and do a search for all files owned by apache and maybe delete them.  Then you can go about updating whetever it was that was exploitable.  Check your system log or apache log do see what process crashed if you can.

----------

## troymc

 *alex6z wrote:*   

> Really, you don't have to rebuild your box! Most likely all that happened what there was some exploit to apache/PHP or the like and they gained access to your apache user account.  It's no big deal all you have to do it kill all process with apache as their user and do a search for all files owned by apache and maybe delete them.  Then you can go about updating whetever it was that was exploitable.  Check your system log or apache log do see what process crashed if you can.

 

Sorry, there is no simple solution to being hacked.  The ONLY way to re-instate trust in this system is to wipe it & rebuild from scratch and mark all backups as tainted. And to take the steps now to secure it, that you didn't take before.

If they can execute any code on your system, they could have just as easily executed some kind of privilege escalation tool. Just because you only see stuff running as apache, don't assume that's all there is.

troymc

----------

## alex6z

troymc wrote: 

Sorry, there is no simple solution to being hacked. The ONLY way to re-instate trust in this system is to wipe it & rebuild from scratch and mark all backups as tainted. And to take the steps now to secure it, that you didn't take before. 

If they can execute any code on your system, they could have just as easily executed some kind of privilege escalation tool. Just because you only see stuff running as apache, don't assume that's all there is. 

I am assuming that a user in your system can't gain access to the root account.  There hasn't been a local root exploit in the kernel for quite a while, and they don't have access to X11 to try to exploit it because they are not local users(in most cases). It is quite rare that a local user can become root from within the system compared to some phpBB exploit.

	This said, that it's harder to exploit your way to root once in the system than it is from the outside, people should be more worried having root services running and not so worried about things like ntpd and apache that use a safe user account.

.

	It seems that becasue someone has executed code under a non privileged account you think it is necessary to rebuild the whole system.  According to this logic anyone that is running any service should rebuild their box because there might have been some remote root exploit!  Should all users running sshd rebuild their box because it *might* have been exploited even though there are no known working exploits?  Should anyone that has a box where someone gained access to a non priveleged UID rebuild their box even though there are no known working exploits in the linux kernel and they probably don't have any dangerous SETUID programs?

----------

## troymc

 *alex6z wrote:*   

> 
> 
> I am assuming that a user in your system can't gain access to the root account.  There hasn't been a local root exploit in the kernel for quite a while, and they don't have access to X11 to try to exploit it because they are not local users(in most cases). It is quite rare that a local user can become root from within the system compared to some phpBB exploit.
> 
> 

 

We obviously have different philosophical approaches to security. You make many assumptions throughout your whole post which I would consider to be very dangerous. In a security situation, I will always prefer to err on the side of caution.

 *alex6z wrote:*   

> 
> 
> This said, that it's harder to exploit your way to root once in the system than it is from the outside
> 
> 

 

Sorry, this is simply not true. From the outside the only targets you have are the network services available, from inside your targets are every possible binary, every file/dir permissions, every running service, etc.  You can see configuration files, view network activity, examine disk contents, etc.

 *alex6z wrote:*   

> 
> 
> It seems that becasue someone has executed code under a non privileged account you think it is necessary to rebuild the whole system.  According to this logic anyone that is running any service should rebuild their box because there might have been some remote root exploit!  Should all users running sshd rebuild their box because it *might* have been exploited even though there are no known working exploits?  Should anyone that has a box where someone gained access to a non priveleged UID rebuild their box even though there are no known working exploits in the linux kernel and they probably don't have any dangerous SETUID programs?
> 
> 

 

To play your game against you: Since my home server is not vulnerable to any known exploits, why do I need any active security on it at all? I can just turn off the firewall, tripwire, & snort. Why do all that work, when I am not vulnerable to anything?

No, we can invent all the extreme conclusions we want but Reductio ad Absurdum will not work here.  What I stated was:  for a system in which there has been a breach of trust (ie hacked), the only way to re-instate that trust would be to wipe & reload.  As long as you have trust in the box, there is no need to do anything.

troymc

----------

## alex6z

All I'm saying is that it is unlikely that the person that got into the apache account was able to get access to the root user. There are 4 ways to do this: 1) Exploit Linux or a module 2) Exploit a setuid binary 3) Exploit a UID 0 service that is normally firewalled from the outside. 4) Take advantage of a misconfiguration like insecure filesystem access permissions.

	It seems to me that having something like ftpd, sshd or telnetd running (accessable from the outside) is more likely to be a method of gaining root permissions than having a program running under a normal user account on the system.

	I'm thinking about taking my 133MHz box and making it into a public shell server (with good firewall protection to prevent irc spamming etc. on my router) and letting people login and see if they can hack into the root account  :Smile: .

----------

## orange_juice

 *CodAv wrote:*   

> Make yourself familiar with SSL private/public key authentication, and disable tunneled clear text passwords in your sshd configuration. This eliminates the risk weak passwords pose to your system.
> 
> 

 

Is it indeed SSL or SSH private/public key authentication, or both?

Kind regards,

orange_juice

----------

## maineus

Try an antispyware program.

----------

## vibrokatana

I believe there was a hint awhile ago to remove execution from the tmp directory, seems to stop alot of the upload exploits

----------

