Security Log - Authorization cookie check - Protect Setup Scripts

flo

The security log shows many instances called "Authorization Cookie Check". This has been going on every few days over weeks already. There might be 20 entries on 1 day all from the same IP address, a few days later there might be another 17 entries from different IP and so on. All entries show the same log info, only the IP differs across the days.

IP: (varies across days)
type: Authorization cookie check
user name: blank
user ID: blank
outcome: Failed
authority: blank
addtl info: :deleted

There seems to be only 1 previous comment about such "Authorization Cookie Check" in the forum from March 2014. In that case the IP was always the same, so there was an easy solution to block the IP.

1) does "Authorisation Cookie Check" indicate an attempt to gain access to the Admin login details?
2) access to the login details should not be possible provided the setup scripts are protected properly, is that correct?
3) is there anything i can do to prevent further attempts, or add other security measures?

and

4) the most recent "Authorization cookie check" incident occurred 2 days ago. I happened to log in 2 minutes after this latest incident. The security log first shows an entry "Protect Setup Scripts" 10 seconds before an entry showing my admin login.

IP: (my own and same as admin login)
type: Protect setup scripts
user name: blank
user ID: blank
outcome: Success
authority: zp_admin
addtl info: protected

10 seconds later the log shows my login:

IP: (my own)
type: Admin login
user name: (my own)
user ID: (my own)
outcome: Success
authority: zp_admin
addtl info: blank

Setup scripts were and are always protected, all files ending ".php.xxx". Setup file permissions are 0644, the timestamp shows last modification when i run setup months ago. The Setup folder is permission 0755 and was last modified yesterday, approx 24h after the log incident. I have not modified anything at least not knowingly.

Does the log entry "Protect setup scripts" indicate that whatever happens during the "Authorisation Cookie Check" somehow manages to trick the system to think the setup scripts are not protected when they actually are? In addition, why does this protection happen 10 seconds before my admin login?
Would you expect the Setup folder to show a modified timestamp through any authorised admin activity?

Questions over questions, sorry for the long post and thanks for any info and suggestion you may have.

acrylian

1) Probably.
2) Yes
3) If the theme used offeres a login link remove that or if you have the userlogin-out plugin active you should disable that sot not "present" the login link right away.
4) The backend always checks if the setup file are protected. A full admin may to choose to unprotect which is stored as an option. The backend would show a message about the non protection.

Setup scripts are unproteced when you install Zenphoto the first time and protected after running setup successfully. They also may become unprotected in 1.5.7 and earlier if setup requres outrun. Primarily if the config file is missing. then they would be unprotected. This would run without being loggedin since without the config file there is nothing to check the login status naturally. It would also try to autorun if the db credentials are missing, incomplete or not working. In 1.5.8RC (Github master) this changed already and will just show an config error instead of running setup. The missing config file is the only instance where it would now autorun.

flo

Thank you for the comment, please see more info below.

1+2) thank you

3) no such link and plugin is disabled, the site is a simple photography portfolio site; no users, no comments, the only portal for external interaction is the contact form. The hacker obviously knows the regular admin link, as months/weeks ago there were numerous failed logins using random user name/ID details, in addition to multiple entries of the "Authorization Cookie Check".

4)
a) Setup was last run successfully many months ago and scripts were always protected from all that is visible to me. There never has been a message of any non-protection; but then, would i see such message if there is a protection routine running 10 seconds before my log in?

b) Files do end in "xxx". I did check this was the case not so long ago and it was and is still the case today. I believed this is a fail-proof indicator that scrips are indeed protected, is that correct?

c) As I wrote the timestamp of the setup scripts shows last modification date many months ago when i last ran setup. IF scripts had indeed become unprotected and then protected again would the timestamp not change?

d) interestingly, as you mention the option to "unprotect the scripts" via the admin backend, there is no such option visible. I have seen this option before, but cannot remember how long ago as I never used it. There are only the other standard utility options e.g. "Run setup" and "Setup >> restore scripts".

Would you recommend to run a new setup?

e) I am on 1.5.7. There is a cfg file present in zp-data; I assume this is the config file and created automatically during the setup? I did a lot of image related work over the last months and all appears normal, both when logged in as admin and when logged out. Presumably this means that db credentials must be complete and correct?

