5

Currently, I am doing a penetration testing laboratory with a server with the following services:

Nmap scan report for 10.0.11.125
Host is up (1.3s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 2.0.8 or later
22/tcp open  ssh     OpenSSH 5.8p1 Debian 7ubuntu1 (Ubuntu Linux; protocol 2.0)
Service Info: Host: Foo; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Currently, I have access to an FTP account (let's say username & password are the credentials for the in scope server).

In the FTP account I have the followings:

ftp> ls -al\
227 Entering Passive Mode (10,185,11,125,254,161).
150 Here comes the directory listing.
drwxr-xr-x    3 1003     1003         4096 Aug 05 01:31 .
drwxr-xr-x    3 1003     1003         4096 Aug 05 01:31 ..
-rw-r--r--    1 1003     1003          220 May 18  2011 .bash_logout
-rw-r--r--    1 1003     1003         3367 Aug 05 02:02 .bashrc
-rw-r--r--    1 1003     1003          690 Aug 05 02:13 .profile
drwxrwxrwx    2 1003     1003         4096 Aug 05 01:45 .ssh
226 Directory send OK.
ftp>

As you can observe I have uploaded a .ssh folder with the following contents.

ftp> cd .ssh
250 Directory successfully changed.
ftp> ls -la
227 Entering Passive Mode (10,185,11,125,112,156).
150 Here comes the directory listing.
drwxr-----    2 1003     1003         4096 Aug 05 01:45 .
drwxr-xr-x    3 1003     1003         4096 Aug 05 01:31 ..
-rw-------    1 1003     1003          408 Aug 05 01:34 authorized_keys
226 Directory send OK.

After that, I have tried to obtain access using the uploaded authorized_keys on the SSH protocol as such: 

proxychains ssh username@10.0.11.125
username@10.0.11.125's password:

Am I doing something wrong? How can I find the username of UID 1003?

Lucian Nitescu
  • 1,802
  • 1
  • 13
  • 27
  • 5
    i. you can bet whether the ftp user is the same as ssh user name. ii. you can always try to get /etc/passwd if the ftp server is badly configured – mootmoot Aug 09 '18 at 12:04
  • @mootmoot I will much appreciate a detailed answer as a final answer. Could you extend it? – Lucian Nitescu Aug 09 '18 at 12:13
  • likely it doesnt have ssh shell so it just allows ftp. for example in /etc/passwd this account is /bin/false – Aria Aug 09 '18 at 12:33
  • Well, that is the purpose of pentest, you need to test all possible weakness, the list is countless. You need to prepare the checklist for any mistake that can be made by a novice admin and expand the attack from there. (The answer will be too long, so I will prefer not to write an "answer") – mootmoot Aug 09 '18 at 12:46
  • 1
    Use `ssh -vv` to display debug info. SSH will refuse public key auth if the permissions for `.ssh` are too permissive... – ThoriumBR Aug 09 '18 at 18:52

2 Answers2

3

Your general Idea behind this is very good.

Some issues with this approach

In a best-case (or worst-case, depending which side you're on) scenario:

Authentication

  1. SSHD has key authentication enabled by having the PubkeyAuthentication set to yes in sshd_config
  2. The AuthorizedKeyFile is set to .ssh/authorized_keys (which is the default if I recall correctly).
  3. The FTP user has a valid shell in /etc/passwd like /bin/bash or /bin/sh

However:

  1. You might not have the right username. Getting the FTP Server version might be a good place to start to check for defaults. (like proftpd adds the proftpd user and group).
  2. Public key authentication might not be enabled at all, which means .ssh/authorized_keys is ignored completely.
  3. The AuthorizedKeyFile is in a custom location, allthough I haven't seen a lot of sshd's where it is.
  4. (a between-parentheses note: Some SSHD's require the authorized_keys file to have a 600 permission mask. This might also be an issue in your case, allthough I would assume different output).

Your problem specifically

My best guess is your problem is either However 1, or However 2, with equal probability. It seems that SSH Key Auth is not kicking in at all (SSHD doesn't seem to try to check Public key), which to me is an indication that there is no public key for the FTP user, or that public key authentication is disabled completely.

And your question

How can I find the username of UID 1003?

  • As mootmoot suggested in the comments, you could try to open files like /etc/passwd, if ACL's are incorrectly configured.

  • You could also try to bruteforce your luck by adding keys for common names, proftpd, like noted above, vsftpd, ftpd or just ftp are some popular ones.

  • If you have done proper recon and you got lucky, you might've gotten the ftp service name and version which could give you an idea of default users.

  • This could be achieved with nmap's -sV flag, or by grabbing the banner (if the configuration allows it).

As you can see, there's a lot that depends on the configuration and setup of the server. I'm sure there are some good resources available through Google that can give you more ideas like these (before this turns into a full essay :-))

Nomad
  • 2,359
  • 2
  • 11
  • 23
0

Your listing shows:

drwxrwxrwx    2 1003     1003         4096 Aug 05 01:45 .ssh

ssh is very picky about permissions; if you can reduce that 777 to 700 you may have better luck.

That doesn't mean any of the other answers also don't apply, but to me, that 777 just pops out and hits me in the eye.

  • By default, you're gonna have more luck with 600, I covered this in my answer (Point However 4) :-) – Nomad Aug 13 '18 at 16:51
  • 1
    Not quite. You mentioned the authorized_keys file, which in his listing did have 600 already. I was talking about the ~/.ssh *directory* itself, which in his listing was 777 (and I didn't see that covered in "However 4"). TBH, I just noticed that ThoriumBR's comment on the question does cover it. I must have missed that earlier. –  Aug 20 '18 at 18:40