Showing posts with label Mac OSX Leopard. Show all posts
Showing posts with label Mac OSX Leopard. Show all posts

Trojan exploiting unpatched Mac OS X vulnerability in the wild

The source code of a trojan horse exploiting last week’s uncovered local root escalation vulnerability in Mac OS X 10.4 andMacshadows 10.5 has been released in the wild, allowing malicious attackers to take advantage of the ARDAgent-based trojan in what appears to be a very short vulnerability-to-malware cycle, since the trojan template was released on the same day as details for the vulnerability emerged.

Discussion and release of the source code originally took place at the Mac Shadows forums, whereas the source code is now circulating across many other forums and IRC chat rooms, including several popular ones mainly visited by Chinese script kiddies.

According to an advisory issued by SecureMac last week :

SecureMac has discovered multiple variants of a new Trojan horse in the wild that affects Mac OS X 10.4 and 10.5. The Trojan horse is currently being distributed from a hacker website, where discussion has taken place on distributing the Trojan horse through iChat and Limewire. The source code for the Trojan horse has been distributed, indicating an increased probability of future variants of the Trojan horse.

The Trojan horse runs hidden on the system, and allows a malicious user complete remote access to the system, can transmit system and user passwords, and can avoid detection by opening ports in the firewall and turning off system logging. Additionally, the AppleScript.THT Trojan horse can log keystrokes, take pictures with the built-in Apple iSight camera, take screenshots, and turn on file sharing. The Trojan horse exploits a recently discovered vulnerability with the Apple Remote Desktop Agent, which allows it to run as root.


http://blogs.zdnet.com/security/images/ardagent_setuid_trojan.JPG


 Compared to this week’s reported PokerStealer trojan horse targeting Mac OS X users, by trying to trick them intoARDAgent-based trojan empowering the malware with administrator capabilities, the ARDAgent-based trojan is doing it automatically, unless of course you’ve already taken care of the issue until a fix for it is officially available.

The author of the trojan, Adrew, even left a copyright notice within, however, it appears that the source code for the trojan isn’t a one-man operation, but the result of a collaborative discussion aiming to add as many modules as possible. Here’s what he thinks of OS X security, according to his own statement :

    “Apple tells us that OS X is safe and secure and fails to actually confirm that it is so on their own. We are left to experiment and test our own security and too often we discover that we aren’t actually as secure as we were led to believe,” Andrew said in an e-mail. “When you are seeking information about how to secure your own system, frequently the best sources of that information are hackers, not the vendors.”

Going full-disclosure with the idea to shorten the time until a patch is released by the vendor for the sake of closing the “window of opportunity” for malicious abuse of the vulnerability is one thing, releasing a do-it-yourself trojan template in a vulnerability-to-malware fashion is entirely another.


[Source: zdnet]


Two New Mac OSX Trojans


A report of an Apple Remote Desktop Agent vulnerability recently surfaced. Now there's news of a trojan that can exploit the flaw.

The exploit tool, called "Applescript Trojan horse template" was crafted by forum participants of MacShadows.com. These guys appear to have been hobbyist hackers interested in testing the ARDAgent vulnerability. It doesn't appear to be in the wild at present. We detect it as Backdoor.Mac.Hovdy.a.

What's the ARDAgent flaw? In a nutshell, ARDAgent runs Applescript with root privileges. So once the victim is tricked into installing Hovdy, no user passwords are required for it to do its thing, which is provide backdoor access to the attacker.

You can read more details from Security Fix here and here. SecureMac's advisory is here.

Trojan number two:

There was also another Mac OSX trojan discovered last week.

This one was found by Intego. We detect it as Trojan-PSW:OSX/PokerStealer.A.

Response Analyst Mark G. performed our analysis and provided the following details:

PokerStealer.A heavily relies on social engineering. It comes with the filename PokerGame.app (180Kb), sounds interesting, right?

Trojan-PSW:OSX/PokerStealer.A

However, once executed, it will prompt the user for a password.

Trojan-PSW:OSX/PokerStealer.A

It checks the provided password to see if it matches the username of the machine. If not, it will ask again. It needs the user's password to continue.

What happens behind the scenes is the following: It enables the SSH of the infected machine by running; It acquires the local IP address, subnet mask, private IP address of the router (domain), public IP address by querying via the Internet; It gets the version of OSX, recovers its hash and saves it to a file named secret_file.

After all the necessary information has been gathered it then sends the information to a specific e-mail address with a subject of Howdy and the message details include username, password, and IP addresses.

With the e-mailed information, the attacker can perform routines from a remote location through SSH without the user knowing it and may even take control of the infected machine.



he PokerStealer.A trojan appears to have been written by someone with more than just hobbyist level motivations.

PokerStealer's infection is limited by the password requirement.

So what do you think happens next?

That's right. The author of PokerStealer (motivated by profit) is going to seek out the hobbyist's "Applescript Trojan horse template" and will reduce the infection steps of PokerStealer.A to simply running an application named "Poker Game".

How many Mac users do you think like to play poker?


[Source: f-secure]

OSX.Trojan.PokerStealer Trojan Horse

INTEGO SECURITY MEMO - June 20, 2008

Exploit: OSX.Trojan.PokerStealer

Discovered: June 20, 2008

Risk: Low

