Security concern - access cPanel, no login required

[horustwohawks]

Security concern - access cPanel, no login required

Hi folks,
This is my first post here... I did search the forums for what I feel is a reasonable period of time and found nothing about this. If this post is misplaced please point me to the correct place.

First, know that I am a reseller on a shared server at Hostgator, so obviously I have no access to the actual cPanel installation (files, server, etc).

During the recent Horde problem I was contacted by a client concerned that they could use their back button/history to waltz right back into their webmail even after logging out, so evidently anyone having access to a PC where they, or an employee, has been logged into their email can gain access.

After a a great deal of testing I confirmed this to be true, even after clearing cookies, cache, closing and reloading the browser(s), I can use history links to regain access! I performed these tests on Win2k and XP in FF1.5 and 2.x and IE5.5, 6, and 7. All settings for remebering any passwords or forms have been disabled and cleared beforehand. I tested over and over again for the last few days.

After the supposed fix for Horde was issued about a day ago, I tested with same results. No matter how I try to clear it, I can "almost" always get back into webmail somehow. I mean, "eventually" I cannot, but there's no consistent procedure for making certain login access is required, or more to the point, that logging out has effectively reset the session.

***I then wondered about cPanel access to my WHM, so I tested that just now... same results!!

Hostgator, at length, says they cannot help on this one, that this is a cPanel problem and I need to begin working the process over here, and at bugzilla.cpanel.net, so here I am.

Below I will post my procedures for you all to check out for yourselves.
PLEASE TEST AND REPORT BACK HERE!

I find this extremely disconcerting, and I am surprised I cannot find any information here on this... I mean I would have thought such a blatant security hole would have been exposed and dealt with by now, but then I am assuming it has been the same all along, which admittedly may be an incorrect assumption.

I will post my procedures next.

thank you,
HTH

 

[horustwohawks]

How I regain WHM Access after Logging out without Logging Back in

How I regain access to webmail after logging out, without loggin in again.
(Obviously this procedure was written while Horde is offline at my server, but I think its wise to include this whole thing as it is - it still applies...)
1) Login to Webmail at www.thedomain.com/webmail
2) Choose Horde - you will see the message left by Hostgator and that you apparently do not have access
3) Change "index.php" at the end of the url in the addressbar to "login.php", or select it from history in the address bar (or a link you keep, or using the back button, or from wherever... try any links relating to your horde email )
4) Dimiss any prompts to login. You will eventually get the Horde Login Button.
5) Click the Login button to enter - but you will get Hostgator's message again,
*6) Click your back button and you are in Horde
7) If you are not in Horde, try other saved links or history links... such as
http://www.thedomain.com:2095/horde/imp/mailbox.php?mailbox=INBOX&actionID=login
....and get right in.

8) Since you cannot logout from there because the sidebar is gone due to the patchwork going on, go to www.thedomain.com:2095/webmail
9) Click on Squirrelmail
10) Click SignOut
11) Click the Back button dismissing prompts to login. Eventually, going back and forth, you "may" get into your webmail.

12) If you do not get into your email you may see that you do access the Horde page with the login button.
13) when you click it it seems you cannot get in.
14) Then selecting www.thedomain.com/webmail gives you the webmail client selector.
15) From there you can click right into your webmail via Squirrel or Horde. Again, with Horde you may need to "accidentally select" your login.php page, either using back button or history links...

That's what I got so far, and I can duplicate it every time... on my Win2k Box, so this is not XP dependant as may have been implied by earlier posts. Try clearing cookies and cache and closing your browser. I did and I experienced the same results!?
==========================================

WHM Access After Logging out.
This one's even easier...
1) Log into WHM
2) Go Anywhere
3) Logout
4) Clear cookies and cache (optionally, close and then reopen the browser)
5) Go back to the WHM page
6) Dismiss the login prompt
7) Now use your back button to procede right into WHM

 

[horustwohawks]

This afternoon around 12:50p pt (about 20mins ago) I was unable to reproduce the results for WHM access, but I continue to be able to access any of the webmails, squirrel, horde, or opencube, using the procedures listed above.

I will keep testing this over the next few days and report anything significant here. I hope others do as well.

Please be sure to note the OS being used and the Browsers and their versions.

Thanks,
HTH

 

[cPanelDavidG]

For future reference, feel welcome to submit security concerns to our security team at: [email protected]

 

[horustwohawks]

For future reference, feel welcome to submit security concerns to our security team at: [email protected]

Thanks David.

Thought I'd post here to see what others might be able to find by repeating the procedures and "checking me" on this reported behavior I claim to be observing ...before beginning an actual support issue or presuming to be filing a bug or anything prematurely.

I do have a followup...

Maybe I was wrong about the WHM open access (however, I have been able to consistently repeat the webmail access)...

Per the WHM access: You know, I was certain of the observation after having tested this over and over again up to yesterday afternoon, - after seemingly regaining access without logging back in, going into places where I'd not yet been in order to prove it was real access, ...to be absolutely sure I wasn't making any assumptions before posting this,
.....but I tested several times since yesterday afternoon and have not been able to reproduce the access claimed, so maybe I made an error while testing, or something else changed...?

Anyway, non of the folks over at HG who responded were able to reproduce this behavior with WHM, so all in all I feel a little more at ease about the whm.

I still have yet to hear form others about trying to regain access to webmail though. As of today I can still repeat the procedure listed and regain access.

Cheers,
HTH

 

[cPanelKenneth]

I know this was possible in one of our test builds. If your cPanel server is now updated to build 21703, then it has a fix for that issue.

 

[horustwohawks]

I know this was possible in one of our test builds. If your cPanel server is now updated to build 21703, then it has a fix for that issue.

Thanks Kenneth.
I observe presence of the update to 21703, but, of course, I could not determine when that may have been applied (rememeber, I am on a shared server there).
Although it would be interesting to know when that happened, I don't think I ever will.
I wonder if the "test" version you mention may have been applied during the Horde repair/updates that was taking place during end of last week - anything to do with that?

It kind of reminds me of that Jim Carry movie "dumb and dumber" where he asks the girl what she thinks the chances are of a girl like him and a guy like her getting together, and after she answers "one in a million" he makes this ridiculous face and say, "so you're saying there's a chance!".

So I was just thinking... so you're saying there's a chance... that I am not totally out of my mind regarding my testing .. ;^)

All righty then... back to work.
HTH

 

[rpmws]

Thanks Kenneth.
I observe presence of the update to 21703, but, of course, I could not determine when that may have been applied (rememeber, I am on a shared server there).
Although it would be interesting to know when that happened, I don't think I ever will.
I wonder if the "test" version you mention may have been applied during the Horde repair/updates that was taking place during end of last week - anything to do with that?

It kind of reminds me of that Jim Carry movie "dumb and dumber" where he asks the girl what she thinks the chances are of a girl like him and a guy like her getting together, and after she answers "one in a million" he makes this ridiculous face and say, "so you're saying there's a chance!".

So I was just thinking... so you're saying there's a chance... that I am not totally out of my mind regarding my testing .. ;^)

All righty then... back to work.
HTH

one thing I have noticed with windows clients (and maybe any other) is if you have authenticated on any http authentication site, and you have another browser open ..minimized or whatever and you close the authenticated browser session ..you can then open the minimized browser and navigate to the protected area again without a password box. Is it possible there is a hidden browser window on your desktop?

 

[horustwohawks]

one thing I have noticed with windows clients (and maybe any other) is if you have authenticated on any http authentication site, and you have another browser open ..minimized or whatever and you close the authenticated browser session ..you can then open the minimized browser and navigate to the protected area again without a password box. Is it possible there is a hidden browser window on your desktop?

Hi rpmws,
Interesting, and I am really apreciative that, you mentioned this. I did not know this.

When it was first reported to me about the webmail problem with Horde I was indeed testing with two different browsers running. However, at length, there was something a staff member at HG mentioned and I thought "I'd better be absolutely certain there isn't some sort of behind the scenes interaction between those browsers" ...even though I thought "there's no way, I have been clearing cache and cookies and history, and closing and then reopening browsers..."

...but I did start testing early on with only one browser running because I wanted to be sure not be unwittingly creating non-reproducable test procedure for others, and mucking it all up.

I am going to have to take some time out later to test what you mention.
Thanks for posting that.

Cheers,
HTH

 

[cPanelKenneth]

Thanks Kenneth.
I observe presence of the update to 21703, but, of course, I could not determine when that may have been applied (rememeber, I am on a shared server there).
Although it would be interesting to know when that happened, I don't think I ever will.
I wonder if the "test" version you mention may have been applied during the Horde repair/updates that was taking place during end of last week - anything to do with that?

