Jump to content

Buckit

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Buckit

  1. Oh, I have the SUDO-through-LDAP working just fine, that's not the issue. The issue is that the "Defaults:pstate rootpw" line is not something that I can mangle into LDAP. Or at least, I haven't been able to make it work yet. And I -really- don't want to adjust all the local /etc/sudoers files. EDIT: Scratch that! The sudoers.ldap documentation provides one very important detail: Ace! So now, if I want to make things work with the default PasswordState scripts, it's a matter of: CN=pstate-ECHO,OU=sudoers,OU=domain,OU=local: sudoHost = ALL sudoCommand = /usr/bin/echo sudoOption = rootpw sudoUser = pstate CN=pstate-PASSWD,OU=sudoers,OU=domain,OU=local: sudoHost = ALL sudoCommand = /usr/bin/passwd sudoOption = rootpw sudoUser = pstate All that is left right now is to make sure that SUDO will always ask for a password instead of having that passwordless grace period. Otherwise you're gonna run into the "passwords don't match" dealio, because the initial password prompt does not appear. Nice!
  2. ACK... In the meantime I'll keep on looking for alternatives to test the root password. EDIT: An alternative, yet again using Python, would be the Python PAM library -> https://github.com/FirefighterBlu3/python-pam. However, as before that would introduce a requirement for Python (plus a non-standard lib) on the client-systems. I can of course make sure we meet these requirements on our end and use a custom validation script, but it won't help PasswordState users in general. python -c "import pam; pam.authenticate(root, secret)" There's also PamTester, but that's ancient and not included with Linux distros. The Python lib described above would be more elegant. I wish PAM itself would include something similar to PamTester!
  3. As Sarge pointed out, this would not be easy to do. Aside from the technical feasibility, there is also the desirability of such a modification: persistent shell history across sessions is one of the core and oft-used features of the Linux shell environments. Taking it out would be like telling a Windows admin that they couldn't use keyboard shortcuts anymore.
  4. Woof, this is a toughy. Thing is, sudo.ldap does have a way of pulling Defaults from "CN=defaults,OU=sudoers", but I haven't yet figured out how to plonk "Defaults:pstate rootpw" in there properly. I haven't found any proper examples yet and what I've tried so far leads to syntax errors. Trying to do away with the need for the rootpw clause entirely, I've taken to looking for alternative ways of verifying the known password. I've gotten the following to work: SALT=$(sudo grep ^"root:" /etc/shadow | cut -d\$ -f3); diff <(sudo grep ^"root:" /etc/shadow | cut -d: -f2) <(python -c "import crypt; print (crypt.crypt('${KNOWNPASSWORD}', '\$6\$${SALT}\$'))") The downside to this is: We assume that Python is installed. The privileged account will also need SUDO privileged to grep. That's nasty. We can of course limit it to "grep * /etc/shadow" but it's still not very nice. It certainly ups the level of risk. An alternative to using the Python solution, would be mkpasswd. However, that's not available on all Linuxen and I understand that its functionality also differs per distro. Darn. EDIT: Now, with regards to verifying that a change was made as part of the reset script, there are a number of options. Easiest of course would be to verify whether /etc/shadow was changed within the last minute. It's not foolproof, but better than nothing. There is also the following: diff <(sudo passwd --status root | cut -d" " -f3) <(date +%Y-%m-%d) Again, not foolproof as it will only validate that a change was made today. Of course, on distros where it's available, /var/log/secure will contain an entry mentioning that the account's password was changed.
  5. Good morning guys First up, I sincerely hope I didn't sound too dickish in my first posts of this thread. I learned a few things today, thanks to you all But we'll get to that. Now... I realize that catching all the right messages is going to be hard. One nice work-around would be to do what I suggested: verify the password immediately after setting it. Don't assume that if the change-script reports a success, that it actually worked. Right now, heartbeat status is set to green after a change, so why not let PasswordState do an actual verification? Personally I'd auto-set it to grey after a reset, not green. Sarge, on to your points: Ha, I learned something today! Thanks! That makes sense and I feel stupid for not know this upfront. That's also why the following didn't make much sense until now: I did not gather the right urgency from the manuals regarding that particular topic, so I went against it and never applied the rootpw. Now, since we're managing our SUDO-rules centrally in LDAP I'll poke around and see if we can't apply settings like these on a per-rule basis. I hardly feel like modifying /etc/sudoers on our hundreds of boxen. I know, a config manager like Puppet would do wonders; don't get me started After I posted that blurb I poked around some more and it seems like the issue may be something else entirely. I'll prod the croc some more. I also have a fun idea to verify the password in a completely different way. I'll try that out before making a bigger oaf of myself ... and back to Support: Heck yeah, I'm on it like... well, insert any colorful analogy of your choosing. I'll test that asap. That's some awesomely fast work you've done. Thank you! I've been saying this to many colleagues: I've got nothing but good words for Click Studios. You're friendly, professional and quick to respond. I love your quick turnaround on patching as well Great work. I'll keep you posted.
  6. Yeah, we'll definitely look into having a break-glass account. The stupid thing is, usually PasswordState is where we keep our break-glass accounts! So now we have to find a new solution for that. A solution that will withstand the test of time, as employees will come and go while PasswordState is here to stay.
  7. I have also found why the password changes are failing: the PAM module pam_pwquality is interfering. Apparently the passwords are TOO long or complicated. I'll poke around some more. The original point stands though: the false successes are a potential disaster. EDIT: Another thought... Why does running the password reset script also set the heartbeat status light to green? It does not actively go out and test the password after setting it, so this is another false flag. It would be much better if, after changing a password, it was immediately verified as well. That way you'd immediately know if things failed, despite the change-script reporting a false success. That's a feature request right there: always validate/heartbeat after a password change! Never assume success.
  8. Well, I'm a bit less confused why you would use "sudo echo". It's a cute way of verifying the user's password if it's the root account. Funny if ($Username -eq 'root') { $ValidateCmd = " echo '$CurrentPassword' | sudo -kS echo Password Validated || echo Password Incorrect`r" } else { $ValidateCmd = " echo ' $CurrentPassword' | su '$username'`r" } This whole section's weird though, because this command blurb is only applicable when $PrivilegedAccountUserName -ne "". We're connecting as the priv. user and we're validating root; you don't want to use sudo here, you want to SU to the target user. Unless you''re again assuming that the SUDO rule wants root's password. Which it won't; that's not normal behaviour. Putting that aside, the command fails either way and the script fails to pick up on it. It still falsely reports a success. I'll try and dig up why it does that. EDIT: Yeah, I've found it... $results = $ssh.GetReceivedText($channelNum, "ansi") if ($results -eq $null) { $exception = New-Object System.Exeption ($ssh.LastErrorText); throw $exception } if ($results.toLower() -like '*: password validated*' -or $results.toLower() -like '*:password validated*') { Write-OUtput "Success" } else { if ($results.toLower() -like '*authentication failure*') { Write-Output "Failed to validate password for account '$UserName' on Host '$HostName'. UserName or Password is incorrect." } else { Write-Output "Success" # <-- SMOKING GUN } } The mind boggles. If the output does not match the expected success result, nor does it match the expected error result, we just assume that it's a succes?! O_O I'm changing that locally to instead write something like "Unexpected failure on the Linux side."
  9. Hi again, In a situation very similar to my earlier thread about problems with the Windows password resetting script, I am now also running into issues with the Linux resetting and validation/heartbeat scripts. SYMPTOMS: Running a password change against an account, using a privileged account for Linux, reports a false positive: the password is not changed, but the reset button turns green. Running a heartbeat validation against the account which was changed (but which did not change) reports a false positive: PasswordState says the new password is valid, while it is not. REPRODUCTION: I'm running build 8180, on 2012R2 with Powershell 3 and a local MSSQL Express. I'm resetting two local accounts (e.g. in /etc/passwd and /etc/shadow). One is "root", let's call the other "bob". The accounts in question cannot login through SSH, so I'm using a privileged account. Let's call it "pstate". The privileged account ("pstate") can SSH into the system. The privileged account ("pstate") has one SUDO command allowed: /bin/passwd and /usr/bin/passwd. Host records and user/password objects were made in PasswordState. The current password for the users is entered into the record. PasswordState can connect to the host just fine and the priv. user "pstate" is seen logging in. I now ask PasswordState to: heartbeat, expire, heartbeat for both local accounts ("root" and "bob"). OUTCOME: PasswordState reports that the initial heartbeat is OK/green. PasswordState reports that the password reset is OK/green. PasswordState reports that the post-reset heartbeat is OK/green. However, testing the password locally (with "su - root") fails. The logs show the password is incorrect. The local /etc/shadow files also show that zero updates were made. The logs also show that the SU for the post-reset heartbeat fails! The SUDO logs report a number of failed SUDO commands for the priv. user "pstate". See logging below. One is the "echo" command. Seriously, why the heck would you "sudo echo"?! That makes no sense. CONCLUSION: It is my conclusion that, similar to the other issues I have reported before, the outcome validation of the plugins and scripts of PasswordState is severly lacking in error detection. Many situations report false positives, which will lead to big problems down the road! What would we do if our root passwords turn out to be incorrect during a large outage?! LOGGING: Now, I feel silly saying this, but I cannot currently pull the text logs from the testing environment. We'll have to make do with screenshots for now. ROOT CAUSE ANALYSIS: I will start delving into the Powershell scripts to search for more background on the matter. SUGGESTIONS: I don't know why or when you added the design assumption that "sudo passwd root" should ask for the root account's password. I've never seen that in production environments, so it's a bit odd to have that in there. I would just as soon dike that assumption out in your official product, but doing so would break the installations for all your other customers. We're all kind of stuck now More to follow... Cheers! Thomas
  10. Right'o! Well, let's make it a feature request, for us to have the ability to create new managed types through the GUI. It'd be even better if you could specify the scripts to be used, but that'd be the cherry on the sundae
  11. Thanks for the heads-up Azkabahn! That's a good thing to keep in mind. Being a Unix-person I'm used to dealing with Syslog, so I hadn't expected difficulties with importing such a stream. I know that Splunk has proper parsers for the format, but thanks to you I realize that not all solutions are created equal
  12. Right now we're looking at simply offloading it for safe storage. In due time we might move towards a sexier solution that involves something like Splunk.
  13. Hey guys, I'm in the process of building a wad of new plugins, to manage various IoT devices. I have already defined new host and OS types for these and the boxen have been registered as hosts. Now comes the time to start adding password records to the database, which is where I fall flat. I've added new account types through the administrative section of the GUI. However, none of these new types are set, nor can they be set, to "managed" status. I'd really like to do this though, and set up automatic linking to the correct (newly made) plugin scripts. Is there a way of doing this that doesn't require me trudging through the MSSQL backend? I could of course just lie and use an existing account type, manually setting the right script each time, but that feels inelegant.
  14. You make some great points, thank you! I have already resolved to using an external Syslog box for the audit logging; that should suffice in that regard. And I hadn't thought of the SQL Server encryption yet, I'll thrown that in with the team and see what they think. Thank you!
  15. Ah, I wasn't aware of those limitations. I'm only used to extensions in Safari, which can be downloaded and installed as separate files. Thank you for explaining!
  16. Understood, that's an option of course. But in this case we're looking at situations where zero personnel have their PasswordState admin rights activated and where all heck breaks loose. Thanks for taking the issue into consideration, I appreciate it.
  17. Hiya, I was poking around the MSSQL database backend for PasswordState and noticed a few fields that are not stored with encryption, while they could be (ab)used to gain access to sensitive data. Or to wipe tracks should an actor gain access to the database and/or PasswordState. Obviously it's imperative that the database backend is secured to the teeth, but it's also not unlikely that the designated DBAs do not have admin-rights in PasswordState. Having access to the database may thus lead to an escalation of privileges. Most notably: Valid usernames may be harvested from the database, but I realize there's not much we can do about that. The dbo.SecurityAdmins and dbo.SecurityGroupsMembership tables are unencrypted. Could it be that the GUID field plays a role in checksumming the data, to ensure that nobody is adding access rights to their own account? Valid usernames in dbo.PrivilegedAccounts are not encrypted, giving insight into juicy targets for other platforms. Is there some method of auditing the dbo.Auditing table? What prevents a DBA from diking out a bunch of incriminating evidence? Anywho... just some thoughts, while at the office in those lost days between one holiday and the next
  18. Hi again! Another day, another RFE I was wondering whether it'd be possible for you guys to include the browser extension installers with the base PasswordState installation, similar to what you already to with the Remote Session Launcher. Not all customers will have access to the browsers' respective extension / app stores, so it'd be great if they also came with the base installer. Cheers, Thomas
  19. Hi guys! The current implementation of AD-coupled security groups works well enough for us. However, in our current use-cases even the 5-minute fastest-sync-possible may not be fast enough at times. Our sysadmins need to jump through an RBAC-portal to activate certains roles and AD-groups before working on specific cases, which means that they don't have access to their PasswordState groups 24x7. In case of a huge fire / outage /end-of-the-world even five minutes may make a difference, no? Would it be possible to change PasswordState's behaviour in such a way that it verifies the Active Directory MemberOf information for a user when he/she logs in? I realize this may lead to N-amount of hops with nested groups, but I reckon you should already have a way of resolving those anyway. So to sum it up: real-time verification as opposed to a synchronized list of groups in the local database. Cheers, Thomas
  20. I see lots of potential for integration with tools like Salt, Chef, Puppet and Ansible through your API. Seeing how it's all http(s)-based, it's entirely possible to build your own toolset to interface between the two. It's certainly not trivial, but if you build things out on a case-by-case basis you can get quick results. I'm doing just that, by building a new set of Powershell commands for my team.
  21. Fun and games! Fun and games... Also, there's a fair amount of Dutchies on these forums! Cool to see...
  22. The initial installation of PasswordState will not startup unless you accept the download of the encryption keys I'll gladly be one of your test subjects! Also, as a sidenote, let me note how much I love your forum software! It's user-friendly, good looking and has all the features I need. I just discovered the "select-text to auto-quote" feature! Great stuff.
  23. Hi again! Eyeing your page on the secure design and implementation of PasswordState, I noticed that it's not yet possible to integrate with HSMs: Hardware Security Modules. Right now, when installing PasswordState, we're given a password-protected ZIP file that has the encryption keys to the password database. These are a vulnerable target and will be a sought-after prize for any attacker. Instead of handling the encryption keys in such a manner, I would like to request that PasswordState be remodeled in such a way that all crypto keys can be locked away in an HSM. I've already put Thales nShield HSMs to good use in other use-cases and environments, and they've proven very valuable. Not only does an HSM ensure that your keys will never be stolen (if implemented correctly), depending on the make and model they will also ensure safe and secure backups of the keys. Many HSMs integrate nicely with Microsofts CNG API, thus providing a standard method for applications to hook into them.
  24. Not necessarily. There's a reason why "I swear I didn't change a thing!" is one of the oft-heard excuses at /r/talesfromtechsupport.
×
×
  • Create New...