Voicemail Recordings Menu Link Prompts for Maint Login

[sanitycheck]

Clicking the Voicemail/Recordings link (ARI) in the main PIAF menu prompts the user for maint credentials before displaying the page, as if this feature were an Admin function (it isn't). However, canceling the login prompt will pass the user to the expected extension login page. The maint prompt will continually pop back up when navigating the site.

TM1000 mentions here that this problem as been addressed in FreePBX 2.8, but upgrading from 2.7 did not fix this for me (on a new, basic 32-bit PIAF 1.7.55 install on a Dell T110 with update-scripts and update-fixes installed as of last week).

Wardmundy mentioned here that this prompt was introduced as a security measure, or was part of a security measure, for servers directly accessible from the Internet. If that is true, and is still true with FreePBX 2.8, perhaps a help-pbx option could be written to eliminate the prompt for servers accessible from the LAN only.

Jroper suggests a work-around by editing the pbx.conf file; but as I read it, this change would eliminate the maint login altogether, allowing normal users to access admin functions. This would be an unacceptable compromise for most.

Kevsworld, too, came up with a work-around. I have not tried it for fear of that change breaking something else now or in the future.

Direct user access to the voicemail/recordings portal is an important (selling) feature of PIAF and FreePBX. I hope an official fix or work-around can be developed for LAN-access-only servers, without having to eliminate password protection on the regular admin features. - thanks

 

[wardmundy]

If security isn't an issue, just...

rm /etc/pbx/httpdconf/ari.conf
service httpd restart

 

[sanitycheck]

Checked that directory today but no ari.conf file exists; only pbx.conf and a pbx.conf file with an additional extension.

 

[tm1000]

Clicking the Voicemail/Recordings link (ARI) in the main PIAF menu prompts the user for maint credentials before displaying the page, as if this feature were an Admin function (it isn't). However, canceling the login prompt will pass the user to the expected extension login page. The maint prompt will continually pop back up when navigating the site.

TM1000 mentions here that this problem as been addressed in FreePBX 2.8, but upgrading from 2.7 did not fix this for me (on a new, basic 32-bit PIAF 1.7.55 install on a Dell T110 with update-scripts and update-fixes installed as of last week).

Wardmundy mentioned here that this prompt was introduced as a security measure, or was part of a security measure, for servers directly accessible from the Internet. If that is true, and is still true with FreePBX 2.8, perhaps a help-pbx option could be written to eliminate the prompt for servers accessible from the LAN only.

Jroper suggests a work-around by editing the pbx.conf file; but as I read it, this change would eliminate the maint login altogether, allowing normal users to access admin functions. This would be an unacceptable compromise for most.

Kevsworld, too, came up with a work-around. I have not tried it for fear of that change breaking something else now or in the future.

Direct user access to the voicemail/recordings portal is an important (selling) feature of PIAF and FreePBX. I hope an official fix or work-around can be developed for LAN-access-only servers, without having to eliminate password protection on the regular admin features. - thanks

The official fix from FreePBX works. Unfortunately (and this is no attack on the PBX in a flash folks) PBX in a flash uses htaccess files because they believe that security is weak otherwise, and at one point it was very weak and you could hack in. However FreePBX fixed this security 'hazard' while PBX in a Flash decided to keep their htaccess files in place. Therefore you will never see an 'official' fix for this issue from FreePBX. You might see a fix from darmock or wardmundy but I doubt it and it's not something everyone is asking for.

You should really just edit that file and move the javascript file or remove the htaccess files as others have said..

The only thing anyone could do now is to create a script for you to fix that. And yes I could do that. But what's the point since to you it won't be 'official' so I doubt you'd use it.

 

[jroper]

Jroper suggests a work-around by editing the pbx.conf file; but as I read it, this change would eliminate the maint login altogether, allowing normal users to access admin functions. This would be an unacceptable compromise for most.

The change suggested would not leave the rest of the system exposed.

The reasoning behind the requirement for directory access was not so much because any perceptions of insecurity in the code, simply that the login is an extension number - relatively easy to guess or discover using social engineering, - and the password could only be numbers, and generally speaking - because of our fixation with bank PIN's - only 4 digits.

Clearly it is not appropriate for everyone to put an extra level of protection in place - e.g. if your ARI is behind a firewall, and only accessible from within your internal network, but may be an optional part of your armoury for security if exposing the ARI to the Internet.


Joe

 

[wardmundy]

The official fix from FreePBX works. Unfortunately (and this is no attack on the PBX in a flash folks) PBX in a flash uses htaccess files because they believe that security is weak otherwise, and at one point it was very weak and you could hack in. However FreePBX fixed this security 'hazard' while PBX in a Flash decided to keep their htaccess files in place. Therefore you will never see an 'official' fix for this issue from FreePBX. You might see a fix from darmock or wardmundy but I doubt it and it's not something everyone is asking for.

Here's the problem with the "FreePBX works" logic. Their spaghetti code was written by dozens and dozens of people over many, many years. Most of the folks have gone. Nobody (including Philippe) knows what's still lurking in all of that code. If you're not familiar with the way FreePBX works internally, try driving your car down the interstate by looking in the rear view mirror. That will give you a pretty good idea of what you're up against coding in the "FreePBX language." Without a clean (documented) rewrite by folks that know what they're doing (which seems more and more unlikely given the fork with FreePBX 3.0), you'd be crazy IMHO to rely solely on FreePBX's security mechanisms if your system is exposed to the Internet. But, if you like being a pioneer, by all means have at it. :eekb:

 

[tm1000]

Here's the problem with the "FreePBX works" logic. Their spaghetti code was written by dozens and dozens of people over many, many years. Most of the folks have gone. Nobody (including Philippe) knows what's still lurking in all of that code. If you're not familiar with the way FreePBX works internally, try driving your car down the interstate by looking in the rear view mirror. That will give you a pretty good idea of what you're up against coding in the "FreePBX language." Without a clean (documented) rewrite by folks that know what they're doing (which seems more and more unlikely given the fork with FreePBX 3.0), you'd be crazy IMHO to rely solely on FreePBX's security mechanisms if your system is exposed to the Internet. But, if you like being a pioneer, by all means have at it. :eekb:

Ward,

I completely agree with you!

 

[sanitycheck]

The change suggested would not leave the rest of the system exposed.

I would like to try your suggestion, but that earlier post did not list specific changes to make to pbx.conf. Could you post those, please? My pbx.conf does not have an ARI section; it has only the following sections: admin, panel, maint, meetme.

Without a work-around, what is the suggested method for dealing with the prompts on new server deployments? Are regular (non-maint) users no longer supposed to use the ARI?

I would have guessed that the locking (or appearing to lock) users out of a key feature like the ARI would have attracted much more attention than it has, and much sooner.

 

[wardmundy]

What version of PBX in a Flash are you using? What version of FreePBX? We support 2.6 only! What other patches have been applied? Have you changed any of our default security model?

If you don't have ari.conf, then PIAF is not imposing the password restriction. It's either coming from FreePBX or from the ARI system itself. Do you get the ARI login prompt? Have you checked whether you have ARI_ADMIN_USERNAME and ARI_ADMIN_PASSWORD settings in /etc/amportal.conf?


By the way, our Apache security model doesn't force you to use the maint password for everything. You can create as many passwords as you like and use them for your apps as you see fit. If you just want to keep the bad guys out, one ari password for all ari users would suffice:

htpasswd /usr/local/apache/passwd/wwwpasswd ari-user

The ari.conf file merely enforces the passwords which you choose to use:

#Password protect ARI interface
<Directory /var/www/html/recordings>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /usr/local/apache/passwd/wwwpasswd
Require valid-user
</Directory>

But, as I said, if you don't have the ari.conf file, then PIAF isn't imposing the password shield.

Try this to find the source assuming it's an Apache-imposed password restriction:

cd /
grep -r /var/www/html/recordings *

Then take a very long lunch break.

 

[Fortel]

Administrator

It sure sounds like you have an Administrator set up... Within FreePBX, are there any users set up under the Setup/Administrator section? If so, try deleting them and access ARI...

 

[sanitycheck]

What version of PBX in a Flash are you using? What version of FreePBX?

I did mention that in the first post, but it's 1.7.55. FreePBX was initially upgraded to 2.7, which seems to be where the problem started. I later upgraded to FreePBX 2.8 as a potential fix suggested by TM1000, but it didn't fix the problem.

We support 2.6 only!

I was not aware of that, but knowing it now, I will not upgrade FreePBX beyond whatever version you install by default unless I read that you support a higher version. I was under the impression that FreePBX 2.7 was a supported and safe upgrade because it is mentioned as the highest supported version in the PIAF Aastra scripts. Aastra apparently tests and supports higher versions of FreePBX in PIAF than you do.

What other patches have been applied?

Only update-scripts and update-fixes. This is a very basic system.

Have you changed any of our default security model?

No.

Do you get the ARI login prompt?

Yes, but only after escaping out of the admin (maint) prompt. I can log in to the ARI just fine, but the same small (maint) login prompt keeps popping up. Again, I can escape it away without having to log in, but it will continually reappear during the ARI session.

Have you checked whether you have ARI_ADMIN_USERNAME and ARI_ADMIN_PASSWORD settings in /etc/amportal.conf?

Yes, they are there. Commenting them out and restarting the system does not fix the problem, so I removed the comments. Thinking it was related (or possibly the same thing), I deleted an admin user as Fortel suggested above; but that didn't fix the problem, either.

By the way, our Apache security model doesn't force you to use the maint password for everything...

Valuable information to know, though in this case even the maint password is not required. A prompt for the maint login comes up, but I can simply escape it away without entering any credentials and get to the ARI login screen. The prompt in this case does not prevent me from getting to the ARI, it's just annoying. I also get a prompt if I try to go to any of the admin pages, as expected, but escaping the login prompt does not let me get in there.

Try this to find the source assuming it's an Apache-imposed password restriction:

cd /
grep -r /var/www/html/recordings *

Then take a very long lunch break.

Did that, and got this output after running for over a day:

grep: dev/usbdev2.4_ep02: No such device or address
grep: dev/usbdev2.4_ep81: No such device or address
Binary file dev/sdb1 matches
Binary file dev/sdb matches

The command never ended to return me to the shell prompt. I tried it twice for > 24 hours and it did the same thing. I had to ctrl-c my way out of it both times.