Subject: another breakin
Date: Fri, 18 Mar 2005 11:51:35 -0500
From: * *
To: "Joseph Chung" <jchung@monmouth.edu>
Joe, I found that the bluehawk server had two processes
named "uselib24" - which is apparently an exploit for the uselib()
syscall. The webserver user was running it - so I need to figure out
how they got the webserver to run a program to begin with.
Date: Fri, 18 Mar 2005 13:49:35 -0500
From: Joe Chung <jchung@monmouth.edu>
To: * *
Subject: Re: another breakin
On Fri, Mar 18, 2005 at 11:51:35AM -0500, * * wrote:
> Joe, I found that the bluehawk server had two processes
> named "uselib24" - which is apparently an exploit for the uselib()
I played around with the published exploit when it first came out
(http://isec.pl/vulnerabilities/isec-0021-uselib.txt; just compiled it
and ran it as jchung). If successful, it's supposed to give you a
root shell. I was not able to get a root shell on rockhopper or the
Linux lab machines with this exploit.
According to a modified published exploit which is what uselib24 is
(http://packetstorm.linuxsecurity.com/0501-exploits/uselib24.c),
this'll only work on the 2.4 series of kernels. bluehawk was on
2.6.10-something, right?
> syscall. The webserver user was running it - so I need to figure out
> how they got the webserver to run a program to begin with.
So it was running as the 'web' user, right? Could it have been someone
local cracking passwords? bluehawk:/etc/passwd looks like a port from
Irix.
Have you seen
https://www.redhat.com/archives/fedora-list/2005-March/msg00594.html
yet?
LOG_EMERG A panic condition. This is normally broadcast to all
users.
LOG_ALERT A condition that should be corrected immediately,
such as a corrupted system database.
LOG_CRIT Critical conditions, e.g., hard device errors.
LOG_ERR Errors.
LOG_WARNING Warning messages.
LOG_NOTICE Conditions that are not error conditions, but should
possibly be handled specially.
LOG_INFO Informational messages.
LOG_DEBUG Messages that contain information normally of
use only when debugging a program.
LOG_KERN Messages generated by the kernel. These cannot be
generated by any user processes.
LOG_USER Messages generated by random user processes. This is
the default facility identifier if none is specified.
LOG_MAIL The mail system.
LOG_DAEMON System daemons, such as telnetd, ftpd, rshd,
etc.
LOG_AUTH The authorization system: login, su, getty,
etc. ftpd, and rshd also use LOG_AUTH.
LOG_LPR The line printer spooling system: lpr, lpd, etc.
LOG_LOCAL0 Reserved for local use. Similarly for LOG_LOCAL1 through
LOG_LOCAL7.
/ A filename (beginning with a leading slash). The file will be opened
in append mode.
@ A hostname preceded by an at sign (``@''). Selected messages are
forwarded to the syslogd on the named host.
Letter A comma-separated list of users. Selected messages are written to
those users if they are logged in.
* An asterisk. Selected messages are written to all logged-in users.
/var/log/messages
The messages file holds information that prints to the console.
These might include root logins and su attempts.
/var/log/lastlog
This file holds the most recent login time for each user in the
system. On some systems this is a directory with each user stored
as a single record. The directory hold a record for each person
that has ever logged in. It can be used to track login records.
The utmp and wtmp files
The utmp file is where information such as the terminal line, login
time, and command executing are stored for access by the who
command. The wtmp keeps track of logins and logouts since reboot.
The command last reads that file and processes the information.
/var/adm/acct (Solaris)
This is the system accounting file. If enabled, the accounting file
records a record for every process listing the following
information:
+ username who ran the command
+ name of the command
+ CPU time used
+ completion timestamp of the process
+ Flag indicating completion status
Accounting information can be very useful in monitoring who is
doing what on your system. In addition, by summarizing accounting
to develop cummulative statistics you can often build a case for
upgrading the system.
/var/adm/sulog (Solaris)
The sulog file holds records for everyone that has su'ed on the
system.
/var/log/lp-errs or /var/spool/lpd
Many sites direct the SYSLOG output for the lpd (printing)system
to this file. This file is then monitored for problems.
sudo groupadd wheel
sudo nano /etc/group
or by running the usermod command:
sudo usermod -G wheel username
On belushi, the wheel group is defined as follows:
wheel:x:1002:jchung
# See old owners, permissions
ls -l /bin/su
# Change owners, permissions
sudo chgrp wheel /bin/su
sudo chmod o-rx /bin/su
sudo chmod u+s /bin/su
# See new owners, permissions
ls -l /bin/su
-rwsr-x--- 1 root wheel 40168 May 17 2017 /bin/su
sudo john -wordlist:/usr/share/dict/american-english-huge /etc/shadow
# modified by jchung, 4/2018 # retain hourly 6 retain daily 7 retain weekly 4 retain monthly 12
# m h dom mon dow command # rsnapshot jobs, jchung, 4/2018 0 0 * * * /usr/bin/rsnapshot daily 0 1 * * 0 /usr/bin/rsnapshot weekly 0 2 1 * * /usr/bin/rsnapshot monthly
On your VMs, check for and try to mitigate vulnerability to the Meltdown/Spectre vulnerability.
We will download and run a published vulnerability checking script (spectre-meltdown-checker.sh).
The kernel version you are currently running on your VMs is 3.16.0-4-amd64, per the output of 'uname -a'. The spectre-meltdown-checker.sh script will report that your VM is vulnerable to the Meltdown exploit. To mitigate the Meltdown vulnerability, you will need to upgrade to a newer kernel.
To upgrade to a new kernel, run the following commands to upgrade packages, including available kernel upgrades:
sudo apt-get update sudo apt-get dist-upgrade
One of the packages will be a newer version of the kernel (3.16.0-5-amd64). To use the new kernel, you will need to reboot with
sudo reboot
After reboot, verify that your VM is running kernel version 3.16.0-5-amd64, and then run the spectre-meltdown-checker.sh script again to verify that your system is no longer vulnerable to Meltdown.