Lion's passwords can be changed by local users | CompuScoop.com

Click to find out more information

In OS X, user passwords are encrypted and then are stored in files called “shadow files” which are placed in secure locations on the drive. Based on system permissions, the contents of these files can then only be accessed and modified by the user, or by administrators provided they first give appropriate authentication. This means that only the user can change its password, or if needed, then an administrator can do this by first authenticating.

Thank you for reading this post, don't forget to subscribe!

Unfortunately, recent discoveries have shown that in OS X Lion this security structure is not intact, and any user on the system can modify the passwords of other local accounts quite easily. The problem at hand appears to be because of a permissions oversight that allows all users search access to the system’s directory services.

In late 2009, the security blog “Defence in Depth” covered a method for cracking OS X passwords where users could extract the password hash for other users on the system; however, doing this ultimately required admin privileges. The post outlined that technically on systems prior to OS X 10.7 that user passwords could be extracted, but this ultimately could only be done by people with administrative passwords. Recently the blog outlined the new findings in Lion, where this can now be done by nonadmin users.

In Lion the permissions for the user’s shadow files are still restrictive and prevent tampering; however, the need for direct access can be bypassed in because the system holds the password hashes in the system’s directory services, which any user can look up. As a result, the hashes can be extracted without needing to supply admin privileges, and then be run through various hacking tools and scripts to recover the user’s password.

In addition to being able to extract the password hashes for a user, any user can also directly change another user’s password, including those of system admins, merely by supplying the following command in the Terminal (substituting USERNAME for the short name of the target account):

dscl localhost -passwd /Search/Users/USERNAME

When run, this command will appear to give an error, but if you enter the same new password at all prompts then the target account’s password will be changed. This is particularly notable, because once an admin’s password is changed, the hacker can log in as that the admin account and have full access to the system.

Overall this issue in Lion means that any user (even nonadmins) can extract or change the password of another user’s account, provided they have access to the directory, such as via the Terminal utility. However, this problem does have two limitations:

  • Local access
    The first is that the hacker needs to have access to local accounts your system, which means that you will have had to set the hacker up with an account beforehand. This hack can be done remotely with SSH connectivity, but the hacker would need to already know a local account username and password to do this. Alternatively the hacker can approach a system that is already logged in and change the passwords of accounts on it, but in this case the hacker would still need local physical access to do this.
  • Directory service access
    Besides local access, the hacker then needs to have access to the system’s directory services (such as via the Terminal). Even if a hacker can log into the system, without access to the directory setup then the hacker will not be able to modify account information.

As a result of these restrictions, there are a few steps you can take to help better secure your system until Apple has released a patch to address this problem:

    1. Disable automatic log-in
      OS X has the option to automatically log in to a system. While this is convenient, it is also a security risk (especially for administrator accounts). By disabling automatic log-in in Lion you can prevent your account from being accessed merely by restarting it, and thereby prevent access to the Terminal and other utilities that can allow access to the directory services. Note that if you have FileVault 2 enabled, then automatic log-in will not be enabled.
    2. Enable sleep and screensaver passwords
      Since this problem can be taken advantage of by anyone with physical access to an unlocked account, if you leave your system in a public area then someone can sit down at your account and invoke this hack. Therefore, enable a password both for waking from sleep and for when the screensaver starts, to prevent unauthorized access if you step away.
    3. Disable Guest accounts
      If you have the Guest account enabled on your system, disable it in the Users & Groups section of System Preferences. Furthermore, only keep accounts active that are regularly used by people you know, and delete those that are no longer in use.

Enable parental controls on all accounts, turning off any program that has access to the directory services, including the Terminal and X11 (for xterm).

  1. Manage users on the system
    It may seem easy to just set up all accounts with administrative privileges, but this setup is not a secure way to run the system, especially given this latest security issue. In OS X you can set up one admin user and then set all other users to be managed accounts. This will allow you to govern whether they have access to tools that could modify the directory services. For instance, since the Terminal allows for this you can disable access to that program for all accounts on the system except for the Admin account. If you enable the “Limit Applications” feature for an account in the system’s Parental Controls, the Terminal and other similar utilities will be disabled by default for that user.

Once again, for now this problem only appears to be a risk if your system is accessed directly by a hacker who has the ability to log in and access the directory services with a tool that can modify the directory services’ settings. Setting up a more restrictive environment for accounts on the system should be enough to prevent this latest flaw from being taken advantage of until Apple releases a patch to fix the problem.

Via: C|Net.com

About Post Author

(Visited 4 times, 1 visits today)


Advertisement

You may have Missed:

Verified by MonsterInsights