[BUG]CVE-2021-36471

[zhouf003]

https://gist.github.com/cybersaki/31ffe679a5552c1047164e3a5b01c2fd

Describe the bug
This vulnerability can be searched by using the google dork 'inurl:"/admin/index2.html"' or 'inurl:"/admin/index3.html"' (without single quotes).
AdminLTE dashboards have index2.html/index3.html in their products. Using this we can search for the AdminLTE templates which are being used in websites.

Expected behavior
Is there any patch which will fix this bug?

Environment (please complete the following information):
AdminLTE 3.1.0

[REJack]

Please explain me how we (AdminLTE) should fix this? There nothing that the Template could do to avoid this, thats a failure of the developers of the sites with the vulnerability it self.

[codetheorist]

Yep, these files simply shouldn't be included in the production build of the implementing project.

This bug is a by-product of exposing your entire node_modules folder publicly, which should be avoided unless you really know what your doing.

If any files are required from node_modules they should be imported using a bundler but if you need them in the browser, then NPM probably isn't the right tool. In those instances, you should use a CDN build or copy a static version of the file to a separate folder, which is publicly available using a URL.

[James-G-Hill]

Hello, I have seen this issue raised from a scan of a website's dependencies; is this not actually a bug with AdminLTE at all? Why is it being listed as an AdminLTE vulnerability?

[Hi-Timofey]

Is this CVE even valid? Can't find any PoC or attack description to reproduce. If anyone could point out what's going on with this vuln I will appreciate it.

[puikinsh]

This is an extremely old one. I don't think it is still relevant since we released a significant upgrade to the template.

[Hi-Timofey]

This is an extremely old one. I don't think it is still relevant since we released a significant upgrade to the template.

I understand. But here's my problem - there's a "vuln" with no description/PoC that is publicly known. I was trying to reproduce it and now I have no clue how is it even on NVD db. I just want some clarification on how this work bcz it could be that someone is still using old version with undefined messy CVE. And one and only relevant reference (as far as gist on this CVE contains no useful information imo) for this issue is this thread.

[James-G-Hill]

@Hi-Timofey I actually ran up against this issue myself due to this vulnerability being raised during a penetration test. I submitted an update to request that this CVE be regarded as disputed and the CVE Assignment Team updated the description to show that:

https://www.cve.org/CVERecord?id=CVE-2021-36471

The list of websites that the reporter of the CVE cited as evidence of vulnerability included websites that weren't actually based on AdminLTE as far as I can see, such as:

https://p2p.wrox.com/sharepoint-admin/index2.html

So I think this was mistakenly reported as an AdminLTE error and, as posts higher up on this page state, is in fact a configuration error on the part of various website developers, some of whom happened to be using AdminLTE.

I'm no cybersecurity expert by the way; this is just the conclusion I came to personally after digging around trying to bat back on this being included in the pen test report I received from a partner organization I worked with. I would very much welcome somebody with more knowledge correcting me on any errors I have made.

[Hi-Timofey]

@Hi-Timofey I actually ran up against this issue myself due to this vulnerability being raised during a penetration test. I submitted an update to request that this CVE be regarded as disputed and the CVE Assignment Team updated the description to show that:

https://www.cve.org/CVERecord?id=CVE-2021-36471

The list of websites that the reporter of the CVE cited as evidence of vulnerability included websites that weren't actually based on AdminLTE as far as I can see, such as:

https://p2p.wrox.com/sharepoint-admin/index2.html

So I think this was mistakenly reported as an AdminLTE error and, as posts higher up on this page state, is in fact a configuration error on the part of various website developers, some of whom happened to be using AdminLTE.

I'm no cybersecurity expert by the way; this is just the conclusion I came to personally after digging around trying to bat back on this being included in the pen test report I received from a partner organization I worked with. I would very much welcome somebody with more knowledge correcting me on any errors I have made.

Didn't knew that there's a possibility to request description change. Thanks for your efforts. Also, I'm working in offensive security team and I was studying this cve last week .
IMO, there's no CVE at all as far as there's no additional information from researcher who found it.
As you mentioned, all thees links is not convincing that it is actually a bug in framework rather than misconfiguration or website owners mistakes. Also, there's no actual PoC. The researcher is not responding to my attempts at gaining any further info. Could be cool if someone with subscription on X could managed to message him :)
In the meantime, all that remains to be said is that this doesn't seem like a real security risk. If you are reading this and wondering what to do - just upgrade to the latest version (since the developer said they rebuilt the codebase and the probability of this kind of bug is minimal) and forget it.

[cybersaki]

@Hi-Timofey I actually ran up against this issue myself due to this vulnerability being raised during a penetration test. I submitted an update to request that this CVE be regarded as disputed and the CVE Assignment Team updated the description to show that:
https://www.cve.org/CVERecord?id=CVE-2021-36471
The list of websites that the reporter of the CVE cited as evidence of vulnerability included websites that weren't actually based on AdminLTE as far as I can see, such as:
https://p2p.wrox.com/sharepoint-admin/index2.html
So I think this was mistakenly reported as an AdminLTE error and, as posts higher up on this page state, is in fact a configuration error on the part of various website developers, some of whom happened to be using AdminLTE.
I'm no cybersecurity expert by the way; this is just the conclusion I came to personally after digging around trying to bat back on this being included in the pen test report I received from a partner organization I worked with. I would very much welcome somebody with more knowledge correcting me on any errors I have made.

Didn't knew that there's a possibility to request description change. Thanks for your efforts. Also, I'm working in offensive security team and I was studying this cve last week . IMO, there's no CVE at all as far as there's no additional information from researcher who found it. As you mentioned, all thees links is not convincing that it is actually a bug in framework rather than misconfiguration or website owners mistakes. Also, there's no actual PoC. The researcher is not responding to my attempts at gaining any further info. Could be cool if someone with subscription on X could managed to message him :) In the meantime, all that remains to be said is that this doesn't seem like a real security risk. If you are reading this and wondering what to do - just upgrade to the latest version (since the developer said they rebuilt the codebase and the probability of this kind of bug is minimal) and forget it.

Hi Timofey and others,

This is the actual researcher behind this CVE. I intended to share this template disclosure to CVE.org as a low/info severity vulnerability but I am not sure how it was classified as a critical/high issue. A few of actual "Security engineers" have contacted me for past 2 years trying to understand the severity of this CVE and anytime anyone reached me, I have guided them of it's low severity. And I intended to recorrect the gist as well to a low/info type and the exploitability is very low.

"all thees links is not convincing that it is actually a bug in framework rather than misconfiguration or website owners mistakes."

• No, it was the template's issue, either they should have disabled the default template sample dashboard or the default settings should have supported it to be whitelisted within their environment. Also the links are super old, even when I tried to open a few of those links after I updated the CVE, those were not accessible.

"Also, there's no actual PoC." - if you have read the gist file, THERE IS POC.

"Could be cool if someone with subscription on X could managed to message him :) In the meantime, all that remains to be said is that this doesn't seem like a real security risk."

• My gist is there in CVE.org, you could have checked the owner of the gist, where a website was mentioned, the website has my linkedin, facebook profiles. None of you reached me. But all the security engineers did. Please don't lie about things you didn't do.

"just upgrade to the latest version" - I think version has nothing to do here, since this is a whitelisting configuration issue and the template's availability of private listing their sample admin dashboard within their environment rather than allowing it for public hosting.

You know you can disclose/disregard any vulnerability but can always reach out to the researcher if you can read the gist properly.

-Regards,
cybersaki.
My actual linkedin profile where you CAN REACH ME - https://www.linkedin.com/in/cyb3rs4k1/

[Hi-Timofey]

• Also the links are super old, even when I tried to open a few of those links after I updated the CVE, those were not accessible