f) There is nothing to prevent any future "Authorization cookie check" incidents? Then the only strategy seems to ensure setup scripts are fully protected? Are my permission settings as described previously as good as possible?

acrylian

3) The hacker obviously knows the regular admin link

Well, we are open source so the admin link is not a secret. We have something against that on the list though.

There never has been a message of any non-protection; but then, would i see such message if there is a protection routine running 10 seconds before my log in?

The backend checks for unprotected files frequently but the logging should only occur if they were in fact unprotected. At least that way in reconfigure.php. I cannot reproduce that on our own site but I didn have security logger set to log all attempts.

4b) Yes, the .xx files are not excecutable by a webserver - unless it is configured to do so naturally but why should it - so setup cannot be run.

4c) The time stamp actually would change. This is always confusing Git as they are always listed for committing after they have been unprocteded although they didn't change at all.

d) interestingly, as you mention the option to "unprotect the scripts" via the admin backend, there is no such option visible.

"Setup >> restore scripts" is the button I was referring to.

4e) Yes, that is the config file. If your site is working all is fine actually.

4f) There is nothing to prevent any future "Authorization cookie check" incidents?

That check itself causes no harm and is just the cookie related check if you are loggedin. That happens for you as well to see if you can be granted access to your site.

The security loggers logs not only issues especially if you set it to log "all attemps".

flo

Thank you.

So then it seems setup files are indeed protected and were not un-protected by any of the possible known reasons that you mentioned. Leaves the question why there is a "Protect setup script" routine showing in the log? Seems strange that neither you nor anyone else has experienced a similar issue and my simple portfolio site is the only one targeted with the "Authorization cookie check". But such is the mystery of life i guess

If you don't see a way the "Protect setup script" incident is related to the "Authorization cookie check" incidents then i can relax and simply ignore both?

And could you please confirm if my permission settings are ideal? Perhaps not directly related, but i'd appreciate if you could confirm. Setup scripts 0644, setup folder 0755.

acrylian

Leaves the question why there is a "Protect setup script" routine showing in the log?

But I review reconfigure and recent changes in 1.5.8RC. It might be reconfigure causing unprotection a little too early. I have change that at least. But it should not have harmed anything.

I had the logger not setup for all attempts and didn't have such entries on our own site. Perhaps I will now that I changed it. I have to keep an eye on that.

In any case If setup really would have been run there would be something in the separate setup log.

The permissions actually look fine:
https://www.zenphoto.org/news/permissions-for-zenphoto-files-and-folders/

flo

Thanks for all the advice and support!

flo

After a week without "Authorisation cookie checks" the hacker was back again. Guess the funny guy is reading this forum too

Still thinking about this and it doesn't make sense to me Acrylian.

The conclusion from our previous comments here was that the "Authorisation cookie check" has no chance of success due to setup files always being protected, and the only purpose you mentioned was that this is a check whether I am logged in.

I trust your expertise, but why would anyone spend their time and resources doing this repeatedly over weeks and months with the most recent such check executed 18 times in the space of 2 minutes?

Surely they expect some gain from their activity? Why target a simple photo portfolio site holding small, compressed images only; a site without users, shop or any other potential (data) value from all i can see.

Do you/Does anyone here have any guess?
Has no-one else experienced these "Authorisation cookie checks"?

And one more question please: is there any difference in potential vulnerability with regards to these "Authorisation cookie checks" if i happen to be logged in to the site at the time?

Thank you

acrylian

That check itself has nothing to do with setup. I cite myself:

That check itself causes no harm and is just the cookie related check if you are loggedin. That happens for you as well to see if you can be granted access to your site.

The unrptotectiong of setup fileshappens a little too early in 1.5.7 on reconfigure requests before it is actually needed. There have been changes in 1.5.8RC in that regard. So please test that before we actually release it.

flo

My question is not about the unprotecting of setup scripts, i think we cleared that point in previous comments? I also did not suggest the "Authorisation cookie check" is related to the setup.

