HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Displaying articles for: July 2006

SQL Injecting Microsoft Access



It is widely believed that
retrieving data from a Microsoft Access database using SQL Injection is more
difficult than more robust databases such as MySQL or SQL Server. There are two
reasons for this misconception. First, widely employed “Convert/cast Error”
attacks do not yield database information in the error message.  Second, default read permission to system
tables is set to “Not Allowed” which is important to retrieve vital information
such as table names and column names. Often this is used as an excuse not to
worry about SQL Injection in web applications with MS Access as the backend.  However, this is true if attackers only rely
on using system tables to acquire information about tables and columns. What we
want to point out is that it’s not necessary to access system tables to extract
database information.



What if the attacker already has
information about the database behind the web application and knows table names
and column names. For example, if the target is a former employer or customer
of the attacker he can use Blind SQL injection to extract the data.  In some cases, union queries can be appended
to the SQL allowing the attacker to retrieve additional data along with the
data that is supposed to be displayed the web page.



            Another
case if you use database wizards, sample applications, or common open source
applications as a base for your web applications, you may be exposing to an
attacker as much information as he needs to extract data from your database.  Finger printing these canned applications is
fairly easy and since they are open to anyone, the attacker has the blueprint
of your application.  Again, the attacker
could use Blind SQL Injection or union queries to extract the data.



            Even if an
attacker doesn’t have access to system tables or prior knowledge of the
applications database, it can always be brute forced.



            The real
solution to the problem is removing SQL Injection possibilities regardless of
the database being used.  Ways to protect
against SQL injection are validating input parameters in your application.  Use parameterized queries to avoid appending SQL
commands.  Avoid using databases created
by Access wizards and sample databases. 
Also, avoid using canned applications from shared hosting providers.  If you do use open source applications,
obscure your database by changing the table and column names so that they are
less easy to guess by an attacker.

Whitelisting: Not just for Web Applications Anymore...



An interesting vulnerability was
found this week in a prominent web app firewall. A user could append a pound
sign (#) to the end of any URL and bypass all file type restrictions the
firewall implements. This is yet another example of a fundamental problem in
the computer industry: Using blacklisting (checking that the input doesn’t
contain something bad) instead of whitelisting (checking that the input only
contains what is good) for input validation. Blacklisting fails as soon as an
attacker finds a new way to send malicious data that you are not looking for.
Worse, there are a near infinite number of ways to send bad data. Whitelisting
is more effective because you already know what the allowed characters or data
types for an input are. Denying all input that isn’t allowed protects against
all attacks regardless of whether they are known or unknown.





We’ve talked about this filtering
problem before but it’s important to note that it exists all over software
industry.  Another instance of the same
carelessness in web apps took place in the IIS Unicode vulnerabilities, where
characters such / and \ had Unicode equivalents that were not filtered by the
app.  Therefore, one could craft a URL
such as http://site_got_owned.com/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir
to execute arbitrary commands.



            The filtering
problem is also quite prominent in standard executable/binary applications as
well.  IDS/IPS filters have problems with
packet fragmentation and signatures that only catch one variation of an
exploit.  Another problem occurs when the
vendors of a vulnerable program only patch the execution path leading to the
vulnerable code and not fixing the problem itself.



            Far too
many products use and have used the practice of blacklisting. Not only is
blacklisting less secure, it is also more resource intensive and far more prone
to false positives that whitelisting.  The
lesson here is that all applications, web or otherwise, must be secure by
design and should not depend on any sort of firewalling or 3rd party
application to protect or sanitize or verify data for them.  SPI recommends integrating whitelisting
directly into the application. The security of your organization may depend on
it.

The Dangers of Shared Hosting:

When you pay someone to host your website, chances are your site isn’t running on a single box all by itself. Hosting companies like GoDaddy or Rackspace use shared hosting, which means your website is stored on a computer with multiple other websites to conserve resources and raise profits. This leaves your data on a system that is making all of its users share the same resources assuming that none of the users will run vulnerable software. This means that if one of those users is compromised, then all the users are compromised. Are you prepared to put your site’s security in other people’s hands?

We touched on the issue of default scripts in a previous post where GoDaddy servers were compromised. Hosting services may provide default web pages, scripts, or CGI gateways for sending mail, uploading files, posting to forum, etc. These are dangerous for two reasons. First, they are open source so that anyone who uses that hosting provider can see the source code and find vulnerabilities. The trick is only customers of the hosting provider can examine the source so the scripts don’t get the same number of eyeballs finding problems as traditional open source applications get. The second reason default scripts are dangerous is due to the further reaching consequences. This means that if an attacker finds an issue in a default script and can properly exploit it, then all the accounts on that server could be compromised. Exploitation like that could be far reaching to thousands of domains with thousands of users all running off of a single server. This high payout for a single vulnerability means that shared hosting environments are targeted more and more by attackers.

Blind Attack Methodologies Come of Age.

While current vulnerabilities are still a threat, a new
breed of so-called “blind” vulnerabilities is coming of age. This new strain of
threats are not as blatant or easily executed but can be just as dangerous as
traditional exploits in the hands of an attacker.


 


Until recently, the only popular instance of this class
of vulnerabilities was Blind SQL Injection.  Blind SQL Injection can have the
same consequences as SQL Injection.  The main difference in the two methods is
that instead of sending a SQL statement, Blind SQL Injection attacks use a
series of True and False statements to determine if the vulnerability exists.
While Normal SQL Injection attacks only work when the application returns
detailed error messages, Blind SQL Injection works by looking for subtle changes
in the behavior of the application itself, such as links no longer working after
an attack string was submitted.  For more information on this, refer to the
Blind SQL White paper available at http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf.


 


Blind SQL Injection is a rather well known attack now. But
the “blind” methodology for detecting vulnerabilities by behavioral changes
instead of receiving known error messages extends beyond Blind SQL Injection.  A
few days ago, a new vulnerability was disclosed in a popular PHP based
application.  This vulnerability allowed an attacker to discern the existence of
files based on error messages by giving a new path for a file instead of the
default.  With this kind of vulnerability, an attacker could brute force
existent directories or files to discover valid usernames, temporary files,
directory structures, or other information that could lead to the escalation of
other vulnerabilities if not to complete compromise of the
system.


 


These kinds of attacks are possible because of a
combination of input validation and logical flaws in the way error handling is
done.  While the application doesn’t display an error message allowing the attacker to
know something worked, the subtle changes caused by the attack are detectable
and reveal the same weaknesses.  Unfortunately, due to the nature of logic based
vulnerabilities, it is difficult for modern vulnerability scanners to discover
these kinds of unknown issues and so they completely fail to detect this class of threats.  This occurs because traditional methods of detecting
vulnerabilities are based matching some known pattern of letters (string
matching).  Without knowing the subtle ways the application might react,
scanners simply don’t know what to look for. With these new attacks
methodologies, new types of detection become necessary. Here at SPI Labs, we’ve
got a few ideas…

Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog

Featured


Follow Us
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.