Well, that's exactly why I mentioned PoC. You described the attack scenario, but in fact there is no information on how to reproduce such behavior. In this regard, I did not mean to say that there is no information in GIST at all. But, it is still unclear why you classified it as PTRAV. Personally, I think the words “Traverse to /admin/index2.html, /admin/index3.html” are insufficient to describe the attack. The same goes for “Maybe (Or no)” as a description of the impact.

• None of you reached me. But all the security engineers did. Please don't lie about things you didn't do.

Well, there is a comment under your post in which I ask you to contact me because Facebook, LinkedIn,X are officially unavailable in my country. Assuming that without verification I would not be able to write to you there, I used the means of communication available to me at the moment. I did not write that I wrote to you everywhere. I could try to sign up but personally prefer github or email.

think version has nothing to do here, since this is a whitelisting configuration issue and the template's availability of private listing their sample admin dashboard within their environment rather than allowing it for public hosting.
No, it was the template's issue, either they should have disabled the default template sample dashboard or the default settings should have supported it to be whitelisted within their environment. Also the links are super old, even when I tried to open a few of those links after I updated the CVE, those were not accessible.

This might be quite useful to add all this info to CVE/GIST as "reference" nstead of unresponsive examples. And the fact that people have been writing to you all this time to clarify information about this vulnerability confirms this. CVE exists so that other people know how the bug originated, how to fix it, and how it works.

So, with all due respect, I suggest updating the GIST with more detailed descriptions so others will save their time, rather than engaging in a debate about who is a “security engineer” and who is not.

[cybersaki]

Well, that's exactly why I mentioned PoC. You described the attack scenario, but in fact there is no information on how to reproduce such behavior. In this regard, I did not mean to say that there is no information in GIST at all. But, it is still unclear why you classified it as PTRAV. Personally, I think the words “Traverse to /admin/index2.html, /admin/index3.html” are insufficient to describe the attack. The same goes for “Maybe (Or no)” as a description of the impact.

Ans : There is POC to how to recreate the scenario. It's just directory traversal, two "directory words" are enough, which makes it a low severity. Simple. That's why the name "traverse to...". I might need to re-learn security if this is not clear.

Well, there is a comment under your post in which I ask you to contact me because Facebook, LinkedIn,X are officially unavailable in my country. Assuming that without verification I would not be able to write to you there, I used the means of communication available to me at the moment. I did not write that I wrote to you everywhere. I could try to sign up but personally prefer github or email.

Ans : Why would I contact you personally ? If you require a clarification, you have to find modes of communication. I can't cater to everyone according to their country's preferences.

This might be quite useful to add all this info to CVE/GIST as "reference" instead of unresponsive examples. And the fact that people have been writing to you all this time to clarify information about this vulnerability confirms this. CVE exists so that other people know how the bug originated, how to fix it, and how it works.

Ans : I have added all these in the GIST. I would suggest you all "engineers" to re-read properly and come back with assumptions. For the fix, I think it's for the devs to decide. I would be happy to explain fix for a known vulnerability. So I can only recommend to disable or whitelist the sample dashboard. If they find a new fix, am happy to include and update that in the gist as well.

So, with all due respect, I suggest updating the GIST with more detailed descriptions so others will save their time, rather than engaging in a debate about who is a “security engineer” and who is not.

Ans : I updated it already and it's already done for godsake. I am sure you never met a security person in any of the places you worked. And you are not the first one I met. This happens to everyone new dev I meet.

[jubeenshah]

Hi @Hi-Timofey I agree. This CVE does not make sense. Nothing that the developers can do. A low severity problem, not a critical one.

Just one way CVE team is getting overloaded with requests... Think the maintainers should close this "bug".

[cybersaki]

Hi @Hi-Timofey I agree. This CVE does not make sense. Nothing that the developers can do. A low severity problem, not a critical one.

Just one way CVE team is getting overloaded with requests... Think the maintainers should close this "bug".

Closing the bug here won't give you the resolution on closing IRL production issue occurrence. Good luck on that.