Slashdot Mirror
'Opener' Malware Targets OS X
the_webmaestro writes "Macintouch.com is covering the "opener" malware, a new and potential vulnerability which affects Mac OS X. If true (it's not on HoaxBusters yet), this could become a Mac user's worst nightmare... Worse even than Microsoft Word macro viruses (heretofore the only real 'viruses' which threatened Mac users)! Normally, when ever I'd see virus alerts, I'd revel in the fact that as a Mac user, I was immune (except for the slow-down of the net, the loss in productivity of my colleagues, and the increase in SPAM--often coming from my friends and colleagues). [Sigh] Perhaps, my days of telling friends and family that there are no viruses for Macs may be coming to an end. There have been stories."
As this Bash script (that's all it is) needs root access or physical access to the machine to propagate, I am not too concerned. Root is disabled by default on all shipping Mac's and if anyone has physical access to your machine then you are in serious trouble anyway.
Saying this though, keeping your Mac patched is probably the best idea. Some vulnerabilities in Mac OS X can give you root privs, but having the firewall on and only services that you need enabled (none are enabled by default) will protect you from those issues.
OS X does this to a certain extent in that it tells you what application is running the security dialogue and what key it's requested, but unfortunately anyone can fake that interface in seconds. One thing to sure of is that when you type in your password it is into a normal OS X password box, anything else and the program gets to see the plain text of your password and could do anything. If it's the system's password box then the system does all the authentication and the program never gets a chance to steal the password.
Bob
The best fix for this problem is to apply common sense. Do not give your admin password to any application except an installer for software acquired from a trusted source, or the OS X system utilities.
I am TheRaven on Soylent News
UNIX? They're not even circumcised! Savages!
Damn! Forgot to cover the ampersand... Each successive call of the command *also* spawns a seperate instance of itself, behaving in the same manner. Exponential growth and recursion too!
UNIX? They're not even circumcised! Savages!
Automator won't do much more that AppleScript couldn't already do (which is quite a lot, since you can AppleScript the Terminal and give it shell commands), it will just give scripting a point & click interface.
As a poster above said, a script by itself, whether it be Bash, AppleScript or Automator, is not really much of an exploit, it's the manner of getting on to the system that is.
Automator is just a friendly GUI on top of AppleScript, which has been around since System 7.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Causing the OS to respond as if to the control-alt-delete sequence is not a problem - the OS puts up its dialog box which is presumably secure.
The concern is if an application can intercept it when you do it on your keyboard, and stop the OS from putting up the box, but instead put up its own version that looks the same.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Yes, there were viruses in the pre-OS X days. But the crappy article summary was obviously talking about OS X. Do you have any examples of OS X viruses? Without one, you have no point, and sound like a troll.
Sure, virus scanners are proof of viruses. It's definitely not possible that the company behind VirusBarrier is just trying to trick people into buying a product they don't need. Because corporations don't want profit, right? They'll just try to justify the program's existence by adding features for non-virus stuff and claiming they're building an infrastructure for fast response if there ever is a virus. So mod parent down -1 Troll!
Something about the writing style of this story really strikes me as sensationalist.
"Oh woe is me! I have a Mac but someone might (cringe) hack it! And think of all those people who trusted me when I recommended Macs as safe! The world should be ending around 3pm today Eastern Time...."
And it's not even a vulnerability! Geez, it's almost enough to make me think this is just someone grinding an axe.
Go into Netinfo, enable root account. You can now log in as root.
Back when OS X was pretty new, lots of *nix illiterates used to think you had to be logged in as root to have all the administrative powers of the system. Lots of software would be broken by it, and shareware developers would be swamped by email by people saying "I'm logged in as root and your program doesn't work".
Vonal Declosion
On a current 10.3.5, i've just confirmed that /Library/StartupItems is rwxrwxr-x for root:admin. This means that any user that can "administer this comuter" can write in here without sudo or providing an administrator password. I'm running a permission verify to see what it says about this situation. Personally, I see no reason why this directory should be group writable.
You can make it a lot worse that that. It is (somewhat) exploitable by a timing attack if your virus waits patiently for another program to start installing. There is probably some recognizable signature you can check for in ps, and just keep running it repeatedly. Once another program is installing, the virus can then jump in and do the operation that requires root, thus popping up a dialog box. The title will probably be wrong, but the timing of the dialog box will be *right*, so most users wouldn't notice except for a second box popping up later. They'll probably convince themselves that they mistyped the password the first time.
This is a common vulnerability to just about any shared medium, and why users need to be careful even just running untrusted programs as a user. The unix equivalent is well timed "password" prompts from malware when the user runs something else they expect to generate such a message, such as ssh.
In fact, you have to do none of the above - you just have to have admin rights (which most not-so-unix-savvy Mac users probably do because the don't bother to add another account beside the one created during system setup, which *does* have admin rights) and run some program from a not-really-to-be-trusted source (e.g. some "nifty freeware tool") which contains the script and installs it without further user interaction. Users with admin rights do *not* need to login as root or to authenticate to install files in
Cthulhu fhtagn!
any mac coder aroud to port tripwire to macos X ?
DarwinPorts already offer a Tripwire port for OS X.
Hm. On my 10.3.5, I have these settings, which are perfectly sane:
/Library/StartupItems/ /Library/StartupItems/
$ id
uid=501(alex) gid=501(alex) groups=501(alex), 79(appserverusr), 80(admin), 81(appserveradm)
$ ls -ld
drwxr-xr-x 3 root wheel 102 4 Aug 11:12
I can't remember changing the modes and ownership my self.
The most frightening thing is that if you read the evolving thread on the shell script in question, the "developers" seem to have trouble understanding what simple commands do. "What does 'find' do?" ... Yet, there's enough of them that they end up producing something that, at least, appears like it might function, and might serve some relatively benign but nefarious purpose...
Kinda like linux....
You might also want to take a look at radmind:
"At its core, radmind operates as a tripwire. It is able to detect changes to any managed filesystem object, e.g. files, directories, links, etc. However, radmind goes further than just integrity checking: once a change is detected, radmind can optionally reverse the change."
Come to the University of Mars! Classes starting soon!
There's a bit of a complication to your idea of using MD5 sums to verify the integrity of executables on Mac OS X: prebinding.
I work at the configuration and deployment level rather than the source code level most of the time, so I may not quite explain this correctly. But one of the performance optimisation features of Darwin / Mac OS X is to pre-bind executables to libraries which would otherwise be dynamically linked at runtime. This makes launching an application faster.
In doing so it actually alters the executable file itself. Most install packages explicitly do this as a post-install step, and the runtime system itself will attempt to re-bind any executable it finds without valid prebinding information.
The specifics of prebinding differ from machine to machine, even with the same OS, library and application versions... so an MD5 checksum of somebody else's binary is going to be useless to you because the files themselves are almost certainly not identical after prebinding has been performed.
Incorrect. You do need to authenticate. As an admin you are given slightly brouder privileges, but you are not in wheel. You need to sudo (or the GUI equv) to write to anything in /System/Lib
Actually, the default account created by system setup (at least on my Mac running 10.3.5) is a regular user account for the most part. I can access admin sections of the system, but I am prompted for my password first to confirm that I want to do this. This is really no different than having a seperate user for admin rights, and I feel it's a very good solution.
Sorry, I can't just let this one go. As a nearby poster points out, the
This is on a machine running 10.3.5; I can't speak for earlier versions.
The best newspaper in the USA: the Anderson Valley Advertiser.
No, you're simply wrong. Unlike Linux, by default on MacOS X, there is no root account active. Read that again - there is no root account active. You have to specifically enable it after you've installed the OS. The user created during install does have admin priviledges, but that doesn't mean that he or she has root priviledges. In fact, this has saved OS X from several vulnerabilities that afflicted Linux and other Unixes in the past.
A key combination (like how XP claims pressing Ctrl-Alt-Del to log in makes your computer "more secure") is a pretty stupid idea, and anything will be able to intercept it before the OS does if it tries hard enough.
Not if the OS is written correctly. Secure attention sequences (the official name for this idea) work, when implemented correctly.
I've noticed that XP seems to have introduced a setting (on by default, even!) which stops it from working, though, which is remarkably daft IMO.
1) Someone said that root isn't active by default. That's sort of true. Root obviously exists. Anyone who is in the group admin can do "sudo" to do a specific command as root. They have to type their password to use sudo. However they can't login as root or su to root, because root doesn't have a password. If you want to be able to su to root, you give root a password by "sudo passwd root" or something similar. That command is not documented by Apple. They intend that users who want to do something as root will use sudo. "sudo bash" would appear to be functionally equivalent to "su", so assigning a password to root doesn't seem necessary, and is probably not best practice.
2) There has been a lot of discussion about creating files in /Library/StartupItems. On a system that was installed from scratch a couple of months ago with the most recent OS, /Library/StartupItems is protected 755 root:wheel. On an older system it is protected 775 root:wheel. But you need to realize that wheel is *not* the admin group. My normal uid, which is an administrator, is not in wheel. The admin group is admin.
This is on a system with 775 root:wheel.Apple has done their best to make sure that you must type the password of an administrator before doing anything one would think of as administrator actions. Frankly I think there are enough corners in any complex OS to get unwary users to install Trojans. But some of the info in this thread has been wrong.
As an admin user though, you should be able to write to /Library/StartupItems. The script will then be run as root on next reboot, and move itself from /Library/StartupItems to /System/Library/StartupItems
What is the robbing of a bank, compared to the founding of a bank? -- Bertolt Brecht
Hm, I remember you used to be able to write directly to /Library/StartupItems without sudo-ing.
/Library/StartupItems/ /System/Library/StartupItems/
That must have been changed with some security update in the last while, because in 10.3.6 they're both
drwxr-xr-x 6 root wheel 204 15 Oct 19:22
drwxr-xr-x 34 root wheel 1156 30 Sep 19:05
What is the robbing of a bank, compared to the founding of a bank? -- Bertolt Brecht
Anyone out there who has installed Aironet wireless drivers, you might want to do something about your permissions in /Library/StartupItems.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Well, technically it's not a trojan horse either. A trojan (horse) always hides itself in vessel, usually some stupid program or excecutable app... This is just a rootkit without andy means of becoming root, so the issue is moot...
I am running 10.3.5. I just repaired permissions.
/Library | grep StartupItems
/System/Library/StartupItems. That is a separate folder and it seems to be what the other people are referring to.
/System/Library | grep StartupItems
/System/Library one is owned by root. The one under /Library is not.
ls -al
gives the following
drwxrwxr-x 5 root admin 170 16 Aug 00:06 StartupItems
It is owned by the admin group. All admin users have write access.
I think the confusion is with
ls -al
gives the following
drwxr-xr-x 34 root wheel 1156 9 Aug 17:58 StartupItems
The