HP-UX hacking program

[Jojo Castro]

Hi All,

Can anyone already encountered this type of file?

# ls -lrt *mhello*
---------- 1 root bin 70224 Aug 27 2004 mhello

This file when triggered by an ordinary user, were automatically switched to superuser "root."
I have already changed it to permission 000.

Thanks!

[Torsten.]

The file is owned by root, so somebody with root access has it installed. Why not remove it?

[Jojo Castro]

For investigation purpose, i did not yet. Its a binary file. Can anyone knows how to decode this?

[Ismail Azad]

Hi jojo,

What you have encountered is a typical bomb script. A script that helps out a hacker in the process of trying to get root access.

These are some typical lines you would see in a bomb script:-

chmod u+s /usr/bin/sh (On root's shell)
cp /usr/bin/sh /tmp/hidden_files

When these commands are executed on the roots shell, it implies that whenever someone executes what is in /tmp/hidden_files, a normal user gets root access. This is the base "idea" that is involved in the "mroe" script. Now comes the question, who would be stupid enough to execute these commands on the roots shell. Well this can be done otherwise as well! No more comments. Dont forget to assign points. :)

Regards
Ismail Azad

[Ismail Azad]

Hi,

You should have checked if this mhello thingy had the 's' in the ll output. Searching for the files that have the setuid bit set is also a critical aspect that has to scrutinized by a security administrator.

Regards
Ismail Azad

[Jojo Castro]

Hi Ismail,

herewith is the comparison

# ll /usr/bin/sh
-r-xr-xr-x 2 bin bin 582440 Sep 14 2005 /usr/bin/sh


# ll mhello
---------- 1 root bin 70224 Aug 27 2004 mhello


Originally, mhello permission is -rwsr-xr-x

[Jojo Castro]

If somebody is willing to decode what does this program do, im willing to share the file via email. thanks!

[Ismail Azad]

Yes,

You see the original mhello has the setuid bit set. The decoded form would have lines similar to what was typed in my previous post. But there are many ways to do this. That is why I said in future, as a security administrator use the find command and check for executables that have set uid permission.

Regards
Ismail Azad

[Torsten.]

The basic idea of such "hacking" is to use the possibility of misspelling or curiosity.
This is not a hacking guide!
A bad user could write a script doing some bad things and put it in a public writable place, for example named "ls-l" (this is what you type if you forgot to type space) or something similar. If root is now unexperienced and lazy enough to put "." in PATH, the script may be named like a real command too and it will be executed as root.
Work as root only if needed, check your PATH variable, don't execute commands you don't know ...

[Jose Mosquera]

Hi,

Use the command "what" to try to sniff inside of it:
#what /path/mhello

Sometimes the "strings" command could give hints about it.
#strings /path/mhello

If the script actually does what you say, the first thing you should do is put it in quarantine (rename it or move it) to certify that their absence does not impact on your production. Once this certificate you should consider changing the root password.

Rgds.

[Jojo Castro]

Hi Jose,

Herewith is the output

# what /usr/sbin/mhello
/usr/sbin/mhello:
# strings /usr/sbin/mhello
0su -

[Dennis Handly]

>Herewith is the output

What does "file /usr/sbin/mhello" show?

If this is an executable, the proper strings(1) command is:
strings -a /usr/sbin/mhello

[Jose Mosquera]

Hi again,

Please could you check if the /etc/shells file exists? And if true, please check if it contain the line:
/usr/sbin/mhello

Rgds.

[Matti_Kurkela]

># strings /usr/sbin/mhello
>0su -

Looks like it's a relatively simple binary, perhaps a statically linked one. It probably runs "su -" as root, to properly initialize the environment for the root user.

The output of these commands might reveal something more:

# file /usr/sbin/mhello
# ldd /usr/sbin/mhello
# strings -a /usr/sbin/mhello

The timestamp of the file won't necessarily mean anything: with root privileges, anyone can change file's timestamps. But if the intruder hasn't modified it, this file may have been on your system for quite a while.

If your hacker was smart, s/he has already set up multiple methods for regaining the root privileges, just in case you find and remove some of them. On the other hand, this *might* be the only one - but without knowing each and every OS file on your system, you cannot be absolutely sure. Therefore, the only way to be sure all the hacker's backdoors are removed is to completely re-install the OS from a known-good installation media, like an original printed HP installation CD.

You may want to backup the system before re-installation, for the purposes of evidence and possible data restoration. But you should never restore any configuration files, scripts or binaries from that backup, unless you can somehow verify that the files you restore haven't been modified by the hacker.

You should probably assume all the passwords used in this system are now known to the hacker and should be changed.

MK

[Jojo Castro]

hi dennis / Jose / Matti,

Attached herewith is the output of what, strings -a, file and ldd command for file /usr/sbin/mhello.
No /usr/sbin/mhello entry on /etc/shells.
Yes i think this was already planted quite sometime.
As of now, we are still observing what might the hacker want to do with the system.
And you are very right Matti, the onyl way to clear this is to fresh install or re-install from last good ignite backup.
As of now, we are using ipfilter to block all unecessary IP's being seen from our system.
Hope you could provide more information on my attachment.

Thanks!

[Jojo Castro]

# ldd mhello
libc.so.1 => /usr/lib/hpux32/libc.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1

Resending with the correct output from ldd command.

[Dennis Handly]

>Hope you could provide more information on my attachment.

From the unsats, it seems to call these:
system setgid setuid

So as MK said, it drops into root.

Use: elfdump -n .dynsym -s mhello

>MK: perhaps a statically linked one.

That's near impossible for customers to do that on Integrity.

>The timestamp of the file won't necessarily mean anything:

The internal timestamps indicate it was linked Feb 13 2010.

[Jojo Castro]

Hi Dennis, here is the output

# elfdump -n .dynsym -s mhello

mhello:

.dynsym:

Index Type Bind Other Sect Value Size Name

0 NOTY LOCL 0 UNDEF 0x00000000 0
1 SECT LOCL 0 0x1 0x04000000 0 __text_seg
2 SECT LOCL 0 0x10 0x40010000 0 __data_seg
3 SECT LOCL 0 0x1b 0x40010058 0 __thread_specific_seg
4 NOTY GLOB 0 0x1 0x04000000 0 __text_start
5 NOTY GLOB 0 0x12 0x40010000 0 __init_end
6 NOTY GLOB 0 ABSOL 0x00000000 0 __TLS_PREALLOC_DTV_A
7 NOTY GLOB 0 0x12 0x40010000 0 __init_start
8 FUNC WEAK 0 UNDEF 0x0423a400 0 system
9 NOTY GLOB 0 0xf 0x040009d0 0 _etext
10 FUNC WEAK 0 UNDEF 0x04224be0 0 setgid
11 FUNC WEAK 0 UNDEF 0x042250a0 0 setuid
12 NOTY GLOB 0 0x11 0x40010000 0 __hp_preinit_start
13 FUNC GLOB 0 0xf 0x040009d0 0 _etext_f
14 NOTY GLOB 0 0x14 0x40010000 0 __fini_end
15 NOTY GLOB 0 ABSOL 0x00000000 0 __TLS_INIT_START
16 NOTY GLOB 0 ABSOL 0x00000010 0 __profil_size
17 NOTY GLOB 0 ABSOL 0x00000000 0 __TLS_INIT_SIZE
18 NOTY GLOB 0 ABSOL 0x00000000 0 __SYSTEM_ID
19 NOTY GLOB 0 0x11 0x40010000 0 __hp_preinit_end
20 FUNC GLOB 0 0x1 0x04000000 0 __text_start_f
21 FUNC GLOB 0 UNDEF 0x04169600 0 ___exit
22 NOTY GLOB 0 ABSOL 0x00000000 0 __TLS_SIZE
23 NOTY GLOB 0 0x18 0x40010030 0 __gp
24 NOTY GLOB 0 ABSOL 0x40010058 0 _end
25 OBJT GLOB 0 0x3 0x04000220 0 _DYNAMIC
26 NOTY GLOB 0 ABSOL 0x00000000 0 __TLS_INIT_A
27 NOTY GLOB 0 0x8 0x04000790 0 __unwind_header
28 NOTY GLOB 0 0x10 0x40010000 0 __data_start
29 FUNC GLOB 0 0xe 0x04000880 208 main
30 NOTY GLOB 0 0x14 0x40010000 0 __fini_start
31 NOTY GLOB 0 0x17 0x40010035 0 _edata
32 NOTY GLOB 0 ABSOL 0x0000003f 0 _FPU_STATUS

[Jojo Castro]

Hi Dennis,

how did you saw this?

The internal timestamps indicate it was linked Feb 13 2010.

[Hakki Aydin Ucar]

additionally you can use HP Host IDS to keep track of users access to this file and this type of files..

[Bill Hassell]

> # ls -lrt *mhello*
> ---------- 1 root bin 70224 Aug 27 2004 mhello

If an ordinary:

ll mhello

does not show the program, the filename probably has invisible (control) characters in the name. Use -b to show special characters:

ll -b mhello

Now to determine who might be using the program, make a script like this:

#!/usr/bin/sh
logger -p user.warn "mhello was run by $(who -muR)"
exit

Now move the mhello program to another location and change the name to something you can remember. Whoever tries to use the program will be logged in syslog.log along with their hostname/IPaddr.

[Dennis Handly]

>here is the output
8 FUNC WEAK 0 UNDEF 0x0423a400 0 system
10 FUNC WEAK 0 UNDEF 0x04224be0 0 setgid
11 FUNC WEAK 0 UNDEF 0x042250a0 0 setuid
21 FUNC GLOB 0 UNDEF 0x04169600 0 ___exit

Those are all of the functions it calls.

>how did you saw this?

Right there in your "strings -a" output.
Or use:
elfdump -d mhello

[Jojo Castro]

Hi Dennis,

So all of these function calls correlate what this compiled actually do which is to "automatically switched as a superuser root." Regardless of what kind of user i am.

$./mhello
(c)Copyright 1983-2003 Hewlett-Packard Development Company, L.P.
(c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California
(c)Copyright 1980, 1984, 1986 Novell, Inc.
(c)Copyright 1986-2000 Sun Microsystems, Inc.
(c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology
(c)Copyright 1989-1993 The Open Software Foundation, Inc.
(c)Copyright 1990 Motorola, Inc.
(c)Copyright 1990, 1991, 1992 Cornell University
(c)Copyright 1989-1991 The University of Maryland
(c)Copyright 1988 Carnegie Mellon University
(c)Copyright 1991-2003 Mentat Inc.
(c)Copyright 1996 Morning Star Technologies, Inc.
(c)Copyright 1996 Progressive Systems, Inc.


RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause in DFARS 252.227-7013.


Hewlett-Packard Company
3000 Hanover Street
Palo Alto, CA 94304 U.S.A.

Rights for non-DOD U.S. Government Departments and Agencies are as set
forth in FAR 52.227-19(c)(1,2).
You have mail.

Value of TERM has been set to "xterm".
WARNING: YOU ARE SUPERUSER !!

[Dennis Handly · Accepted solution]

>So all of these function calls correlate what this compiled actually do which is to "automatically switched as a superuser root." Regardless of what kind of user i am.

Exactly, setuid setuid set you to root.
system("su -") fires off a root shell

[Jojo Castro]

Thanks to all for the clarifications specially to D.H.