[Byrdonawire]

In this post, we are going to be taking a look at SSRF and the possibilities with it.

we will need to know some terms:
LFD - local file download
LFI - local file inclusion
RFI - remote file inclusion
FIV - file inclusion vulnerability
SSRF - server side request forgery
DTA - directory traversal attack

Directory Traversal Attack

"http://example.com/index.php?file=../../../../etc/passwd"

A directory traversal attack resulting in the disclosure of /etc/passwd.

This is also obtained through SSRF, as we forged a request that seems to have come from the server. The PHP probably looks something like this:
fopen("../../../../../etc/passwd");
and since the server is the thing running fopen(); it is us that forges the request
SSRF -> DTA -> LFI



SSRF = just a request that we make the server do itself so it has server-level permissions on running it - this allows us to achieve LFI through SSRF -> DTA
Usually, it is the case that a SSRF vulnerability will allow for LFI.
SSRF -> LFI

SSRF can also lead to LFD, but the absolute majority of the time, you will only find either LFI or LFD, never both.

SSRF -> LFI
file:///etc/passwd

file:// is the URI schema

/etc/passwd is the file to request

In the last post, we talked about XXE -> SSRF -> LFI

Whereas this is simply SSRF -> LFI

The /etc/passwd file can sometimes be useful, but typically it is not. For instance, if we wanted to find the webroot for a webserver, in order to get a shell on the server. The majority of the time, the only thing stopping you is not knowing the webroot directory.

The /etc/passwd file will contain this information:
User name
Encrypted password
User ID number (UID)
User's group ID number (GID)
Full name of the user (GECOS)
User home directory
Login shell



So what do we do to find the webroot directory? Look for www-data user or apache* user or nginx* user or httpd user!

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0ync:/sbin:/bin/sync
shutdown:x:6:0hutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
avahi:x:70:70:Avahi daemon:/:/sbin/nologin
rpc:x:32:32ortmapper RPC user:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
sshd:x:74:74rivilege-separated SSH:/var/empty/sshd:/sbin/nologin
dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin
oprofile:x:16:16:Special user account to be used by OProfile:/home/oprofile:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
avahi-autoipd:x:100:156:avahi-autoipd:/var/lib/avahi-autoipd:/sbin/nologin
gdm:x:42:42::/var/gdm:/sbin/nologin
sabayon:x:86:86:Sabayon user:/home/sabayon:/sbin/nologin

Alright so this tells us that we have a very good chance at our webroot being somewhere in /var/www, and more than likely in /var/www/html or /var/www/htdocs.

Unfortunately, 99% of admins will not change their default webroot directory.

And the config for the SSH server in /var/empty/sshd

The include function in PHP is an important function to know how it works, include also supports basic SSRF vulnerabilities!

Another function to take note of is fopen(), because it supports DTA, and most SSRF for LFI, for example file:// and http://

[meow]

A few comments:

• /etc/p@sswd does not contain encrypted passwords unless you got access to a very, very, VERY outdated box (you are never going to find this). You are thinking of /etc/sh@dow, which can't be read without superuser privileges.
  
• there are SO many more things you can do with SSRF than read files
  
• "Unfortunately, 99% of admins will not change their default webroot directory." This is in most cases only true for servers which aren't hosting multiple websites, which is pretty rare nowadays. Even then, a lot of single-site hosts do change the default directory.
  

Other than that, nice tutorial.

This is for everyone - a lot of people believe the default php.ini setting for allow_url_fopen is 0 (disabled), which is only true for allow_url_include. If you see unsanitized output being passed to fopen() anywhere then take advantage of it.

[Byrdonawire]

Yes that is true and so many host do not even give access to the php.ini file to check unless you make them. Especially a shared one. It is impossible to fully secure a site on a shared server your self the client simply does not have enough control and there for you are left at the security of the host. Which is not reliable in alot of cases.