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

CVE-2018-7251 | SECURITY ADVISORY FOR ANCHORCMS | Reported by Arif Khan #1247

Closed
pehelwan opened this Issue Feb 19, 2018 · 20 comments

Comments

Projects
None yet
6 participants
@pehelwan

pehelwan commented Feb 19, 2018

Given the high amount of risk possessed by this vulnerability has been assigned CVE-2018-7251 on the same day itself due to the high amount of risk it poses to its users . A suggested temporary fix from the end-user's side would be to forbid the access to anchorcms/errors.log .
For more information please refer to http://www.andmp.com/2018/02/advisory-assigned-CVE-2018-7251-in-anchorcms.html

Regards,
Arif Khan(Security Researcher)
http://www.andmp.com/2018/02/advisory-assigned-CVE-2018-7251-in-anchorcms.html

@daviddarnes

This comment has been minimized.

Member

daviddarnes commented Feb 19, 2018

Thanks for spotting this! Would you be able to advise on a solution? Other than the user not turning on errors on live sites?

@pehelwan

This comment has been minimized.

pehelwan commented Feb 19, 2018

Yes , Its clear here that this file should in fact be not accessible to anyone but administrator so its a case of Improper Access Control rather , only admin should have access to it . Can you elaborate what do you mean by "Other than the user not turning on errors on live sites?"

Regards,

@pehelwan

This comment has been minimized.

pehelwan commented Feb 19, 2018

I couldn't however find how to whom, if at all there is a window ,I can reach out to report a security issue privately and get it resolved quickly before it gets exploited in the wild which is currently the case

@daviddarnes

This comment has been minimized.

Member

daviddarnes commented Feb 19, 2018

@pehelwan I didn't realise this error log isn't your own, I thought it was your test. Surely you shouldn't be reporting that url publicly as you're only making the security issue worse?

My query was to whether you have a bug fix in mind for the security problem?

@pehelwan

This comment has been minimized.

pehelwan commented Feb 19, 2018

Temporary - Forbid access to errors.log until further fixture

Long Time - Fixing access controls to admin only in sensitive areas like error logs files

@pehelwan

This comment has been minimized.

pehelwan commented Feb 19, 2018

Hmm... there are plenty of sites for OSINT to exploit this issue , one that I think is the best way to realise the precarious situation is - publicwww.com , try dorks with metatags that are a part of this CMS' front end pages , I 'm sure you will find other ways being deeply involved with it .

@pehelwan

This comment has been minimized.

pehelwan commented Feb 19, 2018

So the above website , a blog I guess was my scapegoat for the purpose of this demo which I feel is legit by laws if someone is on purpose/explicitly making public his/her logs/sensotive details that are not even obfuscated and can be quickly discovered by any fuzzer even though you haven't studied the application before.

@attritionorg

This comment has been minimized.

attritionorg commented Feb 19, 2018

This just got assigned CVE-2018-7251 and published.

@daviddarnes

This comment has been minimized.

Member

daviddarnes commented Feb 20, 2018

@pehelwan thank you for reporting this. I understand that it must be quite easy to get a hold of the error log, but I would prefer not to have it posted on an open source forum for people to easily locate and use on their site without their consent. I've redacted the url for now.

As for the bug we'll have to do some investigation, but I'm guessing the only way that error log got uploaded was that the user deployed the site with a development setting turned on? Would that be the case @CraigChilds94?

@pehelwan

This comment has been minimized.

pehelwan commented Feb 20, 2018

Any credits to me ,from your side for spotting it ?

@pehelwan pehelwan changed the title from Vulnerability to CVE-2018-7521 | SECURITY ADVISORY ANCHORCMS BY ARIF KHAN Feb 20, 2018

@pehelwan pehelwan changed the title from CVE-2018-7521 | SECURITY ADVISORY ANCHORCMS BY ARIF KHAN to CVE-2018-7521 | SECURITY ADVISORY FOR ANCHORCMS| BY ARIF KHAN Feb 20, 2018

