SSRF - Printable Version +- Sinisterly (https://sinister.ly) +-- Forum: Hacking (https://sinister.ly/Forum-Hacking) +--- Forum: Website & Server Hacking (https://sinister.ly/Forum-Website-Server-Hacking) +--- Thread: SSRF (/Thread-SSRF--86154)

SSRF - Byrdonawire - 11-25-2016 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:// RE: SSRF - meow - 11-25-2016 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. RE: SSRF - Byrdonawire - 11-25-2016 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.