SEO

Hello,

I was writing a script yesterday that goes and searches popular shell
locations and within those all shells and reports ls -l output on them.

What it produced concerned me. In two locations, the bourne sh has two
different file sizes.

Now CERT usually reccommends that you compare the system against known
media. How exactly is this done? I have the distribution on CD, and
have superuser access to the system. My thought was that I'd print the
output of the script, go to the server room and pull the server down
into single user mode, mount the CD, and (hopefully I could then) do a
long listing of the sh binary to see what the actual size was.
Actually, I thought I would find a way to print the binary sizes on CD,
so I could just search the entire system for incorrect file sizes.

Problem2: If there is a trojan in the system, what is the most
effective step by step way to reload the original binaries? I dont
necessarily want to reinstall the OS, and all backups are now suspect.

What do I do?

Thanks.

James wrote:
> Hello,
>
> I was writing a script yesterday that goes and searches popular shell
> locations and within those all shells and reports ls -l output on them.

Google tripwire.

>
> What it produced concerned me. In two locations, the bourne sh has two
> different file sizes.

Could be a problem. Could just be a mess someone made.

>
> Now CERT usually reccommends that you compare the system against known
> media. How exactly is this done?

Frequently via a digest (e.g., sum, md5)

> I have the distribution on CD, and
> have superuser access to the system. My thought was that I'd print the
> output of the script, go to the server room and pull the server down
> into single user mode, mount the CD, and (hopefully I could then) do a
> long listing of the sh binary to see what the actual size was.

The size isn't necessarily a good indicator.

Again, "google tripwire"

> Actually, I thought I would find a way to print the binary sizes on CD,
> so I could just search the entire system for incorrect file sizes.
>
> Problem2: If there is a trojan in the system, what is the most
> effective step by step way to reload the original binaries? I dont
> necessarily want to reinstall the OS, and all backups are now suspect.

If you've been compromised, disconnect the system from the network,
try to find out *how* it was done, re-install the entire system from
media and fix the hole before reconnecting.

On 2006-05-06, James <djcameron60616@yahoo.com> wrote:
> Hello,
>
> I was writing a script yesterday that goes and searches popular shell
> locations and within those all shells and reports ls -l output on them.
>
> What it produced concerned me. In two locations, the bourne sh has two
> different file sizes.

Likely one built statically linked & the other not.

What does 'ldd' say for each one?


--
"Other people are not your property."
[email me at huge [at] huge [dot] org [dot] uk]

On Sat, 06 May 2006 16:29:43 GMT, base60 <nobody@whitehouse.com>
wrote:

>James wrote:
>> Hello,
>>
>> I was writing a script yesterday that goes and searches popular shell
>> locations and within those all shells and reports ls -l output on them.
>
>Google tripwire.
>
>>
>> What it produced concerned me. In two locations, the bourne sh has two
>> different file sizes.
>
>Could be a problem. Could just be a mess someone made.
>
>>
>> Now CERT usually reccommends that you compare the system against known
>> media. How exactly is this done?
>
>Frequently via a digest (e.g., sum, md5)
>
>> I have the distribution on CD, and
>> have superuser access to the system. My thought was that I'd print the
>> output of the script, go to the server room and pull the server down
>> into single user mode, mount the CD, and (hopefully I could then) do a
>> long listing of the sh binary to see what the actual size was.
>
>The size isn't necessarily a good indicator.
>
>Again, "google tripwire"
>
>> Actually, I thought I would find a way to print the binary sizes on CD,
>> so I could just search the entire system for incorrect file sizes.
>>
>> Problem2: If there is a trojan in the system, what is the most
>> effective step by step way to reload the original binaries? I dont
>> necessarily want to reinstall the OS, and all backups are now suspect.
>
>If you've been compromised, disconnect the system from the network,
>try to find out *how* it was done, re-install the entire system from
>media and fix the hole before reconnecting.