@pehelwan pehelwan changed the title from CVE-2018-7521 | SECURITY ADVISORY FOR ANCHORCMS| BY ARIF KHAN to CVE-2018-7521 | SECURITY ADVISORY FOR ANCHORCMS Feb 20, 2018

@pehelwan pehelwan changed the title from CVE-2018-7521 | SECURITY ADVISORY FOR ANCHORCMS to CVE-2018-7251 | SECURITY ADVISORY FOR ANCHORCMS Feb 20, 2018

@daviddarnes

This comment has been minimized.

Member

daviddarnes commented Feb 20, 2018

@pehelwan thanks for updating the issue title, will help with future referencing. Sorry but we don't have a place other than this GitHub repo to provide credit for bug reporting

@pehelwan

This comment has been minimized.

pehelwan commented Feb 20, 2018

@daviddarnes daviddarnes ,what about a Hall of Fame position on anchorcms.com website ? In case you may add one for responsible reporters or maintain a list of them ?

@daviddarnes

This comment has been minimized.

Member

daviddarnes commented Feb 20, 2018

@pehelwan that is an interesting idea, but I would think it would be only for people who have contributed a fair amount of development to the project

@pehelwan pehelwan changed the title from CVE-2018-7251 | SECURITY ADVISORY FOR ANCHORCMS to CVE-2018-7251 | SECURITY ADVISORY FOR ANCHORCMS | Reported by Arif Khan Feb 20, 2018

pehelwan referenced this issue Feb 21, 2018

Update .htaccess to forbid access to logs
In response to CVE-2018-7251

pehelwan referenced this issue in pehelwan/anchor-cms Feb 21, 2018

@pehelwan pehelwan referenced this issue Feb 21, 2018

Closed

Fix for #1247 #1254

@CraigChilds94

This comment has been minimized.

Member

CraigChilds94 commented Feb 21, 2018

Fixed by #1248

@KennethWussmann

This comment has been minimized.

KennethWussmann commented Feb 26, 2018

This is not going to fix it quite well. What about other webservers like nginx who ignore .htaccess?

@Radiergummi

This comment has been minimized.

Member

Radiergummi commented Feb 26, 2018

@KennethWussmann I will admit we should provide examples in the documentation, but someone who uses nginx probably also has their own (VPS) server. Reasonably, you can expect those people to be proficient enough to configure nginx on their own.
There are way too many web servers to provide examples and consideration for, but the typical audience of AnchorCMS is likely using shared hosting with Apache2 so that is always going to be top priority.

@KennethWussmann

This comment has been minimized.

KennethWussmann commented Feb 26, 2018

@Radiergummi You should definitely provide this information in the installation process documentation, that you may punch holes in your system and loose your database.
Maybe there should also be the opportunity to log to a different file/directory outside of the default static served directory.

@pehelwan

This comment has been minimized.

pehelwan commented Feb 26, 2018

in the ngnix conf file add the following directive -
location ~ /anchorcms/errors.log {
deny all;
}

Hope this works !

@Radiergummi

This comment has been minimized.

Member

Radiergummi commented Feb 26, 2018

@KennethWussmann although not too obvious, the log file output directory can be changed by using a custom log reporter, refer to anchor/config/error.php in your installation. On L15, change the output path to a directory outside of your web root.

We are currently reviewing the logging functionality and in the middle of setting up CI including E2E/unit tests to prevent things like these from happening in the future. I hope you understand, however, that this is a project we work on in our spare time and some things might take a little to be properly implemented.

@KennethWussmann

This comment has been minimized.

KennethWussmann commented Feb 26, 2018

@pehelwan nginx was just an example to show that this issue is not fixed with adding a .htaccess file.

@Radiergummi Well, letting the users messing about with your source code and deal with it again after updating doesn't seem to be a good solution either.

For sure it's a DevOps problem. There should just exist the opportunity for them to prepare their systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment