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.

Hi, so the next question is: If I run only SSH 2 daemon but with sshd_config Option "Protocol 2,1 " for compatibility - is it vulnerable? Annette Sysadmin IfM Technical University Berlin Germany

Boris Lorenz ---

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

Ralf Koch wrote:

Hi,

the main question is, if your SSH daemon is vulnerable.

The option "Protocol 2,1" sets only the preferred version to SSH2. You're allowed to connect with SSH1 too.

Cheers,

Ralf

Hi, we updated to rpm package openssh-2.9p1-17 on all our Linux boxes some days ago and I think: This is a SSH2 Daemon. Isnt it? Is it vulnerable? Its possible that the last incident just came trough the SSH1 vulnerability. Another question: Is duarawkz only a Linux hackertool? Maybe some enthused hackers ported it to other platforms? I have still some SSH1 unix platforms here. Bye, Annette

On Wed, 21 Nov 2001, Annette Jaekel wrote:

Hi, so the next question is: If I run only SSH 2 daemon but with sshd_config Option "Protocol 2,1 " for compatibility - is it vulnerable? Annette Sysadmin IfM Technical University Berlin Germany

It sure is. The cracker will connect pretending not to be able to do protocol 2, and your system will obligingly pull out the (vulnerable) protocol 1 for her. Bear

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 ---