Description: A Trojan horse has been found in the wild masquerading as program for Mac OS X called “PokerGame”. The Trojan in question is a shell script encapsulated in an application, and is distributed in a 65 KB Zip archive; unzipped, it is 180 KB.


The Trojan horse, when run, activates ssh on the Mac on which it is running, then sends the user name and password hash, along with the IP address of the Mac, to a server. It asks for an administrator’s password after displaying a dialog saying, “A corrupt preference file has been detected and must be repaired.” Entering the administrator’s password enables the program to accomplish its tasks. After gaining ssh access to a Mac, malicious users can attempt to take control of them, delete files, damage the operating system, or much more.

Intego VirusBarrier X4 and X5 with virus definitions dated June 20, 2008 protect against this Trojan horse. Intego recommends that users never download and install software from untrusted sources or questionable web sites.

About Intego
Intego develops and sells desktop Internet security and privacy software for Macintosh.

Intego provides the widest range of software to protect users and their Macs from the dangers of the Internet. Intego's multilingual software and support repeatedly receives awards from Mac magazines, and protects more than one million users in over 60 countries. Intego has headquarters in the USA, France and Japan.

As the dangers of the Internet grow, Intego is hard at work, developing new software to protect users and their Macs from th latest security and privacy threats.

We protect your world.


[Source: Intego]


Local root escalation vulnerability in Mac OS X 10.4 and 10.5 discovered

June 19th, 2008

Yesterday, an anonymous reader released details on a local root escalation vulnerability in Mac OS x 10.4 and 10.5, whichLocal root escalation vulnerability in Mac OS X works by running a local AppleScript that would set the user ID to root through ARDAgent’s default setuid root state. Here’s how it’s done :

“Half the Mac OS X boxes in the world (confirmed on Mac OS X 10.4 Tiger and 10.5 Leopard) can be rooted through AppleScript: osascript -e ‘tell app “ARDAgent” to do shell script “whoami”‘; Works for normal users and admins, provided the normal user wasn’t switched to via fast user switching. Secure? I think not.”

Find out how to fix it.

You’ve got several possible workarounds, you can remove the Apple Remote Desktop located in /System/Library/CoreServices/RemoteManagement/, or you can go through the visual Workaround for the ARDAgent ’setuid root’ problem.

Moreover, the AppleInsider speculates on the potential for abuse :

The effects of malicious code run as root may range from deleting all the files on the Mac to more pernicious attacks such as changing system settings, and even setting up periodic tasks to perform them repeatedly. Not all Macs are vulnerable, however. If a user has turned on Remote Management in the Sharing pane of System Preferences under Mac OS X 10.5, or if a user has installed Apple Remote Desktop client under Mac OS X 10.4 or earlier and has activated this setting in the Sharing preferences, the exploit will not function. Mac OS X 10.5’s Screen Sharing function has no effect on this vulnerability.

And even though the vulnerability can also be executed via a remote connection under specific circumstances based on the configuration, physical security to prevent the unauthorized local access is as applicable as it’s always been.


[Source: Zdnet]


Researchers pooh-pooh Mac OS X Leopard security

Researchers pooh-pooh Mac OS X Leopard securityThe first independent reviews of the security enhancements in Mac OS X Leopard are in — and they’re not entirely pleasant for the folks in Cupertino.

First up is Heise Security’s takedown of the new application-based firewall in Leopard, which Apple promises will specify the behavior of specific applications to either allow or block incoming connections.

However, Heise Security’s Jürgen Schmidt finds cause for concern:

The most important task for any firewall is to keep out uninvited guests. In particular, this means sealing off local services to prevent access from potentially hostile networks, such as the internet or wireless networks.

But a quick look at the firewall configuration in the Mac OS X Leopard shows that it is unable to do this. By default it is set to “Allow all incoming connections,” i.e. it is deactivated. Worse still, a user who, for security purposes, has previously activated the firewall on his or her Mac will find that, after upgrading to Leopard, the system restarts with the firewall deactivated.

In contrast to, for example, Windows Vista, the Leopard firewall settings fail to distinguish between trusted networks, such as a protected company network, and potentially dangerous wireless networks in airports or even direct internet connections. Leopard initially takes the magnanimous position of trusting all networks equally.

[Source: Zdnet]

Apple plugs holes in Xcode

October 31st, 2007

Apple has shipped a new version of its Xcode Developer Tools to patch three security holes that allow malicious hackers to launch code execution or privilege escalation attacks.

Apple plugs holes in Xcode

The update, available for Mac OS X v10.4.x and Mac OS X v10.5, blocks an attack vector that lets a local attacker gain superuser privileges, which may lead to a complete system compromise.

The first issue is a buffer overflow exists in the way Tektronix Hex Format (TekHex) content is handled.

“By enticing a user to run gdb’s “restore” command on a maliciously crafted TekHex file, an attacker may cause an unexpected application termination or arbitrary code execution,” Apple said in an alert.

Two security flaws in the Xcode WebObjects package are also addressed in this update. From Apple’s advisory:

The Xcode WebObjects package contains a demo version of OpenBase for use with WebObjects example code. This demo version of OpenBase may allow a local user to obtain system privileges. This update addresses the issue by disabling the Apple-provided demo version of OpenBase.

Kevin Finisterre, the security researcher who reported the WebObjects flaws to Apple, has posted exploit code (here and here) to demonstrate the issue.

[Source: Zdnet]