> For the complete documentation index, see [llms.txt](https://dhaneshsivasamy07.gitbook.io/oscp-2022/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dhaneshsivasamy07.gitbook.io/oscp-2022/enumeration/http-https/lfi-lfi-greater-than-rce.md).

# LFI ( LFI -> RCE )

Whenever an application seems to retrieve something always check for LFI.

## LFI

* Searching for files as specified in the web page provides us with the requested page

![File being retrived with ?file parameter](/files/oGq1wZIVLs1fGjsGlG0y)

* Looking at the url `http://10.10.10.84/browse.php?file=phpinfo.[php](<http://10.10.10.84/browse.php?file=info.php>)`, the requested file is being fetched with the parameter `file`
* Since the requested resource are being fetched on a GET parameter, lets test for the availability of `LFI`

![LFI Confirmed](/files/XiDv5XkJ8IXBOpEeJy1F)

* LFI (Local File Inclusion) is a vulnerability where the system files are requested via web service and the contents are displayed in the web app
* Since the `/etc/passwd` is a globally readable file, we are able to check for the availablility of the LFI and obtainted the output

### Intresting files to look for

```bash
/etc/passwd
/etc/apache2/sites-enabled/000-default.conf # know the location of the web files
/etc/hosts # neighbouring hosts ?
/etc/knockd.conf # port knocking sequence
log files ? --> RCE 
```

## Php-Filter File Read

* Whenever an LFI is identified try to obtain the contents of the \*.php files with php filter

```bash
?file=php://filter/convert.base64-encode/resource=index.php
?file=php://filter/convert.base64-encode/resource=config.php
?file=php://filter/convert.base64-encode/resource=/etc/passwd
```

* Some times the page which are vulnerbale to LFI will not show encoded php content as expected when using php filter, so check the value without the .php extension

```bash
?file=php://filter/convert.base64-encode/resource=index
?file=php://filter/convert.base64-encode/resource=config
```

## LFI to RCE

* Log files are system generated files for a service, the log files contain aspects like which IP accessed the service, which resource was requested, on which time stuffs like that
* Log Poisoning is a technique where the log files are injected with some code and when chained with LFI, it could result in `RCE` (Remote Code Execution)
* Since we already confirmed the existence of LFI, lets try to obtain the http log file.

> For debian distribution the apache log file will be under `/var/log/apache2/access.log`
>
> For RHEL / Red Hat / CENT OS / Fedora the apache log file will be under `/var/log/httpd/access_log`
>
> For the freebsd distros the apache log file location will be `/var/log/httpd-access.log`

* Requesting the log file in the web service LFi and we have access to the log file which makes the possibility of log poisoning

![Log file access](/files/PtMbMupbY1OkSE7JJ1ZB)

* Legend
  * RED - IP address of the user who requested the resource
  * BLUE - TIME and DATE of request
  * GREEN - Requested Resource
  * PURPLE - User-Agent
* Lets Inject some code in the user-agent parameter and request the log file which could result in RCE
* Requesting the web page with php code injected in the `User-Agent` header

![Injecting](/files/Hw49NL3cTPYiZXjzh07r)

* Now again requesting the log file generates an error

![Accessing](/files/pLsH2sDw2YoEUibr7ekG)

* The Error Message says that its expecting a varible which we modified in the previous request
* Notice, The php code injection took place at the User-Agent Header and the Error message is also produced where the user agent value will be
* Now again requesting the resource with the `rce` parameter specified (which was the injected php code) we are able to obtain the code execution

![RCE](/files/tKMPtcg4rsLqZqSawBmt)

* Since the code execution is successful, a reverse shell can be obtained from this rce
* The reverse shell is obtained as `www`

![Shell](/files/gq79LFglLsNJZLzJ4l2h)