EAR is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users.
How to identify?
Take the site
https://www.lucas.com/ as an example and the administrative panel is in the
/admin/ folder, validated by login.php (
The next step is to search for files with or without an extension (in this case it will be
.php), in order to obtain more information from the administrative panel (it can also occur in non-administrative panels). I usually use the ffuf tool to do the fuzzing (ffuf) and I create a wordlist with common internal system files like:
dashboard.php, among others.
https://www.lucas.com/admin/menu.php there is a redirect to
https://www.lucas.com/admin/login.php, however using a browser that does not follow the redirect (cURL) it is possible to view the source code of the
menu.php file, analyze the parameters used and find other internal administrative files. With that, I identified that the file
news.php interacts with the SGBD, in addition to finding the possibility of editing through
news_edit.php (POST) with the following parameters: title, author, image, summary, id and date of posting.
How to get access with EAR?
Using cURL to get the reverse shell:
$ curl -i -X POST -H "Content type: multipart/form-data" -H "Referer: https://www.lucas.com/" https://www.lucas.com/admin/news_edit.php -F firstname.lastname@example.org -F titulo=EAR Tutorial -F author=Lucas Rocha -F id=1
The Referer part is not necessary, but it is a possible bypass for systems that only check the Referer (it can also be combined with the Host Header Injection vulnerability, which consists of using X-Forwarded-Host or X-Forwarded-For to try to enter the system).
I have been dedicating myself to the Information Security area with a focus on offensive security such as pentesting, vulnerability analysis and cyber researching, feel free to contact me if you have any doubts.
- Execution After Redirect (EAR)
- Testing for Host Header Injection
- CWE-698: Execution After Redirect (EAR)