Posts Tagged ‘authentication

Blind XPath Injuction

Blind XPath Injection attack that enables an attacker to extract a complete XML document used for XPath querying, without prior knowledge of the XPath query. The attack is considered “complete” since all possible data is exposed. The attack makes use of two techniques –XPath crawling and Booleanization of XPath queries. Using this attack, it is possible to get hold of theXML “database” used in the Xpath query. This can be most powerful against sites that use XPath queries (and XML “databases”) for authentication, searching and other uses.

Compared to the SQL injection attacks, XPath Injection has the following upsides:

1. Since XPath is a standard (yet rich) language, it is possible to carry the attack ‘as-is’ for any XPath implementation. This is in contrast to SQL injection where different implementations have different SQL dialects (there is a common SQL language, but it is often too weak).

2. The XPath language can reference almost all parts of the XML document without access control restrictions, whereas with SQL, a “user” (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. So the outcome of the Blind XPath Injection attack is guaranteed to consist of the complete XML document, i.e. the complete database.

It is possible to take a more systematic approach to the XPath Injection problem. This approach is called “blind injection” (the foundations of which are laid in, in the SQL injection context). It assumes more or less nothing on the structure of the query except that the user data is injected in a Boolean expression context. It enables the attacker to extract a single bit of  information per a single query injection. This bit is realized, for example, as “Login successful” or “Login failed”.

This approach is even more powerful with XPath than it is with SQL, due to the following characteristics of XPath:

The technique we use is as follows:

We first show how to crawl an XPath document, using only scalar queries (that is, queries whose return type is “string”, “numeric” or “Boolean”). The crawling procedure assumes no knowledge of the document structure; yet at its end, the document, in its completeness, is reconstructed.

We then show how a scalar XPath query can be replaced by a series of  Boolean queries. This procedure is called a “Booleanization” of the query. A Boolean query is a query whose result is a Boolean value (true/false). So in a Booleanization process, a query whose result type is string or numeric is replaced with a series of queries whose result type is Boolean, and from which we can reconstruct the result ofthe original string or numeric query.

Finally, each Boolean query can be resolved by a single “blind” injection. That is, we show how it is possible to form an injection string, including the Boolean query, that when injected into an XPath query, causes the application to behave in one way if the Boolean query resolves into “true”, and in another way if the query resolves into “false”. This way, the attacker can determine a single bit – the Boolean query result.

The novelty in this approach towards XPath Injection is that it does not require much prior knowledge of the XPath query format, unlike the “traditional” approach described above. It does not require that data from the XML document be embedded in the response and that the whole XML document is eventually extracted, regardless of the format of the XPath query used by the application. It uses only a difference in the application behavior resulting from a difference in the XPath query return value to extract a single information bit.


Tags : , , , , , , , , , , , , , , , , , ,

Enterprise Password Management

This  provides recommendations for password management, which is the process of defining, implementing, and maintaining password policies throughout an enterprise. Effective password management reduces the risk of compromise of password-based authentication systems. Organizations need to protect the confidentiality, integrity, and availability of passwords so that all authorized users—and no unauthorized users—can use passwords successfully as needed. Integrity and availability should be ensured by typical data security controls, such as using access control lists to prevent attackers from overwriting passwords and having secured backups of password files. Ensuring the confidentiality of passwords is considerably more challenging and involves a number of security controls along with decisions involving the characteristics of the passwords themselves. For example, requiring that passwords be long and complex makes it less likely that attackers will guess or crack them, but it also makes the passwords harder for users to remember, and thus more likely to be stored insecurely. This increases the likelihood that users will store their passwords insecurely and expose them to attackers.

Organizations should be aware of the drawbacks of using password-based authentication. There are many types of threats against passwords, and most of these threats can only be partially mitigated. Also, users are burdened with memorizing and managing an ever-increasing number of passwords. However, although the existing mechanisms for enterprise password management can somewhat alleviate this burden, they each have significant usability disadvantages and can also cause more serious security incidents because they permit access to many systems through a single authenticator. Therefore, organizations should make long-term plans for replacing or supplementing password-based authentication with stronger forms of authentication for resources with higher security needs.

Organizations should implement the following recommendations to protect the confidentiality of their passwords.

Create a password policy that specifies all of the organization’s password management-related requirements.

Password management-related requirements include password storage and transmission, password composition, and password issuance and reset procedures. In addition to the recommendations provided in this publication, organizations should also take into account applicable mandates (e.g., FISMA), regulations, and other requirements and guidelines related to passwords. An organization’s password policy should be flexible enough to accommodate the differing password capabilities provided by various operating systems and applications. For example, the encryption algorithms and password character sets they support may differ. Organizations should review their password policies periodically, particularly as major technology changes occur (e.g., new operating system) that may affect password management.

Protect passwords from attacks that capture passwords.

Attackers may capture passwords in several ways, each necessitating different security controls. For example, attackers might attempt to access OS and application passwords stored on hosts, so such passwords should be stored using additional security controls, such as restricting access to files that contain passwords and storing one-way cryptographic hashes of passwords instead of the passwords themselves. Passwords transmitted over networks should be protected from sniffing threats by encrypting the passwords or the communications containing them, or by other suitable means. Users should be made aware of threats against their knowledge and behavior, such as phishing attacks, keystroke loggers, and shoulder surfing, and how they should respond when they suspect an attack may be occurring. Organizations also need to ensure that they verify the identity of users who are attempting to recover a forgotten password or reset a password, so that a password is not inadvertently provided to an attacker.

Configure password mechanisms to reduce the likelihood of successful password guessing and cracking.

Password guessing attacks can be mitigated rather easily by ensuring that passwords are sufficiently complex and by limiting the frequency of authentication attempts, such as having a brief delay after each failed authentication attempt or locking out an account after many consecutive failed attempts. Password cracking attacks can be mitigated by using strong passwords, choosing strong cryptographic algorithms and implementations for password hashing, and protecting the confidentiality of password hashes. Changing passwords periodically also slightly reduces the risk posed by cracking. Password strength is based on several factors, including password complexity, password length, and user knowledge of strong password characteristics. Organizations should consider which factors are enforceable when establishing policy requirements for password strength, and also whether or not users will need to memorize the passwords.

Determine requirements for password expiration based on balancing security needs and usability.

Many organizations implement password expiration mechanisms to reduce the potential impact of unauthorized use of a password. This is beneficial in some cases but ineffective in others, such as when the attacker can compromise the new password through the same keylogger that was used to capture the old password. Password expiration is also a source of frustration to users, who are often required to create and remember new passwords every few months for dozens of accounts, and thus tend to choose weak passwords and use the same few passwords for many accounts. Organizations should consider several factors when determining password expiration requirements, including the availability of secure storage for user passwords, the level of threats against the passwords, the frequency of authentication (daily versus annually), the strength of password storage, and the effectiveness or ineffectiveness of password expiration against cracking. Organizations should consider having different policies for password expiration for different types of systems, operating systems, and applications, to reflect their varying security needs and usability requirements.

Tags : , , , , , , , , , , , , ,

DB2 security mechanisms

A database security plan should define:

There are three main mechanisms within DB2 that allow a DBA to implement a database security plan : authentication, authorization, and privileges.

Authentication is the first security feature you will encounter when you attempt to access a DB2 instance or database. DB2 authentication works closely with the security features of the underlying operating system to verify user IDs and passwords. DB2 can also work with security protocols like Kerberos to authenticate users.

Authorization involves determining the operations that users and/or groups can perform, and the data objects that they may access. A user’s ability to perform high-level database and instance management operations is determined by the authorities that they have been assigned. The five different authority levels within DB2 are SYSADM, SYSCTRL, SYSMAINT, DBADM, and LOAD.

Privileges are a bit more granular than authorities, and can be assigned to users and/or groups. Privileges help define the objects that a user can create or drop. They also define the commands that a user can use to access objects like tables, views, indexes, and packages.

You will need to create a database within the db2inst1 instance. Make sure that the db2instance variable is still set to db2inst1, and then create the sample database using the command db2sampldrive, using the name of the drive where you want to create the sample. For the examples, we’ll create the sample database on our C drive, as follows:

C:\PROGRA~1\SQLLIB\BIN>db2sampl c:

Tags : , , , , , , , , , , , ,

Flaws in Authentication Protocols

Several database systems have plain text authentication protocols, by which we mean authentication protocols in which the password is passed “on the wire” in a plain text or easily decrypted format. In a default configuration (that Sybase warns against, but which we have still seen in use) Sybase passes passwords in plaintext. By default, Microsoft SQL Server obfuscates passwords by swapping the nibbles (4-bit halves of a byte) and XORing with 0xA5. In both ofthese cases, the vendors warn against using the plain text versions of their authentication protocols and provide strong, encrypted mechanisms that are relatively easy to deploy — but the defaults are still there, and still dangerous.

MySQL has historically had a number of serious problems with its authentication protocol. Although the protocol isn’t plaintext, the mathematical basis of the authentication algorithm prior to version 4.1 was called into question by Ariel Waissbein, Emiliano Kargieman, Carlos Sarraute, Gerardo Richarte, and Agustin Azubel of CORE SDI (CVE-2000-0981). This describes an attack in which an attacker that can observe multiple authentications is quickly ableto determine the password hash.

A further conceptual problem with the authentication protocol in MySQL prior to version 4.1 is that the protocol only tests knowledge of the password hash, not the password itself. This leads to serious problems if a user is able to somehow determine another user’s password hash — and MySQL has been subject to a number of issues in which that was possible. Robert van der Meulen found an issue (CVE-2000-0148) in MySQL versions prior to 3.23.11 whereby an attacker could authenticate using only a single byte of the expected response to the server’s challenge, leading to a situation whereby if you knew a user’s username, you could authenticate as that user in around 32 attempts.

Chris Anley recently found a very similar problem in MySQL (CAN-2004-0627) whereby a user could authenticate using an empty response to the server’s challenge, provided he or she passed certain flags to the remote server.This category of bugs is almost as dangerous as the “unauthenticated flaws in network protocols” category, because in many cases the traffic simply looks like a normal authentication. Attackers don’t need to exploit an overflow or do anything clever, they simply authenticate without necessarily needing the password—or if they’ve been able to sniff the password, they just authenticate.The best defense against this kind of bug is to ensure that your database patches are up-to-date, and that you don’t have any plaintext authentication mechanisms exposed on your databases. If your DBMS cannot support encrypted authentication in your environment, you could use IPSec or SSH to provide an encrypted tunnel. MySQL provides explicit guidelines on how to do this in its documentation, though recent versions of MySQL allow authentication to take place over an SSL-encrypted channel.


Tags : , , , , , , ,