| Summary: | CSRF protection bypass with XSS | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Pisher Honda <pisher24> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | Security | ||
| Priority: | - Unknown - | CC: | michael.tremer, peter.mueller, pisher24 |
| Version: | 2 | ||
| Hardware: | all | ||
| OS: | Linux | ||
| URL: | https://192.168.56.5:444/cgi-bin/mail.cgi | ||
| Attachments: |
using xss to craft a csrf request
poc for csrf attachment-868675-0.html attachment-899617-0.html |
||
Created attachment 719 [details]
poc for csrf
Thank you for reporting this.
Could you please verify for me that this patch fixes the problem?
> https://patchwork.ipfire.org/patch/2561/
Hey there, This would patch the issue. I would like to know, if we can go ahead and request CVE for this issue? or else is there a procedure from your end to apply for a CVE? (In reply to Pisher Honda from comment #3) > This would patch the issue. Did you just review the patch or did you test it, too? > I would like to know, if we can go ahead and > request CVE for this issue? or else is there a procedure from your end to > apply for a CVE? You can go ahead and request a CVE. We do not have a procedure for this as it is normally done by the researcher before the issue is being reported to us. *> Did you just review the patch or did you test it, too?* ijust reviewed the patch code. i didn't had much time to test it with DAST approach will test it tommorrow once i go to work space, Please send me the complete modified mail.cgi file(includes patch as well) so that i can quickly test it using DAST approach and get back to you FYI version used for testing is *IPFire 2.23 - Core Update 136* (In reply to Michael Tremer from comment #4) > (In reply to Pisher Honda from comment #3) > it is normally done by the researcher before the issue is being reported to > us. This should not be the case, cve requests should be donee the vulnerability is patched https://blog.ipfire.org/post/ipfire-2-23-core-update-138-released Why didn't the release note of Core Update 138 mention this? (In reply to Peter Müller from comment #8) > https://blog.ipfire.org/post/ipfire-2-23-core-update-138-released > > Why didn't the release note of Core Update 138 mention this? Because it was not released in c138. It was supposed to be, but then everything was moved to 139 and an emergency update was inserted for the Intel vulnerabilities: > https://git.ipfire.org/?p=ipfire-2.x.git;a=shortlog;h=refs/heads/core138 This is now scheduled to be released in c139. Hi, if this vulnerability is about to be fixed in C139, this bug should be classified as ON_QA, shouldn't it? Thanks, and best regards, Peter Müller Created attachment 1614 [details] attachment-868675-0.html HI Mike i have reported a bug back in 2020 and claimed the CVE of 2020-19204 But now the cve is claimed by other person. How is this possible (above mail chain is attached regarding our previous discussion). Any insights on this would be appreciated thanks Pisher/Mohan On Wed, Oct 30, 2019 at 4:30 PM IPFire Bugzilla <bugzilla@ipfire.org> wrote: > Michael Tremer <michael.tremer@ipfire.org> changed bug 12226 > <https://bugzilla.ipfire.org/show_bug.cgi?id=12226> > What Removed Added > Assignee nobody@ipfire.org michael.tremer@ipfire.org > CC michael.tremer@ipfire.org > Status NEW MODIFIED > > *Comment # 2 <https://bugzilla.ipfire.org/show_bug.cgi?id=12226#c2> on bug > 12226 <https://bugzilla.ipfire.org/show_bug.cgi?id=12226> from Michael > Tremer <michael.tremer@ipfire.org> * > > Thank you for reporting this. > > Could you please verify for me that this patch fixes the problem? > > https://patchwork.ipfire.org/patch/2561/ > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > - You are on the CC list for the bug. > > Hello, Said CVE has not been changed by us. Who has claimed this instead of yourself? Created attachment 1615 [details] attachment-899617-0.html That's a issue from NVD I believe On Thu, 21 Nov 2024, 14:57 IPFire Bugzilla, <bugzilla@ipfire.org> wrote: > *Comment # 13 <https://bugzilla.ipfire.org/show_bug.cgi?id=12226#c13> on > bug 12226 <https://bugzilla.ipfire.org/show_bug.cgi?id=12226> from Michael > Tremer <michael.tremer@ipfire.org> * > > Hello, > > Said CVE has not been changed by us. Who has claimed this instead of yourself? > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > - You are on the CC list for the bug. > > |
Created attachment 718 [details] using xss to craft a csrf request As the CSRF mitigation technique ipfire employed reffer header check technique but as the application is already vulnerable to xss i was able to bypass the refer check, here is how i did it - Navigate to mail service under the system menu and enable it - fill in the input fields in the field mail server address which is vulnerable to XSS(CSRF-1) , Now using this XSS vulnerability craft a post request to a page which is vulnerable to csrf(wake on lan) Vulnerable Files :: ================== cgi-bin/mail.cgi is vulnerable for reflected XSS