At the risk of pointing out the obvious, keep in mind that on most
Unices there are normally two different versions of the sh binary (and
HP-UX is no exception).

The first, located in /sbin/sh is statically linked and used as the
default root shell as well as the shell normally used by most startup
scripts. It is statically linked so that there are no library
dependencies and thus no need to mount the /usr file system to have a
fully functional shell.

The second, located in /usr/bin/sh is the normal, dynamically linked
version.

Because one is statically linked and the other not, they will be of
very different sizes (and check sums).

In article <1146931718.961814.320370@i40g2000cwc.googlegroups .com>,
"James" <djcameron60616@yahoo.com> writes:
|>
|> I was writing a script yesterday that goes and searches popular shell
|> locations and within those all shells and reports ls -l output on them.
|>
|> What it produced concerned me. In two locations, the bourne sh has two
|> different file sizes.

On most Unices, 3-4 different sizes is normal!

The average Unix (not Linux) ships with anything from 2-5 different
'Bourne' shells, several of which are aliases for the system's preferred
Bourne-like shell, and most of which have subtly different behaviours.
/sbin/sh is often a statically linked 'true' Bourne shell, but I have
never found any consistency in the other ones.

Now, depending PRECISELY on how the system has been installed and
updated, it isn't uncommon for locations like /usr/bin/sh and /bin/sh
to get linked to or copied from different Bourne-like shells or
different versions of the same one.

Oh, joy.


Regards,
Nick Maclaren.

James wrote:

> Now CERT usually reccommends that you compare the system against known
> media. How exactly is this done? I have the distribution on CD, and

md5sum might be the easiest to use. You get checksums to compare.

> have superuser access to the system. My thought was that I'd print the
> output of the script, go to the server room and pull the server down
> into single user mode, mount the CD, and (hopefully I could then) do a
> long listing of the sh binary to see what the actual size was.

naah. The size is no secure indicator. You can always pad up a file to give
it the proper size ;-). You know chkrootkit?

> Problem2: If there is a trojan in the system, what is the most
> effective step by step way to reload the original binaries? I dont
> necessarily want to reinstall the OS, and all backups are now suspect.

???
If you are sure you are compromised you should first secure every evidence
for possible later investigation, try to find out how it was done (else you
might end up with the same problem half a day later), then do a reinstall.
No way to gurantee a clean system otherwise.

> What do I do?

Tell your honey you'll be doing overtime ;-)

--
"as appealing as it might seem, it is impossible to patch or upgrade users"
<Security Warrior>

On 2006-05-06, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
> In article <1146931718.961814.320370@i40g2000cwc.googlegroups .com>,
> "James" <djcameron60616@yahoo.com> writes:
>|>
>|> I was writing a script yesterday that goes and searches popular shell
>|> locations and within those all shells and reports ls -l output on them.
>|>
>|> What it produced concerned me. In two locations, the bourne sh has two
>|> different file sizes.
>
> On most Unices, 3-4 different sizes is normal!
>
> The average Unix (not Linux) ships with anything from 2-5 different
> 'Bourne' shells, several of which are aliases for the system's preferred
> Bourne-like shell, and most of which have subtly different behaviours.
> /sbin/sh is often a statically linked 'true' Bourne shell,

.... except when it's a Posix shell. (You try running a script that uses
a ^ for a pipe like could be done in original Bourne ...)

> but I have
> never found any consistency in the other ones.

Duh, in Tru64, you can get several different shells from the same binary
too.

> Now, depending PRECISELY on how the system has been installed and
> updated, it isn't uncommon for locations like /usr/bin/sh and /bin/sh
> to get linked to or copied from different Bourne-like shells or
> different versions of the same one.

And then there's the one that overwrites one of the shells with a
symlink to some other shell ...


--
Mikko Nahkola <mnahkola@trein.ntc.nokia.com>
#include <disclaimer.h>
#Not speaking for my employer. No warranty. YMMV.