My question today is about continuing "Authorisation cookie checks", that originate from varying IPs located in Russia, Canada etc. If that check is no harm and only serves to check if i am logged in (isn't that what you are saying?) then what is the point of someone spending time and resources doing consistent repeated "Authorisation cookie checks"?

Any guess?
Does no-one else experience such "Authorisation cookie checks"?

And I asked if there is any difference to potential vulnerability if i happen to be logged in while the checks occur. Presumably you will say no, but I'd appreciate the answer from the experts, as I am not.

Thanks
(P.S. spelling edited)

acrylian

Okay, sorry. Again these checks are normal to see if the cookie is set if someone tries to login or access parts like the admin that are restricted. Your own login cookie - as any cookie -is local to the browser you used to login. If you login using Firefox you are naturally not loggedin with e.g. Chrome on the same computer.

And yes, since the security logger is enabled we have this on our site as well. Any site will have login or access attempts by someone. This is often done automatically.

flo

No worries and thanks for all help, but sorry i am not sure if i fully understand your answer or the ramifications.

There has not been any recent unauthorised login attempt, at least not visible to me, as there is no such event recorded in the security log. All I can see in the log are the repeated "Authorisation cookie checks" (and my own access).

If i understand you right then these "Authorisation cookie checks" might show up if someone tried to access restricted parts, but should such access attempt not show up in the security log?

If the "Authorisation cookie checks" are automated then sure this may continue, but I still do not see the point. From all info exchanged between us here, there is no possible gain and therefore no point in doing these checks? So again, why does someone spend time & resources on this? You may be used to seeing such attempts, but to me it makes no sense. Surely they hope to exploit some vulnerability?

And could i ask again please? There is no difference in potential vulnerability regardless whether i am logged in or not at the time these cookie checks occur?

acrylian

The "Authorisation cookie checks" is a base check to see if you are allowd to see what you are requesting. No cookie, no access. The cookie outdates itself (as set on the options) or you can clear them manually.

That check happens checkCookieCredentials() method of the Zenphoto_Authority class where the security logger is attached to via a filter. It just logs all checks.

The security logger does not log possibly dangerous events per se (as it does not know what might be or not), it just logs all events in areas it is attached to that you might want to observe.

For example if your site constantly times out because there are to many requests eating up all performance. Then you could see if there lots of unauthorized (and failed) requests from the same unknown IP* which you then could block that IP via your server for example.

*There is a privacy bug that the IP is stored in full even if storing is disabled on the security options (as storing full IPs generally violates the GDPR).

So again, why does someone spend time & resources on this? You may be used to seeing such attempts, but to me it makes no sense. Surely they hope to exploit some vulnerability?

Such attemps happen on bascially every public site and they are not targeting you specifially. While there might be a actual person doing this manually it is more likely they just do this via tools randomly and automated just like spam mails you surely get every now and then as well. They might not even target Zenphotio specifially (we are really not big enough), but just common vulnerabilities. I have seen requests on ZP sitets that actually target WordPress for example.

flo

Sorry for the delay to my response, i only find the time now.

Thanks for all info and advice acrylian. I guess you are telling me more than you would normally [have to] explain here and i thank you for that. Bottom line of all seems to be that there is no reason for concern, the "Authorisation cookie requests" from varying IPs are not an issue, nor do they aim at any known vulnerability of the system. Consequently i can ignore these "Authorisation cookie requests".
Do i understand you correctly?

And, i asked 3 times previously, but you did not respond, at least not directly. My question may be too obvious or simple for you, but it is not for me. I asked if there is any difference in vulnerability, whether i am logged in [as admin] at the time of such "Authorisation cookie requests".
If I understood you right that i can simply ignore these "Authorisation cookie requests" then my question would still remain, but be more general. So i ask for the 4th time: is there any difference in vulnerabilities if i am logged in compared to not be logged in?

cheers

acrylian

Do i understand you correctly?

Yes, should not. Regarding security there is of course never a 100% guarantee.

I asked if there is any difference in vulnerability, whether i am logged in [as admin] at the time of such "Authorisation cookie requests".

I think I did answer that already. No there is not. Since cookies are tied to the browser(s) you are logged in, no one else will have access to them. Unless your browser/computer system has been hacked of course which we will not assume to be the case.

flo

Thank you!