Detecing Installation of Pirated Apps

[#1]

This is probably an impossible task, but I thought I'd query the list.

Is there any way to detect if an App has been installed via the App
Store, or if it has been pirated and installed using the Kickback
method? Yes, I know that my users shouldn't have admin rights, but
that ship sailed long ago, and in any event, the Kickback method of
piracy doesn't prevent the installation of an application to the
user's Desktop (for instance).

We suspect that we have a small contingent of middle schoolers who are
actively installing pirated App Store applications on their computers,
which is in direct violation of our AUP. So we seek proof of the
pirated app installation and, if possible, a way to detect
installation using a Casper extension attribute.

Drag and drop installations don't leave receipt files in
/var/db/receipts, so I can't query that.

Is there a way to check the "copy protection receipt" that's supposed
to be in properly-written App Store apps?

Thanks,

Damien Barrett
System Technician
Montclair Kimberley Academy
Montclair, NJ 07042
973-842-2812

[ryanhollitz]

Not sure if you can detect, but you certainly could blacklist the Kickback software. That way they can't launch it at all. You can even send a message or an email to the user when this is detected. We blacklist all Pier-to-Pier software in our environment.

ryan

[rockpapergoat]

for app store apps, the app bundle contains a folder (_MASReceipt) with a receipt file inside. that can be removed, of course, but it should be there for copied app bundles.

you could look for those folders/files, i suppose.

you seemed to indicate this activity violates policy, yet you allow local admin rights. those two don't necessarily jive.

if you can't set and enforce policy, you're constantly going to be fighting those fires. at the least, set mcx only to allow apps from the /Applications.

[tlarkin]

This is what I would recommend, in no particular order:

1) Use MCX to restrict what file paths applications can run from, then ensure any student account will not have write ability to that file path 2) Check for group membership of the admin group against all accounts, use dummy receipts or extension attributes 3) Remove the app store completely, to a file path that is not allowed to execute apps, then hide it with chflags 4) Promote training in your labs and from teachers to identify misuse of the school property.

This is what I do in our 1 to 1 here where I work. I used to do the whole white/black list apps via MCX and it became such a pain that I finally decided to change my policies. I know restrict by file path instead. Students are allowed to run all apps with in the /Applications folder and with in /Library/Application Support/ and no other path is allowed. They cannot run apps from their home folder, they cannot run them from a thumb drive, and then I move all apps I don't want them to use (ie the app store) into /Applications/Utilities and deny them access to run apps from that path.

Before we went with Macbook Airs I also used a set of scripts to check for admin group membership and install a dummy receipt (which now I have posted as an extension attribute on the casper admin site) since students could previously remove the RAM and restart the computer and delete the /var/db/.AppleSetupDone file and root the machine, with the Macbook Airs the RAM is soldered to the motherboard and since Apple changed how firmware passwords work I don't think you can hardware reset it anymore.

-Tom

[talkingmoose]

This was my thought as well. Who's responsible for the machines? Or
On 10/5/11 7:08 AM, "Nate St. Germain" <nate at techsuperpowers.com> wrote:
rather, who's assuming the legal risk and financial penalties of getting
caught with pirated software?

Assuming it's your school then be sure to point the policy decision-makers
to the BSA website:
http://www.bsa.org/country/Anti-Piracy/Know%20the%20Law.aspx. Yes, BSA
investigates schools too.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

[donmontalvo]

Yep. We find that providing the Firm with a TCO summary (users having admin rights) and properly outlining accountability/liability can help the coax the Firm and reverse the "our users must have admin rights" trend.
Smith, William wrote:

Once the business understands what can (and likely will) happen on the compliance/liability side, the key stake holders at the Firm tend to scramble to get their diaper on. ;)

Don

[sean]

You can find applications anywhere on the system, Desktop or other

locate *.app

I'd suggest the following as a starter:

1) To use kickback, then it needs to be installed. Have a policy to spot this. 2) I've never even seen a kickback install, can it be run standalone or does it need to install binaries on the system. If the former, then Monitor connection of Volumes and check these connected volumes for any occurrence of kickback. 3) I assume kickback runs a process, kill it with Casper.
4) Only allow apps to be run from certain locations with mcx and monitor these locations for changes. Of course, this doesn't prevent someone from running an app from anywhere using terminal and sudo, since they are admins.
5) Check logs for sudo use
6) Write a doc on why it is unnecessary, time (and hence money) wasting and potentially dangerous if users are admin and give it to someone who will care and can do something about it.
7) If there is no one of seniority that cares about 6, then don't bother wasting your time preventing all the issues that arise from allowing admin. Highlight the potential risks each time a new risk appears (like kickback), providing an idea of man hours required to prevent each item and leave it in the hands of those responsible. Either they care or they don't.

I'm sure I haven't even got close to allowing for all potential problems here, but I guess that is why 6 is so important. The ship may have sailed, but it always comes back to dock every so often!

Sean