It kind of reminds me of that Jim Carry movie "dumb and dumber" where he asks the girl what she thinks the chances are of a girl like him and a guy like her getting together, and after she answers "one in a million" he makes this ridiculous face and say, "so you're saying there's a chance!".

So I was just thinking... so you're saying there's a chance... that I am not totally out of my mind regarding my testing .. ;^)

All righty then... back to work.
HTH

What I mean is that during internal testing of the code that was eventually published as build 21703, we detected similar behavior (logout -> back button -> whoops still logged in). It's quite plausible that this existed in older, already published builds (for example 21594, which predated 21703).

Another matter to consider when using HTTP authentication:

There is no allowance in the HTTP Authentication specification for a logout mechanism, other than closing the browser.

This means that the logout functionality is totally dependent upon the browser to implement properly. We do our part, clearing out any server-side session information, but if the browser doesn't provide a mechanism for HTTP Authentication logout then it will over-ride what we do.

For example, older browsers (e.g. IE 6, Opera 8, etc) would ignore the logout request and simply log you in when using the back button. This was the case for webmail, cpanel and WHM, because the Client (the browser) still had a properly authenticated 'token.'

I haven't examined the fix performed during internal tests to determine whether it is more strict in regards to server-side cleanup or simply covered an 'oops.'

 

[cPanelKenneth]

so all we need to do is fix all the 14 billion bowsers installed and we will be ok. Ken ..you might want to get started now :D I will buy you a beer when I see you next .. LOL

But if I do it, what will Mario and Luigi do?

 

[rpmws]

What I mean is that during internal testing of the code that was eventually published as build 21703, we detected similar behavior (logout -> back button -> whoops still logged in). It's quite plausible that this existed in older, already published builds (for example 21594, which predated 21703).

Another matter to consider when using HTTP authentication:

There is no allowance in the HTTP Authentication specification for a logout mechanism, other than closing the browser.

This means that the logout functionality is totally dependent upon the browser to implement properly. We do our part, clearing out any server-side session information, but if the browser doesn't provide a mechanism for HTTP Authentication logout then it will over-ride what we do.

For example, older browsers (e.g. IE 6, Opera 8, etc) would ignore the logout request and simply log you in when using the back button. This was the case for webmail, cpanel and WHM, because the Client (the browser) still had a properly authenticated 'token.'

I haven't examined the fix performed during internal tests to determine whether it is more strict in regards to server-side cleanup or simply covered an 'oops.'

so all we need to do is fix all the 14 billion bowsers installed and we will be ok. Ken ..you might want to get started now :D I will buy you a beer when I see you next .. LOL

 

[rpmws]

But if I do it, what will Mario and Luigi do?

same as always ..convert "working hard" into "hardly working" ..but from what I understand they are who everything bad gets blamed on there. I think the real problem might be too much Scooby Doo :D

 

[horustwohawks]

- snip - clearing out any server-side session information, but if the browser doesn't provide a mechanism for HTTP Authentication logout then it will over-ride what we do.

For example, older browsers (e.g. IE 6, Opera 8, etc) would ignore the logout request and simply log you in when using the back button. This was the case for webmail, cpanel and WHM, because the Client (the browser) still had a properly authenticated 'token.'

I haven't examined the fix performed during internal tests to determine whether it is more strict in regards to server-side cleanup or simply covered an 'oops.'

I was wondering about the browser's Authentication management...
If at login a cookie is used to set a token for authenticity of the session, and the hash is set on the server (and I would think in the cookie as well, but this is part of the question), then I would think that a "logout cookie" (as opposed to relying on a browser "mechanism for http authentication logout") could be used to set an alternate digest authentication hash that would effectively require a login again from that browser - does this make any sense, and if so couldn't this work?

I was observing the hash in @pwcache (through the "etc/.." folder) while testing before and and what I thought was interesting is if you messed with the hash (albeit its cached I realize, but still) if I did the back button / history-link thing to get back in I sometimes would observe the hash changing. I always got back in regardless. I couldn't quite make senses of this - didn't seem logical, but then I do not really know what's happening...

Since I do not have a proper understanding of whats happening my presumptions could be all incorrect, but what I was thinking about this was if the browser somehow still had a token, it would be keyed in to/with the generated hash - right(?), so if I messed it on the server, how in the heck was the browser causing the server to recreate a new hash? I thought the hash would be the key in as far as authenticating that the password was entered correctly for that session. If true, then I would think that no matter if the user got in for a session one time, if the hash were to 'fail' during the session, or be forced to something else (as thru a timout or logout) I would think the system could then force a re-login by the same user, "flakey browser http authentication mechanism" be damned - no?

