Yo phil & others, On 21-Nov-01 Annette Jaekel wrote:
Boris Lorenz wrote:
Yuppa,
On 21-Nov-01 Reckhard, Tobias wrote:
...
that a flaw in the SSH1 protocol has been used to break into the two said ^^^^^^^^^^^ ... There is a remote integer overflow vulnerability in several implementations of ^^^^^^^^^^^^^^^^^^^^^^ the SSH1 protocol that allows an attacker to execute arbitrary code with the ^^^^^^^^^^^^^^^^^
Note the (more or less subtle) difference.
Tobias
Que...?
Is it nit picking time already? Didn't know that, OMG! ;)
While we're at it, if you're running SSH protocol version 2 (in any implementation) *and* a vulnerable SSH protocol 1 demon, with a fallback to V1 for compatibilty with the lame old ssh1, you're vulnerable too, congratulations.
sorry phil, I can't quote your original message, since my pine decidet to be a
naughty piece of bytes, and ate your posting...
So, from the top of my head, your problem was that you had suffered from a
crc32 compensation attack, and now seem to have no control over the system
anymore, not even if logged in as root.
Well, let's separate two things here:
First, there's the crc32 attack, which exploits vulnerable implementations of
the SSH1 protocol, by overflowing the variable space of a 16bit integer, which
should have been a 32bit integer.
The result of this attack is a (remote) root compromise, since most (all?)
installations of sshd (1+2) run as root.
Second, it's up to the imagination/skill of the attacker(s) what to do next.
Typically, a rootkit will be installed, which trojanizes several binutils,
installs backdoors and whatnot. WHICH rootkit (if any) is active on your system
is a matter of further analysis. Finally, most attackers will try to clean the
logs of any suspicious entries.
The SuSE security FAQ at http://www.susesecurity.com/faq provides you with a
good starting point for your investigations. In short:
1.) Secure the scene
2.) Take the system offline
3.) Backup any logfiles, configs and other essential stuff
4.) Take a quick first look into all of your logs
5.) Check for rootkits, e. g. with chkrootkit from http://www.chkrootkit.org
6.) Create an image of the cracked fs (e. g. with "dd"), and let the Coroner's
Toolkit (TCT) utils inspect it (get TCT from http://www.fish.com/forensics )
7.) Look for "anomalities", which may include:
- strange log entries in messages, maillog, wtmp, lastlog, warn, etc.
- Unusual entries in .bashrc/.profile/.login in home dirs
- hidden files/directories
- unknown directories in /dev, /var, /home, /usr, /opt, /mnt, etc.
- unknown users in /etc/passwd or /etc/shadow
- strange entries in /etc/crontab, or user's crontabs
- setgid/setuid files
- network interfaces in promiscuous mode (sniffers)
- ...
TCT is a toolkit for forensic examinations ("WHO made WHAT, WHEN, and WHY"). It
collects any information it can find about a file system, and provides a basis
for further investigations, which comes in handy if your regular system logs
are insufficient. Beware, some TCT tools (namely unrm/Lazarus) run for several
hours, and need lots of disk space.
While TCT runs, read all its docs, and the additional info about the art of
forensic examination on www.fish.com/forensics. It's not about learning this
technique in one day, but a good place to start.
After the data collection is completed, browse the Coroner logs for said
anomalities. TCT also creates md5 checksums for every file, which could be
compared to known-clean files of the same SuSE distro.
If any of you crc32 victims need additional info, you may as well drop me a
private mail.
Boris Lorenz