Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading LFITester #17

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Upgrading LFITester #17

wants to merge 3 commits into from

Conversation

brzeszczu
Copy link

The final result of the changes would be a program that is server-type independent for log poisoning vuln (all types of web servers will be served, not only nginx and apache), error handling, little changes in Crawler, more available payloads to chech from external file etc.

Current changes: little change in Crawler, server type independence for log poisoning (not fully ready yet).

check tags in the code:
# UPGRADE: when in URL exist only "?" (no "=") then do nothing (don't add payloads to that URL after
check comments in code:
# UPGRADE: deleted check if server leaks a Server Header. 
# UPGRADE: deleted in order to perform Log Poisoning for every type of webservers
@Konstantinos-Papanagnou
Copy link
Collaborator

Hello @brzeszczu ,

First of, thanks for your diligence and contribution to this project.
I am reviewing your commits now and I have a few questions.

(Disclaimer, I didn't test this yet, just read the code)

The crawler seems great, nice addition in capturing the URLs from the img tags.

Regarding the platform dependent update, I'll note first how this was conceived and developed. The idea is that every different underlying infrastructure (i.e. Apache2, nginx, etc) have their own unique (sometimes) location to store the logs. If you take a close look at the function definitions of nginx and apache log poisoning, it contains the most common directories where potentially poison-able logs reside on the system. That's why we currently have different definitions for different underlying infra.
Additionally, to avoid detection, it's a good idea to not brute force every single possibility, and that's another reason why it was broken down to header checks first and then poisoning the server. Now, a lot of seemingly different software for web servers can be a variation of either apache2 or nginx as I've encountered before (like litespeed is a variation of apache2). So we can add them as apache2 or nginx. For entirely different type of underlying infra, we can add a new function for it. If the web server is not validated, the user can choose to still attack using one of the known methods until one works.

That said, can you describe in more detail your exact expectations of the log poisoning module? Maybe it also makes more sense what we intend on doing at the given point of time.

Looking forward for your response,
Konstantinos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants