KBOX security vulnerabilities
Hi ALL,
I want to highlight a main issue ( mainly i am suffering from ) which is i am facing in kbox, i am not sure if there is any solution there or someone else point out the issue , i did not find it if any,
Please do mention solution and feed back.
We use to run multiple scripts including password change / admin rights change and other administrative and security changes on our KBOX clients and surely we did not want our user's to know these settings.
But problem is that kbox keep cache / history of scripts and activity it perform on the system which can be viewed by any user.
Please help me out if there is any settings that KBOX did not keep history on the client systems ( " program files\kace\kbox\kbots_cache).
or it can be kept in encrypted form.
Sorry for the long detail , but i am sure every one understand my point.
Help required.
I want to highlight a main issue ( mainly i am suffering from ) which is i am facing in kbox, i am not sure if there is any solution there or someone else point out the issue , i did not find it if any,
Please do mention solution and feed back.
We use to run multiple scripts including password change / admin rights change and other administrative and security changes on our KBOX clients and surely we did not want our user's to know these settings.
But problem is that kbox keep cache / history of scripts and activity it perform on the system which can be viewed by any user.
Please help me out if there is any settings that KBOX did not keep history on the client systems ( " program files\kace\kbox\kbots_cache).
or it can be kept in encrypted form.
Sorry for the long detail , but i am sure every one understand my point.
Help required.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
airwolf
12 years ago
I wouldn't consider this a security vulnerability, but definitely an insecure design flaw. I would like to see all plain text scripting (e.g. batch files) deployments encrypted on the client as well.
One way to get around this is to write your own encrypted and/or compiled scripts. We use AutoIT to deploy anything with secure credentials - we can compile and encrypt the scripts so end-users cannot view the contents.
One way to get around this is to write your own encrypted and/or compiled scripts. We use AutoIT to deploy anything with secure credentials - we can compile and encrypt the scripts so end-users cannot view the contents.
Posted by:
merrymax
12 years ago
Dear Andy ,
I appreciate your views , but i think this is a security vulnerability , if you are running a business where data is very critical and you want your systems to be secured then this is a security vulnerability otherwise any it person will read the contents and remove restrictions as per required.
But i would like to see that data should be kept encrypted.
I appreciate your views , but i think this is a security vulnerability , if you are running a business where data is very critical and you want your systems to be secured then this is a security vulnerability otherwise any it person will read the contents and remove restrictions as per required.
But i would like to see that data should be kept encrypted.
Posted by:
tpr
12 years ago
I understand that it isn't a security vulnerability within kbox, per se, but there should at least be alerts on the pages where scripting or software packages are configured so admins will know that plain text passwords will be viewable.
Posted by:
cblake
12 years ago
Any scripting solution (including AD) has a similar opportunity for this issue. It's the nature of scripting- least common denominator is command line. If you are at the keyboard typing in your stuff it's being logged, and I can get at it easily, and the only sure way to work around it it so compile your scripts. AutoIT or AdminScriptEditor are great tools for this. That's what I do no matter what tools I'm using to execute the script if I need to pass creds without advertising them in clear text. Hope that helps.
Posted by:
nshah
12 years ago
This might be a simplistic approach but why not just delete the folder the script would install under after running? Password changes need to happen once so you aren't really needing it to stay there for a long time or you can have the script enable to run once a week or on demand in the event someone changed it. This of course has issues if you are running something repeatedly where then you would need to protect the files...etc as Airwolf and cblake mentioned.
C:\ProgramData\Dell\KACE\kbots_cache\packages\kbots
C:\ProgramData\Dell\KACE\kbots_cache\packages\kbots
Posted by:
ninjamasterpro
12 years ago
I think it should be handeled properly or KBox should not give history in XML format because any smart user can view it and get the passwords or other security settings.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.