Tuesday, August 02, 2005

Goggle - A Hacker's favorite tool in the toolbox....

http://news.yahoo.com/news?tmpl=story&u=/pcworld/20050802/tc_pcworld/122066

If you haven't had a chance to read Johnny Long's book, do so. It's
eyeopening. I've always found google to be a valuable research tool,
but little did I know the extent of what I could research.

Also, check out his site: http://johnny.ihackstuff.com/index.php

Google - A Hacker's favorite tool in the toolbox....

http://news.yahoo.com/news?tmpl=story&u=/pcworld/20050802/tc_pcworld/122066


If you haven't had a chance to read Johnny Long's book, do so. It's
eyeopening. I've always found google to be a valuable research tool,
but little did I know the extent of what I could research.


Also, check out his site: http://johnny.ihackstuff.com/index.php

Wednesday, July 27, 2005

Overheard on an OWASP discussion listserv....

A truer statement has never been echoed.....

"Although I believe that some care must be placed in the disclosure of zero-day style vulnerabilities that can be maliciously exploited by worms and virus, I don't believe that we should subscribe to the COTS 'responsible vulnerability disclosure' ideas since they are designed to minimize the impact of the vulnerabilities in their stock price, instead of increasing the security of their products and clients."

-- Dinis Cruz

Overheard on an OWASP discussion listserv....

A truer statement has never been echoed.....

"Although I believe that some care must be placed in the disclosure of zero-day style vulnerabilities that can be maliciously exploited by worms and virus, I don't believe that we should subscribe to the COTS 'responsible vulnerability disclosure' ideas since they are designed to minimize the impact of the vulnerabilities in their stock price, instead of increasing the security of their products and clients."

-- Dinis Cruz

Tuesday, July 26, 2005

Taking Oracle to the Woodshed...

From Security Focus News, http://www.securityfocus.com/news/11252:

"Claiming that Oracle has failed to fix six vulnerabilities despite having more than 650 days to issue a patch, researchers at security firm Red Database Security published details of the flaws on Tuesday.

The flaws vary in severity with three of the six classified by the firm as high risk, potentially allowing a remote attacker to compromise a server or overwrite files, according to advisories released by Red Database."

Oracle's response -
 'We believe the most effective way to protect customers is to avoid disclosing or publicizing vulnerabilities before a patch or workaround has been developed,'


Seriously, does Oracle think its in the best interest of their customers to keep them in the dark?!  Especially when it takes nearly 2 years before a fix is available.   

So how's your computer's diet?

At a presentation during OWASP's 2005 Application Security conference in Europe, Jeff Williams, the OWASP chair, proposed an idea that software should come with Software Facts. This information would be conveyed in a manner similar to the same Nutrional Facts chart on US Food.

Just as the Nutrional Facts chart raises consumer awareness of the health value of the foods that they are consuming, the Software Facts chart would inform the consumer how healthy the software that your computer is about to consume is.

This is an idea that intrigues me as I can only see it as a benefit to the consumer. Companies may have to doa little extra work to compile the required statistics, but if you ask me, it's stuff they should be testing for anyway.

Now there is the argument that the average consumer is not going to know what Cross Site Scripting or SQL Injection percentages actually mean. But the first step is to get the information out there and the next step is to educate.

Image from OWASP.org

Ten Signs Your Application Is Susceptible to SQL Injection Attacks

10. The database used by your application has admin accounts with default passwords (or even worse, no passwords at all)

It may sound obvious, but it wasn’t until after the SQL Slammer virus navigated the Internet in 2003 that Microsoft began requiring a password for the SA account.

9. Your application uses an account with administrative privileges to connect to the database.

Another obvious one, but how many code examples on the web have you seen that uses SA when talking to a MS SQL database.

8. Your application ignores the least privilege principal when connecting to the database.

If you have an application that only needs to query a database, then use an account with only read-only permissions. Also ensure that the only accessible tables to that user are those that are required by the application.

7. Your error messages display too much information to the user (i.e. stack traces, connection strings).

An example from thedailywtf.com, a site that posts actual application code and asks the question WTF?!:

 [ArgumentException: 
   Item has already been added.  
   Key in dictionary: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"
   Key being added: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"]
 System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) +931
 System.Collections.Hashtable.Add(Object key, Object value) +11
 Initech.BcpCms.Data.ConnectionManager.EnsureConnection(ConnectionProvider provider, String connectionString) +667
 

6. Your application does not limit the number of characters in input fields to a proper amount.

If your password policy asks for password 3-12 characters in length, then don’t allow the user to enter 255 characters or more. Otherwise, it is too easy to inject extra SQL code into the request.

5. Your application builds SQL statements on the fly (dynamic SQL)

Use parameterized queries or stored procedures to access a database as opposed to building sql statements on the fly. Yes, this makes it harder to change or modify the query, but that’s the point.

4. Your application fails to validate the output

If you only expect one row to be returned from the database, doublecheck the return results to make sure that one and only one row is returned.

3. Your application does handle improper characters like ‘ or ;

Several years ago, a single message on an Internet forum invoked the devious nature of its members. The message simply pondered what would happen if they changed the URL displayed in a web browser from - http://mybank.com/default.asp?id=3 to http://mybank.com/default.asp?id=3;SHUTDOWN.

The URL managed to submit a request for the database server to shutdown and the new banking site was instantly unavailable.

2. Your application does all of its validation on the client

As a general rule, validation on a client is for user friendliness. The server should always do the primary validation. (And make sure to do the validation before your application consumes it.)

It is too easy to intercept requests from a client, modify them, and forward them on to the server. This is especially easy for web applications through the use of a proxy. Programs like Web Scarab are very good at this.

And the number one sign that application is susceptible to SQL Injection attacks…

1. Your application communicates with ANY sql database

No SQL database can avoid be exposed to these attacks. Whether it be Oracle, MySQL or MS SQL, a valid SQL statement can be manipulated to return unexpected results.

However, being aware of this fact and taking steps avoid SQL Injection attacks is the first step in building up your application’s immunity.

Taking Oracle to the Woodshed...

From Security Focus News, http://www.securityfocus.com/news/11252:

"Claiming that Oracle has failed to fix six vulnerabilities despite having more than 650 days to issue a patch, researchers at security firm Red Database Security published details of the flaws on Tuesday.

The flaws vary in severity with three of the six classified by the firm as high risk, potentially allowing a remote attacker to compromise a server or overwrite files, according to advisories released by Red Database."

Oracle's response -
 'We believe the most effective way to protect customers is to avoid disclosing or publicizing vulnerabilities before a patch or workaround has been developed,'


Seriously, does Oracle think its in the best interest of their customers to keep them in the dark?!  Especially when it takes nearly 2 years before a fix is available.   

So how's your computer's diet?

At a presentation during OWASP's 2005 Application Security conference in Europe, Jeff Williams, the OWASP chair, proposed an idea that software should come with Software Facts. This information would be conveyed in a manner similar to the same Nutrional Facts chart on US Food.

Just as the Nutrional Facts chart raises consumer awareness of the health value of the foods that they are consuming, the Software Facts chart would inform the consumer how healthy the software that your computer is about to consume is.

This is an idea that intrigues me as I can only see it as a benefit to the consumer. Companies may have to doa little extra work to compile the required statistics, but if you ask me, it's stuff they should be testing for anyway.

Now there is the argument that the average consumer is not going to know what Cross Site Scripting or SQL Injection percentages actually mean. But the first step is to get the information out there and the next step is to educate.

Image from OWASP.org

Ten Signs Your Application Is Susceptible to SQL Injection Attacks

10. The database used by your application has admin accounts with default passwords (or even worse, no passwords at all)

It may sound obvious, but it wasn’t until after the SQL Slammer virus navigated the Internet in 2003 that Microsoft began requiring a password for the SA account.

9. Your application uses an account with administrative privileges to connect to the database.

Another obvious one, but how many code examples on the web have you seen that uses SA when talking to a MS SQL database.

8. Your application ignores the least privilege principal when connecting to the database.

If you have an application that only needs to query a database, then use an account with only read-only permissions. Also ensure that the only accessible tables to that user are those that are required by the application.

7. Your error messages display too much information to the user (i.e. stack traces, connection strings).

An example from thedailywtf.com, a site that posts actual application code and asks the question WTF?!:

 [ArgumentException: 
   Item has already been added.  
   Key in dictionary: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"
   Key being added: "data source=DTESQL04.INITECH-GLOBAL.COM;initial catalog=BCPCMS;user id=cmsadmin;password=flTSP4#1;"]
 System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) +931
 System.Collections.Hashtable.Add(Object key, Object value) +11
 Initech.BcpCms.Data.ConnectionManager.EnsureConnection(ConnectionProvider provider, String connectionString) +667
 

6. Your application does not limit the number of characters in input fields to a proper amount.

If your password policy asks for password 3-12 characters in length, then don’t allow the user to enter 255 characters or more. Otherwise, it is too easy to inject extra SQL code into the request.

5. Your application builds SQL statements on the fly (dynamic SQL)

Use parameterized queries or stored procedures to access a database as opposed to building sql statements on the fly. Yes, this makes it harder to change or modify the query, but that’s the point.

4. Your application fails to validate the output

If you only expect one row to be returned from the database, doublecheck the return results to make sure that one and only one row is returned.

3. Your application does handle improper characters like ‘ or ;

Several years ago, a single message on an Internet forum invoked the devious nature of its members. The message simply pondered what would happen if they changed the URL displayed in a web browser from - http://mybank.com/default.asp?id=3 to http://mybank.com/default.asp?id=3;SHUTDOWN.

The URL managed to submit a request for the database server to shutdown and the new banking site was instantly unavailable.

2. Your application does all of its validation on the client

As a general rule, validation on a client is for user friendliness. The server should always do the primary validation. (And make sure to do the validation before your application consumes it.)

It is too easy to intercept requests from a client, modify them, and forward them on to the server. This is especially easy for web applications through the use of a proxy. Programs like Web Scarab are very good at this.

And the number one sign that application is susceptible to SQL Injection attacks…

1. Your application communicates with ANY sql database

No SQL database can avoid be exposed to these attacks. Whether it be Oracle, MySQL or MS SQL, a valid SQL statement can be manipulated to return unexpected results.

However, being aware of this fact and taking steps avoid SQL Injection attacks is the first step in building up your application’s immunity.