This brings up the question, so how does a time-out session work? Most places where they set a time-out simply have no way of allowing the user back in without logging in again. For instance, you can be assured this will not happen on any browser while accessing your accounts at the bank, period!

Considering that, if anything I am saying is in the neighborhood of being real, then it would seem that it doesn't matter if the browser is flakey in its handling of Authnetication, this could be worked around in some simple manner - no?

Food for thought, or..?

Cheers,
HTH

 

[cPanelKenneth]

I was wondering about the browser's Authentication management...
If at login a cookie is used to set a token for authenticity of the session, and the hash is set on the server (and I would think in the cookie as well, but this is part of the question), then I would think that a "logout cookie" could be used to set an alternate digest authentication hash that would effectively require a login again from that browser - couldn't this work?

I was observing the hash in @pwcache (through the "etc/.." folder) and what I thought was interesting is if you messed with the hash (albeit its cached I realize, but still) if I did the back button / history-link thing to get back in I sometimes would observe the hash changing.

Since I do not have a proper understanding of whats happening my presumptions could be all incorrect, but what I was thinking about this was if the browser somehow still had a token, it would be the hash - right(?), so if I messed it on the server, how in the heck was the browser causing the server to recreate a new hash? I thought the hash would be the key in as far as authenticating that the password was entered correctly. If true, then I would think that no matter if the user got in for a session one time, if the hash were to 'fail' during the session I would think the system could force a re-login by the same user - no?

The authentication only happens once, not on each access. Once the authentication is successful, the client is authenticated and stores the authenticated token, or hash. As long as the client continues to have the token, the authentication is still valid. Each page request merely checks for the token.

It's been a while since I looked at the spec for HTTP Authentication, so bear that in mind for the following:

The token/hash you find in the etc directory is simply a cache, not necessarily the one used to maintain the authenticated session. This is why you will observe a modified cached token/hash being reverted to the old value, because the Client still has a valid token. Modifying the cache does not force a re-authentication, which would invalid the token the Client has.

This brings up the question, so how does a time-out session work? Most places where they set a time-out simply have no way of allowing the user back in without logging in again.

Considering that, if anything I am saying is in the neighborhood of being real, then it would seem that it doesn't matter if the browser is flakey in its handling of Authnetication, this could be worked around in some simple manner - no?

Food for thought, or..?

Cheers,
HTH

Let's clarify a few things:

There are two primary methods of authentication on the Web:

1. HTTP Authentication - of which there are two methods
   1. Basic
   2. Digest
2. Form Authentication - uses cookies

cPanel currently uses HTTP Basic Authentication, which is a bare-bones affair. There is not such thing as a session-timeout with HTTP Basic. HTTP Digest does allow for session timeouts, again as long as the browser supports it. HTTP Authentication is dependent upon the web server and the web browser.

Form authentication, which cPanel can use by setting a tweak setting, is quite a different 'beast.' It is primarily dependent upon the web browser accepting cookies (although there are ways around that) and the skill of the programmer(s) implementing the authentication functionality in the web application. With this type of authentication, there is theoretically no limit to what can be accomplished (session timeouts, forced resets, 2-phase authentication, and on and on). This is because it's dependent upon one thing on the client: acceptance of a cookie.

Whereas the HTTP method relies upon browser vendors accurately implementing a specification. As a programmer, there is little one can do to control or improve HTTP Authentication, which is why the majority of web sites do not use it.

My prior comments were regarding the HTTP Basic Authentication as implemented in cPanel.

 

[horustwohawks]

Thank you for taking time out to be offering that understanding to some real basics, Kenneth. That helps.

Cheers,
HTH

 

[cPanelKenneth]

Thank you for taking time out to be offering that understanding to some real basics, Kenneth. That helps.

Cheers,
HTH

No problem.

 

[rvskin]

I would suggest add JavaScript to alert user to CLOSE windows upon the logout or programming JavaScript to close the windows automatically. This way you can cut 99% security risk.

 

[mctDarren]

But if I do it, what will Mario and Luigi do?

Has someone been playing too much Super Smash Bros Brawl on someone's Wii??

... Like my son and I have for the past couple days?