[Clips] Sony's "DRM" Rootkit

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: clips at philodox.com
 Date: Mon, 31 Oct 2005 18:43:40 -0500
 To: Philodox Clips List <clips at philodox.com>
 From: "R.A. Hettinga" <rah at shipwright.com>
 Subject: [Clips] Sony's "DRM" Rootkit
 Reply-To: rah at philodox.com
 Sender: clips-bounces at philodox.com

 Click the link for pics.

 Cheers,
 RAH
 -------

 <http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html>


 Mark's Sysinternals Blog
 Monday, October 31, 2005

 Sony, Rootkits and Digital Rights Management Gone Too Far
 Last week when I was testing the latest version of RootkitRevealer (RKR) I
 ran a scan on one of my systems and was shocked to see evidence of a
 rootkit. Rootkits are cloaking technologies that hide files, Registry keys,
 and other system objects from diagnostic and security software, and they
 are usually employed by malware attempting to keep their implementation
 hidden (see my "Unearthing Rootkits" article from the June issue of Windows
 IT Pro Magazine for more information on rootkits). The RKR results window
 reported a hidden directory, several hidden device drivers, and a hidden
 application:


 Given the fact that I'm careful in my surfing habits and only install
 software from reputable sources I had no idea how I'd picked up a real
 rootkit, and if it were not for the suspicious names of the listed files I
 would have suspected RKR to have a bug. I immediately ran Process Explorer
 and Autoruns to look for evidence of code that would activate the rootkit
 each boot, but I came up empty with both tools. I next turned to LiveKd, a
 tool I wrote for Inside Windows 2000 and that lets you explorer the
 internals of a live system using the Microsoft kernel debugger, to
 determine what component was responsible for the cloaking.

 Rootkits that hide files, directories and Registry keys can either execute
 in user mode by patching Windows APIs in each process that applications use
 to access those objects, or in kernel mode by intercepting the associated
 kernel-mode APIs. A common way to intercept kernel-mode application APIs is
 to patch the kernel's system service table, a technique that I pioneered
 with Bryce for Windows back in 1996 when we wrote the first version of
 Regmon. Every kernel service that's exported for use by Windows
 applications has a pointer in a table that's indexed with the internal
 service number Windows assigns to the API. If a driver replaces an entry in
 the table with a pointer to its own function then the kernel invokes the
 driver function any time an application executes the API and the driver can
 control the behavior of the API.

 It's relatively easy to spot system call hooking simply by dumping the
 contents of the service table: all entries should point at addresses that
 lie within the Windows kernel; any that don't are patched functions.
 Dumping the table in Livekd revealed several patched functions:


 I listed one of the intercepting functions and saw that it was part of the
 Aries.sys device driver, which was one of the images I had seen cloaked in
 the $sys$filesystem directory:


 Armed with the knowledge of what driver implemented the cloaking I set off
 to see if I could disable the cloak and expose the hidden processes, files,
 directories, and Reegistry data. Although RKR indicated that the
 \Windows\System32\$sys$filesystem directory was hidden from the Windows
 API, it's common for rootkits to hide directories from a directory listing,
 but not to prevent a hidden directory from being opened directly. I
 therefore checked to see if I could examine the files within the hidden
 directory by opening a command prompt and changing into the hidden
 directory. Sure enough, I was able to enter and access most of the hidden
 files:


 Perhaps renaming the driver and rebooting would remove the cloak, but I
 also wanted to see if Aries.sys was doing more than cloaking so I copied it
 to an uncloaked directory and loaded it into IDA Pro, a powerful
 disassembler I use in my exploration of Windows internals. Here's a
 screenshot of IDA Pro's disassembly of the code that calculates the entries
 in the system service table that correspond to the functions it wants to
 manipulate:


 I studied the driver's initialization function, confirmed that it patches
 several functions via the system call table and saw that its cloaking code
 hides any file, directory, Registry key or process whose name begins with
 "$sys$". To verify that I made a copy of Notepad.exe named $sys$notepad.exe
 and it disappeared from view. Besides being indiscriminate about the
 objects it cloaks, other parts of the Aries code show a lack of
 sophistication on the part of the programmer. It's never safe to unload a
 driver that patches the system call table since some thread might be just
 about to execute the first instruction of a hooked function when the driver
 unloads; if that happens the thread will jump into invalid memory. There's
 no way for a driver to protect against this occurrence, but the Aries
 driver supports unloading and tries to keep track of whether any threads
 are executing its code. The programmer failed to consider the race
 condition I've described. They'll have to come up with a new approach to
 their rootkit sooner or later anyway, since system call hooking does not
 work at all on 64-bit versions of Windows.

 After I finished studying the driver's code I rebooted the system. The
 cloak was gone as I expected and I could see all the previously hidden
 files in Explorer and Registry keys in Regedit. I doubted that the files
 had any version information, but ran my Sigcheck utility on them anyway. To
 my surprise, the majority did have identifying product, file and company
 strings. I had already recognized Dbghelp.dll and Unicows.dll as Microsoft
 Windows DLLs by their names. The other files claimed to be part of the
 "Essential System Tools" product from a company called "First 4 Internet":


 I entered the company name into my Internet browser's address bar and went
 to http://www.first4internet.com/. I searched for both the product name and
 Aries.sys, but came up empty. However, the fact that the company sells a
 technology called XCP made me think that maybe the files I'd found were
 part of some content protection scheme. I Googled the company name and came
 across this article, confirming the fact that they have deals with several
 record companies, including Sony, to implement Digital Rights Management
 (DRM) software for CDs.

 The DRM reference made me recall having purchased a CD recently that can
 only be played using the media player that ships on the CD itself and that
 limits you to at most 3 copies. I scrounged through my CD's and found it,
 Sony BMG's Get Right with the Man (the name is ironic under the
 circumstances) CD by the Van Zant brothers. I hadn't noticed when I
 purchased the CD from Amazon.com that it's protected with DRM software, but
 if I had looked more closely at the text on the Amazon.com web page I would
 have known:


 The next phase of my investigation would be to verify that the rootkit and
 its hidden files were related to that CD's copy protection, so I inserted
 the CD into the drive and double-clicked on the icon to launch the player
 software, which has icons for making up to three copy-protected backup CDs:


 Process Explorer showed the player as being from Macromedia, but I noticed
 an increase in CPU usage by $sys$DRMServer.exe, one of the previously
 cloaked images, when I pressed the play button. A look at the Services tab
 of its process propertieds dialog showed it contains a service named "Plug
 and Play Device Manager", which is obviously an attempt to mislead the
 casual user that stumbles across it in the Services MMC snapin
 (services.msc) into thinking that it's a core part of Windows:


 I closed the player and expected $sys$DRMServer's CPU usage to drop to
 zero, but was dismayed to see that it was still consuming between one and
 two percent. It appears I was paying an unknown CPU penalty for just having
 the process active on my system. I launched Filemon and Regmon to see what
 it might be doing and the Filemon trace showed that it scans the
 executables corresponding to the running processes on the system every two
 seconds, querying basic information about the files, including their size,
 eight times each scan. I was quickly losing respect for the developers of
 the software:


 I still had to confirm the connection between the process and the CD's
 player so I took a closer look at each process. Based on the named pipe
 handles I saw they each had opened when I looked in Process Explorer's
 handle view I suspected that the player and $sys$DRMServer communicated via
 named pipes and so I launched Filemon, checked Named Pipes in the Volumes
 menu, and confirmed my theory:


 At that point I knew conclusively that the rootkit and its associated files
 were related to the First 4 Internet DRM software Sony ships on its CDs.
 Not happy having underhanded and sloppily written software on my system I
 looked for a way to uninstall it. However, I didn't find any reference to
 it in the Control Panel's Add or Remove Programs list, nor did I find any
 uninstall utility or directions on the CD or on First 4 Internet's site. I
 checked the EULA and saw no mention of the fact that I was agreeing to have
 software put on my system that I couldn't uninstall. Now I was mad.

 I deleted the driver files and their Registry keys, stopped the
 $sys$DRMServer service and deleted its image, and rebooted. As I was
 deleting the driver Registry keys under
 HKLM\System\CurrentControlSet\Services I noted that they were either
 configured as boot-start drivers or members of groups listed by name in the
 HKLM\System\CurrentControlSet\SafeBoot subkeys, which means that they load
 even in Safe Mode, making system recovery extremely difficult if any of
 them have a bug that prevents the system from booting.

 When I logged I discovered that the CD's icon was missing from Explorer.
 Deleting the drivers had disabled the CDs. Now I was really mad. Windows
 supports device "filtering", which allows a driver to insert itself below
 or above another one so that it can see and modify the I/O requests
 targeted at the one it wants to filter. I know from my past work with
 device driver filter drivers that if you delete a filter driver's image,
 Windows fails to start the target driver. I opened Device Manager,
 displayed the properties for my CD-ROM device, and saw one of the cloaked
 drivers, Crater.sys (another ironic name, since it had 'cratered' my CD),
 registered as a lower filter:


 Unfortunately, although you can view the names of registered filter drivers
 in the "Upper filters" and "Lower filters" entries of a device's Details
 tab in Device Manager, there's no administrative interface for deleting
 filters. Filter registrations are stored in the Registry under
 HKLM\System\CurrentControlSet\Enum so I opened Regedit and searched for
 $sys$ in that key. I found the entry configuring the CD's lower filter:


 I deleted the entry, but got an access-denied error. Those keys have
 security permissions that only allow the Local System account to modify
 them, so I relaunched Regedit in the Local System account using PsExec:
 psexec -s -i -d regedit.exe. I retried the delete, succeeded, and searched
 for $sys$ again. Next I found an entry configuring another one of the
 drivers, Cor.sys (internally named Corvus), as an upper filter for the IDE
 channel device and also deleted it. I rebooted and my CD was back.

 The entire experience was frustrating and irritating. Not only had Sony put
 software on my system that uses techniques commonly used by malware to mask
 its presence, the software is poorly written and provides no means for
 uninstall. Worse, most users that stumble across the cloaked files with a
 RKR scan will cripple their computer if they attempt the obvious step of
 deleting the cloaked files.

 While I believe in the media industry's right to use copy protection
 mechanisms to prevent illegal copying, I don't think that we've found the
 right balance of fair use and copy protection, yet. This is a clear case of
 Sony taking DRM too far.

  posted by Mark Russinovich @ 11:04 AM

 --
 -----------------
 R. A. Hettinga <mailto: rah at ibuc.com>
 The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
 44 Farquhar Street, Boston, MA 02131 USA
 "... however it may deserve respect for its usefulness and antiquity,
 [predicting the end of the world] has not been found agreeable to
 experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
 _______________________________________________
 Clips mailing list
 Clips at philodox.com
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com