How i got my First Bug Bounty in Intersting Target (LFI to SXSS)

4 min readDec 10, 2020

Hello guys,

so want to share my first bug bounty in HackerOne private program so first i Open all scope in chrome tab and one of the scope get my attention the target is online IDE like VS Code or Visual Studio Code.

this the public repo that use on the target :
- https://github.com/microsoft/vscode
- https://github.com/cdr/code-server

so first i explore the site so since the target was Online VS Code so i check the terminal and check gcc version and kernel version im tried to get root access but im failed the terminal was open to anyone so i can execute any command in terminal even i can reverse shell based the description of the target the terminal was open becuase the target don’t have any sensitive information.

so i create the file with name of xss.html with xss payload

but after i run i can’t see any output…

then i started to the view source code and i found intersting in source code,

full directory called in url after hashes

/usr/local/****/src/browser/media/favicon.ico

this is full directory of inside the server so i check this to another tab and try to change the url and i try to view /etc/passwd

the /etc/passwd successfully called in url

Confirm!!! This LFI or Local file inclusion Vulnerability!!!

after seing this i read again the policy coz i lost many reputation for not reading the policy of the program LOL!!! 🤣🤣🤣

i read again the policy and in the scope description and this what they said

ide.redacted.com is an online IDE, available to the public for developing test Applications. Its primary purpose is to facilitate bootcamps — it is not a intended for production use, or for anything other than one-off test scenarios.
The shell terminal is deliberately available to everyone, without authentication required, because there is no sensitive information to be revealed.
The shell is also resource limited, does not accept inbound network connections, and the shell session will automatically expire. It is not designed as a long-term store of data.
The shell runs in a container. It should not be possible to access the host operating system, however if you find a way to break out of the container and compromise the host then we would like to hear about it :-)

Now we got a LFI then we need to exploit this in real senario since the /etc/password can call in the terminal functionally so means they not accept this Vulnerability without impact 🤔🤔🤔

and i got idea since we can call the internal files and we can create the file i use it to create the file with *.php extension as Webshell but it always return to the “Content-type: text/plain” so we can’t execute the php files and i realize this non-sence because we can do all in terminal…

then i try the first file i created with xss payload so i copy the location of the as internal file…