MonitorWare Knowledge Base

Please be advised that there is a security hole that would allow anyone to login completely bypassing the login page.

This needs to be fixed immediately. I have a fix that adds a new cookie to validate against.

Your other option is to turn off cookies. Here is how to disable cookies:

In index.php
Comment out line 55: if statement.

Then block comment out lines 70 through 87

This will ignore cookies.

Add lines at 88
setcookie("valid", 0, time(), "/");
setcookie("usr", 0, time(), "/");

This will invalidate all cookies users might have.

I have a second fix that allows the use of cookies,but requires adding a hash value to the cookie list. This still can be worked around since headers are sent in plain text.

A third fix will include the IP of the verified user in the hash, not sure how this will hold up to spoofing.

You best bet is to not use cookies at all!!!!! They are to easy to fake!!

Project maintainer, if you want to know how i got around the login, please contact me directly. There is no use in posting how to do it, cause that will put other at greater risk.

I think I already got the idea what happens. I think that the third fix is probably not efficiently enough, because in some environments the IP will be the same for a large user base because they are using a proxy. As of my understanding, this is also quite often the case in Asia, where official IP addresses are extremely hard to aquire. I have been told that many providers resort to double NATing, thus mostly invalidating any IP-based security approach.

Rainer

Agreed, the hash value would work as long as there was a secure method of transporting it to the client, SSL?

I must admit the cookie & session process needs to be reworked on.
I wouldn't totally remove cookie support as if someone wants to be remembered by a cookie, we have to give him the oppertunity.
The best solution would to use an additional session table as like in phpbb and using session hashes to "remember" the user.

I reviewed your changes, and you have modified a lot, very impressive. Running PHPLogCon without Cookies if wanted is a good feature, but it should be done optional.

best regards,
Andre Lorbach

I'm going to work them back in with a define statement and add a hash value to the cookie, this will make just setting the cookie value tougher to bypass. For now, on my systems i have commented out the code. Besides the sessions store all the user data, and when cookies are used the sessions are not started, so the cookies only keep the user loged in, and values between session are lost.

There is an if statement before session_start() function call. Don't remember off the top of my head where in include.php it was. Near the top i think.

Yes, SSL is a very good idea. The doc also needs to be improved. I think we should strongly recommend SSL (also because the log data itself is sensitive). We could even add a configuration option that, if selected, allows connections over https exclusively. That could be selected by default.

Rainer

alorbach, et. al.

I've rewritten (again) phplogcon there is a new version phplogcon-1.2.2_bgs. I restarted completly from 1.2.1 and re-wrote the changes i made in the previous version but this time with cookies in mind. At this point there is no checking other than the user is in the DB. Please test this and let me know where problems exist. Again, no installer, modify config.php by hand.

www.hackthebox.org

At this point I'm going to try to sync up with the phplogcon devlopers so we are on the same page.

THIS IS NOT AN OFFICIAL RELEASE!! I'M WORKING WITH THE DEVELOPERS AND THEY WILL MAKE THE NEXT OFFICAL RELEASE.

But, in the mean time you can test the code.

About the cookies. I've been thinking about the cookies, and how they were used in phplogcon, and what i understood was that the cookie just stored some auth values. So if someone wanted to be remember by cookies, would it not be better to send the php session id (SID) as a cookie (default php install). I'm assuming you have the --enable-trans-id turned on and the session id is passed via url?

So, by removing the cookies produced by phplogcon did not really disable cookie authentication. Unless you have the sid in the uri ( session.use_cookies = 0 )

So if cookies are on, the session id should be sent as a cookie. If cookies are off then sessions will rely on url. Since we can generate new session ids each time the users navigates the site (page to page, or between logins) this will offer a bit more robust method of a secure web app. The sid can be updated in the cookie or the url. This will reduce the possibility of an attacker guessing the sid since it is constantly changing. And if proper house keeping is done at logout the session data can be destroyed. Also php has garbage collection to clean up old sessions. Further more, storing a sesion expire value in the uses DB entry will furhter limit the time frame the user is allowed between acceses. (Auto refresh will work nice here, since the session can be set to expire after say 1 hour).

phplogcon relies heavily on the $_SESSION[] array to store user settings. When cookies are on, the session is not started, and no session info saved between site accesses, (save for the stuff in the DB) thus the only way the web app knows the user is validated is by some cookie values. (eaisly faked) Since the values are static and the expire is set for (30days?) anyone who has access to the computer can access the logs if the user does not log out. (I wont touch on the other way to get by the login that i previously reported).

If you are paranoid of the web I dont sugest reading this article. However, if you want to find out how vurneralbe you (and i mean you the person reading this BB, and not phplogcon) are to attackers you should read this.

http://www.acros.si/papers/session_fixation.pdf

I have not tried these yet, but from what i read, i think 90% of my php web apps are unsecure. I posted this here because this is good for any sysadmin to know, even if he/she does not write the php code. I think that if phplogcon is written properly it can over come may of the issue described within that article.

I'm also going to say this. phpLogCon is great I like the software i think it has great possibilities, but at this point I would not expose it to the public web. I myself am running phpLogCon (not just the demos) I have a second httpd running on a 192.x.x.x address that cannot be accessed by the public. But i would like to, so that is why i'm going to try to help as much as possible to fix these problems.

BTW: anyone reading this is free to jump in and comment on phplogcon. I want to know peoples thoughts about the software.

Let me put in some background info. When phpLogCon was initially developed, we did not even want to include authentication at all. Then, some settings creeped in and we thought they would be nice to store on a per-user basis. We called it profiles at that time. I remember I insisted it should not be protected by a password, because that would cause the wrong impression Anyhow, over time that, too, creeped in. Obviously without revisiting the "security" of our profiles (now promoted to real users). This just for your extended information.

Anyhow, to solve the issue it might be worth to sit back, relax and think about these early stages. One thing that we initially had on our mind was that if it would be protected, htaccess could be used for that. So let me ask if that would still be an option, eventually tied together with the rest of it. Probably it doesn't "feel" like current technology, so I'd better forget about it

Rainer

.htaccess files are good, but also well known. Without proper directory permissions they can be easily overwritten

php configuration varbiles can be set as well, there is a directive something like 'php_admin_value'

I think it would be better to set the configuration directives in the httpd.conf file either globally or on a per virtual host basis.

I think using sesions straight out is about good enough. The sid can be sent via cookie or url. This is going to be as about as secure you can get without SSL. If the sid is changed everytime the user accesses the page then that will reduce the possibility of someone picking up on a stale session. And if all the cookies/sessions are removed after they expire or after a logout that's even better.

Maybe a better question would be: Why do i need more than one user to have access to the logs? (Yes, I know there are going to be a 100 responces to this, and i want to hear them all

I'm going to pose the question in the rsyslog, you don't have to respond. I would like to find out how others are usig the phplogcon.