Implementing Database Security and Auditing phần 6 docx

203 7 Using the Database To Do Too Much For many years Sun’s tagline was “the network is the computer.” Looking at some of the latest database products, you can’t help but wonder if the ven- dors think that “the database is the computer.” Well, it’s not, and it should not be used as such. The database is not an operating system. It is not a Web server. It is not an application server. It is not a Web services provider. It is a database, and managing data is hard enough. In this chapter you’ll see many of the advanced features that databases have today—features that allow you to call functions deployed on the operating system through the databases, to call stored procedures using a Web interface, and more. These functions will become increasingly main- stream—even though from a security perspective they introduce addi- tional problems and complexities. The goal of this chapter is to make you aware of potential risks, convince you to stay away from some of the more dangerous ones, and give you enough information so that if you decide to enable these features anyway, you will pay more attention to the security aspects of these features. 7.1 Don’t use external procedures All databases have a query language and a procedural language (well, almost all of them—MySQL before version 5 actually doesn’t have the lat- ter). Each of the procedural languages of the main database servers is highly functional and robust. In addition, all of the databases have a large set of built-in procedures that you can use when writing programs. How- ever, the database vendors often go an extra step and provide you with mechanisms for invoking functions that reside outside the database runt- ime. This can cause many problems that are related to elevated privileges, as you’ll see in the next few sections. 204 7.1 Don’t use external procedures 7.1.1 Disable Windows extended stored procedures Extended stored procedures are DLLs that can be installed by a SQL Server administrator to provide enhanced functionality within SQL Server. SQL Server extended stored procedures are dangerous for several reasons. The main risk has to do with their power and their ability to access and invoke actions at the operating system level. Using these procedures blurs the boundary between the database and the operating system and can give too many privileges to a user signed on to the database. After seeing so many security issues in previous chapters, and especially application vulnerabilities as described in Chapter 5, a clear separation between the host and the data- base should be on your mind. Another risk has to do with vulnerabilities that have been found in these procedures. In this section I will try to con- vince you that they are just not worth it and that you should remove them. Some extended procedures allow a SQL Server user to have broad access to the operating system. As an example, the extended procedures xp_regread and xp_instance_regread allow the PUBLIC role to read from the system registry. This means that I can get useful information which tells me where the SQL Server 2000 instance is installed by issuing statements of the form: exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\Setup', 'SQLPath' exec xp_instance_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\Setup', 'SQLPath' To get the default login (and see if guest has been removed or not): exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\ MSSQLServer\MSSQLServer', 'DefaultLogin' exec xp_instance_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\ Microsoft\MSSQLServer\MSSQLServer', 'DefaultLogin' Here is one final example showing how vulnerable extended procedures can make you. There really is a lot in the registry—data that you may not even be aware of. This information is useful to an attacker. For example, if you are using IPSec to encrypt data in transit (see Chapter 10), then an 7.1 Don’t use external procedures 205 Chapter 7 attacker can see what your active policy is and what it entails by issuing the following sequence of commands: exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local', 'ActivePolicy' This returns a policy name, for example: SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000} The attacker can then execute: exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'description' exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'ipsecData' exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'ipsecISAKMPReference' These are two powerful extended procedures an attacker can use to get a full snapshot of your Windows host and everything that is installed there. You should either completely remove these procedures or limit their access to privileged accounts. Providing PUBLIC role access to them is completely unacceptable. If you really don’t want to sleep at night, remember that there is also an equivalent xp_regwrite extended stored procedure. Many extended stored procedures provide access to operating system facilities from within SQL Server in addition to xp_regread . Some of them are extremely dangerous because they fully expose the operating system to the SQL Server instance. All of these are in most cases an unnecessary vul- nerability, and you should remove them or limit access to them. Table 7.1 details these problematic SQL Server 2000 extended procedures. Three more undocumented extended procedures that can be readily used by an attacker to run arbitrary dynamic SQL without having proper privileges are: 206 7.1 Don’t use external procedures Table 7.1 Extended stored procedures that provide access to operating system features Extended Procedure Description xp_availablemedia Returns data about the drives on the machine. A sample output looks like: C:\ 1339351040 1 2 E:\ 306806784 0 2 F:\ 319094784 0 2 G:\ 1287389184 0 2 H:\ 329121792 0 2 I:\ 781451264 0 2 J:\ 120569856 02 xp_cmdshell Executes a given command string as an operating- system command shell and returns any output as rows of text. When you grant execute permissions to users, the users can execute any operating-system command at the Windows command shell that the account running SQL Server has the needed privi- leges to execute. This is arguably the most dangerous procedure. xp_dirtree Lists the directories and subdirectories under a spe- cific directory passed in as a parameter, for example: exec xp_dirtree 'c:\Windows' xp_enumdsn Gets a list of the configured Data Source Names (DSN) on the system. xp_enumerrorlogs Lists the SQL Server error log files and their creation time. xp_enumgroups Returns the groups at the W indows level. As an example, my list includes ORA_DBA group, because I also have Oracle installed on my machine. xp_enum_oledb_providers Lists all available OLE DB providers. xp_fileexists Allows you to test the existence of a file at the Win- dows level. xp_fixeddrives Similar to xp_availablemedia but for fixed drives only. xp_getfiledetails Gets file system details about files or directories. xp_getnetname Gets the server’s network name. 7.1 Don’t use external procedures 207 Chapter 7  xp_execresultset  xp_printstatements  xp_displayparamstmt xp_logevent Logs a user-defined message in the SQL Server log file and in the Windows Event Viewer. xp_loginconfig Reports the login security configuration of SQL Server as running on Windows. xp_logininfo Reports the account, the type of account, the privi- lege level of the account, the mapped login name of the account, and the permission path by which an account has access to SQL Server. xp_msver Returns SQL Server version information. In addi- tion to version information regarding the actual build number of the server, various environment information is also returned—a little too much for comfort from a security perspective. xp_ntsecenudomains Returns the Windows domains to which the host belongs. xp_regaddmultistring Adds a new value to a multivalue string in the regis- try. xp_regenumvalues Returns multiple result sets that list registry values and data. xp_regdeletekey Deletes a specified registry subkey. xp_regdeletevalue Deletes a specified registry value. xp_regremovemultistring Removes a multistring value from a registry entry. xp_regwrite Writes registry values directly from within SQL Server. This is a very dangerous procedure. xp_servicecontrol Allows you to stop, start, pause, and continue Win- dows services. xp_subdirs Similar to xp_dirtree but returns only those directo- ries that have a depth of 1. xp_unc_to_drive Lists details on physical machines, naming, etc. Table 7.1 Extended stored procedures that provide access to operating system features (continued) Extended Procedure Description 208 7.1 Don’t use external procedures Using these to run SQL is normally limited to privileged users. Unfortu- nately, these three extended stored procedures contain vulnerabilities that allow this even for a low-privileged user. You can get a patch from Microsoft for these vulnerabilities at www.microsoft.com/technet/security/bulletin/ MS02-043.mspx. Interestingly enough, I did a search on Google for these strings, and apart from the many vulnerability notices, I didn’t find a single link for someone describing actual usage—so hopefully there aren’t too many of you out there using these undocumented features. Another patch you should apply for extended stored procedure involves a buffer overflow vulnerability. From the amount of bad press they have received, you would think that extended stored procedures have more buffer overflow vulnerabilities than other built-in procedures and functions. This is a result of a few vulnerabilities that are “reused” by many of these procedures. srv_paraminfo() is a common function used to parse input parameters for extended procedures. The signature for this method is: int srv_paraminfo ( SRV_PROC * srvproc, int n, BYTE * pbType, ULONG * pcbMaxLen, ULONG * pcbActualLen, BYTE * pbData, BOOL * pfNull ); This function has a flaw that could result in a buffer overflow condition. The function is designed to locate the nth parameter in a string and put it into a buffer provided by the extended procedure. By design, the function does not provide a way for an extended procedure to indicate the length of the buffer; instead, the extended procedure is expected to ensure that the buffer will be large enough to hold the parameter. However, not all extended procedures provided by default in SQL Server perform this checking. A mali- cious user who provides a sufficiently long parameter to an affected extended procedure could cause a buffer overflow within the function in order to either cause the SQL Server to fail or to execute arbitrary code. The following extended procedures are all affected by the srv_paraminfo vulnerability:  xp_controlqueueservice 7.1 Don’t use external procedures 209 Chapter 7  xp_createprivatequeue  xp_createqueue  xp_decodequeuecmd  xp_deleteprivatequeue  xp_deletequeue  xp_displayqueuemesgs  xp_dsninfo  xp_mergelineages  xp_oledbinfo  xp_proxiedmetadata  xp_readpkfromqueue  xp_readpkfromvarbin  xp_repl_encrypt  xp_resetqueue  xp_sqlinventory  xp_unpackcab The patch for this shared vulnerability is available at www.microsoft.com/technet/security/bulletin/MS00-092.mspx. The patch works by changing all default extended procedures to allocate a correctly sized buffer before calling srv_paraminfo. In order to lessen your liability, you should make sure your system is patched with fixes to these vulnerabilities, and you should make sure you either remove these from your system altogether or at least provide access to them only to privileged accounts. You should also track their usage by mon- itoring all calls to these procedures. If you are unsure whether these proce- dures are being used (and thus are worried that removing or changing their privileges may affect an application), you should trace their usage for a period of one to four weeks and then take action. If you find that an appli- cation is using these procedures, you should bring the topic to the attention of the application owner and try to work a schedule for rewriting the code using these procedures so that you may disable them. If they are not used simply remove them. To remove an extended proce- dure (e.g., xp_regread), use the following command: exec sp_dropextendedproc 'xp_regread' 210 7.1 Don’t use external procedures To revoke PUBLIC role permissions, use the following command: revoke execute on xp_regread to PUBLIC To monitor all executions of these extended procedures, you can either create a trace within SQL Server or use an external monitoring tool. 7.1.2 Disable external procedures in Oracle Oracle’s PL/SQL provides an interface for calling external functions that can be written in any library and compiled into a shared library (or dynam- ically linked library). This is done through a mechanism called external pro- cedures or EXTPROC. If you have a Java method called void foo(int) in a class called Bar, you can define a PL/SQL wrapper using: CREATE PROCEDURE pl_foo (i NUMBER) AS LANGUAGE JAVA NAME 'Bar.foo(int)'; And then call it using a PL/SQL block as follows: DECLARE j NUMBER; BEGIN pl_foo(j); END; Similarly, if you want to create a wrapper for a C function, use the fol- lowing syntax: CREATE OR REPLACE LIBRARY fooLib as '/opt/lib/foo.so'; CREATE OR REPLACE PACKAGE BODY fooPackage IS PROCEDURE pl_foo(I IN NUMBER) IS EXTERNAL NAME "foo" LIBRARY fooLib LANGUAGE C; END; 7.1 Don’t use external procedures 211 Chapter 7 In the example shown, the functions are in an external library that needs to be available to the server. In order for such an external function to be available, you have to register the shared library with PL/SQL. You tell PL/ SQL about the library using the LIBRARY clause in the EXTERNAL defi- nition. The actual loading of the library happens through a session-specific agent called EXTPROC that is invoked through the listener. As shown in Figure 7.1, when the wrapper is called, PL/SQL calls the listener process, which spawns EXTPROC. The shared library is loaded in an external address space and the call to the function is performed. The reply then comes back through EXTPROC, which keeps running to serve up addi- tional calls so that loading overhead occurs only once. Because the invocation process is initiated through the listener, the lis- tener configuration would typically have the following entry in listener.ora: SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = C:\oracle\product10g\10.1.0\Db_1) (PROGRAM = extproc) ) ) and the following in tnsnames.ora: EXTPROC_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(KEY = EXTPROC)) ) Figure 7.1 EXTPROC invocation process. [...]... architecture, one database will often use other databases to create better working environments for developers and better data repositories for business users This chapter focuses on such database- to -database relationships and how they affect the need to secure and monitor databases As you’ll see throughout this chapter, database- to -database communications add challenges to good security Although you... you should understand the calling and security models and enable them one procedure at a time using a review/test/inspection process to ensure that you are not putting the database at risk If you are going to start exposing internal database procedures and constructs as Web services (and wish to do so securely), you have no choice but to start understanding a large set of buzzwords and acronyms Some... query that uses both tables in database A and tables that physically reside in database B The client is oblivious to the actual location of the tables When the query is handled by database A, the database engine makes a request on database B From the perspective of database B, this is a request like any other—it comes from the network, needs to be authenticated and authorized, and the response sent back... IBM and Microsoft are cooperating on a technological basis gives anything produced within this process a tremendous amount of clout, and the result is widespread industry acceptance Chapter 7 8 Securing database- to -database communications Databases are often not islands that are completely disconnected from other databases In fact, in a world where most databases are deployed on UNIX, Windows, and. .. WS-Secure Conversation describes how to manage and authenticate message exchanges between parties, including security context exchange and establishing and deriving session keys 7.5 Summary In this chapter you saw mechanisms for calling nondatabase procedures through the database and mechanisms for calling database procedures through servers that are not the database You saw that you can often call functions... database servers and then look at a report where the client IP and the server IP are both in this group This will give you a monitor of database- to -database communications only Remember that using the IP group will show you access from your database servers but not from a database server of which you may not be aware Therefore, the two reports are complementary and you should use Figure 8.2 Using database. .. IBM, Sun, and Oracle together with Microsoft pushing the same set of technologies and promoting them as standards? Well, it’s true: all of these companies are cooperating and are driving the standards being formed for Web services In fact, the two most dominant companies in this campaign are IBM and Microsoft, and many of the definitions and specifications result from joint work between IBM and Microsoft... within the database and that you can call functions compiled and loaded from shared libraries You also saw that you can easily call stored procedures through Web servers, application servers, or HTTP servers directly embedded within the database Chapter 7 228 7.A Cross-site scripting and cookie poisoning All of these features enhance the database functionality and can decrease development and deployment... be fully aware and prepared for the added complexity and, unfortunately, possible security issues In terms of complexity, any scheme that involves multiple address spaces with multiple calling schemes, different variable layout, and multiple programming languages is complex and hard to troubleshoot In terms of security issues, the main one is documented in Oracle Security Alert #29 and involves a serious... again Unfortunately, database vendors try to make the database an architecture for any development and deployment pattern and in doing so include servers that are really not the focus of database operations and that introduce unnecessary vulnerabilities The prime example for this is the embedding of the Oracle HTTP Server with the Oracle 9i database The Oracle HTTP Server is a branded Apache Web server . 3 068 067 84 0 2 F: 319094784 0 2 G: 1287389184 0 2 H: 329121792 0 2 I: 781451 264 0 2 J: 120 569 8 56 02 xp_cmdshell Executes a given command string as an operating- system command shell and. database and have security built into both the application layer and the database. The first set of issues involves known (and unknown) Apache server vul- nerabilities. As an example, Oracle Security. impor- tant guideline and is worth stressing here again. Unfortunately, database vendors try to make the database an architecture for any development and deployment pattern and in doing so include