Re: Bad protocol version identification '^V^C^A'

[Matt Harris <mdh@xxxxxxxxxxx>]

I believe a known issue regarding the ssh.com SSH server was released
within the past two or three weeks - it's probably being scanned for
pretty heavily.  Details were on bugtraq.  This is probably what this
is, if you're running OpenSSH you should be fine.  There's also that
pesky problem with OpenSSL which affected OpenSSH on a number of
platforms compiled using the vulnerable OpenSSL, it could be a scan
looking for that as well.  I get scanned a good 10 unique times a day, I
would assume most people get scanned quite frequently as well, so as
long as there're no signs of a system compromise, you shouldn't lose too
much hair over it.  Go through the motions, check the box for SSHD core
files, etc etc, and make sure the box is safe just to be sure.  Never
does hurt.  :-)
Also check to be sure that you're using the latest stable versions of
everything, especially your SSH servers and anything else [web servers,
etc] that may use OpenSSL and make sure that OpenSSL itself is updated,
and any binaries linked with it are suitably recompiled to use the
correct and safe version and all that good stuff.  

Bojan Zdrnja wrote:
> I suppose this is plain SSHD buffer overflow attack, followed by 'id'
> commands. Attacker tryed buffer overflow (which didn't succeed,
> according to logs) and after that he tried to execute 'id' commands to
> see if his attack worked (ie. If he managed to elevate his privileges).
> IIRC, SSH expects protocol identification as first data on the channel -
> attacker tried overflow and then 2 commands which SSHD interpreted as
> bad protocol identification.
> > In-Reply-To:
> > <1395.136.159.104.19.1038501745.squirrel@xxxxxxxxxxxxxxxxxxxxxxxx>
> >
> > I wouldn't worry too much about this.  These type of log events are
> > usually symbolic of some type of network scanner or brute
> > force scanner.
> > You can duplicate a similar log event by using nc or telnet
> > and connecting
> > to a 'ssh' server ( nc -vv hostAddress 22 ).  However, I would be
> > concerned with whatever service you have listening that are
> > identified in
> > you logs before the ip address of the remote connection ( ie /bin/id
> > and /usr/bin/id ...).  I would check to see what these
> > services are and if
> > you don't need them I would disable them as it may be possible that
> > someone is trying to exploit that service.
> >
> > jm

> > >
> > >Had the following entries in brought to my attention by
> > LogWatch this
> > >morning.
> > >
> > >Can anyone guide me to what they might be and if I need to
> > be concerned
> > >about them?

-- 
/*
 *
 * Matt Harris - Senior UNIX Systems Engineer
 * Smithsonian Institution, OCIO
 *
 */

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com